Create a new .deb package so the editor is easy to install on Debian based systems.

[ntoll]

Create a new .deb package so the editor is easy to install on Debian based systems.

[skitt]

Nice, a Microbit-friendly editor... Tell you what, I’ll take care of PyQtChart; I’ll move the bug to the appropriate place (WNPP as @ntoll just found out on Twitter) and package it up. I can follow up on Mu itself too. (I’m a DD and I maintain a number of Python packages already.)

[knowledgejunkie]

My packaging of mu-editor has been reviewed and uploaded to the Debian NEW queue.

[russel]

Right, having removed Mu and all the dependencies pip3 put in place (which are exactly the ones I have installed via packaging, gggrrr…) I now have a complete build. I guess I should install with dpkg… duly installed and removed,so it is looking fine.

Sorry to have caused issues with this. But all good to go!

[knowledgejunkie]

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:

• package yotta (need to file an ITP, and which is reported to be discontinued upstream...)
• get the firmware building from pristine source in a chroot without network access using the packaged yotta
• split the microbit firmware out into its own package (firmware-microbit-micropython) as other applications/utilities may want it available
• package uflash, repackaging to remove all copies of the currently-included firmware (firmware.hex and uflash.py) and add a dependency on the new firmware package, ensuring it can find the installed default firmware file for seemless flashing.
• repackage mu-editor to remove the included convenience uflash/firmware and add a dependency on the new uflash package, again ensuring it finds the packge-installed uflash script and firmware file.

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...

[knowledgejunkie]

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)

[carlosperate]

It's been a while, but we can close this ticket, thank you @knowledgejunkie and everybody else that has helped!

[ntoll]

@bennuttall this is the ticket for .deb-ifying the editor.

[bennuttall]

Great - thanks

[ntoll]

I'm going to go through this process to get the package into Debian:

https://www.debian.org/devel/wnpp/

[asb]

See PR #102 for a start on this.

[carlosperate]

Unless we want to publish the deb package somewhere else, looks like we can close this issue :)

[ntoll]

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. :-)

[bennuttall]

This list points at this location where the deb can be found.

[bennuttall]

Also

sudo apt-get update
sudo apt-get install mu

[rotacoder]

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.

[carlosperate]

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.
I'm living this link here for future reference, as it might be a good way to solve this: https://github.com/spotify/dh-virtualenv

@asb have you seen or used dh-virtualenv before?

[jaustin]

@carlosperate is this actually fixed now? I notice there's a debian directory rules/control file etc?

[carlosperate]

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 , as that's the last documented release. For a newer release we should update the changelog.

[jaustin]

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> .

[gquintana]

To be able to install a mu .deb package on, at least Debian stable and Ubuntu LTS, some dependencies requirements should be downgraded:

python3-pyqt5       required:5.10 debian_stretch:5.7   ubuntu_xenial:5.5.1 ubuntu_bionic:5.10.1
python3-pyqt5.qsci  required:2.10 debian_stretch:2.9.3 ubuntu_xenial:2.9.1 ubuntu_bionic:2.10.2

This would also make installing mu with pip easier (no specific virtualenv required).

[ntoll]

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?

[gquintana]

@ntoll An "in between" solution could be to provide a .deb package and let users download it and install it using dpkg -i, at least until this package get published in Debian repos.

[bennuttall]

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!

[ntoll]

@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). ;-)

[bennuttall]

@XECDesign can you confirm it would be possible to add to our PPA once Mu is released?

[XECDesign]

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.

[ntoll]

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..?

[XECDesign]

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.

[ntoll]

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.

See: https://twitter.com/ntoll/status/1004000758352764929

[bennuttall]

@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.

[ntoll]

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. :-(

[XECDesign]

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.

[ZanderBrown]

DebConf is in Taiwan I believe so probably not convenient...

[ntoll]

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).

[gquintana]

@skitt can you give some advice?

[ukBaz]

No idea how up-to-date the following information is:
https://wiki.debian.org/LocalGroups#UK
https://blog.einval.com/

[ZanderBrown]

Me & IRC often end badly & I'm really not in the Debian world but let's see if that gets us anywhere

[ntoll]

Hi @skitt -- first of all, THANK YOU. Secondly, I'm more than prepared to move mountains, do boring stuff etc... assuming the caveat that I'm a technical savvy Debian ignoramus (when it comes to packaging), so if there's anything you need me to do, don't hesitate to ask. Third, I assume this will go something like sid -> test -> stable (when testing is switched to stable). Finally, Just having PyQtChart available is a win, let alone having Mu packaged. Once again, thank you.

[russel]

@skitt I was going to issue a ITP and actually try building the package prior to finding a mentor. I was looking for a suitable package to follow, preferably to create an 'all' package as I believe this package does not require any shared objects – but I may be wrong. If you have a Python package building Git repository for one of the other Python3 packages I'd be happy to chip in by trying to make a workable package for PyQtChart based on it.

[ntoll]

@russel there are already Debian related packaging things in the repos, but they're a bit of a black box and the version numbers of dependencies in setup.py are often > than what's currently in Debian (testing).

[skitt]

@russel oops, sorry, I didn’t mean to step on anybody’s toes. I’ve turned https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892198 into an ITP, if you want it you can take it, or we can work on it together (I’ve started on it but I’m still at the “listing build dependencies” stage). Given that this is a PyQt5 module, the best repository to start from is PyQt5’s in https://salsa.debian.org/python-team/modules/pyqt5. As @ntoll says you’ll need to work with the packages in unstable, the versions in Debian 9 are too old, and anyway packages always target unstable first.

[russel]

@ntoll The debian directory relates to packaging mu itself, a precursor is getting the package python3-pyqt5.qtchart (and python3-pyqt5.qtchart-dbg) created and in Debian Sid. Once that is in place changes will be needed to the mu dependecies in the debian directory files.

My question to @skitt was whether he had a python3-??? package building repository I could use as a paradigm to create one for python3.pyqt5.pychart.

[ntoll]

@russel aha... you're a ⭐ :-)

[russel]

@skitt Toes not being trodden on at all. The goal is to get the package in as soon as possible. I was just trying to help out after @ntoll 's Twitter request.

The last time I did any packaging was in 2004 when one of my startup staff was deeply into putting stuff into Debian and got us to switch from RH to Debian – damn good choice. He was the DD, I was the person doing what I was told. :-)

I'm a total beginner to modern Debian Packaging, so collaboration with and working to the requirements of a DD sounds excellent. If you want me to act as your gopher on this, that works for me.

(I use Debian Sid and Fedora Rawhide, anything else is far too outdated. I guess I should also have an Arch set up. :-)

[ntoll]

Just a FYI... lost in all the traffic. We aim to be releasing a 1.0 version of Mu very soon. It is that which will need to be the version ultimately packaged. I'm trying to front-load effort so "it just works" when the 1.0 balloon goes up, IYSWIM.

[darrell24015]

When it gets to the point of testing, I’ll be happy to try out Debian, Ubuntu and Raspbian installs.

[russel]

@skitt If you have a URL for the repository you have for "python3-pyqt5-qtchart" package I'll clone it and see if I can get some positive contributions in place.

[plugwash]

I am a Debian Developer.

I looked at packaging mu a while back, the two main missing dependencies for a reasonably useful mu package seemed to be the pythong qtchart stuff and pygame zero.

I started looking at the pygame zero stuff but ran into a bunch of files of questionable provenance among documentation and examples. I raised this with the author of pygame zero, first by private email and then was later asked to take it to a github issue which I did . Unfortunately things then went quiet. I have now decided to try and package pygame zero without the offending files.

[plugwash]

The github issue for copyright/licensing issues in the documentation/examples for pygame zero is at lordmauve/pgzero#75

[skitt]

I’ve pushed the packaging to https://salsa.debian.org/skitt/pyqt5chart; it works for me, there’s just an issue with one of the debug files I need to check.

[russel]

@skitt I have forked and cloned. In my usual be as literal and irritating as possible mode:

|> python3 configure.py
/bin/sh: 1: ./sip: Permission denied
Error: './sip -V' did not generate any output.

|> which sip
/usr/bin/sip

Is this just a question of removing the ./ so as to get PATH lookup? I'll progress this and look to provide a pull request.

[skitt]

You need to build it as a Debian package, ideally using git-buildpackage:

sudo apt install git-buildpackage pristine-tar build-essential
gbp clone https://salsa.debian.org/skitt/pyqt5chart
cd pyqt5chart
gbp buildpackage -us -uc

This will clone the repository and set everything up so that the archives can also be found for the build. The last step will probably complain about missing dependencies; you’ll need to install those and re-run the build-package step.

[russel]

I'll try that after lunch, gbp installed trivially. The implication here is that the README is not actually giving the right instructions for installation.

[skitt]

Right, and that probably seems weird if you don’t work with Debian source packages all the time ;-). The idea is that Debian source packages contain all the upstream source, including README etc., and all the packaging files go in debian. We don’t adjust upstream instruction to match Debian build instructions (which are always the same in the end: retrieve the source package, and run dpkg-buildpackage; gbp is a convenient wrapper for git-hosted repositories).

[russel]

