<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:18 Skele joined
00:19 <bahamat> dalias: Doing some further testing, musl doesn't retry truncated responses with tcp at all.
00:20 <bahamat> If the truncated reply includes answers it uses them, but it doesn't retry with tcp.
00:20 <Skele> hey, after about 12 hours my resolv.conf gets changed back to a local network address instead of the VPN provided one. So far I only have found people saying that this is done by the udhcpd client but haven't found any real indication for this
00:20 <Skele> . Anyone who could point me in the right direction would be great
00:20 <Shiz> that's what dalias said before, no?
00:22 <bahamat> Yeah, I suppose so. That wasn't immediately clear to me.
00:22 <Shiz> Skele: create /etc/udhcpc/udhcpc.conf
00:22 <bahamat> I had interpreted it as if there are answers, and it's truncated it'll retry with tcp
00:23 <Shiz> add 'RESOLV_CONF=no' to it
00:23 <Shiz> that'll stop it from overwriting your resolv.conf, at least
00:36 <Skele> thanks a lot, Shiz
00:37 <Skele> udhcpc is correct without a c instead of a d at the end?
00:39 <Shiz> udhcpc, yes
00:39 <Shiz> the c means client
00:41 <Skele> I see
00:49 <bahamat> dalias: Do you have a bug number or anything that I can add myself as a watcher?
00:54 mikeee_ joined
00:59 <dalias> not yet, busy with other things
01:11 mdillon joined
01:24 nirtdap joined
01:27 bahamat left
01:35 <TemptorSent> mmlb: I've been out most of the day and will be again for another couple hours, but drop me a line and let's get you a custom image if we can :)
01:37 dirac1 joined
02:13 gromero joined
02:22 Nobabs27 joined
02:23 coin3d joined
02:28 s33se joined
02:37 Janhouse joined
02:52 royger joined
03:56 Emperor_Earth joined
04:01 dirac1 joined
04:02 sparklyballs joined
04:03 mdillon joined
04:04 mguentner joined
04:07 blackwind_123 joined
04:10 mguentner2 joined
05:17 mdillon joined
05:20 chatter29 joined
05:25 royger joined
05:34 blueness joined
05:37 royger_ joined
05:54 mattjbarlow joined
06:23 ezequielg joined
06:24 fabled joined
06:29 slukin joined
06:34 systmkor joined
06:34 dikaio joined
06:50 stwa joined
06:57 m0e joined
07:16 coin3d joined
07:23 t0mmy joined
07:33 wonton joined
07:35 sparklyballs joined
07:37 gogoprog joined
08:23 cyborg-one joined
08:25 mackson joined
08:59 tmh1999 joined
09:22 eau joined
09:22 jlyo joined
09:23 fekepp joined
09:35 OsakaFoo joined
09:54 m0e joined
10:56 blueness joined
11:40 mystified joined
11:41 rollniak joined
11:53 CcxWrk joined
11:55 blueness joined
12:05 damongant joined
12:17 gromero joined
12:26 blueness joined
12:28 blueness joined
12:42 cyborg-one joined
12:42 farosas_ joined
12:57 blueness joined
13:07 Ganwell joined
13:10 Ganwell joined
13:10 felixjet joined
13:56 czart_ joined
14:03 Berra joined
14:31 fekepp joined
14:36 zopsi joined
14:38 ahrs joined
14:53 snaphuman joined
14:53 ogres joined
15:00 trn joined
15:01 nanohest joined
15:09 bluetazmanian joined
15:10 Pizzarabe joined
15:11 <Pizzarabe> Hi guys, I would like to use alpine as my main container image. what is the best way to keep track of security bugs in alpine and alpine packages?
15:11 jackmcbarn joined
15:12 <_ikke_> Pizzarabe: the commit messages usually contain the CVE numbers
15:12 <_ikke_> But I'm not sure if that's exhaustive
15:13 <Pizzarabe> _ikke_: you mean the git commits (http://git.alpinelinux.org/cgit/aports/log/?h=v3.5.2)?
15:14 <_ikke_> yes
15:15 <Pizzarabe> Is there a good way to keep track of the git log? I thought about sth. like a mailing list or a rss feed, maybe sth. I can automate the container updating
15:15 mikeee_ joined
15:18 <_ikke_> There are some tools which track package updates, but I don't recall the names anymroe
15:18 <_ikke_> anymore
15:18 <_ikke_> (one is a fedora project)
15:20 <Pizzarabe> Okay, lets look at that different, how do you update your alpine installations?
15:20 <_ikke_> Pizzarabe: run apk upgrade -U from time to time
15:24 <Pizzarabe> Okay, I will try to get clair running then ;) (https://github.com/coreos/clair)
15:29 fabled joined
15:30 fekepp joined
15:43 cyborg-one joined
15:47 Skele joined
15:52 coin3d joined
15:59 rafalcpp_ joined
16:02 BitL0G1c joined
16:19 bluetazmanian joined
16:38 rafalcpp joined
17:09 xsteadfastx joined
17:09 dlaube joined
17:10 mikeee_ joined
17:12 xsteadfastx joined
17:14 xsteadfastx joined
17:22 lesion joined
17:30 jyaworski joined
17:32 bluetazmanian joined
17:32 mmlb joined
17:32 <mmlb> hey TemptorSent ping me whenever you have a chance so I can try getting builds to work
17:35 bluetazm_ joined
17:44 jyaworski joined
17:50 <TemptorSent> mmlb: *ping* - How's it going?
17:51 <mmlb> hey TemptorSent, alright. I got alpine booting in qemu-system-aarch64 (but then it stopped working for some reason). Anyway I'd like to make an iso with virtio drivers in.
17:51 <mmlb> TemptorSent: how you doing?
17:52 <TemptorSent> mmlb: Moving a bit slow this morning, but up and about anyway :)
17:52 <TemptorSent> mmlb: Okay, that should be pretty straightforward.
17:52 <mmlb> yeah I hear that
17:53 <mmlb> ok cool. I've got a docker container running alpine:latest. created said builder user, only group is abuild, messed with sudoers, but looks like I can't fetch deps
17:55 <TemptorSent> mmlb: That's odd.
17:55 trn joined
17:55 <mmlb> let me try again now
17:57 <TemptorSent> mmlb: If you pull the lastest rev of my mkimage branch, you should be able to add virtio to wheichever profile you want by creating a new profile that calls the one you want to base on then calling add_initfs_features_virtio and add_initfs_load_modules "<list of modules you want at boot>
17:57 ahrs joined
17:58 <TemptorSent> Oh, and possibly initfs_add_apks if you have modules that aren't in the kernel tree, but virtio should be.
17:58 <TemptorSent> ..AFK a bit, back shortly.
17:58 jyaworski joined
17:59 <mmlb> kk
18:01 bluetazmanian joined
18:02 ldleworker joined
18:03 <ldleworker> Hello, I am unable to build docker images with alpine right now I keep getting logs like: https://gist.github.com/dustinlacewell/9440e101e7d668d1b1d407019a234cf3
18:03 <ldleworker> Is there currently an issue with apk repositories?
18:03 rollniak joined
18:04 <mmlb> TemptorSent: I was able to manually install all the apks...
18:04 <TemptorSent> mmlb: Okay, so abuild-apk isn't doing the su thing for you like it's supposed to then?
18:05 <TemptorSent> mmlb: Is it trying and failing or not trying/
18:05 <mmlb> I'll take a look
18:06 <TemptorSent> mmlb: Not that it matters as far as making it work, but it would be nice to know why it doesnt.
18:06 wonton joined
18:06 NIN101 joined
18:07 <ldleworker> ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.5/community: temporary error (try again later)
18:07 <ldleworker> it returns 404
18:08 <ldleworker> Anyone?
18:09 <TemptorSent> Idleworker: try dl-4 and see if yout get the error... somethign one one of the mirrors may have died.
18:09 <ldleworker> huh? I'm not specifying a mirror.
18:09 <ldleworker> How do I do that manually.
18:10 <TemptorSent> Idleworker: /etc/apk/repositories
18:10 <ldleworker> I'm building a docker image...
18:10 <mmlb> TemptorSent: abuild-apk fetch --root /tmp//tmp/mkimage.LkGcaB/apkroot-x86_64 --link --recursive --output /tmp//tmp/mkimage.LkGcaB/apks_x86_64_snip.work/apks/x86_64 acct alpine-base ...
18:10 <mmlb> acct: unable to select package (or it's dependencies) ... repeat for each package
18:11 <TemptorSent> mmlb: Looks like it's not finding the repo?
18:11 <TemptorSent> and is the /tmp//tmp/... in the --root intentional?
18:12 <mmlb> yeah seams that way I just noticed this:
18:12 <mmlb> >>> WARNING: mkimage.sh:x86_64: no repository set
18:12 <TemptorSent> It looks like it's being double-specced for some reason.
18:12 <mmlb> OK: 0 distinct packages available
18:12 <TemptorSent> Yeah, that'd do it :)
18:12 <mmlb> TemptorSent: that was default. I just ran `./mkimage.sh`
18:13 <mmlb> I take it I should specify a profile?
18:13 <TemptorSent> Oh, yeah -- you don't want to do that :)
18:13 <mmlb> :D
18:13 <TemptorSent> mmlb: Yeah, you should specify the profile, workdir, outdir, and pass the --hostkeys option!
18:13 <TemptorSent> do a --help
18:13 <mmlb> I did, but doesn't say if anything is required soOo...
18:14 <Xe> ldleworker: gist your dockerfile?
18:14 <TemptorSent> Yeah, I haven't gone back and rewritten the help-text yet, just added a couple items.
18:16 <mmlb> TemptorSent: `./mkimage.sh --hostkeys ~/.abuild/builder-58c19b5b.rsa --outdir /tmp/out --workdir /tmp/work --profile vanilla --repository-file /etc/apk/repositories` gives me same error but with less packages
18:16 <TemptorSent> mmlb: I'm using './mkimage.sh --repository-file /etc/apk/repositories --outdir /tmp/mkimage.out --workdir /tmp/mkimage.tmp --apk-cache-dir /tmp/mkimage.apkcache --hostkeys --profile xen' for instance
18:16 <mmlb> actually no, only xtables-addons-vanilla was unmet
18:17 <mmlb> let me try your call
18:17 <TemptorSent> hmm, it was supposed to avoid adding xtables-addons to vanilla kernels. Let me check that.
18:19 <TemptorSent> Oops, my bug I think.
18:19 sergey joined
18:22 tmh1999 joined
18:22 <TemptorSent> mmlb: Pull again, should be fixed.
18:23 <mmlb> k will try again
18:23 <TemptorSent> mmlb: It's great to check for a supported kernel, but not so great to try to add modules for all the other ones too.
18:24 <TemptorSent> mmlb: It might take a sec for it to show up actually, I forgot github isn't my local repo.
18:27 <TemptorSent> mmlb: Let me know if anythig else is broken :)
18:31 <mmlb> TemptorSent: have to fix a fire at work right now, should be back at this in ~1hr tops
18:32 <TemptorSent> mmlb: No worries, don't forget to pull the pin on the extinguisher ;)
18:38 bluetazmanian joined
18:39 bluetazm_ joined
18:40 <mmlb> pull the pin on the grenade, not extinguisher. got it!
18:41 <TemptorSent> mmlb: Pull pin and throw...
18:41 <TemptorSent> mmlb: ...not the pin, the GRENADE you fo-*BOOM*
19:15 aw1 joined
19:15 snaphuman joined
19:18 bluetazmanian joined
19:23 blackwind_123 joined
19:29 cyborg-one joined
19:52 mouthbreather joined
20:06 Guest47080 joined
20:06 Guest47080 left
20:10 fabled_ joined
20:35 aw1 joined
20:38 hairyhenderson joined
20:40 mguentner joined
21:07 <mmlb> TemptorSent: vanilla x86_64 works fine, I uncommented out the `add_archs "aarch64"` from profiles/alpine/profile-vanilla.sh but that fails when I do --arch aarch64
21:09 <mmlb> TemptorSent: fails with `/tmp/update-kernel.bjePdP/root/lib/ld-musl-x86_64.so.1: Not found.`
21:26 <TemptorSent> mmlb: Hmm, looks like update kerenel is trying to use the wrong loader perhaps? I haven't poked at cross-building yet...
21:29 jackmcbarn joined
21:31 <mmlb> I think more along the lines of mkinitfs
21:32 <TemptorSent> mmlb: Yeah, mkinitfs is called from update-kernel, but there's no sign of the architecture being passed, so that's likely the culprit.
21:32 <TemptorSent> mmlb: Let me see if I can find an easy way of altering that.
21:34 m4 joined
21:36 <mmlb> ok
21:38 <TemptorSent> mmlb: Could you tell what was looking for ld-musl-x86_64.so.1?
21:39 <TemptorSent> mmlb: I'm guessling lddtree in initfs_base.
21:39 nanohest joined
21:39 <mmlb> yup
21:43 jackmcbarn joined
21:43 <TemptorSent> mmlb: looks like it may be an issue with lddtree itself, trying to parse...
21:46 <mmlb> yeah I think you are right, I'll try to catch what it is that is not aarch64, but my root dir seems to be wiped
21:46 cyborg-one joined
21:49 <TemptorSent> mmlb: I suspect it's actually readelf related... It's trying to use the wrong ld path?
21:49 <mmlb> maybe, I'll stop the process before calling lddtree and see if I can poke around
21:53 <TemptorSent> mmlb: readelf calls scanelf via elfspecs in /usr/bin/lddtree --Try adding a line to dump the command to a file in scanelf for debugging perhaps.
21:53 <mmlb> will do
21:56 <TemptorSent> mmlb: I'm guessing scanelf needs different arguments to work properly and it's only by accident that it works when the target and host are the same.
21:56 <mmlb> yeah thats likely the case, cross compile/packaging is always fun
21:58 <TemptorSent> mmlb: I'm not sure that it was ever setup to work previously, considering.
22:01 ogres joined
22:05 <TemptorSent> Hmm, someone else take a look at /usr/bin/lddtree:find_elf around line 78 please and tell me if that code parses sanely in your head?
22:13 <TemptorSent> In fact, does the entire nested function definition for check_paths INSIDE find elf make any sense?
22:15 <mmlb> TemptorSent: I'll be looking at this some more later tonight/tomorrow, cya later
22:18 <TemptorSent> mmlb: Okay, sounds good -- it looks like a bug in lddtree to me at the moment.
22:18 <TemptorSent> mmlb: Some vodo-gone-wrong likely.
22:20 bluetazmanian joined
22:23 bluetazmanian joined
22:30 Ayyad joined
22:30 czart joined
22:33 <TemptorSent> It appears elf_specs is undefined the first time through the loop, which leaves check_path comparing against "".
22:54 Fearfulx joined
22:54 <Fearfulx> fastcgi_pass unix:/run/php/php7.0-fpm.sock;
22:54 <Fearfulx> how do I get this to work in alpine linux?
22:54 <Fearfulx> nginx + php-fpm
23:23 <Shiz> Fearfulx: you edit the php-fpm configuration to listen on a socket
23:23 <Shiz> presumably
23:42 alacerda joined
23:53 minimalism joined