Create a new .deb package so the editor is easy to install on Debian based systems. #58
Comments
|
@bennuttall this is the ticket for .deb-ifying the editor. |
|
Great - thanks |
|
I'm going to go through this process to get the package into Debian: |
|
See PR #102 for a start on this. |
|
Unless we want to publish the deb package somewhere else, looks like we can close this issue :) |
|
Is there a link somewhere "upstream" (Debian?, Raspbian?) to which we can point for the package. It'll mean that this issue resolves by pointing at the solution. :-) |
|
This list points at this location where the deb can be found. |
|
Also sudo apt-get update
sudo apt-get install mu |
|
I've downloaded the mu binary for my Debian system but when I try to run it I get the error "cannot execute binary file". I assume this is because the binary is for a 64 bit system and I'm running 32 bit. Is this correct and if so will there be a 32 bit binary available in the future? Thanks. |
|
Looks like now that Mu has started using PyPI dependencies that might not available through the OS package manager we need to figure out a way to include these. @asb have you seen or used dh-virtualenv before? |
|
@carlosperate is this actually fixed now? I notice there's a debian directory rules/control file etc? |
|
The dependency issues have been fixed (we have "temporary" fall back on the code due to package rename). The files in the debian directory are up to date (the changelog is in sync with the history file), so a deb file and associates files can be created by running the respective command line tools. |
|
Cool, thanks for the explanation - I wasn't actually planning on building
any packages yet, just more interested about how ready it was to happen -
Looks like there's not a package in upstream Debian at the moment?
…On 4 January 2017 at 13:09, Carlos ***@***.***> wrote:
The dependency issues have been fixed (we have "temporary" fall back on
the code due to package rename). The files in the debian directory are up
to date (the changelog is in sync with the history file), so a deb file and
associates files can be created by running the respective command line
tools.
As a quick note, if we were to create a new deb file right now, it should
be done on c2a0f23
<c2a0f23>
, as that's the last documented release. For a newer release we should
update the changelog.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#58 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAI-qTwoq1BfcClwxj5oaczNT7TfpwJKks5rO5nzgaJpZM4HCpiE>
.
|
|
To be able to install a mu .deb package on, at least Debian stable and Ubuntu LTS, some dependencies requirements should be downgraded: This would also make installing mu with pip easier (no specific virtualenv required). |
|
We're also stymied since there's been zero action on this (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892198) in upstream Debian. Any suggestions for how to move this forward? |
|
@ntoll An "in between" solution could be to provide a .deb package and let users download it and install it using |
|
I believe there's also a plan to have this package available in our PPA: https://launchpad.net/~rpi-distro/+archive/ubuntu/ppa But yeah, a .deb on the site would be handy too! |
|
@bennuttall if there's a plan, it'd be good if this were properly communicated. Open collaboration etc etc etc ... (I know I'm preaching to the choir here, just saying this here so it's logged for future reference). ;-) |
|
@XECDesign can you confirm it would be possible to add to our PPA once Mu is released? |
|
It's possible, but that will be decided once we have a release ready to go for Raspbian. I'd recommend focusing on getting the package into Debian and Ubuntu properly. That will help steer development in the right direction and avoid adding difficult dependencies. |
|
Hey hey @XECDesign, the only difficult package that I can think of right now is referenced in this bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892198 Is there anything we can do to help make this happen..? |
|
I haven't been following the development since Peter's feedback, so I don't know how much of it has been addressed. I'm only responsible for getting the release into our distro of Raspbian. |
|
Completely understand. Busy people are busy (aren't we all?). Can you suggest anyone upstream-Debian related who may be able to sit down with me (perhaps in London) so I can buy them food/drink in exchange for answering my questions and pointing out how best to unblock the various issues. |
|
@ntoll Have you tried contacting Riverbank about the PyQtCharts package? I don't know if they are responsible or involved in the Debian packages for their software. |
|
Honestly..? Right now I'm up to my eyes in all sorts of Mu related things which I'm trying hard to juggle, resolve and make good for a 1.0 release. I simply don't have the time to keep asking people (like Riverbank and/or Debian related folks) about yet more stuff they're only going to say they don't have time to do. My hunch is if Riverbank were responsible for packaging PyQt and associated modules for Debian, it would have already been done. Furthermore, someone may even have replied to my bug report about the missing package. I can't help but feel like I'm going round and round in circles here. :-( |
|
I'm not in that world, so I wouldn't be able to point to anybody. Peter might know of some Debian conventions or meet up groups which could be helpful. |
|
DebConf is in Taiwan I believe so probably not convenient... |
|
Taiwan would be fun, if time consuming @ZanderBrown. @XECDesign, completely understand... I'm just trying to effectively, politely and collaboratively unblock something that's been unresolved for far too long (and which if I could do myself, I would have done ages ago). |
|
@skitt can you give some advice? |
|
I have a couple of questions regarding the current inclusion of the debian/ directory in the repository and release tarballs, the topic of which is discussed in the "Guidelines for Upstream" [1] @skitt points to. [1] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source The guidelines recommend omitting an upstream's debian/ in release tarballs, and to consider keeping packaging work in a separate branch in the repository. i) Per the guidelines, is dropping debian/ from release tarballs going forwards an agreeable proposition? ii) Once mu is accepted into Debian/Ubuntu, is there an intention to sync (e.g. after a new release is packaged for Debian) the "official Debian" debian/ structure (either fully or in part) back into the upstream source? Would the upstream debian/control be updated to reflect the codebase's current dependencies? |
|
I see we are in Raspbians new "Recommended Software", nice. (It's beta 15) |
|
@knowledgejunkie re (i), dropping the Re (ii), that’s a tough question. Ideally, For Mu all this is somewhat moot anyway since some essential dependencies aren’t available in stable releases of anything. The first release of a distribution with Mu will be Ubuntu 18.10 as far as I’m aware (I’m unfamiliar with the Raspbian release process); we can revisit the situation when that’s released. |
|
It's a beta behind and doesn't seem to have all modes enabled but Raspbian is already shipping us (latest release was this week) |
|
On 30/06/18 15:29, Zander wrote:
It's a beta behind and doesn't seem to have all modes enabled but Raspbian is already shipping us (latest release was this week)
No, the raspberry pi foundation is shipping mu through their repos and images for raspbian. The raspbian project has nothing to do with those builds.
|
|
@plugwash Aha... thanks for the clarification. I always thought Raspbian was "supported" / maintained by Raspberry Pi. I guess not. In that case, I believe Mu won't get into Raspbian until Raspbian gets the package from whatever distro it uses as upstream (Debian stable?), right..? |
|
Just a quick heads up... due to some late-breaking changes in how the micro:bit mode works, I've had to introduce a new dependency on the |
|
I've pushed initial packaging of Mu to debian mentors [1] for review by any interested Debian Developers and testing by any adventurous users, and pushed the gbp-based packaging repository to salsa.debian.org [2] [1] https://mentors.debian.net/package/mu-editor Key dependency python3-pyqt5.qtchart has just reached Debian testing/sid thanks to @skitt. python3-pgzero is currently in sid thanks to @plugwash. Details:
|
|
Is there a ready-made deb I can download and install, or do I build it locally? I can try an install and play over the weekend. |
|
There is no ready-made deb to download, as it's intended that testers (i.e. users not reviewing the underlying packaging) check out the mu-editor repository from salsa.debian.org and build it locally using their preferred build system. However, I could send you a locally-built deb (that I'm running locally) if that would help? |
|
I'll do the salsa checkout and build no problem. But having a pre-built deb as well would be good to act as a check that my build does the same thing as someone else's. |
|
I've just pushed a new respin of the packaging to my salsa repository; please delete and reclone the repo if you've already checked it out. As of this update, the package is placed in the non-free/python section due to the inclusion of the pre-compiled micro:bit firmware in mu/contrib/uflash.py. |
|
Is it possible to split the non-free part to a separate package? It'd be a shame to have mu in the non-free repository. |
|
By way of an overdue update (and paraphrasing a recent update on the uflash issue tracker), I've built the MicroPython DAL locally on Debian testing/sid (using yotta and uflash from pip whilst their packaging is in progress) without the non-dfsg-compatible SoftDevice binaries present, flashed my microbit and tried a few examples, which work \o/. Building the upython firmware with the current buildchain dependencies in Debian testing/sid did not work out-of-the-box (as others have also found) but it did seem to generate a working micropython environment. I also noted that the filesize of the generated firmware is different to that recently committed to uflash (built by @carlosperate ?) - I'm thinking (and hoping) that this is solely due to differences in the build toolchain only. Note that I am not an embedded (or cpp) developer, and installed the build deps per the micropython instructions). In terms of finishing the Debian packaging for mu, the next steps seem to be:
With builds working without the SoftDevice binaries present, it looks (to me at least) like the firmware (and packages such as mu/uflash which depend on it) is suitable for the main part of the Debian archive (and not non-free). We're getting there... |
|
Hi folks, As you'll no doubt seen, 1.0.1 was released yesterday. I'd just like to check to see if there's anything I can do to help with the Debian packaging. As you also no doubt understand, I'm a complete ignoramus when it comes to this sort of stuff so I'm definitely relying on those of you who are experts to guide me and/or tell me what to do as the upstream application maintainer. So, please don't hesitate to give me a kick if need be! Thank you for your continued help and support with Mu! N. |
|
I was taking a look at updating the Raspbian package and hit a hurdle:
Are you dropping support for Stretch? |
I wonder if it makes sense to move forward with packaging mu without including the microbit firmware, either excluding the microbit mode completely or telling the users they have to download the firmware themselves. I also wonder what the situation is with the adafruit mode? Does it have a similar blob that we need to deal with? |
Apologies for my absence. Reports of my demise have been thankfully under-reported... I am currently respinning the updated Mu (and related) packages to untangle uflash.py (which will be packaged separately, with the firmware untangled from uflash (to package it separately). I'm also pulling out any non-DFSG-compatible files. The vanilla respin of Mu should be posted to mentors by the weekend. I am also working on getting the remaining unpackaged yotta build system deps completed so that the firmware can be built.
I don't think so (but await confirmation). In adafruit mode files are placed on the device directly. (Also note there is no reported dependency for Mu on circuit python code). |
|
I've just pushed my packaging of mu-editor to the Debian Python Apps repository for review. Earlier this week I pushed my packaging of uflash, nudatus and guizero to the Debian Python Modules repository, which should give us a full stack of currently unpackaged dependencies. |
|
Any chance of getting mu in a PPA packaged for 18.10? |
|
My packaging of mu-editor has been reviewed and uploaded to the Debian NEW queue. |
|
Almost 3 years to the day after this ticket was originally opened, mu-editor was ACCEPTED into Debian unstable this evening. It will migrate to testing in due course. If you can, please try it out and report any issues running Mu on Debian to the usual place (reportbug, bugs.debian.org) |
|
Do you have a download link for the .deb file? I'm running Debian stable ("Stretch"), but often unstable packages can be installed via |
|
The public mirrors and the websites take a bit of time to update after a package is accepted by ftpmaster, it seems to have appeared there now |
|
mu-editor 1.0.2 is now available in Debian testing, and should be part of the forthcoming Debian 10 "Buster" release. As it has been accepted into Debian, it should therefore also be newly available in the forthcoming 19.04 "Disco Dingo" release of Ubuntu. The firmware-microbit-micropython package providing the MicroPython hex built from source is now in the Debian NEW queue, and should be available in Debian testing/unstable very soon. In the meantime, the firmware-microbit-micropython-dl package will download the current firmware.hex from the uflash github repository and allow full micro:bit testing from within mu-editor on Debian. |
That's great! 👍 Also if I can tidy up the snap release too, users on older Ubuntu releases will be able to install it, and when new Mu releases are available, it'll be possible to get the latest version regardless of what's in apt. Raspbian is usually able to keep up-to-date as we're less conservative with policy of leaf packages. |
firmware-microbit-micropython entered Debian unstable on 2019-01-20 and migrated to Debian testing on 2019-01-25. Please test it out if you're able to (or switch to it if you have the firmware-microbit-micropython-dl package installed). |
|
It's been a while, but we can close this ticket, thank you @knowledgejunkie and everybody else that has helped! |
We should package the "Mu" editor for Debian based systems. This will include Debian itself, Ubuntu and, of course, Raspbian.
The package should have three dependencies:
python3-pyqt5,python3-pyqt5.qsciandpython3-pyqt5.qtserialport.We should only package the appropriate parts of this repository. The process for packaging and installing from such a package should be documented in the README here:
https://github.com/ntoll/mu/tree/master/package
The text was updated successfully, but these errors were encountered: