<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
30
00:03 uriah joined
00:07 blackwind_123 joined
00:16 blackwind_123 joined
00:22 blackwind_123 joined
00:29 blackwind_123 joined
00:38 blackwind_123 joined
00:42 rbd joined
00:56 Emperor_Earth joined
01:03 dirac1 joined
01:34 fnlkj joined
01:44 xsteadfastx joined
01:47 MH0815 joined
01:47 s33se joined
02:17 dirac1 joined
02:29 kl3_ joined
02:33 blackwind_123 joined
02:40 czart__ joined
02:42 s33se joined
03:04 mguentner joined
03:06 blueness joined
03:09 mdillon joined
03:36 mguentner2 joined
04:22 ryonaloli joined
04:24 atomi joined
04:25 ryonaloli joined
04:26 urda joined
04:36 greguu joined
05:05 fabled joined
05:26 atomi joined
05:28 atomi joined
05:30 atomi joined
05:45 IRCFrEAK joined
05:47 IRCFrEAK left
05:56 ostera joined
06:06 grayhemp joined
06:12 kahiru joined
06:24 cyteen joined
06:40 mdillon joined
06:41 ostera joined
06:47 fnlkj_ joined
06:54 ostera joined
07:02 blueness joined
07:05 schndr_ joined
07:08 ostera joined
07:19 tru_tru joined
07:21 ostera joined
07:22 stwa joined
07:26 kazblox joined
07:33 sparklyballs joined
07:35 ostera1 joined
07:38 cyborg-one joined
07:48 ostera1 joined
08:00 gogoprog joined
08:02 ostera1 joined
08:09 cyteen joined
08:16 ostera1 joined
08:20 sirnaysayer joined
08:21 cyteen joined
08:29 ostera1 joined
08:39 marcelius joined
08:43 royger joined
08:43 schndr_ joined
08:43 ostera1 joined
08:48 MDrights joined
08:56 ostera2 joined
09:04 cyteen_ joined
09:06 xsteadfastx joined
09:10 ostera2 joined
09:23 ostera2 joined
09:25 rollniak joined
09:37 ostera2 joined
09:37 fnlkj joined
09:39 ncopa joined
09:39 ncopa joined
09:51 ostera2 joined
09:54 atomi joined
10:04 ostera2 joined
10:12 kl3 joined
10:14 fekepp joined
10:18 ostera2 joined
10:31 ostera2 joined
10:32 blueness joined
10:45 ostera2 joined
10:56 sirnaysayer joined
10:59 ostera2 joined
11:07 atomi joined
11:12 ostera2 joined
11:26 ostera2 joined
11:26 Skele joined
11:39 ostera2 joined
11:47 ryonaloli joined
11:53 ostera2 joined
12:00 blueness joined
12:06 ostera2 joined
12:10 schndr_ joined
12:18 gromero joined
12:20 ostera2 joined
12:23 blueness joined
12:26 blueness joined
12:31 farosas joined
12:34 ostera2 joined
12:35 blackwind_123 joined
12:36 medber joined
12:47 ostera2 joined
13:01 ostera2 joined
13:10 tkharju joined
13:14 ostera2 joined
13:27 MDrights joined
13:28 ostera2 joined
13:28 slowpak joined
13:29 kl3 joined
13:31 DSyndrome joined
13:33 pidsley joined
13:38 mosez joined
13:41 ostera2 joined
13:44 DSyndrome joined
13:55 ostera2 joined
14:06 blueness joined
14:09 ostera2 joined
14:22 Meths joined
14:22 ostera2 joined
14:28 ncopa joined
14:28 ncopa joined
14:29 Meths joined
14:31 lesion joined
14:35 Meths joined
14:35 ncopa joined
14:35 ncopa joined
14:36 ostera2 joined
14:39 stwa joined
14:49 ostera2 joined
14:56 Meths joined
15:03 ostera2 joined
15:06 Meths joined
15:09 ncopa joined
15:09 ncopa joined
15:13 Meths joined
15:16 ncopa joined
15:16 ncopa joined
15:17 ostera2 joined
15:24 Meths joined
15:25 LouisA joined
15:28 tmh1999 joined
15:30 ostera2 joined
15:31 minimalism joined
15:35 Berra joined
15:44 ostera2 joined
15:51 mmlb joined
15:51 Meths joined
15:57 ostera2 joined
16:10 Meths joined
16:11 ostera2 joined
16:16 Meths joined
16:21 Meths joined
16:25 ostera2 joined
16:27 Meths joined
16:30 grayhemp joined
16:33 Skele joined
16:37 rollniak joined
16:38 ostera2 joined
16:40 atomi_ joined
16:41 Meths joined
16:48 tmh1999 joined
16:52 ostera2 joined
16:54 grayhemp joined
17:01 tkharju joined
17:02 gopar joined
17:05 Meths joined
17:05 ostera2 joined
17:10 dlaube joined
17:11 cyteen joined
17:15 Meths joined
17:18 kazblox2 joined
17:19 ostera2 joined
17:20 Meths joined
17:21 cyborg-one joined
17:27 Meths joined
17:32 ostera2 joined
17:33 pidsley joined
17:34 grayhemp_ joined
17:39 Meths joined
17:43 gopar joined
17:44 gopar joined
17:46 ostera2 joined
17:46 grayhemp joined
17:49 mnp_ joined
17:49 <mnp_> greets
17:50 <mnp_> we're having trouble finding anything about alpine licenses, eg, busybox, when distributing alpine containers
17:50 Meths joined
17:50 <mnp_> has this bene written up anywhere?
17:51 <Xe> mnp_: https://busybox.net/license.html https://www.musl-libc.org/intro.html
17:51 <mnp_> yeah, we're aware of those
17:51 <mnp_> thinking higher level, eg alpine itself?
17:51 <Xe> sec
17:52 <mnp_> lots of distros have a /usr/share/licenses directory to handle informing the user
17:52 <Xe> http://pkgs.alpinelinux.org/package/edge/main/aarch64/alpine-baselayout says gpl2 for at least the base layout, the packages it depends on will tell you what else makes up the base system
17:53 <mnp_> i see
17:53 <Xe> http://pkgs.alpinelinux.org/package/edge/main/aarch64/apk-tools apk seems to be GPL2
17:53 <Xe> my understanding is that the license text is not shipped to the disk to save space
17:54 <mnp_> i don't see anything in the repos either, am i missing it?
17:55 <Xe> https://github.com/alpinelinux/aports/blob/master/main/apk-tools/APKBUILD#L23
17:55 <Xe> also
17:55 <mnp_> so i guess that's pkg-by-pkg basis for all the apks
17:56 <Xe> random file in apk-tools: https://git.alpinelinux.org/cgit/apk-tools/tree/src/add.c#n1
17:56 <TBB> grep -e ^L:/lib/apk/db/installed
17:56 <TBB> and
17:56 <TBB> add a space between the : and the /lib part
17:57 <mnp_> yeah, that's good for cataloging pkgs
17:58 <mnp_> github usually bugs you for a top-level LICENSE file
17:59 kazblox joined
17:59 <mnp_> if I wanted to submit a PR to clarify licenses, should it go to the github repo?
18:00 ostera2 joined
18:02 sergey_ joined
18:09 gopar joined
18:11 Meths joined
18:13 ostera2 joined
18:17 grayhemp_ joined
18:18 grayhemp_ joined
18:20 ogres joined
18:27 ostera2 joined
18:41 ostera2 joined
18:41 Ganwell joined
18:41 john51_ joined
18:42 blueness joined
18:50 ahrs joined
18:56 Meths joined
19:04 uriah joined
19:05 grayhemp joined
19:06 Meths joined
19:08 Drece joined
19:10 Drece left
19:11 Meths joined
19:12 kazblox joined
19:38 laj joined
19:42 blueness joined
19:47 tmh1999 joined
19:48 blueness joined
20:18 orbiter joined
20:19 grayhemp joined
20:21 tmh1999 joined
20:23 gopar joined
20:56 Nobabs27 joined
21:01 grayhemp joined
21:08 wonton joined
21:16 aw1 joined
21:22 grayhemp joined
21:26 untoreh joined
21:28 <untoreh> mkinitfs does not copy some libraries when the root has been usrmoved
21:28 <untoreh> the targets of symlinks don't get copied leaving some links hanging
21:31 <TemptorSent> untoreh: Can you give a bit more detail on what's hanging and how you got it that way? I'm working on rewrite of the mkinitfs scripts.
21:35 <untoreh> https://pastebin.com/raw/ZXLEpRyy
21:36 <untoreh> I mean the usr merge, moving /bin /sbin /lib* in /usr and linking /bin -> /usr/bin etc
21:37 blueness joined
21:37 <TemptorSent> untoreh : Ahh, not surprising with the current implementation, since it's globbing in the base filesystem.
21:39 <TemptorSent> untoreh: Okay, so what is linked where exactly? ls -ld /* /usr/*
21:40 <TemptorSent> untoreh: But clearly you're not getting the libs you need...
21:40 <untoreh> the changes are just these https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
21:41 <TemptorSent> First problem -- it relates to systemd :P
21:42 <untoreh> it's just a change for making an ostree setup, not really much with systemd
21:42 <untoreh> if you can directly the support for ostree in the init script that would be nice
21:42 <TemptorSent> honestly, I find it idiotic, as it breaks the entire reason for the seperation in the first place!
21:43 <untoreh> directly add*
21:43 <Shiz> the entire separation is silly
21:43 <Shiz> so i don't disagree
21:43 <TemptorSent> /bin and /sbin should work without /usr mounted, as /usr is often on another filesystem or even remote!
21:43 <Shiz> 'often' being in reality 'never'
21:44 <Shiz> :p
21:44 <TBB> not anymore :D
21:44 <Shiz> the original reason was boot disks being small
21:44 <Shiz> or at least, too small to host all system binaries
21:44 <TemptorSent> Split configs e something I do regully still!
21:44 <Shiz> this is very evidently not the case these days
21:45 <TemptorSent> Shiz: It's not just th (WTF? I just lost my lowercAse A key.
21:46 <TBB> you were blaspheming on systemd
21:46 <TemptorSent> BRB, my keybrd won't let me type lower cAse A Anymore.
21:46 <Shiz> lol
21:46 <TBB> fear the revenge of the men in red hats
21:47 <TemptorSent> *LOL* YeAh, wouldn't be the first time I hAd someone go After me.
21:47 TemptorSent joined
21:49 <TemptorSent> That was weird :P
21:49 <TemptorSent> Anyway, I regularly run systems with my root mounted RO and /usr mounted later.
21:49 orbiter joined
21:49 <TemptorSent> (helps to be in the right channel too :P )
21:49 <untoreh> ostree initramfs support https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#booting-and-initramfs-technology
21:50 <Shiz> imo separate /usr is deprecated by initramfs
21:51 <TemptorSent> Shiz: Only where people have totally ignored the fact that /bin and /sbin are supposed to be the minimal tools.
21:51 <Shiz> i don't see how that changes anything
21:51 <Shiz> it's supposed to be the minimal tools to get your system booted up
21:51 <Shiz> exactly what initramfs is for
21:51 <TemptorSent> Fedora is justifying it based on the fact that they already have ~450MB in the root directory.
21:52 <TemptorSent> Shiz: No, I can USE a system with just / mounted.
21:52 <Shiz> good for you, but that's not what it was "supposed" for
21:52 <Shiz> :p
21:53 <TemptorSent> Shiz: Actually, that's exactly what it was for, and I used it for that purposed extensivley back in the SunOS days all the way to present.
21:54 <Shiz> well, sunOS did about everything wrong, so i'm not surprised by that
21:54 <Shiz> at all
21:54 <TemptorSent> Shiz; When you're running a system that needs to boot even if it can't mount it's net mounts and you're working in a constrained environment, it's quite helpful.
21:55 <Shiz> that's what initramfs is for, again
21:55 <TemptorSent> If / was only ever mounted as the tempfs (which I do VERY frequetly), then usr is broken if not mounted from some media.
21:55 <TemptorSent> Shiz: rootfs IS a tmpfs
21:56 <TemptorSent> Shiz: Anything you mount stacks on top of that.
21:56 <Shiz> https://linux.die.net/man/8/pivot_root
21:56 <TemptorSent> Shiz: So if my initfs comes up and my netmount doesn't, I'd like to actually be able to use it.
21:56 <TemptorSent> Shiz: Not used.
21:56 <Shiz> used by all mkinitramfses out there
21:56 <Shiz> :)
21:56 <TemptorSent> Shiz: In fact, not even enabled in our BB
21:57 <Shiz> i'm saying your specific boot situation is not relevant enough to justify a separate /usr
21:57 <Shiz> since the same situation can be done by initramfses just fine
21:57 <TemptorSent> Shiz: No, type busybox | grep pivot_root
21:57 <TemptorSent> Shiz: You can't magically make a netdev fs mount when I'm running out of ram from something booted off rom!
21:58 <Shiz> ?
21:58 <Shiz> also you're right, it's switch_root
21:58 <Shiz> :)
21:58 <TemptorSent> Shiz: Bootstrap on many embedded projects is flash chip.
21:58 <Shiz> yes, and?
21:59 <Shiz> https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n673
21:59 <Shiz> btw
21:59 <TemptorSent> Shiz: Right, which has much different side-effects than pivot root, and essentially just mounts over the top.
22:00 <Shiz> it does not
22:00 <TemptorSent> Shiz: Yes, it does. Read the kernel docs.
22:00 <Shiz> this is not a kernel function
22:00 <Shiz> it's a user-space utility
22:00 <TemptorSent> The switch_root semantics are kernel-derrived.
22:00 <Shiz> nope
22:01 <Shiz> pivot_root(2) exists, but its main use is initrd, not initramfs
22:01 <Xe> wait, initrd != initramfs?
22:01 <Shiz> which have different semantics as to where to tempfs is stored and how its created/destroyed
22:01 <Shiz> yes
22:01 <Xe> TIL
22:01 <Shiz> initrd is a very old kernel mechnaism nobody should use
22:01 <TemptorSent> So what happens with switch_root is that it mounts a new filesystem, wipes the old one, and does a chroot.
22:01 <Shiz> often when people refer to initrd they mean initramfs
22:02 <TemptorSent> Shiz: Correct, and with the initrd went the actual change of the root fs.
22:02 <Shiz> TemptorSent: you're wrong btw
22:02 <Shiz> you forget one important step
22:02 <Shiz> the move mount
22:02 <TemptorSent> pivot_root actually changed the location of the root, while switch_root simply does a chroot.
22:02 <Shiz> wrong
22:02 <Shiz> switch_root move-mounts the new fs to /
22:02 <TemptorSent> Shiz: The move mount is only for convenience.
22:03 <Shiz> the location of the root is actually changed
22:03 <TemptorSent> Nope, other way around, it moves everything else to the new $sysroot, then does exec chroot $sysroot
22:03 <Shiz> you should probably read the busybox docs :)
22:03 <TemptorSent> Shiz: I have, at great lenght, as well as the kernel docs and source.
22:04 <Shiz> maybe we are just confusing terminology them
22:04 grayhemp joined
22:04 <Shiz> by moving the root i mean the proper rootfs is now at / and the old rootfs is gone in all meanings of the word
22:04 <Shiz> (mount presence, kernel memory, etc.)
22:04 <TemptorSent> Shiz: /dev/root remains mounted at /, and the rest of the system believe /sysroot is / because of the chroot call.
22:05 <Shiz> that is not true
22:05 <Shiz> since you don't chroot into /sysroot
22:05 <Shiz> you chroot into .
22:05 <TemptorSent> Shiz: Nope, it is EXPLICITLY stated that the rootfs remains regardless of what you do.
22:05 <Shiz> after the move-mount
22:05 <TemptorSent> REad the kernel docs.
22:05 <Shiz> TemptorSent: "Since initramfs is a ramfs, deleting its contents frees up the memory it uses."
22:05 <TemptorSent> Shiz: Actually you cd $sysroot; chroot . ; cd .
22:05 <Shiz> the old rootfs is gone.
22:06 <Shiz> TemptorSent: no.
22:06 <TemptorSent> Shiz: No, the CONTENTS may be gone, but the rootfs mount is NOT removed.
22:06 <Shiz> from busybox switch_root.c:
22:06 <Shiz> mount(".", "/", NULL, MS_MOVE, NULL)
22:06 <Shiz> xchroot(".");
22:06 <TemptorSent> Linus went on a very long rant about exactly how this all works.
22:06 blackwind_123 joined
22:06 <Shiz> you cd, then you move-mount, then you chroot, then you cd .
22:07 <TemptorSent> move-mount doesn't do anything magical, it is essentially the same as doing a bind/unmount
22:08 <TemptorSent> So it doesn't move the rootfs, it just moves anything you happened to have mounted on top of /.
22:09 <TemptorSent> You could just as easily switch root without deleting anything, but it'd waste the ram and not be terribly useful.
22:09 grayhemp joined
22:10 <Shiz> 00:04:46 TemptorSent │ Shiz: /dev/root remains mounted at /, and the rest of the system believe /sysroot is / because of the chroot call.
22:10 <Shiz> immunity:~# cat /proc/mounts | grep -F ' / '
22:10 <Shiz> /dev/vda3 / ext4 rw,relatime,data=ordered 0 0
22:10 <Shiz> ? :p
22:11 <TemptorSent> Shiz: So, where's /dev/root?
22:11 <Shiz> nowhere
22:11 <Shiz> immunity:~# grep /dev/root /proc/mounts
22:11 <Shiz> immunity:~#
22:11 <TemptorSent> Shiz: Not according to Linus or the source!
22:12 <Shiz> embargo:~$ mount | grep ' / '
22:12 <Shiz> /dev/mapper/enc_root on / type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
22:12 <Shiz> embargo:~$ grep /dev/root /proc/mounts
22:12 <Shiz> embargo:~$
22:12 <Shiz> replication on another system that does LUKS so you know it needs an initramfs to boot
22:12 <Shiz> :)
22:12 <TBB> I seem to remember something about systemd based systems being able to return to their initramfs
22:13 <TBB> in other words, shutting down the entire system to the pre-switchroot state
22:13 <Diftraku> only place I found /dev/root was on my Asus router running AdvancedTomato
22:13 <Shiz> i think /dev/root is an initrd artifact...
22:14 <Diftraku> granted, most ppaces I check run systemd and ubuntu/fedora
22:14 <TemptorSent> Nope, it's where the kernel mounts the device it boots from
22:14 <Shiz> # ls -lh /dev/root
22:14 <Shiz> lrwxrwxrwx 1 root root 4 Mar 28 14:59 /dev/root -> vda3
22:14 <Shiz> :p
22:14 <Shiz> # ls -lh /dev/root
22:14 <Shiz> ls: /dev/root: No such file or directory
22:14 <Shiz> on the other node
22:14 <Shiz> and yes, /dev is a devtmpfs
22:14 arenstar joined
22:15 <TemptorSent> The device is just a link to it, the fs is the one the kernel mounts
22:15 <Shiz> well
22:15 <Shiz> not according to /proc/mounts
22:15 <Shiz> :)
22:16 <TemptorSent> Like I said, read the kernel source.
22:17 <TemptorSent> You can mount over the top of it and chroot so you're referring to a differnt location as /, but all that does is hide it, since its dirent isn't accessible under the new root.
22:20 <TemptorSent> Since we ran the chroot with exec, we see all mounts relative to the $sysroot directory and no longer see rootfs. Try it using rdinit=/bin/sh
22:20 gromero_ joined
22:20 <TemptorSent> To verify, setup a chroot, then take a look at /proc/$pid/mountinfo for your shell.
22:22 <TemptorSent> But the point is that having / be the minimal system, while /usr contains the 'normal' system is especially useful to something like alpine if we do it right.
22:22 <Shiz> nope.
22:23 <TemptorSent> That gives us minimal, possibly cut-down utilities in /, while supporting fully-functional utils in /usr
22:24 <TemptorSent> And bringing BACK /usr/x11 would allow us to put libs/bins built for use with X there while not contaminating the rest of the namespace.
22:24 <Shiz> oh HELL no
22:24 <TemptorSent> Shiz: Okay, you maintain three different versions of the same package and keep them from conflicting when they all have the same names.
22:25 <Shiz> i don't think alpine is what you're looking for, then
22:25 <Shiz> have you considered gobo linux
22:25 <Shiz> :p
22:25 <TemptorSent> I don't want X11 deps in my system unless I'm using X, thanks.
22:25 <Shiz> me neither, so i don't install shit that uses X
22:25 <Shiz> pretty easy
22:26 <TemptorSent> Yeah, now what do you do with libs that have X as an optional dep.
22:26 <Shiz> you split them up
22:26 <TemptorSent> Shiz: You have to compile them both ways.
22:26 <Shiz> you realize apk has replaces= and conflicts=
22:26 <Shiz> :p
22:27 <TemptorSent> Shiz: Now, you have say libgd built with X and libgd built without X
22:27 <TemptorSent> How do you make sure you have the one you need?
22:27 <Shiz> you install the one you need
22:27 <TemptorSent> Shiz: Easy way, if you're using X, include the /usr/x11 directory
22:28 <TemptorSent> Shiz: Yeah, let me know how many unresolved symbols pop up when someone has the wrong version
22:28 <Shiz> let's make subhierarchies for all possible package features!
22:28 <Shiz> TemptorSent: they won't?
22:28 <Shiz> because the X version will rely on libX11 or xcb
22:28 <Shiz> or whatever it uses
22:28 <Shiz> dependencies are not hard
22:28 <Shiz> (overly, anyway)
22:28 <TemptorSent> Shiz: What I mean is how do you know whether you're using a version that supports X or not?
22:28 <Shiz> you check # apk info?
22:29 <TemptorSent> Shiz: At RUNTIME?
22:29 <Shiz> please don't highlight me every line
22:29 <Shiz> it's rather annoying
22:29 <Shiz> as opposed to?
22:29 <TemptorSent> Sry.
22:29 <Shiz> by 'you' i'm presuming 'the user'
22:30 <TemptorSent> User usually, yes.
22:30 <Shiz> any package that would rely on the X11 version of libgd would depends= on it
22:30 <Shiz> the user, yes they can just check apk info?
22:30 <Shiz> what is wrong with that
22:30 <TemptorSent> Do you run apk-info $somedep before you run say 'convert blah.jpg blah.png'
22:31 <Shiz> your point is utterly lost on me
22:31 <Shiz> no, because i'm expecting it to work, just as i would for that
22:31 <TemptorSent> And realize that the version of imagemagick you're using is compiled against X.
22:31 <TemptorSent> Yeah, real problem that came up was a request to enable X for imagemagick :)
22:32 <Shiz> well
22:32 <Shiz> alpine is not gentoo
22:32 <Shiz> we're not gonna offer unlimited different packages for different option configs
22:32 <Shiz> in the first place
22:32 <TemptorSent> No, but it could take a few good hints.
22:32 <Shiz> i'd rather it not
22:32 <TemptorSent> Shiz: X vs not is a pretty big split.
22:32 <Shiz> no less big than libintl vs not
22:33 <TemptorSent> Shiz: Much larger in terms of deps/installed size.
22:33 <Shiz> i don't see any reason for imagemagick to have X support in the first place
22:33 <Shiz> so my argument would be for disabling it
22:33 <TemptorSent> And pretty clear in most cases, although there are a few packages that use X that don't actually need the head.
22:34 <Shiz> and good software should already have a split between gui/non-gui components
22:34 <TemptorSent> Shiz: Because it's necessary to use it in X configurations properly.
22:34 <Shiz> sounds nonsense
22:34 <TemptorSent> Shiz: I believe it actually interacts with the internals of X when enabled for things such as setting root image, grabbing frame data, etc.
22:34 <Shiz> unless you mean stuff like import(1)
22:34 <Shiz> which should be cleaned anyway
22:35 <Shiz> and never used
22:35 <Shiz> i mean, imagemagick should be cleansed, but that especially
22:35 <TemptorSent> Shiz: As well as color management, font rendering, etc
22:35 <Shiz> doesn't need it for that
22:35 <Shiz> i can promise you that
22:35 <TemptorSent> Shiz; Yes, actually it does if you're using it in X for graphics.
22:35 <Shiz> the only thing it needs X for are features that are relevant to X
22:36 <Shiz> which are not relevant
22:36 <Shiz> and often bad
22:36 <Diftraku> why would you need monitor color management if you are converting pictures with imagemagick?
22:36 <TemptorSent> Shiz: If you break imagemagick under X for people who need it, you get to deal with the angry mob :)
22:37 <TemptorSent> Diftraku: Because the color management is part of the equation for conversion.
22:37 <Shiz> sure, i'll tell them to use better software for whatever they're trying to use imagemagick for that is relevant to X
22:37 <Diftraku> but you don't need X for that?
22:37 <Shiz> yeah, you don't.
22:37 <TemptorSent> Diftraku: It's using the CMS for your monitor to set the gamma/curves.
22:38 <Diftraku> I sure as hell don't need X on a server doing conversions with imagemagick
22:38 <TemptorSent> I'm not aware of CMS that works without the X server.
22:38 <Shiz> if it's doing that, it's 100% doing stuff wrong
22:38 <TemptorSent> Shiz: Okay, how would you proposed to do CMS?
22:38 <Diftraku> why would you need X to do the conversion if you are never displaying it?
22:38 <Shiz> not in imagemagick
22:38 <Shiz> presto
22:39 <Shiz> CMS is part of the rendering system
22:39 <Shiz> not of the image conversion system
22:39 <Shiz> so whatever image viewer you use
22:39 <Shiz> or video player
22:39 <TemptorSent> Diftraku: Because you're working with files in your colorspace and trying to convert them to a standard colorspace.
22:39 <Shiz> i see the wtf here
22:39 <Diftraku> sure, they have colour spaces but I don't need the monitor colour management for it
22:39 <Shiz> it's having files in a monitor colorspace but not having the colorspace info available otherwise
22:40 <Diftraku> when the damn tool does it internally
22:40 <TemptorSent> CMS is MUCH more than that - it's not about output to the screen, it's about matching across multiple scanners, camera, monitors, printers, etc.
22:40 <Shiz> except through X
22:40 <TemptorSent> And nailing them all to a pantone or other spec using a calibration tool.
22:41 <Shiz> and it simply assuming input images are in your magical monitor monorspace it gets from X are even more of a WTF
22:41 <TemptorSent> Try some 4 color DTP layouts and see how many bluelines it takes before you get something that even comes close to what you're seeing.
22:42 <Shiz> TemptorSent: convert can read .icc files through -profile
22:42 <Shiz> no X11 support needed
22:42 <Shiz> or +profile
22:42 <TemptorSent> Shiz: It works like this: You create content on your workstation, which has your monitor - then you want to send those files for rendering in some other application on another machine.
22:42 <Shiz> yes
22:42 <Shiz> so what you should do is send along your monitor .icc
22:43 <Shiz> or convert it locally using that .icc
22:43 <Shiz> not with magic info obtained from X that may or may not be accurate
22:44 <TemptorSent> Shiz: The CMS and the X server need to work together to get the proper information.
22:44 <Shiz> no...
22:44 <Shiz> .icc
22:44 <Shiz> again
22:44 <TemptorSent> Shiz: the .icc profile is only part of the picture.
22:44 <Shiz> it really isn't...
22:44 <Shiz> .icc contains everything you need to normalize the image to a standard Adobe RGB/sRGB/what-have-you profile
22:45 <TemptorSent> Shiz: That's nice, but CMS isn't just about RGB/sRGB -- that's easy!
22:45 <TemptorSent> Shiz: I work in CMYK, CMmYyKk, HSB, LAB, and spot-color.
22:46 <Shiz> and?
22:46 <Shiz> the point is removing the device-dependence
22:46 <Shiz> whatever you want to do with it afterwards has little relevance to the monitor
22:46 <Shiz> :p
22:46 ScrambledAuroras left
22:46 <TemptorSent> Shiz: And how are you supposed to get what you expect if you're not running CMS in your x-server?
22:47 <Shiz> by using the damn .icc to convert it to a standard RGB profile
22:47 <Diftraku> does imagemagick actually depend on libX11 beyond some GUI tooling it might have?
22:47 <TemptorSent> Shiz: The display OUTPUT needs to use the icc
22:47 <Shiz> whatever renderer you need can then apply image correction again if it needs to to display on your monitor
22:47 <TemptorSent> Diftraku: It can use the font server and color management, but doesn't need it
22:48 <Diftraku> but does it depend on libX11 on a modern distro
22:48 <Diftraku> that's what I'm curious about
22:48 <TemptorSent> Shiz: And you know which monitor it's on at the moment HOW without the Xserver?
22:48 <TemptorSent> Diftraku: In many cases, yes I believe.
22:48 <Diftraku> because purely command-line tools running on a headless server with only a TTY shouldn't install X11
22:49 <Diftraku> and I could find X11 in imagemagicks deps on xenial
22:49 <Shiz> TemptorSent: the
22:49 <Shiz> icc
22:49 <Shiz> profile
22:49 <Shiz> you pass it
22:49 <TemptorSent> Diftraku: That was my original point, and why I'm a fan of sticking X stuff back in /usr/x11 where it belongs.
22:49 <Shiz> Diftraku: it doesn't
22:49 <Shiz> modern imagemagick in distros does not depend on x11
22:49 <Diftraku> then why are we blabbing about X11 and imagemagick?
22:49 <Diftraku> :3
22:49 <Shiz> because TemptorSent is trying to justify /usr/x11
22:49 <Shiz> :p
22:50 <TemptorSent> Shiz: Okay, I run 3-4 monitors and move my work between them freely.
22:50 <Diftraku> but shouldn't they use something that actually depends on X11 for those arguments?
22:50 blueness joined
22:50 <TemptorSent> Shiz: So which color profile is display supposed to use now?
22:50 <Shiz> TemptorSent: ?
22:50 <Shiz> what color profile for display output is automatically done by your renderer
22:50 <Shiz> if your program SAVES display-specific profile pics that is a wtf
22:50 <Shiz> Diftraku: perhaps
22:51 <Diftraku> also, if we do go for /usr/x11 we should also make /usr/mir and /usr/wayland
22:51 <TemptorSent> Diftraku: My argument was that the imagemagick libs built without X belong in /usr/* while those built with X would be better off in /usr/x11/*
22:51 <TemptorSent> Diftraku: Actually, that would be sane imho.
22:52 <TemptorSent> Shiz: I'm talking about workflow, which include displaying images on your local system and converting them to a foreign profile, then previewing the expected output where possible.
22:52 <Shiz> and both displaying and previewing should be color-corrected by your renderer
22:52 <Shiz> not the thing that converts it
22:53 <TemptorSent> Shiz: ImageMagick IS the renderer!
22:53 <Shiz> and that is where the issue is
22:53 <Shiz> imagemagick shouldn't be a renderer
22:53 <Shiz> there's better shit for that
22:53 <TemptorSent> Shiz: So what should?
22:53 <Shiz> your image viewer
22:53 <TemptorSent> Shiz: Um, that's nice, except that's what I use imagemagick for.
22:54 <Shiz> well
22:54 <Shiz> get a better image viewer
22:54 <TemptorSent> Shiz: Find me one that I can do everything I can do with 'convert' and 'display'
22:54 <Shiz> convert is not a renderer.
22:54 <TemptorSent> That's what it's designed to do, not much else out there that does.
22:54 <Shiz> the image conversion and rendering steps are distinc and separate
22:55 <TemptorSent> Shiz: Actually, that's exactly what it is.
22:55 <Shiz> as rendering adjusts for local configuration, like your monitor colors
22:55 <TemptorSent> Shiz: It renders from one format to another, applying whatever kernels you want.
22:55 <Shiz> yes, and local kernels should be separate and not represented in the file on-disk
22:56 <Shiz> that's like escaping html and then putting it i na database
22:56 <Shiz> local kernels should be applied just-in-time in the viewing phase
22:56 <TemptorSent> Shiz: By kernels, I'm referring to in the image processing term, not the linux kernel :)
22:56 <TemptorSent> Shiz: Transforms/filters/etc.
22:56 <Shiz> ... why would you assume I thought otherwise?
22:57 <Shiz> I know what a kernel is, I do image processing and rendering too
22:57 <TemptorSent> Just making sure the overloaded term wasn't leading to confusion.
22:58 <TemptorSent> But using a framebuffer as a target and rendering to it is the cleanest way of doing many of the manipulations.
22:59 <Shiz> not particularly
22:59 <TemptorSent> So unless you want to kill framebuffers too, it's helpfull to have a framebuffer that knows its color context.
22:59 <Shiz> and by that
22:59 <Shiz> i mean a virtual framebuffer is more than fine too
22:59 <Shiz> you don't at all need X11 framebuffers for this
22:59 <TemptorSent> Again, I have an image spanning a couple monitors, how does it get displayed?
23:00 <TemptorSent> It needs both the colorspace for the image and the colorspace for both monitors
23:00 <Shiz> you're again talking about displayin
23:00 <TemptorSent> Only part of which I'd expect imagemagick to handle.
23:00 <Shiz> im arguing the entire time imagemagick should not handle this
23:01 <TemptorSent> Yes, because I'm talking about a workflow where imagemagick is rendering images to a framebuffer or using the display tool
23:01 <Shiz> yes, and i'm saying it has no business doing that
23:01 <Shiz> again
23:01 <TemptorSent> Something needs to tell the display server which color profile the source is.
23:01 <TemptorSent> So what does?
23:02 aw1 joined
23:02 <TemptorSent> ImageMagick (and GraphicsMagic) are the tools that everything else is built on for such usese.
23:02 <Shiz> your image viewer
23:02 <Shiz> 'everything else'?
23:02 <Shiz> i literally only see IM and GM used because of convert(1)
23:02 <TemptorSent> No 'image viewer' per-se involved.
23:03 <Shiz> and the bindings
23:04 <TemptorSent> Oh, and I'm already not happy about all the deps it drags in on a headless system dbus? Avahi? really?
23:04 <TemptorSent> Take a look at 'display'
23:05 <TemptorSent> And at the more useful features of convert, where it can basically build an image on the fly.
23:10 <TemptorSent> Basically, I'd like to have all those whiz-bang feature available only when I need them, and install a more minimal tool by default.
23:13 uriah joined
23:15 fnlkj joined
23:22 Nobabs27 joined
23:24 ostera joined
23:32 ostera joined
23:34 blueness joined
23:34 fnlkj joined
23:38 fnlkj joined
23:56 <Nobabs27> I installed ngircd, all I get is "connection timed out" when trying to connect...
23:59 ostera joined