• 2 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle




  • Bumping package versions usually isn’t hard. Here, I’ll do this one out loud here, & maybe you can do it next time you need to:

    1. Search https://github.com/NixOS/nixpkgs/pulls to see if someone else already has a PR open for a version bump for this package.
    2. Clone the nixpkgs repo if you haven’t already: git clone https://github.com/NixOS/nixpkgs.git ~/devel/nixpkgs (or git pull if you have).
    3. Create a branch for this bump: git checkout -b stremio
    4. Find stremio: find pkgs -name stremio
    5. Edit it: $EDITOR pkgs/applications/video/stremio/default.nix Looks like nixpkgs has version 4.4.142. If I go to https://www.stremio.com/ (link in meta.homepage in this file) and click ‘Download’, it all says 4.4, which is not helpful. The ‘source code’ link goes to github, and the ‘tags’ link there lists version v4.4.164, which is what we’re looking for.
    6. In my editor, I change the version: 4.4.1424.4.164.
    7. In my editor, I mess up both the hashes: I just add a block of zeros somewhere in the middle: sha256-OyuTFmEIC8PH4PDzTMn8ibLUAzJoPA/fTILee0xpgQI=sha256-OyuTFmEIC80000000000000000000A/fTILee0xpgQI=.
    8. Leaving my editor, I build the updated package: nix-build . -A stremio
    9. It fails, because the hashes are wrong, obviously. But it tells me what hash it got, which I copy/paste back in, in the spirit of collective TOFU. I do this twice, once for each hash.
    10. It builds successfully. I test the result: ./result/bin/stremio. Looks like it works enough to prompt me to log in, at least. I don’t know what stremio is or have an account, but it’s probably fine.
    11. I commit my change: git commit -a -m 'stremio: 4.4.142 -> 4.4.164'
    12. I push my commit: git push github (If this is your first time, create a fork of nixpkgs in the github web UI & git remote add a remote for it first)
    13. I create PR in the github web UI: https://github.com/NixOS/nixpkgs/pull/263387



  • Thanks for the lead!

    It looks like the Buddy Read feature does in fact start with a specific book and organize a group around it, but it invites me to specify all the people that will ever be in the group right away, at group creation time. I get three ways to invite people:

    • “Machine-learning powered reading buddy recommendations” - Unspecified voodoo. Three users are shown.
    • “Community members who have this book on their radar” - Probably folks that have this on their public ‘to read’ list. Three users are shown.
    • Specifying users directly by username

    This doesn’t quite fit the “I’m up for this, let me know when it starts” mechanic.

    I could create a new group & invite all three of the users with this book in their public ‘to read’ list, but I think folks treat the the ‘to read’ list very, very casually – not at the “I’m ready to commit to a reading group” level. These three users have 723, 2749, and 3771 books on their ‘to read’ lists respectively. I see that I somehow have have 46 books on mine, & haven’t been thinking of it as a ‘ready to commit to reading group’ list.




  • chkno@lemmy.mltoLinux@lemmy.mlWayland or X11? Why?
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    1 year ago

    X11 for xdotool. ydotool doesn’t support (& can’t really support with it’s current architecture) retrieving information like the current mouse location, current window, window dimensions & titles. Also, normal (unprivileged) user ydotool use requires udev rules or session scripts and/or running a ydotool daemon & many distros don’t yet ship with this Just Working.

    X11 for Alt-F2 r to restart Gnome Shell without ending the whole session. This is a useful workaround for a variety of Gnome bugs.




  • I ran Gentoo for ~15 years and then switched to NixOS ~3 years ago. The last straw was Gentoo bug 676264, where I submitted version bump & build fix patches to fix security issues and was ignored for three months.

    In Gentoo, glsa-check only tells you about security vulnerabilities after there’s a portage update that would resolve it. I.e., for those three months, all Gentoo users had a ghostscript with widely-known vulnerabilities and glsa-check was silent about it. I’m not cherry-picking this example—this was one of my first attempts to help be proactive about security updates & found that the process is not fit for purpose. And most fixed vulnerabilities don’t even get GLSA advisories—the advisories have to be created manually. Awhile back, I had made a ‘gentle update’ script that just updated packages glsa-check complained about. It turns out that’s not very useful.

    Contrast this with vulnix, a tool in Nix/NixOS which directly fetches the vulnerability database from nvd.nist.gov (with appropriate polite local caching) and directly checks locally installed software against it. You don’t need the Nix project to do anything for this to Just Work; it’s always comprehensive. I made a NixOS upgrade script that uses vulnix to show me a diff of security issues as it does a channel update. Example output:

    commit ...
    Author: <me>
    Date:   Sat Jun 17 2023
    
        New pins for security fixes
    
        -9.8    CVE-2023-34152  imagemagick
        -7.8    CVE-2023-34153  imagemagick
        -7.5    CVE-2023-32067  c-ares
        -7.5    CVE-2023-28319  curl
        -7.5    CVE-2023-2650   openssl
        -7.5    CVE-2023-2617   opencv
        -7.5    CVE-2023-0464   openssl
        -6.5    CVE-2023-31147  c-ares
        -6.5    CVE-2023-31124  c-ares
        -6.5    CVE-2023-1972   binutils
        -6.4    CVE-2023-31130  c-ares
        -5.9    CVE-2023-32570  dav1d
        -5.9    CVE-2023-28321  curl
        -5.9    CVE-2023-28320  curl
        -5.9    CVE-2023-1255   openssl
        -5.5    CVE-2023-34151  imagemagick
        -5.5    CVE-2023-32324  cups
        -5.3    CVE-2023-0466   openssl
        -5.3    CVE-2023-0465   openssl
        -3.7    CVE-2023-28322  curl
    
    diff --git a/channels b/channels
    --- a/channels
    +++ b/channels
    @@ -8,23 +8,23 @@ [nixos]
     git_repo = https://github.com/NixOS/nixpkgs.git
     git_ref = release-23.05
    -git_revision = 3a70dd92993182f8e514700ccf5b1ae9fc8a3b8d
    -release_name = nixos-23.05.419.3a70dd92993
    -tarball_url = https://releases.nixos.org/nixos/23.05/nixos-23.05.419.3a70dd92993/nixexprs.tar.xz
    -tarball_sha256 = 1e3a214cb6b0a221b3fc0f0315bc5fcc981e69fec9cd5d8a9db847c2fae27907
    +git_revision = c7ff1b9b95620ce8728c0d7bd501c458e6da9e04
    +release_name = nixos-23.05.1092.c7ff1b9b956
    +tarball_url = https://releases.nixos.org/nixos/23.05/nixos-23.05.1092.c7ff1b9b956/nixexprs.tar.xz
    +tarball_sha256 = 8b32a316eb08c567aa93b6b0e1622b1cc29504bc068e5b1c3af8a9b81dafcd12
    



    1. Paper tokens: Produce 100 billion authentication tokens (could be passwords, could be private keys of signed certificates), print them on thick paper, fold them up, publicly stir them in giant vats at their central manufacturing location before distributing them to show that no record is being kept of where each token is being geographically routed to, and then have them freely available in giant buckets at any establishment that already does age-checks for any other reason (bars, grocery stores that sell alcohol or tobacco, etc.). The customer does the usual age-verification ritual, then reaches into the bucket and themselves randomly selects any reasonable number of paper tokens to take with them. It should be obvious to all parties that no record is being kept of which human took which token.

    2. Require these tokens to be used for something besides mature-content access. Maybe for filing your taxes, opening bank accounts, voting, or online alcohol / tobacco purchases. This way, people requesting these tokens do not divulge that they are mature-content consumers.