<    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 _2_4 25  
26 27 28 29 30 31
00:00 blueness joined
00:21 <awilfox> TemptorSent: if it is inconsistent, that is a bug, but --root changes the root everywhere. including cache dir
00:25 <TemptorSent> awilfox: Right, which essentially makes the --cache-dir feature useless.
00:25 <TemptorSent> I'm installing in four different --roots in the proces of building ONE image.
00:26 <TemptorSent> Same goes for building chroot environments, it's not useful if I have to go set up a link for every single one.
00:27 <awilfox> maybe --cache-root would make sense, idk, you'll have to wait for fabled.
00:28 <TemptorSent> If is pass " --cache-dir /media/usb/apkcache --root /mnt/mynewalpine", it really should use /media/usb/apkcache as the cache directory!
00:29 <TemptorSent> If is pass " --cache-dir tmp/apkcache --root /mnt/mynewalpine" then I might reasonably expect to get /mnt/mynewalpine/tmp/apkcache.
00:36 laj joined
01:42 <TemptorSent> Alright, in other news, let's see if we can get postgis and all of its deps bumped successfully...
01:45 cyteen joined
01:45 blueness joined
02:15 <kaniini> you talk a lot in absolutes
02:15 <kaniini> XYZ is useless because it doesn't do what i want
02:17 <TemptorSent> kaniini: Okay, can you explain how you would expect it to act and when you would use the --cache-dir option with a --root option and with it appending the cache dir to the root dir?
02:20 <kaniini> have you considered that they aren't meant to be used together?
02:21 <kaniini> and what happens by the way, is that it chroot() into the --root directory and then --cache-dir processing comes later
02:23 <kaniini> (well that is an oversimplification, in reality openat(2) is used to accomplish it)
02:23 <TemptorSent> kaniini: Right, I looked at the code. It's currently treating the --root option as the absolute root of the fs, not the root of the apk tree.
02:23 <kaniini> that's the intended use of it
02:23 <TemptorSent> Try asking tar to do the same thing and see what happens..
02:23 <kaniini> apk isn't tar
02:24 <TemptorSent> tar -c -C /some/path /
02:24 <kaniini> that doesn't change the fact that apk isn't tar and has a different usecase
02:25 <kaniini> TemptorSent: consider this
02:25 <TemptorSent> Like I said, can you explain when you would use --cache-dir on the command line if you're NOT trying to foce it to an absolute directory?
02:25 <kaniini> fuck this, i'm out
02:25 <TemptorSent> Sorry, I'm just trying to understand how the current behavior actually provides a benefit.
02:26 <TemptorSent> I can't figure out how I would use it in practice as it sits.
02:26 <kaniini> i've explained to you already, why it is why it is.
02:26 <kaniini> it is not foreseen that one would want to use both --cache-dir and --root at the same time
02:27 <TemptorSent> That wast the explicit reason I requested it of fabled a couple weeks ago.
02:28 <TemptorSent> If one wanted to set the cache dir globally, a config file or env variable would be the place to do it, not the command line.
02:29 <kaniini> okay, let me try once more
02:29 <TemptorSent> Using --root /some/new/root is a huge thrash of cache.
02:29 s33se_ joined
02:29 <kaniini> EVERY OTHER OPTION THAT SPECIFIES A PATH ALSO DOES IT RELATIVE TO --ROOT
02:29 <kaniini> HAVE YOU CONSIDERED JUST USING A FUCKING HARDLINK
02:30 <TemptorSent> EVERY time I call apk --root --init?
02:30 <kaniini> YES
02:30 <kaniini> EVERY TIME YOU CALL ANY APK COMMAND
02:30 <kaniini> AS I EXPLAINED HOURS AGO
02:30 <TemptorSent> I'm talking DOZENS of calls.
02:30 <kaniini> then make /etc/apk/cache a hardlink to your actual cache dir
02:31 <kaniini> not a symlink; a hardlink, so it can escape the chroot
02:31 <TemptorSent> Okay, so basicaly go back to what I was doing before and creating a whole directory structre, creating sym links, etc?
02:31 <kaniini> oh my god
02:32 <kaniini> apk --root /foo --initdb
02:32 <kaniini> ln /your/path/to/cache /foo/etc/apk/cache
02:32 <TemptorSent> Right, and my apk cache is on /var, and my builds are on /tmp
02:32 <kaniini> <whatever else you want to do>
02:33 <TemptorSent> different FS
02:33 <kaniini> okay
02:33 <kaniini> mount -o bind /your/path/to/cache /foo/etc/apk/cache
02:33 <TemptorSent> Hardlinks across FS no bueno :)
02:33 <TemptorSent> Agan, that's for EVERY call to apk.
02:33 <kaniini> oh gnoes
02:33 <TemptorSent> Hundreds of them to build all profiles.
02:34 <kaniini> whatever shall we do with the 2 to 3 extra seconds this takes in aggregate
02:34 <kaniini> even for hundreds of them
02:34 <TemptorSent> Um, it's a bit more than that...
02:34 <kaniini> bind mounting? not really
02:34 <TemptorSent> And this happens as non-root HOW btw?
02:35 <kaniini> make a suid helper
02:35 <TemptorSent> Complexity much?
02:35 <kaniini> your entire project is complex
02:35 <kaniini> what's a little more
02:35 <TemptorSent> It's hardly just mkimage.
02:36 <TemptorSent> I want a new alpine root at /mnt/alpine, right?
02:36 <TemptorSent> I do apk --root /mnt/alping --initdb
02:37 <kaniini> 20:25 <@kaniini> fuck this, i'm out
02:37 <TemptorSent> Now I install a dozen or so apks: 'apk --root /mnt/alpine add $apks'
02:37 <kaniini> you could flatten them down to a single transaction
02:37 <kaniini> however, see above
02:38 <kaniini> your average chroot deployment does not care about the cache dir
02:38 <TemptorSent> Now I want to do it again for another root, so 'apk --root /mnt/alpine2 --initdb add $apks'
02:38 <kaniini> yeah
02:38 <kaniini> this is a solved problem
02:38 <kaniini> they call it docker
02:38 <kaniini> good luck, have fun
02:39 <awilfox> you could also just use a local repository
02:39 <awilfox> then caching doesn't matter
02:39 <TemptorSent> Now, I want to have it use the cache, so I do: 'apk --cache-dir /media/usb/mycache /mnt/alpine3--initdb add $apks'
02:39 <TemptorSent> Now, what happens?
02:40 <TemptorSent> Trying again attempting to use the same cache: 'apk --cache-dir /media/usb/mycache /mnt/alpine4--initdb add $apks'
02:40 <awilfox> literally you get two syntax errors (/mnt/alpine3--initdb is not a valid command)
02:40 <TemptorSent> *lol* okay, my fingers are tired.
02:40 <awilfox> again, just run your own local repository
02:40 <TemptorSent> Trying again attempting to use the same cache: 'apk --cache-dir /media/usb/mycache --root /mnt/alpine4 --initdb add $apks'
02:40 <TemptorSent> That's what I'm trying to BUILD
02:40 <awilfox> serve it using SimpleHTTPServer on localhost:8888 or something
02:41 <awilfox> you're trying to build a local repository? that is not what cache-dir is for
02:41 <TemptorSent> the pain is that apk knows how to use links, but WON'T and I can't force it to still.
02:41 <kaniini> awilfox: don't even bother :D
02:41 <awilfox> apk fetch -r $apks -o /your/stuff, then apk index it and serve it
02:41 <awilfox> simple
02:41 <awilfox> so simple
02:41 <awilfox> lol
02:41 <TemptorSent> How many copies do I REALLY need on my system?
02:42 <kaniini> apk does not store a copy by default
02:42 <TemptorSent> if it's in the cache, it just links it rather than copies it.
02:42 <kaniini> i have been telling you that for hours too
02:42 <kaniini> when you apk add a package
02:42 <kaniini> it just streams the package file straight into the processing routines
02:42 <TemptorSent> I have /etc/apk/cache -> /var/cache/apk
02:42 <kaniini> does not store it on disk
02:42 <kaniini> yes
02:42 <kaniini> but you do not need it
02:43 <TemptorSent> You must have a hell of a lot faster connection than I do!
02:43 <awilfox> I already solved your problem
02:43 <TemptorSent> It takes me 20 minutes to download a full set of apks for a reasonable system.
02:43 <kaniini> by the way, if you do apk --repository /foo/bar it will reference the repo outside of the chroot
02:43 <awilfox> fetch once, make your own server, done
02:43 <kaniini> you do not even have to make your own server
02:45 <TemptorSent> I need a package cache that acts like a cache because that's what it's being used for. If 4 different profiles need the same package on the same arch, it should just ln it.
02:45 <kaniini> so implement an apk cache server
02:45 <TemptorSent> What is the intent of the --cache-dir option otherwise? That's what I can'f figure out.
02:45 <TemptorSent> When would you use it?
02:45 <kaniini> the apk cache itself is a badly named feature sir
02:46 <kaniini> it is for 'run from ram' instances to lazily build a local repo on a local disk for storing updates + added packages so the system can be reassembled upon reboot
02:46 <TemptorSent> It seems to work just fine when I can use it by having multiple runs with the same root.
02:47 <kaniini> i am just telling you what it is for
02:47 <kaniini> no need to be combative
02:47 <TemptorSent> So people like me that have slow networks are basically SOL?
02:48 <TemptorSent> I'm not trying to be combatative, I'm trying to figure out why a feature works the way it does when such behaviour seems to have no particular use.
02:48 <kaniini> seems to have a particular use to the people who run from ram
02:49 <kaniini> (it's not for building chroots, really, it's not!)
02:49 <kaniini> what you really want to do is
02:49 <TemptorSent> I read through the source of apk and I get what it's doing with the database -- the apk cache basically stores versioned APKINDEXes that allow multiple sources to coexist.
02:49 <kaniini> install something like nginx
02:49 <kaniini> and have it cache the packages at your gateway
02:49 <TemptorSent> I don't really want multiple copies of every package needed, especially the kernel and firmware!
02:49 <kaniini> then you use
02:50 <kaniini> right
02:50 <kaniini> so
02:50 <kaniini> listen
02:50 <kaniini> and i will tell you what you actually want to do
02:50 <kaniini> what you want to do is implement your own local package cache server
02:50 <kaniini> using nginx
02:50 <TemptorSent> maintain a local fork of apk if I have to ;)
02:50 <kaniini> which is very easy to do
02:51 <TemptorSent> Does that work with 'apk fetch -L' ?
02:51 <TemptorSent> Because *THAT* is what I'm trying to accomplish
02:52 <TemptorSent> ONE set of copies where I'm building and that's it.
02:52 <kaniini> you want something like this
02:52 <kaniini> http://turtle.dereferenced.org/~kaniini/nginx-cache.txt
02:53 <kaniini> it will accelerate your apk fetches
02:53 <kaniini> done
02:54 <kaniini> well
02:54 <kaniini> really more like this
02:54 <kaniini> http://turtle.dereferenced.org/~kaniini/nginx-cache2.txt
02:54 <kaniini> then you use
02:54 <kaniini> http://some.ip:8080/alpine/edge/main
02:54 <kaniini> as your repo
02:54 <kaniini> and voila it's cached
02:54 <kaniini> with only one copy downloaded
02:55 <kaniini> that approach also works with debian repos too
02:57 <TemptorSent> Okay, thats's cool and all, but when I have say 10 apkroots with the same packages, how many actual files do I have?
02:59 <mitchty> just hardlink the duplicates https://liw.fi/dupfiles/
03:00 blueness joined
03:00 <TemptorSent> mitchty: That's the point, apk already knows how to use hardlinks where it can, but I can't force the directory to an absolute path.
03:01 <TemptorSent> I'm not IN a chroot jail, I'm outside trying to get my cache path to referr to the location I specify.
03:02 <TemptorSent> In fact, there's no actual chroot involved, just a lot of initilizing repositories, indexing them, signing them, and dumping them to an image.
03:04 <kaniini> then maybe ask fabled nicely to add literal path support to cache-dir
03:04 <TemptorSent> My real question is is there a use case for the current behavior to stand?
03:05 <kaniini> yes, run from ram setups
03:06 <TemptorSent> Okay, more to the point, if the --cache-dir option is passed and the --root option is passed, is there any reason to not have the --cache-dir option refer to the absolute root as long as it has a leading slash?
03:07 <TemptorSent> Can you think of any case where that would NOT work?
03:08 <TemptorSent> Or where that would not be the expected behavior?
03:10 <TemptorSent> The help text says '-p, --root DIR Install packages to DIR'
03:10 <TemptorSent> And '--cache-dir CACHEDIR Override cache directory'
03:12 <TemptorSent> Nowhere does --root say it treats that as the FS root, only the root for installing, nor does --cache-dir say anything about CACHEDIR being relative to --root.
03:13 <TemptorSent> So all I'm asking is for the behavior to match the documentation, or explain why it behaves in the manner it does and change the documentation (and add a way to ACTUALLY override the cache dir)
03:14 <TemptorSent> It's a bug either way you slice it when the actual behavior is ambiguous or contrary to docuemtation.
03:15 <TemptorSent> I can parse C pretty well, so I was able to suss out what was taking place, but it was non-obvious to say the least.
03:29 <TemptorSent> kaniini: On a run from ram system, where my apk root is the same as my fs root, --cache-dir referrs to whatever location relative to absolute by accident. In a pre-pivot situation, if I actually expected to access the cache in the sysroot, I would expect to prepend $sysroot, otherwise loading from media, etc, fails.
03:29 <TemptorSent> So I believe even for that use case, the current behavior is in fact broken.
03:37 <TemptorSent> IMHO all specified files/directories should be handled as follows: Begins with /,./,../, refer to actual root, unadorned leading paths refer to whatever the current root is.
03:39 <TemptorSent> Sorry, it's just this happens to be a very real and immediate pain point for me and is severly impacting my productivity.
03:40 <TemptorSent> And all the FS thrashing actually IS causing problems, as my SD card is starting to hang up while remapping.
03:55 <kaniini> SD card? :D
04:02 <TemptorSent> kaniini: What can I say, it's what I had on hand at the time :)
04:03 <TemptorSent> Micro-sd no less, in one of those tiny readers.
04:05 <TemptorSent> At this point, I'm too far in the middle of a project to take the time to build a proper sytem.. I have 32g of memory sitting next to me, but I don't want to take the tiem or risk some random damage taking me out when I'm already behind.
04:07 <TemptorSent> I'm working of 24G of a 32G sd card!
04:07 <TemptorSent> I have more ram sitting next to me than my entire storage space.
04:08 <TemptorSent> So when it comes to wasting storage and bandwith resources I feel the pain worse than most!
04:17 ppisati joined
07:15 ageis joined
08:05 blueness joined
08:12 fekepp joined
08:37 fekepp joined
08:50 t0mmy joined
08:50 blueness joined
09:20 t0mmy joined
09:59 t0mmy joined
10:27 fcolista joined
10:31 sigjuice joined
10:52 blueness joined
10:58 fabled joined
11:13 ferseiti joined
11:55 eleksir joined
12:19 farosas_ joined
12:21 leitao joined
12:30 <ncopa> fedora hosted retired: https://fedoraproject.org/wiki/Infrastructure/Fedorahosted-retirement
12:30 <ncopa> we need fix those: $ grep fedorahosted main/*/APKBUILD community/*/APKBUILD testing/*/APKBUILD | tpaste
12:30 <ncopa> http://tpaste.us/1vO0
12:43 gromero joined
12:52 gromero joined
13:29 <fcolista> is this an abi change?
13:29 <fcolista> -usr/lib/libosinfo-1.0.so.0.3.0
13:29 <fcolista> +usr/lib/libosinfo-1.0.so.0.1000.0
13:44 <skarnet> holy version bump batman :D
13:46 <fabled> fcolista, only if the soname changes
13:47 <fcolista> this means that only if from usr/lib/libosinfo-1.0.so becames usr/lib/libosinfo-1.1.so
13:47 <fcolista> ?
13:47 <skarnet> depends on how the library is linked
13:48 <skarnet> by default, yes, your interpretation is correct and this is not an ABI change
13:48 <skarnet> but it would still be wise to check the way the library is built
13:50 <fcolista> skarnet, how ?
13:52 <skarnet> does the configure/make/$buildsystem pass weird flags to ld? typically, grep for "-soname"
13:53 <skarnet> if no -soname is given to ld (no -Wl,-soname to the link step of gcc) then the soname is still libosinfo-1.0 and you're fine
13:53 <skarnet> if it's a regular gnu configure then it's likely the case
13:54 <skarnet> or, a quicker test would be to try building the stuff that uses it and see if it breaks ;)
13:54 <fcolista> skarnet, thx!
13:55 <skarnet> np :)
15:01 blueness joined
15:16 Emperor_Earth joined
15:30 blueness joined
15:37 blueness joined
15:44 blueness joined
15:47 dsabogal joined
15:52 <fcolista> fabled: i'm struggling with a segfault. This is what i get with valgrind:
15:52 <fcolista> https://dpaste.de/B0U3/raw
15:52 <fcolista> is this related to a stack corruption?
15:53 <fcolista> might be related to an issue with stack (that in musl is small, while in glibc is bigger)?
15:54 <fcolista> I've this issue opened since a while, and openvas-dev are ignoring this issue:
15:54 <fcolista> http://lists.wald.intevation.org/pipermail/openvas-devel/2016-November/003769.html
15:56 czart__ joined
16:02 blueness joined
16:05 <leitao> ncopa, during my musl debug, I found an issue on ppc64le that is not solved. http://www.openwall.com/lists/musl/2017/03/08/2
16:07 BitL0G1c joined
16:28 mikeee_ joined
16:29 <TemptorSent> *yawn* 'morning all.
16:39 <TemptorSent> fabled: Are you still on by chance?
16:40 MH0815 joined
18:02 BitL0G1c1 joined
18:13 dfgg joined
18:14 fekepp joined
18:15 BitL0G1c joined
19:19 blueness joined
20:04 vakartel joined
20:13 ferseiti joined
20:17 zenny joined
20:18 <zenny> Hi, though it is beyond devel chat, I am asking because I could not find alpine-linux chat group. Could not find any documents on installing alpinelinux's root in zfs (which reportedly is possible since version 3.5 (https://www.alpinelinux.org/posts/Alpine-3.5.0-released.html). Can anyone elaborate or point to any document? Already tried with ROOTFS=zfs setup-alpine -m sys /mnt, but got installed into ext4. Even trying to load
20:18 minimalism joined
20:22 vakartel joined
20:29 blueness joined
20:44 Emperor_Earth_ joined
20:45 gromero joined
21:01 leitao joined
21:07 blueness joined
21:16 mikeee_ joined
21:24 fekepp joined
21:33 m41 joined
21:42 vakartel joined
21:44 zenny joined
21:55 gromero joined
23:04 laj joined