<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:02 <mitchty> yep, no parallelism in it
00:02 <mitchty> let me see how much it impacts
00:07 <jirutka> no, no, no, NO! https://github.com/alpinelinux/aports/pull/972
00:07 <jirutka> he must really hate his users that he moved all sources to his own repo with git-web and *disabled* downloading tarballs!
00:16 <jirutka> btw if anyone interested in this, read https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
00:58 <mitchty> jirutka: its not too bad, i pushed up an autosquash commit with the changes
00:59 <mitchty> ah whoops, didn't see it was merged already
00:59 <mitchty> this is the changes https://github.com/mitchty/aports/commit/bfe6061074d15f8bb0947ec2bba8077cd28cb8df
01:04 <mitchty> jirutka: thanks for merging cabal! now i can open a ton of pr's to tell people to stop using my old port
01:31 blueness joined
02:08 <pickfire> jirutka: Huh? ranger is unmaintained?
02:12 <pickfire> kaniini: Yeah, I support manpages as well! :)
02:14 dlintw joined
02:14 <dlintw> help https://github.com/alpinelinux/aports/pull/952
02:18 <kaniini> pickfire: i mean for apk :)
02:19 <pickfire> kaniini: Yes, I support man.
02:19 <pickfire> -man*
02:20 <pickfire> dlintw: I don't find that pull request ince.
02:20 <pickfire> nice*
02:23 <dlintw> kaniini, could you help me check why CI failed in https://github.com/alpinelinux/aports/pull/952
02:24 <dlintw> kaniini, what's things should I do on https://github.com/alpinelinux/aports/pull/940 and https://github.com/alpinelinux/aports/pull/939, I can not see them on testing after several days.
02:25 <dlintw> pickfire, what's you mean what's pull request?
02:32 s33se_ joined
02:39 vitronic joined
03:56 <pickfire> dlintw: I mean https://github.com/alpinelinux/aports/pull/952
03:59 diego__ joined
04:00 diego__ left
04:05 diego__ joined
04:06 diego__ left
04:07 diego__ joined
04:08 diego__ joined
04:20 Emperor_Earth joined
05:15 <pickfire> Hi, I am currently packaging a non-free application for alpine (wps-office) which provides multiple arch, how do I separate the x86_64 arch from x86?
05:49 chatter29 joined
07:04 BitL0G1c joined
07:46 <TemptorSent> Bloody hell -- I've been fighting this IFS problem all day trying to make the plugin loader prettier.
07:52 <skarnet> IFS? If you're writing shell, don't expect it to be pretty. "Working" is more or less the best you can do. :P
08:11 scadu joined
08:27 t0mmy joined
08:38 Mutter joined
08:39 Mutter joined
08:40 FRP joined
08:41 blueness joined
08:48 FRP joined
08:50 FRP-admin joined
08:51 xfix joined
08:52 <TemptorSent> IFS hell solved! *YAY* Talk about wasting a day though!
08:56 FRP-admin joined
09:06 <skarnet> grats
09:11 FRP-admin joined
09:11 blueness joined
09:11 BitL0G1c1 joined
09:15 FRP-admin joined
09:17 ncopa joined
09:18 <TemptorSent> skarnet: I wasn't worried about the pretty with the IFS, I was worried about the working part.
09:19 <TemptorSent> skarnet: What I really should do is convert EVERYTHING to \n separated everywhere and convert on output only if needed.
09:19 <skarnet> yes. Even better if you can make your words null-separated, but that's difficult to do in shell.
09:19 <TemptorSent> skarnet: Anyway, I finally got it working.
09:20 <TemptorSent> skarnet: Yeah, I use xargs -0 and printf %s\0 where appropriate.
09:20 <skarnet> nice.
09:21 <TemptorSent> skarnet: But I haven't even started trying to go through and change ALL the logic in the code to use \n separated values, especially since it will require further work on the means of setting/getting them.
09:21 <skarnet> all in good time.
09:22 <TemptorSent> Give me a sec and I'll finish cleaning up the work and push it.
09:24 FRP-admin joined
09:34 fekepp joined
09:53 <TemptorSent> Major revision of mkimage pushed to https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
09:55 stwa joined
09:55 <TemptorSent> (and breakage it seems, grr. More testing, less pushing :) )
09:55 royger joined
09:58 <TemptorSent> I love it when totally unrelate parts of code break at random :/
09:59 <TemptorSent> Well, that proved to be simple... a stray semicolon in place of &&.
10:01 <TemptorSent> Unbroken version pushed :)
10:02 <TemptorSent> Hmm... need to talk to fabled still about why apk --cache-dir isn't actually doing what it's supposed to.
10:39 blueness joined
12:01 _ikke_ joined
12:01 blueness joined
12:12 stwa joined
12:19 leitao joined
12:20 laskin joined
12:21 farosas_ joined
12:22 <jirutka> mitchty: IMO it’d be better to wait until we move it into community repo
12:23 <jirutka> pickfire: yes, b/c it’s broken, http://bugs.alpinelinux.org/issues/6839
12:24 <jirutka> skarnet: TemptorSent: shell can be pretty…
12:24 <jirutka> TemptorSent: but If you’re dealing with spaces in items, then shell is not a good tool…
12:25 <skarnet> murder can be pretty, too
12:25 <jirutka> skarnet: ofc it can ;)
12:26 <jirutka> TemptorSent: it’d be probably better to rewrite mkimage (at least part of) to Lua, it seems to be already too much complex for shell
12:27 gromero joined
12:32 blueness joined
12:41 ferseiti joined
13:04 ed___ joined
13:05 errm joined
13:05 errm left
13:05 _errm joined
13:06 <_errm> I just opened a PR to subpackage npm on the nodejs apk https://github.com/alpinelinux/aports/pull/981anyone have any thoughts about this?
13:07 <_errm> I think its usefull, since npm is not always needed & there is an alternative package manager now - yarn
13:21 m4 joined
13:33 <jirutka> _errm: I agree with that, but please change one abuild per commit
13:37 <_errm> ok …
13:39 <_errm> its ok to keep all the changes in the same PR on github?
13:48 <jirutka> of course
13:48 <jirutka> it is
13:49 <^7heo> jirutka: btw, we might have to go away from github.
13:53 <coredumb> has there been clarifications on the new TOS ?
13:55 <^7heo> not sure.
13:55 <^7heo> but it still stands that "we might"
13:55 <^7heo> and therefore it "might" be a good idea to have an alternative.
13:55 <jirutka> ^7heo: no, read https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
13:56 <jirutka> yes, it’s a good thing to have a *working* alternative…
13:56 <^7heo> right.
13:56 <^7heo> thanks for the link, alos
13:56 <^7heo> also
13:57 <_errm> gitlab.com is nice …
13:57 <^7heo> nope.
13:57 <^7heo> not in my experience.
13:57 <^7heo> But maybe I should give it another shot.
13:57 <skarnet> oh hey, it's that conversation again
13:58 <skarnet> how are you my old friend? long time no see, it's been at least two... weeks
13:58 <^7heo> :P
14:02 <_errm> well I say nice, I mean somewhat useable…
14:05 <^7heo> yeah
14:05 <^7heo> but then gogs also is.
14:05 <^7heo> and gitea (from mosez and cie)
14:05 <^7heo> and some other clones I guess, too.
14:06 <jirutka> NoGo…
14:07 <^7heo> jirutka: stop being a NoGo :P
14:07 <jirutka> but well, everything’s better than Patchwork… but GitHub works very well for us now
14:07 <^7heo> yeah
14:08 <^7heo> jirutka: so, it IS to see if we have something in case github would "break" for us.
14:08 <^7heo> jirutka: thanks for confirming.
14:08 <jirutka> that also reminds me that I should finally write the proposal for thesis about minimalistic GitHub/GitLab/Gogs/whatever alternative… something very simple with pull requests support and hooks
14:08 <^7heo> yeah
14:09 <^7heo> but the challgenge is:
14:09 <^7heo> the interface for those PRs and hooks
14:09 <^7heo> if you do hooks, people will want webhooks
14:09 <^7heo> if you do PRs, people will want reviews
14:09 <^7heo> and then you end up like github.
14:09 <jirutka> with hooks I mean both
14:10 <jirutka> and with support for PR I mean primarily for reviews, that’s the whole point
14:10 <jirutka> It still can be very simple
14:10 <jirutka> I’d like to avoid traditional user accounts…
14:10 <jirutka> also
14:10 <jirutka> so everything you need is your SSH pubkey
14:11 <jirutka> and probably some token that you get by SSH so you can login into web interface to add comments, if you want to use web interface
14:11 <jirutka> but it should also provide usable remote CLI interface
14:12 <^7heo> jirutka: well, user accounts could be based on git.
14:12 <jirutka> yes, but the problem is that you cannot use SSH pubkey to login into web page :(
14:13 <^7heo> jirutka: also, it technically is possible to use git branches or tags or whatnot to "push reviews"
14:13 <jirutka> (securely)
14:13 <jirutka> no, git notes
14:13 <^7heo> or that.
14:13 <^7heo> right.
14:13 <jirutka> or how is that called
14:13 <^7heo> yeah gotchat.
14:13 <^7heo> s/chat/cha/
14:13 <jirutka> yes, that’s what I’m thinking about, but there are still some unresolved questions
14:13 <^7heo> why would you need to auth to the web?
14:14 <jirutka> for users who’d like to add comments via web interface
14:14 <jirutka> to be honest, I don’t know how to make a simple CLI interface that would allow you to add comments to the code (to specific lines), this is much easier via web interface
14:15 <jirutka> anyway, I need to work now
14:15 <^7heo> jirutka: you can definitely start the git note (or whatever) with a line identifier
14:15 <jirutka> but you can kick into me once a day to remind me to write the proposal for this topic :)
14:15 <^7heo> jirutka: and that solves the problem
14:15 <^7heo> I'll try to poke gently
14:15 <^7heo> not kick :D
14:29 <scadu> what's the biggest change in current ToS? sorry, didn't have time to look at this yet
14:29 <jirutka> scadu: read https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
14:30 <scadu> jirutka: oh thanks. I missed this one.
14:30 <jirutka> unfortunately there are some people who create a panic b/c of their interpretation of ToS…
14:30 <jirutka> and now we have to deal with some sources on personal git with no tarballs…
14:31 <jirutka> no that git-web doesn’t provide support for this, but the developer has disabled it…
14:34 <jirutka> according to twitter they (GitHub) got a lot of questions about ToS and are currently refining it to be more clear, so we’ll see
14:36 blueness joined
14:44 tty` joined
14:50 blueness joined
15:08 dlintw joined
15:19 al3hex_ joined
15:19 al3hex joined
15:29 <mitchty> one reason to always ask a lawyer to read legalese
15:35 <^7heo> if you got the cash, sure. :P
15:35 <yGweSm1OzVHe> well you could also ask the laywers working for the fsf*
15:37 <^7heo> and risk to have a tainted answer.
15:37 <^7heo> no matter how...
15:37 <^7heo> ... it's best to pay.
15:51 <yGweSm1OzVHe> the fsf* would have complained if the panicking people were right about their misunderstandings.
15:54 <^7heo> don't assume that the complaining people will always complain in case of fuckup.
15:54 <^7heo> or rather, don't assume you can trust an 1:1 equivalent of trigger-warning people and fuckups.
15:55 <^7heo> because the day they're tired, crap will hit the fan ;)(
16:22 <jirutka> yes, and also don’t trust non-lawyer’s interpretation of a legal documents; there are many non-senses in laws and especially in USA companies must protect themselves, b/c anyone can sue them for total bullshits; so they may not be any bad intention behind it, just various interpretations
16:23 <jirutka> huh, someone did the change in abuild I’m talking about for a year and still didn’t actually do it; I’m ashamed now :( I wanted to start with refactoring and then implement this change and that’s not an easy work so… I postponed it
16:25 <kunkku> I went just without refactoring :)
16:26 mikeee_ joined
16:26 <jirutka> yeah, that’s probably more reasonable, b/c it can be done in shorter time… or let’s say, be actually done :)
16:29 <kunkku> but let's see how people react
16:30 <jirutka> this is definitely good change, I hate writing `|| return 1` on almost every line; abuild should be run with -e since the beginning
16:31 <jirutka> I just worry if it really works as expected, b/c… read my email
16:43 <ncopa> i am tempted to just push that to git and fix things as they break ...
16:43 <ncopa> the set -e abuild thingy
16:45 <jirutka> agree, but we should review the patches first…
16:46 <jirutka> and most importantly verify that it really aborts on non-zero status inside all functions
16:47 <ncopa> the ${foo:0:1} is bashism isnt it?
16:47 <kunkku> seemed to work anyway :/
16:47 <jirutka> well, yes, but ash supports it
16:47 <jirutka> and we already use it in APKBUILDs
16:47 <jirutka> simialr to `${foo/o/x}`
16:47 <ncopa> ans we use ${foo/../..}
16:47 <ncopa> yes
16:48 <ncopa> my thinking is that we should try avoid when possible
16:48 <jirutka> hm, not sure if dash supports this syntax
16:48 <ncopa> and i think we can avoid in this case
16:48 <ncopa> i dont think it deso
16:48 <ncopa> $ dash -c 'foo=foo; echo ${foo:0:1}'
16:48 <ncopa> dash: 1: Bad substitution
16:49 <jirutka> I’ve tried it too :)
16:49 <jirutka> just about to write the same result
16:58 <ncopa> leitao: seems like static build is broken on ppc64le?
16:58 <leitao> ncopa, with musl, right?
16:58 <ncopa> yes
16:58 <leitao> gromero investigated a little bit about it.
16:58 <leitao> not sure how far he went
16:59 <ncopa> $ gcc -static hello.c && ./a.out
16:59 <ncopa> Segmentation fault
17:05 <leitao> right, it fails on every static compilation
17:05 <leitao> let's see how further gromero went, and I can dig further
17:34 leo-unglaub joined
17:34 leitao_ joined
17:35 leitao_ joined
17:48 <gromero> leitao: ncopa just far to get gdb compiled on alpine, but nothing after discovering that if is passed the problem is gone -fno-pie... I have to investigate further so...
17:48 vakartel joined
17:48 laskin joined
17:49 <gromero> *if "-fno-pie -static" is passed
17:49 <leitao> gromero, that is why I do not reproduce this problem on Debian.
17:50 <leitao> I am able to run static compiled binaries on Debian with musl. But I checked and musl-gcc is using no-pie
17:51 <gromero> leitao: makes sense. -fpie is enabled by default on alpine to improve security, but I'm not sure if it's musl issue or something also related to the loader, for instance...
17:51 vakartel joined
17:54 m4 joined
18:00 <TemptorSent> *yawn* Good morning all. Has anyone seen fabled around lately?
18:13 leo-unglaub joined
18:17 leo-ungl_ joined
18:47 <TemptorSent> WTF? Why does qemu-system-x86_64 depend on mesa/wayland?
18:48 <awilfox> TemptorSent: OpenGL guest acceleration
18:52 <TemptorSent> And why is SDL support disabled?
18:52 <awilfox> idk policy, only mechanism
18:53 <TemptorSent> *lol* Yeah... methinks a lightweight qemu may be needed.
18:54 <awilfox> qemu does not lend itself to having multiple versions installed easily, nor does it lend itself to having split deps
18:54 <awilfox> mesa is required increasingly by most X11 apps because ~compositing~ so really it is not that big of a deal to have that dep in /my/ opinion, but I am not a developer here so that is not my judgement call to make.
18:55 <TemptorSent> awilfox: Because my database server needs x11 compositing, right?
18:56 <kaniini> why does your database server need x11 at all
18:56 <awilfox> qemu is an X11 application (unless you use serial console and no vga, but I'm not sure that is even in tree any more)
18:57 <awilfox> and qemu is designed to be used to run virtual machines, some of which run windows, which needs opengl acceleration to even boot these days (thinking 7/8/10)
18:57 <awilfox> so there is actually a very good reason to have mesa as a qemu dep
18:57 <awilfox> if you are not happy with it, perhaps you could use a different virtualisation environment, such as xen pv (which does not even use qemu) or bochs (which does not support opengl)
18:58 <awilfox> not sure if alpine has a bochs package, but I know it runs a damn good xen pv host because it's doing that for me right now :)
19:04 <TemptorSent> awilfox: Yeah, I have xen working, but I happen to need qemu/kvm for several applications.
19:05 gromero_ joined
19:05 <TemptorSent> awilfox: A qemu-light package might be the easiest solution.
19:15 stwa joined
19:21 leo-unglaub joined
19:24 <TemptorSent> kaniini: Exactly -- when was the last time I actually started X on any of my servers? Granted, at some point I might end up with server-hosted applications and such, but my db server, web server, and storage server sure as hell don't need X!
19:26 <TemptorSent> Query: Is there any reason NOT to generate isolinux.cfg, syslinux.cfg, and extlinux.cfg for all images which use any flavor of syslinux on x86(_64)?
19:38 fekepp joined
19:38 Emperor_Earth joined
19:39 blueness joined
19:48 fekepp joined
19:55 czart__ joined
20:12 <kaniini> TemptorSent: why does your db server need qemu then
20:13 <TemptorSent> kaniini: for the VMs.
20:14 <kaniini> then it's a VM server, that's a different story altogether :)
20:15 <TemptorSent> kaniini: Actually, more of databases running on a VM layer -- it makes migration and such MUCH easier.
20:15 <kaniini> but sure, a vnc-only qemu may be useful
20:17 <TemptorSent> kaniini: Why do I need VNC for TEXT?
20:17 <TemptorSent> kaniini: ssh-console would be more like it :)
20:18 <mitchty> well after looking at that compiler in dyalog that runs on a gpu, be handy to have gpus generally available.
20:18 <TemptorSent> kaniini: the curses interface actualy suits nicely - being able to use the full terminal size would be a nice touch.
20:19 <kaniini> TemptorSent: 99% of the world does not use serial console
20:19 <TemptorSent> kaniini: and if we need some sort of graphics support, install a full-fledged package.
20:20 <TemptorSent> kaniini: Actually, they probably do, they just don't know it :)
20:20 <* kaniini> is generally in favor of a lightweight package still being useful to 99% of interested users
20:20 <* kaniini> does not maintain qemu though, so has no opinion
20:21 <TemptorSent> kaniini: Can you think of any vm server that really needs all the weight of supporting graphics unless it's specifically for a desktop or scientific viz?
20:22 <TemptorSent> kaniini: Most of the VM appliances I see these days are more likely than not to have a web config tool or be totally lights-out and just take config files to get them booted until you can ssh in.
20:22 blueness joined
20:24 <TemptorSent> kaniini: On a desktop, hopefully you'll be able to use PCI passthrough and have the guest use the graphics card directly if you're going to sit in front of it.
20:29 m4 joined
20:35 <kaniini> TemptorSent: 99% of people using kvm even just boot normal boot media and install using the normal GUI installer for their distro
20:47 tmh1999 joined
20:48 <tmh1999> ncopa, fabled : Hi, I sent an email earlier to the list about making Alpine s390x packages available on Alpine's official repo. How do you think about it ?
20:49 fabled joined
20:49 <tmh1999> Hi fabled
20:52 <TemptorSent> Good afternoon fabled!
20:54 <fabled> tmh1999, TemptorSent: hi, sorry i've been away few days, and came to just check few things and going again in a minute. hope to catch up on things tomorrow/the day after.
20:56 <TemptorSent> fabled: No problem, when you've got a chance I ran into a couple issues I could use a hand on.
20:57 <TemptorSent> ...and I'm currently trying to figure out why my iso is bailing out to the recovery shell in the initrd..
20:58 <TemptorSent> With a complaint of no such file or directory and invalid argument, I'm guessing a driver loading? Trying under qemu
21:00 <TemptorSent> dying on: umount: can't unmount /sysroot/proc: Invalid argument
21:02 <TemptorSent> Hmmm... is DEVICETREEDIR really supposed to be in there I wonder?
21:10 <TemptorSent> Probably not -- that's for u-boot it looks like
21:13 <tmh1999> fabled : sure we all have busy days
21:15 <TemptorSent> Bloody hell this is getting annoying. Has anyone run into the initrd bailing when trying to start using isolinux under qemu for no apparent reason?
21:30 <TemptorSent> Question: Where was 'modloop' being injected into the kernel command line again? I'm not finding it anywhere obvious.
21:40 Tsutsukakushi joined
21:40 triple joined
21:44 <TemptorSent> Hmm, time to start comparing the FS against a known release I guess.
21:46 t0mmy joined
21:47 Tsutsukakushi joined
21:47 triple joined
22:02 leo-unglaub joined
22:11 <TemptorSent> *facepalm* It *might* be a key problem... Where's my verbose option?
22:19 triple joined
22:20 Tsutsukakushi joined
22:24 _errm joined
22:24 <TemptorSent> Okay, got it to at least tell me the complaint is an UNTRUSTED signature for APKINDEX.tar.gz ... what's missing here?
22:27 laj joined
22:33 <tdtrask> TemptorSent: signing key must be in /etc/apk/keys/
22:34 <tdtrask> (public key, obviously)
22:36 <TemptorSent> tdtrask: Noted - but the other odd thing I'm seeing is an interactave request to overwrite APKINDEX.tar.gz
22:36 <TemptorSent> tdtrask: And it's not part of my code :)
22:37 <TemptorSent> tdtrask: I just went on a cleaning spree removing stale/orphan keys... let's see if that helped.
22:41 <tdtrask> TemptorSent: never seen that before, but never played in the code your replacing before
22:41 <TemptorSent> Hmm, still no joy.
22:42 <TemptorSent> tdtrask: Nothing I actually touched should have changed the signing that I can think of...
23:07 <mitchty> jirutka: when you get a chance i'm curious to have a look at your cargo integration stuff and looking into how I can get cabal doing similar
23:12 <TemptorSent> Bloody hell.. don't you hate it when variables get redefined because someone left out a check and just overwrote with the default? Doesn't show up until things run in a different order.
23:39 <TemptorSent> okay, where is this 'mv -i /path/to/output/APKINDEX.tar.gz' coming from?
23:46 <jirutka> skarnet: where is fcntl.h located on various systems? POSIX specifies fcntl.h (top-level), musl and macOS respects this, gnu has sys/fcntl.h, not sure about OpenBSD and NetBSD
23:46 <skarnet> always fcntl.h top-level
23:47 <skarnet> there's also one in gnu
23:47 <skarnet> the one in sys is probably included by the top-level one
23:47 <jirutka> aha, yes, you’re right
23:47 <skarnet> probably a legacy from before everything got standardized
23:47 <TemptorSent> Weird.. keys straightend out, but still invalid argument unmounting /proc.
23:47 <jirutka> and wait.h?
23:48 <skarnet> sys/wait.h
23:48 <skarnet> I don't think there's any logic to "is this header in top-level or in sys/"
23:49 <skarnet> you have to look at POSIX, typically http://pubs.opengroup.org/onlinepubs/9699919799/idx/is.html
23:49 <skarnet> which tells you what's supposed to be in sys/
23:52 <jirutka> thanks!
23:54 <skarnet> np :)
23:55 <TemptorSent> Bugger, I seem to have found myself another project. Is anyone else running into problems with proc not wanting to unmount in an initfs?
23:58 scadu joined