<claudia>
I think about renaming it to xorg-libs-minimal because maybe there is use for the whole xorg-libs for others.
<testuser[m]>
There will be lot of duplicates in xorg-libs that already exist in xorg-libs-minimal
<testuser[m]>
So they gotta change anyway
<claudia>
Hm, also true. This way you dont have to change the depends.
<claudia>
I also think about for pkgs in kiss-games needing libglvnd to just put them in a seperate directory and dont specify libglvnd in the depends. This way users still using xorg could use the packages and dont have to fork.
<dilyn>
$/kiss-community is changing with dylan's latest announcement :)
featfred has joined #kisslinux
featfred has quit [Client Quit]
claudia has joined #kisslinux
<claudia>
wuu
<claudia>
dilyn: do you already have future plans on maintaining kiss-community?
soliwilos has quit [Remote host closed the connection]
Uks2 has quit [Quit: Byee]
Uks2 has joined #kisslinux
<micr0>
dilyn: seems like kiss-community/community doesn't need to change much - just remove any duplicated-with kiss-linux/repo/extra packages that existed just for wayland support?
<dilyn>
the officially unofficial KISS Linux community repository will be located at kiss-community/community, because Dylan has no intention of keeping one
<dilyn>
the main repository will be 'archived' in some sense
<dilyn>
I don't use xorg and have no interest in using it or providing support for it -- if someone would like to maintain a xorg repository in kiss-community, they are more than welcome to it!
<micr0>
kiss-community/repo can be 'archived', though it might be nice to be able to upstream all the updates into kisslinux/repo ?
<claudia>
I think now kiss-community/community is now the official community repository. At least from this community :D
illiliti has quit [Ping timeout: 265 seconds]
<dilyn>
it'll be archived in the sense that it won't be the official main repository and people should be discouraged from using it if they want to use Dylan's supported KISS. ideally, it's a libressl-xorg repository, maintaining packages that have to be changed from kisslinux/repo to continue this support, and not a whole other upstream repository
<dilyn>
if nobody has any interest in maintaining such a thing, then it WILL be archived in a literal sense, though I'll probably be keeping a copy of it around on my system 'just in case'
<micr0>
dilyn: archived in the literal sense === press the archive button on github but yeah, keep a second copy just in case
<micr0>
dilyn a quick check, it looks like gnugrep, json-c, mutt, pcre, and ssu in the /community repository conflicts with upstream kisslinux/repo/extra
<micr0>
should I make a tracking github issue to take a look at what the changes are, and if they should be upstreamed or removed?
<micr0>
ideally, nothing in /community would conflict with anything in kisslinux/repo/{core,extra,wayland}
<claudia>
dilyn: my question also aimed at: dou you plan on being my beloved dictator for eventually additionally needed packages?
<claudia>
<3
<dilyn>
well luckily for us, today is the day of Yet Another Purge :D so we can take a look at those and drop them
<dilyn>
I am the beloved dictator of very little, now! <3
<dilyn>
but i agree that there shouldn't be any conflicts if we can help it, micr0. duplicate packages are a waste of 'our time' when they can be found at $/kisslinux
<micr0>
i'll take a look to see what the diffs are
<dilyn>
tyty
<micr0>
gnugrep: no pragmatic difference (just changed install to use cp in build): can be dropped
<dilyn>
the kiss-community organization can also now be expanded, because we aren't so strictly beholden to the guidestones! community/ will still defer to the guidestones, but other repositories could now live there
<dilyn>
for instance, gkiss could have a new officially unofficial home
<micr0>
json-c: checksum update: can be dropped from community
<micr0>
mutt: inline cyrus-sasl build, remove perl dependency: there is a difference, but would reccomend dropping from community.
<dilyn>
+1
<konimex>
since I'm maintaining json-c, I would recommend immediate drop
<micr0>
pcre: disable utf-8 support: i got mixed feelings about this. utf-8 support in regular expressions is useful. would like to see this upstreamed into kisslinux/extra
<micr0>
I am gonna make a PR with the uncontroversial drops, and ping you konimex to :thumbsup: or whatever
<micr0>
ssu: no functional difference, reccomend drop
claudia has quit [Quit: zzz]
<noocsharp>
you can drop mutt too, i'm the maintainer
<micr0>
thank you konimex and noocsharp
<jslick>
Does foot-pgo provide some realized performance benefit over foot? Interesting that it is treated special in the main repo
<konimex>
also, with fribidi dropped from the main repo, I just discovered that fribidi is a GNU package
<dilyn>
jslick: it's slightly/noticeably faster in some situations. I don't think it technically has to be a different package; dilyn could do like the `cmake` package does for instance
<micr0>
> The primary difference between install and cp is that if the destination file already exists install unlinks it first.
<micr0>
> More probable scenario is that you update a program or a library while it is in use. If the binary is unlinked first, it won't affect the running program
<micr0>
I am gonna test this theory by updating how kiss installs packages to use the `install` command, and see if that prevents the crash
kyxor has joined #kisslinux
<dilyn>
`install` in foo/build shouldn't have any bearing on when foo is installed -- `kiss` still uses `cp` itself
<dilyn>
or do you mean exactly what I just said :o
<dilyn>
woop
<kyxor>
Hi, did anyone make a package for this https://github.com/google/re2 maybe in one of your personal repos? I need it, so if not I'll make it myself. But asking just in case to save time
<micr0>
yeah, but we specify `cp -f` which should be the same unlinking behavior as install
<micr0>
so my next best guess is that, we do pkg_remove_files while installing
kyxor has quit [Quit: kyxor]
kyxor has joined #kisslinux
jslick has quit [Ping timeout: 256 seconds]
zola has quit [Ping timeout: 265 seconds]
<micr0>
oh, `cp -fP` is still incorrect. Trying `install` now with kiss build pango
zola has joined #kisslinux
zola is now known as Guest9529
<micr0>
yeah okay, switching to `install` seems to have worked
<micr0>
i reinstalled: glib, pango, cairo, wayland, and sway while in a sway session
<micr0>
and no crash
<dilyn>
unfortunately dylan worked very hard to *remove* install from `kiss`...
<micr0>
this is busybox install, in the package manager
<micr0>
its fine if all the packages themselves use cp, since its always installing to a staging area
<micr0>
the other alternative, which may also come with performance improvements, is to see if tar x has options that act like `install` does, and use that instead of iterating over each file
<cem>
yeah, honestly switching from rsync slowed down the package manager so much
<cem>
I reverted that change in my fork when he did that
illiliti has quit [Ping timeout: 265 seconds]
<micr0>
cem dilyn well I will open an issue explaining the problem (our current `cp -fP` crashes running software if you replace any dependencies)
<micr0>
And id be disappointed (but not surprised) if it was not fixed one way or another (using install, rsync, or doing the correct kind of unlinking with cp)
Guest9529 has quit [Read error: Connection reset by peer]
<testuser[m]>
Is install different than rm + cp ?
<dilyn>
avoid rsync at all costs :v
<micr0>
testuser[m] yes, see backscroll if you can linking to stackexchange, which also links to a deeper discussion
<testuser[m]>
> Why unlinking (which can be also done by rm before cp) matters?
<testuser[m]>
Doesn't this imply that they do the same
<micr0>
I think `cp -f` only has the behavoir *IF* it encounters an EPERM error
<cem>
dilyn: why? rsync is great :P
<testuser[m]>
I said rm + cp
<micr0>
so it will do unlinking if EPERM; which insinuates that cp is not encountering EPERM currently
zola has joined #kisslinux
zola is now known as Guest5117
<dilyn>
rsync is DUM
<dilyn>
if your program has 600 options it has too many options.
<dilyn>
I should not have to pipe --help to `less` so i can figure out what to do
<cem>
I mean
<cem>
Fair
<micr0>
I don't think it will be too hard to convince dylan to use install, since its part of busybox
<dilyn>
gl
<cem>
micr0: heh
<micr0>
"its the users fault to expect their system to not crash while upgrading software" would be a pretty hostile attitude to take
<dilyn>
KISS *is* a semi-hostile project in a sense...
<dilyn>
the user is expected to 'have a brain', as it were
<testuser[m]>
if he doesn't settle for install (probably won't) he'll definitely fix it in another way
<micr0>
Thats more what I am hoping for - i dont care *how* it gets fixed, but would be surprised if it didnt get fixed some way
micro_O has joined #kisslinux
<micr0>
I prefer computers that respect the user is a human, and that brains are fallable
<cem>
dilyn: I mean, being hostile as a project is very different than not fixing bugs on purpose
<micr0>
surprised no one added a bot here for commands
<dilyn>
kissbot was brutally murdered
<micr0>
an irc bot is like, one of the best 'first programming project'
<micr0>
dilyn the mob got to kissbot?
<root__>
dilyn: Does firefox in bin repo have wayland support, if not will it get it?
<vulpine>
wait dylanaraps is back? :o
<root__>
Yes, for some time already
root__ has left #kisslinux [#kisslinux]
jslick has joined #kisslinux
micro_O has quit [Ping timeout: 258 seconds]
<dilyn>
repo-bin does not have wayland support
claudia has joined #kisslinux
<kyxor>
do you guys recommend to switch to wayland? If that thing is less bloat and compiles faster than X I might consider it
<kyxor>
Still its a big commitment for me, since all my aps are written for x11, and I don't know anything about wayland protocol which I would need to learn to rewrite them
<kyxor>
also that news of gcc getting rust frontend or whatever, like why I just want a C compiler not this bs
<kyxor>
free software is under attack by those rust guys... trying to stick themselves in every project. Just like c++ guys but worse
GalaxyNova has joined #kisslinux
<claudia>
kyxor: It mostly comes down on what programs you rely gui wise and how they are supported.
<claudia>
E.g there is no gtk2
<claudia>
but gtk+3 is fine for prob the most stuff.
<kyxor>
Hopefully repo-main under community stays though, and those who want wayland can just use the Dylan's repo-main
jslick has quit [Ping timeout: 258 seconds]
Uks2 has quit [Quit: Byee]
Uks2 has joined #kisslinux
<dilyn>
xorg support in kiss-community repo-main will only exist if someone maintains it. I don't use xorg (and haven't for a long, long while), so I can't guarantee much about it
claudia has quit [Read error: Connection reset by peer]
<dilyn>
lvm2 && libcap; i'd rather not maintain them, I don't use them or any of their dependencies
<dilyn>
this would fall to konimex/onodera-punpun (lvm2), and testuser/xuxiaodong (libcap)
<dilyn>
also test-user you should probably take pcre2 (android-tools)
zola has joined #kisslinux
mahmutov has joined #kisslinux
<GalaxyNova>
how would i go about switching to Dylan's upstream
<GalaxyNova>
without borking my system
<noocsharp>
rebuild everything that depends on libressl
teddydd has quit [Ping timeout: 252 seconds]
<GalaxyNova>
should i force remove libressl
<noocsharp>
i mean you could, but you have to rebuild everything that depends on it anyway
<dilyn>
depends on what the output of kiss-revdepends libressl is
<dilyn>
git and curl should only have libressl as make deps and no part of the actual build system should require libressl, so nothing should break. theoretically.
<dilyn>
so i'd just kiss r libressl; kiss b $(kiss-revdepends libressl)
<illiliti>
is there any non-bloated image viewer on wayland?
Guest054355 has joined #kisslinux
<dilyn>
imv maybe?
<illiliti>
imv depends on icu
<illiliti>
bloated
<dilyn>
lol
<dilyn>
mpv?
<illiliti>
mpv is good, but it isn't a "proper" image viewer though
<dilyn>
I don't think many others exist that don't require KDE...
<dilyn>
you could always try to gut icu from imv probably...
<kyxor>
hey guys, i am trying out wayland but sway fails to build, here is the log: https://0x0.st/-OL_.txt
<kyxor>
using the last commit of dylan repo
<kyxor>
need to rebuid libinput
<kyxor>
ok I was right, nvm then
<GalaxyNova>
welp...
<GalaxyNova>
I think I might have ruined my system
<GalaxyNova>
rip
<kyxor>
what happened Galaxy?
<GalaxyNova>
tried switching to OpenSSL
<GalaxyNova>
now git is broken and nothing will build
GalaxyNova has quit [Quit: Whoooooshh]
<kyxor>
uh, that's why I am testing wayland on tmpfs (temporary copy of rootfs), so that I don't break my main system
<kyxor>
and pretty much any package development or whatever I do on tmpfs so that in case shit happens I don't have to clean out junk and broken stuff from my main rootfs
mahmutov has quit [Ping timeout: 272 seconds]
mahmutov has joined #kisslinux
zola has quit [Ping timeout: 258 seconds]
GalaxyNova has joined #kisslinux
<GalaxyNova>
my irc client crashed lol
GalaxyNova has quit [Client Quit]
<dilyn>
what do you mean 'git is broken'?
<dilyn>
what are you trying to build that you need git to be working
<kyxor>
eh I think this might be best time to use kiss-reset, though because I can't build foot properly it says something fcft.h not found
<GalaxyNova>
yep
<kyxor>
oh rebuild libffi
<dilyn>
/usr/bin/ld: /usr/lib/libgobject-2.0.so: undefined reference to `ffi_type_sint32@LIBFFI_BASE_7.0'
<dilyn>
would be your problem
<dilyn>
kiss b $(kiss owns /usr/lib/libgobject-2.0.so)
<kyxor>
yeah
<kyxor>
but rebuild libffi cause it seems like that library is not providing symbol for glib, or vise versa rebuild glib
<GalaxyNova>
dilyn: Thanks! it sway builds now
GalaxyNova has quit [Quit: Whoooooshh]
<dilyn>
ffi recently saw an update that resulted in libffi.so.7 becoming libffi.so.8, and of course their build system didn't provide any 7 -> 8 symlink.
<dilyn>
so anything linking against libffi7 symbols mysteriously lost them :)
kyxor has quit [Quit: kyxor]
GalaxyNova has joined #kisslinux
<GalaxyNova>
wait what
<GalaxyNova>
I've just noticed something interesting
<GalaxyNova>
in the new website on the of the items in the overview is gone