<    April 2017    >
Su Mo Tu We Th Fr Sa  
 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  
00:04 LouisA joined
01:11 s33se joined
03:19 <kaniini> it may be worth adding file: capabilities for stuff in /usr/bin and so on
03:30 <TemptorSent> How so?
04:10 <kaniini> so that you can do
04:10 <kaniini> `apk add file:/usr/bin/clang` and it will find it
04:12 <TemptorSent> ahh, okay, as a type tag.
04:12 <TemptorSent> That's what I have in the manifest system I'm using currently to make dep tracking sane.
04:13 <TemptorSent> And something of the sort probably needs to be added to apks in general.
04:14 <Shiz> kaniini: where is the provides info actually stored, i can't find it in the .PKGINFO
04:14 <TemptorSent> So we can distribute a manifest of files that can ve versioned.
04:14 <TemptorSent> It's not currently stored in a usable manner that I have found.
04:15 <TemptorSent> It looks like it's derived by magick in the APKINDEX
04:16 <kaniini> Shiz: it is definitely in .PKGINFO, https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1153
04:17 <Shiz> huh
04:17 <TemptorSent> kaniini: file info is?
04:17 <Shiz> oh, i was using the wrong .apk
04:17 <Shiz> makes sense
04:17 <TemptorSent> The only way I can find it is by extracting the pax headers from the .apks.
04:18 <kaniini> TemptorSent: we are talking about capability tags in provides field
04:18 <kaniini> i do not know what you are referring to :P
04:19 <TemptorSent> Oh, okay -- I was looking at general case 'pkg requires file foo, and bah, bar, and, baz all contain file foo'
04:20 <TemptorSent> So if you want to tell the difference between the files, you need to tag them with both the package and checksum.
04:20 <TemptorSent> Then when apk requests an arbitrary file, it will have a list to compare against the current installed tree and dep tree to see if it is a hit or near match for existing packages
04:21 <TemptorSent> I haven't implemmented the distance heuristics, but I already calculate the entire deptree for every bin and script with a checksum tree for each.
04:23 <TemptorSent> Unless somehow apk can derrive that during install :)
04:27 <TemptorSent> Um, I think we can do much better very shortly.
05:29 fabled_ joined
05:48 cyteen joined
06:33 vakartel joined
07:04 blahdodo joined
07:31 tty` joined
07:41 fekepp joined
07:58 blueness joined
08:23 tty` joined
08:40 royger joined
08:43 tonix joined
08:56 vakartel joined
09:54 czart joined
10:20 czart_ joined
10:42 blueness joined
11:13 <_ikke_> looks like rsync.a.o is down
11:14 <clandmeter> yes it is
11:14 <_ikke_> (I'm monitoring it :-) )
11:14 <clandmeter> hold on to your seats please
11:14 <_ikke_> np
11:14 <clandmeter> we are going for a joyride
11:14 <* skarnet> grabs the popcorn.
11:14 <clandmeter> we are going to increase it with 150 Horse power
11:17 <clandmeter> and scaleway has a nice way of allowing you to attache additonal volumes, we have to wait for some time.
11:19 blueness joined
11:23 <ashb> How big is the alpine package repo?
11:26 t0mmy joined
11:27 <clandmeter> depends
11:27 <clandmeter> only packages is less
11:27 <clandmeter> we also have releases
11:27 <clandmeter> and its not all we got
11:28 <ashb> right now is it in the order of: 1g? 5g? 10g? 50g?
11:28 <clandmeter> x10
11:31 gromero joined
11:36 <clandmeter> small simple secure gets pretty large over time :)
11:40 <skarnet> the important thing is that it's possible to only strictly install what you need
11:40 <skarnet> the size of the entire package database is irrelevant
11:41 <clandmeter> It is when you need to distribute it.
11:42 <clandmeter> but thats not a user problem.
11:42 <skarnet> indeed.
11:43 <^7heo> moin
11:49 <ashb> yeah, I was idly curious how much space it would take to mirror it
11:52 <xentec> apk fetch $(apk info) && du -sh
11:52 <ashb> that would only get it for the current release. There are 3? 4? "current" ones
11:52 <xentec> or you parse all sizes from $(apk info)
11:53 <xentec> fill your repofile with all versions and then parse apk info -s
11:56 rdutra joined
12:21 leitao_ joined
12:33 ysh joined
12:37 <rdutra> ncopa: hi
12:38 <rdutra> ncopa: I am trying to compile grub for ppc64le but it is failing. The problem is that grub is compiled in 32 bits mode for ppc64le but seems that Alpine gcc does not have support to compile for 32 bits (it shows --disable-multilib). Any idea of what I can do?
12:43 <clandmeter> rdutra, isnt that only a problem for bios build?
12:43 <clandmeter> iirc
12:44 ysh joined
12:47 <rdutra> clandmeter: well, if I understood the grub build correctly for x86_64 it builds "bios" and "efi" configurations but for ppc64le the valid configuration is "ieee1275"
12:47 <clandmeter> right, for aarch64 i build it only for efi
12:48 <clandmeter> im not sure about ppc though
12:48 <rdutra> clandmeter: yes, it uses --with-platform=efi, right?
12:49 <clandmeter> yes
12:49 <clandmeter> if you need another platform you can add your own.
12:50 <rdutra> clandmeter: looking the configure file, for ppc64le needs --with-platform=ieee1275
12:50 <rdutra> but for ppc64le the grub compile for 32 bits and it is failing with Alpine gcc
12:50 <clandmeter> ah you already added that
12:51 <rdutra> clandmeter: yes, it is failing after I add the correct --with-platform parameter
13:22 <ncopa> rdutra: how does that work? is it just called with -m32?
13:22 <ncopa> i suppose the correct thing to do there is have a proper crosscompiler
13:22 <ncopa> for 32bit
13:23 <ncopa> there is a similar situation for xen on x86_64
13:23 <ncopa> hvmloader is 32bit
13:23 <ncopa> the problem there was that it pulled in the system libc headers
13:23 <ncopa> so stdint.h got painfully wrong
13:24 <ncopa> on glibc it does not happen because they support 32bit mode
13:24 <rdutra> ncopa: the CFLAGS variable in configure has the -m32 and in config.log I see the error: error: -m32 not supported in this configuration
13:25 <rdutra> ncopa: yes, glibc has 32 bit mode
13:26 ysh joined
13:27 <rdutra> ncopa: regarding the xen on x86_64, you mean the --target flag in its configure?
13:28 <ncopa> no
13:28 <ncopa> the makefile for hvmloader adds -m32 to gcc
13:28 <rdutra> ah, ok
13:29 <royger> hm, I don't understand. stdint.h must have the right types for both 32/64bit.
13:29 BitL0G1c joined
13:30 <ncopa> royger they dont with musl
13:30 <ncopa> musl does not support that
13:31 <rdutra> ncopa: what you mean with "have a proper crosscompiler for 32 bit"?
13:31 <royger> hm, really? that's kind of weird. musl only supports 64bits?
13:33 ysh joined
13:33 <royger> do you install a different stdint.h depending on whether it's 32/64bits? because that's very weird. A proper stdint.h file should be done using the __LP64__ define, and should be the same for 32/64 bits
13:33 BitL0G1c joined
13:34 <royger> I can understand that musl doesn't support linking a 32bit binary against a 64bit libc, but the headers should work fine
13:34 <ncopa> they dont
13:34 <ncopa> i talked with dalias about it
13:34 <ncopa> and they will not support it
13:34 <ncopa> the "proper" way is to crosscompile the libc (headers)
13:35 <ncopa> and install them in different location
13:35 <ncopa> and append -I /usr/location/include
13:35 <ncopa> i think xen also does cross compile of newlibc
13:35 <ncopa> in the xen case i was able to work around it
13:35 <ncopa> with a hack
13:35 <royger> ncopa: yes, that's another can of worms.
13:36 <royger> but the headers thing, well, I will better not comment about it.
13:36 <ncopa> talk with dalias about it
13:37 <ncopa> the problem with -m32 and support "multilib" is that you cannot guarantee that nay other libs (headers) support it
13:37 <rdutra> ncopa: regarding the xen case, where you did the hack? in the APKBUILD file itself or some other place?
13:38 <royger> yes, but that should be a link-time issue, not a compile time one
13:38 <ncopa> the way it coudl be fixed would be to install 32bit headrs at different location and patch gcc to replace the -I /path/to/ when -m32 is specified
13:38 <ncopa> well, yes, compiletime too
13:38 <TemptorSent> ncopa: Does that also imply that no x32 support is forthcoming?
13:38 <ncopa> since the headers need have support for multilib too
13:38 <ncopa> (in theory)
13:38 <ncopa> i suspect in most cases it just happens to work
13:39 <ncopa> because the headeres does not do anything funky
13:39 <royger> in the hvmloader case for example, this is a standalone kernel. It's not going to link against anything
13:39 <ncopa> but there is no guarantee for it
13:39 <ncopa> which is why my hack works (worked)
13:39 <royger> (one could argue that then has no business using the libc headers...)
13:39 <ncopa> exactly
13:40 <ncopa> it shouldnt
13:40 <royger> but come one, it's just int types...
13:40 <ncopa> rdutra: what i did was replace #include<stdint.h> with #include<stdint_local.h>
13:41 <ncopa> and just provided the needed inttypes
13:41 <ncopa> royger: yes, so its trivial to provide a int types header for hvmloader
13:42 <ncopa> but musl sees it from libc POV
13:43 <royger> oh, libc guys, they are just like compiler guys...
13:44 <royger> anyway, I'm quite sure upstream would be have to remove stdint.h inclusion and simply provide the typedefs for uint* whatever that hvmloader needs
13:44 <royger> s/have/happy/
13:50 <TemptorSent> ncopa: Do you have any particular attachment to the passwd/group/fstab files in /usr/share/mkinitfs? Any objections to taking the defaults from alpine-baselayout directly instead?
13:52 <ncopa> royger: you can look at the patch in aports/main/xen
13:52 <ncopa> i suppsoe i should have upstreamed it
13:52 <ncopa> but i think it needs a bit cleanup
14:13 BitL0G1c joined
14:20 tmh1999 joined
14:51 duncaen joined
15:43 duncaen joined
15:49 <_ikke_> rsync.a.o is up again?
15:50 <_ikke_> just not http yet
15:51 <ashb> now it is
15:51 <arch3y> do you guys have any docs on a developers workflow? I did see on the docs about contributing and you submit pkgs and fixes via git commits via email
15:52 <_ikke_> arch3y: You can also submit pull requests through github
15:52 <^7heo> arch3y: docs aren't the only problem we have atm; but yeah there are three different ways to contribute
15:52 <^7heo> arch3y: 1. gh
15:52 <^7heo> arch3y: 2. ML
15:52 <^7heo> arch3y: 3. patchwork
15:52 <arch3y> yeah gh is fine too
15:52 <arch3y> yeah docs can ben a problem to develop and keep up to date
15:53 <^7heo> especially when you only have a mediawiki
15:53 <arch3y> I am still figuring out how abuild works and how APKG are structured Im used to pkgbuilds so its similiar but a bit different
15:53 <arch3y> yeah for mediawiki is a bitch to maintain
15:53 <^7heo> and contributors (like me) don't want to have to use firefox every time they want to do a small update in the docs
15:53 <arch3y> it makes you miss hthe days of markdown
15:53 <^7heo> mediawiki is actually older than markdown...
15:54 <arch3y> yeah cant lynx handle it if all you want it text
15:54 <arch3y> yeah I know that but I just meant markdown format is nice to use
15:54 <^7heo> sure
15:54 <^7heo> anything is nicer to use than mediawiki.
15:54 <^7heo> I'd even write my doc in perl using XML only than use mediawiki
15:54 <arch3y> yeah well sometimes the overhead of a db is not needed
15:54 <^7heo> It's not the DB
15:54 <arch3y> but its the most common
15:55 <^7heo> I don't care how it works under the hood
15:55 <^7heo> it's more about the UI/UX
15:55 <arch3y> ah gotcha
15:55 <^7heo> having to click in the most annoying website ever to get what I want after my brain works full power for seconds at a time to find the "logic" in that mess...
15:56 <arch3y> we had ours built in laravel and we just pushed md files via git
15:56 <arch3y> it was alot simpler and still looked nice
15:56 <^7heo> and finally get a tiny-timsy little microsoft-eula-formatted textarea in which I have to edit gigantic amounts of text...
15:57 <^7heo> yeah the main issue that is brought up every time is the conversion
15:57 <^7heo> from markdown or asciidoc to whatever.
15:57 <^7heo> at least github is doing that automatically
15:57 <arch3y> yeah true true
15:57 <^7heo> so for now we have docs (unofficial atm) on github
15:57 <^7heo> https://github.com/adocs/adocs
15:57 <^7heo> but...
15:57 <^7heo> it's mostly empty.
15:57 <arch3y> gotcha
15:58 <^7heo> I want to make a bot that mirrors the media wiki there...
15:58 <^7heo> no time yet.
15:58 <arch3y> do you guys want sqaushed commits as well so the history stays quiet
15:58 <^7heo> it's better squashed yes.
15:58 <^7heo> usually, people contribute in aports
15:58 <arch3y> yeah thats my plan
15:59 <^7heo> and in this repo the rule of thumb is: 'one aport, one commit'
15:59 <arch3y> yep
15:59 <arch3y> always
15:59 <arch3y> never anymore then that
15:59 <^7heo> ofc you can rework your stuff after it's comitted
15:59 <^7heo> in a subsequent commit
15:59 <arch3y> yeah how does the build system pick it up
15:59 <arch3y> every pkg goes in testing first
15:59 <^7heo> but usually it's not a good thing to cut features in too many commits.
16:00 <arch3y> yeah Im of the mind to not commit anything until I have it working
16:00 <^7heo> on gh, packages are built in travis; and if they fail the PR is marked as failing
16:00 <arch3y> then I commit deps first before I commit the main pkg
16:00 <arch3y> yeah I remember reading about that
16:00 <^7heo> then if they suceeded, the PR is merged in
16:00 <arch3y> makes sense
16:00 <^7heo> and if merged in, they are built by our builders
16:00 <^7heo> and eventually end up on the repos
16:01 <arch3y> but they need to be put into testing first
16:01 <^7heo> different repos just mean different care in maintaining packages
16:01 <arch3y> and after proper built and signoff they go into main
16:01 <^7heo> main == extra care, stuff there MUST work and be maintained
16:01 <arch3y> or core I forget which ones there are
16:01 <^7heo> community == yeah it's supposed to work
16:01 <^7heo> testing == well, it should work, but if it breaks, you get to keep both parts.
16:02 <^7heo> usually new packages start in testing
16:02 <^7heo> and after a time of them not being an integration problem with others
16:02 <^7heo> they might be moved to community
16:02 <^7heo> and eventually to main if they are important
16:02 <arch3y> yeah my plan would be put any libs I need for the pkg in testing then move it into main or wherever you guys want it
16:02 <^7heo> well
16:02 <arch3y> yeah well a few of these are libs
16:02 <^7heo> about libs, it really depends
16:02 <kaniini> community repo is mostly maintained by maintainers not developers (developers commit the changes on the maintainer's behalf)
16:03 <^7heo> true also
16:03 <arch3y> k just want to make sure that I commit to the correct place
16:03 <kaniini> main is largely maintained by developers (although it is possible to send patches for consideration)
16:03 <arch3y> so I dont make a mess of things
16:03 <^7heo> arch3y: commit to testing
16:03 <arch3y> thats my plan
16:03 <^7heo> arch3y: if wrong, you can always `git mv` and `git amend` in the PR.
16:03 <^7heo> arch3y: you'll see comments then.
16:04 <arch3y> yeah Ive never used amend
16:04 <arch3y> but Im familiar with mv obvs
16:04 <^7heo> it's normally git commit --amend
16:04 skarnet joined
16:04 <arch3y> ah gotcha to add comments why it was moved
16:04 <^7heo> but I have an alias everywhere for `git amend` to call `git commit --amend`
16:04 <^7heo> because I do it quite a lot.
16:04 <^7heo> so...
16:04 <arch3y> yeah makes sense aliaes are life
16:05 <^7heo> depending on your workflow, but yeah typing less commands == coding more ;)
16:05 <^7heo> moin skarnet
16:05 <arch3y> I was looking at libcli as it in unmaintained but needed by the pkg Im adding
16:05 <arch3y> so Ill have to work on fixing it or trying to at least
16:05 <^7heo> well then try to take it from unmaintained
16:05 <^7heo> then `abuild -r` it locally
16:06 <^7heo> and when you actually get an .apk out of it, git push.
16:06 <^7heo> and open a PR
16:06 <arch3y> but all I should ever push is the APKBUILD and any necesary patches correct
16:06 <arch3y> sounds good Ill fork tonight from github and submit a few prs
16:07 <kaniini> yes
16:07 <arch3y> do you guys have a gitignore setup in aports or is it just implied that someone wont commit more then necesary
16:08 <arch3y> Im always careful when I commit, but I know ppl who love to use -a
16:08 <^7heo> arch3y: it's implied that people don't add shit in their indexes :D
16:08 <^7heo> just don't use -a
16:08 <arch3y> good good
16:08 <kaniini> there is a .gitignore iirc, but ^
16:08 <arch3y> yeah I never do
16:08 <^7heo> the same as "don't use the master branch for all your fixes"
16:09 <^7heo> master == release
16:09 <^7heo> git has branches for a reason ;)
16:09 <arch3y> I always got mad cuase I worked with other devs who did and they built a massive gitignore
16:09 <^7heo> pricks also code.
16:09 <^7heo> that's a problem; but what can you do...
16:09 <arch3y> true so each fix or patch should be its own branch and then submitted as a pr
16:10 <^7heo> that's what I do.
16:10 <arch3y> k thats doable
16:10 <^7heo> ofc in aports, since a merged PR is a release
16:10 <^7heo> then you open a PR from your branch to the aports master.
16:10 <arch3y> yeah
16:10 <arch3y> thats how I would do it
16:10 <^7heo> yeah
16:10 <^7heo> and locally it's your own stuff.
16:11 <^7heo> you can do mess it up if you want ;)
16:11 <^7heo> but I wouldn't recommend that.
16:11 <arch3y> I did run into an issue with abuild that I was trying to solve
16:11 <^7heo> we need good maintainers, not messes ;)
16:11 <arch3y> nah I try to follow strict workflows and be clean as possible
16:11 <^7heo> :+1:
16:11 <arch3y> well I come from a long line of maintaining AL pkgbuilds
16:11 <arch3y> so I know all about trying to stay clean and work out issues
16:11 <^7heo> Gut gut.
16:12 <^7heo> Let's see that in practice ;)
16:12 <arch3y> I may need some leeway while I learn the processes you guys have
16:12 <arch3y> but once I figure it out Ill be good to go
16:12 <^7heo> we usually don't bark at interested newcomers.
16:13 <^7heo> I mean, I used to; especially people with "arch" in their nick...
16:13 <^7heo> but I try to be nicer.
16:13 <arch3y> lol I understand I used to as well
16:13 <arch3y> but luckily Im not someone who has never maintained it before and yes I do love Arch
16:14 <^7heo> yeah let's not talk about arch, we're gonna fight.
16:14 <arch3y> but Id like to see where you guys go and it will be fun to be on the ground floor of something
16:14 <arch3y> sure we wont
16:14 <^7heo> but anyhooo
16:14 <^7heo> have fun PR'ing ;)
16:14 <arch3y> yep I actually have a question about abuild
16:15 <arch3y> when building libcli it complains about how the src is named
16:15 duncaen joined
16:15 <arch3y> why do we not want the src to match the github version
16:15 <^7heo> can you please pastebin something?
16:16 <^7heo> so I see what you mean?
16:16 <arch3y> one sec
16:17 <arch3y> https://pastebin.com/PfTueJJu ^7heo
16:18 <arch3y> I can paste the apkbuild as well if needed
16:18 <^7heo> yeah one sec
16:18 <^7heo> I need to plug my laptop
16:18 <arch3y> sure no worries I get the fix rename the tarball that is downloaded
16:18 <^7heo> ok back
16:19 <^7heo> arch3y: ok
16:20 <arch3y> yep Im here
16:20 <^7heo> arch3y: so that's because your downloaded file is named 'v${pkgver}.tar.gz'
16:20 <jirutka> arch3y: ^7heo: no, don’t squash commits, unless told to
16:20 <^7heo> while it's supposed to be named '$pkgname-$pkgver.tar.gz'
16:20 <arch3y> kk
16:20 <arch3y> thats an easy fix
16:20 <^7heo> jirutka: wait wat?
16:20 <^7heo> arch3y: wait
16:21 <jirutka> arch3y: if commits needs to be squashed, the committer can do it
16:21 <^7heo> jirutka: there's a flag on github to avoid comitters from changing the PR.
16:21 <^7heo> jirutka: or do you mean something else?
16:21 <jirutka> ^7heo: ?
16:21 <jirutka> ^7heo: we don’t push via GH interface
16:21 <^7heo> jirutka: I'm not sure what you mean; but I get your point.
16:21 <^7heo> jirutka: right.
16:21 <^7heo> jirutka: then please ignore what I said.
16:21 <arch3y> will do
16:22 <^7heo> arch3y: long story short
16:22 <arch3y> I can fix libcli without an issue, Ill pull the other patch file I made for a different project
16:22 <^7heo> arch3y: what did you fix your 'needs to be renamed' problem?
16:22 <arch3y> ^7heo: oh I just did source=$pkgname-$pkgver.tar.gz::urltosource
16:22 <arch3y> to change the way the pkg is downloaded
16:23 <jirutka> ^7heo: commits go to the primary repository at git.a.o, then synced to GH; we just git am patches from PRs to the master and rebase/squash/whatever if needed, that’s why we use https://github.com/jirutka/github-pr-closer :)
16:23 <^7heo> arch3y: ok fine
16:23 <^7heo> arch3y: that's the right fix; I wasn't sure what you went for.
16:24 <arch3y> ^7heo: yeah no worries
16:24 <^7heo> jirutka: I see.
16:24 <arch3y> I have the patch for liblci as well so itll be fixed in a moment
16:25 <arch3y> I had to patch for gcc >5.2
16:26 <arch3y> do you guys have any issues with sed statements in a prepare func
16:26 <arch3y> or does it need to be an actual patch file
16:26 <arch3y> this was a simple one line fix
16:26 <^7heo> arch3y: usually people don't make a prepare function.
16:26 <^7heo> arch3y: we just name the file .patch
16:26 <^7heo> and it's automatically patched.
16:26 <arch3y> ok well this had a prepare
16:27 <^7heo> probably why it was in unmaintained/
16:27 <arch3y> how does it get automatically patch without calling patch -i
16:27 <^7heo> (lots of APKBUILDs of questionnable quality have been moved to unmaintained/)
16:27 <arch3y> it was a simple one line fix though, I will look at other examples
16:27 <arch3y> yeah I have seen alot of questionable stuff
16:27 <arch3y> like ppl doing make || return 1
16:27 <arch3y> its ugly lol
16:27 <^7heo> that actually was the case until recently.
16:28 <^7heo> because we didn't run the abuild with set -e
16:28 <jirutka> arch3y: see default_prepare in /usr/bin/abuild
16:28 <arch3y> jirutka: will do
16:28 <jirutka> arch3y: there is code handling patches
16:28 <arch3y> jirutka: thats cool
16:28 <arch3y> thats a cool feature to have
16:29 <^7heo> arch3y: but anyway, long story short, the || return 1 was a requirement until a few weeks ago.
16:29 <arch3y> gotcha
16:29 <arch3y> well Im glad that has changed
16:29 <^7heo> arch3y: so even if it's ugly, it's not what I referred to with "questionable quality" ;)
16:29 <arch3y> thanks to the devs for fixing it
16:29 <arch3y> ^7heo: makes sense
16:30 <arch3y> I really have to stop typing PKG and type APK lol darn muscle memory
16:30 <arch3y> is there anything like namcap for the binaries to scan for missing deps
16:30 <^7heo> I bet you can make your shell/vi correct it.
16:31 <arch3y> for sure especially on my alpine box
16:31 <^7heo> arch3y: what do you mean? missing build deps?
16:31 <^7heo> arch3y: or missing runtime deps?
16:32 <arch3y> runtime deps
16:32 <^7heo> they are automatically computed.
16:32 <arch3y> k let me paste the messy apkbuild
16:32 <arch3y> if I may
16:33 <^7heo> ofc.
16:35 <arch3y> ^7heo: http://dpaste.com/27HS29S
16:35 <arch3y> Im going to clean it up a bit more and change maintainer and move the prepare to a patch file
16:36 <^7heo> Wow, it's full of html
16:36 <Shiz> remove the empty vars, they're useless
16:36 <Shiz> :p
16:36 <arch3y> Shiz: yeah I was going to for sure
16:36 <arch3y> I hate wasted space
16:36 <^7heo> with pastebin I knew how to access the /raw/
16:36 <^7heo> but with dpaste...
16:36 <arch3y> I just wanted to make sure I was removing the right onces
16:36 <Shiz> just add .txt, ^7heo
16:37 <arch3y> pastebin threw off captcha
16:37 <arch3y> so was like screw this lol
16:37 <^7heo> Shiz: gosh
16:37 <^7heo> Shiz: "logical"
16:37 <Shiz> makes sense to me
16:37 <clandmeter> unexpand ;)
16:37 <^7heo> not to me.
16:37 <^7heo> it's /raw/ on pastebin
16:37 <^7heo> it's /plain/ on other bins
16:37 <^7heo> sometimes /text/
16:38 <^7heo> sometimes it's another subdomain
16:38 <^7heo> sometimes an HTTP header...
16:38 <^7heo> I mean wtf.
16:39 <arch3y> apologies for causing confusion I could of used an encrypted pastebin luckily I decided not too
16:39 <Shiz> lol
16:39 <clandmeter> arch3y, try unexpand APKBUILD > APKBUILD.new
16:39 <arch3y> do I have to call cd $srcdir or can I call $pkgname-$pkgver directory
16:39 <arch3y> clandmeter: sure
16:40 <arch3y> k done
16:40 <^7heo> unexpand, the natural enemy of python developers.
16:40 <arch3y> what does unexpand do might I ask
16:40 <^7heo> soft tabs to hard tabs.
16:40 <arch3y> Ive never seen it before
16:40 <arch3y> gotcha
16:40 <arch3y> you learn new stuff everyday Isee
16:41 <clandmeter> its nice when you do a lot of copy pasta
16:41 <^7heo> I don't know.
16:41 <arch3y> yeah thats true Ill have to remember that
16:41 <arch3y> thanks clandmeter
16:41 <^7heo> I like to use it only at the end.
16:41 <Shiz> why would it be a natural enemy of python devs
16:41 <Shiz> python works with hard tabs just fine
16:41 <^7heo> Shiz: trolls happen on -offtopic and you know it ;)
16:41 <Shiz> but this is -devel
16:41 <Shiz> :p
16:42 <^7heo> indeed it is ;)
16:44 <arch3y> so I see the subpackage param is that for split pkgs
16:45 <arch3y> or do you guys support split pkgs in one apkbuild file
16:48 <arch3y> is there a flag I can pass to abuild so that it wont clean up my pkg and src dir
16:48 <arch3y> I like to keep it handy in case I need to look at the layout of the pkgdir on the disk
16:49 <arch3y> ah I see -K should do what I want
16:50 <clandmeter> cehck abuild.conf
16:50 <arch3y> k thanks will do
16:51 <arch3y> do I need to add my patch file in the src line inorder for abuild to see it
16:51 <clandmeter> yes
16:51 <clandmeter> all files need to go inside of it
16:51 <arch3y> k thought so
16:52 <arch3y> then it run checksum to gen sums for all files
16:52 <clandmeter> right
16:52 <arch3y> roger that
16:52 <clandmeter> you just raised one level in apkingdom
16:53 <^7heo> now you can use a wooden sword.
16:53 <arch3y> oh Im just getting started lol
16:53 <^7heo> sounds like someone spent too much time on dotarch.
16:53 <arch3y> I used to maintain most of the pkgs for archstrike, so Im quite familiar with the processes
16:53 <arch3y> lol yrs
16:53 <* ^7heo> hides
16:54 fabled joined
16:54 <arch3y> nah I like this community its a bit different but its fresh
16:54 <arch3y> and you guys are open to ppl helping out
16:54 <^7heo> depends
16:54 <arch3y> I did mess up my source line
16:54 <arch3y> true
16:54 <arch3y> but you are open to the idea
16:54 <arch3y> until they screw you over lol
16:54 <clandmeter> if you use the s word ppl start to be less friendly
16:54 <^7heo> on the day, on my hunger, on my recent exprience with arch-related people, etc.
16:55 <arch3y> well Ill do my best to not offend and be friendly
16:55 <^7heo> < arch3y> but you are open to the idea
16:55 <^7heo> arch3y> until they screw you over
16:55 <^7heo> Exactly.
16:55 <^7heo> But heh for some reason I didn't bark yet while you have arch in your nick.
16:55 <arch3y> and I completely understand you have to be hard on ppl to maintain the intergrity of your system
16:56 <^7heo> So it must be one of my good days.
16:56 <arch3y> well Im competent thats the problem lol
16:56 <arch3y> probably so
16:56 <^7heo> let's hope you are as competent as advertized.
16:56 <^7heo> and no harm will be done ;)
16:56 <TemptorSent> ^7heo: You must have eaten recently ;)
16:56 <^7heo> TemptorSent: I have indeed.
16:56 <clandmeter> how can you measure competence?
16:56 <arch3y> well I guess you cant really
16:57 <arch3y> but all you can do is show in your work and demeanor
16:57 <^7heo> clandmeter: in terms of bugfixes/features.
16:57 <arch3y> that you will work hard and put in effort
16:57 <skarnet> generally, the more competent, the less verbose in IRC. :P
16:57 <arch3y> ouch lol
16:57 <clandmeter> haha
16:57 <^7heo> skarnet: indeed.
16:57 <clandmeter> ^7heo ^
16:57 <arch3y> but makes sense
16:57 <^7heo> clandmeter: wat?
16:57 <^7heo> clandmeter: you were on IRC all day...
16:58 <Shiz> arch3y: subpckages= is for split packages, yes
16:58 <arch3y> Shiz: thanks
16:58 <arch3y> I guess the go to for splits would -doc pkgs
16:59 <Shiz> a function according to the subpackage name (or a different one delimited with colon) gets invoked to move the files from the main package dir to the subpkgdir
16:59 <Shiz> yeah
16:59 <Shiz> abuild has a default doc() that you usually don't need to override
16:59 <Shiz> it automatically moves manpages out of the way
16:59 <Shiz> (if you have $pkgname-doc in your subpackages)
16:59 minimalism joined
16:59 <arch3y> ah nice
16:59 <arch3y> thats good to know
17:00 <Shiz> there's also a default dev() afaik
17:00 <arch3y> Im used to havng to split it by hand
17:00 <Shiz> for header files and static libraries
17:00 <arch3y> trying to get it to see my patch file now
17:00 <Shiz> add it to sources=
17:01 <Shiz> just the filename if it's in the same dir as the APKBUILD
17:01 <arch3y> I did but it needs to be one per line
17:01 <arch3y> yeah it is
17:01 <Shiz> not per line
17:01 <Shiz> it's just split using standard shell splitting afaik
17:01 <Shiz> so more like split by whitespace
17:01 <arch3y> k
17:01 <Shiz> but adding it to sources= and running # abuild checksum should make it work
17:02 <Shiz> if you override prepare(), be sure to call default_prepare() in your overridden function
17:02 <arch3y> no I see my problem
17:02 <arch3y> I cant type
17:02 <clandmeter> ah you fit right in
17:02 <arch3y> fixed
17:03 <arch3y> darn now my package func hates my cd to $pkgname-$pkgver
17:04 <arch3y> do you guys have any style like vars being enclosed with {} or " "
17:04 <Shiz> no {} if it's not needed
17:04 <arch3y> k
17:04 <Shiz> quote if needed/reasonable
17:04 <arch3y> yeah Im just using qoutes
17:04 <Shiz> so, in most situations unless you're very sure it's not
17:04 <Shiz> :p
17:04 <arch3y> roger that
17:05 <arch3y> k libcli is fixed and building on x86_64
17:05 <arch3y> do you guys have any plans for armv7 or armv6
17:05 <^7heo> Shiz: wait, you ONLY need to declare a subpackage with -doc
17:05 <^7heo> and it finds the manpages?!
17:05 <Shiz> yes
17:05 <^7heo> \o/
17:05 <algitbot> \o/
17:05 <^7heo> That is fucking awesome, I didn't kno!
17:05 <^7heo> know*
17:05 <^7heo> a lot more of my packages are gonna have doc now.
17:05 <Shiz> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1472
17:05 <Shiz> ;p
17:06 <arch3y> yeah thats pretty awesome
17:06 <arch3y> its a smarter builder
17:06 <^7heo> yeah
17:06 <arch3y> Ill definetly have to commend you guys on that one
17:06 <arch3y> thanks alot
17:08 <arch3y> do you guys use abuild -i to specifically install the apkg locally when testing
17:08 <clandmeter> If all goes well we will have arm7 later this year
17:09 <arch3y> Im used to building on armv6 armv7 and aarch64
17:09 <arch3y> directly on live hardware, I did see you guys hooked up with scaleway which is awesome
17:09 <clandmeter> We have both armhf and aarch64
17:10 <arch3y> is it built board specific or by processor
17:10 <clandmeter> Don't mention that name today please....
17:10 <arch3y> my apologies
17:11 <^7heo> you coulnd't know
17:11 <^7heo> but for alpine-scaleway, today was a black day.
17:11 <skarnet> what happened?
17:12 <^7heo> shit hit the fan in the scaleway world.
17:12 <^7heo> and we were without a master for a few hours.
17:12 <^7heo> (yay)
17:12 <skarnet> oh, hw issues.
17:13 <clandmeter> No worse
17:13 <clandmeter> Shortage
17:14 <^7heo> And the levenshtein distance between shor and sabo is 3.
17:16 <clandmeter> scaleway does not guarantee the hardware you run on. so if you reboot and somebody else takes your node....
17:16 <Shiz> ....
17:18 <^7heo> magic happens!
17:23 <scadu> and I was going to create account on scaleway :x
17:23 <^7heo> by all means, do :{
17:24 <^7heo> They obviously need more business ;)
17:25 <scadu> ^7heo: I should avoid reboots too then
17:25 <^7heo> scadu: who needs to reboot?
17:26 <^7heo> scadu: you can run a Linux box on 2.6
17:26 <scadu> ^7heo: only stable and well-tested software, bro
17:27 <* scadu> hides at offtopic bar
17:27 <clandmeter> scadu, its amsterdam that has issues now
17:27 <clandmeter> dunnot about france
17:27 <^7heo> s/not/no/
17:27 <^7heo> clandmeter: France will have issues in 5 years.
17:27 <^7heo> clandmeter: for now, we're still okay I think.
17:28 <arch3y> thats quite unfortunate
17:29 <^7heo> life is unfortunate. #DealWithIt.
17:29 <* ^7heo> hides
17:31 <scadu> clandmeter: welp, I prefered Amsterdam, but now I'm not so sure
17:33 duncaen joined
17:33 <kaniini> the far right is taking over everywhere :/
17:33 <^7heo> Nah, not the syria.
17:33 <* kaniini> waits for america to be great again (yeah right)
17:33 <* ^7heo> hides
18:14 <ragechin_> Shiz: fwiw, I ended up throwing the contents of my custom package to /etc/custom-packages/(...), then using the postinstall scripts to move the various contents in place
18:30 <arch3y> are pkgs like flex and bison considered default when compiling from a base build
18:30 <Shiz> arch3y: i dont think so
18:30 <Shiz> check the build-base metapkg to be sure
18:31 <Shiz> apk info -R build-base
18:31 <arch3y> Shiz: thanks
18:31 <Shiz> or alpine-sdk
18:31 <Shiz> it seems to be in neither
18:32 <arch3y> k so it has to be added to makedeps for each pkg that needs it got it
18:36 blueness joined
18:42 duncaen joined
18:50 duncaen joined
18:53 minimalism joined
19:08 tmh1999 joined
19:12 <TemptorSent> Has anyone seen fabled around lately?
19:13 <_ikke_> last week wednesday
19:23 <TemptorSent> _ikke_ : Thanks. I really need those fixes in APK and I'm not sure who else can help there.
19:46 rdutra joined
19:51 rdutra joined
20:10 gromero joined
20:27 <TemptorSent> Oh, FFS - Why do we have kernel package version that don't match their release?
20:29 LouisA joined
20:30 <TemptorSent> Vanilla only *SOMETIMES* as a revision, so we have to guess what the kernel release string is until we get it right :/
20:41 <^7heo> TemptorSent: In case of doubt, use brutefore. In case it fails, use more.
20:41 <TemptorSent> ^7heo: Yeah, 60% of the code is bruteforceing around APK problems :(
20:42 <TemptorSent> I need to know the kernel release BEFORE installing the kernel, and worse, I need to parse the kernel release and determine a kernel-package vrom that.
20:43 <^7heo> TemptorSent: then you're doing it right ;)
20:43 <^7heo> TemptorSent: also, if you wanna learn German, 'vrom' isn't the right translation for 'from'
20:43 <TemptorSent> I have several hundred lines already trying to get a consistent result, and then I find some random corner case that breaks EVERYTHING.
20:44 <TemptorSent> Yeah, yeah. I'll talk to my neurologist again about it :/
20:44 <^7heo> Gut gut.
20:44 <* ^7heo> hides
20:45 <TemptorSent> I've had a couple nasty impacts to the brain and some peripherial nerve damage -- when I type "fast", my error rate sucks. I used to be clean at over 110WPM :(
20:48 <TemptorSent> ^7heo: The PITA with the kernel verision is I need to be able to accept apk atoms, uname output, custom built versions, and kernel-release specs interchangably.
20:48 <^7heo> yeah, finger race condition...
20:49 <^7heo> it increases with faulty hardware.
20:49 <TemptorSent> EBBAC error.
20:49 <^7heo> more like EBBAK
20:50 <TemptorSent> *lol* Yeah, that too. Error Between Board and Chair
20:50 <TemptorSent> <more from electronics troubleshooting>
20:51 <TemptorSent> ...when you're the cause of the noise on the oscope, not the circuit you're probing.
20:52 <^7heo> TemptorSent: oh it wasn't "error between brain and chair" intially?
20:52 <^7heo> TemptorSent: that I corrected s/chair/keyboard/ ?
20:52 <TemptorSent> ^7heo: Same gag, different realm, same pronounciation.
20:52 <^7heo> and if I had to chose, I'd rather be the cause of the noise on the oscope than on the geiger.
20:53 <TemptorSent> Yeah, I tick a bit.
20:53 <^7heo> huhu
20:53 <^7heo> as long as you don't glow...
20:53 <TemptorSent> Nah, not yet ;)
20:54 <TemptorSent> I don't spend that much time working with carnatite.
20:55 <skarnet> the common acronym is PEBKAC
20:56 <TemptorSent> Persistent Error Between Keyboard And Chair?
20:56 <skarnet> problem exists
20:56 <TemptorSent> So many versions, and all accurate.
20:57 <TemptorSent> skarnet: Any thoughts on a sane means of determining the kernel package a given kernel release should be contained within?
21:00 <skarnet> nope, you're not taking me as a hostage tonight
21:00 <TemptorSent> Since sometimes vanilla comes up with the form '4.9.22', and sometimes '4.9.22-0', vs. grsec which appears to always be the form '4.9.22-0-grsec'
21:01 <Shiz> lol
21:02 <TemptorSent> No worries. At this point, I'm probably going to stop wasting my time trying to work around problems and wait until they're fixed to proceed. My code is getting downright ugly with the need to ' apk ... | grep -v "WARNING' | ...
21:03 <TemptorSent> And since I can't seem to raise fabled, it looks like my work is on hold until the next release.
21:03 <Shiz> that's why you apk() { apk "$@" | grep -v WARNING | ... }
21:04 <Shiz> centralise the filtering
21:04 BitL0G1c joined
21:05 <TemptorSent> Shiz: Yeah -- your patch just needs to get merged and that part would be fine. Otherwise, no warnings even when I want them :(
21:06 <TemptorSent> But the one that is absolutely killing me is the inability to give a full atom with version to apk, meaning every single invocation ends up with a loop to strip off "-*-*
21:08 <Shiz> that's what functions are for
21:08 <TemptorSent> But then, of course package names break, so I have to check for a version FIRST, then strip the version, then operate on the package, then add it back again.
21:08 <TemptorSent> No, functions don't fix the inability for apk to accept the atom.
21:09 <TemptorSent> Can you say race condition?
21:10 <TemptorSent> ...and this is exactly why I'v ended up with a broken system twice after running apk upgrade on my live system, my net flaked out and I ended up with the kernel and modules installed not matching.
21:10 <TemptorSent> Right now, almost a third of my code is parsing and handling various issues that should be the baliwick of apk.
21:11 <TemptorSent> And a third more could be eliminated with the addition of manifests to the packaging.
21:13 <TemptorSent> So right now, I'm not actually making any headway on improving anything, I'm simply writing layer upon layer of conditionals to handle all the various idisyncratic constructs.
21:16 <TemptorSent> It should not take 200+ lines to parse a kernel release, determine it's already staged, if not then create a directory and fetch/install, othewise use the existing and make sure it's current.
21:18 <TemptorSent> But that's about what it takes because of the mess of the kernel version vs. kernel release vs. pkgver vs. kernel flavor vs. custom build
21:22 <TemptorSent> And, to top it off, to remain compatabile, mkinitfs needs to take the (uname -r) output and figure out not just which kernel package it belongs to, but which modules it's supposed to use.
22:05 duncaen joined
22:26 Madchen left
22:31 tmh1999 joined
22:40 <kaniini> Shiz: what patch is this
22:40 <TemptorSent> kaniini: A very small patch to fix the output of apk warnings to go to stderr rather than stdout.
22:41 <TemptorSent> Issue #7107
22:41 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
22:42 <kaniini> link ?
22:42 <kaniini> i'll merge it
22:42 <Shiz> its in that link
22:43 <kaniini> https://git.alpinelinux.org/cgit/apk-tools/commit/?id=5ba27c90007b2441f1fe35365c753a5365f3a2de
22:43 <TemptorSent> Thank you!
22:44 <Shiz> \o
22:45 <TemptorSent> If anyone has any thoughts on fixing #7100, much of the remaining pain would go away :)
22:45 <algitbot> Feature #7100: apk should support the use of full &#39;$pkgname-$pkgver&#39; atom as returned by &#39;apk search -x $pkgname&#39; everywhere &#39;$pkgname&#39; is used - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7100
22:45 <TemptorSent> And thank you Shiz for the patch.
22:46 <kaniini> #7100 not possible
22:46 <algitbot> Feature #7100: apk should support the use of full &#39;$pkgname-$pkgver&#39; atom as returned by &#39;apk search -x $pkgname&#39; everywhere &#39;$pkgname&#39; is used - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7100
22:47 <kaniini> done
22:48 <kaniini> apk-tools 2.7.0-r4
22:48 <Shiz> woo new apk-tools
22:52 <tmh1999> kaniini : forgot checksum for new patch for apk-tools
22:53 <tmh1999> lol
22:54 <kaniini> anyway
22:55 <tmh1999> anyway ?
22:55 <kaniini> TemptorSent: #7100 fundamentally not possible as the depsolver does nto really think in terms of 'atoms', but 'dependencies' and most places that take pkgname really takes a dependency
22:55 <algitbot> Feature #7100: apk should support the use of full &#39;$pkgname-$pkgver&#39; atom as returned by &#39;apk search -x $pkgname&#39; everywhere &#39;$pkgname&#39; is used - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7100
22:55 <kaniini> TemptorSent: what you *could* do is try `apk fetch linux-grsec=4.9.whatever`
22:56 <kaniini> TemptorSent: e.g. flip the last - into a =, which would make it a valid dependency that describes the atom
23:01 <TemptorSent> kaniini: Crap. That kills it for me. The inability to feed search results back into fetch essentially makes the entire process a giant mess.
23:02 <TemptorSent> I think I'm going to give it up as a bad job.
23:03 <TemptorSent> It's been fun playing, but my the dent in my forehead is getting a bit too large from banging my head against the wall.
23:04 <TemptorSent> Someone ping me when there's a new package format that doesn't have the limitations and I might try again.
23:05 <TemptorSent> It doesn't look like I'll be able to functionally use alpine for my original intended purpose until then.
23:08 <TemptorSent> I can't reliably make mkinitfs work without the occasional failure and start from scratch due to package-bumps mid-process.
23:08 <kaniini> in fact, apk search is the only thing that outputs like that
23:08 <kaniini> TemptorSent: what exactly are you trying to do?
23:08 <TemptorSent> I'm guessing people with fast,reliable connections never see this.
23:09 <TemptorSent> How about this "apk search -x `apk search -x zfs`"
23:09 <TemptorSent> Something other than no-results would be nice.
23:11 <TemptorSent> In other words, every time I query a package, I have to strip the version, do apk search -x on the package name, compare the version I get against the version specified, then use the stripped name to fetch the packages, then check the versions, then unpack the kernel version file from the kernel so I can find the REAL kver....
23:11 <TemptorSent> In other words, I spend all of my time and code manipulating version strings back and forth.
23:12 <TemptorSent> And I can't do it generically because it's not actually consistent nor reliable (see meta-packages)
23:12 <TemptorSent> So every time I fetch -o, I'm taking a gamble.
23:13 <TemptorSent> er apk fetch -s
23:13 <TemptorSent> I have absolutely no guarentee that the package I just searched for by name is actually the one I fetch.
23:13 <TemptorSent> So I have to download each and every apk to a file first, verify that, then extract from that.
23:14 <TemptorSent> You can see where this quickly gets absurd.
23:14 <arch3y> do you guys want kernel style commit messages?
23:15 <TemptorSent> kaniini: By the time I'm done, I end up with somethign that's both fragile and slow.
23:17 <TemptorSent> kaniini: It means every time I have a list of packages, I have to run through a loop at a minimum of three times.
23:19 <TemptorSent> kaniini: And it makes parsing ugly, because every place I touch a package or apk, I need to handle the same thing.
23:21 <TemptorSent> For instance: You can specify a kernel as either an explicit .apk file, a build directory, a kernel release, or a package (with or without version)
23:22 <TemptorSent> But it immediately becomes ambiguous because you don't have a of making sure you don't fetch the wrong version without going through another round of hoops.
23:22 <TemptorSent> ^way
23:24 <TemptorSent> What I don't understand is why the parser can't understand the exact same format it uses for apk files and search output.
23:25 <TemptorSent> Clearly, it's unambiguous somewhere in apk.
23:25 <kaniini> what does the `linux-grsec-4.3-4.3.49-r0` atom describe?
23:25 <kaniini> is the version 4.3-4.3.49-r0?
23:25 <TemptorSent> ?
23:25 <kaniini> or is it 4.3.49-r0
23:26 <kaniini> this is assuming that you make it the same as `linux-grsec-4.3=4.3.49-r0`
23:26 <TemptorSent> Given what I've been using, it would reslove as 4.3.49-r0
23:26 <kaniini> so, what you can do is
23:26 <kaniini> linux-grsec=<version>
23:26 <TemptorSent> What I want is linux-grsec-4.3.49-r0
23:26 <kaniini> try that with apk fetch
23:26 <kaniini> you can also do
23:26 <kaniini> yes
23:26 <kaniini> so
23:27 <kaniini> try linux-grsec=4.3.49-r0
23:27 <kaniini> instead
23:27 <kaniini> or would it be helpful
23:27 <kaniini> if we had an option
23:27 <kaniini> to make apk search output
23:27 <TemptorSent> Here's the problem, that means EVERY time, I need to either do 3 variable transforms per atom or a sed script.
23:27 <kaniini> as linux-grsec=4.3.49-r0
23:27 <kaniini> ok
23:27 <kaniini> so
23:27 <TemptorSent> Take a apk filename, try to find the package based on that.
23:27 <kaniini> if we change apk search
23:28 <kaniini> to output something that would be a valid dependency description instead
23:28 <kaniini> would that solve your problem? :)
23:28 <kaniini> on that one
23:28 <kaniini> would something like
23:28 doppo joined
23:28 <kaniini> apk info --version --format="%{name}=%{version}" <apk file>
23:28 <kaniini> solve the problem?
23:29 <TemptorSent> That's the problem, I have to do apkfile="$(apk search -x "${pkg%-*-*})" ;
23:30 <TemptorSent> Not really, because it still doesn't give me the same thing as the apk file, which is what I then have to open and operate on.
23:30 <TemptorSent> So it still leaves me at least one more step in a loop
23:31 <kaniini> but what i am saying is
23:31 <kaniini> you could do
23:31 <kaniini> apk fetch $(apk search -x --format "%{pkg}=%{version}")
23:32 <TemptorSent> For instance, in staging modules I need to check first for the "flavored" version of a package (zfs-grsec) before the unflavored version (zfs), but still have to check unflavored so things such as linux-firmware work.
23:33 <arch3y> k first commit going out lets hope its a winner
23:33 <kaniini> i guess i just dont understand what you want changed in apk
23:33 <kaniini> oh well
23:33 <TemptorSent> Yeah then I have to do:
23:33 <kaniini> you said you wanted the ability to pass output from apk search into apk fetch
23:34 <TemptorSent> tar -tvf "$(apk search -x "${pkg%-*-*}"
23:34 <kaniini> i proposed a way to do it
23:34 <TemptorSent> I need the output from apk search -x to remain the same, as I rely on that to figure out which file I'm operating on!
23:36 <TemptorSent> Also, file/direcotry names with the equal are not my idea of wonderful.
23:36 <kaniini> so if we made - equivilant to = for dependency nodes, would that solve your problem?
23:36 <TemptorSent> If it would allow it to accept the atom as it appears in apk filenames and the output of search -x, it should.
23:37 <kaniini> oops, i mean, equivalent
23:38 <TemptorSent> It seems it should be possible to check against the list of atoms before invoking the depsolver, since everything uses the database anyway.
23:39 <TemptorSent> Check the index for an exact match and preload that for the depsolver if found.
23:39 <kaniini> well
23:39 <TemptorSent> I just haven't learned my way around the guts of apk yet, as it's bounces all over the place and comments are few.
23:39 <kaniini> the problem is
23:39 <kaniini> apk fetch
23:40 <kaniini> calls apk_package_foreach_name_matching
23:40 <kaniini> er
23:40 <kaniini> apk_name_foreach_matching()
23:40 <TemptorSent> file/line so I can follow along?
23:42 <kaniini> fetch.c:326
23:42 <arch3y> ^7heo: you around by chance?
23:42 <TemptorSent> Ahh, I was up in the wrong chunk of the file.
23:44 <TemptorSent> kaniini: Okay, I'm seeing that -- why couldnt' apk_name_foreach_matching do the match for the first level and replace the atoms, then recurse?
23:44 <TemptorSent> Is there a TOC function on github somewhere?
23:45 <kaniini> TemptorSent: because apk_name_foreach_matching only deals in linux-grsec portion, not the full 'atom'
23:46 <TemptorSent> So it has no ability to fetch a specific version?
23:46 <kaniini> exactly
23:46 <kaniini> what you could do i think is
23:46 <kaniini> let me try something
23:47 <TemptorSent> Shit, that pretty much means I have no choice but to download the files to a tmp dir and manually verify them.
23:47 <kaniini> haha i think i found a solution
23:47 <kaniini> it is really bad, but it will work
23:48 <TemptorSent> If *you're* saying its bad, it must be BAD!
23:48 <kaniini> raccoon:/home/kaniini/apk-tools/src# apk fetch --recursive .mkinitfs-dep
23:48 <kaniini> Segmentation fault
23:48 <kaniini> do you see where i am going with this
23:49 <TemptorSent> Other than pointing out apk really shouldn't segfault with bad input? :P
23:49 <kaniini> would you like to know why that segfaults?
23:49 <kaniini> .mkinitfs-dep is an injected virtual that depends on linux-grsec=4.9.22-r0
23:49 <TemptorSent> Because it's attempting to treat that as a package name and it's probably in a dep loop.
23:50 <kaniini> nope
23:50 <kaniini> it's because
23:50 <kaniini> it has no source URL
23:50 <TemptorSent> Oh, bloody hell.
23:50 <kaniini> so it tries to fetch NULL
23:50 <kaniini> !
23:50 <kaniini> one sec
23:50 <kaniini> i got this
23:50 <kaniini> I GOT THIS
23:50 <TemptorSent> Okay, that get's us half way to hell :)
23:50 <kaniini> you will have to do
23:50 <kaniini> linux-grsec=4.9.22-r0
23:51 <kaniini> as the pin
23:51 <kaniini> but
23:51 <kaniini> then you can apk fetch --recursive on the virtual
23:51 <kaniini> and it will work
23:51 <kaniini> as soon as i fix this NULL thing
23:51 <TemptorSent> Hmm, then how do I find out what I ended up with for file names?
23:51 <kaniini> it will be back to
23:51 <kaniini> linux-grsec-4.9.22-r0
23:51 <kaniini> once fetched
23:52 <kaniini> it is just the argument on the commandline
23:52 <kaniini> one sec
23:52 <TemptorSent> Right, and how do I conveniently transform the equal at the second slash in shell script again? :P
23:52 <TemptorSent> But it's at least getting closer.
23:54 <kaniini> it is called
23:54 <kaniini> you save the original arg
23:54 <kaniini> :p
23:56 <kaniini> /sbin/apk: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped, with debug_info
23:56 <kaniini> time to gdb this