I did say it was a long time since I had done this stuff. :-)

|> gbp clone https://salsa.debian.org/skitt/pyqt5chart
gbp:info: Cloning from 'https://salsa.debian.org/skitt/pyqt5chart'
|> cd pyqt5chart/
|> gbp build-package -uc -us
'build-package' is not a valid command.

Usage:
    gbp <command> [<args>]

The most commonly used commands are:

    buildpackage - build a Debian package
    import-orig  - import a new upstream tarball
    import-dsc   - import a single Debian source package
    import-dscs  - import multiple Debian source packages

Use '--list-cmds' to list all available commands.

|> gbp buildpackage -uc -us
gbp:info: Creating /home/users/russel/BuildArea/pyqt5chart_5.10.1+dfsg.orig.tar.gz
gbp:error: Error creating pyqt5chart_5.10.1+dfsg.orig.tar.gz: Pristine-tar couldn't checkout "pyqt5chart_5.10.1+dfsg.orig.tar.gz": execution failed: [Errno 2] No such file or directory: 'pristine-tar': 'pristine-tar'

[skitt]

Oops, sorry about that, I’ve fixed it above. You also need to install pristine-tar...

[russel]

OK, done, I am moving :-) There were various python3.*dbg packages I didn't have installed, I installed them and the process got going. However:

cd dbg-build-3.6 && python3.6-dbg ../configure.py --verbose -q /usr/bin/qmake -c -j 10 \
		-d /usr/lib/python3.6/dist-packages \
		--sip-incdir /usr/include/python3.6dm \
		--debug --no-sip-files
Error: Unable to import PyQt5.QtCore. Make sure PyQt5 is installed.

and yet:

|> python3
Python 3.6.5 (default, May 11 2018, 13:30:17) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore
>>> 

[skitt]

Believe it or not, I did build the package in CI before pushing it, so it should be buildable ;-). Your build is failing because python3.6-dbg, the debug-symbol-equipped Python interpreter, can’t find PyQt5.QtCore, which is provided by python3-pyqt5-dbg. To verify locally, you need to run your import test in python3.6-dbg, not plain python3.

[ntoll]

@russel @skitt you folks are awesome. Thank you for the effort you're putting into this. :-)

[russel]

Ah of course python3.6-dbg is a completely different installation silo to python3.6, rather than just being the debug symbols for it. It seems though that python3-pyqt5-dbg package installs into the python3 silo not the python3.6-dbg one.

[skitt]

They both install in python3... Doesn’t it work for you after installing the -dbg package?

[russel]

It seems not:

|> aptitude search ~i | grep pyqt5
i  pyqt5-dev - Development files for PyQt5
i A python3-dbus.mainloop.pyqt5 - D-Bus Qt main loop support for Python 3
i A python3-pyqt5 - Python 3 bindings for Qt5
i  python3-pyqt5-dbg - Python 3 bindings for Qt5 (debug extensions)
i  python3-pyqt5.qtquick - Python 3 bindings for QtQuick module

|> python3
Python 3.6.5+ (default, Jun  8 2018, 21:55:12) 
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore
>>> 

|> python3.6-dbg
Python 3.6.5+ (default, Jun  8 2018, 21:55:12) 
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt5.QtCore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /home/users/russel/.local/lib/python3.6/site-packages/PyQt5/QtCore.so: undefined symbol: PyModule_Create2
>>> 

[skitt]

ImportError: /home/users/russel/.local/lib/python3.6/site-packages/PyQt5/QtCore.so: undefined symbol: PyModule_Create2

means there’s a mixture of local (pip-managed?) modules and system modules; for this build Python should only be using system modules.

[russel]

OK, that is because I installed Mu via "pip3 install --user". Whilst I never pip into the package managed area I keep forgetting it precedes the system stuff. It would have helped if I had actually read that line wouldn't it. :-)

[skitt]

I’ve just uploaded the PyQtChart package to Debian NEW. An ITP has been filed for mu itself, see https://bugs.debian.org/901461

[ntoll]

Folks (especially @russel and @skitt),

Apologies for my absence from contributing to this issue: I've been working hard this past two weeks on getting beta.16 out (which happened yesterday).

First of all, it's wonderful to see all this progress being made. Thank you very much for your hard work. If there's anything I can do to help (as a technical but Debian naive developer) please don't hesitate to give me a kick via this ticket. I'd move mountains to get this working.

Secondly, just so you're aware of Mu's time-lines, here's what I expect to happen next:

• Beta.17 out in just under a fortnight (this will contain final added/updated minor changes and features).
• Release candidate the week after.
• Assuming no show stoppers in the RC. 1.0.final will be out soon after that.

