<     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 _2_7  
28 29 30 31
00:03 dobson joined
00:16 BitL0G1c joined
01:03 minimalism joined
01:13 <Shiz> jirutka: found a fix for the broken abi tests
01:21 <Shiz> jirutka: do you have a log of the test failures?
01:41 s33se_ joined
02:47 gromero joined
03:05 <TemptorSent> For purposes of consistency throughout the alpine tools (at least scripts), I'd like to propose the definition of a set of error handling functions/formats in a common location.
03:08 <TemptorSent> The scope would include printing info/error messages to the terminal, providing for logging, and providing handler hooks to cleanly fail/die/exit
03:12 <TemptorSent> The ideal case would be to provide the same set of functions using the same formats for tools in all languages, thus making a much more cohesive product.
03:16 <TemptorSent> Thus, calling 'a_error "I failed"' from a shell script would display the same as 'a_error("I failed");' in a C program.
03:19 <Shiz> definitely not, since naming conventions differ per language
03:25 <TemptorSent> Adjusting for naming conventions as needed..
03:26 <TemptorSent> The point is to have consistent look & feel across tools, not exact naming.
03:27 <TemptorSent> Figuring out how to enable/disable colors based on the environment variable is about the only part that may require fiddling.
03:28 t0mmy joined
03:28 <TemptorSent> Is it "USE_COLORS=1" in all existing cases?
03:32 <TemptorSent> Should it be "USE_COLORS={always,never,auto}" to be consistent with ls?
03:38 <TemptorSent> Okay, higher level question - forget implementation details - What format do we want to use to print/log info/message/warning/error messages from ALL alpine tools so they have consistent appearance?
03:40 <TemptorSent> And how do we want to handle failure cases in a consistent manner? What gets printed on failure at various verbosity levels to which sink?
03:41 <TemptorSent> Ideally, we leave ourselves the option of doing I18N in some sane manner, but that's it's own set of issues.
03:45 <TemptorSent> Although I'm not sure of how to cleanly handle i18n in POSIX shell...
03:50 minimalism joined
04:23 Emperor_Earth joined
04:46 D630 joined
05:21 czart__ joined
05:39 fabled joined
05:55 t0mmy joined
05:58 mmlb joined
06:32 dynaMIX joined
06:37 ppisati joined
08:08 royger joined
08:32 fekepp joined
08:59 <_ikke_> wow, cargo release builds takes ages
08:59 <clandmeter> :)
09:00 <_ikke_> it's compiling for 4 hours now
09:00 <clandmeter> wut?
09:01 <xsteadfastx> i got a flag for libtermkey to update the version... i did that but in the message that person tells me to provide a static library version in libtermkey-dev package... i have no idea what that person means ;-)
09:01 <_ikke_> its a small scaleway vps, but still
09:01 <clandmeter> yeah that takes some time
09:01 <_ikke_> debug build took about 13 minutes
09:01 <clandmeter> but 4 hours could mean something is wrong
09:02 <clandmeter> are you building something with cargo, or cargo itself?
09:08 t0mmy joined
09:14 <_ikke_> withcargo
09:14 <_ikke_> habitat
09:16 vakartel joined
09:22 vakartel joined
09:56 <ncopa> openjdk8 is causing some pain
09:56 <ncopa> apparently they use different tarball of hotspot on aarch32 (armhf)
09:57 <clandmeter> ah, that explains the checksum errors
09:57 <ncopa> hum
09:57 <ncopa> i once in a while get error from tpaste.us
09:58 <clandmeter> ok let me restart it.
09:58 <clandmeter> ithink i know the fix
09:58 <ncopa> http://tpaste.us/vM1o
09:58 <clandmeter> just dsidnt have time yet
09:58 <clandmeter> yes thats the same error
09:59 <ncopa> this change fixes the checksum error on armhf: http://sprunge.us/UCBb
10:00 <ncopa> however, the icedtea-hotspot-* patch fails :-(
10:03 <clandmeter> sucks
10:30 <ncopa> ok, im not really sure how to solve this
10:31 <ncopa> can openjdk crosscompile?
10:32 <_ikke_> the habitat test suite can also take some time..
10:32 <ncopa> habitat?
10:32 <_ikke_> project from chef
10:35 <ncopa> neither am i
10:36 <ncopa> whoops wrong win
10:36 gromero joined
10:53 <ncopa> what a nightmare
10:53 <ncopa> this openjdk business
10:53 <_ikke_> hmm
10:53 D630 joined
11:00 cyteen joined
11:19 D630 joined
11:34 <jirutka> yes, openjdk is really PITA
11:45 rdutra joined
11:47 rdutra joined
11:47 <^7heo> Any more info on the Passing the baton thing?
11:48 AlexIncogito joined
11:48 <^7heo> i.e. do we actually want to do something?
11:49 <^7heo> should we federate people?
11:51 farosas joined
11:53 Tsutsukakushi joined
11:53 <Tsutsukakushi> hi
11:55 <Tsutsukakushi> what are alpine's plans now that grsec is private
11:56 <AlexIncogito> Have you read the ongoing disccusion here ? http://lists.alpinelinux.org/alpine-devel/5626.html
12:02 <Tsutsukakushi> there doesn't seem to be any concrete plans in it
12:02 <Tsutsukakushi> like the latest person seems to thing that grsec just stopped developing or something
12:02 <Tsutsukakushi> maintaining grsec patches in their current form will be hard work
12:03 <Tsutsukakushi> are there plans to join forces with the gentoo hardened-kernel project or something like that
12:04 <Tsutsukakushi> https://github.com/thestinger/linux-hardened
12:05 <AlexIncogito> From what I have read on different ML and forums, there are different initiatives, and ways that require further exploration and examination about going with keeping grsec
12:06 <AlexIncogito> There is this thread, which opens a (very) remote chance of seeing grsec integrated upstream, if google or other is willing to actually hire grsec http://openwall.com/lists/kernel-hardening/2017/05/11/2
12:06 <AlexIncogito> There is this ongoing thread, with no reply so far from grsec https://forums.grsecurity.net/viewtopic.php?f=3&t=4699
12:07 <jirutka> AlexIncogito: what does it mean “hire grsec”?
12:07 <AlexIncogito> From openwall thread, we can surmise grsec is in a "step back, and watch" attitude, which makes sense considering their motivation for going private
12:07 <AlexIncogito> Which would explain the lack of definite answer on their own forums
12:09 <AlexIncogito> @jirutka: as per openwall thread, the gist of it is: PAXTeam assert they have received no help, proposal or otherwise from google and other sponsors. Kees asserts they are willing to fund them
12:09 <Tsutsukakushi> grsec won't be mainlined as it is
12:10 <ncopa> Tsutsukakushi the current plan is to maintain the 4.9 patch for as long as possible
12:10 <Tsutsukakushi> what do YOU think are their motives for going private
12:10 <ncopa> jirutka i think i found a simple solution for openjdk on arm
12:10 <Tsutsukakushi> that kernel-hardening thread made it seem like it's purely financial
12:10 <ncopa> and i know what goes wrong
12:10 <ncopa> jirutka i think what happened was
12:11 <ncopa> oracle open sourced their arm32 hotspot
12:11 <Tsutsukakushi> i find it hard to take anything that pax team says seriously
12:11 <_ikke_> ugh, habitat release compile + make test takes 1.5h :-(
12:11 <Tsutsukakushi> he and spender aren't the best communicators
12:12 <ncopa> jirutka: im gonna stop adding noise to this chan. i'll explain in the git commit
12:13 <jirutka> _ikke_: that’s awfully long time… is it really “normal”, isn’t there some bug?
12:13 <Tsutsukakushi> ncopa: but what about the next stable kernel
12:13 <ncopa> we will have to deal with that then
12:13 cyteen_ joined
12:13 <_ikke_> jirutka: Might be, I'll paste the compile output somewhere
12:13 <jirutka> ncopa: this is not noise, it’s on-topic!
12:13 <Tsutsukakushi> ncopa: which is why i'm asking about plans
12:14 <Tsutsukakushi> dealing with it then without any plan sounds kind of painful
12:14 <jirutka> Tsutsukakushi: Shiz is trying to extract PaX from grsecurity patches and maintain it separately, but not sure if he’s still on it, it looks like a lot of pain
12:14 <Tsutsukakushi> doing anything with that gigantic patch seems like pain
12:15 <Tsutsukakushi> other than "stealing" ideas
12:15 leitao joined
12:16 <ncopa> Tsutsukakushi: the plan is to try keep unofficial grsecurity as long as possible. for now it looks like it might be possible to maintain it for 4.9
12:16 <ncopa> i have done that for 4.4 for a while
12:16 <ncopa> so i know what pain it is
12:17 <AlexIncogito> Well, money is caring... From what I understand about the whole grsecurity+pax history, it is understandable they feel upset. I may be missing parts of the story, but they do make very compelling arguments, with specific facts, about the various incidents, behaviours, and general lack of investment from other in their work. And neither kees or anyo
12:17 <AlexIncogito> ne else seem to have refuted them... Their tone may be sarcastic and unfriendly, but they did make an indirect opening regarding funding. And isn't it natural that their work should be rewarded ? It seems, they more than most, deserve it
12:17 <ncopa> spender also said that they might dump testing patches regularily in the future
12:17 <ncopa> but he didnt want to promise to do so, which is why they didn't say anything about it in the public announcement
12:18 <Tsutsukakushi> chances are that the companies haven't wanted to fund them because of their general attitude
12:18 <ncopa> so our options are: try keep maintain unofficial patch or switch to mainline
12:18 <AlexIncogito> Possibly.. That said Torvald doesn't seem to be the most agreeable either
12:19 <Tsutsukakushi> ncopa: there are more options tho
12:19 <^7heo> Tsutsukakushi: the gh/thestinger/linux-hardened repo is maintained by the folks at copperheados afaik
12:20 <AlexIncogito> There's also this forward porting initiative https://github.com/minipli/linux-unofficial_grsec
12:20 <ncopa> AlexIncogito that will not go beyond 4.9
12:20 <^7heo> Tsutsukakushi: and they called "the community" to commit to continuing the grsec project on twitter.
12:21 <jirutka> Tsutsukakushi: we should provide better support for vanilla kernel anyway (e.g. virt variant)… then we will just drop hardened, or not
12:21 <Tsutsukakushi> (also linux-libre)
12:21 <ncopa> AlexIncogito: i do use the minipli stuff. i have compared with my fork
12:21 <Tsutsukakushi> some guy on your forum made a very stupid false statement about linux-libre
12:21 <Tsutsukakushi> btw
12:21 <Tsutsukakushi> maybe should be corrected
12:23 <ncopa> jirutka: so, openjdk. oracle released their arm32 stuff (hotspot i think), which has native code
12:23 <^7heo> Tsutsukakushi: where?
12:24 <ncopa> the default hotspot has native code for aarch64 but not for arm32
12:24 <jirutka> kaniini has promised me to improve vanilla kernel configs, add some more hardening, but it seems that he haven’t had time for it yet
12:24 <^7heo> time is a scarce resource
12:24 <ncopa> the aarch32 hotspot has native arm32 code but no native aarch64
12:24 <^7heo> especially when there's so much IRC to do.
12:25 <ncopa> ha
12:25 <ncopa> jirutka so what im gonna do: use hotspot=default explicitly
12:25 <ncopa> that should give us what we have had earlier
12:26 gromero joined
12:26 <ncopa> this is slower on armhf than the newly released
12:26 <jirutka> ncopa: can’t we just use aarch32 hotspot on armhf?
12:26 <ncopa> that is what configure does by default
12:26 <ncopa> but then the patches does not apply
12:26 <jirutka> ncopa: aha
12:27 <jirutka> ncopa: well, I agree, hotspot=default
12:27 <ncopa> so for now i think we need to just use the old hotspot
12:27 <ncopa> to move forward
12:27 <ncopa> then we can look into how to apply patches conditionally
12:27 <jirutka> ncopa: anyway, if one want performance, (s)he will probably not use armhf…
12:27 <jirutka> aarch64 FTW
12:27 <ncopa> yeah
12:28 <ncopa> i think oracle finally realized that if they keep things closed, people will ook for open alternatives
12:28 <ncopa> so i think they realized that they lose on it
12:28 <^7heo> Tsutsukakushi: https://twitter.com/CopperheadOS/status/865068357527187456
12:28 <jirutka> I don’t believe that
12:28 <^7heo> Tsutsukakushi: that is what I was referring to.
12:28 <jirutka> Oracle is pure evil
12:28 <jirutka> they were most likely forced to do it, somehow
12:28 <^7heo> +1
12:28 <ncopa> ofc
12:29 <ncopa> they realized they are losing
12:29 hnyqp joined
12:29 <ncopa> and does not have any choice than release the code if they want be relevant in future
12:29 <^7heo> Like microsoft suddently "loving "linux""
12:29 <ncopa> ofc
12:29 <jirutka> I don’t believe that they understand open-source, the situation on market etc. and did it voluntarily
12:29 <Tsutsukakushi> back
12:29 <Tsutsukakushi> ^7heo: in the kernel area, the deblobbed thread
12:29 <ncopa> they understand business
12:30 <jirutka> I personally even don’t believe that they did it b/c they realized that they’re losing
12:30 <Tsutsukakushi> ^7heo: he says linux-libre is outdated when it had had a release 15 days before his comment
12:30 <Tsutsukakushi> ^7heo: and the latest release currently is from this month
12:30 <Tsutsukakushi> not outdated
12:30 <jirutka> if the world and market would be relational and fair, Oracle would be already dead for years
12:30 <^7heo> Tsutsukakushi: I was expecting a link. I don't doubt your words, but acting on it needs a source. ;)
12:30 <jirutka> they’re still here, despite their pure evil and their products are horrible
12:31 <Tsutsukakushi> i didn't have it open anymore, i can get the link
12:31 <Tsutsukakushi> https://forum.alpinelinux.org/forum/kernel-and-hardware/kernel-without-binary-blobs
12:31 hnyqp joined
12:33 <ncopa> jirutka im not claiming they are releasing the sources due to goodwill or charity or because they want support open-source
12:33 <ncopa> i think they do it as a desperate action to keep java relevant in business
12:34 <jirutka> ncopa: but they’re still doing everything they can to kill it…
12:34 <ncopa> kill what?
12:34 <jirutka> ncopa: like suing companies from using Java
12:34 <jirutka> ncopa: unclear terms
12:34 <Shiz> hello
12:35 <Shiz> jirutka: i did more work on llvm stuff last night a bit
12:35 <Shiz> all llvm components that i know of have testsuites now
12:35 <jirutka> ncopa: releasing JRE/JDK that is free to download, but contains even licensed parts, so one may use it against license without even knowing it
12:36 <jirutka> Shiz: even clang? that’d be grat!
12:36 <Shiz> yeah
12:36 <Shiz> llvm, clang, compiler-rt, libc++, lld
12:36 <Shiz> i should check llvm-libunwind too
12:36 <jirutka> ncopa: with licensed parts I mean components that should not be used without paid license
12:37 <Shiz> 14:21:53 Tsutsukakushi │ maybe should be corrected
12:37 <Shiz> why don't you o it yourself?
12:37 <jirutka> ncopa: instead of cleanly releasing two variants, one with only free components and one with their proprietary paid components
12:37 <Tsutsukakushi> i don't have an account on the forums
12:37 <Shiz> jirutka: btw:
12:37 <Tsutsukakushi> and i don't want to create one just to make a single comment
12:38 <Tsutsukakushi> i already have enough useless accounts
12:38 <jirutka> btw why we have forum?
12:38 <Shiz> one of my changes is renaming llvm-test-utils to llvm-utils and throwing stuff from the cmake's LLVM_INCLUDE_UTILS in there
12:38 <Shiz> seems ok?
12:38 <jirutka> who actually reads comments on forum?
12:40 <jirutka> imo it’d be better to merge ML and forum, i.e. use some forum that can be used completely via email like ML, to have only one channel instead of two
12:41 <jirutka> Shiz: why? it is *test* utils, not just random utils
12:41 <Shiz> thats not what the cmake file calls it
12:41 <Shiz> and i don't think it's a good idea to start making up package names ourselves
12:41 <Shiz> :P
12:42 <Shiz> https://github.com/llvm-mirror/llvm/blob/master/CMakeLists.txt#L482
12:42 <jirutka> Shiz: we don’t have other chance here…
12:42 <Shiz> https://github.com/llvm-mirror/llvm/blob/master/CMakeLists.txt#L842
12:42 <Shiz> why don't we?
12:42 <jirutka> aha, okay
12:42 <Shiz> llvm-utils is a fine package name :P
12:42 <jirutka> well, send PR, I’ll review it later evening
12:42 <Shiz> :)
12:42 <jirutka> maybe, but not for the current content, that is pure test utils
12:42 <jirutka> purely
12:42 <Tsutsukakushi> jirutka: there is that one frontend for mailman3
12:43 <jirutka> Tsutsukakushi: yeah
12:43 <jirutka> Tsutsukakushi: HyperKitty
12:43 <Tsutsukakushi> ye
12:43 <jirutka> Tsutsukakushi: I know it, I have Alpine packages for it
12:43 <Tsutsukakushi> i've yet to see it used anywhere
12:43 <AlexIncogito> All the implications of this may escape me but, with regard to the grsec situation, given security is the main theme here, how feasable would it be to maintain an official grsec branch on 4.9, even after the next increment, and backport security patches ? It may give a comfortable timeframe to figure out what to do, while allowing users to retain a
12:43 <AlexIncogito> safe base
12:43 <Tsutsukakushi> and their test instance blocks Tor afaik
12:43 <jirutka> Tsutsukakushi: it’s not very good, but unfortunately there’s not anything better :(
12:43 <Shiz> "official grsec branch" 100% unlikely
12:44 <Shiz> but forward-porting the last public patch to newer 4.9 is what we already /do/
12:44 <Shiz> for 3.6
12:44 <jirutka> Tsutsukakushi: you can try it https://gitlab.com/mailman/mailman-suite/issues/3
12:45 <AlexIncogito> Yes but what happens after 4.9 ?
12:45 <Tsutsukakushi> AlexIncogito: answer seems to be "we'll deal with it then"
12:46 <Shiz> well if nothing changes, no grsec
12:46 <AlexIncogito> Isn't that a huge step back ?
12:46 <Shiz> two things
12:47 <Shiz> as already has been said ad infinitum, grsec is not the sole, or even the biggest part, of our security story
12:47 <Tsutsukakushi> well, if the current trend continues then the linux-hardened project might be at ok stage by the time next stable kernel is released
12:48 <Shiz> and there's other projects in the works like strcat's hardened projects, and we may look at developing some features ourselves
12:48 <Shiz> we'll see that last part when the time comes
12:48 <Shiz> nobody likes grsec going private but there's not much we can do about it
12:48 <jirutka> Shiz: kaniini has mentioned some project on top of vanilla kernel, but don’t remember the name
12:48 <Shiz> spender's not going to license grsec at a distro level, especially a public one, even if we had the money
12:49 <jirutka> Shiz: IIRC acronym starts with "A" and has 4 letters XD
12:49 <Shiz> jirutka: https://github.com/thestinger/linux-hardened/wiki
12:49 <Shiz> that's strcat's project
12:49 <Shiz> jirutka: sure you're not thinking of AOSP?
12:49 <jirutka> nope
12:49 <Shiz> or KSPP?
12:50 <jirutka> nope
12:50 <jirutka> wait for kaniini, I have really bad memory for acronyms XD
12:51 <^7heo> KSPP: Kernel Self Protection Project
12:52 <^7heo> (i.e. an alternative to grsec)
12:52 <Shiz> KSPP is not an alternative to grsec
12:52 <^7heo> Shiz: https://www.grsecurity.net/compare.php
12:52 <Shiz> it's simply kees' branch to upstream certain security features
12:52 <Shiz> ^7heo: and?
12:52 <^7heo> Shiz: that table is misleading then.
12:52 <Shiz> it is
12:53 <Shiz> of course it is, they're comparing their own project to other projects
12:53 <Tsutsukakushi> it's not alternative because grsec has no intention or desire to upstream anything
12:53 <Shiz> it also tries an equivalency between SELinux and grsec
12:53 <Shiz> which is ridiculous at best
12:53 <Shiz> SELinux's goal is not kernel self-protection, it's an RBAC/DAC system
12:53 <^7heo> Shiz: yeah that's what I was wondering about.
12:53 <Shiz> likewise for AppArmor
12:55 <^7heo> Well, long story short
12:55 <^7heo> There's no real equivalent for grsec
12:55 <^7heo> I think that's what the table is mainly aimed at.
12:56 <Shiz> of course grsec will say that themselves
12:56 <Shiz> they have to sell their patch
12:56 <^7heo> true.
12:56 <^7heo> but do you know any project that could compare to grsec?
12:56 <Shiz> closest i got is strcat's project
12:56 <Shiz> i hope it doesn't turn out to be just kspp v2 though
12:56 <^7heo> so the linux-hardening thing Tsutsukakushi linked?
12:57 <Shiz> https://github.com/thestinger/linux-hardened/wiki#upstream-progress-tracking
12:57 <Shiz> yes
12:58 <^7heo> yeah I followed that.
12:58 <^7heo> not closely but I did follow it.
12:58 <^7heo> Problem is, since they want to make money out of it; it's not easily available yet.
12:58 <^7heo> Only on a Pixel/Pixel XL if you live in the north american continent.
12:59 <^7heo> (if I got it right)
12:59 <Tsutsukakushi> out of that kernel?
12:59 <^7heo> AFAIU yes.
12:59 <Tsutsukakushi> what is afaiu
13:00 <^7heo> As far as I understand/understood
13:00 <^7heo> (in our case, the latter)
13:00 <Tsutsukakushi> that linux-hardened kernel is right there
13:00 <Tsutsukakushi> you can clone it if you want
13:00 <^7heo> I'm talking about android
13:00 <Tsutsukakushi> and run it
13:00 <Shiz> ^7heo: you are very very wrong
13:00 <^7heo> ASOP
13:00 <Tsutsukakushi> but
13:00 <Shiz> linux-hardened has nothing to do with android...
13:00 <Tsutsukakushi> you were just talking about completely other stuff
13:01 <^7heo> Shiz: stop saying that I'm wrong BEFORE you have a change to understand what I'm talking about...
13:01 <^7heo> Shiz: that doesn't help with anything...
13:01 <^7heo> Tsutsukakushi: well, it's easy to integreate with Linux in the scope of Alpine.
13:01 <Tsutsukakushi> so you aren't talking about that linux-hardened anymore
13:01 <Tsutsukakushi> but about something else?
13:01 <^7heo> Tsutsukakushi: but yes you're right, that's not what I'm talking about; I was saying: "it's not easily available yet."
13:02 <Tsutsukakushi> yes
13:02 <Tsutsukakushi> and that sounded like it was about the last thing discussed
13:02 <Tsutsukakushi> which was linux-hardened
13:02 <^7heo> well, the linux-hardened repo/project.
13:02 <^7heo> yes.
13:02 <Shiz> so i stay with my point
13:02 <Shiz> linux-hardened has nothing to do with copperhead
13:02 <jirutka> Shiz: ^7heo: hm, maybe it’s really KSPP… sounds familiar… so I was half-right, it doesn’t start with “A”, but has 4 letters XD
13:03 <Shiz> except that copperhead may use it at one point
13:03 <Shiz> there's no money intention in linux-hardened
13:03 <Shiz> and it's as easily available as cloning the repo and building it
13:03 <Shiz> just like upstream linux
13:03 <^7heo> well, if you call "cloning the project, applying it, solving the conflicts, doing all the work so you get a working kernel, and then putting the working kernel package on the repos" easy
13:03 <^7heo> then yes it's easy.
13:04 <^7heo> I'm talking about "downloading binary, installing binary" easy.
13:04 <Shiz> uuh
13:04 <Shiz> you don't need to apply anything
13:04 <Shiz> the cloned repo IS the final tree
13:04 <^7heo> So you just clone and make?
13:04 <Shiz> and this is not different from upstream linux
13:04 <Shiz> yes
13:04 <^7heo> ah
13:04 <^7heo> I didn't get that part.
13:04 <^7heo> please disregard what I have been saying then.
13:05 <Tsutsukakushi> well, you clone, make menuconfig and make
13:05 <Shiz> :p
13:05 <^7heo> yeah yeah like a normal kernel.
13:05 <^7heo> my bad.
13:05 <Tsutsukakushi> gotta enable the features
13:05 <^7heo> true.
13:05 <^7heo> but I expected it to be a set of patches in a repo.
13:05 <^7heo> I didn't look in depth yet.
13:05 <^7heo> Then it's a really cool work.
13:06 <Shiz> we gotta evaluate later just how viable/quality it is
13:06 <^7heo> Also: <@Shiz> linux-hardened has nothing to do with copperhead
13:06 <Shiz> but first, 3.6
13:06 <^7heo> It has
13:06 <^7heo> same guy is doing both.
13:06 <Shiz> ^7heo: your own remark goes back to you, read further
13:06 <Shiz> @Shiz │ except that copperhead may use it at one point
13:07 <Shiz> :p
13:07 <^7heo> but that was my entire point tbh
13:07 <^7heo> they already do
13:07 <^7heo> on Pixel/Pixel XL
13:07 <Shiz> not afaik
13:07 <^7heo> really?
13:07 <^7heo> I do not have sources on that other than my memory, from IRC conversations
13:07 <Shiz> the last copperhead OS build was may 1st
13:08 <^7heo> that's not true.
13:08 <^7heo> You can't know that.
13:08 <^7heo> because:
13:08 <Shiz> https://copperhead.co/android/downloads
13:08 <Shiz> ...
13:08 <^7heo> the images for Pixel/Pixel XL are NOT avaialble.
13:08 <^7heo> you gotta pay for them; and only with a new Pixel device.
13:08 <Shiz> yes they are?
13:08 <Shiz> or at least
13:08 <Shiz> their dates are
13:08 <Shiz> they are right htere on the site
13:08 <Shiz> Pixel N2G47O.2017.05.01.22.35.44
13:08 <Shiz> Pixel XL N2G47O.2017.05.01.22.35.44
13:08 <^7heo> Right, that was even on twitter.
13:08 <Shiz> so yes, I can know that
13:09 <^7heo> Lemme fetch the tweet.
13:09 <^7heo> because I beg to differ there.
13:09 <^7heo> I believe the dates on the website are not correct.
13:12 <^7heo> Ok, I need more practice with twitter.
13:12 <^7heo> You're right.
13:12 <^7heo> it's just a *pinned* tweet.
13:12 <^7heo> Not a new one.
13:12 <^7heo> v_v
13:13 <Shiz> :P
13:13 <^7heo> Sorry Shiz, and you're right, the Pixel images are likely not containing the linux-hardened since it would mean that strcat would have intentionally antidated the commits on github just for that sake.
13:16 <fcolista> ncopa, I added this: http://tpaste.us/Bewn for having a custom iso with zfs, then i've generated the iso with:
13:16 <fcolista> sh mkimage.sh --tag edge --outdir /home/fcolista/iso --arch x86_64 --repository http://d
13:16 <fcolista> l-cdn.alpinelinux.org/alpine/edge/main --profile custom
13:16 <ncopa> fcolista i dont think it will work
13:17 <fcolista> would be nice having the part "custom" of profile actually customizable, maybe taking as input a yaml
13:17 <fcolista> ncopa, it worked :)
13:17 <ncopa> ok, nice
13:17 <fcolista> I had the iso created
13:17 <fcolista> x86_64-edge:~/iso$ ls -l
13:17 <fcolista> total 302080
13:17 <fcolista> -rw-r--r-- 1 fcolista fcolista 309329920 May 17 14:49 alpine-custom-edge-x86_64.iso
13:17 <fcolista> then i've made a bootable usb with this iso, and i had zfs up and running
13:18 <ncopa> ok
13:18 <fcolista> dunno if it's the right approach to have custom iso, though
13:19 <ncopa> i think you could do mkimg.zfs.sh
13:20 <ncopa> and instead of profile_custom(){ .. }
13:20 <ncopa> you call it profile_zfs
13:20 fekepp joined
13:20 <ncopa> then you do --profile zfs
13:20 <ncopa> that said
13:21 <ncopa> i was thinking about adding zfs kernel modules to alpine-extended
13:21 <fcolista> ncopa, what about a more-general custom iso?
13:22 <ncopa> how do you mean?
13:22 <ncopa> if you want make a custom iso you make a new profile
13:22 <fcolista> Like a user that wants his own iso, with custom apks
13:22 <fcolista> and feed a only mkimg.custom.sh with a yaml file maybe
13:23 <ncopa> what if he wants other kernel flavor?
13:24 <ncopa> or what if he want or not want serial console?
13:24 <ncopa> the idea is that you can define your own profile
13:24 <fcolista> Right. Maybe those can be passed as options
13:25 <ncopa> or he could define what he wants in his profile
13:25 <fcolista> yes, true. Would be nice to have it documented, since the wiki page related to "custom ISO" is outdated i believe
13:26 fekepp joined
13:26 <ncopa> yup
13:26 <fcolista> thx for the feedback though ncopa
13:26 <ncopa> however, that profile_custom
13:27 <ncopa> we could ship it as mkimg.custom.sh
13:27 <ncopa> and add comments
13:27 <ncopa> then it should be relatively easy for people to figure out how to make a custom iso
13:27 <ncopa> eg the mkimg.custom.sh would only be as an example
13:28 pbregener joined
13:29 <ncopa> what do you think about adding zfs modules to the alpine-extended iso?
13:29 <fcolista> ncopa, i don't know how much stable/mature is
13:29 <fcolista> since i didn't tested it
13:30 <ncopa> it works
13:30 <ncopa> i use it on my laptop
13:30 <fcolista> oh
13:30 <fcolista> that's cool
13:30 <fcolista> so i'm ok with that then
13:30 <ncopa> the current problem is that it is inconvenient to install alpine on zfs root
13:31 <ncopa> becaue you need to boot something with zfs modules afailable
13:31 <ncopa> available*
13:31 <fcolista> alpine-extended that ships it as a module by default would solve it
13:31 <ncopa> yes
13:32 <ncopa> we should probably also ship the zfs userpace package there too
13:32 <fcolista> yes ofc
13:32 <fcolista> in the alpine-extended it really makes sense
13:45 fekepp joined
13:46 leo-unglaub joined
13:59 pbregener joined
14:07 <clandmeter> How would somebody know he needs extended iso for zfs support?
14:21 mmlb joined
15:21 <ncopa> the only issue i see with it is possible legal issues
15:24 <Shiz> we already distribute zfs binaries, though
15:27 <ncopa> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
15:27 <ncopa> true
15:28 <jirutka> someone mentioned some tool for maintaining patches few weeks ago… does anyone remember name of the tool?
15:29 <_ikke_> quilt?
15:29 <jirutka> I’m looking for something that would help me with porting patches to newer version of code base
15:29 xentec joined
15:31 <Shiz> sounds like quilt
15:31 <Shiz> although you may want to just use git :P
15:31 <_ikke_> jirutka: was it in this channel?
15:32 <jirutka> yeah, quilt
15:32 <jirutka> thanks
15:54 tty` joined
15:55 <ncopa> anyone volunteer to write a release notes for 3.6.0?
15:55 <* clandmeter> hides
15:55 <ncopa> i mean
15:55 <ncopa> can someone help me write a proposal for 3.6.0 release notes
15:55 <clandmeter> i think Shiz did a good job last time.
15:55 <TemptorSent> fcolista: RE ZFS and custom isos, it's solved problem in my branch of mkimage, but waiting on fixes to apk to make it user-ready (waiting several minutes to extract the manifest from an apk is a deal-breaker)
15:56 <ncopa> then publish the proposal here so we can discuss it so we dont forget anything important
15:56 <ncopa> TemptorSent: fcolista has slightly different problem than you had, his iso works
15:57 <ncopa> he does not need the zfs userspace in his initramfs
15:57 <TemptorSent> ncopa: Ahh, then it should just be a matter of adding it to the image's local repo.
15:58 <clandmeter> the problem is there is no documentation about mkimage
15:58 <ncopa> yeah
15:58 <TemptorSent> True.
15:58 <clandmeter> ive seen multiple ppl try using alpine-iso
15:58 <clandmeter> im not sure it still works
15:58 <TemptorSent> *lol* Yeah, I was one of them.
15:59 <clandmeter> the wiki entry really needs a redirect to mkimage.sh
16:00 <clandmeter> or atleast a notice of its abandon state
16:00 <TemptorSent> ncopa: Any ETA on the extraction of checksums from apks that you're aware of?
16:01 <ncopa> ?
16:02 <TemptorSent> ncopa: The usability holdup on my mkimage branch at this point is the fact that I'm having to extract the checksums from the pax archive headers using awk, which takes ENTIRELY too long for things such as the kernel/firmware.
16:03 <TemptorSent> kaniini had mentioned he thought it should be fairly easy to add that functionality, but we're looking after 3.6 drops unless something changes IIRC.
16:04 <clandmeter> ncopa, mkimage is since 3.5 right?
16:05 <clandmeter> I added a obsolete mark on our wiki entry.
16:10 <ncopa> TemptorSent it does sound fairly easy to add it
16:10 <jirutka> uh, there are sooo many changes since 3.5, it’ll be quite hard to remember them all; maybe we should write it continually next time
16:10 <ncopa> TemptorSent but it will not happne before 3.6 release
16:11 <jirutka> what I remember from head: rust, rust, cargo, rust!
16:11 <TemptorSent> ncopa: That would significantly speed up the most painful part.
16:11 <TemptorSent> Understood - that's why I suspended work on the new mkimage suite until after 3.6 drops.
16:11 <jirutka> then ghc
16:11 <jirutka> and from less important: php7
16:11 <ncopa> jirutka yes, i was also thinking of writing a plan for 3.7 release and goals
16:12 <jirutka> llvm4
16:12 <ncopa> from the top of my head:
16:12 <TemptorSent> kernel grsec->hardened
16:12 <jirutka> important change: llvm is out, every llvm package has version suffix now, the latest is llvm4, the latest also provides="llvm-*-$pkgver-r$pkgrel"
16:13 <jirutka> but other llvm components, clang, lldb, lld, llvm-libunwind, … are in single version, built against the latest llvm
16:13 <ncopa> php 7.1, gcc 6.3
16:14 <TemptorSent> release notes should probablyt note the change to 'set -e' in abuild.
16:14 <jirutka> we have added lld, llvm-libunwind and libc++ (if you move it to community)
16:14 <ncopa> go 1.8
16:14 <ncopa> did we update phyth 3 version?
16:14 <ncopa> python*
16:14 <jirutka> yes, 3.6
16:14 <ncopa> basically all languages that updated significantly
16:14 <jirutka> also luajit-2.1_beta3
16:15 <ncopa> is it incompatible with previous luajit?
16:15 <jirutka> I hope that it’s not
16:15 <ncopa> then its lower prio
16:15 <ncopa> if we get too much stuff we can drop mention it
16:16 <ncopa> postgresql update needs to be mentioned but i dont think we updated it
16:16 <jirutka> emscripten
16:16 <TemptorSent> What's status on pgsql? Has anyone packaged 10b1?
16:16 <ncopa> no
16:16 <jirutka> well, at least emscripten-fastcomp (their llvm fork)
16:16 <jirutka> emscripten itself is still in testing, I don’t know if I want to move it to community, emscripten is mess
16:16 <ncopa> important stuff is things that can make things break when people upgrade
16:16 <TemptorSent> There are major breaking changes in pgsql 10 vs. 9.6, including changing versioning scheme.
16:17 <jirutka> we don’t have pgsql 10, cause it’s not released yet
16:17 <TemptorSent> Beta 1 just dropped.
16:17 <kaniini> reworking kernel packaging is on my todo list for 3.7
16:17 <jirutka> beta…
16:17 <Shiz> clandmeter: i never wrote release notes...
16:17 <ncopa> lol
16:17 <kaniini> so that third-party modules are built against all arch-specific flavors
16:17 <jirutka> nginx updated to 1.12
16:18 <kaniini> instead of having one APKBUILD for each flavor
16:18 <ncopa> that is significant
16:18 <Shiz> fix some important apk bugs
16:18 <Shiz> :P
16:18 <Shiz> important for rel notes
16:18 <kaniini> ya
16:18 <kaniini> like how providers are handled
16:18 <kaniini> :P
16:18 <TemptorSent> kaniini - good, that's critical. I'm still getting broken modules on upgrade until I reboot.
16:18 <ncopa> so we can group them like
16:19 <ncopa> - (possibly) breaking changes
16:19 <ncopa> - significant fixes
16:19 <jirutka> ruby 2.3 → 2.4
16:19 <ncopa> not sure if we backported the apk fixes?
16:19 <ncopa> yes
16:19 <Shiz> kernel update too ofc
16:19 <jirutka> abuild set -e and check
16:19 <ncopa> kernel too yes
16:20 <Shiz> is linux-hardened in the repo on 4.9.28?
16:20 <TemptorSent> At the least, the russian roulette patch should be backported.
16:20 <ncopa> abuild set -e is not that important
16:20 <ncopa> i mean not for most runtime users
16:20 <jirutka> hm, true
16:20 <ncopa> its ofc a very good thing for devs
16:21 <ncopa> - devs improvements
16:21 <TemptorSent> ncopa: set -e may break someone's local abuilds, so a note is probably worthwhile still.
16:21 <kaniini> TemptorSent: yes, i want to make sure that it is packaged in a way that apk will group the upgrades atomically
16:21 <kaniini> what is annoying is: some packages are right, others are not
16:21 <ncopa> Shiz: Linux ncopa-desktop 4.9.28-1-hardened
16:21 <TemptorSent> kaniini: Let's figure out what the RIGHT way is, then force everything into that form.
16:22 <kaniini> TemptorSent: i already know what the right way is
16:22 <ncopa> oh
16:22 <ncopa> significant new stuff: ppc64le, s390x support
16:22 <jirutka> yes
16:22 <TemptorSent> kaniini: Okay, cool :)
16:22 <clandmeter> Shiz, then it was somebody who looked like you :)
16:23 <Shiz> ncopa: nice
16:23 <kaniini> TemptorSent: backporting russian roulette patch is not necessary
16:23 <Shiz> clandmeter: i take offense to this
16:23 <TemptorSent> kaniini: And this will allow multiple kernel versions installed simultaneously, including their modules, right? :)
16:23 <kaniini> TemptorSent: apk will upgrade itself before running the upgrade transaction(s)
16:23 <kaniini> TemptorSent: that is the goal yes
16:24 <TemptorSent> kaniini: Ahh, okay - wasn't sure if it would screw up the dep calcs before the fact or not.
16:24 <kaniini> TemptorSent: it is going to require some minor changes to abuild
16:24 <TemptorSent> kaniini: Makes sense - essentially dependent packages should be built for each version/flavor.
16:25 <clandmeter> Shiz, sorry I will try not to mistake you next time.
16:25 <Shiz> ;p
16:25 <Shiz> now i'm curious who did in fact do it
16:25 <Shiz> also i don't mind writing relnotes
16:25 <Shiz> fwiw
16:27 <tmh1999> yay ppc64le and s390x support
16:27 <kaniini> TemptorSent: in general, i want to change the way upgrades are grouped too in apk, so that upgrades happen together whenever possible (a package and its subpackages)
16:28 <TemptorSent> kaniini: That would make good logical sense, as well as possibly allowing partial-upgrades in a sane manner.
16:28 <clandmeter> Oh now I remember
16:28 <clandmeter> It was ikke
16:29 <* kaniini> is not really convinced on binary format for apkindex though :)
16:29 <Shiz> i see how it is, all of us dutchmen are the same huh
16:29 <kaniini> yes now get in your windmill and shut up
16:29 <TemptorSent> kaniini: At some point, would you be willing to diagram out APK's current structure?
16:29 <Shiz> ;p
16:29 <tmh1999> lol
16:29 <TemptorSent> No binary indexing!
16:29 <kaniini> TemptorSent: given enough whiskey, sure
16:29 <tmh1999> I thought Shiz is Japanese
16:30 <TemptorSent> kaniini: What's your poison? :)
16:30 <Shiz> tmh1999: i don't think weeaboo qualifies as proper japanese
16:31 <kaniini> for apk-tools my personal todo list is basically
16:31 <kaniini> - apk install/remove as alternates for apk add/del
16:31 <TemptorSent> kaniini: I'm still trying to understand the resolution process in apk, as it's several layers it seems.
16:31 <Shiz> でも。。。ありがとう
16:31 <Shiz> moving on
16:31 <kaniini> - apk contents dumper
16:32 <kaniini> - apk builder
16:32 <kaniini> - grouping package changes into subtransactions sorted by origin
16:32 <TemptorSent> Those two are essentially 'pax' + some metadata, correct?
16:32 <kaniini> - ed25519 key support
16:33 <kaniini> - apk subcommand support (like git, so you can install apk-foo binary and have it integrate into the package manager)
16:34 <TemptorSent> I'm liking it kaniini.
16:34 <kaniini> - apk dist-upgrade as alias for apk upgrade --available
16:34 <kaniini> all of that should be in 3.7
16:34 <kaniini> no promises, but i will try
16:34 <kaniini> oh, also
16:35 <TemptorSent> kaniini: That would represent major improvements to usability.
16:35 <kaniini> - ability to record external installed files into the package manager database
16:35 <Shiz> i don't like the dist-upgrade term :(
16:35 <kaniini> (so you can do pip3.6 install foo, and pip3.6 can then record the files it now controls in apk's database so it leaves them alone)
16:35 <jirutka> kaniini: +1
16:36 <jirutka> kaniini: what about something like “alternatives”? we need it badly
16:36 <TemptorSent> kaniini: Along with that, can we add a means of handling symlinks?
16:36 <kaniini> (the plan there is to allow pip and others to actually leverage the package building functionality and then install the package)
16:37 <kaniini> jirutka: yes, alternatives is something i am looking into as well
16:37 <kaniini> as for fabled's binary indexes
16:37 <kaniini> i'm not 100% on them
16:37 <TemptorSent> I have 'alternatives' partially implemented.
16:37 <kaniini> it may save a few msec of time, but i don't really think we need to worry about that
16:37 <TemptorSent> I do not like the idea of binary indicies
16:37 <kaniini> apk is already waaaaaay faster than most
16:38 <TemptorSent> If needed, a binary cache is a possibility I suppose.
16:40 <TemptorSent> kaniini: Can we put the apk work list somewhere on the wiki perhaps?
16:40 <kaniini> jirutka: so on alternatives,
16:41 <kaniini> jirutka: i don't think it is appropriate to have them in apk
16:41 <jirutka> kaniini: agree, it should be a separate utility
16:41 <jirutka> kaniini: I just thought that it’s relevant to bring it to this discussion
16:42 <TemptorSent> kaniini, jirutka: Agreed - although apk could indicate the which providers are available.
16:42 <kaniini> TemptorSent: it could, but then we just created yet another alternatives implementation tied to a package manager
16:42 <kaniini> TemptorSent: and in reality, like all the others, it will suck
16:43 <* kaniini> is more into solving specific problem domains with specific tools
16:43 <TemptorSent> kaniini: No need for it to do anything special, just expose the information in the abuild.
16:43 <kaniini> TemptorSent: abuild can just as easily create a file in /etc/alternatives/$pkgname
16:44 <TemptorSent> kaniini: Right, but that won't be available until the package is installed.
16:44 <kaniini> TemptorSent: which is a lot cleaner
16:44 <kaniini> TemptorSent: provides and alternatives are different things
16:44 <TemptorSent> kaniini: I'm considering the "Which providers can I use for this functionality"
16:44 <kaniini> TemptorSent: if a packager wants to make apk aware of it, she should use $provides
16:45 <TemptorSent> kaniini: For instance, "What are my alternatives for 'ssh'?"
16:45 <kaniini> TemptorSent: apk search --provider ssh
16:45 <kaniini> TemptorSent: searching by $provides is already on my todo, but maybe not for 3.7
16:46 <TemptorSent> Does that work for both openssh and dropbear? If so, that's all we need from apk.
16:47 <TemptorSent> The utility can manage which one is in use, but it needs to have a way of knowing what's available.
16:47 <kaniini> TemptorSent: it does not work for that yet, as nobody has added that metadata... but that is basically what i plan to do. i dont see it as related to alternatives
16:47 <kaniini> TemptorSent: you can already install openssh and dropbear at same time, for example
16:47 <TemptorSent> Right, the 'alternatives' part would be selecting which of them handles incomming connections.
16:47 <kaniini> no it wouldn't
16:48 <kaniini> you apparently don't know what we mean by alternatives
16:48 <kaniini> :D
16:48 <TemptorSent> Okay, I guess not?
16:48 <kaniini> alternatives is
16:48 <kaniini> two packages provide /usr/bin/pkg-config
16:48 <kaniini> we want both installed
16:49 <jirutka> kaniini: what about support for installing multiple versions of same pkg simultaneously? I’m thinking about preparation to bury FHS…
16:49 <TemptorSent> Right, that's the simple case.
16:49 <kaniini> so those packages rename their /usr/bin/pkg-config to /usr/bin/pkg-config.pkg-config and /usr/bin/pkg-config.pkgconf
16:49 <TemptorSent> kaniini: Direct replacement is easy to manage with a symlink or wrapper.
16:49 <kaniini> jirutka: to add that to apk would be a ton of work
16:50 <kaniini> TemptorSent: right, that is what we are talking about
16:50 <jirutka> kaniini: but it’ll be definitely worth it ;)
16:50 <TemptorSent> kaniini: Okay, that's only a portion of what I was considering.
16:51 <kaniini> TemptorSent: yes i like shipping things and then incrementally improving on them instead of solving all things at once. it means we ship on time.
16:51 <TemptorSent> kaniini: I also have support for different packages providing the same functionality even if they have different configs.
16:52 <TemptorSent> kaniini: Agreed - although sometimes it's harder to implement a partial solution than the whole thing.
16:53 <kaniini> jirutka: i have grave concerns about departing from FHS in a way that is actually usable
16:53 <TemptorSent> kaniini: On the apk side, all that's needed is a bit of meta-data to indicate what functionality the package provides.
16:53 <TemptorSent> kaniini: LFHS is a bloody disaster IMHO, and has been since shortly after it's inception.
16:54 <jirutka> kaniini: me, skarnet and others think that it’s unavoidable and very needed, FHS is broken by design
16:55 <kaniini> jirutka: okay, when you, skarnet and others come up with a proposal to do this that won't confuse the shit out of some guy downloading an alpine ISO and trying it out, we can talk ;)
16:55 <TemptorSent> kaniini, jirutka: It's essentially impossible to correctly implement a system following FHS.
16:55 <jirutka> kaniini: the idea is to install pkgs into /something/$pkgname-$pkgver and use FHS structure like /usr/bin, /usr/lib etc. just for symlinks into /something/…
16:55 <kaniini> TemptorSent: when i say "departing from FHS", what i really mean is "departing from alpine's implementation of FHS"
16:56 <TemptorSent> kaniini: *lol* Well, as long as alpine's implementation of FHS isn't the LFHS, we're good :)
16:56 <Shiz> i agree with kaniini re:fhs
16:56 <TemptorSent> Redhat bjorked LFHS badly very early on.
16:56 <Shiz> a big concern about departing from our layout to a /pkg like structure is
16:56 <Shiz> reasonable partition segmentation dies
16:57 <jirutka> kaniini: ofc, I’m just mentioning some preconditions for apk…
16:57 <Shiz> e.g. i can't segment /var to its own partition anymore
16:57 dynaMIX joined
16:57 <kaniini> Shiz: yes, that too
16:57 <jirutka> wait, I’m definitely not saying store everything, including logs and configs of apps, into /something/$pkgname!!
16:58 <kaniini> jirutka: no but if i want /usr to be separate from /
16:58 <TemptorSent> Shiz: Not necessarily - it depends on how the packages are exposed and where their data lives.
16:58 <kaniini> jirutka: same thing
16:58 <Shiz> kaniini: eh, separate /usr can die
16:58 <Shiz> :P
16:58 <jirutka> . /etc, /var/log, /var/lib makes sense and they should stay, at least the separation, not necessary these names
16:58 <TemptorSent> No, seperate /usr can not die!
16:58 <Shiz> it can very much die
16:58 <kaniini> anyway, i do not see alpine moving away from its current filesystem layout anytime soon
16:58 <jirutka> yes, separate /usr has no sense
16:59 <TemptorSent> Shiz: Yes, I've read all the BS on why /usr isnt' needed any more, but it's BS IMNSHO.
16:59 <jirutka> and never had, just some ppl made up some sense that never was there
16:59 <Shiz> jirutka: it had some use before initrd/initramfs existed
16:59 <Shiz> but now, no
16:59 <TemptorSent> I frequently mount /usr from a different location.
16:59 <TemptorSent> Not to mention with differnt mount options, which is the real big issue.
16:59 <jirutka> Shiz: exactly
17:00 <jirutka> TemptorSent: and you’re doing it why? b/c you can?
17:00 <Shiz> let's delay this discussion for later
17:00 <Shiz> :p
17:00 <kaniini> like, if somebody seriously tries to shove that into alpine without testing it, i will just fork the distro and go on my own way :P
17:00 <jirutka> stop overcomplicating things just b/c 0.01 % of ppl do crazy things just b/c they can…
17:01 <kaniini> okay, here is another reason i am against it
17:01 <kaniini> i do not want to waste cpu time and inodes on storing and resolving symlinks
17:01 <Shiz> then hardlink
17:01 <TemptorSent> kaniini: That's possibly a valid concern.
17:02 <jirutka> kaniini: agree, we should definitely think about it and write proposal before migrating, I’m just saying what would be needed from apk to make it really useful and these changes are not tightly coupled with particular FS hirearchy
17:02 <TemptorSent> Shiz: Nope, hardlinks across FS don't work.
17:02 <Shiz> anyway
17:02 <jirutka> kaniini: symlinks are meant mainly for backward compatibility
17:02 <Shiz> topic for a later time
17:03 <Shiz> and that time is not now
17:03 <Shiz> what is now is 3.6 releasing
17:03 <Shiz> :P
17:03 <jirutka> and hardlinks are really not a good idea for this, as TemptorSent noted and there are more reasons
17:03 <TemptorSent> Agreed Shiz -- but we probably should start writing up notes.
17:03 <jirutka> Shiz: yes
17:04 <kaniini> jirutka: any such proposal must have a way to entirely opt out of it
17:04 <TemptorSent> I hate to say it, but we really need to build up roadmap.
17:05 <jirutka> kaniini: what do you mean? opt-out for users?
17:05 <jirutka> kaniini: that would be insane
17:05 <jirutka> kaniini: the goal is to decrease complexity, not to increase it!
17:05 <kaniini> i am quite happy with my filesystem the way it presently is
17:06 <TemptorSent> Not necessarily so insane - it could install either way without major changes.
17:06 <jirutka> TemptorSent: definitely not
17:06 <jirutka> TemptorSent: it’d be better to keep FHS than making a hybrid
17:06 <jirutka> TemptorSent: that would just bring the worst from both worlds
17:06 <TemptorSent> jirutka: I mean apk could install it either way, the FHS shouldn't matter.
17:06 <Shiz> and yet the conversation continues
17:07 <jirutka> TemptorSent: maybe you don’t see all consequences
17:07 <jirutka> ok, stop here
17:07 <TemptorSent> Looking at the apk-tools themselves, they should be FHS agnostic IMHO.
17:08 <jirutka> TemptorSent: omg, this is not only about apk-tools
17:08 <TemptorSent> The details should be in the packaging.
17:08 <kaniini> i do not want /pkgs
17:08 <TemptorSent> Right, I'm looking at kaniini's TODO and what is needed in APK to support a non-LFHS system.
17:09 <kaniini> if i am forced to have /pkgs, i will stop using alpine
17:09 <kaniini> 100%
17:09 <kaniini> yes, the conversation continues, because i do not want to wake up one day to have /pkgs
17:09 <jirutka> TemptorSent: but yes, I’ve mentioned multiple times that allow apk to install multiple versions simultaneously is not about FHS, no-FHS or anything, it’s very valid feature agnostic towards FS scheme
17:09 <kaniini> correct: it's about systemd-like tactics to force people to have things they don't want
17:09 <kaniini> i do not want /pkgs
17:09 <jirutka> kaniini: could you please think about it a bit more before writing such strong words?
17:09 <kaniini> i have thought about it, and i do not want it
17:09 <jirutka> kaniini: I hope that you can see what problems FHS creates
17:10 <kaniini> i do know FHS is flawed, but it is also what my sysadmins already know
17:10 <jirutka> kaniini: and how it’s conceptually wrong (one big mutable state)
17:10 <kaniini> if you want this stuff, go use Nix
17:10 <jirutka> kaniini: so we should suffer from it for eternity or what?
17:10 <kaniini> don't fuck up alpine
17:10 <jirutka> kaniini: it’s not about fucking up alpine, but fixing it…
17:10 <jirutka> kaniini: I don’t want Nix OS b/c systemd
17:10 <kaniini> suddenly freebsd 11 with all of it's bugs looks attractive again
17:11 <kaniini> okay use GNU Guix instead
17:11 <jirutka> no, I want to use Alpine
17:11 <kaniini> clearly you don't, if you want to force /pkgs on everyone
17:11 <jirutka> omfg
17:11 <kaniini> have you considered the overhead this will have for run from ram configs?
17:12 <jirutka> no
17:12 <Shiz> can we stop fighting and concentrate on 3.6 instead
17:12 <Shiz> jirutka: write a proposal about what you want
17:12 <Shiz> then we can discuss it
17:12 <jirutka> but we’ve discussed it multiple times with skarnet and others
17:12 <kaniini> and then i will NAK it
17:12 <kaniini> because i do not want it
17:12 <kaniini> i dont care what skarnet has to say on it
17:12 <jirutka> and we think that it brings much more benefits than negatives
17:12 <Shiz> right now it's just flinging around with no idea of what the other side wants
17:12 <Shiz> so let's not devolve to that further
17:13 <jirutka> and no one is saying that we will force Alpine to it, it’s open discussion
17:13 <kaniini> what i want is quite simple: things to remain the same as it is now
17:13 <jirutka> you’re position is not very constructive now
17:13 <kaniini> if i wind up having to fork alpine to keep my systems the way they are now, that is truly unfortunate
17:13 <TemptorSent> jirutka, kaniini: Let's attack this in detail later, but for now, document the issues so we don't have to rehash them.
17:14 <kaniini> i refuse to work on anything related to this
17:14 <jirutka> kaniini: once again, can you please stop being dickhead, be more open-minded and constructive?
17:14 <kaniini> i am not going to contribute my time to creating a situation i absolutely do not want
17:14 <Shiz> guys, relax
17:14 <Shiz> this clearly isn't the right atmosphere or time to discuss this in
17:14 <jirutka> we wanted to discuss it, not fight about it
17:14 <TemptorSent> kaniini: Do you have solutions for the problems that don't require breaking with LFHS?
17:14 <kaniini> jirutka: once again, can you stop proposing such radical changes to the way the system image is stored on disk?
17:15 <kaniini> TemptorSent: "problems"
17:15 <kaniini> TemptorSent: seems to be working fine for the past, oh, almost 50 years now
17:15 <TemptorSent> The inability to handle multiple versions of a package sanely.
17:15 <kaniini> nope, i don't
17:15 <jirutka> kaniini: you probably don’t see what extreme complexity and problems FHS brings
17:15 <kaniini> jirutka: i really do see
17:16 <jirutka> kaniini: as all other ppl who refuses to change anything and rather makes stupid workarounds for these problems
17:16 <kaniini> jirutka: i also see having to spend lots of time retraining everyone who manages alpine systems on my network how to use /pkgs
17:16 <jirutka> that’s why I don’t use Debian and craps like this
17:16 <kaniini> so i am glad you have told me about this proposal
17:16 <kaniini> so i can certainly halt migrating from freebsd to alpine
17:16 <jirutka> omg
17:16 <TemptorSent> And the library mismatch issues that plague some software (as in one program requires one SPECIFIC version of a lib, while another requries a different rev of the same version)
17:16 <kaniini> TemptorSent: flatpak
17:17 <jirutka> kaniini: flatpak is great example of HACKS (not solutions) for FHS
17:17 <jirutka> and to dynamic linking
17:17 <kaniini> seems to work fine
17:17 <jirutka> yeah, systemd also seems to work fine
17:17 <jirutka> as debian
17:17 <jirutka> and others…
17:17 <TemptorSent> kaniini: Okay, now we're getting closer, except IIRC flatpak add significan overhead, which is what we were trying to avoid..
17:17 <Shiz> i'll compile the above list into a concrete changelog for 3.6
17:18 <TemptorSent> Thank you Shiz.
17:18 <kaniini> kind of ironic that you use systemd as an example here when you intend to use systemd tactics to get /pkgs
17:18 <jirutka> if you want rigid system with tons of legacy shit, then I don’t understand why you use Alpine
17:18 <jirutka> we don’t use glibc! how unconventional!
17:18 <kaniini> who said i want tons of legacy shit
17:18 <jirutka> you’re afraid of changes
17:18 <kaniini> no, i am afraid of specific changes that i see as being an extreme shitshow
17:18 <jirutka> I just mention something about moving out from FHS and you’re freaking out like I’m threating you with a nuclear bomb
17:19 <kaniini> and will refuse, rightly, to contribute to making an extreme shitshow
17:19 <jirutka> once again, this is not constructive at all
17:19 <TemptorSent> Well, to be honest a nuke is probably about the right scale to take out LFHS.
17:19 <jirutka> argument, propose different solutions for certain problems
17:20 <kaniini> trying to emulate FHS ontop of /pkgs will not work reliably
17:20 <kaniini> i can think of many ways the emulated FHS tree will become inconsistent
17:20 <kaniini> please just respect that i do not want this
17:20 <jirutka> afk, I need to do some work and don’t want to be more upset…
17:21 <jirutka> fyi, Homebrew use something like this and it works quite well…
17:21 <kaniini> LOL
17:21 <kaniini> no
17:21 <TemptorSent> Does anyone else remember BEFORE LFHS? We had nice unix flavored directory structures. LFHS is what made a mess of it by assuming everything would be for the same arch/version as the host regardless of where it mounted from.
17:21 <jirutka> it enables things that are impossible on FHS
17:21 <kaniini> homebrew
17:21 <kaniini> is a fucking disaster
17:21 <kaniini> i have to constantly
17:21 <kaniini> reinstall apps on homebrew
17:21 <kaniini> after installing other apps
17:21 <jirutka> it’s not a great inspiration, it has different purpose, but I would not mark it as disaster
17:21 <kaniini> because the symlinks got messed up
17:22 <kaniini> if you want djb linux go make djb linux, don't drag alpine into it
17:22 <TBB> what's this /pkgs thing, software packaged into its own subdirectories or such?
17:23 <jirutka> TBB: it’s a sensible way how to install software, without messing with single big global state and solving tons of prolems with it
17:23 <kaniini> it's also a great way to wind up with a broken emulated FHS
17:23 <TBB> any pointers?
17:23 <TemptorSent> There's no reason it must be in /pkgs, /usr/pkgs would be equally valiud (or possibly moreso)
17:24 <* kaniini> puts in remote hands tickets to have freebsd 11 reinstalled on machines now
17:24 <jirutka> TemptorSent: it doesn’t matter how it would be named and where located…
17:24 <TemptorSent> jirutka: Exactly, nor does it need to be a single directory root.
17:24 <kaniini> suddenly broken process scheduling, memory management, and a buggy security hole called libXo look very attractive
17:25 <jirutka> kaniini: that’s your choice…
17:25 <jirutka> stop it please
17:25 <jirutka> we will sometime write some proposal that we can then discuss
17:25 <kaniini> jirutka: it will be the choice of everyone else who has this scheme show up on their machine and has to spend more than 30 seconds debugging it
17:25 <jirutka> this discussion is pointless now
17:25 <kaniini> jirutka: my answer is no
17:25 <kaniini> jirutka: regardless of any proposal
17:25 <jirutka> kaniini: than you know what…
17:26 <Shiz> hmm
17:26 <Shiz> i've got thsi right now
17:26 <Shiz> https://txt.shiz.me/ZjBhMWM3YT
17:26 <Shiz> but surely there is more that can be said
17:26 <Shiz> :)
17:26 <Shiz> also added * The `-grsec` packages have been renamed to `-hardened`
17:26 <TBB> my initial reaction to this is, both that and the traditional way of packaging are useful. I guess the main question is just how complex will supporting both get. but I think you've gone through that up there already
17:27 <Shiz> jirutka: do you have anything to add to that list?
17:27 <TemptorSent> Version for GHC?
17:27 <jirutka> TBB: yes, that’s the question we have to answer before any move… but it needs constructive discussion, to consider all positives and negatives, not what kaniini is doing right now… ಠ_ಠ
17:27 <kaniini> like
17:28 <kaniini> to be blunt
17:28 <kaniini> i would rather have systemd
17:28 <kaniini> than this
17:28 <tmh1999> Shiz : it should be "IBM System z" I guess
17:28 <Shiz> right
17:28 <Shiz> i was unsure how to name the target
17:29 <jirutka> s390x = IBM System Z ?
17:29 <tmh1999> yeah, I was confused at first. System/390 is more like s390(31 bit), System z is zArchitecture, which is 64 bit
17:29 <jirutka> 31bit? o.O
17:29 <TemptorSent> Yes,
17:29 <kaniini> yes, 31 bit.
17:29 <jirutka> why 31, not 32? o.O
17:30 <kaniini> the highest bit is used for bank
17:30 <Shiz> yeah s390 is not s390x
17:30 <Shiz> i know that much
17:30 <Shiz> s390x is 64-bit for one
17:30 <kaniini> or something weird
17:30 <TemptorSent> System z is it's own animal, but IIRC is based on the s390 arch.
17:30 <Shiz> good call re: ghc version
17:30 <Shiz> just added it
17:31 <kaniini> jirutka: if we were starting from scratch with a package filesystem then i would be supportive of this
17:31 <kaniini> jirutka: but i cannot support the notion of migrating everyone from FHS to a package filesystem
17:31 <tmh1999> jirutka : s390x = Linux on System z. System z is its own animal as TemptorSent says.
17:31 <kaniini> jirutka: it is too fucking risky
17:31 <Shiz> kaniini: this is an argument i can understand
17:32 <Shiz> anyway
17:32 <Shiz> let's see
17:32 <TBB> at first glance, it's also not -that- hard a problem to solve; since traditional package managers already, all of them pretty much, support alternative target roots, they can also already as is manage per-app package setups and deps. So basically they can be used for this already. I can see some challenges as well, but it takes some time to formulate them in words properly
17:32 <asie> i think package-based filesystem could benefit from more experimentation, not more usage in production
17:32 <Shiz> i'm sure we did more fundamental changes in 3.6, no?
17:32 <asie> gobolinux tried, for one
17:32 <kaniini> jirutka: so, NAK until the end of time, don't even bother writing a proposal if that is what it is going to be
17:32 <jirutka> Shiz: I can’t remember now, I’ll look at it once again later…
17:32 <jirutka> kaniini: please stop now
17:33 <kaniini> the linux-grsec -> linux-hardened swap should show you how fragile this stuff can be
17:33 <kaniini> why the hell would we want to do something this risky
17:33 <jirutka> kaniini: ncopa asked me to be more polite, so I’m not gonna reply to you now
17:33 <kaniini> i'm not going to stop until it's dead
17:33 <TBB> well, the whole world of containers is heading to that direction
17:34 <Shiz> i added development-related changes
17:34 <Shiz> is there anything of note there except set -e and sha512sums?
17:34 <jirutka> kaniini: then you should probably leave, b/c there are more ppl who supports this idea… but no one wants to force it without careful consideration of all positives/negatives and discussion about technical solutions
17:34 <kaniini> jirutka: okay i will fork alpine
17:34 <* kaniini> will be spending the weekend doing this
17:35 <jirutka> kaniini: how can I explain you that saying “I don’t want to hear any arguments, I don’t want to think about it, just NOPE” is totally wrong?!
17:35 <jirutka> kaniini: you still don’t get it
17:35 <jirutka> kaniini: calm down please
17:35 <kaniini> you are assuming i haven't thought about it
17:35 <jirutka> kaniini: we just want to discuss it for now, nothing more… and you’re freaking out like a small baby
17:35 <Shiz> no need to fork anything right now
17:35 <Shiz> alpine isn't going anywhere
17:35 <kaniini> maybe i thought about this some years ago and determined that there is no way to safely upgrade the system image in this manner
17:35 <TemptorSent> Shiz: I think that covers all I'm aware of of note.
17:35 <kaniini> maybe that is why we haven't done this
17:36 <tmh1999> Shiz : probably abuild version bump for dev
17:36 <kaniini> maybe i do not want to hose every single alpine install on the planet
17:36 <Shiz> i'll take a look at the abuild change log too
17:36 <Shiz> https://git.alpinelinux.org/cgit/abuild/commit/abuild.in?id=5b7b1f80cbaa88849e2698d67bf2d72ac9addac4
17:36 <Shiz> I think we can note this
17:37 <Shiz> oh
17:37 <Shiz> the check() stuff
17:37 <Shiz> of course
17:37 <Shiz> how could i forget
17:37 <tmh1999> :D
17:37 <jirutka> Shiz: I’ve already mentioned check()
17:38 <jirutka> Shiz: among other things before kaniini started freaking out :(
17:38 <kaniini> jirutka: as i said before, if we were starting from scratch, a package fs would be great
17:38 <Shiz> * A `check()` function has been added that allows packages to run test suites after `build()`, ensuring no regressions have occurred.
17:38 <Shiz> This has been implemented for a number of packages, and policy onward will be to have them either be presented or explicitly opted-out of with good reasoning.
17:38 <Shiz> how's this wording?
17:38 <Shiz> s/presented/present/
17:38 <TemptorSent> presented?
17:39 <TemptorSent> Gotcha :)
17:39 <TemptorSent> Sounds good.
17:39 <TBB> kaniini: you've got a good point in steps going to that direction ending up in a much more complex system to maintain. but on the other hand, a couple of years ago there were no suitable tools for handling that complexity, and things have moved on since then haven't they?
17:39 <kaniini> jirutka: however, to move everyone to a package fs after the point is extremely risky: what if somebody has modified their FS in some way that we do not anticipate?
17:40 <TemptorSent> kaniini: If that's the concern, make it Alpine 4.0 and indicate that manual changes may need to be carried forward.
17:40 <kaniini> jirutka: oops bob edited /usr/bin/some-shell-script, do we wipe out his changes by making it a symlink to /pkgs/some-package-1/usr/bin/some-shell-script
17:41 <kaniini> TemptorSent: not acceptable
17:41 <kaniini> we do not EVER break users
17:41 <kaniini> i should mention this is why jirutka got pissed off at barthalion to begin with
17:41 <jirutka> kaniini: oh really? come on
17:41 <xentec> *hust* cross-compiling *hust* ;)
17:41 <jirutka> kaniini: are you f**king kidding me?!
17:41 <TemptorSent> Hmm, I thought that breaking changes were reserved for major version numbers, like with just about all software these days.
17:42 <Shiz> kaniini: btw, now that i catch you
17:42 <kaniini> jirutka: was his packaging not breaking people's stuff?
17:42 <jirutka> kaniini: what kind of argument is this?!
17:42 <Shiz> opinion about option="!checkroot" that runs check() outside of fakeroot?
17:42 <kaniini> Shiz: +1
17:42 <jirutka> kaniini: have you switched to personal attacks now or what?
17:43 <TemptorSent> How is fakeroot being handled anyway? Using the fakeroot script?
17:43 <kaniini> personal attacks? i am just stating that you got angry at somebody else for breaking the distribution
17:43 <kaniini> facts are not personal attacks
17:43 <Shiz> TemptorSent: it just wraps stuff in the fakeroot binary
17:43 <Shiz> i think that's from debian?
17:43 <Shiz> http://fakeroot.alioth.debian.org/
17:43 <Shiz> this one
17:44 <Shiz> the issue is it's too permissive (as it has to trick software into thinking it's root), but that breaks some test suites
17:44 <TemptorSent> Shiz: Okay, I have a cleaner wrapper for fakeroot that allows you to use it directly in a script, which may be a better option long-term.
17:44 <Shiz> who explicitly test for certain permission stuff
17:44 <kaniini> TemptorSent: the last time we jumped major version it was because we fundamentally changed ABI. but we did not break upgrading the distribution. we made damned sure upgrading from uclibc to musl was safe in all cases.
17:45 <TemptorSent> Fixing the fakeroot library itself will require somewhat more effort, but shouldn't be any major work if semantics need fixing.
17:45 <kaniini> you can't make upgrading from FHS to pkgfs safe
17:45 <kaniini> it is impossible
17:45 <kaniini> you are splitting a single mutable state into multiple sub-states and it is an AI-hard problem
17:46 <TemptorSent> kaniini: I'm not sure it's impossible, but agreed it is more difficult than a migration.
17:46 <kaniini> this type of thinking is what brought us Vista
17:47 <kaniini> do you guys not remember the general market reaction to Vista? hint: it was bad
17:47 <TemptorSent> *lol* No, microsoft brought us Vista :P
17:47 <kaniini> microsoft thinking they could just change the entire OS
17:47 <kaniini> is what caused microsoft to bring us vista
17:47 <TemptorSent> They didn't change much of the OS, just the gui.
17:47 <TemptorSent> That was the problem.
17:47 <kaniini> not true
17:47 <kaniini> memory paging was changed
17:48 <kaniini> the way windows was installed to the filesystem was changed
17:48 <kaniini> some crap called ximage was introduced
17:48 <kaniini> a ton of new apis were introduced, a ton of old apis were removed
17:49 <TemptorSent> Hmm, I seem to recall much of that happened shorly before Vista, but it's been long enough that I'm not sure.
17:49 <kaniini> my point is
17:49 <kaniini> jumping from XP to Vista
17:49 <kaniini> was completely broken for 99% of people
17:50 <kaniini> switching alpine from FHS to pkgfs will have similar fallout regardless of how much mitigation is done
17:50 <Shiz> building llvm right now
17:50 <TemptorSent> XP - XPSP2 was broken as often as not as well.
17:50 <Shiz> vista was a major rearchitecture of the NT base
17:50 <Shiz> btw
17:50 <kaniini> yes
17:50 <kaniini> it was
17:50 <kaniini> and FHS to pkgfs is also a major rearchitecture
17:50 <Shiz> hmm
17:50 <kaniini> that is my point entirely
17:51 <Shiz> i wonder why we build tblgen separately in LLVM
17:51 <kaniini> jirutka: so to be blunt the reason why i am hard no on this is
17:51 <kaniini> jirutka: i see the result being everyone staying on the last version of alpine that did not have that indefinitely
17:51 <TemptorSent> kaniini: Okay, so what do we do to solve the real, existent, and worsening problems? Build multiple chroots?
17:52 <kaniini> jirutka: and then i see 2 years later alpine having to do a security update
17:52 <kaniini> TemptorSent: GO USE NIX
17:52 <TemptorSent> How does that solve the problem on Alpine?
17:52 <kaniini> it solves your problem because now you are using a distribution where you do not have this perceived problem
17:53 <kaniini> 99% of alpine users are not having worsening problems from FHS, sorry they are just not
17:53 <TemptorSent> kaniini: It's not a perceived problem, it's a real, significant, and painful problem for MANY people.
17:54 <kaniini> you are wanting things that alpine simply cannot deliver. sorry about that, really.
17:54 <kaniini> use something that can deliver those things.
17:54 <TemptorSent> Package A only works with an older revision of somelib.so, Package B only works with a new revision of somelib.so, both of which unfortunately have the same major version.
17:54 <kaniini> don't try to force a breaking change for 99% of users because you want multiple versions of a package installed
17:54 <kaniini> THEN REBUILD PACKAGE A
17:55 <TemptorSent> It's impossible to support the newer rev in some cases (yes, REALLY)
17:55 <kaniini> then fix package A
17:55 <TemptorSent> Trying to build GIS tools is one significant area of pain.
17:56 <TemptorSent> Yeah, don't I wish -- deps on proprietary libs aren't so fixable.
17:56 <TemptorSent> JP2000/ECW/MrSID being one set of cases.
17:57 <TemptorSent> Worse is that some tiff libs must be built with explicit support for higher bit depths, which then breaks some other packages.
17:58 <TemptorSent> The only viable solution for those is to have indepentent libs for each and make sure the right one gets linked.
18:00 <kaniini> alpine does not support proprietary software, so your argument is moot
18:00 <TemptorSent> Also, supporting glibc where-needed/as-needed is dependent on having distinct paths if we want to ever support it sanely.
18:00 <TemptorSent> kaniini: Then you're killing the ability to use Alpine in multiple industries.
18:01 <kaniini> TemptorSent: they are killing it by not providing musl versions of their libraries.
18:01 <TemptorSent> kaniini: There are no open-source alternatives for the encoders/decoders required.
18:01 <kaniini> TemptorSent: that's unfortunate
18:02 <kaniini> it's still not our problem
18:02 <TemptorSent> Look up MrSID and ECW
18:02 <kaniini> why?
18:02 <kaniini> it's not our problem
18:03 <TemptorSent> If it's not our problem, then whose is it?
18:03 <kaniini> if those vendors wish to support alpine, then they would provide binaries that work on alpine
18:03 <TemptorSent> If we can't support industry standard file formats, WE have a problem.
18:03 <Shiz> do we?
18:04 <kaniini> no, whoever wishes to consume those file formats on alpine, has a problem
18:04 <kaniini> and they can solve it by not using alpine
18:04 <kaniini> incidentally docker makes that pretty easy
18:04 <TemptorSent> Well, it's supported on other major distributions.
18:04 <TemptorSent> Bloody hell, docker just to run gdal? That's nuts.
18:04 <kaniini> no, it is supported on GNU/Linux distributions
18:04 <kaniini> alpine isn't a GNU/Linux distribution, now is it?
18:06 <TemptorSent> lizardtech offers a SDK for MrSID free of charge for multiple operating systems.
18:06 <TemptorSent> If we ask nicely, they might be willing to support musl directly.
18:07 <asie> couldn't a musl-based static library/binary set work on glibc as well? just not the other way around?
18:07 <TemptorSent> Now to compress MrSID files, you need to install a SDK with a key, which has the same names IIRC.
18:07 <asie> well, the other way around too, but that might have licensing issues
18:08 <TemptorSent> Here's our lib conflict -- same lib, same version even, different api availability.
18:08 <Shiz> asie: yes, it would
18:09 <TBB> (damn, that old c64 guy Mr SID surely doesn't like some proprietary company stealing both his nickname and the .sid file extension...)
18:10 <TemptorSent> *lol*
18:13 <kaniini> blah blah blah
18:13 <kaniini> stop trying to do things with alpine it cannot do
18:13 <kaniini> you are just going to be in for a world of hurt
18:13 <kaniini> yes, pkgfs would be lovely to have, if we were starting from scratch
18:13 <TemptorSent> More like stop trying to make alpine do things it couldn't do before it sounds..
18:14 <kaniini> but the idea of migrating all installs to pkgfs
18:14 <TemptorSent> Okay, forget the pkgfs -- how do I solve my actual problems?
18:14 <kaniini> use docker
18:14 <TemptorSent> Docker is not a solution -- I still need something running UNDER it, right?
18:14 <kaniini> if you need glibc and libc6-compat is not enough
18:14 <kaniini> use docker
18:14 <kaniini> with like debian
18:14 <kaniini> or something
18:15 <Shiz> hmm
18:16 <Shiz> any way to get the current kernel flavor through apk?
18:16 <TemptorSent> Shiz: Rather than using uname -r?
18:17 <Shiz> yes
18:18 <TemptorSent> Shiz: I don't know of any apk magick per-se.
18:19 <TemptorSent> There are files installed in /usr/share/kernel/*/kernel.release where * is the flavor...
18:19 <Shiz> i wish there was an easy way to install a package matching your installed kernel flavor(s)
18:20 <TemptorSent> Yeah, I have that handled in my kerneltool -- it automagically determines the flavor and installes the flavored package if found, otherwise tries unflavored.
18:20 <rdutra> question: I am booting a ppc64le ISO (built it using ./mkimage.sh) and in the login console I tried "root" user but I got an error message "Login incorrect". Is the default user really "root" or maybe I am missing something?
18:20 <Shiz> i think this is something that should be handled in the apkbuilds somehow
18:21 <kaniini> yes, it is really root
18:21 <Shiz> e.g.
18:21 <Shiz> if i do
18:21 <Shiz> # apk add wireguard
18:21 <Shiz> i ideally want it to install wireguard-hardened as it infers from me having linux-hardened installed
18:22 <kaniini> Shiz: that is what i intend to fix when i fix all kernel-related APKBUILDs
18:22 <Shiz> :)
18:22 <TemptorSent> Shiz: Yeah, one problem with that is you have both kernel modules and userspace with the same name (zfs-hardened and zfs)
18:22 <Shiz> TemptorSent: sure
18:22 <kaniini> maybe it can be the first feature for my new alpine fork
18:22 <Shiz> you can call it zfs-modules
18:22 <Shiz> doesn't really matter
18:22 <TemptorSent> Exactly.
18:22 <kaniini> (which trust me, if i have to deal with pkgfs migration i am forking)
18:22 <TemptorSent> And it should install the modules for ALL kernels using that.
18:23 <kaniini> i want that to be very well understood, especially by jirutka
18:24 <kaniini> it's the migration i have a problem with, not with having a distribution that has that design
18:24 <kaniini> and i would even be alright with having code in apk-tools to support that type of distribution
18:24 <kaniini> but i cannot support fundamentally changing alpine in that way because the risks are way too high
18:24 <Shiz> i think that is fine
18:25 <Shiz> it may be worth investigating an alternative version of alpine where this happens
18:25 <kaniini> if we break a ton of installs then everything we have done so far is for nothing because the momentum we have is lost
18:25 <Shiz> doesn't have to be The Distribution Called Alpine
18:25 <TemptorSent> kaniini: Okay, how about we look at this the other way - fork a variant that supports pkgfs and allow migration for those who want it.
18:25 <Shiz> anyway
18:25 XgF joined
18:25 <kaniini> TemptorSent: yes, that is fine. i am fine with that
18:26 <Shiz> :)
18:26 <TemptorSent> kaniini: Okay, cool :)
18:26 minimalism joined
18:27 <kaniini> TemptorSent: what i am not fine with is somebody going "apk upgrade --update --available" and then winding up with pkgfs and their entire setup completely broken
18:28 <kaniini> i will never be fine with that, regardless of how safe it is claimed to be
18:29 <kaniini> and the second that becomes a likely scenario is the second i fork alpine for the good of alpine
18:30 <TemptorSent> kaniini how about allowing something like 'apk migrate' to a new install?
18:31 <TemptorSent> No automatic upgrade would change any structure, and existing packages could be installed in the new install, along with configs.
18:34 <kaniini> what part of "AI hard problem" did you not get
18:34 <TemptorSent> Anyway, it's a solvable problem so long as we don't try to automatically upgrade unconditionally, and supporting both installation types from a common set of packages shouldn't be terribly difficult.
18:34 <kaniini> apk-tools can be adapted to easily handle either scenario
18:34 <TemptorSent> How is installing the same set of packages and copying their config files AI-hard?
18:35 <kaniini> TemptorSent: people go in and modify the files that are installed
18:35 <kaniini> TemptorSent: we want to kepe those modifications in tact
18:36 <kaniini> so here's what i propose
18:36 <TemptorSent> Right, and we can keep them (as long as we have checksums?), but if they run a migration, we warn them that manual changes may need attention.
18:36 <kaniini> if you install alpine and you configure apk-tools
18:36 <kaniini> to use a pkgfs layout
18:36 <TemptorSent> Nothing breaking happens automatically, and nothing changes in the existing install.
18:36 <kaniini> then it will give you that layout
18:36 <kaniini> otherwise
18:36 <kaniini> it will continue as it is now
18:37 <TemptorSent> That would be just fine with me.
18:37 <kaniini> and then if they change the layout to be pkgfs in the future
18:37 <kaniini> they can do this apk migrate thing
18:37 <kaniini> to get pkgfs
18:37 <kaniini> jirutka: is this fine with you? ^^^^^^
18:38 <kaniini> i will work on the layout aspect for 3.7
18:38 <kaniini> if this is fine
18:38 <kaniini> my thing is really simple
18:38 <kaniini> people who have pre-existing installs
18:38 <kaniini> are not going to be happy
18:38 <TemptorSent> I like the concept of apk being able to handle arbitrary layouts using the same core.
18:38 <kaniini> if they are migrated to pkgfs
18:39 <TemptorSent> Agreed - unexpected breakage is to be avoided.
18:39 <kaniini> and i do not think the gain is worth pissing off every alpine user ever
18:39 <kaniini> because they swallowed an upgrade they couldn't handle
18:39 <kaniini> consider unattended upgrades too
18:39 <kaniini> say you have a cron which apk upgrades the box nightly
18:39 <kaniini> (you can install a package which does this)
18:40 <kaniini> and then the next day
18:40 <kaniini> your system is hosed
18:40 <TemptorSent> Right, that's actually my biggest concern personally -- I have machines that I have no physical access to that auto-update.
18:40 <kaniini> by your apk upgrade cron
18:40 <kaniini> but yet i haven't thought this through
18:40 <kaniini> :D
18:40 <TemptorSent> That's why I was hit so hard by the apk bug -- I suddenly started having unusable machines.
18:41 <kaniini> then why on earth
18:41 <kaniini> would you advocate for pkgfs?
18:41 <kaniini> :D
18:41 tty`_ joined
18:41 <TemptorSent> So given that it would only be used for new installations or explicit migrations, pkgfs is sane IMHO. Expecting automatic upgrade to it, not so much.
18:42 <kaniini> yes, but that was what was originally proposed
18:42 <kaniini> and that is my problem
18:43 <kaniini> there are pros and cons to both
18:43 <kaniini> we should support both
18:43 <TemptorSent> I don't recall having an automatic upgrade path being part of the proposal TBH
18:43 <TemptorSent> Agreed - supporting both is preferable, even supporting mixed usage may be desirable in certain cases.
18:43 <kaniini> TemptorSent: that is the only way we could do it and have it be default
18:44 <kaniini> TemptorSent: jirutka used explicit language such as "supporting FHS is painful" etc
18:44 <TemptorSent> kaniini: Once stabilized, it could be the default for all NEW installs if it proves to work properly.
18:44 <kaniini> sure, that is fine
18:44 <kaniini> as long as you can choose FHS
18:45 <TemptorSent> And he's right, it IS painful to support LFHS, especially in cases that have dep hell.
18:46 <TemptorSent> So if we at least have a solution that allows for non LFHS usage, even if it requires manual migration, it can solve those problems where they exist.
18:46 <kaniini> sure but for typical deployments you just made the deployment a lot more complex
18:46 <kaniini> i dont think it is wise to throw out something that people know just because it isn't optimal for some edge cases
18:47 <TemptorSent> It's not just edge cases unfortunately, it's just about any case where multiple versions must be supported.
18:47 <TemptorSent> Many packages essentially handle it themselves (postgresql for instance uses a self-contained directory structure)
18:47 <kaniini> 99% of the time this is not a thing. citation: nobody asks about it on #alpine-linux or mailing lists.
18:48 <TemptorSent> Multiple GCC versions are similar.
18:49 <kaniini> jirutka: ????????????
18:49 <TemptorSent> Right now, those are kluged and fragile constructs which break if you look at them sideways.
18:50 <kaniini> i'm just trying to figure out if this apk layout proposal of mine will solve jirutka's concerns
18:51 <kaniini> so that we can avoid having to destroy alpine over it
18:51 <TemptorSent> At the very least, we need to find a sane way of specifying lib paths per lib/binary for the loader to fix the actual problem.
18:51 <kaniini> most likely,
18:52 <kaniini> what we would do is have custom ELF interpreter
18:52 <kaniini> for the stubs
18:52 <kaniini> instead of hardlinks
18:52 <kaniini> which would provide that type of functionality
18:52 <TemptorSent> Thats exactly what I'm thinking.
18:52 <kaniini> which you need anyway to do pkgfs properly
18:52 <kaniini> sorry but DJB gets it wrong sometimes
18:53 <Shiz> i don't want to read any of djb's C code
18:53 <kaniini> but hey i haven't thought about this at all
18:53 <Shiz> or use execline for that matter
18:53 <TemptorSent> Or modifying the linker logic to check an xattr perhaps.
18:53 <Shiz> :P
18:53 <kaniini> TemptorSent: yes, that is possibly interesting
18:54 <kaniini> an ld_library_path xattr
18:54 <TemptorSent> It would be both sane, and a good use of xattrs.
18:54 <TemptorSent> Eliminating the problem of keeping the stub and binary paths synced.
18:55 <kaniini> yes, that would work nicely.
18:55 <kaniini> downside: alternatives support would have to live in apk
18:56 <TemptorSent> Not necessarily - there's not reason a general tool couldn't handle that.
18:56 <kaniini> because then you're reconfiguring the emulated FHS
18:56 <kaniini> if i want
18:56 <kaniini> foobar-1.0 to be the selected package in the emulated FHS
18:57 <kaniini> then it needs to change the symlinks
18:57 <kaniini> so it is faster to just have it in apk
18:58 <TemptorSent> Hmm, possibly - if it fits well in apk, I suppose that's fine too.
18:58 <Shiz> @kaniini │ an ld_library_path xattr
18:58 <Shiz> doesn't -rpath exist for this purpose
18:58 <TemptorSent> rpath is compile time IIRC, possibly changed using elftools?
18:58 <kaniini> Shiz: yes, but we do not want to edit the binaries being installed
18:58 <Shiz> you can use patchelf
18:58 <Shiz> okay
18:58 <kaniini> Shiz: yes, but we do not want to edit the binaries being installed
18:59 <kaniini> if you checksum a binary, it should match what is in apk
18:59 <TemptorSent> Also, the xattr approach would allow us more flexability than -rpath, including pinning a specific version of a lib by checksum if we wanted to.
19:00 <kaniini> by using xattrs, we can attach additional rpaths without editing the binary
19:00 <kaniini> and the change to musl would be very minor
19:01 <TemptorSent> This would also probably allow proper glibc foreign support if we do it right.
19:01 <kaniini> no, it would not
19:01 <kaniini> glibc is a different animal entirely
19:01 <TemptorSent> Why not?
19:02 <kaniini> any binaries that need glibc also need to be built against glibc-linked libraries
19:02 <TemptorSent> We'd have to make a modified ld.so, but thats about it.
19:02 <kaniini> pkgfs will not help you there
19:02 <TemptorSent> Just toss glibc-related packages in their own directory and load the appropriate lib using the xattr.
19:03 <ncopa> fwiw, i actually have pretty strong opinions re FHS, but now is totally wrong time to discuss it
19:03 <kaniini> ncopa: i do not like FHS either
19:03 <kaniini> ncopa: i just do not like breaking everyone's stuff
19:03 <Shiz> i still think we can flesh this out later
19:03 <Shiz> and focus on 3.6 now :)
19:03 <TemptorSent> ncopa: Yeah, we're getting ahead of ourselves here, but at least I think we're finding some solutions.
19:04 <kaniini> i rather find solutions now than have somebody else find solutions i find undesirable later and wind up having to fork alpine to dodge them
19:04 <ncopa> i agree with Shiz
19:04 <ncopa> drop everything else
19:05 <scadu> especially fighting :x
19:05 <ncopa> this FHS idscussion is not productive
19:05 <ncopa> fighting is not productive
19:06 <kaniini> breaking peoples systems is not productive either
19:06 <TemptorSent> I think we can summerize with this: Don't automatically break peoples shit :)
19:06 <Shiz> yes, but we are not anywhere close to start making a decision on the FHS stuff
19:06 <Shiz> so nothing's going to happen either way until after 3.6
19:06 <Shiz> so let's finish 3.6 first
19:06 <Shiz> :)
19:06 <ncopa> kaniini: exactly. lets make sure we dont break things for the 3.6 release
19:07 <asie> just keep a box called "ideas which sound neat but will break people's shit"
19:07 <asie> and keep it around for i don't know alpine 4.0 or something
19:07 <scadu> +9000
19:07 <asie> once you start breaking people's shit, break it once, break it a lot, but break it well.
19:07 <kaniini> i pulled an all-nighter to ensure linux-hardened change did not break people
19:07 <asie> so you don't have to break again
19:07 <ncopa> asie: +1
19:07 <TemptorSent> asie: +1
19:07 <kaniini> i like the apk layout idea
19:07 <asie> but assuming alpine will never break anyone's system ever after an upgrade is misguided
19:07 <asie> eventually something will happen that will unavoidably break things anyway
19:08 <kaniini> asie: it is policy
19:08 <asie> yes, but unexpected things may happen
19:08 <TemptorSent> asie: In that case, it shouldn't happen AUTOMATICALLY, it should require user-intervention to initiate a breaking change.
19:08 <kaniini> sure, but that is different than "lol we should just change everything yolo"
19:08 <asie> that is correct
19:08 <ncopa> we will not change everything
19:08 <asie> TemptorSent: yes, it should require user intervention, ideally with an explanation of what exactly is being broken and, even more ideally, how to fix it
19:08 <skrzyp> well
19:09 <skrzyp> https://a.doko.moe/woefho.jpg
19:09 <TemptorSent> exactly asie.
19:09 <kaniini> ncopa: moving from FHS is basically changing everything. i like apk layout idea because it allows supporting either configuration.
19:09 <TemptorSent> Which implies a major version number change by standard semantics.
19:09 <ncopa> kaniini: i know, but now is not the time to talk about it
19:10 <TemptorSent> kaniini: flexible apk-tools is a win.
19:10 <skrzyp> 21:07 < asie> once you start breaking people's shit, break it once, break it a lot, but break it well.
19:10 <skrzyp> #whatdoespoetteringsaid
19:10 <ncopa> lol
19:10 <scadu> well, we are not going everywhere atm, so I don't know why some shit exploded here few minutes ago. it's quite sad that we lack of human resources, but something is still burning
19:10 <scadu> because why not
19:11 <asie> scadu: because alpine-devel is a diverse place where 140 people have 140 visions of how a linux distro should work
19:11 <asie> and the 141st is a bot
19:11 <TemptorSent> *LOL*
19:11 <asie> actually, that's incorrect
19:11 <scadu> asie: where you see 140 active people?
19:11 <TemptorSent> Better check the bot's opinion too :)
19:11 <asie> scadu: being inactive doesn't mean they don't have a vision of how a linux distro should work
19:11 <* kaniini> mutters and prepares a fork anyway
19:11 <asie> in addition, even if there's people in here without a vision
19:11 <asie> i bet many of us have multiple
19:11 <asie> so it adds up in the end
19:11 <scadu> asie: yep, but you don't have to shit each other
19:12 <asie> scadu: that is correct, but people can get really defensive about potential threats... and "breaking user installations" is a potential threat
19:12 <asie> i do agree that half of this conversation was unnecessary flinging
19:12 <skrzyp> these Krtcek memes are actually accurate
19:12 <skrzyp> https://a.doko.moe/eypsds.jpg
19:12 <kaniini> half of the conversation was jirutka calling me a dickhead
19:12 <kaniini> to be honest
19:13 <Shiz> i can confirm that my bot has strong opinions on linux distros
19:13 <Shiz> anyway
19:13 <Shiz> 3.6
19:13 <Shiz> ncopa: did you see my notes?
19:13 <ncopa> nope
19:13 <ncopa> they drowned in the daily drama
19:13 <scadu> much surprise
19:13 <tmh1999> Shiz : mind update again with some discussed changes ?
19:14 <Shiz> yes i'll upload a new version
19:14 <TemptorSent> What tmh1999 said :)
19:14 <tmh1999> old one : https://txt.shiz.me/ZjBhMWM3YT.txt
19:14 <Shiz> https://txt.shiz.me/Y2RhOTA1Mm
19:14 <Shiz> improved one
19:15 BitL0G1c joined
19:16 <TemptorSent> re -grsec -> -hardened -- you might mention 'kernel related packages' rather than 'packages'
19:16 <skrzyp> https://a.doko.moe/zdtemr.jpg
19:16 <skrzyp> i think I'm not gonna stop :D
19:17 <asie> i think you eventually are, coinciding with the moment you step on someone's nerves
19:17 <Shiz> lol
19:17 <asie> can we get #alpine-drama?
19:17 <skrzyp> asie: that's not serious business
19:17 <TemptorSent> Also, was that SHA1 -> SHA512 propigated to the .apk format?
19:17 <scadu> asie: erm, this is not -drama? wrong channel then
19:17 <skrzyp> people will still drama, docker will be docker
19:18 <scadu> coconut will be coconut
19:18 <asie> okay, but can we really focus on 3.6 here now? and development? memes can go elsewhere
19:18 <Shiz> TemptorSent: nyet
19:18 <kaniini> can we get 3.6 out the door
19:18 <Shiz> well i wrote relnotes above
19:18 <Shiz> feel free to comment on them
19:18 <TemptorSent> Shiz: Okay - that's the big open issue I guess.
19:18 <kaniini> Shiz: they look fine to me
19:18 <skrzyp> Shiz: is the zfs support finished yet? xD
19:19 <Shiz> I'm not sure what the status on zfs stuff it
19:19 <skrzyp> I mean, relnotes are sometimes too enthusiarstic
19:19 <Shiz> maybe TemptorSent does
19:19 <TemptorSent> kaniini: What is needed to update the .apk checksums to use sha512?
19:19 <skrzyp> there was a "zfs support on roofs" about 6 months ago in relnotes
19:19 <skrzyp> and no one actually tested that
19:19 <kaniini> TemptorSent: abuild
19:19 <kaniini> TemptorSent: i will do it in 3.7
19:19 <skrzyp> I came up with some bug reports, no one bothered
19:19 <Shiz> afaik it has been possible for the rootfs but not the bootfs
19:19 <TemptorSent> kaniini: Oh, that's held for 3.7 -- gotcha.
19:19 <Shiz> or something like that
19:20 <Shiz> but i don't know the status of zfs
19:20 <TemptorSent> ZFS works fine, but the installer tools don't so much.
19:20 <kaniini> ZFS is terrifying to me
19:20 <TemptorSent> The problem is that ZFS handles mounts differently than standard mount
19:20 <kaniini> on freebsd and linux i have had major corruption issues with L2ARC
19:21 <kaniini> so i gave up on trying to use ZFS on root with alpine :P
19:21 <TemptorSent> With ZFS, createing a new dataset creates the directory, rather than mounting to an existing mount point.
19:21 <TemptorSent> So proper installer support will require a bit of work to abstract the directory creation.
19:22 <TemptorSent> That said, it works fine if you manually setup the directory structure.
19:22 <Shiz> do we have any 'breaking' changes other than the grsec -> hardened rename?
19:23 <TemptorSent> Hmm, possibly GCC revision as a breaking change.
19:24 <TemptorSent> Also php7 is a breaking change for some I believe.
19:24 <TemptorSent> php5 finally got the axe, right?
19:26 <TemptorSent> You could also note the fix for apk re: warnings ->stderr
19:27 <Shiz> did we end up removing php5 entirely?
19:27 <TemptorSent> I'm not sure -- there was talk of it at one point..
19:28 <TemptorSent> But it's not the default any longer IIRC, which may break things.
19:29 <TemptorSent> okay, it looks like php5 is now packaged as such, with both php5 and php7 in community
19:29 <TemptorSent> So a note that those requiring php5 need to install php5 packages should do it.
19:29 <TemptorSent> But that's just going by apk policy
19:31 <TemptorSent> I'm not sure if php5 is intended to remain supported long term or if it's going to the deprecation pile.
19:33 <kaniini> php5 is supported for now, deprecated in 3.8
19:33 <kaniini> most likely
19:33 <TemptorSent> Hmm, I need to update my aports repo, but I'm seeing problems with php7 -- it's in both testing and community.
19:34 <ncopa> Shiz: dowe need mention apk there? it sounds like the apk fix is a breaking change
19:34 <Shiz> that is already mentioned, no?
19:34 <Shiz> Noteworthy fixes and breaking changes
19:34 <Shiz> -------------------------------------
19:34 <Shiz> * Bugs in apk(8) dependency handling during upgrades have been fixed;
19:34 <Shiz> or did you mean something else?
19:34 <ncopa> that one
19:34 <ncopa> it sounds like its a braking change
19:34 <Shiz> that's why it's under the breaking changes heading
19:34 <Shiz> :P
19:35 <ncopa> but it is not a breaking change?
19:35 <kaniini> it's not a breaking change though
19:35 <Shiz> right
19:35 <kaniini> it was broken before, then we fixed it
19:35 <TemptorSent> Okay, looks like the php7 was culled from testing.
19:35 <kaniini> it's the opposite of a breaking change :P
19:35 <Shiz> yeah i think i listed it there because of 'noteworthy fix'
19:35 <Shiz> but i can separate that out
19:35 <ncopa> do we need to mention it?
19:36 <TemptorSent> Yes - noteworthy fix.
19:36 <ncopa> how many was affected by it?
19:36 <Shiz> at least kaniini and TemptorSent
19:36 <Shiz> :P
19:36 <ncopa> how many was aware that it was a problem?
19:36 <TemptorSent> Well, considering it keeps us from destroying just about every alpine box on upgrade, I think it's important :)
19:36 <kaniini> i don't think it is really notable
19:38 <TemptorSent> Preventing massive unexpected breakage is notable IMHO.
19:38 <kaniini> not really -- it's what we should be doing every day as a distribution
19:39 <ncopa> i agree with kaniini
19:39 <TemptorSent> The fact that only a few of us were noticing it biting us in other strange ways doesn't reduce the importance of mitigating the future disaster.
19:39 <kaniini> https://media.makeameme.org/created/well-congrats-you.jpg
19:39 <kaniini> all i have to say about that being notable
19:39 <ncopa> i doubt many people noticed it was a problem
19:39 <TemptorSent> But it's relnotes, so whatever works.
19:40 <Shiz> I'll omit it then
19:40 <TemptorSent> If I was a user who had been experiencing strange behavior, a note that it was fixed would be nice.
19:40 <ncopa> the shorter we can make it the better
19:40 <TemptorSent> But it's not a breaking change, it's a bugfix.
19:41 <kaniini> it is technically interesting, but to an end user it is going to come off more like "holy shit the package manager was broken, maybe canonical is right and i shouldn't use alpine"
19:41 <kaniini> do we really want to give canonical more FUD?
19:42 <TemptorSent> Word it 'Improved apk resolver to better handle corner cases during upgrade."
19:42 <kaniini> shit has gotten real with them, they are super salty over what alpine has done to ubuntu server
19:42 <kaniini> they literally blog about how shit alpine is
19:42 <Shiz> do we have anything to add re:noteworthy /new/ packageS?
19:42 <Shiz> I have rust and ghc listed
19:42 <kaniini> such as here: https://insights.ubuntu.com/2016/02/10/docker-alpine-ubuntu-and-you/
19:42 <Shiz> any other big ones?
19:42 <Shiz> over a year ago
19:42 <Shiz> :p
19:43 <TemptorSent> Weren't there some X updates recently as well?
19:43 <kaniini> yes, they have been salty for quite a while shiz
19:43 <kaniini> :)
19:44 <kaniini> if you actually follow this stuff you'll observe canonical people spend non-trivial amounts of time spreading FUD about alpine, and recently docker as well (likely to punish them for their decision)
19:44 <kaniini> on things like hacker news, etc
19:44 <kaniini> whenever anything gets posted about alpine or docker, they show up
19:44 <kaniini> every time
19:44 <kaniini> so i think our release notes should be careful not to give them ammo
19:45 <kaniini> when in reality the bugfix is not notable anyway
19:46 <kaniini> i guarantee you, putting that in the release notes will result in them jumping on it and being like "haha apk hosed people's systems"
19:47 <kaniini> (i know we deleted it from the release note, i am just saying that from a PR perspective we need to be careful about mentioning explicit bugfixes as line items)
19:47 <scadu> kaniini: you don't know if someone from canonical isn't watching -devel :p
19:47 <kaniini> they probably are
19:48 <* Shiz> runs $ git diff --name-only --diff-filter=A origin/3.5-stable | grep APKBUILD | grep -v 'testing|unmaintained' to find new interesting builds
19:48 <kaniini> but at least then it comes off as kooky conspiracy theory rambling instead of "look at this thing in their release notes! teehee!"
19:48 <kaniini> you know what i mean?
19:48 <scadu> kaniini: yep
19:48 <Shiz> hmm
19:48 <Shiz> emscripten maybe?
19:48 pbregener joined
19:48 <scadu> kaniini: everything's on plate :p
19:49 <ncopa> kaniini i think we are all done with it
19:49 <kaniini> Shiz: i think emscripten is worth adding
19:49 <kaniini> Shiz: can you pastebin the latest?
19:49 <Shiz> yes
19:49 <kaniini> something about the llvm was bugging me
19:49 <Shiz> https://txt.shiz.me/NDdhMTlhY2
19:50 <kaniini> * The `llvm` package is now provided by the versioned `llvm<X>` package that is selected as default LLVM;
19:50 <Shiz> yeah it's not terrifically worded
19:50 <kaniini> i'm not sure about the wording here
19:51 <Shiz> * The `llvm` package is now provided by a versioned `llvm<X>` package;
19:51 <Shiz> maybe just this?
19:51 <kaniini> - the LLVM package has been provided by a versioned `llvm<X>` package, which is presently `llvm4`
19:52 <Shiz> how's this: * The `llvm` package has been changed to be provided by a versioned `llvm<X>` package, which is presently `llvm4`;
19:52 <Shiz> i want to make clear that it's about the literal package called `llvm`
19:52 <Shiz> :p
19:54 <kaniini> sure
19:54 <kaniini> works for me
19:54 <Tsutsukakushi> reading the CoCk thread on the ML...
19:54 <kaniini> the what?
19:54 <Tsutsukakushi> >and disparaging remarks of any kind,
19:54 <Tsutsukakushi> stuff like this is what makes CoCks suck so much
19:55 <Tsutsukakushi> sometimes people use bad language in a heated argument
19:55 <TemptorSent> I'd simplify that slightly, to: The 'llvm' package is now provided by...
19:55 <Tsutsukakushi> this might have a chilling effect on people in such arguments
19:56 <Tsutsukakushi> ^7heo:
19:56 <kaniini> Tsutsukakushi: thank you for your input, but we are trying to get 3.6 out the door. can you reply to the ML thread instead?
19:57 <Tsutsukakushi> my mail setup is kind of fucked currently...
19:57 <kaniini> that is unfortunate
19:57 <Tsutsukakushi> it is
19:57 <Tsutsukakushi> and really annoying too
19:57 <Shiz> https://txt.shiz.me/OGQxYWVlYm
19:58 <Shiz> btw, commit stats
19:58 <Tsutsukakushi> tho it has made me use gmane quite a bit
19:58 <Tsutsukakushi> so that's quite nice
19:58 <^7heo> Tsutsukakushi: yes. But at the same time, the goal of the CoC is to avoid people coming over and insulting others.
19:59 <asie> ^7heo: he's just biased. plenty of good CoCs, plenty of bad CoCs.
19:59 <^7heo> Tsutsukakushi: so... it's kinda difficult to make a one-size fits all without being explicit about everything.
19:59 <asie> the very part where he says "CoCk" shows that he is unlikely to be reasoned with in this regard
19:59 <Tsutsukakushi> insulting others during a heated debate is not done out of malice
19:59 <^7heo> asie: CoCs are mostly thrusting everywhere
19:59 <Shiz> ML, please
19:59 <Shiz> or at least, not here right now
19:59 <kaniini> ^
19:59 <^7heo> right, offtopic, people.
19:59 <Tsutsukakushi> but because you are frustrated when you think people don't understand what you are saying
19:59 <asie> nope, -offtopic it is
20:00 <kaniini> Tsutsukakushi: please drop it
20:00 <Shiz> ima take a look at b.a.o
20:00 <algitbot> https://bugs.alpinelinux.org
20:00 <Shiz> to see what needs to be done still
20:00 <Tsutsukakushi> kaniini: i had written that message when you said anything
20:00 <Tsutsukakushi> before*
20:02 <kaniini> Shiz: xenqemu ifuncs regression, i already have a fix for it
20:02 <Shiz> i wish i could filter for !resolved
20:02 <Shiz> :|
20:04 <xentec> Shiz: Add filter > Status > is not: resolved
20:04 <Shiz> guess i found something that owrked
20:04 <Shiz> xentec: yeah but that also catches closed
20:04 <xentec> yep
20:04 <Shiz> so bleh
20:04 <TemptorSent> nightmared: #7285 - Once solution would be to simply provide the zfs modules in the initramfs using an appended cpio
20:04 <algitbot> Bug #7285: Kernel modules on USB key - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7285
20:04 <TemptorSent> nightmared: #7285 - Once solution would be to simply provide the zfs modules in the initramfs using an appended cpio
20:04 <algitbot> Bug #7285: Kernel modules on USB key - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7285
20:04 <TemptorSent> WTF?!?!
20:05 <TemptorSent> That's RE: not nightmared
20:07 <TemptorSent> That should avoid the legal issue, while still allowing zfs to be used from the initramfs environment
20:08 <kaniini> 3.7
20:08 <TemptorSent> Why? It doesn't require anything other than adding a file to the image.
20:09 <TemptorSent> A single cpio.gz with the contents of /lib/modules from the zfs-hardened package
20:09 mwbrown joined
20:14 <kaniini> because we are already in feature freeze
20:15 <TemptorSent> kaniini: Right, and? No new feature here, just packaging.
20:15 <TemptorSent> kaniini: No other files need to be changed at all, just one added to the boot dir.
20:16 <TemptorSent> kaniini: The user can add the additional append themselves during boot.
20:32 <kaniini> clandmeter: ping
20:32 <clandmeter> pong
20:32 <kaniini> clandmeter: can you give Shiz write access to the bug tracker so he can close bugs
20:33 <kaniini> Shiz: can you tell clandmeter what your login is so he can do that
20:33 <Shiz> it's shiz
20:33 <Shiz> or hi@shiz.me
20:33 <kaniini> sweeeeeeet
20:33 <Shiz> forgot if email was used
20:38 <clandmeter> Shiz, restart your computer and try
20:38 <Shiz> i'll just update systemd that's the same right
20:38 <clandmeter> yes, just kill pid 1
20:39 BitL0G1c joined
20:39 <Shiz> thanks, works :)
20:45 <rdutra> kaniini: Shiz: is there any link/documentation that describes the steps that run after "setup-alpine" or explaining the entire install process? I found https://wiki.alpinelinux.org/wiki/Installation but did not find this information
20:45 <rdutra> btw. I am booting alpine ppc64le and using qemu
20:46 <kaniini> that recent commit about console=hvc0 doesnt seem right to me
20:46 <TemptorSent> I don't believe it's documented as such rdutra.
20:46 <kaniini> what if we want boot alpine on bare metal
20:46 <TemptorSent> rdutra: What are you running into?
20:47 <Shiz> kaniini: should we disable GRKERNSEC_SYSFS_RESTRICT before branching 3.6?
20:47 <Shiz> there seem to be MESA issues with it
20:47 <kaniini> Shiz: i'm okay with it. send me an mbox and i will push it
20:48 <Shiz> gotcha
20:48 <Shiz> post-3.6 we might look into modifying it to be a sysctl
20:48 <TemptorSent> Can it be enabled through sysfs after the fact?
20:48 <Shiz> no
20:48 iamthemcmaster joined
20:48 <Shiz> it has no sysctl :(
20:48 <TemptorSent> Drat.
20:48 <TemptorSent> Kernel command line option?
20:49 <TemptorSent> I haven't looked at that specific chunk yet.
20:50 <TemptorSent> If not, we probably need to change that or it's going to be worthless.
20:50 <rdutra> TemptorSent: It stops at: https://hastebin.com/raw/uniwoxalov
20:51 <rdutra> TemptorSent: I am not sure if it is correct, as I do not know the steps it run
20:52 <TemptorSent> rdutra: Hmm, that's an odd place to stop.
20:53 <rdutra> TemptorSent: the setup-alpine script is part of aports repo?
20:53 <Shiz> hmm
20:53 cyteen joined
20:53 <TemptorSent> Um, not sure right off...
20:53 <TemptorSent> one sec.
20:54 <Shiz> it's part of alpine-conf
20:54 <Shiz> https://github.com/alpinelinux/alpine-conf/blob/master/setup-alpine.in
20:54 <TemptorSent> Thanks Shiz
20:55 <rdutra> thanks
20:56 <rdutra> TemptorSent: not sure if in x86_64 the setup-alpine is working fine and actually is the first time I run this command
20:56 <TemptorSent> rdutra: You might try running the individual setup commmands manually
20:57 <TemptorSent> rdutra: Try setup-sshd
20:58 <rdutra> TemptorSent: yeah, I will see in which part of the script the run stopped
20:59 <rdutra> gotta go now, thanks!
20:59 <TemptorSent> rdutra: I'm going to take a SWAG on setup-disk
20:59 iamthemcmaster joined
21:17 NightKhaos_ joined
21:40 <TemptorSent> Is there any chance we could add an all-archs key to the master alpine keychain an sign the keys package with that, eliminating a very irritating cross-platform target-root chicken and egg problem?
21:41 <TemptorSent> Theoretically, multiple key signatures should be supportable, but I don't know how apk handles trust chains.
21:50 blahdodo joined
22:01 fekepp joined
23:19 brentous joined
23:22 <brentous> ncopa & clandmeter: I'm getting "HTTP/1.1 503 Backend is unhealthy" when trying to pull the APKINDEX from the CDN. I was told I should let you 2 know.
23:23 <Shiz> temp fix is changing mirrors to nl.alpinelinux.org
23:23 <xentec> dl-cdn is really dying the last days, huh
23:24 <brentous> Alright looks like I'll be /etc/host-ing that
23:25 <Shiz> you can just edit it in /etc/apk/repositories
23:26 <brentous> Normally I would do something like that, but I'm working on automation and temporary edits like this are somewhat anathema
23:27 <Shiz> right
23:27 <brentous> Looks like the URIs are different between nl and dl-cdn :o
23:28 <Shiz> should be /alpine for both
23:28 <brentous> `WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz: No such file or directory`
23:28 <brentous> errr
23:28 nathanielks joined
23:29 <Shiz> likely nl.alpinelinux.org doesn't like it if you give it ah ttp request with Host: dl-cdn.alpinelinux.org
23:29 <brentous> `HTTP/1.1 404 Not Found` for the same URI with nl.alpinelinux.org
23:29 <Shiz> http://nl.alpinelinux.org/alpine/v3.5/main/x86_64/
23:29 <Shiz> works here...
23:30 <brentous> Ah I think you're right: vhosts issue.
23:30 <nathanielks> hiya, alpine team! looks like it may have been reported already, but http://dl-cdn.alpinelinux.org/ appears to be down. should I use nl. instead?
23:30 <Shiz> yep, it is
23:30 <Shiz> use nl. for now, yeah
23:30 <Shiz> or cz.
23:30 <nathanielks> very good, thanks 🤘
23:31 <Shiz> sorry bout the issues, dl-cdn has been having some real issues lately :/
23:31 <brentous> I'll just throw a `sed -i s/dl-cdn/nl/g /etc/apk/repositories` in my local version of the Dockerfile I guess
23:31 <brentous> Thanks for the info Shiz
23:35 <nathanielks> just glad they’re getting worked out :D