<    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:26 t0mmy joined
00:55 cyteen joined
00:57 <tmh1999> TemptorSent : looks like we have this https://wiki.alpinelinux.org/wiki/Remote_Desktop_Server. Now setting up xfce on VBOX
00:58 <TemptorSent> tmh1999: Ahh, okay - cool.
01:01 <tmh1999> TemptorSent : have you used Alpine in VBOX ? got the classic cannot pass through Login page at lxdm. Log says nothing strange : http://tpaste.us/xW1o
01:03 <TemptorSent> tmh1999: No, haven't tried it in vbox, mostly qemu w/wo kvm
01:30 <TemptorSent> Alright, mkinitfs surgery almost complete -- initial testing now.
01:30 BitL0G1c joined
02:06 blueness joined
02:44 tmh1999 joined
02:52 s33se joined
03:33 tmh1999 joined
04:28 ammunta joined
04:32 ammunta joined
04:41 <TemptorSent> Okay, it seems to be working for the most, now it's just a matter of cleaning up.
04:41 <TemptorSent> Any opinions on whether bb-static / apk-static should be used in the initfs?
04:46 jailbox joined
05:13 <TemptorSent> Okay, tested and working at least with virt profile, still need to split initfs-features out where it makes sense (scsi/ata/network).
06:15 fabled joined
06:20 lucybun joined
06:33 BitL0G1c joined
06:45 <pickfire> _ikke_: You there?
06:45 <pickfire> Any maintainers online?
06:46 <pickfire> %3191
06:46 <algitbot> [alpine-aports] main/git: upgrade to 2.12.1 - Patchwork: http://patchwork.alpinelinux.org/patch/3191/
06:47 <fabled> pickfire, looks good, will push soon
06:47 <pickfire> fabled: Do you have any suggestion how do I find the maintainers that are currently online?
06:48 <pickfire> And looks like pkgs.alpinelinux.org is outdated.
06:48 <pickfire> http://pkgs.alpinelinux.org/packages?branch=edge&repo=main&name=git
06:48 <fabled> no. we don't usually want to be bugged about asking expedited review. if there's major breakage the ones online will see it...
06:51 <kaniini> i have some thoughts on a way where we could allow maintainers to push updates to their own packages
06:52 leprechau joined
06:52 <kaniini> it basically involves gpg signed commits and a commit-hook to reject as appropriate
06:55 <TemptorSent> kaniini: How about a checksum on their test-results where available in addition, possibly rejecting by default if the build or test log contains known error strings?
06:56 <ncopa> morning
06:56 <ncopa> jirutka: i have a shell problem for you
06:56 <TemptorSent> kaniini: That would allow verification that the same behavior is seen on all build servers.
06:57 <ncopa> the recent set -e change in abuild
06:57 <TemptorSent> 'morning ncopa.
06:57 <ncopa> introduced a bug (or more a new feature)
06:58 <TemptorSent> *lol* Wiping all mirrors - that's quite a feature!
06:58 <ncopa> we set some vars like replaces, install_if depends, pkgdesc in the split functions
06:58 <TemptorSent> ;)
06:58 <ncopa> the set -e change in runparts() changed to is respawend abuild recursively
06:58 <ncopa> so the splitfunc will run in a subshell
06:59 <ncopa> and the variables set in the split func will be forgotten on return
06:59 <ncopa> now, I'd say that setting those vars in the subshell was wrong in the first place
07:00 <ncopa> but we have that many many places
07:00 <ncopa> so we need get that functionality back
07:00 <ncopa> i wonder if we can print the error message via trap
07:01 <TemptorSent> ncopa: Can you just propigate back the environment by calling 'set' as the final function and using set -- $( subshell)?
07:01 <ncopa> TemptorSent: no
07:02 <ncopa> we have no control over the output from the subshell
07:02 <TemptorSent> ncopa: So this is after an error in the subshell causes it to bail, but before cleaning up?
07:04 <ncopa> yes
07:04 <pickfire> kaniini: That's a nice idea
07:04 <ncopa> the introduced `set -e` will make it bail on unexpected places
07:05 <TemptorSent> ncopa - let me take a look at it... if you know where it will return to, a trap and error handler might work.
07:05 <ncopa> the `|| return 1` we have everywhere is our current way to make it bail in a "controlled" manner
07:05 <ncopa> i thikn the only cleanup it need to do is print the function it tried to run
07:06 <ncopa> so i think trap should be possible and not that hard to implement
07:06 <ncopa> this is the commit that introduced it: http://git.alpinelinux.org/cgit/abuild/commit/?id=36d5193776180385a39626a83241822736a5f6b8
07:06 <TemptorSent> ncopa: Yeah, I have more of those than I'd care to in mkimage still, working on fixing the error reporting there to use '|| ! warning "Fail!"' syntax.
07:07 <ncopa> see the change in runpart()
07:09 <ncopa> - $part || die "$part failed"
07:09 <ncopa> htats what it used to do
07:09 <ncopa> now it runs that in subshell (recusively calls itself)
07:10 <ncopa> so it can catch the error
07:10 <ncopa> i think we can do something like:
07:10 <TemptorSent> line num?
07:10 <ncopa> @@ -567,7 +566,9 @@ update_config_guess() {
07:10 <ncopa> runpart() {
07:10 <ncopa> around 567
07:11 <ncopa> look at the above patch
07:11 <ncopa> what it did previously
07:11 <TemptorSent> Hmm, looking at the rev indicated and not seeing the subshell, let me FF
07:11 <kaniini> in my opinion, this set -e should be reverted for now
07:11 <kaniini> we already managed to hose the edge repos
07:12 <ncopa> i think we need to revert the `$part || die ...` part
07:12 <kaniini> and now seems more breakage :/
07:12 <ncopa> but i think we can do something like:
07:12 <kaniini> being able to override $pkgdesc and friends for subpackage seems very critical
07:12 <kaniini> at least i use that a lot :)
07:13 <ncopa> RUNPART_FUNC=$part; part || die "..."; unset RUNPART_FUNC
07:13 <ncopa> and in trap handler we check if RUNPART_FUNC is set
07:13 <ncopa> kaniini: yes, this is worse than previous error that purged our master mirror
07:14 <ncopa> as it builds the .apk wrong
07:14 <ncopa> brb. will eat breakfast
07:15 <ncopa> we should probably wait with pushing more til this is fixed
07:15 czart_ joined
07:17 <TemptorSent> Um, looking at the code in github, it looks like there's a bug in the abuild_function definition -- the || is referring to the assignment now AFAIK, not the result.
07:19 <TemptorSent> Single quoting the || may help, but the result should be checked when $abuild_function is called.
07:20 vakartel joined
07:20 <TemptorSent> Somewhere around 2346 appears to be where the error handling needs to sit.
07:26 <TemptorSent> ncopa: So the actual subshell invocation is at line 723 that's causing the issue?
07:40 <ncopa> no
07:40 <ncopa> https://github.com/alpinelinux/abuild/blob/master/abuild.in#L569
07:41 <ncopa> it execute abuild recursively
07:41 <ncopa> i know how to fix it
07:41 <TemptorSent> ncopa on the last line in the subshell, add 'set >&3' and read it back on fd3 outside the subshell.
07:42 <ncopa> no, i'll revert it back to how it was
07:42 <ncopa> $part || die ...
07:42 <TemptorSent> Okay -- it doesnt' appear to actually run anything at all in "runpart()" as it currently sits.
07:43 <ncopa> and add a trap "echo "$func failed >&2" EXIT
07:43 <ncopa> before the $part || die
07:43 <ncopa> and after i reset the trap
07:43 <ncopa> trap - EXIT
07:43 <TemptorSent> It just prints a message and assigns a value to the variable "abuild_function"
07:44 <TemptorSent> The trap should do it.
07:45 <ncopa> it also executes the program "$abuild_path"
07:46 <TemptorSent> ncopa: Is it missing a set of paraens then? I see 'abuild_function=$part "$abuild_path" \'
07:48 <TemptorSent> Or is it actually setting abuild_function to equal part followed by invoking abuild_path?
07:49 <TemptorSent> One way or the other, it looks like something is missing with the way it's formatted.
07:49 <ncopa> no it works
07:51 <TemptorSent> As intended? Why the declaration of abuild_function=$part as part of the command rather than on it's on line?
07:51 <ncopa> the abuild_function is passed over
07:51 <ncopa> so abuild executes abuild wiht abuild_function set
07:52 <ncopa> when abuild startsup it will check if abuild_function is set or not
07:52 <ncopa> if it is set, then it knows it is called recursively
07:53 <ncopa> and it will execute the abuild_function and exit
07:53 <TemptorSent> Okay, so it's actually a complete call to abuild, not a subshell within the existing script.
07:53 <ncopa> yes
07:53 <ncopa> recursive call
07:53 <TemptorSent> Now the issue makes more sense :)
07:53 <ncopa> https://github.com/alpinelinux/abuild/commit/36d5193776180385a39626a83241822736a5f6b8
07:53 <ncopa> we need to revert the hunk that modifies the runpart() function
07:54 <ncopa> and the very last hunk, that handles abuild_function
07:55 <TemptorSent> Yeah, that looks sane. Othewise some form of environment passing would be needed to unroll cleanly.
07:56 <TemptorSent> ncopa: I tend to use subshells within my scripts and call the main function rather than calling the whole script.
07:57 <ncopa> thats probably a good idea
07:57 fekepp joined
07:57 <TemptorSent> ncopa: I basically make the actual body of the script nothing but conditional initilization and a call to the main function with "$@"
07:58 <TemptorSent> ncopa: It makes error handling and traps much easier to keep track of and you can explicitly control your file descriptors rather than having a recursive mess.
08:00 <TemptorSent> Speaking of that, mkinitfs now exists as a self-contained plugin within mkimage, including supporting most of the original command line opts :)
08:09 <ncopa> fix is pushed to abuild repo
08:10 <TemptorSent> That should do it.
08:10 royger joined
08:12 <TemptorSent> ncopa: That should short-circuit any logic issues so you don't have to explicitly check every enclosing function.
08:13 blueness joined
08:14 <TemptorSent> Since I'm using fkrt, I'm better off unrolling and closing things out cleanly than failing out of the funtion in places, but the traps are often quite helpful.
08:15 <TemptorSent> ncopa: Are you going to force-rebuild anything built since the breaking change?
08:19 <ncopa> yes
08:19 <ncopa> i am looking at that now
08:19 <ncopa> those needs to be rebuilt: http://tpaste.us/Ynog
08:20 <TemptorSent> Oh, not too hideous at least!
08:21 <ncopa> thats all commits since the breaking change
08:21 <TemptorSent> Although it looks like I managed to pull a couple of possibly broken pkgs with my last update/upgrade.
08:21 <ncopa> most of them are broken pkgdesc i think
08:22 <TemptorSent> Oh, that's not fugly at least. Kernels with bad configs would hurt.
08:22 <ncopa> configs are not modified
08:22 <ncopa> the depends of the -dev package might be broken
08:22 t0mmy joined
08:23 <TemptorSent> Okay, cool - nothing that should break a running system horribly upon reboot.
08:23 <ncopa> correct
08:24 <* kaniini> sends more mail to alpine-devel that will probably give some people a stroke
08:25 <TemptorSent> That's great to hear -- despite to potentially catastrophic events, no actual damage :)
08:25 <TemptorSent> two
08:25 <kaniini> note, i do not have any knowledge of whether or not that proposal is actually technically feasible
08:25 <kaniini> that is an infra question for sure
08:26 <kaniini> i know we have a system that blocks unapproved backports from edge to stable branches unless you have rights to push to stable branches, so it seems plausible that we could implement what i propose
08:28 <TemptorSent> Also, I have a very strange situation on my dev machine -- when I last updated before my last reboot it pulled kernel 4.9.10-0-grsec, but it pulled modules for 4.9.11-0-grsec -- is this a fluke, or did something break that's now fixed?
08:28 <kaniini> upgrading the kernel image will replace the modules
08:29 <TemptorSent> kaniini: Right, and how exactly did I end up with a discrepency between my running kernel and the modules installed? I've run upgrade since then and have NEW modules dir for 4.9.16.
08:30 <TemptorSent> kaniini: Deleting the modules for the currently running kernel is a BAD THING (tm)
08:30 <kaniini> :D
08:30 <kaniini> it's a, well
08:30 <kaniini> it's a known issue
08:31 <kaniini> it's just another area where the current kernel image packaging could be improved :/
08:31 <TemptorSent> Okay, at least it's known.. I'll see about addressing it when I reextract the user-facing functionality of update-kernel.
08:33 <TemptorSent> I haven't poked too much at that yet, other than to scrap the entire mess and clean up what was left :)
08:33 kunkku joined
08:35 <kaniini> TemptorSent: there's APKBUILD-side things to clean up with kernels, this stuff being related -- we should probably change uname to be 4.9-<abirev>
08:36 <kaniini> if 4.9.16 does nto change ABI etc :)
08:36 <TemptorSent> kaniini: That would make sense, although we'd have to be very careful and look at module versioning to not break things
08:37 <kaniini> sounds like you have domain expertise in that
08:37 <TemptorSent> kaniini: In fact, it may be wise to hash the actual abi exposed.
08:38 <kaniini> and on that note, it is no longer 90 in my house, so zzz
08:38 <TemptorSent> Wow, warm day! It's raining and mid 60s here currently :)
08:39 <TemptorSent> Goodnight, and we'll talk soon.
08:41 <kaniini> yeah man, we're going to Make Alpine Great Again(tm)
08:42 <kaniini> ™?
08:42 <kaniini> yes, that's the one
08:42 <TemptorSent> *lol*
08:44 <kaniini> we're going to drain the meaningless abump review swamp
08:44 <kaniini> it's going to be drained
08:44 <kaniini> maybe
08:44 <kaniini> if my idea is technically feasible anyway
08:45 <TemptorSent> kaniini: I don't see why it wouldn't be -- just check the token against their encrypted sig.
08:45 <kaniini> i mean due to gitolite or whatever system we use
08:46 <fabled> i wonder if git-olite supports that somehow simply. allow per-folder push based on the contents of that folder
08:46 <TemptorSent> Right, it should work fine as a hook, nothing too fancy required I don't think.
08:48 <TemptorSent> Sign the folder name with a dev-server key, send that to users allowed to commit, have them drop the token in the directory signed with their key.
08:48 <kaniini> right, the technical details i havent really worked out -- it was more conceptual
08:49 <kaniini> there's another benefit i did not think of too
08:49 <TemptorSent> Concept sounds sound to me :)
08:49 <kaniini> technically, they are already onboarded as developers, so granting them full rights is just a matter of editing a file
08:50 <fabled> i think supporting push to specific subtree parts based on ssh-key is already supported in gitolite
08:50 <fabled> and we are using that too
08:50 <kaniini> then i suppose it's really just a matter of whoever people are working with the maintainer to go through the motions of getting that set up
08:51 <* kaniini> ponders
08:53 <kaniini> fabled: that seems interesting too, because that could be an additional step -- for example,
08:53 <kaniini> could start out as
08:53 <kaniini> 1. restricted to only your own packages as approved by the people who were previously committing them on your behalf,
08:54 <kaniini> 2. restricted only to testing and community repos
08:54 <kaniini> 3. allowed to work on main
08:54 <fabled> i think we have few people with push to testing only
08:54 <fabled> so 2/3 separation is done
08:54 <fabled> the thing on allowing push only to packages one maintains is interesting
08:54 <kaniini> yeah, it seemed to me mostly about just extending what we already had to (1)
08:55 <fabled> i wonder how we could get it
08:55 <fabled> would be nice if could map ssh-keys to email id:s, and parse the Maintainer lines from APKBUILD directly
08:55 <fabled> that way the # Maintainer comment would be the authorization token
08:55 <kaniini> would be nice to have an additional comment like
08:55 <fabled> would scale / be more maintainable than having separate config/acl file
08:55 <kaniini> # Allowed: x, y, z
08:56 <kaniini> if they wanted to allow other maintainers to push to it
08:56 <fabled> why not just have multiple # Maintainer lines then?
08:56 <TemptorSent> fabled: What about just including the ssh fingerprints in the package?
08:56 <fabled> if ssh key gets comprimised, i'd rather keep it separate mapping
08:56 <fabled> instead of needing to edit all APKBUILDs
08:57 <kaniini> that could work as well
08:58 <kaniini> but right now, iirc apk does not understand more than 1 maintainer at a time
08:58 <kaniini> may be good to add support for that if we go that route
08:58 <TemptorSent> fabled: Right, just the finger prints to check against to restrict any outside that, not permissive.
08:58 kunkku joined
08:58 <ncopa> i kind of like 1 maintainer
08:58 <ncopa> i mean having one person responsible
08:58 <kaniini> i see the advantage to both
08:59 <ncopa> if there are more persons, then i think each might think that the other(s) will take responsability
08:59 <kaniini> and then there's packages like musl, kernel, etc that are quite clearly team-maintained
08:59 <ncopa> yes, but i think one person need to be ultimately responsible
08:59 <kaniini> i agree with that
08:59 <kaniini> which is why i proposed # Allowed
08:59 <TemptorSent> Add a Point of Contact flag to one maintainer.
08:59 <kaniini> or such
09:00 <kaniini> which leaves Maintainer as the primary decision maker on the package
09:00 <ncopa> yes
09:00 <kaniini> and then allowed contributors are delegated by the maintainer
09:00 <ncopa> or # Co-maintainer:
09:00 <kaniini> (and of course devs are allowed to touch any package within reason and common sense as they do now)
09:01 <ncopa> also, different persons can tak reponsability for different arches
09:01 <TemptorSent> ideally, allow for both forms depending on the reality of the project -- some projects really do have multiple maintainers, with each primarily responsible for a different portion.
09:02 <TemptorSent> ncopa: arch, doc, translations, etc.
09:02 <ncopa> yes
09:02 <fabled> ideally, i'd like buildbot or similar building before git push
09:03 <ncopa> yes
09:03 <kaniini> yes, i agree there
09:03 <ncopa> staging builder
09:03 <kaniini> maybe what happens is
09:03 <kaniini> they are allowed to push to a staging tree
09:03 <TemptorSent> preferably more than one with results coorrelating
09:03 <kaniini> which if it passes build
09:03 <kaniini> then it gets merged to the real tree
09:03 <kaniini> something like that
09:04 <fabled> yes, full CI like merging
09:04 <TemptorSent> kaniini: Can pushes be left in a staging state until they've passed 'review' by the buildbot?
09:04 <fabled> developer submit pull-request to bot; it builds, if all success then it merges bineries+git commits
09:04 <ncopa> i think a simpler first step might be to have a bot add labels to the github pull request
09:04 <TemptorSent> I like that workflow.
09:04 <ncopa> as mentioned in the email i wrote in response
09:05 <ncopa> fabled: i like that idea too
09:05 <kaniini> yes, github is a first good step
09:06 <fabled> yeah, it's the 1st babystep. going full CI is a bit of more work...
09:06 <TemptorSent> Would branching be too heavy for that application? branch 'git checkout -b build-$arch-$pkg && build && git merge'
09:06 <kaniini> a good example is vakartel, for example
09:06 <ncopa> and i think labels are useful even if its not fully automated yet
09:06 <kaniini> he's probably 70-80% of the way to being an actual dev
09:07 <fabled> i probably enable --enable-gnu-unique-object on gcc
09:07 <ncopa> i would probably have given vakartel push access if he was better at making sure things does not break
09:07 <kaniini> yes, like i said about 70-80% of the way there
09:08 <kaniini> needs to get better at testing
09:08 <ncopa> and yes i agree we need better automatic testing
09:08 <kaniini> 6 months from now, very plausible that he could be a dev
09:08 <ncopa> in general
09:09 <TemptorSent> I'm guilty of needing better testing -- it's far to easy to break something simple and not notice because your latest test didn't happen to hit it.
09:09 <kaniini> same with misery on github (i do not know his irc nick)
09:09 <kaniini> again, probably about 80% of the way there
09:10 <ncopa> i also want give leitao push access
09:10 <kaniini> i agree with that, and also tmh for s390x
09:10 <ncopa> yes
09:11 <ncopa> btw
09:11 <ncopa> around 1 april i think we need have a feature freeze
09:11 <ncopa> first week in april
09:11 <TemptorSent> Question - what's the chance we could automate most version bumps given an existing abuild and a new version number and nothing else?
09:11 <ncopa> so we can start up the stable builders
09:11 <kaniini> TemptorSent: very likely. and that is something i want to enable too
09:11 <ncopa> that means we have only a week or so to pull in TemptorSent's work
09:11 <kaniini> TemptorSent: but on an *opt-in* basis
09:12 <TemptorSent> kaniini: Auto-bump, test.
09:12 <ncopa> auto pull request
09:12 <kaniini> TemptorSent: if it's opt-in, maintainer has to own it
09:12 <TemptorSent> ncopa: Ouch! I need some eyeballs on it if it's going to be ready to main-line in a week.
09:12 <ncopa> the CI builder needs to check for ABI breakage
09:12 <kaniini> if we have a bot just bumping stuff, that is going to end in chaos
09:13 <kaniini> TemptorSent: i propose a conservative version of your overall plan for 3.6 fork
09:13 <kaniini> for example we are probably keeping RTLD_LAZY out for 3.6 too
09:13 <ncopa> TemptorSent: yes thats what i'm saying. i need help with someone review your work
09:13 <ncopa> yes i think LAZY will have to wait
09:13 <kaniini> i'll try to review it tomorrow
09:13 <kaniini> it is very intense stuff :)
09:13 <ncopa> we need plan what to include in 3.6
09:13 <ncopa> what gcc version
09:13 <ncopa> etc
09:14 <ncopa> maybe we want bump llvm
09:14 <ncopa> samba
09:14 <TemptorSent> kaniini: Not necessarily, constrain the version bumps, and build the old and new side by side, check for both errors and different files generated, if there are any questions, flag for manual intervention.
09:14 <kaniini> lets stay at 4.9 kernel for 3.6 and keep grsec in
09:14 <ncopa> i think vakartel had a PR for samba
09:14 <ncopa> re grsec
09:14 <ncopa> i am a bit in doubt there
09:15 <ncopa> it depends a bit on how much support we can get from grsecurity upstream
09:15 <TemptorSent> grsec is a mess and I'm not sure will be maintainable for the life of 3.6
09:15 <ncopa> TemptorSent: exactly
09:15 <kaniini> that's true
09:15 <kaniini> on the other hand, if we kill it now
09:15 <ncopa> that is the exact problem
09:15 <TemptorSent> Keep it as an option for now and change the default
09:15 <kaniini> we're going to have a ton of trolls show up
09:16 <kaniini> ohmagerd not secure by default anymore cuz dropped grsec etc
09:16 <ncopa> they will pop up anyway i think
09:16 <ncopa> TemptorSent: sound like a good suggestion
09:16 <kaniini> true
09:16 <fabled> kaniini, i'm working on musl.git to fix it; the pre-lazy support ldso commit breaks c++ apps
09:16 <fabled> you probably saw the discussion on #musl
09:16 <TemptorSent> Once we can find a viable path forward, depreciate -grsec with a package.
09:17 <fabled> i almost pushed lazy support to musl, but cought up it breaking stuff on c++ programs
09:17 <kaniini> TemptorSent: the viable path forward is likely concentrate on app sandboxing using apparmor or similar
09:17 <kaniini> with that said, i do not think i can have apparmor ready for 3.6
09:17 <TemptorSent> Ouch! Yeah, that'll leave a mark. Is it because of symbol mangling not being entirely determined?
09:17 <kaniini> i do have packages
09:19 <TemptorSent> kaniini: I'd be happy to dig into that once 3.6 drops, but I think you're right on time being too short to both integrate it and TEST it.
09:19 <ncopa> hm
09:19 <ncopa> i have a problem with builddeps
09:19 <ncopa> checkdepends
09:19 <ncopa> checkdepends are not pulled in
09:19 <kaniini> humm
09:20 <kaniini> my patch for that only pulled them in if it knew we were going to run tests
09:20 <TemptorSent> Hmm, new issue? Or just noticing something that may have broken a little while back.
09:20 <kaniini> i.e. not cross-compiling
09:20 <ncopa> its lua-aports
09:20 <ncopa> i am bootstrapping native ppc64le
09:20 <ncopa> building the toolchain and abuild
09:20 <ncopa> before building world
09:21 <ncopa> how can i disable tests?
09:21 <ncopa> abuild --disable-test ...
09:21 <ncopa> something
09:21 <TemptorSent> Does it not yet have the required packages to build the tests?
09:21 <fabled> ncopa, tests are not run when cross-compiling
09:21 <ncopa> this is native
09:21 <fabled> what's the problem there?
09:21 <fabled> recursive dependencies?
09:22 <ncopa> i use lua-aports to calculate the build dependencies
09:22 <TemptorSent> failed make check?
09:22 <ncopa> it does not pull in checkdepends
09:22 <fabled> oh
09:22 <fabled> right
09:22 <fabled> fix lua-aports?
09:22 <ncopa> >>> pkgconf: Analyzing dependencies...
09:22 <ncopa> ERROR: unsatisfiable constraints:
09:22 <ncopa> .makedepends-pkgconf-0:
09:22 <ncopa> masked in: cache
09:22 <ncopa> satisfies: world[.makedepends-pkgconf]
09:22 <ncopa> kyua (missing):
09:22 <ncopa> required by:
09:22 <ncopa> atf (missing):
09:22 <ncopa> required by:
09:22 <ncopa> yeah
09:22 <ncopa> but do we want all those when we bootstrap?
09:22 <ncopa> i suppose we do
09:23 <ncopa> boostrap aports that is
09:23 <fabled> the checks might introduce build dependency loops too
09:23 <ncopa> can we do ABUILD_CHECKS=false
09:23 <TemptorSent> ncopa: You probably want to bootstrap with the absolute minimum, then build your system using that.
09:24 <kaniini> as i designed it,
09:24 <TemptorSent> ncopa: Kinds like the way you used to bootstrap gcc :)
09:24 <kaniini> checks should not be run during bootstrap
09:24 <kaniini> humm
09:24 <fabled> they are not run during bootstrap.sh
09:24 <fabled> but the first native build after that, might not have all checkdeps available yet
09:24 <ncopa> boostrap.sh is for the toolchain
09:24 <kaniini> oh, i see the problem now :)
09:24 <kaniini> hmm
09:24 <fabled> and some core package's checkdeps might depend on unbuilt stuff
09:25 <kaniini> one moment
09:25 <ncopa> this is the aports/abuild bootstrap
09:25 <kaniini> i will push a fix
09:25 <kaniini> for that
09:25 <ncopa> maybe we need an ABUILD_BOOTSTRAP var?
09:25 <TemptorSent> fabled: That's what it looks like. It should probably build once through the tree without tests, then enable them and check.
09:25 <kaniini> yes
09:29 <ncopa> i think we should avoid introduce more braking changes before 3.6
09:29 <ncopa> i want TemptorSent's work
09:29 <ncopa> but we should try avoid more big breakages
09:30 <kaniini> abuild patch i just pushed should fix ppc64le bootstrap
09:30 <kaniini> assuming you tell abuild you're bootstrapping
09:30 <kaniini> ABUILD_BOOTSTRAP=1 abuild ...
09:30 <ncopa> perfect
09:30 <kaniini> sorry for breaking your stuff :D
09:31 <ncopa> i built the pkgconf checkdepends manually
09:31 <ncopa> kaniini: it was worth it
09:31 <kaniini> i am trying to source an octeon machine to port alpine to that (routerboards)
09:33 <TemptorSent> ncopa: Current status of my work is all major components frankensteined and refactored, inclding the functionality of mkimage, the generation capabilities of update-kernel, and all of mkinitfs except a few flags and listing.
09:34 <ncopa> good
09:35 <TemptorSent> ncopa: It knows how to generate overlays, the mkinitfs features have been modularized, and it can build the same profile for multiple base systems with a little work.
09:35 <ncopa> TemptorSent: i am very happy for what you have done
09:35 <ncopa> just need allocate time to review it properly
09:35 <ncopa> or get help with that
09:36 <TemptorSent> ncopa: It will load both from it's own directory structure, ~/.mkimage, or a directory (or even file) specified.
09:37 andypost joined
09:37 <TemptorSent> ncopa: I've completed a number of features and stubbed out several more, and have tested to some extent the ones I've built out.
09:38 <TemptorSent> The important one being automatically generating ssh keys and starting sshd in the image.
09:39 <TemptorSent> I want to clean up the implementation of overlays to avoid multiple calls to the main function, so the deps will move to their own functions where needed.
09:40 <TemptorSent> At this point, what's most needful is some architectural review with how this will fit the system as a whole, as well as how it will look for building releases.
09:42 <TemptorSent> There are a couple apk issues that are really quite painful that I'd love to see addressed before this gets mainlined -- there are a few hacks I don't like at all to work around limitations (bugs?).
09:46 tmh1999 joined
09:47 <TemptorSent> I still have to integrate the custom-kernel-build functionality and reimplement the actual update portion of update-kernel to reach parity with existing utilities, but the rest is either done or close AFAIK.
09:48 <ncopa> very good
09:52 <ncopa> oh
09:52 <ncopa> ome more thing that i'd like
09:53 <ncopa> potensial breaking change
09:53 <ncopa> use slibtool instead of gnu libtool
09:53 <TemptorSent> Might as well break it all at once!
09:53 <ncopa> i am not sure how though
09:53 <TemptorSent> Hmm, that would be nice -- and a lot smaller!
09:53 <TemptorSent> I'm not sure if it supports everything we need though.
09:54 <ncopa> we probably need some options="gnu-libtool"
09:54 <ncopa> so we can force use of gnu libtool
09:54 <TemptorSent> Yeah, that would solve it.
09:55 <TemptorSent> But for compilations, that should speed things up significantly!
09:55 <ncopa> what i am worried about is how we do it
09:55 <ncopa> without editing every APKBUILD
09:56 <TemptorSent> Run a test build against the tree with slibtool in place of gnu and note breakages, then add the gnu-libtool flag to those only.
09:57 <ncopa> yes but
09:57 <ncopa> gnu libtool is normally bundled with the source packages
09:57 <ncopa> so we need some logic to replace it
09:58 <ncopa> i hitnk you can do: make LIBTOOL=slibtool
09:58 <ncopa> or similar
09:58 <ncopa> no
09:58 <fabled> ncopa, kaniini : bootstrap.sh sets BOOTSTRAP=... depending on the stage
09:58 <TemptorSent> export LIBTOOL=slibtool
09:58 <ncopa> MAKE="make LIBTOOL=slibtool" make
09:58 <ncopa> i dont think its enough to export LIBTOOL=slibtool
09:59 <TemptorSent> Or alternaly, get mean and actually replace libtool in src pkgs with a link to slibtool
09:59 <ncopa> that is what i'd like
09:59 <ncopa> unless options="!slibtool" or similar
09:59 <TemptorSent> Yeah, I don't trust autotools to not manage to mangle something.
10:00 <TemptorSent> especially if it's calling libtoolize
10:00 <ncopa> fabled: i built the checkdepends manually
10:00 <ncopa> its progressing
10:00 <fabled> ok
10:00 <fabled> it's not many of those yet
10:00 <fabled> but when we extend check() support, it probably needs proper solution
10:00 <ncopa> we'd need have a wrapper for litoolize too i think
10:01 <fabled> i'm testing gcc w/ --enable-gnu-unique-object, and building qt w/ -dbg
10:01 <fabled> to shed more light for the musl ldso change issue
10:01 <fabled> lunch now
10:01 <ncopa> fabled: yeah. i think kaniini had a plan for ABUILD_BOOTSTRAP
10:01 <ncopa> oh, with gcc
10:01 <ncopa> there was a patch that we might want for plugins
10:01 <ncopa> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094
10:01 <ncopa> in case you are building gcc
10:03 <^7heo> anyway
10:04 <^7heo> about the suggestion from kaniini
10:04 <TemptorSent> Alright guys, I've got to call it a night (well, morning actually) before sunrise, so I'm outta here in a half-hour or so.
10:04 <^7heo> it's a really cool idea imho
10:04 <^7heo> TemptorSent: o/
10:05 <TemptorSent> ^7heo: It's been a long day :)
10:07 <TemptorSent> I tend to be more productive in the middle of the night anyway, it's just the all-nighters are getting hard.
10:15 t0mmy joined
10:22 <TemptorSent> ncopa: You do realize that it will be almost impossible for me to have real documentation done in a week for mkimage & friends, right?
10:29 atmoz_ joined
10:31 atmoz joined
10:31 <ncopa> yeah
10:32 <TemptorSent> ncopa: The code is pretty well documented for the most part, but there is no dev or user docs as of yet.
10:34 <TemptorSent> I still need to go back through mkinitfs and add documentation to all functions there.
10:35 <TemptorSent> And I'm hoping those files that aren't commented are so painfully obvious as to not need them :)
10:38 <TemptorSent> genrootfs needs to get tied into the rootfs imagetype, but that's trivial now that I have fkrt, I just haven't done it yet.
10:46 <TemptorSent> Alright, time for me to crash.
10:48 <TemptorSent> Latest revisions pushed, most initfs features should be there and work I think except for some of networking.
10:49 <TemptorSent> Letting my box build a largish image while I sleep. Be back in 6-8hrs probably.
10:50 <pickfire> ERROR: unsatisfiable constraints:
10:50 <pickfire> linux-grsec-4.9.16-r2:
10:50 <pickfire> breaks: world[linux-grsec><Q1nWlyOYhnh6+TD1lhn37e9tie5GU=]
10:50 <pickfire> What does that mean?
10:50 vakartel joined
10:54 <^7heo> pickfire: your apk operation conflicts with an already installed, locally installed (from .apk file) package
10:54 <pickfire> ^7heo: How do I remove that error?
10:55 <^7heo> by removing or replacing that package
10:55 <^7heo> brb
10:55 <pickfire> How?
10:59 blueness joined
11:04 <fabled> pickfire, kaniini, libbluray upgraded changed sonames, and need vlc rebuild
11:06 <pickfire> fabled: Did you bump the correct person?
11:07 fekepp joined
11:07 <fabled> possibly not, the commit was from Klitzing
11:08 <pickfire> Okay.
11:19 fcolista joined
11:41 <clandmeter> fabled, i guess we can have travis check soname changes and alarm about it?
11:42 <clandmeter> although major version bumps should always be checked by reviewer.
11:49 ferseiti joined
12:07 <ncopa> i wonder if we also should have an automatted apk dot --errors
12:08 <ncopa> to make sure the dependencies in repo is correct
12:08 <^7heo> so
12:17 leitao joined
12:17 BitL0G1c joined
12:31 <ncopa> \o/ ppc64le builder is online
12:31 <algitbot> \o/
12:32 awsumpwner27 joined
12:32 <ncopa> leitao: ppc64le is online: http://build.alpinelinux.org/
12:33 <ncopa> its building world now
12:33 <leitao> ncopa, that is a great news!
12:33 <leitao> ncopa, how can I see what breaks?
12:33 <ncopa> in #alpine-commits
12:34 <ncopa> currently the builder will stop on first breakage
12:34 <ncopa> we can set it to ignore errors for now
12:34 <leitao> ok
12:34 <ncopa> but then we will have to manually create the list
12:34 <ncopa> i think we let it run til it stops
12:36 <leitao> Sure, I am eager to see what breaks and submit the patches.
12:44 <tmh1999> ncopa : the list/order of building package was also my concern :D for s390x I start building "base" packages like in bootstrap.sh then perl* py-* lua* lib*. packages in main are okay now. in community some packages need to be patched.
12:55 farosas joined
13:06 t0mmy joined
13:44 stwa joined
13:46 <clandmeter> ncopa: omg, we are turning into a real distro...
13:46 <clandmeter> all your arch belong to us :D
14:15 ferseiti joined
14:16 andypost joined
14:20 stwa_ joined
14:43 <^7heo> clandmeter: by "real distro", you mean "bureaucratic failure"?
14:45 <clandmeter> ^7heo, i have no idea what you mean by that.
14:45 <^7heo> :P
14:45 <clandmeter> but i was trying to be positive, which i normally try do do.
14:45 <^7heo> also it's "all your arch are belong to us"
14:45 <^7heo> yeah, and I'm your complete nemesis.
14:45 <^7heo> Always defaulting to disappointment.
14:45 <^7heo> So reality is never as bad as I expected it.
14:46 <^7heo> And I'm secretly very happy.
14:46 <^7heo> (because reality rocks in comparison to what I imagine it to be)
14:52 elroncio joined
14:57 blueness joined
15:23 <^7heo> guys
15:23 <^7heo> how do I simply use my local cache as an apk source?
15:24 <ncopa> you cant i think
15:24 <^7heo> ah?
15:24 <ncopa> if you mean apk cache
15:24 <^7heo> where is the local cache?
15:24 <^7heo> /var/lib/apk?
15:24 <ncopa> symlink /etc/apk/cache points to it
15:24 <ncopa> if the symlink is missing then its disabled
15:25 <^7heo> damn
15:25 <^7heo> it's disabled.
15:25 <^7heo> where is the cache? :P
15:25 <^7heo> /var/cache/apk?
15:25 <ncopa> ln -s /where/ever/you/want/it /etc/apk/cache
15:25 <^7heo> ah.
15:26 <ncopa> yes, /var/cache/apk is a good location
15:26 <^7heo> but it contains the indexes atm
15:26 <^7heo> (altho JUST the indexes)
15:26 <^7heo> I'm asking because I'd like to know if there's a location in ANY system where the APKs are cached
15:26 <^7heo> or not.
15:26 fekepp joined
15:26 <ncopa> lrwxrwxrwx 1 root root 12 Dec 26 18:35 /etc/apk/cache -> /var/lib/apk
15:27 <ncopa> that appears to be what i use here
15:28 <^7heo> ah
15:28 <^7heo> yeah it's also here
15:28 minimalism joined
15:29 <^7heo> but it's empty, because the cache link is missing.
15:29 <^7heo> long story short
15:29 <^7heo> there's no way to find the apks I might need if I didn't enable the cache first, right?
15:30 <^7heo> I feel like we should automatically cache the essential packages
15:31 <^7heo> because they might be missing from the repos later on
15:31 <^7heo> while people are still running them
15:32 <^7heo> there was this case where I basically had to view the git history of aports, generate my own package, and install it, just to get it work with my running kernel.
15:32 <^7heo> because the newer package was basically for a newer kernel than the one I was running
15:33 <^7heo> #joysofrunningedge
15:39 <^7heo> ncopa: there's no way to find the apks I might need if I didn't enable the cache first, right?
15:39 <ncopa> correct
15:40 <tmh1999> ^7heo : or you can $ sudo find / -name "*.apk"
15:41 <^7heo> tmh1999: it's a huge waste of cpu/time
15:41 <^7heo> either it's enabled or it's not there.
15:41 <^7heo> plus it could actually match some broken||dev packages on our machines.
15:42 <^7heo> ncopa: is there a way to prevent apk from trying to set the uid/gid on fileS?
15:42 <^7heo> files*
16:15 <TemptorSent> 'morning all.
16:23 <^7heo> moin
16:25 gromero joined
16:25 <TemptorSent> Give the coffee a minute to settle in, then it might be 'good morning' :)
16:29 <ncopa> morning TemptorSent
16:32 <TemptorSent> Hello ncopa, how was your day?
16:33 <TemptorSent> I don't see any other emergencies in the backlog this morning at least!
16:33 <ncopa> :)
16:33 <^7heo> TemptorSent: I've worked on my script more
16:33 <^7heo> TemptorSent: it is now able to install a base system, but
16:33 <ncopa> TemptorSent: got the ppc64le builder up
16:33 <^7heo> 1. from network only
16:33 <TemptorSent> ^7heo: Cool.
16:33 <^7heo> 2. we have problems if the user isn't root - because the default packages EXPECT root.
16:34 <^7heo> which is in my honest opinion a problem
16:34 <^7heo> it should be working with whatever user the system is running as.
16:34 <TemptorSent> fkrt will take care of that I believe.
16:34 <^7heo> fkrt?
16:34 <^7heo> fakeroot
16:34 <^7heo> sorry :P
16:34 <TemptorSent> fkrt is my implementaion that allows you to use fakeroot inline in scripts.
16:35 <^7heo> nice
16:35 <TemptorSent> utils/utils-fkrt.sh in my tree.
16:35 <^7heo> I'll check that out
16:35 <^7heo> that's pretty cool
16:35 <^7heo> so far, my script does:
16:35 <^7heo> 1. env setup
16:36 <^7heo> 2. creates a small script called 'chroot' at the root of the created virtual env
16:36 <TemptorSent> Damnit, abuild bump reverted the 'mv -f' addition and now it's interactive move when signing again!
16:36 <ncopa> oh
16:36 <^7heo> the script created in 2. is the ONLY piece that needs root (for chroot)
16:36 <ncopa> that change never made it to the git repo then
16:36 <^7heo> (and mount)
16:37 <TemptorSent> ncopa : Luckily its a very easy manual fix :)
16:38 <TemptorSent> ncopa: insert '-f' at line 39, char 6 :)
16:39 <TemptorSent> ^7heo: Okay, that follows. So what is puking on being non-root?
16:39 <^7heo> TemptorSent: apk.
16:39 <^7heo> TemptorSent: definitely apk.
16:39 <^7heo> it wants to set uid/gid
16:40 <^7heo> and well, it can't.
16:40 <TemptorSent> ^7heo: Ahh okay. Yeah, fkrt/fakeroot should work there, you can even set it to save state.
16:40 <TemptorSent> ^7heo: Then tar it up preserving those perms if you want.
16:42 <^7heo> can it be made to work outside of the chroot too?
16:42 <^7heo> because before the chroot is started, apk has to install the busybox and the sh that the chroot will need.
16:44 <TemptorSent> ^7heo: Yep, that's what I use to handle 'root' perms as user.
16:44 <^7heo> great
16:44 <^7heo> so we need to hook your fkrt to that script
16:45 <^7heo> so far my script is 56 lines, and the chroot script it creates is 22 lines.
16:45 <TemptorSent> ^7heo: For that, you might be fine just running it through the standard 'fakeroot' if you don't need to twiddle it.
16:45 <^7heo> all works if I create the busybox/sh by hand
16:45 <^7heo> but not via apk
16:46 <^7heo> TemptorSent: maybe yeah
16:46 <TemptorSent> try manually running apk with fakeroot and see if that works.
16:48 <TemptorSent> ^7heo: fkrt is a few hundred lines because it handles essentially everything the fakeroot script did plus some.
16:48 <^7heo> TemptorSent: with fakeroot, the install scripts and triggers for busybox and for baselayout still fail
16:48 <^7heo> in the end
16:48 <TemptorSent> ^7heo: Odd, what's the failure?
16:49 <^7heo> it's failing the exact same way as with executing apk with my user
16:49 <^7heo> without the error messages
16:49 <^7heo> =/
16:49 <TemptorSent> Hmm, it's trying to write somewhere it really doesn't have perms it sounds like.
16:49 <^7heo> ERROR: busybox-1.25.1-r0.post-install: script exited with error 1
16:50 <^7heo> I wouldn't be surprised if that busybox script was trying to write to an absolute path.
16:50 <TemptorSent> ^7heo: Hmm, possibly.
16:51 <^7heo> anyway
16:51 <^7heo> I'll check with that later.
16:51 <^7heo> any idea how to run the fakeroot directly from the script?
16:51 <^7heo> i.e. without having to run `$ fakeroot ./script venv-path` but just `$ ./script venv-path`?
16:52 <TemptorSent> For that, grab utils-fkrt :)
16:52 <^7heo> damn
16:52 <TemptorSent> ^7heo: You can manually preload the lib actually, since you don't need anythign special.
16:52 <^7heo> it's not in aports...
16:54 <TemptorSent> Nope, except in my trees scripts: https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/utils/utils-fkrt.sh
16:54 <TemptorSent> (I think I typed that right...)
16:55 <TemptorSent> You'll want the utils-basic.sh as well or add the definitions for setvar/getvar to your script.
16:55 <TemptorSent> But you can just take a look at how that works and implement the chunk you need.
16:56 <^7heo> ok
16:57 <^7heo> ncopa: any idea how to use a package from @community in an APKBUILD?
16:58 <TemptorSent> ^7heo: It boils down to ldpreloading the fakeroot lib after starting faked.
17:00 <kaniini> ^7heo: you can depend directly on it, but only in community or testing repo
17:00 <TemptorSent> ^7heo: busybox.post-install only does 'exec /bin/busybox --install -s', which you probably don't want in the chroot, so run apk with the --no-scripts flag.
17:01 <^7heo> kaniini: how so?
17:01 <^7heo> kaniini: I'm having erlang@community in my makedepends list
17:01 <^7heo> and it fails.
17:02 <TemptorSent> ^7heo: Er, you don't want OUTSIDE the chroot -- call it first thing in your script inside the chroot instead.
17:02 <kaniini> ^7heo: you just depend on erlang
17:03 <kaniini> unless you mean you have @community tagged locally. the actual builders dont work like that
17:04 <^7heo> ah
17:04 <^7heo> I have @community tagged locally yes.
17:05 <^7heo> how do the actual builders work?
17:05 <kaniini> no tagging
17:05 <^7heo> like
17:05 <^7heo> ALL the URLs in the /etc/apk/repositories file one after the other?
17:05 <kaniini> yes
17:06 <^7heo> well, I guess that can work
17:06 <^7heo> I wanted to have packages tagged explicitely
17:06 <^7heo> but I guess I need that un-explicitely since I'm writing APKBUILDs too...
17:36 tty` joined
17:43 fabled joined
17:59 cyteen joined
18:02 atmoz joined
18:09 tmh1999 joined
18:11 leo-unglaub joined
18:19 BitL0G1c joined
18:22 leo-unglaub joined
18:36 BitL0G1c joined
18:39 <^7heo> does anyone know who Marlus Saraiva is?
18:39 <^7heo> (maintainer from erlang)
18:41 <TemptorSent> ^7heo : No clue, but that's quite a system to maintain.
18:42 <^7heo> exactly
18:42 <^7heo> I'm trying to build an erlang package for work
18:42 <^7heo> and it does not work.
18:42 <^7heo> So I wonder if it's an issue with the erlang package or with the software I'm trying to build.
18:42 <TemptorSent> ^7heo: Both?
18:43 <TemptorSent> ^7heo: Erlang seems great... once you actually get it all agreeing to work together.
18:44 <TemptorSent> ^7heo: It wants to be its own OS really, and trying to cram it in a general package is messy.
18:44 elroncio joined
18:46 <TemptorSent> ^7heo: Maybe you can make it an image target ;)
18:48 <TemptorSent> ^7heo: Crap, that's a long list of subpackages!
18:49 <TemptorSent> ^7heo: There doesn't appear to be a wy of pulling all subpackages in that I can see?
18:50 <^7heo> oooh
18:50 <^7heo> < TemptorSent> ^7heo: Crap, that's a long list of subpackages!
18:50 <^7heo> Thanks!
18:50 <^7heo> that's what I was missing.
18:50 <TemptorSent> ^7heo: NP :)
18:50 <^7heo> I only saw 4 packages earlier for some reason.
18:51 <TemptorSent> ^7heo: It needs a $pkgname-all subpackage that depends on all the rest of the subpackages
18:52 <TemptorSent> ^7heo: Otherwise you get to do forensics to figure which your application needs, and hope the error reporting points you the right direction.
18:54 <^7heo> yeah exactly what I'm doing right now.
18:56 <^7heo> currently oscillating between abuild -r and vi APKBUILD...
18:56 <^7heo> ok, different error.
18:56 <^7heo> I'll fix that tomorrow ;)
19:04 <TemptorSent> *lol* Progress comes in fits and starts.
19:22 blueness joined
19:28 <TemptorSent> That was entertaining -- I had a build come up broken because for some reason alpine-base didn't fetch musl after the previous update. Seems fixed now, but odd.
19:32 C745H joined
19:51 TemptorSent joined
19:57 TemptorSent joined
19:58 <TemptorSent> Okay, lets see how long I can stay online this time.
19:59 <TemptorSent> The storm is knocking out my landline intermittenly.
20:00 <kaniini> TemptorSent: what connection do you have ?
20:03 <TemptorSent> A couple tin cans and a wet piece of string :)
20:06 <TemptorSent> ADSL2 over a half mile of ugly spliced old direct-burried copper to a remote served by fiber strung tree-to-tree down the road where they couldn't bore.
20:07 <TemptorSent> Oh, and the NEW drop to my house is a bare cable sitting out on the ground from the telco's splice point to my TNI on my utility pole.
20:09 <TemptorSent> And THAT is a big improvement over the previous drop that came a quarter mile winding across the property from our neighbors with a splice that the TDR indicated was literally under the septic tank!
20:10 <TemptorSent> (and 3 other splices we gave up on once we found where that one was)
20:11 <TemptorSent> We just got several inches of rain in well less than an hour.
20:21 <TemptorSent> Bootloader question - should we enable non-efi grub configs in addition to the existing grub-efi?
20:25 <kaniini> for which?
20:25 <kaniini> i think we want to continue with isolinux where possible
20:35 <TemptorSent> kaniini: We currently have support (theoretically at least) for isolinux, extlinux, and syslinux, rpi, uboot, and grub-efi, and I plan to add at least pxelinux.
20:35 <kaniini> where were you 5 years ago?!!!!?!
20:43 <TemptorSent> kaniini: Trying to stay out of the computer realm mostly.
20:44 <TemptorSent> So if there are any other bootloaders we might want to support, let me know and I'll at least stub them out.
20:45 <TemptorSent> Or boot-configs for that matter.
20:47 <TemptorSent> It's pretty easy to handle once all the various pieces are seperated out.
20:48 blueness joined
20:49 <TemptorSent> We can look at the custom-built kernels and baking in the initramfs after the main functionality is solid.
20:52 <TemptorSent> I plan to break down update-kernel a bit further into general utility functions, staging, and generation, which should make it a bit easier to utilize for live systems.
20:53 <TemptorSent> Finding library deps / kernel module deps / firmware deps can be used many other places.
21:12 vakartel joined
21:16 <TemptorSent> Okay, just taught mkimage about the ppc, ppc64le, and s390x archs. Already had armhf, aarch64, x86, x86_64. What's missing?
21:17 <TemptorSent> Do we have anything for MIPS or SPARC?
21:22 <TemptorSent> Any SHARC support in the wings? That's becoming big in the embedded realm.
21:49 <kaniini> mips is coming for 3.7
21:52 <TemptorSent> kaniini: Okay, cool. Adding recognized archs is a matter of a single file and maybe 4 lines, including a comment :)
22:05 <kaniini> there is also ppc64le which made the cut for 3.6
22:06 <TemptorSent> Got it already :)
22:37 blueness joined
22:53 blueness joined