[00:16] <Mathisen> so im doing a test switch from many many years on debian to ubuntu server. i kinda got tierd of to old packages like php making issues for example nextcloud.. anyway this snap thing is confusing. lets say i want to add php-imagick to a snap version is this even posible ?
[00:16] <Mathisen> snap is new to me. i never used it until now
[00:23] <sarnold> Mathisen: the general idea of snap is that whoever packaged it has provided all the dependencies themselves
[00:23] <sarnold> Mathisen: are you making a snap package yourself? or using snaps that other people have packaged?
[00:26] <Mathisen> sarnold, im just trying out the snap version of nextcloud in this case, but from the looks of it i just gonna host it normal without snap
[00:27] <Mathisen> the loop mounting it does also seems realy confusing to me. 
[00:27] <sarnold> hah, this is a bit thin on details :( https://snapcraft.io/nextcloud
[00:28] <sarnold> ah! they put the details in the git README https://github.com/nextcloud-snap/nextcloud-snap
[00:30] <Mathisen> yeah i already set up everything. and working just missing one package really
[00:30] <Mathisen> php-imagick to be specific 
[00:31] <Mathisen> but from reading "It seems that the SNAP mainteners don´t like the imagick package because of security terms, so it isn´t in the package"
[00:33] <sarnold> yeah, imagemagick is pretty rough :/ but if you're hosting photos you took yourself, it's probably fine
[00:35] <sarnold> Mathisen: oh, take a look at the last two comments on https://github.com/nextcloud-snap/nextcloud-snap/pull/629
[00:35] -ubottu:#ubuntu-server- Pull 629 in nextcloud-snap/nextcloud-snap "Add Imagemagick support in PHP" [Closed]
[00:57] <Mathisen> yeah il hold of for a bit an give this a week to learn 
=== chris14_ is now known as chris14
=== jgee11869225344 is now known as jgee1186922534
=== shokohsc640 is now known as shokohsc64
=== jgee11869225345 is now known as jgee1186922534
=== jgee11869225342 is now known as jgee1186922534
=== jelly-home is now known as jelly
[12:53] <athos> Hey, ahasenack, paride FYI: https://lists.debian.org/debian-devel/2023/03/msg00054.html. Just in case this starts a more in depth discussion regarding kea
[12:57] <paride> athos, thanks
=== p3lim5 is now known as p3lim
=== ikonia is now known as Guest7235
=== ikonia_ is now known as ikonia
=== shokohsc644 is now known as shokohsc64
=== bbezak4 is now known as bbezak
=== alkisg1 is now known as alkisg
=== sdeziel_ is now known as sdeziel
[20:51] <athos> sergiodj: so, this is the diff for the armhf symbols file https://launchpadlibrarian.net/654936250/buildlog_ubuntu-lunar-armhf.isc-kea_2.2.0-5ubuntu1~ppa1_BUILDING.txt.gz :/
[20:51] <athos> perhaps the solution here would be to add a version script indeed and forward it upstream
[20:52] <sergiodj> athos: ouch :-/
[20:52] <sergiodj> athos: yes, forwarding it upstream is definitely a great idea
[20:53] <sergiodj> I'm OK with adding the ld script for now in order to get the MRI complete.  I know you do your due dilligence to make sure the necessary symbols are properly exported :)
[20:54] <sergiodj> but ultimately, it is upstream's job to determine which symbols need exporting
[21:11] <athos> yeah... it is not trivial to come up with such a version script though. Hard to get sound filters. For isntance, one of the libraries has a lexer and even symbols in that lexer are being exported
[21:12] <athos> TBH, I guess I will refrain from touching the symbols for this one. We can carry a large symbols file for now and then we can work with upstream to only export the right symbols
[21:14] <sergiodj> athos: ideally, upstreams will list all symbols being exported in the map file.  but as you said earlier, there are several kinds of upstreams :-/