| 12 Apr 2025 |
 emily | for libpinyin,
libpinyin X GPLv3+ depends on KyotoCabinet since f24 | 21:41:20 |
| emily | though I'm not sure if Kyoto Cabinet is maintained either 😆 | 21:42:12 |
| emily | ah, https://dbmx.net/kyotocabinet/ points to https://dbmx.net/tkrzw/. | 21:42:35 |
| emily | but https://github.com/libpinyin/libpinyin/blob/a6f4d3c239883b5e1dd0770ab2b433042845e9c9/configure.ac hardcodes only support for Berkeley DB and Kyoto Cabinet. | 21:43:04 |
| emily | the latest Kyoto Cabinet is still like three years newer than the latest Berkeley DB, and there's a good chance it doesn't have this specific reproducibility bug, so… it may be a good option for libpinyin :) | 21:46:43 |
| 13 Apr 2025 |
|  Bot_wxt1221 joined the room. | 13:32:05 |
 guider-le-recit | Hi miss Emily, you are aboslutely correct, I edited the package.nix file, removed Berkeley DB from buildInputs and replaced it with kyotocabinet, added a list configureFlags = [ "--with-dbm=KyotoCabinet" ];, and now the build completes no more derivation errors | 13:32:30 |
| guider-le-recit | * Hi miss Emily, you are aboslutely correct, I edited the package.nix file, removed Berkeley DB from buildInputs and replaced it with kyotocabinet, added a list configureFlags = [ "--with-dbm=KyotoCabinet" ];, and now the build completes with no more derivation errors | 13:32:51 |
| guider-le-recit | Thank you | 13:33:13 |
| emily | nice! | 13:33:45 |
| guider-le-recit | I'm gonna make the github issue now and send the link so you can push your solution | 13:33:55 |
| emily | solving Berkeley DB reproducibility issues would still be valuable in general though, since it's likely there's software that doesn't support anything else :) | 13:34:18 |
| emily | I know Debian and Fedora have been working on getting rid of it for years, but I don't know if they've fully achieved that | 13:35:08 |
| emily | documenting your great deep dive into the internals will definitely be valuable | 13:36:17 |
| guider-le-recit | Are you aware of any links that i can read up on that? | 13:37:21 |
| guider-le-recit | okay | 13:37:28 |
| emily | https://fedoraproject.org/wiki/User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora is an old table from Fedora and https://lists.debian.org/debian-devel/2014/06/msg00338.html is an email from a decade-old mailing list thread in Debian talking about alternatives like LMDB | 13:39:34 |
| emily | Debian still has a BDB package to this day though: https://packages.debian.org/source/sid/db5.3 | 13:39:39 |
| emily | so I assume they didn't completely get rid of it :) | 13:40:24 |
| guider-le-recit | How did you get that so fast? | 13:40:44 |
| emily | ah, here's a more detailed Fedora change proposal: https://fedoraproject.org/wiki/Changes/Libdb_deprecated (but they still have the package too) | 13:40:54 |
| emily | well, I found the Fedora thing yesterday, and the Debian link from https://en.wikipedia.org/wiki/Berkeley_DB ("By 2013 there were many alternatives to BDB, and Debian Linux was typical in their decision to completely phase out Berkeley DB, with a preference for the Lightning Memory-Mapped Database (LMDB).[26]") just now when checking if there might be an active fork/API-compatible replacement we could switch to 😆 | 13:42:01 |
| emily | so more like I already had them in tabs/browser history | 13:42:01 |
| guider-le-recit | This is great | 13:43:20 |
| guider-le-recit | Thank you once more | 13:43:32 |
| emily | thank you for digging into this! | 13:44:10 |
| emily | moving packages off Berkeley DB to a more maintained database library where possible will be great for both reproducibility and performance/security/etc., and if we can get the reproducibility issue in BDB itself fixed even better :) | 13:44:47 |
| guider-le-recit | https://github.com/NixOS/nixpkgs/issues/398375 | 14:00:48 |
| guider-le-recit | i wanted to comment your solution but wasnt sure if your username on github is emilazy or something else | 14:01:56 |
| emily | yep, @emilazy | 14:07:09 |