Obviously, it's Mu 1.0.final that we want to get into Debian. ;-) Please shout very loudly if you see any problems with the above. To be honest, apart from a few minor changes and updates, beta.16 is very close to how 1.0 will work and there won't be any further dependencies added to Mu in the meantime.

Finally, getting Mu this far has been a team effort. As a token of my thanks to the wider community I've had some limited-edition Mu t-shirts printed for those who have contributed time/code/help/effort to the project. I think you both (@russel and @skitt) should be the recipients of a t-shirt. ;-) You'll need to let me know how to get them to you once 1.0 is out the door. :-D

As always, feedback is most welcome.

[plugwash]

I just uploaded pygame zero to Debian, lets hope it clears the new queue successfully.

[carlosperate]

From the debian ticket looks like we've got a list of actions we should resolve in order to be able to successfully submit the deb package:

1. The current packaging uses 3.0 (native), that is probably fine for snapshot builds distributed by yourselves but for actual packaging for Debian we probably want to use 3.0 (quilt) with the packaging for Debian being based on an upstream stable release tarball (apparently serge's packaging at https://github.com/XECDesign/mu uses 3.0 quilt).

@XECDesign if this is the case, could you submit a PR to this repo with this change?

2. The build-depends in the Debian packaging look grossly incomplete compared to the dependencies in setup.py

I've also wondered about this. The dependencies listed in the control file from the b15 in http://archive.raspberrypi.org/debian/pool/main/m/mu/ contains more than what it is listed in this repo:

Depends: python3-matplotlib, python3-pycodestyle, python3-pyflakes, python3-pyqt5, python3-pyqt5.qsci, python3-qtconsole, python3-serial, python3:any (>= 3.3.2-2~), python3-pyqt5.qtserialport

@XECDesign is this list automatically generated? Is there something we need to do in this repo to make sure the list is complete?

3. The install_requires in setup.py seems to specify exact versions? are those exact versions really nessacery? remember debian only has one version of a python library at a time.

4. Some of the versions specified in your setup.py are lower than the versions currently in sid. Sid currently has pyqt5 5.9.2 and matplotlib 2.1.1

@ntoll I've usually seen this the opposite way than what we have in this repo.
In the projects I've looked at before the setup.py file used to have minimum versions, and then the requirements.txt file would have exact versions. But in those cases it was because setup.py was used to pip install, and the requirements.txt was to replicate a production-like environment.
To be completely honest I've read so many different articles about Python packaging, I don't really know whats right from wrong.

Should the versions in the setup.py be changed to be only the minimums (but still within semver major revisions)?

5. setup.py depends on pygame zero which doesn't currently appear to be in Debian (I have been working on this but much of the documentation/examples have unclear licensing or even suspected violations which is making it a slow and depressing process).

This might change soon based on @plugwash's latest comment (thanks!).

6. setup.py depends on PyQtChart which doesn't currently appear to be in Debian (now uploaded to new by Stephen Kitt)

This will change soon as well, thanks @skitt!

7. What to call the package? I can see a two-letter package name meeting some resistance as being prone to conflicts, maybe mu-editor?

In this case we should call the package mu-editor, as that's the PyPI name.

@ntoll I think we might need to unify the name of the Mu application. Are we calling the app "Mu"/"mu" or "mu-editor"? The new macOS installer has named the app 'mu-editor' and perhaps should be renamed based on this decision.

8. The package description could do with some improvements. Right now it really doesn't tell me anything about what mu can do (beyond just editing files but we have a pile of tools for that).

I think the short description is probably fine, but it is true that if somebody just encountered this in a package manager they might not really know what makes Mu stand out.

9. debian/copyright only mentions a single copyright holder, whereas even a quick look at the code points to an Authors file that mentions other authors. Also poking through the docs folder reveals a number of images that don't look original to this project. We need to know where they came from and what license terms they are under.

I think pygame zero had to go through the same with their images.
@ntolls is there an easy to find place that gives attribution to the files from https://github.com/mu-editor/mu/tree/master/mu/resources/pygamezero ?

10. use of /usr/bin/env python3 is discouraged, debian prefers use of an explicit path.

Not sure what the debian explicit path might be in this case, maybe @ntoll knows as well?

[ntoll]

Taking each item in turn:

1. I guess we're waiting on @XECDesign do push something.
2. What @carlosperate says.
3. The exact versions are just a habit of mine from deploying web-based applications to (private) production. We can and should be flexible on this. What I'd need to know to make changes is what the version numbers should be for each dependency given the current state of Debian testing.
   4.I hear ya about so many ways to skin a cat @carlosperate. I like your suggestion... the versions in setup.py should be minimums.
4. Great to see PG0 getting into Debian. Great stuff @lordmauve.
5. Kudos to @skitt for tackling this. Thank you! :-)
6. This is probably my lack of communication. From the command line, from now on, it'll always be: mu-editor. It turns out "mu" has recently become a popular name for "small" projects that do X. Having the -editor suffix ensures we don't clash with others.
7. Are you referring to the short description in setup.py..? If so, I can easily update this to be more interesting.
8. Everything about copyright status and Mu should be covered here: https://mu.readthedocs.io/en/latest/copyright.html
9. No idea what to use for Debian. What's "best practice" supposed to be..?

