IRC Logs for #crux-devel Friday, 2019-01-18

*** j_v has quit IRC04:04
*** jibade has joined #crux-devel04:55
*** jibade has quit IRC05:19
*** Workster has quit IRC05:28
*** Workster has joined #crux-devel05:37
*** prologic has quit IRC05:56
*** prologic has joined #crux-devel06:00
*** Workster has quit IRC06:26
*** Workster has joined #crux-devel06:35
*** j_v has joined #crux-devel06:37
*** Workster has quit IRC06:43
*** dztctjvfcbtweavy has joined #crux-devel06:43
juej_v: thanks for the hint to rebuild libtiff to solve the libjpeg-turbo problem07:37
juej_v: but, how do you detect this?07:38
*** darfo has quit IRC07:39
*** darfo has joined #crux-devel07:40
*** deus_ex has joined #crux-devel09:47
*** Romster has quit IRC09:52
*** Romster has joined #crux-devel09:58
*** pedja has joined #crux-devel11:49
*** deus_ex has quit IRC11:52
*** deus_ex has joined #crux-devel13:41
*** pedja has quit IRC13:42
j_vjue: ran into build failure when rebuilding texlive. the texk/dvipng portion, which uses libgd, through errors that, after investigating, pointed at libjpeg linking errors. turns out that libjpeg-turbo, now that it uses cmake build system instead of autotools, no longer ships a libtool archive file.14:15
j_vnot a problem in a of itself, but looks like at least some ports that depend on libjpeg-turbo will ship their own libtool archive file that uses a hard path to a, which causes build failures. rebuilding such ports causes these .la files to be generated correctly.14:18
j_vs/in a of itself/in and of itself/14:19
j_vprobably the most thorough way to eradicate future issues is to rebuild all installed ports that depend on libjpeg-turbo and ship a libtool archive file.14:21
j_vfor prt in $(prt-get dependent libjpeg-turbo); do if grep -q "usr/lib/lib.*\.la" $(prt-get path $prt)/.footprint; then prt-get update -fr $prt; fi; done14:28
j_vsorry, that script fragment would probably have been more appropriate in the #crux channel14:40
*** Romster has quit IRC14:42
*** Romster has joined #crux-devel14:47
jueI got build-errors for libgd, lcms2 and cups-filters and probably for all ports that depends on libjpeg-turbo, tried to fix libgd but without success15:02
juedon't get it why rebuilding of libtiff solved the issue?15:03
j_vlibgd depends on libtiff which also depends on libjpeg-turbo... libtiff installs a file that has in it a reference to /usr/lib/ that will break the build of libgd, so rebuilding libtiff with new libjpeg-turbo will force libtiff to regenerate it's .la file15:05
j_vthen, instead of having /usr/lib/ on its linker line, it will have -ljpeg15:06
j_vmy opinion is that libtool is a pita15:07
jueyep, indeed15:07
j_vsorry, that was supposed to be "instead of having /usr/lib/ on its..."15:09
juethanks for the explanation, now I got it :)15:09
j_vit is a pleasure to help, you are welcome15:10
juerebuilded has now a -ljepg and not /usr/lib/libjpeg.la15:11
frinnstshould I revert?15:17
frinnsti ran the new libjpeg-turbo version for a few weeks on my home system without problems. but I dont run the ports you list there so..15:17
jueno, not necessary15:18
jueI'M preparing an update for cups-filters currently and will do a [notify] commit to explain the problem15:18
juehope it's understandable what I've written15:24
j_vfrinnst, i don't think it was an issue you caused. at least i don't see it that was. the 2.* series of libjpeg-turbo deprecated autotools configuring, as you know, so we were going to hit this eventually. not really a bug, just something that doesn't show up until the point we run in to it.15:27
juewell, guess it was a broad hint to be very carefully if we update an library and a .la file has been removed from the footprint15:30
j_vgood point. learn something new all the time. too bad that when i get to the point that i think i have seen it all, i will not be able to remember the details about many of these things anyways. my memory really is getting worse as i get older.15:34
juesame here :)15:35
pedjaI locked libjpeg-turbo until openimageio/opencolorio/freeimage catch up :)15:37
j_vit has been a nice break these last three/four weeks, in between jobs. next week start new job away from home. won't have as much time as while i have been off, but at least this new job will be low enough hours that i should be able to keep up with things better than i was this summer/autumn.15:40
j_vpedja, that makes sense. those ports can be really touchy to new versions of deps, from what i remember.15:45
pedjaj_v, I learned that the hard way :)15:46
pedjamakes sense from their perspective, thou, vfx platform is pretty conservative15:48
j_vyep, it is complex and it all gets interrelated, too15:49
pedjait's a big challenge to move that amount of production systems to new libraries, particularly ones that break api/abi15:51
pedjaswitching to python3/qt5 is also fun, I guess15:52
pedjalots of technical debt15:53
j_vexactly. of course, we run into issue because big downstream projects sometimes use internal functions instead of the exported api's, and we get the kind of breakage that texlive runs into with poppler, et cetera15:53
pedjaor like openzfs was using deprecated internal kernel functions, and now when that got removed and replaced with gpl-only ones, it sucks big time for them on 5.0+ kernels :)15:56
pedjahunting that stuff is fun15:56
j_vyeah, it can be a mess. these guys writing this stuff are supposed to know this, but i thing sometimes it comes down to quick and dirty to get stuff 'out the door'15:57
j_vit happens in all walks of life, sometimes justified, often over used... taking the time to get it 'right' usually pays off, but pressures can get pretty ugly too15:59
pedjaquick hacks almost always become the essential part of the code :)16:01
pedjawell, 'right' is often replaced with 'good enough'16:02
j_vyep. i think often, and especially with complex interdependent libraries, that those quick hacks can't just be replaced that easily.16:02
pedjabecause they become something that applications/other libs depend on. it's a mess16:03
j_vfor me, deep breaths and taking a walk when i get frustrated is sometimes necessary :)16:04
pedjaor just switching to doing something else for a while16:05
j_valso, prevents me from getting to buried in the issue i am trying to find the fix for, or getting so close to it i cannot see the fix when it bumps into my nose ;)16:05
pedjahappened to me quite a few times :)16:08
pedjaobscure error messages don't help either16:09
pedjathe dependency chain can get ugly real fast16:10
j_vyeah, that is so true16:12
pedjathe most frustrating thing are applications that expect their dependencies to be built in a certain way, but no mention of it in the documentation16:12
j_vgood dev docs about building big software packages are a blessing, but often too rare16:14
pedjaspelunking thru github issues or CI setups is often the only way to figure it out16:15
j_vperfect word for that, spelunking :)16:16
pedjaor just going thru it several times, fixing shit, until it breaks no more :)16:16
pedjaotoh, I'll take no docs over wrong docs any time16:18
j_vgood point. i think, in those cases of wrong docs, it is often a matter of outdated information16:19
pedjaand when its clearly marked as outdated, there is no issue16:20
pedjabut when I keep getting some random error because I go with some docs, and the things have changed considerably in the mean time, it's...not fun :)16:21
j_vyes, sir. frustration galore16:22
pedjaso I just read Cmake*.txt to figure out how and what16:25
pedjaautotools, otoh, are just a black box to me, how all the things in it fit together16:26
j_vtoo much magic behind the scenes, with autotools, no doubt about it16:51
*** Romster has quit IRC18:31
*** Romster has joined #crux-devel18:35
*** onodera has joined #crux-devel21:00
*** Romster has quit IRC21:09
*** Romster has joined #crux-devel21:10
*** onodera has quit IRC23:33

Generated by 2.14.0 by Marius Gedminas - find it at!