=== almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === yofel_ is now known as yofel [00:54] good evening :) [07:47] good morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === dk_ is now known as Guest35783 === al-maisan is now known as almaisan-away [10:59] My package installs file into /etc directory but I need this file to have different contents on i386 arch and different contents on amd64. I am not sure how to approach this problem. Any hints? [11:04] why? [11:11] tumbleweed: it is a configuration file that has to contain *full path* to libcrypto. Its location is /usr/lib/i386-linux-gnu/libcrypto.so on i386 and /usr/lib/x86_64-linux-gnu/libcrypto.so on amd64. [11:16] jariq: why are you not relying on the linker to find libcrypto for you? [11:22] funkyHat: I would in general but it is LoadFile directive of Apache HTTPD that requires "absolute path or relative to ServerRoot" and patching httpd to rely on linker is no go here. [11:24] So I was thinking about using "if" statement with architecture (or something similar) in rules file, but I was unable to find an example or any documentation that would support this idea. [11:30] jariq: if you really need to hard code the path to libcrypto and include it in httpd config, why not include a file outside of /etc instead, and build different packages for each arch? I'm sure there is a less weird way of going about this whole thing though [11:44] funkyHat: Could you please elaborate on "different packages for each arch"? Package with different name? [11:47] jariq: ok, so assuming this is a good idea, what's the problem? just generate the file during the build [11:47] ^this [12:08] jariq: you build a package for each arch ("Architecture: any" in debian/rules) and not an Arch:all package [12:10] or, I suppose, you generate the config file in postinst, but failure in maintainer scripts breaks users' systems... [12:13] And users that use puppet or copy config files to a new system or migrate from 32bit to 64bit systems have problems too, which is where my suggestion stemmed from. [12:16] Generating the file during the build: How do I know in rules file for which platform is it building? is there any variable I can test? [12:18] Different package for different platform: Is there any convention on naming resulting packages? I.e package32 for i386 and package64 for amd64? [12:23] jariq: you run dpkg-architecture -qDEB_BUILD_MULTIARCH [12:23] jariq: no, the package is the same name for all architectures [12:24] obviously the bash package on amd64 has a different binary for /bin/bash, as the bash package on i386 [12:26] I am going to give a try to dpkg-architecture. Thank you for suggestions. [12:27] oops, I meant DEB_HOST_MULTIARCH [12:34] tumbleweed: DEB_HOST_MULTIARCH works for me. Thank you very much. === dk is now known as Guest66626 === emma_ is now known as emma === highvolt1ge is now known as highvoltage === yofel_ is now known as yofel === nenolod is now known as mogri [21:43] xnox: Thanks for getting .05 in =) [23:49] ESphynx: note the bug report I filed though ;-) [23:50] xnox: noted ;) [23:50] xnox: I promise to do it for next update :P [23:50] xnox: btw that's not new with this package, but I guess you caught it cause I took out the giflib-dev build dep :P [23:50] (which wasn't used) [23:51] ESphynx: I'm not gonna tell you how/why I spotted it, just to keep you in the dark and myself on the edge ;-) [23:51] that should keep you more disciplined =))))))) in an nice way. [23:51] lol [23:52] as for taking out the deps folder, well again I'm ok with it for the orig tarball [23:52] but not for the tarball that you'd be grabbing off the GitHub tag [23:52] (like the other few things taht are already 'omitted' in the debian .orig tarball) [23:53] that's fine?