[skitt]

I think it’s worth pointing out that it’s not absolutely necessary to get the Debian packaging perfectly right in Mu’s repository: Debian packages have their own packaging which is applied on top of whatever sources are part of a release. So while it’s nice to have Debian-style packaging as part of Mu, for users who want to build a Debian package themselves, it’s not a requirement for the package which will end up in Debian and derivatives.

If you want to make life easy for Debian packagers, I would suggest not focusing on the Debian packaging itself, but rather on the rest of the guidelines for upstreams (which I get the impression you’re doing a good job of already — kudos for example on the document describing the copyright status, that’s usually what takes the most time when preparing a new package for Debian).

[ntoll]

@skitt I didn't even know the guidlines for upstreams existed..! I'll go through them tomorrow and ensure Mu is as compliant, easy, helpful as possible.

I like the "What happens in Debian, stays in Debian" philosophy... keeps things nicely clean and separated. :-)

[knowledgejunkie]

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?

[ZanderBrown]

I see we are in Raspbians new "Recommended Software", nice.

(It's beta 15)

[skitt]

@knowledgejunkie re (i), dropping the debian directory from release tarballs is fine from a Debian perspective. It can however be nice to include it for people who want to build the package themselves while they wait for the next release of whichever distribution they’re using...

Re (ii), that’s a tough question. Ideally, debian/control in particular should only reflect the basic requirements of the package (in whatever configuration the maintainer decides is appropriate, hopefully in agreement with upstream). So wherever the package ends up being built, if the requirements can be satisfied then everything will go smoothly. However the target distributions are quite different: for maximum usability, an upstream-provided debian directory should be designed for people who want to build on the current release of whichever distribution is being targeted (or even popular older releases, e.g. Ubuntu LTS), whereas the Debian debian directory will be designed for the next Debian release (as currently prototyped in unstable). This means that there’s no hard-and-fast rule for syncing the two.

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.

[ZanderBrown]

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)

[plugwash]

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.

[ntoll]

@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..?

[ntoll]

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 semver Python module in the beta.17 release of Mu. Happily, this appears to already be packaged in Debian. This is just an FYI.

[knowledgejunkie]

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
[2] https://salsa.debian.org/nickm-guest/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:

• to meet Debian Policy, the bundled (but currently unavailable in Debian) Abode Source Code Pro fonts have been removed and replaced by Inconsolata.
• to handle the missing gpiozero, guizero and pigpio dependencies on i386/amd64, PI_APIS is not imported.
• the udev rules, appdata, desktop file (patched for mu->mu-editor change) and icon are installed.
• a basic manpage is included
• developer documentation is generated in a separate package mu-editor-doc
• clarification is needed on the DFSG-compatibility of the included micro:bit firmware in uflash.py

[russel]

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.

[knowledgejunkie]

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?

[russel]

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.

[knowledgejunkie]

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.

[hackerb9]

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.

[ntoll]

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.

[XECDesign]

I was taking a look at updating the Raspbian package and hit a hurdle:

Mu only works with Python version 3.6 or above.

Are you dropping support for Stretch?

[plugwash]

In terms of finishing the Debian packaging for mu, the next steps seem to be:

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?

[knowledgejunkie]

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.

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 also wonder what the situation is with the adafruit mode? Does it have a similar blob that we need to deal with?

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).

[knowledgejunkie]

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.

[CarlFK]

Any chance of getting mu in a PPA packaged for 18.10?
there was mention above of here:
https://launchpad.net/~rpi-distro/+archive/ubuntu/ppa
but that seems to have never happened.

[hackerb9]

Do you have a download link for the .deb file? I'm running Debian stable ("Stretch"), but often unstable packages can be installed via dpkg -i if there aren't too many dependencies. I tried going to the standard location, but got nothing: https://packages.debian.org/unstable/editors/mu-editor

[plugwash]

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

[knowledgejunkie]

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.

[bennuttall]

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.

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.

[knowledgejunkie]

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.

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).