Closed whaleygeek closed 6 years ago
At the moment Raspbian still installs Mu version 0.1 from their repositories (http://archive.raspberrypi.org/debian/pool/main/m/mu/). There hasn't been any other releases yet, so if speech is not included in the version they currently have, there is nothing to upgrade to using apt-get
.
I am not 100% sure if this version already had a help button? I believe it does, so to find out which version you have you could click on it and it should open a browser pointing to the corresponding version of documentation.
If they need to get the latest version of Mu they can always "install from source" (manually install dependencies, and pip install -r requirements.txt
). There are instructions on the README file.
Alternatively, they could try the latest development deb files from http://ardublockly-builds.s3-website-us-west-2.amazonaws.com/index.html?prefix=microbit/raspberry_pi/ Instructions can be found on https://s3-us-west-2.amazonaws.com/ardublockly-builds/microbit/raspberry_pi/installation_instructions.txt However, I would not quite recommend this method, as these are really only meant for development and testing purposes and might not work exactly as expected (there could be clashes with the versioning with previous or future released of the "proper" deb packages).
Thanks @carlosperate - it would be helpful for those that want to use the latest version of Mu on the Raspberry Pi, if there was an easy way to bypass the 'official' repos and just get it from a 'latest greatest' repo - is it possible that PSF could host a 'latest' repo somewhere that @ntoll can just push a .deb to when he does new releases - we can always write up some instructions for people as to how to add an additional repo to their repo configuration, and the apt-get would then get a more up to date version.
I'm not sure it's fair to keep asking Raspberry Pi Foundation to update the Repo list, I'm sure they are very busy with other stuff! So an (optional) way to bypass standard repos for those that want a more up to date version by choice, would be really helpful.
A Raspberry Pi Community Repository maybe a good idea.
Does anyone know how we could manually install Mu on a Raspberry Pi from latest, without any sort of build being required? I have some non-techy people in the community that want to use the latest features, but the repo is out of date, and I need an alternative way for them to install latest and greatest on their Raspberry Pi.
microbit.org-ticket: 283
@whaleygeek just follow the developer setup instructions. It should be as simple as:
--python=/usr/bin/python3 --system-site-packages
)pip install -r requirements.txt
./run.py
CHECK THESE INSTRUCTIONS FIRST - they're off the top of my head so there maybe devil in the detail but the general gist of it is correct.
As for keeping it up to do - you should ping the RPi Foundation. It's completely out of our (Mu's) hands.
Btw, I have fixed the builds I had running on a raspberry pi here, so as a last resort you could look into running the bin files from http://ardublockly-builds.s3-website-us-west-2.amazonaws.com/?prefix=microbit/raspberry_pi/ These are not really supported, they are generally used for testing and I cannot guarantee that they will work, but it's easy to check if they do (just download, add executable permissions and execute).
a better way to run on rpi would be to clone mu (git clone https://github.com/mu-editor/mu
) then run sudo python3 setup.py install
It looks like not all dependencies are packaged correctly in this, pyflakes is missing, apparently?
Can someone check the packaging and make sure everything that is needed is listed?
Thanks!
On 19 Dec 2016 6:12 pm, "Zander" notifications@github.com wrote:
a better way to run on rpi would be to clone mu (git clone https://github.com/mu-editor/mu) then run sudo python3 setup.py install
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mu-editor/mu/issues/185#issuecomment-268035843, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAS7nUHuOUdoiulJ1ogEM99vlHAcdks5rJsj8gaJpZM4KwhaM .
Could you clarify which method do you mean? Installing the packages that @ntoll listed + requirements.txt should cover all dependencies.
Was using Zander's simpler instructions, as I don't think it's fair to ask non-techy users to follow the more complex steps.
On 21 December 2016 at 21:38, Carlos notifications@github.com wrote:
Could you clarify which method do you mean? Installing the packages that @ntoll https://github.com/ntoll listed + requirements.txt should cover all dependencies.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mu-editor/mu/issues/185#issuecomment-268647223, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAb3IjxGZn21rLad2hKw-4kqYI3Biks5rKZxMgaJpZM4KwhaM .
Would it be possible to have an install.sh script that people could download and run, that did the necessary install steps automatically on Raspberry Pi? There looks to be quite a lot of intricate steps there, and I'm not sure that all of them are completely defined as a set of commands that an average user could just type in and run without knowledge of how to do that sort of thing.
I've contacted Raspberry Pi Foundation a number of times, and have had no luck getting them to update the Repo's, so we need a much simpler way to install Mu on Raspberry Pi that bypasses those Repo's, if we want the average user to be able to use all the great new features of Mu.
Thanks
David
On 21 December 2016 at 23:12, David Whale david@thinkingbinaries.com wrote:
Was using Zander's simpler instructions, as I don't think it's fair to ask non-techy users to follow the more complex steps.
On 21 December 2016 at 21:38, Carlos notifications@github.com wrote:
Could you clarify which method do you mean? Installing the packages that @ntoll https://github.com/ntoll listed + requirements.txt should cover all dependencies.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mu-editor/mu/issues/185#issuecomment-268647223, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAb3IjxGZn21rLad2hKw-4kqYI3Biks5rKZxMgaJpZM4KwhaM .
We could add a shell script, but then it would be yet another way to install dependencies, I think we should instead make sure we have a more unified method. Unfortunately we are in a bit of an uncertain transition period, PyQt wheels are now available through PyPI, so we could do a full dependency installation from pip/setup.py, but at the moment there are different incompatibilities on each platform. Apart from that I will assume a wheel for ARM Linux is not in their roadmap, so we would still have to create a deb file that depends on the apt package repository, and that should be added to the raspberry pi repositories.
As far as this whole deb package thing goes, I think we just need to communicate with each other a bit better. I could be wrong, but I've got the impression that we are basically saying "here is the repo! you can create a deb file and publish it", and they are saying "send us a deb file and associated files and we'll publish it!".
In the meantime you can install all the packages required from apt, similarly to what the deb package would do:
sudo apt-get install python3 python3-setuptools python3-pyqt5 python3-pyqt5.qsci python3-pyqt5.qtserialport python3-serial python3-pep8 pyflakes
git clone https://github.com/mu-editor/mu.git
cd mu
python3 run.py
@whaleygeek I'll be visiting the RPi Foundation in the new year. I'll raise it with them in person. It's definitely something to keep tabs on.
@ntoll, if you come on the 10th you could then make it to the Cambridge Python user group meetup as well :) Physical computing by @bennuttall https://www.meetup.com/CamPUG/events/233934900/
Depending on family commitments, I might just do that. ;-)
@ntoll I remember when I met you in Cambridge you said you had met with the Raspberry Pi foundation to discuss this. What was the outcome?
You say that Mu 0.1 is installed on Pi @carlosperate but how did you determine that? How could our users determine that it is version 0.1, as I don't see any visible evidence in the installed code. Is there a hidden log or something we can get users to check to inform us of which version of Mu they have, when they are logging tickets with us?
@ntoll In order to escalate tickets effectively over to this repo with sufficient minimum information for you to process, we need to be able to capture the version number of the editor that users are struggling with, in case the problem they have has been fixed in a later release.
Can you provide an update of where we are in that thinking at the moment, and when we hope to have visible version numbers displayed in Mu? Thanks.
About new releases: I believe once the pending issues on MicroPython are resolved we'll release an new version of Mu with the latest micropython, and that version will be included in the raspberry pi repositories.
Right now only version 0.1 has been released in the raspberry pi repos, so if Mu was installed using apt-get, then that's the version they have.
One way to find out which version you are running is to look at the logs. One of the things we need to do is to better document how to access this file. If the application is executed from the command line it will print the log location on console, but it's not a straightforward process outside of linux.
To find out which version you are running from the application itself you can check the help. Clicking that button should open the documentation specific to the Mu version the user is running, and can be identified through the URL. This online documentation could also be updated to better display this information (and if there is a new version that could be installed)/
@whaleygeek I met the person responsible for packaging Mu when I visited the RPi Foundation. Now that we know each other he's aware there will be a new version of Mu in the coming weeks and has promised me a quick turn-around when it comes to packaging. I'll put my thinking cap on about logs / versions etc.
Not a brilliant solution but pressing help opens http://codewith.mu/help/<version>
providing a non-command line method to obtain version information
In addition to following this advice...
sudo apt-get install python3 python3-setuptools python3-pyqt5 python3-pyqt5.qsci python3-pyqt5.qtserialport python3-serial python3-pep8 pyflakes
git clone https://github.com/mu-editor/mu.git
cd mu
python3 run.py
If you go into mu directory and edit interface.py edit lines 534 and 535 to
self.setIconSize(QSize(25, 25))
self.setToolButtonStyle(0)
also edit line 891 to
self.setMinimumSize(800, 400)
It now fits beautifully on a raspberry pi official display.
@jg00dman please note markdown has support for code blocks allowing
In addition to following this advice...
sudo apt-get install python3 python3-setuptools python3-pyqt5 python3-pyqt5.qsci python3-pyqt5.qtserialport python3-serial python3-pep8 pyflakes
git clone https://github.com/mu-editor/mu.git
cd mu
python3 run.py
If you go into mu directory and edit interface.py edit lines 534 and 535 to
self.setIconSize(QSize(25, 25))
self.setToolButtonStyle(0)
also edit line 891 to
self.setMinimumSize(800, 400)
It now fits beautifully on a raspberry pi official display.
to be better expressed as
In addition to following this advice...
sudo apt-get install python3 python3-setuptools python3-pyqt5 python3-pyqt5.qsci python3-pyqt5.qtserialport python3-serial python3-pep8 pyflakes git clone https://github.com/mu-editor/mu.git cd mu python3 run.py
If you go into mu directory and edit interface.py edit lines 534 and 535 to
self.setIconSize(QSize(25, 25)) self.setToolButtonStyle(0)
also edit line 891 to
self.setMinimumSize(800, 400)
It now fits beautifully on a raspberry pi official display.
Then by specifying the language syntax highlighting is avalible
In addition to following this advice...
sudo apt-get install python3 python3-setuptools python3-pyqt5 python3-pyqt5.qsci python3-pyqt5.qtserialport python3-serial python3-pep8 pyflakes git clone https://github.com/mu-editor/mu.git cd mu python3 run.py
If you go into mu directory and edit interface.py edit lines 534 and 535 to
self.setIconSize(QSize(25, 25)) self.setToolButtonStyle(0)
also edit line 891 to
self.setMinimumSize(800, 400)
It now fits beautifully on a raspberry pi official display.
Blocks are opened and closed with triple backtick (`) and a language is specified by placing the language name directly after the opening triple backtick (eg
python`)
Thanks - I'm new to this... I've got a patch ready which is better, it responds to changes in the window size. I've tried to submit a pull request... had to learn what a pull request was;)
pull request submitted for patch available here: https://github.com/jg00dman/mu
Don't worry about it 😄
This Guide gives you an idea of Markdown formatting for GitHub
Note you can also reference other issues / PR's with # e.g. #246
@jaustin This is the ticket that is tracking both the 'discovery of version number' and 'how do we even install the latest Mu on Raspberry Pi without it being in the repos.
@whaleygeek I think it might help clarity if we broke out a ticket for "I'd like to install the latest version of Mu on a Raspberry Pi really easily" - that way we can track that separately to the version number.
I think for the time being we need to recognise that Mu will change faster than the default RPi images do (and that's a good thing!) so having a way for people to get a latest would be great. I'm happy to create that issue if @carlosperate and @ntoll are happy with me splitting this conversation.
Please do! :-)
@whaleygeek From memory:
#!/bin/bash
# Download & Install Mu on Raspberry Pi (And persumably Debian in general)
git clone https://github.com/mu-editor/mu/ # Clone mu
cd mu # Enter mu's directory
git fetch --tags # Get tags from the server
latestTag=$(git describe --tags `git rev-list --tags --max-count=1`) # Work out what the latest tags is (i'm assuming it's for a stable release)
git checkout $latestTag # Checkout the latest tags
sudo pip3 install -r requirements.txt # Fetch the requirements from pip
sudo python3 setup.py install # Install mu making it avalible in the Applications menu
cd .. # Return to parent directory
rm -rf mu # Remove the folder we cloned mu into
Erm, that's very complex, not at all teacher friendly, won't work if the Pi's are not connected to the internet (as they rarely are due to the fact that the Pi stores the wifi password in plaintext and most technicians ban Raspberry Pi being internet connected as a result).
What we really need is a single link that teachers click on to get a package, they copy that onto a USB memory stick, copy it onto the pi, unzip it and run something that installs it ready to go. Is that possible?
Unfortunately that wouldn't work for getting the Qt dependencies onto the Pi so internet would be required for that.
To reduce typing in commands we could put a copy on the website to simplify to something like curl https://codewith.mu/getmu.sh | bash
However that said i'll put some thought into an offline get mu package for the rPi....... (no promises)
Thanks very much for your help and ideas. Needing internet access to install things on the Pi is a right pain in schools to be honest. It's one of the main reasons many schools give in with them, they are so hard to update due to the requirement to be connected to the internet to install software. In many of the pi clubs in schools I work in, the rooms we use the Pi's in have no internet access at all, and the technicians will not give us access to wifi for reasons said. At a pinch we sometimes tether to our phone, but for a big download on 15 pi's that's out of the question.
"and the technicians will not give us access to wifi for reasons said" <- this is a very sad state of affairs.
Reasons said being 'the wifi password is stored in plain text'.
Been reading through pip
docs and hopefully after some playing tomorrow i may be able to compose some instructions for getting mu onto an offline pi (thinking of names: 'mubox', ' mupack', mupill'...?)
Of course the fact that Raspbian is using py2 by default is slightly complicating.
If all goes well the end result should be a (albeit fairly large) zip + script containing everything required for copying onto Pis and installing Mu
Yep it can be a pain updating a gaggle of Pi's....I normally run into this issue in the library with slow public internet which then causes the updates to trickle down really slowly.
I figured out how to get round this years ago for a different reason...I have meant to do a blog post about it but completely forgot.
Annnnyway...
(I'm quickly typing this from memory)
Connect one Pi up to the internet...via your phone or other means. Dont worry there wont be any significant data use for this part.
Open a terminal and switch to root
apt-get update apt-get --print-uris --yes upgrade | grep ^\' | cut -d\' -f2 >downloads.list
Copy the downloads.list onto a pendrive and take to another computer.
If its a Linux machine (not sure about Windows) create a directory and run the following inside it: wget --input-file \<path to downloads.list>
This will download all the required .debs down...once complete copy them onto the pendrive
Back on the Pi copy the downloaded files into /var/cache/apt/archives
Rerun apt-get update && apt-get upgrade
Pi will then upgrade from files in the archives.
Take pendrive to next Pi and repeat.
If your just after a single package change upgrade to the name of the required package.
This technique in effect makes apt think its already got the files downloaded and it just needs to install them. First used it many moons ago to get some drivers installed an ancient server in datacenter.
Further reading can be found: http://www.tuxradar.com/answers/517
Now, I'd better get that blog post done :D
@davidwhalemef I think this is my queue to come swooping in with a PiNet plug!
PiNet of course gets around the internet issue (ish) by allowing you to install it in one place, then have that pushed out to all the Pis on the network.
Obviously it requires the Pis to be networked (wired only), but does get around the whole copying files 15 times.
I am well aware of many schools using PiNet without web access to the PiNet server. If they need to add anything, they simply throw the PiNet server into their car boot, install whatever with their home internet connection then bring it back in the next day, ready to go.
Plus, PiNet Jessie comes with Mu (whichever version is in Jessie) built in :)
As for:
as they rarely are due to the fact that the Pi stores the wifi password in plaintext and most technicians ban Raspberry Pi being internet connected as a result
Thats a poor excuse for banning...it seems that the techs dont want the extra workload of allowing the Pi onto the network. I'd be concerned if its only a WiFi password controlling access to a WiFi network in a school.
Some times you need to play them at their own game.
PiNet is ace but then you have the overhead of carting the networking stuff around which may be silly for a codeclub/event thats only an hour or two long.
As for taking the server home...they dont have to if they follow what I posted earlier. All they would need is the download.list to take home, the can then just download whats needed and bring it in on a pendrive or some such.
Could also go the full hog of hosting your own mirror....now that would be overkill :D
Hi, I'm a friend of ntoll's, sporadic Pi user, and a long time cyber security consultant - and seeing this mentioned on Twitter piqued my interest.
First of all note that other operating systems don't appear to keep their WiFi password particularly well hidden either, i.e. Windows 10: https://www.itechtics.com/2-ways-find-saved-wifi-passwords-windows-10/ ; I only mention that in passing as information to keep in hand if you need it, rather than I'm advocating you badger your school technicians about appropriate threat modelling ;)
From my limited understanding of the situation the ideal solution to this situation is a "guest" wireless network with separate SSID and password to the main school network; however I don't recommend trying to force school technicians into the required VLAN configuration either - but this isn't my area, their kit might have an easy option here, it's certainly worth asking IMHO.
My suggested solution would be to run a "spare" Pi as a dedicated class hotspot, using something like "http://elinux.org/RPI-Wireless-Hotspot" - attach an appropriate WiFi adapter and that Hotspot-Pi could run a wireless network purely for the other Pi's, with the Ethernet connection either going directly into the school network, or connecting to the Ethernet port of a teacher's school laptop - that laptop then uses it's wireless connection with Windows' Internet Connection Sharing to send the traffic off to the Internet over the school Wireless LAN.
Depending on the technical knowledge of the tutors the repeated use of Network Address Translation here could be diagrammed, which will make any professional network engineer cry, but also teaches how malleable network connectivity can be. ( In the same way I really like the look of PiNet above, just to introduce some key IT concepts to students around user account management, and users being separate from "their" hardware ).
Using a Pi as a WiFi hotspot will probably show up throughput issues in the hardware, but there's a lesson there; and in the same way this solution would give a concrete example of how useful a general purpose computer can be - that tiny box you're using to play games and/or learn python, is now routing traffic like that mysterious white box your ISP sent your parents.
Also the security issues - i.e. can you run any kind of firewalling on the "Hotspot-Pi" to only permit the Pis to access appropriate online repositories, and also what can you see if you run a packet sniffer, fits in nicely with the DCMS drive for teaching cyber security skills ( http://www.computerweekly.com/news/450412747/DCMS-announces-cyber-clubs-programme-to-teach-6000-students-cyber-skills ). So there might even be a way to use this dilemma to illustrate cyber security problems to students.
I definitely see that there's pain here, but illustrating that pain, as well as the "yak shaving" ( https://en.wiktionary.org/wiki/yak_shaving ) required to make Mu work, will give students an insight into the nature of IT problems.
NOTE - I realise I've written a relatively long post that is in "yak shaving" territory itself, so of course I'm happy for this comment to be moved, or deleted, or whatever the appropriate administrators need to do to keep an online thread on subject, and I'll discuss this directly with ntoll at some point.
Yep, all relevant and this could spawn a new package for the Pi... ClassroomConnector or something similar :D
As an aside, I did do some work on the hotspot side of life a while back...just need to be stop being lazy and get the updated libraries plumbed in. Also probably refactor it as well :)
Its at https://github.com/heeed/PiSpot if you want a look
Folks,
That's an epic response @OakTwo - everyone else, I have nothing but huge respect for @OakTwo's expertise in cyber security and when he talks, I listen.
I believe the problem isn't technical - it's a harder category of problem: It's political.
Historically, many schools received Public Private Partnership funding (introduced by the Labour Government) to build infrastructure, but this came with strings attached. For example, long term contracts for said private third parties to run school IT infrastructure. It means it's common for school teachers to be using equipment over which they have no control. If they want new software installed they need to go through a bureaucratic assault course to make it happen (and that also costs the school money, as the third party will insist on a risk assessment). Furthermore, it's not the school who employs such technicians, but the third party supplier. From a purely commercial point of view they have no interest in educational attainment - they're simply concerned with ensuring the school network is constrained enough such that they meet legal requirements and are protected if anything goes wrong ("we did everything we could"). This is why school technicians are so risk averse. Finally, if a teacher took the situation into their own hands and, by having physical access to the computing devices, just re-installed the OS, added their software and configured stuff to their own requirements, they'd be fired for misconduct since the school would be in breach of contract with the third party supplier.
Add to this the problem that having a third party supplier actually looks convenient to a school's (too often ignorant) senior management team / board of governors, and you can see why this is a political / cultural problem rather than anything technical.
Upon reflection, I'd just buy a 4G access point (they're about £50 and provide a fast enough connection) and connect the Pis to that. This is the path of least resistance and completely bypasses the tragedy that is school IT infrastructure. It's an example of yet another battle we will have to fight in the education world, and it's important to acknowledge it, but Mu is not the place for this battle. While we will always endeavour to make Mu as easy to install and accessible as possible, we cannot burn through valuable time and effort tackling what is, essentially, a political problem. What I'm saying is there are better ways to fight that battle.
So my advice to @DavidWhaleMEF and others is to bypass the school completely and buy a 4G dongle. This isn't the answer I want to give, and I regularly feel this sort of pain too (which is why we should make Mu as easy as possible to get onto a Pi), but we're volunteers and there's only so much we can do. I believe, when we next release Mu and it's properly packaged in Raspbian much of the problems discussed above will disappear. Yet again, we run into the too-much-to-do-and-not-enough-time-to-do-it-in problem. We'll get there... patience and mutual support is what we need (and I know I can certainly rely on @DavidWhaleMEF for that).
Phew.
If they want new software installed they need to go through a bureaucratic assault course to make it happen
I fear this is a slight understatement.
Irony is with Chrome Apps & Co much of the restrictions become irreverent:
No you can't possibly use: | Alternative |
---|---|
VNC Client | VNC® Viewer for Google Chrome™ |
SSH Client | Secure Shell |
Access the C Drive |
Use 7-Zip which i find is often installed |
and so the list goes on.....
@whaleygeek @DavidWhaleMEF I thought you might like to know, and pass on, the ability to store an encrypted WiFi password:
Running this:
$ wpa_passphrase YOUR_SSID YOUR_PASSWORD
Will spew out:
network={
ssid="YOUR_SSID"
#psk="YOUR_PASSWORD"
psk=6a24edf1592aec4465271b7dcd204601b6e78df3186ce1a62a31f40ae9630702
}
Then just use the uncommented 'psk' line in wpa_supplicant.conf
Okay, I've created #249 to track the installation side of this, scoping it specifically to something for much less technical audiences :)
A few notes I've carefully considered as useful/relevant, so I've kept this as brief as possible, happy to take personal followups to avoid taking up everyone's time, for the "TL;DR" version just read the first point below ;)
The thing about the 4G access point is that is a cost...if you, for example, have 10 Pi to update each with 100MB of updates your looking at around a 1GB of mobile data usage.
Also how does that fit if older non-WiFi capable Pi are in use?
Beauty of my solution is that once you have the files downloaded you can copy them onto the Pi and leave it to update and there is no need to updated any config files.
Closing since the version of Mu is displayed in the title bar of the Window.
Smashing, thanks @ntoll
I have a user who is trying to get speech working on the Raspberry Pi version of Mu, and it is failing with an error saying 'no module named speech'.
I got them to do an update/install of mu from the command line, but it still does not work.
a) How could they tell me what version of Mu is actually installed at the moment? b) what version of Mu on the Pi does the speech module get introduced? c) If the RPF have not updated the repo's, how can a user get the latest greatest version of Mu installed on the Raspberry Pi, without having to wait for this repo update to happen?
Many thanks!