Dark Dragon (02fa6e40) at 21 Mar 18:05
Yes, it can be merged. Thanks!
I agree that it would be good if the schema check would succeed on the main branch. While one could change the typo from category to string, I think it makes sense to only allow a finite set of options for things which become a category in Zola to avoid having multiple different spellings for the same thing.
Dark Dragon (02fa6e40) at 20 Mar 20:14
Fix summary source URL validator after upstream fix has been released
... and 490 more commits
I would propose to change this print statement to stdout
as this is not an error one would want to fix in my opinion, so it is just an information.
This comes in handy for me as I can now redirect stdout
to separate the errors from the informative print statements:
python ./checkers/check_via_appstream.py check ./content/apps 2>&1 >/dev/null
In the future this might also allow to e.g. let a pipeline fail if there are errors, but not make it fail if there are only print statements to
stdout
to inform about certain circumstances.
I think a return code is much better suited to decide if a pipeline should fail (this is already how it is handled at the moment).
stdout
is the default, please just remove the argument for consistency reasons:
print(f'{item_name}: Ignoring autotools template variable for {property["apps_key"]}: {found_entry}')
Maybe add the link to the last section including a sentence that people should let us know about any ideas they have, additional efforts they know about and things they are doing themselves to drive this forward.
Dark Dragon (0f2c0cce) at 17 Mar 17:18
Thanks for fixing my typos!
If you have another idea for a better end, I am open for suggestions. I definitely want to finish the post with a call to action (this was the main motivation to write it in the first place). On the other hand, I follow this topic since many years and really don't know what could be done (other than building everything myself and even then it would probably have a low chance for adoption). Therefore, I would like to encourage people to think/brainstorm for themselves what could be done. My goal would be that this topic gains priority and awareness with developers all around the stack.
I think the (automated?) post on Mastodon is good enough for a discussion.
Thanks for suggesting this guest post. Any feedback welcome before publishing!
Dark Dragon (56a0c7ea) at 17 Mar 16:00
Add post about push notifications
Dark Dragon (31e576e9) at 17 Mar 16:00
content/2024-03-17-mfc03-overdue-failures: fix image
... and 277 more commits
PS: To fix it everywhere, we would also need a checker, that points out flawed/underspecific metadata
😜
This is actually quite easy with a schema checker. Defining what flawed/underspecific means is the harder part
I think a lot of initial AppStream files are just copied from existing ones. As in the LPA domain many apps are newly created the problem will just increase when one doesn't fix the existing ones. Every fix of an existing app makes it less probable that some discouraged one is copied for a new app. And one doesn't need to maintain downstream workarounds. Both these these benefits are independent from upstream improving their metadata on their own.
I am still not experienced with branch juggling
Not having the (mental/social/personal) capacity to deal with upstream right now
One needs less capacity in the long run for upstreaming as this is a one-off task while maintaining downstream fixes is a continuous one
I suggest using MRs for changes as this allows to notice problems before they occur. I also do this for projects where I am the only person working on as this makes sure main
is always clean and does not require me to do any hot fixes at any time. Instead I can just stop working at any time and continue where I left of with an always working main
state.
Having said that, I suggest doing what the test does. When the app_id
contains a .desktop
we should also use .desktop
for the filename (one can still manually introduce an alias). If this doesn't seem intended, send an upstream PR to change the app_id or otherwise introduce the launchable property for apps still using the legacy app_id (new apps really shouldn't do this and it is probably a copy&paste error and should be fixed).
Based on my interaction with the repology maintainer (as mentioned here), repology did not show any interest in accepting changes to make life easier for projects like LPA. That's why I didn't want to add it in the first place. I do not want to waste the time of my life fighting to integrate some service which does not want to be integrated. I suggest removing it. Otherwise, you are on your own with this, sorry.
My first guess would be that the corresponding XML files do not contain the <launchable>
property. This is required to automatically determine if the .desktop
is really unwanted (see code) as for some apps, the .desktop
is obligatory and it would be a failure to remove it (for example chat.schildi.desktop
as IDs also need to contain at least 2 dots and 3 parts).
What is the corresponding merge request for the failed job?