💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2021-07-18.txt captured on 2024-03-21 at 15:59:28.
⬅️ Previous capture (2021-12-17)
-=-=-=-=-=-=-
[2021-07-18T00:01:55Z] <micr0> also a little weird - the releases all say that the kiss package is 5.4.11 ... so its hard to tell
[2021-07-18T00:04:18Z] <micr0> interesting, same issue with kiss 5.4.11
[2021-07-18T00:04:46Z] <sad_plan> has anyone had issue with eiwd not having iwd_passphrase for some reason? I find it very strange tbh.. never had any issues with it at all tbh, except now obviously :p
[2021-07-18T00:05:38Z] <dilyn> it used to include that utility...
[2021-07-18T00:06:33Z] <sad_plan> ikr..
[2021-07-18T00:09:17Z] <soliwilos> I built an old eiwd and kept a copy of that tool.
[2021-07-18T00:10:16Z] <micr0> ok so the latest working image was 2021.7-5. the error still shows but is not fatal i think
[2021-07-18T00:10:47Z] <soliwilos> Anyone else getting errors building vim? "auto/config.h:106:16: error: duplicate 'unsigned'"
[2021-07-18T00:11:02Z] <sad_plan> I belive I did build it straight from illiliti when doing a reinstall, and I dont seem to recall any issues. i removed the sources aswell, and did a redownload, still no dice. kiss manifest doesnt show it either. theres no difference in my buildscript either, from what dylan has in his repo either..
[2021-07-18T00:11:13Z] <sad_plan> oh well, time for wpa_supplicant I suppose
[2021-07-18T00:13:04Z] <soliwilos> You can maka do without that utility.
[2021-07-18T00:13:23Z] <soliwilos> s/maka/make/
[2021-07-18T00:13:42Z] <sad_plan> by manually adding the file you mean?
[2021-07-18T00:13:50Z] <soliwilos> Yes.
[2021-07-18T00:14:59Z] <sad_plan> im not sure of how its listed though. I do recall it not being very.. intricate tbh. mine was for some reason also saved in cleartext.. which isnt very safe tbh :p
[2021-07-18T00:16:56Z] <soliwilos> It should be root owned with 600 perms, I think it's always in cleartext, but need permission to read it.
[2021-07-18T00:17:53Z] <soliwilos> Only contains [Security]\nPassphrase=....
[2021-07-18T00:18:58Z] <sad_plan> sound about right. I recall not being able to access it even with ssu. had to go by su.
[2021-07-18T00:20:12Z] <micr0> This is kinda nice, to be running kiss in containers
[2021-07-18T00:20:18Z] <soliwilos> The ssid is given as the name of the file, filetype is .psk
[2021-07-18T00:21:52Z] <micr0> especially since its podman and not docker. its just a shell script, not a Containerfile
[2021-07-18T00:24:52Z] <sad_plan> ik
[2021-07-18T00:36:17Z] <micr0> soliwilos trying `kiss build vim` in a fresh container, will let you know shortly if it works or not
[2021-07-18T00:37:59Z] <riteo> I've been thinking about it for a while, are shell scripts THAT slow?
[2021-07-18T00:38:48Z] <riteo> in the end you're just gluing c programs and writing to files usually in a tmpfs which is basically memory
[2021-07-18T00:39:10Z] <riteo> are c port of kiss any faster than kiss itself?
[2021-07-18T00:39:28Z] <micr0> soliwilos yeah `kiss build vim` worked for me
[2021-07-18T00:40:10Z] <micr0> riteo speed is just one reason for the c port
[2021-07-18T00:40:42Z] <micr0> but just talking about that - setting up subshells and calling out to external programs are usually slower than having one monolithic program
[2021-07-18T00:40:53Z] <soliwilos> micr0: Alright, thank you. Then I know it's something I can change on my system to make it work.
[2021-07-18T00:41:44Z] <micr0> so a small example - if you run the shasum executable 10,000 times, because you want to shasum 10k files, that would likely be much slower than having a shasum function in your favorite program, and running that function 10,000 times
[2021-07-18T00:42:05Z] <riteo> that's were optimizations come in
[2021-07-18T00:42:19Z] <micr0> sure - and you could do that in your shell script as well!
[2021-07-18T00:42:22Z] <riteo> sha1sum supports both calculating multiple files and checking them from a file
[2021-07-18T00:42:34Z] <riteo> that sped up *immensely* minekiss in my case
[2021-07-18T00:42:45Z] <micr0> which sha1sum? arent there like a million of them?
[2021-07-18T00:43:09Z] <riteo> are you talking about the implementation or the way minekiss uses them?
[2021-07-18T00:43:11Z] <micr0> well, i was just coming up with an illustrative example. likely oil-shell has better benchmarks than anything else out there
[2021-07-18T00:43:34Z] <riteo> I do get your point though
[2021-07-18T00:43:36Z] <micr0> talking about which implementation
[2021-07-18T00:43:56Z] <riteo> oh I have no idea, I think gnu one
[2021-07-18T00:44:01Z] <riteo> although it should work fine with busybox
[2021-07-18T00:44:03Z] <micr0> but yeah, like, basically external process calls are more expensive than function jumps, which are more expensive than inlining stuff
[2021-07-18T00:44:11Z] <riteo> yeah I get your point
[2021-07-18T00:44:33Z] <riteo> also running programs requires stuff like loading in memory and passing through elf interpreters and whatnot
[2021-07-18T00:44:57Z] <micr0> checking for the program across all PATH entries, yep
[2021-07-18T00:45:01Z] <micr0> lots of stuff
[2021-07-18T00:45:04Z] <riteo> right
[2021-07-18T00:45:28Z] <riteo> micr0: what do you think about the future switch to a c package manager?
[2021-07-18T00:45:36Z] <micr0> for a from-source distro, I am unsure if speed is the best thing
[2021-07-18T00:46:09Z] <riteo> the statically compiled argument has already been proven wrong by dilyn some time ago
[2021-07-18T00:46:15Z] <micr0> riteo the more implementations of `kiss`, the better - it forces each version to work better, and makes it easier for more implementations
[2021-07-18T00:46:40Z] <riteo> oh that's sure a good thing, it encourages a clean standard
[2021-07-18T00:46:46Z] <riteo> and a well defined one too
[2021-07-18T00:47:01Z] <micr0> i am hoping it creates tests that other implementations can work against, yeah
[2021-07-18T00:47:15Z] <riteo> but like, looking at the pros and cons I'm still not sure about the future switch to k
[2021-07-18T00:47:23Z] <riteo> or w/e it will be called
[2021-07-18T00:47:26Z] <micr0> but as far as hackability, i'm very likely going to stick to the shell implementation - its just so damn transparent
[2021-07-18T00:47:41Z] <micr0> like, its really easy for me to see whats going wrong when things go wrong, and hack around it
[2021-07-18T00:47:46Z] <micr0> or extend
[2021-07-18T00:48:17Z] <noocsharp> i think a well written c package manager could do the same thing
[2021-07-18T00:48:19Z] <micr0> but i think having a less extensible, more purpose-built package manager is good. may attract people who are not necessarily interested in building tooling
[2021-07-18T00:48:34Z] <riteo> mh, that's a really good pro of all shells script in general
[2021-07-18T00:48:55Z] <dilyn> wait what did i disprove
[2021-07-18T00:49:00Z] <micr0> like I might port `kiss` to oil and zig
[2021-07-18T00:49:10Z] <riteo> that a statically linked executable is not that different from a statically built base system
[2021-07-18T00:49:15Z] <riteo> oil?
[2021-07-18T00:49:18Z] <riteo> that's new to me
[2021-07-18T00:49:58Z] <riteo> talking about the kiss package standard, I'm curious to see the package linter someone was working on
[2021-07-18T00:50:12Z] <riteo> I wonder how it will be called too, kisscheck?
[2021-07-18T00:50:41Z] <riteo> yes, I love names a lot
[2021-07-18T00:51:20Z] <micr0> if i were to make a wishlist for kiss, it would be: kiss build/install could never break (staticly installed or through some other means), respect upstream package defaults, keep the visibility (simple package manager, simple packages) and extensibility (hooks). Everything else I want to see is just personal opinion, or I am making happen myself, like better testing and binary packages.
[2021-07-18T00:51:34Z] <micr0> riteo oil = oil shell = osh
[2021-07-18T00:51:41Z] <riteo> ooooh I see
[2021-07-18T00:51:55Z] <micr0> it aims to replace bash but being 100% compatible, but then you can opt in to a much saner language
[2021-07-18T00:52:04Z] <riteo> compatible in what regards?
[2021-07-18T00:52:39Z] <micr0> like literally you could do `osh myscript.bash` for every existing bash script in the universe, and it would have the same side effects
[2021-07-18T00:52:51Z] <riteo> I see
[2021-07-18T00:53:10Z] <riteo> you're talking about a saner language, so I guess it parses both syntaxes?
[2021-07-18T00:53:12Z] <micr0> but then you could opt-in to more safety, or at least have less undefined side effects for those that are not defined
[2021-07-18T00:53:56Z] <riteo> that's interesting
[2021-07-18T00:54:32Z] <riteo> RE kiss build/install never breaking: in what circumstances could it break?
[2021-07-18T00:54:55Z] <riteo> if the system's core tools are statically built it should never break in theory, right?
[2021-07-18T00:55:23Z] <micr0> yep
[2021-07-18T00:55:30Z] <soliwilos> Using a shell other than the one/few tested to work.
[2021-07-18T00:56:01Z] <micr0> yeah using kiss a the core packaged bash has broken some subcommands, but i dont think build/install has broken
[2021-07-18T00:56:09Z] <micr0> updating `kiss` itself has broken kiss build/install
[2021-07-18T00:57:17Z] <micr0> and 'broken' is a spectrum
[2021-07-18T00:57:35Z] <soliwilos> x264 wouldn't build for me when using oksh, but changing back to busybox sh and it built.
[2021-07-18T00:57:46Z] <micr0> that is super useful to know
[2021-07-18T00:58:08Z] <micr0> i'll make sure to add 'shell' to the matrix for my testing container
[2021-07-18T00:58:15Z] <riteo> doesn't oil have a posix compatibility mode?
[2021-07-18T01:00:19Z] <micr0> the planned matrix is: image X kiss version X shell X package.
[2021-07-18T01:01:59Z] <noocsharp> /5
[2021-07-18T01:02:05Z] <noocsharp> oops
[2021-07-18T01:31:48Z] <riteo> And finally, offline mode should be implemented on minekiss
[2021-07-18T01:31:56Z] <riteo> I also cleaned it up quite a bit
[2021-07-18T02:06:01Z] <akira01> soliwilos: have you tested surf wayland?
[2021-07-18T02:23:43Z] <acheam> dilyn: so my llvm links to both libedit and ncursesw
[2021-07-18T02:32:34Z] <dilyn> why... why does it do that? lol
[2021-07-18T02:32:43Z] <dilyn> like what's libedit/ncurses provide llvm?
[2021-07-18T02:35:23Z] <akira01> kiss will go to llvm or just a option?
[2021-07-18T02:35:40Z] <akira01> last dylan post made me think about
[2021-07-18T02:36:00Z] <dilyn> no
[2021-07-18T02:36:12Z] <dilyn> it's just more cc agnostic now
[2021-07-18T02:36:55Z] <akira01> good
[2021-07-18T02:39:42Z] <acheam> dilyn: because I build it with lldb
[2021-07-18T02:40:38Z] <dilyn> ohoooo i see
[2021-07-18T02:40:42Z] <dilyn> interesante...
[2021-07-18T02:41:13Z] <acheam> why would it even need libedit?
[2021-07-18T02:41:19Z] <acheam> without lldb that is
[2021-07-18T02:42:12Z] <acheam> y'know, itd be real nice if git didnt depend on libcurl
[2021-07-18T02:42:35Z] <acheam> like, i wouldnt mind it missing out on some features like https
[2021-07-18T02:42:56Z] <acheam> but i feel that it should be unjustifiable hard to implement http cloning without it
[2021-07-18T02:52:11Z] <riteo> what does git depend on to download https repos?
[2021-07-18T02:53:06Z] <riteo> readelf tells me that it links to only like, 4 libraries and I don't see libcurl in there, why does libgit depend on it?
[2021-07-18T02:54:27Z] <dilyn> for getting https sources
[2021-07-18T02:54:37Z] <dilyn> build a shared git and see
[2021-07-18T02:54:45Z] <riteo> oh, so it's statically compiled
[2021-07-18T02:54:50Z] <dilyn> yeah
[2021-07-18T02:54:52Z] <riteo> I see
[2021-07-18T02:55:03Z] <dilyn> that's why it's so big (:
[2021-07-18T02:55:38Z] <acheam> im trying to repackage git right now with a static libcurl
[2021-07-18T02:55:38Z] <riteo> would it be stupid/impossible to do the same with libgit too?
[2021-07-18T02:55:40Z] <dilyn> i imagine you could probably forgo using libcurl if you only wanted to be able to get repos over ssh
[2021-07-18T02:55:45Z] <acheam> riteo: no
[2021-07-18T02:55:49Z] <acheam> but you still depend on cmake
[2021-07-18T02:56:01Z] <riteo> well, that's something at least
[2021-07-18T02:56:25Z] <riteo> so because of cmake dylan will not use it, right?
[2021-07-18T02:57:01Z] <riteo> I'm curious of what he'll use instead
[2021-07-18T03:01:07Z] <akira01> dilyn: spotifyd still in graveyard
[2021-07-18T03:01:55Z] <dilyn> god i really hate the graveyard
[2021-07-18T03:02:15Z] <akira01> I plan to port other packages
[2021-07-18T03:02:24Z] <akira01> From graveyard
[2021-07-18T03:20:37Z] <acheam> so my next step is going to try and semi staticify my install
[2021-07-18T03:20:42Z] <acheam> not going for fully static
[2021-07-18T03:20:55Z] <acheam> but combining packages where a library is only the dep for a single package
[2021-07-18T03:20:57Z] <acheam> and stuff like that
[2021-07-18T04:35:23Z] <testuser[m]> Hi
[2021-07-18T04:39:28Z] <dilyn> you won't run into my walls on that journey acheam!
[2021-07-18T04:39:39Z] <dilyn> freetype-harfbuzz might be a little annoying
[2021-07-18T04:41:27Z] <acheam> many build files shall be copied from you
[2021-07-18T04:41:34Z] <acheam> hi testuser[m]
[2021-07-18T04:41:53Z] <riteo> hi testuser[m]!
[2021-07-18T04:44:17Z] <necromansy> hey
[2021-07-18T07:11:10Z] <GalaxyNova> Anyone know a portable replacement for SUDO_UID?
[2021-07-18T07:13:38Z] <testuser[m]> how would it be possible, the privilege escalation utilities need to set it right ? Not the sh
[2021-07-18T07:13:48Z] <testuser[m]> What do you need it for
[2021-07-18T07:16:01Z] <GalaxyNova> testuser[m]: I'm asking more for a workaround. Basically I have to drop root in a process.
[2021-07-18T07:16:04Z] <GalaxyNova> in C btw
[2021-07-18T07:17:47Z] <GalaxyNova> I need a user id to setuid() to :/
[2021-07-18T07:19:52Z] <GalaxyNova> would statting /dev/tty1 be good enough?
[2021-07-18T07:21:09Z] <testuser[m]> Why do you need the program to start as root ? Maybe there's an alternative
[2021-07-18T07:21:31Z] <testuser[m]> Like for webservers you can just give specific permissions to bind port
[2021-07-18T07:22:05Z] <GalaxyNova> because I'd either have to 1) call an external program like sudo or doas 2) implement my own priviledge escalation code
[2021-07-18T07:22:41Z] <testuser[m]> https://github.com/swaywm/sway/blob/96102184ab96c522fe1f9175bc4d5ceb09aa1720/sway/main.c#L152
[2021-07-18T07:22:58Z] <testuser[m]> This ?
[2021-07-18T07:23:21Z] <GalaxyNova> thanks :D
[2021-07-18T07:29:19Z] <testuser[m]> Btw it works only if SUID bit is set on the binary, not if it's run directly as root. Then it would just abort since it regained root privileges
[2021-07-18T10:35:57Z] <sad_plan> hey
[2021-07-18T10:40:48Z] <testuser[m]> hi
[2021-07-18T10:40:55Z] <riteo> hi
[2021-07-18T10:41:29Z] <soliwilos> o/
[2021-07-18T11:04:17Z] <riteo> gtg, bye everyone!
[2021-07-18T11:21:41Z] <claudia> I wonder if maintaining a textfile instead of the graveyard would be easier^^
[2021-07-18T11:22:08Z] <necromansy> id say it would be imo
[2021-07-18T11:22:34Z] <sad_plan> like instead of dumping all the packages into its own repo, just add the info into a txt file instead?
[2021-07-18T11:22:46Z] <claudia> I dont like the idea of the graveyard too. There is git log.
[2021-07-18T11:23:02Z] <necromansy> yeah id imagine thats how youd want it
[2021-07-18T11:23:04Z] <claudia> The only benefit I sea, that its obviously what package there are on a first glance
[2021-07-18T11:23:18Z] <necromansy> just dump the package name and version to the text file
[2021-07-18T11:23:19Z] <sad_plan> there is, but having a graveyard makes it more userfriendly. for noobs anyway :p
[2021-07-18T11:23:29Z] <claudia> Like you have to know what you are looking for
[2021-07-18T11:23:31Z] <claudia> yeah
[2021-07-18T11:24:37Z] <testuser[m]> no
[2021-07-18T11:24:40Z] <testuser[m]> Just put
[2021-07-18T11:24:43Z] <testuser[m]> name: commit hash
[2021-07-18T11:24:51Z] <necromansy> heck
[2021-07-18T11:24:53Z] <necromansy> you right
[2021-07-18T11:24:55Z] <necromansy> thats way smarter
[2021-07-18T11:25:14Z] <claudia> got an example?
[2021-07-18T11:25:24Z] <claudia> ah in the txt?
[2021-07-18T11:25:27Z] <testuser[m]> commit hash of when it was dropped
[2021-07-18T11:25:29Z] <testuser[m]> yeah
[2021-07-18T11:25:45Z] <testuser[m]> so you can just make a script that goes through the file and revives the package with your given name
[2021-07-18T11:26:10Z] <testuser[m]> Assuming a community repo with full history
[2021-07-18T11:26:19Z] <sad_plan> cant you just git log | grep drop, and then grep or fzf to find you package? and then revert it, fork it intot your own repo or whatever?
[2021-07-18T11:27:42Z] <testuser[m]> That's just the graveyard txt with extra steps
[2021-07-18T11:27:55Z] <sad_plan> ¯\_(ツ)_/¯
[2021-07-18T11:28:15Z] <claudia> Can there be a github interna script to maintain this script?
[2021-07-18T11:28:24Z] <claudia> like looking for "drop"
[2021-07-18T11:28:45Z] <testuser[m]> Grepping won't be reliable, what if someone uses "purge" or "remove"
[2021-07-18T11:29:03Z] <claudia> we could force "drop"
[2021-07-18T11:29:15Z] <necromansy> eh
[2021-07-18T11:29:26Z] <claudia> when this removes the maintenance for maintaining the file/graveyard
[2021-07-18T11:30:40Z] <necromansy> forcing commit message phrasing is probably too extreme to make a pipeline work
[2021-07-18T11:31:01Z] <necromansy> esp when a commit hash points straight to it
[2021-07-18T12:59:17Z] <micro_O> claudia two benefits of graveyard: packages show up in kiss find (or kiss search if you have the graveyard locally), so its way easier to discover 'someone packaged this once'
[2021-07-18T13:00:24Z] <micro_O> and resurrecting a package is much easier with kiss fork
[2021-07-18T13:02:14Z] <micro_O> so basically the graveyard makes it so instead of having everyone have to do multiple steps multiple times (look up text file, find git repo, clone git repo, find commit, revert commit), it makes some people do a few steps once (find commit, revert commit)
[2021-07-18T13:03:53Z] <micro_O> as far as detecting dropped packages, i would just search git commits where a) a file named build was deleted, b) there were 0 additions, and c) there are no packages that show up in kiss-find. That would at least be good enough to reduce false positives to a low number.
[2021-07-18T13:09:51Z] <micro_O> another way to put it: if you are about to `echo package_name commit_hash repo_uri >> graveyard.txt`, why not `bury() { git clone $repo_uri && git -C ${repo#*/} revert $commit_hash | git -C graveyard.git am - }`
[2021-07-18T13:11:22Z] <micro_O> (or the equivalent)
[2021-07-18T13:29:14Z] <claudia> micr0: graveyard might be useful for your kiss-find utility but for making a proper graveyard one must effectively maintain 2 repositories and additionally look for duplicates now and then. E.g there is atm glew in graveyard and community.
[2021-07-18T13:31:12Z] <claudia> Idk, I prefer a clean structure over an easy to use.
[2021-07-18T13:32:06Z] <claudia> I dont even like the idea of the textfile as is duplicating effort for the maintenance.
[2021-07-18T14:07:09Z] <soliwilos> akira01: No, I haven't tried surf-wayland.
[2021-07-18T14:08:15Z] <akira01> i see
[2021-07-18T14:13:41Z] <acheam> why not just have graveyard as a subdirectory of the repo?
[2021-07-18T14:13:47Z] <acheam> thats what I do for asd
[2021-07-18T14:14:21Z] <acheam> its as simple as "mv extra/xyz junk/"
[2021-07-18T16:33:13Z] <akira01> anyone with sway-tiny still get amixer error?
[2021-07-18T16:48:06Z] <claudia> akira01: I tried bindsym XF86AudiolowerVolume exec "/usr/bin/amixer sset Master 5%-" but no sucess.
[2021-07-18T16:53:38Z] <akira01> Me too
[2021-07-18T17:02:51Z] <soliwilos> Not using sway now, but in an old sway config I have "bindsym XF86AudioLowerVolume exec ...".
[2021-07-18T17:04:04Z] <soliwilos> Have you tried wev?
[2021-07-18T17:12:59Z] <claudia> soliwilos: do you got a link to the source of wev? I cannot find it rn.
[2021-07-18T17:13:38Z] <testuser[m]> Its on sr.ht. under drewdevault acc
[2021-07-18T17:13:39Z] <soliwilos> https://git.sr.ht/~sircmpwn/wev
[2021-07-18T17:14:03Z] <claudia> merci.
[2021-07-18T17:14:49Z] <claudia> wow
[2021-07-18T17:15:00Z] <claudia> the squared window wev opens is hardcore O_O
[2021-07-18T17:25:59Z] <claudia> I have tested with sway-no-seat and sway-tiny. Wev does show keypress for regular keys but not the Xf86Volume keys.
[2021-07-18T17:26:54Z] <claudia> They seem to be handled differently in some way.
[2021-07-18T17:28:08Z] <soliwilos> I get "sym: XF86AudioRaiseVolume ..."
[2021-07-18T17:28:37Z] <soliwilos> Running hikari.
[2021-07-18T17:28:42Z] <micr0> claudia graveyard seems both clean and easy-to-use for me. also I like acheams suggestion, though i am not sure community.git would like having graveyard from other repositories, who knows
[2021-07-18T17:29:31Z] <micr0> its a completely separate repository, so not sure whats cleaner than that
[2021-07-18T17:32:32Z] <soliwilos> claudia: I'd expect it to work in upstream sway, so possibly something were modified that tampered with those keys.
[2021-07-18T17:34:18Z] <testuser[m]> Maybe the libevdev patch ?
[2021-07-18T17:38:10Z] <soliwilos> Yeah.
[2021-07-18T18:09:49Z] <soliwilos> claudia: You could try adding --to-code to the bindsym lines, see if it makes a difference.
[2021-07-18T18:12:33Z] <soliwilos> It's really to make keybindings layout independent.
[2021-07-18T18:18:53Z] <akira01> claudia: when disable amixer in sway config i can get XF86Audio from wev
[2021-07-18T18:23:45Z] <claudia> soliwilos: this makes no difference.
[2021-07-18T18:24:29Z] <claudia> Hm when, removing the Xf86key from the config makes wev to show the keypress, then I guess our way to parste the argument to "/usr/bin/foo --argument" is not right.
[2021-07-18T18:26:52Z] <soliwilos> Try dropping the " " around the command and arguments?
[2021-07-18T18:34:08Z] <claudia> No. Tried a variety of possibilities. with " and ' and each argument in ' or "
[2021-07-18T18:35:23Z] <claudia> Anyway one could always a wrapperscript for volume up and down for the time being :p
[2021-07-18T20:22:50Z] <claudia> akira01: the "mediakey" sway-tiny issue should be fixed.
[2021-07-18T20:22:53Z] <claudia> https://github.com/kisslinux/repo/issues/293
[2021-07-18T20:24:04Z] <akira01> Gosh thanks
[2021-07-18T20:24:11Z] <akira01> Will test now
[2021-07-18T20:26:13Z] <GalaxyNova> idk if anyone else noticed this but kiss-size sway is smaller than kiss-size sway-tiny
[2021-07-18T20:28:26Z] <akira01> Yup amixer works now
[2021-07-18T20:28:26Z] <claudia> wlroots is build into tiny and no-seat
[2021-07-18T20:29:17Z] <akira01> GalaxyNova: what about ram?
[2021-07-18T20:59:46Z] <sad_plan> hey
[2021-07-18T22:50:40Z] <sad_plan> when a makefile does not have an option to install, what would be the best approach to install it with the buildscript?
[2021-07-18T22:54:10Z] <sad_plan> I dont suppose cp does the trick correctly :p
[2021-07-18T23:31:23Z] <noocsharp> cp + chmod
[2021-07-18T23:32:01Z] <noocsharp> i think install used to be preferred, but it no longer is
[2021-07-18T23:33:12Z] <sad_plan> yeah, I know Dylan moved away from install command earlier. in this case there is only possible to make, but you gotta cp it yourself into the correct dir.
[2021-07-18T23:33:31Z] <sad_plan> but sure, ill try that