• 0 Posts
  • 73 Comments
Joined 4 years ago
cake
Cake day: June 24th, 2020

help-circle





  • I’ve had those errors on my system for years. I never thought that they were NixOS specific. I just assumed something to do with a buggy firmware:

    Enabled 4 GPEs in block 00 to 1F
    ACPI Error: Aborting method \_SB.PCI0.GPP2.PTXH.RHUB.POT3._PLD due to previous error (AE_AML_UNINITIALIZED_ELEMENT) (20240322/psparse-529)
    [x~20]
    ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
    

    I don’t notice any ill-effects from them, so it may be a red herring. I have a:

    $ < /sys/devices/virtual/dmi/id/board_name
    ROG STRIX B450-F GAMING
    

    with a 5900X.

    I don’t usually see as many prints as you have there, but it’s quite a few, and the number seems to vary (grow?) over time. I keep meaning to investigate it, but haven’t got around to it.

    I think you should keep looking in your logs for other problems. If you can share the full log I’d be happy to take a look.




  • Something which notifies you whenever a new comment or reply is made to a selected post/comment, so that you can keep track of any new conversation.

    Something like this would be awesome as a core Lemmy feature IMO. It would essentially turn a post (or maybe any comment tree?) into a matrix style room. Lemmy is actually decent for long term discussion (e.g. helping someone with a problem), but not if there are more than two people involved.









  • Many of the files have been created by hand with a hex editor, thus there is no better “source code” than the files themselves.

    I don’t buy that. There would have been some rationale behind the contents that could be automated, like “compressed file with bytes 3-7 in the header zeroed”.

    You also probably don’t need these test files to be available in the environment where the library itself is built. There are various ways you could avoid that.

    I do agree about the autotools stuff though.

    Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer’s computer.

    This seems avoidable. We shouldn’t be copying code around like that.




  • All of this would be avoided if Debian downloaded from GitHub’s distributions of the source code, albeit unsigned.

    In that case they would have just put it in the repo, and I’m not convinced anyone would have caught it. They may have obfuscated it slightly more.

    It’s totally reasonable to trust a tarball signed by the maintainer, but there probably needs to be more scrutiny when a package changes hands like this one did.