Re: RFS: mu-editor and yotta dependencies
On Sat, 29 Dec 2018 at 20:20, Nick Morrott wrote: > > On Fri, 28 Dec 2018 at 07:58, Nick Morrott wrote: > > > > On Thu, 20 Dec 2018 at 01:29, Nick Morrott > > wrote: > > > > > > yotta > > > = > > > > > > I am also preparing packaging for yotta, the ARM mbed build system > > > used for the micro:bit's MicroPython runtime (used by python-uflash > > > and thus indirectly by the mu editor for flashing the micro:bit). > > > > > > The current list of yotta dependencies uploaded to salsa is: > > > > > > https://salsa.debian.org/python-team/modules/python-hgapi > > > https://salsa.debian.org/python-team/modules/python-project-generator-definitions > > > https://salsa.debian.org/python-team/modules/python-project-generator > > > > yotta > > = > > > > New yotta dependencies uploaded for review/sponsored upload: > > > > https://salsa.debian.org/python-team/modules/python-mbed-ls > > https://salsa.debian.org/python-team/modules/python-mbed-host-tests > > https://salsa.debian.org/python-team/applications/mbed-test-wrapper > > https://salsa.debian.org/python-team/applications/valinor > > I have now pushed yotta itself for review/sponsorship: > > https://salsa.debian.org/python-team/applications/yotta I have now pushed the final piece of the puzzle, firmware-microbit-micropython, to salsa for review/sponsorship: https://salsa.debian.org/python-team/applications/firmware-microbit-micropython I've tested the generated MicroPython firmware locally with my micro:bit and the new mu-editor and python3-uflash packages, using the examples provided in this package, and it worked. \o/ Cheers, Nick
Re: RFS: mu-editor and yotta dependencies
Le dimanche 30 décembre 2018 à 23:15:10+, Nick Morrott a écrit : > On Sun, 30 Dec 2018 at 18:42, Pierre-Elliott Bécue wrote: > > > > Re, > > > > Actually, nudatus is a dependency of uflash. > > See below for my reasoning for adding python3-nudatus as a Recommends > for python-uflash, rather than a hard Depends. > > > ## python-nudatus > > > > Uploaded. > > Awesome > > > ## python-uflash > > > > Uploaded, though installing it will be hard, as > > firmware-microbit-micropython is missing and apt tries to fetch the > > recommends too. > > nudatus is really an optional dependency of uflash, as minification is > not essential. The uflash code checks to see if nudatus is available > at runtime, and will disable minify if it is not available. It's a build-dep of uflash (or at least you declared it that way), I was mentionning the dependency in that way: I needed to build nudatus first. > > ## python-guizero > > > > Uploaded. > > Awesome > > > ## mu-editor > > > > Hmmm. > > > > In the dependencies of the project are mentionned and imported: > > > > gpiozero > > Please see the request to provide the gpiozero package on non-armhf > architectures at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856413 > > > pigpio > > Please see the RFP discussion for packaging pigpio at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908787 Saw both. I was more interested in "are they mandatory for mu to work". It seems that the answer is nope. :) > > pynsist > > pynsist is a tool to build Windows installers Ack. > > + some deps useful for testing. > > i) pytest-cov measures test coverage, and I am not sure if that's a > useful statistic for packing? Nah, that's why I wrote "+ some deps useful for testing". :) > ii) pytest-random-order would be useful, especially for reproducibility. Ack, I'll look into it when you're done (saw your ITP). > *However*, since upstream Mu added the dependency back in 2018/03, > upstream pytest-random-order 1.0.0+ disabled its "random by default" > behaviour (2018/10). As such, the mu-editor tests are not currently > randomised. This is a testing regression and I will report it, so that > the forthcoming 1.0.2 release of Mu contains it. > > pytest-random-order is not actually packaged yet for Debian, so I could ITP > it. > > > I don't see any of those three packages in debian right now. Is there a > > reason you consider we don't need these? > > I have added notes about gpiozero/pigpio to d/control. pynsist does > not seem necessary. So they don't seem mandatory to you to have a working release of mu-editor? I've uploaded the package. Thanks for your thoroughness, and your contribution to Debian! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: RFS: mu-editor and yotta dependencies
On Sun, 30 Dec 2018 at 18:42, Pierre-Elliott Bécue wrote: > > Re, > > Actually, nudatus is a dependency of uflash. See below for my reasoning for adding python3-nudatus as a Recommends for python-uflash, rather than a hard Depends. > ## python-nudatus > > Uploaded. Awesome > ## python-uflash > > Uploaded, though installing it will be hard, as > firmware-microbit-micropython is missing and apt tries to fetch the > recommends too. nudatus is really an optional dependency of uflash, as minification is not essential. The uflash code checks to see if nudatus is available at runtime, and will disable minify if it is not available. > ## python-guizero > > Uploaded. Awesome > ## mu-editor > > Hmmm. > > In the dependencies of the project are mentionned and imported: > > gpiozero Please see the request to provide the gpiozero package on non-armhf architectures at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856413 > pigpio Please see the RFP discussion for packaging pigpio at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908787 > pynsist pynsist is a tool to build Windows installers > + some deps useful for testing. i) pytest-cov measures test coverage, and I am not sure if that's a useful statistic for packing? ii) pytest-random-order would be useful, especially for reproducibility. *However*, since upstream Mu added the dependency back in 2018/03, upstream pytest-random-order 1.0.0+ disabled its "random by default" behaviour (2018/10). As such, the mu-editor tests are not currently randomised. This is a testing regression and I will report it, so that the forthcoming 1.0.2 release of Mu contains it. pytest-random-order is not actually packaged yet for Debian, so I could ITP it. > I don't see any of those three packages in debian right now. Is there a > reason you consider we don't need these? I have added notes about gpiozero/pigpio to d/control. pynsist does not seem necessary. Are there any others I have missed? Thanks, Nick
Re: RFS: mu-editor and yotta dependencies
Re, Actually, nudatus is a dependency of uflash. ## python-nudatus Uploaded. ## python-uflash Uploaded, though installing it will be hard, as firmware-microbit-micropython is missing and apt tries to fetch the recommends too. ## python-guizero Uploaded. ## mu-editor Hmmm. In the dependencies of the project are mentionned and imported: gpiozero pigpio pynsist + some deps useful for testing. I don't see any of those three packages in debian right now. Is there a reason you consider we don't need these? -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: RFS: mu-editor and yotta dependencies
Le dimanche 30 décembre 2018 à 05:14:34+, Nick Morrott a écrit :
> On Sun, 30 Dec 2018 at 02:12, Pierre-Elliott Bécue wrote:
> >
> > Le dimanche 30 décembre 2018 à 02:01:28+0100, Pierre-Elliott Bécue a écrit :
> > > [snip]
> >
> > ## python-project-generator-definitions: uploaded
> >
> > 1) I uploaded a bit fast. It's not a big issue but could you consider
> > removing the explicit python3 dependencies from the binary package's
> > Depends field? Normally debhelper finds the appropriate list from
> > python3:depends meta-dependency, using install_requires field of
> > setup.py.
>
> Updated
>
> > ## python-project-generator:
> >
> > 1) I wonder why you removed the alternative entry point.
>
> I dropped it to be consistent with
> python3-project-generator-definitions which only provides a single
> entrypoint in the same "namespace". I also thought the longer
> entrypoint name was somewhat cumbersome.
>
> > 2) Please remove all specific entries for the binary package Depends,
> > except python3-project-generator-definitions (<< 0.3.0):
> > python3:depends drags the others properly.
>
> Updated
Uploaded, thanks!
> > ## valinor:
> >
> > 1) You should ask upstream to provide a changelog, even though your
> > changelog.upstream.md is a perfectly fine temporary solution.
>
> https://github.com/ARMmbed/valinor/issues/29
>
> > 2) Same about the Depends field of this package, keep gdb of course, as
> > no :depends entry will drag it.
>
> Updated
>
> > 3) d/watch: could you use version=4 here or is there an issue?
>
> Bumped to version 4 (I had cribbed from another d/watch file using pypi)
>
> > 4) Is there a good reason for your export PYBUILD_AFTER_INSTALL=mv
> > {destdir}/usr/bin/valinor {destdir}/usr/share/valinor/run in d/rules
> > plus the link for /usr/bin?
>
> The package build attempts to install the script "valinor" into
> /usr/share/valinor/valinor/, which it can't because of the naming
> conflict. This occurs in a few of the other packages too I think.
Ack, I'm surprised by the mentioned behaviour but in any case, this choice
you made isn't irrelevant so let's stick to it for now.
If you find some time to investigate what causes such behaviour, please give
me some feedback!
> > ## python-mbed-ls:
> >
> > 1) Same as the others regarding the Depends field of the binary package.
>
> Updated
>
> > 2) For the Doxygen patch, you removed the genlatex, I guess it's because
> > you don't want to drag texlive for the building part? I'm fine with
> > this.
>
> Yes
I made a small mistake, you had to keep python3-pkg-resources and
python3-colorlog here, but I forgot to mention them. I made a fixing commit.
Uploaded.
> > ## python-mbed-host-tests:
> >
> > 1) Same as the others regarding the Depends field, prospectively keeping
> > the versioned dependencies
>
> Updated
I restored python3-pkg-resources as a dependency. I missed that one.
Uploaded.
> > ## mbed-test-wrapper:
> >
> > 1) Still the same Depends question. :) keep binutils-arm-none-eabi, of
> > course.
>
> In this instance, the source setup.py file does not declare anything
> in install_requires and so the dependencies must be added manually.
>
> I've asked upstream to consider adding explicit dependencies for
> mbed-ls and mbed-host-tests:
>
> https://github.com/autopulated/mbed-test-wrapper/issues/3
Ack, my bad, I must've been a little tired, I missed the setup.py emptyness.
Uploaded.
> > ## python-hgapi
> >
> > 1) You should suggest your patches to upstream.
>
> The patches were take from upstream's repository and links to the PRs
> are in the patch headers.
Ah, good to know!
> > ## yotta
> >
> > 1) Same old Depends field. You must keep valinor and mbed-test-wrapper at
> > least for now (I think that they'll be matched by the dh magic when
> > they'll be in the archive).
>
> Updated
>
> > 2) I wonder why you added python3-openssl and python3-idna to the
> > dependencies, they seem not needed according to setup.py? If you need
> > them, please add them manualy to the Depends field as they won't be
> > dragged by the python3:depends variable. In that case maybe it would be
> > worth do att a README.source in the debian/ directory explaining why
> > these packages are needed. If upstream forgot to add these dependencies,
> > please notify them with a bug report.
>
> I *think* I originally added them because they are suggested deps of
> requests. I can't see anything in the source that suggests they are
> needed, so I will drop them.
Ack, and uploaded, too.
> > Summary:
> >
> > > > -> yotta: x
> > > > -> python-hgapi: ./
> > > > -> mbed-test-wrapper: x
> > > > -> python-mbed-host-tests: x
> > > > -> python-mbed-ls: x
> > > > -> valinor: x
> > > > -> python-project-generator: x
> > > > -> python-project-generator-definitions: ./ (!)
> >
> > The other packages will have to
Re: RFS: mu-editor and yotta dependencies
On Sun, 30 Dec 2018 at 02:12, Pierre-Elliott Bécue wrote:
>
> Le dimanche 30 décembre 2018 à 02:01:28+0100, Pierre-Elliott Bécue a écrit :
> > [snip]
>
> ## python-project-generator-definitions: uploaded
>
> 1) I uploaded a bit fast. It's not a big issue but could you consider
> removing the explicit python3 dependencies from the binary package's
> Depends field? Normally debhelper finds the appropriate list from
> python3:depends meta-dependency, using install_requires field of
> setup.py.
Updated
> ## python-project-generator:
>
> 1) I wonder why you removed the alternative entry point.
I dropped it to be consistent with
python3-project-generator-definitions which only provides a single
entrypoint in the same "namespace". I also thought the longer
entrypoint name was somewhat cumbersome.
> 2) Please remove all specific entries for the binary package Depends,
> except python3-project-generator-definitions (<< 0.3.0):
> python3:depends drags the others properly.
Updated
> I'll upload as soon as this is done, as the package builds properly and
> raises no lintian issue.
>
> ## valinor:
>
> 1) You should ask upstream to provide a changelog, even though your
> changelog.upstream.md is a perfectly fine temporary solution.
https://github.com/ARMmbed/valinor/issues/29
> 2) Same about the Depends field of this package, keep gdb of course, as
> no :depends entry will drag it.
Updated
> 3) d/watch: could you use version=4 here or is there an issue?
Bumped to version 4 (I had cribbed from another d/watch file using pypi)
> 4) Is there a good reason for your export PYBUILD_AFTER_INSTALL=mv
> {destdir}/usr/bin/valinor {destdir}/usr/share/valinor/run in d/rules
> plus the link for /usr/bin?
The package build attempts to install the script "valinor" into
/usr/share/valinor/valinor/, which it can't because of the naming
conflict. This occurs in a few of the other packages too I think.
> Same as -project-generator, I'll upload as soon as you've answered these
> questions. It builds perfectly otherwise.
>
> ## python-mbed-ls:
>
> 1) Same as the others regarding the Depends field of the binary package.
Updated
> 2) For the Doxygen patch, you removed the genlatex, I guess it's because
> you don't want to drag texlive for the building part? I'm fine with
> this.
Yes
> I'll upload as soon as you've answered these questions.
>
> ## python-mbed-host-tests:
>
> 1) Same as the others regarding the Depends field, prospectively keeping
> the versioned dependencies
Updated
> I'll upload as soon as you've answered these questions.
>
> ## mbed-test-wrapper:
>
> 1) Still the same Depends question. :) keep binutils-arm-none-eabi, of
> course.
In this instance, the source setup.py file does not declare anything
in install_requires and so the dependencies must be added manually.
I've asked upstream to consider adding explicit dependencies for
mbed-ls and mbed-host-tests:
https://github.com/autopulated/mbed-test-wrapper/issues/3
> I'll upload as soon as you've answered these questions.
>
> ## python-hgapi
>
> 1) You should suggest your patches to upstream.
The patches were take from upstream's repository and links to the PRs
are in the patch headers.
> Uploaded.
>
> ## yotta
>
> 1) Same old Depends field. You must keep valinor and mbed-test-wrapper at
> least for now (I think that they'll be matched by the dh magic when
> they'll be in the archive).
Updated
> 2) I wonder why you added python3-openssl and python3-idna to the
> dependencies, they seem not needed according to setup.py? If you need
> them, please add them manualy to the Depends field as they won't be
> dragged by the python3:depends variable. In that case maybe it would be
> worth do att a README.source in the debian/ directory explaining why
> these packages are needed. If upstream forgot to add these dependencies,
> please notify them with a bug report.
I *think* I originally added them because they are suggested deps of
requests. I can't see anything in the source that suggests they are
needed, so I will drop them.
> Summary:
>
> > > -> yotta: x
> > > -> python-hgapi: ./
> > > -> mbed-test-wrapper: x
> > > -> python-mbed-host-tests: x
> > > -> python-mbed-ls: x
> > > -> valinor: x
> > > -> python-project-generator: x
> > > -> python-project-generator-definitions: ./ (!)
>
> The other packages will have to wait, I'd rather finish this batch first.
That's awesome. Thank you for the review.
I've pushed changes to salsa, (hopefully) addressing all of the above
issues. Please let me know if I've missed any or if any follow up is
required.
> As my remarks are more like nitpicking, I'd like to insist on the quality of
> your work. Those packages are really neat.
>
> Thanks for your great work!
Thanks for your kind words,
Nick
Re: RFS: mu-editor and yotta dependencies
On Sun, 30 Dec 2018 at 01:02, Pierre-Elliott Bécue wrote: > > Le samedi 29 décembre 2018 à 20:33:37+, Nick Morrott a écrit : > > -> yotta > > -> python-hgapi > > -> mbed-test-wrapper > > -> python-mbed-host-tests > > -> python-mbed-ls > > -> valinor > > -> python-project-generator > > -> python-project-generator-definitions > > Hi Nick! > > Thanks for your work! Thank you for your detailed review of my prospective packages, which I'll start working through. > P.S.: I see you are uploader of many packages. Did you consider applying to > become DM/DD? (this question may be totally stupid, maybe you answered > somewhere, but I'm not really into stalking, so I'd rather get the answer > from you) My intention is to apply for DD once we have mu-editor and MicroPython for the micro:bit available in Debian. My key is in good shape after a few Debian UK BBQs, and joining debian-python to get Mu into the archive is providing exposure to new packaging/building steps that I've not encountered so far on my Debian adventure. Thanks again, Nick
Re: RFS: mu-editor and yotta dependencies
Le dimanche 30 décembre 2018 à 02:01:28+0100, Pierre-Elliott Bécue a écrit :
> [snip]
## python-project-generator-definitions: uploaded
1) I uploaded a bit fast. It's not a big issue but could you consider
removing the explicit python3 dependencies from the binary package's
Depends field? Normally debhelper finds the appropriate list from
python3:depends meta-dependency, using install_requires field of
setup.py.
## python-project-generator:
1) I wonder why you removed the alternative entry point.
2) Please remove all specific entries for the binary package Depends,
except python3-project-generator-definitions (<< 0.3.0):
python3:depends drags the others properly.
I'll upload as soon as this is done, as the package builds properly and
raises no lintian issue.
## valinor:
1) You should ask upstream to provide a changelog, even though your
changelog.upstream.md is a perfectly fine temporary solution.
2) Same about the Depends field of this package, keep gdb of course, as
no :depends entry will drag it.
3) d/watch: could you use version=4 here or is there an issue?
4) Is there a good reason for your export PYBUILD_AFTER_INSTALL=mv
{destdir}/usr/bin/valinor {destdir}/usr/share/valinor/run in d/rules
plus the link for /usr/bin?
Same as -project-generator, I'll upload as soon as you've answered these
questions. It builds perfectly otherwise.
## python-mbed-ls:
1) Same as the others regarding the Depends field of the binary package.
2) For the Doxygen patch, you removed the genlatex, I guess it's because
you don't want to drag texlive for the building part? I'm fine with
this.
I'll upload as soon as you've answered these questions.
## python-mbed-host-tests:
1) Same as the others regarding the Depends field, prospectively keeping
the versioned dependencies
I'll upload as soon as you've answered these questions.
## mbed-test-wrapper:
1) Still the same Depends question. :) keep binutils-arm-none-eabi, of
course.
I'll upload as soon as you've answered these questions.
## python-hgapi
1) You should suggest your patches to upstream.
Uploaded.
## yotta
1) Same old Depends field. You must keep valinor and mbed-test-wrapper at
least for now (I think that they'll be matched by the dh magic when
they'll be in the archive).
2) I wonder why you added python3-openssl and python3-idna to the
dependencies, they seem not needed according to setup.py? If you need
them, please add them manualy to the Depends field as they won't be
dragged by the python3:depends variable. In that case maybe it would be
worth do att a README.source in the debian/ directory explaining why
these packages are needed. If upstream forgot to add these dependencies,
please notify them with a bug report.
Summary:
> > -> yotta: x
> > -> python-hgapi: ./
> > -> mbed-test-wrapper: x
> > -> python-mbed-host-tests: x
> > -> python-mbed-ls: x
> > -> valinor: x
> > -> python-project-generator: x
> > -> python-project-generator-definitions: ./ (!)
The other packages will have to wait, I'd rather finish this batch first.
As my remarks are more like nitpicking, I'd like to insist on the quality of
your work. Those packages are really neat.
Thanks for your great work!
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
Re: RFS: mu-editor and yotta dependencies
Le samedi 29 décembre 2018 à 20:33:37+, Nick Morrott a écrit : > -> yotta > -> python-hgapi > -> mbed-test-wrapper > -> python-mbed-host-tests > -> python-mbed-ls > -> valinor > -> python-project-generator > -> python-project-generator-definitions Hi Nick! Thanks for your work! I'll start with these. Mail to follow soon. P.S.: I see you are uploader of many packages. Did you consider applying to become DM/DD? (this question may be totally stupid, maybe you answered somewhere, but I'm not really into stalking, so I'd rather get the answer from you) -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Re: RFS: mu-editor and yotta dependencies
On Thu, 20 Dec 2018 at 01:29, Nick Morrott wrote: > > I've started pushing dependencies for the mu editor [1] and yotta [2] > to salsa, and would appreciate reviews/feedback on the packaging work > and sponsorship of my uploads when we're happy. > > [1] https://bugs.debian.org/901461 > [2] https://bugs.debian.org/908781 As 12 of the 13 packages are now available on salsa (only firmware-microbit-micropython to go, see thread for details) I thought I'd post the dependency chains that they make (to know which new package depends on which other new package(s) and which are best to review/upload first): mu-editor = mu-editor -> python-nudatus -> python-guizero -> python-uflash -> firmware-microbit-micropython-dl* (suggested, included in python-uflash) or -> firmware-microbit-micropython (recommended, built from source) firmware-microbit-micropython = firmware-microbit-micropython -> yotta -> python-hgapi -> mbed-test-wrapper -> python-mbed-host-tests -> python-mbed-ls -> valinor -> python-project-generator -> python-project-generator-definitions Thanks, Nick
Re: RFS: mu-editor and yotta dependencies
On Fri, 28 Dec 2018 at 07:58, Nick Morrott wrote: > > On Thu, 20 Dec 2018 at 01:29, Nick Morrott wrote: > > > > yotta > > = > > > > I am also preparing packaging for yotta, the ARM mbed build system > > used for the micro:bit's MicroPython runtime (used by python-uflash > > and thus indirectly by the mu editor for flashing the micro:bit). > > > > The current list of yotta dependencies uploaded to salsa is: > > > > https://salsa.debian.org/python-team/modules/python-hgapi > > https://salsa.debian.org/python-team/modules/python-project-generator-definitions > > https://salsa.debian.org/python-team/modules/python-project-generator > > yotta > = > > New yotta dependencies uploaded for review/sponsored upload: > > https://salsa.debian.org/python-team/modules/python-mbed-ls > https://salsa.debian.org/python-team/modules/python-mbed-host-tests > https://salsa.debian.org/python-team/applications/mbed-test-wrapper > https://salsa.debian.org/python-team/applications/valinor I have now pushed yotta itself for review/sponsorship: https://salsa.debian.org/python-team/applications/yotta Cheers, Nick
Re: RFS: mu-editor and yotta dependencies
On Thu, 20 Dec 2018 at 01:29, Nick Morrott wrote: > > yotta > = > > I am also preparing packaging for yotta, the ARM mbed build system > used for the micro:bit's MicroPython runtime (used by python-uflash > and thus indirectly by the mu editor for flashing the micro:bit). > > The current list of yotta dependencies uploaded to salsa is: > > https://salsa.debian.org/python-team/modules/python-hgapi > https://salsa.debian.org/python-team/modules/python-project-generator-definitions > https://salsa.debian.org/python-team/modules/python-project-generator yotta = New yotta dependencies uploaded for review/sponsored upload: https://salsa.debian.org/python-team/modules/python-mbed-ls https://salsa.debian.org/python-team/modules/python-mbed-host-tests https://salsa.debian.org/python-team/applications/mbed-test-wrapper https://salsa.debian.org/python-team/applications/valinor This leaves yotta itself and firmware-microbit-micropython to complete and push to salsa, which should happen in the next day or two. mu-editor = All necessary dependencies for mu-editor are available for review and upload https://salsa.debian.org/python-team/modules/python-uflash https://salsa.debian.org/python-team/modules/python-nudatus https://salsa.debian.org/python-team/modules/python-guizero https://salsa.debian.org/python-team/applications/mu-editor python-uflash provides an additional binary package to download the MicroPython firmware if firmware-microbit-micropython is unavailable. Thanks, Nick
Re: RFS: mu-editor and yotta dependencies
On Thu, 20 Dec 2018 at 01:29, Nick Morrott wrote: > > I've started pushing dependencies for the mu editor [1] and yotta [2] > to salsa, and would appreciate reviews/feedback on the packaging work > and sponsorship of my uploads when we're happy. > > [1] https://bugs.debian.org/901461 > [2] https://bugs.debian.org/908781 I've pushed mu-editor packaging for review: https://salsa.debian.org/python-team/applications/mu-editor As a short-term stopgap whilst I continue packaging yotta - micro:bit MicroPython's build system, the python-uflash package provides an empty "micro:bit firmware downloader" package to enable full testing of the mu-editor whilst source builds of the MicroPython runtime are unavailable. Cheers, Nick
RFS: mu-editor and yotta dependencies
I've started pushing dependencies for the mu editor [1] and yotta [2] to salsa, and would appreciate reviews/feedback on the packaging work and sponsorship of my uploads when we're happy. [1] https://bugs.debian.org/901461 [2] https://bugs.debian.org/908781 mu editor = The current list of mu dependencies uploaded to salsa is: https://salsa.debian.org/python-team/modules/python-uflash https://salsa.debian.org/python-team/modules/python-nudatus https://salsa.debian.org/python-team/modules/python-guizero A new bugfix release of mu is imminent so I am waiting a few days to see if it drops before pushing. yotta = I am also preparing packaging for yotta, the ARM mbed build system used for the micro:bit's MicroPython runtime (used by python-uflash and thus indirectly by the mu editor for flashing the micro:bit). The current list of yotta dependencies uploaded to salsa is: https://salsa.debian.org/python-team/modules/python-hgapi https://salsa.debian.org/python-team/modules/python-project-generator-definitions https://salsa.debian.org/python-team/modules/python-project-generator I anticipate there will be another half dozen or so packages being uploaded soon to round out the yotta dependency chain. Many thanks, Nick
