Package Details: lastpass

Git Clone URL: (read-only, click to copy)
Package Base: lastpass
Description: The Universal LastPass installer for Firefox, Chrome, and Opera
Upstream URL:
Licenses: custom
Submitter: Det
Maintainer: darose
Last Packager: darose
Votes: 94
Popularity: 0.000000
First Submitted: 2013-06-02 17:50 (UTC)
Last Updated: 2024-01-04 01:14 (UTC)

Latest Comments

1 2 3 4 5 6 .. 23 Next › Last »

darose commented on 2022-02-17 21:24 (UTC)

Alright I've experimentally adopted this package. I may have to drop it if it becomes too hard to maintain. I upgraded to v4.88.0.1. It looks working in both FF and Chromium, but LMK if anyone sees any issues.

darose commented on 2022-02-17 19:27 (UTC)

Oh wow. I've been using it without any issue for so long that I hadn't even realized that. If no one else wants to adopt it I can take a look and see if it's not too complicated to maintain.

duhbLow7 commented on 2022-02-17 18:22 (UTC)

This package is unmaintained and quite outdated.

eschwartz commented on 2020-09-09 00:31 (UTC) (edited on 2020-09-09 00:33 (UTC) by eschwartz)

Nice diff there for

-wget -O lpchrome_linux.crx ""
+wget -O lpchrome_linux.crx ",crx3&x=id%3Dhdokiejnpimakedhajhdlcegeplioahd%26uc"

What a waste of time this bump is. Grrr.

This file isn't even used by the package. I'm fixing this without bumping pkgrel, users who successfully built it in the past are unaffected.

daniel_shub commented on 2020-09-08 23:59 (UTC)

I am getting a build error for with makepkg in a clean chroot. The sha256 checksum of the lplinux-4.1.59.tar.bz2 file that gets downloaded (826e383a6bad905d942e22b14aee67dbc39e8f7a5243d706af787c8fcec6f158) does not match the checksum in the PKGBUILD. Looking at the downloaded lplinux-4.1.59.tar.bz2 file, while the version number has not changed with the updated lastpass/PKGBUILD, the tarball now contains a file with a date of 2020-08-31, which makes me think they may have changed something behind the scenes without incrementing the version number.

Det commented on 2019-07-11 11:51 (UTC)

He responses in complaining manners, but he's right.

eschwartz commented on 2019-04-03 17:17 (UTC) (edited on 2019-04-03 17:19 (UTC) by eschwartz)

No, it really isn't bad practice. It is bad practice to fail hard because you have a tightly interwoven dependency on makepkg internals (and the format that is absolutely, positively, guaranteedly documented, since I wrote the documentation). Given I have actually discussed this with one of the lead developers of yay, and my advice to not be vulnerable to breaking for any reason, was accepted, I consider myself justified in adding this.

I did not break yay. I discovered that yay was already broken. I also guaranteed that yay-git now supports upcoming versions of pacman.

Furthermore, the official policy of the AUR is that if an AUR helper does not work, you should use makepkg directly, and if makepkg itself does work, then the problem is automatically with the AUR helper and only the AUR helper.

I am not changing this, and it is not open for debate.

gromain commented on 2019-04-03 17:00 (UTC)

I think that adding an unreleased and undocumented feature to something is bad practice too, since it breaks tools that could not have been informed of coming changes.

thayne commented on 2019-04-01 06:49 (UTC)

Is b2sums supported by makepkg? I can't find any documentation on it.