Package Details: ly 0.5.3-0

Git Clone URL: (read-only, click to copy)
Package Base: ly
Description: TUI display manager
Upstream URL:
Licenses: custom:WTFPL
Conflicts: ly-git, python-ly-git
Submitter: nullgemm
Maintainer: nullgemm
Last Packager: nullgemm
Votes: 38
Popularity: 2.29
First Submitted: 2018-09-23 19:46 (UTC)
Last Updated: 2021-10-07 15:26 (UTC)

Latest Comments

antoniovazquez commented on 2022-06-11 11:34 (UTC)

Why does this package depend on xorg-xauth?

I have manually edited the PKGBUILD to not include this dep and gladly report that it compiles and flawlessly runs without any issue.

It would be nice to be able to avoid X deps if not being in use. Maybe moving this package to optional deps?

Also, ly-git should not be in the conflicts section.


thiagowfx commented on 2022-02-12 16:07 (UTC) (edited on 2022-02-12 16:08 (UTC) by thiagowfx)

FYI: There's no need to add conflicts with the -git package.

The ly-git package should add a conflicts with ly, but ly doesn't need to add a conflicts with ly-git.

languitar commented on 2021-10-09 15:30 (UTC)

Could you mark /etc/ly/ and /etc/ly/ as backup files in the PKGBUILD? They provide an easy point of modification for the environment and currently contained changes are removed on every update of this package.

nullgemm commented on 2021-10-07 15:18 (UTC)

@Sapiens Right... Should be fine now...

Sapiens commented on 2021-10-07 14:30 (UTC)

@nullgemm it seems you need to also modify the PKGBUILD, it does not build yet

nullgemm commented on 2021-10-07 14:08 (UTC)

@Sapiens @jojoto147 I just pushed a few emergency commits to fix this. Sorry for the inconvenience, I forgot Ly relied on this piece of shit.

jojoto147 commented on 2021-10-07 13:04 (UTC)

nullgemm/ctypes has been removed from but is still available on the nullgemm Gitea

Sapiens commented on 2021-10-07 12:13 (UTC) (edited on 2021-10-07 12:19 (UTC) by Sapiens)

    -> Cloning ctypes git repo...
    Cloning into bare repository '/home/sapiens/.cache/yay/ly/ctypes'...
    Username for '':

I am getting asked for github credentials for the ctypes repository.

dreieck commented on 2021-04-24 19:22 (UTC)

It should conflict with python-ly (which is a completely unrelated package from the community repository):

error: failed to commit transaction (conflicting files)
python-ly: /usr/bin/ly exists in filesystem (owned by ly)
Errors occurred, no packages were upgraded.

Please add a corresponding conflicts=-statement.

Thanks for maintaining!

yonson commented on 2021-02-16 15:59 (UTC) (edited on 2021-02-16 16:01 (UTC) by yonson)

Would it be reasonable to add "/etc/pam.d/ly" as a backup file?

I make changes to "/etc/pam.d/ly" in order to incorporate pam_ssh configurations. These changes are blown away on package updates, which I believe is because the file isn't marked as backup.

I realize this use case is pretty specific and I do not know AUR pkgbuild best practices.

macxcool commented on 2020-08-25 22:52 (UTC)

/usr/bin/ly conflicts with python-ly that's in the Community repo. Is there anything that can be done about that?

Cristophero commented on 2020-04-25 07:39 (UTC)

Muchas gracias!

commented on 2020-04-21 11:16 (UTC)

@J5lx ah ok thanks for the clarifying

J5lx commented on 2020-04-21 11:13 (UTC)

No, this is not the same. The way I did it, git will automatically use the correct version of each submodule according to the gitlink stored in the object database. If you use mv, it will instead use the HEAD of each submodule, which, in a package for a specific release, is highly undesirable because it means that the same PKGBUILD can potentially yield different build results depending on when it is built. Also, there’s always the chance that breaking changes get introduced in one of the submodules, in which case your solution would result in a build failure, but mine wouldn’t.

commented on 2020-04-21 01:54 (UTC)

To base on J5lx's PKGBUILD instead of using git submodule can also just do:


    cd "$srcdir/$pkgname"

for _i in argoat configator ctypes dragonfail termbox_next; do

    mv "$srcdir/$_i" sub/



J5lx commented on 2020-04-21 00:50 (UTC)

Oh, there’s one other thing I just forgot about: ly’s default PATH is actually not well-suited to Arch. It breaks Netbeans for example, see FS#60533. It would probably a good idea to adapt the configuration file accordingly in the PKGBUILD. Personally I’m currently using an empty default path in config.ini and leave the PATH entirely to /etc/profile.

J5lx commented on 2020-04-21 00:31 (UTC) (edited on 2020-04-21 00:32 (UTC) by J5lx)

cygolm: I just cought up with the latest comments, maybe I can clarify some things. First of all, there’s no need for a merge, a rename or anything like that. After all, it is only a change to the packaging procedure, from a user perspective it shouldn’t make any difference. You can simply reupload the current version of this package as ly-bin (if you like) and switch this package over to building from source.

ly-git should continue to be a separate package. As per VCS package guidelines: “Suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. unless the package fetches a specific release.” (emphasis is mine). This means that the difference between -git and non-git packages is that -git packages are generally built from git HEAD. In other words, git packages are based on the very latest, bleeding edge, potentially unstable development code, whereas non-git packages are generally built from the sources of the latest stable release. In particular, it’s perfectly fine for non-git packages to retrieve their sources via git as long as it’s a specific release.

Also, here’s an improved version of ndowens04’s PKGBUILD for Arch Linux: Compared to the original version, I’ve moved the submodules to sources (As per package guidelines) since it is generally considered bad practice to download stuff manually during the build. Also note how ly is cloned via git, but the exact version is specified via #tag=${pkgver}. I’ve also added backup to prevent pacman from silently overwriting configuration files and removed the executable bit from files that should not have it (see atmouse’s comment).

I realise this is a quite a bit to digest, so if you have any questions feel free to ask :)

Edit: wording + formatting

commented on 2020-04-19 07:25 (UTC)

Here is a way to do source version, just added it in Artix Linux

nullgemm commented on 2020-02-28 18:52 (UTC)

@qubidt You're right, I didn't notice there was a sneaky AUR-specific version of the "Arch submission guidelines" page on the Wiki... They should me merged IMHO.

Anyway, I'm not sure how to handle this now. Won't requesting a package merge with a hypothetical ly-bin break everyone's setup? If my understanding is right, "ly-git" should also be renamed to "ly", so this is going to be a huge mess...

qubidt commented on 2020-02-19 19:10 (UTC)


J5lx has a point. This should be ly-bin

atmouse commented on 2019-11-07 01:28 (UTC)

systemd[1]: Configuration file /usr/lib/systemd/system/ly.service is marked executable. Please remove executable permission bits. Proceeding anyway.

nullgemm commented on 2019-09-14 19:26 (UTC)


J5lx commented on 2019-09-11 18:02 (UTC)

Is there any reason for using a binary download instead of compiling from source, even though this is open source? I’ve had all sorts of compatibility issues with repackaged binaries in the past, so even if it might work fine right now I’d still be more comfortable with building from source.

nullgemm commented on 2018-09-26 13:47 (UTC)

Thank you for reporting this, should be fine now.

lll2yu commented on 2018-09-24 11:12 (UTC)

This should conflict with ly-git as both install the files at same location.