<    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:00 <TemptorSent> jirutka: What I really need is for someone on arm to take a look and let me know what I need to do to clean things up there.
00:01 <TemptorSent> jirutka: Also, the archs are the next thing I'm eyeballing at extracting to their own playground, which would pretty much take care of any remaining hard-coded bits.
00:02 <TemptorSent> jirutka: I know almost nothing about the rest of the alpine ecosystem beyond the core of packages involved in building images and booting, so any help with design decisions much appreciated.
00:03 <TemptorSent> jirutka: Oh, and any idea why the hell the vanilla kernel isn't just named vmlinuz-vanilla? It would make life MUCH simpler!
00:04 <TemptorSent> jirutka: There's some voodo kernel/module land that I haven't even looked at.
00:06 <TemptorSent> jirutka: But, for instance, you can now easily build your own xen profile and have it actually work now that the hardcoaded check for $profile="xen" is gone and it's implemented as a feature instead.
00:07 PeteDaGuru left
00:08 <TemptorSent> pavlix: Anyway, getting back to your original question several hours ago -- it's ready for playing with, and shouldn't be too far from meeting your specific needs.
00:12 <TemptorSent> Before it actually goes into a live tree, it needs several things: Better documentation of functions, overall user documentation, addition of a couple more calling options to allow injecting nonce data, keys, etc.
00:14 <TemptorSent> It also needs the features to be refactored out better and overlays deduplicated of common configurations. Every profile with package that depends on udev is going to need it's suite of runlevels and such in the overlay, there's no reason every overlay should try to create the same links.
00:14 <TemptorSent> Oh, and the build-order code has had absolutely NO testing yet :)
00:16 <TemptorSent> I just rigged up a simple _before _after _needs _conflicts resolving system (and yes, it does have a watchdog counter in case of infinite loops).
00:16 <pavlix> TemptorSent: That sounds great. I'm going to bed now. Will keep in touch.
00:17 <TemptorSent> pavlix: Alright, have a great night and I'll talk to you soon. Feel free to drop me an email - chrisgiorgi at gmail.
00:18 <TemptorSent> jirutka: So, does seeing it in-use help explain the reasoning behind the fkrt utility? ;)
00:20 <TemptorSent> jirutka: The multiple-instance support isn't used as of yet, but I can easily see the need arrising when we start building multiple outputs at once..
00:33 BitL0G1c joined
00:37 <TemptorSent> Hmm, I wonder when the new apk is going to drop... I REALLY need the cache dir config option!
00:45 <TemptorSent> jirutka: I should be able to tackle the parallel dispatch soon so we can burn on several cores at once.
01:12 <TemptorSent> Wow! Was someone listening to me? New apk tools just popped in on apk upgrade :)
01:12 <TemptorSent> Thank you!
01:55 czart_ joined
01:57 blueness joined
02:34 s33se_ joined
03:20 tmh1999 joined
03:25 Emperor_Earth joined
05:25 <TemptorSent> Hmm, --cache-dir doesn't seem to be doing what I expected..
05:27 <TemptorSent> Never mind, I'm an idiot, don't mind me... It helps if you define APK_CACHE_DIR from the getopts BEFORE you try to use it :)
05:39 awilfox joined
05:51 <pickfire_> Anyone have any idea how do I provide a package that needs either python2 or python3?
05:51 pickfire joined
05:52 <TemptorSent> pickfire_ : Sorry, haven't gotten too deep into the apk/ abuild system itself yet.
05:52 <TemptorSent> Needs either or both?
05:52 <pickfire> TemptorSent: So what do you mean?
05:52 <pickfire> TemptorSent: One of them.
05:53 <pickfire> So let's say if the user have python2, it depends on python2, if the user have python3, it depends on python3.
05:53 <TemptorSent> Hmm, can you evaluate an expression inline?
05:53 blueness joined
05:53 <pickfire> But if the user have none, let the user install either python2 or python3
05:53 <pickfire> I don't want the user to install python2 if they have python3 just for this.
05:53 <TemptorSent> check for a python interpreter of any sort?
05:53 <pickfire> Or I just put depends="python2 python3"?
05:54 <pickfire> Yeah
05:54 <pickfire> any python interpreter will work.
05:57 <pickfire> By the way, how do I enable the user to view /sys/class stuff?
05:57 <pickfire> I need to read from there to be able to get acpi info.
06:00 <TemptorSent> Hmm, haven't had to do that one yet... probably mdev/udev?
06:00 <TemptorSent> What about a pre-inst if you can't do it directly in the apk?
06:10 <TemptorSent> fabled would be the one to ask.
06:18 <pickfire> TemptorSent: Nevermind, I had sent it to the mailing lists.
06:19 <pickfire> Shitty gnupg2 everytime can't decrypt, blame their bad agent.
06:28 <TemptorSent> Okay, current revision pushed to https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts , diff history at http://termbin.com/aina
06:30 <TemptorSent> Hmm, do I need to do anything to the PR to update it to the new HEAD of my branch?
06:31 <TemptorSent> It looks like the answer is no -- it was automagical.
08:09 blueness joined
08:23 <awilfox> before I reinvent the wheel: is there any sort of fancy command or API that can determine how much size a package graph will add to an installed system?
08:24 <awilfox> for instance, when you 'apt-get install build-essential' on debian it says "After installation, 46.2 MiB of additional space will be used."
08:25 <awilfox> can apk provide that sort of information? I know it can do individual packages (installed size) in the index, but I am curious if it can do an entire graph (for instance, if you pick a gtk app, include gtk lib itself if not already installed)
08:27 <awilfox> apparently apk add -i does that, but not in machine friendly way
08:29 <awilfox> guess I can look at code for apk add -i... nevermind, sorry for noise :)
08:31 <TemptorSent> awilfox - sorry, haven't delved into that yet -- fabled or ncopa should know for sure.
08:46 <awilfox> http://git.alpinelinux.org/cgit/apk-tools/tree/src/commit.c#n274 found :)
08:55 <TemptorSent> Cool!
09:21 <TemptorSent> Wtf? Did apk just use mv -i or something? Interactive prompt in the middle of my script, that's not good...
09:25 fekepp joined
09:40 <TemptorSent> fabled_ : Check your PR review requests -- I've been busy : )
10:50 <TemptorSent> 'morning SWF
12:01 <jirutka> pickfire: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python
12:02 <pickfire> jirutka: Why are you giving me that?
12:03 <jirutka> pickfire: you’ve asked "Anyone have any idea how do I provide a package that needs either python2 or python3?"
12:03 <pickfire> jirutka: Yes
12:03 <pickfire> But the package name isn't py2-ydcv or py3-ydcv
12:03 <pickfire> It's not in pypi
12:03 <pickfire> There is no setup.py
12:03 <pickfire> Just a python file.
12:03 <jirutka> pickfire: can you explain what exactly you need?
12:04 <jirutka> pickfire: create an abuild, install some pkg, or…?
12:04 <pickfire> jirutka: https://github.com/felixonmars/ydcv
12:04 <pickfire> Create a package.
12:04 <pickfire> jirutka: That repo only have a zsh-completion file and a python script
12:04 <pickfire> That is not a pypi project
12:05 <pickfire> So it will be named ydcv instead of py-ydcv
12:05 <pickfire> Should I call it ydcv-py2 and ydcv-py3?
12:06 <jirutka> pickfire: aha, this is not a python library, but a tool that just happens to be written in python; create a package ydcv and make it depend on python3, it’s not needed to support python2 for this
12:07 <pickfire> jirutka: But it can use python2 as well.
12:07 <jirutka> pickfire: and maybe also pypy or any other python interpreter…
12:07 <pickfire> So if others installed python2 and not python3, I see no reason for them to install python3 just for this.
12:07 <pickfire> Oh, yeah
12:08 <pickfire> Or I just create ydcv without any depends?
12:08 <jirutka> pickfire: unfortunately we don’t have support for such situations in apk yet
12:08 <pickfire> Oh
12:08 <pickfire> But doesn't apk have something like provides?
12:08 <jirutka> pickfire: and not adding any python into depends is definitely not right solution
12:08 <pickfire> pacman have that too
12:09 <jirutka> it has, but it doesn’t work for this case
12:09 <pickfire> So something like python2, python3, pypi all provides python
12:09 <pickfire> As well as lua5.1, lua5.2, lua5.3 where all of them provides lua as well
12:09 <jirutka> sry, i don’t have time to explain it now
12:09 <jirutka> this is known issue and I hope that we’re gonna solve it soon
12:10 <jirutka> it’s more complicated than it seems to be though
12:10 <jirutka> if you want to create a package for ydcv, then just make it depend on python3 (b/c this should be the default python) and don’t overcomplicate it
12:11 <pickfire> Huh?
12:11 <pickfire> How come?
12:11 <pickfire> The default python is python2.
12:11 <pickfire> Try `python`, it's python2
12:12 <pickfire> python3 should be the default but it isn't
12:27 <jirutka> pickfire: sry for interruption, I’m at restaurant now and I got a meal
12:27 <jirutka> pickfire: yes, /usr/bin/python is python2, as PEPxxx (don’t remember number) specifies
12:28 <jirutka> pickfire: but default target Python for tools should be python3; python2 is legacy, not under active development and hopefully will be finally retired in 2020
12:31 <jirutka> pickfire: the first paragraph: https://fedoraproject.org/wiki/Packaging:Python#Python_Version_Support, we currently follow the same strategy, at least for new packages
12:33 <jirutka> pickfire: PEP 394 https://www.python.org/dev/peps/pep-0394/; this PEP was published after Arch switched python → python3 that caused a lot of issues
12:58 <pickfire> Ah
13:15 andypost joined
13:57 leo-unglaub joined
14:44 BitL0G1c joined
16:30 Emperor_Earth joined
17:08 <kaniini> awilfox: if you request interactive-mode by `touch /etc/apk/interactive` it will literally work just like apt :)
17:08 <kaniini> awilfox: may be a good thing for adelie
17:52 <awilfox> kaniini, yeah I was thinking that but my question was more for a packagekit/muon type thing I am thinking/planning related to horizon
17:53 Emperor_Earth joined
18:00 Emperor_Earth joined
18:05 Emperor_Earth joined
18:11 Emperor_Earth_ joined
18:16 Emperor_Earth_ joined
18:25 Emperor_Earth joined
18:28 Emperor_Earth__ joined
18:34 Emperor_Earth_ joined
18:43 Emperor_Earth joined
18:45 Emperor_Earth_ joined
18:55 Emperor_Earth joined
19:46 <kaniini> BitL0G1c: let me know on logstash review and i will take care of it
19:47 <TemptorSent> Good morning kaniini.
19:56 <BitL0G1c> kaniini - yes looking at it now
21:07 Meeh_ joined
21:12 chris|_ joined
21:18 andypost joined
22:02 minimalism joined
22:02 rnalrd joined
22:02 tru_tru joined
22:06 czart_ joined
22:12 mikeee_ joined
22:16 blueness joined
23:18 andypost joined
23:55 czart__ joined