<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:21 <kaniini> Shiz: it seems ok
00:21 <kaniini> Shiz: which branch is this for
00:21 <Shiz> 3.3-stable
00:21 <kaniini> ok
00:21 <kaniini> i'll sort it in a few
00:22 <Shiz> i at least confirmed that the new grsec patch compiles on x86_64
00:22 <Shiz> :p
00:22 <Shiz> no box to test on though
00:29 <nmatt> Shiz I got a test vm setup
00:30 <nmatt> Shiz: is it for 4.9.25?
00:33 <Shiz> nmatt: nyet, older backport for 3.3
00:33 <Shiz> 4.1.39
00:34 <Shiz> err, forward-port rather from 4.1.18
00:34 <Shiz> alpine 3.3, kernel 4.1.18 -> 4.1.39 that is
00:36 <nmatt> oh
00:36 <nmatt> nvm :(
00:37 <Shiz> :P
00:37 <Shiz> i also have a 4.9.25 forward-port
00:37 <Shiz> somewhere
00:39 <nmatt> i don't think the 4.9.25 port would be that hard
00:40 <Shiz> https://up.shiz.me/priv/grsec-3.1-4.9.25-201704252333-alpine.patch
00:40 <Shiz> no guarantees etc, just a quick forward-port
00:41 LouisA joined
01:02 s33se_ joined
02:42 <nmatt> Shiz: cool I'm going to add a patch section to our wiki. Do you might me linking to that patch?
02:42 <nmatt> I will list it as a test patch (i.e. not stable)
02:42 <nmatt> s/might/mind/
02:47 <Shiz> feel free
02:47 <Shiz> also label it unofficial and quick
02:47 <Shiz> :P
02:56 Mr_H joined
02:57 <kaniini> yoyoyo
02:57 <kaniini> why are you giving away the patch for free
02:57 <kaniini> we could be making $$$ CASH MONEY $$$ on this Shiz
02:58 <Shiz> lol
02:58 <kaniini> nmatt: i start the bidding at $300 for the patch, what is your counteroffer
02:59 <nmatt> $300 to rebase the 4.9.24 patch to 4.9.25 ??
02:59 <nmatt> lol
03:00 <kaniini> nmatt: hardened-3.1-4.11-201705012200-alpine.patch starts at $799
03:00 <nmatt> $500/month for support right ;)
03:00 <kaniini> let me talk with Jake in sales we might be able to cut you a deal
03:01 <kaniini> nmatt: oh sorry Jake in sales says $369 per machine with 0 incidental support tickets
03:03 <kaniini> for what it's worth, the 4.9.25 patch seems to be booting fine
03:04 <TemptorSent> kaniini - is it one of those 'sliding scale' deals?
03:04 <kaniini> absolutely
03:05 <kaniini> there is the gentoo surcharge: $50 per CFLAG being used in the commandline
03:06 <nmatt> dang that's gonna make the ricers mad
03:09 <kaniini> when is gentoo going to stop pretending that freedesktop.org pkg-config is still a relevant software? even fedora gave up on that one
03:11 <kaniini> hell, even GNOME gave up on that one
03:11 <Shiz> fedora moved to pkgconf?
03:11 <Shiz> nice
03:11 <kaniini> yes
03:11 <kaniini> RETROACTIVELY
03:11 <Shiz> for fedora to drop something FDo it must be pretty heavy stuff
03:11 <kaniini> that is how bad pkg-config broke them
03:13 <kaniini> Shiz: https://admin.fedoraproject.org/pkgdb/package/rpms/pkgconf/
03:14 <kaniini> Shiz: they went all the way back to fedora 24 for it
03:14 <Shiz> nice
03:15 <kaniini> Shiz: they also closed like a shitload of bugs in their distro when they switched because pkg-config was quietly screwing them in subtle ways before
03:15 <kaniini> but hey, i wrote this stuff for no reason right
03:16 <Shiz> i took a look at pkg-config exactly once
03:16 <kaniini> oh wait, pkg-config kept resolving dependencies wrong breaking things in alpine and then they went to glib-2.0 requirement
03:16 <kaniini> ;)
03:16 <Shiz> and then i saw it needed a bootstrap glib
03:16 <Shiz> and then i closed the window
03:16 <kaniini> oh
03:16 <kaniini> pkg-config
03:16 <kaniini> gets a lot of things wrong with it's depsolver
03:16 <Shiz> nice
03:16 <kaniini> well, the new one isnt so bad, but it's kind of too little too late
03:26 <TemptorSent> kaniini: Since you're our resident dep-solver expert, would you mind looking at my apkroottool implementation and letting me know what logic errors I haven't addressed?
03:28 <TemptorSent> kaniini: At some point, it needs to become C based, because running large tree searches through repeted process invocation is somewhat insane.
03:32 <kaniini> TemptorSent: shell scripting is really not something you want me getting involved in :P
03:33 <kaniini> i just cobble things together there
03:34 <TemptorSent> kaniini: Yeah, not the script (which I still dislike because of the hacks for apk lacks :/ ), but the dependency logic itself
03:35 <kaniini> ok let me be more direct
03:35 <TemptorSent> kaniini : see https://github.com/TemptorSent/aports/blob/mkimage-refactor-scripts/scripts/mkimage/utils/utils-apk.sh
03:35 <kaniini> non-trivial parts of the current generation of mkinitfs were my doing
03:35 <* kaniini> scurries
03:36 <TemptorSent> *lol* Don't worry, I've made my share of shell messes :)
03:36 <TemptorSent> Besides, the heavy lifting is really a few lines of awk
03:37 <TemptorSent> cd L317-L349 for the actual resolution
03:37 <TemptorSent> er s/cd/see/g
03:38 <TemptorSent> It's not the prettiest code I've ever written, but it seems to work?
03:38 <kaniini> i'm going to be blunt
03:38 <kaniini> i dont know a damn thing about awk
03:39 <kaniini> walk me through what this does
03:39 <TemptorSent> Think of it as psuedo code, I think the only awkish function is 'split'
03:40 <kaniini> i mean it's a recursive-descent depsolver right?
03:40 <kaniini> it looks ok to me
03:40 <kaniini> i dont see anything blatently wrong with it
03:42 <TemptorSent> _manifest_deps_resolve_index takes the input from the first pass to create the index, then at the end of input iterates each list of raw deps from whatever dep gernerator (objdump, etc), an resolves them to index entries - which are a combination of a tag, filename, and checksum.
03:43 <TemptorSent> So you go from indexa\tdep1\t\dep2\t...\tdepn to indexa\tdep1index\tdep2index\t...\tdepnindex
03:43 <kaniini> the only concern i have is
03:44 <kaniini> there's no depth counting
03:44 <TemptorSent> Then _manifest_deps_resolve_recurse just does a direct array iteration.
03:44 <kaniini> so you can loop it
03:44 <TemptorSent> Nope, see i!=j
03:44 <kaniini> in alldeps()
03:44 <kaniini> for (t in td) { sd[td[t]]=td[t] ; if (td[t] !=d) { alldeps(ad, td[t], sd) } }
03:45 <TemptorSent> So it only runs per input line, an the array is already stuffed.
03:45 <TemptorSent> It'd have to be a rather strange case to allow it to loop.
03:47 <TemptorSent> So, on the input , ideps gets filled with an index value and the contents of the entire dep line, with each entry being a checksummed index token
03:48 <TemptorSent> (oops, I can dump the extra split -- artifact from refactor)
03:49 <TemptorSent> It then iterates over each dependor token (i in ideps returns keys in ideps)
03:50 <TemptorSent> split("",all) clears the array all in a portable way.
03:50 <TemptorSent> then it iterates by key over the array, putting results into all
03:52 <TemptorSent> it prints the first token, then each result in all as long as it's not empty or our top level index key.
03:56 <TemptorSent> alldeps is stupidly simple, it splits the value of the dep into the variable td, then iterates t over the keys in td, setting the output array value to the value of each dep token using the key as the dep key, then it checks that the value isn't equal to the calling index, and recurses if not.
03:57 <TemptorSent> Ug, I think that is less clear than the code :)
03:58 <TemptorSent> To stick in a loop, we'd have to have an actual dep loop I believe.
04:00 <TemptorSent> A TTL loop detector might be worth while if that situation is actually possible.
04:01 <kaniini> one should never assume it is impossible
04:01 <kaniini> :)
04:02 <TemptorSent> Agreed, I need to do a bit more analysis (or a test case) to determine if it actually can loop in than manner.
04:03 <TemptorSent> Its not wonderfully fast or anything, but it is pretty simple and flexible.
04:09 <TemptorSent> Hmm, actually a simpler fix may be just changing the order of the guard condition for alldeps to come before the adding of td[t] to sd[], and to simply check if (td[t] in sd)
04:09 <TemptorSent> That should eliminate loops right?
04:10 <TemptorSent> Since it returns true as soon as the entry already exists, and we can exit.
04:11 <TemptorSent> er, continue
04:12 <TemptorSent> The other thing, is just give it a try and see if it looks sane in use
04:15 <TemptorSent> from the mkimage dir, ./apkroottool --arch aarch64 setup /tmp/myaarch64
04:15 <TemptorSent> Add repos/keys as desired :)
04:16 <TemptorSent> (same global option format as apk)
04:16 <TemptorSent> ./apkroottool.sh help
04:16 <TemptorSent> (er, yes, with the sh)
04:18 <TemptorSent> './apkroottool.sh setup /tmp/myaarch64 aarch64' does the same
04:23 <TemptorSent> At some point, I really need to write a proper merkle-dag tree based solver for this kind of stuff
06:04 czart__ joined
06:19 rnalrd joined
06:21 <TemptorSent> kaniini: Would it be insane to implement something like a Merkle DAG directly in the PAX/tar headers?
06:24 <TemptorSent> Actually, several overlaid DAGS... Path,Index,Depends,Provides
06:26 <TemptorSent> (DAGs just being a simple solution, we can choose something more appropriate for the actual structure if needed, such as a red/black tree backing it.
06:28 <TemptorSent> Should be able to go from O(2^n) to O(nlogn) worst case.
06:30 <TemptorSent> Right now, I suspect some of the functions are more like O(n!)
06:33 <TemptorSent> ...such as naive recursive dep solvers on reverse sorted lists :)
06:36 <skarnet> what has pax/tar got to do with dependency solving
06:36 <TemptorSent> A convenient place to store the information perhaps :)
06:36 <skarnet> what about an additional file that you then include in the tarball
06:37 <TemptorSent> Since we're already using PAX headers for SHA1 checksums, including the tags in the header would be convenient
06:37 <skarnet> instead of abusing headers for an unrelated format
06:37 <skarnet> checksums make sense
06:37 <TemptorSent> I'm doing that currently :)
06:37 <skarnet> it's about verifying that the tarball isn't corrupted
06:38 <skarnet> an unrelated data structure isn't the same thing at all
06:38 <TemptorSent> The deps are hashlists of the checksums of the files in the deplist
06:38 <skarnet> well, keep doing it in a separate file :P
06:39 <TemptorSent> The point of the Merkle tree in the headers would be both verificiation and unique identification of both individual files and complete paths.
06:40 <TemptorSent> So you could refer to fstab or /etc/fstab by two distinct hashes, but could determine if the file content hash matches.
06:40 <TemptorSent> (this is essentially what I'm doing for libs currently, although really screwy rpaths might break things)
06:42 <TemptorSent> The dep tree then reduces to a tagged set of checksums for each file.
06:43 <TemptorSent> Also, if we can use apk to effectively read/write headers to/from text format, it would allow us to have self-consistent archives/manifests without secondary generation.
06:44 <skarnet> don't mix dependencies and checksums, and don't abuse tar headers. Please.
06:44 <TemptorSent> Um, how do you divorce the deps from their checksums?
06:44 <skarnet> Every time you think you're smart, tech debt increases, and somewhere a kitten cries.
06:45 <kaniini> skarnet for technical committee 2017
06:45 <skarnet> kaniini: where do I sign
06:45 <TemptorSent> Using the filename means you can't tell if the file is the same one in differnt locations or not.
06:46 <skarnet> a file listing full paths?
06:46 <skarnet> I'm not sure exactly what dependencies you're talking about: what depends on what and what should be documented?
06:46 <TemptorSent> A manifest with full paths, then an index of all libs/bins, and a dep list for each index entry.
06:48 <kaniini> i do not think shell is the appropriate language for that type of processing :P
06:48 <TemptorSent> So I can tell it I want the binaries /sbin/apk and /usr/sbin/zfs and it will extract a subset with the deps for those binaries and all libs.
06:48 <skarnet> you need the full paths in the dep list, end of story.
06:48 <TemptorSent> kaniini: Exactly, this really should be in apk.
06:48 <TemptorSent> skarnet: Why not the hash?
06:49 <skarnet> why store clear, readable file names when we can store their hashes instead? it's so much more fun!
06:49 <TemptorSent> It maps 1:1 a specific pkg/file/content to a tagged hash
06:50 <TemptorSent> The tags contain the filename/path as appropriate, as well as the package name and arch.
06:50 <skarnet> because when you construct the dep tree, you need to go from the hash to the name
06:50 <TemptorSent> So it essentially serves as a UUID
06:50 <skarnet> and that is not a O(1) operation
06:51 <TemptorSent> grep :)
06:51 <skarnet> and that is not a O(1) operation
06:51 <TemptorSent> No, but it actually solves the problem of uniquely identifying a full dep chain
06:52 <TemptorSent> So if any dep changes, you can recognize that fact.
06:52 <TemptorSent> even if the version number of the lib didn't change, the hash did.
06:52 <skarnet> I'm not sure exactly what you're trying to accomplish, it's early morning on a holiday and I already regret entering this discussion. Goodbye.
06:53 <TemptorSent> Sorry, I didn't realize it was a holiday!
06:53 <skarnet> np, my fault for jumping in.
06:53 <TemptorSent> Enjoy you day off, I'll try to put together a better sketch of the logic.
06:55 <TemptorSent> kaniini: I'm hoping this can be part of apk3 functionality, so we can eliminate a lot of redundant and fragile code that has to parse data that apk already uses.
06:56 <TemptorSent> kaniini: Allowing it to act as a general tool would just ice the cake.
06:57 <TemptorSent> kaniini: In fact, it would make the binary-deltas that the old alpine-iso tool tried to support almost trivial.
09:05 fekepp joined
11:01 dsuch joined
11:20 LouisA joined
11:23 goberle joined
11:32 goberle joined
12:01 blueness joined
13:11 <fabled> i think i figured out the Go 1.8 build error
13:16 <clandmeter> doing some maintenance to infra, should be back in a min.
13:20 <dsuch> Hello, I'm looking for a contractor to build an APK package for certain software to be placed in that software's repository (i.e. not Alpine Linux's repository).
13:21 <dsuch> Additionally, a few packages needed by the software appear to be unavailable yet in Alpine Linux as compared to Ubuntu, RHEL and other distributions, and, depending on the task's complexity, I would like for the contractor to create the packages for Alpine as well.
13:21 <dsuch> Thus, I think it would be best to work with a core Alpine developer so as to facilitate the process of making sure the new packages are added where they are due.
13:21 <dsuch> Could you please suggest the best place to look for such a person? Thanks.
13:21 <skarnet> here is a nice place, the alpine-dev ML is another one
13:22 <skarnet> (I'm not a core developer, but am contractable, please send me a PM if interested ;))
13:23 <skarnet> also, please bear in mind that if a piece of software appears in Ubuntu/RHEL/... and not in Alpine, it's probably because it requires heavy patching in order to build with musl
13:24 <skarnet> so depending on the precise nature of the software, the necessary amount of work may vary. It can be very simple if there's no particular glibcism in the software, or it can be basically insurmountable if the software is deeply tied to glibc.
13:26 <rnalrd> clandmeter, maintenance for patchwork/pkgs/bugs?
13:26 <rnalrd> i can't reach them
13:26 <dsuch> Thanks skarnet, yes, I realize that there may be various reasons behind it. The missing packages are dependencies to NumPy and SciPy, such as liblapack-dev or liblapack3 in terms of Ubuntu names. They are certainly C or assembly heavy.
13:26 <clandmeter> yes
13:26 <rnalrd> k
13:26 <clandmeter> almost done
13:26 <rnalrd> np
13:28 <skarnet> dsuch: asm would certainly not be a problem. As for C, it really depends on the amount of glibcisms used, but if it's purely for calculus there's no reason why it should be hard.
13:28 <dsuch> skarnet: Sure, I understand it.
13:31 <clandmeter> rnalrd: should be ok now
13:32 <rnalrd> yes, tnx
13:32 <clandmeter> i only multiplied that minute by 15. not bad.
13:32 <rnalrd> :)
14:25 <TemptorSent> kaniini - see zhasha's comment on #alpine-linux 'That was fun. apk upgrade deleted my kernel'
14:26 tmh1999 joined
14:43 mmlb joined
14:51 <^7heo> guys, how to get drivers loaded at boot?
14:51 <^7heo> Given the right file in /lib/modules/$kernel/kernel/drivers?
14:51 <TemptorSent> ^7heo - the 'modules' kernel command line is what you're looking for I think.
14:51 <^7heo> I mean, at boot.
14:51 <^7heo> how is it configured?
14:51 <TemptorSent> Bootloader
14:52 <_ikke_> /etc/modules-load.d/?
14:52 <TemptorSent> It's currently broken.
14:52 <^7heo> thanks _ikke_
14:52 <^7heo> _ikke_: I have only four files in there...
14:52 <_ikke_> Either that, or /etd/modprobe.d
14:52 <TemptorSent> _ikke_ I don't believe that is available at boot.
14:52 <^7heo> s/files/lines/
14:52 <^7heo> _ikke_: thanks
14:53 <TemptorSent> ^7heo - what modules do you need loaded?
14:54 <^7heo> I need the overall logic.
14:54 <^7heo> to understand.
14:55 mvertes joined
14:55 <TemptorSent> ^7heo - Okay, so the way it works is /init modprobes $KOPT_modules and $KOPT_rootfstype early in the process.
14:55 <^7heo> TemptorSent: where are those files located?
14:56 cyteen joined
14:56 <TemptorSent> ^7heo: See /usr/share/mkinitfs/initramfs-init L345
14:57 <TemptorSent> ^7heo: It then reads /etc/modules (NOT any of the subdirs currently!?!) and loads those.
14:58 <TemptorSent> ^7heo: All files are in the initfs.
14:59 <clandmeter> ^7heo, dont forget to add it to a runlevel.
14:59 <TemptorSent> Runlevel? At boot time?
14:59 <clandmeter> /etc/init.d/modules
15:00 <TemptorSent> There is not /etc/init.d/modules at boot time, that's on the root we're trying to mount.
15:00 <^7heo> clandmeter: that is awesome
15:00 <^7heo> clandmeter: that is EXACTLY what I wanted.
15:01 <^7heo> clandmeter: what is the corresponding file with which the SYSTEM loads its modules?
15:01 <TemptorSent> ^7heo: Oh, you mean how to load modules from openrc once boot is done and the switch-root has happened?
15:02 <clandmeter> TemptorSent, take your head out of initramfs ;-)
15:02 <clandmeter> real things happen outside of it :p
15:02 <TemptorSent> clandmeter: He said load modules at BOOT, which implies initfs
15:02 <clandmeter> ^7heo, what do you mean with SYSTEM?
15:03 <clandmeter> systemd?
15:03 <* clandmeter> hides
15:03 <* TemptorSent> flogs clandmeter within an inch of his life.
15:03 <TemptorSent> *LOL* That's not even funny clandmeter!
15:05 <TemptorSent> ^7heo: Can you clarify whether you're talking modules required to mount the real root or just modules that need to be loaded when the openrc init system starts?
15:06 <clandmeter> crap, can a lxc container get network stats from proc? or is that somehow limited?
15:09 Klowner joined
15:09 <dsuch> clandmeter: If this is helpful,
15:09 <dsuch> clandmeter: I know that grsecurity blocks access to /proc/net/tcp but I can access it from lxc
15:10 <clandmeter> im using vnstat
15:10 <clandmeter> but it seems that the vnstat users is not a member of readproc..
15:11 <clandmeter> i wonder if that actually matters
15:12 <dsuch> clandmeter: Well, if this is related at all, I once had a situation as here https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2015-April/001059.html https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2015-April/001065.html
15:13 <dsuch> clandmeter: But this really is my limits in this regards, sorry!
15:15 <kaniini> TemptorSent: seems to be working as expected, he pinned a package that no longer exists in edge
15:18 <clandmeter> dsuch, seems to start working now.
15:19 <clandmeter> i guess it was a matter of adding the user to readproc
15:24 BitL0G1c joined
15:28 <clandmeter> kaniini, the current warning for check() is being masked if package() produces lots of data.
15:44 <TemptorSent> kaniini: Ahh, okay -- I didn't see the detail, just the no kernel on upgrade :)
16:01 <kaniini> TemptorSent: the @edge part :)
16:06 <^7heo> TemptorSent: I just wanted to get how the system was loading the modules at boot.
16:34 Long_yanG joined
16:40 chris|_ joined
16:40 letoram_ joined
16:42 <TemptorSent> ^7heo: Ahh, the sequence is kernel-builtins; modules= kernel command line & rootfs type in initramfs-init; /etc/modules in initramfs; then mount real root & switch root, then start openrc, with /etc/init.d/modules (and possibly others) loading the modules in the /etc/modules-load.d and friends or loading specific modules explicitly.
16:42 xmux joined
16:43 geekblogtv joined
16:43 <pickfire> Can't locate mktexlsr.pl in @INC (@INC contains: /usr/share/tlpkg /usr/share/texmf-dist/scripts/texlive /usr/local/lib/perl5/site_perl /usr/local/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at /usr/bin/mktexfmt line 23.
16:43 <pickfire> Weird, latex looks broken.
16:43 squaremo joined
16:44 <TemptorSent> ^7heo - I'll update the wiki to clarify what I think I know, then you can sanity check it?
16:45 <^7heo> TemptorSent: maybe
16:52 MH0815 joined
16:56 asie joined
18:06 TemptorSent joined
18:07 <TemptorSent> Grr! Is >12hrs network uptime asking too much? Per 24hr period?
18:08 xfix joined
18:08 <_ikke_> heh
18:08 <_ikke_> I cannot imagine having such a bad connection (I'm spoiled)
18:09 <_ikke_> I feel for you
18:09 <TemptorSent> ^7heo: Anyway, now that my edit actually saved, take a look at https://wiki.alpinelinux.org/wiki/Architecture
18:10 <TemptorSent> _ikke_ - It's not just the network, it the landline too -- and no cell signal without going elsewhere to make a calll.
18:11 <TemptorSent> There's a special place in hell for Occam Networks... oh, wait -- they're already there :P
18:11 <skarnet> TemptorSent: my ISP-supplied router resets its DHCP connection every 12 hours (even though the lease is 24 hours). *And* shuts down every TCP connection, *even when* the lease is renewed with the same IP.
18:12 <skarnet> fortunately, I had the hardware and ability to build my own router with a DHCP client, and set the PoS to bridge mode, where it works
18:12 <TemptorSent> skarnet: I could live with that by comparison! I loose everything, inclding dialtone, multiple times per day, sometimes for most of the day.
18:12 <skarnet> but imagine the average consumer who can't do that
18:13 <skarnet> well that's what you get for living in BFE
18:13 <_ikke_> BFE?
18:13 <TemptorSent> Yeah, it's sitting on a fiber loop FFS! The power is the issue, not the fiber.
18:13 <skarnet> Bumfuq, Egypt
18:14 <_ikke_> right
18:14 <TemptorSent> It's crappy hardware with crappy diagnostics.
18:14 <TemptorSent> And even crappier digital troubleshooting tools for analog problems!
18:15 <TemptorSent> You can't diagnose a power problem with a DMM to save your life in the real world -- yon need a 'scope.
18:16 <TemptorSent> At the very least, and ANALOG VMM
18:17 <TemptorSent> Anyway, I have a network for a few minutes, so please take a look at the wiki page I stubbed and note fixes.
18:18 <_ikke_> is rpi a kernel flavor?
18:19 <TemptorSent> Yes, it is AFAIK _ikke_.
18:19 blueness joined
18:20 <_ikke_> "Includes Raspberry Pi kernel"
18:20 <skarnet> yes it is
18:20 <_ikke_> ok
18:20 <skarnet> armv7 is... complicated
18:20 <skarnet> (also Pi1 is armv6)
18:20 <skarnet> (which is also complicated)
18:21 <TemptorSent> arm is... complicated ;)
18:21 <TemptorSent> Actually, embedded is complicated in general.
18:21 <skarnet> yeah. Say what you want about the PC architecture, standardization of the hw boot procedure was a good thing.
18:21 <TemptorSent> The STANDARD sucks, but the fact of it is good.
18:22 <jirutka> I’ve finally finished that php7 crap; there’s quite long list of failing tests: https://github.com/jirutka/alpine-aports/blob/6cd26abe1585d2d40011f3dc4dd25825b8d05c55/community/php7/disabled-tests.list
18:23 <skarnet> jirutka: where's the python2/python3 situation at? is it solved?
18:23 <jirutka> skarnet: what do you mean?
18:24 <skarnet> before TemptorSent came around, what spammed the channel for days was endless discussions on how to provide both Python 2 and Python 3 packages
18:24 <TemptorSent> *lol*
18:24 <skarnet> I have to assume there was a point to them
18:24 <TemptorSent> Sorry for disrupting the great python debate.
18:24 <jirutka> skarnet: we already have many py2/py3 packages…
18:25 <skarnet> so it's solved then?
18:25 <jirutka> skarnet: depends…
18:25 <skarnet> that's the kind of answer I don't like
18:25 <TemptorSent> I think depends are what aren't solved ;)
18:25 <jirutka> skarnet: there are multiple cases, some are solved quite well, some are hacked, some are not solved
18:25 <TemptorSent> I ran into problems with py3 deps in several places.
18:25 <jirutka> skarnet: I don’t have time to read backlog now, so please copy my relevant comments
18:26 <jirutka> me
18:26 <skarnet> oh, it's not related to anything in the backlog
18:26 <skarnet> I was just curious, mostly
18:27 <jirutka> https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python
18:27 <TemptorSent> pgsql is fix now, correct?
18:27 <jirutka> not yet, I’m gonna do it now
18:27 <skarnet> jirutka: thanks.
18:27 <TemptorSent> Thank you. I'll poke at the postgis stuff after the base pgsql stuff is done then.
18:28 soldF5Nsd1eF joined
18:29 YoursTruly joined
18:43 kaniini1 joined
18:44 <kaniini1> fabled: errors were split from other log messages
18:44 <kaniini1> so TemptorSent and i were talking about kernel packaging
18:44 <kaniini1> i think we should really generate APKs like linux-grsec-4.9.22 instead of linux-grsec
18:44 <kaniini1> because right now there is no way to rollback the upgrade
18:44 <kaniini1> pretty much
18:44 <kaniini1> yes based on everyone's advice
18:44 <kaniini1> which turned out to be wrong
18:44 <kaniini1> that never happens though
18:44 <kaniini1> never
18:44 <kaniini1> yes, fflush() should fix it
18:44 <kaniini1> ncopa: sooooo
18:44 <kaniini1> ncopa: what do we do now
18:44 <* kaniini1> is working on s/grsec/hardened/
18:44 <kaniini1> as an aside, clang has Control Flow Integrity plugin now
18:44 <kaniini1> it may be interesting to switch system compiler to clang
18:44 <kaniini1> $ sudo apk upgrade --update --available
18:44 <kaniini1> (1/2) Installing linux-hardened (4.9.24-r1)
18:44 <kaniini1> boom
18:44 <kaniini1> .
18:44 <kaniini1> rnalrd: i think the solver computes half the solution (purge linux-grsec itself), and then the other half on the second apk upgrade run
18:44 <kaniini1> likely yes
18:44 <kaniini1> exactly
18:44 <kaniini1> yes
18:44 <kaniini1> that is fine
18:45 <kaniini1> as long as linux-hardened is in /etc/apk/world
18:45 <kaniini1> it's not run
18:45 <kaniini1> it went from 0 to 1
18:45 <kaniini1> it should be fine as it is
18:45 <kaniini1> well
18:45 <kaniini1> we might want to bump it to -r2
18:45 <kaniini1> just to be pedantic
18:45 <kaniini1> but
18:45 <kaniini1> just never reboot
18:45 <kaniini1> yoyoyoyo
18:45 <scadu> lawl
18:46 <scadu> kaniini1: what happened? :f
19:04 mvertes joined
19:33 leitao joined
19:35 dsuch left
19:49 LouisA joined
20:05 BitL0G1c joined
20:35 cyteen joined
20:35 consus joined
20:49 xfix joined
20:53 xfix joined
21:17 <Shiz> do i have someone on ignore or
21:17 <Shiz> is kaniini talking to himself
21:17 <^7heo> he is talking to himself.
21:23 tmh1999 joined
21:29 <leitao> :-)
21:31 <kaniini> oh
21:31 <kaniini> i see
21:31 <kaniini> the matrix people finally fixed their irc bridge
21:31 <kaniini> go figure
21:31 <kaniini> i was recieving messages, but could not actually get on the network, it was quite weird
21:33 TemptorSent joined
21:34 <kaniini> oh man
21:35 <kaniini> humm
21:35 <kaniini> bad user info
21:35 <mitchty> this matrix thing sounds a slosh buggy :)
21:35 <mitchty> skosh stupid autocorrect
21:35 <kaniini> no, this seems to be a freenode bug
21:36 <kaniini> or more specifically, a freenode oper abuse issue
21:40 <skarnet> everything looks like a freenode op abuse issue to you :P
21:43 <kaniini> this specifically was
21:43 <kaniini> when a client exits with 'bad user info', it means the client was x:lined
21:43 <kaniini> but the reason for doing so in this case was legitimate
21:43 <kaniini> somebody created an account and was spamming through the homeserver
21:54 <Shiz> so it wasn't abuse
21:56 <kaniini> it's abuse in that they did not bother to reach out
21:58 minimalism joined
22:05 skarnet joined
22:06 <jirutka> is there anyone who have tried lld (LLVM linker) pkg?
22:07 <jirutka> btw what is the state of flatpak in Alpine? is it already working?
22:08 <jirutka> it seems to be quite popular, when VoidLinux announced flatpak support, they got a lot of attention
22:15 <mitchty> jirutka: not yet, i'm going to try it soon though, its about a 3x decrease in link speed over gold from what i've been seeing from other people
22:27 leitao joined
22:45 breno_ joined
22:48 cyteen joined
22:52 TemptorSent joined
23:08 <jirutka> I’m accepting bets how many php test will fail on other arches than x86_64 :P
23:08 <^7heo> 42
23:09 <jirutka> there’s some idiot that keeps flagging nginx b/c he apparently don’t understand what “stable version” means… >_<
23:11 <^7heo> yeah we need to implement an "already flagged" feature.
23:11 <^7heo> and reminders for the maintainers.
23:12 <jirutka> that would not help here
23:12 <jirutka> nginx is up-to-date
23:12 <^7heo> yeah but the flag has already been set
23:12 <jirutka> and users can’t flag already flagged pkg, only Anitya integration can do that :P
23:12 <jirutka> yeah, I’ve removed it…
23:12 <jirutka> directly from DB, cause we don’t have UI for that
23:12 <^7heo> ah
23:13 <jirutka> I’ve even added "stable version" to the pkg description, but it apparently didn’t help…
23:13 <skarnet> "anitya integration"
23:14 <skarnet> doesn't bode well for build reproducibility :P
23:14 <jirutka> ??
23:17 <skarnet> "anitya" = "inconstance, ephemerality"
23:18 <^7heo> huhu
23:19 <jirutka> heh
23:19 <jirutka> didn’t know that
23:39 <^7heo> I'll leave that here: https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide%20-%20Rev%201.1.pdf
23:41 <^7heo> and https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
23:44 <skarnet> yeah, this is going to make some noise
23:47 <^7heo> most definitely.
23:57 <jirutka> ncopa: clandmeter: PHP mess is finally fixed! :) https://github.com/alpinelinux/aports/pull/1339; however, there are hundreds failing tests… https://github.com/alpinelinux/aports/blob/master/community/php7/disabled-tests.list