Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

micropro: init at 0.4 #89689

Closed
wants to merge 2 commits into from
Closed

micropro: init at 0.4 #89689

wants to merge 2 commits into from

Conversation

kaliumxyz
Copy link

Motivation for this change

getting the Micropro TL866CS universal programmer utility in nixpkgs

Things done

Wrote nix file for micropro utility, added self as its maintainer.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@kaliumxyz kaliumxyz changed the title add Micropro micropro: init at 0.4dev Jun 6, 2020
@kaliumxyz kaliumxyz changed the title micropro: init at 0.4dev micropro: init at 0.4 Jun 6, 2020
Copy link
Member

@IvarWithoutBones IvarWithoutBones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few suggestions :)

Also, commit message does not follow the contributing guidelines.

pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
pkgs/development/tools/minipro/default.nix Outdated Show resolved Hide resolved
@kaliumxyz
Copy link
Author

@IvarWithoutBones I've incorporated your suggestions c:

Copy link
Member

@IvarWithoutBones IvarWithoutBones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few more minor nits, otherwise LGTM :)

];

buildInputs = [
stdenv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't look like stdenv is required here.

@@ -0,0 +1,46 @@
{stdenv, fetchgit, pkg-config, libusb1}:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor formatting thing:

Suggested change
{stdenv, fetchgit, pkg-config, libusb1}:
{ stdenv, fetchgit, pkg-config, libusb1 }:
stdenv.mkDerivation rec {

PKG_CONFIG = "${pkg-config}/bin/pkg-config";

buildPhase = ''
sed -i -e 's/ GIT_BRANCH = .*/ GIT_BRANCH = "master"/g' ./Makefile
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patching should probably be done in the preConfigure phase. Also, i think using substituteInPlace would be a bit cleaner than using sed.

pname = "minipro";
version = "0.4";

src = fetchgit {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, missed this earlier. Should be using fetchFromGitLab here, this way you can fetch the stable release:

Suggested change
src = fetchgit {
src = fetchFromGitLab {
owner = "DavidGriffith";
repo = "minipro";
rev = version;
sha256 = "17k2vanz0xrmvl5sa12jr1n4x5m2s7292qs79mvj40bxbhrcmaci";
};

cp -rv ./minipro $out/bin/
mkdir $outputMan -p
mv ./man/* $outputMan
'';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be tabbed over once

@kaliumxyz
Copy link
Author

kaliumxyz commented Jun 11, 2020

@IvarWithoutBones I've split up the package in stable and unstable, moved to using leaveDotGit so that the package can be build as intended (which sadly does mean that we need to keep using fetchgit), fixed the manpages and the udev files, it should be good to go now c: Thank you for your help and feedback so far!

@IvarWithoutBones
Copy link
Member

IvarWithoutBones commented Jun 11, 2020

I've split up the package in stable and unstable

Why both? Wouldn't just stable be good enough?

moved to using leaveDotGit so that the package can be build as intended

That's probably not a very good idea, because of #8567 (Also, pretty sure fetchFromGitLab has a similar flag). From local testing i noticed the testing isn't required, couldn't we just drop it? (Assuming that's why you want to keep .git)

Thank you for your help and feedback so far!

Glad it's helpful :) Apologies about inconsistencies and such, I'm quite a beginner at this 😅

Also, looks like you forgot to push.

@kaliumxyz
Copy link
Author

Why both? Wouldn't just stable be good enough?
The unstable variant has support for newer firmware (though not for the minipro I use), and some fixes

That's probably not a very good idea, because of #8567 (Also, pretty sure fetchFromGitLab has a similar flag). [...]
The .git is for version information, its not required but its part of the tool, I could not find a similar flag on fetchFromGitLab, seeing that its only used for version information and not part of the output, it should not lead to issues with the build being nondeterministic. I just realized that the build output includes a timestamp in the version, which should probably be patched out (let me do that quickly).

forgot to push
pushed now c:

@IvarWithoutBones
Copy link
Member

The unstable variant has support for newer firmware (though not for the minipro I use), and some fixes

Ah, okay 👍

seeing that its only used for version information and not part of the output, it should not lead to issues with the build being nondeterministic

This is an issue in the cloning process, so it would.

@kaliumxyz
Copy link
Author

we can go back to patching out the version information and just showing blanks on -V, setting it to anything else relevant, or manually setting it for every update (unless there is some other way we can get the information of the current commit?).

Copy link
Member

@IvarWithoutBones IvarWithoutBones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few more nits :)

{ stdenv, installShellFiles, which, fetchgit, git, pkg-config, libusb1 }:
stdenv.mkDerivation rec {
pname = "minipro";
version = "0.4dev";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Version naming convention for unstable git revs is unstable-<date>.

Suggested change
version = "0.4dev";
version = "unstable-2020-04-18";

substituteInPlace Makefile --replace '$(shell date "+%Y-%m-%d %H:%M:%S %z")' "1970-01-01 00:00:00 +0000"
'';

buildPhase = ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be using makeFlags for this.

Suggested change
buildPhase = ''
makeFlags = [ "-e minipro" ];

];

buildInputs = [
stdenv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stdenv doesn't seem to be required

description = "An open source program for controlling the MiniPRO TL866xx series of chip programmers";
homepage = "https://gitlab.com/DavidGriffith/minipro";
maintainers = with maintainers; [ kalium ];
license = stdenv.lib.licenses.gpl3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're already doing with stdenv.lib;, you don't need to mention that here.

Suggested change
license = stdenv.lib.licenses.gpl3;
license = licenses.gpl3;

@@ -0,0 +1,49 @@
{ stdenv, installShellFiles, which, fetchgit, git, pkg-config, libusb1 }:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like you're using either git or which, and the package seems to compile fine without them.

@IvarWithoutBones
Copy link
Member

we can go back to patching out the version information and just showing blanks on -V

I have a local expression which does none of the git patching, and doesn't have leaveDotGit enabled. However, it still outputs the following when executing it with the -V flag:

minipro version 0.4dev     A free and open TL866XX programmer
Build date:     2020-06-12 07:43:54 +0000
Commit date:    2019-10-19 23:38:37 +0000
Git commit:     5c397ebf4b5e736c31f4469821895bcc1bd38d69
Git branch:     tag: 0.4, refs/keep-around/5c397ebf4b5e736c31f4469821895bcc1bd38d69

I think we don't need to worry about that at all.

minipro is a utility for using the minipro TL866 series of universal programmers

corrected with suggestions from @IvarWithoutBones
@kaliumxyz
Copy link
Author

okay good, seems to work for me as well now.

I've incorporated your comments, and only patch out the buildDate timestamp (else its not deterministic) :).

Copy link
Member

@IvarWithoutBones IvarWithoutBones left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGMT :)

@Lassulus
Copy link
Member

We need a rebase because the maintainer-list got updated

@SuperSandro2000 SuperSandro2000 marked this pull request as draft November 28, 2020 00:22
@bmwalters bmwalters mentioned this pull request May 12, 2021
10 tasks
@stale
Copy link

stale bot commented Jun 3, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 3, 2021
@Artturin Artturin closed this Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants