<    April 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
00:00 gromero_ joined
01:05 s33se_ joined
02:42 <Shiz> kaniini: we need to do kernel bumps for 3.3 and 3.2 as they are still affected by a bad CVE and are still supported
02:46 LouisA joined
04:47 poptart joined
05:09 BitL0G1c joined
05:27 Adran joined
07:07 andypost joined
07:32 cyteen joined
09:50 xfix joined
10:01 LouisA joined
10:04 czart_ joined
10:42 cyteen joined
11:10 Ayyad joined
12:02 vakartel joined
12:28 blueness joined
14:01 cyteen joined
14:06 Ayyad joined
14:45 blueness joined
14:50 Ayyad joined
14:50 blueness joined
14:58 blueness joined
15:07 <Shiz> tot
15:07 <Shiz> ncopa: ping
15:07 <ncopa> Shiz: pong
15:18 nmatt joined
15:22 <nmatt> hey all, I heard that alpine is planning on maintaining a grsecurity fork since it's going private. I'm starting a distro independent project to 1. upstream as much of the grsec features as possible and 2. maintain a patchset of these features that haven't made it to upstream. (https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project)
15:23 <nmatt> I welcome any contributions/comments from the alpine folks
15:39 TemptorSent joined
15:51 <ncopa> nmatt how does that differ from KSPP?
16:04 <przemoc> IIUC, HKP is about bringing grsec/pax features to the kernel. KSPP is about hardening kernel, not necessarily by merging grsec/pax features, but indeed it was mostly the case (often w/ different implementation, IIRC), so far if I'm not mistaken. so difference seems subtle so far. Kees Cook is already mentioned on HKP page as KSPP/Upstream Liaison
16:05 <przemoc> s/so far// overloaded
16:05 <Shiz> afaics, HKP intends to work with KSPP to port grsec/pax features, and maintain its own patchset where that is unfeasible or not done yet
16:05 <Shiz> correct me if I'm wrong, nmatt
16:06 Ayyad joined
16:30 <pickfire> When I tried bumping unbound to 1.6.2, I am surprised that it failed to build.
16:45 <jirutka> andypost: are you here? I need help :)
16:45 <Shiz> pickfire: time to fix build issues :P
16:46 <pickfire> Shiz: I don't like those.
16:46 <pickfire> I just hope it works.
16:47 <arch3y_> Ill do it let me take a look
16:47 <pickfire> arch3y_: Nice.
16:47 <jirutka> pickfire: welcome to real world
16:47 <jirutka> pickfire: you thought that it’s as easy as just editing single line in apkbuild…?
16:48 TBB joined
16:48 <Shiz> hey now
16:48 <arch3y_> it never is
16:48 <Shiz> there's also running # abuild checksum
16:48 <arch3y_> tahts pkgbuilding for you
16:48 <Shiz> and you may need to reset the pkgrel
16:48 <pickfire> jirutka: Yes!
16:48 <pickfire> Not even editing.
16:48 <pickfire> Just abump.
16:48 <arch3y_> so many return ones bleh
16:49 <arch3y_> got to fix all of that first
16:49 <pickfire> Shiz: Need not to run abuild checksum.
16:49 <jirutka> pickfire: we wouldn’t need any contributors for that, don’t you think?
16:49 <Shiz> well, with abump you don't
16:49 <pickfire> Just abump unbound-1.6.2
16:49 <Shiz> with manual editing you do
16:49 <* Shiz> doesn't use abump
16:49 <pickfire> I do some manual editing sometimes.
16:50 <pickfire> Just remove the _builddir old stufff.
16:50 <arch3y_> Im sure its more love then that
16:53 czart joined
16:53 blueness joined
16:56 <TemptorSent> It's always good to put eyeballs on the actual file contents and make sure everything is sane. abump just makes bad APKBUILDS build newer broken packages :)
16:56 <TemptorSent> (See the kernel modules mess from a couple days back with empty depends="" )
16:57 <TemptorSent> I still have no idea how that managed to be missed for YEARS without horribly bricking things.
16:58 <Shiz> i can tell you but i'm not sure you'd like the answer
16:58 <TemptorSent> Dumb luck?
16:58 <^7heo> lamd duck
16:58 <^7heo> s/md/mb/
16:58 <Shiz> more in the vein of 'most people dont have terrible internet that interrupts kernel+module upgrade transactions'
16:58 <Shiz> so yes, to a degree dumb luck
16:59 <arch3y_> the build issues seem to be related to flex issues pulling a fix in now
16:59 <TemptorSent> It was worse that that though, the only reason it would upgrade properly is by pure chance that all the packages in the repo were the same version at more or less the same time.
17:00 <TemptorSent> So it would also happen any time the repo was in the process of syncing too.
17:02 <TemptorSent> Yet more weight to the kernel packaging needing to be changed to reflect the kernel release in the package name.
17:02 <jirutka> TemptorSent: as I said, I’ve bricked one of my production server b/c of broken kernel just few weeks ago… fortunately I usually do snapshot of the system volume before upgrading
17:03 <TemptorSent> jirutka: Yeah, I'm guessing it was happening sporadically, but non-obvious in its cause until I looked at it and kaniini pushed fixes.
17:03 <TemptorSent> The whole -grsec -> -hardened change brought out corner cases left and right.
17:04 <TemptorSent> I think I hit every one of them too :)
17:04 <jirutka> TemptorSent: also kernel configs are currently in horrible state, it’s not modularized, so I’d be quite surprised if two kernel variants have the same flags that should be the same
17:04 <pickfire> Oh, when I am bumping poppler and poppler-qt4, I found that poppler doesn't install dependencies since texlive required the old libpoppler, how do I solve this without removing texlive to bump poppler-qt4?
17:04 <TemptorSent> jirutka: The problem was they didn't depend on the kernel even! Not to mention a version string...
17:05 <TemptorSent> So apk add zfs-hardened would happily just pull in the lastest -hardened modules for whatever the kernel version happens to be in the repo.
17:05 <arch3y_> current issue with unbound and flex https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1223 since the maintainers of flex has not released flex 2.6.4 the issue still exists
17:06 <TemptorSent> And no kernel :)
17:06 <pickfire> musl1.1.16-r8nuevaedgemainTimo Teräs2017-04-29 16:43:11
17:06 <pickfire> What?
17:06 <TemptorSent> jirutka: I've got most of a solution I think, but I could use some help with the packaging portion.
17:06 <jirutka> TemptorSent: that’s why apk/abuild should imo support ==, not just > and >=, to specify exact dependency version, not just range
17:06 <TemptorSent> jirutka: Agreed.
17:06 <pickfire> There's a new version of musl called nueva
17:07 <jirutka> TemptorSent: so kernel modules can depend on exact kernel version, not just some random or greater than
17:07 <pickfire> Looks like someone spam us, the message is asdasdd
17:07 <TemptorSent> jirutka: I've basically worked around all the apk bugs in my build system now I think, so we could use that to GENERATE the kernel packages.
17:08 <TemptorSent> jirutka: Yeah, actually the modules should depend on the exact version magic string.
17:08 <jirutka> TemptorSent: I’d perfer to fix/improve apk then workaround it… we’re not debian to workaround all the crap instead of solving underlaying problems ;)
17:08 <TemptorSent> jirutka : Yes, but the kernel still has a special place in hell because we need to maintain multiple versions at the same time.
17:09 <jirutka> TemptorSent: actually, this is not special for kernel
17:09 <jirutka> TemptorSent: for example, to upgrade PostgreSQL, you need both old and new version simultaneously…
17:09 <TemptorSent> Since I stage everything by kernel release, I can build atomically.
17:10 <jirutka> TemptorSent: this can be workarounded by adding major.minor suffix to pkgname, but…
17:10 <TemptorSent> jirutka: Right, full multislotting would be nice, but that's a major overhaul to apk.
17:10 <jirutka> TemptorSent: I know
17:11 <jirutka> TemptorSent: currently it’s probably not worth it
17:11 <Shiz> i would like slotting, but yeah it's hard
17:11 <Shiz> together with some kind of alternatives system ;p
17:11 <jirutka> TemptorSent: but once we get rid of FHS, it’d be much easier to have multiple versions of same pkg in the system, and so it’d be maybe worth to add this support to apk
17:11 <TemptorSent> For now, things like pgsql with major.minor is fine. With the kernel, the semantics are a lot uglier because we have not just version, we have flavor/custom
17:12 <jirutka> Shiz: alternative system is MUST have, we already needed it badly
17:12 <TemptorSent> jirutka: Agreed, FHS is the underlying problem that makes it hard to do right.
17:12 <Shiz> although i never liked the term 'alternative'
17:12 <jirutka> Shiz: but lack of people and time… :/
17:12 <jirutka> Shiz: me neither
17:12 <TemptorSent> I sorta have that at image build time, and it could be adapted to system use I think.
17:13 <jirutka> anyway, I’d like to fix that damn php and then get some rest for today
17:13 <TemptorSent> Such as you can choose which ntp provider, which ssh provider, etc.
17:13 <Shiz> we already kind of do that
17:13 <TemptorSent> And it builds configureation for and activates the specified one in the overlay.
17:13 <Shiz> APKBUILDs can provide= a virtual
17:14 <Shiz> it's more of a file basis
17:14 <TemptorSent> Yeah, we can probably work a combination of that for deps, and what I'm working on for scripts to make selecting providers doable.
17:15 <TemptorSent> With 'features' being the term I'm currently using.
17:16 <TemptorSent> such as 'feature ntp provider=chrony' in a config file.
17:17 <TemptorSent> So once the FHS mess is gone, parallel features can work with little or no pain.
17:18 <TemptorSent> Just have apk build a providers manifest and pick the one you want :)_
17:18 <TemptorSent> That should allow solving the UI problem at the same time.
17:21 <arch3y_> devs how do you handle libtool issues like https://gist.github.com/archey/dfe871871f9ac571d0223d53adb7acd9
17:22 <Shiz> ignore them
17:22 <arch3y_> umm ko
17:22 <Shiz> since right after it's already ran
17:22 <Shiz> as from your log
17:22 <Shiz> :P
17:22 <Shiz> mostly it's irrelevant afaik
17:22 <arch3y_> k then Ill push the fix for unbound to upgrade to 16.2
17:23 Emperor_Earth joined
17:26 <pickfire> I guess I need to sleep soon, it's so late now.
17:26 <pickfire> But still libreoffice haven't finished building for like an hour.
17:29 <arch3y_> k pr pushed
17:31 blueness joined
17:31 <arch3y_> see pickfire that took about five mins to fxi lol
17:31 <arch3y_> sometimes the bad builds can be simple to resolved
17:32 <TemptorSent> jirutka: BTW, speaking of pgsql, do you know off hand who's doing the work there?
17:33 <jirutka> TemptorSent: yes
17:34 <TemptorSent> jirutka: It looks like some work is needed to clean it up, which I might attack if it's not already in the works.
17:34 <jirutka> TemptorSent: what exactly?
17:34 <TemptorSent> Mostly in terms of deps IIRC, as well as extensions.
17:35 <jirutka> TemptorSent: interesting, I haven’t recognized any problem with deps and extensions
17:35 <TemptorSent> I was working on the postgis stuff and hit some oddities.
17:35 <jirutka> postgis is a quite different beast
17:35 <TemptorSent> python I think was one.
17:36 <jirutka> oh crap, why the heck postgresql-python3 does not declare dependency on python3
17:36 <TemptorSent> Yeah, I know - but the postgres packaging may need a couple tweaks to make extensions saner.
17:36 <TemptorSent> Yeah, that kind of stuff :)
17:36 <jirutka> s/postgresql-python3/postgresql-plpython3/
17:36 <jirutka> I’ve probably overlooked that
17:36 <TemptorSent> Like I said, I hit the corner cases ;)
17:37 <Shiz> actually
17:37 <jirutka> this is not a corner case, but simple bug :)
17:37 <Shiz> most python packages don't have a dep on python3
17:37 <Shiz> i thought that was policy
17:37 <jirutka> Shiz: py3-* pkgs?
17:37 <Shiz> yeah
17:37 <TemptorSent> Breaks building things because python3 never gets installed!
17:37 <jirutka> no, it’s not policy
17:38 <TemptorSent> So when I was trying to get the postgis stuff working, it failed on python.
17:38 <jirutka> okay, I’ll add that to my todo list and look at it soon
17:38 <TemptorSent> PostGIS is a bigger mess yet.
17:38 <TemptorSent> No worries, just wanted to know if it something I needed to look into :)
17:39 <TemptorSent> When I get back to poking at PostGIS, I'll see if anything else turns up sideways.
17:40 <TemptorSent> The gdal stuff is where it gets really ugly, and I'm not sure what to do about packaging because of all the proprietary crap.
17:41 <jirutka> it’s weird that python2 is autodetected via dynamic links and python3 is not
17:41 <TemptorSent> MrSID, JP2000, ECW, etc.
17:41 <TemptorSent> Probably and artifact of the py2/3 split somehow.
17:42 <TemptorSent> That's a whole mess in and of itself too :/
17:42 <jirutka> don’t think so, postgresql-plpython3 contains plpython3.so, that lib should depend on python3 lib
17:43 <Shiz> my build box is broken lol
17:43 <Shiz> [168216.126675] hrtimer: interrupt took 316183800 ns
17:43 <TemptorSent> Hmm, does the dep show with search?
17:43 <Shiz> [171445.337551] make[1053]: unhandled level 0 translation fault (11) at 0x00000048, esr 0x92000004
17:43 <Shiz> randomly
17:43 <TemptorSent> Well THAT'S not good Shiz. Bad instruction?
17:43 <Shiz> no, it just randomly happens
17:43 <TemptorSent> Memory okay?
17:43 <Shiz> who knows...
17:44 <TemptorSent> Core temps?
17:44 <TemptorSent> You DON'T run ECC?
17:44 <Shiz> it's ARM
17:44 <Shiz> what ECC lol
17:44 <TemptorSent> Ahh.
17:44 <TemptorSent> Hmm, Don't some of the ARMs support ECC these days too?
17:45 <Shiz> probably not this one
17:45 <Shiz> and translation faults shouldn't be related to bad memory
17:45 <Shiz> except if the bad memory somehow corrupts the paging table
17:45 <TemptorSent> Anyway, check the physical variables -- I've seen that sort of behavior most often from overheating or poor contacts.
17:46 <TemptorSent> Yeah, my memory controller on my i7 cooked and started doing that.
17:46 <TemptorSent> Every time it was under load, it would start corrupting pages.
17:47 <TemptorSent> Any dmesg entries?
17:49 <Shiz> just that
17:49 <TemptorSent> What chip/board?
17:49 <TemptorSent> I'll check for a HW errata.
17:50 <Shiz> thunderx t88
17:50 <Shiz> none exist that i know of
17:50 <TemptorSent> Ahh, pass 1 or pass 2?
17:51 <Shiz> 2
17:52 <TemptorSent> Check google, looks like some stuff required to differentiate the two versions, don't know if it's mainline.
17:53 <TemptorSent> There is an erata -- 'Cavium erratum 27456'
17:54 <Shiz> i know it's pass 2 :P
17:54 <Shiz> yeah, just no public errata
17:56 <TemptorSent> Google "CAVIUM_ERRATUM_27456"
17:57 <TemptorSent> Broadcast TLBi instruction may cause the icache to become invalid
17:57 <TemptorSent> Check your .config :)
17:59 <TemptorSent> It's less than a dozen lines each in the cpu_errata.c and proc.S files.
18:00 <pickfire> What does that mean?
18:00 <pickfire> ERROR: unsatisfiable constraints:
18:00 <pickfire> x265-2.3-r0:
18:00 <pickfire> breaks: x265-dev-2.4-r0[x265=2.4-r0]
18:00 <pickfire> satisfies: world[x265] ffmpeg-libs-3.2.4-r1[so:libx265.so.110]
18:00 <pickfire> arch3y_: How do you fix it?
18:01 <TemptorSent> Erratum looks like a good possibility for a match to your error.
18:01 <pickfire> TemptorSent: Huh?
18:01 <TemptorSent> That's re Shiz: above :)
18:01 <pickfire> arch3y_: Can I see how do you fix it?
18:01 <TemptorSent> He doesn't like me highlighting him every line.
18:02 <pickfire> Ah
18:02 <Shiz> TemptorSent: neat, thanks
18:02 <TemptorSent> NP, tracking down HW bugs is something I have too much practice with ;)
18:02 <pickfire> arch3y_: Just bump me the link, need to sleep.
18:04 <Shiz> yeah it has all the errata
18:04 <Shiz> enabled
18:04 <TemptorSent> Manufactures hate me -- I triggered a couple major bugs that led to a popular PLC not properly reading the first contact closure and proceedign to ignore the press of a stop button!
18:05 <TemptorSent> Hmm, up your kernel debug level and see if you can track it down a bit.
18:05 <TemptorSent> Might have to drag out the debugger.
18:06 <pickfire> Should I just do git send-email -2?
18:06 <TemptorSent> Do you have a logic probe that can keep up with the address lines?
18:07 <pickfire> ?
18:07 <TemptorSent> Sorry pickfire, ^^ RE: Shiz again.
18:07 <* pickfire> is sending it
18:07 <pickfire> Okay.
18:07 <arch3y_> pickfire: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0
18:08 rdutra joined
18:08 <TemptorSent> Shiz: If you can find a reproducer, punt it back to the HW manufacture to fix and distribute.
18:08 <pickfire> arch3y_: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR31
18:08 <pickfire> Where do you even search that?
18:09 <pickfire> By the way, what is --enable-pie?
18:09 blueness joined
18:09 <pickfire> And --enable-relro-now
18:09 <TemptorSent> pickfire: pie is a position independent executable
18:09 <Shiz> it enables position-independent code and read-only bind-fast relocations
18:09 <Shiz> hardening features
18:09 <arch3y_> yes
18:09 <arch3y_> thanks for answering faster lol
18:09 <pickfire> Do we not need || return 1?
18:09 <Shiz> not anymore
18:09 <arch3y_> no we dont
18:09 <arch3y_> and Im so gald
18:09 <Shiz> in edge, apkbuilds are set -e by default
18:09 <arch3y_> err glad
18:09 <pickfire> Nice
18:09 <Shiz> so they exit on error automatically
18:10 <pickfire> I doesn't know about that.
18:10 <pickfire> I thought need to wait for 3.6
18:10 <TemptorSent> Although you may still want to use them for semantic clarity where you're checking conditions or failing.
18:10 <arch3y_> all pkgs are built on edge as I understand it
18:10 <Shiz> arch3y_: no
18:10 <arch3y_> I will not be using them
18:11 <Shiz> packages are built for edge on edge, and for stable branches separately
18:11 <Shiz> those are the 3.x-stable branches of the aports git repo
18:11 <arch3y_> makese sense
18:11 <pickfire> arch3y_: https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR63
18:11 <arch3y_> yep yep
18:11 <pickfire> Why do you even do a line that is so long?
18:11 <pickfire> It's beginning to look like PKGBUILD
18:11 <TemptorSent> arch3y_ as in '[ -e "$file" ] || return 1', as opposed to just '[ -e "$file" ]'
18:11 <arch3y_> becuase it is a pkgbuild lol
18:12 <pickfire> APKBUILD*
18:12 <Shiz> pickfire: you mean the sha512sums?
18:12 <Shiz> those are generated by abuild checksum
18:12 <pickfire> Shiz: No, I mean the column is over 100
18:12 <Shiz> that's just how long sha512sums, can't really break them up
18:12 <pickfire> https://github.com/alpinelinux/aports/pull/1335/commits/f1275f31bb501ca14fb290f4ed3df7a4d1e513f0#diff-15f5d130ed00181fc2da878844f5cd3cR63
18:12 <Shiz> oh i was looking at the wrong line
18:12 <pickfire> Not sha512sum
18:12 <arch3y_> and personally I dont like all of the \ lines it just looks weird to me
18:12 <Shiz> yeah some linebreaks would help probably
18:12 <arch3y_> but if thats style changes you guys want then Ill comply or stop comitting lool
18:13 <pickfire> lool
18:13 <arch3y_> how would the line breaks help
18:13 <pickfire> So basically just `export LEX=:`
18:13 <TemptorSent> I tend to let the editor/pager do the line-breaking and try to lay it out so it's clear broken or not (less -S)
18:13 <arch3y_> yep
18:13 <pickfire> arch3y_: It helps to read.
18:13 <arch3y_> well I have eyes
18:13 <pickfire> Doesn't hurt my eyes.
18:13 <arch3y_> so I use them to read
18:13 <pickfire> arch3y_: Use them wisely.
18:14 <arch3y_> well we are of differing opinions the \ hurt my eyes
18:14 <arch3y_> I do
18:14 <pickfire> Then that just look like arch's PKGBUILD.
18:14 <arch3y_> exactly
18:14 <pickfire> They have like over 100 for each line.
18:14 <arch3y_> these are basically pkgbuilds with a fiw differences
18:14 <TemptorSent> I can't stand having line breaks at 80 cols -- I develop on the console and have 240 columns.
18:15 <arch3y_> look if guys dont like it dont accept the commit and we can move on
18:15 <pickfire> Mine have like 87.
18:15 <TemptorSent> pickfire Use something that does sane line-wrapping :)
18:15 <TemptorSent> Also, leave spaces between long lines so the wrap is distinct from the line below.
18:15 <pickfire> Well, I just don't like it. Not saying not to accept the commit. The commit itself is nice.
18:16 <arch3y_> style is definetly a personal choice for sure
18:16 <pickfire> TemptorSent: Yeah.
18:16 <pickfire> arch3y_: Maybe because I use neovim here?
18:16 <TemptorSent> pickfire: You should consider tuning your tools to your needs rather than the code.
18:16 <arch3y_> I dont know I use straight up vim with very little options
18:16 <TemptorSent> I'm on standard vim.
18:17 <pickfire> Same.
18:17 <TemptorSent> No options, nothing fancy.
18:17 <arch3y_> but yes Im used to building pkgbuilds so my commits will look like pkgbuilds
18:17 <pickfire> I do some options, just like some color change.
18:17 <arch3y_> but to me its clean and it builds nicely so what does it matter
18:17 <pickfire> Or sometimes I use kak, rarely vis
18:17 <pickfire> They don't do wrap.
18:17 <arch3y_> just my opinion though
18:17 <TemptorSent> Yeah, I get sick of copying settings between accounts and machines, so I'm pretty much used to the stock config.
18:17 <pickfire> Ah
18:18 <arch3y_> me too
18:18 <pickfire> TemptorSent: Don't store dotfiles?
18:18 <TemptorSent> Nope, I log in to machines all over the place with no common anything.
18:18 <pickfire> Wow,
18:19 <pickfire> I sometimes use vim without config, the blue is just too dark here since my brightness is low and st have dark blue.
18:19 <pickfire> st - simple terminal
18:20 <TemptorSent> You think that's bad, wait 'till you log into an older solaris box and try to remember how to not break it with their weird vi oddities.
18:20 <TemptorSent> I'd fix the color definition in st then!
18:20 <pickfire> Ah
18:20 <TemptorSent> Use the right layer of abstraction ;)
18:21 <pickfire> :)
18:21 <pickfire> By
18:21 <pickfire> e
18:21 <TemptorSent> Because that way, you fix it EVERYWHERE the blue is too dark to read.
18:24 <TemptorSent> In fact, it looks like you can use an iterm2 color scheme and convert it with st...
18:26 <TemptorSent> pickfire: See http://st.suckless.org/migrating
18:28 blueness joined
18:28 <^7heo> well you can setup a highlight group in vi
18:28 <^7heo> with a regex
18:28 <^7heo> works in any terminal
18:29 <Shiz> jirutka: ^7heo: do we have a check() policy for prohibitively long unit tests?
18:29 <Shiz> i'm looking at grpc's testing infra and their complete tests take an hour to complete
18:29 <^7heo> noch niht
18:29 <^7heo> nicht
18:29 <Shiz> WAITING: ETA 2848.9 sec; 3477 queued, 1 jobs running, 158 complete, 0 failed
18:29 <^7heo> wow
18:29 <TemptorSent> ^7heo: Yeah, the issue at hand is that when logging into different boxes at random, keeping vim highlighting in sync is a pita.
18:29 <^7heo> yeah that's long
18:30 <jirutka> Shiz: check() is intended for integration tests, no unit tests; it doesn’t make much sense to run unit tests in pkgs
18:30 <Shiz> right
18:30 <^7heo> TemptorSent: nah it's fine as long as you do it from the vimre
18:30 <^7heo> rc even
18:30 <Shiz> jirutka: it's more that it's all the same for grpc
18:30 <Shiz> :P
18:30 <jirutka> Shiz: hm, typical fucked up tests…
18:30 <^7heo> and AFTER you load the colorscheme
18:30 <TemptorSent> And that having colors too dark to read on your terminal isn't too useful, so fix the terminal color scheme first.
18:30 <^7heo> yeah
18:30 <Shiz> jirutka: i'll try to see if interop tests between C and C++ suffices
18:30 <jirutka> Shiz: so no options to run just a subset?
18:31 <TemptorSent> ^7heo: I tend to log into boxes that have no common files or are freshly built more often than not, so I've just gotten used to the vim defaults.
18:33 <^7heo> In a company that was popping up new boxes every other hour, I actually configured ssh to send a command before connecting; so to probe for a file or setup my home
18:34 <^7heo> that was a bit hackish but handy
18:34 <^7heo> ofc the best is to have the ops team adding your files therw
18:34 <^7heo> there
18:34 <Shiz> >>> grpc: Entering fakeroot...
18:34 <Shiz> Running interop servers is only supported with --use_docker option enabled.
18:34 <Shiz> fucking grpc
18:35 <jirutka> it’s Google’s project, so…
18:35 <jirutka> don’t expect any good habits ;)
18:59 TemptorSent joined
19:08 consus joined
19:20 _ikke_ joined
19:25 <^7heo> guys
19:25 <^7heo> I updated my Alpine
19:25 <^7heo> it won't boot
19:25 <^7heo> it's stuck into a dhcp loop
19:26 <^7heo> and won't boot until I deactivate all my interfaces from the BIOS
19:26 <Shiz> wut
19:26 <^7heo> yep
19:30 <^7heo> So yeah
19:31 <^7heo> quite annoying
19:32 <^7heo> I mean, as long as I can deliver a DHCP answer to the dhcpd it's fine
19:33 <^7heo> but if I do not, it's stuck in a loop of dhcp requests
19:35 TemptorSent joined
19:35 <TemptorSent> Question - Is anyone aware of any libs ending in anything other than .a .so or .so.* that need to be dep-tracked?
19:37 <Shiz> .rlib
19:37 <TemptorSent> Got it, thanks.
19:38 <TemptorSent> That's the extension right, no following version?
19:38 <Shiz> afaik, yes
19:39 <TemptorSent> tag of 'librust:' okay?
19:40 <TemptorSent> (others currently being tagged ast 'libso:' and 'liba:')
19:41 leitao joined
19:41 <TemptorSent> And do we have any binary deps that aren't either the target of the shebang or the output of objdump -p | grep NEEDED?
19:42 fabled joined
19:44 <Shiz> 'libso' seems somewhat... double
19:44 <Shiz> :P
19:45 <TemptorSent> Yes, but for a tag it's much clearer than just so:, and makes it easy to grab all libs by just greping for lib.*:
19:45 <jirutka> TemptorSent: but we already use tag “so:”
19:46 <jirutka> TemptorSent: what are you doing?
19:46 <TemptorSent> I'm trying to determine how much of lddtree I really need, because it seems a bit messy.
19:46 <TemptorSent> jirutka: Creating an index of files vs. checksums, then building the deptree of checksums for each lib, then buildning the complete deptree.
19:47 <jirutka> abuild (https://github.com/alpinelinux/abuild/blob/master/abuild.in) already contain code for tracking deps
19:47 <TemptorSent> jirutka: Which I can then dep the binaries against and have their full deptree.
19:47 <jirutka> I think that this part is worth separating out of abuild and reimplementing in Lua or C
19:47 <jirutka> it’s quite complex for shell script and currently quite slow, b/c shell…
19:48 <TemptorSent> I actually got it up to reasonable speed and minimal complexity in shell..
19:48 <jirutka> so you may start with this :)
19:49 <jirutka> but pls stop reinventing wheels, apk/abuild already define tags like so:
19:50 <TemptorSent> jirutka: Hmm, looking at it I don't think what I have works quite the same way...
19:50 <jirutka> TemptorSent: you’re looking at it for the first time now?!
19:52 <TemptorSent> jirutka: I hadn't stumbled across that particular file while looking at my deps -- everything else is using lddtree that I encountered in mkinitfs
19:52 <TemptorSent> Also, I think mine is potentially MUCH faster
19:52 <jirutka> please, get familiar with that we already have *before* reimplementing it…
19:53 <TemptorSent> jirutka: I've been trying to -- lack of documentation is somewhat problematic, because I have no idea what's implemented where.
19:53 <jirutka> yes, lack of documentation is a problem
19:54 <jirutka> but if you’ve created at least one apkbuild, then you should now that there’s some sort of deps tracking ;)
19:54 <TemptorSent> jirutka: What I'm doing in my implementation is building the manifest and index, the resolving on that.
19:55 <jirutka> as i said, the current impl. in abuild is complex and slow, so if your is better, it’s worth separting it into a standalone module/script and using it even from abuild
19:55 <TemptorSent> Yeah, I didn't realized it was pulled out in abuild in that manner -- I thought there was some apk magick involved in the resolution.
19:56 leott joined
19:56 <TemptorSent> Yeah, that's where I'm heading with it.. If we can get proper manifest support in apk, it can be downright fast with a bit of c for tooling.
19:56 leott left
19:57 <TemptorSent> I run it as multiple phases, first manifest, then index, then index-deps, then tree-deps, then extract subset by simple grep -f
19:58 <TemptorSent> Hmm, .c32 is a nosys lib right?
20:00 <Shiz> what do you mean by nosys
20:00 <TemptorSent> abuild.in is 2358 lines... yeah, that might be why I didn't find it on first glance.
20:00 <TemptorSent> Raw libs with no crt or system libs linked.
20:00 <TemptorSent> grub/syslinux
20:00 <TemptorSent> What's a proper name for them?
20:00 <jirutka> TemptorSent: yes, it’s awfully long and quite big part of it is deps tracking and related code
20:01 <TemptorSent> jirutka: At least the libs/bin deps I have in a few hundred lines, including extracting subsets.
20:01 <jirutka> few hundred?!
20:02 <TemptorSent> jirutka: Yeah, I think so...
20:02 <TemptorSent> I have some convenience functions that help knock that down.
20:03 <TemptorSent> Multipass parsing makes it much more tractable, as I had a bloody mess before when I was trying to use lddtree-like semantics.
20:04 <jirutka> i mean few hundreds is not small amount…
20:04 <TemptorSent> A couple short awk scripts do most of the ulgy work.
20:05 <^7heo> So, I boot my machine, it starts the initramfs-grsec with some files (is the initramfs-grsec the whole image that gets loaded in ram?)
20:05 <^7heo> and then it starts my kernel with the openrc init.
20:06 <^7heo> I guess the openrc is what starts my network; so where should I look to find the scripts that actually do that?
20:06 <TemptorSent> It's not perfect, but it seems to work pretty well, is reasonably fast, and the complexity is limited.
20:06 <TemptorSent> It handles link tracking, package tracking, etc.
20:07 <TemptorSent> ^7heo /etc/init.d/networking IIRC
20:08 <TemptorSent> ^7heo ifup
20:09 <jirutka> ^7heo: /etc/init.d/networking (you can symlink it to net.<devname>), reads /etc/network/interfaces, uses busybox ifup or something like that
20:10 <TemptorSent> jirutka: Looks like ~500 lines for the whole thing, including subsetting.
20:11 <^7heo> jirutka: thanks
20:11 <jirutka> ^7heo: yw
20:12 <TemptorSent> jirutka: And that generates the manifest, the lib and bin index, the lib and bin deptrees, and the subsets of each.
20:13 <TemptorSent> jirutka: The kernel modules I have tracked similarly, with full sanity checking -- I'm working on integrating everthing common into one tool then using that for both functions.
20:14 <TemptorSent> Basically, given an index and an unresolved list of deps for each entry, it will generate a resolved complete deptree for each entry.
20:15 <TemptorSent> Figuring out exactly how we want the semantics to work is about all that's left.
20:16 <TemptorSent> Doing pkgconfig should be a few dozen lines more.
20:16 <TemptorSent> Essentially, if we can generate a list of deps for a given file, it solves the rest.
20:17 <TemptorSent> Anyway, I need to get running errands, so I'm out for the day.
20:18 <TemptorSent> (line count includes comments/blanks, not sloc)
20:33 trn joined
20:40 stf joined
20:43 <^7heo> Wait, openrc is distributing scripts?
20:43 <^7heo> We're not using the alpine scripts?
20:43 <Shiz> ?
20:43 <Shiz> the initscripts are a combination of alpine and openrc scripts
20:44 <Shiz> networking is alpine iirc
20:44 <^7heo> https://github.com/OpenRC/openrc/blob/master/init.d/network.in
20:44 <^7heo> looks like it's OpenRC's to me.
20:44 <Shiz> doesn't look like that to me
20:44 <^7heo> oh wait
20:44 <^7heo> networking.initd
20:44 <^7heo> I see.
20:44 <^7heo> I didn't see networking in there, sorry.
20:54 <jirutka> ^7heo: actually I’d prefer OpenRC network scripts (called netifrc), they are more flexible than this debian-like thing
20:55 <Shiz> netifrc isn't part of openrc, it's a separate thing
20:55 <^7heo> I dunno; I really have to look in what's wrong with mine.
20:55 <^7heo> because if it's a bug affecting other people...
20:57 <^7heo> It's not guaranteed that most users would know how to de-activate their ethernet interface...
20:58 <^7heo> let alone it being possible.
21:01 <Shiz> anyone here that can shed some light on how the go/ghc bootstrapping works?
21:01 <Shiz> im looking at whats needed for rust
21:09 <rdutra> ncopa: leitao: can you take a look at this PR please https://github.com/alpinelinux/aports/pull/1336 ?
21:14 <leitao> rdutra, sounds good for me
21:29 <jirutka> Shiz: I’m afraid that fabled (and maybe ncopa) is the only one who know it… :/
21:33 asie joined
21:37 <fabled> Shiz, it is a cross-build. basically scripts/bootstrap.sh builds the initial compiler
21:37 vakartel joined
21:37 minimalism joined
21:37 <Shiz> yeah, i get as much
21:37 <Shiz> i'm just confused how go-bootstrap relies on go and go relies on go-bootstrap
21:37 <Shiz> :P
21:37 <fabled> oh
21:38 <fabled> that's legacy on Go part
21:38 <fabled> the reason is
21:38 <fabled> for x86_64, we bootstrap Go using go-bootstrap package. it can be built with gcc present only
21:38 <fabled> it's old Go
21:38 <fabled> one of those that did not require Go to build Go
21:38 <Shiz> ah right
21:38 <fabled> for pretty much all other architectures
21:38 <fabled> it's bootstrap.sh cross-building go package
21:38 <fabled> now because there's two flavors
21:39 <fabled> go makedepends on go-bootstrap
21:39 <fabled> but also provides it
21:39 <jirutka> fabled: Shiz: maybe ghc-bootstrap is more closer example?
21:39 <fabled> yes
21:39 <Shiz> so the situation for rust is
21:39 <fabled> ghc for x86_64 was bootstrapped from non-alpine host
21:39 <Shiz> right
21:39 <fabled> and manually installed to edge builders
21:39 <Shiz> yeah that's similar to what we 'want' rust to do
21:39 <fabled> other architectures were cross-built
21:40 <jirutka> fabled: could you please exmplain how exactly it work? how is this -bootstrap pkg build (as all other or somehow specially?), how cross-compilation is handled etc.
21:40 <fabled> -bootstrap package exist only for go
21:40 <jirutka> and ghc
21:40 <jirutka> ghc-bootstrap
21:40 <fabled> that's historical then, it's not used
21:41 <jirutka> omfg
21:41 <Shiz> :P
21:41 <jirutka> why we have historical bloat in repository that is actually not used?
21:41 <jirutka> so ghc-bootstrap can be removed?
21:41 <fabled> yes
21:41 <Shiz> fabled: is there any automation on how ghc is bootstrapped on a non-alpine host?
21:41 <jirutka> great, at least I haven’t wasted my time with review yet
21:41 <Shiz> any scripts out there etc
21:41 <Shiz> or does the non-alpine host also use the APKBUILD
21:41 <fabled> i think i wanted to keep it around until we have ghc in a stable release
21:41 <jirutka> so how exactly is it bootstrapped?
21:42 <fabled> i think ghc bootstrap was basically
21:42 <fabled> - make docker image that builds initial build that can target musl/alpine
21:42 <fabled> - export tarball
21:42 <Shiz> right, but is that automated anywhere?
21:42 <fabled> - apkbuild just rewraps tarball to apk
21:42 <jirutka> I wanted to move ghc into community already, but I thought that ghc-boostrap must be moved with that and it’s quite huge and messy, so I postponed review
21:42 <Shiz> or was that just someone's manual work
21:42 <Shiz> :P
21:42 <fabled> that's what ghc-bootstrap did
21:43 <fabled> or does (though arch="" now; so it's effectively disabled)
21:43 <jirutka> yes and how is it bootstrapped now, if ghc-bootstrap is not used at all?
21:43 <fabled> it's not
21:43 <jirutka> not?
21:43 <fabled> it's self-dependent like gcc
21:43 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/testing/ghc-bootstrap/APKBUILD
21:43 <Shiz> ah yes i see now
21:43 <fabled> for new architectures it's bootstrapped via bootstrap.sh cross-compiling it
21:43 <jirutka> so you need existing alpine pkg to build next one?
21:43 <fabled> yes
21:43 <jirutka> aha
21:43 <jirutka> someone told me that this is exactly what we don’t want in Alpine
21:43 <fabled> same as with all compilers that are written in the same language
21:44 <jirutka> so it’s not true?
21:44 <fabled> we can't avoid it
21:44 <jirutka> then we don’t need rust-bootstrap at all…
21:44 <fabled> no
21:44 <fabled> we may need to do same with java in future
21:44 <fabled> gcc is dropping gcj
21:44 <jirutka> currently we use prebuilt binary from VoidLinux for bootstrapping and we already have our Alpine binary now, so we can use it to build another rusts
21:44 <Shiz> :)
21:44 <Shiz> we do need a rust-bootstrap package
21:45 <Shiz> so it can be provided by rust and makedepended on
21:45 <Shiz> for the sake of the cross build
21:45 <fabled> not necessarily
21:45 <jirutka> why? it’s not needed for ghc…
21:45 <Shiz> well i mean
21:45 <Shiz> we need it in name
21:45 <fabled> i'm ok if we just hand build first rust
21:45 <Shiz> jirutka: it is though
21:45 <Shiz> jirutka: https://git.alpinelinux.org/cgit/aports/tree/testing/ghc/APKBUILD#n23
21:45 <fabled> inject it to builder, and then push the apkbuild
21:45 <Shiz> that sounds hacky....
21:45 <fabled> other/new architectures can be then just cross-built
21:45 <fabled> not really
21:45 <jirutka> Shiz: I guess that this is yet another unused legacy noise… isn’t it?
21:45 <fabled> that's how it's done
21:46 <Shiz> jirutka: i don't think it is
21:46 <Shiz> as I understand it, first the actual ghc-bootstrap package was used to get a working package
21:46 <Shiz> but in newer cycles the ghc package provides ghc-bootstrap
21:46 <Shiz> (see provides= in the ghc package)
21:46 <fabled> yes, the makedepends/provides of ghc-bootstrap is legacy now
21:46 <Shiz> since the build host does need ghc
21:46 <fabled> we could drop provides, and makedepends=ghc
21:46 <Shiz> right
21:48 <jirutka> fabled: please, please, can you document at least briefly this stuff? we’ve already wasted some time trying to figure out how to do that based on ghc-bootstrap etc.
21:48 <fabled> you have irc-log now :)
21:48 <fabled> but yeah
21:48 <jirutka> fabled: there’s not even stupid one line comment in ghc-bootstrap explaining that it’s not used
21:48 <jirutka> fabled: no, irc log is not a documentation
21:48 <jirutka> fabled: no one will find it in future
21:49 <fabled> well
21:49 <jirutka> so right now we can move rust to community, then (?) remove dependency on binaries from Void and add rust to makedepends, right?
21:49 <fabled> the thing is that not often we get language that depend on themselves
21:50 <jirutka> well, but cross-compiling is not so uncommon and this is also totally undocumented…?
21:50 <fabled> also there's a gotcha on moving from testing -> community
21:50 <fabled> since community can't depend on testing
21:50 <jirutka> I know, that’s why I suggested to first move it, build with prebuilt binaries from Void and then drop them
21:51 <fabled> yes
21:51 <fabled> if that works now
21:51 <fabled> then it's good
21:51 <jirutka> yes it works
21:51 <fabled> i'm ok doing that
21:51 <jirutka> okay, I’m gonna do it right now :)
21:51 <jirutka> and then open a whine XD
21:51 <fabled> i think we should keep ghc-bootstrap until ghc is in community
21:51 <jirutka> wine
21:52 <fabled> i'm hoping we can support cross-building better in future, and document it
21:52 <fabled> so far it's been implemented only to the extent of bootstrapping new arch
21:52 <jirutka> another question, how to cross-compile rust to other arches using abuild?
21:52 <fabled> use bootstrap.sh for now
21:52 <fabled> apkbuild needs to support cross-building for that
21:52 <jirutka> okay, I’ll look at it
21:52 <fabled> currently we don't ship cross compilers
21:53 <fabled> another thing i hope we can change in future
21:53 <jirutka> just for sure, these cross variables and other stuff in ghc abuild, are they actually used…? :)
21:53 <fabled> bootstrap.sh basically does that for you
21:53 <fabled> yes
21:53 <fabled> read bootstrap.sh
21:53 <fabled> it basically executes "CHOST=<targetarch> abuild foo"
21:53 <fabled> in predetermined order
21:53 <jirutka> Shiz: hm, we have still disabled rust tests
21:53 <fabled> it triggers lots of stuff happen
21:54 <fabled> it sets up environment variables for cross-building
21:54 <fabled> and abuild also handle makedepends_* differently
21:54 <Shiz> so, the nice thing about the rust APKBUILD is
21:54 <fabled> cross-building is a chapter of it's own. especially for gcc.
21:54 <Shiz> with some teeny tiny changes you could run it on a glibc host with apk/abuild installed
21:54 <Shiz> and cross-compile it :)
21:54 <Shiz> (and these are actually very minor changes)
21:54 <jirutka> Shiz: yes
21:55 <Shiz> jirutka: want me to make these changes?
21:55 <jirutka> Shiz: but since fabled said that it’s not needed and I hope that upstream will someday finally provide prebuilt binary of rustc that is actually portable or linked against musl, then I’d prefer to not waste time with that
21:56 <Shiz> ok
21:56 <jirutka> Shiz: could you please try to run uncomment check() in rust pkg and try to run them?
21:56 <Shiz> sure
21:56 <Shiz> running
21:57 <jirutka> btw i found out that php is broken even more than i thought, when I try to run tests, all fails b/c of linking problem; it seems that some extensions does not work when built as shared…
21:59 <jirutka> fabled: thanks for the information! we’ll look at bootstrap.sh
22:00 <fabled> thanks for your work too... i'm surprised how many new self-hosting compilers there are around
22:01 <Shiz> too many
22:01 <Shiz> :(
22:01 <fabled> yeah
22:01 <fabled> and it's sad that in some cases they have no idea how to make it bootstrappable
22:01 <Shiz> even rust's package manager needs to be bootstrapped
22:01 <Shiz> it uses itself to build itself
22:01 <Shiz> :/
22:01 <jirutka> fabled: yes; and you don’t wanna know how many issues in rust build system Shiz fixed to make it even work :(
22:02 <fabled> i looked that we do carry a bunch of patches... indicating someone banged their head a lot on it
22:02 <fabled> so kudos
22:08 <Shiz> btw: does $CARCH reflect builder or target?
22:12 <kaniini> target
22:12 <kaniini> CHOST reflects builder
22:13 <kaniini> erf
22:13 <kaniini> no
22:13 <kaniini> CHOST reflects target
22:13 <kaniini> CBUILD reflects builder
22:14 <Shiz> may need to do a small edit to the rust apkbuild then
22:14 <Shiz> i need to get the builder arch
22:58 Ahrkor joined
23:15 blueness joined
23:50 jirutka joined