we're getting bit by this in our composes. See commentary here. Can we get the priority of this heightened?

We have this ticket already planned for the current sprint. But how urgent it is? New Pungi release is not planned yet and it was supposed it will be released around the middle of March because no priority issues were there so far.

It's urgent in that it prevents us from getting any Atomic Workstation ISOs built, because their volume IDs wind up over the 32 character limit and so the build fails.

We could possibly work around this in the config by changing the Workstation substitution to Workstation-, though? Until it's fixed in Pungi.

Otherwise we can patch it downstream in Pungi, I guess.

@mclasen for info: this is why Atomic Workstation ISOs are failing in Rawhide.

possibly temporary workaround in https://pagure.io/pungi-fedora/pull-request/525#

Commit caed78e relates to this ticket

I don't think that worked. Python's default sort of a list of 2-tuples is not by the length of one of the components of the tuple, after all. The default sort in this case is in fact alphabetical in some way (I'm guessing it takes the first value in each tuple and sorts alphabetically) -

>>> dic = {'cc': 'cc', 'bbbb': 'bbbb', 'aaa': 'aaa'}
>>> sorted(dic.items())
[('aaa', 'aaa'), ('bbbb', 'bbbb'), ('cc', 'cc')]

Yeah, that's exactly what it does:

>>> dic = {'cc': 'xx', 'bbbb': 'yyyy', 'aaa': 'zz'}
>>> sorted(dic.items())
[('aaa', 'zz'), ('bbbb', 'yyyy'), ('cc', 'xx')]

Your code just happens to work for this case because WorkstationOstree sorts alphabetically after Workstation, and you reverse the sort order. But that doesn't make much actual logical sense as a way to do the sorting.

https://pagure.io/pungi/pull-request/857

should this be closed now?

+1 to close...