<    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 24 25  
26 27 28 29 30 31
00:04 blueness joined
00:07 blueness joined
00:46 fekepp joined
01:37 fekepp joined
01:42 grrrkit joined
02:01 s33se_ joined
02:37 blueness joined
02:44 <TemptorSent> note: apk is throwing a spurious warning "Ignoring /home/chrisgio/packages/testing/aarch64/APKINDEX.tar.gz: No such file or directory" for an arch I haven't built packages on, but I'm pulling apks for.
02:45 <TemptorSent> This is breaking things rather badly that rely on piping the output from apk.
02:46 <TemptorSent> 'apk fetch $pkg --stdout | tar -xzC $dir' for instance
02:49 <tmh1999> TemptorSent : I guess it happens for the first built package only. After one package is built, it's gone.
02:51 <TemptorSent> tmh1999: Too bad I'm not setup for actually BUILDING on aarch64
02:52 <TemptorSent> tmh1999: I built x86_64 apks, and now I'm pulling aarch64 packages for an image - no building, no aarch64 directory in ~/packages.
02:52 Kruge joined
02:54 <TemptorSent> tmh1999: So now I'm dead in the water testing the aarch64 building until I can figure out why APK is throwing a fit (and --quiet doesn't help)
02:55 <tmh1999> I see
02:55 <tmh1999> Hum..
02:55 <TemptorSent> tmh1999: Give it a shot -- maybe it's something local to me... build a package for your native arch, then try to fetch one for a foreign arch.
02:55 <tmh1999> Is the message on stderr or stdout ?
02:56 <TemptorSent> It's being handled as if it's stdout, but I haven't tried splitting hairs with it yet.
02:57 <TemptorSent> ...needless to say having to do a redirected stderr while consuming stdout in every location apk fetch --stdout is used is not going to be pretty.
02:57 <tmh1999> $ apk fetch --arch aarch64 musl downloads the musl package for me to $PWD
02:57 <TemptorSent> Do you have a local packages repo as that user for your native arch?
02:58 <TemptorSent> and none built for aarch64?
02:58 <tmh1999> hold on it downloads the native package not aarch64
02:59 s33se joined
02:59 <TemptorSent> Yeah, you need to pass the --arch and probably a different root
03:00 <TemptorSent> tmh1999: If you can, please test against https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
03:01 <TemptorSent> using profile uboot and arch aarch64
03:03 <TemptorSent> I'm trying to shoot down any last big-ugly showstopper bugs in mkimage and keep hitting pain-points in other tools (apk, lddtree, mkinitfs, etc -- I replaced update-kernel entirely)
03:04 <tmh1999> I am not sure you are able to fetch packages from different arch.
03:05 <TemptorSent> Before I built packages and setup my own local repo, it worked FINE!
03:06 <TemptorSent> The warning is new, spurious IMHO (the entire arch directory doesn't exist, a non-existent APKINDEX is to be expected!), and breaks things that worked before.
03:06 <TemptorSent> The only change was the addition of a repository that only has my native arch, not foreign archs that I want to pull.
03:08 <TemptorSent> do 'mkdir /tmp/apktst && apk add --arch aarch64 --root /tmp/apktst --initdb -R alpine-base'
03:10 <tmh1999> it doesn't work for me :(
03:10 <tmh1999> alpine-base missing required by world[alpine-base]
03:10 <tmh1999> option -R doesn't even exist
03:12 <TemptorSent> oops, sory - the -R is on my fetch
03:12 <TemptorSent> run the --initdb, they try a fetch command
03:13 <TemptorSent> do 'mkdir /tmp/apktst && apk add --arch aarch64 --root /tmp/apktst --initdb && apk fetch --arch aarch64 --root /tmp/apktt -R alpine-base'
03:15 <TemptorSent> Right now, I'm going to have to punt and let someone else test it I guess.
03:15 <TemptorSent> I need to finish cleaning up a couple other issues I need sooner.
03:23 t0mmy joined
04:25 <TemptorSent> Working one it :)
04:25 <TemptorSent> s/one/on/
05:07 vflyson joined
05:08 <vflyson> o/ ello. Trying to build libstrophe on Alpine, found https://raw.githubusercontent.com/faradayio/aports/master/testing/libstrophe/APKBUILD but it uses an old version; decided to build from scratch as described on https://github.com/strophe/libstrophe but getting an error running ./configure "configure: error: C compiler cannot create executables"
05:10 <vflyson> Most likely it is related to autoreconf putting wrong arguments for gcc into ./configure (e.g. it uses flags -qversion and -V instead of --version and -v, ergo the error)
05:22 <vflyson> First thought I solved it by changing "--version -v -V -qversion" to "--version -v" but then realized that I was missing the libc-dev apk on my system; somehow now it ran ./configure with no errors, the thing got compiled just fine
05:23 <vflyson> Could somebody please create a request for that apk to be updated for libstrophe version 0.9.1 and brought back into the repos? It's a good library and is available on most distros. I just don't have the account on the bugtracker, a github person.
05:24 <vflyson> Sorry for the bother, have a good one!
05:24 vflyson left
06:23 blueness joined
07:03 volleyper joined
07:05 vakartel joined
07:12 blahdodo joined
07:35 vakartel joined
07:41 <pavlix> kaniini: I don't have any details, I haven't actually seen the kernel builds at all. But I would help if kernel-tools proved useful to the project.
07:45 <kaniini> pavlix: can kernel-tools work across kernel versions? for example, raspberry pi kernel is different version frequently than what we normally ship (but we want to keep the base features in sync)
07:58 fekepp joined
08:35 blueness joined
08:39 royger joined
08:52 t0mmy joined
08:54 <pavlix> kaniini: it is a young project and it can basically do whatever you wish; in other word, now it's the best time to define requirements for the project
08:55 <pavlix> kaniini: currently it's very basic and it serves me as a Gentoo user to reliably and reproducibly build a kernel for my system and actually *check* the configuration
08:56 <pavlix> kaniini: I had some multiversion consideration but as long as it is just a personal project, I'm going to address them *as they come*, but if there are specific requirements in the issues, I can answer them and address them
09:09 t0mmy joined
09:42 fekepp joined
09:58 blueness joined
10:02 fekepp joined
10:04 fekepp joined
10:09 t0mmy joined
10:11 <yGweSm1OzVHe> mozilla further selfsabotaging firefox: https://bugzil.la/1345661 - can we disable this in alpine?
10:13 <^7heo> we have to
10:13 <^7heo> no question
10:14 <^7heo> thanks for reportinv
10:14 <^7heo> reporting
10:15 <scadu> wut, I didn't know that Firefox depends on PA
10:16 <skarnet> it's the new default
10:16 <skarnet> fortunately it can still be worked around
10:16 <^7heo> Yeah
10:17 <^7heo> but you know what can not be worked around?
10:17 <^7heo> firefox's legal requirements
10:17 <scadu> I'm curious how long it could be worked around
10:17 <^7heo> we should change the name at the very lesadt
10:17 <^7heo> least*
10:18 <^7heo> scadu: let's see.
10:18 <scadu> let's change to Snow bear!
10:18 <asie> Firefox 54 deletes ALSA completely, no?
10:19 <scadu> oops.
10:19 <yGweSm1OzVHe> https://bugzilla.mozilla.org/show_bug.cgi?id=1345661#c64
10:20 <yGweSm1OzVHe> distros pathcing alsa back
10:20 <^7heo> yeah
10:27 <^7heo> after firefox and iceweasel, what about badger?
10:43 <clandmeter> for anyone not following #alpine-linux http://tpaste.us/rqax
10:45 leprechau joined
10:47 <skarnet> clandmeter: this had been a long time coming
10:47 <scadu> mm, nice. so we are going into apparmor now? I didn't check yesterday's​ backlog from -devel
10:48 <skarnet> does it make me a bad person if I find that hilarious?
10:48 <clandmeter> well, at least we will have lazy loading...
10:48 <ncopa> this grsecurity thing going on is bad :-(
10:48 <ncopa> they are making all grsecurity patches private
10:50 <clandmeter> ncopa, it is and it has been since some time...
10:50 <clandmeter> good thing is, you will have to spend less time on it.
10:52 <skarnet> join me and dance on grsec's corpse
10:52 <scadu> xD
10:53 <scadu> skarnet: let's dance then
10:55 <skarnet> \o\ /o/ \o/ \o_ _o/ -o- _/o\_ *^^*
10:55 <algitbot> \o/
11:14 volleyper joined
11:26 cyteen joined
11:39 blueness joined
11:49 blueness joined
12:06 blueness joined
12:13 leitao joined
12:13 farosas joined
12:22 ferseiti joined
12:35 NightKhaos joined
12:39 leo-unglaub joined
13:01 leitao joined
13:09 t0mmy joined
13:14 tty` joined
13:17 ppisati joined
13:56 blueness joined
14:04 hairyhenderson joined
14:40 ryanlelek joined
14:52 <leo-unglaub> i am curious to find out why this person on the ML wants to find out the alpine linux licence ...
14:52 <leo-unglaub> this person is working for Raytheon, they build bombs and all that war shit that kills people ..
14:53 <leo-unglaub> i would asume they want to use alpine linux on those bombs in the future ...
14:58 <skarnet> that's the price of success: people get interested in you, even the ones you'd rather they didn't.
14:59 <skarnet> that's also the price of freedom - if software is to be used by everyone, then "everyone" includes arms manufacturers.
15:20 <jirutka> leo-unglaub: hm, that’s the risk… we may specify in license Alpine must not be used for evil purpose, but then it would not be truly free software anymore
15:20 <kaniini> you guys are looking at it the wrong way
15:20 <kaniini> they are using free software
15:20 <kaniini> to drop free (as in freedom) bombs on "the terrorists"
15:21 <duncaen> just buy their hardware to request the source
15:21 <kaniini> to bomb ISIS with terrorists
15:21 <kaniini> er
15:21 <kaniini> with freedom
15:21 <jirutka> leo-unglaub: and also it’s quite a problem how to define “evil”… well, we may directly specify “military”, but that’s not black and white
15:21 <^7heo> whatever works.
15:21 <kaniini> Freedom!
15:21 <kaniini> or socalled cyber 'weapons'
15:24 <duncaen> i just hope they dont use gpsd
15:25 <kaniini> well, the answer for raytheon is the same answer as everyone else
15:25 <kaniini> the software itself is dependent on the license of the software itself
15:27 <duncaen> "Open-source software enables low-cost maintenance, stability, and most importantly, continuous improvement to forecast accuracy and timeliness"
15:27 <jirutka> I’m afraid that some programs may recompile binaries with different options when you run `make check` and some maintainers may not notice it
15:27 <skarnet> yay optimizing for the test bench
15:28 <skarnet> ./configure --volkswagen
15:28 <jirutka> I’m always checking what the check task do, but I don’t expect that everyone do it
15:29 <duncaen> do the check after the install target
15:31 <jirutka> yeah, that’s one of the possible solutions how to prevent it
15:32 czart joined
15:34 <duncaen> do you have many aports that use check?
15:36 <jirutka> not yet
15:38 <jirutka> clandmeter: I think that you’ll welcome this change :) https://github.com/lxc/lxc/commit/72ead1c05401789ced73d9e3f47d1c11aa6dd951 (I’ve already backported it to main/lxc@edge)
15:38 <duncaen> ah ok, we have a open task for this in void too, but we are still not sure how we handle it in case it needs more dependencies etc, and if we enable them by default
15:39 <jirutka> duncaen: you’re Void developer? :)
15:39 <duncaen> yes
15:39 <jirutka> duncaen: :)
15:41 <jirutka> duncaen: how do you handle the problem when more packages provides same executables and you want to be able to install them in parallel and switch between them, like various versions of JVM, py2 or py3 variant of some tool etc. Debian, Fedora and some others use update-alternatives for this, Gentoo eselect
15:42 <duncaen> we have xbps-alternatives which creates symlinks
15:42 <jirutka> duncaen: is this written from scratch or based on update-alternatives?
15:42 <duncaen> from scratch afaik
15:42 <duncaen> http://sprunge.us/VHVR
15:42 <duncaen> there are packages, and alternative groups which can be in multiple packages
15:43 <jirutka> great, where can I find source code of this tool?
15:43 Ganwell joined
15:43 <duncaen> https://github.com/voidlinux/xbps/tree/master/bin/xbps-alternatives
15:43 <kaniini> jirutka: apk-tools 3 will have alternatives
15:43 <duncaen> and https://github.com/voidlinux/xbps/blob/master/lib/package_alternatives.c
15:43 <jirutka> duncaen: thanks!
15:43 <duncaen> there are some things that are not so nice
15:44 <duncaen> e.g. creating a target directory to avoid dangling symlinks
15:44 dfgg joined
15:44 <jirutka> kaniini: I’m afraid that we can’t wait until apk-tool 3 for this… and also I don’t think that it should be integrated directly into apk…?
15:44 <kaniini> dont look at me, it is what fabled plans to do :P
15:45 <jirutka> kaniini: ok, I’ll discuss it with him :)
15:45 <duncaen> we shoot ourself by allowing to choose /bin/sh, when readline was updated users with bash as /bin/sh broke the install scripts at installation time :s
15:46 <jirutka> kaniini: maybe I can write a prototype in Lua, try how it works, and he can eventually rewrite it in C as part of apk-tools
15:46 <kaniini> yes
15:58 tmh1999 joined
15:59 tmh1999 joined
16:00 TemptorSent joined
16:00 ferseiti joined
16:05 leitao joined
16:30 doppo joined
16:53 blueness joined
16:59 LouisA joined
17:29 <tmh1999> anyone has a copy of lua-xml package in your build machine ? looks like the host providing the package is down
17:29 <tmh1999> LuaXML_130610.zip is the package name
17:41 <tmh1999> nvm archive.org is awesome
17:43 blueness joined
18:03 <scadu> tmh1999: you could always use different mirror. see http://rsync.alpinelinux.org/alpine/MIRRORS.txt
18:06 <tmh1999> scadu : I mean the source package, not .apk
18:06 volleyper joined
18:22 gromero joined
18:27 leo-unglaub joined
18:53 <tmh1999> looks like perl-test2-suite has a new version, and require new perl-sub-info and perl-term-table.
19:14 czart_ joined
19:15 leitao joined
19:18 Emperor_Earth joined
20:02 myrrd joined
20:05 blueness joined
20:12 t0mmy joined
20:19 myrrd left
20:34 skarnet joined
20:51 ferseiti joined
21:58 laj joined