New Release 2.2.0 release ?

[hzeller]

Given that the last commit hinted that 2.2.0 is around the corner, but has been sitting there for a few months, I would like to request to create a new release.

Reason is that I'd like to use the avrxmega3 (attiny1604, attiny804,...) class of devices that have been added after the last release.

If this gets a proper 2.2.0 label and release, it is much easier to convince distributions to pick up and package this version.

Thank you!

(Currently some distributions are stuck in even older versions, but that is a different story)

[dl8dtl]

Basically, not a bad idea, but I'd need some time to at least walk through some of the bugs, and fix the most serious ones.

Going through the pull requests is probably the simpler part here.

[leonty]

Please, include in 2.2.0 the patch mentioned in https://github.com/avrdudes/avr-libc/issues/563 (pgmspace utils generic usage for tiny core MCUs). Moreover this patch has already been incorporated by Microchip in their version of avr-libc https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-B4AD7063-9288-4E83-A857-F4FBD028A8BB

[hzeller]

@dl8dtl it seems like you're pretty busy, are there things we can help to get a release out the door ?

[kamocat]

Is there a list of issues which need to be closed before the 2.2 release? I am happy to help.

[leventelist]

I'd be happy to test an RC version of 2.2.0... if that helps.

[leventelist]

I created a fork, and applied some of the PRs above. https://github.com/leventelist/avr-libc

[anatol]

Hi, the Arch package maintainer here. Some of our users keep asking us to bring the latest avr-libc changes and make a new Arch package. But our policy is to stick to the official releases only. Thus we rely on you to provide a new 2.2.0 release.

Any ETA for 2.2.0 release date?

[dl8dtl]

The question would go to Johann, how comfortable he'd feel to roll out the status quo as v2.2.0.

Actually preparing the release is not that much work, I'll be able to find the time for that.

[dl8dtl]

Here is the result of a make distcheck from last night. If you have troubles unpacking the file, it is actually a .tar.bz2 file, but Github doesn't allow me to upload it with that extension. avr-libc-220git.zip

[sprintersb]

There's 2 problems:

1. How to deal with problems in I/O headers? Supporting it all by hand and reviewing changes introduced by device-packs is beyond any reasonable effort. Just using headers from the newest device packs makes it easier to transition from IDEs that use such packs, but it might render quite some users code invalid, so that they would have to port their code to the layout of device packs.
2. While generating HTML docs works as expected, I have considerable problem in generating PDF. 100.000+ errors due to non-existent fonts glyphs. I tried to follow the docs to install new fonts in TexLive, but that's very complicated and requires closed source stuff which is not hosted by TexLive. Plus, Doxygen generates tex files that will hang the TeX processor. It will bail out after 100 errors, but no pdf is generated. What am doing is just make pdf in $build/doc/api.

[dl8dtl]

I'd prefer keeping traditional IO headers where they exist. Atmel eventually switched to generated headers, which might (as you noticed) incompatible with ours. In particular, in the past, names in datasheets have sometimes been changed, and then, we kept the historic names for compatibility as aliases. Automatically generated headers probably would not work that way.

Also, in particular for the ATmega*RF devices, we once tried to establish a new, more error-preventing naming scheme using bitfields (similar to what can be found now with many ARMs). Atmel's auto-generated headers don't follow that scheme, but there might be sourcecode in the wild using it.

For new devices that don't have any precedence in avr-libc, we could simply use their auto-generated headers.

I'm running into troubles with compiling the documentation now myself. It seems recent doxygen produces LaTeX macro calls that just don't work (and then produce hundreds of errors). I'll investigate a bit further.

[sprintersb]

There are also the following issues with the documentation:

• release_method.html is outdated and needs a refresher, it still explains SVN stuff.
• In avr/interrupts.html#avr_signames there is a list of all ISR names for all devices, which is pretty much outdated. I'd rather add a FAQ entry on how to find IRQ names for a device than supporting more than 10000 entries...

[dl8dtl]

Updating the release stuff is probably not going to be a big deal, but first, I need a working Doxygen setup again that produces valid LaTeX.

The interrupt name table has once been automatically generated, but the infrastructure for that is now defunct (and IIRC their XML files also changed format). So yes, it needs to be written in a generic form.

[sprintersb]

Doxygen setup again that produces valid LaTeX.

The avr libc documentation says to install MiKTeX, so is TexLive supposed to work at all?

[dl8dtl]

MikTeX used to be a fairly complete TeX setup once, probably at a time when there wasn't a TeXLive at all.

Anyway, I've always been compiling it with TeXLive (as long as there used to be a TeXLive). My current issue really seems to be related to the longtabu environment which Doxygen offers as their own LaTeX implementation for tables that are defined in plain HTML in the Doxygen source. Maybe it's related to some special stuff there, we are using rowspan/colspan, for example.

