Package Details: light 1.2.2-5

Git Clone URL: https://aur.archlinux.org/light.git (read-only, click to copy)
Package Base: light
Description: A program to control backlights (and other hardware lights)
Upstream URL: https://gitlab.com/dpeukert/light
Keywords: backlight backlights brightness cli control light lights program
Licenses: GPL-3.0-only
Submitter: maximbaz
Maintainer: dpeukert
Last Packager: dpeukert
Votes: 10
Popularity: 2.82
First Submitted: 2024-01-04 20:04 (UTC)
Last Updated: 2024-02-29 13:33 (UTC)

Pinned Comments

dpeukert commented on 2024-01-22 22:51 (UTC)

The PKGBUILD for this package is hosted here (contributions are welcome!): https://gitlab.com/dpeukert/pkgbuilds/tree/main/light

Latest Comments

1 2 3 Next › Last »

dpeukert commented on 2024-02-29 13:33 (UTC)

@Tblue, @guzzisti, @Zatharalex, @peter.kehl, @sidicer: Should be fixed now.

dpeukert commented on 2024-02-29 13:28 (UTC)

@sidicer: Thanks, that makes sense, I forgot that I don't have pkgrel in the source filename. I'll change the name to make sure the cache gets invalidated.

Regarding the checksums being different, that makes sense IMHO, as GitHub and GitLab presumably use different archival/compression settings for their source archives.

sidicer commented on 2024-02-29 12:29 (UTC) (edited on 2024-02-29 12:35 (UTC) by sidicer)

As the package/commit version has not changed - those who have already had light 1.2.2-5 installed will have this makepkg fail due to sha512sum not matching what they have cached :) It's strange that your sha512sum of light-1.2.2.tar.gz differs from the previous one if you have not changed it and just forked it.

The original hash of the original light-1.2.2.tar.gz is 5815394fb1545d1e06234c261d475e1836e4c43e47e7707b8628891d20b70db04f1661b78ca1d236d549c734430b606498fa46de060c854791b13cf49de07b59 light-1.2.2.tar.gz

haikarainen commented on 2024-02-27 16:19 (UTC)

@Tblue It's not counterproductive at all, I've been looking for maintainers for this software for years, its been officially orphaned for a full year, nobody has shown interest yet still I receive all kinds of emails about it demanding things. I don't care for this piece of software at all quite frankly I'm fed up with the open source community.

Thus, nuking it went precisely as planned for me. I understand that it makes reality a bit tougher for others though, but that's where they can pick up the slack, fork it, or write their own replacement.

Best,

StackDoubleFlow commented on 2024-02-26 04:06 (UTC)

@dpeukert: For me, attempting to install the package through an aur helper (yay) would result in a checksum error, but manually cloning and building the package was successful.

I have both variations of the source archive here: https://drive.google.com/drive/folders/1oWvIDb4f_RoRQcqh2l0DMDoUMSRauCDg?usp=sharing

dpeukert commented on 2024-02-24 11:11 (UTC)

@Tblue, @guzzisti, @Zatharalex, @peter.kehl: I wasn't able to replicate this so far, do any of you have the archive that caused the integrity check to fail on hand? I'd like to see how the files actually differ and if that might point me in the right direction.

dpeukert commented on 2024-02-23 15:27 (UTC)

@Tblue: I could apply them, but I wanted to keep the repo strictly as a mirror of the last release. It wouldn't really help with the checksum issue. Regarding a release, that might help, it depends on if GitLab has an issue with archive checksums globally or just for commit archives. I'll see what I can figure out.

Tblue commented on 2024-02-23 15:18 (UTC) (edited on 2024-02-23 15:19 (UTC) by Tblue)

@dpeukert: Interesting.

Couldn't you just apply the patches directly to the repo, and then clone it? Or create a release on GitLab, and use the archive of that.

dpeukert commented on 2024-02-23 15:14 (UTC)

@Tblue: The patch files haven't changed, they are the exact same files as before. It looks like GitLab doesn't have stable archive checksums for some reason, I'll take a look at that tonight.

Tblue commented on 2024-02-23 15:10 (UTC) (edited on 2024-02-23 15:11 (UTC) by Tblue)

I'm guessing the issue is that the contents of the files changed with the move to the new repo (i.e. not the actual code, but the other metadata in the files).

Deleting the files locally should fix it. From the PKGBUILD side, one could include the version number in the file names, although the checksum issue is probably a one-time problem.

1 2 3 Next › Last »