| 3 Apr 2025 |
 zitrone | r-ryantm was able to update my package https://nixpkgs-update-logs.nix-community.org/wl-gammarelay-rs/2025-04-03.log
but it didn't open a pr for it | 13:00:04 |
| 5 Apr 2025 |
|  zexu joined the room. | 13:09:08 |
| 11 Apr 2025 |
|  @ambroisie:belanyi.fr left the room. | 22:08:49 |
| 13 Apr 2025 |
|  Bot_wxt1221 joined the room. | 13:32:29 |
| 15 Apr 2025 |
|  Indrek joined the room. | 11:55:07 |
| Indrek | This is an interesting failure, seems to perform the update sucessfully but unable to commit the result after https://nixpkgs-update-logs.nix-community.org/bitwarden-desktop/2025-04-15.log
also found another one at https://nixpkgs-update-logs.nix-community.org/tabnine/2025-04-10.log | 13:22:39 |
 Sandro 🐧 | No auto update branch exists
Successfully finished processing
Received ExitFailure 1 when running
Raw command: git commit -am "bitwarden-desktop: 2025.2.0 -> 2025.3.1"
Standard output:
On branch auto-update/bitwarden-desktop
nothing to commit, working tree clean
| 15:03:08 |
 Perchun Pak [don't ping; dm instead] | this is probably because the update script commits changes and r-ryantm tries to create a second commit
https://github.com/NixOS/nixpkgs/blob/2631b0b7abcea6e640ce31cd78ea58910d31e650/pkgs/by-name/bi/bitwarden-desktop/package.nix#L225
https://github.com/NixOS/nixpkgs/blob/2631b0b7abcea6e640ce31cd78ea58910d31e650/pkgs/by-name/ta/tabnine/update.sh#L46 | 17:57:02 |
| Indrek | Yeah, that's most likely it. I'm pretty new to all things nix so it's difficult to say if this is a nixpkgs issue or nixpkgs-update issue.
I guess the automation could soft reset the git state back to what it started with and then perform a commit of its own, but this sounds a little hacky. On the other hand nixpkgs could simply state that update scripts should not be allowed to perform git operations on the repository by default and then things would just work on r-ryantm side. There's probably other solutions may exist as well, but this is just to illustrate my point that it's not clear to me what's the next step from here. | 21:45:10 |
| 19 Apr 2025 |
|  jopejoe1 changed their display name from jopejoe1 to jopejoe1 (4094@eh22). | 12:59:35 |
| 21 Apr 2025 |
|  Grimmauld (any/all) joined the room. | 10:54:13 |
| 22 Apr 2025 |
|  Thomas joined the room. | 17:31:10 |
| 1 May 2025 |
|  Rosuavio changed their display name from Rosario Pulella to Rosuavio. | 20:09:22 |
|  mnaser joined the room. | 21:41:43 |
| mnaser | I'm struggling to understand why the following package did not get bumped:
https://nixpkgs-update-logs.nix-community.org/python312Packages.python-aodhclient/2025-04-30.log
In my case here, there is no updateScript as it claims to say there is one:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/python-aodhclient/default.nix
Also, there is totally a newer tag (for quite sometime):
https://github.com/openstack/python-aodhclient/tags
Does the buildPythonApplication come with its own updater? | 21:44:11 |
| mnaser | Sorry, future lore for those who want to figure it out:
nix-update python3Packages.python-aodhclient
It shows that somehow the next version from 3.6.0 is yoga-eol (openstack tags repos with a eol tag) and I assume it things that's the latest :) | 21:48:01 |
| 2 May 2025 |
| Sandro 🐧 | buildPythonPackage has a default update script | 01:55:18 |
| Sandro 🐧 | yeah, that is probably also a mirror | 02:13:23 |
| 8 May 2025 |
|  samasaur joined the room. | 03:24:24 |
| 13 May 2025 |
| Perchun Pak [don't ping; dm instead] | How do I point out that derivation itself is a source?
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/astal/source.nix
https://nixpkgs-update-logs.nix-community.org/astal.source/2025-05-13.log | 12:22:51 |
 FliegendeWurst (@GPN23) | passthru.src = final; maybe | 13:53:40 |
| FliegendeWurst (@GPN23) | though the setup seems a bit odd to me anyway | 13:53:53 |
| FliegendeWurst (@GPN23) | why not just have the updateScript in one of the normal packages? | 13:54:34 |
| 14 May 2025 |
| Perchun Pak [don't ping; dm instead] | In reply to @fliegendewurst:matrix.org
why not just have the updateScript in one of the normal packages? So update bot would have a better name for PR | 11:38:55 |
| 18 May 2025 |
| Grimmauld (any/all) | Okay, i give up-
Following package:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/sd/SDL_ttf/package.nix
We currently set the version "2.0.11.1-unstable-2024-04-23.
Upstream only has a tag for 2.0.11. They won't be tagging any more old versions for SDL_ttf for SDL1. But, canonically, we are on 2.0.11.1: https://github.com/libsdl-org/SDL_ttf/commit/e31d11a692e5b55e8e624ad766e4e44d655422c8
Currently, running the update script on SDL_ttf just crashes, because the 2.0.11.1 tag does not exist. But removing the .1 isn't entirely correct either. What is the best way to make the update script succeed and still correctly represent the version? | 21:17:46 |
| FliegendeWurst (@GPN23) | Removing the ".1" seems correct to me, we use the last released version in the unstable naming scheme. | 21:21:51 |
| FliegendeWurst (@GPN23) | And 2.0.11 is the last released version | 21:21:58 |
| Grimmauld (any/all) | pbsds said 2.0.11.1 was the actual version, but dropping the .1 would have been my solution too. It is common for release notes entries to be prepared before the tag (and edited later!). And https://repology.org/docs/requirements also explicitly says to do -post of tagged too:
Obviously, no fake versions, e.g. versions which were not officially released by upstream. Note that a mere mention of "next" version by upstream (in changelog or build system script) does not make it official. A git tag or a release announcement does.
| 21:23:36 |
 pbsds | just checked with repology, no one else cares about the .1 | 21:24:03 |
| Grimmauld (any/all) | As in:
- we can do whatever
- we should keep it
- we should drop it
- not required
- ???
| 21:25:29 |
