<  February 2017   >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28
00:59 IRCFrEAK joined
01:00 IRCFrEAK left
02:47 Shiz joined
02:59 s33se_ joined
04:02 Emperor_Earth joined
04:05 madgoat joined
04:05 madgoat left
04:47 skarnet joined
06:07 blahdodo joined
07:06 blahdodo joined
07:10 blueness joined
07:17 <fcolista> morning all
07:33 <fcolista> ncopa, fabled: i hadd to apply this patch to build v4l-utils: http://sprunge.us/UIjD
07:33 <fcolista> *had
07:58 fabled joined
08:32 stwa joined
08:33 vakartel joined
08:37 blueness joined
08:49 t0mmy joined
09:04 <ncopa> fcolista: you should report it upstream
09:05 <ncopa> and you could do: # !defined(TEMP_FAILURE_RETRY) instead of __GLIBC__
09:05 <fcolista> ncopa, thx. I was scared that this might introduce bugs or security flaws
09:06 <ncopa> no, it looks valid
09:06 <ncopa> are there many places TEMP_FAILURE_RETRY is used?
09:06 <fcolista> only here
09:07 <fcolista> utils/ir-ctl/ir-ctl.c
09:07 <ncopa> you could probably do the loop manually instead of using the macro
09:07 <ncopa> in any case, would porbably be good to report it upstream
09:09 <fcolista> i'm not a C coder, so actually i'm unsure about how to do that. I'll report it to upstream, though.
09:09 <fcolista> how to do it effectively i mean :)
09:09 fekepp joined
09:12 fekepp1 joined
09:28 <nmeum> hm, the most recent ffmpeg upgrade included an soname bump
09:28 <nmeum> but packages depending on ffmpeg weren't rebuild
09:59 royger joined
10:05 <clandmeter> ppl who bump libraries should be really carefull.
10:05 <clandmeter> nmeum: who bumped it?
10:13 stwa joined
10:27 <przemoc> fabled: yeah, as I already wrote in mesg before the one mentioning you explicitly, I realized (too late) it's already fixed in master and 3.5-stable (and even mentioned the sha1s myself). but according to commit dates, curl in 3.4-stable was upgraded to 7.52.1 on 2017-01-09 and you applied the fix in master and 3.5-stable on 2017-01-24, so I dare to say that stables did not have older version when
10:27 <przemoc> you fixed the issue (I presume that your local 3.4-stable branch was simply not up-to-date with remote one). :)
10:27 <przemoc> anyway, thanks for applying
10:28 blueness joined
10:31 <nmeum> clandmeter: http://git.alpinelinux.org/cgit/aports/commit/?id=388c5ed7bee76f6d3cf1d9e43e872d2abe7356cb
10:31 <nmeum> there is also already a bug report #6885
10:31 <algitbot> Bug #6885: mpv broken- please rebuild everytime you upgrade ffmpeg on edge - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/6885
10:32 <nmeum> I would have rebuild all effected packages but apk search -r so:... is currently broken isn't it?
10:37 ncopa joined
10:37 ncopa joined
10:44 ppisati joined
11:07 blueness joined
11:12 <przemoc> nmeum: why you wrote that `apk search -r ...` is broken? is it a fact?
11:14 <nmeum> > 11:58 <@ncopa> fabled: i think i have a possible apk bug
11:14 <nmeum> > 11:58 <@ncopa> to reproduce: apk search --exact -r so:libvncclient.so.0
11:14 <nmeum> > 11:58 <@ncopa> it should have shown remmina
11:14 <nmeum> > 11:59 <@ncopa> but it doesnt
11:14 <nmeum> that's all I know
11:14 <przemoc> ah, ok
11:18 stwa joined
11:44 skarnet joined
11:57 farosas joined
11:59 LouisA joined
12:15 leitao joined
12:27 czart joined
12:44 <ncopa> how can i properly pass the $@ args to a su command?
12:44 <ncopa> seems like su - alpine -c "foo $@" makes su pick up the $2
12:45 <ncopa> su - alpine -c "cd $startdir && abuild $@"
12:51 <przemoc> you cannot, because -c takes only one argument, so you have to quote "$@" expansion yourself within arg passed to -c
12:51 <przemoc> I meant "you cannot easily"
12:51 <Shiz> ncopa: "$@" is only special in that specific form
12:52 <Shiz> what i'd do is
12:52 <Shiz> set -- cd $startdir '&&' abuild "$@"
12:52 <skarnet> s6-setuidgid
12:52 <* skarnet> whistles innocently.
12:52 <Shiz> wait, as przemoc states, -c only takes a single arg
12:53 <Shiz> if it took multiple args, su - alpine -c "$@" with the above thing would work
13:06 <clandmeter> nmeum: wasnt that an error with aports intead of apk-tools?
13:08 <clandmeter> nmeum: are you sure its the ffmpeg upgrade?
13:08 <nmeum> hm?
13:09 <clandmeter> x265 got a bigger upgrade recently
13:10 <nmeum> the mpv error in #6885 claims that it is
13:10 <algitbot> Bug #6885: mpv broken- please rebuild everytime you upgrade ffmpeg on edge - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/6885
13:10 <nmeum> but I haven't look at it closer yet so: no, I am not sure
13:10 <nmeum> *looked
13:12 <clandmeter> that bug is not really verbose, better to find out what the error msg is.
13:13 <nmeum> yeah
13:13 <clandmeter> does ffmpeg bump soname on patch level changes?
13:27 <Shiz> clandmeter: "sometimes"
13:29 <nmeum> well according to mpv the soname for libavformat and libavutil changed
13:33 LouisA joined
13:34 <Shiz> clandmeter:
13:34 <Shiz> JEEB │ FFmpeg bumps it randomly
13:34 <Shiz> JEEB │ although usually the issue is that they don't bump :D
13:34 <Shiz> :p
13:44 clandmeter2 joined
14:14 <ncopa> they bump abi on minor releases?
14:14 <ncopa> wow
14:14 <ncopa> thats painful
14:15 <clandmeter2> ncopa: stop ignoring me!
14:16 <ncopa> clandmeter: it was a reaction to your comments
14:28 blueness joined
14:58 <Shiz> ncopa: and they dont bump when they should, sometimes
14:58 <Shiz> the situation is flaky
14:59 <Shiz> thats why imo a good more safe approach is to rebuild stuff that links against ffmpeg whenever ffmpeg is updated
15:08 blueness joined
15:16 tty` joined
15:19 <clandmeter> Shiz: why not add logic to ffmpeg apkbuild that will check for changes?
15:20 <Shiz> how?
15:21 <clandmeter> we are talking about so changes right?
15:23 <Shiz> abi changes
15:23 <Shiz> that doesnt necessarily mean a new api being added or removed
15:23 <Shiz> it can also involve changing the semantics of an existings ymbol
15:23 <clandmeter2> sure, but i thought the discussion was about soname
15:24 <clandmeter2> i mean in this particular case.
15:24 <Shiz> i mean, as i see it there's two issues
15:24 <Shiz> 1) they bump SONAME on patch versions
15:24 <Shiz> 2) they sometimes dont bump SONAME even when abi changes
15:24 <clandmeter2> right
15:25 <Shiz> i guess you can fix 1) by adding a _soname= to the abuild and checking for it in install()
15:25 <clandmeter2> 1. is easy to solve by keeping a record of it.
15:25 <Shiz> and have it error out if it mismatches so you know when to rebuild
15:25 <clandmeter2> for abi changes you will need to compare it with prev apk
15:26 <Shiz> realistically, you can't
15:26 <Shiz> since its not like you can trivially check semantic changes
15:31 <clandmeter2> right, well atleast we can check for soname changes just like we do with checkapk
15:33 czart joined
15:39 minimalism joined
16:06 tty` joined
16:37 <leitao> Out of curiosity, is there any company offering Alpine support?
16:44 <tdtrask> leitao: depends how much you're offering :)
16:44 <leitao> tdtrask, In fact, I just want to understand how is the support model behind Alpine
16:45 <tdtrask> nothing official
16:52 <kaniini> leitao: something, something, free market solutions
17:07 hrmlgon-y joined
17:07 pickfire_ joined
17:09 Somasis_ joined
17:09 trfl_ joined
17:10 coredumb joined
17:13 iamthemcmaster joined
17:14 <jirutka> emergency, what can I do when after upgrade the system reboots right after syslinux boot menu?
17:15 <ncopa> verify that kernel is ok
17:15 <scadu> or just run away before you boss notice
17:16 <ncopa> jirutka: how did you upgrade?
17:16 <ncopa> from alpine v3.4 to v3.5?
17:16 <jirutka> nope, 3.4.? to 3.4.6
17:16 <ncopa> oh
17:16 <ncopa> thats bad :-/
17:16 <jirutka> what?
17:17 <ncopa> that it fails within stable branch
17:17 <ncopa> should not happen
17:17 <jirutka> i know
17:17 <ncopa> boot from emergency usb
17:17 <jirutka> it’s quite possible that it’s a HW problem… b/c fucking OpenNebula
17:17 <ncopa> and run filesystem check
17:17 <jirutka> this platform is unreliable as hell
17:18 <ncopa> mount the root files system and /boot
17:18 <ncopa> eg mount $rootdev /mnt && mount $bootdev /mnt/boot
17:18 <ncopa> and bind mount /proc: mount --bind /proc /mnt/proc
17:19 <ncopa> then try reinstlal kernel: apk fix --root /mnt linux-grsec
17:19 <jirutka> I’m trying to revert to latest snapshot now
17:20 <jirutka> uff, it boots now
17:20 <jirutka> finally I was able to revert it, b/c it was stuck for 10+ minutes
17:28 <jirutka> I think that it’d be useful to preserve previous kernel and config during upgrade
17:28 <jirutka> so if something went wrong, you can boot the old kernel
17:29 <scadu> A/B upgrade would be awesome ;3
17:30 <jirutka> btw if anyone tell you to use OpenNebula in production, run away fast
17:34 skarnet joined
17:37 <ncopa> yes, it would be nice with rollback posibility
17:37 <ncopa> i also think it would be nice with automatic updates
17:39 <scadu> aanndd lliivveeppaattcchh ;v;v
17:39 <jirutka> I’m afraid that we cannot afford automatic updates now, without proper QA a automatic testing
17:47 <ncopa> yes
17:47 <ncopa> proper QA needs be done first
17:47 <ncopa> and automatic testing
17:51 <ncopa> nmeum: do you use tmux?
17:51 <nmeum> yep, why do you ask?
17:51 <ncopa> have you noticed that first line does not always display output correctly?
17:51 <nmeum> nope
17:52 <ncopa> if i do tmux and try a command with <tab> completion
17:52 <ncopa> the first line does not print it correctly
17:53 <nmeum> by first line you mean the first line written by your shell to stdout with the application that match your completion 'pattern'?
17:53 <ncopa> the line at the top of the window
17:53 <ncopa> tmux window
17:54 <ncopa> when the first command i type is at the top of the tmux window, the it is not displayed correctly
17:54 <nmeum> hm, that's strange what terminal emulator are you using?
17:55 <* nmeum> has to go now but will look at the backlog later
17:57 <ncopa> xfce4-terminal
17:57 <ncopa> but it happens from osx terminal too
17:58 <mitchty> is there a way to specify a git repo for an apkbuild? this has zero releases https://github.com/google/bloaty or should i just clone it at build time?
17:59 <jirutka> mitchty: point to specific commit
17:59 <Kruge> Has anything changed in the php7 packages recently?
18:00 <jirutka> mitchty: and made up some version number, I usually use date in format YYYYMMDD in these cases
18:00 <Kruge> I'm suddenly unable to get random_bytes() on a 3.13 kernel, but able to on a 4.4
18:00 <jirutka> mitchty: and also do not forget to write upstream that they should consider making proper releases…
18:00 <mitchty> sounds good, the arch package picked 0.0.0.... https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=bloaty-git#n15
18:01 <mitchty> and theres already an issue thankfully https://github.com/google/bloaty/issues/22
18:01 <jirutka> mitchty: another option is something like 0.0_gitYYYYMMDD
18:03 <jirutka> mitchty: heh, give them some time, it’s Google, they don’t know much about software development… and making releases is very hard, almost rocket science… ah wait…
18:03 <mitchty> jirutka: i expect no traction on that commit tbh :)
18:03 <mitchty> err issue rather
18:04 <mitchty> the tool is nice, if a bit buggy at times
18:04 <jirutka> for the record, I’m not making fun from Google just from this particular case, I see this in Google projects very often…
18:05 <scadu> jirutka: b-b-b-but you have less problems. you don't have to worry about deploying new release!
18:09 <jirutka> scadu: and even better is no to have any issue tracker, then you don’t have to solve all the bugs that people make in your software!
18:09 blueness joined
18:10 <scadu> \o/
18:10 <algitbot> \o/
18:10 MH0815 joined
18:11 <skarnet> jirutka: Google knows a lot about software development. What they're challenged with is interaction with the outside world, tools that aren't internal to Google. When you're working at Google, it's very easy to forget that there actually are other developers outside of the company, and smart ones even, worth interacting with - and forgetfulness happens very fast.
18:12 <jirutka> lol
18:12 <jirutka> this explains a lot
18:17 <Kruge> In case anyone is interested, I tested a docker container with php7 7.0.16 from edge/testing in it on a 3.13 kernel and random_bytes() fails to get sufficient data. The same container works fine on a 4.14 kernel.
18:19 <jirutka> Kruge: not enough entropy?
18:19 <Kruge> That's what it says
18:20 <Kruge> 7.0.15 on 3.13 worked ok
18:21 <jirutka> this is probably the same problem as described in http://bugs.alpinelinux.org/issues/6635#note-3
18:23 <jirutka> it’s cased by libressl, fabled reported it in https://github.com/libressl-portable/portable/issues/274
18:25 <Kruge> Well. At least it's a *known* bug. That'll learn me for using testing.
18:26 <jirutka> the workaround/solution(?) for VMs is to add e.g. virtio-rng
18:27 <Kruge> This is docker on top of a physical box, should have sufficient entropy
18:28 <jirutka> don’t know how to deal with that on embedded devices without HW random generator; on physical servers there should be enough entropy
18:28 <skarnet> there should be something early in the boot sequence that blocks until the entropy pool has been initialized, always
18:28 <jirutka> what OS do you have on this physical box?
18:28 <Kruge> skarnet: Agreed. But this box has been up for 12 hours.
18:28 <skarnet> on containers, there should be an option to share the rng with the host's, I think
18:28 <Kruge> jirutka: Ubuntu 14.04, with a 3.13 kernel
18:28 <skarnet> if virtio-rng is the name then that's it
18:29 <jirutka> skarnet: nope, containers share kernel
18:29 <jirutka> skarnet: so I’d think that there should not be any problem with entropy
18:29 <skarnet> if the host has been initialized, then yes indeed
18:29 <skarnet> dinner time, bbl
18:29 <jirutka> virtio-rng cannot be used in containers (obviously)
18:30 <Kruge> php 7.0.15 doesn't have any such problems, just the upgrade to 7.0.16
18:30 <jirutka> have you installed both php versions from edge or v3.5?
18:31 <Kruge> and 7.1.1, too, it seems
18:31 <Kruge> edge
18:31 <jirutka> so they both should be compiled against libressl
18:31 <jirutka> hm, weird, maybe there’s also some bug in php
18:33 <Kruge> 7.1.1 fails on a 4.4 kernel
18:33 <Kruge> Just throwing these random (!) testing results out there
18:53 t0mmy joined
19:16 <mitchty> question on provides, is this correct, or do I have to specify the release for those as well? https://github.com/alpinelinux/aports/compare/master...mitchty:ghc-cleanup?expand=1#diff-a8cf59ca3e0622ff4b66c4e7b5e9fce7R36
19:26 LouisA joined
19:27 Somasis joined
19:27 fekepp joined
19:49 <mitchty> also do the provides need to show up in replaces as well like for pkgbuild?
20:08 <jirutka> what the hell is wrong with OpenNTPd?! it has only one job, keep clock in sync… it knows that it’s out of sync and do nothing about it
20:12 <scadu> jirutka: maybe difference is too big? dunno if there is some magic switch, but if the service is running is should prevent such issue from occurring anyway.
20:12 <jirutka> scadu: exactly; it happened to me on several servers already
20:13 <jirutka> scadu: it’s not that system is started with clock too out-of-sync
20:13 <jirutka> scadu: I’ve fixed clock manually and after a wekk, it was out-of-sync again
20:13 <scadu> jirutka: lawl
20:13 <jirutka> scadu: so OpenNTPd clearly doesn’t do its job right, but don’t know why
20:16 LouisA joined
20:18 <jirutka> Feb 19 01:04:45 localhost daemon.info ntpd[2107]: adjusting local clock by -151.431094s
20:18 <jirutka> Feb 19 01:04:45 localhost daemon.info ntpd[2108]: clock is now synced
20:18 <jirutka> Feb 19 08:25:59 localhost daemon.info ntpd[2107]: adjusting local clock by -154.110484s
20:18 <jirutka> Feb 19 08:25:59 localhost daemon.info ntpd[2108]: clock is now synced
20:18 <jirutka> Feb 19 08:30:16 localhost daemon.info ntpd[2107]: adjusting local clock by -154.095786s
20:18 <jirutka> Feb 19 08:30:16 localhost daemon.info ntpd[2108]: clock is now unsynced
20:18 <jirutka> Feb 19 08:34:41 localhost daemon.info ntpd[2107]: adjusting local clock by -154.086257s
20:18 <jirutka> Feb 19 08:34:41 localhost daemon.info ntpd[2108]: clock is now synced
20:18 <jirutka> Feb 19 08:36:18 localhost daemon.info ntpd[2108]: clock is now unsynced
20:18 <jirutka> Feb 20 19:38:43 localhost daemon.info ntpd[2107]: adjusting local clock by -165.072344s
20:18 <jirutka> Feb 20 19:38:43 localhost daemon.info ntpd[2108]: clock is now synced
20:18 <jirutka> Feb 20 20:07:55 localhost daemon.info ntpd[2107]: adjusting local clock by -166.266714s
20:18 <jirutka> Feb 20 20:07:55 localhost daemon.info ntpd[2108]: clock is now unsynced
20:18 <jirutka> what the heck?
20:19 <skarnet> you have another time source auto-updating the clock and conflicting with ntpd?
20:20 <jirutka> don’t think so
20:21 <jirutka> what other time source can I have?
20:22 <jirutka> it’s a VM, but I don’t have any special guest utils
20:24 <jirutka> I don’t understand what’s it doing, ntpctl -s all shows that clock is unsynced and offset is increasing (!), not decreasing
20:26 <jirutka> aha, now it jumped down
20:28 <mitchty> is the vm hosts' time changing?
20:28 <mitchty> its probably saying unsynced due to the jumps, and declares the host clock as unreliable
20:29 <jirutka> I dunno, I don’t have access to hypervisor
20:29 <jirutka> but VM should not see host’s time…?
20:29 <mitchty> might depend, i know vmware with the tools can do that, (and it sucks)
20:29 <jirutka> hm, actually… it uses it to sync when booting/shutting down
20:30 <jirutka> this is KVM
20:32 <mitchty> might want to look at what clock source you have cat /sys/devices/system/clocksource/clocksource0/current_clocksource
20:32 <mitchty> and make sure that jives with what kvm needs
20:32 <mitchty> i had to deal with ntp at the last job, vm's and ntp/time is a rathole
20:33 <mitchty> the actual protocol and algorithms are pretty simple though
20:33 <mitchty> but god help you if your traffic RTT isn't symmetric
20:34 <mitchty> that, was not fun to learn, outbound was like 10ms, inbound like 15ms, that'll ruin everything on its own
20:34 <jirutka> cat /sys/devices/system/clocksource/clocksource0/current_clocksource kvm-clock
20:34 <jirutka> ahaa
20:35 <mitchty> that looks right from what i've used of kvm
20:35 <jirutka> but this means that it uses host’s clock, doesn’t it?
20:35 <mitchty> i think so, been a bit let me look
20:38 <mitchty> yep
20:39 <mitchty> so i'd venture a guess that your hypervisor host is setting the clock via something stupid like ntpdate
20:39 <mitchty> likely due to drift, if its that bad that fast it looks like bad hardware
20:39 <jirutka> available clock sources: kvm-clock hpet acpi_pm
20:40 <mitchty> for slewing as an example you can do 200 jiffies per million to update, if your clock drifts beyond that eventually ntp will give up
20:40 <jirutka> unfortunately I don’t manage these hypervisors and I wouldn’t be surprised if there’s something wrong…
20:40 <mitchty> could try hpet
20:42 <mitchty> wouldn't be my first choice but it looks like lvm-clock syncs with the hypervisor
20:42 <jirutka> is there some proper place where it should be configured on Alpine?
20:43 <jirutka> I’ve looked into hwclock runscript, but it seems that this syncs clock with HW just during boot and shutdown
20:43 <mitchty> i always dumped it in the kernel boot params, clock={tsc,hpet,etc..}
20:43 <jirutka> okay, I’ll try that
20:44 <jirutka> I’ve never needed to change this
20:44 <mitchty> generally you shouldn't need to
20:44 <jirutka> it always just worked, so I don’t know any details about time sync mechanisms
20:45 <mitchty> but when ntp is not syncing time, it indicates either a misconfigured system, or hardware issues
20:46 <mitchty> whoops sorry clocksource= rather, I cannot brain today
20:47 <mitchty> actually i bet it this, the hypervisors clock isn't being synced by ntp
20:48 <mitchty> kvm-clock syncs it periodically to the hypervisor
20:48 <jirutka> hwclock -r shows HW clock time… and yes, it’s out of sync
20:48 <mitchty> and openntp notices and thinks the system clock is jumping by 160seconds each time it wakes up, which for ntp at the extreme end would be 64seconds
20:49 <mitchty> which would make openntp declare the clock a bad ticker and figure its not possible to keep synced after a while
20:53 <mitchty> sounds about right then
21:03 <jirutka> mitchty: okay, thanks a lot for help with troubleshooting!
21:05 <jirutka> aka problems that never happen when you have complete infrastructure under your control… I’ve never had this problem before, but after migrating VMs to faculty’s shitty infra, I’m dealing with one obscure problem after another :/
21:06 <skarnet> the real question is, why have a ntpd running in a container if the host has synchronized time anyway :P
21:08 <jirutka> it is not a container, but VM
21:09 <jirutka> uh, Travis has some issues… this day is weird
21:10 <scadu> jirutka: https://www.youtube.com/watch?v=8CPlF-IEkXQ
21:14 <skarnet> if it's a VM, doesn't the vm manager have a way to sync time from the host?
21:15 <mitchty> jirutka: np, good luck on getting it working, sounds like a non fun situation
21:44 blueness joined
21:52 <jirutka> skarnet: I dunno, but why?
21:53 <skarnet> because syncing time from an external machine is expensive and inaccurate, whereas transmitting the time from a host to a guest should be fast and accurate?
21:54 <jirutka> especially when host time is wrong…
21:54 <skarnet> well obviously the host should be correctly synced >.>
21:54 <jirutka> I’m using ntp in all VMs for years and never had problem when I managed also hypervisor behind them
21:55 <jirutka> s/behind/under/
21:55 <skarnet> but imagine a host with 5 guests, I'd rather have the host run 1 NTP client and export its system clock as, say, virtual CMOS to the guests
21:55 <skarnet> than have the host + all guests perform NTP exchanges with a server down the road
21:55 <jirutka> and how exactly would you synchronize time from host system, when using KVM?
21:56 <jirutka> vmWare has some crappy utility for this and as scadu confirmed, it doesn’t work well
21:58 <skarnet> kvm could export the host's hwclock as the guest's hwclock?
21:58 <jirutka> yes
22:22 czart_ joined
23:00 blueness joined
23:14 faffolter joined
23:14 faffolter joined