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:16 |
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:23 |
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:26 |
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:27 |
sarnold | ah! they put the details in the git README https://github.com/nextcloud-snap/nextcloud-snap | 00:28 |
Mathisen | yeah i already set up everything. and working just missing one package really | 00:30 |
Mathisen | php-imagick to be specific | 00:30 |
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:31 |
sarnold | yeah, imagemagick is pretty rough :/ but if you're hosting photos you took yourself, it's probably fine | 00:33 |
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:35 | |
Mathisen | yeah il hold of for a bit an give this a week to learn | 00:57 |
=== 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 | ||
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:53 |
paride | athos, thanks | 12:57 |
=== 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 | ||
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:51 |
sergiodj | athos: ouch :-/ | 20:52 |
sergiodj | athos: yes, forwarding it upstream is definitely a great idea | 20:52 |
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:53 |
sergiodj | but ultimately, it is upstream's job to determine which symbols need exporting | 20:54 |
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:11 |
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:12 |
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 :-/ | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!