<    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 alacerda joined
00:02 alacerda_ joined
00:09 alacerda__ joined
00:12 alacerda_ joined
00:20 blueness joined
00:21 alacerda__ joined
00:22 alacerda_ joined
00:30 alacerda__ joined
00:31 alacerda_ joined
00:36 alacerda__ joined
00:45 alacerda_ joined
00:48 <pickfire> duncaen: Not sure, how do I check?
00:49 <duncaen> not sure there is /bin/libinput-{list-devices,debug-event}
00:50 thohal joined
00:51 <pickfire> duncaen: Yes, there is those stuff.
00:52 <pickfire> I hope you can bump me, sometimes I didn't even know someone messaged me.
00:53 <duncaen> was just an idea, never really used the wayland, it scares me a bit, but libinput looks ok tbh
01:21 LouisA joined
02:00 <tmh1999> anyone know how is APTS for now ? https://wiki.alpinelinux.org/wiki/Alpine_Package_Testing_Suite
02:27 t0mmy joined
02:36 Meths joined
02:57 s33se joined
03:04 ephemer0l joined
03:25 <TemptorSent> Query -- what does apk do with this construct exactly?: "apk add --root $sysroot $repo_opts $apkflags $pkgs <$ovlfiles"
03:28 <TemptorSent> (apkflags include --overlay-from-stdin and --clean-protected above)
03:30 <TemptorSent> More specifically, what is the expected content of $ovlfiles file and how is it applied WRT the apks? Before? After? Can files to NOT be incldued be masked?
04:03 cyteen joined
05:21 <fabled> TemptorSent, $ovlfiles is list of filenames extracted from the apkovl (.tar.gz). apk will not overwrite those from .apk packages.
05:30 mikeee_ joined
05:34 <tmh1999> fabled : I messaged you yesterday about YAMA, did you respond ? I was out of internet that time ...
05:35 <tmh1999> fabled : I am about to push another large number of patches, so in case you are about to check on mine, please hold, as it would save your time.
05:38 <kaniini> tmh1999: what is your question re: YAMA
05:39 <tmh1999> kaniini : Ah I just told fabled that I forgot to enable YAMA in my linux-vanilla s390x patch
05:39 <tmh1999> kaniini : which you told me earlier
05:39 <tmh1999> kaniini : *told me about YAMA
05:40 <TemptorSent> fabled: The two things I'm trying to accomplish is twiddling config files cleanly at first boot before starting services (including excluding files the apks install that I don't want), and being able to selectively extract certion portions of the file system from apks as needed (say /etc) with something like 'apk fetch -R -o $outdir --extract /etc'
05:42 <kaniini> tmh1999: ah :)
05:46 <tmh1999> kaniini : btw, do you know how is APTS now ? https://wiki.alpinelinux.org/wiki/Alpine_Package_Testing_Suite. I'd like to see/work on it.
05:47 <kaniini> we've pretty much replaced that with check() in APKBUILDs
05:50 <tmh1999> kaniini : beautiful
05:54 <fabled> tmh1999, no, i've been sleeping. please submit new config if you can, i hope to review and commit the pending s390 stuff today
05:56 <tmh1999> fabled : yeah I am working on them, will submit in a couple of hours
06:00 <fabled> great. back in 5mins.
06:12 fabled joined
07:06 andypost joined
07:25 <tmh1999> what should we do when a package only have git repo, and does not have a release tarball? I tried to git clone inside APKBUILD but it requires checksum thing.
07:26 <tmh1999> ah right, remove source=
07:27 <clandmeter> tmh1999: github?
07:27 <clandmeter> NIN101: done
07:27 slukin joined
07:27 <tmh1999> clandmeter: https://git.joeyh.name/git/myrepos.git/, source.myrepos.branchable.com
07:28 <tmh1999> clandmeter : this author hosts 2 git repos, and both don't have release tarball.
07:28 <tmh1999> clandmeter : nevermind, I got it figured out. clone inside APKBUILD, remove source= and sha512sums=
07:28 <clandmeter> ah right
07:28 <clandmeter> what is the project page?
07:29 <tmh1999> clandmeter : http://myrepos.branchable.com/
07:31 <tmh1999> I am looking to buy a small board, possibly rpi3, to log our IRC chat. Any recommendation ?
07:32 <clandmeter> we already do logging
07:32 <clandmeter> but you are free of course to log yourself
07:33 <tmh1999> clandmeter : is it in here http://dev.alpinelinux.org/irclogs/ ? Last time I check, it loses a lot of chat
07:33 <tmh1999> or am I wrong ?
07:33 <clandmeter> it does?
07:34 <clandmeter> tmh1999, there is also http://irclogger.com/.alpine-devel/2017-03-17
07:34 <tmh1999> clandmeter : maybe my bad. Thanks for another source !
07:34 <tmh1999> just save some bucks ^^
07:35 <clandmeter> well the zero is pretty cheap
07:35 <clandmeter> the power adapter is same price :)
07:35 <tmh1999> :)
07:36 <clandmeter> tmh1999, ask the project owner to do proper tags or tarballs.
07:36 <clandmeter> seems he chosen to remove his source from github because of TOS Changes.
07:36 <tmh1999> clandmeter : He has tags. So I checkout the tagged branch. Is it ok ?
07:37 <clandmeter> https://git.joeyh.name/index.cgi/myrepos.git/snapshot/myrepos-1.20170129.tar.gz
07:38 <clandmeter> not sure those snapshots are sane
07:39 <tmh1999> clandmeter : Wow. I have been looking for the cgit interface for a while. Thanks!
07:41 <clandmeter> tmh1999, it was not like it was really hidden ;-)
07:42 <tmh1999> clandmeter : my bad ^^
08:20 cyteen joined
08:38 Klowner_ joined
08:43 t0mmy joined
08:48 tmh1999 joined
08:56 vakartel joined
09:26 ageis joined
09:33 royger joined
09:46 mikeee_ joined
09:47 stwa joined
09:47 JStoker joined
10:09 fekepp joined
10:11 <^7heo> jirutka: I have a life.
10:12 <^7heo> and I'm also thinking that...
10:13 <^7heo> ...the reason I complained so much about your script is that you're solving a different problem.
10:16 <^7heo> TemptorSent: it was almost 21 when we talked
10:17 <^7heo> so about to be night :p
10:47 <tmh1999> ^7heo: what is your timezone ?
10:54 <scadu> CET :3
11:06 <pickfire> GG
11:06 <pickfire> Really?
11:06 <pickfire> Hahahhahahahaahah
11:06 <pickfire> c860144b
11:07 <pickfire> Wait
11:07 <pickfire> * c860144b testing/tlp: new aport
11:08 <pickfire> jirutka: Is it my eyes that are broken or it really did merged?
11:09 <pickfire> https://github.com/alpinelinux/aports/commit/c860144b5b79ea667fbedcc34a800637b0339b88#diff-e74cce27af5d72760a36be525d08364eR17
11:09 <pickfire> ncopa: How did it get there?
11:11 <pickfire> Sorry about messing up stupid commit in my repo but I didn't know how it get merged.
11:12 <pickfire> I got wacom working now, should I add support for x86 and arm as well?
11:13 <pickfire> But honestly, I don't think I would use a wacom tablet on arm.
11:13 <pickfire> Even though raspberry pi was previously my desktop.
11:14 <tmh1999> pickfire : GG lol
11:19 <pickfire> Haha
11:19 <ncopa> commit c860144b5b79ea667fbedcc34a800637b0339b88
11:19 <ncopa> Author: Ivan Tham <pickfire@riseup.net>
11:19 <ncopa> Commit: Natanael Copa <ncopa@alpinelinux.org>
11:19 <ncopa> apparently it was me who pushed it
11:19 <ncopa> sorry about that
11:19 <pickfire> tmh1999: Are you in +0800?
11:19 <pickfire> Yes
11:19 <pickfire> ncopa: But I am curious how did you get it?
11:19 <pickfire> I didn't submit that to ML.
11:28 blueness joined
11:32 blueness joined
11:39 <pickfire> ncopa: http://git.pickfire.tk/aports/commit/?id=74e9d1e506b389dfa097d79814853d970036f37e
11:39 <pickfire> Done
11:39 <pickfire> I am curious how alpine builder looks like.
11:40 <pickfire> tmh1999: Wow
11:40 <pickfire> 13 patches in a row
11:40 <pickfire> great work
11:41 blueness joined
11:41 <fabled> tmh1999, is fpreg_t patch submitted for upstream musl ?
11:42 <tmh1999> fabled : Yes. I thought you subcribed to musl too ?
11:42 <fabled> i am, but i'm little backlogged and not up-to-date on all of it
11:42 <tmh1999> I should have mentioned in the patch
11:43 <fabled> oh, it was committed already too
11:43 <fabled> ok
11:43 <tmh1999> yeah I waited until it was committed
11:43 <fabled> i should cherry-pick other musl patches too
11:44 <tmh1999> oh, that's what cherry-pick means
11:44 <tmh1999> been wondering for a while ..
11:44 <pickfire> tmh1999: Yead
11:44 <pickfire> I just used it for my first time the other day.
11:44 <tmh1999> pickfire : nice play
11:45 <pickfire> Just do git cherry-pick
11:45 <pickfire> git cherry-pick <commit>
11:45 <fabled> tmh1999, it means to take and apply individual patches. the git 'cherry-pick' command can be used to do it on git tree.
11:46 <tmh1999> fabled : yeah I am reading about it. so cool
11:46 <fabled> uuu. lazy binding emulation is there too
11:49 <pickfire> Is there an api for aports-turbo?
11:49 <^7heo> tmh1999: it depends on the day. but physically yes, CET.
11:50 <fabled> tmh1999, re: luajit/lua-turbo, it should be "all !s390x"
11:51 <fabled> otherwise it looks good stuff.
11:52 <tmh1999> fabled : I remember I saw somewhere both "!aarch64" and "all !aarch64". but "!390x" still works for me ?
11:52 <fabled> hum, i think the expected format is "all !foo"
11:52 <fabled> if it's !foo only it should not build on anything
11:52 <fabled> unless someone changed it
11:52 <tmh1999> ^7heo : Thanks, it's good to know to adjust my time to see everyone
11:53 <tmh1999> fabled : Okay cool
11:53 <^7heo> today it's more latin america
11:53 <pickfire> %3164
11:53 <algitbot> [alpine-aports] main/linux-grsec: Add support for hid wacom tablets - Patchwork: http://patchwork.alpinelinux.org/patch/3164/
11:53 <pickfire> Delete that
11:53 <tmh1999> fabled : Thanks for reading the patches :))
11:53 <pickfire> I forgot to apkgrel
11:54 <^7heo> tmh1999: yeah well good luck with that
11:55 <pickfire> Oh no delete %3164 as well
11:55 <algitbot> [alpine-aports] main/linux-grsec: Add support for hid wacom tablets - Patchwork: http://patchwork.alpinelinux.org/patch/3164/
11:55 <pickfire> Oh no delete %3165 as well
11:55 <algitbot> [alpine-aports] main/linux-grsec: Add support for hid wacom tablets - Patchwork: http://patchwork.alpinelinux.org/patch/3165/
11:57 <tmh1999> ^7heo : with what ?
12:00 BitL0G1c joined
12:04 <^7heo> tmh1999: synchronizing with everyone.
12:05 <jirutka> ^7heo: well, *you* have said that you’re gonna send PR, so I’m just asking when to expect it, nothing more ;)
12:05 <^7heo> jirutka: it didn't sounds like a question about when to expect it :)
12:06 <^7heo> but okay, you can expect it soon™
12:06 <^7heo> (Blizzard soon)
12:06 <jirutka> ncopa: see? that’s what I’m talking about with review process… this https://github.com/alpinelinux/aports/commit/c860144b5b79ea667fbedcc34a800637b0339b88#diff-e74cce27af5d72760a36be525d08364eR17 should never get into aports, this runscript is totally wrong
12:07 <jirutka> am I the only one here who care about QA? :(
12:08 <^7heo> no
12:08 <^7heo> I also do.
12:08 <^7heo> Very much so.
12:09 <^7heo> But atm my time is more fragmented than a sharpnel grenade during expansion.
12:09 <jirutka> and Valery has messed yet another abuild today… and Leonardo already pushed it… at least he reverted it right after that
12:09 <jirutka> what the heck is this day
12:09 <jirutka> I should go back sleep, maybe tomorrow will be better
12:12 <^7heo> that's a logical fallacy.
12:12 <^7heo> but it's true that sleep will help tho :P
12:14 <pickfire> I am trying to update openrc
12:14 <pickfire> But I don't get what the depend() {} does
12:14 <pickfire> init.d/localmount.in
12:15 <pickfire> old
12:15 <pickfire> - need fsck
12:15 <pickfire> + need fsck root
12:15 <pickfire> new
12:15 <pickfire> need fsck
12:15 <pickfire> use lvm modules mtab root
12:15 <pickfire> should I patch that as well?
12:15 <^7heo> pickfire: please don't paste on IRC.
12:15 <^7heo> pickfire: that's like IRC 101 :P
12:15 <pickfire> ^7heo: But it is short
12:15 <^7heo> no.
12:15 <^7heo> it isn't.
12:15 <^7heo> 3 lines is short.
12:15 <^7heo> that is 8.
12:15 <^7heo> more than double.
12:15 <pickfire> Thats 2 lines
12:16 <^7heo> two lines 2 times
12:16 <pickfire> That is to show the difference
12:16 <^7heo> long story short: this is really hard to read: it's a lot of short lines
12:16 <^7heo> it's
12:16 <^7heo> virtually
12:16 <^7heo> no
12:16 <^7heo> different
12:16 <^7heo> to
12:16 <^7heo> this
12:16 <^7heo> ok? :D
12:17 <^7heo> (I bet you can show the difference in one line, that's why I'm ranting)
12:17 <^7heo> (one LONG line)
12:17 <pickfire> Yeah, there's no difference
12:17 <pickfire> https://transfer.sh/bH5gE/0002-force-root-be-rw-before-localmount.patch
12:17 <pickfire> ^7heo: There's the paste
12:18 <^7heo> thanks
12:18 <pickfire> ^7heo: Do you understand it?
12:18 <^7heo> didn't open it yet.
12:19 <^7heo> but
12:19 <^7heo> there's one thing I can tell for sure
12:19 <^7heo> now that you pasted the thing, I understand the question MUCH better.
12:19 <^7heo> it looks like the old and the new are in the patch.
12:19 <^7heo> this is very weird.
12:20 <^7heo> it's not a valid patch AFAICT
12:20 <pickfire> Yes
12:20 <^7heo> coming from ncopa it's really weird.
12:20 <pickfire> I edited his patch
12:20 <^7heo> wait wat?
12:20 <pickfire> That's why I am asking here
12:21 <^7heo> pickfire: okay, there are two RIGHT ways to ask about the diff in a diff. And exactly two AFAIK.
12:21 <^7heo> pickfire: one of them is pasting TWO diffs and asking the diff between those.
12:21 <pickfire> How?
12:21 <^7heo> pickfire: the other one is the diff of diffs.
12:21 <^7heo> lemme show you.
12:21 <pickfire> But I only have one diff
12:21 <^7heo> no you've got two, obviously.
12:21 <pickfire> How do I get 2?
12:23 <pickfire> ^7heo: You mean https://transfer.sh/E6SFK/0002-force-root-be-rw-before-localmount.patch
12:23 <tmh1999> pickfire : please use http://tpaste.us/ or something so people dont have to download the patch to view
12:23 <* pickfire> goes random about patch
12:25 <pickfire> tmh1999: http://ix.io/p3M
12:27 <^7heo> pickfire: yeah that's what I meant.
12:27 <pickfire> Ah
12:27 <jirutka> pickfire: please read http://manpages.org/openrc-run/8
12:27 <^7heo> tmh1999: with curl you don't need to download the patch to see it ;)
12:27 <pickfire> ^7heo: How do you normally patch?
12:27 <pickfire> Yeah
12:27 <^7heo> pickfire: with patch -p1
12:27 <pickfire> I use curl
12:27 <^7heo> same here
12:27 <pickfire> patch -p1?
12:27 <pickfire> How to use?
12:27 <^7heo> man patch
12:27 <pickfire> Haha
12:27 <^7heo> what?
12:27 <pickfire> RTFM
12:27 <^7heo> indeed.
12:27 <jirutka> git diff | curl -F 'tpaste=<-' http://tpaste.us/
12:28 <^7heo> jirutka: diff -u otherwise.
12:28 <jirutka> yes
12:28 <^7heo> jirutka: so noobs don't spend 1h making a git repo JUST to get the output of diff -u ;)
12:28 <pickfire> jirutka: Wow that site is so nice and bloated
12:28 <jirutka> ^7heo: ofc -u should be used, I was too hurry :/
12:28 <^7heo> jirutka: :P
12:28 <^7heo> jirutka: alles klar
12:28 <skarnet> Herr Kommissar
12:29 <^7heo> :P
12:29 <pickfire> ix.io is easier
12:29 <skarnet> (that's an old one)
12:29 <^7heo> yeah ix.io is what I use
12:29 <^7heo> but it's in python and lacks features.
12:30 <^7heo> (python == not really efficient when being benchmarked by users)
12:31 <skarnet> it's something that will send stuff to the network. Nobody will notice the python slowdown.
12:31 <pickfire> ^7heo: Make it C?
12:31 <^7heo> pickfire: the problem isn't about the paste program.
12:31 <^7heo> pickfire: the problem is the URL.
12:31 <^7heo> ix.io is awesome.
12:31 <^7heo> and I really like that the dude implemented netrc.
12:31 <pickfire> Yes, it is short
12:32 <pickfire> ^7heo: How's netrc?
12:32 <^7heo> pretty good, thanks.
12:32 <^7heo> you?
12:32 <pickfire> I haven't really used it except for mail
12:32 <pickfire> s-nail*
12:35 <^7heo> I have to check snail
12:54 mikeee_ joined
12:54 <jirutka> ^7heo: wtf?! I thought that this file is already in the repository, so it’s more straightforward to diff it against last commit…
12:55 <jirutka> ^7heo: but it was just an example, I hope that everyone here is intelligent enough to understand that (s)he can replaced git diff with any other command…
12:57 <^7heo> jirutka: wait, what file?
12:57 <jirutka> ^7heo: the one that pickfire diffed
12:57 <^7heo> ah
12:57 <^7heo> I don't know actually.
12:57 <jirutka> ^7heo: so why are you bitching about setting git repository just to make a diff…?!
12:58 <^7heo> jirutka: no I am not.
12:58 <^7heo> jirutka: you are overrun and make mistakes in reading.
12:58 <^7heo> jirutka: relax, breathe deeply and re-read :P
12:59 blueness joined
12:59 <jirutka> ^7heo: probably? <^7heo>: jirutka: so noobs don't spend 1h making a git repo JUST to get the output of diff -u ;)
13:01 <^7heo> I don't understand what's not clear about me saying that "reminding people of the existence of 'diff -u' is a good way to avoid noobs to waste time with setting up a git repo"
13:01 <jirutka> ^7heo: yes, I’m quite stressed now, doing to many things and dealing with f*cking ownCloud that is basically in critical state (I’m reminding to my co-workers that we MUST migrate the data really SOON and finally shut it down, b/c it’s a ticking bomb)
13:01 <jirutka> nevermind, probably I’ve really misunderstood you
13:01 <^7heo> jirutka: it's all good, I know how stress works; and how it can make one rant and be über aggro.
13:02 <^7heo> jirutka: I'm the first one to be WAY too aggro over people when I'm stressed.
13:02 <^7heo> You won't find it difficult to find proof of that on IRC :P
13:02 <^7heo> especially around those parts :D
13:03 <^7heo> jirutka: I thought that seafile was much better than owncloud btw.
13:03 <^7heo> never checked, but anything is better than owncloud if you ask me.
13:17 farosas joined
13:22 <jirutka> ^7heo: I know about Seafile and no, I’m really not sure if it’s any better than ownCloud
13:22 <jirutka> ^7heo: I’ve tried to package it and hence read part of the source code, sent few patches and experienced how they (not) collaborate with community
13:29 <^7heo> ah dang
13:29 <^7heo> well, thanks for the info :)
14:00 <pickfire> My thinkpad hangs a few time when abump stuff (especially firefox)
14:01 <pickfire> I heard seafile is better
14:02 minimalism joined
14:10 ferseiti joined
14:18 <^7heo> pickfire: again, it's *not* hard to do better than owncloud.
14:20 <pickfire> ?
14:20 <jirutka> it’s not hard to be better at X when X do something horribly terribly wrong
14:21 <jirutka> s/wrong/bad/
14:21 <jirutka> but that doesn’t mean that Y is good
14:23 <^7heo> indeed.
14:23 leo-unglaub joined
14:26 <pickfire> ncopa: I have bump some packages and as well created some.
14:27 <pickfire> I lost track of the count
14:27 <pickfire> Where should I send it?
14:27 <pickfire> ML or GH?
14:27 <^7heo> github will do that for you, if you use it.
14:27 <^7heo> (the counting)
14:27 <pickfire> Okaf
14:27 <pickfire> 40^
14:27 <pickfire> ?
14:27 <pickfire> About that
14:27 <jirutka> uh, definitely GitHub
14:28 <jirutka> it’d be really time consuming to verify 40 pkgs basically completely manually
14:30 <pickfire> Wait, still building firefox, hope it does't hangs
14:30 <pickfire> Or I don't care, just send and let travis test is
14:30 <pickfire> Or I don't care, just send and let travis test it*
14:30 <jirutka> please make single PR per package, or at least separate big ones like Firefox
14:31 <jirutka> b/c there’s a time limit and log size limit on Travis…
14:33 <pickfire> Oh shit
14:33 <pickfire> I will never do that
14:33 blueness joined
14:34 <pickfire> jirutka: Please help me
14:34 <pickfire> jirutka: http://git.pickfire.tk/aports/
14:34 <pickfire> I need to take shower and sleep
14:35 <pickfire> Tomorrow I am going earlf
14:35 <pickfire> early*
14:36 <pickfire> ANYONE: Please help to merge wave of patches at http://git.pickfire.tk/aports/ or shit
14:36 <pickfire> http://git.pickfire.tk/aports/
14:36 <pickfire> https://github.com/alpinelinux/aports/pull/1020
14:36 <pickfire> What happened to that
14:37 <pickfire> jirutka: Oh no, my previous patches are gone again.
14:37 <pickfire> Luckily, it was committed to master.
14:38 <* pickfire> phoof, gone
14:40 <pickfire> Wow, travis build firefox so damn fast compared to my computer.
14:50 blueness joined
15:02 leo-unglaub joined
15:15 czart_ joined
15:18 <jirutka> pickfire: could you please read some git tutorial?
15:18 <jirutka> pickfire: it’s not that hard, it’s just about switching branches
15:18 <pickfire> jirutka: I know.
15:18 <jirutka> then I can’t understand how you can do it wrong
15:19 <jirutka> or how it can be even done wrong
15:19 <pickfire> But I don't want to go switch one by one and have 40+ branches
15:19 <jirutka> git does not allow you to rewrite something without using --force
15:19 <pickfire> I just want to keep the history linear with --force
15:19 <jirutka> not needed to separate them all, you can keep e.g. all py-* pkgs in single branch/PR
15:20 <pickfire> Ah
15:20 <jirutka> if you don’t master git, never use --force
15:20 <pickfire> jirutka: But how do I move firefox?
15:21 <jirutka> git am <SHA>
15:21 <jirutka> SHA of the firefox patch
15:21 <jirutka> run git am on the target branch
15:21 <pickfire> It is on top of the other patches
15:21 <jirutka> eh, pardon
15:21 <jirutka> I mean git cherry-pick
15:21 <pickfire> Ah
15:21 <jirutka> you can use git am too, but with patch file, not just SHA of the commit
15:22 <pickfire> jirutka: How do I remove main/redis, main/nss... below py-*?
15:23 <pickfire> I mean definitely need to force right?
15:23 <pickfire> Even so git logs is messed up so need force push
15:23 <pickfire> I bet there won't be a single force
15:24 <jirutka> well, I would collect SHAs of the py-* patches and use git cherry-pick…
15:24 <pickfire> But then history is change
15:24 <pickfire> Need git push
15:24 <jirutka> yes, but you’ll create a new branch
15:24 <pickfire> --force
15:24 <pickfire> jirutka: Create new branch from where?
15:24 <jirutka> it was just a rule of thumb, if you want to keep your existing PR and clean it, then you must use --force
15:24 <jirutka> from master
15:25 <pickfire> Nevemind
15:25 <jirutka> or you can create patch file from all of these commits using git format-patch
15:25 <jirutka> and then apply them to new branches using `cat foo.patch | git am`
15:26 <pickfire> I will fix it after I come back from holidays and adding krita and kde friends to the list.
15:26 <jirutka> if it’s easier for you to work with patch files
15:26 <pickfire> I don't like working with patch files
15:26 <pickfire> I don't even know the correct way of patching.
15:26 <pickfire> Bye, need to pack things and sleep.
15:27 <jirutka> ok
15:27 <pickfire> Good luck and have a nice day!
15:36 <ncopa> this is a scary change: http://tpaste.us/XE1B
15:36 <ncopa> i am grouping the alpine build keys by architecture
15:37 <ncopa> and only enable those apk keys that are relevant for that architecture
15:38 stwa joined
15:38 <ncopa> this is so that people who have physical access to a given build server and can get the private key for that arch
15:39 <ncopa> will only be able to use that key on machines for that architecture
15:39 <ncopa> so if you have physical access to x86_64 build server (and private key), you will not be able to build stuff for other architectures
15:40 <ncopa> using that key
15:40 <ncopa> that is the idea at least
15:40 <yGweSm1OzVHe> it would be preferable to have the keys offline - will ponder how to do this correctly
15:41 <ncopa> we do make all the keys available via the package so you can easily get the pubkey for other architectures in case you want install packages cross arch
15:41 <ncopa> eg if you want crosscompile
15:41 <ncopa> yGweSm1OzVHe: its the priv key used during building package
15:44 <ncopa> oh
15:44 <ncopa> it also means that this package is no longer architecture independent
15:50 thohal joined
15:56 <duncaen> what is apk fetch coffee :D?
15:57 <ncopa> try --force
15:57 <duncaen> heh nice, wasnt sure if i want to try it
15:58 <ncopa> i once tried to implement --russian-roulette
15:58 <ncopa> which 1 time out of 6 would execute apk del '*'
15:58 <ncopa> no quesions asked
15:59 <duncaen> let the use seed random :D
15:59 <ncopa> as a safeguard i added an --interactive feature so it woudl actually ask "are you sure"
15:59 <duncaen> *user
15:59 <ncopa> but there was a bug in that part
16:00 <ncopa> so i blew away my system :)
16:00 <ncopa> i realized that it was mayve not a great idea to have that feature available at all on production systems :)
16:01 <TemptorSent> *lol* The world saved by your own bug :)
16:02 <duncaen> is there a way in apk to propagate new signing keys from the repository, or is this something that would requiere adding the keys to keys_dir?
16:02 <TemptorSent> I always liked to include a self-destruct button on machines I built... then I triggered one accidentally.
16:02 <ncopa> TemptorSent: yes, the problem is when that you need to test stuff to know if it works..
16:03 <ncopa> duncaen: we ship the keys in a package
16:03 <ncopa> so apk upgrade will give you new keys
16:03 <TemptorSent> BTW: Regarding abuild-sign, changing mv to mv -f eliminates the interactive problem -- stupid default!
16:03 <ncopa> TemptorSent: yes, that is what i tried to say the other day
16:03 <ncopa> or maybe i just thought it for myself
16:04 <duncaen> ah ok, xbps ships keys in the repodata which is a bit scary, it woudlnt add them automatically you have to type yes in any case even with -y but still
16:04 <TemptorSent> ncopa: Right, I'm just verifying that it in fact fixes the issue.
16:05 <TemptorSent> ncopa: And I'm also seeing some very strange behaviour I need to track down... bind mounts are showing up with a source of the device the source directory is on, not the source directory.
16:05 <ncopa> duncaen: have you heard of TUF? the update framework
16:06 <ncopa> https://theupdateframework.github.io/
16:06 <ncopa> good stuff there
16:06 <duncaen> no, looks interesting
16:06 <TemptorSent> ncopa: /dev/sda2 mounted on /mnt, /mnt/tmp bind mounted on /tmp. mount shows /dev/sda2 mounted on /tmp
16:06 <ncopa> we will implement some of the ideas in next apk
16:07 <ncopa> TemptorSent: does that happens with gnu util-linux too?
16:07 <TemptorSent> ncopa: I'm seeing it in /proc/mounts!
16:07 <ncopa> so its kernel
16:07 <ncopa> i suppose its a feature not a bug
16:08 <TemptorSent> So either a very fubared mount command or a broken kernel.
16:08 <TemptorSent> But it appears to be causing problems at boot time as well.
16:09 <TemptorSent> So I'd like to see if others are able to reproduce the behavior and determine where it occurs.
16:09 <duncaen> hm yea looks a bit much to implement all the features
16:09 <ncopa> but they show some of the problems
16:10 <duncaen> the biggest problem for me is that we cant really change anything about it without running two versions at once to not break backwards compatibility
16:13 <TemptorSent> That's quite an ambitious spec. I don't know that I like the idea of parsing json for metadata, but that's not too ugly even.
16:14 mikeee_ joined
16:15 <duncaen> xbps uses proplists and changing this seamlessly is impossible :s
16:28 <TemptorSent> Couldn't we implement this direcly using git? Store the signatures for binaries in the tree and sign the commits. Just compare multiple repos to ensure no tampering.
16:28 <ncopa> i think i'd like to tag new abuild next week
16:29 <^7heo> ncopa: is everything in the alpine image necessary?
16:30 <TemptorSent> ^7heo : Which image? :)
16:30 <^7heo> (docker image)
16:30 <TemptorSent> ncopa: Oh, that reminds me - I ran into somewhat of a show-stopper for cross-arch building.
16:30 <^7heo> (sorry, I meant to write docker alpine image, and apparently omitted it)
16:30 <^7heo> like, scanelf is installed.
16:30 <TemptorSent> ncopa: Everything worked fine and I was successfully building aarch64 uboot images from x86_64 host...
16:30 <^7heo> why?
16:31 <^7heo> dependency on pax?
16:31 <TemptorSent> ^7heo: Scanelf is used by lddtree for update-kernel/mkinitfs
16:31 <^7heo> ah ok.
16:31 <^7heo> thanks.
16:31 <TemptorSent> ^7heo: Yeah, ran into that one already ;)
16:31 <ncopa> but you dont need mkintifs in docker image
16:32 <ncopa> World updated, but the following packages are not removed due to:
16:32 <ncopa> scanelf: musl-utils libc-utils
16:32 <ncopa> its used by ldconfig
16:32 <^7heo> ah ok
16:33 <TemptorSent> ^7heo: You might be able to make a shaved image.
16:33 <^7heo> what do you mean?
16:33 <TemptorSent> ^7heo: Install only the packages you absolutely need and excise the orphan files.
16:33 <^7heo> ncopa: just fyi, I'm writing a script that copies all the needed files from a running alpine into a folder, in order to chroot to it
16:34 <^7heo> TemptorSent: that's why I'm using the docker image, that work is already done afaik
16:34 <^7heo> ncopa: much like the docker image, but without docker, only with chroot.
16:34 <ncopa> ^7heo: interesting
16:34 <TemptorSent> ^7heo: Well, sorta. You could probably find quite a bit to trim still.
16:34 <^7heo> ncopa: how about unifying that process into using that script to generate the docker image too?
16:34 <ncopa> well
16:34 <^7heo> ncopa: that way it's maintained and can be used both ways.
16:35 <TemptorSent> ^7heo: Have that mostly :)
16:35 <^7heo> ncopa: unless you already got something that does that ;)
16:35 <ncopa> we do ship minirootfs
16:35 <^7heo> TemptorSent: if you know how to trim the docker image while not removing important features, I'm sure ncopa would be interested.
16:35 <ncopa> a tarball with minimal stuff
16:35 <^7heo> ncopa: the point is to get it from a running system
16:35 <^7heo> ncopa: without the need for a network connection.
16:36 <ncopa> TemptorSent has done some great work with the scripts generating the images
16:36 <ncopa> and the minirootfs
16:36 <TemptorSent> my mkimage branch actually can build miniroot too
16:36 <^7heo> ncopa: i.e. to be able to have a docker-like-without-network chroot when you're offline.
16:36 <duncaen> basically mkinitfs with more modules?
16:37 <ncopa> what i need/want is generate the docker image when we tag releases
16:37 <TemptorSent> ^7heo: https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
16:37 <^7heo> TemptorSent: will check that out, I think you've linked it yesterday and I read it very fast.
16:37 <ncopa> so we need to build the rootfs tarball when we build the iso images
16:37 <TemptorSent> Yeah, it can do pretty much anything you care to with a bit of fiddlign.
16:38 <ncopa> the major problem I have with TemptorSent's work is that it just so much :)
16:38 <^7heo> TemptorSent: my idea was to do the equivalent of a virtualenv for python
16:38 <^7heo> TemptorSent: if you know what that is
16:38 <ncopa> and i have not known TemptorSent long enough to trust him
16:38 <^7heo> TemptorSent: but for alpine.
16:38 <ncopa> but this experience here will help on that
16:39 <^7heo> well, we can crowd review and report, and assert :)
16:39 <TemptorSent> ncopa: I have it able to build the same profile with multiple base image types now as well, so you could configure once and drop images for multiple archs /vm hosts.
16:39 <ncopa> good
16:39 <ncopa> it does looks good
16:39 <duncaen> ^7heo: but virtualenv just links a few binaries and sets and enivronment variable
16:39 <ncopa> i want this merged before 3.6
16:40 <^7heo> duncaen: foobar/bin/python ... regular file
16:40 <^7heo> duncaen: no, it copies.
16:40 <ncopa> which means it needs to be merged within a week or two
16:40 <ncopa> hum
16:40 <TemptorSent> ^7heo: Yeah, I believe you could pull from the running system with a little apk trickery ... apk info -L for all installed packages | cpio?
16:40 <^7heo> duncaen: so essentially the idea here is the same
16:40 <^7heo> duncaen: plus chroot.
16:40 <^7heo> with busybox it'd be very easy.
16:41 <^7heo> TemptorSent: I actually would go for: mkdir $destdir; cp $list_of_needed_files $destdir
16:41 <TemptorSent> ncopa: Don't trust me too much, I'm rusty and out of practice :) I try to code keep my code clear enough to read.
16:41 <^7heo> TemptorSent: that should do it kinda
16:41 <duncaen> would be easy if you use your package manager and the cache
16:42 <TemptorSent> ^7heo: What's generating the list of needed files?
16:42 <^7heo> TemptorSent: modulo the directory names.
16:42 <^7heo> that's my current problem.
16:42 <^7heo> I am using the list of files from the docker image.
16:42 <duncaen> and keep in mind symlinks :P
16:42 <ncopa> ok i think its weekend for me now
16:42 <^7heo> ncopa: o/
16:42 <^7heo> ncopa: take care and have fun :)
16:42 <ncopa> you too
16:42 <^7heo> duncaen: ofc I keep in mind symlinks ;)
16:42 <ncopa> all of you
16:42 <TemptorSent> ncopa: Have a great weekend!
16:42 <^7heo> ncopa: thx )
16:43 <TemptorSent> ^7heo: cpio is your friend :)
16:43 <TemptorSent> It takes a list of files and copies them to the archive or target directory
16:44 <TemptorSent> so it'd be (mkdir $target ; cpio -di < $listfile)
16:44 <duncaen> i never got it working with multiple levels of symlinks, dont remember the exact problem, afaik it was something like /bin/ > usr/bin/ /usr/bin/foo > bar
16:45 <TemptorSent> If you don't like cpio, there's always tar :)
16:47 <^7heo> I like cpio
16:47 <^7heo> :D
16:47 <duncaen> TRAILER!!!
16:49 <^7heo> hmmm?
16:49 <^7heo> duncaen: my experience with symlinks is: recreate them.
16:52 <TemptorSent> ^7heo: That's the reason for using tar/cpio -- they handle links and device nodes cleanly.
16:52 <^7heo> really?
16:52 <^7heo> even symlinks with absolute paths?
16:52 <TemptorSent> ^7heo: Yup.
16:53 <^7heo> (since it's meant for a chroot that should work too, but still)
16:53 <TemptorSent> ^7heo: As long as the absolute path exists in the chroot, your're good.
16:53 <^7heo> yeah that's what I meant.
16:53 <^7heo> So that leaves us with one question
16:53 <TemptorSent> Othewise, you might need to run a link-fixer on stuff referencing odd locations.
16:53 <^7heo> how on earth do we generate the list of needed files?
16:54 <^7heo> because I'd rather have the list generate the docker image, not the other way around ;)
16:54 <^7heo> if you catch my drift.
16:54 <TemptorSent> apk info -L for each package would do it I think from the apk side.
16:54 <duncaen> use the package manager
16:54 <^7heo> I'm not sure that ALL of the base system is indexed into the package manager.
16:54 <TemptorSent> But lddtree basically does the heavy lifting on deps.
16:55 <^7heo> I've seen files with no parent packages,in the past.
16:55 <^7heo> not sure if it was a bug
16:55 <^7heo> but I have.
16:55 <TemptorSent> Actually, the entire base system is packaged AFAIK now.
16:55 <duncaen> going through the lddtree route seems only usefull if you only want specific binaries
16:55 <TemptorSent> ^7heo: Except for the generated ones on the image (mkinifs, kernel configs, etc)
16:55 <TemptorSent> duncaen: That's the idea.
16:56 <^7heo> ok
16:56 <TemptorSent> mkimage knows how to spit out a rootfs already, so perhaps start with the skel profile and see what's on the image to cut still.
16:56 <^7heo> I think we're unto something here.
16:57 <^7heo> jirutka also did something comparable, but with a different goal; and that was what I was discussing yesterday: https://github.com/jirutka/alpine-chroot-install/
16:57 <TemptorSent> I already knocked things down to essentially the bare minimum of packages, and we can feed apk a list of files NOT to extract, so that gives us a pretty minimal baseline need :)
16:58 <^7heo> the main difference between my idea and what jirutka does is that jirutka has (potentially) ANY unix system chroot into an alpine one
16:58 <^7heo> my idea would just be to spawn virtualenv for alpine.
16:59 <^7heo> so from alpine to alpine, only.
16:59 <^7heo> rootless if possible.
16:59 <TemptorSent> ^7heo: Should be easy enough..
16:59 <^7heo> (aside from the chrooting)
16:59 <TemptorSent> Rootless is hard.
16:59 <^7heo> nah I thought about dumping a script in the virtualenv
16:59 <^7heo> that would do all the root-needing things we need
17:00 <^7heo> mount and chroot and all
17:00 <duncaen> just use a usernamespace instead of chroot
17:00 <TemptorSent> ^7heo: You'll have to do all the preconfig.
17:00 <^7heo> duncaen: nah
17:00 <TemptorSent> ^7heo: Yeah, that works - you'll just have to preload your environment and not have anything on low ports.
17:00 <^7heo> yeah
17:01 <^7heo> duncaen: maybe as an alternative
17:01 <^7heo> duncaen: but it's way too specific to recent linuxes.
17:01 <duncaen> hm alpine to alpine doesnt already include this?
17:01 <^7heo> what do you mean?
17:02 <duncaen> if you just write a script to chroot from alpine hosts into alpine chroots you created doesnt this already include a "newer" kernel
17:03 <TemptorSent> duncaen: Um, no...
17:03 <TemptorSent> duncaen: chroot has nothign to do with the kernel at all.
17:03 <duncaen> i know, but the alpine system on the host
17:04 <TemptorSent> duncaen: You're still on the same system, same kernel, same file system, etc, just treating a different point in the filesystem as the root.
17:04 <duncaen> or is this just to create chroot tar balls that you then run on your debian x.y box?
17:04 <duncaen> i know what a chroot is
17:05 <TemptorSent> duncaen: Chroots are great for development environments, sandboxing, an contanerizing certain applications, but they don't get you anythign you didn't have on the bare system like a VM can.
17:05 <^7heo> duncaen: the ONLY reason for the chroot to occur is because we need to reset the shell path.
17:05 <^7heo> duncaen: to consider the new directory as "root"
17:05 <^7heo> exactly like in a python virtualenv.
17:06 <^7heo> and docker obviously is like a chroot, but on steroids, because it adds a lot more features.
17:06 <^7heo> so the idea is "the docker of the poor, for offline uses"
17:06 <^7heo> basically.
17:07 <duncaen> yes and i suggested user anmespaces to drop the root requierement
17:07 <^7heo> and without cgroups
17:07 <^7heo> yeah and I answered that namespaces are a good idea as an alternative.
17:07 <^7heo> but for the first one, I'd try chroot.
17:07 <^7heo> and let's see where that goes.
17:08 <duncaen> btw take a look at this if you need simple "containers" https://github.com/arachsys/containers
17:09 <^7heo> duncaen: there's a HUGE gap between what we're talking about and you're suggesting.
17:09 leo-unglaub joined
17:09 <duncaen> ?
17:09 <^7heo> duncaen: the idea we're discussing is a mkdir followed by a cpio followed by a "sudo chroot-script.sh"
17:09 <^7heo> and that should be ALL (afaik)
17:09 <^7heo> there's no recompilation of a C binary involved, no advanced kernel magic, etc.
17:09 <duncaen> oO
17:09 <^7heo> s/recomp/comp/
17:10 thohal joined
17:10 <duncaen> there is setuid involved which owuld be a turnoff for me
17:10 <^7heo> there are setuid binaries involved everywhere in your system.
17:10 <^7heo> deal with it.
17:10 <duncaen> not really
17:11 <^7heo> last time I checked, ping was a link to /bin/bbsuid
17:11 <TemptorSent> ^7heo: (mkdir -p $target && cpio -id < $filelist && sudu chroot $target /bin/sh -c su $user)
17:11 <^7heo> and that's just the first I can think of.
17:11 <duncaen> ping can work iwth capabilities
17:11 <^7heo> TemptorSent: I wish we had sudu, but we'll have to work with sudo :P
17:12 <TemptorSent> *lol*
17:12 <^7heo> TemptorSent: and you're missing the mount -bind and such
17:12 <^7heo> there's four mounts we have to do
17:12 <^7heo> dev, pts, sys and pro
17:12 <duncaen> /usr/bin/iputils-ping = cap_net_raw+ep
17:12 <^7heo> c
17:12 <^7heo> duncaen: now it can.
17:12 <^7heo> duncaen: that's fairly recent.
17:13 <TemptorSent> ^7heo: Hmm, maybe and maybe not on the bind mounts even, depending on what we need.
17:13 <duncaen> not sure, fedora is removing setuid stuff since 2011
17:14 <^7heo> TemptorSent: I wanted to put them in the exec-chroot script
17:14 <TemptorSent> ^7heo: the cpio can include the device nodes...
17:14 <^7heo> but we could totally have a flag to enable them
17:14 <^7heo> like -f (for full)
17:14 <^7heo> TemptorSent: I'd rather remount
17:14 <^7heo> TemptorSent: it's easier to clean IMHO
17:14 <duncaen> ping with capabilities was broken in 2008 https://bugzilla.redhat.com/show_bug.cgi?id=455713 in 2010 they added it again
17:15 <^7heo> duncaen: 2011 *is* relatively recent.
17:15 <^7heo> also
17:15 <duncaen> in debian releases maybe :P
17:15 <TemptorSent> ^7heo: Right now, I'm having issues with bind mounts showing up wrong in /proc/mounts
17:16 <^7heo> duncaen: anyway, currently, mount and unmount are suid.
17:16 <^7heo> duncaen: and that is used during boot.
17:16 <^7heo> duncaen: like it or not.
17:16 <^7heo> same for su (ofc), passwd
17:16 <duncaen> and boot is uid 0
17:16 <TemptorSent> ^7heo: Actually, bb-suid isn't needed for boot...
17:17 <^7heo> yeah because as duncaen said, the boot happens as root
17:17 <^7heo> but my point was
17:17 fabled joined
17:17 <^7heo> there's a couple of things that are suid root
17:17 <TemptorSent> ^7heo: On an embedded system, you might not have any user but root :)
17:17 <^7heo> including sudo, Xorg, etc.
17:17 <^7heo> and well...
17:18 <^7heo> they're used that way.
17:18 <duncaen> my point is just that i try to avoid setuid wherever possible, we dont really have to argue about it i understand your point too
17:18 <^7heo> and if we have to bitch about one of them being suid
17:18 <^7heo> I wouldn't really, REALLY wouldn't go for chroot (which isn't btw)
17:18 <TemptorSent> ^7heo: What's the chance of just getting chroot to use caps?
17:19 <duncaen> the problem with most caps is that they are effecitvely root too
17:19 <^7heo> TemptorSent: what's the issue with using sudo just for that chroot?
17:19 <^7heo> duncaen: exactly.
17:19 <^7heo> also
17:19 <TemptorSent> ^7heo: None, except you do need to be root to do it... I'm thinking fixing the abuild problem :)
17:19 <^7heo> we could replace sudo by s6-sudo if that is an issue.
17:19 <^7heo> what abuild problem?
17:20 <TemptorSent> ^7heo: Eliminate the necessity of suid for building packages.
17:20 <^7heo> ah
17:20 <^7heo> yeah
17:20 <^7heo> that would be neat
17:20 <duncaen> why does it need suid?
17:20 <^7heo> but in a chroot, that would be possible.
17:20 <TemptorSent> chroot+fakeroot.
17:20 <^7heo> and fabled could even give some feedback on that right now.
17:21 <^7heo> afaik he was working on something alike
17:21 <duncaen> we have different chroot "styles" in xbps-src, you can choose between normal chroots, user namespaces etc
17:21 <^7heo> duncaen: yeah but that is not yet here.
17:21 <TemptorSent> duncaen: That's something that would be great to support. Feel like lending some code? :)
17:22 <^7heo> Anyway
17:22 <duncaen> https://github.com/voidlinux/xbps/tree/master/bin, xbps-uchroot and xbps-uunshare for namespaces
17:22 <^7heo> I gotta go
17:22 <^7heo> but next week I'll need that chroot thingie
17:22 <^7heo> esp for building a package.
17:22 <^7heo> so that'll be great to get it figured out.
17:23 <TemptorSent> duncaen: see link to my branch of mkimage a couple pages back, I'd like to drop it in there if nothign else.
17:23 <duncaen> uchroot is based on linux-user-chroot
17:23 <^7heo> hmm
17:23 <^7heo> but then, we still have the abuild issue.
17:23 <^7heo> (and we'd need to suid root it for now)
17:23 <^7heo> or would we?
17:24 <^7heo> I'd like to try asap to see if we can do without.
17:24 <duncaen> uunshare doesnt needs suid
17:24 <^7heo> nah abuild.
17:24 <duncaen> why would it need suid?
17:25 <^7heo> because it needs root rights atm.
17:25 <TemptorSent> duncaen: It needs to install the builddep pand dep packages on the host system ATM, but with a chroot, an entire build environment with the specified deps and ONLY the deptree can be populated.
17:26 <TemptorSent> This would fix a lot of dependency bugs real fast I bet too :)
17:26 <^7heo> yeah
17:26 <^7heo> that's the real thing I wanna test
17:26 <duncaen> ah ok
17:26 <^7heo> can we ACTUALLY just mkdir && cpio && chroot && abuild
17:26 <^7heo> because that would be freaking ace.
17:27 <duncaen> thats what xbps-src does, but it uses xbps to populate the chroot, and we keep it around
17:27 <TemptorSent> ^7heo: Probably yes, but for proper testing, we'll want to extract the apks fresh from scratch to ensure our entire dep chain is good.
17:27 <^7heo> $ docker run --rm -it alpine:latest /bin/sh
17:27 <^7heo> # find / -type l -exec ls -l {} \; | grep bbsuid
17:27 <^7heo> #
17:27 <^7heo> nice.
17:28 <^7heo> also
17:28 <^7heo> $ docker run --rm -it alpine:latest /bin/sh
17:28 <^7heo> # find / -type l -exec ls -l {} \; | grep '^...s'
17:28 <^7heo> #
17:28 <^7heo> Also nice.
17:29 <TemptorSent> ^7heo: If we could just get the caching in apk to actually work every time, it wouldn't even be painful.
17:29 <^7heo> yeah
17:29 <^7heo> but so far the docker image has no suid
17:29 <^7heo> so I guess we don't need any.
17:30 <duncaen> because suid doesnt work in docker?
17:30 <^7heo> altho docker might have a specific docker mechanism to replace it.
17:30 <^7heo> duncaen: no idea.
17:30 <TemptorSent> I want to be able to tell apk to cache EVERYTHING it fetches, regardless of output type, location, root, whatever.
17:30 <^7heo> duncaen: I don't use docker much
17:30 <^7heo> TemptorSent: that might be a different problem to solve another time ;)
17:30 <^7heo> TemptorSent: but agreed, might be nice.
17:30 <duncaen> hm not sure there is a requierement for PR_SET_NO_NEW_PRIVS but i guess if you setuid to the mapped uid in the namespace it should work
17:31 <^7heo> TemptorSent: problem is, how would different apk share the same cache?
17:31 <TemptorSent> ^7heo: It's my biggest pain-point currently -- refetching and copying on the same FS
17:31 <^7heo> yes and no.
17:31 <TemptorSent> ^7heo: What does the cache care about it's contents? Each APKINDEX gets tagged as it is.
17:32 <^7heo> at least you're sure you're not missing a dep because you have it installed.
17:32 <^7heo> I guess it makes sense to have a local cache for apks on your gateway
17:32 <duncaen> with xbps-src you binary-bootstrap your masterdir, which is a chroot, it then just chroots into it and bindmounds the hostdir, which contains the cache, ccache cache and the local repository where it adds the resulting packages
17:33 <duncaen> binpkgs/ ccache/ repocache/ sources/
17:33 <^7heo> TemptorSent: I'm asking: if you cp the apk in the chroot, and the cache in the chroot, before you chroot, you effectively are duplicating it.
17:33 <^7heo> TemptorSent: so it's gonna be two unrelated APK distributions.
17:33 <TemptorSent> ^7heo: ln or bind mount :)
17:33 <^7heo> yeah ok
17:34 <^7heo> but then you hit the problem I was referring to
17:34 <TemptorSent> ^7heo: apk theoretically knows how to use hardlinks when possible.
17:34 <^7heo> and that is the problem I am trying to solve in the first place.
17:35 <^7heo> that if you have a dep installed, and you miss it in your APK, you'll only see it at travis (or build) time.
17:35 <TemptorSent> As long as you're on the same FS, ln should work fine.
17:35 <^7heo> sure
17:35 <TemptorSent> Nope, because you only link the apks themselves, not the extracted FS.
17:35 <^7heo> you mean the binaries?
17:36 <^7heo> wouldn't then the binary image be loaded in a different root, and use a different cache anyway?
17:36 <^7heo> unless you link the cache.
17:36 <^7heo> but then you'll create a disparity
17:36 <^7heo> you'll have missing packages from both sides.
17:36 <TemptorSent> ^7heo: You can have a pool full of .apks and the cache files needed, then use apk --root $target --initdb $apks
17:36 <^7heo> since the cache will have packages in your chroot AND in your real system listed the same way in world
17:37 <^7heo> oooh right apk --root
17:37 <^7heo> I missed that one
17:37 <^7heo> well, let's see
17:37 <^7heo> but I have to go home now
17:37 <TemptorSent> ^7heo: Yeah, that's what I'm using all over the place and why I'm in so much pain when I can't actully get the cache to do what I want!
17:37 <^7heo> I think I'm the only one left in the office atm.
17:38 <TemptorSent> ^7heo: Go home and relax! We'll pick this up later.
17:39 <duncaen> i guess i have to look more into apk, i dont really get the problem
17:53 leo-unglaub joined
18:05 <tmh1999> rnalrd : Thank you for reading/merging my patches :)
18:26 <fabled> duncaen, ^7heo : we are looking into using bubblewrap or potentially make it configurable backend. there's some proof-of-concept code, but it's still work-in-progress.
18:28 <TemptorSent> Hello fabled.
18:31 <TemptorSent> fabled: Any chance you could shed some light on how to fix this issue I'm seeing with apk?: I previously had mkimage hapilly fetching and building aarch64 images on my x86_64 host, then I created my own local apk repo and built some x86_64 packages into it. Now, aarch64 builds are failing because the warning about no aarch64 index in my local repo breaks the pipes from apk to tar/cpio.
18:31 tty` joined
18:32 <fabled> TemptorSent, care to file a bug?
18:33 <TemptorSent> fabled: Sure, but I'm afraid I can't do much about copy/pasting the output at the moment.
18:34 <TemptorSent> fabled: Do we have a bugserver on here?
18:34 <fabled> http://bugs.alpinelinux.org/projects/alpine/
18:35 <TemptorSent> fabled: The short report is that apk throws a spurious warning when a repository doesn't have all archs represented.
18:35 <TemptorSent> fabled: Also, any idea what happend to the gpm package? I actually could really stand to have my mouse on the console again.
18:36 <fabled> TemptorSent, originally we had only repositories for the current root in repositories file. since supporting cross root stuff, that changed, and there's some minor issues left like the one you have with the tar pipe
18:36 <fabled> TemptorSent, no idea about gpm
18:37 tty` joined
18:37 <^7heo> funny, I try to replace the mouse in the gui
18:37 <^7heo> and TemptorSent wants it in cli
18:38 <TemptorSent> ^7heo: About all I want it for is copy/paste -- which is what it's good for IMHO :)
18:41 <jirutka> ncopa: huh, when do you plain to release v3.6?
18:49 <jirutka> is Tuan M. Hoang here?
18:49 <duncaen> bubblewarp looks a bit complicated
18:50 volleyper joined
18:53 <tmh1999> jirutka : hello
18:54 <jirutka> tmh1999: hi
18:54 <jirutka> tmh1999: you’re Tuan M. Hoang?
18:54 <tmh1999> jirutka : yes I am
18:55 <jirutka> tmh1999: what does this mean “update new package Old package was removed” ?
18:55 <tmh1999> jirutka : It means the package was removed from the source, not available to download anymore
18:56 <tmh1999> or the author moved it to some other directory
18:56 <tmh1999> actually it's more like pkgrel bump, you know
18:56 <tmh1999> pkgver bump
18:57 <jirutka> tmh1999: aha. please when bumping abuild, follow standard commit message format: `<repo>/<pkgname>: upgrade to x.y.z` (or ”update” if you prefer) and maybe add info about the old package is not available anymore into body of the commit message
18:58 <tmh1999> jirutka : Thanks. Bet I have missed some points in the Alpine dev guide ...
18:59 <jirutka> tmh1999: actually I’m not sure if it’s written somewhere, but you can see it in git log; and also abump tool generates this message
19:00 <TemptorSent> Do we have a posix 'pax' tool anywhere?
19:00 <tmh1999> jirutka : Thanks for the advices. I am picking along with the processes.
19:07 blueness joined
20:10 blueness joined
21:02 KSD joined
21:03 <KSD> Hello everyone !
21:56 minimalism joined
22:06 <clandmeter> jirutka, we should add a github pr template with the dev guidelines.
22:06 <jirutka> clandmeter: you mean this one? https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md
22:07 <clandmeter> yes, and add it to the PR as a template
22:07 <clandmeter> so the dev has to remove it.
22:07 <jirutka> clandmeter: I’m afraid that ppl who needs this the most do not read it…
22:07 <clandmeter> maybe when he is forced to remove it, they will actually read it.
22:08 <jirutka> clandmeter: to be honest, it’s really too long…
22:08 <clandmeter> ive seen this practice more often .
22:08 <clandmeter> then fix it
22:08 <clandmeter> ;)
22:08 <jirutka> clandmeter: to be used as a template for PR, we should maybe make few check points that the contributor should agree with
22:09 <jirutka> I don’t mean literally “check it”, but…
22:10 <clandmeter> what im trying to solve is, most contributors dont read the contributors guide, cause they just miss it.
22:11 <clandmeter> and yes, it can be improved.
22:11 <clandmeter> not sure im the right person to correct my own words.
22:12 <clandmeter> anyway, its time for me to go to bed. dont go too late jirutka
22:12 <clandmeter> gnite :)
22:14 <jirutka> okay, I’ll look at it later; but not this weekend
22:14 <jirutka> good night
22:14 <kaniini> dell are extremely frustrating
22:15 <TemptorSent> kaniini: In what way? Their wondeful proprietary management?
22:15 <kaniini> their shipping department
22:16 <kaniini> i ordered a new laptop to put alpine on, right?
22:16 <kaniini> it's been sitting around some warehouse in Texas for the past week
22:18 <TemptorSent> kaniini: Yeah, love that too. Did you have a rush on it? I think that means they hurry up and set it on the warehouse shelf rather than taking their time about it :)
22:19 <kaniini> i just used 2-day shipping as per usual when i order from dell
22:19 <kaniini> let me put it this way...
22:19 <kaniini> TemptorSent: http://i.imgur.com/UB5LtFM.png
22:20 <kaniini> TemptorSent: do you see a problem here?
22:20 <TemptorSent> kaniini: Yeah, two days shipping, two weeks sitting around waiting to actually go somewhere.
22:20 <kaniini> all they have to do is put it in a box and send it out
22:20 <kaniini> it says it's done
22:20 <kaniini> ready to go
22:21 <TemptorSent> Estimated delivery: Today :)
22:21 <kaniini> i do not see how it could be delivered if they havent even sent it out the door
22:23 <TemptorSent> kaniini: Maybe they have H.G.Wells working for them...
22:24 <kaniini> so then i contact them
22:24 <kaniini> and they are like
22:24 <kaniini> oh that date is inaccurate
22:24 <kaniini> we can ship it any time between now and march 22
22:28 <tmh1999> kaniini : I've come to learn the hard way that things related to logistics usually not very precise. So everytime I order something, I expect my mind to be off from it, or it will kill me inside ...
22:28 <tmh1999> kaniini : it comes when it comes
22:28 <kaniini> lol
22:28 <kaniini> pretty much
22:29 <tmh1999> hurt, but true
22:30 <tmh1999> kaniini : or there's one thing is there was a snow blizzard in the US east coast, maybe it contributes to transporting from Texas to EU
22:30 <kaniini> no quite literally
22:30 <kaniini> dell just havent put it in a box
22:30 <kaniini> and sent it out the door
22:30 <kaniini> i could literally go pick it up
22:31 <kaniini> if i wanted to drive to texas
22:31 <kaniini> which involves entering trumpland so i dont know if i really want to ;)
22:31 <tmh1999> yeah fuck dell then
22:43 fekepp joined
23:42 alacerda joined
23:46 blueness joined