<    April 2017    >
Su Mo Tu We Th Fr Sa  
 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  
00:57 duncaen joined
01:01 <jirutka> Shiz: I’m idiot… I forgot to replace certs and remember that before bad… and after that I checked recompiled rustc and realized that I forgot to add the modified patch to sources…
01:01 <Shiz> hehe
01:28 s33se joined
01:48 blueness joined
02:17 tmh1999 joined
02:34 blueness joined
03:14 blueness joined
03:59 Emperor_Earth joined
04:43 <TemptorSent> Looking for input on why keys for arch x86_64 come up with aarch64 package signatures being untrusted.
04:45 <TemptorSent> I'm a bit stuck until I can figure that out as far as cross-arch building.
05:09 <Shiz> because the keys are different
05:09 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/main/alpine-keys/APKBUILD
05:11 tmh1999 joined
05:15 fabled joined
05:20 <TemptorSent> Is there a way to fetch the keys for the other archs from the host arch using some trusted key?
05:22 <TemptorSent> Or do we have to install the keys package first, thus play chicken-and-egg?
05:35 <TemptorSent> (grumbles or, option C, yet another disgusting hack of dumping it through tar and only extracting the /usr/share/apk directory BEFORE setting the target arch
05:41 <Shiz> all keys are in /usr/share/apk
05:41 <Shiz> even for the other arches
05:41 <Shiz> just copy from /usr/share/apk/keys/targetarch
05:47 <^7heo> moin Shiz
05:47 <^7heo> Shiz: do you ever sleep? ;)
05:48 <Shiz> no
05:48 <^7heo> I thought one would have problems doing that.
05:49 <skarnet> well you've seen Shiz, now you understand why he's that way
05:49 <TemptorSent> Shiz: Yeah, I was trying to maintain encapsulation a bit better than that.
05:50 <Shiz> skarnet: i take insult to this
05:50 <skarnet> it was a joke!
05:50 <Shiz> TemptorSent: the key package is always installed on the host, so...
05:51 <skarnet> (you'd know a joke from an insult if you had slept)
05:51 <TemptorSent> Shiz: Yeah, supposing the host is alpine of course.
05:52 <Shiz> i don't think that's an unfair assumption, considering you're likely also invoking apk
05:52 <TemptorSent> I'm trying to take as little for granted as I can about exactly what the host is.
05:52 <Shiz> if you have apk, you have alpine-keys
05:52 <TemptorSent> apk.static...
05:53 <TemptorSent> Anyway, I have a work around I think... and it makes sure I'm using the latest keys.
05:54 <Shiz> don't make things more difficult than they need to be
05:54 <TemptorSent> For a somewhat general-purpose tool, I'm not going to make too many assumptions.
05:55 <TemptorSent> apk may be abuild-apk or apk.static just as easily as /sbin/apk.
05:57 <Shiz> i5t's not general purpose though
05:58 <TemptorSent> So we must be hosted on alpine to build alpine components?
05:59 <Shiz> i think that is a fair assumption, yes
05:59 <Shiz> if you just want to rely on apk being available, install alpine-keys yourself
06:00 <TemptorSent> Yeah, that's what I'm doing basically, but only the part that isn't for the wrong arch, then I fetch the one for the right arch.
06:01 <Shiz> you don't really need to do the latter if you can just copy the keys over
06:01 <TemptorSent> Right, I mean I fetch it out of the directory
06:02 <TemptorSent> cp -L "$staging_apkroot/usr/share/apk/keys"/* "$staging_apkroot/etc/apk/keys"
06:02 <Shiz> don't do that
06:02 <Shiz> at least use the proper arch subdirectory
06:03 <Shiz> now you're copyingg a bunch of stuff in the staging keydir that is not relevant to it
06:03 <TemptorSent> er, oops - yes, arch is actually in my command.
06:03 <TemptorSent> That's what I get for typing without looking at it.
06:06 <TemptorSent> Anyway, much bigger issue is breakage related to the spurious warning ending up in my kernel verion when querying "WARNING: Ignoring /home/chrisgio/packages/testing/aarch64/APKINDEX.tar.gz" when I have not aarch64 repo at all in my personal directory, but do have x86_64.
06:06 <TemptorSent> fabled: Any thoughts ^^^
06:07 <TemptorSent> I can't shut it up either with -q
06:09 <TemptorSent> And somehow I don't think having a sed hack to remove my own personal repo from the repos file is going to be a good call ;)
06:12 tmh1999 joined
06:16 <^7heo> does anyone here know what packages are needed for zfs to work?
06:16 <^7heo> zfs, zfs-libs and zfs-utils-py I suppose?
06:17 <^7heo> maybe zfs-grsec too?
06:21 <Shiz> TemptorSent: redirect 2>/dev/null ?
06:21 <TemptorSent> ^7heo: You need zfs-grsec, spl-grsec, and zfs
06:22 <Shiz> TemptorSent: also, apk --repositories-file= exists
06:22 <Shiz> :p
06:22 <TemptorSent> Shiz: Not really a great solution, because then actual errors get burried.
06:24 <^7heo> TemptorSent: but I guess those will pull other stuff, like zfs-libs?
06:24 <TemptorSent> Shiz: The problem is that my repositories file has my local repo in it (as I suspect many users do), but I don't happen to have ANY aarch64 directory, let alone packages there. Rather than throwing a warning, it should show a message 'no index for arch '$arch' in repo '$repo', ignoring... displayed with verbose.
06:24 <Shiz> i think a warning is perfectly valid
06:24 <Shiz> you gave it a repo, that repo doesn't exist
06:24 <Shiz> plenty of reason for a warning
06:24 <TemptorSent> ^7heo: Yes, the rest SHOULD follow.
06:25 <^7heo> TemptorSent: I'm asking because I'm attempting to copy the right packages in the default install distrib
06:25 <TemptorSent> Shiz: Okay, great - let's break everything in unexpected ways because we only have packages for x86_64 in our custom repo at the moment.
06:25 <^7heo> so... any way to see the dependency graph with APK
06:25 <^7heo> ?
06:25 <Shiz> not apk's fault you gave it a repo that doesn't exist...
06:25 <Shiz> i don't understand why you're invoking apk without the proper --root anyway
06:26 <TemptorSent> So if a repo happens to be down at the moment, we want to have things fail strangely rather than just skip it?
06:26 <^7heo> Shiz: you're answering TemptorSent right?
06:26 <Shiz> yes
06:26 <^7heo> to both questions?
06:26 <Shiz> yes
06:26 <^7heo> danke
06:26 <Shiz> yes
06:26 <Shiz> ( ≖‿≖)
06:26 <Shiz> TemptorSent: nothing fails, it gives you a warning
06:26 <Shiz> on stderr
06:26 <Shiz> literally the best possible thing it can do
06:27 <Shiz> i don't understand how it fucks up your kernel version request
06:27 <^7heo> "nothing fails, it gives you a warning"
06:27 <Shiz> ^7heo: # apk dot btw
06:27 <^7heo> wait wat?
06:27 <Shiz> ^7heo: failure is fatal
06:27 <Shiz> this is not a failure, it's a warning
06:27 <TemptorSent> ^7heo: You can see the depends by doing 'apk fetch --simulate --recursive zfs zfs-grsec spl-grsec
06:27 <^7heo> ah no fail as in 'no fatal'
06:27 <^7heo> TemptorSent: yeah maybe better than having to read the dot graph.
06:27 <^7heo> thanks
06:28 <Shiz> TemptorSent: speaking of overthinking
06:28 <Shiz> how about # apk info -R zfs zfs-grsec spl-grsec
06:28 <Shiz> :P
06:28 <TemptorSent> Shiz: Every script that uses the output from 'apk search' directly goes straight to hell.
06:28 <Shiz> this is apk info
06:28 <Shiz> not apk search
06:28 <Shiz> and nobody said anything about sripts
06:29 <TemptorSent> Shiz: the warning from APK is what's breaking my scripts, as well as severeral existing scripts.
06:29 <TemptorSent> Shiz: apk info only works if you have the packages installed IIRC
06:30 <Shiz> i think i said something a while ago about not highlighting me in rapid succession
06:30 <Shiz> and no, it does not
06:30 <Shiz> https://txt.shiz.me/NTkyZTJhND
06:30 <^7heo> guys, the MBR is supposed to be 512 bytes right?
06:30 <Shiz> 448 bytes
06:30 <^7heo> yeah so less than 512
06:31 <^7heo> how come I have stuff after it?
06:31 <^7heo> syslinux?
06:31 <Shiz> the partition table
06:31 <^7heo> isn't the mbr including the partition table?
06:31 <^7heo> well, obviously not but...
06:31 <^7heo> I thought it was.
06:32 <Shiz> ^7heo: https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
06:32 <Shiz> :)
06:32 <^7heo> damn doc, all the things are on the web...
06:32 <^7heo> I wish I could just fetch a CLI friendly and readable version...
06:33 <Shiz> links exists
06:33 <^7heo> thanks
06:33 <^7heo> ?
06:33 <Shiz> i mean links(1)
06:33 <Shiz> :p
06:33 <^7heo> ah
06:33 <^7heo> yeah no not a fan of adding problems to my problems in order to not see the original problem.
06:34 <Shiz> TemptorSent: i see your point in that it's not printing to stderr
06:34 <Shiz> it should do that
06:34 <TemptorSent> Yeah, like I said, it behaves badly.
06:34 <^7heo> it could be worse.
06:34 <^7heo> it could behave badly AND be orange.
06:35 <TemptorSent> *LOL*
06:35 <Shiz> ah
06:35 <^7heo> (and waste most of its time playing golf)
06:35 <Shiz> looks like it's relatively easy to fix
06:35 <TemptorSent> Anyway, turns out the warning was masking the REAL problem, namely that I'm not getting a result.
06:36 <Shiz> TemptorSent: btw
06:36 <Shiz> -q should prevent it, i think
06:37 <TemptorSent> Yeah, but turns of warnings I want to see as well. I'll have to go insert it strategically in a few places because I can't just drop it in my _apk wrapper for apk without breaking things I want warnings for.
06:37 <Shiz> ¯\_(ツ)_/¯
06:37 <TemptorSent> Basically, I want warnings for anything BUT that.
06:37 <TemptorSent> And, preferably, to stderr :)
06:37 <Shiz> i think that's a silly request
06:37 <Shiz> to stderr can be done, however
06:40 <TemptorSent> Warning that a particular repo doesn't have your arch seems a bit different than warning that a signature is unverified.
06:40 <Shiz> not really
06:40 <Shiz> they both just mean the repo is unavailable
06:41 <TemptorSent> One of them is essentially a normal condition for anyone who works on multiple archs and uses the same repo list, the latter indicates a misconfiguration in-fact.
06:42 <Shiz> both are misconfigurations
06:42 <TemptorSent> But a query - is taking the return value of a variable assignment containing a command substitution POSIXly correct?
06:43 <TemptorSent> I'd argue that my repos file isn't misconfigured, I just haven't cross-built anything to aarch64 yet.
06:43 <Shiz> it's fine to not have packages
06:43 <Shiz> it's not fine to not have an index
06:43 <TemptorSent> Once I do, it will magically work.
06:43 <Shiz> also, needs example
06:44 <TemptorSent> It doesn't even have a directory, so it's the same as a repo that has the host down.
06:44 <Shiz> which is also bad
06:44 <Shiz> anyway
06:44 <Shiz> https://txt.shiz.me/MWE2YjE2Zj
06:44 <TemptorSent> It should silently fail to the next one, unless it was pinned.
06:44 <Shiz> here's your apk patch
06:44 <Shiz> definitely not
06:44 <Shiz> it should definitely not silently fail
06:44 <TemptorSent> So we shouldn't allow repos to cascade cleanly?
06:45 <Shiz> it does cascade cleanly
06:45 <Shiz> it just warns you about it
06:45 <TemptorSent> I thought that was the whole point of CDNs
06:45 <Shiz> why is this so hard
06:45 <Shiz> CDNs operate on the same single domain or even IP
06:45 <Shiz> so this has nothing to do with CDNs
06:45 <TemptorSent> Because warnings on a normal occurence break things.
06:45 <Shiz> https://txt.shiz.me/M2I2OTc0ZW
06:45 <TemptorSent> And yes, a set of mirrors is a CDN, if not the typical usage of the term these days.
06:45 <Shiz> botched some whitespace
06:46 <Shiz> wrong
06:46 <Shiz> anyway, with this patch it doesn't break things anymore
06:46 <Shiz> feel free to forward it to ncopa/fabled
06:46 <Shiz> :p
06:47 <TemptorSent> Thank you!
06:47 <Shiz> i think that whitespace is still botched thanks to my terminal...
06:47 <Shiz> i'll just upload the git-format-patch
06:47 <TemptorSent> That would probably be ideal :)
06:48 <Shiz> https://up.shiz.me/priv/0001-print-print-warnings-and-errors-to-stderr.patch
06:48 <Shiz> there
06:49 <TemptorSent> That cleans it up nicely, and appears to allow use of an alternate FD with a little work, thanks.
06:52 <TemptorSent> Let's see if I can not botch the bug report :)
06:56 <TemptorSent> fabled, please see Issue #7107 - patch by Shiz.
06:56 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
06:57 <TemptorSent> Shiz: Anyway, regarding checking the return value of a variable assignement containing a command substitution, are you aware of anything non-posix about such a usage?
07:03 tmh1999 joined
07:05 <TemptorSent> Shiz: So, get this -- I CAN'T use the -q flag with 'apk search -x' because it gives me a different result, namely, just the package name and not the version!
07:07 <TemptorSent> Which, unfortunately, is going go break all sorts of other things if I try to run with a global quiet flag.
07:12 <TemptorSent> Perhaps a '--no-warn' option?
07:21 <xsteadfastx> does "install="$pkgname.pre-install"" gets executed even if i install a meta package?
07:23 <Shiz> xsteadfastx: i see no reason why not from the top of my head
07:24 <Shiz> meta-packages aren't actually anything special for apk
07:31 ncopa joined
07:31 ncopa joined
07:33 <xsteadfastx> ok... what can i do to test a open-rc init script?
07:34 <clandmeter> run it
07:35 <clandmeter> Shiz, did you guys get rust going?
07:35 <Shiz> clandmeter: the basics work, weeding out issues now
07:36 <xsteadfastx> clandmeter: it gives me "* WARNING: snapcast-server is already starting" and nothing happens"
07:36 <clandmeter> is it running?
07:36 <clandmeter> if not zap it
07:37 <xsteadfastx> its not doing anything
07:37 <xsteadfastx> i tried to start it in my devel docker container
07:37 <xsteadfastx> i installed openrc
07:37 <clandmeter> huh?
07:38 <clandmeter> are you running it on docker?
07:38 <Shiz> openrc doesn't run in docker
07:38 <ncopa> xsteadfastx: you normally dont run the init.d script in docker
07:39 <xsteadfastx> ok i try to run start-stop-daemon command itself... and it has a problem with "--exec"
07:40 <xsteadfastx> if i do a "start-stop-daemon -S snapserver" it runs
07:40 <xsteadfastx> "start-stop-daemon -S -x snapserver" not
07:40 <clandmeter> you do not have a regular alpine env?
07:41 <xsteadfastx> no
07:41 <xsteadfastx> :(
07:41 <Shiz> if the openrc script invokes start-stop-daemon, it's likely not a very good openrc script
07:41 <Shiz> just a side-note
07:41 <Shiz> xsteadfastx: --exec takes an absolute path
07:41 <clandmeter> yes, you dont need to use those in your initd
07:41 <Shiz> not a binary name
07:42 <clandmeter> openrc takes care of that.
07:42 <xsteadfastx> Shiz: not? what else to do?
07:42 <Shiz> man openrc-run
07:42 <Shiz> command=/usr/bin/mycommand
07:42 <Shiz> command_args=...
07:42 <Shiz> command_background=yes
07:42 <Shiz> pidfile=/run/$RC_SVCNAME.pid
07:43 <Shiz> that should be the full contents of your initd file (with the #!/sbin/openrc-run hashbang)
07:43 <Shiz> with command_args filled in to have it run in the foreground
07:43 tty` joined
07:43 <Shiz> openrc will take care of everything
07:43 <clandmeter> xsteadfastx, instead of docker you can also try lxc
07:43 <clandmeter> which would make a beter env to test things like that.
07:44 <xsteadfastx> mh ok...
07:44 <Shiz> looks like snapserver runs in the foreground by default, so command_args= can be empty or even better, command_args="$SNAPCAST_SERVER_OPTS"
07:44 <Shiz> so people can override/add options in /etc/conf.d
07:45 <xsteadfastx> right now i add a default config file
07:45 <Shiz> or filled with the other options you'd normally pass it (without -d) and then $SNAPCAST_SERVER_OPTS
07:46 <clandmeter> and if it logs to console you can redirect it to log file(s) with start-stop-daemon options
07:46 <xsteadfastx> there is so much... i think my head explodes ;-)
07:47 <clandmeter> its actually not that hard ones you have done it :)
07:47 <clandmeter> and the man pages has a good example(s)
07:48 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/main/opensmtpd/smtpd.initd
07:48 <Shiz> see this example :)
07:48 <Shiz> (totally not written by yours truly)
07:49 <clandmeter> and skip the mta line :)
07:49 <Shiz> well, rewrite depends() as is fit, of course
07:50 <xsteadfastx> start-stop-daemon tells me that --stdout and -stderr or only working when using --background
07:51 <clandmeter> command_background=yes
07:51 <clandmeter> that should add it automagically
07:51 <Shiz> see the lines i pasted above :P
07:51 <xsteadfastx> the opensmtp examples lookgs great
07:51 <xsteadfastx> but
07:51 <clandmeter> and read the man page :p
07:52 <xsteadfastx> snapserver doesnt have a config option or sometrhing
07:52 <clandmeter> dont scroll it, read it! ;-)
07:52 <xsteadfastx> stuff needs to be sourced from a file
07:52 <Shiz> xsteadfastx: right, and?
07:52 <xsteadfastx> that sets some environemtn variables snapserver reads
07:52 <Shiz> start_pre() {
07:52 <Shiz> . someconfigfile
07:52 <Shiz> }
07:53 <xsteadfastx> ok
07:53 <Shiz> again, man openrc-run is your friend
07:53 <Shiz> :)
07:53 <clandmeter> start-stop-daemon also support env variables.
07:54 skarnet left
07:55 <xsteadfastx> yeah sorry for my questions. i never really did some serious packaging. i know its pretty straight forward but sometimes i make things hard for myself
07:56 <clandmeter> its fine, we will start to shout or stay silent when we have enough of you.
07:59 <^7heo> guys
08:00 <^7heo> is the content of /usr/share/syslinux/mbr.bin the only payload that is written to disk to install mbr?
08:00 <Shiz> yes
08:00 <Shiz> at least
08:00 <Shiz> the mbr part
08:00 <Shiz> extlinux writes a vbr too
08:01 <TemptorSent> You'll also need to run syslinux against it I believe, or something which fixes up devnames
08:01 <^7heo> TemptorSent: I'm not interested in knowing how the /boot works, but what is the layout on disk.
08:02 <TemptorSent> Read install-bootable, it does a bit of twiddling with UUID, but I'm not sure if it's actually baked in.
08:02 <^7heo> you mean setup-bootable?
08:02 <TemptorSent> er, yeah -- getting tired :)
08:03 <^7heo> what I don't get is:
08:03 <TemptorSent> syslinux wants access to an unmounted device, which implies it's twiddling bits.
08:04 <^7heo> I have bytes in the middle of that mbr.bin
08:04 <^7heo> I mean, on disk, the mbr.bin is split in parts with seemingly unrelated bytes in the middle.
08:04 <TemptorSent> Hmm, lemme look at my with xdd
08:05 <TemptorSent> er xxd
08:05 <^7heo> what I'm comparing:
08:05 <^7heo> $ xxd /usr/share/syslinux/mbr.bin
08:05 <^7heo> and
08:05 <^7heo> $ sudo dd if=/dev/sda ibs=440 count=1 2>/dev/null |
08:05 <^7heo> xxd
08:06 <TemptorSent> Hmm, I think you're missing an offset...
08:07 <Shiz> no
08:07 <^7heo> no it's that.
08:07 <TemptorSent> Should be 446
08:07 <Shiz> no
08:07 <Shiz> it should be 440
08:07 <Shiz> ^7heo: they don't differ at all on my machine
08:07 <^7heo> they do here...
08:07 <Shiz> immunity:~# dd if=/dev/vda of=mbr.bin bs=440 count=1
08:07 <Shiz> 1+0 records in
08:07 <Shiz> 1+0 records out
08:07 <TemptorSent> Hmm, spec says 446
08:07 <Shiz> immunity:~# diff mbr.bin /usr/share/syslinux/mbr.bin
08:08 <Shiz> immunity:~#
08:08 <^7heo> damn
08:08 <Shiz> TemptorSent: no, spec says the partition table starts at offset 446
08:08 <Shiz> :P
08:08 <^7heo> Shiz: lemme paste my xxd output to show you what I got.
08:09 <^7heo> http://ix.io/qbp
08:09 <^7heo> my on-disk mbr
08:09 <TemptorSent> Okay, point Shiz - AVAILABLE space for code prior to partition table is 446 bytes, any of which that are unused should be 0.
08:09 <^7heo> my mbr.bin: http://ix.io/qbq
08:09 <^7heo> as you can see, they differ, greatly.
08:10 <TemptorSent> Whats your disk's UUID?
08:10 <Shiz> ^7heo: are you sure you don't have gptmbr.bin?
08:10 <^7heo> no I'm not.
08:10 <^7heo> but I shouldn't have that.
08:10 <TemptorSent> or mbr_c mbr_f ?
08:10 <^7heo> what are those btw?
08:11 <Shiz> ^7heo: that is not the syslinux mbr
08:11 <Shiz> i can tell you that
08:11 <Shiz> :p
08:11 <TemptorSent> No, not in any of those versions.
08:11 <TemptorSent> Alternate mbr it appears, see /usr/share/syslinux
08:12 <Shiz> it's not that
08:12 <Shiz> it looks like a windows mbr...
08:12 <TemptorSent> Wait a sec, any chance it eltorito from xorriso?
08:12 <TemptorSent> with the compat header?
08:12 <Shiz> these are windows mbr error messages, ^7heo
08:12 <Shiz> https://technet.microsoft.com/en-us/library/cc977213.aspx
08:12 <Shiz> see here
08:13 <Shiz> TemptorSent: it's not any MBR that belongs to syslinux
08:13 <^7heo> Shiz: ah
08:13 <^7heo> Shiz: well, to be fair...
08:13 <^7heo> Shiz: I have installed alpine first and windows second...
08:14 <Shiz> there you go
08:14 <^7heo> Shiz: so... it might be ;)
08:14 <Shiz> windows always overwrites the mbr
08:14 <Shiz> :P
08:14 <^7heo> Shiz: thanks for making sense of my stuff.
08:14 <^7heo> but if I overwrite the mbr with the syslinux one, won't I lose my partitions if I write after 440?
08:15 <Shiz> yes, so don't write after 440
08:15 <Shiz> the syslinux mbr.bin is only 440 bytes long in the first place
08:15 <^7heo> :D
08:15 <^7heo> yeah
08:15 <^7heo> nah but all makes sense now.
08:15 <^7heo> so fdisk would only write from 446 to 512?
08:16 <Shiz> on mbr systems at least, yes
08:16 <Shiz> and to 510
08:16 <Shiz> 511 512 is the boot signature
08:16 <Shiz> 0xAA55
08:16 <^7heo> ah
08:16 <^7heo> how come you know that so well?
08:17 <Shiz> i've written an OS before
08:17 <Shiz> lol
08:17 <^7heo> ah.
08:17 <^7heo> is the source anywhere?
08:17 <Shiz> only in my shameful local archives
08:17 <Shiz> (it's not very interesting and VERY old)
08:17 <TemptorSent> Yup, you start throwing a lot of 0xDEADBEEF around to figure out whats REALLY going on :)
08:18 <Shiz> ask me anything about A20 lines
08:18 <* Shiz> grumbles
08:18 <^7heo> A20?
08:18 <^7heo> Shiz: yeah I suspected it to be old; but I still am interested to know how far you went.
08:18 <^7heo> anyway
08:18 <^7heo> backing up the mbr
08:18 <Shiz> https://en.wikipedia.org/wiki/A20_line
08:18 <TemptorSent> Yeah, you were having page hell.
08:19 <Shiz> you need it to access more than 1MB of memory
08:19 <Shiz> it's an electircal connection on the KEYBOARD CONTROLLER
08:19 <TemptorSent> Thank you intel.
08:19 <Shiz> because IBM PC is hacks on top of hacks on top of hacks
08:20 <^7heo> v_v
08:20 <^7heo> ok so writing down the syslinux mbr now.
08:21 <^7heo> any precaution I should take?
08:21 <Shiz> just dd if=/usr/share/syslinux/mbr.bin of=/dev/sda bs=440 count=1 should work fine
08:21 <Shiz> i've done it tonnes of times
08:21 <^7heo> ok
08:21 <TemptorSent> Stretch after every dozen characters or so and make sure you write neatly :)
08:22 <^7heo> okay, rebooting.
08:22 <^7heo> banzaiiiii
08:22 <TemptorSent> Good luck!
08:22 <clandmeter> Shiz, cargo is not yet updated right?
08:22 <Shiz> not yet
08:23 <Shiz> i have an updated apkbuild locally but i ran into some rustc bugs
08:23 royger joined
08:24 <clandmeter> ah cargo is not written in rust?
08:24 <Shiz> it is
08:24 <Shiz> why do you think i ran into rustc bugs
08:24 <Shiz> :P
08:24 <^7heo> okay, I'm now booting via the syslinux mbr
08:24 <^7heo> it does the same, but prints hex stuff on the screen for an instant at boot
08:25 <Shiz> hehe
08:25 <Shiz> ^7heo: fwiw, syslinux's mbr code is very basic
08:25 <Shiz> (as it has to fit into 440 bytes)
08:25 <Shiz> it reads the partition table, finds the first partition with the bootable flag set
08:25 <^7heo> yeah but windows's mbr fits in the same size
08:25 <Shiz> and jumps to that partition's VBR
08:25 <Shiz> (volume boot record)
08:25 <Shiz> well, window's mbr does the same
08:25 <clandmeter> Shiz, right now i see, it needs itself.
08:25 <clandmeter> i didnt see rust as makdep
08:26 <Shiz> ah
08:26 <Shiz> should be added
08:26 <Shiz> actually, should also be a depends= in general for it
08:26 <^7heo> so I did well to activate my boot partition
08:26 <^7heo> right?
08:26 <^7heo> or it wouldn't have jumped to the right vbr...
08:26 <Shiz> clandmeter: rust is already in its normal depends
08:26 <Shiz> even in the current file
08:26 <Shiz> :P
08:26 <Shiz> ^7heo: yes, if your boot part wasn't marked as active/boot it wouldn't have worked
08:27 <^7heo> \o/
08:27 <clandmeter> heh, right
08:27 <algitbot> \o/
08:27 <^7heo> with windows it would have, I bet.
08:27 <clandmeter> looked over it...
08:27 <Shiz> ^7heo: unlikely, actually
08:27 <Shiz> anyway
08:27 <Shiz> the VBR is what extlinux --install (or update-extlinux) writes to
08:27 <Shiz> afaik it hardcodes the FS offset to extlinux.conf and syslinux.c32 in there
08:27 <xsteadfastx> ok finnally i created a PR on github for snapcast
08:27 <Shiz> sorry, ldlinux.c32
08:28 <Shiz> then it loads these in the VBR code and jumps to them
08:28 <^7heo> Shiz: I'll need you to review my installation documentation when it's done.
08:28 <Shiz> and ldlinux.c32 is... syslinux :)
08:28 <^7heo> so to get it right
08:28 <Shiz> err, ldlinux.sys
08:28 <^7heo> when I setup a disk
08:28 <^7heo> I do:
08:28 <^7heo> fdisk /dev/sdX
08:29 <^7heo> then I create the label, the partitions, etc.
08:29 <^7heo> I write that to disk, and then
08:29 <^7heo> dd if=/usr/share/syslinux/mbr.bin of=/dev/sda bs=440 count=1
08:29 <^7heo> That is enough for a bare simple disk.
08:29 <Shiz> you forgot extlinux --install /boot
08:29 <^7heo> Then I have to run syslinux/extlinux for installing the VBR
08:29 <Shiz> yep
08:29 <^7heo> but that's the PARTITION's business, not the disk ;)
08:30 <Shiz> right
08:30 <^7heo> (I know, it's kinda the same thing, but I'm talking offsets here)
08:30 <Shiz> syslinux's boot chain is essentially
08:30 <^7heo> (therefore it's not really)
08:30 <^7heo> yeah
08:30 <^7heo> totally gotcha
08:30 <Shiz> MBR -> VBR -> ldlinux.sys + extlinux.conf -> your kernel + initramfs
08:30 <^7heo> makes sense, and it's REALLY cool to actually find someone who knows this stuff.
08:30 <^7heo> I just wouldn't have expected it to be you :D
08:30 <^7heo> (no offense, it's just that I expect only old dudes to know that)
08:30 <Shiz> :p
08:30 <Shiz> i'm full of useless facts
08:31 <^7heo> it's far from useless actually.
08:31 fekepp joined
08:31 <Shiz> well, otherwise useless
08:31 <^7heo> "magic man in the sky following flock useless" isn't my exact definition of useless.
08:31 <Shiz> like the two main interface types in japanese visual novels
08:31 <Shiz> full of random facts
08:31 <Shiz> :p
08:31 <^7heo> yeah makes you INTERESTING|GOOD_RNG
08:32 <^7heo> anyway, that's actually really cool info you gave me.
08:32 <Shiz> :)
08:32 <Shiz> np
08:32 <^7heo> because: when I create my label, and my partitions, that goes into 446-510
08:32 <^7heo> the mbr goes in 0-440
08:33 <^7heo> and the whole boot record (which should be called mbr but whatever) is 0-512
08:33 <^7heo> what I do not get is:
08:33 <Shiz> actually
08:33 <^7heo> I have stuff past that point
08:33 <Shiz> the entire thing is called the mbr
08:33 <Shiz> typically 0-446 is called the boot code
08:33 <^7heo> yeah exactly.
08:34 <^7heo> but people (and mbr.bin too) calls that boot code the mbr
08:34 <^7heo> which is confusing.
08:34 <Shiz> what do you mean by stuff beyond that point?
08:34 <^7heo> why is it 446 and not 440?
08:34 <^7heo> (I'll wait for you to answer so we don't cross fire questions so much ;))
08:35 <Shiz> no special reason, i think syslinux's mbr.bin is just 440 bytes
08:35 <Shiz> they saved a whole 6 bytes
08:35 <^7heo> ok
08:35 <Shiz> :p
08:35 <^7heo> now about your question: well, if I run `dd if=/dev/sda ibs=440 count=1 skip=1 2>/dev/null | xxd`, it's not showing zeros... It's showing syslinux related stuff.
08:35 <Shiz> apparently some OSes like some form of signature at offset 440
08:36 <^7heo> sorry, I meant to use ibs=512
08:36 <Shiz> ^7heo: so my counter-question to that is
08:36 <Shiz> what do you think comes after the mbr
08:36 <^7heo> but same story still.
08:36 <Shiz> :P
08:36 <^7heo> well, I would expect that the mbr code uses the mbr label to jump to the right partition
08:36 <^7heo> and execute THAT vbr
08:36 <Shiz> right
08:36 fekepp joined
08:36 <^7heo> so after the mbr should be nothing, until the partition starts.
08:36 <Shiz> so
08:37 <Shiz> couldn't it be that the first partition starts after the first sector?
08:37 <Shiz> :P
08:37 <^7heo> (unless you have cryptsetup like I do, but that's another story, it's not LUKS code I can see it)
08:37 <^7heo> nah my partition is aligned much farther in the disk.
08:37 <^7heo> lemme find where.
08:38 <^7heo> the problem is
08:39 <^7heo> that disk has been used MANY times for wildly different stuff.
08:39 <^7heo> there's no way to know if I have dead bytes or not at a given offsent.
08:39 <^7heo> s/sent/set/
08:39 <^7heo> DAMN.
08:39 <^7heo> 8225280 bytes
08:39 <^7heo> that's the space BEFORE my first partition...
08:40 <^7heo> it's... big.
08:40 <Shiz> hehe
08:40 <Shiz> Device Boot Start End Blocks Id System
08:40 <Shiz> /dev/vda1 * 3 206 102400 83 Linux
08:40 <^7heo> start: 2048 (Units = sectors of 1 * 512 = 512 bytes)
08:41 <^7heo> 2048 * 512 = 1048576
08:41 <^7heo> yet if I use "cylinders" instead of sectors as units...
08:41 <^7heo> I get 8225280
08:41 <^7heo> wtf...
08:41 <^7heo> that's weird.
08:42 <^7heo> ooh, I get it.
08:42 <^7heo> windows decided to disregard the cylinder boundaries when creating the partitions
08:42 <^7heo> and aligned them with nothing in particular, or something I'm not aware of.
08:43 <^7heo> which also explains the: Partition 1 does not end on cylinder boundary
08:43 <^7heo> so fdisk -l reports 1 as in "1 cylinder" but it's not accurate, since it's rounding up.
08:44 <^7heo> windows...
08:44 <^7heo> anyway, I still have 1048576 bytes of free space before my first partition. So why the heck do I have stuff after the MBR?
08:44 <Shiz> olds tuff
08:44 <Shiz> probably
08:44 <^7heo> yeah but it mentions "SYSLINUX"
08:45 <xsteadfastx> mh i cant install the pulseaudio-dev package
08:45 <^7heo> why would you?
08:45 <^7heo> the point of pulseaudio is to uninstall it ;)
08:45 <Shiz> xsteadfastx: it's only in edge
08:46 <^7heo> Shiz: at offset 512 it starts with: eb58 9053 5953 4c49 4e55 58
08:46 <xsteadfastx> yes... it has some "Error relocating /usr/lib/libglib-2.0.so.0: pthread_setname_np: symbol not found".... oh noez
08:46 <^7heo> which is 0xEB 'X' 0x90 'SYSLINUX'
08:46 <Shiz> ah
08:46 <^7heo> which must be some kind of magic number.
08:46 <Shiz> that seems problematic
08:47 <^7heo> I would assume.
08:47 <xsteadfastx> ^7heo: its pretty good for getting sound of a docker container
08:47 <Shiz> 0x90 is nop
08:47 <^7heo> dude, WHY would you know that? :D
08:47 <* ^7heo> hides
08:47 <xsteadfastx> before i had that task i refused to use it
08:47 <Shiz> xsteadfastx: methinks alsa works better
08:47 <Shiz> :P
08:47 <Shiz> ^7heo: i do reverse engineering
08:47 <^7heo> +1
08:47 <xsteadfastx> yes it does.... but i never got this out of a container before
08:47 <Shiz> 0xEB is jump
08:47 <^7heo> Shiz: do you often program via xxd?
08:48 <xsteadfastx> i think i could link the soundcast device itself to the container
08:48 <Shiz> i've stared at enough assembly in my life to recognize an x86 jmp
08:48 <Shiz> :p
08:48 <^7heo> < Shiz> Why use gcc when you have xxd -p?
08:48 <^7heo> (xxd -p -r in that case, but still)
08:53 <xsteadfastx> works. alsa through a sounddevice in a docker container. much less hassle
08:53 <^7heo> yeah alsa FTW ™
08:54 <^7heo> pulseaudio is just meant as an incentive to pay admins.
08:54 <^7heo> "I have no sound"
08:54 <^7heo> "Ok I'll fix it for you" - $PKGMGR $DEL_OP pulse-audio
08:54 <^7heo> "Wow, it works, thanks! I'm glad that I can see how you're useful for once."
08:58 <xsteadfastx> it most of the time alot more than you need
08:58 <xsteadfastx> i can see that you can do streaming stuff with it and things... but most of the time you only want sound
08:59 <^7heo> Shiz: I think I know what's up
09:00 <^7heo> Shiz: the LUKS header might be in the partition...
09:01 <^7heo> Shiz: you are right, the .X.SYSLINUX is the VBR start.
09:01 <Shiz> ;)
09:01 <^7heo> I checked the start of my boot partition
09:01 <Shiz> for your information
09:01 <^7heo> I have *exactly* the same code.
09:02 <Shiz> 0xEB <val> jumps <val> bytes ahead
09:02 <Shiz> so it skips over the SYSLINUX indicator
09:02 <^7heo> yeah I know
09:02 <^7heo> I mean
09:02 <^7heo> I figued.
09:02 <^7heo> s/ue/ure/
09:03 <^7heo> so essentially
09:03 <^7heo> the LUKS header IS in the partition it points to.
09:03 <^7heo> at the start of it.
09:12 t0mmy joined
09:15 andypost joined
09:32 <xsteadfastx> py-gst1 still seems to be broken... so strange. cant import gi
09:35 <Shiz> xsteadfastx: apk add py-gobject3
09:37 <xsteadfastx> YES! that was it
09:38 <xsteadfastx> but should not be py-gobject3 a dependency for py-gst1?
09:39 <xsteadfastx> there is "depends_dev" for it.... but if you cant import the bindings its broken or?
09:41 <^7heo> Shiz: I have one question: since syslinux presents the user with a menu, it means that the mbr will anyway jump to *a* partition's VBR first, which will list all available boot options, right?
09:41 <^7heo> (because the menu is contained in a file, not in a binary form on the hard drive, afaik)
09:42 <^7heo> and so ONLY that partition needs to be active, the rest (even if they hold copies of the same partition that the options point to) don't need to be active, right?
09:42 <Shiz> yes
09:44 <Shiz> sec, in a meeting
09:44 <^7heo> ok
09:44 <^7heo> I'll write here, answer when you can ;)
09:46 <^7heo> so if I'm correct: MBR code -> active partition's VBR code -> syslinux's menu -> initramfs -> OS
09:46 <^7heo> am I missing something?
09:54 <^7heo> Damn
09:55 <^7heo> pickfire: wasn't it you doing zfs over cryptsetup with a pool?
09:55 <^7heo> 'cause I currently have a chicken-egg problem with zfs + cryptsetup.
10:00 <xsteadfastx> clandmeter: should i set myself as maintainer in the snapcast pkg?
10:01 <clandmeter> yes please.
10:02 <^7heo> yeah the post I found on serverfault is actually documenting LUKS on top of ZRAID
10:02 <^7heo> not the opposite, since it can't deal with multiple drives.
10:02 <^7heo> it == cryptsetup
10:02 <xsteadfastx> ok. and i also have a question about py-gst1... it needs py-gobject3 to get it working. else python cant import it. its set in depends_dev... but i think its something for "depends"
10:03 <clandmeter> xsteadfastx, yes it still needs love
10:04 <xsteadfastx> should i just add it?
10:05 <clandmeter> you can, but i think it also needs python2 support.
10:05 <clandmeter> for both
10:05 <xsteadfastx> py-gobject3 is python2
10:06 <clandmeter> then we need to add py3 :)
10:06 <clandmeter> however you can also just fix the things you need now.
10:07 <clandmeter> we can add that later.
10:09 <xsteadfastx> ok
10:37 <^7heo> how does alpine linux boot over a Z-Raid?
10:37 <^7heo> Klowner: have you attempted that?
10:37 <^7heo> did anyone attempt that?
10:38 vakartel joined
10:39 <jirutka> Shiz: reminder https://github.com/alpinelinux/aports/pull/1206 :)
10:42 czart__ joined
10:55 tmh1999 joined
11:04 <jirutka> Shiz: cc on Alpine implicitly compiles with -pie, so even when I disable pie in rustc, it still produces static PIE
11:04 <jirutka> Shiz: when I invoked cc command manually and added -no-pie, then it produced statically linked no-PIE binary that works (i.e. no segfault on panic)
11:08 <jirutka> Shiz: is this really a bug in Rust? what if libunwind just don’t work with static PIE in general, does that make sense?
11:15 blueness joined
11:17 <jirutka> Shiz: maybe relevant https://github.com/rust-lang/rust/issues/22885
11:21 <jirutka> Shiz: or instead of manually invoking cc, `rustc -Clink-arg=-no-pie main.rs` (-Z print-link-args prints cc command)
11:35 <Shiz> i'm not entirely convinced libunwind fails with static pie
11:35 blueness joined
11:36 <Shiz> and that bug is afaik outdated
11:36 <Shiz> if it was pax it would fail to launch in the first place
11:36 <Shiz> jirutka: how did llvm-libunwind turn out?
11:38 <jirutka> Shiz: no difference for static PIE
11:46 <Shiz> jirutka: tried compiling with debug? :P
11:48 <jirutka> emm, not yet :P
11:49 <jirutka> i found out that it really does not fix the problem, so put back original libunwind
11:50 <Shiz> it might provide more useful debug info
11:50 <Shiz> maybe
11:50 <jirutka> Shiz: llvm-libunwind is in testing, so you can try it
12:00 blueness joined
12:03 leitao joined
12:15 rdutra joined
12:26 vakartel joined
12:30 farosas joined
12:41 tmh1999 joined
12:56 terra joined
12:59 <terra> Guys, according to feedback, my new aport request needs some changes. Should I prepare new patch from scratch or only changes over previous request?
13:06 <_ikke_> terra: A complete new patch usually
13:08 <_ikke_> terra: usually you call that patch vX where X is the iteration number (v2 for example)
13:10 <terra> _ikke_: got it. thanks.
13:15 <leitao> Is Alpine still on Soft freeze?
13:18 <^7heo> I don't think it has been soft-frozen yet.
13:20 <leitao> nmm, I receive an email saying "We are imposing a soft freeze in edge for now, as part of preparation for the 3.6 release."
13:21 <leitao> The email title is 'Soft freeze imposed for 3.6 release prep"
13:24 <^7heo> yeah but I'm not sure if it was followed on.
13:25 vakartel joined
13:28 tmh1999 joined
13:47 ncopa joined
13:47 ncopa joined
13:49 leo-unglaub joined
13:59 tmh1999 joined
14:00 <ncopa> tmh1999: hi
14:00 <ncopa> looks like disk went full on build-edge-s390x
14:00 <ncopa> something appeared to go wrong with community/monitoring-plugins
14:00 <ncopa> it hadd 100G build log
14:00 <ncopa> i just purged it
14:01 <^7heo> wow 100G of log.
14:05 fekepp joined
14:09 terra joined
14:22 <kaniini> ncopa: x86 builder is missing
14:22 <ncopa> ok
14:24 <ncopa> its back now
14:34 tmh1999 joined
15:07 <jirutka> Shiz: r u here?
15:12 zoidbergwill joined
15:12 <pickfire> ?
15:12 <pickfire> Someone bumped me?
15:13 <_ikke_> pickfire: ^7heo highlighted you
15:13 <Shiz> jirutka: sorta
15:14 <jirutka> Shiz: any progress with rust?
15:14 <pickfire> _ikke_: What did he said?
15:14 <Shiz> i've been at work today
15:14 <Shiz> :P
15:14 <pickfire> I wonder if I can do reverse search on irssi.
15:14 <Shiz> i found the root cause for a static pie issue though
15:14 <pickfire> Shiz: Ah, nice. Didn't know you are working on the static rust thing.
15:15 <jirutka> Shiz: I’ve disabled PIE for static, build cargo and… what the hell… it builds broken binary, the same problem as you’ve said, dynamically linked without link to libc
15:15 <jirutka> Shiz: really? where? :)
15:16 <_ikke_> pickfire: ^7heo │ pickfire: wasn't it you doing zfs over cryptsetup with a pool?
15:16 <^7heo> thanks a bunch irclogger_com
15:16 <pickfire> Ah
15:16 <pickfire> No
15:16 <^7heo> _ikke_:
15:17 <pickfire> ^7heo: I use brtrs raid 1 with one disk on luks.
15:17 <pickfire> raid 0*
15:18 <^7heo> ah yeah
15:18 <^7heo> ok so please disregard my question
15:34 <tmh1999> ncopa : there are packages hosted at distfiles.alpinelinux.org that is 404. can you bring up the host online ?
15:35 <tmh1999> ncopa : I actually have built up to half of community. I am checking what's wrong with monitoring-plugins
15:36 terra joined
15:38 <kaniini> also the website is not regenerating when new git events happen
15:49 <tmh1999> rnalrd : Hi, looks like you applied old version of my patch instead of v2 : http://patchwork.alpinelinux.org/patch/3286/, http://patchwork.alpinelinux.org/patch/3291/ . Can you change it ?
15:57 <tmh1999> the v2 patch status is accepted in patchwork but it is not merge in aports tree
16:05 <ncopa> ok, i'll have a look at distfile
16:05 <ncopa> i thought it was working...
16:07 <tmh1999> thanks !
16:26 vakartel joined
16:34 <ncopa> distfiles.alpinelinux.org should work again
16:35 <ncopa> there used to be a limit on filesize
16:35 <ncopa> i wonder if it is still the case
16:40 tmh1999 joined
17:20 <Shiz> jirutka: hello, back
17:33 <TemptorSent> fabled - are you on by chance?
17:45 fabled joined
17:51 MH0815 joined
18:07 ic3cdr joined
18:19 <TemptorSent> fabled: Would you please take a look at Issue #7107 and Shiz's attached patch and drop a point release of apk addressing at least that issue? Thanks!
18:19 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
18:21 <fabled> TemptorSent, looks about right
18:22 <TemptorSent> Hi fabled - that, combined with the fact that 'apk search -x -q $pkg' returns differnt results thant 'apk search -x $pkg' breaks cross-platform building for me.
18:24 <TemptorSent> I have in my repositories file my local repo, which I need for staging packages I've built on x86_64, but the fact that repo entry exists, but has no aarch64 (or whatever) packages, throws a warning when trying to run 'apk search -x $pkg' to obtain the full package version, which 'apk search -x -q $pkg' omits.
18:25 <TemptorSent> Also, if you have time, please take a look at 7100-7104
18:26 blueness joined
18:31 <Klowner> ^7heo: zfs raid? I've got that working
18:32 <Klowner> just make your pool all raid'y and go nuts
18:33 <TemptorSent> Klowner: I think ^7heo was asking about boot from raidz.
18:33 <Klowner> ohhh, booting, no
18:34 <TemptorSent> If your using a detached header, why not just use that to boot off as well?
18:35 <TemptorSent> Leaves nothing but encrypted disks behind with no information about them to aid someone who gets physical access to a powered off machine (You DO have tripwires to that kill power on physical intrusion, RIGHT?)
18:38 terra joined
19:00 boingolov joined
19:00 <boingolov> looks like jenkins is broken
19:08 minimalism joined
19:09 <TemptorSent> I'm really beginning to curse at Redmine on a regular basis. I commented on Issue #6591 and somehow lost at /p on the sed script, would someone in the APK project please fix the original comment and delete my reply to my reply?
19:09 <algitbot> Bug #6591: APK is executing scripts inside /var/cache, and it prevents normal operation - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/6591
19:11 <TemptorSent> Thanks...
19:14 blueness joined
19:35 <jirutka> Shiz: <Shiz> i found the root cause for a static pie issue though … I’m curious :)
19:55 <jirutka> leitao: hi
19:56 t0mmy joined
19:56 <jirutka> leitao: I’ve tried to build neovim and it correctly uses system-provided LuaJIT on my system
20:07 tmh1999 joined
20:29 <^7heo> Klowner: do you have zfs root?
20:29 <^7heo> Klowner: and if yes, are you using that over LUKS?
20:31 <Klowner> I have zfs root but not doing anythign with LUKS
20:31 <Klowner> just zfs on linux
20:31 <^7heo> Ok
20:31 <^7heo> I'm attempting ZFS over LUKS
20:32 <^7heo> and possibly Z-RAID ZFS over LUKS with detached header.
20:32 <^7heo> it's... challenging ;)
20:37 <Klowner> that sounds like a project :D
20:50 <leitao> jirutka, hm, here it download it from the web
20:52 <jirutka> leitao: does it pull luajit pkg?
20:55 <^7heo> Klowner: I'm currently exchanging via ML with the guys who wrote LUKS/Cryptsetup/dm-crypt with the hope that it will be easy to use one detached header for many disks.
20:55 <^7heo> Klowner: in that case, this would be awesome news.
21:00 <^7heo> Klowner: also, I am writing a documentation on how to do that.
21:01 <^7heo> omg.
21:01 <^7heo> apk dot generates SUCH a mess of a graph...
21:01 <^7heo> http://webgraphviz.com/
21:01 <^7heo> source: http://ix.io/qeU
21:02 <^7heo> that is the offspring of Baal, the devourer of the souls.
21:23 <kaniini> its meant to be visualized yes :p
21:24 <^7heo> ?
21:24 <kaniini> apk dot graphs
21:25 <kaniini> you can do the same with pkgconf, too. pkgconf --digraph <.pc files here>
21:25 <^7heo> yeah but still, it's useless
21:25 <^7heo> there's WAY too much clutter to visualize anything with it.
21:25 <kaniini> tbh, largely it's meant to be used for visualizing the exact solution the dep solver came up with
21:26 <kaniini> it might be nice to declutter the graph for other uses though :)
21:26 <^7heo> yeah totally.
21:26 <^7heo> esp since most usages won't need the exact versions of all the things.
21:27 <^7heo> in my case, for instance, I could have almost used the http://pkgs.alpinelinux.org/package/v3.5/main/aarch64/* pages
21:27 <^7heo> starting with the pages I want to install
21:27 <^7heo> and (manually) recursively list all of them.
21:27 <^7heo> ofc using that with a dot file is much nicer since it does the recursion for you.
21:27 <^7heo> but yeah in the end it's kinda faster to process the output of apk directly than to read the graph, 'cause it's HUGE.
21:35 <Shiz> jirutka: so
21:35 <Shiz> .g. libssh2-sys specifies a static=ssh2 attribute
21:35 <Shiz> rust seems to strip the static= from that
21:35 <Shiz> in the resulting metadata
21:46 <^7heo> If anyone ever wants to generate the list of packages to copy on the install media for a given package to be available via the install media, the command is:
21:46 <^7heo> apk dot $packagename | sed '1,3d; $d; s/^ //; s/->.*$//; s/"//g; s/-[0-9r.-]\+//' | sort -u | while read package; do ls $install_disk_mountpoint | grep -q "$package" || echo "Package $package"; done
21:51 <^7heo> wait no that will miss the dependencies that don't have any.
21:51 <^7heo> which CAN happen.
21:53 <TemptorSent> ^7heo: I'm working on solving that problem permentently :)
21:54 <TemptorSent> Currently, I'm finishing up the kernel and module staging tool, which manifests everything it installs with checksums, so you can get a complete dep tree of not just packages, but individual files.
21:55 <^7heo> myeah
21:57 <Shiz> so tired
21:59 <^7heo> yeah.
21:59 <^7heo> totally.
21:59 <TemptorSent> ^7heo: Hopefully, I'll be ready to push that shortly, still getting it working right.
22:00 <^7heo> well, my sed expression works very well.
22:00 <^7heo> I corrected it and now it works REALLY well.
22:03 <TemptorSent> You're just looking for packages needed?
22:04 <^7heo> yeah.
22:04 <^7heo> $ install_media_extra_deps /media/sdc1/apks/x86_64 zfs
22:04 <^7heo> keyutils-libs
22:04 <^7heo> krb5-conf
22:04 <^7heo> ...
22:07 <jirutka> krb5-conf? for what do you need krb?
22:07 <jirutka> Shiz: no wonder, since you don’t sleep :)
22:11 <Shiz> i took a nap from when i got home until just now, actually
22:11 <Shiz> :P
22:13 <^7heo> jirutka: zfs
22:14 <jirutka> ^7heo: why the heck ZFS needs Kerberos?!
22:14 <TemptorSent> It handles encryption and authentication with it for nfs
22:17 <Shiz> eww
22:17 <jirutka> yet another reason why I’m not fan of ZFS…
22:17 <^7heo> I dunno, I am trying it currently.
22:17 <^7heo> it seems "cool"
22:18 <^7heo> but I'll tell you more when I see how it performs.
22:19 <Shiz> jirutka: i might be able to cook up a patch for the library issue
22:19 <Shiz> meanwhile, whats the overall status?
22:24 <^7heo> jirutka: the thing with zfs is that it is supposed to work in RAID intelligently and recover from errors and perform encryption, checksum, etc.
22:25 <^7heo> (encryption coming soon, not yet avail)
22:25 <^7heo> and by "checksum" I meant "recovery based on redundancy and silent corruption detection"
22:25 <^7heo> and so forth
22:26 <^7heo> the problem you'd have with it has more to do with the zero-admin I think.
22:26 <^7heo> which is why the kerberos deps are pulled, instead of a per-setup dep.
22:27 <TemptorSent> ^7heo: zfs supports exporting to nfsv4 and CIFS, both of which use kerberos based authentication.
22:28 <^7heo> TemptorSent: if it wasn't automatically managed, the dependency would be pulled by the person installing it instead of "just in case"
22:28 <TemptorSent> ^7heo: You could probably do without those deps unless you're using those exports.
22:28 <^7heo> I guess, but the graph listed them so...
22:28 <TemptorSent> ^7heo: Try a lddtree on each binary and see what actually uses it.
22:28 <^7heo> nah no time for that.
22:29 <^7heo> first I do the thing, THEN I'll iterate ;)
22:29 <TemptorSent> It looks like nvpair is the one that needs it
22:31 <Shiz> jirutka: it seems their own musl build uses llvm libunwind btw
23:06 rdutra joined
23:14 <jirutka> Shiz: great! overall status is that it’s kinda fucked up :/
23:15 <Shiz> do we have a list of issues?
23:15 <Shiz> 1) panic! broken
23:15 <Shiz> 2) it tries to link in dynlibs to a static-PIE lib
23:15 <jirutka> Shiz: I know that it uses llvm’s libunwind, that’s why I’ve tried it
23:15 <Shiz> anything else?
23:15 blueness joined
23:15 <jirutka> Shiz: panic is broken on static PIE, works on classic on-PIE static; I have a patch to make non-PIE static working
23:16 <jirutka> Shiz: but rustc and cargo tests fails on both and don’t know why yet
23:16 <jirutka> and it fails quite strangely…
23:16 terra joined
23:16 <Shiz> i'm discussing it with the #musl people
23:16 <Shiz> or at least, trying
23:16 <Shiz> :D
23:17 minimalism joined
23:17 <jirutka> Shiz: cargo tests failing when compiled with dynamic https://hastebin.com/nevulocejo
23:18 <Shiz> yeah this is an interesting one
23:18 <jirutka> Shiz: note: relocation R_X86_64_PC32 against protected symbol `_ULx86_64_local_addr_space' can not be used when making a shared object
23:18 <Shiz> luckily it's just one error
23:18 <jirutka> yes
23:19 <Shiz> i ran into this before
23:19 <Shiz> 2017-03-08 23:30:27 <dalias> the .o file containing that reloc was miscompiled
23:19 <Shiz> 2017-03-08 23:30:32 <dalias> so Ltrace.o I think
23:19 <Shiz> 2017-03-08 23:30:43 <dalias> TPOFF32 is not a valid TLS reloc type in shared libraries
23:20 <jirutka> when I’ve tried to build it as non-PIE static, it failed even compile… don’t remember details now… I have to retry it; I was in hurry and forgot to log it
23:20 <Shiz> jirutka: i think my patch may actually solve this properly
23:20 <jirutka> :)
23:20 <Shiz> jirutka: so the issue is
23:21 <jirutka> can you please share?
23:21 <Shiz> i haventm ade it yet
23:21 <Shiz> :P
23:21 <Shiz> rustc passes a final -Wl,-Bdynamic to the linker commandl ine
23:21 <Shiz> i think it 'just' needs to omit this for crt-static
23:21 <Shiz> that's all
23:22 <jirutka> I still don’t understand why it happens only on musl host; rustc supports musl for years, to build statically linked executables on non-musl systems
23:22 <jirutka> it even does not pass -static, only -Bstatic
23:23 <jirutka> I mean does not pass -static before your patch
23:23 <^7heo> /usr/bin/xxd is owned by vim-8.0.0027-r0
23:23 <^7heo> Weird.
23:23 <Shiz> jirutka: yes but
23:24 <Shiz> jirutka: it's not static PIE
23:24 <jirutka> aha, I remembered; when I’ve tried to build cargo as static non-PIE, it produced dynamic binary with no link to libc
23:24 <Shiz> which probably confuses it
23:24 <jirutka> Shiz: this is the patch to fix non-PIE static http://tpaste.us/eD6B
23:25 <jirutka> Shiz: it’s based on your patch, I added --no-pie, b/c cc on Alpine builds --pie by default
23:25 <Shiz> :(
23:26 <Shiz> don't do that :P
23:26 <jirutka> why?
23:26 <jirutka> non-pie static is better than broken pie static; since you’re working on fixing pie static, I’ve tried non-pie
23:32 <kaniini> we want static PIE though :p
23:32 <kaniini> question.
23:32 <kaniini> how does llvm version bumps effect rust?
23:32 <kaniini> or does rust link against llvm statically
23:33 <jirutka> kaniini: rust needs llvm 3.7, 3.8 or 3.9
23:33 <jirutka> kaniini: does not work with 4.0 yet
23:33 <kaniini> sure. that's not my question though
23:33 <kaniini> rust links against llvm 3.8 dynamically. what happens when we upgrade to 3.9?
23:33 <jirutka> kaniini: to be honest, I don’t care for now if it’s PIE or not, I want to FINALLY have working rustc into v3.6
23:33 <jirutka> kaniini: then rustc must be recompiled ofc
23:34 <kaniini> but rustc requires rust?
23:34 <jirutka> kaniini: rustc can be linked against llvm even statically if needed
23:34 <jirutka> kaniini: yes, currently we use binaries from VoidLinux for bootstrapping
23:34 <kaniini> yes, i think we should link rustc statically
23:34 <jirutka> kaniini: why?
23:34 <kaniini> so that we do not have to rebootstrap it every time
23:35 <jirutka> it’s not needed to rebootstrap every time
23:35 <jirutka> just rebuild rust package, that’s all
23:35 <jirutka> single package
23:35 <kaniini> but the rust package requires the old llvm
23:35 <jirutka> yes
23:35 <jirutka> and?
23:35 <jirutka> we need to keep 3.8 or 3.9 anyway
23:36 <kaniini> so it will fail to run, when the new llvm is installed
23:36 <jirutka> and also 3.7, for ghc
23:36 <kaniini> unless we unconditionally build our rust against VoidLinux's toolchain which seems all sorts of terrible idea
23:36 <jirutka> no, when we upgrade llvm to 4.0, then we will also create llvm3.8 (or llvm3.7) and build rustc against it
23:36 <jirutka> the same as llvm3.7 that we already have
23:37 <jirutka> and VoidLinux’s rust links llvm statically
23:37 <kaniini> so then we have 3 llvm packages installed on our machine for ghc, rust and dotnet-core
23:37 <Shiz> jirutka: okay, i have something
23:37 <kaniini> so much for minimalism
23:37 <Shiz> a patch that is
23:38 <jirutka> so you prefer to “hide” it or what?
23:38 <jirutka> yes, LLVM is PITA, we all know that
23:38 <Shiz> https://txt.shiz.me/OTk4YzliND
23:38 <Shiz> completely untested
23:38 <jirutka> and there’s unfortunately nothing we can do about that :(
23:38 <Shiz> gonna try it now
23:38 <Shiz> jirutka: you didn't push the no-static-pie patch to aports yet, right?
23:38 <jirutka> Shiz: no, I did not
23:39 <Shiz> :)
23:39 <jirutka> kaniini: eventually we will bootstrap rustc using prebuilt binary from upstream, maybe in ten years they will FINALLY dammit provide it; or we cross-compile it from fucking glibc binary in same way as ghc :/
23:40 <kaniini> jirutka: i mean, i guess. it just seems like a mess
23:40 <jirutka> omg, I’m really fan of Rust, but since I’ve started trying to compile it on Alpine, I have really VERY mixed feeling about it…
23:40 <jirutka> kaniini: and what do you propose instead?
23:40 <Shiz> i was a fan of Rust until I started using it
23:40 <Shiz> it has mellowed a bit since
23:40 <Shiz> it's a nice community though
23:40 <kaniini> also, depending on VoidLinux to bootstrap is not a situation i think we should be in
23:41 <jirutka> kaniini: ofc, this is just temporary
23:41 <jirutka> kaniini: anyone is welcome to write script for bootstrapping from glibc binary :) now we have bigger issues, like that our rustc is completely broken
23:41 <kaniini> jirutka: i don't have a solution for the "different projects depend on different llvm versions" problem, but i think that clear bootstrapping methods should be required as a deliverable for each language that requires bootstrap
23:41 <Shiz> kaniini: once we have our own binraies out we can simpy use those to bootstrap
23:42 <Shiz> voidlinux is mostly until we have a stable build of our own with the bugs weeded out
23:42 <kaniini> Shiz: but if they depend on llvm (there is no llvm3.8 package right now), then we cannot, as llvm will be upgraded
23:42 <jirutka> kaniini: I know, but once again, we have bigger issues now…
23:43 <kaniini> i think we should move llvm to llvm3.8
23:43 <kaniini> to ensure that we solve this before it becomes a future problem
23:43 <kaniini> so, basically
23:43 <jirutka> kaniini: I’ve cross-compiled rustc ~9 months ago when I’ve created first version of our rust pkg and it was not very pleasure experience, so I’m not eager to it now, but I’ll eventually do it
23:44 <kaniini> llvm packages MUST be versioned
23:44 <kaniini> something like how we handle Gtk
23:44 <jirutka> there’s on the todo list
23:44 <kaniini> okay
23:44 <kaniini> but the problem is
23:44 <jirutka> but I’d like to first try to update llvm to 3.9 and create llvm3.9 instead of 3.8
23:44 <kaniini> okay
23:45 <kaniini> if you want to do that, that's fine. i will work on that front
23:45 <kaniini> then we can rebuild rust against llvm3.9
23:45 <kaniini> and then remove llvm from the distro
23:45 <kaniini> yes, that works for me
23:45 <jirutka> I wouldn’t say that I want to do that :)
23:45 <kaniini> i mean, if that is the approach you want to take, using llvm 3.9 with rust
23:46 <jirutka> it’d be better, but not necessary
23:46 <kaniini> may as well do it
23:46 <jirutka> depends on how difficult it will be to port our patches
23:46 <kaniini> we just need to keep the transitional llvm package for now
23:46 <kaniini> until we get that done
23:47 <jirutka> transational?
23:47 <kaniini> yes, the current llvm (not versioned) packages
23:47 <jirutka> Shiz: looking at your patch… it seems that rust build system is really broken
23:47 <jirutka> Shiz: b/c this change is like very obvious
23:47 <kaniini> because removing it will break the dependencies of everything dependent on llvm right now
23:48 <jirutka> yes
23:48 <kaniini> so we need to shift those to llvm3.9 deps
23:48 <kaniini> but since rust needs rust to build, we need to keep main/llvm in the distro for now
23:48 <kaniini> crystal is the other one to figure out, but that will wait for 3.7
23:49 <jirutka> kaniini: no, we don’t
23:49 <Shiz> jirutka: currently building against it
23:49 <jirutka> kaniini: once again, rust from VoidLinux we use for bootstrapping is statically linked against LLVM, so we don’t need LLVM to use it
23:49 <kaniini> jirutka: we do if we wnat to remove the main/llvm
23:50 <kaniini> jirutka: okay
23:50 <jirutka> kaniini: or maybe I don’t understand the issue, that’s quite possible, I’m a bit drunk now
23:50 <Shiz> i presume we do want to still support the case of the user doing # apk add llvm
23:50 <Shiz> and have it install the 'newest' llvm by default
23:50 <kaniini> Shiz: that's easy. we use provides= for that :)
23:50 <Shiz> yes
23:50 <Shiz> just making a note
23:50 <jirutka> Shiz: agree, llvm can be a metapackage depending on the newest llvm or something liek that
23:50 <Shiz> :)
23:50 <jirutka> kaniini: yeah, or that, better :)
23:51 <kaniini> Shiz: it will pick the newest provider for it
23:51 <jirutka> I’m quite pissed of from this situation with Rust :(
23:51 <jirutka> when I pushed recent changes to repo I thought that it’s finally complete and then found out that it’s more like completely broken
23:52 <Shiz> jirutka: i'm talking to rust devs about it and they seem very agreeable at least
23:52 <kaniini> jirutka: for bootstrapping, yes voidlinux binaries are used. what this is about more is trying to ensure rust lands with the right dependencies off the bat
23:52 <jirutka> Shiz: agreeable that their build system is broken as hell?
23:52 <Shiz> at least agreeable on that the behavior we want is the correct behavior
23:52 <Shiz> from rust
23:52 <Shiz> :P
23:52 <kaniini> all of these LLVM languages are annoying
23:53 <jirutka> yeah, we want static binary to be really static and not somehow mixed and dynamic binary be really dynamic, linked against libc, that’s obviously correct behaviour :))
23:53 <jirutka> not languages, just LLVM itself
23:53 <kaniini> ghc, rust, crystal (which exists only in third-party repo), and probably 10 others people want that i dont yet know about :)
23:53 <kaniini> they are annoying for depending on LLVM :)
23:53 <jirutka> yeah
23:53 <kaniini> annoyance by association
23:53 <jirutka> unfortunately there’s currently nothing better with same performance :(
23:54 <jirutka> but the same, when I see LLVM somewhere, I’m sad
23:54 <jirutka> Julia also uses LLVM
23:55 <jirutka> IIRC this was my first fight with LLVM insanity
23:55 <Shiz> surprisingly, in my time with rust llvm has not been the source of errors
23:55 <Shiz> :P
23:56 <jirutka> heh, yes :)
23:56 <Shiz> also to come back to your question jirutka
23:56 <kaniini> yes, julia is the other one i was thinking about.
23:56 <Shiz> i think the reason a lot of stuff worked before is that they simply bypassed a lot of toolchain stuff
23:56 <Shiz> which was reason for a ton of breakage here but they didn't notice because they didn't use it
23:57 <Shiz> now that we removed the silly toolchain bypasses (linking crt*.o manually, really?!)
23:57 <Shiz> those things come to surface
23:57 <kaniini> crystal is the one that is still missing, but i am working with the upstream maintainer who packages it to come up with a plan to get it into actual alpine
23:58 <kaniini> and dotnet-core, but that is more of a conversation that i am planning to have, as i do not want to do much of the lifting on that one personally considering microsoft is hungry to support alpine
23:59 <jirutka> btw what are preferred boolean values in CMake? ON/OFF, TRUE/FALSE, YES/NO…?