Re: Orphaning mu-editor, firmware-microbit-micropython, and their (build)-deps
On Fri, 19 Apr 2024 at 16:34, Hans-Christoph Steiner wrote: > > Hey Nick, > > Thanks for maintaining mu-editor, my kids are just getting started with it. > So > I might be interested in taking it over. Are the updates a lot of work? I > see > the tarball is tagged with dfsg so there's that... Dear Hans-Christoph, Thank you for your interest. It's great to hear that you're starting to use mu-editor with your kids - it's why I packaged it in the first place. Updating mu-editor, and firmware-microbit-micropython, can be challenging at times and other times straightforward, depending on the changes upstream have made. The initial packaging of the whole "stack" took a long time, as upstream deliver mu-editor, uflash and the micropython binary (one of the reasons why it's +dfsg) all together in the same project. I think it required 14 separate source packages to be built to finally get mu-editor and micropython for the micro:bit into Debian. Keith Packard (CC'd) is interested in contributing and co-maintaining mu-editor, and there is a current MR in the repo. The mu-editor repository has also just had a drive-by upstream bump to version 1.2.0 but nothing else so far... Thanks, Nick
Orphaning mu-editor, firmware-microbit-micropython, and their (build)-deps
Dear team, I intend to orphan two of my team maintained packages, and their several (build)-dependencies, that I originally packaged and have maintained (to varying degrees, it can be argued) since 2018. Thank you to team members who have contributed bug fixes and patches during this time. I've really appreciated it \o/. I don't have (and have not had for a while) the time to maintain all of these, so to free them up for more active development following new releases I would like to offer these to other members of the team to pick up if interested. Apologies for holding up any progress; I should have done this a while ago... I am the only Uploader on all of the packages below. If anyone is interested, please take over and replace me as the Uploader. If no one has added themselves as an uploader in Salsa within two weeks to any of the packages below, I will formally orphan them: mu-editor (new 1.2.0 version to be packaged) python-uflash (build dep, dep, new version to be packaged with mu-editor) python-nudatus (build dep, dep, up to date) python-pytest-random-order (build dep, up to date) python-guizero (dep, up to date) firmware-microbit-micropython (new 1.1.1 version to be packaged) yotta (build dep, up to date) valinor (build dep, up to date) python-project-generator (build dep, up to date) python-project-generator-definitions (build dep, up to date) mbed-test-wrapper (build dep, up to date) python-mbed-host-tests (build dep, up to date) python-mbed-ls (build dep, up to date) python-hgapi (build dep, up to date) I will also remove myself as an uploader on pytest-xvfb (leaving one other), which is a build-dep of python-guizero. With all thanks, Nick
Re: How to create multi-source tarball with different submodules for scipy
On Mon, 16 Jan 2023 at 16:06, Andreas Tille wrote: > > Hi, > > I tried to create a multi-source tarball for scipy in its experimental > branch[1]. Upstream includes a set of git submodules in its build > process. I intended to merge all these submodules in a single > scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a > script[2] which makes sure that the exact directory structure as it is > used by upstream is conserved. This directory layout is needed in the > build process. Unfortunately `dpkg-source -x` extracts the content of > the submodules tarball into a subdirectory submodules/. > > Is there any trick to unpack this tarball right into the root? > Otherwise I need to do some symlinks workaround in d/rules to provide > all files where these are needed. When I packaged firmware-microbit-microbit I wasn't aware of any tricks, so I resorted to overriding dh_auto_build to move the extracted components into their expected paths before building: https://salsa.debian.org/python-team/packages/firmware-microbit-micropython/-/blob/debian/master/debian/rules Not sure if this useful, but I thought I'd pass it along in case it helps. Cheers, Nick
Bug#979152: ITP: ueberzug -- a command line utility which draws images on terminals
Package: wnpp Severity: wishlist Owner: Nick Morrott X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, ni...@debian.org * Package name: ueberzug Version : 18.1.9 Upstream Author : Nico Bäurer * URL : https://github.com/seebye/ueberzug * License : GPL-3+ Programming Lang: Python Description : a command line utility which draws images on terminals Überzug is a command line utility which draws images on terminals using child windows. Advantages to w3mimgdisplay: - no race conditions as a new window is created to display images - expose events will be processed, - so images will be redrawn on switch workspaces - tmux support (excluding multi pane windows) - terminals without the WINDOWID environment variable are supported - chars are used as position - and size unit - no memory leak (/ unlimited cache) I intend to maintain this package within the Python packaging team.
Re: Policy proposal: Consistent use of UNRELEASED in debian/changelog
On Mon, 28 Sep 2020 at 01:08, Louis-Philippe Véronneau wrote: > > Hi! > > I am proposing a minor addition to the DPT policy to try to make the use > of UNRELEASED in debian/changelog more consistent. The full diff can be > found here +1. Seems to match what we do in the Perl team. Thanks, Nick
Re: Merging the PAPT and the DMPT
On Mon, 21 Sep 2020 at 12:21, Ondrej Novy wrote: > > Example of mass-commit: > https://salsa.debian.org/python-team/packages/alembic/-/commit/0519af5c5f82cced88431b6c0ec364f2979e0c42 > https://salsa.debian.org/python-team/packages/alembic/-/commit/51dbd7b278551fbd33abac72c7a240e6baea6a16 > > Suggestion for better wording of changelog is welcome. Here goes nothing! d/control: Update Vcs-* fields with new Debian Python Team salsa layout d/control: Update Maintainer field with new Debian Python Team contact address For a mass commit it seems sensible to make the messages consistent, but these may still be too verbose. Cheers, Nick
Re: RFS: python-pyjsparser (ITP bug #943785)
On Fri, 1 Nov 2019 at 09:50, Peter Wienemann wrote: > > Dear Python team, > > I prepared packaging for python-pyjsparser (ITP bug #943785) on > > https://salsa.debian.org/python-team/modules/python-pyjsparser > > It provides a fast JavaScript parser written in Python. > > It would be great if a DD could review the code, provide feedback and > (if everything looks OK) upload it. Peter, Thank you for your work in packaging python-pyjsparser. Out of curiosity, what are you using to be build your package? I checked out the package and built it - your work looks good, and the build was successful. I then ran it through lintian, Debian's package linting tool which you should get into the habit of using before uploading to salsa (and once you're a DM/DD, also before uploading to the archive). Here is the lintian output for the binary changes file: N: Unpacking packages in group python-pyjsparser/2.7.1-1 N: N: Processing changes file python-pyjsparser (version 2.7.1-1, arch source all) ... N: N: Processing source package python-pyjsparser (version 2.7.1-1, arch source) ... P: python-pyjsparser source: rules-requires-root-missing I: python-pyjsparser source: debian-watch-contains-dh_make-template (line 11) X: python-pyjsparser source: debian-watch-does-not-check-gpg-signature I: python-pyjsparser source: testsuite-autopkgtest-missing X: python-pyjsparser source: upstream-metadata-file-is-missing N: N: Processing buildinfo package python-pyjsparser (version 2.7.1-1, arch all source) ... N: N: Processing binary package python3-pyjsparser (version 2.7.1-1, arch all) ... I: python3-pyjsparser: extended-description-is-probably-too-short N: Finished processing group python-pyjsparser/2.7.1-1 The output is split into 2 sections for the source and binary package(s). As you can see, there are a few issues to take care of, which I expand on below (you can ignore the gpg-signature warning unless the packages on pypi are signed). * d/control - no Rules-Requires-Root field [lintian] - the extended package description should probably include details about the library's key features/support [lintian] * d/copyright - the only copyright dates I can see in the source are 2014-2015 - you can add the Upstream-Contact field to the header * d/rules - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1" * d/upstream/metadata - please add and complete this file - there are plenty of examples in the team's salsa project [lintian] * d/watch - +1 for asking upstream to version their releases on github - the additional (commented) scaffolding inserted into the file by dh-make can be removed to leave only the version line and the URL to check [lintian] - as this is a version 4 watch file, we can take advantage of new variable substitutions for the version and extension fields, so that the URL to check would look like: https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@ * upstream changelog - there is no upstream changelog * documentation/examples - There is no documentation at all, aside from the simple example in the README. Perhaps this snippet could be installed as an example when installing the package? * tests - there are no tests to run at build time (and therefore no autopkgtests to run for continuous integration whenever the package's dependencies are updated). Looking at the github repo there seems to be a significant testsuite that should really be available in the Debian source package to take advantage of autopkgtest. [lintian] I hope you find this useful - if you have any questions don't hesitate to ask the team (the Python list is visible and archived, IRC may get a quicker answer...). I'm a new DD and there are likely some things that the more experienced members of the team will notice. Thanks, Nick
Request to (re)join the team
Hi everyone, I'd like to migrate my current membership of the debian-python DPMT and PAPT teams on salsa to use my shiny, new DD account \o/. My salsa account is nickm. Thank you for your help, guidance, mentorship and sponsored uploads so far! Cheers, Nick
RFS: mu-editor 1.0.2+dfsg-3
Dear team, I've just uploaded mu-editor 1.0.2+dfsg-3 to PAPT to fix #930270 [1] and was wondering if someone might have some time to review and upload, so that I might file an unblock request with the release team for buster. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930457 Many thanks, Nick
Re: Review/upload request for python-guizero
On Fri, 1 Mar 2019 at 06:14, Dmitry Shachnev wrote: > > Hi Nick, > > On Fri, Mar 01, 2019 at 02:56:38AM +, Nick Morrott wrote: > > Yesterday I uploaded a new 0.6.0 release of python-guizero to DPMT on salsa > > [1]. > > > > [1] https://salsa.debian.org/python-team/modules/python-guizero > > > > Conscious of the approaching Buster freeze and 10-day migration > > period, would anyone be kind enough to review and upload this new > > release today? > > Uploaded. Dmitry, Thank you so much! Cheers, Nick
Review/upload request for python-guizero
Yesterday I uploaded a new 0.6.0 release of python-guizero to DPMT on salsa [1]. [1] https://salsa.debian.org/python-team/modules/python-guizero Conscious of the approaching Buster freeze and 10-day migration period, would anyone be kind enough to review and upload this new release today? Thanks in advance, Nick
Re: Build test failure for python-easydev
On Wed, 23 Jan 2019 at 06:54, Andreas Tille wrote: > > Hi Nick, > > On Tue, Jan 22, 2019 at 11:33:09PM +, Nick Morrott wrote: > > > I'm a newcomer to the python team, but I'm looking at this at the > > > moment to improve by debugging and python packaging. > > Cool. Thanks a lot. Your outright contribution was very helpful and > really welcome. The only change I made is to revert your commit > 38022ac5 since there is no point in changing the upstream source that > way. I agree upstream should not ship that file but if its in the > upstream tarball I see no need to remove it here. Apologies about that. My build failed immediately due to the presence of that file when I started testing, and removing it got the build to proceed so I could look at the test failures. That file is not present in their upstream github repository at the release date of 0.9.37. pypi points to the repo as the definitive source location so it's my fault for not investigating the pypi tarball further. If it persists it can obviously always be removed automatically via d/copyright if desired. > > Hope this helps, > > Definitely. Package is uploaded - one worry less. :-) Excellent! Cheers, Nick
Re: Build test failure for python-easydev
On Tue, 22 Jan 2019 at 22:25, Nick Morrott wrote: > > On Tue, 22 Jan 2019 at 20:50, Andreas Tille wrote: > > > > Hi Piotr, > > > > Also here I have no idea what to do next. > > Andreas, > > I'm a newcomer to the python team, but I'm looking at this at the > moment to improve by debugging and python packaging. Andreas, I've sent an MR [1] for you (and more experienced Python packagers) to review to get you started. [1] https://salsa.debian.org/med-team/python-easydev/merge_requests/1 I note the following lintian issues after a build. The important ones are the missing manpages: N: Starting on group python-easydev/0.9.37-1 N: Unpacking packages in group python-easydev/0.9.37-1 N: N: Processing changes file python-easydev (version 0.9.37-1, arch source all) ... N: N: Processing source package python-easydev (version 0.9.37-1, arch source) ... X: python-easydev source: upstream-metadata-file-is-missing X: python-easydev source: debian-watch-does-not-check-gpg-signature N: N: Processing binary package python3-easydev (version 0.9.37-1, arch all) ... X: python3-easydev: library-package-name-for-application usr/bin/easydev3_browse usr/bin/easydev3_buildPackage X: python3-easydev: application-in-library-section python usr/bin/easydev3_browse usr/bin/easydev3_buildPackage P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/cno/static/bgfooter.png P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/cno/static/bgtop.png P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/cno/static/warning.jpg P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/standard/static/bgfooter.png P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/standard/static/bgtop.png P: python3-easydev: image-file-in-usr-lib usr/lib/python3/dist-packages/easydev/share/themes/standard/static/warning.jpg W: python3-easydev: binary-without-manpage usr/bin/easydev3_browse W: python3-easydev: binary-without-manpage usr/bin/easydev3_buildPackage N: N: Processing binary package python-easydev (version 0.9.37-1, arch all) ... X: python-easydev: library-package-name-for-application usr/bin/easydev2_browse usr/bin/easydev2_buildPackage X: python-easydev: application-in-library-section python usr/bin/easydev2_browse usr/bin/easydev2_buildPackage P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/cno/static/bgfooter.png P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/cno/static/bgtop.png P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/cno/static/warning.jpg P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/standard/static/bgfooter.png P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/standard/static/bgtop.png P: python-easydev: image-file-in-usr-lib usr/lib/python2.7/dist-packages/easydev/share/themes/standard/static/warning.jpg W: python-easydev: binary-without-manpage usr/bin/easydev2_browse W: python-easydev: binary-without-manpage usr/bin/easydev2_buildPackage N: Finished processing group python-easydev/0.9.37-1 Hope this helps, Nick
Re: Build test failure for python-easydev
On Tue, 22 Jan 2019 at 20:50, Andreas Tille wrote: > > Hi Piotr, > > Also here I have no idea what to do next. Andreas, I'm a newcomer to the python team, but I'm looking at this at the moment to improve by debugging and python packaging. Thanks, Nick
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
Bug#917923: ITP: python-pytest-random-order -- pytest plugin to randomise the order of tests (Python 3)
Package: wnpp Owner: Nick Morrott , Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-pytest-random-order Version : 1.0.4 Upstream Author : Jazeps Basko * URL : https://github.com/jbasko/pytest-random-order * License : Expat Programming Lang: Python Description : pytest plugin to randomise the order of tests (Python 3) pytest-random-order is a pytest plugin that randomises the order of tests. This can be useful to detect a test that passes just because it happens to run after an unrelated test that leaves the system in a favourable state. The plugin allows the user to control the level of randomness they want to introduce and to disable reordering on subsets of tests. Tests can be rerun in a specific order by passing a seed value reported in a previous test run. This package installs the pytest plugin for Python 3. I plan to maintain this package in the Debian Python Modules Team.
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
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
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
Bug#917384: ITP: python-mbed-host-tests -- tools to flash, reset and supervise testing on mbed-enabled devices
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-mbed-host-tests Version : 1.4.4 Upstream Author : Przemyslaw Wirkus * URL : https://github.com/ARMmbed/htrun * License : Apache-2.0 Programming Lang: FIXME Description : tools to flash, reset and supervise testing on mbed-enabled devices mbed-host-tests is a module and utilities used during ARM Mbed Enabled device development for: * Driving test binary flashing * Device reset * Test execution I plan to maintain this package in the Debian Python Modules Team.
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
Bug#917118: ITP: python-mbed-ls -- module listing mbed-enabled devices connected to host
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-mbed-ls Version : 1.6.2 Upstream Author : Przemyslaw Wirkus * URL : https://github.com/ARMmbed/mbed-ls * License : Apache-2.0 Programming Lang: Python Description : module listing mbed-enabled devices connected to host The Mbed LS module detects and lists "Mbed Enabled" devices connected to the host computer. Mbed LS provides the following information for all connected boards using console (terminal) output: - Mbed OS platform name - mount point (MSD or disk) - serial port I plan to maintain this package in the Python Applications Packaging Team.
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
Bug#913924: ITP: project-generator-definitions -- collection of target/MCU definitions for project-generator
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: project-generator-definitions Version : 0.2.36 Upstream Author : Martin Kojtal * URL : https://github.com/project-generator/project_generator_definitions * License : Apache-2.0 Programming Lang: Python Description : collection of target/MCU definitions for project-generator project-generator-definitions is a dependency of project-generator [1]. [1] https://bugs.debian.org/913923 I plan to maintain this package in the Python Applications Packaging Team.
Bug#913923: ITP: project-generator -- generate tailored project files for embedded tools (IDEs)
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: project-generator Version : 0.9.13 Upstream Author : Martin Kojtal * URL : https://github.com/project-generator/project_generator * License : Apache-2.0 Programming Lang: Python Description : generate tailored project files for embedded tools (IDEs) project-generator is a dependency of valinor [1]. [1] https://bugs.debian.org/913920 I plan to maintain this package in the Python Applications Packaging Team.
Bug#913920: ITP: valinor -- generate IDE project files to debug ELF files
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: valinor Version : 0.0.11+git20160222.486094a Upstream Author : ARM Limited * URL : https://github.com/ARMmbed/valinor * License : Apache-2.0 Programming Lang: Python Description : generate IDE project files to debug ELF files Valinor is used to generate debugger project files, and launch a debugger, when debugging an ELF file. Valinor is designed to be used as a proxy debug command for yotta targets to provide as their scripts.debug command. Valinor is a dependency of yotta [1]. [1] https://bugs.debian.org/908781 I plan to maintain this package in the Python Applications Packaging Team.
Bug#908787: RFP: pigpio -- library allowing remote control of Raspberry Pi GPIO
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org, pkg-raspi-maintain...@alioth-lists.debian.net * Package name: pigpio Version : 67 Upstream Author : Joan * URL : https://github.com/joan2937/pigpio * License : Public Domain Programming Lang: C/Python Description : library allowing remote control of Raspberry Pi GPIO pigpio is a C/Python library for the Raspberry Pi which allows (remote) control of the General Purpose Input Outputs (GPIO). It is a dependency of mu-editor [1] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901461
Bug#908783: ITP: firmware-microbit-micropython -- MicroPython runtime for the BBC micro:bit
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: firmware-microbit-micropython Version : 1.0.0-rc.4 Upstream Author : The MicroPython-on-micro:bit Developers * URL : https://github.com/bbcmicrobit/micropython * License : Expat Programming Lang: C Description : MicroPython runtime for the BBC micro:bit The BBC micro:bit is a small computing device for children. One of the languages it understands is the popular Python programming language. The version of Python that runs on the BBC micro:bit is called MicroPython. This package provides a firmware image that can be flashed to the micro:bit that provides the MicroPython REPL and the ability to upload Python scripts for execution. The MicroPython firmware uses the yotta build tool for build and dependency management, and gcc-arm-none-eabi for compilation. I plan to maintain this package in the Python Applications Packaging Team.
Bug#908781: ITP: yotta -- build tool for C/C++ projects using modular components
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: yotta Version : 0.18.5 Upstream Author : ARM Limited * URL : https://github.com/ARMmbed/yotta * License : Apache-2.0 Programming Lang: Python Description : build tool for C/C++ projects using modular components yotta is a tool from ARM mbed, to make it easier to build better software with C++ and C by re-using modules. Modules are published to the yotta registry to share them with other people, or re-use them privately in your own projects. Whenever you build a project with yotta, you first select a yotta target. Targets describe the platform that you're building for (such as an embedded IoT development board, or natively for Linux), and provide all the information that yotta and modules you're using need to configure themselves correctly for that platform. yotta is the build tool used for the compilation of the micro:bit MicroPython firmware. I plan to maintain this package in the Python Applications Packaging Team.
Re: Request to join DPMT and PAPT
On 27 August 2018 at 07:35, Ondrej Novy wrote: > Hi, > > čt 23. 8. 2018 v 18:16 odesílatel Nick Morrott > napsal: >> >> would like to join the Python Modules (DPMT) and Python Applications >> (PAPT) teams, > > > welcome :). Ondřej, eamanu15, Thank you both for the warm welcome :) Cheers, Nick
RFS: mu-editor/1.0.0-1 [NEW]
Please review and sponsor the upload of the new package mu-editor
* Package name: mu-editor
Version : 1.0.0-1
Upstream Author : Nicholas Tollervey
* URL : https://github.com/mu-editor/mu
* License : GPL-3.0+
Programming Lang: Python
Description : simple editor for beginner Python programmers
Mu is a simple code editor for beginner programmers based on extensive
feedback from teachers and learners. Having said that, Mu is for
anyone who wants to use a simple "no frills" editor.
Mu is a modal editor with modes for Adafruit's CircuitPython, the
micro:bit's version of MicroPython, PyGame Zero and standard Python 3
(including a graphical debugger). Some of the modes make available a
REPL (either running on the connected CircuitPython or MicroPython
device or as a Jupyter based iPython session in Python3 mode).
It builds the following binary packages:
mu-editor - simple graphical Python editor for beginner programmers
mu-editor-doc - developer documentation for mu-editor
The package was checked using the latest version of lintian, and is
lintian clean (bar testsuite-autopkgtest-missing which is not yet overridden).
The packaging has been uploaded to Debian Mentors:
https://mentors.debian.net/package/mu-editor
The packaging can also be found on salsa.d.o:
https://salsa.debian.org/nickm-guest/mu-editor.git
Please note that the packages are currently tagged for
non-free/{python,docs} - the embedded pre-compiled Micropython
firmware for the micro:bit doesn't leave an alternative AFAICT at the
moment, with the firmware source not yet being a part of Debian.
Thanks,
Nick
Request to join DPMT and PAPT
Hi, I would like to join the Python Modules (DPMT) and Python Applications (PAPT) teams, initially in order to package the mu editor [1] and help out with packaging future dependencies. [1] https://bugs.debian.org/901461 I have read, and accept, the Python Modules policy [2]. I have been unable to find the Python Applications policy document [3] (linked from the PAPT wiki page [4]) on salsa since the alioth transition. [2] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst [3] http://python-apps.alioth.debian.org/policy.html [4] https://wiki.debian.org/Teams/PythonAppsPackagingTeam My salsa login is nickm-guest. I have been a member of the Debian Perl team since November 2015 [6]. [6] https://qa.debian.org/developer.php?login=knowledgejunkie%40gmail.com Thanks, Nick
Request to join the Python Modules and Python Applications teams
Good evening everyone, I would like to join the Python Modules (DPMT) and Python Applications (PAPT) teams, initially in order to package the mu editor [1] and help out with packaging future dependencies. [1] https://bugs.debian.org/901461 I have read, and accept, the Python Modules policy [2]. I have been unable to find the Python Applications policy document [3] (linked from the PAPT wiki page [4]) on salsa since the alioth transition. [2] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst [3] http://python-apps.alioth.debian.org/policy.html [4] https://wiki.debian.org/Teams/PythonAppsPackagingTeam My salsa login is nickm-guest. I have been a member of the Debian Perl team since November 2015 [6]. [6] https://qa.debian.org/developer.php?login=knowledgejunkie%40gmail.com Thanks, Nick
