<     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 _2_6 27  
28 29 30 31
00:09 iadknet_ joined
00:11 BitL0G1c joined
00:28 ogres joined
00:33 switchy joined
00:43 iadknet_ joined
00:48 mouthbreather joined
00:48 blueness joined
01:01 luxio joined
01:01 <luxio> o
01:01 <luxio> o/
01:12 <Shiz> heyo
01:15 tmh1999 joined
01:16 `jpg joined
01:19 <luxio> I currently have zsh and ash installed, how do I remove zsh, install bash, and make bash my default shell?
01:20 <luxio> Is there a wiki page on this?
01:21 <scv> just remove and add the relevant packages? there's no chsh so i'd probably just edit passwd but there's likely a proper way to change the shell
01:26 <luxio> i think I got it. brb logging out
01:28 luxio joined
01:28 <luxio> Yep! It's working
01:28 <luxio> thanks scv !!
01:28 <scv> np
01:29 s33se joined
01:39 grayhemp_ joined
01:48 s33se_ joined
02:04 zocker joined
02:08 Kooda[b] joined
02:08 jid joined
02:18 grayhemp joined
02:19 aw1 joined
02:36 dirac1 joined
02:46 dirac1 joined
03:02 dirac2 joined
03:03 dirac2 joined
03:06 dirac2 joined
03:07 ryonaloli joined
03:08 dirac2 joined
03:14 dirac2 joined
03:17 dirac2 joined
03:19 mdillon joined
03:25 dirac2 joined
03:30 k0nsl joined
03:30 k0nsl joined
03:36 blueness joined
03:38 tmh1999 joined
03:43 <ryonaloli> i've been told that fortify-headers are incomplete and have perf issues compared to a true _FORTIFY_SOURCE=2 implementation. what is the extent of the incompleteness?
03:44 <ryonaloli> and are there any plans to actually upstream improved _FORTIFY_SOURCE to musl?
03:52 blueness joined
04:21 <nwmcsween> what perf issues?
04:23 <ryonaloli> this is just something i was told. i am not sure what the perf issues are. i haven't looked into it deeply.
04:24 <dalias> i haven't heard anything like that
04:24 <dalias> it might be true but would need to be measured
04:25 <dalias> re: =2, it's a really bad idea because it results in a nonconforming implementation
04:25 <dalias> it will introduce DoS bugs into correct prograsm
04:25 <dalias> and it's hard to know in advance which programs that will happen to
04:25 <ryonaloli> well programs don't have to be compiled with =2
04:25 <dalias> right but people don't tend to understand that and just throw =2 at things without knowing what it means
04:26 <nwmcsween> I sort of doubt it would be slower unless glibc has some chummy stuff going on with gcc
04:26 <nwmcsween> (some sort of builtin)
04:26 <dalias> while i can't control what alpine does, hardening hacks that break correct programs by violating interface contracts aren't welcome upstream in musl
04:27 <ryonaloli> that's scary :/
04:30 <ryonaloli> a current list of important security features which are missing from musl which i need to implement currently are fn ptr protection (whether xor mangling, PROT_READ for the fn ptrs, or both, for things like pthread_atform, atexit, at_quick_exit, C++11 local dtors), setjmp protection, cross-dso cfi support and safestack support, thread stack randomization, a hardened allocator (a really hardened one
04:30 <ryonaloli> , with out of line metadata, etc), _FORTIFY_SOURCE=2 or improved fortify-headers, and possibly library load order randomization, though that's not as important.
04:31 <ryonaloli> currently bionic has all of those to the best of my understanding, which makes it the most secure libc, but it's targeted for arm and android platforms in particular, so it's not viable.
04:31 <ryonaloli> glibc is huge and a real pain, so it's really only musl where implementing any of those is possible.
04:31 kunev joined
04:33 <nwmcsween> selfrando iirc does func randomization and runtime
04:33 mdillon joined
04:33 <ryonaloli> idk much about selfrando. does it require libc support like cross-dso cfi?
04:34 <ryonaloli> (regardless, apparently there are many simple programs it can't even compile with, so it's out of the question for now until it's better understood)
04:37 <nwmcsween> how would you use PROT_READ for fps?
04:39 blueness joined
04:40 <nwmcsween> also wasn't xoring fn ptrs a bad form of sec?
04:42 <ryonaloli> xor mangling is the fastest and avoids a race condition around the PROT_READ method that occurs with atexit, but it can infoleak.
04:43 <ryonaloli> PROT_READ is slower and more complicated and avoids the issue of having a leakable cookie, but there's a race condition for atexit-related functions. having a mix of the two is ideal, but xor mangling or the PROT_READ method alone is still not bad.
04:43 <ryonaloli> i wouldn't be surprised if openbsd (which uses the PROT_READ method) has solved the race issue, though.
04:57 Mutter joined
05:00 <dalias> ryonaloli, "most secure libc" is a joke
05:00 <dalias> hardening features are one small aspect of security
05:00 <TBB> it's one layer, that's what it is. nothing less, nothing more
05:01 <ryonaloli> hardening features provide a strong scaffold, but of course it's just one aspect.
05:01 <ryonaloli> CFI makes ROP extremely difficult, but it won't prevent already executing malware from running, you need a MAC for that.
05:02 <dalias> usually hardening features just make significantly more work for an attacker
05:02 <dalias> sometimes they prevent attacks
05:02 <dalias> but the case where they help is where you already have a severe security bug
05:02 <ryonaloli> indeed
05:03 <dalias> avoiding having those bugs in the first place is much more important
05:03 <ryonaloli> and a libc is used for effectively all programs on a computer, many of which are going to have security bugs.
05:03 <ryonaloli> "just don't have bugs in the first place" is, of course, the antithesis of hardening.
05:03 <dalias> yes but most of them are going to be exploitable regardless of what libc does
05:03 fabled joined
05:03 <dalias> that doesn't mean don't harden
05:03 <ryonaloli> the libc still plays an important factor, because the lack of support for cross-dso cfi for example makes rop much easier.
05:03 <dalias> but it does mean hardening that increases complexity is a serious tradeoff not a clear win
05:04 <ryonaloli> oh yeah, i don't think that extreme increases in complexity for a small benefit are worth it.
05:04 <ryonaloli> because it risks introducing new bugs (e.g. KASLR, VMAP_STACK, etc)
05:05 <dalias> btw re: hardened allocator it's interesting that ppl consider out-of-line more hardened
05:06 <ryonaloli> well that alone doesn't harden.
05:06 <dalias> inline-but-validated seems stronger in many ways; it helps detect overflows that would go uncaught with no inline metadata
05:06 <ryonaloli> look at the copperhead bionic forkl.
05:06 <ryonaloli> *fork
05:06 <dalias> i'll probably go for a mix in the next-gen malloc for musl
05:07 <dalias> minor validatable info inline with the important data that would be dangerous if corrupted kept out-of-line
05:08 <ryonaloli> would you accept patches for cross-dso cfi support?
05:08 <ryonaloli> it protects fn ptrs outside of the libc as well.
05:09 <dalias> not sure. i haven't seen what's involved in it.
05:09 <ryonaloli> https://android-review.googlesource.com/#/c/246837/ https://android-review.googlesource.com/#/c/326011/ https://android-review.googlesource.com/#/c/248499/ https://android-review.googlesource.com/#/c/170988/ and https://android-review.googlesource.com/#/c/304676/ is what bionic did for cross-dso cfi support (and safestack)
05:10 <ryonaloli> though they did a lot more
05:10 <ryonaloli> so it can be made simpler. most of that code is test cases for android-specific stuff.
05:11 <ryonaloli> as for xor mangling/PROT_READ fn ptrs, that should be easy (not much complexity there) and has a good security improvement.
05:11 <ryonaloli> probably something i can add myself. i'm gonna add it to a musl fork anyhow, so i can work on upstreaming it.
05:11 <ryonaloli> though cross-dso cfi support is currently out of my league.
05:13 <dalias> in general i'm very skeptical of anti-rop stuff though; it's usually huge complexity cost relative to actual protection it provides
05:13 <dalias> and the good stuff requires incompatible ABI
05:13 <ryonaloli> the anti-rop stuff is not part of libc. it's just support that the libc needs.
05:13 <ryonaloli> the anti-rop stuff is done by the compiler if applications want it.
05:13 <ryonaloli> and the complexity is pretty low since it's only forward edge. also 1% perf hit.
05:14 D630 joined
05:15 <dalias> this kind of thing == huge complexity: https://android-review.googlesource.com/#/c/304676/
05:15 <dalias> and it introduces bugs almost surely..
05:16 <ryonaloli> which one?
05:17 <ryonaloli> sigaction.cpp?
05:17 <dalias> yeah
05:17 <dalias> wrapping signal handlers like this is a known-super-difficult problem with lots of nasty corner cases
05:17 <ryonaloli> the complexity there does not seem that huge
05:17 <dalias> glibc considered doing it for other reasons
05:17 <ryonaloli> though i could ask bionic devs if they've had any problems or what their solutions were
05:17 <dalias> and dropped that consideration after realizing how difficut it was to get right
05:18 <dalias> they haven't had any problems because they're not aware of the problems
05:18 <dalias> :)
05:18 <dalias> same as how dietlibc has not had any problems :)
05:18 <dalias> complexity does not mean the code as written is complex
05:19 <dalias> it means there are complex hidden interactions with other things that are difficult to reason about or prove correct
05:19 <dalias> and that the code will grow much more complex as people realize that and try to fix it to adapt :)
05:19 <* ryonaloli> asking to see how bionic delt with it
05:19 <TBB> just kill off C, finally
05:20 <dalias> just stop using low-quality software written in C without proper sandboxing
05:20 <ryonaloli> oh also
05:20 <ryonaloli> dalias: that's for safestack
05:20 <ryonaloli> not cross-dso cfi
05:20 <ryonaloli> it looks like
05:20 <dalias> *nod*
05:21 <ryonaloli> so that would likely not even be needed for cross-dso cfi support (though safestack support that works for dsos is also very important)
05:21 <dalias> it's the same issue as in the 90s with bind, wuftpd, etc.
05:21 <dalias> it's not the people running vsftpd or running less-secure junk in a nobody chroot who are getting rooted
05:22 <dalias> it's the people running known-utter-crap software with permissions to do everything important
05:22 <ryonaloli> people with secure setups also get rooted. they just tend to need to get targeted (more often)
05:24 <ryonaloli> so what i gather is that cross-dso cfi does not look *too* complex, safestack, at the moment, looks too complex due to requiring wrapping signal handlers in a way that cannot be proven correct. xor mangling/PROT_READ fn ptr protection is ok to upstream. _FORTIFY_SOURCE=2 is not good because it breaks programs that blindly try to use it.
05:24 <ryonaloli> what about thread stack randomization?
05:25 <ryonaloli> that's another thing i plan to implement in my own musl fork, so i can try to upstream that as well.
05:25 <ryonaloli> it should also be simple.
05:25 <ryonaloli> will improve security against remote and scriptless exploits, which are common and getting more common as the complexity of formats grow.
05:30 <ryonaloli> dalias: and do you think using a combination of xor mangling and PROT_READ is best? that's my opinion, and the opinion of some other folk i have talked to, as it would both prevent the race issues and the issue of a leakable cookie.
05:31 <dalias> what would thread stack randomization do?
05:31 <dalias> just random offset for initial sp?
05:32 <dalias> done naively that breaks the ability to run with small stacks in an unpredictable/unreproducible way
05:32 <dalias> (apps that are close to the limit will randomly stack-overflow depending on the offset)
05:33 <ryonaloli> dalias: randomize more than just the lower bits, which the kernel can already do (for the main thread stack)
05:33 <dalias> ?
05:33 <dalias> the upper bits are already randomized as much as ASLR gives you
05:34 <dalias> i'm not sure what you mean by PROT_READ
05:34 <dalias> most interesting function pointers are not in places where you can make the whole page read-only
05:39 gogoprog joined
05:42 ryonaloli joined
05:43 <ryonaloli> (resending because i pinged out) dalias: randomizes more than the lower bits, which the kernel can already do (for the main thread stack). but, looking through my logs at least, it looks like the implementation is non-page aligned randomization of the secondary stacks as well. copperhead bionic (and i think openbsd's libc?) already do this correctly, so no need to find a new way to reimplement it,
05:43 <ryonaloli> potentially naively.
05:43 <ryonaloli> and i missed anything you said after "(apps that are close to the limit will ..."
06:18 rollniak joined
06:25 grayhemp joined
06:32 fabled joined
06:33 grayhemp joined
06:40 greguu joined
06:41 `jpg joined
06:42 <avih> dalias: if i read the correct standard, it says "The macro NAN is defined if and only if the implementation supports quiet NaNs for the float type. It expands to a constant expression of type float representing a quiet NaN.". however, musl seems to define NAN as (0.0f/0.0f) if it's not __GNUC__ > 3.03. should that definition be allowed in a constant? tcc complains about division by zero in a constant. tcc does have __nan__ which works correctly if use
06:42 <avih> . is there a way to communicate this to musl headers?
06:47 arnotixe joined
06:54 ocb joined
06:54 <ocb> hello
06:54 gogoprog1 joined
06:58 <Shiz> avih: then tcc's analyzer is broken
06:58 <Shiz> division by zero is perfectly valid for floating point
06:58 <avih> also in a constant?
06:58 iadknet_ joined
06:59 <avih> the analyzer is not broken though. but it interprets it incorrectly if it's allowerd
07:00 <avih> i'm trying to figure out where the solution is. could be tcc, or somehow communicate the support for NAN.
07:00 serge____ joined
07:04 <Shiz> constant or not doesn't really change anything
07:04 <ocb> I'm kind of new to linux, have setup 3 alpine linux apache+php in docker container few weeks ago. Have setup another one today but can't seem to get mod_rewrite work. Enabled the module in httpd.conf, set AllowOverride All for /web/html dir, rebooted docker, mod_rewrite.so corresponds to path but rewrite does not work and haven't got it loaded in phpinfo(). Any suggestion what to check, as mod_rewrite
07:04 <ocb> works on other 3 alpine linux dockers created from same template. Also did diff check of httpd.conf and everything corresponds to other docker containers except the ServerName of course.
07:04 <Shiz> more importantly, it shouldn't warn on system headers avih
07:05 <avih> Shiz: not sure i follow. there was no warning involved. tcc just fails with "division by zero in a constant"
07:05 <Shiz> oh, then it's even worse
07:06 <avih> ok, that's why i'm asking :) to understand where the issue is
07:07 <Shiz> are you using tcc or the tinycc fork?
07:07 <avih> Shiz: it's not tcc which breaks. it just considers the source invalid.
07:08 <Shiz> well, that is its breakage
07:08 <Shiz> :P
07:08 <avih> i started by asking if it should be allowed in a constant expression :)
07:08 <avih> if i knew that, i'd know where the issue is :)
07:08 <Shiz> http://repo.or.cz/w/tinycc.git btw this is the fork
07:08 <Shiz> that i know of
07:09 <avih> Shiz: i don't think there's more than one tcc/tinycc. it's the one started by fabrice bellard, now hosted on http://repo.or.cz/w/tinycc.git , where the main dev branch is "mob", which is relatively active
07:13 <avih> and there have been talks about releasing 0.9.27 for some months now, though fixes still go in. most recently - musl related.
07:13 <Shiz> https://txt.shiz.me/YzllOWMwMW.txt
07:13 <Shiz> :P
07:13 ocb left
07:13 <Shiz> it looks like it was mindlessly copied from the integer generation code
07:13 <Shiz> where division by zero is of course invalid
07:14 <Shiz> constant vs non-constant is not relevant as it just follows IEEE 754 semantics
07:15 <Shiz> afaik
07:15 <avih> Shiz: could you point me to where the c99 standard says or implies that 0.0f/0.0f should be allowed in a constant?
07:16 <avih> (i was still reading through it when you started replying and interrupted me ;) )
07:17 <Shiz> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
07:17 <Shiz> F7.4
07:17 <Shiz> the specific code example even includes division by floating point zero
07:17 <Shiz> (specifying run-time exceptions when FENV_ACCESS is on, but it proves the source code is correct)
07:18 <avih> "7.4 Character handling <ctype.h>" ??
07:18 <Shiz> F7.4
07:18 <Shiz> not 7.4
07:18 <Shiz> furthermore, from F3:
07:18 <Shiz> "— The +, −, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations"
07:19 <Shiz> IEC 60559 being of course IEEE 754 and defining floating point division by zero as valid
07:19 <avih> i don't think i can find "F7.4" in the pdf i have.
07:20 <Shiz> try F.7.4
07:20 <Shiz> it's on page 449
07:20 <avih> found it. (good thing you quoted :p )
07:21 <Shiz> it seems like the tcc error is just from copying the integer constant propagation code
07:21 <Shiz> for floating point
07:21 <Shiz> and not removing the 0 case
07:21 <avih> yeah, possibly. fixing isn't hard if one knows where the issue is ;)
07:22 <avih> and i wasn't sure what should be supported. thanks :)
07:22 <Shiz> just gave you a patch even
07:22 <avih> push it yourself :)
07:22 <avih> no registration required :)
07:24 nepochal joined
07:25 <Shiz> i'm busy ;p
07:26 <avih> of course you are :)
07:26 <avih> it should probably come with a test though, to make sure it fails for integers and works for floats
07:34 t0mmy joined
07:36 <avih> Shiz: also, your patch doesn't fix it. it makes instead show "error: initializer element is not constant"
07:37 <avih> it should be using it's __nan__ there instead
07:37 <avih> its*
07:37 <Shiz> it shouldn't
07:38 <Shiz> it should be left to be generated at runtime
07:38 <Shiz> and only be statically generated when it has to be
07:38 <avih> as a constant expression??
07:38 <Shiz> see F.7.4
07:38 <Shiz> it specifically mentions that if used as part of a static initialiser expression it's fine to be constant-propagated
07:39 <Shiz> however, when not, it must be subject to FENV_ACCESS requirements
07:39 <Shiz> which can mean throwing an exception at runtime
07:39 <avih> "other than one in an initializer for an object that has static storage duration"
07:39 <avih> which is my initial use case. i'm adding now.
07:40 <avih> specifically: float w[] = { 0.0/0.0 }; // raises an exception
07:41 <avih> and that's the exact case where the source code uses NAN, and musl replaces it with 0.0f/0.0f
07:42 <avih> hence, so far i still think it should be using its __nan__ there
07:46 arnotixe joined
07:47 <avih> it also has a comment " /* NOTE: we only do constant propagation if finite number (not NaN or infinity) (ANSI spec) */
07:47 <avih> so it seems rather intentional
07:48 <avih> (could of course be erroneously so)
07:48 <avih> also, it might have changed in c99
07:58 royger joined
07:58 arnotixe joined
07:59 rnalrd joined
08:03 aw1 joined
08:05 `jpg joined
08:16 MuffinMedic joined
08:16 `jpg joined
08:19 `jpg joined
08:26 `jpg joined
08:27 minimalism joined
08:30 `jpg joined
08:40 `jpg joined
08:48 MuffinMedic joined
08:52 kvda joined
09:13 kahiru joined
09:24 `jpg joined
09:26 Dick_Hammer joined
09:46 blackwind_123 joined
09:49 rollniak joined
10:08 blueness joined
10:21 gromero joined
10:24 lesion joined
10:29 russkel joined
10:30 <russkel> hey all, question I couldn't find an answer for: why is it that a standard disk install is taking up more than 500mb? I thought it was supposed to be ~130mb install?
10:40 <Shiz> russkel: that doesn't seem like it should be right
10:43 <russkel> Shiz: it's running in virtual box, I set up a 500mb HDD and simply booted the standard iso, did setup-alpine and it failed install
10:43 <russkel> just created a 2gb hdd and the install has worked
10:43 <Shiz> it might be temporary files
10:43 <Shiz> ?
10:43 <russkel> potentially, RAM is limited to 256MB if that makes a difference
10:59 iadknet_ joined
11:09 klogd joined
11:12 czart_ joined
11:14 lesion joined
11:15 <klogd> Anyone had any weird permission issues when running Alpine as a docker host? Have a fresh install of 3.5.2 running docker 17.04.0-ce (installed via apk). Trying to run a very simple container I've run on lots of other computers and I'm getting "murmur.x86: mprotect: Permission denied (13)"
11:24 help-im-stuck joined
11:25 <Shiz> klogd: that makes sense
11:25 <Shiz> alpine ships with a hardened kernel, but if your containers aren't equipped for that (e.g. ubuntu-based), they don't have the required exemption markings on binaries to indicate that it can do certain otherwise naughty stuff
11:25 <Shiz> all alpine binaries ship with those markings of course where needed
11:25 <Shiz> but e.g. ubuntu and debian do not apply them
11:35 cyteen joined
11:36 <klogd> Shiz: I've tried 3 containers, the one based on ubuntu:14.04 works, but jessie-slim and busybox. From what you said I was expecting the ubuntu one to be failing as well?
11:38 <klogd> The ubuntu based one is the only one making a dedicated user account for the program, the other two run as root, if that makes any difference
11:43 <Shiz> it depends on the binaries inside of the container
11:54 ppisati joined
11:57 freedomrun joined
11:59 <klogd> ah, I see. I ended up cloning the mumble server and changing it to alpine:latest and then everything is working a lot better. Thanks for the info
12:02 Dick_Hammer joined
12:14 farosas joined
12:22 gromero joined
12:38 minimalism joined
12:41 tmh1999 joined
12:44 ogres joined
12:54 pratch joined
12:59 pratch joined
13:07 Zucca joined
13:10 blueness joined
13:23 Xanza joined
13:24 <Xanza> I'm trying to install and run Alpine from a USB drive via VMDK image which uses the USB drive as a virtual disk. I've done it successfully in the past, but the installer seems to hang here every time: https://a.safe.moe/dsjYy.png Any advice or guidance?
13:42 mihnea joined
13:55 Diftraku joined
14:00 afics joined
14:03 dave0x6d joined
14:03 cyteen joined
14:09 Dick_Hammer joined
14:17 rollniak joined
14:40 atomi joined
14:42 Skele joined
14:46 orbiter joined
14:52 jhyelton joined
14:56 blackwind_123 joined
15:00 fabled joined
15:21 jhyelton joined
15:30 jhyelton joined
15:33 grayhemp joined
15:43 pratch joined
15:49 pratch joined
16:02 Dick_Hammer joined
16:14 grayhemp joined
16:37 davidmichaelkarr joined
16:38 emacsomancer joined
16:47 felixsanz joined
16:58 ogres joined
17:02 kunev joined
17:02 dlaube joined
17:06 iadknet_ joined
17:10 Dick_Hammer joined
17:11 grayhemp joined
17:11 aw1 joined
17:16 Diftraku joined
17:31 grayhemp_ joined
17:46 gopar joined
18:00 t0mmy joined
18:03 __0xAX joined
18:17 ^ingo^^^ joined
18:20 jhyelton joined
18:25 czart joined
18:30 greguu joined
18:31 Dick_Hammer joined
18:40 jhyelton joined
18:45 jhyelton joined
18:48 jhyelton joined
18:53 jhyelton joined
18:54 orbiter joined
18:56 grayhemp joined
18:57 <mauli> after trying to debug but failing woud anyone be able to help me with alpine-iso: am trying to make with APKOVL, it is set, but the make (make -d) does not seem to use it, anything I am missing ?
19:00 emacsoma` joined
19:02 grayhemp joined
19:08 cyborg-one joined
19:11 jhyelton joined
19:15 <clandmeter> alpine-iso had been superseded
19:15 <clandmeter> Check root of aports
19:17 <mauli> ah okay, the wiki referenzed it, thx
19:18 iadknet joined
19:19 grayhemp joined
19:21 <TemptorSent> Uhoh, who was looking at alpine-iso?
19:22 <TemptorSent> I went down that road before... then found out it was out of date for years already.
19:25 jhyelton joined
19:26 <TemptorSent> The current mkimage is about to be superseded as well.
19:29 grayhemp joined
19:30 grayhemp_ joined
19:34 jhyelton joined
19:39 grayhemp joined
19:41 ahrs joined
19:43 blueness joined
19:48 jhyelton joined
19:54 kvda joined
19:56 grayhemp joined
20:03 blueness joined
20:06 mortis304 joined
20:09 kvda joined
20:10 Emperor_Earth_ joined
20:11 jhyelton joined
20:13 grayhemp_ joined
20:16 jhyelton joined
20:16 Emperor_Earth__ joined
20:23 gopar joined
20:25 gopar_ joined
20:26 sergey_ joined
20:27 aw1 joined
20:34 Dick_Hammer joined
20:35 preyalone joined
20:36 jhyelton joined
20:36 jhyelton joined
20:48 grayhemp joined
20:50 dave0x6d joined
20:50 jhyelton joined
21:11 <mauli> so what to use to build an image ?
21:12 <Shiz> mauli: scripts/mkimage.sh in the aports repo
21:13 <Shiz> the dependencies are commented in the first few lines of the script
21:15 rollniak joined
21:20 grayhemp joined
21:25 jhyelton joined
21:28 <mauli> hm, weird am getting ERROR: unsatisfiable constraints ( alpine-base (missing), linux-firmware ...)
21:29 <TemptorSent> Error while doing what?
21:29 <Shiz> does it also say '>>> WARNING: no repository set' perhaps? ;p
21:30 <Shiz> it is intended to be pointed to a one (or more repos) that have aports build
21:30 grayhemp joined
21:30 <Shiz> not sure if fully built is necessary
21:31 <mauli> damn ,yes ... warnings should not be ignored
21:32 <Shiz> e.g. to build the latest edge/main
21:32 <Shiz> $ ./scripts/mkimage.sh --repository http://nl.alpinelinux.org/alpine/edge/main
21:32 <Shiz> and you can supply extra repositories through --extra-repository
21:32 <Shiz> e.g. your local ones that have your own packages you want to add
21:33 <TemptorSent> Also, make sure you add the option to include host keys, otherwise you'll get an unusable image.
21:33 <mauli> thought it might be using system repo per default, my mistake
21:33 <Xe> TemptorSent: it'll be useful, just oneshot :D
21:34 <TemptorSent> Xe: It won't boot because the repo can't be verified.
21:34 <Xe> oh, gg
21:35 <TemptorSent> mauli: Yeah, you have to be explicit.
21:35 <TemptorSent> mauli: What are you trying to do with the image? The existing mkimage.sh is rather limited.
21:35 <mauli> am trying to setup an image with working live from scratch yea, alpine-iso had the possibility to use lbu file
21:37 <Shiz> you can still do that
21:37 <TemptorSent> mauli: Okay, you're getting out of the realm of what the existing mkimage can do happily. I have a complete rewrite that's waiting on a couple changes in APK to make the switch.
21:39 <Shiz> mauli: add a profile in mkimg.yourname.sh and set apkovl=
21:40 <TemptorSent> see https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts for details.
21:40 <Shiz> more specifically: mkdir ~/.mkimage, edit ~/.mkimage/mkimg.whatever.sh, add something like profile_mauli() { profile_standard; apkovl="my-apkovl-generation-script.sh" }
21:40 <Shiz> then call mkimage.sh with --profile mauli
21:40 <Shiz> and have that script existing
21:40 <mauli> already setup a profile^^, thx
21:40 gopar joined
21:42 flazz joined
21:43 <flazz> upgrading from 3.4 to 3.5 seems to cause curl to not get some intermediate certs, anyone have any advice?
21:49 gopar joined
21:51 <flazz> but funny enough openssl seems to verify the whole chain
22:09 jhyelton joined
22:11 arnotixe joined
22:17 kahiru joined
22:37 grayhemp joined
22:38 gopar joined
22:40 kahiru joined
22:41 blueness joined
22:42 kahiru joined
23:20 grayhemp joined
23:32 lesion joined
23:34 farosas joined
23:39 blueness joined