<    March 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 31
00:21 Emperor_Earth joined
00:32 Emperor_Earth_ joined
01:34 blueness joined
02:25 Emperor_Earth_ joined
02:29 Emperor_Earth_ joined
02:33 s33se joined
03:13 Emperor_Earth_ joined
03:25 Emperor_Earth_ joined
05:20 Emperor_Earth_ joined
05:34 blueness joined
05:34 Emperor_Earth_ joined
06:53 <TemptorSent> Good evening -- for anyone interested I just pushed the lated revision of my rewrite of mkimage to github. See https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
06:53 <TemptorSent> Now supports generating ssh keys and autostart features/overlays!
06:59 Emperor_Earth_ joined
07:03 <pickfire> I am planning to create ranger APKBUILD, should I separate rifle as another package?
07:30 <TemptorSent> *shrugs* Um, what's ranger? ;)
07:32 <TemptorSent> Oh, just looked that up -- kinda cool :)
07:37 <pickfire> Huh TemptorSent you really didn't know ranger?
07:38 <pickfire> It's a cool file manager? I feel like it's better than vifm.
07:38 <pickfire> :)
07:38 <pickfire> I seldom use it but it is very useful.
07:39 <TemptorSent> Yeah, I've been a bit out of the loop.
07:40 <pickfire> TemptorSent: Should I separate the ranger.desktop as well?
07:40 <pickfire> Because *.desktop are totally useless for me.
07:41 <TemptorSent> *lol* Agreed, but the number of packages might get as long as the number of installed files at that rate :)
07:42 <TemptorSent> just blackhole the target directory perhaps?
07:43 <TemptorSent> ln -s /dev/null /path/to/desktop/target ;)
07:43 <TemptorSent> preceeded by rm -rf /path/to/destktop/target if necessary.
07:44 <TemptorSent> mount --bind /dev/null /path/to/target works too.
07:44 <pickfire> Oh
07:44 <pickfire> I didn't know I can do that.
07:45 <pickfire> I might just as well ln -s /dev/null /usr/share/doc/
07:45 <TemptorSent> *lol* It's a horrible, horrible thing to do.
07:45 <pickfire> How come?
07:45 <pickfire> I only read man pages.
07:45 <pickfire> I never cared /usr/share/doc (unless it is used by the applications like krita)
07:45 <pickfire> But it is a rare case
07:45 <pickfire> Taskwarrior uses them as well.
07:46 <TemptorSent> Mostly because when you're TRYING to install a doc and you can't figure out why it's not showing up, you'll bash your head into the wall for hours until you remember what you did.
07:46 <pickfire> Desktop files doesn't cost much space but /usr/share/doc sure does
07:46 <pickfire> TemptorSent: I install package-doc just for the man pages.
07:46 <pickfire> nothing else
07:46 <pickfire> :D
07:46 <TemptorSent> Try mounting a tmpfs to /usr/share/docs, that way things don't complain on install that they can't make the file/directory.
07:47 <pickfire> Oh
07:47 <TemptorSent> Yeah, I'd really like to see man pages separated from all the other docs. I NEED man pages, especialy on alpine where I need to figure out what the version of a tool I'm using actually supports.
07:47 <pickfire> I wanted that as well.
07:47 <pickfire> I bet I won't ever install -doc if there are -man
07:48 <TemptorSent> Lots of ways to deal with obnoxious directories you don't care about, depending on what's trying to write to them.
07:48 <pickfire> TemptorSent: But one thing, alpine had definitely loss a lot of man-pages.
07:48 <pickfire> TemptorSent: Maybe we do a feature request for -man?
07:49 <TemptorSent> mounting/unmounting a tmpfs does a good job of letting things work "normally", then making them disappear.
07:49 <pickfire> As well as that, .1.bz2 would be nice as well
07:49 <pickfire> TemptorSent: No, it doesn't
07:49 <TemptorSent> Yeah, the documentation situation needs some help.
07:49 <pickfire> Applications can't read
07:49 <TemptorSent> What do you mean applications can't read?
07:50 <pickfire> open("/usr/share/doc/blah/shit-is-gone", "r");
07:50 <pickfire> fprintf(stderr, "/usr/share/doc/blah/shit-is-gone cannot be found!");
07:51 <TemptorSent> Right, the tmpfs trick is mostly for handling things that install a bunch of crap in a dirctory you don't want.
07:51 <pickfire> The best thing -man
07:51 <TemptorSent> so you mount it, install the package, and unmount it.
07:51 <pickfire> No
07:51 <pickfire> That's troublesome, I wouldn't wanna mount tmpfs for /usr/share/doc
07:54 <TemptorSent> Add to .profile: apk-nodoc() { mount -t tmpfs tmpfs /usr/share/doc && apk $@ ; umount /usr/share/doc }
07:54 <TemptorSent> er, quotes on the $@ may be desirable.
07:55 <pickfire> Oh
07:55 andypost joined
07:55 <pickfire> Nice
07:56 <TemptorSent> *lol* Like I said, it's evil, but it works!
07:56 <pickfire> I would just alias that but it's not the correct way
07:56 <TemptorSent> Yeah, the alias doesn't do so well with the parameter in the middle of the string.
07:57 <TemptorSent> but you can alias apk=apk-nodoc
07:57 <TemptorSent> Then you're set. If you really want to install a package with docs intact, run /sbin/apk
07:58 <TemptorSent> A nice trick might be to allow a config option/variable that lets you set the tar transform/exclusion list.
07:59 <TemptorSent> Then apk could let you filter out / transform whatever you want pretty easily.
08:04 <TemptorSent> That's a project to delve into later -- maybe fabled to could take a quick look at the feasiblity? It should be pretty straightforward to pass through to tar.
08:17 <TemptorSent> Does anyone know if Bjoren Schilberg hangs out on here?
08:18 Emperor_Earth_ joined
08:19 <pickfire> TemptorSent: I have found a problem.
08:19 <pickfire> TemptorSent: ranger have doc
08:19 <pickfire> How? https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python
08:19 <pickfire> That site doesn't show how to do it with docs?
08:19 <pickfire> Or should I just not care about python2? Just go with python3.
08:27 <TemptorSent> Hmm, I really don't know the abuild format yet...
08:28 <TemptorSent> Can you easily make a seperate _docs() function to grab them?
08:28 <TemptorSent> Or are they intermeshed with the rest of the output?
08:29 <TemptorSent> is py-serial similar in structure by chance?
08:30 <TemptorSent> That looks like it brute-forces it reasonably well.
08:33 <TemptorSent> pickfire: Looking at it, it might be as easy as running "make DOCDIR="$subpkgdir/usr/share/docs/ranger" doc"
08:34 <pickfire> Nevermind, I had submitted that package.
08:34 <pickfire> I won't want troubles from py2 and py3
08:34 <pickfire> Just use python3
08:35 <pickfire> TemptorSent: If you want, add your name to the "Contributor"
08:35 <pickfire> ^^
08:35 <TemptorSent> Agreed. If you want to use python2, go ahead.
08:35 <TemptorSent> ?? Contributor on?
08:36 <TemptorSent> I don't see much reason to have a python2-ONLY system, so anyone using python should assume python3 is supported by default and python2 requires explicit dep.
09:05 Emperor_Earth_ joined
09:07 Emperor_Earth_ joined
09:20 gk_1wm_su joined
09:20 gk_1wm_su left
09:27 gk_1wm_su joined
10:14 <TemptorSent> Alright, time for me to call it -- g'night all!
10:19 Shiz joined
10:20 <yGweSm1OzVHe> sorry but py3 is a failed academic attempt which is now very similar to systemd is being pushed down the throats of everyone.
10:26 <Shiz> thats an impressive amount of nonsense in a single sentence
10:31 <asie> agreed
10:32 t0mmy joined
10:35 <yGweSm1OzVHe> why you think?
10:41 <pickfire> yGweSm1OzVHe: No
10:41 <asie> yGweSm1OzVHe: python 3 is not being pushed down anyone's throats
10:41 <asie> both 2 and 3 are readily available on pretty much any distro
10:41 <pickfire> python2 is going to die in 2020
10:42 <pickfire> Patchwork moderator: Please kill #3103
10:42 <algitbot> Bug #3103: acf-kamailio is broken - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/3103
10:42 <pickfire> Patchwork moderator: Please kill %3103
10:42 <algitbot> [alpine-aports] main/taskd: Add init scripts - Patchwork: http://patchwork.alpinelinux.org/patch/3103/
10:42 <pickfire> So confusing
10:43 <pickfire> TemptorSent: I mean just contribute by adding python2 subpackage to ranger and your name as well. I am currently using python3 only.
10:43 <yGweSm1OzVHe> asie: maybe your throat is less sensitive than mine
10:44 <pickfire> No need extra 100MB for nothing
10:44 <pickfire> yGweSm1OzVHe: https://pythonclock.org/
10:44 <asie> yGweSm1OzVHe: feel free to fork python 2 and maintain it if that's a problem for you
10:44 <asie> at least one person has done tht
10:44 <asie> that*
10:44 <pickfire> Yes
10:44 <yGweSm1OzVHe> that pythonclock is part of my throatpain
10:44 <pickfire> Haha :D
10:45 <pickfire> yGweSm1OzVHe gives me stomach pain
10:45 scadu joined
10:45 <* pickfire> laugh too much
10:45 <TemptorSent> pickfire: Oh, perhaps if I end up actually finding a use for python I'll worry about packaging for it ;)
10:45 <pickfire> ?
10:46 <pickfire> TemptorSent: So you want to package it with python2 only if you find that python2 is useful?
10:46 <pickfire> By 2020, I bet there is python4 and there will be as much pain as now.
10:46 <TemptorSent> I have hardly written a line of python. As far as packaging, I was thinking a bit further upstream, in the tool rather than the package.
10:47 <pickfire> Just like lua5.1, lua5.2, lua5.3. Pickfire forsee python2, python3, python4 by 2020. The difference is that lua uses 1M and python uses 100M
10:47 <TemptorSent> Yeah, python is horribly bloated IMHO.
10:48 <pickfire> Yes and I still write in python.
10:48 <pickfire> Why? Pandas have no alternative in C.
10:48 <pickfire> TemptorSent: Are you a patch maintainer?
10:48 <pickfire> moderator*
10:48 <pickfire> patchwork moderator*
10:49 <TemptorSent> pickfire: Nope, I'm just getting involved in Alpine dev, and haven't really been active on the scene in general in a number of years now.
10:49 <pickfire> Note: docker is now uses monthly releases, abump docker-17.03.0-ce fails
10:49 <pickfire> TemptorSent: How to get involve in Alpine dev?
10:50 <pickfire> I want to fix that broken wget -s in abuild, I have sent a patch to alpine-devel@lists.alpinelinux.org, is that correct?
10:50 <TemptorSent> I saw a need in mkimage that I wanted to fill for my own purposes and brought it up here about two weeks back.
10:51 <TemptorSent> I haven't actually even subscribed to the lists yet myself :) I shold probably do that.
10:51 <pickfire> I want to fix nlplug-findfs as well, if not everytime I boot to recovery shell.
10:51 <TemptorSent> That's more up the line I'm working on right at the moment.
10:51 <pickfire> Huh?
10:51 <pickfire> TemptorSent: You're working on that?
10:52 <TemptorSent> I'm rebuilding the entire image system, including overlays.
10:52 <TemptorSent> I haven't actually started work on the guts of mkinitfs and friends, but that's next on the list.
10:52 <pickfire> TemptorSent: Oh, that's even worse. I don't even know how those overlays stuff works.
10:53 <TemptorSent> By tomorrow I should have the whole structre working
10:53 <pickfire> I mean I am just interested to know how alpine bootloop, like you can plug out usb drive after booting.
10:53 <TemptorSent> No, I mean I have an overlay BUILDER to go with th image builder :)
10:53 <pickfire> overlay BUILDER?
10:53 <TemptorSent> hang on...
10:53 <pickfire> Just bump me
10:54 <TemptorSent> pickfire: See https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
10:55 <TemptorSent> I have just a little more surgery to do and I'll have a nice, stand-alone plugin loader utility that can be used for whatever you want :)
10:56 <pickfire> Huh?
10:56 <TemptorSent> Take a look at the code :)
10:57 <pickfire> No doc?
10:57 <TemptorSent> Basically, it will be able to handle making a proper initfs with whatever you want enabled from a simple profile.
10:57 <TemptorSent> *lol* Nope, not yet.
10:58 <* pickfire> think it is something to build the alpine iso
10:58 <TemptorSent> Currently, yes - that is the original use.
10:58 <pickfire> I really hope that there is doc for alpine.
10:59 <TemptorSent> I'll spend some time documenting once everything has stabilized a bit. I'm not sure what's actually left of the original code at this point... probably not much :)
10:59 <pickfire> kaniini: What do you think if I add apk.1?
11:00 <pickfire> Of course, I will write it in mdoc(1) instead of roff(1).
11:00 blueness joined
11:01 <TemptorSent> I just got it to the point of building a complete image with overlays and all, including autogenering ssh keys. It knows how to handle xen in any profile...
11:01 <TemptorSent> ZFS/NFS/iSCSI root fs support coming soon :)
11:02 <pickfire> :)
11:02 <pickfire> TemptorSent: How is that useful?
11:03 <TemptorSent> ...so yeah, I'll be poking at the guts of the initfs code.
11:03 andypost_ joined
11:03 <TemptorSent> Write profile, build image, run image :)
11:04 <TemptorSent> Where profile has the ability to include other profiles, but more importantly, can be built with features that specify functionality rather than lists of packages.
11:05 <TemptorSent> And the overlays are built based on the profiles/features specified.
11:05 <Shiz> 11:46:40 pickfire │ By 2020, I bet there is python4 and there will be as much pain as now.
11:05 <Shiz> http://www.curiousefficiency.org/posts/2014/08/python-4000.html
11:05 <TemptorSent> So you need a dozen differnt rpi machines all with their own setup? No problem :)
11:06 <pickfire> Weird, I am not bumped when Shiz message me.
11:06 <TemptorSent> Anyway, I need sleep -- I can't read the screen anymore without having to stick my face in it.
11:07 <pickfire> Good night, sleep tight and don't let the bed bugs bite.
11:07 <yGweSm1OzVHe> i'm a long time python dev, and i did my share of porting py2 to py3 in the end it did only cause extra work and no extra benefits, from my experience neither people still get confused and fuck up raw string/unicode handling as they did with py2. as far as i see py3 is an attempt to fix things they fucked up in py2 (like /bin/init) and now they're pushing their "solution" (which dose not make things any
11:07 <yGweSm1OzVHe> better, but worse in some regards) instead of trying again to fix the things correctly
11:07 <TemptorSent> Yeah.. the spiders ar the ones I worry about.. they've been trying to share the bed with the constant storms out lately.
11:08 <yGweSm1OzVHe> please instead of going adhominem and laugh at someone try to understand and argue about the topic, no personal attacks, lets leave that to the systemd maintainers, let's not have the same style
11:09 <asie> yGweSm1OzVHe: imagine if they released py4 now which broke string handlig again
11:09 <Shiz> they won't
11:09 <asie> the situation is a bit different because you can't have ten pythons the way you have ten init systems
11:09 <asie> well, you can, but they're just ten languages
11:09 <asie> just ask perl, or lua
11:10 <asie> (lua 5.1 is not 5.2 is not 5.3)
11:11 <asie> also, porting is always the raw end of th estick
11:11 <yGweSm1OzVHe> exactly, i consider py3 a different language from py2 but they share a lot in common, but then i also wrote function bodies that are also c and python at the same time.
11:11 <asie> yup, this is the correct way of thinking.
11:11 <Shiz> my only issue is your characterisation of python 3 as being pushed down anyone's throats
11:11 <asie> if so, why hate py3 for being "pushed on"? you don't HAVE to use it like you HAVE to use systemd
11:11 <asie> on a systemd-based distro
11:11 <Shiz> it reeks of weird conspiracy theories
11:11 <Shiz> people write python3 because they prefer python3
11:11 <asie> the only problem people have with systemd is that you can't remove it
11:11 <yGweSm1OzVHe> not sure about that
11:11 <asie> python3 is one apk command away
11:11 <Shiz> i only write python3 when i write python code because i find python2 unpleasant to write i
11:11 <yGweSm1OzVHe> there's social pressure
11:11 <Shiz> n
11:12 <asie> yGweSm1OzVHe: there's always social pressure
11:12 <asie> there's social pressure to use windows
11:12 <asie> or steam
11:12 <asie> or skype, or facebook
11:12 <yGweSm1OzVHe> eeek
11:12 <Shiz> there's always social pressure to varying degrees, but that's not relevant
11:12 <asie> social pressure is normal - people tell people to use what works for them
11:12 <Shiz> what's relevant is the characterisation of it being pushed down people's throats
11:12 <asie> social pressure is not necessarily malicious
11:12 <asie> and is not automatically malicious
11:12 <asie> it's human.
11:12 <yGweSm1OzVHe> you wrote "people write py3 because they like it" not all of them like it, som eof them only do it because of the pressure
11:12 <asie> then they're weak
11:13 <Shiz> which is both unpleasant and creates an unnecessarily hostile environment for people who like and prefer python3
11:13 <yGweSm1OzVHe> i contest your generalization from your own perspective
11:13 <Shiz> and i contest yours
11:13 <asie> if they let other people influence their decisions, then they shouldn't do that. simple
11:13 <Shiz> unless you have numbers of people who cave in to python 3 because of peer pressure, a conclusion of "being pushed down people throats" is both hasty and toxic
11:13 <asie> as in
11:13 <asie> if it bothers them
11:13 andypost__ joined
11:13 <asie> if it bothers you that other people want you to use py3, start hanging out with other people. there's literally billions to choose from.
11:14 <asie> s/that other people/that people/
11:14 <yGweSm1OzVHe> how about having both?
11:14 <asie> both py2 and py3?
11:14 <yGweSm1OzVHe> i have no problems with coexistence
11:14 <Shiz> (also, there's nothing "academic" about python3)
11:14 <asie> that's currently the case
11:14 <asie> one doesn't conflict with the other
11:14 <asie> except for /usr/bin/python
11:14 <yGweSm1OzVHe> replacing py2 with py3 is not coexistence
11:14 <asie> who is replacing it?
11:14 <asie> where?
11:14 <asie> people move on from py2 to py3 because they want to do it; same reason people move on from lua 5.2 to 5.3
11:14 <asie> (and same reason mike pall of luajit doesn't...)
11:15 <yGweSm1OzVHe> scroll back to the discussion aboug gdb depending on py2
11:15 <yGweSm1OzVHe> about
11:15 <Shiz> it's not like python 2 software is retroactively disappearing from the internet
11:15 <asie> yGweSm1OzVHe: oh, yes; people will generally pick the more supported option for default packaging
11:15 <Shiz> until it is, "replacing" is hardly a honest way of putting it
11:15 <asie> if you can choose an older, unmaintained version of a software
11:15 <asie> or a newer, long-term one
11:15 <asie> which would you pick, as a system maintainer?
11:16 <asie> if you want an OS which bends to your will, use Gentoo
11:16 <yGweSm1OzVHe> can we not serve all needs?
11:16 <asie> no?
11:16 <Shiz> no
11:16 <yGweSm1OzVHe> do we have to pick sides?
11:16 <yGweSm1OzVHe> why?
11:16 <asie> yes, unless you want bloat
11:16 <Shiz> if you want to complain about picking sides
11:16 <yGweSm1OzVHe> why bloat?
11:16 <asie> including both py2 and py3?
11:16 <Shiz> complain to gdb which apparently only allows ONE python version to be used
11:16 <asie> (and py4 and py5...)
11:16 <Shiz> this is not alpine's issue
11:16 <asie> also, ^
11:16 <Shiz> it's gdb's
11:16 <yGweSm1OzVHe> why not gdb-nopy, gdb-py2, gdb-p3?
11:16 <asie> because that's 3x the build server effort
11:17 <asie> help pay for the build server and i'm sure you'll be given an OK
11:17 <asie> but the build server is a limited resource
11:17 <yGweSm1OzVHe> are you paying for it?
11:17 <asie> no, but someone is
11:17 <yGweSm1OzVHe> oh.
11:17 <asie> it's not a free resource
11:17 <asie> packages need a server to be built on
11:17 <asie> more packages = slower builds on updates
11:17 <asie> PHP had the same discussion
11:17 <Shiz> the issue with option packages like that is that they exponentially grow with the number of options
11:17 <asie> we argued which PHP versions to keep
11:17 <asie> out of 5.6, 7.0, 7.1
11:17 <Shiz> at some point, we as a distro have to draw a line
11:17 <asie> but each version is effectively 10-15 additional packages
11:18 <yGweSm1OzVHe> so?
11:18 <asie> x 5-10 architectures
11:18 <Shiz> alpine packaging is fairly flexible, but it's not portage
11:18 <asie> that's HOURS of building effort
11:18 <Shiz> it will never have something like USEflags
11:18 <asie> for the low resources alpine has
11:18 <asie> also, hard disk space
11:18 <asie> servers have a limited supply of that as well
11:18 <Shiz> i'm not saying draw the line at gdb/gdb-py2/gdb-py3 btw
11:18 <asie> we're talking in general
11:18 <Shiz> just making a general picture that we'll never be as flexible as e.g. gentoo
11:18 <asie> the question of supporting multiple user configuration
11:18 <asie> versus trying to pick a few common use cases
11:19 <asie> as i said, if you want to bend a system to your will, you need a source-based distribution
11:19 <Shiz> (also, just saw gdb installs /usr/bin/run; eww)
11:19 <asie> or at least a package overlay on top of alpine, which isn't hard to make
11:19 <asie> alpine is one of the easiest distros to make a repo for
11:19 <Shiz> e.g., taking a random gentoo package
11:20 <asie> yGweSm1OzVHe: gdb-py2 and gdb-py3 would mean someone at alpine has to test both to ensure they both work correctly, too
11:20 <asie> tester effort is even more "expensive" than buildserver effort
11:20 <Shiz> gdb: Installed versions: 7.10.1(22:31:03 17/02/16)(client -expat -lzma -multitarget -nls -python -server -test -vanilla PYTHON_SINGLE_TARGET="python3_3 -python2_7 -python3_4" PYTHON_TARGETS="python3_3 -python2_7 -python3_4")
11:20 <Shiz> if we were to embed all the possible options here, we'd have 2**12 gdb packages
11:20 <asie> and as you said
11:20 <Shiz> (4096)
11:20 <asie> it's not about gdb-py2 and gdb-py3
11:20 <asie> the same applies to every scriptable piece of software in the world, period
11:21 <asie> pleasing everyone in this regard would cost alpine gigabytes of hard drive space, hours of buildserver effort and potentially days of testing effort
11:21 <asie> for the benefit of a very small fraction of the userbase vs. things like adding new features or packages
11:21 <yGweSm1OzVHe> py[23]-latest would be enough i guess
11:21 <asie> but py2 and py3 is available
11:22 <asie> it's just that gdb forces you to choose one or the other
11:22 <asie> and alpine goes with the more maintained one of the two
11:23 <asie> as i said, if we make an exception for python
11:23 <asie> do we also make an exception for lua?
11:23 <asie> or php?
11:23 <asie> what about java?
11:23 <asie> or ruby?
11:23 <asie> or node.js? or web browser versions?
11:23 <asie> the reason we have hundreds of Linux distributions is because they all cater to a different audience
11:23 <yGweSm1OzVHe> those are not different languages ,but different versionsof the same language
11:23 <asie> yGweSm1OzVHe: lua 5.1 is not 5.2 is not 5.3
11:23 <asie> they're all incompatible with each other
11:24 <asie> in some ways
11:24 Emperor_Earth_ joined
11:24 <asie> luajit is also not lua 5.1 or is it 5.2
11:24 <yGweSm1OzVHe> i dont consider py3.2 a differnt language from py3.7
11:24 <asie> php 5.5, 5.6, 7.0, 7.1, etc. are all incompatible as well
11:24 <yGweSm1OzVHe> do they have backward compatible changes without any benefits?
11:24 <asie> java 7 and 8 also have behaviour differences. i ran into one just recently
11:24 <asie> yGweSm1OzVHe: NONE of them are 100% compatible with each other
11:24 <asie> ALL of them have some breaking changes, even if very very small
11:24 <asie> Ruby might not, I suppose.
11:24 <yGweSm1OzVHe> yes, but do the backward incompatible changes actually have a benefit?
11:25 <asie> Benefit is subjective.
11:25 <yGweSm1OzVHe> not really
11:25 <asie> yes, really.
11:25 <asie> Mike Pall considers Lua 5.3 a bad design and made LuaJIT cater to Lua 5.2.
11:25 <yGweSm1OzVHe> show me the benefits. the subjective ones please
11:25 <asie> Most other Lua developers consider 5.3 a good design.
11:25 <asie> Look into it.
11:25 <yGweSm1OzVHe> let's focus on py first before we shift goalposts
11:25 <asie> No, because you're thinking from YOUR personal problem's perspective
11:25 <yGweSm1OzVHe> no
11:25 <asie> whereas I'm trying to explain why THIS problem cannot be solved
11:26 <asie> if we make an exception for Python , we either make an exception for every such case
11:26 <asie> ...or we're a bunch of hypocrites
11:26 <yGweSm1OzVHe> i actually postulate that py3 is not an improvement to py2
11:26 <asie> according to some key figures, Lua 5.3 is not an improvement to Lua 5.2
11:26 <yGweSm1OzVHe> and this is what i call a failed academic experiment
11:26 <asie> according to other key figures, it is
11:26 <asie> i'm trying to tell you that Python is not the only case in the world where two incompatible versions created a schism
11:26 <Shiz> https://up.shiz.me/M2I2MmU3.png
11:26 <Shiz> here's a 2013 survey
11:27 <Shiz> can you drop the point now
11:27 <yGweSm1OzVHe> again, no problem with having a new language.
11:27 <asie> No, you're clearly having a problem with it.
11:27 <asie> Because gdb only lets you be compatible with one or with the other.
11:27 <asie> And there's a lot of other software which does this as well.
11:28 <yGweSm1OzVHe> Shiz: can you tell me the how was this sampled?
11:28 <asie> >Note that "python" plugin in WeeChat can support only one version, so it can be a 2.x or 3.x, not both at same time.
11:28 <asie> This is an example, yGweSm1OzVHe
11:28 <asie> this is another piece of software which would require two separate builds
11:28 <Shiz> "The survey was publicized via posts to comp.lang.python, python-dev and hacker news."
11:29 <asie> While WeeChat is a bit different in that it recommends Python 2 for compatibility reasons, does that mean we should not support Python 3? I mean, gdb, in your hypothetical scenario, has versions for both.
11:30 <Shiz> also relevant:
11:30 <Shiz> http://ianozsvald.com/wp-content/uploads/2016/06/work_python.png vs http://ianozsvald.com/wp-content/uploads/2016/06/home_python.png
11:30 <Shiz> peer pressure, huh :-)
11:30 <asie> Shows a clear split.
11:30 <asie> More Python 2 at work due to older codebases.
11:31 <yGweSm1OzVHe> python-dev and python.lang seems to be biased as a crowd, no?
11:31 <asie> Every human being is biased.
11:31 <Shiz> python-dev, maybe
11:31 <Shiz> comp.lang.python is a user's community
11:31 <Shiz> python-dev doesn't have enough active distinct users to shift the results of the survey that much
11:31 <Shiz> on its own
11:32 andypost__ joined
11:34 blueness joined
11:35 <yGweSm1OzVHe> btw do you know who did this survey and what is their bias?
11:36 <yGweSm1OzVHe> maybe the solution is to code up a a py-shim ;) which you can plug in either py you want without recompiling.
11:36 <Shiz> the python C API doesn't work that way.
11:36 <yGweSm1OzVHe> meh
11:36 <yGweSm1OzVHe> what's the problem with it?
11:36 <Shiz> significant architectural changes between python 2 and 3's C API
11:40 <asie> yGweSm1OzVHe: if you're willing to put in the effort to make one
11:42 blueness joined
11:42 <pickfire> Looking from here, Shiz and asie looks like the same person talking.
11:42 <asie> pickfire: Clearly, it's a conspiracy
11:42 <pickfire> An agreement to perform together an illegal, wrongful, or subversive act.
11:43 <asie> Subversive sounds about right.
11:44 <pickfire> Sex and creativity are often seen by dictators as subversive activities
11:44 <pickfire> But yeah, I think I understand it now.
11:44 <pickfire> In a nutshell, gdb should default to python2 and should never use python3 right?
11:45 <asie> pickfire: In a nutshell, we should provide a package for "gdb with python2" and "gdb with python3".
11:45 <pickfire> Ah, that's what I want. But I thought you all are against that?
11:45 <asie> Which makes sense on first glance, but then we'd have to apply the same logic to /everything/
11:45 <asie> That's my only problem with it.
11:45 <asie> It's a great idea, but Gentoo does it far better than Alpine ever will.
11:45 <* pickfire> don't quite like gentoo
11:45 <pickfire> Need to compile everything myself.
11:47 <Shiz> whats the usecase for a gdb with python2
11:47 <Shiz> any pre-existing commonly-used scripts that break?
11:50 <yGweSm1OzVHe> there's a bunch of reverse engineering tools based on this
11:50 <pickfire> I don't use gdb with python personally.
11:51 <Shiz> right
12:03 blueness joined
12:12 blueness joined
12:55 <jirutka> pickfire: "Patchwork moderator: Please kill #3103" … kill as resolved?
12:55 <algitbot> Bug #3103: acf-kamailio is broken - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/3103
12:57 Emperor_Earth_ joined
12:57 <jirutka> fyi, I’ll rather ignore all this bullshit about python2 vs. python3; python2 is dead, not under active development anymore, period.
12:58 <jirutka> and no, there will definitely not be Python 4 at 2020, this is yet another total bullshit
13:03 <yGweSm1OzVHe> maybe py2 is feature complete? an doesn't need more development?
13:03 <jirutka> you can’t be serious…
13:04 <yGweSm1OzVHe> why? what is missing from py2?
13:04 <yGweSm1OzVHe> i mean besides the stuff they messed up again in py3?
13:04 <jirutka> maybe broken unicode support?
13:04 <yGweSm1OzVHe> also broken in py3
13:04 <jirutka> any many other things that are fixed fixed in python3
13:05 <jirutka> it’s not very good even in py3, but still much better than py2
13:05 <yGweSm1OzVHe> people still fuck it up like in py2
13:06 <jirutka> sorry, but I don’t wanna discuss this topic; this is the most annoying thing in entire Python universe
13:07 <jirutka> Python is represented by Python developers, they’re goal is very clear, if you disagree, then fork Python; the only reason why Python 2 is still somehow maintained are big companies that has written piles of shit in it and are not willing to even try to port it into Python3
13:08 <yGweSm1OzVHe> bec
13:08 <yGweSm1OzVHe> ause there is no benefit in porting to py3
13:08 <yGweSm1OzVHe> the bugs they fixed are not fixed well
13:08 <jirutka> of course there are
13:08 <jirutka> just read what’s new in python 3
13:08 <jirutka> you can do this yourself
13:09 <yGweSm1OzVHe> actually unicode support is decent but not intuitive
13:09 <jirutka> well, yes, as probably everything in Python it’s kinda weird and half-working… but that’s for a different discussion
13:09 <yGweSm1OzVHe> agreed ;)
13:10 <yGweSm1OzVHe> a new version should make things better not different
13:10 <jirutka> they did it better, just not great
13:11 <jirutka> if they would fixed it properly, then it would create even more incompatibilities and more hate among conservative devs
13:12 <yGweSm1OzVHe> maybe, we don't know
13:12 <jirutka> yeah
13:37 Emperor_Earth_ joined
14:40 <pickfire> jirutka: No, that's duplicate.
14:41 <pickfire> jirutka: Wait, I am talking about %3103
14:41 <algitbot> [alpine-aports] main/taskd: Add init scripts - Patchwork: http://patchwork.alpinelinux.org/patch/3103/
14:52 HRio joined
14:54 <HRio> I have a question regarding the new soon to be policy of check() in APKBUILD, any framework you plan on using to implement unit tests for shell projects?
14:54 <HRio> In alpine I found testing/bats unmaintained/roundup, but nothing in main or community...
15:20 Emperor_Earth_ joined
15:25 blueness joined
15:29 blueness joined
15:45 Emperor_Earth_ joined
15:52 BitL0G1c joined
16:05 andypost joined
16:06 Emperor_Earth_ joined
16:08 Emperor_Earth_ joined
17:08 BitL0G1c joined
17:19 <jirutka> HRio: that’s a good suggestion, we should move bats at least into community
17:24 <skarnet> please, check first that there are no vampire bats among them
17:26 <jirutka> TemptorSent: I don’t know about many Python projects that provides man pages (actually no one I can remember) and -doc subpkg with HTML pages are IMHO useless, you can just read them online w/o messing your system with it; maybe that’s why there are no examples for py- pkgs with -doc :/
17:30 <jirutka> pickfire: ranger? IIRC it’s in unmaintained, it was horribly broken
17:30 Emperor_Earth_ joined
17:31 <Shiz> jirutka: actually, it's not THAT uncommon for some projects to only have .html docs but none of those online
17:31 <Shiz> i've countered a few of those in the past yearss, sadly
17:31 <Shiz> also, can't expect the users to always have internet connectivity, so i'd advocate for keeping .html in docs
17:32 <jirutka> okay
17:33 <Shiz> example: https://github.com/CoreSecurity/pcapy
17:33 <Shiz> docs only in repo, not online
17:33 <Shiz> (pcapy.html)
17:34 <jirutka> I personally don’t mind it, b/c I almost never install -doc subpkgs; I have dozens of system with Alpine and prefer not to pollute it with something I can easily find online or on some non-production system that I use like a playground
17:34 <Shiz> sure, but then you can just not install -doc :)
17:34 <Shiz> i do the same on prod systems
17:34 <jirutka> aha, that’s okay, it’s just single html
17:34 <jirutka> but some packages generates many HTML pages, including styles and images… sometimes it has many megabytes…
17:35 <Shiz> yeah, but even stuff like that...
17:35 <Shiz> idk, it can be useful
17:35 <Shiz> luckily we split -doc packages up in the first place :)
17:36 <jirutka> yeah, if the pkg’s build script atuomatically installs relevant docs, then I usually keep it and only move it into /usr/share/doc/$pkgname, if it does not install there by default (and add -doc)
17:38 Emperor_Earth_ joined
17:51 <pavlix> what's up?
18:03 <TemptorSent> jirutka: The package pickfire was working on (ranger) did happen to have both pydoc and man pages, but my wish to have man pages able to be installed WITHOUT installing the rest of the docs in /usr/share/docs is not python specific.
18:04 <jirutka> TemptorSent: we currently don’t have any -man subpkgs, just -doc
18:04 <TemptorSent> jirutka: Exactly :)
18:05 <jirutka> TemptorSent: there’s also a special package "docs" that pulls -doc for very installed pkg
18:05 <TemptorSent> jirutka: As a general solution, setting an environment variable to pass to tar on extraction would probably kill many birds with one stone.
18:05 <jirutka> TemptorSent: no
18:05 <Shiz> nonooo
18:05 <TemptorSent> ??
18:06 <jirutka> TemptorSent: I agree that in same cases it would make sense to differentiate man pages and rest of the docs
18:06 <TemptorSent> What is so horrible about filtering tar?
18:06 Emperor_Earth_ joined
18:07 <TemptorSent> I'd love to see a "man" package similar to docs that ONLY installs the man pages.
18:08 <TemptorSent> It could use the -doc apks, but filter the file list on extraction.
18:10 <jirutka> the distinction between man pages and other docs makes sense for me, but definitely not via filtering tar
18:10 <jirutka> but as normal subpkg
18:13 <TemptorSent> jirutka: Filtering tar or explicitly listing files for extraction is a simple way of allowing users more flexabilty in what they install on a minimal system wihout needing to break packages down to infintessimals.
18:14 <jirutka> it’d generate many problems and increase complexity
18:16 <TemptorSent> jirutka: It would probably be better than my current solution, which is to blackhole the output directory on extract :)
18:16 <jirutka> that’s your own solution on your own computer, you can do whatever you want with your computer ;)
18:16 <TemptorSent> jirutka: Current solution: in .profile: apk-nodoc() { mount -t tmpfs tmpfs /usr/share/doc && apk $@ ; umount /usr/share/doc }
18:17 <TemptorSent> jirutka: Yeah, it's ugly as sin, but it does work.
18:17 <jirutka> that’s good for you :)
18:18 Emperor_Earth_ joined
18:18 <jirutka> yeah, ranger is a good example of pkg that puts bloat of some examples and other things into -doc
18:18 <TemptorSent> jirutka: I guess what I'd like to see is the ability to use a tar exclude file to specify files/directories to NEVER be extracted by apk.
18:19 <jirutka> I’d like to see if anyone actually use these…
18:20 <jirutka> in this case, it’d make sense to extract these examples into a -examples subpkg
18:20 <TemptorSent> jirutka: It doesn't make man packages magically happen, but it would let users set /usr/share/docs as an excluded directory, which is just as good for mnay practical applications (think rpi)
18:20 <jirutka> or maybe just provide something like -src subpkg with full sources…
18:21 <jirutka> no, it’s not a solution, it’s just a dirty hack
18:21 <TemptorSent> jirutka: Filtering becomes almost a necessity when you start dealing with network file systems and shared resources.
18:22 <jirutka> https://hastebin.com/iwexipomix.txt … most of the files in /usr/share/doc are actually not a documentation, that’s the problem
18:22 <TemptorSent> jirutka: For instance, /usr/share/doc on a RO NFS mount or CD.
18:24 <TemptorSent> jirutka: The other REALLY useful tool is --xform, which would make setting up configurations with odd mount points much easier.
18:24 <jirutka> TemptorSent: you can suggest this to fabled, maybe he’ll have different opinion about it than me; and more importantly he’s the person who is competent to decide this, not me
18:25 <TemptorSent> jirutka: Fair enough. I'm looking at the types of configurations *I* need to deal with, which may not be as common as most.
18:27 <jirutka> TemptorSent: I agree with distinction between man pages and rest of the docs, this makes sense for me too, and we already have a mechanism for this – subpackages, not needed to implement some new hacks for it
18:27 BitL0G1c1 joined
18:28 <jirutka> personally I’d just remove anything but man pages or plain text files from -doc, but understand that especially desktop users have quite different needs
18:28 <TemptorSent> jirutka: Here's a use case: I run postgresql as my database server and need to relocate it's root directory to /datastore/postgresql on the machines that are running in media mode.
18:29 <jirutka> you can do that in /etc/conf.d/postgresql
18:29 <TemptorSent> jirutka: Yeah, I don't much care about the images, examples, etc. When I need docs, I want docs.
18:29 <jirutka> if you mean data directory…
18:29 <TemptorSent> jirutka: Not just data directory, but the whole install.
18:30 <jirutka> ranger segfaults
18:30 <jirutka> the same problem as in the previous package that is currently in unmaintained
18:30 <jirutka> just run ranger and it segfaults
18:30 <jirutka> IIRC ^7heo_ have tried to fix it before…?
18:31 <TemptorSent> jirutka: The reason being that postgresql version needs to match database version, and our boot media may have an old version.
18:31 <jirutka> and…?
18:31 <jirutka> aha, I see where it’s going
18:32 <Shiz> but pgsql dbs are already installed in a version-segregated directory ;p
18:32 <jirutka> I have probably the same problem… I still have PostgreSQL cluster on Gentoo and here I can install multiple versions in parallel which is needed when upgrading between minor versions
18:33 <jirutka> I don’t know how to simply do this on Alpine… IIRC I’ve already suggested to maintain add version suffix into postgresql pkg and always mantain at least two versions, so people can upgrade
18:35 <jirutka> Shiz: yes, but for example runscript is not version-segregated and you cannot install two different version of PgSQL on Alpine, can you?
18:39 <TemptorSent> jirutka: Yeah, it's a real problem for me anyway, and it sounds like it's bit you too.
18:40 <jirutka> TemptorSent: yes and I’m gonna migrate our PgSQL instances soon, so I should somehow solve it asap :/
18:41 <TemptorSent> jirutka: That's why tar filter/xform on extract would be very useful on my end. If nothing else, I could version the pgsql binaries names directly.
18:41 <jirutka> TemptorSent: I don’t see how you can solve this issue with tar filtering…
18:41 <TemptorSent> jirutka: I throw around some databases with many gigs of data in them.
18:42 <jirutka> btw how can I respond to a patch in Patchwork without subscribing to aports ML?
18:43 <jirutka> I don’t know what magic did Patchwork use to match emails into threads, if only subject is sufficient…
18:43 <jirutka> s/respond/reply/
18:43 <TemptorSent> jirutka: tar --xform='s|postmaster|postmaster-$version|' :)
18:44 <jirutka> no, this would not actually help
18:44 <jirutka> b/c apk does not allow you to install two versions of the same pkg
18:44 <jirutka> and even if it would allow it, this is a dirty hack, not a systematic solution
18:45 <jirutka> actually the only truly systematic solution is abandoning this damn FHS…
18:47 <skarnet> +1
18:47 <skarnet> I'm glad you're bumping against it again and again
18:48 <skarnet> with your voice maybe we can convince the big bosses
18:48 <jirutka> ha, skarnet, could you please reply to that it’s broken and add link to http://bugs.alpinelinux.org/issues/6839 ?
18:48 <skarnet> (your voice is the cheapest torture implement I can think of)
18:48 <Shiz> damn
18:48 <Shiz> rude
18:49 <jirutka> what?! my voice?!
18:49 <skarnet> I should have put a smiley
18:49 <TemptorSent> jirutka: Essentially, I just throw the FHS out for my databases and dump them in self-contained directories.
18:49 <jirutka> skarnet: oh crap, reply to this http://patchwork.alpinelinux.org/patch/3102/
18:49 <skarnet> Shiz: context: last time we talked about convincing people to ditch FHS, I was up for waterboarding people and jirutka insisted on talking to them first
18:50 <Shiz> ah :p
18:50 <jirutka> aha XD
18:50 <TemptorSent> *lol*
18:50 <Shiz> im pro-cleaned-up-FHS
18:50 <Shiz> :p
18:50 <skarnet> cleaned up?
18:50 <Shiz> which involves no such nonsense as /root
18:50 <jirutka> but I didn’t mean to torture them by talking, but to agree on it, like civilized people! XD
18:50 <Shiz> or /boot
18:50 <skarnet> you can't clean that up, it needs to be burnt down to the ground and rebuilt upon
18:51 <Shiz> I somewhat agree
18:51 <Shiz> but I also fear that you're gonna put forward djb's filesystem layout
18:51 <Shiz> which i dislike even more
18:51 <Shiz> :p
18:51 <TemptorSent> FHS is great for the basic system tools, but applications that have a bunch of files with interdependencies and version requirements spread across the FS are nuts.
18:51 <skarnet> I'm not a /package fan
18:51 <jirutka> Shiz: do you know Homebrew at least a little?
18:51 <skarnet> I like some of the guarantees it provides
18:51 <Shiz> jirutka: i use it daily
18:51 <Shiz> :p
18:52 <skarnet> but I'd be just as happy with a similar layout that provide the same guarantees and maybe more
18:52 <jirutka> Shiz: great, then that’s how I personally imagine that it may work, just with better names than Cellar etc :P
18:52 <TemptorSent> ' /opt has the sanest structure for applications actually.
18:52 <Shiz> homebrew's systme is interesting, i agree
18:52 <jirutka> Shiz: still use FHS, but just for compatibility, by putting symlinks into it
18:52 <jirutka> no, /opt is defined in FHS, so it’d be better to avoid it
18:53 <jirutka> to not confuse people too much
18:53 <skarnet> but /opt is the exact right place to have a directory-based hierarchy
18:53 <jirutka> maybe something like /pkgs/$pkgname-$pkgver (and symlink /pkgs/$pkgname)
18:53 <TemptorSent> I mean that currently in FHS, only opt is actually intended to encapsulate.
18:53 <skarnet> not following the FHS doesn't mean we can't have /bin
18:53 <jirutka> yes, that’s true
18:53 <HRio> jirutka: OK, if bats is in community or main I can use that. Thanks
18:53 <skarnet> so it doesn't mean we can't have /opt, either
18:54 <jirutka> yeah, but not for creating directories for packages inside it
18:54 <skarnet> oh?
18:54 <skarnet> I don't remember anything in FHS forbidding it
18:54 <skarnet> but I may have misread
18:54 <jirutka> I donjt like /opt/$pkgname/ …
18:55 <TemptorSent> /opt actually usually DOES have a directory for each package.
18:55 <skarnet> TemptorSent: that's what I thought, too
18:55 <jirutka> b/c FHS defines /opt as a directory for stuff that is not managed by package manager
18:55 <jirutka> and ppl are used to use it like that
18:55 <skarnet> ah
18:55 <Shiz> you'd like homebrew's equivalent
18:55 <skarnet> so it's ok for me to use it like that on my machines, but for a distro it's more problematic. I see.
18:55 <Shiz> for its secondary set of symlinks
18:55 <Shiz> /usr/local/opt
18:55 <Shiz> :p
18:55 <skarnet> ugh
18:56 <jirutka> why? isn’t more clear to just made up some actually reasonable name right under / ?
18:56 <TemptorSent> /opt is intended for packages which don't fit the FHS and are locally installed.
18:56 <Shiz> ~ » ls -lP /usr/local/opt/ffmpeg
18:56 <Shiz> lrwxr-xr-x 1 mark admin 22 21 Feb 02:13 /usr/local/opt/ffmpeg -> ../Cellar/ffmpeg/3.2.4
18:56 <skarnet> jirutka: honestly idc, the argument you gave is good
18:56 <jirutka> instead of burying it into /usr/local/whatever/insanely/long/crap
18:57 <Shiz> jirutka: i was being sarcastic, obviously
18:57 <Shiz> homebrew is forced to usr something under /usr/local because that's the only /usr place OSX lets you install stuff
18:57 <skarnet> I like /opt, but if a distro shouldn't use /opt, then let's use something else
18:57 <jirutka> Shiz: wat a moment, /usr/local is used on macOS for very specific reasons, it doesnjt make any sense for us
18:57 <TemptorSent> For instance /opt/google/chrome is the target location for chrome.
18:57 <Shiz> jirutka: that's why i was being sarcastic
18:57 <skarnet> /pkgs sounds good, or even /p for shortness
18:57 <Shiz> i prefer /pkg if we're going that way
18:57 <Shiz> /bin is not /bins either
18:58 <skarnet> isn't /pkg used in some BSD?
18:58 <jirutka> yeah, or /pkg, that’s maybe better than /pkgs
18:58 <skarnet> not that we care, but avoiding any possible confusion would be useful
18:58 <Shiz> skarnet: not seeing anything in man hier
18:58 <skarnet> jirutka: what's wrong with http://patchwork.alpinelinux.org/patch/3102/ and why should I reply to it?
18:58 <jirutka> I was not very clear with FHS and symlinks… I’d like to keep all configs in one place, e.g. /etc, and also logs and application data
18:59 <TemptorSent> I'm not sure pkg is the right abstraction, since a given application may use several packages.
18:59 <Shiz> skarnet: netbsd has /usr/pkg
18:59 <Shiz> "packages maintained by groups other than the NetBSD Project."
18:59 <jirutka> actually I think about /pkg as immutable, it should be possible to mount it read-only
18:59 <skarnet> absolutely
19:00 <Shiz> that's not gonna play nicely with a lot of stuff
19:00 <skarnet> but you should then remount it rw everytime you apk upgrade :)
19:00 <jirutka> yes
19:00 <TemptorSent> jirutka: That could work for most of my use cases I guess.
19:00 <Shiz> so datafiles would be scattered throughout the FS
19:00 <Shiz> ?
19:00 <Shiz> :p
19:01 <jirutka> no, just in /var/lib/$pkgname as now, or some other directory with the same semantics
19:01 <skarnet> you could have a /rw/$package, iow /var/lib/$package
19:01 <Shiz> and /var/db
19:01 <jirutka> it can be just /var/$pkgname, doesn’t matter
19:01 <Shiz> and whatever else is under /var
19:01 <skarnet> anything under /var is fine, by definition it's rw
19:02 <jirutka> . /var and /etc makes sense for me, (/usr)/bin, (/usr)/lib, (/usr)/share is the problem
19:02 <jirutka> . /bin etc. make sense for symlinks, to simplify PATH
19:02 <skarnet> who are you and what have you done with jirutka
19:02 <jirutka> ?
19:02 <skarnet> you make a ton of sense lately :P
19:03 <Shiz> /lib also makes sense, probably
19:03 <Shiz> for LD_LIBRARY_PATH...
19:03 <skarnet> gaaah
19:03 <skarnet> my client doesn't know /say
19:03 <Shiz> just type two slashes
19:03 <jirutka> we’ve already talked about this on FOSDEM and I said the same as now…
19:03 <TemptorSent> jirutka: What I was using on some previous machines was something like /app/postgresql/9.6.2/*
19:03 <Shiz> that's how mine escapes it
19:03 <skarnet> nope
19:04 <Shiz> ah, nettalk
19:04 <Shiz> beyond saving
19:04 <Shiz> :p
19:04 <skarnet> I'll take any suggestion for a simple, free, Windows client
19:04 <Shiz> hexchat?
19:04 <jirutka> skarnet: you’re sentence is semantically invalid
19:05 <skarnet> and yours is grammatically invalid :P
19:05 <Shiz> most common relatively simple windows client i see used
19:05 <Shiz> https://hexchat.github.io/
19:05 <jirutka> skarnet: it’s internally inconsistent
19:05 <TemptorSent> Hmm, does BitchX work on windoze?
19:05 <skarnet> Shiz: thanks, I'll check
19:05 <jirutka> skarnet: eh, well, that’s quite possible, my English still sucks :/
19:05 <Shiz> bx has a rather unfortunate name still...
19:05 <jirutka> btw Textual for macOS is great ;)
19:05 <skarnet> TemptorSent: I hated BitchX when I ran it on a Linux client
19:06 <TemptorSent> *lol* Yeah, the name is unfortunate these days I guess.. I've been using it for 20 years though.
19:06 <skarnet> Shiz: "Highly scriptable with Python and Perl". I said simple!
19:06 <Shiz> i'll still be stuck on weechat in 2025 i think
19:06 <Shiz> skarnet: the UI is simple
19:06 <Shiz> :p
19:06 <Shiz> nettalk's code probably isn't all that jazzy either
19:07 <skarnet> I don't think any IRC client's code is jazzy
19:07 <TemptorSent> skarnet: Why did you hate BitchX? It feels better than mIRC IMHO.
19:07 <Shiz> bx's name was always unfortunate
19:07 <TemptorSent> A rusty IRC client would be interesting indeed...
19:08 <skarnet> TemptorSent: couldn't say. Maybe it was the GUIness of it on a Linux client and my general discomfort.
19:08 <TemptorSent> Shiz: Yeah, it started in the days before anyone cared about political correctness.
19:08 <skarnet> nothing wrong with female dogs
19:08 <Shiz> doesn't make it any less appropriate back then
19:09 <TemptorSent> skarnet: GUI? It has a two line status bar and that's about it to clutter the screen.
19:10 <skarnet> it runs in a terminal? I really don't remember.
19:10 <skarnet> but I couldn't get used to it anyway.
19:10 <TemptorSent> skarnet: Yup! I don't think I've ever even tried to use it in X.
19:10 <Shiz> bx, irssi and weechat are all TUI clients yes
19:11 <Shiz> relatedly: every time jirutka (re)tweets i feel like i'm learning a little bit of czech
19:11 <Shiz> very educational
19:11 <jirutka> :)
19:11 <skarnet> anyway I didn't like it, personal preference, and you can't generalize on that anecdotal evidence because I'm a very weird data point when it comes to clients.
19:11 <TemptorSent> At the time I started using it, one of the big draws was it was much less vulnerable to script-kiddie attack.
19:12 <Shiz> the only thing i know bx for is having auto-away messages on by default
19:12 <TemptorSent> skarnet: Okay, I was just curious if it had some major pain point that I'd missed.
19:12 <jirutka> this weekend was InstallFest, that’s why so many tweets in Czech
19:13 blueness joined
19:13 <* Shiz> is away (Auto-Away after 15 mins) [BX-MsgLog On]
19:13 <Shiz> like that
19:13 <TemptorSent> Shiz: Auto nick completion is nice, multiple windows for different channels if desired, etc.
19:13 <jirutka> mitchty: https://twitter.com/jakubjirutka/status/838437341400268800 (ghc)
19:14 <TemptorSent> Shiz: DCC that actually works was a real boon too back in the day -- xdcc and friends were twitchy.
19:14 <Shiz> the only one i understood was about some vps provider offering colorful alpine images
19:14 <Shiz> :p
19:16 <TemptorSent> My IRC-foo is rusty these days, I had a haitus of several years (>10?!? - where do the years go?).
19:18 <TemptorSent> ...speaking of VPS images, would anyone be up for building some various test images using my branched mkimage? I don't know about production ready, but it's getting close -- which is good, because my client needs images a week ago :)
19:19 <mitchty> jirutka: yep, but at the same time ghc is as old as python, its got its warts, but it was a fun port, once i got past having to learn 10 things at once
19:20 <jirutka> mitchty: but according to what you said and how insanely big the pkg is, it’s definitely not SIMPLE as Don Stewart said, is it…?
19:20 <jirutka> mitchty: also, read https://twitter.com/mimi1vx/status/838465059923836929
19:22 <mitchty> don't think he knows what he's on about, the debian ghc install is 700Mib with profiled libraries
19:23 <mitchty> 300Mib without them
19:23 <jirutka> mitchty: I think that he lies… I’ve tried it on Fedora now: https://termbox.io/term/pod-LwEunaZBBQ
19:23 <jirutka> mitchty: 986 MiB
19:23 <mitchty> i'd ask for proof, sounds like bullshit or ignorance of the actual size, maybe compressed
19:23 <jirutka> mitchty: yeah, he probably doesn’t count all the dependencies… classic error
19:24 <TemptorSent> Holy crap: A gig for a compiler, tools, and libs? What is this? vizual studio?
19:24 <mitchty> with xz compression you can get a ghc dist install to about 80Mib
19:24 <jirutka> hm, but download size 89 MiB… this looks like a very good compress ratio…
19:24 <mitchty> TemptorSent: its 3 runtimes that the size gets up with, mostly profiled/debugging libraries
19:25 <Shiz> i hope at least in the alpine those prof/dbg libs are separate
19:25 <Shiz> :p
19:25 <Shiz> alpine package*
19:25 <mitchty> Shiz: yes, ghc is now split with ghc/ghc-dev the latter being the profiled libraries
19:26 <mitchty> https://pkgs.alpinelinux.org/package/edge/testing/armhf/ghc-dev
19:26 blueness joined
19:27 <mitchty> jirutka: and as for simple, its not TOO bad, but coming into the ghc internals i won't say its easy, depends on how we're defining simple
19:27 <mitchty> https://www.infoq.com/presentations/Simple-Made-Easy
19:28 <mitchty> the make system is byzantine though
19:29 <mitchty> and being rewritten https://github.com/snowleopard/hadrian
19:30 <mitchty> as for his original comment, i have done the same with some simulated annealing stuff
19:31 <Shiz> great
19:31 <mitchty> i had a toy version that used cpus to run 500 000 steps on my i7 laptop cpu in about 8 hours, added the accelerate framework and Acc in two spots, took 20 seconds using cuda
19:31 <Shiz> a build system in the same language of the compiler youre compiling...
19:31 <Shiz> people don't really think this through do they
19:31 <mitchty> its no different than Make then not?
19:32 <jirutka> skarnet: ad Patchwork, I don’t know how to reply to the patch without having the email in mailbox and so subscribing to that ML; the ranger is broken, it segfaults and there’s already issue for it http://bugs.alpinelinux.org/issues/6839
19:32 <mitchty> at some point every compiler had to be bootstrapped
19:32 <Shiz> make doesn't need make to compile
19:33 <jirutka> omg, I really love when lang must be bootstrapped AND also use build system written in the same lang so you have double chicken-egg problem… the same problem with Rust :(
19:34 <mitchty> can probably blame the rewrite on rust actually :)
19:36 <jirutka> mitchty: there’s the answer: https://twitter.com/mimi1vx/status/838472613668212736
19:36 <Shiz> you can build GNU make by doing ./configure && ./build.sh
19:36 <Shiz> :)
19:36 <jirutka> mitchty: he don’t know what he’s speaking about…
19:37 <mitchty> jirutka: thought so, unless you get strip crazy its almost always ~1GiB
19:37 <jirutka> this is much bigger even than OpenJDK!
19:37 <mitchty> i can get it down to 200MiB but it doesn't work then
19:37 <jirutka> I cannot find anything more bloated than JDK…
19:37 <jirutka> well, of course, except ghc :P
19:38 <mitchty> they inline a lot, and i don't think theres eve been any attention to code size
19:38 <jirutka> can it be compiled with -Os ?
19:39 <mitchty> the rts yes
19:39 <mitchty> its default -O2
19:39 <mitchty> for the c side of the rts
19:40 <mitchty> but there are three of them, default, threaded, and profiled/profiled+threaded
19:40 <jirutka> why do you build it with -O3?
19:40 <mitchty> noticeably reduces compile times of libraries
19:40 <Shiz> rustc is pretty big too
19:41 <skarnet> I'm afraid the art of easy bootstrapping has been dead for a decade or more
19:41 <mitchty> and not a huge impact on the resulting size of things tbh, it just tries harder to inline things
19:42 <jirutka> that guy wrote me in #vpsfree that -O3 and perf-llvm is the most stupid idea that he seen… but I really doubt that he know what’s he talking about…
19:42 <jirutka> I asked him to join our discussion here, but he didn’t…
19:42 <mitchty> ironically the llvm backend produces the smallest code size
19:43 <mitchty> i compared for x86_64 and the native code generator
19:43 <mitchty> llvm backend and -O3/-O2 was the smallest
19:43 <mitchty> so... i guess have him tell me why its stupid with numbers
19:44 <mitchty> its easy enough to change
19:48 <mitchty> also sounds like a likely troll tbh, i'd just ignore them
19:48 andypost joined
19:48 <mitchty> i prefer results to hot air
19:49 <jirutka> yes, we’ve just “discussed” in #vpsfree… I asked him once again to talk with you about it if he have some constructive critique
19:50 <jirutka> -O3/-O2 was smaller than -Os? -Os should optimize for size, so I’d expect to produce smaller binaries…
19:50 <mitchty> jirutka: ghc only uses -ON, -Os would have to be in SRC_CC_OPTS as it would only impact the c rts
19:50 <jirutka> also that high compress ratio for *binary* files suggests that there’s extreme duplication in these binaries
19:50 <jirutka> aha
19:50 <mitchty> there likely is
19:51 <mitchty> once i get more of a handle on the core -> llvm stuff i wanted to have some fun pruning the low hanging fruit
19:51 <mitchty> i think its inlining more than it needs to generally
19:52 <mitchty> i could kick off a build of ghc with -Os and compare
19:55 <mitchty> oh another thing that might make the alpine ghc bigger, splitsections is being used, which gives less decrease in binary size than splitobjects, but the latter is a hack, and it only works on x86
20:02 <jirutka> I think that it’d be also better to separate haskell-* into subpkgs instead of just defining provides
20:02 <mitchty> thats a lot harder, the compiler uses those libraries
20:03 <jirutka> ghc package can depends on them…
20:04 <mitchty> sure, but to what end
20:04 <jirutka> also it means that mimi1vx lied b/c he told me in #vpsfree that it’s a stdlib, so it doesn’t make to count it into size…
20:05 <jirutka> if compiled needs them for itself, then these are not *just* stdlib…
20:05 <jirutka> but regular dependencies of the compiler
20:05 <mitchty> basically
20:05 <mitchty> well you can argue they're both
20:06 <mitchty> and there is talk about splitting them out into subpkgs on their own right, but its a lot of thankless work
20:07 <mitchty> i'm also only one person working on this in my part time, mostly because I wanted a static pandoc, and also to use idris on alpine linux
20:09 <jirutka> ok, I understand that
20:10 <mitchty> also, i still see people doing stuff like this https://github.com/fpco/pid1/blob/c11322bbdd3e894e8d35c8db7ee1e348a2978459/static-base/Dockerfile#L16
20:11 <mitchty> which will just bloat the size of every executable
20:11 <mitchty> even though the fix is to just specify ld-options: -static in the cabal file for the executable
20:11 <mitchty> you see people applying glibc fixes for ubuntu everywhere
20:13 <mitchty> i was going to open a ton of issues and fix pr's once cabal gets merged into testing
20:15 <jirutka> well, you know, docker users usually don’t understand what are they doing…
20:16 <mitchty> so i'll do a quick look at the size of ghc with perf-llvm -O3, c -Os, perf-llvm no -O, -Os, perf-llvm w/o any -O settings, and stock without any, and stock with c -Os
20:16 <jirutka> what are these .hi files?
20:16 <mitchty> haskell interfaces
20:17 <jirutka> sources or compiled code?
20:17 <mitchty> its compiled
20:17 <mitchty> they're used by the compiler in one of its passes
20:19 <mitchty> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/IfaceFiles
20:21 <jirutka> are these files ghc-specific or usable even for some other haskell compilers?
20:27 <mitchty> ghc specific
20:27 <mitchty> realistically ghc is the only haskell compiler of note, there is hugs but that hasn't seen an update for 5 years
20:27 <mitchty> and jhc stopped development
20:29 <Shiz> uhc?
20:29 <jirutka> Fedora uses prefix ghc- for haskell pkgs; if these binaries are ghc-specific, then it’s maybe better than haskell-prefix
20:29 <mitchty> i was borrowing from arch there
20:29 <jirutka> and all of them have also suffix -devel
20:31 <mitchty> so i honestly don't care what we call them, theres a ton of examples to pick from or invent a new name for them
20:33 <mitchty> uhc looks to also be about the only other one that is actively maintained, not sure if it supports anything past haskell 98 though
20:40 <jirutka> I have server at academic network with 1 Gbps connectivity and downloading from that f*cking amazon s3 at speed 500 kiB/s… grr
20:57 <mitchty> ok so in ~3 hours i'll have numbers on the disk size of all the permutations of ghc with -O... with the c rts, and the haskell side, and with/without llvm
20:57 <mitchty> which is more productive and scientific than arguing which is best imo
20:58 <mitchty> based on that we can change it or not
21:15 slukin joined
21:32 andypost joined
21:37 <mitchty> apk installed size output is in bytes correct
21:39 <mitchty> -Os doesn't change the profiled library sizes at all, ghc by 12.28KiB
21:40 <mitchty> i suppose i could try compiling against llvm with -Oz
21:40 <mitchty> but at this point that points to the c side not contributing a hell of a lot to overall code size
21:55 czart_ joined
22:14 <mitchty> and size with -O3 and -O2 is no different
22:14 <mitchty> will compare without perf-llvm
22:14 <mitchty> note this is all x86_64
22:16 <jirutka> so why you’ve used -O3 instead of default -O2?
22:17 <mitchty> i haven't compared how fast these compilers build things
22:17 <mitchty> last i tried though this cut off a good 30 minutes on build times for stack and cabal on armhf
22:18 <mitchty> but given it takes 12 hours to compile those entirely from scratch i'm not inclined to test each of these permutations to validate someones point, this is ONLY on disk install size
22:18 <mitchty> i'm willing to change whatever, but i'd like actual numbers to base a decision on
22:22 <mitchty> i guess i can compare the build times of cabal and stack with the resulting compilers too
22:22 <jirutka> I’m just asking why you’ve changed the defaults at the first place, what was the initial reason
22:23 <mitchty> to make the armhf builds faster
22:23 <mitchty> in general
22:23 <jirutka> aha
22:23 <mitchty> i'll just remove it, tbh i don't really give a shit, and i'm spending more time talking about it than its worth, i'll just submit a pr to remove it
22:27 <mitchty> https://github.com/alpinelinux/aports/pull/980
22:32 <jirutka> maybe you misunderstood me; I don’t have any problem with it, I’m just asking to understand the decisions that you’ve made
22:34 <mitchty> nah its fine i just don't have the numbers to back it up right now
22:34 cyteen joined
22:35 <mitchty> i'll go setup a jenkins job to go compare it all on x86_64 and armhf
22:35 <mitchty> but it'll take like a week or more to get the actual reality
22:36 <mitchty> and then it actually has something tangible rather than my horrible memory of what i did
22:36 <kaniini> pickfire: i am generally supportive of a manpage!
22:47 Emperor_Earth joined
22:51 <mitchty> so anyway, is there a chance the cabal apk could get merged? or if i need to change anything in it let me know, but I hacked the cabal bootstrap.sh script to download all its dependencies and use the cached dependencies https://github.com/alpinelinux/aports/pull/915
22:51 <mitchty> if we want it to work any different let me know but not having cabal limits ghc's usefulness
22:53 <mitchty> or if it should get broken apart into each pkg getting its own discreet package I can do that too, but it'll take a while to work, and there is... 19 pkgs that cabal depends on for builds (not runtime)
23:00 cyteen joined
23:01 <mitchty> all depends on how we want to do ghc pkgs or not to save on any recompilation time for any dependent packages
23:05 Emperor_Earth_ joined
23:14 laj joined
23:44 <mitchty> and jirutka sorry if i'm coming off as angry or mad, i'm not really, and for the provides, do you want me to split the packages into subpackages named ghc-$library-dev?
23:46 <jirutka> looking at it now
23:48 <jirutka> what’s this error: "sh: /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld-: unknown operand"
23:53 <mitchty> the ld detection failing
23:53 <mitchty> and the reason for https://github.com/alpinelinux/aports/pull/915/commits/52f4806caadd3a91eed56a1e0661a0e364424f2f#diff-15f7e2fe859b5cc21fb2498121943aeaR7
23:53 <mitchty> aka force it to use ld.gold for linking
23:57 <mitchty> i could update that patch to rip out the entire ld detection logic in the cabal bootstrap.sh script
23:58 <jirutka> that’d be probably better if it doesn’t affect too many lines; and most importantly write a comment why you did it, so future you or other maintainers would know
23:59 Emperor_Earth_ joined
23:59 <jirutka> uff, it takes forever to build