2017-10-01 03:20:53 Hi #alpine-devel! craftyguy and I have been brainstorming, how we could improve collaboration between Alpine and derivatives. Could you guys please take a look? https://github.com/postmarketOS/pmbootstrap/issues/663 2017-10-01 03:48:00 ollieparanoid[m]: hi there! responded to your issue. may I ask you a question? 2017-10-01 07:31:49 ollieparanoid[m]: improving collaboration between alpine and its deratives could be good for both, without doubt 2017-10-01 07:32:17 the key thing really is getting rootbld deployed 2017-10-01 07:32:25 then derivatives can even build on our servers 2017-10-01 07:32:38 however, i have gotten my testing server back up 2017-10-01 07:32:47 which does it's own CI run on every single open pull request 2017-10-01 07:32:57 and merges the ones that pass into a local branch 2017-10-01 07:33:13 (from the people who i want to work with, that is) 2017-10-01 07:33:27 it doesn't waste it's time building packages from people who work with other devs ;P 2017-10-01 07:34:17 so that should help speed up pmOS stuff 2017-10-01 07:41:00 this won't help with arm, but will help with getting things merged. rootbld needed to fix arm situation 2017-10-01 14:37:30 kaniini: how can we help arm? Most of the devices running pmos are armhf :) 2017-10-01 15:22:45 Like donating hardware, or helping to script it out, or ?? 2017-10-01 17:17:53 kaniini: also, regarding your earlier comment about arm... does this mean that patches auto-accepted by the system will never get an arm package if the package supports arm? Take the two I submitted that were accepted: tslib & directfb. Currently they don't have an armhf package, are they queued up on some builder to get one eventually or is this a one-and-done thing until I submit PRs to update them in the future? 2017-10-01 17:19:53 to fix arm other than rootbld being deployed, need to fix the broken packages 2017-10-01 17:20:13 Is there a list of these broken packages somewhere? 2017-10-01 17:20:23 but somehow arm builders are missing ld 2017-10-01 17:20:58 if you monitor #alpine-commits you will see errors 2017-10-01 17:23:41 I'm not sure how to help fix that 2017-10-01 17:24:13 like the current package `cloudi` stuck in the armhf builder 2017-10-01 17:26:58 Ah! binutils isn't being installed. binutils-dev is in the APKBUILD for `cloudi`, but binutils-dev doesn't provide ld. I would have thought that the builder should just have binutils installed anyways and that APKBUILDs would not need to explicitly list binutils in their makedepends.. maybe I am wrong? 2017-10-01 17:27:06 in any case, that package just needs 'binutils' in its makedepends 2017-10-01 17:29:13 kaniini: I can submit a PR to add binutils to that package's makedepends, but shouldn't binutils be installed anyways on the builder since pretty much every package would use it? 2017-10-01 17:29:28 that's like making every package explicitly list gcc as a makedepend 2017-10-01 17:29:37 no the arm builder admins need to fix the builder 2017-10-01 17:31:01 ok.. and how might one notify the "arm builder admins" ? 2017-10-01 17:31:16 ACTION is really trying to help y'all out here :) 2017-10-01 18:57:46 what is rootbld (/me is out of the loop) 2017-10-01 18:59:02 shouldn't you explicitly list gcc? coming/using nix the thought of not explicitly listing dependencies is weird 2017-10-01 19:00:46 <_ikke_> alpine-sdk is assumed to be present 2017-10-01 19:01:11 <_ikke_> it's a build dependency, not a runtime dependency 2017-10-01 19:01:11 It's a build system though, it should have a compiler installed. Where would you draw the line though, explicitly listing the kernel? Electricity for running the machine? :P 2017-10-01 19:04:19 kernel, maybe depending on if you depend on a syscall that might not be present in some versions, and an example of what assuming gcc only tends to result in http://undeadly.org/cgi?action=article;sid=20170930133438 2017-10-01 19:27:35 mitchty: grepping through abuild, rootbld looks like a new set of functionality to build packages in chroots / Linux containers 2017-10-01 19:28:11 I imagine it can help use the build machines more effectively, because otherwise running concurrent builds could be dangerous 2017-10-01 19:28:22 there's no guarantee the builds won't step on each other and corrupt each other, etc. 2017-10-01 19:28:25 afaik 2017-10-01 19:29:03 so i assume every container either has alpine-sdk installed or a read-only version of it is mounted 2017-10-01 19:29:05 hopefully the latter 2017-10-01 19:29:11 i'm more curious if i could use it to start/help with testing upstream git masters for things 2017-10-01 19:29:25 i'm using jenkins atm for that and its annoying 2017-10-01 19:29:37 hm yeah I'm not sure, i'm just lurking and learning about alpine 2017-10-01 19:29:59 but i would be interested in running/testing packages in containers too 2017-10-01 19:30:07 <_ikke_> oilshell: abuild already uses a fakeroot to build packages 2017-10-01 19:30:18 i'm not sure how the build machines are set up, I didn't see any documentation on the wiki about that 2017-10-01 19:30:59 <_ikke_> It's not really documented 2017-10-01 19:31:39 <_ikke_> I think something based on aports-lua 2017-10-01 19:31:54 oh what does fakeroot do? on Debian that simulates UID 0 2017-10-01 19:32:07 I believe it uses ld.so interception for libc 2017-10-01 19:32:14 so you don't have to run all your package builds as actual root on the build machine 2017-10-01 19:32:20 or is that something different in alpine? 2017-10-01 19:33:38 <_ikke_> I'm not sure of what it actually does 2017-10-01 19:33:42 if fakeroot is like on debian, I think that rootbld is better than fakeroot 2017-10-01 19:33:43 <_ikke_> but it serves a similar purpose 2017-10-01 19:33:48 rootbld uses containers 2017-10-01 19:34:00 containers have UID namespaces and so forth, so there is a different root/UID 0 within each container 2017-10-01 19:34:19 whereas at least on debian, fakeroot does some tricky magic to fool the process into thinking it has root when it doesn't 2017-10-01 19:34:46 i think fakeroot is ancient technology and rootbld/containers are the new thing. it should give better isolation if i understand correctly 2017-10-01 19:35:11 fakeroot essentially only isolates one thing, but you need other stuff to be isolated like the file system (chroot) and networking, etc. 2017-10-01 19:35:52 <_ikke_> is network isolation necessary? 2017-10-01 19:35:56 if you look at the rootbld() function in abuild now, there is a huge command line 'bwrap --unshare-ipc --unshare-uts $bwrap_opts ...' 2017-10-01 19:36:04 the unshare() stuff is for Linux containers 2017-10-01 19:36:30 i'm not sure about network specifically 2017-10-01 19:36:38 but containers give you that flexibility if you want it 2017-10-01 19:36:54 <_ikke_> alpine standard is to build not as root, and everything should be installed in $pkgdir 2017-10-01 19:36:55 the --ro-bind is making a readonly mount from the host into the "guest" container 2017-10-01 19:37:22 ok that's good 2017-10-01 19:37:25 root builds are bad 2017-10-01 19:37:33 It looks to me like fakeroot is an option? 2017-10-01 19:37:51 but I imagine that rootbld would allow more concurrent builds on the build machines 2017-10-01 19:37:56 but I don't know how they are set up 2017-10-01 19:38:11 like do they actually install the package? I think installing the package is where bad things can happen 2017-10-01 19:38:31 you don't want to have concurrent installs, at least in Debian and other distros that is asking for trouble 2017-10-01 19:40:09 <_ikke_> One of the bigger issues they currently have is builders getting stuck 2017-10-01 19:47:25 _ikke_: yeah I don't understand why they get stuck? can't they go on to the next package? 2017-10-01 19:47:38 i think the isolation provided by rootbld probably helps with that 2017-10-01 19:47:42 <_ikke_> I don't know the details 2017-10-01 19:48:16 without knowing all that much about alpine, if it doesn't build as root, then i imagine the issue is the install step, which must happen as root to write to /bin/ and so forth 2017-10-01 19:48:23 and there are trigger scripts too 2017-10-01 19:48:42 so someone could submit a bad or malicious package 2017-10-01 19:48:50 and just rm -rf / in the install step, AFAIK 2017-10-01 19:48:56 <_ikke_> right 2017-10-01 19:49:07 <_ikke_> that's why changes are revieuwed 2017-10-01 19:49:09 <_ikke_> reviewed 2017-10-01 19:49:40 so probably the builders stop on a failure because the machine might be in a bad state? 2017-10-01 19:49:58 <_ikke_> They never build as root, so the machine itself is not affected 2017-10-01 19:50:21 but do they install? there is custom code in the install step 2017-10-01 19:50:52 <_ikke_> Yes, but never in / 2017-10-01 19:51:12 <_ikke_> it's more the package they do 2017-10-01 19:51:22 <_ikke_> not the install scripts (that happens only if you install the package) 2017-10-01 19:52:20 ok yeah if it only builds as non-root then you should be able to clean up after it, and you should be able to have concurrent builds 2017-10-01 19:52:35 well another reason for the containers is build deps 2017-10-01 19:52:48 that's probably the main reason actually 2017-10-01 19:52:53 if you have a missing dependency in the APKBUILD 2017-10-01 19:53:01 and the build machine HAPPENS to have it, then the error won't get flagged 2017-10-01 19:53:20 a previous package could have required say "python" to build 2017-10-01 19:53:36 but then if it's not declared, it will fail on someone else's machine 2017-10-01 19:54:13 so basically the containers only mount the declared dependencies to do the build, and not what happens to be on the build machine 2017-10-01 19:54:34 someone was talking about "ld" missing which is a related issue, although I would think most packages implicitly have a build dep on ld 2017-10-01 19:54:47 "fakeroot" in the Debian sense doesn't do that. there "root" means UID 0 2017-10-01 19:54:59 <_ikke_> Yeah, I think a base alpine install is an implicit dep 2017-10-01 19:55:10 whereas the root in chroot/rootbld means the root of the file system, e.g. what is / ? 2017-10-01 19:55:20 it's two different uses of root AFAIK 2017-10-01 19:55:32 <_ikke_> yes 2017-10-01 19:56:05 ld is in binutils, which isn't part of the base install 2017-10-01 19:56:13 yeah so without knowing very much I imagine that the containers should make the build machines a lot faster 2017-10-01 19:56:25 since they don't have to install and uninstall a 100 MB of dependent packages for every package build 2017-10-01 19:56:31 But should be in some "alpine SDK" 2017-10-01 19:56:35 you just do the --ro-bind thing 2017-10-01 19:57:48 no 2017-10-01 19:58:09 you build against a minimal set so you get the dependencies absolutely right for any given package 2017-10-01 19:58:39 if building needs extra packages, so be it, but as soon as you rely on a preinstalled set you risk missing a dep and someone else's going to have to solve it 2017-10-01 19:58:44 that's what i'm saying 2017-10-01 19:58:53 i'm saying the rootbld mechanism is what helps with that 2017-10-01 19:59:03 I hope it makes them more resilient. As it stands today on the armhf build server, one package failing to build brings the whole thing down and only a human can make it process the queue further. This means that there could be packages with updates fixing CVEs that sit in the queue indefinitely because some other package ahead of it didn't compile successfully. 2017-10-01 19:59:30 it ensures that you don't happen to have extra packages lying around, you only see the build dependencies you declared in APKBUILD 2017-10-01 20:00:14 is there only one armhf build server? 2017-10-01 20:00:34 <_ikke_> and note that alpine is lightning fast with installing packages 2017-10-01 20:01:01 Seems like there is only one building edge.. 2017-10-01 20:01:04 it's definitely fast 2017-10-01 20:01:11 And it's stuck again 2017-10-01 20:01:19 although you definitely need at least 100 MB to build a lot of packages 2017-10-01 20:01:37 <_ikke_> You can cache packages 2017-10-01 20:01:50 oh like a local mirror? 2017-10-01 20:01:56 how do you do that? i was wondering about that 2017-10-01 20:01:58 <_ikke_> like a cache 2017-10-01 20:02:27 <_ikke_> setup-apkcache 2017-10-01 20:02:57 ok cool I will check that out 2017-10-01 20:03:25 yeah installing is very fast in Alpine, but there aren't any guarantees because there are triggers 2017-10-01 20:03:35 you could run "sleep 100" in your trigger, etc. 2017-10-01 20:03:53 <_ikke_> triggers do not run during building 2017-10-01 20:04:11 no but you have to install build deps. when i build python, I have to install "ld" or whatever 2017-10-01 20:04:11 <_ikke_> only APKBUILD 2017-10-01 20:04:14 and "ld" has a trigger, no? 2017-10-01 20:04:17 or it could have a trigger 2017-10-01 20:04:21 <_ikke_> right 2017-10-01 20:04:25 I'm saying to build, you must install 2017-10-01 20:04:34 you install deps 2017-10-01 20:04:35 <_ikke_> oilshell: I understand you know 2017-10-01 20:04:41 and installing is the step that causes problems with root 2017-10-01 20:04:58 ok cool, yeah I am trying to understand alpine, this helps :) 2017-10-01 20:05:01 <_ikke_> UID -? 2017-10-01 20:05:05 <_ikke_> UID 0 2017-10-01 20:05:08 it is fairly similar to debian 2017-10-01 20:05:14 but it seems faster and nicer 2017-10-01 20:05:33 <_ikke_> alpine keeps its packages very slim 2017-10-01 20:05:35 Who maintains the armhf build server(s)? 2017-10-01 20:05:52 yes i like that, and i like that the base install is very slim 2017-10-01 20:06:36 <_ikke_> craftyguy[m]: kanini mayby? 2017-10-01 20:08:25 does alpine cross-compile? e.g. does the armhf build server have to be an armhf machine? or could it be x86 and cross compile? 2017-10-01 20:08:43 <_ikke_> no cross-compilation iirc 2017-10-01 20:08:55 <_ikke_> only native builds 2017-10-01 20:09:01 ah ok 2017-10-01 20:09:12 Hmm, we cross compile alpine packages in pmOS... 2017-10-01 20:09:26 oh how do you do it? 2017-10-01 20:09:49 Why wouldn't the build servers do that too? Seems more efficient than running a slow armhf system 2017-10-01 20:10:25 i don't know much about ARM, but if it's really a single armhf machine then it's not surprising things are backed up :-/ 2017-10-01 20:10:26 I believe we use qemu (yes, I know..) 2017-10-01 20:10:39 So that's kind of cheating.. 2017-10-01 20:10:51 oh well qemu under x86-64 might be faster than a real armhf machine 2017-10-01 20:10:58 if it has 16 or 32 cores etc. 2017-10-01 20:10:59 ollieparanoid: can probably expand a bit more 2017-10-01 20:11:23 Right, it's a lot faster than compiling on my armhf device 2017-10-01 20:12:07 do you guys have your own build servers running qemu? or are you talking about just for local development builds 2017-10-01 20:12:59 but qemu is not cross-compiling BTW 2017-10-01 20:13:05 <_ikke_> nope 2017-10-01 20:13:11 right now it's just local development builds 2017-10-01 20:13:14 and yes I know qemu is not 'cross compiling' 2017-10-01 20:13:34 but it sort of is, still producing armhf binaries on x86 :P 2017-10-01 20:13:47 ok so then you do both? native compiles under qemu AND cross-compiles without qemu? 2017-10-01 20:14:01 OK 2017-10-01 20:14:09 but I ask because I wonder if abuild supports cross compiling 2017-10-01 20:14:10 native compiles don't happen under qemu 2017-10-01 20:14:12 and I think it doesn't 2017-10-01 20:14:27 instead of cross copmiling you compile under emulation (QEMU) 2017-10-01 20:14:33 yea I think you're right, it'll try to build for whatever the native arch is 2017-10-01 20:14:43 if the apkbuild supports it 2017-10-01 20:14:52 <_ikke_> oilshell: isn't it just matter of having a compiler capable of cross-compiling? 2017-10-01 20:14:53 ok 2017-10-01 20:15:27 yeah that is part of the problem. afaik GCC needs a separate cross-compiled build, but Clang supports it natively 2017-10-01 20:15:29 in clang it's just a flag 2017-10-01 20:15:35 the bigger problem AFAIK is passing the right flags 2017-10-01 20:15:39 every package is different 2017-10-01 20:15:48 autotools packages should support cross-compiling 2017-10-01 20:15:53 but other packages may not. 2017-10-01 20:16:05 it's a lot of work to cross compile afaik, so a lot of people just compile under emulation 2017-10-01 20:16:16 building under emulation (i.e. qemu) might be easier to support then 2017-10-01 20:16:25 i would assume that is what the armhf build servers do but I don't have any first hand knowledge 2017-10-01 20:16:31 for us, we don't have to modify the apkbuilds for them to work 2017-10-01 20:17:09 me neither. btw I don't think kaniini maintains the armhf build server, at least not based on some of his earlier remarks 2017-10-01 20:17:23 right now it seems that the build server is maintained by ghosts 2017-10-01 20:18:01 i do not maintain the arm build servers sorry :p 2017-10-01 20:18:14 i think the infra team do 2017-10-01 20:18:22 <_ikke_> kaniini: ah sorry 2017-10-01 20:18:33 either that or one of ncopa or fabled 2017-10-01 20:19:03 but what happened is the binutils package needs to be fixed on them 2017-10-01 20:19:09 i have an idea to do it 2017-10-01 20:19:36 oh btw I googled and found this page 2017-10-01 20:19:37 http://wiki.alpinelinux.org/wiki/User:Ncopa/buildserver 2017-10-01 20:19:55 it's probably old but it mentions using lxc which is linux containers 2017-10-01 20:20:18 <_ikke_> yes, alpine uses LXC containers alot 2017-10-01 20:20:21 <_ikke_> but not a container per build 2017-10-01 20:21:03 also https://wiki.alpinelinux.org/wiki/Setting_up_a_compile_vserver 2017-10-01 20:21:12 ncopa, fabled : do either of you maintain the armhf build server? 2017-10-01 20:22:42 > An Alpine 1.9 vserver template 2017-10-01 20:22:43 well, that's a bit old :P 2017-10-01 20:23:35 haha 2017-10-01 20:24:36 lol someone dislodged the armhf build server and it promptly failed on a new package and is now hung again 2017-10-01 20:25:08 how do you tell the status? 2017-10-01 20:25:37 http://build.alpinelinux.org/ 2017-10-01 20:25:44 also, #alpine-commits 2017-10-01 20:40:26 oh and it hung on cloudi again because no one is around to install binutils. this is sad. 2017-10-01 20:50:55 oh yes I see 2017-10-01 20:51:16 it looks like it does install 113 packages before building, and then it purges them all at the end 2017-10-01 20:51:35 so that is the concurrency issue that _ikke_ and I were talking about 2017-10-01 20:52:03 unless you have a container per build, you can't do concurrent builds if you have to set up 113 packages and then tear them down at the end 2017-10-01 20:52:15 the root file system is a big global variable in this case which inhibits concurrency 2017-10-01 20:52:34 although I don't understand why it couldn't just go on to the next package 2017-10-01 21:00:28 kaniini, do you have a solution for mixing edge with stable and busybox providing /bin/sh? 2017-10-01 21:53:11 Error loading shared library libfreetype.so.6: No such file or directory (needed by /usr/bin/mkfontscale) 2017-10-01 21:53:13 i 2017-10-01 21:53:23 i'm finding libfreetype.so.6.15.0 2017-10-01 21:53:32 sorry, using a new keyboard 2017-10-01 21:54:13 craftyguy[m]: are you a postmarketOS dev too? may I ask a question? 2017-10-01 21:54:23 strange, must be a new dependency for some reason, cacti failed to build but builds after installing freetype-dev 2017-10-01 21:54:33 foxkit: yea, sure :) 2017-10-01 21:55:13 the armhf edge build server keeps banging its head on the wall by trying, and failing, to build `cloudi` over and over, and over. 2017-10-01 21:55:32 poor thing 2017-10-01 21:55:38 at least it doesn 2017-10-01 21:55:45 't segfault on bash 2017-10-01 21:57:03 craftyguy[m]: you enable doxygen for QCH builds on KF5. how big are the -doc packages on average would you say? 2017-10-01 21:57:31 I'm trying to see if it would be worth it to add those to our (Adélie) builds 2017-10-01 21:57:39 our community is split 2017-10-01 21:58:06 if they're small I'll probably do it, if it's like 30 MB per pkg then probably not. 2017-10-01 22:00:52 foxkit: here's the size of all doc packages in my cache right now: https://ptpb.pw/8JCc 2017-10-01 22:01:51 have we patched in the new openvpn CVE patch? 2017-10-01 22:02:21 https://community.openvpn.net/openvpn/changeset/c7e259160b28e94e4ea7f0ef767f8134283af255/#file0 2017-10-01 22:02:23 CVE-2017-12166 2017-10-01 22:03:19 wait, we have 2.4 i believe, which disables method 1 by default 2017-10-01 22:14:53 craftyguy[m]: oh wow, ok. thank you! 2017-10-01 22:15:26 foxkit: you're welcome! 2017-10-02 01:34:01 Can anyone help me change the timestamp settings for my /var/log/messages? Every entry in the log is dated Dec 31 13.59.59... 2017-10-02 01:40:19 that sounds like it's reading 0 as the current time 2017-10-02 01:40:31 what logger daemon are you using? syslog-ng, rsyslog, something else? 2017-10-02 01:40:44 is this in a container (if so which kind) or is it on physical hardware? 2017-10-02 01:42:13 physical hardware and I am unsure of the logger daemon... I know chrony is installed and dropbear is storing its logs in there 2017-10-02 01:42:52 m4chm4n: try running the command `rc-status` 2017-10-02 01:43:10 it tells you all running services on the machine running OpenRC 2017-10-02 01:43:27 one of them should have 'log' in the name 2017-10-02 01:44:14 ok 2017-10-02 01:44:36 klogd 2017-10-02 01:44:53 I assume i need to change some settings in the conf? 2017-10-02 01:45:28 would that be located in /etc? 2017-10-02 01:47:11 I unfortunately have very little experience with the sysklogd package :( you may need to wait for someone more experience 2017-10-02 01:47:14 experienced* 2017-10-02 01:48:17 well I am open to changing if need be. I just set up my ssh server on it a few days ago. My first attempt at this kind of thing. 2017-10-02 01:50:10 and if not, then I can use the info you helped me obtain to look online for some answers. 2017-10-02 01:50:46 it shouldn't be necessary, but I don't know why it is doing that. 2017-10-02 01:56:07 oh, ok. yea its making the configuration of fail2ban a pain in my ass!!! 2017-10-02 01:57:00 I can imagine so 2017-10-02 01:58:42 could you recommend something similar to fail2ban that is easier to setup? 2017-10-02 01:59:46 or a way to block multiple failed login attempts 2017-10-02 02:04:22 m4chm4n: why not just ignore those log lines or disable them? any internet connected system is going to get people probing it. 2017-10-02 02:07:24 honestly the problem seems more that the log files all say 0 2017-10-02 02:07:27 for a time 2017-10-02 02:08:08 how would I set up fail2ban if I disable logging, xe? 2017-10-02 02:09:06 I know any internet connected system will get probed... I am just trying to minimize the chances of my server getting pwnd 2017-10-02 02:09:18 m4chm4n: you don't. fail2ban doesn't provide security the way most people think it does. 2017-10-02 02:11:18 I am using rsa keys and shit. so I am not that worried about security as I am worried about reducing the chances them getting into my machine. 2017-10-02 02:13:09 my main goal at this moment is to ban ip's that have multiple failed login attempts. So if fail2ban is not what I am supposed to be using, then please tell me the more appropriate program. 2017-10-02 02:17:26 RSA keys are actually perfectly secure, I think even Alpine uses RSA keys for package signing, it's just they're 4096 or 8192 bit 2017-10-02 02:17:33 only rsa512 768 1024 is bad 2017-10-02 02:17:43 plus I am not just relying on one piece of software to keep me safe. Just trying to stay one step ahead of the bad guys. 2017-10-02 02:18:51 Yea thats the one reason I am using them, foxkit. So much easier than using a pw everytime I want to login to my server. 2017-10-02 02:28:38 m4chm4n: if it only allows authenticated keys to connect, why should any failures to authenitcate matter? 2017-10-02 02:28:42 authenticate* 2017-10-02 02:31:14 Sorry, I guess I shouldn't obsess over cluttered logs. I will stop bugging the chat with my, obviously annoying, chatter. Didnt mean to upset anyone. 2017-10-02 02:31:26 nah, it's all good 2017-10-02 02:31:55 it's just really unfortunate that some security compliance things require fail2ban like behavior 2017-10-02 02:32:29 craftyguy[m]: should the cloudi package change? 2017-10-02 02:33:39 Im just going to see if I can find a way to ban bots from trying to connect some other way. 2017-10-02 02:34:05 thanks foxkit for the help. 2017-10-02 02:34:18 craftyguy[m]: it has binutils-dev as a dependency, so it shouldn't fail on ld, right? and the problem is related to that package on armhf arch, right? 2017-10-02 02:34:28 np 2017-10-02 02:36:39 craftyguy[m]: armhf could be disabled if binutils won't get fixed for awhile 2017-10-02 02:41:18 hey, foxkit, do you know anything about iptables? 2017-10-02 02:41:34 nope, my edge router runs OpenBSD with pf 2017-10-02 02:43:27 ah, I see.... is pf easy to setup? I think I may want to implement that into my network. My wifi router, that came from my isp, has shit for options... 2017-10-02 02:47:50 I bought a book on pf actually 2017-10-02 02:47:54 I don't know how good the online documentation is 2017-10-02 02:48:13 my job used to be network administration, so I'm.. how you say.. very technically inclined with this stuff 2017-10-02 02:52:23 Yea, I have always loved this kind of tech related stuff. Although its more of a hobby to me. I always wanted to get into the tech related job fields. But I love cooking too much to change jobs.. 2017-10-02 02:53:23 Plus, I am 32 now, and I feel like it would be an uphill battle to try and get in now. 2017-10-02 02:57:26 okeuday_bak: binutils-dev does not provide ld, binutils provides ld 2017-10-02 02:58:12 disabling armhf is a bad idea. we need armhf packages for the Alpine derivative we are working on. I'm sitting here waiting for some packages I submitted a few days ago to get built on armhf so I can continue my work, for example 2017-10-02 02:58:55 okeuday_bak: the armhf build server should have binutils installed, since just about every package that is compiled needs things like ld 2017-10-02 03:02:52 craftyguy[m]: if it would help, I can add binutils in the cloudi deps, but I can't merge the change 2017-10-02 03:06:52 the running wisdom is you never add the dependencies listed in build-base to any package 2017-10-02 03:06:55 because build-base is implicit 2017-10-02 03:07:11 foxkit: ok, and build-base includes binutils? 2017-10-02 03:07:50 okeuday_bak: yea I could do that too.. but I guess the bigger question is why isn't binutils there already? This package compiles on other archs.. 2017-10-02 03:08:24 Even bigger question is: who maintains the armhf build servers?! 2017-10-02 03:09:36 okeuday_bak: yes https://git.alpinelinux.org/cgit/aports/tree/main/build-base/APKBUILD 2017-10-02 03:10:52 foxkit: but I don't understand how binutils can't exist on armhf then, is the build-base or binutils package broken on the arch temporarily? 2017-10-02 03:12:15 Good questions! Only the maintainer of the armhf server can answer! 2017-10-02 03:13:26 craftyguy[m]: Ok 2017-10-02 03:13:54 Seriously, who is maintaining it? They seem unreachable 2017-10-02 03:35:26 what is being blocked by the armhf server? does it prevent code from getting merged? 2017-10-02 03:51:13 oilshell: well, it prevents armhf packages from being built. That's kind of critical for the project I am working on 2017-10-02 03:52:00 oh is this in testing or edge? i'm not sure how the different components of repo work 2017-10-02 03:52:50 craftyguy[m]: you're working on pmos right? I'm just curious how it relates to alpine in terms of the infrastructure 2017-10-02 03:54:08 craftyguy[m]: is there a reason you can't build your own armhf package in your repo until the alpine one catches up? 2017-10-02 03:58:13 oilshell: yes, pmos. 2017-10-02 03:59:12 foxkit: well, we do that now, but if I want a bunch of folks to test things, then it doesn't exactly scale well. we have offered to help the Alpine folks with infrastructure, etc, but no one has identified themselves as, for example, being maintainers of the armhf build servers 2017-10-02 03:59:34 nevermind the security implications of not knowing who owns a build server 2017-10-02 04:00:41 it sounds like you need your own build servers? 2017-10-02 04:01:02 i don't know the history but like most open source projects it's probably one overloaded guy maintaining everything 2017-10-02 04:01:13 oilshell: in pmos, we do not currently host binaries. the idea is that we (pmos devs) help Alpine by submitting package updates/changes/and new packages to Alpine. 2017-10-02 04:01:59 if we are forced to use our own build servers, I would have no motivation to submit much back to Alpine. We'd essentially become a fork. I don't want that, but then again I'm just one person and don't necessarily represent all of pmos 2017-10-02 04:02:23 ok but it's not surprising that doesn't scale 2017-10-02 04:02:32 most popular projects have more patches than people to review patches, etc. 2017-10-02 04:02:47 oilshell: and so, we've offered to help. https://github.com/postmarketOS/pmbootstrap/issues/663 2017-10-02 04:03:29 yeah I saw that 2017-10-02 04:04:05 we are literally saying "let us help you with this increased demand, by helping with menial tasks that free you to do other things, etc" 2017-10-02 04:04:56 yeah it sounds like alpine is bottlenecked on knowledge transfer 2017-10-02 04:05:02 hell, I have a dual socket xeon system I could dedicate to this effort, and would be willing to contribute in other ways, including fixing broken packages that don't build with armhf, helping to review PRs, etc. 2017-10-02 04:05:02 if nobody here knows how the build servers are set up, etc. 2017-10-02 04:05:39 oilshell: yea, that's what it sounds like. a handful of people know how to run things, but it's not being spread around 2017-10-02 04:06:24 yeah but that is normal for popular projects 2017-10-02 04:06:36 I'd rather put energy into helping Alpine than into setting up and maintaining separate build servers, etc. if that makes sense 2017-10-02 04:06:54 i would hope more people respond to your message in a few days 2017-10-02 04:07:00 it sounds like more tasks do need to be offloaded 2017-10-02 04:07:29 it seems like the build server work would be a good thing to offload, but there are trust issues there 2017-10-02 04:07:45 if somebody took care of the build servers maybe the PRs would be reviewed faster 2017-10-02 04:07:52 definitely. 2017-10-02 04:08:33 on the other hand, I'm having a very hard time identifying who maintains the armhf build servers... sooo... yea. trust issues? 2017-10-02 04:09:06 well judging by the wiki it's probably ncopa. how long have you been asking? i wouldn't expect maintainers to be on IRC every day 2017-10-02 04:09:21 but I digress. I would very much like to help Alpine 2017-10-02 04:09:25 maybe send a message to the mailing list? 2017-10-02 04:09:26 esp given it's the weekend 2017-10-02 04:09:42 yup 2017-10-02 04:10:01 oh yea, totally understand that they could be on holiday for 2 weeks, etc. 2017-10-02 04:10:45 maybe alpine should be up-front about who is maintaining what, just so users are informed 2017-10-02 04:13:13 yeah that would be nice. but usually it is a couple overloaded people 2017-10-02 04:13:26 then somebody gets fed up and does something, and now you own it :) 2017-10-02 04:13:33 last person to touch owns it :) 2017-10-02 04:13:51 haha 2017-10-02 04:13:57 guess i should be careful :P 2017-10-02 04:15:15 anyways, I'm trying to be supportive of all Alpine developers. I hope we can come up with great ways to offload some of the load they have! 2017-10-02 05:36:45 craftyguy: the infra team knows who runs the build servers as it is part of their purview. i don’t know personally as i don’t really use the arm ports 2017-10-02 05:38:26 i’m quite certain that if i asked or you asked them you could get an answer 2017-10-02 05:40:29 i mean i am trying to be nice here but alpine is a completely non commercial project and expecting some sort of SLA is insane 2017-10-02 06:15:51 fuck it. 2017-10-02 06:15:55 i'm going to just be straight up 2017-10-02 06:17:54 craftyguy: the "offer to help" really comes off badly to us, because it really reads to us, as basically a demand-not-demand for an SLA, and honestly if you want an SLA you should work with yocto or something like that who has a huge corporate ecosystem behind it that can give you the SLAs you want. alpine/armhf is literally the most underresourced port in the project and usually just barely makes the cut for releases 2017-10-02 06:17:55 simply because the ecosystem surrounding alpine frankly does not care about arm in any sort of way that would result in development time being sponsored for the port 2017-10-02 06:18:36 i'm just being real with you, that is how it is 2017-10-02 06:19:09 now if phones had x86 processors or power8 processors 2017-10-02 06:19:16 you would have all the SLAs on the planet 2017-10-02 06:19:34 because there's plenty of people doing work on the x86 and power architectures 2017-10-02 06:20:43 until pmOS came along, the arm ports were largely community-driven ports used by people who wanted to play with alpine on their raspberry pi or other device like that 2017-10-02 06:21:35 the ARM bigiron story basically hasn't played out, so there's basically nobody interested in the ARM ports for use in the datacenter 2017-10-02 06:21:48 and 'serious' embedded players just stick with yocto because it's what they know 2017-10-02 06:24:42 similarly, your thread on github requests, in essence, an SLA on reviews. if you want expedited reviews, you need to find individual developers to work with you. it is not the policy of the project to give preference to any particular group of contributors, but if you have a mentor and you're working on becoming a developer, then you will naturally get more expedited reviews 2017-10-02 06:27:58 it's great that you guys are here, but it is unreasonable to expect special treatment that nobody else would get just because you guys care about the arm ports 2017-10-02 06:28:44 you need to play by the same rules as everyone else who is trying to become a dev, otherwise it is not fair to those people -- some of whom have been working for several years to earn dev rights 2017-10-02 06:33:33 i will of course update the github post, too. but derivatives do not just get special treatment because they are derivatives. 2017-10-02 07:19:07 kaniini, do you have a solution for mixing edge with stable and busybox providing /bin/sh? 2017-10-02 07:19:38 clandmeter: it should be working just fine, what happens ? 2017-10-02 07:20:04 packages depend on /bin/sh 2017-10-02 07:20:10 which is not available in 3.6 2017-10-02 07:20:25 ah 2017-10-02 07:20:38 try: apk add --virtual=/bin/sh busybox 2017-10-02 07:20:58 i was wondering if we could backport it to 3.6 bb 2017-10-02 07:21:04 i'm okay with that 2017-10-02 07:21:10 i'm sure you can handle it 2017-10-02 07:21:18 so i'll leave you to it? 2017-10-02 07:21:45 i just want to make sure it doesnt bring future issues. 2017-10-02 07:21:55 i cant think of any 2017-10-02 07:21:59 i don't see it bringing any future issues with upgrading 2017-10-02 07:22:22 and policy-wise it is fine to backport because it is intended to facilitate compatibility with upgrading anyway 2017-10-02 07:22:43 so +1 from me :) 2017-10-02 07:23:30 ok 2017-10-02 08:19:54 omg grapichmagick releases CVE every so often? 2017-10-02 08:21:57 that's tragick 2017-10-02 08:22:50 it is for them, since it looks that it has a lot of sec issues 2017-10-02 08:23:13 I have trouble being empathetick 2017-10-02 08:36:23 clandmeter: what breaks due to missing provides=/bin/sh? 2017-10-02 08:36:51 anything package that has a script 2017-10-02 08:36:56 any... 2017-10-02 08:37:29 it used to add busybox to deps, now abuild adds /bin/sh 2017-10-02 08:37:32 and provides=/bin/sh will solce that? 2017-10-02 08:37:36 solve* 2017-10-02 08:37:52 doesnt all packages with scripts need a depends=/bin/sh as well? 2017-10-02 08:38:04 i guess it will? apk looks for something that provides /bin/sh which in 3.6 is nothing. 2017-10-02 08:38:42 that means that something has a depends=/bin/sh 2017-10-02 08:39:10 i think it would have been good if we would have done: 2017-10-02 08:39:11 if you build a new pkg in edge with any install script it will be added. 2017-10-02 08:39:33 1) add provides=/bin/sh to busybox 2017-10-02 08:39:47 2) wait til next stable (v3.7) 2017-10-02 08:39:55 3) start add packages that depends on it 2017-10-02 08:40:36 i suppose backporing provides=/bin/sh to 3.6 woudl help 2017-10-02 08:49:15 https://dockercommunity.slack.com/archives/C36E9DBCL/p1506612317000431 2017-10-02 08:49:34 when/how was this depend=/bin/Sh introduced? 2017-10-02 08:49:51 i need to register to see that page 2017-10-02 08:51:49 http://i.imgur.com/HLgVcwZ.png 2017-10-02 08:59:59 eew Slack. Why do you guys have both an IRC channel and a Slack room? 2017-10-02 09:10:23 You can you slack via irssi :D 2017-10-02 09:10:26 *use 2017-10-02 09:17:51 You can bridge Slack to IRC via Matrix as well 2017-10-02 09:32:34 Slack has a native bridge 2017-10-02 09:50:17 wut, there is an Alpine channel on Slack? XD 2017-10-02 09:51:08 It's the dockercommunity Slack, so it's probably for Alpine on Docker 2017-10-02 09:52:08 Ah that makes sense 2017-10-02 09:56:54 do we have Alpine on tosters community? 2017-10-02 14:35:24 kaniini: sorry that us reaching out to you to offer help has come across as a 'demand', in fact it's far from it. until your post in github, there was no clear communication from the Alpine developers on how a project like pmos could help Alpine. You said we should become developers, ok! What's the process? Where do I start? 2017-10-02 14:36:28 Is there a list of items "to do" that I could start working on to hopefully, after some time, gain those 'developer references' you mentioned? 2017-10-02 14:43:21 Also, I don't speak for the whole pmOS project, but I am not expecting special treatment for any one architecture or for pmOS. I just want to help, so that Alpine is successful and so that derivatives, like pmOS, are successful. I see a lot of deficiencies in how, for example, armhf is handled in Alpine, but I'm not sure if I can do anything about it because I don't know what to do about it. I understand it's a 2017-10-02 14:43:22 second-class architecture, and that's OK. How can I help make it a first-class citizen? If the answer from the Alpine developers is "you can do nothing" then fine, better that comes out sooner rather than later. But I really hope that's not the case because I have time to help. 2017-10-02 14:45:45 craftyguy[m]: writing documentation, following the bugtracker, updating packages ++ 2017-10-02 14:45:46 that 2017-10-02 14:45:53 that'll help a lot i'm sure 2017-10-02 14:57:22 well writing documentation is one thing we're good at 😄 2017-10-02 14:59:19 Yep :P 2017-10-02 14:59:51 Is there a way to query packages flagged as 'out of date'? 2017-10-02 15:25:29 craftyguy[m]: yes, one sec 2017-10-02 15:25:38 craftyguy[m]: https://pkgs.alpinelinux.org/flagged 2017-10-02 15:57:28 craftyguy: what the arm port lacks is manpower 2017-10-02 16:00:52 and i want alpine on mips, heh 2017-10-02 16:04:33 kaniini: I am here to contribute manpower... 2017-10-02 16:05:17 danieli: thanks! Apparently I am blind because I missed that big 'flags' link on the website :( 2017-10-02 16:05:49 craftyguy[m]: no worries, i 2017-10-02 16:05:52 DAMN APOSTROPHE JSFSIPDJF 2017-10-02 16:06:23 I meant to say I'm pretty new in the Alpine community, you can ask me anything and I'll help you if I can 2017-10-02 16:10:09 ACTION sees youtube-dl in the out-of-date list. That program is impossible to keep up, it has a release like every week 2017-10-02 16:11:50 Thanks danieli :) 2017-10-02 16:12:08 yeah, we're considering a 'volatile' repo 2017-10-02 16:35:23 how do I contribute to that flagged status of: look at this pr for more details 2017-10-02 16:36:02 aka, i know, and if it was as simple as just building new apk packages it would've been out, but things segfault while building so its not so easy 2017-10-02 16:40:49 Hmm, my sdl2 PR has failed to build, because it's looking for directfb-dev. That package is now in aports testing. Does the build server for github PRs need to sync its repo sources or something? https://travis-ci.org/alpinelinux/aports/builds/281965359?utm_source=github_status&utm_medium=notification 2017-10-02 16:52:05 Hey 2017-10-02 16:52:37 Any reason why non gnome shell packages aren't being built for armhf 2017-10-02 16:54:30 opendata: it looks like the armhf build server(s) are being hung up on other packages. there's a new build system being developed now to prevent a failing package build from hanging up the build server, but it hasn't been deployed on armhf 2017-10-02 16:55:27 craftyguy[m]: thanks 2017-10-02 16:55:40 But the last update was like 10days ago 2017-10-02 16:55:56 Surely the should have had the time to build it 2017-10-02 16:57:06 Well, not really. I have a number of packages held up too :) 2017-10-02 16:59:46 opendata: you can watch the armhf build server over at #alpine-commits 2017-10-02 17:00:14 currently two packages, cloudi and laz-perf, are holding it up 2017-10-02 17:01:23 I'm tempted to submit a PR to add 'binutils' to cloudi's apkbuild so it'll succeed.. but I think we need whoever is maintaining that server to install binutils on the system 2017-10-02 17:03:01 i think you do not know what you're talking about 2017-10-02 17:03:13 binutils is definitely installed 2017-10-02 17:03:28 either binutils package is broken or the filesystem on the builder is damaged 2017-10-02 17:04:53 kaniini: well without actual access to the system, I'm assuming something is wrong with binutils, or the system, because 'ld' is missing. binutils provides 'ld'.... 2017-10-02 17:06:38 ok so build-base depends on binutils, yes? 2017-10-02 17:06:54 and abuild always makes sure build-base is installed, yes? 2017-10-02 17:07:00 I'll try not to help others by making assumptions based on the limited evidence present in your build system. 2017-10-02 17:07:32 so then, clearly, binutils is installed, because build-base pulls it in 2017-10-02 17:08:29 so what i would do is this 2017-10-02 17:08:44 you want to become a developer so that you have more access 2017-10-02 17:08:52 and your primary interest is the ARM port 2017-10-02 17:09:13 what i would do is go acquire a raspberry pi or something 2017-10-02 17:09:16 install alpine on it 2017-10-02 17:09:22 and see why laz-perf is failing 2017-10-02 17:09:41 since for some reason we don't have a build log coming from that one 2017-10-02 17:09:49 once you find out why laz-perf is failing, then i would suggest regrouping 2017-10-02 17:09:51 kaniini: yea that's in my list of things to do. it's cloudi that I am mostly clueless about how to resolve 2017-10-02 17:10:10 laz-perf should be reproducible, assuming the build server isn't fucked up in other ways 2017-10-02 17:10:23 also try reproducing build failure of cloudi 2017-10-02 17:10:28 ok 2017-10-02 17:10:31 if it builds for you, it means builder is fucked 2017-10-02 17:10:39 if it doesn't build for you, it means packaging is broken 2017-10-02 17:10:54 if it doesn't build, i suggest blacklisting armhf from the package for now 2017-10-02 17:11:26 send me patches either here (link to just a plaintext file) or on github and i will push them on your behalf 2017-10-02 17:12:05 ok! 2017-10-02 17:15:52 how does one blacklist an architecture in the APKBUILD? the wiki doesn't explicitly say how, and I suspect I could do it by just listing out every arch except the one I wanted to blacklist.. but is there a better way? 2017-10-02 17:16:33 <_ikke_> !armhf 2017-10-02 17:16:36 <_ikke_> in the arches 2017-10-02 17:17:35 thanks 2017-10-02 17:19:06 what i mean by the way 2017-10-02 17:19:12 is if it doesn't build when you test it 2017-10-02 17:19:27 if you just send a patch blacklisting armhf in say, the next 5 minutes, i'm going to ignore it 2017-10-02 17:20:01 kaniini: I know what you mean. I was asking because I didn't know how to do that.. and was curious. 2017-10-02 17:20:23 I'm going to try building these, debugging failures, etc.. 2017-10-02 17:20:23 i just figured i should be clear on this 2017-10-02 17:20:56 no problem. just arbitrarily blacklisting architectures that don't build successfully is not a valid solution. got it. 2017-10-02 17:21:48 well. not exactly. if a maintainer does not wish for their package to build on an architecture, they are allowed to blacklist it. 2017-10-02 17:22:14 that's not what I meant either. sigh 2017-10-02 17:22:47 what you're doing is a non-maintainer change for the purpose of arch-specific QA, so the change needs to be appropriately justified 2017-10-02 17:23:12 to be explicit about what I meant: blacklisting architectures in packages where the maintainer wishes to support said architecture is not a valid solution for resolving a build failure of that package on said architecture without at least some amount of debug. 2017-10-02 17:23:48 yes that would be a correct policy interpretation 2017-10-02 17:24:41 QA changes require strong evidence to support the change because if the maintainer gets annoyed by the change, they can complain about it 2017-10-02 17:25:00 which means they will complain to me as the person pushing the change on your behalf 2017-10-02 17:25:05 and i will be annoyed by this 2017-10-02 17:25:57 this can also result in a revert war where the change is reverted and then reapplied 2017-10-02 17:26:07 which would also be annoying 2017-10-02 17:26:23 so QA changes need to be clearly explained and justified 2017-10-02 17:26:57 <_ikke_> What does QA mean in this context? 2017-10-02 17:27:09 Agreed. Despite what you might think, I'm not actually wanting, or intentionally trying to, annoy anyone. :D 2017-10-02 17:31:44 _ikke_: quality assurance 2017-10-02 17:32:24 _ikke_: in this case, architecture-specific QA means "making sure the architecture is releasable" 2017-10-02 17:34:34 <_ikke_> alright 2017-10-02 17:35:28 also, is there any specific rule that if a package supports $arches for version N that it should continue for version N+1? or rather, if I have issues with one arch not building should/n't that hold up other working arches? would the old arch continue having the old version? 2017-10-02 17:36:12 if you blacklist the package it will be removed from the arch in its entirety 2017-10-02 17:36:52 and no, it is basically up to the maintainer what they wish to do 2017-10-02 17:37:06 so if version N has arches="a b" and if I put in version N+1="a" that would remove the package for arch b entirely? 2017-10-02 17:38:24 yes 2017-10-02 17:38:52 however dropping an arch is considered antisocial 2017-10-02 17:38:59 i wouldn't suggest it as a permanent fix 2017-10-02 17:39:39 right i'm not intending to to be honest, just wondering how it might be possible to do "this arch is ok for now, other arches have issues that I'm debugging" type upgrades, sounds like I don't 2017-10-02 17:40:11 it is actually possible to publish two versions of the same package in the archive 2017-10-02 17:40:18 but it's kinda weird 2017-10-02 18:14:11 essentially what you do is have two dirs with APKBUILDs 2017-10-02 18:14:20 and both versions will get published 2017-10-02 18:35:55 silly question, does someone see problems with building apk tools with the freebsd version of libfetch? 2017-10-02 18:36:13 technically, that is, I'm not requesting anyone to do this for me 2017-10-02 19:44:30 kaniini: regarding laz-perf failure on the armhf build server, I cannot reproduce when building for armhf. The checks pass for me (whereas the first check failed for the armhf build server): http://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/laz-perf/laz-perf-1.1.0-r0.log 2017-10-02 19:50:18 kaniini: As craftyguy said already, we did not mean to make demands or get a special treatment and I'm sorry that the thread sounded that way. I'm happy, that the discussion in this channel regarding "how can we help armhf" is getting productive now. Thanks craftyguy for volunteering as developer. kaniini, I understand, that there's a lot more to it than saying "yes I want to be a developer.". I'm so grateful 2017-10-02 19:50:19 about your seemingly infinite patience with us and I hope we don't stress it further and that it will be worth it (i.e. in contributions that come back). Thank you very much! 2017-10-02 19:53:31 Also out of curiosity: Is there a full list of requirements for a developer or infrastructure team member? I could not find anything in the Alpine wiki. 2017-10-02 20:01:05 foxkit: you asked about the size of the doc packages of KDE. They don't seem to 2017-10-02 20:01:05 be that big, here are some pre-compiled ones: 2017-10-02 20:01:06 https://github.com/PureTryOut/pmos-plasma-mobile/tree/master/x86_64 2017-10-02 20:01:23 oilshell: this is how postmarketOS cross-compiles packages (I'll be happy to explain more about it, but we should take that to #postmarketOS): https://wiki.postmarketos.org/wiki/Build_internals 2017-10-02 20:01:41 oilshell: also abuild supports cross-compiling directly. see scripts/bootstrap.sh in the aports folder and https://dev.alpinelinux.org/%7Etteras/bootstrap/abuild-crossbuild-aarch64.conf 2017-10-02 20:05:17 TBB: yes, freebsd libfetch and netbsd libfetch are completely API-incompatible 2017-10-02 20:21:16 craftyguy: i'm nervous about the buildserver 2017-10-02 20:22:25 yea, I'm not able to reproduce the cloudi thing either, but I am hanging up on something way earlier in the build.. still trying to characterize it 2017-10-02 20:22:48 i think i may have fixed cloudi 2017-10-02 20:23:07 fabled reinstalled binutils on the armhf builder 2017-10-02 20:23:14 i'm looking at the lazperf test 2017-10-02 20:23:15 it may be flawed 2017-10-02 20:23:48 do they build servers use overlays on some rootfs (where something like binutils would be installed) ? 2017-10-02 20:23:57 no :D 2017-10-02 20:24:08 that's what rootbld is intended to introduce :D 2017-10-02 20:24:38 ah! ok 2017-10-02 20:25:11 and that's a pretty cool feature 2017-10-02 20:25:59 god 2017-10-02 20:26:03 i need an armhf device 2017-10-02 20:26:07 so i can fuck with this 2017-10-02 20:26:23 i wonder where i can get one locally 2017-10-02 20:27:29 Where is 'locally' for you? 2017-10-02 20:27:58 I have one, but I'm building using the armhf cross compiler + qemu (as ollieparanoid outlined in his post above) 2017-10-02 20:28:04 kaniini: if you have a phone to spare... 2017-10-02 20:28:30 this has produced valid armhf binaries for several months now for my armhf device, without actually having to compile on that dreadfully slow thing 2017-10-02 20:28:56 I did build ofono on it a few weeks back, took a couple of hours :D 2017-10-02 20:29:21 oh 2017-10-02 20:29:24 you are not running test builds on actual hardware? 2017-10-02 20:29:30 that may be why lazperf passes for you :P 2017-10-02 20:30:23 laz-perf contributor (me) just happens to be lurking in the room today. If you find any issues with the packaging or the tests, let me know. I have no experience with armhf though. 2017-10-02 20:30:44 io_tests is failing on armhf 2017-10-02 20:30:59 i don't trust qemu emulation 2017-10-02 20:32:06 let me try to build it on my armhf device.. 2017-10-02 20:32:29 it is important to build on real hardware so tests run on real hardware 2017-10-02 20:32:37 qemu emulation is historically far more permissive than actual hardware 2017-10-02 20:32:45 noted 2017-10-02 20:33:04 guess I'm buying the beefiest armhf device I can find 2017-10-02 20:33:05 this n900 ain't gonna cut it :P 2017-10-02 20:34:18 kaniini: seems so, melding around the sources and quite a lot seems to have changed 2017-10-02 20:39:12 wonder if I can get one of our guys to have a look at this and estimate how much work it would be to change this under the hood... would that be in any way beneficial to Alpine? 2017-10-02 20:41:54 kaniini: what about building on armhf but using distcc + cross compilers? 2017-10-02 20:42:11 that would allow checks to run on armhf, but use cross compilers on faster systems to help with compiling 2017-10-02 20:47:51 TBB: i rather not use freebsd libfetch 2017-10-02 20:48:17 freebsd libfetch has a really broken I/O model based around funopen(3) 2017-10-02 20:48:56 like most things in life, just because freebsd gets some things right doesn't mean it gets all things right. libfetch is not right 2017-10-02 20:53:54 that's true; at that point it becomes a question of what one's willing to live with 2017-10-02 20:54:16 basically every choice has its flaws and benefits 2017-10-02 20:55:08 besides `-doc`, `-lang`, `-dev`, and `-libs`, what other subpackages does abuild provide? 2017-10-02 20:55:26 -dbg comes to mind first 2017-10-02 20:58:52 and if I don't specify one of those subpackages even though some files should be in one, will those files get installed anyway with the main package? 2017-10-02 20:59:31 like if I don't specify the `-dev`, subpackages, will all the `/usr/include` files be installed along-side the main package? 2017-10-02 21:02:44 I'm going to go with logic instead of knowledge there, functions that specify what goes where are called package split functions; if there's no splitting then your conclusion would be correct 2017-10-02 21:03:31 but that's just speculation on my part, I've studied abuild but not -that- deep 2017-10-02 21:06:17 yeah I would think so too. as I'm missing some files/directories which should come from a package I've already installed (according to the same package on other distros) 2017-10-02 21:31:19 kaniini: laz-perf test 1 fails on actual armhf hardware 2017-10-02 21:52:00 the prefix are interesting, not only the suffixes 2017-10-02 22:23:23 PureTryOut: at least for -doc, abuild will complain if your regular package would contain something in /usr/share/doc 2017-10-02 22:23:41 (but you probably know that already :p) 2017-10-02 22:41:28 can anyone recommend me a better logging program than klogd? 2017-10-02 22:42:03 preferably a lightweight program 2017-10-02 22:53:13 for kernel logs? ucspilogd < /proc/kmsg 2017-10-02 22:53:24 for syslogd? socklog 2017-10-03 02:35:03 craftyguy: ok 2017-10-03 02:35:13 craftyguy: i ordered an odroid-c2 or some shit, it will be here thursday 2017-10-03 02:45:17 kaniini: nice! I ordered an odroid-c0 earlier, should be here Wednesday or Thurs 2017-10-03 02:45:38 is that better or worse than -c2 2017-10-03 02:45:46 the c2 was like 50 bux 2017-10-03 02:45:55 i couldnt find anything beefier than 2gb ram 2017-10-03 02:46:22 Similar specs I think 2017-10-03 02:46:24 i mean, i found one with 8gb ram, but it was on aliexpress and they said it would take until november to arrive, so that's not workable 2017-10-03 02:49:24 one of the main ways the postmarketOS people can help is by figuring out where i can buy a cavium thunderx system that doesn't cost as much as 3 of my house payments 2017-10-03 02:49:58 i'm willing to pay that for TALOS, but not for an underperforming broken memory coherency model ARM piece of junk 2017-10-03 02:51:01 i'll take similar spec to the thunderx, just need ram and speed. these little SBCs aren't anywhere competitive with the actual alpine build servers 2017-10-03 02:51:02 :P 2017-10-03 02:53:06 if i could source such a machine, i could run CI on all packages in review queue against arm as we do x86 2017-10-03 03:03:37 Haha, yea, well I'm not too excited either about dropping serious money on a really beefy arm system 2017-10-03 03:04:52 did you see my comment about distcc? instead of building the biggest, baddest, most expensive arm thing out there, why not use an x86_64 system(s) running cross-compilers to do most of the heavy building over distcc? code checks, configure scripts, and the like would run on the arm system in that setup 2017-10-03 03:05:41 obviously not everything builds cleanly over distcc, but this might be a middle ground between using a sbc and a huge expensive arm server 2017-10-03 03:08:52 ah the odroid-c0 is 1gb ram. womp womp. 2017-10-03 03:20:08 my basic thing is this 2017-10-03 03:20:20 with a PC you can go and drop like 2017-10-03 03:20:29 $250-300 on a decent board 2017-10-03 03:20:33 and another $250-300 on a decent cpu 2017-10-03 03:20:48 if they could have something at that price point that had a decent cpu, say a thunderx for example 2017-10-03 03:20:55 then you have something 2017-10-03 03:45:02 craftyguy[m]: cross distcc is seriously begging for trouble 2017-10-03 03:45:09 craftyguy[m]: have you tried that distcc approach? Wouldn't it require a lot of per-package hacking? 2017-10-03 03:45:10 craftyguy[m]: this is with my ex-crossdev developer hat on 2017-10-03 03:45:45 yeah that is my suspicion too, i don't have that much first hand experience but most people think cross compiling is a pain 2017-10-03 03:45:56 and when you add distcc that seems to compound the pain 2017-10-03 03:46:32 that said if it actually works it would be cool 2017-10-03 03:46:55 the main problem is that a cross gcc can almost never have the *exact* same specs, options, and assembler output as a native gcc 2017-10-03 03:47:19 and for your system to work, the distcc job has to be started native (otherwise configure isn't being run native) 2017-10-03 03:47:29 which means you are mixing native and cross gcc output into the same file 2017-10-03 03:47:37 although I read that clang supports cross compilation natively? it's just a flag, not a separate binary? 2017-10-03 03:48:05 I heard that there is some interest to moving alpine to clang default? so that could be a path to easier cross compilation? 2017-10-03 03:48:51 that wasn't the reason AFAIK 2017-10-03 03:49:04 right 2017-10-03 03:49:15 i think it was for stuff like sanitizers and CFI 2017-10-03 03:49:38 gcc has addressSanitizer but i haven't used it 2017-10-03 03:49:49 the clang versions are where all that stuff is developed first, and I like it a lot 2017-10-03 03:49:54 AddressSanitizer is awesome 2017-10-03 03:50:12 interesting perspective. it seems to work OK in my (very) limited experiments, and I agree with the added level of complexity 2017-10-03 03:50:14 LLVM sanitisers don't all work on musl, though some of them do 2017-10-03 03:50:48 hm yeah I haven't tried with musl 2017-10-03 03:51:03 ASAN just needs to hook into malloc() so that should be the same across musl or glibc 2017-10-03 03:51:18 it needs to know how long the buffers you allocate are, which is fairly non-invasive 2017-10-03 03:51:34 craftyguy[m]: if you have a demo of this working I'd be interested 2017-10-03 03:51:47 regarding cross compilers in general... I can't imagine that larger projects (like Google's Android) are compiling every binary on ARM. Hell, AOSP builds with cross-compilers. Is the inaccuracy in "exact output" really that bad? 2017-10-03 03:51:48 like if you have some shell scripts I would be interested in replicating 2017-10-03 03:52:29 right AOSP is built on x86 with cross-compilers in the tree 2017-10-03 03:52:41 and cyanogen, etc. i experimented with that a few years ago 2017-10-03 03:52:42 it works fine 2017-10-03 03:52:44 craftyguy[m]: Android has a controlled environment and the entire image is crossed, not just parts. also, they have total control over the build system and don't have autoconf or such to contend with. 2017-10-03 03:53:01 their Makefile also parallelizes perfectly and can saturate all your cores 2017-10-03 03:53:02 craftyguy[m]: all of AOSP code is aware of cross building and is written with that understanding. most packages are not. 2017-10-03 03:53:12 right 2017-10-03 03:53:19 they rewrite the build system to every package essentially 2017-10-03 03:53:25 that is what I was talking about with "per-package" work 2017-10-03 03:53:27 oilshell: I installed distcc on both my armhf device and x86_64 desktop, the desktop is running distccd. I set DISTCC_HOSTS on the armhf device to point to the desktop. I just built laz-perf (trying to debug that failure on the alpine build servers). i also built ofono a few times a while back to fix some issues 2017-10-03 03:53:34 if you want to rewrite the build system for every package then it will work :) 2017-10-03 03:54:01 what is laz-perf? did you test the binary too? 2017-10-03 03:54:02 haha, ok, ok. I have a very limited amount of knowledge here, so I appreciate the course corrections :) 2017-10-03 03:54:19 craftyguy[m]: some interesting notes to take: 2017-10-03 03:54:31 oilshell: it's one of two packages hanging up the Alpine edge arm build server. *shrug* 2017-10-03 03:54:44 - bash, when cross-compiled, does not implement PIPESTATUS correctly, and will always report a failure on the other side of the pipe. that took me two weeks to dig out... 2017-10-03 03:54:50 I am able to reproduce the same failure I see when building it 100% natively and with distcc/cross-comp 2017-10-03 03:55:29 - perl cannot be crossed and it does not support building with any cross compiler, nor does it support distcc (its build system will actively hurt you if you try, and even if you disable the spikes, it will break badly) 2017-10-03 03:56:08 the failure, a test, runs entirely on armhf in this case. my point being, I don't see anything different in this one data point between native-only comp and cross-comp 2017-10-03 03:56:11 but, one data point... 2017-10-03 03:56:29 foxkit: in those cases, distcc will built it locally instead of distributing? 2017-10-03 03:56:56 totally understand not every package will work over distcc.. even if a fraction did, I think that would help speed things up 2017-10-03 03:57:18 then again, I could be wasting my time 2017-10-03 03:58:03 if you can get it to work reliably for a fair number of packages that would be cool 2017-10-03 03:58:30 but it is a somewhat different problem than Android has 2017-10-03 03:58:35 wow, so laz-perf's failing test is throwing SIGBUS. I haven't seen that in years. I think it's something something alignment problems? 2017-10-03 03:58:46 oilshell: I see. TIL! 2017-10-03 03:58:47 so are you going to test which ones do and don't? and are you going to inform your users of the potential for breakage? also, some failures in cross or distcc won't show up even under test suites. when I crossed our base system image to powerpc32 so that I had something to use to build over, there was a strange failure trying to install a python library, and only one, that was necessary for the build 2017-10-03 03:58:49 system to work. it turns out cp was segfaulting with -p argument 2017-10-03 03:59:24 this is why alpine uses native builders at all times 2017-10-03 03:59:35 yeah SIGBUS seems like one of those things you get when your code and your compiler don't match :) 2017-10-03 03:59:35 ah 2017-10-03 03:59:36 and only crosses the necessary packages to build build-base for new arches 2017-10-03 03:59:42 i don't remember all the reasons for it, but alignment is one 2017-10-03 04:00:07 oilshell: that SIGBUS was with a native-only compile too, so distcc/cross-comp can't be blames! 2017-10-03 04:00:09 SIGBUS is somewhat equivalent to the ARM version of SIGSEGV. invalid memory access, incorrect alignment, etc 2017-10-03 04:00:27 you would need to use gdb and see where the failure was etc 2017-10-03 04:00:53 foxkit: I appreciate the "here be dragons" warning. Perhaps my idea isn't worth pursuing afterall 2017-10-03 04:01:18 i think you should pursue it and at least document the dragons for the next person :) 2017-10-03 04:01:24 ACTION has no idea what he is doing, but he's trying!2 2017-10-03 04:01:35 either that or benchmark QEMU compilation vs. cross compilation 2017-10-03 04:01:36 and making typos whenever he can! 2017-10-03 04:01:50 i'm curious how much qemu slows things down 2017-10-03 04:02:24 the problem with qemu is that the CPU emulation is notoriously inaccurate 2017-10-03 04:03:14 so alpine is currently building armhf packages natively, with a single armhf machine? 2017-10-03 04:03:29 i don't know much about arm but aside from reliability, isn't it crazy slow? 2017-10-03 04:03:37 oilshell: yea that's what I would like to know too. 2017-10-03 04:04:42 I built laz-perf, this random package that I only have a vague interest in because it's hanging up the official builder, on a Nokia N900 running Alpine. It took a few minutes. Yes, 'crazy slow' might be accurate 2017-10-03 04:06:14 I'm still struggling to understand how the same compiler (and version) running natively on one arch and as a cross-compiler on another arch can produce different results 2017-10-03 04:06:37 cross-compilers aren't perfect 2017-10-03 04:07:20 not for C at least 2017-10-03 04:07:52 i'm not an expert but the idea that you need a different compiler binary to compile x86 vs. arm seems totally wrong, a big confusion of host and target 2017-10-03 04:07:54 and the ways they are imperfect add up in ways that can and do work against you in very subtle ways as foxkit was saying 2017-10-03 04:07:57 it should just be a flag 2017-10-03 04:08:14 not everything is as easy as go :/ 2017-10-03 04:08:35 well I think Clang works that way 2017-10-03 04:09:10 https://clang.llvm.org/docs/CrossCompilation.html On the other hand, Clang/LLVM is natively a cross-compiler, meaning that one set of programs can compile to all targets by setting the -target option. 2017-10-03 04:09:34 in go you can just do `GOARCH=arm GOOS=freebsd go build` from your x64 macbook running windows and it doesn't matter 2017-10-03 04:09:41 without knowing better I suspect it's because gcc uses global variables all over the place and LLVM/clang don't :-/ 2017-10-03 04:09:47 right 2017-10-03 04:09:49 that's how it should work 2017-10-03 04:09:52 it's not so much global variables 2017-10-03 04:09:57 GCC has "spec files" 2017-10-03 04:10:04 and various compile-time switches 2017-10-03 04:10:07 and it doesn't seem particularly hard if you architect your compiler right 2017-10-03 04:10:22 when GCC is compiled natively, this is different than a cross-compiling GCC 2017-10-03 04:10:39 with the LLVM case, I don't see any reason there should be difference in output between native and cross compilation 2017-10-03 04:10:58 clang outputs to LLVM IR which does not change between architectures 2017-10-03 04:10:59 as long as the C++ in the compiler is portable (and it is) works then the results should be identical 2017-10-03 04:11:16 that IR is turned into assembly language by a common driver 2017-10-03 04:11:36 GCC outputs directly to assembly language 2017-10-03 04:12:06 gcc i'm sure has some intermediate representations too. there are many optimizations that don't depend on the arch 2017-10-03 04:12:10 it is a massive difference in architecture. this makes clang have an additional step and much more support libraries (was somewhere around 1 GB for clang vs 200 MB for gcc), but also much better cross support 2017-10-03 04:12:15 they just don't have a text representation like LLVM 2017-10-03 04:12:15 as with everything it is a tradeoff 2017-10-03 04:12:50 well incorrect results seems like a really bad tradeoff :-( 2017-10-03 04:13:28 the results are not incorrect. but they differ. 2017-10-03 04:13:42 the bash and perl etc cases are related to their wrong code 2017-10-03 04:13:51 it is not gcc's fault 2017-10-03 04:14:23 yeah i guess they can differ with respect to undefined behavior 2017-10-03 04:14:26 the reason distcc between native and cross doesn't work correctly is because gcc's output can vary. it is always valid assembler, but it could spill registers differently, or use a different calling convention, or literally anything 2017-10-03 04:14:46 mm why would it be different? 2017-10-03 04:15:00 debian has done all this "reproducible builds" work which seems to all use GCC 2017-10-03 04:15:04 byte-for-byte equality 2017-10-03 04:15:05 and you have the same issue with clang, the difference is clang only has one equivalent of a spec file per architecture 2017-10-03 04:15:26 oilshell: a cross compiler can and sometimes will have different specs from a native compiler 2017-10-03 04:15:39 i have seen the spec files with the %s and whatnot 2017-10-03 04:15:41 i don't know much about them 2017-10-03 04:15:53 but as far as I understand that is part of the GCC code. that's an implementation detail 2017-10-03 04:16:06 if the spec files are different and it causes a difference in output 2017-10-03 04:16:09 well that just seems like a bug 2017-10-03 04:16:46 it isn't a bug because of the way GCC is designed, built, and supported; a GCC that has host/target difference is a different compiler to one that has the same host/target 2017-10-03 04:16:55 you can make them identical 2017-10-03 04:17:13 right so Alpine builds its own native GCC 2017-10-03 04:17:26 I assume it should also be able to build a cross GCC with the exact same spec files 2017-10-03 04:17:27 but it is a lot of work, and you might miss something, and if you do, you may not catch that missing something until you have already shipped 2500 packages with subtle bugs that no one notices until *bam* 0day or *bam* segfault in critical process 2017-10-03 04:17:36 and the output should be identical, modulo bugs in GCC ?? 2017-10-03 04:18:05 right well that is why I think the idea of having separate cross binaries is mistaken 2017-10-03 04:18:19 yes, as long as the gcc defaults don't change between versions, all options are specified manually instead of taking defaults, and so on 2017-10-03 04:18:30 yes I understand what you're saying 2017-10-03 04:18:35 but then you have all the other work 2017-10-03 04:18:35 you can build the compilers with many different options 2017-10-03 04:18:43 and if you don't match them, then you'll get different output 2017-10-03 04:19:09 now you have to make distcc work. or else your configure runs will be crossing too, and there are a *tonne* of bugs in autoconf re crossing. it's also really hard to cross with other build systems like jam. and explicitly impossible with waf. 2017-10-03 04:19:10 but that possibility also exists when building two different native compilers. but I suppose that cross compilation opens up even more possibilities for differences 2017-10-03 04:19:53 and then you have to run the test suite, which usually takes longer than building. CMake takes 7 mins to build and 39 mins to test on my PowerPC, for instance. libuv takes 3 mins to build and 11 mins to test on my 8-core xeon CPU 2017-10-03 04:19:59 i discovered an interesting fact about autoconf the other day 2017-10-03 04:20:00 and you can't cross a test run 2017-10-03 04:20:17 when you do a native compile, you can determine sizeof(int) in straightforward manner 2017-10-03 04:20:21 like #define SIZEOF_INT 4 2017-10-03 04:20:29 but what you are doing cross compiling, it can't run the program 2017-10-03 04:20:39 so autoconf uses an entirely different path to determine sizeof() 2017-10-03 04:20:50 so maybe you can take the build time down from say 30 to 10 mins by doing cross distcc 2017-10-03 04:20:53 it generates a bunch of C programs with guessed values and does a binary search!! 2017-10-03 04:20:54 but you still have test time 2017-10-03 04:21:03 like it tries 2, 8, 4, etc. and then sees which ones compiles 2017-10-03 04:21:08 oilshell: yep 2017-10-03 04:21:39 yeah i totally believe you will run into problems with that approach 2017-10-03 04:21:47 but I also believe someone should try it and document all those problems :) 2017-10-03 04:22:11 the bash and perl examples are good 2017-10-03 04:22:27 i mean you can think of it from a global perspective 2017-10-03 04:22:51 how many armhf packages are there in Alpine? which ones take the longest to build? and which ones can and can't be cross-compiled? 2017-10-03 04:23:13 i have a pet project that involves rebuilding an entire distro fast 2017-10-03 04:23:33 so that is why i'm interested 2017-10-03 04:24:02 if you really want fast, buy 64 rpis and cluster them with distcc; the number of packages that can't be distcc'd are pretty small 2017-10-03 04:24:11 now you have 64 arm cores 2017-10-03 04:24:18 you mean that 'can' be ? 2017-10-03 04:24:28 and it only cost you like... 2496$ 2017-10-03 04:24:42 yeah that might be the better approach. but this is open source so you can afford to parallelize, try two different approaches simultaneously :) 2017-10-03 04:24:49 oilshell: no, if it is all native armhf, a lot of packages can be built with distcc 2017-10-03 04:25:00 oh i see 2017-10-03 04:25:00 ok 2017-10-03 04:25:33 although I bought a pi zero and was shocked how slow it is. it's 30-100x than a single thread than my core i7 2017-10-03 04:25:53 if you compare mhz it would be 5x slower, 700mhz vs. 3.4 or something 2017-10-03 04:26:09 but it's really more like 50x slower. if you count the 8 cores i have, then that's 400x slower 2017-10-03 04:26:22 so 400 pi zeros at least are not going do much :) 2017-10-03 04:26:25 pi 3 is faster of course 2017-10-03 04:26:42 welcome to ARM 2017-10-03 04:26:57 clock-for-clock it is the worst arch I know of 2017-10-03 04:27:50 I have a 533mhz pentium 3 somewhere. it handled building some toy thing I was writing faster than a 900mhz pi2 2017-10-03 04:27:51 :) 2017-10-03 04:28:02 lol. well, I've learned a lot in the last 15 minutes, I don't know about y'all 2017-10-03 04:28:32 yup 2017-10-03 04:28:48 well I'm not an embedded guy, but I guess that is why buildroot and so forth exists? 2017-10-03 04:28:56 isn't it like android and it rewrites the build system for every package? 2017-10-03 04:29:11 yeah 2017-10-03 04:29:32 AFAIK it's one big tree like Android and you build the whole thing at once, selecting what you want 2017-10-03 04:29:36 i bet there's a good reason behind it, no person could willingly suffer so much 2017-10-03 04:29:39 that is the more typical embedded model afaik 2017-10-03 04:29:46 but that won't solve distcc and/or cross compiling and/or reducing build time woes 2017-10-03 04:29:48 the idea of crossing every package in alpine does seem like a pain in comparison 2017-10-03 04:30:26 well if you rewrite the build system you can make it work with both cross and distcc 2017-10-03 04:30:40 the point is that a lot of packages won't do that because the author never tested it 2017-10-03 04:30:47 the author has to specifically test for that, it doesn't automatically work 2017-10-03 04:31:34 oilshell: by build system, you mean the makefiles/configure scripts, etc in the package, not the abuild+friends build system, right? 2017-10-03 04:32:00 (just want to make sure I understand the terminology correctly) 2017-10-03 04:32:35 right 2017-10-03 04:33:14 someone earlier mentioned debian's reproducible builds.. they are doing no cross compiling? 2017-10-03 04:33:26 i don't think abuild has a concept of cross compilation, but that would be easy to add. the pmbootstrap page above says pmbootstrap adds this concept 2017-10-03 04:33:35 but just because those scripts have the concept, it doesn't mean the actual packages support it 2017-10-03 04:34:21 oilshell: yea pmbootstrap is crosscompiling. we have built quite a few things, including KDE, plasma, directfb, and a few others, with this concept 2017-10-03 04:35:19 I see. yea i understand that the app creators probably just envisioned it building on the same arch it will run on. 2017-10-03 04:35:48 this status update only talks about amd64: https://news.ycombinator.com/item?id=14834386 2017-10-03 04:35:53 I've seen this already in some configure checks (e.g. tinygles, which isn't in alpine) 2017-10-03 04:36:34 i think that Debian would have the exact same problems with cross compilation as we're pointing out here, because Debian has the widest number of packages from diverse authors 2017-10-03 04:36:48 so I would guess they don't do it but I don't know for sure 2017-10-03 04:37:15 I see. yea current progress report is limited, and rightfully so 2017-10-03 04:37:53 maybe look at how Raspian is built? 2017-10-03 04:37:59 that is a debian fork as I understand? 2017-10-03 04:38:08 and it supports a very wide variety of packages 2017-10-03 04:38:17 i hope they don't build on Raspberry Pis :) 2017-10-03 04:38:40 haha 2017-10-03 04:39:24 well even if they cross-comp, the issue of binaries not being equivalent could make for 0-days, segfaults-at-opportune-times, etc 2017-10-03 04:40:10 i'd also be interested in cases where QEMU screws up... I don't know anything about that 2017-10-03 04:40:19 i assume that some arches are much better maintained than others 2017-10-03 04:40:50 I don't think the compilers themselves should exercise weird corner cases of the architecture though 2017-10-03 04:41:15 running arbitrary code under QEMU seems different than just running a compiler to speed up builds 2017-10-03 04:41:26 ha, but I think they do 2017-10-03 04:41:35 like compilers are almost all single-threaded, for one 2017-10-03 04:41:49 i imagine a lot of corner cases are with respect to memory coherency and so forth 2017-10-03 04:41:56 can only speak for qemu x86 emulation 2017-10-03 04:42:02 (compilers exercise arch-specific shit) 2017-10-03 04:42:06 cr4 is implemented incorrectly, which led to cve in linux kernel when they only tested there 2017-10-03 04:42:22 cr2 is implemented as a noop, which leads to incorrect emulation in netbsd 2017-10-03 04:42:34 sse operations are available in all modes, which led to incorrect code in freebsd kernel 2017-10-03 04:42:54 sometimes the flags register isn't set correctly in long mode 2017-10-03 04:43:15 and that's just the incorrect behaviour that I have personally witnessed and attempted to fix 2017-10-03 04:44:14 ok interesting 2017-10-03 04:44:38 but I would imagine a single-threaded compiler should behave much more stably than a kernel 2017-10-03 04:44:46 i guess you have to run it on top of a kernel though :) 2017-10-03 04:45:02 oh, and on mips64, qemu-user doesn't correctly implement endianness 2017-10-03 04:45:09 it always emulates the endianness of your host 2017-10-03 04:45:15 so on ppc, it is always BE, even mips64le 2017-10-03 04:45:22 and on x86, it is always LE, even mips64 2017-10-03 04:45:37 huh? wow so it's just totally wrong? 2017-10-03 04:45:42 yes 2017-10-03 04:45:45 how would anything even work? 2017-10-03 04:45:56 nothing does work 2017-10-03 04:46:08 i guess most people run on QEMU on Intel / little endian ? 2017-10-03 04:46:17 i've never run qemu on anything besides x86 2017-10-03 04:46:24 maybe none of the devs do either 2017-10-03 04:46:29 I've run qemu on x86, ppc, and sparc 2017-10-03 04:46:57 targetting arm, m68k, microblaze, mips, ppc, sparc, x86 2017-10-03 04:47:11 in various combinations 2017-10-03 04:47:20 hm interesting 2017-10-03 04:47:48 yeah I guess I can see why rewriting the build system is the standard practice 2017-10-03 04:47:57 cross compiling is annoying 2017-10-03 04:48:04 emulation is annoying 2017-10-03 04:48:22 or rather getting the author's build system to cross compile 2017-10-03 04:48:23 emulation is useful for quick tests, but it never substitutes real hardware 2017-10-03 04:48:37 when you rewrite you can throw out all the autoconf 2017-10-03 04:48:48 put another way: something passing on qemu doesn't mean it will pass on real hardware, but if it fails on qemu.. wow you must have screwed up bad :) 2017-10-03 04:49:13 fwiw that is what Google does on all its server platforms. all the autoconf is thrown out and bazel is used instead: https://bazel.build/ 2017-10-03 04:49:30 e.g. if you're compiling Python or R etc. you don't use their Makefiles anymore 2017-10-03 04:49:43 and yes that's a big pain but there is a certain logic to it 2017-10-03 04:50:05 if you control the build system you can control exactly what is built, how it is built, and when 2017-10-03 04:51:00 well then, with the caveat that I'm not an embedded guy, it does seem like PMOS is sort of breaking the normal embedded model?? 2017-10-03 04:51:06 it seems like swimming upstream 2017-10-03 04:51:16 why not use buildroot or whatever instead of alpine? 2017-10-03 04:51:29 i thought that is what buildroot is for, and yocto, etc. 2017-10-03 04:55:30 I think that was the point of the project 2017-10-03 04:55:38 breaking the normal embedded model 2017-10-03 04:56:35 idk. I was involved with a phone project in 2010, and haven't touched anything embedded since, so I'm many years removed from that whole ecosystem 2017-10-03 04:57:05 yeah as far as I understood the point is to avoid forking the linux kernel for every single device 2017-10-03 04:57:14 instead have many devices building out of the same source tree 2017-10-03 04:57:22 every vendor right now has their own android fork 2017-10-03 04:57:52 but yeah it sounds like there are some nontrivial problems to solve when you break the model 2017-10-03 04:57:55 sounds like a good idea though 2017-10-03 05:33:28 kaniini: got gnome working on arm but its a hacky fix 2017-10-03 07:04:18 ollieparanoid: only Travis does. At least with pmbootstrap, I can not have a `-doc` package fine 2017-10-03 11:16:26 jenkins needs an apk update - ERROR: libpng-1.6.34-r0: package mentioned in index not found (try 'apk update') 2017-10-03 12:15:12 fabled, you around? 2017-10-03 12:15:36 I got an error with prosody 0.10 compile, which looks for mallinfo 2017-10-03 12:15:44 https://dpaste.de/KzOK/raw 2017-10-03 12:15:50 I've made this patch 2017-10-03 12:15:54 wondering if it's ok 2017-10-03 12:16:58 basically if is not defined WITHOUT_MALLINFO then it is set, calling the macro WITH_MALLINFO which has 2017-10-03 12:16:59 .. 2017-10-03 12:16:59 struct mallinfo info = mallinfo(); 2017-10-03 12:17:00 .. 2017-10-03 12:17:21 and of course the build fails 2017-10-03 12:18:11 so I removed that "#define WITH_MALLINFO" if WITHOUT_MALLINFO is not set 2017-10-03 12:18:21 *is set 2017-10-03 12:18:34 there are not other references to mallinfo 2017-10-03 12:18:50 with this, prosody builds correctly 2017-10-03 12:19:09 can someone please bump libsodium to 1.0.15 2017-10-03 12:19:19 I've tried to : 2017-10-03 12:19:22 make WITHOUT_MALLINFO=1 2017-10-03 12:19:32 but it seems to be ignored 2017-10-03 12:26:46 wWrAR07vpPZ1, 1.10.15 breaks ABI 2017-10-03 12:30:16 oh? how? 2017-10-03 12:31:01 wWrAR07vpPZ1, the new libsodium version breaks ABI, so all the packages having libsodium as dependency needs to be rebuilt 2017-10-03 12:31:02 fcolista: because that sets the make variable, not the C preprocessor define 2017-10-03 12:31:24 Shiz, do you think that my patch is fine? 2017-10-03 12:31:38 no 2017-10-03 12:31:57 i think you should figure out which part of the configure process sets WITHOUT_MALLINFO and fix it 2017-10-03 12:31:58 ok 2017-10-03 12:32:05 this seems like a kludge that's definitely not upstreamable 2017-10-03 12:32:05 ah ok 2017-10-03 12:33:30 Shiz, actually configure does not set this 2017-10-03 12:34:00 seems so 2017-10-03 12:34:15 i'd do something like this then 2017-10-03 12:34:27 (still not a super proper fix, but somewhat workable) 2017-10-03 12:34:39 replace the entire line by #ifdef __GLIBC__ 2017-10-03 12:34:41 fcolista: eh. you're right, just read the release doc. 2017-10-03 12:35:09 ah ok 2017-10-03 12:35:57 a proper fix would be detecting mallinfo in the configure.ac process but that's not a patch i wanna write out while at work 2017-10-03 12:35:59 :p 2017-10-03 12:36:12 there's no configure.ac 2017-10-03 12:36:20 I was looking for that 2017-10-03 12:36:25 I would have patched that one 2017-10-03 12:36:29 oh it's a manual configure 2017-10-03 12:36:33 yes 2017-10-03 12:37:44 Shiz, if i remove that line 2017-10-03 12:37:52 and set __GLIBC__ 2017-10-03 12:37:55 what about this: 2017-10-03 12:37:56 #if !defined(WITHOUT_MALLINFO) && defined(__linux__) 2017-10-03 12:37:56 #include 2017-10-03 12:37:56 #define WITH_MALLINFO 2017-10-03 12:37:56 #endif 2017-10-03 12:38:00 don't set __GLIBC__.... 2017-10-03 12:38:15 Shiz, i mean this: #ifdef __GLIBC__ 2017-10-03 12:38:18 you replace '#if !defined(WITHOUT_MALLINFO) && defined(__linux__)' by '#ifdef __GLIBC__' 2017-10-03 12:38:28 ah ok 2017-10-03 12:38:31 thx 2017-10-03 12:38:33 np 2017-10-03 12:39:20 https://dpaste.de/d2rm/raw 2017-10-03 12:39:21 done 2017-10-03 12:39:23 thx 2017-10-03 18:31:55 <_ikke_> Anyone got experience with packaging go projects? I need to fix the dependencies 2017-10-04 01:47:01 jirutka: thanks for reviewing. I will make the changes later this week or weekend; we are currently desperately trying to tidy up the last media packages necessary for KDE 5 desktop 2017-10-04 08:25:58 I wish there was a place where I could just 2017-10-04 08:26:01 post a bunch of questions 2017-10-04 08:26:04 and get answers 2017-10-04 08:26:15 like: why is xvidcore makedepends="nasm" but --disable-assembly? 2017-10-04 08:26:39 and: why does gstreamer 1.0 packages have ldpath="/usr/lib/gstreamer-.0" instead of -1.0? 2017-10-04 09:03:34 is it really only x86 that has assembler problems on x265? or should that be x86*? 2017-10-04 09:04:01 foxkit, x86 only 2017-10-04 09:04:14 the issue is related to the fact that we build everything PIE enabled 2017-10-04 09:04:14 ah okay 2017-10-04 09:04:23 and x86 has limitations in this mode 2017-10-04 09:04:34 oh right, because of limited registers and silly GOT 2017-10-04 09:04:36 yes 2017-10-04 09:04:41 I see :) 2017-10-04 09:04:51 text relocations; and they way GOT works on x86 2017-10-04 09:10:28 was there really a eglibc based alpine at one point? 2017-10-04 09:10:56 there is reference to it in main/faac 2017-10-04 09:12:19 i tried ones :) 2017-10-04 09:12:50 git blame will probably point in my diection. 2017-10-04 09:13:05 ah. I guess it didn't go so well, since it doesn't exist any more? 2017-10-04 09:15:54 it works ofc, but after playing around i didnt really have the energy to maintain it. 2017-10-04 15:37:17 the 'make check' caught another upstream bug (buffer overflow) 2017-10-04 15:37:39 it caused the test segfault on x86 and armhf 2017-10-04 15:38:00 https://bugzilla.gnome.org/show_bug.cgi?id=788495 2017-10-04 15:38:26 shows the value of supporting multiple arches 2017-10-04 15:38:36 and running tests 2017-10-04 15:53:55 Nice. That only affects musl and not glibc, or is no one actually running 'make check's outside of Alpine? 2017-10-04 15:57:58 i think musl's malloc catches that 2017-10-04 15:58:03 it affects all 2017-10-04 17:13:34 I am curious how musl turns a 1-byte buffer overflow into a segfault 2017-10-04 17:14:11 I'm not very familiar with it but I looked in the manual for debug malloc bounds checks and didn't find anything 2017-10-04 17:14:15 all I found was: http://git.musl-libc.org/cgit/musl/commit/?id=70a92bc968156155dd578f7fb1d4c4e3fceb32f8 2017-10-04 17:14:31 "new footer-corruption check in realloc and free." but I don't see this documented anywhere 2017-10-04 17:15:13 anyway it's cool that it turned it into a crash and the bug is found, but I wonder what other kinds of bugs it can find. I have used LLVM ASAN in the past and it is great 2017-10-04 17:15:47 IMO all C unit tests benefit from ASAN -- they are free tests, but unfortunately a lot of build systems make that hard 2017-10-05 05:22:08 Hi there, just looking for some help creating custom ISO's :) 2017-10-05 05:36:31 deci: https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage is the wiki page 2017-10-05 05:37:42 deci: you are using that wikipage, right? not the older one? 2017-10-05 05:51:02 oops, I was indeed using the old one! 2017-10-05 05:51:10 Thank you :) I'll give this one a try now 2017-10-05 06:14:40 morning 2017-10-05 07:06:07 once dalias ACKs http://www.openwall.com/lists/musl/2017/10/05/1, libbsd will get funopen(3) support :) 2017-10-05 07:59:59 kaniini, i tried that once before 2017-10-05 08:00:02 it did not work out well 2017-10-05 08:00:32 kaniini, http://www.openwall.com/lists/musl/2014/11/11/2 2017-10-05 08:01:59 fabled: i talked with him about it. he is okay with fopencookie as long as he can say that doing weird stuff in the callbacks is undefined behaviour 2017-10-05 08:02:08 oh 2017-10-05 08:02:10 that's a change 2017-10-05 08:02:12 cool 2017-10-05 08:02:30 like longjmp for example 2017-10-05 08:07:30 i submitted very similar patch back in 2014 2017-10-05 08:08:54 my version was: http://sprunge.us/deIX in case you want to cross-check. though it no longer works as-is due to musl stdio changes 2017-10-05 08:16:32 dalias mentions he wants to avoid pthread locking in stdio these days 2017-10-05 08:16:37 that's why i didn't go with that 2017-10-05 08:20:10 it's not doing any write/read buffering, is the buffer really needed? 2017-10-05 08:20:19 i had the buffer because my code was doing some buffering 2017-10-05 08:25:45 it is needed 2017-10-05 08:25:50 musl uses it internally 2017-10-05 08:25:56 yes, i know 2017-10-05 08:26:36 in theory there should be a way to bypass it, but musl literally wants it buffered anyway 2017-10-05 08:26:53 or at least a semblance of a buffer 2017-10-05 08:27:43 ok. good. 2017-10-05 08:29:18 it does work with the official GNU example, http://turtle.dereferenced.org/~kaniini/test_fopencookie.c 2017-10-05 08:29:29 and the libbsd funopen(3) user that i have seems to also work fine 2017-10-05 08:29:41 oops 2017-10-05 08:29:47 http://turtle.dereferenced.org/~kaniini/test_fopencookie.c.txt 2017-10-05 08:29:48 even 2017-10-05 08:33:45 nice 2017-10-05 09:53:45 wonder if https://code.foxkit.us/adelie/packages/blob/master/user/baloo/APKBUILD#L10-22 would satisfy jirutka ;) 2017-10-05 10:52:58 hi guys, how can i do to set lxdm and xfce in spanish? 2017-10-05 19:52:56 fabled, thank you for your delivery again 2017-10-05 20:53:56 hi guys, I have a question about udev-setup: https://github.com/alpinelinux/aports/blob/master/main/eudev/setup-udev 2017-10-05 20:54:42 1. I'm pretty sure the if [ -z "$dryrun" ] block should be outside of the loop, I'll make a patch for that soon unless I'm confusing this 2017-10-05 20:54:54 2. should this script enable the services, or only start them once? 2017-10-05 20:55:25 because when you run them once, you have udev set up for the current session, until you reboot. but as I understand, the setup-* script should make persistent changes, right? 2017-10-05 21:09:09 i believe it does both 2017-10-05 21:09:12 if it does not, its a bug 2017-10-05 21:18:28 what are the alpine priorities before 3.7 as of now? 2017-10-05 21:18:29 i'm gonna have a lot to do until mid next month but i want to contribute to alpine 2017-10-05 21:18:30 ❨✘❩ Disconnected (). 2017-10-05 21:31:59 kaniini: thanks for the answer - it does not enable them (the script is short, it's quite obvious), I'll make a PR to fix this 2017-10-05 22:24:04 Thanks ollieparanoid ! :) 2017-10-05 22:25:46 kaniini: my odroid armhf thing is sitting in my mailbox right now, I'll work on getting that thing booted w/ Alpine later so I can do some (hopefully faster) armhf compiles for debugging build failures 2017-10-05 22:29:39 waiting on power adapter for mine 2017-10-06 01:11:08 hey 2017-10-06 01:13:21 is this discussion on the mailinglist for real or just a bad joke? 2017-10-06 01:16:06 why would it be a bad joke? 2017-10-06 01:16:37 a code of conduct that mentiones people using a special programming language? 2017-10-06 01:18:25 awilfox's comment does not mention a specific programming language 2017-10-06 01:18:53 I agree with aphrael's statement on that reply, however 2017-10-06 01:19:21 i mean, come on: "Not sure if you want to explicitly call out discrimination based on programming language preference in the explicitly disallowed conduct section as well" 2017-10-06 01:19:32 that is the highest form of trolling i have ever seen 2017-10-06 01:20:00 "It’s sometimes scary to be a Python developer in #alpine-devel, and I really feel for the Go programmers as well" 2017-10-06 01:20:14 i mean, really? did people get threatened in here? no, they did not 2017-10-06 01:20:51 please don't deny other people's experiences 2017-10-06 01:21:20 experiences? 2017-10-06 01:21:21 or dismiss them as trolling -- awilfox is quite the serious contributor to alpine, and even if they weren't 2017-10-06 01:22:17 yes, experiences 2017-10-06 01:22:56 I don't know either what caused them to feel like that, but I'm not going to tell them it didn't happen as I both don't read every single message here and understand that things can get interpreted differently as I do 2017-10-06 01:23:19 s/as/than/ 2017-10-06 01:24:13 i do read around 90% of all messages here and there was absolutly nothing to call for this 2017-10-06 01:24:30 I don't think that's a decision you can make for others, sorry 2017-10-06 01:25:05 well, if someone cannot handle other people talking bad about there prefered programming language then sorry, but they have to grow up 2017-10-06 01:25:23 their statement did not imply that happening 2017-10-06 01:28:24 so if it is not happening, why bring it up in the first place and make a mockery out of alpine? 2017-10-06 01:28:33 i totally agree with jirutka here 2017-10-06 01:30:36 their statement did not imply people talking shit about programming languages happening 2017-10-06 01:30:51 what it did imply was discrimination or otherwise unfair treatment of people according to their preferred programming language 2017-10-06 01:30:58 and i'm gonna stop here since i'm heading to bed 2017-10-06 01:35:34 is there any way to see this discussion after the fact 2017-10-06 01:35:38 like a web interface 2017-10-06 01:35:41 or did i miss it 2017-10-06 01:35:49 https://lists.alpinelinux.org/alpine-devel/5842.html 2017-10-06 01:35:58 i appreciate you xe 2017-10-06 01:38:05 from an admittedly-outsider pov this doesnt look bad at all so idk why anyone could consider this 'making a mockery out of alpine' 2017-10-06 01:39:07 Arcaire: read the followups 2017-10-06 01:39:59 ok nvm 2017-10-06 01:41:24 take init system out, replace with 'personal technological preferences', you cover those bases 2017-10-06 01:41:43 the init system one is there for a reason 2017-10-06 01:41:58 seriously? 2017-10-06 01:42:10 how offended can people possibly get - on both sides - over an init system? 2017-10-06 01:42:19 it's not about that 2017-10-06 01:42:23 then remove it 2017-10-06 01:42:42 we get from time to time people who come along and see the alpine community as their new favourite place to sit around and bash on systemd 2017-10-06 01:42:51 we're not terribly interested in this, so it will remain 2017-10-06 01:43:09 sure, but why does that particular piece of bad behaviour have any highline relevance to discrimination? 2017-10-06 01:43:24 "personal technological preferences" covers init systems and programming languages 2017-10-06 01:43:42 but it also doesn't make it so pointlessly specific as to result in a list expanding ad-infinitum as i see in the follow-up posts 2017-10-06 01:44:00 ACTION shrugs 2017-10-06 01:44:31 you render it that specific someone is going to say "WELL IT ISN'T POINTED OUT!!!" 2017-10-06 01:44:43 evidently someone was cyberbullied about being a python dev in the past, so ... 2017-10-06 01:45:06 i don't disagree with Arcaire fwiw 2017-10-06 01:45:10 it was not python, and it was not a specific individual, and i see no reason to bring up past sins 2017-10-06 01:45:10 that said, i was going to go to bed... 2017-10-06 01:45:15 overall i like the coc in the form you presented it with that one criticism, and i generally think cocs are pretty dumb 2017-10-06 01:45:35 Shiz: good night ;) 2017-10-06 01:45:46 generally we (itsec apac) boil cocs down to "dont be an ass" because there's no room for lawyering around that 2017-10-06 01:46:12 https://www.kiwicon.org/faq/#q9 2017-10-06 01:46:16 good ex. 2017-10-06 01:46:37 anyway, if you would like to contribute that suggestion, please reply with it on the thread 2017-10-06 01:47:03 you've already seen the suggestion and you're the one putting it forward 2017-10-06 01:47:08 will it render any good me putting it in an email? 2017-10-06 01:47:25 yes, it will add a statement of record suggesting the change 2017-10-06 01:47:25 yes 2017-10-06 01:47:29 Arcaire: it will be more visible to other people 2017-10-06 01:47:36 *shrugs* aight 2017-10-06 01:47:41 email lists are more permanent than IRC 2017-10-06 01:47:42 alpine isn't a (complete) top-down project 2017-10-06 01:47:46 community opinions are important 2017-10-06 01:48:05 the draft is in community review process, the core group is requesting feedback from the community to incorporate into a second draft 2017-10-06 01:48:11 so yes, i need it in email 2017-10-06 01:48:20 i've been using alpine for like five minutes so i don't think it holds much weight, i just do a lot of community management of 'problem user'-filled communities 2017-10-06 01:48:26 but ok will do 2017-10-06 01:48:49 5 minutes, 5 seconds, doesn't matter, any suggested edits need to go into the thread 2017-10-06 01:49:28 ACTION takes their "make alpine great again" hat off and considers dinner 2017-10-06 01:51:07 Arcaire: for what it's worth, i'm not against changing it to something like "init system or other personal technological preference" 2017-10-06 01:51:22 but it was explicitly specified as a requirement to address the systemd hate crowd 2017-10-06 01:51:57 i'd still argue that this doesn't have to be explicitly codified and we can continue advising people who do this to cancel their internet service provider contracts 2017-10-06 01:51:59 but 2017-10-06 01:52:03 to the email thread 2017-10-06 01:52:41 well, it's complicated. some level of codification is needed so that third parties such as freenode and github will back us up 2017-10-06 02:32:40 >when you post but fastmail eats the verification and it never appears on the list 2017-10-06 02:32:44 ty obama 2017-10-06 02:33:01 o nvm it came through anyway 2017-10-06 02:37:40 thanks :) 2017-10-06 02:37:50 np 2017-10-06 02:38:26 apologies for no 80-char line length limit and mildly broken threading 2017-10-06 02:38:29 idk what caused the latter 2017-10-06 02:38:38 prob because i use webmail like a filthy casual 2017-10-06 02:43:10 i use webmail, too. 2017-10-06 02:46:17 leo-unglaub: the CoC effort is serious, but largely is intended to align alpine's community standards with those of sister projects in the overall ecosystem 2017-10-06 02:51:15 well I'm not making much progress today on my odroid arm thing.. my usb->ethernet dongle doesn't seem to be working anymore. The odroid-c0 was a bad choice. Bad craftyguy, bad. 2017-10-06 02:52:16 the worst part is that there's an eth chip on this thing (kernel shows it), but no traces/pads available on the board to solder an eth connector to. 2017-10-06 02:55:23 the c2 seems decent 2017-10-06 02:55:35 need to find a power brick for it tho 2017-10-06 02:57:04 Yea it does. I totally failed for now with the C0. I thought I could just solder on some usb connectors that I have and be off and running, but nooooope 2017-10-06 02:57:52 Arcaire: trust me, i would rather spend my time hacking on alpine 4 projects, such as apk3 and svc (a prototype multi-process init system replacement) than doing this CoC thing 2017-10-06 02:58:19 What is CoC? 2017-10-06 02:58:32 Was that directed at me for any reason or? 2017-10-06 02:58:39 I read through the history here, but I must have missed it 2017-10-06 02:58:50 I've known you for like half a decade, I'm well aware of what you'd prefer doing out of those two options. :P 2017-10-06 03:01:37 but the CoC is important to bring finality to and get absolutely right 2017-10-06 03:15:03 lol I'm an idiot 2017-10-06 03:16:14 oh? 2017-10-06 03:16:54 I just deciphered the CoC acryonym. yea! 2017-10-06 03:17:01 oh, sorry 2017-10-06 03:17:04 missed your question 2017-10-06 03:17:13 craftyguy[m], http://lists.alpinelinux.org/alpine-devel/5842.html 2017-10-06 03:17:30 Yep, I'm with y'all now :D 2017-10-06 03:17:33 :) 2017-10-06 03:18:10 hey better late than never, or something! 2017-10-06 08:42:39 we have an issue with berkleydb 2017-10-06 08:42:56 the current version 5.3.28 has a bunch of vulnerabilities 2017-10-06 08:43:10 6.2.32 seems to have the fix(es) 2017-10-06 08:43:26 it breaks abi so i tried to rebuild 2017-10-06 08:43:38 openldap fails to build due to the license is incompatible 2017-10-06 08:44:05 conftest.c:148:2: error: #error "BerkeleyDB 6.0.20+ license is incompatible with 2017-10-06 08:44:05 LDAP" 2017-10-06 08:44:05 #error "BerkeleyDB 6.0.20+ license is incompatible with LDAP" 2017-10-06 08:44:05 ^~~~~ 2017-10-06 08:44:34 we could drop the hdb bdb backends for openldap 2017-10-06 08:45:05 but i wonder if someone has time to help me figure out what the license issue is and if it affects other projects too 2017-10-06 08:45:27 my question is, can we or should we upgrade to db 6.2.x? 2017-10-06 08:45:37 or should we try get rid of it 2017-10-06 08:45:46 can we get rid of it? 2017-10-06 08:46:11 any volunteer to help figure that out? 2017-10-06 08:48:53 <_ikke_> ncopa: I might have some time this evening 2017-10-06 08:49:04 i prefer to stay at bdb 5 2017-10-06 08:49:08 bdb 6 is non-free per our guidelines actually 2017-10-06 08:49:14 it is literally affero gpl 2017-10-06 08:49:36 so we dont want bdb 6 2017-10-06 08:49:38 right? 2017-10-06 08:49:39 meaning anything it touches becomes undistributable 2017-10-06 08:49:43 yes 2017-10-06 08:50:43 _ikke_: thanks for villing to help but i think i got the answer i needed 2017-10-06 08:50:52 <_ikke_> right 2017-10-06 08:50:53 what a mess 2017-10-06 08:50:57 indeed 2017-10-06 08:51:24 i think we want drop bdb support alltogether if possible 2017-10-06 08:51:30 at least longterm 2017-10-06 08:51:32 sigh i will write a wrapper around tokyo cabinet to replace it 2017-10-06 08:51:38 for packages that need it 2017-10-06 08:52:12 commercial licensing of bdb ranges from $900 to $13500 per cpu 2017-10-06 08:52:16 wow that is mental 2017-10-06 08:52:22 <_ikke_> wow 2017-10-06 08:52:35 sounds like its worth it 2017-10-06 08:52:37 NOT 2017-10-06 08:52:38 :) 2017-10-06 08:52:49 <_ikke_> Is bdb still that relevant that they can ask such prices? 2017-10-06 08:53:13 i need to prepare my slides for dockercon today 2017-10-06 08:53:17 i doubt it 2017-10-06 08:59:36 db.h looks straightforward i can probably prototype a wrapper this weekend 2017-10-06 09:14:23 <_ikke_> Any policy regarding suid programs? 2017-10-06 09:17:24 yeah, remove the suid bit 2017-10-06 09:17:42 <_ikke_> What if the program is designed around having it? 2017-10-06 09:18:59 then either don't use the program or patch it out I guess 2017-10-06 09:25:37 <_ikke_> PureTryOut[m]: In this case, it's pmount. It's meant to allow users to mount removable media without root 2017-10-06 09:25:40 <_ikke_> hence the suid 2017-10-06 09:26:11 aah. can't that be handled with some polkit rules? 2017-10-06 09:26:26 <_ikke_> Probably 2017-10-06 09:26:44 you want options="suid" if you have a good reason for it 2017-10-06 09:26:48 otherwise abuild will yell at you 2017-10-06 09:26:52 <_ikke_> hehe 2017-10-06 09:27:17 <_ikke_> this program will yell at you without suid 2017-10-06 09:52:45 patches are preferred 2017-10-06 09:52:47 :P 2017-10-06 09:54:15 anyway 2017-10-06 09:54:20 mounting removable can be done without root 2017-10-06 09:55:01 although you'd still need CAP_SYS_ADMIN... blegh 2017-10-06 10:00:46 <_ikke_> Shiz: What I'm trying to say is that the whole idea of the program is that it should be run as root. If that's not preferred, it does not make sense to package it at all 2017-10-06 10:01:03 look up capabilities before making that statement 2017-10-06 10:02:26 <_ikke_> right 2017-10-06 10:02:56 capablehities 2017-10-06 10:12:30 this is what kio (KDE I/O daemon) does when it needs to mount things for the user 2017-10-06 10:12:34 it uses libcap and CAP_SYS_ADMIN 2017-10-06 10:12:36 no suid 2017-10-06 10:16:31 I don't even know for sure what udisks does to implement this, but it's related to policykit 2017-10-06 10:17:23 it's crap all the way down 2017-10-06 10:24:52 it's all just the same privilege mechanisms abused in different ways really 2017-10-06 10:37:52 <_ikke_> Any idea how I should deal with go dependencies in a package? 2017-10-06 10:41:45 ikke: have you looked at glide? 2017-10-06 10:42:09 There are some examples in aports 2017-10-06 10:43:12 <_ikke_> clandmeter: is gogs a good example? 2017-10-06 10:44:17 Not sure, in the supermarket now 2017-10-06 10:44:29 <_ikke_> heh 2017-10-06 10:44:57 Are you sure they are not bundled already? 2017-10-06 10:45:33 <_ikke_> no, it downloads the dependencies during build 2017-10-06 10:47:44 <_ikke_> https://travis-ci.org/alpinelinux/aports/builds/282397691#L697 2017-10-06 11:27:41 was there coming some conferences / fairs with alpine people going in? 2017-10-06 11:30:00 LinuxDays in Czech Republic, like, tomorrow XD 2017-10-06 11:33:03 a Linux conference in Czech Republic sounds like something I would attend ... if only I had the time 2017-10-06 11:59:51 _ikke_: im looking at the pr 2017-10-06 12:00:11 you will probably need to patch the makefile 2017-10-06 12:08:44 and they already include glide file so you can install deps from prepare with glide (if the glide files are uptodate). 2017-10-06 12:25:12 Is it possible to get abuild to extract several sources to their own directory? Currently it just extracts all 3 tar.gz's into one folder but I need them seperated. Can't change the tar.gz's btw 2017-10-06 12:26:18 define your own unpack function if the std one doest do what you want. 2017-10-06 12:28:46 clandmeter: Should I copy the default unpack function and customize it? Or just hard-code the source names into it and running some command 3 times? 2017-10-06 12:31:03 i would look at the logic of abuilds unpack and create a new one more suited for your aport. 2017-10-06 12:31:56 i think there are some examples in aports. you can grep for it. 2017-10-06 13:22:06 clandmeter: thanks 2017-10-06 15:08:54 <_ikke_> clandmeter: My question is, where should the deps come from if they should not be downloaded, should they be included in the package? 2017-10-06 16:54:55 _ikke_: no, you should fetch them in prepare 2017-10-06 16:55:28 <_ikke_> clandmeter: ok, so the issue is they should not be fetched at build time, but rather at prepare time. That's clear 2017-10-06 16:55:36 you can use the supplied glide lock file or create your own. 2017-10-06 16:55:43 yes 2017-10-06 16:55:54 but not only that 2017-10-06 16:56:12 the sources should be locked to specific commit/version 2017-10-06 16:56:20 <_ikke_> understood 2017-10-06 16:56:54 <_ikke_> Now I understand the goal :) 2017-10-06 16:57:00 so the builds are reproducible 2017-10-06 16:57:34 <_ikke_> yea 2017-10-06 16:57:49 the glide lock file will have references to specific commits/versions 2017-10-06 16:58:07 so if you fetch sources with glide, it will always be the same. 2017-10-06 16:58:36 if you are missing the lock file, you can generate your own and add it to aports. 2017-10-06 16:58:58 <_ikke_> Right, I understand the purpose of the glide file 2017-10-06 16:59:26 <_ikke_> thanks! 2017-10-06 16:59:33 nice 2017-10-06 16:59:35 then i can go deck the table 2017-10-06 17:00:25 <_ikke_> hehe 2017-10-06 17:00:29 <_ikke_> enjoy dinner 2017-10-06 17:00:41 <_ikke_> Nice dutchism :P 2017-10-06 18:00:41 clandmeter: you seem to use Matrix, but you're nickname suggests you've joined a different bridged room. may I ask what room you joined? 2017-10-06 18:01:37 im setting up an alpine matrix server and trying it out. 2017-10-06 18:04:48 so you in fact didn't join #freenode_#alpine-devel:matrix.org then right? 2017-10-06 18:05:09 i did before 2017-10-06 18:05:23 cause joining a Matrix room, bridged to IRC, bridged to Matrix causes all kind of messed up stuff 2017-10-06 18:06:08 <_ikke_> lol 2017-10-06 18:06:14 <_ikke_> chat loop 2017-10-06 18:08:27 ive setup a few rooms and added irc integration. is that what you mean? 2017-10-06 18:11:43 yeah. you're now in a Matrix room bridged to IRC, bridged to Matrix 2017-10-06 18:11:54 please just join #freenode_#alpine-devel:matrix.org instead 2017-10-06 18:17:30 do you have an references to these issues? information about integration is limited. 2017-10-06 18:19:58 well I just know issues from my experience. the most obvious one is the display name being messed up. my display name to you is probably "@freenode_PureTryOut[m]:matrix.org", while it should be just "PureTryOut". 2017-10-06 18:20:24 secondly, any in-text links that might be there, like username and room mentions, are afaik gone when passing through IRC 2017-10-06 18:20:51 also, even though this room does not use it, any integrations will not be passed through. think of an Etherpad 2017-10-06 18:21:01 *think for example of Etherpad, a Youtube video, or Jitsi 2017-10-06 18:23:16 ok thanks for the headsup, i will look into it. 2017-10-06 18:23:21 <_ikke_> Am I misunderstanding ncopa here? https://github.com/alpinelinux/aports/pull/2433#pullrequestreview-66572162 2017-10-06 18:23:42 but I'm glad Synapse works on Alpine Linux! did you have many issues? 2017-10-06 18:24:05 a few 2017-10-06 18:24:15 _ikke_: I think he is mainly referring to the makedepends 2017-10-06 18:24:21 depends in itself should work fine iirc 2017-10-06 18:24:21 i added an issue to the tracker related to grsec 2017-10-06 18:24:36 <_ikke_> Yeah, but he requested the makedepends in the first place (see the comment above this) 2017-10-06 18:25:27 i think he means to the main pkg 2017-10-06 18:25:35 _ikke_: the Go dep you mean? 2017-10-06 18:25:41 <_ikke_> no, bash and tmux 2017-10-06 18:25:45 ooh wait, above that even 2017-10-06 18:25:59 <_ikke_> they are not makedepends 2017-10-06 18:26:06 I think he means you should add those makedepends to the top 2017-10-06 18:26:23 no they not but it will force the builder to build them first 2017-10-06 18:26:38 add it to makedepends on top, and add them to the depends of the split package like you have now 2017-10-06 18:26:41 its for when we build world for a new release 2017-10-06 18:27:30 <_ikke_> Does the build order make a difference here? (Trying to understand the issue) 2017-10-06 18:30:56 im not sure but this is what i think what happens. 2017-10-06 18:31:41 <_ikke_> Note that it's just about a shipped bash script 2017-10-06 18:31:49 when we create a new release we start the build from scratch and our scripts will calculate build order based or pkg deps and makedeps 2017-10-06 18:32:00 <_ikke_> right, I follow so far 2017-10-06 18:32:02 the subpkg deps are only available when the pkg is build 2017-10-06 18:32:16 <_ikke_> that's also clear 2017-10-06 18:32:19 can't the bash script be ported to Ash (which Alpine uses, right?)? 2017-10-06 18:32:39 <_ikke_> PureTryOut[m]: can possibly, but for now, I just want to get it included as is 2017-10-06 18:33:19 so when a package starts building because the deps/makedeps are available, it will fail because the subpkg depends on things that maybe not yet available. 2017-10-06 18:33:34 <_ikke_> clandmeter: even if it's just a runtime dep? 2017-10-06 18:35:04 like i said im not 100% sure, but i think it will fail just like abuild will always pull in all depends. 2017-10-06 18:35:41 <_ikke_> clandmeter: ah ok 2017-10-06 18:36:36 <_ikke_> clandmeter: that makes sense then 2017-10-06 18:37:11 PureTryOut: there is also an issue with the py json module 2017-10-06 18:37:27 it has been reported upstream but it seems the project is a bit slow recently 2017-10-06 18:40:03 PyJson or Synapse? 2017-10-06 18:45:50 no the name is different of the py module 2017-10-06 18:46:31 <_ikke_> I often wondered why makedepends was never treated as everything needed to build the package (not the combination of depends and makedepends) 2017-10-06 18:47:31 https://github.com/esnme/ultrajson/issues/254 2017-10-07 05:49:47 there 2017-10-07 06:24:24 <_ikke_> Connected through matrix 2017-10-07 07:41:59 any reason v4l-utils is built without alsa? prevents one from listening 2017-10-07 09:34:34 Is this channel bridged with freenode #alpine-devel ? 2017-10-07 09:34:59 Okay yes it seems to be ^^ 2017-10-07 09:41:16 > Is this channel bridged with freenode #alpine-devel ? 2017-10-07 09:41:17 Yes. https://screenshots.firefox.com/dOacDPibPrat2QY8/riot.lcpu.club 2017-10-07 09:41:56 okay 2017-10-07 09:45:58 oh cool firefox screenshots is still a thing 2017-10-07 10:07:00 why is everyone in the wrong Matrix room lol 2017-10-07 10:07:24 vimacs and Kaniini: please join #freenode_#alpine-devel:matrix.org instead 2017-10-07 10:15:17 PureTryOut: two different rooms, but bridged to one IRC channel, with the same bridge bot... 2017-10-07 10:15:39 I know, it messes things up. please just all join the same room 2017-10-07 10:21:16 Well, we may need to ask the admins of #alpine-*:alpinelinux.org... 2017-10-07 10:22:49 ooh, I thought you bridged your own room... didn't realize Alpine hosted their own Matrix server as well 2017-10-07 10:32:50 ooh Kaniini actually mentioned they did in #postmarketos:disroot.org . Sorry, I guess we'll move over then 2017-10-07 10:33:23 craftyguy, bloom , hl , jnettlet , scadu , ollieparanoid and pablog , please move over to #alpine-devel:alpinelinux.org 2017-10-07 10:34:13 Yes, I know this room from the #postmarketos room. 2017-10-07 10:34:15 ACTION wonders why it's not just #devel:alpinelinux.org 2017-10-07 10:35:38 <_ikke_> probably to match the existing irc channel 2017-10-07 10:36:24 we can have both! 😄 2017-10-07 10:40:19 <_ikke_> Seems to be we have a bug in abuild checksum, it corrupts an APKBUILD 2017-10-07 10:41:46 <_ikke_> fg 2017-10-07 10:54:24 Morning 2017-10-07 10:54:55 <_ikke_> scadu: morning (afternoon) 2017-10-07 10:55:03 huhu 2017-10-07 10:55:36 scadu: you're in both rooms now too :D 2017-10-07 10:55:38 Will -offtopic and other channels be moved to matrix too? 2017-10-07 10:56:14 z3ntu: done 2017-10-07 10:56:16 I'm assuming they already are? 2017-10-07 10:56:33 https://screenshots.firefox.com/IhWjMDQBtypwwb2u/riot.lcpu.club 2017-10-07 10:59:38 vimacs: oh, I didn't notice :p 2017-10-07 10:59:39 Nice 2017-10-07 13:14:47 <_ikke_> Anyone got an idea why the checksum fails on travis, while there are no issues locally? https://travis-ci.org/alpinelinux/aports/builds/284638389#L685 2017-10-07 13:21:09 _ikke_: have you tried deleting the downloaded file ? When I download the file locally I get 47d5c584b3b8c233567eff534b5109548c92075f69776703bc303929ba4278f67fd599987ef4a098aa871c2af0efd89186f96fa28565e73b4672abeb0c23fa45 as sha512 2017-10-07 13:22:19 <_ikke_> z3ntu: that's the same hash as I have locally 2017-10-07 13:22:44 <_ikke_> and also the one registered in the APKBUILD 2017-10-07 13:23:09 have you run "abuild checksum"? 2017-10-07 13:23:29 <_ikke_> z3ntu: I'm just reviewing the PR, but I advised the submitted to use that command 2017-10-07 13:23:36 <_ikke_> submitter* 2017-10-07 13:25:05 And by default abuild checksum puts the checksum at the bottom with the filename without variables (see eg https://github.com/z3ntu/razergenie-alpine/blob/master/APKBUILD#L29) 2017-10-07 13:25:56 <_ikke_> yes, I'm aware 2017-10-07 13:26:11 I'm guessing that's the problem ^^ 2017-10-07 13:26:25 <_ikke_> The order does not matter 2017-10-07 13:26:35 <_ikke_> but I see they included the pkgver and name in the hash 2017-10-07 13:26:37 <_ikke_> in the name 2017-10-07 13:26:48 yeah I meant that 2017-10-07 13:28:39 <_ikke_> I just tested that, and at least locally it works 2017-10-07 14:41:51 anyone know why i cannot find the following kernel config? http://tpaste.us/OzpX 2017-10-07 15:01:00 && SND_SST_IPC_ACPI [=m]=n 2017-10-07 15:01:02 says so right here 2017-10-07 15:01:18 you need to disable SND_SST_IPC_ACPI it seems 2017-10-07 15:01:32 yes, but i cant find that either :| 2017-10-07 15:03:38 it doesnt show me a location to find it. http://tpaste.us/werJ 2017-10-07 15:30:22 I think i found it. 2017-10-07 15:30:31 had to disable some of the other soc drivers. 2017-10-07 20:34:38 hello. Are apk-triggers allways run when the belonging apk ist first installed, regardless of the trigger-condition? 2017-10-07 20:58:46 it looks like it only runs if files are installed to the directory, even on first install 2017-10-07 20:58:54 ref dtabase.c in apk-tools 2017-10-07 20:59:00 database.c* 2017-10-07 21:57:48 correct 2017-10-07 22:01:46 foxkit: thanks for looking into this 2017-10-07 22:02:00 happy to help :) 2017-10-07 22:05:53 strange enough, i built a package which triggers on /usr/share/kernel/* and does definitely not change anything in /usr/share/kernel/*, but it triggers every time on install 2017-10-07 22:11:59 triggers fire whenever any path has changes by any package 2017-10-07 22:12:05 also 2017-10-07 22:12:15 you don’t put * in the trigger :) 2017-10-07 22:16:31 kaniini: sure? i copied the trigger-line from mkinitfs ;) 2017-10-07 22:17:20 https://git.alpinelinux.org/cgit/aports/tree/main/mkinitfs/APKBUILD#n15 2017-10-07 22:23:37 that means 'any subdir of /usr/share/kernel/ but not /usr/share/kernel itself' 2017-10-07 22:23:42 and is technically valid 2017-10-07 22:39:07 so, just to get this right: if the package im installing does not change the path its trigger watches and no other pacakges are installed (deps or something), the trigger-script should not run, correct? 2017-10-07 22:47:32 that is correct 2017-10-07 22:52:13 okay, and what exactly qualifies as a change? is it enough to `touch` something? if so, that could be my problem (i read a file under /usr/share/kernel) 2017-10-07 23:39:22 do you mean you read it in a pre/post install script? because your package shouldn't really be reading files anywhere else 2017-10-08 04:18:23 zoot zoot 2017-10-08 04:57:11 so I got my log time stamp situation almost all the way figured out. hwclock sets itself to UTC, which is only a few hours off from me. A lot better than every single time stamp being dec 31 13:59:59.... 2017-10-08 07:07:22 foxkit: yes, in a post-install script 2017-10-08 09:19:32 interesting, the matrix topic is synced with irc. 2017-10-08 09:21:21 clandmeter: cool, I wish that was working for the postmarketOS channel. someone created the IRC channel "in the early days", who is not online anymore, and now we can't update the IRC channel's topic :-\ 2017-10-08 09:21:22 but I guess I should just ask a freenode moderator or something 2017-10-08 09:23:05 ollieparanoid: you can try ask for a group acc, then you can get back the channel(s) 2017-10-08 09:23:37 what was our previous topic? :) i kind of lost it now. 2017-10-08 09:27:27 thanks! 2017-10-08 09:31:53 clandmeter: Topic for #alpine-devel is: "Alpine Linux distribution development | release 3.6.2 is out! | use #alpine-offtopic for chitchat" 2017-10-08 09:32:16 thanks foxkit! 2017-10-08 09:33:50 np :) 2017-10-08 10:02:37 woop woop 2017-10-08 10:23:00 How does Alpine usually handle services, enable them in post-install, or let the user enable them either explicitly or with the `setup-*` scripts? (It seems to be a bit inconsistent for eudev, because it sort of does it both ways?) 2017-10-08 10:28:00 eudev is probably so critical that it's done a bit differently, but most services you install after the initial install don't enable themselves 2017-10-08 10:30:25 TBB: thanks! 2017-10-08 10:38:24 ollieparanoid: what do you mean inconsistency? 2017-10-08 10:38:50 i dont believe any of our services are started by post install scripts 2017-10-08 10:39:11 there has been a discussion about adding that feature to apk-tools. 2017-10-08 10:40:08 i think the only way eudev gets added automagically is by setup-xorg-base 2017-10-08 10:40:14 added+started 2017-10-08 10:41:16 actually im not sure if it was a started or only a restarted feature for apk-tools (in case of upgrade). 2017-10-08 10:45:46 ah yeah, that's the difference, setup-xorg-base 2017-10-08 14:07:38 how can i disable binary stripping when building with abuild? 2017-10-08 14:08:21 intuitively: options="!strip" 2017-10-08 14:11:28 skarnet: nice, thanks! 2017-10-08 14:12:02 try it before thanking me XD 2017-10-08 14:12:47 i did 2017-10-08 14:14:10 cool then! 2017-10-08 14:14:16 is this stuff somewhere documented? 2017-10-08 14:15:46 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#options 2017-10-08 14:17:18 mh, year, embarrassing i did not find it myself 2017-10-08 15:14:48 clandmeter: udev-init-scripts enables udev-trigger. I wrote this together, but I was not sure in which form to post it: https://gist.github.com/ollieparanoid/f0d84318a2b9b2ac77bd36326ddfce0f 2017-10-08 15:14:49 https://github.com/alpinelinux/aports/blob/master/main/udev-init-scripts/udev-init-scripts.post-install#L8 2017-10-08 15:14:59 absynt: add the !strip flag to options in the APKBUILD 2017-10-08 15:15:31 see also: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#options (look, that fancy table!) 2017-10-08 15:20:14 that's, like, exactly what I said 2017-10-08 15:35:12 are you guys getting my messages? 2017-10-08 15:35:38 yes 2017-10-08 15:36:10 what the hell 2017-10-08 15:36:11 log is screwed up: https://dev.alpinelinux.org/irclogs/%23alpine-devel-2017-10.log 2017-10-08 15:36:11 in my client, I've sent the !strip message before skarnet sent it 2017-10-08 15:36:36 might be my bad internet connection, nvm 2017-10-08 15:37:18 your client is more than one hour late XD 2017-10-08 15:38:28 maybe it is the matrix-irc bridge 2017-10-08 15:38:28 one hour is like a huge delay 2017-10-08 15:45:03 idk, that log seems like my chat history 2017-10-08 16:28:12 can somebody explain to me why this (https://paste.ee/p/q84q1) simple APKBUILD always triggers its trigger when it is installed? There is nothing touching /usr/share/kernel/* 2017-10-08 18:41:32 absynt: does the /usr/share/kernel folder exist? 2017-10-08 18:41:34 that might be enough to trigger it (not sure though) 2017-10-09 05:31:15 Does anyone know of a profiler (like gprof) for musl? Seems like it's not possible to build with the `-pg` flag enabling gprof support (linking fails due to some glibc-specific thing AFAIK) 2017-10-09 05:34:49 try 'perf' or 'oprofile' 2017-10-09 05:35:37 gprof sux anyway 2017-10-09 05:36:19 foxkit: are those in Alpine? I'm not able to find any packages with those names, and searching 'contents' for those filenames turns up nothing 2017-10-09 05:36:33 there's a contents?! 2017-10-09 05:36:47 I wrote apk-file as a cheap hack that does `tar tf` on each apk... 2017-10-09 05:37:20 https://pkgs.alpinelinux.org/contents 2017-10-09 05:37:32 craftyguy[m]: I have no idea if they're in Alpine or not as I've never actually profiled anything under Alpine. oprofile needs two or three patches for musl, so probably not; perf is a kernel thing so you'll need to download the kernel sources 2017-10-09 05:37:36 It works reasonably well for searching package contents :P 2017-10-09 05:38:16 I see, thanks 2017-10-09 05:39:43 reminds me, I need to submit more patches to KDE so that maybe it can be in alpine by plasma 5.12 LTS 2017-10-09 05:39:54 would hate to have to wait another year+ for 5.16 2017-10-09 05:42:34 ACTION plays with libnv structure iteration 2017-10-09 05:43:34 any good cloud host that offers alpine as a first-class? 2017-10-09 05:43:40 best i got is vultr which gives me an iso 2017-10-09 05:43:51 scaleway do dumb things with the kernels which i can't accept 2017-10-09 05:43:59 welp wrong alpine chan 2017-10-09 11:58:08 Hello. Can anybody provide some help in building packages please? I use following subpackages="$pkgname-dev $pkgname-doc" in my build, without special dev() function. And I get symlink "libzbar.so -> libzbar.so.0.2.0" in zbar-dev package, but it should be in zbar package. 2017-10-09 11:58:58 Other symlink and real lib are in zbar package. How can I place libzbar.so symlink to zbar package. I should fully rewrite dev() function? 2017-10-09 12:01:57 <_ikke_> w1r0x: This is the default_dev function: 2017-10-09 12:01:59 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1587 2017-10-09 12:02:27 Yep, already read this. Is this right way to move whis file after calling deafult_dev ? 2017-10-09 12:02:33 this* 2017-10-09 12:02:44 default_dev 2017-10-09 12:02:46 w1r0x: .so should be in -dev pkg, there is no need to place it in non-dev pkg. .so is used only during building and resulted binaries use SONAME, i.e. .so.VER files 2017-10-09 12:03:36 so it is a library, which I want to use as dependency in my app, and it shouldn't be in dev package. 2017-10-09 12:04:42 Hm.. I thouth that when I run my application it is look for libname.so not for libname.so.ver 2017-10-09 12:05:57 przemoc: thank you! I think my issue resolved. 2017-10-09 12:08:18 runtime linker looks what is written in dependencies of ELF, and during building linker puts there SONAME found in your .so file, which should be .so.VER (unless it's build wrong or someone simply doesn't care about so versioning) 2017-10-09 12:08:36 s/build/built/ 2017-10-09 12:10:09 ^- should have been s/\/built/ :P 2017-10-09 12:40:56 nick 2017-10-09 12:43:38 ncopa: is mqtt service still being used ? 2017-10-09 12:46:09 would it be difficult to add some kind of msgNumId maybe timestamp to each msg ? 2017-10-09 13:21:08 vkrishn: yes it is. its probably not very difficult to add msgNumId and timestamp 2017-10-09 13:21:16 but not today 2017-10-09 13:21:27 i think in the long run we probably want send a json message 2017-10-09 13:21:56 its not a public/official/documented service so we reserve the right to change things without prior warning 2017-10-09 13:22:00 yes, I notices all msgs are not json'ed 2017-10-09 13:22:10 thanks 2017-10-09 13:22:43 it would be nice if some kinda of nice format is brought into practice 2017-10-09 13:23:04 may serve as example for other distros or development 2017-10-09 13:24:23 I had thought of one sometiem back, but may be more complex i guess 2017-10-09 13:24:25 / / /<[where|action|data|msg]> 2017-10-09 13:24:38 made into json format 2017-10-09 13:25:07 thanks, gtg 2017-10-09 19:36:42 hmm why are we missing sshfs for edge/main? 2017-10-09 19:44:19 clandmeter: because either nobody packaged it or it's in testing/community? 2017-10-09 19:44:54 it should be in main 2017-10-09 20:18:32 point is that third parties shouldn't be able to effectively block participation 2017-10-09 20:19:49 erf, wrong channel :) 2017-10-09 22:29:16 is there a reason xvmc is disabled in mesa? is it on purpose? 2017-10-10 11:32:40 foxkit: https://www.phoronix.com/scan.php?page=news_item&px=MTU3MDM 2017-10-10 20:59:11 anyone have time to help me with a python module that can compare apk version strings? 2017-10-10 20:59:32 as in help me write a python module 2017-10-10 21:00:20 i think the easiest thing to do was to take the src/version.c from apk-tools and wrap the compare function with some python glue 2017-10-10 21:00:34 then we get the exact same code that apk itself uses 2017-10-10 21:08:07 ncopa 2017-10-10 21:08:14 I've already written that 2017-10-10 21:09:03 I need to go offline sadly, but it is in the pmbootstrap code. I can give you the exact path tomorrow if you can't find it. https://github.com/postmarketOS/pmbootstrap 2017-10-10 21:09:06 (it passes all testcases from apk) 2017-10-10 21:12:54 \o/ 2017-10-10 21:13:06 thank you! 2017-10-10 21:25:09 ncopa: in case you didn't find it yet, it's here: https://github.com/postmarketOS/pmbootstrap/blob/master/pmb/parse/version.py#L216 2017-10-10 21:25:51 yes i found it 2017-10-10 21:26:01 it was exactly what I was looking for 2017-10-10 21:26:06 i owe you a beer ;) 2017-10-10 21:26:41 ollieparanoid[m] that is... 2017-10-10 21:26:47 not me, ollieparanoid[m] :P 2017-10-10 21:27:39 I just cause trouble for pmOS :D 2017-10-10 21:38:54 anything new around here? 2017-10-10 21:42:04 clandmeter: you seem to have fixed the issue with the sshfs package on edge/main, how did you fix it and could you please close #7745? 2017-10-10 21:43:17 Hi 2017-10-10 21:43:27 Fabled did 2017-10-10 21:43:43 It was an issue with openssh 2017-10-10 22:04:57 So I can submit a PR for updating an existing patch in testing (package: ofono), but I also have a patch I wrote for fixing a device-specific issue I had which was not merged into ofono in time for the new release. Any issues with my PR including 1) the APKBUILD update to the new version and 2) my new patch? 2017-10-10 22:05:08 or should those be broken into two PRs? 2017-10-11 01:01:34 Provided that I am logged as 'root', how to shift users without providing a password? 'su' asks for a password, e.g. 'su - username' will ask for a password. 2017-10-11 01:12:08 seems like you installed the shadow package? 2017-10-11 02:01:55 ncopa: thanks, I did not know this. 2017-10-11 02:37:22 @Shiz: were you talking to me? (I was disconnected, and do not see entire conversation.) 2017-10-11 04:20:05 is there a reason that dev packages don't dep on the source package by default? 2017-10-11 04:38:59 <_ikke_> foxkit: source package is the parent / main package? 2017-10-11 04:39:11 yeah 2017-10-11 04:39:35 <_ikke_> Because the dev packages are used for makedeps, you typically only need that package 2017-10-11 04:39:46 I put "foo-dev bar-dev" in baz APKBUILD and it complains that /usr/biiiin/bar is missing 2017-10-11 04:39:55 but if I put "foo-dev bar" in, it complains about /usr/include/bar.h missing 2017-10-11 04:39:57 :/ 2017-10-11 04:39:57 <_ikke_> what complains about that? 2017-10-11 04:40:30 it's an example; the actual packages are kdesignerplugin and akonadi, which are KDE packages I'm writing up 2017-10-11 04:41:00 kdesignerplugin-dev has /usr/include/kde/designerplugin.h and /usr/lib/cmake/.... stuff, and kdesignerplugin has /usr/bin/kgendesignerplugin 2017-10-11 04:41:03 akonadi needs both 2017-10-11 04:41:38 is it more proper to put kdesignerplugin in depends_dev of kdesignerplugin, or should I specify both packages in akonadi's makedepends? 2017-10-11 04:42:32 <_ikke_> I think -dev packages should not contain binaries, so I think it makes sense to depend on both 2017-10-11 04:43:24 but the -dev package isn't useful without the binary installed as well 2017-10-11 04:43:29 but ok 2017-10-11 04:43:31 I will do it that 2017-10-11 04:43:33 way 2017-10-11 04:43:50 <_ikke_> foxkit: Might be that someone else has a different idea 2017-10-11 05:00:11 foxkit: it is ok for the -dev package to contain binaries which are only useful with the -dev package installed 2017-10-11 05:03:26 <_ikke_> kaniini: ah ok, I stand corrected :) 2017-10-11 08:18:28 jirutka: im a bit curious what is using ruby-rmagick and if it is possible to ruby-rmagick to use imagemagick7? 2017-10-11 08:18:47 so we dont need maintain imagemagick6 in addition to 7 2017-10-11 08:26:28 ncopa, as a suggestion depending on what uses rmagick, suggest to upstream to use minimagick instead: https://github.com/minimagick/minimagick 2017-10-11 08:26:40 much lighter, supports more backends including graphicsmagick 2017-10-11 08:28:39 yeah sounds like a better alternative. i am just curious what needs rmagick 2017-10-11 09:51:37 foxkit: did you already include efi support in your install scripts? 2017-10-11 14:49:05 clandmeter: adelie doesn't presently have an installer 2017-10-11 14:54:58 kaniini: ok. I'm looking at adding efi support to ours. 2017-10-11 14:56:45 that should definitely be done before 3.7 2017-10-11 14:56:49 if you need help with that clandmeter im up 2017-10-11 15:06:41 This should be good to go if a maintainer can take a quick look at your convenience. Thanks! https://github.com/alpinelinux/aports/pull/2474 2017-10-11 15:10:51 Shiz: ok but not today. Maybe tomorrow. 2017-10-11 19:47:34 clandmeter: I just sent a package of some of the tools required for efi to one of the Alpine developers 2017-10-11 19:47:44 earlier today, that is 2017-10-11 19:48:03 haven't submitted them because I never quite got the permission to do that, before today 2017-10-11 19:48:25 they're probably quite terrible, the apkbuilds, but anyway 2017-10-11 19:48:43 To who? 2017-10-11 19:48:56 fabled 2017-10-11 19:49:51 and I conveniently forgot one of the apkbuilds required to compile one of the tools (efitools if I remember correctly, the package also has sbsigntool in it) 2017-10-11 19:52:43 I think it was efitools that required stuff from CCAN, and packaging that was a real bitch 2017-10-11 19:52:59 it's like CPAN but for C code 2017-10-11 20:03:49 I actually had those somewhat ported already at the beginning of this year, but as a hired gun in the project I work for I need an explicit permission to contribute back on a per package basis, and I didn't have that (although I imagine my customer wouldn't have had anything against it) 2017-10-11 21:12:03 i think the stuff *needed* for efi should be already in the repos, no 2017-10-11 21:12:43 not sure, haven't checked recently 2017-10-11 21:14:12 I did check; as far as I know, signing is done using sbsign which is not in the repos and doing efi variable updates is done using efi-tools which is not there either 2017-10-11 21:14:48 however it's quite possible that there are other tools that do the same things 2017-10-11 22:05:07 clandmeter: we have already packaged EFI stuff yes. efibootmgr, grub-efi, efivar, and all the tools and stuff are all packaged and working (my laptop boots using UEFI) 2017-10-11 22:05:33 clandmeter: would you like a pull request with the EFI packages? I guess to testing/? 2017-10-11 22:07:40 foxkit: they are already in testing and main 2017-10-11 22:11:26 clandmeter: hm, we had to set libdir to /usr/lib explicitly or else efibootmgr thought /usr/lib64 was appropriate. did you not have that issue? 2017-10-11 22:12:24 I think I addressed it 2017-10-12 07:03:15 kaniini: looks like recent musl commit broke login for me. 2017-10-12 07:03:28 not sure what is exactly the problem as i cannot log atm. 2017-10-12 07:13:38 let me see 2017-10-12 07:15:27 [952208.801596] login[6504]: segfault at 0 ip 00007feb7a6a7b9b sp 00007ffe1b377fb0 error 4 in ld-musl-x86_64.so.1[7feb7a68a000+89000] 2017-10-12 07:15:28 hmm 2017-10-12 07:15:31 this is interesting 2017-10-12 07:15:38 it means latest musl has a problem 2017-10-12 07:15:45 great ;) 2017-10-12 07:15:46 can you get a backtrace? 2017-10-12 07:15:51 yes nice 2017-10-12 07:17:41 clandmeter, i can reproduce 2017-10-12 07:17:44 let me take a look 2017-10-12 07:18:07 it's the forked process that segfaults 2017-10-12 07:18:25 still digging on it 2017-10-12 07:18:56 #0 0x00006a48ea1b2b9b in __putenv (s=s@entry=0x6fea8324ba0 "TERM=xterm", 2017-10-12 07:18:56 a=a@entry=1) at src/env/putenv.c:17 2017-10-12 07:18:56 17 src/env/putenv.c: No such file or directory. 2017-10-12 07:18:56 #0 0x00006a48ea1b2b9b in __putenv (s=s@entry=0x6fea8324ba0 "TERM=xterm", 2017-10-12 07:18:56 (gdb) where 2017-10-12 07:18:57 a=a@entry=1) at src/env/putenv.c:17 2017-10-12 07:18:59 #1 0x00006a48ea1b2df9 in setenv (var=0x6fea8113375 "TERM", 2017-10-12 07:19:01 value=0x790230d680fe "xterm", overwrite=) 2017-10-12 07:19:03 at src/env/setenv.c:26 2017-10-12 07:19:05 sounds like the clearenv change 2017-10-12 07:19:23 yes 2017-10-12 07:19:31 just got to that 2017-10-12 07:19:33 going to back it out 2017-10-12 07:19:39 it's vverified? 2017-10-12 07:20:47 yep 2017-10-12 07:20:51 i backed it out and login is working 2017-10-12 07:21:02 yeah 2017-10-12 07:21:06 can confirm 2017-10-12 07:21:16 you push the fix? 2017-10-12 07:21:27 and report to #musl / mailing list too? 2017-10-12 07:21:33 yep 2017-10-12 07:21:38 i pushed fix 2017-10-12 07:21:53 thx 2017-10-12 07:21:53 will regress it after taking a nap 2017-10-12 07:24:32 fabled: i see problem, i did not pull in "overhaul environment functions" but it turns out the fix i pulled in was a fix for that commit 2017-10-12 07:24:40 so we're good 2017-10-12 07:24:48 ok 2017-10-12 07:25:27 i had my todo list to go cherry pick musl commits 2017-10-12 07:25:35 but was hoping dalias to tag a release 2017-10-12 07:26:33 morning 2017-10-12 07:26:34 i was hoping that he could get us 1.1.17 by 3.7 release time, but we are getting too close to freeze 2017-10-12 07:26:52 i asked if it was realistic to have a release this or next week 2017-10-12 07:26:55 and he said yes 2017-10-12 07:26:57 he did help with fopencookie(3) though 2017-10-12 07:27:23 i'm hopeful, but wanted to hedge just in case 2017-10-12 07:27:46 rebasing on 1.1.17 would certainly be welcome for a last minute change 2017-10-12 07:28:04 i am also going to try to get our strftime changes upstreamed 2017-10-12 07:29:44 however, there's another musl blocker that we need to address regardless 2017-10-12 07:29:57 we need stubs for pthread_rwlockattr_getkind_np() and friends 2017-10-12 07:30:06 to make ada threading work correctly 2017-10-12 07:30:07 ncopa: dalias complained his firefox font rendering blew up. he suggested this as a remedy https://bugzilla.mozilla.org/show_bug.cgi?id=1400721 2017-10-12 07:30:10 maybe you can make him happy :) 2017-10-12 07:30:56 honestly, i'm ok with current situation in musl for the most part 2017-10-12 07:31:11 dalias did have a house fire and that would probably screw me up for a minute if i had one 2017-10-12 07:31:50 he knows loud and clear that we do need to get back to having more steady releases soon though 2017-10-12 07:32:18 consistently i think from alpine team he has heard that from basically everyone touching libc 2017-10-12 07:32:18 :p 2017-10-12 07:32:43 even me, who is nominally only half-alpine >.> 2017-10-12 07:33:52 i proposed that he could have other people who could make releases like nsz, he seemed interested 2017-10-12 07:34:16 but at the same time, our patch queue is starting to grow a lot 2017-10-12 07:34:34 which is making me nervous 2017-10-12 07:35:03 but if it comes down to it, we could just softfork our changes into a local git repo on git.alpinelinux.org and do our own releases 2017-10-12 07:35:15 we were already doing that with uclibc anyway :P 2017-10-12 07:35:35 and musl is much, much cleaner than uclibc 2017-10-12 07:36:05 clandmeter: that was another reason that adelie still ships infinality by default instead of new method (I remember we discussed this stuff before); firefox, qt, etc all have 'workarounds' to make freetype less ugly, and changing the ugliness from ugly A to ugly B defeats this and makes an even-worse ugly C :p luckily qt probes and sees it doesn't know what mode it is in, so it doesn't even try now... 2017-10-12 07:36:07 result looks quite ok 2017-10-12 07:37:13 it is not the /most/ legal option, obviously, but microsoft have said before they 'promise not to sue' for freetype. 2017-10-12 07:37:41 do you have a list of other programs affected by it? 2017-10-12 07:37:43 but then again adelie is looking more for stability than cutting edge and, well, maybe then it wasn't good idea to base off 'edge' >.> 2017-10-12 07:38:13 nah basing off edge and polishing it is a proven model 2017-10-12 07:38:16 see also: ubuntu 2017-10-12 07:38:32 i mean, for all of ubuntu's faults, they did prove the model 2017-10-12 07:38:45 clandmeter: most of them are thankfully like qt, but anything that uses skia is affected (which is chromium also), also idk how things like poppler and pango cope, but poppler seems ok in my testing 2017-10-12 07:39:03 I tested poppler in both modes that is 2017-10-12 07:39:05 and it seemed fine in both 2017-10-12 07:39:16 chromium seems also ok 2017-10-12 07:39:26 perhaps they already have patched skia 2017-10-12 07:39:45 those are the major direct consumers of freetype that I can think of 2017-10-12 07:39:59 anyway 2017-10-12 07:40:15 ada threading needs some stubs added to musl 2017-10-12 07:40:21 foxkit: did you have a look at widevine? 2017-10-12 07:40:26 musl's thread library has a lot of stubs already so i don't expect many problems 2017-10-12 07:40:37 widevine on firefox i couldn't get to work 2017-10-12 07:40:41 nope, never could get it working 2017-10-12 07:40:45 fwiw i talked to google about widevine 2017-10-12 07:41:13 and they basically said that if we were to write our own implementation of it 2017-10-12 07:41:25 my custom build of chromium mentioned it fails to load the widevine plugin with permission denied. 2017-10-12 07:41:26 that it could be possible to make it interoperable with widevine itself 2017-10-12 07:41:50 but not 100% sure on the details of how that would work 2017-10-12 07:41:59 i guess they would issue us a key 2017-10-12 07:42:15 not sure if i want to get into the DRM business though :P 2017-10-12 07:42:44 i just wonder if its actually possible to get it working with chromium and musl based systems. 2017-10-12 07:42:49 with the current libs 2017-10-12 07:43:04 i believe it to be possible 2017-10-12 07:43:13 even if we have to put it in non-free 2017-10-12 07:43:26 there is already a non-free/widevine package isnt there? 2017-10-12 07:43:29 or is that for firefox 2017-10-12 07:43:34 yes i added it recently 2017-10-12 07:43:39 that's very low on my todo, and will remain so until one of three things happens: 1) google stop making w3c their slave; 2) google release the code; 3) my mother bugs me that she wants netflix on her desktop 2017-10-12 07:43:43 (it runs adelie) 2017-10-12 07:44:35 isnt spotify also affected by it? 2017-10-12 07:44:53 yes 2017-10-12 07:44:56 google play music also 2017-10-12 07:45:03 spotify has its own binary that doesn't need widevine it just uses a custom decoder 2017-10-12 07:45:07 i couldnt get it working last time i tried. 2017-10-12 07:45:18 so the target is making /opt/spotify/bin/spotify work first 2017-10-12 07:45:21 then in-browser playing 2017-10-12 07:45:23 i mean web spotify 2017-10-12 07:45:26 foxkit: spotify has a web app now 2017-10-12 07:45:30 (spotify themselves have said in-browser is deprecated) 2017-10-12 07:45:36 kaniini: I use it on my desktop since gtk+3 is broken :) 2017-10-12 07:45:41 kaniini: so I know 2017-10-12 07:45:52 foxkit: /opt/spotify/bin/spotify is chromium embedded framework tho 2017-10-12 07:46:06 i don't think gcompat can run CEF apps yet 2017-10-12 07:46:11 i haven't tried anyway 2017-10-12 07:46:12 hmm 2017-10-12 07:46:21 thought it was gtk webkit :/ 2017-10-12 07:46:39 no it's CEF 2017-10-12 07:46:45 foo. 2017-10-12 07:46:51 because on my mac, it has like 30 processes 2017-10-12 07:47:01 and it's all chromium looking stuff 2017-10-12 07:47:13 ah librespot is also abandoned :| 2017-10-12 07:48:03 a lot of ideas i have re: gcompat are stalled until musl 1.2 because i need IFUNCs 2017-10-12 07:48:46 negotiating that with dalias will be fun i suppose 2017-10-12 07:49:25 wait, they're adding ifunc in 1.2?? 2017-10-12 07:49:28 nsz said never 2017-10-12 07:49:39 i will make this happen 2017-10-12 07:50:05 nsz also said fopencookie(3) will never happen 2017-10-12 07:50:08 yet, dalias gave it the green light 2017-10-12 07:50:45 in general, as long as you're persistant and make it clear that alpine wants XYZ, alpine will get what alpine wants from musl 2017-10-12 07:50:54 it's just a matter of pushing for it 2017-10-12 07:52:10 foxkit: well i should clarify 2017-10-12 07:52:24 foxkit: i don't need ifuncs, i need the ability to cleanly patch functions in the libc 2017-10-12 07:52:34 ifuncs are just one way of doing this 2017-10-12 07:53:03 having a way to dynamically register symbol versions with ldso is another 2017-10-12 07:53:25 then we can provide GLIBC_2_2_3 symbols for the glibc quirks we want to carry in gcompat 2017-10-12 07:54:16 ifuncs are probably going to be an easier sell than versioned symbols 2017-10-12 07:55:18 not sure, plan to try both ways 2017-10-12 07:55:23 versioned symbols would be even more useful 2017-10-12 07:55:48 realistically, it would be possible to add them but we would need fork ldso to do it 2017-10-12 07:55:50 which is ugly 2017-10-12 07:55:53 i rather not do that 2017-10-12 07:56:12 the program-interpreter can do whatever it wishes to link the image 2017-10-12 07:56:24 versioned symbols would be more useful, I agree. there was one package, don't remember which, that failed its test suite because /it/ defined versioned symbols and the test hit the wrong one. 2017-10-12 08:00:22 either way, spotify is annoying for other reasons 2017-10-12 08:00:26 such as being proprietary 2017-10-12 08:01:18 given that i want to standardize all audio applications in alpine on sndio so that you can connect any app to pulseaudio or JACK 2017-10-12 08:01:31 proprietary software is annoying towards that goal 2017-10-12 08:01:43 while I eagerly await an open-source, libre stremaing music service, we are probably 5-10 years out from that, at least :/ 2017-10-12 08:02:02 huhuhu jamendo 2017-10-12 08:02:11 jack won't compile on adelie because it has a terrible build system that requires python2 2017-10-12 08:02:12 :/ 2017-10-12 08:02:12 i'll show myself out 2017-10-12 08:02:20 spent two days trying to unfuck it 2017-10-12 08:02:26 the result was two days wasted 2017-10-12 08:02:31 waf? 2017-10-12 08:02:33 yes 2017-10-12 08:02:41 lols 2017-10-12 08:03:13 i guess bye bye jack whenever we get around to nuking python2 in alpine 2017-10-12 08:03:36 well adelie is trying to help in any way we can by porting stuff to py3 where possible 2017-10-12 08:03:54 there's some subtle breakages in some packages, which is why I haven't pr'd them yet 2017-10-12 08:04:05 but I've already migrated a few over that were just builddeps not rundeps 2017-10-12 08:04:30 libxml2 needs one patch to work on 3.6 but is otherwise fully a member of the py3 society now 2017-10-12 08:04:49 mesa still needs py2 to build from git, but their dist tarballs no longer require python 2017-10-12 08:05:02 the codegen they do (yuck) is done dist-side 2017-10-12 08:55:13 clandmeter: i think we should try fix firefox, and make dalias happy 2017-10-12 09:14:06 kaniini: by sndio you mean this http://www.sndio.org/? first time hearing about it. it doesn't seem to offer any alsa or pulse emulation for apps unaware of sndio, though. or am I missing something? 2017-10-12 09:15:39 fabled: care to take a look at http://sprunge.us/eXAK ? 2017-10-12 10:03:37 clandmeter, sounds like the .apk in cache is broken somehow 2017-10-12 10:03:44 apk verify /etc/apk/cache/linux-hardened-4.9.54-r0.e9c36e43.apk 2017-10-12 10:04:53 should fix apk error code 2017-10-12 10:06:08 ok 2017-10-12 10:06:14 could you verify the .apk? 2017-10-12 10:06:23 you are right 2017-10-12 10:06:26 FAILED 2017-10-12 10:08:47 ok. yes, the error code needs to befixed 2017-10-12 10:29:06 fabled: nice, seems to work ok now. 2017-10-12 10:38:42 clandmeter, the commit just pushed fixes it. i was able to reproduce the issue by truncating an apk in cache 2017-10-12 16:37:52 przemoc: yes, theres no wrapper libraries for it. the plan is to patch it in where possible. lots of apps already have a sndio backend :) 2017-10-12 16:38:01 przemoc: sndio itself can talk to alsa, pulse, etc. 2017-10-12 20:55:51 kaniini: I thought sndio could be first-class citizen. kind of like pulseaudio, but I had to make pulse second-class citizen (connected to alsa's dmix) to fix my audio problems on debian a few years back 2017-10-12 20:56:07 sorry for bringing that now, I forgot about this window 2017-10-12 20:58:40 przemoc: this is the goal, to make all audio apps shipped by alpine speak sndio, by default 2017-10-12 20:58:54 przemoc: writing an alsa/pulse wrapper for incompatible apps probably wouldn't be difficult fwiw 2017-10-12 21:04:45 kaniini: pulseaudio was nice in theory, but in practice I never had good experience with it. having customized /etc/asound.conf (with dmix, dsnoop, etc.) worked much better, pulse aimed to be self-configured out-of-the-box and I guess it worked for many, alsa was never really like that, but at least it works when you spend time once to configure your inputs and outputs properly. hope sndio works 2017-10-12 21:04:51 out-of-the-box and doesn't introduce many sounds issues like pa did. 2017-10-12 22:40:31 ncopa: glad I could help you with that version.py! I'm curious: what will you use it for? 2017-10-13 02:26:10 can somebody running the -hardened kernel and edge fire up python3.6 and type "import ctypes" in 2017-10-13 02:34:24 Xe, ^ 2017-10-13 08:16:21 good morning 2017-10-13 08:17:23 <_ikke_> hai 2017-10-13 08:17:43 o/ 2017-10-13 10:33:08 anyone can check & accept bugfix https://github.com/alpinelinux/aports/pull/2487 2017-10-13 10:37:23 fopencookie.. kaniini, sigh ^ 2017-10-13 15:52:50 how do rebuilding php solve it 2017-10-13 15:52:58 musl just need be upgraded 2017-10-13 15:53:27 don’t mix packages between edge and releases for this reason 2017-10-13 16:02:14 i will just fix it properly by putting a hard dep on lobbed 2017-10-13 16:02:17 libbsd 2017-10-13 16:02:19 even 2017-10-13 16:02:26 sheesh 2017-10-13 17:22:28 this error is due to pax kernel is not happy: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/py3-async-timeout/py3-async-timeout-2.0.0-r0.log 2017-10-13 17:22:44 it works if i paxmark python3 binary 2017-10-13 17:22:53 which also explains why travis didnt pick it up 2017-10-13 17:23:15 im not sure how to resolve it 2017-10-13 17:23:30 do we really want disable memory protections for python3? 2017-10-13 17:27:34 what kernel are you running with PAX? grsec? 2017-10-13 17:35:16 kaniini, I thought rebuilding php7-gd against new lib should solve the issue 2017-10-13 17:42:55 ncopa: i believe it is related to libffi 2017-10-13 17:43:20 andypost: no, it is because your musl package was out of date. actual fix is to declare harder dependency on newer musl in libbsd. 2017-10-13 17:45:33 kaniini, thanx a lot! it helps 2017-10-13 17:46:35 I used apk add --upgrade but only apk upgrade only helped 2017-10-13 17:47:46 craftyguy[m]: yes with pax 2017-10-13 17:47:59 unofficial grsec 2017-10-13 17:48:15 kaniini: yes, i think you are right. i wonder what the proper fix is though 2017-10-13 17:48:56 ncopa: libffi needs to be fixed to remove PROT_WRITE when setting PROT_EXECUTE 2017-10-13 17:49:39 seems like there are some pax support in libffi already 2017-10-13 17:49:53 ncopa: https://github.com/libffi/libffi/pull/280 2017-10-13 17:51:25 ncopa: can you try applying that patch to libffi and running `import ctypes` in python3? 2017-10-13 17:52:13 i think i'll revert the commit instead 2017-10-13 17:52:17 dont have time now :-( 2017-10-13 17:52:35 wife is waitin for me to take weekend 2017-10-13 17:54:02 i will check 2017-10-13 17:54:02 h/o 2017-10-13 17:56:53 ncopa: rebooting into hardened kernel 2017-10-13 18:02:38 ncopa: it fixes it 2017-10-13 18:03:12 great, would be nice if you can apply it 2017-10-13 18:03:20 otherwise i'll do it in a week or so 2017-10-13 18:03:24 its dockercon next week 2017-10-13 18:03:33 have a nice weekend! 2017-10-13 18:03:36 thanks! 2017-10-13 18:03:47 ncopa: i applied it 2017-10-13 18:16:05 tmh1999: what is the oldest z machine that will run alpine ? 2017-10-13 18:17:26 i have an opportunity to get a multiprise 3000 for free 2017-10-13 18:17:54 but if it is too old to run alpine, i rather not waste my time and gas driving my truck up to kansas city this weekend ;) 2017-10-13 21:51:18 kaniini: that's a 32-bit model with no support for z/architecture 2017-10-13 21:51:22 idk if that helps you 2017-10-13 22:08:09 does anybody know why our installer is skipping the first mb when creating the partitions? is it related to mbr? 2017-10-13 22:16:49 does the installer use fdisk? 2017-10-13 22:17:24 sfdisk 2017-10-13 22:17:28 I seem to recall that fdisk tries to align the first partition at 1MiB, but don't quote me on that 2017-10-13 22:19:09 yes. one sector (512 bytes) would be enough, theoretically, but because everyone nowadays want good alignment with 4K sectors on non-SSD, and more importantly with SSD disks erase block sizes (and they vary, but usually are powers of 2), so 1 MB is quite a good alignment choice (but not universal). 2017-10-13 22:19:52 most partitioning programs nowadays use 1 MB alignment by default 2017-10-13 22:20:12 right, but its explicitly set now. 2017-10-13 22:20:35 it looks like sfdisk doesn't default to 1MiB alignment though.. does the Alpine installer explicitly implement it? 2017-10-13 22:20:46 (at least according to the sfdisk manpage, it says use fdisk for auto-alignment) 2017-10-13 22:20:52 seems it was 0 before ncopa changed it without commit note. 2017-10-13 22:21:34 i guess when using gpt its not needed 2017-10-13 22:21:57 and raid uses the last sector of disk iirc 2017-10-13 22:26:30 what's not needed when using gpt? gpt sits at the beginning of the disk and also takes place, yet you still want the alignment, so 1MB alignment is used the same way regardless of mbr or gpt being used. at least by all sane partitioners, don't know what alpine installer is doing, though. 2017-10-13 22:29:07 I thought there were some RAID things that used to dump stuff in the first sector. or maybe it was that "windows dymanic disk" stuff, or maybe I just made that up :P 2017-10-13 22:31:34 looks like recent version of sfdisk does align. 2017-10-13 22:31:53 yes, raid can put additional stuff on disk. for hardware one you don't know where, though, unless they tell you. mdraid puts stuff at the beginning. during array creation you can specify data offset, which is usually some nice power of 2 in MB. 2017-10-13 22:32:28 yes, it was at the end before. i mixed it up... 2017-10-14 13:56:25 so, I'm thinking of upstreaming a big chunk of KDE which I have packaged for postmarketOS to Alpine. it's a total of 80 packages right now, of which I like to upstream at least 40. most of them depend on each other. 2017-10-14 13:56:49 how should I do this? make a Github PR for each of them separately and wait with packages till their deps are merged? 2017-10-14 13:57:08 or can I put chunks together in PR's? 2017-10-14 14:00:09 We prefer chunks which depends on each other. 2017-10-14 14:00:58 so it's no problem having multiple packages in 1 PR then? 2017-10-14 14:02:10 Correct 2017-10-14 14:02:41 cool, I'll do that then. thanks! 2017-10-14 14:06:03 I might make it one big chunk then. the APKBUILDS are practically the same anyway, just different package names, checksums and depends 2017-10-14 16:01:57 clandmeter, kaniini, fabled, ncopa: why is linux-firmware arch=all instead of arch=noarch? as I see it, it does not compile any code and it installs all firmware files on all architectures. I'm asking because this is relevant for how we package firmware that is not in there, and I could make a PR to change it to noarch if you guys think that makes sense. 2017-10-14 16:02:10 https://git.alpinelinux.org/cgit/aports/tree/main/linux-firmware/APKBUILD 2017-10-14 16:08:16 also if someone else knows, please answer :p I've just mentioned the people who modifed the APKBUILD. 2017-10-14 17:29:46 submitted my KDE work https://github.com/alpinelinux/aports/pull/2495 2017-10-14 17:30:11 I know it's a lot, but the majority of APKBUILDS are all the same so hopefully it can be merged (reasonably) quickly 2017-10-14 17:32:01 foxkit: btw, you're also packaging kde (desktop), but the lts versions, right? in case this is not obvious, I've thought about that one solution could be naming the lts kde packages -lts, so we can have both. 2017-10-14 17:32:04 PureTryOut: \o/ 2017-10-14 17:32:38 \o/ 2017-10-14 17:32:42 <_ikke_> \o/ 2017-10-14 17:32:59 \o/ 2017-10-14 17:39:39 so, Travis failed because it can't find packages it just built... 2017-10-14 17:40:09 it probably wouldn't finish all packages in the 50 minutes of time it has anyway 2017-10-14 17:40:24 actually, it does that for literally every package with a dep in the same PR 2017-10-14 17:40:34 idk x86_64 compiles in 30 to 45 minutes for me 2017-10-14 17:40:36 which should work for Travis 2017-10-14 17:42:32 well, travis doesn't have the ccache. but it doesn't really matter :p 2017-10-14 17:46:04 ACTION realises the very first package built had a wrong checksum 2017-10-14 17:49:57 that fixed the builds, yay! \o/ 2017-10-14 18:55:00 pfft, Travis showed job failed. so checking why, it's because the log exceeded 4MB. Travis then thinks it's an error message repeating itself. it's not, it's just a fuck ton of packages 😆 2017-10-14 18:56:00 now that was unexpected :D 2017-10-14 18:56:05 (at least to me) 2017-10-14 18:56:53 <_ikke_> But does it fail the build then? 2017-10-14 18:57:05 <_ikke_> Last time it happened to me, the build succeeded 2017-10-14 19:59:25 it seems to fail the build 2017-10-14 20:00:28 either that or the build failed later on, but I can't see why because it stopped logging due to the size 2017-10-14 20:00:36 <_ikke_> I guess the latter 2017-10-14 20:01:57 it ran for 49 minutes and 1 second, maybe it just timed out? 2017-10-14 20:02:33 ACTION sent a long message: PureTryOut[m]_2017-10-14_20:02:33.txt  2017-10-14 20:02:36 last output ^ 2017-10-14 20:08:07 PureTryOut: cut off 59 seconds early because the log got too big 2017-10-14 20:08:32 haha that'd be amazing timing really 2017-10-14 20:08:59 ill run a manual build of it 2017-10-14 20:16:13 thanks! 2017-10-15 03:24:43 ollieparanoid[m]: alpine's typical packaging of things like that is that the 'current' package has -current attached, like nodejs 2017-10-15 03:24:52 because the LTS is what most people will want 2017-10-15 06:30:23 kaniini : that one seems too old 2017-10-15 06:31:09 not even sure you can run any available version of z/OS on it 2017-10-15 06:31:16 not to mention Linux 2017-10-15 06:49:11 how should a new qt5 component be handled? qt5-qtx11extras is needed by a lot of KDE stuff. should it be in testing/ since it's new, or community/ since it's just another module of qt5 which is already in community/? 2017-10-15 08:19:12 foxkit: qt5-x11extras already exists 2017-10-15 08:19:34 idk why it lacks the qt5-qt suffix, but it's there 2017-10-15 08:20:31 hm, how hard is it to rename things in alpine :s 2017-10-15 08:24:26 curl: (6) Could not resolve host: kde.c3sl.ufpr.br 2017-10-15 08:24:31 well that is not at all helpful 2017-10-15 08:24:51 well shit 2017-10-15 08:31:37 I wonder why most qt packages have that qt5-qt suffix anyway. qt5- like upstream should be enough 2017-10-15 08:32:14 ^ agreed 2017-10-15 08:32:19 unless there's something more behind it 2017-10-15 08:33:51 honestly I rather remove qt5- suffix at some point 2017-10-15 08:33:54 qt4 is EOL 2017-10-15 08:33:57 unmaintained 2017-10-15 08:34:06 security disaster waiting to happen, if/when someone finds good CVE in it 2017-10-15 08:34:21 and when that happens, 'x11extras' is a weird name for a package :/ 2017-10-15 08:34:45 RCE exploits are the most juicy ones tbh 2017-10-15 08:35:00 qt does have network stack, so don't count it out 2017-10-15 08:35:07 qt is bloated as all hell 2017-10-15 08:35:10 it has a lot of things 2017-10-15 08:35:17 well qt5 fixes a lot of the bloat 2017-10-15 08:35:31 that is why it is all modular instead of just 'qt5' package. 2017-10-15 08:35:31 i haven't really kept up to date on that tbh 2017-10-15 08:35:56 good, the monolithism was annoying 2017-10-15 08:56:27 foxkit: the qt5- prefix is part of the upstream names though 2017-10-15 09:01:50 ew, it is? 2017-10-15 09:05:57 yup 😆 2017-10-15 09:06:23 I don't mind it really, it makes it clear where it's from 2017-10-15 09:06:42 `qt5-something` tells more what it's about than just `something` 2017-10-15 09:08:15 qtbase is clear enough imo :p 2017-10-15 09:12:25 upgrading all the KF5 crap is a drag 2017-10-15 09:12:40 `abump` would be more useful if they didn't add dependencies >.< 2017-10-15 09:22:12 I mean, I'm fixing my PR right now from your comments. you can just wait till I'm done 2017-10-15 09:24:21 ah. I was going to bump to 5.39.0 and see what the alpine devs said about it 2017-10-15 09:24:44 that way you wouldn't have to deal with all the check stuff and figuring out which tests need X11 and which don't 2017-10-15 09:27:46 meh I don't mind the work 2017-10-15 09:28:05 I just don't want all my work from the previous months to be a waste of time in the end 😛 2017-10-15 09:28:33 also, I like to learn what I can about the Alpine packaging system. tests are new to me, so this is a good chance to figure them out 2017-10-15 09:28:47 also, `$builddir` is new to me. is it a pre-existing variable? 2017-10-15 09:30:00 yes, and it is overridable 2017-10-15 09:30:07 it defaults to "$srcdir/$pkgname-$pkgver" 2017-10-15 09:30:30 ooh, so where all the stuff is unpacked basically 2017-10-15 09:30:32 typically you override it when, for instance, upstream capitalises their name 2017-10-15 09:30:58 for example, https://code.foxkit.us/adelie/packages/merge_requests/5/diffs#f974ae286250c7602f0a3c96fe8991eebd42b496_0_16 2017-10-15 09:31:22 FeatherPad capitalises its name, and $pkgname is featherpad, so builddir has to be overridden here. 2017-10-15 09:33:30 aah ok, that's why I see it in APKBUILDS sometimes. I thought it was a manually made variable 2017-10-15 09:34:35 https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n2457 < nope 2017-10-15 11:22:51 foxkit: I wonder a bit about the SUID bit of screenlocker, as the binary does not actually have it set. if it was a requirement, it should've been set already should it not? 2017-10-15 11:22:57 *kscreenlocker 2017-10-15 11:23:10 it's kcheckpass 2017-10-15 11:23:19 it should have it set 2017-10-15 11:23:22 the build system sets it 2017-10-15 11:24:27 well, abuild isn't complaining that it's not allowed, so I don't think it is set 2017-10-15 11:26:17 I mean, I can set it manually but I don't think that's how it should be done 2017-10-15 11:27:09 isn't PAM the bit that allows it to unlock session? 2017-10-15 11:32:08 nope 2017-10-15 11:32:19 PAM is the bit that lets it do user switching 2017-10-15 11:32:42 I'll have a look in a bit, busy atm 2017-10-15 11:33:59 I'm pretty sure PAM covers it https://bugs.archlinux.org/task/50369 2017-10-15 11:35:54 also, I'm not sure how to figure out what depends need to be in $depends_dev and which one just in $makedepends 2017-10-15 11:40:23 depends_dev can be thought of as a 'header dependency', so Qt5 and KF5 components that it depends on would be there because you would need those headers to compile the package's headers; makedepends is for build-time deps only 2017-10-15 11:41:10 for example: https://code.foxkit.us/adelie/packages/blob/master/user/kio/APKBUILD 2017-10-15 11:41:34 kdoctools is only used during building for generating the docbook file. a library that used kio wouldn't need that. 2017-10-15 11:42:32 so why is qt5-qttools still in $makedepends there? 2017-10-15 11:44:35 qttools is used for QHelpGenerator only 2017-10-15 11:46:36 hmm 2017-10-15 11:46:59 also, some tests fail. should I just disable the test then? 2017-10-15 11:57:13 which tests? 2017-10-15 12:01:25 so far breeze-icons 2017-10-15 12:05:18 I can also just skip that single test I guess 2017-10-15 12:11:15 yeah, that's what we do; there seems to be a problem following symlinks on musl with fdupes 2017-10-15 12:11:19 kconfig even has 18 failed tests... 2017-10-15 12:18:00 aah, kconfig fails due to X11 stuff which you mentioned. I'll disable it for those packages then 2017-10-15 12:28:29 https://i.imgur.com/hdvW337.png https://i.imgur.com/1v3SFDb.png 2017-10-15 12:29:12 I'm so excited to announce that adelie-kde-theme is now a thing, featuring Papirus icon set, Abstract Road wallpaper, and Corindon Red window decos 2017-10-15 12:29:17 fancy 2017-10-15 12:29:19 this would have been such a pain to do with ebuilds 2017-10-15 12:29:27 alpine as a base rocks 8) 2017-10-15 12:29:30 If only Plasma Mobile ran like that 😞 2017-10-15 12:30:05 https://i.redditmedia.com/VZPklVKoZQp5LDUR31G2mC-hj17gaTpn_PnAJhGwNmM.png?w=959&s=0e4878afc2e2433c3d83f3119f2ced93 2017-10-15 12:30:11 although that's pretty good as well ^ 2017-10-15 12:30:16 not that it's usable yet 2017-10-15 12:30:45 that's not bad at all tbh 2017-10-15 12:31:18 all the stuff in our theme is freely available from the store.kde.org site, I just packaged it all together and made a kdeglobals file that is installed to /etc/xdg/system with the adelie-kde-theme.apk :) 2017-10-15 12:37:12 most packages seem to require a running X11 for their tests 😞 2017-10-15 12:41:27 a few of them additionally require D-Bus 2017-10-15 12:41:29 but yes 2017-10-15 12:41:44 that's why I really, really want to try and get a VirtualX-type thing going 2017-10-15 12:41:48 Qt5's tests need it too 2017-10-15 12:42:04 and I'm sure, as we (as a community) package more desktop stuff, there's going to be more tests that need X11 2017-10-15 12:42:44 yeah, same for mobile 2017-10-15 12:43:12 although we will probably also require Wayland eventually 2017-10-15 12:49:26 I believe someone here said they are going to rewrite `apk`, so you could probably suggest the feature for it 2017-10-15 12:52:51 it isn't apk, it's abuild 2017-10-15 12:53:44 well, sure 2017-10-15 14:47:47 foxkit: so I think I got most of your comments resolved now. I'm wondering, what do you mean with the framework tier? what makes a package tier 1 or 2? 2017-10-15 14:48:09 tier 1 are all KDE packages not depending on other KDE packages? 2017-10-15 14:49:00 https://community.kde.org/Frameworks/Policies 2017-10-15 14:49:32 https://en.wikipedia.org/wiki/KDE_Frameworks#Components Click [show] 2017-10-15 14:51:46 ooh thanks! that makes sense then 2017-10-15 15:30:07 it's a bit weird that according to Wikipedia, `kglobalaccel` is a tier 1 package, while it actually depends on several other tier 1 packages 2017-10-15 15:30:38 I think that WP article is outdated 2017-10-15 15:30:45 the authoritative KDE page is a 404... 2017-10-15 15:37:38 yeah I noticed 😆 2017-10-15 15:55:49 foxkit: for reference, a copy of that PDF can be found here https://files.kde.org/frameworks/kde-frameworks-matrix.pdf 2017-10-15 16:53:41 great... "The job exceeded the maximum time limit for jobs, and has been terminated." 2017-10-15 16:53:52 it was succesful up to that point 2017-10-15 16:54:06 anyways, foxkit if you have time, could you check the PR again? 2017-10-15 17:21:53 PureTryOut[m]: it'll be late tonight / early tomorrow. shift work and all, I go to bed in about 3-4 hours, despite that being 4 PM... lol 2017-10-15 17:21:58 but gladly 2017-10-15 17:22:48 no problem! take your time 2017-10-16 14:04:57 i posted this in #alpine-linux as well but i've installed docker, any time i run a docker container that uses mono the container itself segfaults, this can be emby, any one of the other mono apps in existence. Is there something with the kernel security that could be causing this. These same exact containers run fine with any other normal kernel 2017-10-16 14:36:49 Maintainer review/merge of PRs at https://github.com/alpinelinux/aports/pulls/chambbj much appreciated. Thanks! 2017-10-16 14:40:42 hm, we should probably update wpa-supplicant 2017-10-16 14:41:28 https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt 2017-10-16 15:03:57 heh, already announced on the local radio... 2017-10-16 15:35:09 when can we buy the branded krack t-shirts and hoodies? 2017-10-16 16:47:20 I started a ppc64le container (latest tag) from https://hub.docker.com/r/ppc64le/alpine/ and configured it to point to "edge" repository. But when I run apk upgrade it fails with error: 2017-10-16 16:47:20 (3/8) Upgrading alpine-baselayout (3.0.4-r0 -> 3.0.5-r0) 2017-10-16 16:47:20 Executing alpine-baselayout-3.0.5-r0.pre-upgrade 2017-10-16 16:47:20 ERROR: alpine-baselayout-3.0.5-r0: failed to rename var/run.apk-new to var/run. 2017-10-16 16:47:20 Is there something I'm missing or seems it is an issue? 2017-10-16 16:52:20 yes, i believe there is problem with symlinks handling 2017-10-16 16:52:26 i haven't gotten to debnugging it 2017-10-16 16:52:29 yet 2017-10-16 18:01:21 just pushed the wpa_supplicant upgrade, fixes could probably just be cherry-picked for 3.6 and 3.5 but I have no means to test it 2017-10-16 18:01:36 backporting them to 3.4 and 3.3 will probably be pretty annoying 2017-10-16 18:02:07 <_ikke_> nmeum: \o/ 2017-10-16 18:04:07 would probably also be a good idea to patch main/hostapd accordingly 2017-10-17 05:20:14 clandmeter, thanks for the recent efi related packages... was someone working setup-{bootable,disk} to do UEFI boot? 2017-10-17 06:11:46 fabled: i am 2017-10-17 06:12:03 i am happy to help doing/testing it 2017-10-17 06:12:50 i'm hoping to push efitools and sbsigntool today 2017-10-17 06:13:16 I can share a diff later. Still rough though. 2017-10-17 06:14:42 i just setup by hand UEFI boot for my new laptop... and it was painful 2017-10-17 06:14:53 are you using grub, or gummiboot? 2017-10-17 06:14:55 I'm not sure we want to modify nvram? 2017-10-17 06:15:05 Grub 2017-10-17 06:15:18 clandmeter, it would be nice to install to /EFI/Alpine/* and use efibootmgr 2017-10-17 06:15:33 we also need some hooks to update the images there when new kernel comes 2017-10-17 06:15:45 Yes 2017-10-17 06:16:13 setup-bootable needs to be updated too... we can do proper uefi install only if the usb media is booted with uefi 2017-10-17 06:19:23 We probably need to update our iso to support efi 2017-10-17 06:20:05 I think I have an old script to do that. If that still works 2017-10-17 06:20:24 our iso's have uefi working 2017-10-17 06:20:29 i fixed that earlier 2017-10-17 06:20:58 boot setup-bootable converting .iso to usb drops it 2017-10-17 06:38:33 They do? Nice didn't notice. Also arm? 2017-10-17 06:39:41 clandmeter, https://git.alpinelinux.org/cgit/aports/tree/scripts/mkimg.base.sh#n168 2017-10-17 06:41:07 clandmeter, supports x86_64 and aarch64 currently: https://git.alpinelinux.org/cgit/aports/tree/scripts/mkimg.base.sh#n201 2017-10-17 06:44:28 i think setup-bootable could just take the efiboot.img and extract it to USB /EFI/ or similar 2017-10-17 06:45:28 then setup-disk can recognize that we booted in uefi mode if /sys/firmware/efi/efivars is mounted (or exists in general) 2017-10-17 06:45:47 and do uefi install with GPT partition table, and EFI System Partition 2017-10-17 07:04:41 fabled: a nice, did you take part of that from my previous script? the comment looks very similar. 2017-10-17 07:04:50 clandmeter, yes, it's based on your work 2017-10-17 07:05:04 :) 2017-10-17 07:10:57 for setup-bootable my idea was to add a switch to select grub as alternative bootloader, we already have grub stashed in to support ppc boot. detect if we are booting over efi and make it install esp on gpt. we still keep extlinux as default for bios boot ofc. maybe we should also add a switch to let user choose gpt instead of dos as we need gpt anyways. 2017-10-17 07:12:35 clandmeter, ok. i'm happy to look at diffs. i am packaging the sbsigntool and efitools now 2017-10-17 07:13:53 yes, i think it will need somebody with more experience with shell scripting to make it foolproof. 2017-10-17 07:31:01 fabled: on another note, why does our vanilla kernel not have the flavor appended to the filename and others do? 2017-10-17 07:31:26 clandmeter, mmm, i think it's legacy/historical reasons. ncopa would know better. 2017-10-17 07:34:54 i wonder if we should make overlayfs the default when booting ro media. For things like zfs it would be nice if they work out of the box. 2017-10-17 07:36:46 perhaps. now it's behind "overlaytmpfs" boot option 2017-10-17 08:30:50 what code is responsible for creating the /dev/usbdisk symlink? it created for me but points to the second partition on the USB device instead of the first.... 2017-10-17 08:42:46 but not every boot, is alters between part 1 and part 2 between reboots, sigh. 2017-10-17 08:42:55 <_ikke_> You should set it in the kernel boot line 2017-10-17 08:47:02 _ikke_ OK, do you have an example? 2017-10-17 09:11:38 _ikke_: alpine_dev=usbdisk:vfat ? 2017-10-17 09:12:09 <_ikke_> HRio: You should problably use the GUID 2017-10-17 09:14:08 so alpine_dev=UUID=XXXX-XXXX:vfat ? 2017-10-17 09:19:16 <_ikke_> Yes, something like that 2017-10-17 09:25:51 still /dev/usbdisk points to the second part. But it boots and mounts the first part under /media/sdg1. Need to trouble shoot some more, thansk for the pointer. 2017-10-17 09:26:29 <_ikke_> Might also be eudev 2017-10-17 10:13:58 mdev will probably setup sdg1 in initramfs 2017-10-17 10:35:51 ncopa, ping 2017-10-17 10:36:09 i'm getting: ERROR: alpine-baselayout-3.0.5-r0: failed to rename var/run.apk-new to var/run. 2017-10-17 10:36:21 this happens due to the recent baselayout change of making var/run a symlink 2017-10-17 10:36:28 yet, sudo will ship it as directory 2017-10-17 10:44:16 i kill it from sudo, seems that's safe 2017-10-17 10:48:47 clandmeter: changed to UUID in fstab as well, so its mounted on /media/usb. Then it finds the apk cache during boot as well. But /dev/usbdisk -> sdg2, but thats for later. Thanks 2017-10-17 11:03:18 clandmeter, efibootmgr works, care to move it to main or community? it will likely need to go to .iso images too later to get uefi hard disk installs working 2017-10-17 11:06:56 i guess main makes more sense for boot related aports? 2017-10-17 11:07:20 yes 2017-10-17 11:15:03 clandmeter, oh, seems our grub-efi generation is still disabled by default for .iso images 2017-10-17 11:15:41 yes i think our current ones dont have it 2017-10-17 11:16:55 and seems the fat ramdisk image for .iso is placed also in the .iso itself, so it's extractable to usb disk from there 2017-10-17 11:21:58 correct me if im wrong, so the default alpine iso will be isolinux+efi (hybrid)? 2017-10-17 11:41:07 woohoo. can I test it already? 2017-10-17 11:41:36 sure, build your own iso :) 2017-10-17 11:44:19 fabled: i would be nice if we could somehow detect mkinitfs features from the booted system. 2017-10-17 11:45:02 3.6 is really limited by the hardcoded featues in setup-disk 2017-10-17 11:45:58 rdutra: you are doing ppc right? 2017-10-17 12:05:36 clandmeter, yes; that would need to be easier configurable 2017-10-17 12:07:00 scadu, yes, the hybrid efi+syslinux works; i tested it a long time ago. it's just uncommenting the grub_mod="" line in mkimg.base.sh and building your own image 2017-10-17 12:21:05 clandmeter: yes 2017-10-17 12:21:14 hi 2017-10-17 12:21:36 i think ppc64le supports gpt right? 2017-10-17 12:22:50 clandmeter: yes, it does 2017-10-17 12:25:59 rdutra: ok, i will see if i can add support for it. 2017-10-17 12:27:42 clandmeter: ok, in the setup_disk script? 2017-10-17 12:27:52 yes 2017-10-17 12:28:19 clandmeter: ok, if you need help testing or something, let me know 2017-10-17 12:28:46 yes, when we finish it we will let you know to test. 2017-10-17 12:29:07 sure 2017-10-17 12:46:26 fabled: i wonder if we could (as an alternative for now) just source the mkinitfs.conf from running system if setup-disk would find it. 2017-10-17 13:13:27 fabled: oh, that's nice. I'll take it for a trial run soon then 2017-10-17 13:13:40 i hope we could enable that for edge this week 2017-10-17 13:13:45 need to fix setup-* scripts 2017-10-17 13:14:00 and change the efi .img name in the .iso so it becomes Rufus compatible 2017-10-17 14:10:03 I plan to take a look at it this weekend 2017-10-17 14:46:41 fabled: or... is there anything to test at the moment? 2017-10-18 06:42:34 clandmeter, morning. 2017-10-18 07:09:00 fabled: morning 2017-10-18 07:09:58 i never got the setup-disk patch 2017-10-18 07:10:10 but i've been working on the iso/setup-bootable side 2017-10-18 07:10:36 i'm wondering if we should ship the efi boot loader twice, or depend on mtools during 'setup-bootable' 2017-10-18 07:11:14 yeah i was home after 0:00... 2017-10-18 09:37:26 morning 2017-10-18 09:38:00 lua-hashids-1.0.6-r0 contains no files for me. is that just me? 2017-10-18 09:43:08 ScrumpyJack: morning 2017-10-18 09:43:14 its feature 2017-10-18 09:43:18 a 2017-10-18 09:43:42 do you have an lua version installed? 2017-10-18 09:43:57 yes 2017-10-18 09:44:16 iirc it has a install_if to install the correct hashids version based on the installed lua ver 2017-10-18 09:44:17 lua-5.1.5-r4 2017-10-18 09:44:38 and it didnt pull in lua5.1-hashids? 2017-10-18 09:45:12 it did 2017-10-18 09:45:49 then what is your problem? 2017-10-18 09:45:52 :) 2017-10-18 09:46:28 lua-hashids is just a meta pkg to help you install the correct version 2017-10-18 09:46:50 funnily enough, i'm trying to run your turbo-paste locally 2017-10-18 09:46:53 i get this ttp://tpaste.us/dj0J 2017-10-18 09:48:23 so hashids.so isn't in a package? 2017-10-18 09:49:13 nor is hashids.lua ? 2017-10-18 09:50:11 the only files in lua5.1-hashids are clib.so and init.lua 2017-10-18 09:51:13 i think thats correct 2017-10-18 09:51:26 it should try to load hashid/init.lua 2017-10-18 09:52:08 can you show me apk info -L lua5.1-hashids ? 2017-10-18 09:54:24 luajit is an exception. we dont install_if based on luajit so you have to manually install the correct packages. 2017-10-18 09:55:12 luajit needs lua5.1 so you need to install those packages or install lua5.1 so it will be pulled in automatically. 2017-10-18 09:56:48 http://tpaste.us/40nw 2017-10-18 09:57:37 ah 2017-10-18 09:58:10 are you on edge? 2017-10-18 09:58:37 eeyip 2017-10-18 09:59:27 ok let me fix that 2017-10-18 10:12:02 ScrumpyJack: i pushed a fix 2017-10-18 10:13:15 thx for reporting it! 2017-10-18 10:15:08 neat, thanks. when is the next build? 2017-10-18 10:15:16 (edge) 2017-10-18 10:15:21 its build 2017-10-18 10:15:27 just not synced everywhere i think 2017-10-18 10:16:32 nl3.a.o is uptodate 2017-10-18 10:16:46 i think it syncs per push 2017-10-18 10:42:05 foxkit: hey sorry for bothering you, but did you have a chance to look at my PR again? 2017-10-18 11:03:49 PureTryOut[m]: nope, and this is why: https://i.imgur.com/ebFW4ZQ.jpg 2017-10-18 11:04:05 oef, house damage? 2017-10-18 11:04:55 that consumed all my free time this weekend/monday. and now I have lots of work, and I need to give a family member a lift to the dentist this morning, so it probably won't be until this weekend when I can give it a full thorough review. one thing I did notice skimming was that you put license=LGPL instead of LGPL-2.1 or LGPL-3.0. Alpine's trying to standard on SPDX license names so that'd be a help, 2017-10-18 11:04:57 but you don't really need to if you don't want to 2017-10-18 11:05:22 PureTryOut[m]: yeah the ceiling in the shower finally decided to separate into pieces. :/ 2017-10-18 11:05:53 foxkit: no problem. I'll fix the license names and will wait for the weekend then 2017-10-18 11:06:24 contractor is coming out Thursday to repair it, so at least it's being handled quickly 2017-10-18 11:06:28 (I rent) 2017-10-18 12:29:10 clandmeter: updated package, thanks. 2017-10-18 12:29:49 I've got turbo paste listening on localhost, but passing data to it i get "400 No data received.%: 2017-10-18 12:38:23 there's my sunday merge, done on wednesday morning... heh 2017-10-18 13:04:11 less than a week delay, seems good enough 😉 2017-10-19 03:42:57 https://mastodon-dereferenced-org.s3-us-east-2.amazonaws.com/media_attachments/files/000/051/053/original/c8eb4d26e9faf61d.png 2017-10-19 03:43:01 i'm a terrible person 2017-10-19 03:53:03 kaniini: what have you done 2017-10-19 03:54:30 danieli: bash and zsh have a hook that can be called to override the default command-not-found handling, so i wrote a wrapper around apk to suggest packages which may contain the command 2017-10-19 03:54:41 aha 2017-10-19 03:54:43 that's pretty nice 2017-10-19 03:55:09 danieli: this is just a prototype, for full implementation i intend to add a hook to busybox sh as well, and create a new provider namespace "command:" 2017-10-19 03:56:37 this is more intended to be a feature in adelie, but there's no reason why it wouldn't be beneficial to alpine users as well ;) 2017-10-19 03:57:50 probably not default on in alpine tho 2017-10-19 05:21:43 kaniini, thanks for the recent patch queue merges! 2017-10-19 06:09:36 clandmeter, i'm cleaning up grub apkbuild 2017-10-19 06:09:48 enabling grub-efi on arm 2017-10-19 06:10:48 i reached out to IBM to see how much an s390x system would cost to buy 2017-10-19 06:10:54 they quoted me $300k which is literally how much my house cost 2017-10-19 06:11:06 guess that's not happening for a while 2017-10-19 06:22:04 jeez 2017-10-19 06:22:27 i'm not surprised to be honest 2017-10-19 06:22:28 well if somebody asks for adelie to be on s390x and shows up with 300k 2017-10-19 06:22:32 then we will get one 2017-10-19 06:22:33 ;) 2017-10-19 06:44:32 fabled: ok nice. im finishing my local tests and then commit EFI+GPT support 2017-10-19 07:02:54 i'm trying to figure out why guile crashes on s390x 2017-10-19 07:02:58 ACTION sends bill to IBM 2017-10-19 07:30:52 kaniini: since testing/{haxe,neko} is broken on most archs (according to you): would you mind if I move them from testing to unmaintained? 2017-10-19 07:31:23 or do you intend to fix them? 2017-10-19 07:40:12 nmeum: an actual haxe developer submitted the PR so i poked them to fix it 2017-10-19 07:40:13 kaniini, clandmeter : grub cleanup http://sprunge.us/ghQN -- will push soon 2017-10-19 07:40:18 test built on x86_64 and armhf 2017-10-19 07:40:42 nmeum: i prefer to hear back first 2017-10-19 07:40:47 but we have a larger problem 2017-10-19 07:41:02 we need, most likely, to do a late downgrade of guile back to 2.0 2017-10-19 07:41:11 because 2.2 seems to believe that stack memory is an infinite resource 2017-10-19 07:41:31 i think we also need to restrict it to core team only 2017-10-19 07:41:54 because the 2.2 upgrade originated from github 2017-10-19 07:42:00 and wasn't really imo properly smoketested 2017-10-19 07:42:34 of course, the need to properly smoketest it was not known until now, but sheesh 2017-10-19 07:45:54 fabled: grub cleanup looks good 2017-10-19 07:46:58 kaniini, i did pretty good guile testing before applying it 2017-10-19 07:47:14 but yeah 2017-10-19 07:47:17 only on x86_64 2017-10-19 07:47:39 yeah i mean across all the archs 2017-10-19 07:47:57 yes 2017-10-19 07:48:06 i'd really like to get proper build system... 2017-10-19 07:48:21 so that we 'abuild rootbld' all architectures on single box instead of LXCs 2017-10-19 07:48:29 err... all branches 2017-10-19 07:52:10 running abuild on 2.0.14 2017-10-19 07:52:41 this was known to build on s390x before so 2017-10-19 07:54:22 the alternative is we push forward and bump the stacksize again 2017-10-19 07:55:23 but i'm not confident in that 2017-10-19 07:55:54 it should be ok to upgrade mutt in AL3.6 from 1.8.2 to 1.8.3, right? "This is a bug-fix release, fixing a memory leak, a couple IMAP issues, and a few other small issues." 2017-10-19 07:56:31 i'm ok with it 2017-10-19 07:58:14 ACTION has to vanish in a moment for the rest of day, but if no one will be willing to do the mutt bump, he'll send the patch tonight to ML 2017-10-19 08:00:01 brb 2017-10-19 08:02:23 it seems that guile does not infect much 2017-10-19 08:03:23 good 2017-10-19 08:03:27 at least there's that 2017-10-19 08:20:13 going to let guile-2.0.14 build on s390x and take a nap, it is very slow 2017-10-19 08:20:25 so far 2.0.14 is building fine though, just slowly 2017-10-19 08:20:56 i suspect there is a regression in this hashing code 2017-10-19 08:21:00 and that's why it goes all wonky 2017-10-19 08:51:48 clandmeter, the grub failure on armhf is due abuild.conf CFLAGS having -fPIC 2017-10-19 08:51:53 i'm removing that 2017-10-19 08:51:54 ok i think im ready with gpt for setup-disk. 2017-10-19 08:52:08 ok 2017-10-19 08:52:42 i sorted guile 2017-10-19 08:52:52 goodnight 2017-10-19 08:52:52 gnite 2017-10-19 08:53:29 i also put a nice don’t touch this package warning on the apkbuild so hopefully aspiring contributors just leave it alone in future 2017-10-19 08:53:34 dont dream too much about s390x ;-) 2017-10-19 08:53:51 clandmeter, sounds like it'd be nightmare... 2017-10-19 08:54:01 well between my new house and an s390x machine i think i made right choice 2017-10-19 08:54:41 :) 2017-10-19 08:55:14 if you put it in your house you may not need additional heating anymore, could save some costs ;-) 2017-10-19 09:00:12 you kid but actually i am reclaiming the heat from my build servers already :) 2017-10-19 09:04:57 Jacuzzi??? pics or it didnt happen! 2017-10-19 11:27:31 could someone with enough fancy github permissions close? https://github.com/alpinelinux/abuild/pull/28 2017-10-19 12:00:28 nmeum, closed 2017-10-19 12:00:33 fabled: thanks! 2017-10-19 15:25:28 clandmeter: the heat is vented into my attic and used to preheat the ductwork 2017-10-19 16:01:19 hi everybody. i ran into problems when trying to get nextcloud to work in an alpine docker container on my QNAP NAS. long story short: the NAS kernel issues EPERM (instead of ENOSYS) when calling getrandom(), thus breaking php. i created a patch for the php7 package, re-built it and got it to work. is this something that's worth submitting or would this patch be denied 'cause it's (obviously) a 2017-10-19 16:01:25 vendor implementation problem? 2017-10-19 16:52:37 scadu: basic efi support has now landed in alpine-conf master branch. 2017-10-19 16:53:49 i hope we can get it into edge asap, but you can already try from git directly. 2017-10-19 17:29:08 danieli: http://turtle.dereferenced.org/~kaniini/0001-ash-add-support-for-command_not_found_handle-hook-fu.patch 2017-10-19 17:29:12 danieli: i'm going to hell 2017-10-19 17:35:19 am I blind or it's not possible to make ash allow .ash_history bigger than hardcoded CONFIG_FEATURE_EDITING_HISTORY=255 w/o changing its code? it seems once you have 1020 lines and execute new command, it's trimmed to 255 lines, regardless of your HISTFILESIZE setting. I hate losing shell history... 2017-10-19 17:36:22 yes, seems buggy 2017-10-19 17:38:38 was using ash in containers, but screw it, I'll install and switch to bash there too 2017-10-19 17:39:13 there's some other gotchas i want to fix but probably wont make 3.7 release 2017-10-19 17:39:37 (command_not_found stuff is staying out for 3.7, to make it useful we need to add a new provider namespace to abuild) 2017-10-19 17:41:35 in shell the most important thing is its history. that's why I always set HISTSIZE and HISTFILESIZE to 9999999 everywhere (or something like that), but if shell doesn't respect it, it's not worth using. 2017-10-19 17:44:28 matrix reliability is encouraging 2017-10-19 19:32:05 dammit 2017-10-19 19:32:05 i was just about to tag kaniini 2017-10-19 19:33:43 thankfully hope isn't in matrix, otherwise it wouldn't die last 2017-10-19 19:35:19 przemoc: it's a free service run by other people with no cost to you. situations like that aren't exactly conducive to five nines of uptime :P 2017-10-19 19:36:03 I am obviously joking 2017-10-19 19:36:25 sarcasm does not display correctly over IRC 2017-10-19 19:57:46 <_ikke_> Or over the internet in general 2017-10-19 20:00:43 my sarcasm-o-meter is often out of sync 2017-10-19 20:08:43 isn't there a convention to postfix with /s ? 2017-10-19 20:17:48 new musl finally landed 2017-10-19 20:27:02 <_ikke_> wWrAR07vpPZ1: yes /s 2017-10-19 20:41:10 are you now postfixing your answer "yes" with /s, or are you confirming my suggestion? 2017-10-19 20:42:40 <_ikke_> That's the joke 2017-10-19 21:43:31 at least one of us was indeed joking ;) 2017-10-19 22:43:03 https://gist.github.com/przemoc/3c575f2d855ba62680159c426a68f84c <- I wrote simplistic abuild wrapper, that maybe someone will find useful too. (Yes, I prefer setting bunch of vars in script over elaborate ~/.abuild/abuild.conf with hardcoded paths) 2017-10-19 22:57:36 as promised ~15 hours ago: %3648 2017-10-19 23:03:40 kaniini: really nice commit message for musl 1.1.17-r1. my only nitpick would be your non-standard line wrapping setting, i.e. longer than 72 chars. 2017-10-19 23:04:55 as promised, we are going into more detail with musl updates in future :) 2017-10-19 23:05:06 greatly appreciated 2017-10-19 23:07:53 przemoc: i bumped history max to 8192 lines in busybox shell btw 2017-10-19 23:08:09 yeah, saw that 2017-10-19 23:08:17 kind of workaround 2017-10-19 23:09:58 it's because of how busybox history works 2017-10-19 23:10:01 it stores history in an array 2017-10-19 23:10:05 they don't allow size to be bigger than this setting at all from what I've seen, but then there is this weird behavior I was talking about earlier, where I had many more lines than previous 255 default and only at some point it was trimmed. 2017-10-19 23:10:09 right 2017-10-19 23:10:27 so some bug is likely there 2017-10-19 23:11:09 not sure, 255 seemed too little at any rate 2017-10-19 23:12:15 yeah, and thanks for improving it at least. but as I said, I ragestopped ash usage on my containers ;) 2017-10-19 23:20:47 kaniini: I think that foxkit might have answered this to some degree in the past, but what are the things that cannot be backported to AL and warrant another distro build on top of it? 2017-10-19 23:21:40 that's a weird question, because for the most part, we intend to do most development of adelie features directly in alpine where logistically possible 2017-10-19 23:22:35 with adelie, the main purpose of having a fork is to allow more control over the release process for adelie itself. in essence what happens is that adelie takes alpine edge every so often and fixes it up for release with it's own packageset on top 2017-10-19 23:24:51 so far i don't think there is anything in adelie that we have no plans to bring into alpine, for example KDE5 is being negotiated between adelie and pmOS people to determine what the alpine merged version will look like 2017-10-19 23:25:02 and then adelie will rebase on that 2017-10-19 23:25:28 re 1st msg: that's what I've seen so far and it's a good thing. re 2nd msg: so it's mostly about being in control, not about disagreement with, let's say ncopa, about some important matters. and the packages unavailable in AL, beside obviously branding-related, what are they? 2017-10-19 23:26:09 right now the main packages that are deviant in adelie are KDE5 and LXQt, which basically don't exist in alpine yet 2017-10-19 23:26:29 and getting the alpine packaging right for KDE5 at least involves coordinating with pmOS crew because they are doing KDE5 mobile 2017-10-19 23:26:30 ok, desktop-related matters 2017-10-19 23:26:50 adelie does not carry grsecurity variant 2017-10-19 23:27:34 largely because we do not want to risk having trouble from spender since there are commercial intentions with adelie and he could, like, you know, sue us 2017-10-19 23:28:00 understandable 2017-10-19 23:28:10 adelie also does not carry python 2 2017-10-19 23:28:37 but that is largely because we are trying to incubate python2 removal from alpine 2017-10-19 23:28:51 it is easy to get an idea of what would be involved in that if you never ship py2 to begin with ;) 2017-10-19 23:29:25 beyond that, it is very similar. not 100% straightforward to cross-grade, but apk can do it. 2017-10-19 23:31:02 right now, there is also no run-from-ram variant of adelie 2017-10-19 23:31:54 but that's largely due to historical reasons, adelie has it's own cd mastering scripts 2017-10-19 23:32:14 and the original prototyping of adelie was based on gentoo + apk instead of alpine + apk 2017-10-19 23:32:47 but rebasing on AL already happened, right? 2017-10-19 23:32:56 yes 2017-10-19 23:32:58 other than the plans for commercial support, that pretty much covers the differences 2017-10-19 23:33:16 if you maintain a package in alpine, you most likely also maintain it in adelie 2017-10-19 23:33:27 (and also in pmOS) 2017-10-19 23:34:15 i plan to introduce the Original-Maintainer metadata field to apk3 to clarify those relationships 2017-10-19 23:35:03 so most (99.9%) of the stuff available in Adelie should/will be in AL anyway, hopefully. it feels like commercial plan is the true meat of Adelie <-> Alpine differences. 2017-10-19 23:36:23 right 2017-10-19 23:37:12 basically, the commercial plan allows acceleration of development of features in alpine which get shipped in adelie as well 2017-10-19 23:37:12 and being maybe slightly more on the edge in matters that interest Adelie devs more, like polishing desktop experience before bringing it to AL, IIUC 2017-10-19 23:37:20 yes :) 2017-10-19 23:37:41 but also server-side we have serious plans 2017-10-19 23:38:54 przemoc: the other major difference is that adelie will have LTS releases that have 5+ year support lifecycle 2017-10-19 23:42:17 5y is a lot, and requires some resources to properly manage that. OTOH 5y is often necessary when speaking about enterprise solutions. 2017-10-19 23:42:39 przemoc: basically adelie is to alpine like ubuntu is to debian, but with a very serious intention to give back as much as possible using an alpine-first development process 2017-10-19 23:44:33 what i mean here is that debian basically has to beg for patches back from canonical, while instead we happily provide patches early and often 2017-10-19 23:44:34 intentions are good, that much I can tell without doubt 2017-10-19 23:44:46 yeah, I know what you mean 2017-10-19 23:45:31 literally, when in doubt, we have looked at what ubuntu has done with debian and we have done the exact opposite :) 2017-10-19 23:45:40 :D 2017-10-19 23:45:54 road to hell is also paved with good intentions ;) 2017-10-19 23:46:49 that is true, but alpine is a pretty safe bet 2017-10-19 23:50:31 I also think it's a safe bet, but I have a slight hunch here, that adelie is also kind of AL fail-safe project, for some inconceivable case like, I don't know, ncopa going mad and ruining AL. ;) 2017-10-20 00:01:53 przemoc: yes, for another example, we don't ship qt4 where alpine still does for a while until things are migrated. we also have some differences of opinion as to what is valuable (adelie packages are all built with -dbg, which means we can't carry the full alpine set or our mirrors would run out of disk quickly.) 2017-10-20 00:02:17 it's not really a fail-safe project 2017-10-20 00:02:26 (it started out as one though) 2017-10-20 00:02:52 when docker hired ncopa, we were a bit nervous about the future of alpine, because it wasn't really clear what their strategy was with it 2017-10-20 00:02:56 kaniini: the cd in fact does run from RAM (squashfs with RAM overlayfs on /home/live, /root, and /var), it just doesn't have the persistence layer that alpine has. 2017-10-20 00:03:40 I'd like to end up adding lbu support to it and still use it because I like the way it works, but we might change to the alpine scripts, not sure yet. 2017-10-20 00:03:48 oh. the last time i booted an adelie livecd, it was all readonly 2017-10-20 00:03:48 :p 2017-10-20 00:04:02 /etc is readonly 2017-10-20 00:04:19 which wasn't one of my better ideas 2017-10-20 00:04:51 it makes things like dhcpcd unhappy because it can't overwrite /etc/resolv.conf, but that may be just as well because we have carrier-neutral resolvers in as default :p 2017-10-20 00:08:48 przemoc: but yes, to answer your question, if alpine were to have a complete failure of the core team and all processes for dealing with such a failure were exhausted, then absolutely adelie would be insulated from that 2017-10-20 00:08:54 przemoc: it seems unlikely though 2017-10-20 00:11:28 but either way we are vested in making sure such a failure never occurs 2017-10-20 00:11:39 a strong alpine = a strong adelie 2017-10-20 05:05:09 kaniini, thanks for musl updates - was just about start doing them... 2017-10-20 05:07:33 np :) 2017-10-20 05:11:14 fabled: i have a few patches originating from adelie that add command-not-found functionality. one adds provides= entries for all commands provided by a package (command:foo), the other adds the possibility of a hook to busybox shell to optionally allow invoking apk to get package suggestions when a command is not found 2017-10-20 05:11:21 i think it would be neat to have this in 3.7 2017-10-20 05:12:23 i'd rather not clutter provides... but that's the way to do it until we get contents db of non-installed packages 2017-10-20 05:13:28 on average the cluttering doesn't seem so bad 2017-10-20 05:13:38 i think it's worth doing it that way for now until apk3 hits 2017-10-20 05:15:32 yes 2017-10-20 05:18:22 the approach works quite well: https://mastodon-dereferenced-org.s3-us-east-2.amazonaws.com/media_attachments/files/000/051/432/original/d6b028084cda8942.png 2017-10-20 07:35:05 Ganwell: http://build.alpinelinux.org/buildlogs/build-edge-x86/community/girara/girara-0.2.7-r0.log 2017-10-20 10:18:30 I created few updates for PHP packages https://github.com/alpinelinux/aports/pulls/andypost it needs review 2017-10-20 10:18:56 kaniini: http://build.alpinelinux.org/buildlogs/build-edge-x86/community/girara/girara-0.2.7-r0.log 2017-10-20 10:19:01 kaniini: sorry 2017-10-20 10:19:07 kaniini: the tput errors? 2017-10-20 11:40:11 Ganwell: fabled already pushed a fix which disables tests. 2017-10-20 11:40:37 not the tput but the X server not available tests. 2017-10-20 12:45:12 kaniini, that guile downgrade has unblocked our ppc32 builder. apparently that was the big issue. thanks! 2017-10-20 12:45:22 thought it was endianness related due to where it was crashing 2017-10-20 12:45:30 but apparently it wasn't 2017-10-20 12:48:53 foxkit, thanks for that. we should file a guile bug on unbounded recursion causing issues on the two architectures 2017-10-20 12:53:06 fabled: https://bpaste.net/raw/1568c28ebce1 2017-10-20 12:53:24 it crashes during 'GEN guile-procedures.texi' 2017-10-20 12:53:29 that looks different issue 2017-10-20 12:53:37 info threads ? 2017-10-20 12:53:37 it apparently uses itself to generate texinfo 2017-10-20 12:53:50 well that paste is two weeks old.. 2017-10-20 12:54:02 what we had, was the generator crashing in unbounded recursion on cleanup thread 2017-10-20 12:54:03 the builder already chugging away on gtk3 now 2017-10-20 12:54:51 when it finishes I can try to generate the core again 2017-10-20 19:01:54 Hi there! There's a recurring question about why new wiki users can't create pages with external links. I propose to adjust the wiki's main page as follows to cover this (it asks new contributors to add links in plain text and ask in #alpine-linux if we could quickly convert them to real links, also did minor restructuring): https://gist.github.com/ollieparanoid/e94d3027aa27c97ddf2f116ff0239482 2017-10-20 19:02:02 What do you think? 2017-10-20 19:02:56 (the main page seems to be protected, so someone who has the rights would need to make the edit, if you guys like it) 2017-10-20 20:20:37 ollieparanoid: its best to send your suggestion to the infra ml. 2017-10-20 20:21:44 clandmeter: ok, will do 2017-10-20 20:46:44 clandmeter: I've sent it, but it does not show up here yet, does it need someone to approve it? I have registered for the alpine-infra list today. https://lists.alpinelinux.org/alpine-infra/ 2017-10-20 20:47:19 i received it 2017-10-20 20:47:41 not sure how the webif works, could popup later 2017-10-20 20:48:10 yeah probably. thanks for confirming! 2017-10-20 20:48:48 thanks for your input! 2017-10-20 20:50:00 going to start adding command: metadata to packages shortly 2017-10-20 20:50:15 soon you will be able to `apk add command-not-found` for package suggestions 2017-10-20 20:52:50 kaniini: nice! will alpine-base put something in /etc/profile.d/, that automatically checks apk for commands not found? 2017-10-20 20:52:50 (I imagine that this works with a profile script, that the shell loads?) 2017-10-20 20:52:50 ollieparanoid: command-not-found will. i'm not sure if we add this to alpine-base yet. will be part of adelie-base. 2017-10-20 20:54:12 yeah, the pattern seems to be keeping alpine-base as lightweight as possible 2017-10-20 20:56:53 ollieparanoid: demo: https://mastodon-dereferenced-org.s3-us-east-2.amazonaws.com/media_attachments/files/000/051/432/original/d6b028084cda8942.png 2017-10-20 20:59:21 cool, I guess it makes sense to put that into postmarketos-base too, because it makes it more userfirendly 2017-10-20 23:10:19 kaniini: https://git.alpinelinux.org/cgit/aports/commit/?id=53993d6b5a3b555579aa202429764996517ed6aa is there any chance for merging it to 3.6? 2017-10-20 23:14:26 yes 2017-10-20 23:14:40 as well as the dns one 2017-10-20 23:17:32 Cool 2017-10-21 14:24:29 so... the webinterface for the alpine-infra list doesn't show the message I have sent yesterday. this is a bug, right? (should I write that to alpine-infra? :p) https://lists.alpinelinux.org/alpine-infra/index.html 2017-10-21 16:13:03 one thing that command: providers will help is the stupid awk or which thing 2017-10-21 16:13:14 adelie does not ship busybox in core, so there are a lot of packages that need 'which' 2017-10-21 16:13:26 but I can't really contribute back the apkbuilds because /alpine/ builds wouldn't need 'which' 2017-10-21 16:13:37 if I could do command:which, that will pull in which on adelie, and busybox on alpine 2017-10-21 16:17:16 ncopa: came across https://ubuntuforums.org/showthread.php?t=797789 after getting "device descriptor read/64, error -71 " couple of time 2017-10-21 16:17:38 say it can be solved by having CONFIG_USB_SUSPEND enabled in kernel 2017-10-21 16:17:53 but don't know much 2017-10-21 16:18:32 about it, also see https://paulphilippov.com/articles/how-to-fix-device-not-accepting-address-error 2017-10-21 16:18:55 might be a motherboard issue 2017-10-21 16:21:34 I am having 'segmenation fault' while qemu running x86 image under x86_64 install, tried couple of times, will test more 2017-10-21 16:21:50 gtg, thanks 2017-10-21 16:23:10 forgot to mention, tests were in AL.v3.6.0 2017-10-21 18:54:52 foxkit: busybox installs it's symlinks in the .trigger script, so command:.. isn't generated for it 2017-10-22 13:44:20 foxkit: I was wondering if you had a chance to look at my PR again this weekend? 2017-10-22 13:44:53 it's Sunday here, so there's still a chance; we had severe weather yesterday. 2017-10-22 13:45:05 also, did you just say Adelie does not ship Busybox? Do you guys ship with GNU coreutils instead? 2017-10-22 13:45:11 I still haven't even finished kde-utilities... 2017-10-22 13:45:19 for Adélie 2017-10-22 13:45:55 well my PR is just down to some Qt deps and tier 1 KDE packages, shouldn't be too much 2017-10-22 13:46:17 PureTryOut[m]: we ship coreutils right now, yes; it is hoped that eventually there will be a competitor to coreutils that actually meets POSIX so we don't have to deal with GNU extensions 2017-10-22 13:46:49 agreed 2017-10-22 13:47:32 interesting move to ship coreutils rather than Busybox, but I guess I see why for a desktop distro 2017-10-22 13:49:11 it's more for POSIX compliance 2017-10-22 13:49:51 how does sbase fare wrt complicance? 2017-10-22 13:49:53 busybox is ridiculous :/ they cut out a lot of features, and maybe it wouldn't be such a big deal if it was one or two applets, but it's basically every applet missing a parameter here, a return code there, etc etc 2017-10-22 13:49:55 compliance* 2017-10-22 13:50:00 is Busybox not POSIX compliant? hmm TIL 2017-10-22 13:50:09 I thought that was the main reason to use Busybox, besides being tiny 2017-10-22 13:50:13 skarnet: I haven't tried it yet, it seems to be inbetween 2017-10-22 13:52:22 https://en.wikipedia.org/wiki/Sbase 2017-10-22 13:52:34 seems they focus on POSIX complaince 2017-10-22 13:53:38 do you believe what wikipedia says about computer programs at face value? If you do, boy, you will love that bridge I have in stock for you 2017-10-22 13:54:09 foxkit: it's not like busybox guys were strictly cutting stuff, they only haven't implemented bunch of things yet, I would say. any striking examples of POSIX incompliance in busybox? 2017-10-22 13:54:45 PureTryOut[m]: it supports a very few GNU extensions (mainly to ls and tar (which is not even in the POSIX standard)) which is why most people use it; but its awk is atrocious, its shell has numerous deficiencies, cp is nonconformant, on down the list... 2017-10-22 13:55:14 skarnet: I said "seems", so not at face value 😉 2017-10-22 13:55:23 last time I checked (August), bb cp was broken in git head 2017-10-22 13:55:44 so it's not only a conformance issue :P 2017-10-22 13:55:46 przemoc: -H is a synonym for -L in cp in busybox, but -H is supposed to be for direct operands only while -L traverses the tree 2017-10-22 13:56:15 fair enough 2017-10-22 13:56:39 haven't used bb cp's "advanced" features lately, so didn't notice 2017-10-22 13:56:49 przemoc: cut ignores -n because "difficult" 2017-10-22 13:56:52 ACTION should read more about POSIX 2017-10-22 13:57:05 przemoc: would need a small book to describe all the awk problems 2017-10-22 13:57:32 przemoc: less has subtle breakage (unrelated to POSIX) on certain terminals because it doesn't care about termcaps 2017-10-22 13:57:53 I spent a long time trying to make busybox work because I did not want to diverge that far from alpine base 2017-10-22 13:57:57 it just wasn't worth it in the end 2017-10-22 13:58:00 there is fairly decent mawk, so no need to use bb's one awk, right? 2017-10-22 13:58:09 mawk isn't even packaged in alpine 2017-10-22 13:58:15 but that's what we at Adélie ship as /usr/bin/awk 2017-10-22 13:58:43 I offered mawk but there was confusion as to how it would be used, if it could replace gawk in some cases, what to do about a virtual for awk, etc. 2017-10-22 13:58:53 so far we have not yet needed to build gawk at all 2017-10-22 13:59:06 all the places in alpine where makedepends has 'gawk' in it, mawk was sufficient, just bb awk was broken. 2017-10-22 13:59:34 you could say bb awk is only a mawk-up 2017-10-22 13:59:39 but of course, mawk doesn't implement many GNU extensions, so /some/ things of course will need it 2017-10-22 13:59:43 hah 2017-10-22 14:02:46 I think AL should go for mawk. virtual awk would be provided by mawk and gawk, and where awk w/o GNU extensions suffice, it should be used in APKBUILDS, and only when gawk is needed, gawk should be put there. and bb's awk shouldn't be build at all, but for compatibility bb should possibly depend on awk, so people wouldn't need to install it explicitly beside busybox. 2017-10-22 14:03:05 (mawk with higher priority than gawk, of course) 2017-10-22 14:04:19 that's a pretty good compromise; you should email it to -devel 2017-10-22 14:07:07 if you'll reply later on ML with bb awk's bugs (I'm not using it much, so cannot discuss about it), to better convince uninformed, then I'll do it, today or maybe in upcoming days. 2017-10-22 14:07:43 I don't know if I still have my notes about it 2017-10-22 14:13:45 speaking of 2017-10-22 14:13:47 foxkit: ok, ping me when you'll find them 2017-10-22 14:14:00 przemoc: sure thing 2017-10-22 14:14:07 kaniini: i feel like giving implementing my virtuals proposal into apk a shot 2017-10-22 14:14:10 any thoughts or comments? 2017-10-22 14:15:12 Shiz: could you link it for memory refreshing? 2017-10-22 14:15:27 i'd need to grep for it; it's been a bit 2017-10-22 14:15:29 uno momento 2017-10-22 14:15:43 did fabled commented it already perhaps? 2017-10-22 14:16:06 https://txt.shiz.me/ZDNkNTY3MD 2017-10-22 14:16:12 I'm not sure, don't htink so 2017-10-22 14:18:28 I'm pretty sure I've seen somthing like that from you, maybe not exactly this version, though 2017-10-22 14:18:50 well I wrote it up a while back :P 2017-10-22 14:21:34 some kind of alternatives managing is definitely needed, but I think there could be something similar on fabled's list of things to do for new awk. 2017-10-22 14:21:53 don't remember the link and don't have the will to grep for it now 2017-10-22 14:23:28 Shiz: I would suggest posting your proposal to ML for getting a bit more eyeballs on it. if you're brave, it can be [RFC][PATCH] mail even, with some implementation already done. 2017-10-22 14:50:59 foxkit: BTW you may want to upgrade mawk in adelie, 5 days ago there was new release 2017-10-22 14:52:54 re suckless and sbase, I remember they were claiming better UTF8 support than alternatives, but I was never into UTF8 deeply, so cannot tell whether it's true or not 2017-10-22 15:11:06 from the few experiments I've done, it's true. But it's totally independent from POSIX compliance. 2017-10-22 16:57:34 just tossing this out there: would something like 'langdir' in APKBUILD be welcome? 2017-10-22 16:57:39 sddm installs to /usr/share/sddm/translations 2017-10-22 16:58:05 and I'm aware of a few other packages that have to override lang() due to the dir being different from /usr/share/locale 2017-10-22 16:58:36 related: was thinking it might be cool to have something like options="configsub" to put update_config_sub in default_prepare for pkgs that have that option 2017-10-22 17:19:27 hahaha nevermind 2017-10-22 17:19:33 looked at the source, langdir is already a thing! 2017-10-22 21:53:15 this might be an interesting new option in gcc to use for the 386? builds? this is a bit confusing to me. but here is the patch: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=92ac8192dd3bd4b48d6ba882af1f1649231258e9 2017-10-22 22:02:28 1) CET chips don't exist yet 2017-10-22 22:02:36 2) this is in GCC trunk 2017-10-22 22:06:07 ah. 1) i didn't know, 2) means we should ad it to the build options i guess. 2017-10-22 22:06:20 (2 cont'd) not as a patch to gcc 2017-10-22 22:10:44 it won't be available until GCC 8 is a thing 2017-10-22 22:16:10 actually, is there a plan when gcc will be upgraded to a newer version (7.x?) in alpine? not that I need it, quite the contrary, I expect some breakage. but it would be nice to know ahead 2017-10-22 22:17:41 usually such upgrades are after releases now in edge. ncopa didn't plan to do any major gcc upgrade before 3.7 IIRC, because of bad experiences in the past when similar things were done and it didn't went smoothly. 2017-10-22 22:19:08 or maybe not, sorry! ncopa actually wanted gcc 7 for 3.7 2017-10-22 22:19:59 https://lists.alpinelinux.org/alpine-devel/5826.html 2017-10-22 22:20:44 but it doesn't mean he still wants it :) 2017-10-22 22:20:56 (though it's quite probable) 2017-10-22 22:21:24 przemoc: ah thanks for the link! 2017-10-22 22:22:40 compiling 3.4 kernels with gcc 7... that'll be fun 2017-10-22 22:23:00 maybe we should keep our own copy of gcc 6 around till we get a patch that works on the majority of kernels 2017-10-22 22:23:19 we aren't going to be going to GCC 7 in Adelie either 2017-10-22 22:23:29 just because GCC 7's powerpc support is... "iffy" right now 2017-10-22 22:23:53 hmm... 2017-10-22 22:25:07 we plan to stick with gcc 6 for now due to said problems 2017-10-22 22:25:25 even at 7.2 it's still bad? 2017-10-22 22:26:22 are issues in the working at least or only problems are reported so far? 2017-10-22 22:27:15 on power ibm is working on fixes but the ibm compiler guy is kind of annoying 2017-10-22 22:27:59 by annoying you mean barely cooperative? 2017-10-22 22:28:45 he has strange views on what abis are 2017-10-22 22:29:36 for example he tried to make it impossible to have big endian ppc64 abiv2 support 2017-10-22 22:30:42 with adelie on the server side especially we want ppc64be for commercial reasons - it’s easier to port legacy AIX code to because you don’t have to deal with endianess 2017-10-22 22:32:42 we also want to leverage the large amount of cheap powerpc g5 systems on ebay as a platform for developers to test on before deploying to production etc 2017-10-22 22:40:21 nice idea 2017-10-23 08:42:40 fabled: goodmorning, are you around? 2017-10-23 08:43:43 clandmeter, morning 2017-10-23 08:44:00 hi, im getting an error with apk 2017-10-23 08:44:11 ERROR: py3-ruffus-2.6.3-r0: failed to rename usr/lib/python3.6/site-packages/ruffus-2.6.3-py3.6.egg-info.apk-new to usr/lib/python3.6/site-packages/ruffus-2.6.3-py3.6.egg-info. 2017-10-23 08:44:17 i'm good. was playing to get secureboot with custom keys working with not good progress 2017-10-23 08:44:38 clandmeter, sounds like some of the directory compmonents is provided by some other package as a file 2017-10-23 08:45:12 yes i think i can see the strace its a directory 2017-10-23 08:45:23 yeah, apk does not handle that cleanly 2017-10-23 08:45:30 but the error msg is a bit weird? 2017-10-23 08:45:34 it happened with sudo's var/run/foo too 2017-10-23 08:45:42 and alpine-baselayout changing var/run to symlink 2017-10-23 08:45:58 the error could be better. or even better if we handled it somehow sanely 2017-10-23 08:46:16 i have a plan for that in apk3, but not sure how to handle it in current codebase 2017-10-23 08:46:27 i thought when a file already existed it would mention the conflicting pkg? 2017-10-23 08:46:57 if upgrading, it could be just the previous version of the package 2017-10-23 08:47:09 ncopa, fabled: ISTR you didn't like to use mdev in initramfs because it forked too much 2017-10-23 08:47:30 I have something for you: https://skarnet.org/software/mdevd/ 2017-10-23 08:47:54 skarnet, yes, that's one of the things. other was to exit as soon as media/devices for boot are found. thus nlplug-findfs got written. 2017-10-23 08:48:42 skarnet, cool! 2017-10-23 08:49:58 (the really cool thing about it is how it reads /etc/mdev.conf, but shhhh) 2017-10-23 10:05:19 Hi, when i my xen alpine 3.6.2 start there is a fail message "some local fielsystem failed to mount". When i login and "mount -a" its mount. The partition to mount is a raid0 with lvm. What can i do thats automount? 2017-10-23 10:18:52 skarnet: cool! 2017-10-23 10:18:55 looks nice 2017-10-23 10:28:17 ncopa: with that, you shouldn't need nlplug-findfs anymore :P 2017-10-23 10:40:06 i think we still need it 2017-10-23 10:41:49 what's the next step then? 2017-10-23 10:42:05 but we can probably pipe to mdevd instead of forking mdev 2017-10-23 10:42:32 nlplug-findfs forks mdev atm? 2017-10-23 10:42:38 yes 2017-10-23 10:42:59 what nlplug-findfs does is: 2017-10-23 10:43:13 search for given filesystem and/or *.apkovl.tar.gz 2017-10-23 10:43:27 once those are found, it will exit 2017-10-23 10:43:45 it wil run a coldplug trigger 2017-10-23 10:43:56 so it will plug the stuff it finds along the way 2017-10-23 10:44:14 ah, so it acts as a coldplug client 2017-10-23 10:44:36 but if it finds all the stuff it is searching for, before the coldpluging is done, it will exit (i think) 2017-10-23 10:44:50 actually, i think it will wait til coldplug is done 2017-10-23 10:45:14 basically 2017-10-23 10:45:25 its a clodplug client designed to find the stuff alpine needs to boot 2017-10-23 10:45:34 then just coldplug everything with mdevd-coldplug, then look for your ovls :P 2017-10-23 10:45:52 which can be: configured root=/path/to/dev 2017-10-23 10:46:36 or a directory which has a .boot_repository file 2017-10-23 10:46:44 I'd be interested in mdevd-coldplug | mdevd benchmarks as opposed to mdev -s 2017-10-23 10:47:04 because mdev -s is pretty inefficient 2017-10-23 10:47:08 yes 2017-10-23 10:47:17 (even if it doesn't fork) 2017-10-23 10:54:31 kaniini: your provides=command patch to abuild will increase the size of the index 2017-10-23 10:54:46 im not sure how much and if its worth it 2017-10-23 10:56:05 i would guess only a handful of packages would need the provides=command 2017-10-23 11:29:52 which cron gets installed by default? 2017-10-23 11:30:47 ah, seems to be from busybox 2017-10-23 11:37:06 kaniini (or fabled): any idea what goes wrong here? $ docker run --rm -it alpine:edge apk upgrade --no-cache -a | tpaste 2017-10-23 11:37:06 http://tpaste.us/rqyV 2017-10-23 11:42:52 workaround is to upgrade busybox manually first: docker run --rm -it alpine:edge sh -c "apk add -U -u busybox && apk upgrade -a" 2017-10-23 11:47:42 rdutra: you may be interested in the workaround above ^^^ 2017-10-23 11:48:07 docker run --rm -it alpine:edge sh -c "apk add -U -u busybox && apk upgrade -a" 2017-10-23 11:48:21 ncopa: yeah, I got the same error from you (http://tpaste.us/rqyV) 2017-10-23 11:48:54 will use the workaround 2017-10-23 11:49:06 i think the problem is that apk will not autoselect a provides unless it is versioned 2017-10-23 11:49:14 so we need to manually satisfy the dep 2017-10-23 11:50:21 Shiz: do you what the status is on bootstrapping rust for x86, aarch64 and armhf? 2017-10-23 11:50:55 or even the upgrade to 1.21 for x86_64 2017-10-23 11:51:28 maybe jirutka knows? ^^^ 2017-10-23 11:56:28 someone sumitted a patch for an upgrade to 1.18 https://patchwork.alpinelinux.org/patch/3645/ 2017-10-23 11:57:01 ncopa, what are your current thoughts about gcc 7 for 3.7? in your release plans you stated that you want it there, but maybe after all it's better to do it in edge later, i.e. after releasing 3.7? 2017-10-23 11:57:45 i dont think we reach gcc 7 2017-10-23 11:58:28 at this point it will probably slow us down, so i think we better wait with it til after v3.7 2017-10-23 11:58:42 unless someone has patches for the upgrade ready, now 2017-10-23 12:01:40 nmeum: thanks for that reminder... 2017-10-23 12:02:43 I doubt it and even if, then such big changes aren't going smoothly as past experiences have shown, so sticking to gcc 6 seems like a better idea. there is also java thing that will need splitting and retaining from gcc 6, so such upgrade won't be overly quick endeavor. 2017-10-23 12:03:12 yes, i was thining of that java split thing 2017-10-23 12:03:26 if someone has a patch doing that already, then it may be worth the extra work 2017-10-23 12:03:55 but i dont think anybody has done that, so its better wait i think 2017-10-23 12:04:11 i will try get the arm builder for v3.7 bootstrapped today 2017-10-23 12:04:19 at least have it started 2017-10-23 12:04:43 I have a suggestion to post an update to this old thread of yours on ML: https://lists.alpinelinux.org/alpine-devel/5826.html 2017-10-23 12:04:44 hopefully all the builders for v3.7 will be up this week 2017-10-23 12:05:04 przemoc: good idea 2017-10-23 12:05:35 I have nothing of value to add to this discussion. However, I do hope both of you are in Europe. 2017-10-23 12:05:48 Becuase it's far too early in the US to be having this sort of conversation. 2017-10-23 12:05:59 Especially on a Monday 2017-10-23 12:06:06 yeah, we're in Europe 2017-10-23 12:06:09 most Alpine core devs are ;) 2017-10-23 12:06:17 Good. :) 2017-10-23 12:06:19 even not core devs :) 2017-10-23 12:06:22 ACTION sips coffee from Dallas. 2017-10-23 12:07:06 also, sleep schedule is like sex life or religious practice. It's bad taste to question people on theirs. :P 2017-10-23 12:07:58 heh 2017-10-23 12:09:08 in recent months I shifted to going sleep around 3:00 or even 4:00, and getting up aroung 9:00 or 10:00. earlier was more like 0:00-2:00 and I have to regain this sanity soon. 2017-10-23 12:40:55 ncopa: musl is not truly done. see http://www.openwall.com/lists/musl/2017/10/21/3 I mean it's done, but will be done better with next release, which this time rather won't take months. 2017-10-23 12:50:30 ncopa: you ate /run in cp line added to baselayout 2017-10-23 12:54:19 also what are your thoughts about making /var/run -> ../run instead of -> /run? what we have now doesn't properly support nested rootfses. 2017-10-23 12:58:33 +1 for relative symlinks where possible 2017-10-23 13:18:34 +1 2017-10-23 13:18:40 ncopa: i think it should be doable 2017-10-23 13:18:49 no work from me yet but i think i can look int oit 2017-10-23 13:19:00 my laptop is currently in for repairs so i can't do a whole lot for the next few days sadly 2017-10-23 13:19:15 currently on a loaner laptop on linux mint without root 2017-10-23 13:23:02 jirutka: relevant to your comment ^ 2017-10-23 13:23:09 i can take care of it but not until a few days or so 2017-10-23 13:31:07 przemoc: sorry about that. i suppose we want relative symlinks yes 2017-10-23 13:35:02 no problem, at least not for me. but you made yourself unaware of the mistake because of 2>/dev/null. ;) 2017-10-23 13:37:48 atm people who upgrade from older AL and didn't have the symlink already, are simply losing their /var/run content 2017-10-23 13:38:09 there shouldn't be anything of great importance, but you never know what people can come up with... 2017-10-23 15:28:46 ncopa: yes your analysis is correct. will work on a patch 2017-10-23 15:34:43 A slightly offtopic question, but any thoughts on how I asyncronysly parse the output of multiple Popen objects in python? 2017-10-23 15:35:26 I have the procs in a list when they complete. However I dont' wish to wait until all commands are complete. I'd like to process their output/returncode as they finish. 2017-10-23 15:41:22 asyncio 2017-10-23 15:42:52 Thanks. I'll dig at it. 2017-10-23 16:25:14 clandmeter: ah, so I saw the new log. In the zathura we fixed that by installing and starting xvfb. Shall we do the same here? 2017-10-23 16:37:43 Ganwell: if that works then ok. I never played with builders that need a running x server. 2017-10-23 16:38:25 I remember foxkit mention something about x on builders. 2017-10-23 16:39:49 I would like to eventually add something like options="check_xvfb" or such to mark packages needing X for check phase 2017-10-23 16:39:55 but today I am feeling unwell 2017-10-23 16:39:58 sorry 2017-10-23 17:01:15 NP let's discuss another time. Get well! 2017-10-23 18:18:46 ncopa: hmm, this is strange. 2017-10-23 19:56:16 foxkit: that would be great. here is what I did for zathura: https://git.alpinelinux.org/cgit/aports/tree/community/zathura/test.sh 2017-10-23 20:00:25 kaniini: it seems I saw an new log of girara, where the tests were already disabled :). But I still wonder how the test of girara passed when it was in testing. 2017-10-23 20:44:07 ncopa: i can’t reproduce that failure going 3.7 to edge 2017-10-23 20:44:13 or edge to edge 2017-10-23 20:44:57 but i am going to check the providers logic 2017-10-23 20:55:18 i find the bug sort of weird. might be an issue in apk 2017-10-23 20:55:32 i should sleep now 2017-10-23 22:00:02 not sure how relevant this is to the /bin/sh issue. but we've noted that apk-tools-static can't bootstrap aarch4 anymore (in pmbootstrap) 2017-10-23 22:00:16 apk.static -U --root /home/drebrez/.local/var/pmbootstrap/chroot_buildroot_aarch64 --cache-dir /home/drebrez/.local/var/pmbootstrap/cache_apk_aarch64 --initdb --arch aarch64 add alpine-base 2017-10-23 22:00:24 we run that, and then "apk fix" afterwards in qemu 2017-10-23 22:00:41 and now the apk fix doesn't work anymore, because it can't find sh 2017-10-23 22:01:00 https://github.com/postmarketOS/pmbootstrap/issues/811 2017-10-24 00:12:29 no 2017-10-24 00:12:36 it is a bug in pmOS 2017-10-24 00:12:51 the bug we are discussing has to do with upgrades 2017-10-24 00:13:08 you’re getting exit code 127 which means your qemu isn’t working right 2017-10-24 00:14:17 it’s running outside the qemu environment and the aarch64 code is failing to run 2017-10-24 08:45:33 my alpine talk at dockercon is published: https://dockercon.docker.com/watch/6nK1TVGjuTpFfnZNKEjCEr 2017-10-24 08:46:08 thanks for the link! 2017-10-24 08:46:54 <_ikke_> ncopa: \o/ 2017-10-24 08:47:16 oh no, some form to fill? 2017-10-24 08:47:19 <_ikke_> Ugh, you need to provide details in order to watch it? 2017-10-24 08:47:20 ridiculous 2017-10-24 08:47:21 <_ikke_> yeah 2017-10-24 08:47:22 seems like you have to sell your soul to watch it :-( 2017-10-24 08:47:56 <_ikke_> I'm called meh meh 2017-10-24 08:58:57 http://paste.przemoc.net/alpine/dockercon-europe-2017/small-simple-secure-alpine-linux-under-the-microscope.mp4 for those not willing to play games with forms 2017-10-24 09:00:10 I hope you don't mind, ncopa 2017-10-24 09:00:28 <_ikke_> przemoc: nice, was trying to do the same 2017-10-24 09:00:39 ofc. thanks! 2017-10-24 09:07:24 I think that alpinelinux.org site should have dedicated section simply called videos, where you would archive such stuff and keep it on alpine infra (as long as original video providers/uploaders are ok with that, that would require some asking, but even if they wouldn't be ok, they still should be ok at least with linking) 2017-10-24 09:08:27 video is worth thousand images (or more), so it's good to have something more than text and images on the site 2017-10-24 09:09:20 there was your fosdem talk and possibly some others I'm not aware of 2017-10-24 10:07:01 fabled: what is the behavior of aport@branch/repo? does it lock apk to only use that repo for the specified aport or can it also fallback to the non pinned repo lines? 2017-10-24 11:05:35 clandmeter, it can still use other repos 2017-10-24 11:09:13 ah ok. 2017-10-24 11:30:54 was unable to run qemu guest (v3.6.x) under al v3.6.x (host) 2017-10-24 11:31:22 did not go through the docs/changes throughly 2017-10-24 11:31:43 switched to alv3.3(host) and all works now 2017-10-24 11:31:56 guest is still 3.6.x 2017-10-24 11:32:19 przemoc: thanks for mp4 link 2017-10-24 11:33:52 wonder docker has objection to it, really dislike when they show unessary signs of infowareism 2017-10-24 11:40:35 as long as the link remains public only to #alpine* IRC channels, no one should really complain I think. 2017-10-24 11:45:46 also from al2.4 onward has show some rise in memory usages 2017-10-24 11:46:30 but should not be a concern as routers with 4mb rom are not longer made ;) 2017-10-24 11:46:52 +16mb ram 2017-10-24 11:49:17 reason is guest with 512Mb in qemu ran for months in v3.3, now have to assign 1G 2017-10-24 11:50:26 gtg, thanks 2017-10-24 12:56:21 i'd like to freeze abuild now 2017-10-24 12:56:26 im building the toolchain 2017-10-24 12:59:33 ok 2017-10-24 13:00:06 the last commit makes a big difference in how packages are built 2017-10-24 13:00:30 and will likely have an impact of the index size 2017-10-24 13:00:37 i dont know if we care about that 2017-10-24 13:01:32 conclusion with fabled was that the package discovery functionality was preferable vs index size increase 2017-10-24 13:01:40 kaniini: i wonder if its worth it. it will probably not be that many packages that needs the provides=/usr/bin/command 2017-10-24 13:01:44 ok 2017-10-24 13:02:05 plan is to change it once we have file listing indexes 2017-10-24 13:02:06 :) 2017-10-24 13:02:41 do we have an estimate how much apkindex size will increase? 2017-10-24 13:05:35 ~30% 2017-10-24 13:05:50 it’s not too bad 2017-10-24 13:07:26 its currently ~2MB 2017-10-24 13:07:32 uncompressed 2017-10-24 13:07:42 so ~2.6MB 2017-10-24 13:07:57 yes 2017-10-24 13:08:33 time will surely tell 2017-10-24 13:09:16 worst case would be 2.8-2.9 mb imo 2017-10-24 13:09:28 yeah 2017-10-24 13:09:39 it will slow down apk add slightly 2017-10-24 13:09:42 as previously mentioned plan is to move the command discovery to use file indices in apk3 2017-10-24 13:10:00 what i wonder is for what benefit 2017-10-24 13:10:13 i understand provides=/bin/sh 2017-10-24 13:10:22 and a handful others 2017-10-24 13:10:43 but I am sceptic to do it for everything 2017-10-24 13:10:48 even if that is convenient 2017-10-24 13:11:33 the main usecase for it is 2017-10-24 13:11:53 actually intended for users 2017-10-24 13:11:58 you can do 2017-10-24 13:12:07 apk search command:foo 2017-10-24 13:12:17 and it will find the package that contains it 2017-10-24 13:12:27 you can also apk add that directly if you want 2017-10-24 13:12:50 apk add /usr/bin/xscreensaver-getimage-file 2017-10-24 13:13:23 yes but that is kind of a silly example 2017-10-24 13:13:52 better example would be finding which package has say, pkill as an example 2017-10-24 13:14:01 kaniini: how will provides= help ? 2017-10-24 13:14:05 or finding dbus-launch 2017-10-24 13:14:31 there is a package you can apk add 2017-10-24 13:14:50 command-not-found that adds a shell hook that does the lookup for you 2017-10-24 13:14:50 thats my point, most of them are "silly", while a few are useful 2017-10-24 13:15:53 can that info not packaged as separate db(apk),i.e install if needed 2017-10-24 13:16:07 that is the plan for apk3 2017-10-24 13:16:53 i think that could be an online service 2017-10-24 13:17:22 i’m ok with an online fallback 2017-10-24 13:17:24 that info is going to be in ram in both way, or maybe add in modinfo squashfs, rename it with some generic name 2017-10-24 13:17:40 fabled_: do you have any opinion re provides=/usr/bin/command? 2017-10-24 13:18:19 that would allow us to carry the patch in adelie and still have alpine repos work 2017-10-24 13:18:35 ncopa, kaniini, i never thought it through. i think the technically correct place is the content database. but it's not there yet. 2017-10-24 13:18:36 ncopa: when is 3.7 scheduled? 2017-10-24 13:18:50 so that's probably the simplest 'workaround' to do it at this time 2017-10-24 13:18:59 but aports turbo does not have api right now 2017-10-24 13:19:00 kaniini: my objection is that, even if the feature is handy, its not critical, and it will increase bw usage for a very common operation (apk update) 2017-10-24 13:19:11 so... dunno 2017-10-24 13:19:25 i don’t know enough about lua to add an api 2017-10-24 13:19:56 "would allow us to carry the patch in adelie and still have alpine repos work" 2017-10-24 13:20:06 that is worth a bit i suppose 2017-10-24 13:20:22 if only I knew and liked lua enough, I'd help out 2017-10-24 13:22:18 the alpine repos would work either way, but command discovery wouldn’t work for them. e.g. community would be the one we would have interest in 2017-10-24 13:22:35 adelie is not based on al "Small. Simple. Secure" philosophy 2017-10-24 13:23:06 command discovery is based on simple part 2017-10-24 13:23:37 very common complaint on twitter is people not knowing what package has what and giving up 2017-10-24 13:25:02 while I agree that dedicated place would be somewhat better, I think that it will be a nice to be able to search for commands using apk instead of pkgs.a.o, even though apk3 is not ready yet 2017-10-24 13:25:35 if such api exists, that would be fine 2017-10-24 13:25:49 having that as optional install would be better, another option for ram based intalls that have cache enabled is, it only caches' and reads from it 2017-10-24 13:25:57 and not actually unpack it 2017-10-24 13:26:29 would want to have way of knowing what api service to use though 2017-10-24 13:26:54 and of course the command-not-found implementation would have to become written in something other than shell script most likely 2017-10-24 13:27:41 being able to do command search offline is quite nice, and definitely more robust 2017-10-24 13:28:07 i think the 600kb is worth it personally 2017-10-24 13:28:45 how many times APKINDEX is roughly downloaded from most often used server? 2017-10-24 13:29:07 the problem is that it is 600k for *everyone*, regardless if you use it or not 2017-10-24 13:29:09 that’s not a good argument 2017-10-24 13:29:35 i'd say the APKINDEX is downloaded around for every tome you do apk add 2017-10-24 13:29:43 every time* 2017-10-24 13:29:59 true 2017-10-24 13:30:35 well we can carry the patch in adelie 2017-10-24 13:30:42 and not have it in abuild 2017-10-24 13:30:49 upstream 2017-10-24 13:31:07 thats also not ideal solution 2017-10-24 13:31:08 hm 2017-10-24 13:31:33 I asked to estimate how much 600KB would add to daily total gigabytes served by server 2017-10-24 13:31:54 dunno 2017-10-24 13:31:56 in adelie command-not-found is planned to be a default feature 2017-10-24 13:32:08 hm 2017-10-24 13:32:57 przemoc: the 95th% increase would be minor at most, to the point where i would argue that if you’re concerned about it as a mirror admin you probably shouldn’t be hosting a mirror to begin with 2017-10-24 13:33:28 (and if you’re paying for transfer by the GB you shouldn’t be running any mirrors) 2017-10-24 13:33:53 kaniini: would this be a problem? http://tpaste.us/MMdk 2017-10-24 13:34:03 eg replace command:... with cmd:... 2017-10-24 13:34:18 no that is fine :) 2017-10-24 13:34:23 actually 2017-10-24 13:34:37 the bandwith overhead is not that much 2017-10-24 13:34:40 I was asking in a way to show that this 600 KB even in major scale wouldn't be a problem. I'm not against it, kaniini 2017-10-24 13:34:47 because its compressed 2017-10-24 13:35:22 that’s why i went with command yes 2017-10-24 13:35:40 non-english speakers may not know that cmd is an abbreviation 2017-10-24 13:36:31 thats a documentation issue i suppose 2017-10-24 13:36:48 generally speaking, UX is also important, and it's worth to make user's life easier. I literally hate when I have to go to pkgs.a.o to find something (no offence to pkgs.a.o creator) 2017-10-24 13:37:10 przemoc: sure, i was just saying that somebody buying infrastructure on per-GB basis would be a bad choice for somebody wanting to run a mirror 2017-10-24 13:37:37 i dont think command:foo vs cmd:foo makes big difference 2017-10-24 13:37:48 i kinda like cmd: better, because its shorter 2017-10-24 13:37:48 i'm fine with either 2017-10-24 13:38:01 to be honest I also like cmd better 2017-10-24 13:38:03 we use so: for libs and pc: for pkg-config 2017-10-24 13:38:35 works for me :) 2017-10-24 13:38:51 compression-wise, difference between command and cmd will be barely noticeable 2017-10-24 13:39:14 my plan is to leverage the apk3 content database and have 'virtual' providers for this in future 2017-10-24 13:39:24 I don't think we need command-not-found thing in AL, but being able to search for binaries will be definitely a good thing 2017-10-24 13:39:26 but apk3 isnt out yet :P 2017-10-24 13:39:50 i also have to admit 2017-10-24 13:39:53 przemoc: yes, in AL, my plan is to offer it, but not have it default enabled. you can `apk add command-not-found` if you want it 2017-10-24 13:39:59 i didnt look close enough to the patch initieally 2017-10-24 13:40:11 provides = cmd:foo 2017-10-24 13:40:15 is better than 2017-10-24 13:40:22 provides = /usr/bin/foo 2017-10-24 13:40:30 yes, it uses basenames 2017-10-24 13:40:42 makes sense to me 2017-10-24 13:41:00 for 2 reasons 2017-10-24 13:41:09 I'm not sure it's a good thing, I wouldn't mix these with virtual provides because there can be unwanted clashes 2017-10-24 13:41:09 1) it keeps APKINDEX impact down 2017-10-24 13:41:43 and you may not know/care if its in /usr/bin or /bin or /usr/sbin 2017-10-24 13:41:49 2) it allows us to search literally for "cmd:foo" 2017-10-24 13:42:01 which means that the search results have high confidence 2017-10-24 13:42:27 searching is an UI-thing, you could search even with full paths stored internally 2017-10-24 13:42:34 yes 2017-10-24 13:42:42 but not today 2017-10-24 13:42:52 because it depends on the content database spec 2017-10-24 13:42:58 which hasn't been implemented yet :P 2017-10-24 13:43:43 the initial command-not-found prototype we made used substring search 2017-10-24 13:43:50 it... wasn't horrible 2017-10-24 13:44:12 ok 2017-10-24 13:44:15 does it look into libexec things etc. now? don't remember the patch 2017-10-24 13:44:23 are there anything else we want into abuild before we freeze it? 2017-10-24 13:44:26 https://mastodon-dereferenced-org.s3-us-east-2.amazonaws.com/media_attachments/files/000/051/053/original/c8eb4d26e9faf61d.png 2017-10-24 13:44:29 looked like this 2017-10-24 13:45:08 przemoc: no. patch only scans dirs that are considered part of official $PATH :) 2017-10-24 13:46:13 the problem is finding commands such as, audtool or dbus-launch 2017-10-24 13:46:15 ok, fair enough, but won't help you finding some git-* commands for instance 2017-10-24 13:46:22 which aren't in packages that are named 2017-10-24 13:46:29 yes, that is true 2017-10-24 13:46:31 przemoc: i was thinking about the same 2017-10-24 13:46:35 git send-email 2017-10-24 13:46:41 it wont help with that 2017-10-24 13:46:44 however a package maintainer can opt into providing that 2017-10-24 13:46:50 by manually declaring it 2017-10-24 13:46:51 true 2017-10-24 13:48:02 przemoc: but yes, command-not-found is not likely to ever be a default feature in alpine directly. i am pretty sure it would give some contributors a stroke if they encountered it, for example 2017-10-24 13:48:04 ;p 2017-10-24 13:48:43 sure, we're not talking about command-not-found per se, but about command searching features 2017-10-24 13:51:56 gtg, would got check local market if ram prices have come down ;) 2017-10-24 13:52:05 go check* 2017-10-24 13:53:25 ram prices always going down 2017-10-24 13:53:56 not in Poland, I still regret that I didn't bought new desktop computer in 2013 2017-10-24 13:55:33 the more I think about cmd: thing, the more it seems that full path would be better in cmd:, but it would require improving apk search cmd: to allow providing basename alone 2017-10-24 13:56:06 but maybe as long as we completely abandon idea of provides from libexec, then it remains kind of ok 2017-10-24 13:57:18 and how about priority right now with clashing providers? 2017-10-24 13:58:50 core team has to hand-pick and explicitly add provides=cmd: with higher priority (don't remember the syntax) to the pkgs that provide better (from AL view) version of provided command? 2017-10-24 14:00:56 clashing providers only applies when `apk add cmd:foo` 2017-10-24 14:01:08 yeah, I'm talking about that 2017-10-24 14:01:47 right now there is no solution to clashing providers. provides_priority isn't yet actually a thing from APK end. 2017-10-24 14:05:32 ok, it's not worth it at cmd: level after all, I guess, but for "real" virtual packages, without cmd: prefix, it will be good to have. for instance to allow transition from bb awk to mawk, after introducing proper awk provides in bb, gawk and mawk (when it will hit AL) that is. 2017-10-24 14:25:48 kaniini: that 600kb means per providers ? 2017-10-24 14:26:19 meanin one can add multiple servers for /main 2017-10-24 14:27:27 anyway, it might be possible doing the code using shell,jq,jo..+usual busybox tools 2017-10-24 14:27:33 knoppix: 600kb is worst-case for main based on eyeballing it. probably way less than that in reality 2017-10-24 14:27:39 knoppix: and it's per index 2017-10-24 14:28:17 knoppix: and the fallback will work how, for third-party repos? 2017-10-24 17:24:33 <_ikke_> Anyone being able to take a look at https://github.com/alpinelinux/aports/pull/2433 ? There were changes requested, which I've handled 2017-10-24 19:55:06 hey, could someone please merge my patch into aports, i cannot send it via email because my fucked up thunderbird is always messing up the formating 2017-10-24 19:55:07 https://pastebin.com/raw/yLYS9VYx 2017-10-24 19:55:09 thanks! 2017-10-24 19:57:42 <_ikke_> leo-unglaub: and I suppose github is not an option? 2017-10-24 19:58:01 _ikke_: is alpine on github? 2017-10-24 19:58:07 <_ikke_> leo-unglaub: yes 2017-10-24 19:58:47 <_ikke_> https://github.com/alpinelinux/aports 2017-10-24 19:59:31 <_ikke_> The other option would to use git send-email as the mta 2017-10-24 19:59:56 git send-email segfaults *g* why do you think i tryed thudnerbird 2017-10-24 20:00:04 <_ikke_> segfaults? 2017-10-24 20:00:05 git has a regression in the last version that i am trying to find 2017-10-24 20:00:08 <_ikke_> it's a perl script 2017-10-24 20:00:29 <_ikke_> Is that on alpine? 2017-10-24 20:00:37 yes, perl and git crash 2017-10-24 20:00:42 i have two core dumps 2017-10-24 20:02:05 do you have perl modules compiled against a different version of perl than the currently installed one? 2017-10-24 20:02:06 i normally dont use github, the order was "fork, edit, push, pull request, delete fork" correct? 2017-10-24 20:02:25 <_ikke_> yeah, easiest if you have a separate branch for your PR 2017-10-24 20:02:53 is there a naming convetion in alpine for the branch? 2017-10-24 20:02:57 <_ikke_> branch, commit, fork, add remote, push, pr 2017-10-24 20:03:14 <_ikke_> Not that I'm aware of 2017-10-24 20:03:50 <_ikke_> leo-unglaub: I think it's something related to what danieli mentioned 2017-10-24 20:04:05 what? the segfault? 2017-10-24 20:04:13 yes 2017-10-24 20:04:14 <_ikke_> yeah 2017-10-24 20:04:24 perl modules have to be compiled against the currently installed perl version to work 2017-10-24 20:04:33 or so i've picked up 2017-10-24 20:04:48 i doubt that, because i am currently on OpenBSD ... i changed something in my malloc and made it more strict and now stuff crashed all the time 2017-10-24 20:05:00 i really should stop doing this stuff on my office computer *g* 2017-10-24 20:05:02 no idea, you'd have to debug it to know 2017-10-24 20:05:08 also, eeeh, just use master 2017-10-24 20:13:02 so, i hope this pull request is okay 2017-10-24 20:13:09 i never do this stuff on github 2017-10-24 20:13:20 do people do this for every patch they submit? 2017-10-24 20:13:43 <_ikke_> every patch series, yes 2017-10-24 20:14:19 uff, that is a lot of work ... they fork every time? boah, they all must have tousands of outdated repos laying around 2017-10-24 20:14:26 <_ikke_> No 2017-10-24 20:14:29 <_ikke_> You keep a fork 2017-10-24 20:14:34 <_ikke_> And don't delete it 2017-10-24 20:15:22 ah, do people set the original as another remote and merge changes locally? 2017-10-24 20:15:48 <_ikke_> leo-unglaub: Upstream is doing the merging, but yes, they merge locally 2017-10-24 20:17:08 alright, thanks! 2017-10-24 20:17:18 as soon as you have merged it i can delete the fork 2017-10-24 20:17:44 <_ikke_> If you never intend to use it again, you can delete it. But otherwise, I'd keep it around 2017-10-24 20:18:14 when i keep it around, how do i get it up to all the latest changes from the original? 2017-10-24 20:18:45 <_ikke_> leo-unglaub: You only need to make sure your branch is based on the latest upstream master 2017-10-24 20:19:53 <_ikke_> Let's say your remote for upstream is called upstream: git fetch upstream && git checkout -b patch-branch upstream/master 2017-10-24 20:20:16 <_ikke_> Then you can push you patch branch to your fork, and make the PR 2017-10-24 20:20:32 ah, i see 2017-10-24 20:20:41 thanks for explaining it to an old fart like me! 2017-10-24 20:21:45 <_ikke_> Usually jirutka is taking care of the github PRs 2017-10-24 20:32:14 foxkit: hey did you have some time to check the PR out again? 2017-10-25 09:57:59 Hi. I'd like to edit a wiki page, but my account is less than 5h old. Who administers it, so that I can contact them? 2017-10-25 10:00:42 zoot_io: iirc clandmeter 2017-10-25 10:02:33 zoot_io: afaik you can edit, but you cannot add urls 2017-10-25 10:02:37 ACTION hides 2017-10-25 10:02:45 lol 2017-10-25 10:02:48 i c u 2017-10-25 10:02:51 if you edit a page with urls isnt that an issue? 2017-10-25 10:03:04 yes, it's the URL issue 2017-10-25 10:03:44 clandmeter: are you just shy, or don't want further admin? ;-) 2017-10-25 10:04:01 it was not clandmeter who did it 2017-10-25 10:04:15 if its broken its not me. 2017-10-25 10:04:19 ;-) 2017-10-25 10:04:35 but we can maybe enable you. 2017-10-25 10:05:06 Thanks. clandmeter: my username is 'zoot' 2017-10-25 10:05:19 you are zoot? 2017-10-25 10:05:28 Yup 2017-10-25 10:05:33 on the wiki 2017-10-25 10:07:20 is it just me or is networking in qemu broken since the latest upgrade to 2.10.1? The VM is still able to retreive an IPv4 address using DHCP and can reach its default route, but the default route doesn't seem to route any packets (I am running qemu with `-net nic -net user`) 2017-10-25 10:08:27 ncopa: i have no idea what to change to make you trusted. 2017-10-25 10:08:38 make him... 2017-10-25 10:09:08 i dont know either 2017-10-25 10:09:09 mediawiki is such a joy to work with. 2017-10-25 10:09:33 would be nice if we could trust users when they ask us on irc. 2017-10-25 10:10:50 mediawiki bleeeeh 2017-10-25 10:13:26 i give up, this interface is completely useless. 2017-10-25 10:14:33 clandmeter: I concur - just searched the mediawiki docs on permissions ... it would put anyone off! 2017-10-25 10:15:04 at least they can (hopefully) solve complex cases! ;) 2017-10-25 10:15:06 Shall I just set a reminder to edit in 5 hours time? Or will I be blocked by the next hidden editing policy? 2017-10-25 10:15:12 im really sorry. 2017-10-25 10:15:25 zoot_io: i dont think so. 2017-10-25 10:15:26 should work 2017-10-25 10:15:43 clandmeter: there was some attempt from you to do some kind of wiki other way: https://github.com/alpinelinux/alpine-wiki 2017-10-25 10:15:54 what was the main idea behind it and where it was headed? 2017-10-25 10:16:00 przemoc: yes it is. 2017-10-25 10:16:02 its a start 2017-10-25 10:16:08 but it needs a lot of work 2017-10-25 10:16:24 somebody needs to start working on it. 2017-10-25 10:16:29 docs.a.o 2017-10-25 10:17:20 I think danieli mentioned earlier he would look into it. but it seems he is also too busy... 2017-10-25 10:17:47 wiki? 2017-10-25 10:17:52 oh the migration and docs, yeah 2017-10-25 10:18:03 I would start with renaming repository, it's confusing as it is now 2017-10-25 10:18:06 clamdmeter: Ok, I'll try editing later again. Contributing to OSS projects should be easier than this. We all know how much time is wasted by out of date info, or inadequate info. So, I always try to add where I can. 2017-10-25 10:18:07 i've started some of it offline, but i don't really have access anywhere 2017-10-25 10:18:46 clandmeter: thanks for trying. bye for now 2017-10-25 10:18:52 do you want to have access to https://github.com/alpinelinux/alpine-wiki? 2017-10-25 10:19:11 could it be renamed to alpine-docs? 2017-10-25 10:19:23 sure 2017-10-25 10:19:57 I think it would better suit it, but not sure if everyone agrees 2017-10-25 10:20:03 the thing is, is it going to be docs or wiki in the future. 2017-10-25 10:20:16 we were thinking to put "tips and tricks" on the wiki 2017-10-25 10:20:19 and official documentation on docs 2017-10-25 10:20:51 but then we still have the mediawiki disaster like now. 2017-10-25 10:21:11 as these docs.a.o won't be editable by anyone, as it is worked via github, it's less of a typical wiki 2017-10-25 10:21:30 clandmeter: thanks, access to https://github.com/alpinelinux/alpine-wiki would be good. I see there's much to be added. Will this be the new location of the official Wiki instead of the mediawiki? 2017-10-25 10:21:33 well you can send pr's 2017-10-25 10:21:44 My github username is zoot 2017-10-25 10:21:51 ok, cool, thanks 2017-10-25 10:21:55 <_ikke_> The difference is that it can be reviewed through PRs 2017-10-25 10:22:02 <_ikke_> allowing to check for accuracy 2017-10-25 10:22:36 we could also do auto commit on pr's with some CI 2017-10-25 10:22:36 I know I can, but my point is that typical wikis are more straight forward, therefore it's another reason to not name it wiki, and if it aims to be the official docs kind of thing in future, even more so 2017-10-25 10:22:51 that's bad idea 2017-10-25 10:23:14 why? isnt that how the wiki works now? 2017-10-25 10:23:48 normal wikis - yes, but if it means to be official AL docs, it shouldn't work that way IMHO 2017-10-25 10:24:10 then im not catching your point 2017-10-25 10:24:26 we were disucssion issues with wiki and moved to alpine-wiki repo 2017-10-25 10:25:09 what it aims to be? another wiki? or official AL docs site? 2017-10-25 10:26:24 my initial idea was to move wiki to it, thats why its named like that. 2017-10-25 10:26:56 and add CI to manage contributions send via PR 2017-10-25 10:28:18 so subdomain should be changed to wiki2. then, and replace wiki. only when everything useful and correct will be moved from wiki. 2017-10-25 10:28:47 but to be honest I think that AL lacks some good official documentation, not another wiki edited by anyone 2017-10-25 10:29:02 that's what docs.a.o should be reserved for 2017-10-25 10:29:23 absolutely, i dont disagree. 2017-10-25 10:29:32 przemoc: +1 2017-10-25 10:30:12 so we have 2 problems. 1 need proper docs, 2 need proper wiki. 2017-10-25 10:30:45 I believe, if we have proper docs we don't need a wiki 2017-10-25 10:31:30 I partially agree, but docs don't cover all cases and there are always users showing some interesting use cases, so wiki is fine to have, but it's very much secondary thing 2017-10-25 10:32:26 yes they are different animals. i dont think docs can really replace wiki. 2017-10-25 10:32:43 i dont think we want everybody to just modify docs 2017-10-25 10:33:22 but we dont want to prevent users to provide information. 2017-10-25 10:33:25 exactly, that's why I didn't like autocommit thing at first, because seeing docs.a.o subdomain I thought it aims to be more docs than wiki thing 2017-10-25 10:33:29 Before I go, you might want to consider https://readthedocs.org 2017-10-25 10:33:50 <_ikke_> We started to use sphinx with a readthedocs theme 2017-10-25 10:34:10 <_ikke_> If you want to self-host, that's a nice alternative to readthedocs 2017-10-25 10:34:25 readthedocs is nice, but AL will definitely self-host 2017-10-25 10:35:51 we could simply copy the repo and use alpine-docs and alpine-wiki 2017-10-25 10:36:22 but im open to any good alternative. 2017-10-25 10:36:31 good docs have to be written in a way that can be exported not only to HTML pages, but also single PDF file. personally I don't like markdown for such matters, because it doesn't allow to express all the formatting you may want. reStructuredText is much better at this, even if a bit more verbose, but in such cases I prefer versatility than ease of writing. 2017-10-25 10:37:04 but there were strong opponents to rST here 2017-10-25 10:37:16 <_ikke_> sphinx supports rst 2017-10-25 10:37:24 <_ikke_> and I agree that it's a nice format for this 2017-10-25 10:38:09 yeah, sphinx is ok 2017-10-25 10:39:57 asciidoc seems also an interesting option (i know some ppl here prefer it) 2017-10-25 10:40:13 <_ikke_> asciidoc is what git uses 2017-10-25 10:41:17 (mostly those that are rST opponents) 2017-10-25 10:51:39 a minor thing is that I also prefer to depend on python ecosystem (sphinx) than ruby one (asciidoctor). kernel also uses rST and sphinx by the way nowadays: https://lwn.net/Articles/692704/ 2017-10-25 17:32:58 foxkit: I wonder how you managed to package qt5-qtquickcontrols2-dev for Adélie... for me it just complains when trying to split that package. however, it seems to be required for building kirigami2 2017-10-25 17:45:34 jirutka: in your reply to my mail on -devel@ you omitted ncopa@ and -devel@ in CC 2017-10-25 18:02:10 BTW what is this x.py in rust? they no longer use make? 2017-10-25 18:16:59 PureTryOut[m]: ? I used the other qt5 packages as a template 2017-10-25 18:17:08 I believe I used qt-declarative's apkbuild and changed what was relevant 2017-10-25 18:17:17 er qt5-qtdeclarative* 2017-10-25 18:17:29 and it is required for kirigami2 2017-10-25 18:20:07 ACTION sent a long message: PureTryOut[m]_2017-10-25_18:20:06.txt  2017-10-25 18:20:15 <_ikke_> :-/ 2017-10-25 18:20:21 not sure why it even tries to cd there 2017-10-25 18:20:53 `$pkgname-doc` is being made without problems... why must `$pkgname-dev` be different 😒 2017-10-25 18:23:01 ACTION sent a long message: PureTryOut[m]_2017-10-25_18:23:00.txt  2017-10-25 18:23:05 the apkbuild ^ I don't see much wrong 2017-10-25 18:23:38 <_ikke_> hmm, line 2528 seems to be almost at the end 2017-10-25 18:23:56 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n2528 2017-10-25 18:26:08 well it tries to cd to a directory, which in fact does not exist. I'm just not sure why it tries to cd there. it's a subpackage, not the main package... 2017-10-25 18:26:29 PureTryOut[m]: so what happens is default_dev will make a $subpkgdir (which is what it tries to cd to) 2017-10-25 18:26:35 I'm guessing if there were actually any `-dev` files, that directory would exist 2017-10-25 18:26:42 PureTryOut[m]: but default_dev isn't seeing any files to move to $subpkgdir, so $subpkgdir isn't created 2017-10-25 18:26:52 so why does it build fine for you on Adélie then? 2017-10-25 18:27:31 https://code.foxkit.us/adelie/packages/blob/master/user/qt5-qtquickcontrols2/APKBUILD#L14 2017-10-25 18:30:12 dunno. we are using 5.9.1, maybe that matters 2017-10-25 18:31:15 we also don't have a -doc subpackage 2017-10-25 18:31:54 PureTryOut[m]: also, sorry for not being able to review again.. I fell /super/ ill Monday 2017-10-25 18:32:25 waking up every half hour to emit, you know, the fun stuff >.< 2017-10-25 18:32:35 it was dreadful 2017-10-25 18:32:48 now I'm feeling better but have work stuff to catch up on.. 2017-10-25 18:33:03 I haven't even managed to merge musl 1.1.17 into Adélie yet 2017-10-25 18:33:16 ACTION tries to compile 5.9.1 instead 2017-10-25 18:33:40 aah darn dude. well, get better soon! 2017-10-25 18:33:54 also, 5.9.1 did not help 2017-10-25 18:36:06 wait, our sources are different... 2017-10-25 18:37:36 well, that's embarassing 2017-10-25 18:37:45 I might've used qtquickcontrols instead of qtquickcontrols2 all this time... 2017-10-25 18:38:36 aaannndddd.... that did the job. ignore me 2017-10-25 18:39:08 <_ikke_> ACTION whistles 2017-10-25 18:39:11 haha, reminds me of when I got plasma-desktop and plasma-workspace confused and couldn't for the life of me figure out why a patch wasn't applying 2017-10-25 18:42:29 przemoc: jirutkas response was about -O2 -Os? 2017-10-25 18:43:21 yes 2017-10-25 18:43:44 and i know you are right in what you write 2017-10-25 18:43:57 i guess i just needed someone to say it out loud 2017-10-25 18:44:03 im gonna answer 2017-10-25 18:45:11 another solution is to just mute jirutka on github 2017-10-25 18:45:20 i found that made my github experience more pleasant 2017-10-25 18:45:46 I didn't want to resend his mail w/o his consent, as I'm not sure if recipients were omitted by accident or not 2017-10-25 18:46:25 yeah 2017-10-25 18:46:47 it looks like it was an accident 2017-10-25 18:46:51 I think 2017-10-25 18:46:57 but don't want to guess 2017-10-25 18:46:57 (i only bring that up because if you dislike his responses you can just mute him) 2017-10-25 18:48:03 the response is ok-ish, I just don't agree with reasoning, but would need to share the mail 2017-10-25 18:48:29 kaniini: i like jirutka. he is picky and pedantic and i think that it is good that someone on the team is that, and pull in that direction 2017-10-25 18:48:43 and he is not afraid to say out loud when he disagrees 2017-10-25 18:48:51 i appreciate that quality 2017-10-25 18:49:30 i just wish he could be more considerate, specially with new people 2017-10-25 18:53:44 i was just pointing out that if you do not like his responses, you can mute him on github :) 2017-10-25 18:56:33 foxkit: well, I've updated my PR with qt5-qtquickcontrols**2** and Kirigami2 😆 2017-10-25 19:06:22 ACTION sent a long message: PureTryOut[m]_2017-10-25_19:06:22.txt  2017-10-25 19:07:29 i would ask you to pastebin, but then i remembered matrix does it automatically. 2017-10-25 19:07:55 (for the sake of IRC users) 2017-10-25 19:09:10 foxkit: PureTryOut my question i suppose is what is the merge plan for adelie / pmOS then 2017-10-25 19:10:09 well, in terms of what we're merging, everything that's not specific to a device. for example we have device specific meta and kernel packages, which make no sense to have in Alpine really 2017-10-25 19:10:43 i meant specifically who is maintaining what in alpine 2017-10-25 19:10:51 or is it going to be a shared effort 2017-10-25 19:11:03 shared I guess. although I'm probably the one going to maintain KDE 2017-10-25 19:11:38 the one that contributes the packages will maintain it in theory, but if someone else finds a package is outdated they can just make a PR to update it 2017-10-25 20:12:28 clandmeter: I think mediawikis aren't that bad actually, once you get used to the syntax. It does have some nice features, such as templates and tables you can sort and most Linux distributions use it (which is good for new users coming from other distros). But if you really want to transition to markdown, you can somewhat convert the wiki pages with pandoc and actually talk to mediawiki via git (!). Here are 2017-10-25 20:12:29 notes from when I migrated the pmOS wiki from github (markdown) to mediawiki format, it should be possible to simply reverse that: https://gist.github.com/ollieparanoid/6ac9122e31258a7ab8498a362b249fa8 2017-10-25 20:12:30 clandmeter: regarding the "annoying" 5 hours before making the first edit (which is a lot better than what we had previously, which was no explanation when you would be able to edit links), an alternative would be a mediawiki extension that approves all edits: https://bugs.alpinelinux.org/issues/6774#note-2 2017-10-25 20:12:38 *first edit with links 2017-10-25 20:13:26 ollieparanoid: hi 2017-10-25 20:13:32 kaniini: would you prefer if specific persons maintained specific packages? 2017-10-25 20:13:37 hi :) 2017-10-25 20:14:17 well im not against mediawiki as wiki, but the management interface is... 2017-10-25 20:15:18 i dont use it that often, so thats probably the main reason. 2017-10-25 20:15:42 an alternative approach could be documenting the important steps, such as how to unlock someone 2017-10-25 20:15:52 (...on a wiki page? :p) 2017-10-25 20:15:54 <_ikke_> I wonder how wikipedia handles spam 2017-10-25 20:16:20 _ikke_: they require changes to be approved 2017-10-25 20:16:29 but there's probably a lot more to it 2017-10-25 20:16:51 ollieparanoid: right now alpine policy is that one person serves as PoC for each package. *personally* i am on board for acknowledging that packages are *actually team maintained*, but right now setting Maintainer to a non-person is an immediate rejection 2017-10-25 20:18:13 in adelie, team maintenance is okay, but the maintainer field needs to be set to an appropriate PoC for the team 2017-10-25 20:18:13 then I would say the person from pmOS who upstreams the package should take the responsibility of maintaining the package 2017-10-25 20:20:30 my goal is to demonstrate that team maintenance will not kill people's kittens, once that is done, will push for the necessary policy changes at alpine 2017-10-25 20:20:30 ok, good to know 2017-10-25 20:20:32 ;) 2017-10-25 20:24:17 yeah, that sounds nice! 2017-10-25 20:25:53 maybe you should hae a way to "approve" certain teams? or a way for teams to sign up? 2017-10-25 20:28:08 what do you mean 2017-10-25 20:28:12 you literally just set Maintainer: to a mailing list 2017-10-25 20:28:18 or bug tracker 2017-10-25 20:32:36 when thinking about it, teams could mean faster responses to outdated packages/other issues. because when there's only one maintainer and that person is sick or on vacation, no one might answer the mail. with a mailing list or even bugtracker that hopefully doesn't happen 2017-10-25 20:32:39 at least more people see it 2017-10-25 20:33:39 so yeah that would make sense for postmarketOS in the long run in my opinion. 2017-10-25 20:43:50 kaniini: that is something that really has not been discussed yet 2017-10-25 20:43:55 and it probably should be 2017-10-25 20:45:10 for KF5, it makes sense for it to be a shared effort 2017-10-25 20:45:17 for Plasma itself, it depends on what Alpine wants 2017-10-25 20:46:03 Adélie is focusing very strongly on LTS versions and regression testing between bumps and the like. I just spent two days making kscreenlocker 5.8.8 work without SUID for instance. 2017-10-25 20:46:38 the pmOS people (at least from what I have gathered from talking with PureTryOut[m]; he can clarify if I am wrong) want the current edge release which is much less stable 2017-10-25 20:47:22 for instance, the 5.11.90 alpha candidate that just dropped broke wayland sessions on gles2 (so i965 and nouveau; iirc amdgpu uses egl) 2017-10-25 20:47:28 <_ikke_> ACTION tries to keep clean who is contributing to what project :P 2017-10-25 20:47:32 <_ikke_> clear* 2017-10-25 20:47:37 we do indeed, as we want Plasma Mobile which is all cutting edge still 2017-10-25 20:47:59 _ikke_: ollieparanoid and I contribute to postmarketOS, foxkit to Adélie 2017-10-25 20:48:04 _ikke_: I have been contributing to Alpine off and on since 2011. I am also the project lead of Adélie. PureTryOut[m] is the lead of pmOS iirc 2017-10-25 20:48:19 ha no not the lead, that's ollieparanoid 2017-10-25 20:48:36 _ikke_: I also contribute to KDE (and I have recently been granted commit to plasma repos) 2017-10-25 20:50:07 detailed CV available on request :P 2017-10-25 20:50:36 I'd still recommend to package both the LTS version of kde and the bleeding edge version we need, with a -lts or -current suffix 2017-10-25 20:51:02 but of course it depends on what Alpine wants :) 2017-10-25 20:51:41 I think clandmeter was the desktop person last I checked. do you have a comment? :) 2017-10-25 20:51:52 yeah I'd go with a suffix for stable as well 2017-10-25 20:51:55 foxkit: awesome that Adelie is testing it so much! 2017-10-25 20:52:39 kaniini is also a desktop person I think, because he packaged gnome3 2017-10-25 20:52:50 ollieparanoid[m]: yeah, it has been a very long road to get here. we just recently celebrated two years anniversary. still no 1.0 to show. but of course, it didn't help the time having to switch from gentoo fork to alpine fork haha 2017-10-25 20:53:28 my next Big Project is sddm on consolekit2... 2017-10-25 20:53:47 I managed to get it to come up and even create a seat, but it refuses to spawn X :/ 2017-10-25 20:53:56 then I fell ill 2017-10-25 20:56:18 the lts version sounds more appealing 2017-10-25 20:57:05 foxkit: well, it should be easier than all of kde. great job! 2017-10-25 20:58:08 I had the benefit of KDE already being portable to FreeBSD and therefore not dependent on logind/systemd 2017-10-25 20:58:15 sddm /is/ dependent on logind 2017-10-25 20:58:22 they "kind of tried" to make it less so with 0.16.0 2017-10-25 20:58:24 but it broke badly 2017-10-25 20:58:37 I really should push what changes I have so far 2017-10-25 20:59:47 the bleeding edge can run on both mobile and desktop? 2017-10-25 21:00:38 clandmeter: questionably. the next LTS branch will be in February 2018 I believe; that will have all the 5.10/5.11 mobile stuff in it. 2017-10-25 21:00:50 but I don't know if the mobile support will be *finished* by 5.12.0 or not 2017-10-25 21:01:11 in adelie we plan to ship the LTS 2017-10-25 21:01:29 https://community.kde.org/Schedules/Plasma_5 yeah January 30th is 5.12 LTS 2017-10-25 21:01:42 kaniini: you also work on Adélie? 2017-10-25 21:01:53 LTS will probably be most suitable for regular alpine users. 2017-10-25 21:02:05 PureTryOut: yes 2017-10-25 21:02:19 anyway 2017-10-25 21:02:20 aah ok 2017-10-25 21:02:25 people keep asking in #musl about who 2017-10-25 21:02:38 so maybe i should actually code this securewho thing i have in my head 2017-10-25 21:03:01 people don't care about utmp, they care about who 2017-10-25 21:03:01 ;) 2017-10-25 21:03:28 I additionally care about `w` because that gives the command 2017-10-25 21:04:04 clandmeter: is there any chance Alpine could provide both? I completely agree that LTS would be more suitable for regular Alpine users. it looks like the mobile stuff isn't going to be stable any time soon 2017-10-25 21:04:08 w doesn't use utmp to get the command 2017-10-25 21:04:10 thankfully 2017-10-25 21:04:11 :) 2017-10-25 21:05:17 kaniini: right, but I was just saying, it would be cool to have `w` work as well. 2017-10-25 21:06:31 ollieparanoid[m]: that's a lot of duplication (somewhere around 38 packages per https://www.kde.org/info/plasma-5.8.7.php ) 2017-10-25 21:06:39 and a lot of maintenance burden 2017-10-25 21:07:10 and then you have the users that get confused and mix the two... 2017-10-25 21:07:40 yes, duplication and maintenance are the main issues here. 2017-10-25 21:09:30 for such decision we should discus it on the ML. ncopa will have a better opinion about it. 2017-10-25 21:09:53 we plan to offer PPA type things for adelie, it is possible we could share this infrastructure with the pmOS team to allow them to ship latest KDE in a separate repo 2017-10-25 21:10:46 kaniini: that would be awesome! I've just written a mail about that topic to alpine-infra yesterday: https://lists.alpinelinux.org/alpine-infra/0184.html 2017-10-25 21:10:53 kaniini: can you share securewho ideas? I was wondering a little about how to implement it without utmp 2017-10-25 21:10:57 the main problem we're having is the time it takes to compile everything. I'd like to ship the latest version in a separate repo, but compiling for anything other than x86_64 takes ages. last time armhf took a minimum of 5 hours 2017-10-25 21:11:29 haha 2017-10-25 21:11:59 try compiling LLVM 4 on a 2 GB RAM, 1.25 GHz PowerPC G4 from 2003 2017-10-25 21:12:04 nine hours 2017-10-25 21:12:28 just for it to OOM at the very last link phase 2017-10-25 21:12:44 skarnet: essentially idea involves using a setuid wrapper to handle utmp writes similar to utempter 2017-10-25 21:12:59 I'm thinking I will need to turn off debug symbols entirely for LLVM on PowerPC. 2017-10-25 21:13:01 skarnet: the utmp file would still be used, but we would define our own format for it 2017-10-25 21:13:22 foxkit: ccache to the rescue! 2017-10-25 21:13:23 kaniini: how about a utmpd performing all the writes, accessed by a Unix socket, to avoid setuid? 2017-10-25 21:13:25 kaniini: libutx is MIT license if you want a basis :) 2017-10-25 21:13:34 also swap 2017-10-25 21:13:41 skarnet: yes, that also is another option i am thinking about 2017-10-25 21:13:54 skarnet: sounds like you have some ideas, look forward to s6-who ;P 2017-10-25 21:13:59 ollieparanoid[m]: the kernel it is running has swap disabled (all of my custom kernels do) 2017-10-25 21:14:15 it required a custom kernel because debian's ppc kernel is broken 2017-10-25 21:14:21 it's just general design ideas, I don't know the details of utmp 2017-10-25 21:14:22 and they know it, and they have been fighting for two years about what to do about it 2017-10-25 21:14:29 so I gave up and made my own :) 2017-10-25 21:14:36 but I'm ready to discuss formats and stuff people need from utmp 2017-10-25 21:14:52 ollieparanoid: which arch's do you target? 2017-10-25 21:15:07 speaking of arches 2017-10-25 21:15:31 clandmeter: armhf and aarch64 mostly, but also x86_64 for testing stuff (e.g. running in qemu) 2017-10-25 21:15:49 how much pain would it be to add ppc32 to alpine? or is that not a target? if it isn't, that's totally fine with me, but if it is, we (Adélie) could probably have a PR ready in an hour or less adding ppc32 support to all of alpine main/ (afaik) 2017-10-25 21:16:13 haven't tackled community yet. probably should before actually pulling the trigger. 2017-10-25 21:16:16 raiders of the lost arch, starring Indie Anna Fox 2017-10-25 21:16:23 <_ikke_> lol 2017-10-25 21:16:27 skarnet: omg, hahaha <3 2017-10-25 21:16:37 32-bit power is actually still relevant 2017-10-25 21:16:51 there's embedded powerpc cpus that we could support with it :P 2017-10-25 21:16:57 ollieparanoid: well and possible x86_64 tablets in the future I guess 2017-10-25 21:17:02 yes, the RAD4xx series is what I am thinking of 2017-10-25 21:17:10 right 2017-10-25 21:17:40 ppc32 is possible to build in chroot in ppc64 as long as the kernel is configured properly. 2017-10-25 21:17:48 but it needs to match endianness, so it would need to be ppc64 BE 2017-10-25 21:18:07 I'm not sure if any ppc32le hardware exists in the wild 2017-10-25 21:18:42 it looks like some very old cisco appliances are ppc32le 2017-10-25 21:19:18 armhf is actually a bit of a headache, the thunderx platform doesnt support it. 2017-10-25 21:19:28 lol 2017-10-25 21:19:31 we tried to buy 2017-10-25 21:19:33 a thunderx 2017-10-25 21:19:40 and they wanted $6000 2017-10-25 21:19:56 thunderx performance isn't worth 6k 2017-10-25 21:20:08 it isnt but its easy to get. 2017-10-25 21:21:03 what alternatives are there for armhf other than xgene? 2017-10-25 21:21:36 we don't have any decent arm hardware 2017-10-25 21:21:46 arm is ... not yet a priority for us with adelie 2017-10-25 21:21:52 its the reason i got a second xgene board just to make sure we can support it a bit longer. 2017-10-25 21:22:17 if somebody wants to pay us for arm support, then we will just go buy a thunderx 2017-10-25 21:22:50 but thats only aarch64 iirc 2017-10-25 21:22:53 but pretty sure big iron arm is a pipe dream 2017-10-25 21:22:54 so not holding breath on it 2017-10-25 21:23:04 can't you compile armhf on aarch64? 2017-10-25 21:23:16 like x86 on x86_64 2017-10-25 21:23:17 it depends on the cpu 2017-10-25 21:23:20 only if it supports it 2017-10-25 21:23:24 thunderx is aarch64 only 2017-10-25 21:23:28 xgene is both 2017-10-25 21:23:29 you can get some nice reasonably affordable aarch64 hardware for compiling 2017-10-25 21:23:42 like the new marvell machiatobin 2017-10-25 21:23:45 even xgene has to do some funcky stuff to support arm32 2017-10-25 21:26:32 machiattobin does look nice 2017-10-25 21:27:06 its a big step up from the cheaper arm boards, and it has normal standard ITX mounting 2017-10-25 21:28:57 looks like aarch64 should run armhf code fine, its only the thunderx cpu's that removed legacy arm32 stuff 2017-10-25 21:34:03 devs PTAL: https://github.com/alpinelinux/aports/pull/2573 2017-10-25 22:35:30 what patches would be needed in order to allow apk to support a `repositories.d` folder where custom repos can be listed in? I'd like to use this support to be able to package repository entries 2017-10-25 23:22:48 already exists 2017-10-25 23:22:56 alpine just doesn't use it 2017-10-25 23:22:57 :) 2017-10-25 23:23:04 if you create a dir 2017-10-25 23:23:13 //etc/apk/repositories.d/ 2017-10-25 23:23:23 and you put foo.list 2017-10-25 23:23:24 in there 2017-10-25 23:23:29 it will add it :) 2017-10-25 23:24:56 Xe: ^ 2017-10-25 23:25:45 kaniini: does it specifcally have to be named with the extension .list? 2017-10-25 23:26:08 yes 2017-10-25 23:26:17 +1, sweet 2017-10-26 00:15:10 on a brand new installation /etc/inittab seems to have tty50 set twice - this causes problems under kvm 2017-10-26 05:01:27 <_ikke_> BitL0G1c: I don't see it here 2017-10-26 05:01:40 <_ikke_> https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout/inittab 2017-10-26 05:02:32 weird - must have been me then 2017-10-26 05:05:07 <_ikke_> BitL0G1c: Not sure if any of the setup scripts alter inittab 2017-10-26 05:06:02 was just a bit strange on a new install on a new server - I don't think it was anythng I did 2017-10-26 05:07:35 there was some work being done to add gpt support to setup-disk - I solved that a while ago https://github.com/itoffshore/alpine-linux-scripts/blob/master/setup-disk - this still works 2017-10-26 05:13:15 _ikke_ this is how inittab ended up https://hastebin.com/ugexafayit.rb - something added "enable login on alternative console" at the end 2017-10-26 05:14:27 <_ikke_> did you comment out line 16? 2017-10-26 05:18:14 yes & then the error disappears 2017-10-26 05:18:50 actually I commented the last line 2017-10-26 05:19:33 maybe i commented both 2017-10-26 07:05:33 are the arm and s390x builder still dead? 2017-10-26 12:46:37 we have circular deps with python3 tkinter 2017-10-26 12:46:49 depends on xcb-proto which depends on python3 2017-10-26 12:49:13 not good 2017-10-26 12:49:38 we had same issue with python2 earlier 2017-10-26 12:50:02 how did you solve it in that case? 2017-10-26 12:51:49 https://git.alpinelinux.org/cgit/aports/commit/?id=ec356aebd5adedb9de23cbb54ff42a783fb835e7 2017-10-26 12:52:13 problem moved to python3 with 2017-10-26 12:52:22 commit c8cf3118ca7a45dbb5fe677bb31dbf49c80344cf 2017-10-26 12:52:22 Author: William Pitcock 2017-10-26 12:52:22 Date: Sat May 27 20:28:39 2017 +0000 2017-10-26 12:52:22 main/xcb-tools: modernize apkbuild, move to python3 2017-10-26 12:52:32 rebase the fix? 2017-10-26 12:52:39 yup 2017-10-26 12:57:27 ncopa: what did you say that 'sh' issue with upgrading edge was? 2017-10-26 12:57:45 something about a conflict between the alpine base package and busybox 2017-10-26 12:57:57 not conflict 2017-10-26 12:58:00 iirc introduced by setting 'provides' to /bin/sh 2017-10-26 12:58:05 correct 2017-10-26 12:58:08 i can't remember what it was off the top of my head 2017-10-26 12:58:09 ah okay 2017-10-26 12:58:13 i think it can be considered a bug in apk 2017-10-26 12:58:26 sounds safe to say, yes - what do we do about it? 2017-10-26 12:58:40 file a bug on issues.a.o 2017-10-26 12:58:47 and ask fabled if its fixable 2017-10-26 12:58:56 oh, there's none filed - i will file one then 2017-10-26 12:59:34 the feature is, if a dependency is only provided with an unversioned 'provides' 2017-10-26 12:59:40 apk will back off 2017-10-26 12:59:51 gotcha 2017-10-26 12:59:57 and let user manually install whatever provides 2017-10-26 13:00:02 i'll ask fabled_ when he's around, and file an issue for reference 2017-10-26 13:00:28 in this case, apk should be able to figure out that an upgrade will provide the needed /bin/sh 2017-10-26 13:00:42 so yeah, ping fabled_ re: busybox / alpine base package and provides="/bin/sh" or something along those lines 2017-10-26 13:00:50 ncopa: gotcha 2017-10-26 13:01:02 i just needed to ask a little to wrap my head around it 2017-10-26 13:01:08 the workaround is: apk add -U -u busybox 2017-10-26 13:01:19 yeah, i gathered as much 2017-10-26 13:02:00 while i got you here ncopa - most builders (other than x86 and x86_64) seem stuck - who do we poke to fix them? 2017-10-26 13:02:16 before even considering mips, we need to stay on top of this 2017-10-26 13:02:27 im about to set up s390x 3.7 builer 2017-10-26 13:02:31 and x86 2017-10-26 13:02:42 i'm talking about edge 2017-10-26 13:03:14 lastpass issue is reported here: https://github.com/lastpass/lastpass-cli/issues/345 2017-10-26 13:03:40 i think kaniini mentioned a fix allowing builders to move past a broken package, and build the next ones 2017-10-26 13:04:56 sounds scary to me 2017-10-26 13:05:03 how come? 2017-10-26 13:05:34 it'll lessen the backlog of unbuilt packages for the builders - if we monitor it properly, and properly log failed packages 2017-10-26 13:05:44 i think the cleanup script will purge the old version 2017-10-26 13:05:59 so when builder rsync 2017-10-26 13:06:09 the previous version will get deleted 2017-10-26 13:06:48 and if it is a dependency for anything, those will no longer be installable 2017-10-26 13:07:04 hmm, that can be an issue 2017-10-26 13:07:08 there is actually a config option to enable 'continue build on failure' 2017-10-26 13:07:21 which we use when we bootstrap new releases 2017-10-26 13:07:29 build the repo for scratch 2017-10-26 13:07:42 but i dont think its a good idea to enable that for edge 2017-10-26 13:07:50 agreed, edge /is/ bleeding edge 2017-10-26 13:07:56 but thank you for clearing that up 2017-10-26 13:07:59 now i know 2017-10-26 14:29:03 ok i think i know whats wrong with lastpass-cli 2017-10-26 14:29:28 what i dont understand is why it does not fail on x86_64 2017-10-26 14:31:00 lastpass-cli-1.2.1/cmd-generate.c:77:78: warning: comparison is always true due to limited range of data type [-Wtype-limits] 2017-10-26 14:31:00 while ((option = getopt_long(argc, argv, "c", long_options, &option_index)) != -1) { 2017-10-26 14:31:00 ^~ 2017-10-26 14:31:24 option is a char 2017-10-26 14:31:35 getopt_long is int 2017-10-26 14:32:20 fabled: do you have any clue why the aboe warning/error does not happen on x86_64? 2017-10-26 14:32:28 all other arches fails 2017-10-26 14:33:08 signed of char depends on arch iirc 2017-10-26 14:33:14 signedness* 2017-10-26 14:33:14 aha 2017-10-26 14:33:51 ok, thanks. that explains 2017-10-26 14:33:55 For gcc, the default is signed, but you can modify that with -funsigned-char. note: for gcc in Android NDK, the default is unsigned. You can also explicitly ask for signed characters with -fsigned-char. 2017-10-26 14:37:20 my guess is that ppc64l/aarch64/s390x has different default than x86_64/x86 2017-10-26 14:37:33 that does not makes sense 2017-10-26 14:38:20 is there some way to test it? 2017-10-26 14:39:18 very weird 2017-10-26 14:39:41 printf("%d\n", (char)-1); 2017-10-26 14:39:47 That should print 255 if it's unsigned, I think 2017-10-26 14:40:25 According to a quick Google it is unsigned on ARM, at least 2017-10-26 14:41:12 ./a.out 2017-10-26 14:41:12 255 2017-10-26 14:41:23 that was ppc64le 2017-10-26 14:41:55 $ ./a.out 2017-10-26 14:41:55 -1 2017-10-26 14:41:59 that was x86_64 2017-10-26 14:42:21 ok, maybe it's that then 2017-10-26 14:42:38 not sure if the printf test is valid, it depends on other things too 2017-10-26 14:42:49 wow, this was sort of surprising 2017-10-26 14:43:36 so if you want signed char you should tell that 2017-10-26 14:43:41 yes 2017-10-26 14:43:49 or use "signed char" 2017-10-26 14:43:59 thats what i meant 2017-10-26 14:44:14 you should then never declare anything as "char" 2017-10-26 14:44:17 for getopt and getopt_long, it should always be int 2017-10-26 14:44:24 always make it "signed char" or "unsigned char" 2017-10-26 14:44:39 use 'char' when it's a character and it's not used for other things then strings 2017-10-26 14:44:44 char is ok if you don't care about the signedness, for instance if you're just going to do equality tests or print them 2017-10-26 14:44:49 skarnet: yes ofc, i was just suprised that it gave different restul on different arches 2017-10-26 14:44:51 if you are doing comparisons, or arithmetic then it's different 2017-10-26 14:45:19 the proper fix in this case is to use int 2017-10-26 14:45:21 but the fix is to change 'option' to int 2017-10-26 14:58:50 whee!!! \o/ builders unblocked 2017-10-26 15:02:34 rdutra: doi you think you can help with figuring out why py3-aiohttp fails on ppc64le? 2017-10-26 15:02:38 http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/py3-aiohttp/py3-aiohttp-2.3.1-r1.log 2017-10-26 15:02:51 ncopa: sure, will take a look 2017-10-26 15:03:09 ncopa: also failed in s390x 2017-10-26 15:03:21 it could be a problem in binutils 2017-10-26 15:03:36 or linker... i dunno 2017-10-26 15:17:38 <_ikke_> ............................................. 2017-10-26 15:17:48 ncopa: it is failing in ppc64le and s390x because it is trying to strip a x86_64 .so file (_http_parser.cpython-36m-x86_64-linux-gnu.so) 2017-10-26 15:17:49 <_ikke_> sorry, ssh connection hung 2017-10-26 15:18:16 ncopa: not sure yet why the py3-aiohttp build is generating a x86_64 so in ppc64le and s390x 2017-10-26 15:18:40 huh? 2017-10-26 15:18:56 rdutra: might they ship a prebuilt binary in the sources 2017-10-26 15:19:33 ncopa: ummm yes 2017-10-26 15:19:36 ncopa: ./aiohttp-2.3.1/aiohttp/_http_parser.cpython-36m-x86_64-linux-gnu.so 2017-10-26 15:19:41 ncopa: before the build 2017-10-26 15:20:06 ncopa: I can make a patch removing this .so before the build, what you think? 2017-10-26 15:23:37 try rm it from APKBUILD 2017-10-26 15:23:48 should probably be reported upstream too 2017-10-26 15:24:36 ncopa: sure, I will report it upstream 2017-10-26 15:26:56 thanks! 2017-10-26 16:31:51 ncopa: i came up with a solution for rethinkdb 2017-10-26 16:31:54 ncopa: but you're not going to like it 2017-10-26 16:33:00 ncopa: two versions of the APKBUILD, one for ppc and other for s390x 2017-10-26 16:35:11 or just override prepare, filter out unwanted patch(es) and call default_prepare. 2017-10-26 16:35:52 arch-specific patches are possible 2017-10-26 16:35:54 but ugly 2017-10-26 16:36:15 kaniini: if the s390x team wants to add the patches that enable s390x in top of rethinkdb branch 2.3.6, I can adjust my patch from ppc64le in the top of it 2017-10-26 16:36:40 my understanding is that s390x team has 2.3.5 patch 2017-10-26 16:36:47 not 2.3.6 2017-10-26 16:36:49 umm 2017-10-26 16:37:02 so my plan is basically "fuck it, ship 2.3.5 on s390x" 2017-10-26 16:37:09 kaniini: :) 2017-10-26 16:37:57 note that if IBM would like this done properly they can call me and send me an s390x machine ;) 2017-10-26 16:38:38 kaniini: hehehe, you can try ;) 2017-10-26 16:42:26 more imaginative solution: 2017-10-26 16:42:30 [ $CCAR 2017-10-26 16:42:40 [ $CARCH == "s390x" ] && pkgver=2.3.5 2017-10-26 16:42:45 =D 2017-10-26 16:44:34 kaniini: ah, btw, I have acess to a s390x LXC container. If you want/need access to it 2017-10-26 17:47:45 note note note: qt 5.9.2 has a serious regression in qtdeclarative that causes segfault 2017-10-26 17:48:06 it's been confirmed by multiple distros and the qt team, 5.9.3 will likely be out soon 2017-10-26 17:48:10 5.9.1 should not be bumped 2017-10-27 05:19:51 i want to build my own weechat docker image... there is weechat-python for the python plugins... but it does not install python as dependency? shouldnt it depend on python? else its not working... or is it because the user should decide what python version to install? 2017-10-27 10:34:00 kaniini, 'abuild check' and 'abuild -r' do different thing. 'check' runs always test suite as user; where -r runs under fakeroot... wonder how to fix that 2017-10-27 10:34:21 because of that gdnsd issue went through my testing 2017-10-27 10:55:39 Shiz: can you rebase your remailer patch and upgrade it? maybe even move to community. 2017-10-27 10:58:02 i have an idea on how to get it to work, just need to try it out. 2017-10-27 10:58:46 weekend time for me. cya later. 2017-10-27 11:07:52 <_ikke_> clandmeter: enjoy 2017-10-27 12:10:29 https://github.com/alpinelinux/aports/pull/2495#issuecomment-339927267 wut 2017-10-27 12:16:28 yes 2017-10-27 12:20:17 scadu: shenanigans, we're working it out 2017-10-27 12:28:29 PureTryOut: awesome. so you'll continue with LTS, right? 2017-10-27 12:28:44 that I don't know yet. like I said, we're working it out 2017-10-27 12:28:49 postmarketOS still requires the latest, not LTS 2017-10-27 12:29:02 however, KDE Frameworks has no such thing as LTS afaik 2017-10-27 12:29:06 just Plasma 2017-10-27 12:29:17 in which case we can still upstream KDE Frameworks, and keep our own version of Plasma 2017-10-27 12:29:25 but, we're discussing it 2017-10-27 13:29:16 clandmeter: take care man, have a good one 2017-10-27 15:35:00 PureTryOut: where are you discussing this? I don't see any mail on alpine-devel ml today 2017-10-27 15:35:38 right now nowhere, but it'll probably be discussed either in PM or on #postmarketos:disroot.org 2017-10-27 16:24:27 PureTryOut[m]: do you think it will help if we focus on KDE 5.12 (LTS) after the v3.7 release? 2017-10-27 16:31:42 ncopa: definitely. I'm probably sticking to 5.12 as well anyway 2017-10-27 16:32:10 5.8 is just too old for us now 2017-10-27 16:36:13 KDE 5.8 is on the last refrain 2017-10-27 16:36:53 sorry, English is not my native lanague. "last refrain"? 2017-10-27 16:36:59 <^7heo> On the way out 2017-10-27 16:37:00 <^7heo> ACTION hides 2017-10-27 16:37:12 thanks! 2017-10-27 16:37:15 <^7heo> (actually, it's "on the last iteration") 2017-10-27 16:37:22 <^7heo> (before you take what I said seriously) 2017-10-27 16:41:47 I have an idea as to the direction Alpine Linux should take 2017-10-27 16:41:52 https://qntm.org/suicide 2017-10-27 16:42:05 don't let the URL scare you, the page contents are worse 2017-10-27 16:42:38 <_ikke_> related: http://www.commitstrip.com/en/2014/05/16/russian-roulette/ 2017-10-27 16:42:53 LOL 2017-10-27 16:43:00 it's friday, my dudes! 2017-10-27 16:43:24 <^7heo> < danieli> don't let the URL scare you, the page contents are worse 2017-10-27 16:43:29 <^7heo> can I quote that? 2017-10-27 16:43:35 lol sure 2017-10-27 16:43:39 <^7heo> thanks 2017-10-27 16:44:25 <^7heo> _ikke_: yeah that's a famous one 2017-10-27 16:44:31 ^ 2017-10-27 16:44:33 <^7heo> from bash.org if I recall correctly. 2017-10-27 16:44:46 <_ikke_> ^7heo: Yeah, might be 2017-10-27 16:45:12 still a good one 2017-10-27 16:45:21 <^7heo> definitely. 2017-10-27 16:46:36 https://imgur.com/a/IYgbX 2017-10-27 16:47:04 <^7heo> wtaf 2017-10-27 16:47:17 <^7heo> my ssh connection hangs after like 5 seconds... 2017-10-27 16:47:20 <^7heo> ALL the time. 2017-10-27 16:47:31 ^7heo: wireshark it? 2017-10-27 16:47:33 also see: mosh 2017-10-27 16:47:49 <^7heo> nah I tcpdump 2017-10-27 16:47:54 <^7heo> wireshark is for the weak. 2017-10-27 16:48:38 works for me 2017-10-27 16:48:44 lmfao scapy it 2017-10-27 16:48:48 also, refresh that imgur page 2017-10-27 16:48:51 i added a couple good ones 2017-10-27 17:11:52 "why is redis talking to mongodb" 2017-10-27 17:11:53 I love that one 2017-10-27 17:15:27 it's great lol 2017-10-27 18:54:35 danieli: rm -rf won't work in al that is booted using cdrom, and running on ram 2017-10-27 18:54:59 lbu makes the disk on which you save apkovl read-only after save 2017-10-27 18:55:00 ;) 2017-10-27 18:56:28 no wonder ncopa is big fan of russian roulette 2017-10-27 18:57:51 then again, that.. was a joke. 2017-10-27 18:58:05 i know ;) 2017-10-27 19:00:37 that reminds me, does any one know how boot option apkovl=? works, tried couple of times 2017-10-27 19:14:53 haven't used it, but inspecting /usr/share/mkinitfs/initramfs-init from mkinitfs pkg should help you substantially. it looks like it unpacks given apkovl (downloads it first if it's http(s)/ftp URL) and installs its packages later. 2017-10-27 19:20:18 looking for local file, earlier irc logs had some discussion as apkovl=vda:localhost.apkovl.tar.gz 2017-10-27 19:20:27 thanks 2017-10-28 14:43:10 ...dont suppose anyone is around? 2017-10-28 14:44:16 don't ask to ask, just ask 2017-10-28 14:45:01 http://lists.alpinelinux.org/alpine-devel/4993.html 2017-10-28 14:45:09 I'm running into that. Wondering if anyone had suggestions. 2017-10-28 14:59:27 I think I found it 2017-10-28 17:06:07 we need something done about all the broken packages on the builders, especially arm, ppc and s390x 2017-10-28 17:06:30 ncopa: the only ones that seem to be chomping away at an "all right" rate are x86 and x86_64 2017-10-28 17:06:45 hopefully your IRC client gives you highlighting context 2017-10-28 19:08:49 >>> #alpine-commits being spammed with failed builds 2017-10-28 19:22:35 Yes it's normal 2017-10-28 19:22:47 Another day before a release 2017-10-28 19:23:10 <_ikke_> Just for my curiosity, why is it expected? 2017-10-28 19:27:07 Because it's building from zero 2017-10-28 19:27:17 <_ikke_> ok 2017-10-28 19:27:22 Some things will be broken 2017-10-28 19:27:47 And could be a dep. 2017-10-28 19:27:58 i’ve sketched out better build software to handle that 2017-10-28 19:28:03 <_ikke_> right 2017-10-28 19:30:12 Soon we will generate a list of broken packages and we can start fixing things. 2017-10-28 22:14:32 i suppose i should have disabled irc messages 2017-10-28 22:15:32 after first run, those are failing to build: http://tpaste.us/8Qlk 2017-10-28 22:16:17 I'm not sure how much it was with previous releases, but that doesn't seem too bad 2017-10-28 22:17:04 it does not include those who failed due depending on the above list 2017-10-28 22:17:46 Aah ok 2017-10-28 23:47:55 ncopa: I have fixes for some of those 2017-10-28 23:48:01 ncopa: would you like PR? 2017-10-29 09:08:43 ARM builders goes insane 2017-10-29 09:10:20 clandmeter: ^ 2017-10-29 15:05:05 holy crap #alpine-commits 2017-10-29 15:05:19 I'm just curious - where does the name "Alpine" come from? random cool word? 2017-10-29 15:35:57 Nope 2017-10-29 15:36:06 A Linux powered integrated network engine 2017-10-29 15:36:33 Is there a good reason why dkms is not in the alpine repos? 2017-10-29 16:42:08 thats interesting, msg sequence for given arch arriving in mqtt is quite different from alpine-commits :) 2017-10-29 16:43:38 seems both actie 3.7 builder are stuck in hyperloop of 362 and 313 2017-10-29 16:44:49 would be cool if it detects its repeating the loop and shuts till reactivated 2017-10-29 19:14:37 z3ntu: good, probably not 2017-10-29 19:14:47 probably nobody bothering to package it 2017-10-29 19:31:07 Shiz: okay then I'll package it :) 2017-10-29 20:07:03 i can review the PR if you link it ot me when done :) 2017-10-29 20:16:35 Shiz: dkms itself is running but I believe having a trigger when the kernel or a package is updated would be great... 2017-10-29 20:16:54 I'm not sure inhowfar this is possible with apkbuild though... 2017-10-29 20:32:50 Shiz: dkms needs ENABLE_FEATURE_RMDIR_LONG_OPTIONS enabled in busybox... 2017-10-29 20:33:18 any idea what to do (or just depend on coreutils)? 2017-10-29 20:34:14 you can patch it 2017-10-29 20:36:45 Shiz: the option `ignore-fail-on-non-empty` doesn't exist in a short form 2017-10-29 20:36:50 the parents option does though 2017-10-29 20:40:29 i can enable that feature 2017-10-29 20:40:34 in busybox 2017-10-29 20:42:11 kaniini: that would be great 2017-10-29 20:49:26 triggers are not callable before a package removal as it seems, just after? 2017-10-29 22:48:42 clandmeter: did you just make that up 2017-10-29 22:54:56 danieli, Nope. It's the real deal 2017-10-29 22:57:36 z3ntu: handling triggers on package removal is tricky 2017-10-29 22:57:52 z3ntu: haven’t really found a solution i’m happy with for that 2017-10-30 07:40:54 what exactly is going on with the arm builders? 2017-10-30 07:49:31 danieli, it's the new 3.7-branch builders. they are doing initial full build and finding all the nastier issues we've introduced, and vanished upstream source tarballs 2017-10-30 07:56:48 fabled: ah okay, good 2017-10-30 07:56:49 just checking 2017-10-30 07:56:53 it didn't look very good 2017-10-30 08:48:17 commits is pretty messy now. 2017-10-30 08:48:51 maybe we should silence 3.7 buiders. 2017-10-30 10:05:58 yeah 2017-10-30 10:06:09 we should silence the 3.7 builders 2017-10-30 10:08:33 with a gag and AK-47s? 2017-10-30 10:20:47 skarnet, imaging AI scrounging through net looking for keywords, finds yours and flags it, After couple of similar keywords it raises a tag, then TLA's come and bag you. Welcome to AI reasoning, coz its almost impossible for it to get the context of talks. 2017-10-30 10:21:19 skarnet: real gangstas use uzis 2017-10-30 10:21:30 ;) 2017-10-30 10:22:36 note to self: explain how to handle bootstrapping programming languages in the policy manual i am writing 2017-10-30 10:23:23 was looking through the 3.7 builder loop log, it might be possible to guess its in same build loop, but I think that requires same the log first 2017-10-30 10:23:43 saving the log first* 2017-10-30 10:25:22 got the idea while using https://github.com/insteps/mqtt-dirpub 2017-10-30 10:26:48 this give me good practical msgs state for processing afterwards 2017-10-30 10:27:10 thinking for buiding conky scripts 2017-10-30 10:27:23 making conky* 2017-10-30 10:31:17 ncopa, suggestion, mqtt msg build/3-7-aarch64/[state|errors] could be better then build/build-3-7-aarch64 and build/build-3-7-aarch64/errors 2017-10-30 10:32:47 sounds like a good suggestion 2017-10-30 11:34:08 3.7 builders for armhf and aarch64 have uploaded the initial packages 2017-10-30 11:34:19 im setting up s390x now 2017-10-30 11:34:35 and then x86, ppc64le and x86_64 last 2017-10-30 12:36:41 hi all 2017-10-30 12:36:46 re: tmpfs size 2017-10-30 12:37:03 how this can be customized in a usb-only ? 2017-10-30 12:37:20 i've a 8gb usb, and tmpfs is 4gb 2017-10-30 12:37:26 I want it to 6gb 2017-10-30 12:37:44 it will use 50% of RAM by default 2017-10-30 12:37:46 and 7gb ram 2017-10-30 12:37:48 yes 2017-10-30 12:37:55 there is a boot option for it 2017-10-30 12:37:56 *8gb ram 2017-10-30 12:39:10 ncopa, i belieive that fstab doesn't work for that right? 2017-10-30 12:39:55 add rootflags=size=6GB or similar 2017-10-30 12:40:34 rootflags=size=6g 2017-10-30 12:40:43 or 6000m 2017-10-30 12:40:57 cool. 2017-10-30 12:41:00 THanks ncopa! 2017-10-30 12:42:46 Not to jump in here, but what's the preferred venue for PRs? 2017-10-30 12:42:55 specifically for core packages? 2017-10-30 12:44:01 depends on the reviewer i suppose 2017-10-30 12:44:21 That's fair. Moreso, there's no standard github repo, or? 2017-10-30 12:44:30 Well. That'd depend on the package, really. 2017-10-30 12:44:35 you can create PR on github or git send-email to alpine-aports 2017-10-30 12:44:47 github.com/alpinelinux/aports 2017-10-30 12:44:49 Fantastic. 2017-10-30 12:44:51 thats the repo 2017-10-30 12:44:53 I'll start there. 2017-10-30 12:44:54 Thanks 2017-10-30 12:45:24 if you send individual patches alpine-aports@lists.alpinelinux.org is fine 2017-10-30 12:45:29 specially if you prefer feedback via email 2017-10-30 12:45:39 if you prefer github then feel free to use that 2017-10-30 12:46:06 and if you have a patchset with more than 5 patches, then I personally prefer to pull from github 2017-10-30 12:46:13 Github it is. 2017-10-30 12:46:29 When I get some free time I'll throw something on github. 2017-10-30 12:46:34 heh. Free time... 2017-10-30 12:48:33 free time is overrated... 2017-10-30 12:48:34 :) 2017-10-30 13:22:04 As an aside, I'm super impressed with just how light alpine is. 2017-10-30 13:39:35 buildfailures for v3.7 armhf: http://tpaste.us/nZPv 2017-10-30 14:03:01 I know there's an overlay concept and that's saved my backside a few times. 2017-10-30 14:03:20 ..I remember something about an unattended install but it doesn't appear to be in the wiki. Am I missing something obvious? 2017-10-30 14:04:17 the unattended install is not very polished 2017-10-30 14:04:28 I can work with "not very polished" 2017-10-30 14:04:47 I've been voiding warrantys for.. oh boy.. a dozen years or more 2017-10-30 14:05:19 setup-alpine has a (hackish) concept of answer files 2017-10-30 14:06:55 https://github.com/alpinelinux/alpine-conf/blob/master/setup-alpine.in#L66 2017-10-30 14:07:00 Interesting. 2017-10-30 14:07:53 Good enough for me. Just looking for something I can templatize and fire in the background while 23402938420 other things occur. 2017-10-30 14:08:47 I kinda wish I had my job from like.. 10 years ago. I have ideas around PXE booting and automated installs with inventory management. 2017-10-30 14:09:12 in any event, thx 2017-10-30 14:43:27 do we have plan as yet about passing the apkovl to the boot loader, in order to choose different alpine profiles/installs? 2017-10-30 16:35:38 fcolista: i think our initramfs already supports apkovl? 2017-10-30 16:41:50 Natanael Copa: we dont support embedding ovl with new mkimage? 2017-10-30 16:45:11 Hey 2017-10-30 16:46:27 clandmeter, really? 2017-10-30 16:47:06 fcolista: https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in#L461 2017-10-30 16:47:40 but you need an initramfs with networking support 2017-10-30 16:48:22 clandmeter, just if I want to bootstrap from the network 2017-10-30 16:48:41 my idea is having different apkovl in /media/usb/overlays dir 2017-10-30 16:48:42 ? 2017-10-30 16:49:34 ah, not over network 2017-10-30 16:49:38 and syslinux has a menu with different "profile", like ovl=myworkstation.apkvol.tgz; ovl=rescue.apkovl.tar.gz 2017-10-30 16:49:39 no 2017-10-30 16:50:18 I don't want to load the apkovl from the network...which is possible as far as i understand 2017-10-30 16:51:38 right 2017-10-30 16:52:14 i think its possible, if you embed them. 2017-10-30 16:52:31 but i didnt see that option in mkimage 2017-10-30 16:52:44 i never played with it so im not sure. 2017-10-30 16:55:05 ok, i'll try 2017-10-30 16:55:11 thx clandmeter 2017-10-30 16:55:59 the part i linked supports both disk and network 2017-10-30 17:00:01 yep 2017-10-30 17:56:40 something broke... 2017-10-30 17:56:56 my script to test new kernels no longer work 2017-10-30 17:57:02 >>> mkimage-x86_64: --> apks x86_64 b056465151a53295172ea5a69a160511f21fd6df 2017-10-30 17:57:02 chrony: unable to select package (or its dependencies) 2017-10-30 18:01:44 what is your script doing with apk exactly 2017-10-30 18:17:23 $ tpaste < edge.sh 2017-10-30 18:17:23 http://tpaste.us/Lv56 2017-10-31 10:22:36 Is there a way to fix Travis for 3.5 branch? https://github.com/alpinelinux/aports/pull/2615 2017-10-31 10:27:05 Alpine's standard gcc toolchain doesn't build crtbegin.o and crtend.o as PIC 2017-10-31 10:27:10 but it's default PIE 2017-10-31 10:27:39 so there are a few cases where linking a static program fails 2017-10-31 11:08:16 andypost: i dont know if travis can build anything else than git master 2017-10-31 11:10:10 ncopa, good to know, but this PHP release is very strange, all releases mentioned CVE but only 2 of them reports security 2017-10-31 11:15:46 drats 2017-10-31 11:15:52 i pushed it 2017-10-31 11:15:55 and its broken 2017-10-31 11:16:12 trying to do too much at the same time 2017-10-31 11:16:16 ending up doing nothing good 2017-10-31 11:16:37 checking for xml2-config path... /usr/bin/xml2-config 2017-10-31 11:16:37 checking whether libxml build works... no 2017-10-31 11:16:37 configure: error: build test failed. Please check the config.log for details. 2017-10-31 11:16:37 >>> ERROR: php7: all failed 2017-10-31 11:19:41 configure:17046: gcc -o conftest -Os -fomit-frame-pointer -fvisibility=hidden -Os -fomit-frame-pointer -Wl,--as-needed -Wl,-rpath,/lib -L/lib conftest.c 2017-10-31 11:19:42 -lrt -lm -lxml2 -lz -llzma -lm >&5 2017-10-31 11:19:42 collect2: error: ld returned 1 exit status 2017-10-31 11:19:59 /usr/lib/gcc/x86_64-alpine-linux-musl/6.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -llzma 2017-10-31 11:20:10 i wonder what is pulling -llzma 2017-10-31 11:24:15 my local libxml2 was wrong 2017-10-31 11:24:21 purging it locally fixed that 2017-10-31 11:24:24 but it still fails 2017-10-31 11:24:35 http://build.alpinelinux.org/buildlogs/build-3-5-aarch64/community/php7/php7-7.0.25-r0.log 2017-10-31 11:24:45 looks like litespeed is broken or removed? 2017-10-31 11:27:48 nope just renamed 2017-10-31 11:39:22 ncopa, litespeed renamed 2017-10-31 11:41:44 ncopa, https://github.com/alpinelinux/aports/pull/2616/files#diff-ff6de47b5614264935d38f5415bd8babL464 2017-10-31 11:48:00 yeah i realized that. should be ok now 2017-10-31 11:48:07 thanks for the fix! 2017-10-31 14:06:18 i have soon bootstrapped all the 3.7 builders 2017-10-31 14:06:40 but none of them report build errors 2017-10-31 14:07:02 we have 2 options (for now): 2017-10-31 14:07:16 1) enable error messages and spame the #alpine-commits 2017-10-31 14:07:52 2) enable error messages + halt on first error 2017-10-31 14:08:35 3) enable error messages, continue on errors, but disable "community" repo for now 2017-10-31 14:10:03 4) leave error messages off and continue on errors, and let ncopa occationally publish a list of packages that fails 2017-10-31 14:10:12 i guess thats 4 options 2017-10-31 14:11:52 <_ikke_> I started to wonder what base you were using :P 2017-10-31 14:16:05 the error spamming comes from community repo, where not all deps are yet built in main 2017-10-31 14:16:54 the build script does not check if the deps are there, so it fails after calling abuild 2017-10-31 14:17:35 disabling community til we have built everything in main should reduce the error message spamming 2017-10-31 14:17:56 <_ikke_> Does that mean that community should only be built after main? 2017-10-31 14:18:04 yes 2017-10-31 14:31:02 on adelie side, we are writing new build system in python that handles these interdependency issues better 2017-10-31 14:31:39 we also plan to support horizontal scalability (to handle the ARM/MIPS slow builders problem) 2017-10-31 14:31:51 based on buildbot? 2017-10-31 14:32:15 <_ikke_> kaniini: You mean that the work is devided over multiple machines? 2017-10-31 14:33:38 ncopa: not based on anything :) 2017-10-31 14:33:44 _ikke_: yes 2017-10-31 14:39:57 nmeum: https://git.alpinelinux.org/cgit/aports/commit/?id=e07092f6 2017-10-31 15:11:48 ncopa, php5 also needs backport to supported branches https://git.alpinelinux.org/cgit/aports/commit/?id=21bbc56f76 is security fix 2017-10-31 15:21:28 ncopa: the main thing we have added is the ability to say that job X is blocked by job Y 2017-10-31 21:11:23 i think it would be good to have support openjdk9 in alpine v3.7: http://bugs.alpinelinux.org/issues/8089