All I can say: that used to compile before, with older versions of Doxygen. I just fails now.

[sprintersb]

we are using rowspan/colspan, for example

Doxygen allows rowspan/colspan and has it in its documentatio: https://www.doxygen.nl/manual/tables.html

To all of my knowledge, the only HTML-like elements are ones explicitly allowed and understood by Doxygen.

[dl8dtl]

Yes, all there. It produces LaTeX source code that contains the row and column spans, yet the LaTeX fails to compile.

[sprintersb]

I went ahead and added a new script for and version of vectortable.dox in https://github.com/avrdudes/avr-libc/commit/5021ae0eb77626a4969c253c10f53da52e522177.

• The script extracts the information from #include <avr/io.h> (hence needs some up-to-date compiler).
• The table is huge, with ~650 rows and ~12000 mcu mentions. Therefore, it's wrapped in \htmlonly.

[dl8dtl]

but first, I need a working Doxygen setup again that produces valid LaTeX.

Update on this: checking out release 2.1.0, I can compile the documentation. So, the breakage must have been introduced by one of the documentation changes since … guess I have to bisect that now, unless I can find it by reviewing the diffs.

[sprintersb]

I can compile v2.1, too (TexLive 2022), but the pdf has only images and table borders, not a single letter is visible. After

apt install doxygen-latex
apt install texlive-fonts-recommended
tlmgr install psnfss
tlmgr install helvetic

I still get zillions of Missing character: There is no ... in font nullfont! due to

kpathsea: Running mktextfm pcrro8t
.../mktexnam: Could not map source abbreviation  for pcrro8t.
.../mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; input pcrro8t
This is METAFONT, Version 2.71828182 (TeX Live 2022) (preloaded base=mf)
kpathsea: Running mktexmf pcrro8t
! I can't find file `pcrro8t'.
...
! Font T1/pcr/m/it/10=pcrro8t at 10.0pt not loadable: Metric (TFM) file not found.
kpathsea: Running mktextfm nullfont

The infinite loop is in the longtabu environment in mem_sections.tex for table Memory Regions of the Default Linker Script. Features not used before are: <caption>, <th>, superscript.

The errors can be seen without \batchmode.

The source uses <td> without </td> which should be fine; Doxygen adds the </td>'s in the HTML version.

[dl8dtl]

not a single letter is visible

That seems like a font installation issue. I didn't run into that, I always got a readable PDF.

I could get the mem_sections.tex to compile after removing the colspan from a normal table row – maybe it's supported only in table headings? Anyway, it then stumbles across more serious errors in assembler.tex which I still did not understand nor was able to remedy them.

The source uses <td> without </td> which should be fine

It is; adding </td> doesn't change the error behaviour at all.

So it must be something else in those tables, still investigating.

[dl8dtl]

