Package Details: pineflash-git 0.5.5+4.r311.20250206.897bad8-4

Git Clone URL: https://aur.archlinux.org/pineflash-git.git (read-only, click to copy)
Package Base: pineflash-git
Description: A GUI tool to flash IronOS to the Pinecil V1, V2 and future other pine64 products.
Upstream URL: https://github.com/Spagett1/PineFlash
Licenses: GPL-2.0-or-later
Conflicts: pineflash
Provides: pineflash
Submitter: dreieck
Maintainer: dreieck
Last Packager: dreieck
Votes: 2
Popularity: 0.100458
First Submitted: 2022-12-15 12:03 (UTC)
Last Updated: 2025-03-10 18:43 (UTC)

Latest Comments

1 2 3 Next › Last »

kStor2poche commented on 2025-04-23 18:47 (UTC) (edited on 2025-04-23 18:48 (UTC) by kStor2poche)

Barging in on the conversation here.
While I get your point on the maintainability side and think that you seem honest in your approach, I also think that if you cared enough for the size of the package to be optimized that you included a parallelized version of a tool that is supposed to optimize the size of all pngs found in the source in the dependencies, you may as well want optimize the package for real by :

  • optimizing those images before the package building time and hosting them alongside the pkgbuild

  • or simply not including the dependency and avoiding any unnecessary modification, as per this distro's own principles (see https://wiki.archlinux.org/title/Arch_Linux#Principles), which would also then make this package more maintainable

If that was not the case, what was then even the point of using this tool in the building process?

dreieck commented on 2025-04-23 08:11 (UTC) (edited on 2025-04-23 08:58 (UTC) by dreieck)

https://github.com/Spagett1/pineflash/tree/master/assets has a single PNG file

Currently, yes. But upstream might change that.

If you feel like, you can just remove that statement from your local copy of the PKGBUILD, or use the less efficient optipng instead.

Anctually, I am much more concerned about all the external dependencies out of easy control that rust (cargo) downloads for building pineflash.

Regards!

nyanpasu64 commented on 2025-04-23 08:03 (UTC)

I decided to look for the PNG files in the source repo... and it somehow makes even less sense than before.

https://github.com/Spagett1/pineflash/tree/master/assets has a single PNG file, as shown by editing your PKGBUILD to run echo assets/*.png. This file is all of 14.4 kilobytes, and only used for the .desktop entry (and not compiled into firmware for a size-limited flash chip), so I can't imagine why you would want to compress or parallelize it. (TBH these details were suspicious enough I tried looking for hidden code like xz, but didn't find any thus far.) And I haven't found any past commits in the repository with dozens of removed PNG files either. So I'm wondering what purpose this command serves.

I don't know how zopflipng works either, but I ran it on (a reencoded version of) the image and it seems to pass valgrind without errors?

dreieck commented on 2025-04-23 06:50 (UTC) (edited on 2025-04-23 06:52 (UTC) by dreieck)

What's the purpose of including an extra AUR dependency (I don't know whether it's trustworthy) on zopflipng-parallel?

It's a make dependency only.

It is used to losslessly reduce the size of the PNG images that come with the package. You can look into the PKGBUILD to see where and how it is used.

The bash script zopflipng-parallel is a wrapper around the executable zopflipng, part of the Arch Linux package zopfli, which does this recompression in parallel on all images supplied on the command line, thus speeding up the total operation.
You can have a look into the script if you want to check what it does.

Does this answer your question, @nyanpasu64?

Regards!

nyanpasu64 commented on 2025-04-23 06:35 (UTC)

What's the purpose of including an extra AUR dependency (I don't know whether it's trustworthy) on zopflipng-parallel?

dreieck commented on 2025-02-06 14:29 (UTC)

… and now fixed upstream.

dreieck commented on 2025-02-06 12:26 (UTC)

I manually included this patch which has not yet made it upstream to make it build again.

See this comment in the upstream issue tracker.

Tyrant commented on 2025-01-06 21:45 (UTC)

You are right, I should've read more carefully. It's still not fixed upstream.

prochac commented on 2025-01-03 21:01 (UTC) (edited on 2025-01-03 21:01 (UTC) by prochac)

It looks like a cause, not fix.

- Err(error) => println!("A massive error occured, not sure whats goin on here: \n {}", error),
+ Err(error) => panic!("A massive error occured, not sure whats goin on here: \n {}"),

Tyrant commented on 2025-01-02 17:15 (UTC)

Fixed in https://github.com/Spagett1/pineflash/commit/1cbe5547e19789e26faaef176c3d22a51e457e88

1 2 3 Next › Last »