<    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 _2_4 25  
26 27 28 29 30 31
00:02 <TemptorSent> Hmm, segfaulting apk again, this time no apparent reason.
00:06 <TemptorSent> strace shows it dying following openat etc/apk/repositories.d
00:10 <TemptorSent> forcing --repositories-file causes it to crash trying to find keys, specifying --keys-dir leads to crash trying to read APKINDEX caches...
00:15 <mitchty> is adding a test suite worth bumping the release field?
00:44 <^7heo> clandmeter: why not mosez? AFAIK he does the job of leading it
00:47 blueness joined
00:51 <mikeee_> so… what license is Alpine available under? asking for a friend.
00:51 <^7heo> the microsoft EULA
00:51 <TemptorSent> Weird - apk throwing "BAD FILE DESCRIPTOR"
00:55 <TemptorSent> Found I think -- attempting to use --output to a new, non-existent directory.
00:55 <TemptorSent> Should either throw a "directory not found" error or create the directory.
00:58 <Shiz> mikeee_: it's a distro, there's no single unified license
00:58 <Shiz> it's the various licenses its packages consist of
00:58 <Shiz> all of the alpine-specific stuff like apk and alpine-conf etc are bsd/mit iirc
00:59 <Shiz> oh, apk is gpl2 :)
01:06 <mikeee_> and there's no "umbrella" license for the pre-built images on alpinelinux.org/downloads or anything like that?
01:19 royger joined
01:29 blueness joined
01:45 laj joined
02:01 Guest46418 joined
02:27 s33se_ joined
03:24 blueness joined
03:37 cyteen joined
03:48 cyteen joined
05:21 blueness joined
06:02 cyteen joined
06:21 fabled_ joined
07:18 <fcolista> morning
07:22 <TemptorSent> 'morning!
07:22 <TemptorSent> Well, evening for me for another 40 minutes or so :)
07:24 <TemptorSent> ...so I've been beating my head against the combination of mkinitfs, lddtree, and building for aarch on x86_64. Has anyone already solved this, or shall I continue cussing at it until one of us wins?
07:28 <fcolista> ncopa, i'm going to build openvas with the new patch and symbols
07:31 vakartel joined
07:36 <TemptorSent> A spurious libc.musl-x86_64.so.1 dep is showing up when trying to build the image, but a manual run from the shell doesn't come up with the same dep.
07:41 blueness joined
08:09 stwa joined
08:21 cyteen joined
08:33 <fabled_> TemptorSent, it's fixed in new lddtree in github
08:33 <fabled_> should apply the patch
08:34 <fabled> TemptorSent, fix is https://github.com/ncopa/lddtree/commit/a4c4b3ae3ef7ba6f601317e5eb5b92e33fe2f5d4
08:36 <TemptorSent> fabled: Thank you! I just wasted the entire day trying to work around what looked like a path issue.
08:36 <fabled> ncopa, please tag lddtree
08:37 <TemptorSent> That's my only holdup on having aarch64 profiles building on x86_64 hosts at this point.
08:37 <fabled> yeah, one major reason why we revamped alpine-iso away was to support cross-building images properly
08:38 <TemptorSent> fabled: Right now, it's doing everything but being happy with cpio's return status because it can't find the spurious x86_64 file.
08:38 <fabled> yeah, it's the lddtree
08:39 <TemptorSent> I'm taking a WAG that the environment changes, since I can run it cleanly on the cmdline.
08:39 <fabled> i fixed it when writing mkimage.sh
08:39 <fabled> i wanted to also cross-build images :)
08:40 <TemptorSent> Well, mkimage.sh can now do all sorts of fun things, like dump unique ssh keys on your image, (theoretically cross-arch)
08:54 <TemptorSent> fabled: Did you get a chance to take a look at apk --cache-dir w/ --root and reproduce the odd behavior?
08:55 <TemptorSent> fabled: The firmware isn't so small :)
08:57 <fabled> TemptorSent, yeah, firmware is pretty big; that's why modloop creation script tries to delete unneeded ones
08:58 <fabled> i had idea that the .apk could be trimmed down too a bit
08:58 <fabled> but it would require keeping list of the kernel configs in linux-firmware aport
08:58 <fabled> or more likely the union of produced .ko object's and the firmwares mentioned in them
08:59 <fabled> would be especially useful if the linux-firmware package was made arch specific and keeping only the arch required subset of firmwares
08:59 <TemptorSent> I think we can actually pull out what we need pretty easily by splitting the features out better.
08:59 <TemptorSent> Agreed - there is a huge installed overhead just by having that package in the apk repo
09:00 <TemptorSent> I actually setup a seperate list for apks ONLY needed for building the initfs so it can be a bit more sane.
09:01 <TemptorSent> I'd suggest at least splitting the firmware by arch and the modules by function/driver
09:02 <TemptorSent> So if you need iscsi, the feature pulls in the iscsi deps and nothing else. Need a LSI driver, include the driver_lsi feature.
09:03 <TemptorSent> It actually should be pretty simple to integrate the function of mkinitfs in the framework of mkimage directly.
09:03 <TemptorSent> Then just let them both be applets :)
09:05 <TemptorSent> The modules included on the initfs boot cmdline are now configurable, so we should be able to add everything needed to completely automate the initfs generation and overlays.
09:08 t0mmy joined
09:17 fekepp joined
09:21 <ncopa> fabled there was a pull request: https://github.com/ncopa/lddtree/pull/5
09:21 <ncopa> apparently he gave up
09:22 <TemptorSent> Good morning ncopa.
09:22 <ncopa> morning TemptorSent
09:22 <ncopa> sorry for not reviewing your work
09:22 <ncopa> it looks overwhelming
09:22 <ncopa> :)
09:23 <fabled> ncopa, pull request should prevent tagging release now; you can make new release later when PR is applied :)
09:24 <ncopa> yeah
09:25 <TemptorSent> ncopa: No problem, it's a bit of a change ;)
09:26 <TemptorSent> I'm trying to make sure it actually works for all expected functionality at least before even considering moving it towards a production status.
09:27 <ncopa> that would be required :)
09:27 <ncopa> well, at least without breaking existing stuff
09:27 <TemptorSent> *lol* It seems to be an unusual requirement among many sofware projects these days.
09:27 <TemptorSent> Right up with eating your own dogfood.
09:29 <TemptorSent> Was mkimage previously building for all archs correctly from x86_64?
09:29 <ncopa> i think so
09:30 <ncopa> well
09:30 <ncopa> no, i dont know
09:30 <TemptorSent> *lol* Got it :)
09:30 <ncopa> so, for now, its enough if it does not break building native arch
09:31 <ncopa> fabled: have you tested lddtree from git master?
09:31 <TemptorSent> ncopa: I had that yesterday AFAIK :)
09:32 <TemptorSent> What I need to do soon is get a clear idea of what each release profile should contain and what modules are supported for which kernel flavors/archs.
09:33 <TemptorSent> I'd like to make the base profile a true base with only what's required to bring up a working environment, then have the rest add from there.
09:34 <TemptorSent> Also, what would you like to see in the overlays, since they can now be quite granular.
09:36 laskin joined
09:37 <ncopa> the smallest release profile is the minirootfs
09:37 <ncopa> which should contain the minimal required stuff for a minimal chroot/container image
09:37 <ncopa> this should be used for docker image
09:37 <ncopa> this does not even need openrc
09:38 <ncopa> which you otherwise need for a "working environment"
09:39 <ncopa> then we have a "netinstall" image, which is the alpine-standard
09:40 <ncopa> which is a live cd with kernel etc
09:40 <ncopa> but is minimalistic
09:40 <ncopa> you have only the tools needed to get the network up
09:40 <ncopa> so you can install system from network
09:41 <ncopa> the thinking there is
09:41 <ncopa> if you download a full live-dvd on several GB
09:41 <ncopa> then install that to disk
09:41 <ncopa> i mean if the purpose is to install to disk
09:42 <ncopa> then there is likely alot of stuff on that full live dvd that you will never use
09:42 <ncopa> and there is also a big change that some of the packages are outdated
09:43 <ncopa> so on system update you'll get newer versions of the same packages that you already downloaded
09:44 <ncopa> this means that you transfer things you dont need over the wire to get that big install live dvd
09:44 <ncopa> so on our alpine-standard (which would be renamed to netinstall)
09:44 <ncopa> we only include the things needed to bring up the network
09:44 <ncopa> and you install the rest from there
09:45 <ncopa> that way we reduce the amount of bytes transferred over the wire that you dont really need
09:46 <ncopa> you only install the packages that you intend to use
09:46 <TemptorSent> Okay, makes sense.
09:46 <ncopa> and you get the updates on first download
09:46 <TemptorSent> I think we can get away from using the one-off builder for the minirootfs and just make it a profile
09:47 <ncopa> thats good
09:47 <ncopa> i felt it was a bit hackish
09:47 <TemptorSent> The overlay builder handles pretty much everythign else that I can think of right now.
09:47 <ncopa> because the other profiles were focusing on live cd/dvd style
09:47 <ncopa> with kernel etc
09:47 <ncopa> with kernel and bootrepo
09:48 <TemptorSent> The worst hackish thing left is the split of apks between flavored and unflavored so they can parse right for multiple kernel builds.
09:48 <TemptorSent> Would you object horribly to handling all flavored packages as pkgname-FLAVOR and parsing them out at the end?
09:49 <ncopa> not following
09:49 <ncopa> you mean linux-grsec zfs-grsec?
09:50 <ncopa> we dont build all 3rd party modules for all kernel flavors
09:51 <ncopa> for example it makes no sense to build dahdi-virtgrsec
09:53 <TemptorSent> xtables-addons is the main one.
09:53 <TemptorSent> we have both xtables-addons and xtables-addons-flavor
09:54 <TemptorSent> So we have to handle the flavored one specially if we want to have multiple kernels installed in an image.
09:59 stwa joined
10:00 laskin joined
10:01 <ncopa> i think xtables-addons is userspace or common and xtables-addone-$flavor is the kernel modules
10:02 <ncopa> kernel modules may or may not need userspace tools
10:02 <ncopa> iirc dahdi-linux is the firmware which is common for all supported kernel flavors
10:04 <TemptorSent> ncopa Right, I just want to stick the logic in the features rather than buried through every tool on the system
10:04 <TemptorSent> do we really want xtables-addons hard-coded in mkinitfs?
10:05 <ncopa> im not sure why we'd want xtables-addons in the mkinitfs at all
10:05 <TemptorSent> So if I can put in each feature which kernels it supports, we don't have to worry about adding/removing packages so much.
10:06 <TemptorSent> I believe so the modules are there for routers and such.
10:06 <ncopa> but thats never needed in the initramfs stage
10:06 <TemptorSent> Run-from-ram.
10:06 <TemptorSent> They won't get baked into the .modloop if they're not present when building the initfs.
10:07 <ncopa> that sounds wrong
10:08 <TemptorSent> That's the way update-kernel/mkinitfs currently work.
10:08 <ncopa> initfs and modloop are different things solving different problems
10:08 <TemptorSent> The modloop is build as part of the update-kernel process, which just takes apks and mkinitfs features.
10:09 <ncopa> yeah that makes sense
10:09 <TemptorSent> mkinitfs unpacks the apks, then runs the requested feature filters against that, and runs lddtree to pull all deps for libs, and depmod for kernel modules.
10:10 <ncopa> right
10:10 <TemptorSent> So ideally each feature would only include the kernel modules it actually needs, not, say, the entire scsi driver tree!
10:10 <ncopa> yes
10:10 <ncopa> so the xtables-addons kernel module gets into the modloop
10:10 <ncopa> but not into the initramfs
10:11 <TemptorSent> Right, that's what I'm working on cleaning up.
10:11 <TemptorSent> It will mean changes to update-kernel and mkinitfs as well to do it correctly.
10:11 <ncopa> right
10:11 <ncopa> i think the problem was zfs right?
10:12 <ncopa> we currently need both kernel modules *and* user space tools in the initramfs
10:12 <ncopa> so we need both the zfs-$flavor apk and the zfs.apk (with userspace tool)
10:13 <ncopa> similar with the lvm initramfs feature
10:13 <ncopa> where we need the lvm2 package to be able to build the initramfs
10:14 <TemptorSent> Right, zfs I have taken care of actually :)
10:15 <TemptorSent> I just want to get rid of the duplicate variables for tracking the flavored and unflavoed apks.
10:16 <ncopa> where xtables-addons and dahdi-linux are "unflavored" apk and xtables-addons-grsec and dahdi-linux-grsec are the flavored?
10:16 <TemptorSent> Calling the flavored packages $pkgname-FLAVOR shouldn't conflict with anything (Hopefully?!), and is easy for sed to che up and spit out.
10:16 <TemptorSent> exactly.
10:17 <ncopa> what happens if there is a flavored apk which does not have any unflavored .apk?
10:17 <TemptorSent> And zfs is fun, with spl-$flavor, zfs-$flavor, and zfs
10:17 <TemptorSent> It works currently.
10:18 <ncopa> i suppose spl is a good example of a package that does not have unflavored apk
10:18 <TemptorSent> the flavored packages are ONLY treated with flavored suffix, so it won't try including the unflavored version (which breaks a few things othewise)
10:19 <TemptorSent> Exactly. That's what actually started me down this whole rabbit hole with the old alpine-iso (which, by the way, needs to be mentioned as DEPRECIATED on the wiki :) )
10:19 <ncopa> actually there is a spl userland
10:19 <ncopa> its a wiki ;)
10:19 <TemptorSent> Noted.
10:20 <ncopa> virtualbox-guest-modules
10:20 <ncopa> has no unflavored apk
10:20 <TemptorSent> Right, but the initfs needs just the spl & zfs kernel modules and zfs user space.
10:20 <TemptorSent> right.
10:21 <TemptorSent> Currently, it would be handled by doing "add_initfs_apks_flavored virtualbox-guest-modules"
10:21 <ncopa> makes sense
10:21 <TemptorSent> I'd like to change that to "add_initfs_apks virtualbox-guest-modules-FLAVOR"
10:22 <TemptorSent> then just parse initfs_apks once for each flavor.
10:22 <ncopa> and replace the FLAVOR keyword
10:22 <TemptorSent> Correct.
10:23 <ncopa> so you want introduce a variable (or macro) and expand it
10:23 <TemptorSent> Realistically, we should probably have kernel_apks and initfs_apks seperated out.
10:23 <TemptorSent> Already have automatic expansions for those :)
10:23 <TemptorSent> var_list_* are aliased for each list variable, so it's already done.
10:24 <TemptorSent> take a look at one of the profiles in my branch.
10:24 <TemptorSent> All of the accessors are set up by doing "var_list_alias <listname>"
10:25 <TemptorSent> So you get all the syntactic sugar for relatively little overhead.
10:35 <ncopa> ok
10:36 <ncopa> only thing i think is slightly confusing is the "feature" concept
10:36 <ncopa> which can be mixed with mkinitfs feature
10:39 <TemptorSent> In theory, the zfs feature will end up enabling everything needed, from the kernel modules, to the kernel command line, initfs binaries, and overlay.
10:39 <TemptorSent> enabling iscsi will enable the scsi drivers needed for iscsi and that's it, not the whole pile of hardware drivers.
10:40 <fcolista> ncopa, i have the backtrace of yesterday's segfault
10:40 <fcolista> https://dpaste.de/w8tj
10:41 <fcolista> this is the patch i've applied to openvas-libraries: http://sprunge.us/DYSa
10:45 <TemptorSent> ncopa: Also, not sure if you saw earlier, but I managed to crash apk in all sorts of entertaining ways with misformed input strings such as "package-{grsec}" from a bad "var-{$var2}" instead of $var-${var2}
10:45 <TemptorSent> If also croked when fed a non-existent directory rather than creating it or complaining.
10:47 <ncopa> thast interesting :)
10:48 <TemptorSent> Funny what you feed programs when you screw up your script :)
11:14 <TemptorSent> I'm getting really sick of staring at this thing right now... I can't tell WHAT'S breaking.
11:15 <ncopa> maybe you just need some sleep
11:15 <ncopa> its late over there isnt it?
11:15 <TemptorSent> Yeah, 3:15...
11:16 <TemptorSent> I spent 18+ hours fighting with trying to get the damn cross-arch build working, now I'm just going in circles
11:16 <ncopa> get some sleep
11:16 <ncopa> it helps
11:16 <TemptorSent> And it's prbably a stupid typo somewher e:)
11:17 <ncopa> thank you for working on it
11:17 <ncopa> the general impression of it is good
11:17 <ncopa> looks modular and nice
11:18 <TemptorSent> Yeah, as soon as I finish seperating functionality, it should actually be easy to debug.
11:18 <TemptorSent> I seem to be chasing the tail of a random return value.
11:21 <TemptorSent> Alright, time to give up..
11:22 <TemptorSent> and by the way do you have ANY idea where the mv -i for signing the index is coming from? Its seriously fubaring my debugging!
11:23 <ncopa> hum
11:23 <ncopa> dunno
11:24 <TemptorSent> abuild-apk, abuild-sign, any other place it could be?
11:26 <ncopa> its interactive?
11:26 <ncopa> so it stops the execution?
11:26 <ncopa> and prompt for input?
11:26 <ncopa> try using ps
11:29 <TemptorSent> Got it!
11:29 <TemptorSent> Something is popping up interactive mv after signing the index.
11:30 <TemptorSent> I'm suspecting abuild-sign at the moment...
11:30 <TemptorSent> Okay, we have it building aarch64!
11:30 <TemptorSent> Give me a sec and I'll push.
11:34 <fcolista> ncopa, that's the strace, if you want to look at : https://dpaste.de/k4Ud
11:37 <ncopa> fcolista: need to tag the lddtree release first
11:37 <ncopa> im making a simple test uitre
11:37 <ncopa> test suite
11:38 <TemptorSent> Okay, pushed - should work for any arch now (I think)
11:42 <TemptorSent> ncopa: Okay, so the release images will be something along the lines of: bare_fs, net_install, minimal, basic, standard, extended, right?
11:43 <TemptorSent> corresponding to minirootfs, <adding net_install>, base, vanilla, standard, extended
11:43 <ncopa> you have the release images here: https://alpinelinux.org/downloads/
11:44 <ncopa> also
11:44 <ncopa> the text description show on that page should be specified in the profile
11:44 <ncopa> image profile
11:44 <TemptorSent> Right, those are basically flavors of the other profiles through, right?
11:45 <TemptorSent> Most of them use standard as their base
11:45 <ncopa> right
11:45 <TemptorSent> I'll have to look at exactly what was in which for the original profiles.
11:46 <ncopa> i think that standard, vanilla and virtual are the same, with different kernels
11:46 <TemptorSent> But the way it's put together now, we should be able to make the profiles much cleaner.
11:46 <ncopa> i think maybe i enable serial console on virtual too
11:46 <TemptorSent> Right, that can all be done with just a couple lines in a profile now.
11:46 <ncopa> extended is same as "standard" but with extra packages added
11:46 <TemptorSent> you can add AND REMOVE from lists.
11:47 <ncopa> ok
11:47 <ncopa> the arm are slightly different because they are not .iso but .tar.gz images
11:47 <TemptorSent> And I have it so you can force the kernel from a profile by setting it prior to including the base profile
11:47 <TemptorSent> I have that working too AFAIK
11:48 <ncopa> ok
11:48 <ncopa> i will test it later
11:48 <ncopa> need clean up other stuff first
11:48 <TemptorSent> At least it's generating a uboot image for me now for aarch64 :)
11:49 <TemptorSent> I figured if I can get it building images for x86, x86_64 and arm, we're good for now.
11:49 <ncopa> yeah
11:50 <TemptorSent> Once I can force update-kernel and mkinitfs to use an explicit apk-cache, it will actually be reasonably quick to generate the whole set, as only minor parts change.
11:50 <TemptorSent> And get it using -L for copy...
11:51 gromero joined
11:51 <TemptorSent> The repeted copy and extract of the kernel/firmware is killing my poor sd-card based root fs!
11:52 <TemptorSent> Also, it's sufficiently broken down now that I believe we can toss a multi-worker dispatcher in there and let it rip :)
11:53 <TemptorSent> Let me know if the automatic ssh features work for you -- add "feature_ssh autostart autokeygen" to a profile and look in the keys dir of the media for the matching set.
11:54 <TemptorSent> Oh, and is bootchart REALLY necessary on arm?
11:55 <ncopa> i think no
11:55 <ncopa> i think we should disable it by default btw
11:55 <ncopa> it was only to optimize things at boot
11:56 <ncopa> so its a development tool
11:56 czart_ joined
11:56 <TemptorSent> okay, good - then I can rip acct out of the initfs!
11:56 <TemptorSent> Things will look a lot smaller when I'm done with thm.
11:58 <TemptorSent> Running a build that I'm actually going to be using the profile for on a client's box now... let's see if I broke x86_64 in the process of fixing aarch64 cross-build :)
11:59 <TemptorSent> Should be able to get the uboot image down by almost half!
12:01 <TemptorSent> Hmm, only issue I'm seeing with the tarball is it ended up with my username/perms, probably because it's not wrapped in fkrt yet.
12:03 ferseiti joined
12:05 <TemptorSent> Looks like it still makes native images too.
12:06 <TemptorSent> Alright, bedtime, before I break something :)
12:06 <TemptorSent> Goodnight ncopa. Thanks for the input!
12:06 <ncopa> goodnight
12:10 blueness joined
12:18 blueness joined
12:20 leitao joined
12:21 blueness joined
12:34 blueness joined
12:44 blueness joined
13:29 farosas_ joined
13:56 hairyhenderson joined
14:15 <mitchty> is this correct for adding a testsuite and check() function? https://github.com/mitchty/aports/commit/ab8f3e0e0d7aadbf9dcfec5ae118c4d52842c5ff
14:16 <mitchty> noting that if we're cross compiling there is no way the cross compiled ghc will be testable reliably
14:33 <fabled> mitchty, when cross compiling, check() is not called
14:33 <fabled> http://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n71
14:36 <mitchty> ah cool, wasn't sure will nuke that then thanks fabled!
14:38 <mitchty> should i be bumping the release field for this or is it ok to skip it?
14:47 <ncopa> something iw weird with the aarch64 toolchain
14:48 <ncopa> linux-vanilla build fails with
14:48 <ncopa> ld: unrecognized option '-Wl,--as-needed'
14:48 <ncopa> ld: use the --help option for usage information
14:48 <ncopa> make[3]: *** [/home/ncopa/aports/main/linux-vanilla/src/linux-4.9/scripts/Makefi
14:48 <ncopa> le.build:293: arch/arm64/mm/ioremap.o] Error 1
14:48 <ncopa> does not happen on x86_64
14:49 <ncopa> hum
14:49 <ncopa> seems its export LDFLAGS
15:00 <mitchty> and slightly unrelated question, for the idris port https://github.com/alpinelinux/aports/pull/684 I set that up originally to use cabal to download and install all of idris' dependencies at build time https://github.com/alpinelinux/aports/pull/684/files#diff-13750fba489569338de862b1bd266832R31 is that ok or should I work on a similar cabal bridge to what jirutka has for cargo?
15:02 <mitchty> i set it up to use a frozen version constraints file so things shouldn't break in that the versions in the cabal.config will be what cabal uses to build
15:02 stwa joined
15:08 <mitchty> but i'm not sure how exactly we want to do build time dependencies for things that get built, I setup idris so that it can run on its own
15:08 <mitchty> though it now needs to have ghc-dev for makedepends
15:09 Emperor_Earth joined
15:09 <ncopa> not sure how to deal with ghc. maybe jirutka has opinion
15:10 <mitchty> yep no rush, iris though is about 50% of why I ported ghc :)
15:11 <mitchty> idris, too early to type
15:27 <jirutka> mitchty: ncopa: I don’t have a solution for cargo/rust yet, just an idea how to do it :) I’ll write more about it later
15:27 <mitchty> jirutka: my mistake, thought you had it ready
15:28 <jirutka> not yet :/
15:28 <mitchty> anyway, I had started down the path of doing what arch linux does which amounts to having a one way bridge from cabal to pkgbuild files, but its super hacky and i'm not a fan of trying to recreate cabal's pkg management in another package manager
15:30 <jirutka> mitchty: i totally agree with the last sentence; recreating pkg management in another package manager is nonsense
15:32 <jirutka> mitchty: the benefit for us of ghc and rust is that they link ghc/rust dependencies statically, so we must deal just with build dependencies, that simplifies the situation
15:32 <mitchty> jirutka: agreed, i have something that kinda sorta works, but its a ton of work/effort that i'm not sure is worth it in the end
15:32 <jirutka> mitchty: btw I’ve tried upx to minimize size of binaries ghc produces, it has great compress ratio, but doesn’t work with grsecurity :(
15:33 <mitchty> jirutka: heh, i use upx to build a static pandoc and compress it so i can run it anywhere
15:33 <jirutka> mitchty: not everywhere, b/c upx do nasty things in memory…
15:33 <mitchty> jirutka: well, in this case, out of date suse/redhat machines
15:34 <jirutka> mitchty: even when I disabled memory protection for the binary, it still doesn’t work (just segfauts), so maybe it has problem even with running in LXC container
15:34 <mitchty> jirutka: upx is a bit of a hack imo
15:35 <jirutka> I still don’t understand why are binaries produced by ghc so huge
15:35 <jirutka> imo ghc is not doing its work well
15:35 <jirutka> afk
15:38 fabled joined
15:47 <mitchty> its hard to say specifically, functional compilers are a bit new to me and i don't yet understand the simplifiers
16:07 <kaniini> ncopa: i noticed that when crosscompiling ppc too
16:10 <kaniini> mitchty: what is in ghc-dev? ghc doesnt seem like something that should have a -dev (since it is probably files you need to run the compiler)
16:11 <kaniini> mitchty: in general -- we want to avoid downloading files on the builders at buildtime, but i am not sure what the solution is for these particular cases
16:12 dsabogal joined
16:15 <mitchty> kaniini: libraries for debugging, its basically the profiled libraries you use if you need to debug something
16:15 <mitchty> you can build things without them
16:16 <mitchty> there are 3 different runtimes, the default, threaded, and profiled/profiled+threaded runtimes, the -dev basically encompasses the latter
16:17 <mitchty> generally unless you're building/debugging libraries you don't need the latter
16:21 <kaniini> got it
16:22 <mitchty> it was also an attempt at making the base ghc a bit smaller
17:16 mikeee_ joined
17:24 Shiz joined
19:33 minimalism joined
20:07 blueness joined
20:14 LouisA joined
20:22 <TemptorSent> mmlb : Are you around?
20:33 <kaniini> fabled: one thing for apk-tools 3 i think we should have is multi-line descriptions
20:36 <TemptorSent> kaniini : That would be nice, but preferable done so that the first line of the description shows for short, and the extened continues naturally, unlike the way several do short/long
20:36 <kaniini> yes, precisely.
20:36 <kaniini> like Debian
20:36 <kaniini> first line is short description, then you continue it below
20:37 <kaniini> vs the RPM way
20:37 <TemptorSent> And maybe even get people to standardize on the layout of the short description!
20:38 <TemptorSent> Actually, it would be nice to have the project name show up in the description automagically.
20:38 <* kaniini> is working on gtk+ apk frontend
20:40 <TemptorSent> add "projname="MyProject"", then have desc automatically prepend that.
20:40 <kaniini> why? the package name is shown in apk search
20:40 <kaniini> :p
20:40 <TemptorSent> It would make the searches a lot easier where package names don't match the names of the projects they're under.
20:41 <TemptorSent> for instance "projname="dropbear"" in dbclient
20:41 <TemptorSent> or projname="ISC DHCP" in dhclient and dhcp
20:42 <TemptorSent> and the many instances where you want to find all packages related to a project.
20:44 <TemptorSent> We're grabbing the URL, it would make sense to grab a cananonical package name.
20:44 <TemptorSent> Then the description wouldn't have to include the project name every time to clarify.
20:46 <TemptorSent> pkgdesc would be printed as "$projname - $pkgdesc", which makes automagically creating descs for docs and dev packages quite simple.
20:47 <TemptorSent> It would also allow sorting by project, which would group packages you expect to use together in the same place.
21:03 <TemptorSent> What's the chance of alpine-baselayout getting split into -baselayout and -baselayout-host? We really only need hosts, group, protocols, profile, TZ, shells, hostname, services, shadow, passwd, and profile.d in the baselayout, as the rest may or may not bee desired.
21:40 fekepp joined
22:22 cyteen joined
22:47 blueness joined