Guess we are stumbling across genuine Doxygen bugs here. :-( The first culprit I found is \anchor inside a table. If I remove all of them in assembler.dox, it compiles. (The \anchor inside a normal list can remain.) Next, it complains about LaTeX errors in the demo project now.

[dl8dtl]

I see there is a doxygen 1.11.0 just released. I have to compile it here outside of the normal FreeBSD ports infrastructure though, as they have not yet been updated.

[dl8dtl]

Unfortunately, still the same errors. :-( So guess we have to prepare a bug report, but that needs to isolate the bugs in a minimum example.

[dl8dtl]

There appears to be more breakage even in older releases. For example, most of the content for <avr/power.h> disappeared between these two releases in the LaTeX / PDF version. All that appears to be a big mess. :((

[sprintersb]

Maybe I missed some fixes like https://github.com/avrdudes/avr-libc/commit/258b20e192d320a07f3111e6a69a1218109aa5b5

[dl8dtl]

<power.h> looks OK to me, so maybe it's in another file. The various LaTeX source files are all concatenated together, so errors from other files might affect one that is later in the chain. Strange that compilation of the docs on 2.0 works even without this kind of changes – I explicitly checked it. I can still build a 2.0 documentation that is more complete.

All in all, Doxygen appears to be a very sensitive baby …

[dl8dtl]

Small update: \anchor inside a table seems to be severely broken, but it's easy enough to move the anchor just before the table. Then, it compiles now. Updated a number of things, it's right now in the documentation_fixes branch, I'm going to file a PR for that soon. Once that is done, I think we are fine for a release.

[sprintersb]

@anatol @hzeller The main obstacle for a new release (generating PDF documentation) is now out of the way. What avr-gcc version are you planning to use with the next libc release?

[anatol]

Arch Linux does not dictate a version you need to release. Arch Linux helps to bring software you provide to users. Arch always packs the latest release made by upstream (you).

[sprintersb]

Arch Linux does not dictate a version you need to release. Arch Linux helps to bring software you provide to users. Arch always packs the latest release made by upstream (you).

I am asking because the libc depends on the version of the compiler, and how the compiler has been configured. Does this mean than when a new GCC version is released, then Arch does outomatically rebuilds libc? Same for releasing Binutils, which GCC depends on etc.

[hzeller]

I am using NixOS, and while I am not a direct packager of gcc, libc etc, it works similar like in Arch: the latest version of everything is combined, and if there are cross-dependencies, things are re-compiled; so say avr gcc changes, then avr libc, binutiles etc. is also recompiled. So nothing to worry about.

[dl8dtl]

What avr-gcc version are you planning to use with the next libc release?

Mine is 11.2.0.

Not sure, are we just going to roll source code releases, or do we also want to maintain binary releases?

[hzeller]

I'd do source-code releases and then have the package maintainers by different Linux distros figure it out.

[dl8dtl]

Sure, but that's Linux.

In the past, we also provided binary releases for those who don't have the ability to easily get at their own compilation. Not sure if anyone would still need these. People running Microchip tools would probably just stick with their old compilers and libraries anyway, I guess.

[anatol]

At arch we always try to use the latest released version of a project (gcc, libc, ...). We just need the source tarball, and then we compile our own binary package that users will install.

[dl8dtl]

The source tarball will be there, of course. That's what always falls out of the make distcheck step during release building.

[dl8dtl]

2.2.0 is done

[anatol]

Thank you very much!

[sprintersb]

2.2.0 is done

Great! Though README.md documentation still points to nongnu.org (and has Atmel).

[sprintersb]

And in my local HTML documentation, the "Main Page" is just containing a table-of-contents of the documentation, the very page content like supported AVR devices is missing.

...found it: Yet another builddir vs. srcdir issue: 9aa7056d7bce5ba9dc26378d38d9e664d9e91980

[sprintersb]

And maybe https://avrdudes.github.io/avr-libc/ needs "Atmel" being adjusted, too. Nerve-wrecking me.

[sprintersb]

The configure.ac version should now be 2.3.0git or 2.2.1git or something like that, no?

[leventelist]

Thank you all for this release!

On Sun, Jun 9, 2024, 01:21 Jörg Wunsch @.***> wrote:

2.2.0 is done

— Reply to this email directly, view it on GitHub https://github.com/avrdudes/avr-libc/issues/905#issuecomment-2156223229, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLOFSYK2M5B6G2UZL2FGKLZGOGYVAVCNFSM6AAAAAATY2BXF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGIZDGMRSHE . You are receiving this because you commented.Message ID: @.***>

[sprintersb]

@dl8dtl One more question: On https://avrdudes.github.io/avr-libc/ there are links to the documentation, but no links to release balls. And the release notes, are they only available per NEWS file, or is there some "official" release notes page?

[dl8dtl]

2.2.0 is done

Great! Though README.md documentation still points to nongnu.org (and has Atmel).

Thanks, e3cd701b7b7724c8

...found it: Yet another builddir vs. srcdir issue

Ah sorry, consequence of generating main_page.dox now (but the diverging license statements were really painful).

The configure.ac version should now be 2.3.0git or 2.2.1git or something like that, no?

b791e8d7d458b2af647

Also forgot this in the release procedure explanation.

And maybe https://avrdudes.github.io/avr-libc/ needs "Atmel" being adjusted, too.

I plan some more fine-tuning there anyway.

there are links to the documentation, but no links to release balls.

Well, the release tarballs are available from the normal Github releases area. But we could add a pointer there, too.

And the release notes, are they only available per NEWS file, or is there some "official" release notes page?

Basically yes, as it's cumulative. We could certainly also put that release's copy of NEWS straight in the docs directory.

[hzeller]

Could you copy the relevant section from the NEWS file to the release notes in the github release ? https://github.com/avrdudes/avr-libc/releases/tag/avr-libc-2_2_0-release

This is probably where most people will look, and it is easy to do (modulo some hand-formatting as markdown maybe).

[dl8dtl]

I see an option there to create release notes automatically (based on merged PRs), but I don't see one to explicitly set release notes. I could just add NEWS to the list of assets, of course.

[hzeller]

What I mean just in the description of the release; so where it now says This is the first version of the AVR-LibC project that is released from Github. ... you can add more text, manually extracted from the NEWS section (for you, there should be an edit button in the release)

There is also a way to show the changes between tags, but with a lot of changes like here, this is less uesful. https://github.com/avrdudes/avr-libc/compare/avr-libc-2_1_0-release..avr-libc-2_2_0-release

[dl8dtl]

Well, I wouldn't want to blow up that description that much. It would be 180 lines for the current release – and I doubt it is really well enough ready for markdown display.

I just added the file as an asset.

I also added a section about where the releases can be found in the Github pages.