AVRDUDE v7.0 released

[dl8dtl]

I just released version 7.0 of AVRDUDE, the first release being rolled from the Github infrastructure.

While I am sure there are many more things to do, and some of those might have deserved to go into the new release, it was already way behind its original schedule (March 2022) anyway. First, there were a number of local personal things that caused it to be deferred, and then there was Stefan Rueger's excellent analysis of mistakes in avrdude.conf in issue #915 which I wanted to clean up before a release.

Enjoy – and be assured that there will be a next release. ;-)

[MCUdude]

Excellent!
Should we perhaps upload pre-compiled binaries for Linux and MacOS as well? It's nice to have a place where known-good binaries can be downloaded.

[mariusgreuel]

@MCUdude You are interested in the [avrdude-linux-*](https://nightly.link/avrdudes/avrdude/workflows/build/main) binaries, correct? Is it possible that you could check whether the binaries work for you, or in other words, do the binaries use the correct dependencies (they use all shared libries)? I remember I used the armhf build once on my Raspi, and it did not work because I was still on Buster and build in on Bullseye. So, I used a Buster docker container for the cross-builds instead. I am not sure however, if that is the proper way to do when we want to build binaries for distribution.

[dl8dtl]

The Avrdude executable is located in a folder called bin, and the avrdude.conf file is located in a folder called etc.

There appears to be one additional avrdude directory on top of them.

[MCUdude]

@mariusgreuel I need binaries for all major platforms that Arduino IDE can be installed onto, but I want them to be from a release and not a nightly build. By looking at the JSON snippet I posted earlier, I need v7.x binaries for arm-linux-gnueabihf, aarch64-linux-gnu, x86_64-apple-darwin12, x86_64-linux-gnu, i686-linux-gnu and i686-mingw32.

Is it possible that you could check whether the binaries work for you, or in other words, do the binaries use the correct dependencies (they use all shared libraries)?

I can test on an Intel Mac, a PC, an x64 Linux computer, and on a really old Rpi model B running the latest Raspbian. But shouldn't a binary "just work" when it's executed on a computer with the correct operating system? I thought libraries were statically linked and didn't need to be installed by the user separately?

[umbynos]

Hello guys, @arduino maintainer here,
Thanks to the effort you guys put in porting the avrdude project to GitHub, we found some bandwidth to look into the git history of our fork.
As some of you may know, we distribute tools and packages using a package_index.json file that has download links inside it, just like @MCUdude pointed out above. We are planning to provide AVRDUDE 7.x in our packages using that index.

I started working on a temporary fork that will be transferred under Arduino org (but it still needs a lot of love and work). Along with @facchinm, I found the patches that we still need, starting from your main branch. They are currently hosted in my dev branch.

I also started to work on a build & release CI based on GH actions that is able to produce binaries as static as possible. We need static binaries because they would work on almost any machine the user is using. To do so, we are trying to cross compile using a docker container I made. We are using that container also to build another tools called rp2040tools (If the container gains traction, I plan to place it to a dedicated repo in the near future).
The binaries produced can be downloaded for testing purposes from here.

My plan would be to:

• Finish the CI (currently the only platform giving me problems is macOS).
• See together with you which patches could be upstreamed.
• Move the release CI to a dedicated GH repo under Arduino organization: Ideally this repo should contain only the patches that could not be upstreamed, and the release workflow. The source code will be only on the official avrdude repo.

These are the lib dependencies of linux_amd64 binary, produced by the CI I'm working on :

$ ldd avrdude
	linux-vdso.so.1 (0x00007ffec4dc0000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4efd4db000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4efd2bc000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4efcecb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4efd879000)

$ file avrdude
avrdude: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.94, with debug_info, not stripped

The binary downloaded from your CI has the following deps:

$ ldd avrdude
./avrdude: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./avrdude)
	linux-vdso.so.1 (0x00007ffc6f931000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f12dbe87000)
	libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f12dbc6d000)
	libusb-0.1.so.4 => not found
	libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f12dba55000)
	libhidapi-libusb.so.0 => not found
	libftdi1.so.2 => not found
	libreadline.so.8 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12db664000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f12dc225000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f12db447000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f12db229000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f12db00a000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f12dae02000)

$ file avrdude
avrdude: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=76ca1e486c10d85b049edb87cf72bd60a44b709c, for GNU/Linux 3.2.0, with debug_info, not stripped

PS I'm on Ubuntu 18.04 LTS

[umbynos]

Quick update:

• Finish the CI (currently the only platform giving me problems is macOS).

Done ✔️

• See together with you which patches could be upstreamed.

🚧 PR here:

• Added fake EFUSE to atmega8 part. #981
• Try to run ChipErase on UPDI even if return code is -67 #982
• Attiny85: increase delay #983
• Revert "Ensure page_size is always at least 1" #984

• Move the release CI to a dedicated GH repo under Arduino organization: Ideally this repo should contain only the patches that could not be upstreamed, and the release workflow. The source code will be only on the official avrdude repo.

✔️ (here it is, along with a test release 7.0-arduino.1)

[mariusgreuel]

One note for the release process: I pulled the Windows 7.0 release, and it says:
avrdude version 6.99, URL: <https://github.com/avrdudes/avrdude>

Before pushing the v7.0 tag, you need to explicitly set the version number in CMakeLists.txt
https://github.com/avrdudes/avrdude/blob/main/CMakeLists.txt#L24

I guess it could not hurt to write up a wiki release procedure. I suppose that would help also if some other person than Jörg would like to create a release :-).

[mariusgreuel]

One more note regarding the deploy.yml action. If you want to make a correction after a release, it is possible to force-push the release tag. If so, however, you should delete the Github release completly, as the release and the release artifacts will always be created, and the script will choke if the release already exists.

[dl8dtl]

One note for the release process: I pulled the Windows 7.0 release, and it says: avrdude version 6.99, URL: <https://github.com/avrdudes/avrdude>

OK, I fixed that, and re-tagged the release. (Deleted it completely this time.)

I guess it could not hurt to write up a wiki release procedure.

Sure! I even missed to update the NEWS file myself this time.