<     May 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:11 <TemptorSent> Also, wtf is 'z[]' for in fetch.c?
00:21 LouisA joined
01:25 <kaniini> it's non-free proprietary software encoded in apk-tools as part of a voluntary NSA implant programme
01:25 <kaniini> didn't you read about it on wikileaks?
01:25 <TemptorSent> *LOL*
01:26 <kaniini> if you really want to know: apk --force fetch coffee
01:26 <TemptorSent> Now, do I build a binary just to dump it and make sure? :P
01:27 <TemptorSent> Okay, that's awesome :)
01:27 <TemptorSent> Well played.
01:27 <kaniini> i am pretty sure it is explanatory in the source, really
01:27 ephemer0l joined
01:27 ephemer0l joined
01:29 <TemptorSent> ...and RE: BLOB_PRINTF?
01:29 <kaniini> BLOB_FMT is "%.*s" which takes two arguments,
01:29 <kaniini> BLOB_PRINTF is a macro which expands those two arguments for the sake of BLOB_FMT
01:30 <TemptorSent> Okay, so I can use that directly to get the pkg version? Or is there a proper macro for that too?
01:30 <kaniini> if you're wondering that the %.* format modifier does, it defines an upper boundary on how large the supplied buffer (e.g. passed in as argument) may be
01:30 <kaniini> what precisely are you trying to do?
01:32 <TemptorSent> I'm attempting to add an additional manifest format that provides the arch, package name, package version, checksums, filenames, and link targets, as well as uid/gid/mode/size if feasible.
01:33 <kaniini> right now i rather add manifest generation for a given APK file. as you can tell right now, it only introspects the apkdb
01:33 <TemptorSent> I want to solve the feature request for a package index allowing search by file for uninstalled packages.
01:33 s33se_ joined
01:34 <TemptorSent> Good enough - I'll mess with adding the additional formatting, just want to use the right macros :)(
01:36 <TemptorSent> It looks like it's a rather convoluted path to read an apk file using the same mechanism - I couldn't actually figure out where the hook would go without already having a hash key in an index.
01:38 <kaniini> well
01:38 <kaniini> what i'm saying is
01:38 <kaniini> i'm likely to rewrite the entire tool fundamentally
01:38 <kaniini> which may break your patch
01:39 <kaniini> so if you want to hack on apk manifest i would suggest beating me to the apk file stuff
01:40 <TemptorSent> If I knew where to start on the apk file interface, I'd dig in. Where does it read a .apk file in the code without the information preloaded from the index?
01:41 <TemptorSent> The code for fetch was barking up the wrong tree.
01:41 <kaniini> :D
01:41 <TemptorSent> (sorry, couldn't resist the pun)
01:43 <^7heo> tsss
01:46 <kaniini> another thing done already is
01:47 <kaniini> apk gen --key-file=... --control-dir=... --data-dir=...
01:48 <TemptorSent> Very cool - it automatically handles appending the archives, stripping the extra header, and signing, outputting a valid .apk?
01:48 <TemptorSent> What is the resulting apk name?
01:48 <^7heo> btw
01:48 <^7heo> we should gather again
01:48 <^7heo> last time we didn't exchange kes
01:48 <^7heo> keys
01:49 <kaniini> pgp is for losers
01:51 <kaniini> TemptorSent: no, it just synthesizes a valid apk from scratch
01:52 <TemptorSent> I mean it creates the control archive, including sig, and appends the data archive without an extra empty tar header in the middle.
01:54 <^7heo> kaniini: what would you use instead?
01:56 <kaniini> TemptorSent: that's not a valid apk. the extra header is used to tell the sections apart.
01:56 <kaniini> ^7heo: signify
01:57 BitL0G1c joined
01:58 <TemptorSent> kaniini: Hmm, I though it only had a single empty header in the middle, allowing standard tar to read the entire archive without seeing a premature end of archive (two empty headers in a row)
01:59 <kaniini> TemptorSent: yes and it keeps that
02:02 <kaniini> TemptorSent: i also want apk fetch --source to fetch the source files used to generate the APK
02:03 <TemptorSent> Now that would be cool!
02:04 <kaniini> TemptorSent: and for that matter, apk add --make-depends to create a virtual package and add a packages makedepdnds/checkdepends (as recorded in apkindex)
02:04 <TemptorSent> I like it!
02:05 <^7heo> kaniini: http://www.openbsd.org/papers/bsdcan-signify.html
02:05 <^7heo> kaniini: that?
02:06 <Shiz> @kaniini │ TemptorSent: i also want apk fetch --source to fetch the source files used to generate the APK
02:06 <kaniini> ^7heo: yes
02:06 <Shiz> so they would be embedded in .PKGINFO?
02:06 <TemptorSent> How do we handle building such source? aports?
02:06 <kaniini> Shiz: yes
02:06 <kaniini> TemptorSent: in alpine, abuild
02:07 <TemptorSent> What about the patches/files in each package abuild directory?
02:07 <^7heo> kaniini: that's exactly equivalent to pgp, requirement wise
02:08 <kaniini> ^7heo: yes but has a less hostile user experience
02:09 <kaniini> TemptorSent: aports is just a collection of those :)
02:09 <kaniini> TemptorSent: and, apk is used by distributions other than alpine
02:09 <TemptorSent> Right, but how do you package that in a manner that allows apk fetch --source to work?
02:09 <^7heo> kaniini: sure, that's a good thing
02:09 <^7heo> kaniini: but for now pgp also works
02:10 <kaniini> wouldn't know, don't use it
02:10 <kaniini> i don't use software that makes me angry
02:10 <Shiz> what other distros use apk?
02:10 <Shiz> out of curiosity
02:10 Fooster joined
02:10 <^7heo> adelie
02:11 <^7heo> but it's modified afaik
02:11 <kaniini> Shiz: adelie which uses its own build system based on portage
02:11 <Shiz> (poor souls?)
02:11 <Shiz> :p
02:11 <^7heo> tsss
02:11 <kaniini> ^7heo: nope. apk has upstream support for RSA/SHA256 signatures now
02:12 <TemptorSent> What about SHA512?
02:12 <kaniini> yes, that too.
02:12 <TemptorSent> It seems SHA256 is quickly being deprecated.
02:13 <kaniini> apparently the RSA/SHA signatures also works with ECDSA
02:13 <Shiz> that uhm
02:13 <Shiz> i would verify that
02:13 <Shiz> :P
02:13 <kaniini> but i wouldn't recommend it as it's not an officially supported configuration :)
02:14 <kaniini> fuzzy version selection is the only patch adelie has and i'm inclined to incorporate it as well
02:14 <kaniini> it would be useful for alpine users
02:14 <^7heo> yeah
02:14 <Shiz> that seems useful yes
02:15 <TemptorSent> Supporting ec25519 would be nice.
02:15 <TemptorSent> Signing with both sha512 and ec25519 would protect from just about all reasonable collision attacks.
02:15 <kaniini> adelie imo is more of a thought experiment though
02:15 <kaniini> at this point
02:16 <kaniini> because from what i hear gentoo is kinda falling apart these days
02:16 <^7heo> naaah
02:16 <Shiz> TemptorSent: 'both'
02:16 <Shiz> they would be a single scheme
02:16 <kaniini> like there's more alpine devs than active gentoo devs and such
02:16 <Shiz> you can't sign something with sha512, and you can't sign something effectively with just asymmetric crypto
02:16 <Shiz> :P
02:17 <Shiz> kaniini: idk, people have been saying that gentoo is dying for 10 years
02:17 <Shiz> it doesn't seem to be going anywhere
02:17 <kaniini> the people there still working on it i guess are doing good work tho
02:18 <^7heo> if it hasn_t moved for 10 years
02:18 <^7heo> it's probably dead
02:18 <Shiz> by going anywhere i mean going away
02:18 <Shiz> it certainly has moved
02:18 <kaniini> there are also the alpine derivatives
02:18 <^7heo> I knw
02:18 <^7heo> srry I had to
02:19 <TemptorSent> Sorry Shiz, I meant RSA/SHA512 and ED25519
02:19 <Shiz> it would be Ed25519/SHA512 too
02:19 <Shiz> hopefully
02:19 <Shiz> :)
02:20 <TemptorSent> Right, that's how ed25519 is defined IIRC
02:20 <kaniini> umm
02:20 <Shiz> no
02:20 <kaniini> ed25519 is just a asymmetric keypair scheme
02:20 <kaniini> you can use whatever hash you want
02:20 <Shiz> actually
02:20 <Shiz> no he's right
02:20 <Shiz> kaniini: EdDSA is the scene
02:20 <Shiz> ed25519 is EdDSA paramterized to Curve25519 and SHA512
02:20 <TemptorSent> The ed25519 dsa specifies a SHA512 hash
02:20 <Shiz> apparently
02:21 <kaniini> but apk needs proper ed25519 support
02:21 <Shiz> https://en.wikipedia.org/wiki/EdDSA#Ed25519
02:21 <Shiz> see here
02:21 <kaniini> either way
02:21 <Shiz> SHA512 is actually part of ed25519, did not know this either
02:23 <kaniini> there are also internal alpine derivatives too
02:24 <Shiz> at dayjob there's a customized initramfs, does that count as alpine derivative
02:24 <kaniini> i know of a few institutions who rebuild the entire distribution
02:24 <Shiz> :P
02:24 <kaniini> and sign it with their own keys
02:25 <kaniini> adelie kind of started as a thought experiment at day job
02:25 <kaniini> we wanted a backup plan for our alpine machines
02:25 <TemptorSent> Okay, so my question regarding how to make 'apk fetch --source' fetch everything needed to build the package remains... Does it basically mean we include the contents of the package's port directory in the resulting package?
02:26 <kaniini> no
02:26 <kaniini> it would just be URI list generated by abuild
02:26 <TemptorSent> Oh.
02:26 <Shiz> i mean
02:27 <Shiz> you could add the files in the apkbuild directory prefixed by the primary git remote as URLS
02:27 <TemptorSent> So it would lack all the alpine patches/initscripts/etc.?
02:27 <Shiz> :D
02:27 <TemptorSent> That would work if apk could figure out how to fetch from them I guess.
02:27 <Shiz> it was a joke
02:27 <Shiz> i'd prefer that apk not rely on git
02:28 <TemptorSent> Well, not from git itself, but from a http accessible front end to the repo...
02:28 <TemptorSent> That might be a sane solution.
02:29 pickfire joined
02:53 <TemptorSent> kaniini: Okay, so looking at verify.c, it appears essentially the same code for the input stream would be used, replacing apk_sign_ctx_verify_tar with apk_manifest_from_tar or some such function, yes?
02:54 <awilfox> what about not-abuild generated apks? just a thought to toss in
02:55 <TemptorSent> awilfox: Good question -- any thoughts on how to handle source in a dist-agnostic fashion?
02:56 <TemptorSent> abuild is rather tightly tied to the .apk format currently it appears (not necessarily the other way around of course)
02:57 <awilfox> TemptorSent: something in the manifest possibly. thinking something like... SOURCE: uri://foo.bar/package-1.2.3.txz SOURCE: uri://foo.bar/package-1.2.3-data.txz PATCH: uri://distro.org/package/0001-musl.patch
02:57 <awilfox> TemptorSent: oslt
02:58 <TemptorSent> That would work well for handling the discrete patches, but the sed magic and such in APKBUILDS is likely a problem.
02:58 <awilfox> note that there are definitely packages with more than one source tarball (ones I can think of off the top of my head: gimp, torcs, xen)
02:58 <awilfox> and ofc more than one patch
02:59 <TemptorSent> It would take a major overhaul of aports to extract all the magic to agnostic scripts.
02:59 <awilfox> TemptorSent: sed magic is evil, and that sort of thing should be done in patches imo, of course if you are doing version strings then you have more maintenance burden...
03:00 <TemptorSent> Yeah, but often a sed or awk script is required to transform something that's otherwise a moving target.
03:00 <Shiz> apk fetch shouldn't fetch everything needed to build a package
03:00 <awilfox> TemptorSent: over in Adélie I am in the middle of trying to completely revamp the ebuilds we use to have the minimal amount possible of "magic" and get as close to "./configure; make; make install DESTDIR=/usr/src/package/image/" as possible for every package, and that has meant a lot of trying to make people upstream build system fixes
03:00 <TemptorSent> Paths/versions/name-conflicts...
03:00 <Shiz> if you want to do that, clone aports tat the right revision
03:00 <Shiz> jamming everything into the .apk is utterly useless
03:01 <Shiz> s/tat/git at/
03:01 <awilfox> ^ I agree with this, tbh
03:01 <TemptorSent> The problem is most users who want to build one or two packages from source probably don't want to build anythign ELSE from source.
03:01 <awilfox> apk source --fetch means "fetch source", and probably patches
03:01 <awilfox> not "fetch the entire build system"
03:01 <Shiz> it's not like aports is a heavy repo
03:02 <awilfox> with debian (hopefully I am not immediately /kicked for mention the "D" word, I know foul language is prohibited here), apt-get source fetches the .deb stuff from their repo along with the package
03:02 <TemptorSent> Right, but if you build it and it doesn't work as expected without manual intervention, it's going to be rather painful to support.
03:02 <awilfox> but that isn't necessarily a requirement
03:03 <TemptorSent> Right - but including a pointer to the original packaging repo is probably a good way to handle it.
03:03 <Shiz> apk fetch --source is not for building the package
03:03 <awilfox> it's for fetching source
03:03 <Shiz> exactly
03:03 <awilfox> which as I said, can be easily done with SOURCE: PATCH:
03:03 <TemptorSent> If desired, you could define more than one for different dists in the same package I suppose.
03:03 <awilfox> zero-or-more of PATCH, one-or-more of SOURCE
03:03 <Shiz> awilfox: there's packages with zero remote sources
03:04 <Shiz> so not quite
03:04 <awilfox> well actually, zero-or-more of SOURCE for packages that have no sources
03:04 <Shiz> :)
03:04 <TemptorSent> Yeah, those are the ones that require the repository :)
03:04 <Shiz> almost every package requires the remote repo
03:04 <Shiz> repeat after me: apk fetch is NOT for building packages
03:05 <TemptorSent> What is the point of fetching source if you're not going to build a local package with it?
03:05 <awilfox> inspection
03:05 <awilfox> gdb stepping
03:05 <awilfox> auditing
03:05 <TemptorSent> That's what kaniini just spent a lot of time making possible.
03:05 <awilfox> I have used `apt-get source` a lot of times, and built a package with it once
03:05 <Shiz> what awilfox said
03:05 <Shiz> it's not for building packages
03:05 <Shiz> and it's not feasible to make it so
03:05 <Shiz> nor desirable
03:06 <TemptorSent> So you DON'T want to manage custom built source with apk?
03:06 <Shiz> correct
03:06 <Shiz> i don't
03:06 <TemptorSent> Tell kaniini.
03:06 <Shiz> i'm sure he already knows my opinion
03:06 <Shiz> apk manages .apks
03:07 <TemptorSent> So now we have to do some sort of 'fake' package crap to satisfy deps, and conflicting files will not resolve?
03:07 <Shiz> nothing fake about it
03:07 <TemptorSent> Why on earth would that be preferable to making .apks easy to build and using apk to manage them?
03:07 <Shiz> .apks are easy to build
03:07 <Shiz> that's the entire purpose of abuild
03:08 <TemptorSent> Um, you install say php from source...
03:08 <TemptorSent> now, you have somethign that depends on it -- now what?
03:08 <Shiz> then you shouldn't stop trying to use the package manager for things that are not packages
03:08 <Shiz> should*
03:10 <TemptorSent> The whole point is to make it EASY to make a package.
03:10 <Shiz> yes, which is abuild's purpose
03:10 <Shiz> not apk's
03:19 <TemptorSent> I don't care about abuild, portage, or whatnot - I'm talking about the actual packaging of an apk.
03:20 <TemptorSent> see 'apk gen' above.
03:21 <TemptorSent> If you're going to fetch source, fetch ALL sources, including the original repo directory contents.
03:21 <Shiz> that's not gonna happen
03:21 <Shiz> i can tell you that much
03:22 <TemptorSent> Why the hell not? You're telling me we can't fetch ONE directory out of aports without cloning the entire thing?
03:22 <Shiz> that is exactly what i'm telling you
03:25 <TemptorSent> Fine, then list EVERY file in the source repo or fetch recursively!
03:26 <Shiz> no
03:26 <TemptorSent> Then what does it mean to fetch the source of alpine-baselayout?
03:26 <Shiz> nothing, probably
03:26 <TemptorSent> You have a dozen files in there.
03:26 <Shiz> the source is identical to the package
03:27 <Shiz> it has no meaningful definition of source
03:27 <TemptorSent> No, it's not -- it generate shadow using awk, for instance.
03:27 <Shiz> in the APKBUILD
03:27 <Shiz> so fetching all files in the git repo wouldnt help anything with that
03:27 <TemptorSent> As well as several other files using echo. (Yes, in the APK build)
03:28 <TemptorSent> So the package != source.
03:28 <TemptorSent> Okay, I give up - we clearly have very different concepts of what the source of a package consists of.
03:29 <Shiz> embedding the source from your definition is not feasible or desirable in the apk
03:29 <TemptorSent> I'm not wanting to embed it in the apk, I just want a link to it's repo in the apk!
03:30 <Shiz> that is what i mean
03:31 <TemptorSent> Why is it logical to provide uris for the source files to build the binaries, but not the source of the REST of the PACKAGE?
03:31 <Shiz> because 1) those urls can't be meaningfully easily determined
03:32 <Shiz> 2) to actually do something with them apk would incur a dependency on whatever protocol the source uses, which is both varying and probably not desirable
03:33 <Shiz> and no, the url of the primary git repo is not meaningful or usable
03:33 <Shiz> git repo remote*
03:33 <TemptorSent> I'm sorry, but your logic isn't making sense. Why would those uris be any harder to determine than the uris for the upstream source? A local package uses local uris.
03:33 <Shiz> because let me show you mine
03:33 <Shiz> » git remote get-url origin
03:33 <Shiz> alpine:aports
03:34 <Shiz> okay, so tell me how you would determine the url
03:34 <Shiz> the upstream source are embedded into the APKBUILDs
03:34 <Shiz> source URLs*
03:34 <TemptorSent> Okay, what's wrong with that for the uri?
03:34 <Shiz> it's not at all meaningful?
03:34 <TemptorSent> algitbot:alpine:aports/...
03:35 <Shiz> nobody can do anything with that url
03:35 <TemptorSent> git:alpine:aports/.../
03:35 <Shiz> assuming your intent is to allow people to fetch it themselves, that url is literally useless
03:36 <TemptorSent> Assuming we resolve alpine to an alpine git repo, why not?
03:36 <Shiz> that's a big assumption
03:36 <Shiz> this is just local config on my side
03:36 <Shiz> i could call the host mcpoopyhead and it would still be valid for me
03:37 <TemptorSent> Yeah, the user is welcome to resolve it however they want.
03:37 <Shiz> are you going to try to map every possible variation for every developer for every machine to the 'public-reachable' url
03:37 <Shiz> for g.a.o
03:38 <TemptorSent> No, I'm expecting we can list the origin repo by name and resolve it.
03:39 <Shiz> that is not a name, it's a full URL
03:39 <TemptorSent> The user may have to set the appropriate upstream if they want something other than what we resolve.
03:39 <TemptorSent> aports is the repo, alpine is your host, yes?
03:40 <Shiz> aports is the path
03:40 <Shiz> alpine is the host
03:40 <Shiz> it's a SSH URL
03:40 <TemptorSent> aports == aports.git?
03:41 <Shiz> aports == aports
03:41 <TemptorSent> aports is the root of the git repository?
03:41 <Shiz> yes
03:41 <TemptorSent> Close enough.
03:43 <TemptorSent> So if we have a repo name, why don't we just treat it the same way we do the apk dist repos and specify the source repos in /etc/apk/repositories?
03:43 <TemptorSent> (or a parallel file)
03:43 <Shiz> wtf?
03:45 <Shiz> just matching by repo name is awful, for one
03:45 <TemptorSent> If we fetched a .apk from a particular repository, WTF can't we also fetch the package source?
03:45 <Shiz> because they are two separate systems
03:46 <TemptorSent> Because storing a copy of the contents of the package port when it builds the package is hard why?
03:47 <Shiz> not hard, just semantically wrong
03:47 <Shiz> anyway
03:47 <Shiz> im going to bed
03:47 <Shiz> this is tiring
03:47 <TemptorSent> How is it semantically wrong to store the source of the package itself?
03:48 <TemptorSent> call it a .sapk for all I care.
03:49 <kaniini> oh for fucks sake
03:50 <kaniini> TemptorSent: we want to keep apk agnostic of package build systems (other distributions use apk, again)
03:50 <TemptorSent> Sorry kaniini - didn't mean to spam you out.
03:50 <kaniini> TemptorSent: so the sapk would be redundant
03:51 <TemptorSent> kaniini: Understood - but aside from the APKBUILD itself, the contents of the aports directory is in many cases the complete source of a package.
03:52 <TemptorSent> by sapk, I mean a signed tarfile of the package's aport directory.
03:52 <TemptorSent> Or whatever source build system.
03:52 <kaniini> TemptorSent: tell that to adelie
03:53 <TemptorSent> adelie uses portage, right?
03:53 <kaniini> awilfox: can you point me to your collection of APKBUILDs in adelie?
03:53 <TemptorSent> That's why I said ASIDE from the APKBUILD itself.
03:54 <TemptorSent> in portage speak, most of the contents of the aport directories would go in $pkg/files
03:54 <kaniini> TemptorSent: i just want to record the URIs to the source files and allow apk to download them. you would still use abuild or equivalent to rebuild the package (assuming you wanted to even do that)
03:54 <TemptorSent> I'm not sure how the hooks are handled in adelie
03:54 <TemptorSent> kaniini: Okay, so what does 'apk fetch --source alpine-baselayout' mean?
03:56 <kaniini> it would download the sources in $sources with the aports files being prefixed with http://git.alpinelinux.org/aports/raw/...
03:56 <TemptorSent> At the least, it should probably contain a pointer to 'https://github.com/alpinelinux/aports/master/main/alpine-baselayout/'
03:56 <kaniini> (and yes, also the APKBUILD would be implicitly in the sources list, but that's abuild's job)
03:56 <kaniini> i wasn't aware we officially used github, cool
03:57 <TemptorSent> Er oops :P
03:57 <kaniini> that's basically what shiz was saying above btw
03:57 <kaniini> apk gen is not about providing a source build system either
03:57 <kaniini> it's about separating concerns properly, so that abuild manages source and apk manages actually composing the binaries it handles
03:58 <TemptorSent> I had suggested a link to each of the files in the directory and he said absolutely not.
03:58 <kaniini> well luckily that's not really his decision now is it
03:58 <TemptorSent> My point is that the source of the package includes not just the upstream, but the alpine-created artifacts as well.
03:59 <kaniini> yes, it does absolutely
03:59 <kaniini> but abuild itself should still be used to manage the downloaded artifacts
03:59 <TemptorSent> So fetching a directory in a manner that abuild can then use directly would be desirable.
03:59 <kaniini> i think largely shiz was scared that you were proposing something along the lines of having apk manage the sources
04:00 <TemptorSent> Oh, hell no!
04:00 <Shiz> 3i have my own separate concerns with your proposal
04:00 <Shiz> since where does 'http://git.alpinelinux.org/aports/raw/' get inferred from
04:00 <Shiz> especially for 3rdparty repos
04:01 <Shiz> which may not have web front ends or different ones
04:01 <kaniini> my goal is two-fold:
04:01 <kaniini> 1) make it possible for end-users to be able to easily say "show me the source" and get some sources
04:01 <kaniini> Shiz: abuild config option :)
04:01 <kaniini> Shiz: abuild config option :)
04:01 <Shiz> globally?
04:01 <Shiz> i have one abuild config but multiple repos
04:01 <Shiz> :P
04:01 <kaniini> Shiz: if you disable it, then it does not spit out the urls
04:02 <kaniini> Shiz: in your abuild.conf
04:02 <kaniini> Shiz: i expect apk source metadata to be opt-in anyway
04:02 <kaniini> Shiz: but maybe it would be nice to have repo-specific configs in abuild, too
04:02 <Shiz> i think it would be, since i juggle multiple repos under one user
04:02 <Shiz> :P
04:02 <Shiz> (this would also be nice for the output directory stuff...)
04:03 <Shiz> or just a .abuild.conf in the git root that it finds or whatever
04:03 <Shiz> idc
04:03 <Shiz> some form of repo-specific config
04:03 <kaniini> Shiz: but basically idea is you define it in abuild.conf and if the template is empty, then source metadata wont be emitted
04:04 <kaniini> anyway
04:04 <kaniini> apk gen is not about replacing source managers
04:05 <kaniini> to the contrary, it's about making new source managers easier to write
04:05 <kaniini> based on what we learned from adelie using apk but not abuild
04:07 <kaniini> apk gen and apk fetch --source are completely unrelated things
04:07 <kaniini> apk gen is about simplifying abuild and portage's apk generator
04:07 <kaniini> apk fetch --source is about making it easier for end users to obtain sources for packages (either to examine them or to customize them)
04:11 <TemptorSent> ...it seems that the two functions are complementary, as the only remaining part needed is the actual build tool.
04:11 <kaniini> so hopefully that clears that up
04:11 <kaniini> yes, but the source manager itself is unspecified by apk
04:11 <kaniini> and we wish to keep it that way
04:12 <TemptorSent> Right.
04:13 <kaniini> (this is with my apk hat on, not my alpine hat, to be clear. abuild is and will always be the source manager of alpine)
04:13 <TemptorSent> alpine packages will have APKBUILDs, adelie packages will have .ebuilds
04:13 <kaniini> and hypothetical distribution C could have something that looks like rpm specfiles
04:13 <kaniini> doesn't matter to me
04:13 <kaniini> :)
04:14 <kaniini> i recently met up with an rpm guy and he told me about how rpm specfiles really work
04:14 <kaniini> and my eyes glazed over and i wished for death
04:15 <awilfox> it would likely be possible to make alien-like things using `apk gen` too
04:15 <awilfox> i.e. deb2apk, rpm2apk, etc
04:15 <kaniini> punch line: apparently it is a giant preprocessor hack
04:15 <awilfox> which I would of course never recommend, but can imagine places it might be useful
04:15 <awilfox> say, spotify or mathematica or other things distributed as (rpm|deb) in binary form
04:15 <TemptorSent> awilfox: especially for script-based applications.
04:16 <kaniini> right that is another reason why we are doing `apk gen`
04:16 <awilfox> [in fact, this is something I was hoping to accomplish anyway, because lsb's tests are packaged in rpm and they are just bash scripts]
04:16 <awilfox> so yeah `apk gen` is a multi-use tool but it should do one thing and do it well: make apks
04:16 <TemptorSent> Exactly.
04:16 <awilfox> likewise, `apk fetch --source` is a multi-use tool but it should do one thing and do it well: fetch *source*
04:16 <awilfox> not APKBUILD or .ebuild or w/e
04:17 <kaniini> awilfox: those are sources
04:17 <kaniini> awilfox: and need to be fetched
04:17 <TemptorSent> awilfox: I disagree with that, it should fetch the entire source of the PACKAGE.
04:17 <awilfox> there is nothing preventing abuild from making a SOURCE: line that points to alpine/abuild.git/blob/$commit/$package/APKBUILD but that is an implementation detail
04:17 <kaniini> awilfox: but you should use your current source manager to manage the downloaded sources
04:17 <kaniini> awilfox: apk shouldnt try to do that
04:18 <kaniini> awilfox: yes
04:18 <TemptorSent> In other words, give me a directory I can use in abuild on alpine in a private repo
04:18 <TemptorSent> Or add to an overlay in portage.
04:19 <kaniini> awilfox: but, if you omit that detail then people will argue about whether or not the file that describes what you're doing to said tarball and patch files, then people will be like herp derp just put that tarballs down
04:19 <awilfox> fair point
04:19 <awilfox> so, yes, you can put link-to-apkbuild or ebuild or whatever in as a SOURCE:
04:19 <TemptorSent> That way I can modifiy it and use the normal build / packaging tools, then manage it like any other package with apk
04:20 <awilfox> and it should likely reference the exact blob ID if possible
04:20 <awilfox> which, unfortunately, makes it a bit harder to test builds before you run them because now you need to have a commit ID
04:20 <kaniini> awilfox: that is my goal :)
04:20 <awilfox> you can either commit but not push, or push and have a builder machine test it (but then master could be broken)
04:21 <kaniini> awilfox: nah
04:21 <awilfox> or just omit the source metadata on test builds
04:21 <kaniini> awilfox: test builds can just use 'dirty' as the hash
04:21 <TemptorSent> You wouldn't necessarily need the blob ID in advance, you use the current, then tag it.
04:21 <kaniini> very easy to get that out of git
04:21 <awilfox> true
04:22 <awilfox> so does apk gen exist in some form that I can test/play with/attempt to grok? or is it still being discussed?
04:22 <awilfox> just wondering if it warns/errors/whatever if metadata is missing
04:22 <awilfox> I think it should do so but it should choose warning/error based on what metadata it is (name should be fatal, url should be warning, for instance; not all packages have URLs)
04:23 <awilfox> (looking at you, fetchmail)
04:27 <kaniini> awilfox: it exists on my hard disk
04:28 <kaniini> awilfox: i am going to work on manifest first
04:28 <kaniini> awilfox: once that is done, i will integrate and polish up apk gen
04:30 <awilfox> ah okay. that makes sense.
04:31 <kaniini> TemptorSent: and yes, verify.c is a good template for working with APK files
04:33 <Shiz> @kaniini │ punch line: apparently it is a giant preprocessor hack
04:33 <Shiz> i sorta knew this, i think
04:34 <Shiz> and debian control files...
04:34 <Shiz> :(
04:35 <TemptorSent> kaniini: Excellent - Is there a macro for creating a package struct and a file struct outside the db?
04:36 <TemptorSent> Also, what parses the .PKGINFO file?
04:43 <TemptorSent> Ahh, finally figured out how to use BLOB_PRINTF correctly -- didn't realized I had to deref the pointer :)
04:46 <TemptorSent> kaniini: Is there any way to determine which checksum function was actually used?
04:47 <TemptorSent> (for now, I guess I'll hard-code sha1 until the rest is ready)
04:50 <TemptorSent> kaniini: Also, how do links work WRT checksums?
05:15 <kaniini> TemptorSent: length field
05:20 <TemptorSent> Okay, it's not implemented the same as the xattr_csum then, got it.
05:22 <TemptorSent> kaniini: Here's what I'm playing with for format right now: http://termbin.com/fu57
05:27 <TemptorSent> We'll probably want to get the user/group names rather than IDs, since the tarfiles have symbolic, not numeric UIDs IIRC?
05:28 <TemptorSent> This is begging to get a format specifier like date(1) uses.
05:44 <TemptorSent> Hmm, do we have any way of distinguishing between distributed and generated files in the apk database? We're going to get two different results with apk manifest on .apk files vs installed packages any time the install scripts create/alter files.
05:49 <TemptorSent> Looking at it further, I believe the logical way forward would be to refactor the .apk file handling into one place, then expose a package struct and diri tree.
05:49 <TemptorSent> That should allow any tool that currently operates only on the database to operate on a .apk file in a logical manner.
05:50 <TemptorSent> Right?
06:55 t0mmy joined
07:06 fcolista joined
07:06 royger joined
07:12 fabled joined
07:17 blahdodo joined
07:25 baliste joined
07:25 <baliste> good morning
07:25 <baliste> anyone here
07:35 <trfl> go ahead and ask, people will respond whenever they see your question :>
07:38 <baliste> cool :p
07:38 <baliste> so I was taking a look at apk-tools
07:38 <baliste> i see it doesn't use HTTPS or ssl or anything. how does it protect against MITM attacks?
07:39 <baliste> or just tell me I'm wrong and it does.
07:39 <fcolista> baliste, how did you check then?
07:40 <baliste> fcolista, reading the source
07:42 <fcolista> baliste, and what part you've read that brought you to this conclusion?
07:44 <baliste> fcolista, reading files at src/ (add.c/apk.c)
07:45 <baliste> I mean I see you are verifying the images that's
07:45 <baliste> but the connecting itself goes over http and not https - please correct me if I am wrong on this.
07:45 <baliste> s/http/tcp?
07:48 <_ikke_> baliste: All packages and the index is signed
07:48 <_ikke_> baliste: So the packages cannot be altered without invalidating the signature
07:49 <fcolista> mitm cannot happen due to sha512 sum that verifies the integrity of the package. Apk-tools before installing a package verify the sha512 sum
07:49 <_ikke_> the sha512 sum can be altered
07:49 <fcolista> repositories support http, https and ftp
07:50 <fcolista> _ikke_, you should change the local index too
07:50 <_ikke_> it's an rsa signature that verifies the integerity
07:50 <fcolista> yes correct
07:50 <fcolista> rsa verifies the integrity
08:04 t0mmy joined
08:06 fekepp joined
08:18 xsteadfastx joined
08:31 <baliste> maybe this is too much to ask - but can anyone direct me to the code that verifies a package's signature?
08:32 <^7heo> it's in apk
08:32 <_ikke_> baliste: I guess this file: https://git.alpinelinux.org/cgit/apk-tools/tree/src/verify.c
08:35 baliste joined
08:37 consus joined
08:40 t0mmy joined
09:14 LouisA joined
09:41 dave_9911 joined
09:55 jirutka joined
10:52 vakartel joined
10:56 rdutra joined
10:59 pbregener joined
11:10 <pbregener> hi! i know you’re close to a new release, but i’d appreciate someone having a look at (or merging) https://github.com/alpinelinux/aports/pull/1259 (cmake) and https://github.com/alpinelinux/aports/pull/1527 (graphviz)
11:12 <_ikke_> pbregener: I think there was already a feature freeze (rc3 has been tagged and probably the base for the full release)
11:13 <pbregener> _ikke_: i know but given that a bunch of other commits/package upgrades went in after rc3 already, i thought i’d try my luck, too ;)
11:21 Fooster joined
11:22 fabled joined
11:39 Fooster joined
11:41 consus_ joined
11:55 gromero joined
12:02 gromero joined
12:02 leitao joined
12:03 BitL0G1c joined
12:08 vakartel1 joined
12:12 <jirutka> pbregener: cmake is used for building a lot of other pkgs, so this should be probably hold until v3.6 release
12:13 <jirutka> ncopa: ^ https://github.com/alpinelinux/aports/pull/1259 ?
12:13 <pbregener> agreed just wanted to make sure it’s still on your radar
12:15 <ncopa> cmake is a thing that builds other packages
12:15 <ncopa> i am afraid that cmake update may result in currently built packages fails to build
12:15 <ncopa> and at thist point we will not rebuild everything that uses cmake to verify that it still builds
12:15 <ncopa> however
12:15 <ncopa> 3.8.0 -> 3.8.1 sounds like a bugfix only
12:16 <ncopa> jirutka: if you have a look at the changelog for cmake, and think it is safe, then im ok to merge
12:16 <ncopa> graphviz is probably ok
12:17 <ncopa> i dont there are many other packages depending on it
12:20 farosas joined
12:22 <vakartel> anybody knows? http://patchwork.alpinelinux.org/project is dead? last patches are from 2017-05-04
12:38 <jirutka> vakartel: honest question, are you trying to avoid code reviews? you used to use GH for patches and then suddenly after few review cycles of bad quality PRs you switched to patchwork…
12:43 <vakartel> I use patchwork if I make a single-shot patches (like version upgrades) and use github, if I suspect that there may be a debate and/or changes in the patch
12:44 <vakartel> I really see no sence to create new branch in git to make just a version upgrade
12:45 <_ikke_> branches are cheap
12:46 <jirutka> well, this is new aport, not an upgrade http://patchwork.alpinelinux.org/patch/3370/
12:47 <jirutka> this is actually very controversial change, it triggered even a flamewar on IRC http://patchwork.alpinelinux.org/patch/3362/
12:52 <jirutka> I’ve quickly looked into others and gonna merge some of them at evening
12:53 <jirutka> I’ve marked http://patchwork.alpinelinux.org/patch/3403/ as superseded, someone alredy updated it
12:55 pbregener left
12:58 <jirutka> vakartel: ugh, i’ve already told you several times, please do not squash multiple unrelated changes into single commit and always write commit subject that briefly describes all changes made in the commit; this patch http://patchwork.alpinelinux.org/patch/3355/ contain a lot more changes than just “fix user creation in post-install”!
13:00 <vakartel> I can't describe all changes in subject, but it described in body -- "add nut home dir /var/lib/nut used for scheduler
13:00 <vakartel> fix libexec and driver dirs (libexec -> lib)
13:00 <vakartel> add using dns in init-scripts
13:00 <vakartel> remove conf.d files from package because it have no sence for now
13:00 <vakartel> cleanups in APKBUILD and init-scripts"
13:00 <_ikke_> vakartel: that's a sign you need multiple commits
13:01 <jirutka> vakartel: when you do just few unrelated changes when it’d be overkill to split them into separate commits, then use some general commit subject like “fix multiple issues”, “improve abuild” or something like that, but never EVER write “fix user creation in post-install” and then do ten other changes beside this…
13:04 <jirutka> vakartel: it’s especially important to decouple pure refactoring that does not change the resulting package and changes which affects the resulting package
13:05 <jirutka> vakartel: the worst you can do is to bury few functional changes in dozens of refactoring or cosmetic changes
13:06 <jirutka> these are reasons why I have to rewrite all your changes into php package one after the other, b/c it was nearly impossible to understand what the heck you’ve actually changed and how
13:07 <vakartel> yes, it's right. But it's sometimes hard to split all changes I made, because I made it while use it on real working devices. So I posted a combined result of my expirience of using...
13:07 <jirutka> you can split it ex-post… it’s git, not SVN
13:08 <jirutka> git rebase is your friend ;)
13:11 <jirutka> i do it myself, sometimes I change too many things at once when trying to build/fix something and then when I’m finished, I go through the changes I made and split them to multiple commits
13:15 <vakartel> git rebase is my nightmare. I not use git or other cvs-s in my main work. So I know a little about it and try to understand it as needed.
13:17 <vakartel> Ok, I'll try to move all my patches from patchwork to github and split it somehow.
13:18 <jirutka> what VCS do you use at work?
13:22 <vakartel> cvs a little. just for cisco devices configuration history
13:31 <jirutka> CVS? i’m really sorry for you, i’d probably shoot myself or quit the job if forced to use CVS
13:37 <vakartel> it's ok. I made a script 10 years ago that grabs configs from switches and routers and just updates it in cvs. It was an only expirience with vcs-s.
14:59 gromero joined
15:11 cyteen joined
15:14 <baliste> hi, how can I build my own fork of apk-tools? can I just build it delete the original binaries and use?
15:23 <tmh1999> baliste : you clone aports tree, $ cd aports/main/apk-tools ; abuild -r then add /home/username/packages/main to your /etc/apk/repositories, then install apk-tools from your local repo.
15:23 <tmh1999> @channel : I think we have one or some repositories that do not sync up to date
15:24 <baliste> tmh1999, can I clone apk-tools (via git) - build it with make then make install? or are there issues that can show up
15:25 <tmh1999> dl-6 is unreachable for me
15:26 <tmh1999> baliste : abuild -r step will do the make and make install for you. it is the recipe to build packages in Alpine way
15:27 <baliste> tmh1999, yes that's fair - I just don't want to clone the aports tree
15:27 <baliste> you see I'm building a docker image that should compile my version of apk-tools (and it's the only thing I'm changing)
15:27 <tmh1999> --depth 1 won't kill :D especially if you clone into a tmpfs file system :D
15:40 <tmh1999> http://dl-6.alpinelinux.org/alpine/
15:40 <tmh1999> http://mirrors.cug.edu.cn/alpine/
15:40 <tmh1999> http://mirrors.cicku.me/alpine/
15:41 <tmh1999> unreachable for me :(
15:41 <tmh1999> tried with my remote servers too
15:43 <Shiz> baliste: yes, you can
15:45 doppo joined
16:24 <Shiz> ncopa: did you figure out what that keymap issue was caused by?
17:21 federico__ joined
17:27 fekepp joined
17:46 <ncopa> with xen?
17:47 <ncopa> yes
17:47 <ncopa> im gonna tag and branch 3.6 now
17:57 <Shiz> did we fix that udhcpc issue?
18:00 <^7heo> Gosh
18:00 <^7heo> crond wants busybox syslog started...
18:00 <^7heo> yet I have syslog-ng installed...
18:00 <^7heo> that sucks.
18:01 <Shiz> why does it want that?
18:01 <^7heo> No idea.
18:01 <^7heo> I stop syslog, it stops crond
18:01 <^7heo> ok
18:01 <^7heo> I start syslog-ng
18:01 <^7heo> I start crond
18:01 <^7heo> it starts syslog
18:01 <^7heo> v_v
18:04 <^7heo> Also some fucking programs overwrites /etc/syslog-ng/syslog-ng.conf or whatnot.
18:04 <^7heo> my configuration is always lost.
18:05 <^7heo> Ok the /etc/syslog-ng/syslog-ng.conf is actually generated at restart
18:05 <^7heo> weird but whatever.
18:07 <^7heo> At least now it works.
18:07 <^7heo> But I still have no crond
18:07 <^7heo> v_v
18:07 <jirutka> Shiz: have you updated release notes (Julia added)?
18:07 <Shiz> nyet
18:08 <Shiz> ncopa: was the cabal PR merged before 3.6?
18:08 <jirutka> Shiz: no, b/c of issues
18:08 <Shiz> okay
18:08 <ncopa> i havent merged anything today
18:08 <jirutka> Shiz: https://github.com/alpinelinux/aports/pull/1553#discussion_r118118737
18:09 <Shiz> yeah just opened the page
18:09 <jirutka> Shiz: but having ghc in community is IMO still huge improvement, even without cabal
18:09 <jirutka> I’m just sad that rust is built only for x86_64 now
18:11 <^7heo> I really really don't get it.
18:11 <^7heo> crond wants 'logger'
18:11 <^7heo> both syslog and syslog-ng provide it
18:11 <^7heo> why is crond starting logger when syslog-ng is started?
18:11 <jirutka> wants? there’s no such dependency keyword in OpenRC, is there?
18:11 <ncopa> Shiz: was this the last edition? https://txt.shiz.me/Y2RhOTA1Mm
18:12 <Shiz> i think it changed a bit, lemme see
18:12 <^7heo> jirutka: needs, not wants, but same difference.
18:13 <Shiz> https://txt.shiz.me/MjU0NjNjN2
18:13 <^7heo> using rc-service instead of /etc/init.d/crond start was the solution
18:13 <^7heo> it's weird tho.
18:14 <Shiz> that... shouldn't make any difference
18:14 <jirutka> Shiz: could you please sort “Significant updates” alphabetically?
18:14 <^7heo> Shiz: I know; but it does.
18:14 <^7heo> OR
18:14 <^7heo> maybe it's me actually removing syslog from the default boot runlevel and adding syslog-ng instead.
18:14 <jirutka> ^7heo: what?! there should not be any difference between starting with /etc/init.d/foo and rc-service
18:14 <^7heo> would THAT be computed when starting crond?
18:15 <^7heo> (to satisfy the 'needs' requirement even if there already is a service running that provides it?)
18:15 <Shiz> https://txt.shiz.me/YTBhZTRiOT
18:15 <Shiz> sorted
18:15 <jirutka> the service must be in runlevel to satisfy needs requirement
18:15 <jirutka> hm, now Go is before most of others… ok, nevermind
18:16 <Shiz> ^7heo: dependencies must be in the same runlevel, afaik
18:16 <Shiz> what jirutka said
18:16 <^7heo> ah SAME runlevel.
18:16 <^7heo> ok.
18:16 <^7heo> now it makese sense.
18:16 <^7heo> syslog-ng was in needed/wanted and crond in default.
18:17 <^7heo> since I placed syslong-ng in default, it's now good.
18:17 <^7heo> Thanks guys.
18:17 <jirutka> I’m trying to remember what other important changes we made
18:17 <jirutka> but it’s hard, I hardly remember what I was doing a week ago
18:18 <^7heo> +1
18:26 <jirutka> we’ve added or moved from testing: rethinkdb, mongodb (not sure if it’s really noteworthy…) , vis, yarn,
18:47 <ncopa> does this look good? http://wwwtest.alpinelinux.org/posts/Alpine-3.6.0-released.html
18:48 <jirutka> wow, I’m at the second place!
18:50 <Shiz> at least i'm in the top 20
18:50 <Shiz> :p
18:52 <ncopa> commit count is not a good meter
18:52 <ncopa> the best meter is clandmeter :)
18:52 TemptorSent joined
18:53 <Shiz> :P
18:53 <Shiz> lgtm
18:53 <jirutka> ncopa: added links https://dpaste.de/r6Jb/raw
18:53 <ncopa> jirutka: can you push it directly to alpine-mksite master?
18:53 <jirutka> yes
18:54 <ncopa> is it just me or is rsync.a.o a bit slow?
18:54 <ncopa> i can only dl at 300k/s
18:57 <jirutka> 10 MiB/s
18:59 <^7heo> if I `nohup foo &`
18:59 <^7heo> will foo run forever until it exits/crash?
18:59 <ncopa> yes
18:59 <^7heo> (no matter what else happens - aside from computer reboot or explicit killing)
18:59 <^7heo> great, thanks ncopa
19:02 <jirutka> okay, I’m gonna add v3.6 and new platforms to pkgs.a.o
19:08 <jirutka> ncopa: should be v3.3 and v3.4 still on the list?
19:09 <ncopa> they are still supported
19:09 <jirutka> okay
19:09 <ncopa> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
19:21 dsabogal joined
19:30 <jirutka> gosh, we should seriously switch to a *real* database :(
19:33 BitL0G1c1 joined
19:34 <kaniini> 2019-15-01 release date ?
19:34 <kaniini> :D
19:34 <kaniini> er support date
19:39 <dsabogal> is 'immediate availability of version 3.6.0' intended? (compared with the 3.5.0 release post)
19:42 baliste joined
19:51 cyteen joined
20:16 <ncopa> dsabogal: im open to suggestions
20:16 LouisA joined
20:17 <ncopa> im not native english speaking (and i dont think Shiz is either) so help with wording is appreciatet
20:19 Topic for
20:23 <ncopa> does this sound better? We are pleased to announce the release of Alpine Linux 3.6.0, the first in the v3.6 stable series.
20:24 <Shiz> i just took that verbatim from the 3.5.2 announcement
20:24 <Shiz> it is valid english
20:25 <dsabogal> ncopa: yes, it sounds better. i was just pointing out that it seemed to have been copied from a minor release post (where immediate makes sense)
20:25 <ncopa> ok
20:25 <ncopa> we also dont have an "credits" section
20:25 <ncopa> we probably should
20:26 <ncopa> but i am afraid of forgetting someone :)
20:42 <leitao> ncopa, I contributed with two different emails, can I join both contributions together?
20:42 <ncopa> :)
20:42 <ncopa> its git shortlog :)
20:42 <ncopa> i suppose i can join them
20:42 <ncopa> manually
20:43 gromero joined
20:44 <leitao> ncopa, cool, thanks!
20:50 <tmh1999> \o/
20:50 <algitbot> \o/
20:51 <tmh1999> I just find out darkhttp is so cool, which a.o is running. back in the day I was struggling writing my own web server based on libevent.
20:54 <tmh1999> ncopa : https://alpinelinux.org/posts/Alpine-3.6.0-released.html is not found
20:57 <ncopa> tmh1999: http://wwwtest.alpinelinux.org/posts/Alpine-3.6.0-released.html
20:57 <ncopa> not published yet
20:58 <tmh1999> ah right !
20:58 <tmh1999> thought it automatically fetched from alpine-mksite
21:00 kolev_ joined
21:02 kolev_ left
21:05 <ncopa> it does
21:05 <tmh1999> ncopa : The full list of changes can be found in the git log and bug tracker. gitlog and bug tracker point to b2b.gigabyte.com and create.io
21:05 <ncopa> i think i just fixed that
21:05 <ncopa> can you refresh?
21:06 <ncopa> ok i think i push it
21:06 <tmh1999> gotcha
21:07 <tmh1999> actually IBM System z is correct :D but it is not a big deal
21:07 <ncopa> leitao asked me to change it to Z
21:07 <ncopa> but i suppose he is a POWER guy :)
21:07 <tmh1999> :D
21:08 <Shiz> lowercase z would be correct yeah
21:08 <ncopa> tmh1999: so what you do now is to ask me change POWER to pOWER ;)
21:08 <leitao> ncopa, sorry about it.
21:08 <leitao> ncopa, my fault.
21:08 <tmh1999> or p0W3r :D
21:08 <leitao> tmh1999: that sounds cool!
21:08 <Shiz> IBM POWA
21:09 <leitao> in fact, I think the correct naming is "IBM z Systems"
21:09 jirutka joined
21:09 <tmh1999> don't worry it is not a big deal. I have seen people using System Z or System z all the time. To be exact, our Alpine s390x should be "Linux on z" https://en.wikipedia.org/wiki/Linux_on_z_Systems. System z can run many OS. Linux is one of them.
21:10 <ncopa> IBM z System
21:10 <ncopa> sounds more correct to me :)
21:10 <tmh1999> https://en.wikipedia.org/wiki/IBM_System_z
21:10 <tmh1999> leitao is right officially : "IBM z Systems"
21:10 <leitao> IBM System z (officially "IBM z Systems"
21:10 <ncopa> yup
21:11 <tmh1999> but most people I work with usually say System z. so, it's not a big deal.
21:11 <leitao> In fact, Power systems is being renamed also. IBM almost do not like to change names.
21:11 <tmh1999> interesting
21:13 <tmh1999> Shiz : POWA, sounds like a Japanese
21:13 <ncopa> refresh
21:13 <ncopa> ok to push?
21:13 <Shiz> ポワですね?
21:13 <tmh1999> \o/
21:13 <algitbot> \o/
21:14 <leitao> here we go
21:17 <jirutka> ncopa: please tweet it from @AlpineLinux account ;)
21:19 <leitao> ncopa, should we have ppc64le and s390x images from https://www.alpinelinux.org/downloads/ ?
21:21 <TemptorSent> Don't forget to ping phoronix with the announcement :)
21:21 czart__ joined
21:25 <ncopa> leitao: yes we should have those images on downloads page, i will fix that tomorrow
21:25 <leitao> ncopa, ok
21:25 <ncopa> TemptorSent: i pinged distrowatch, which is the phoronix email?
21:25 <ncopa> TemptorSent: care to send to phoronix?
21:26 <ncopa> i suppose they could subscribe to alpine-announce if they were interested
21:26 <TemptorSent> Just send it to @phoronix twitter?
21:27 <TemptorSent> I think email is phoronix@phoronix.com
21:28 <TemptorSent> It would be better coming from an @alpinelinux address :)
21:30 <TemptorSent> I'm sure /. will pick it up eventually - I'm not active there other than lurking these days.
21:32 <ncopa> thank you everyone
21:32 <ncopa> im going to bed
21:32 <TemptorSent> Congratulations, and goodnight!
21:34 <Shiz> night ncopa
21:35 <clandmeter> jirutka, how big is the sqlite db now?
21:35 <jirutka> ncopa: good night, sleep well!
21:35 <jirutka> clandmeter: 3.1 GiB
21:36 <clandmeter> and still pretty fast :D
21:37 <jirutka> clandmeter: it almost collapsed when importing v3.6…
21:38 <clandmeter> the smallest table is the slowest i think
21:39 <TemptorSent> Out of curiousity, WTF is sqlite being used for a database that large?
21:39 <jirutka> TemptorSent: exactly
21:39 <clandmeter> because it just works
21:39 <jirutka> TemptorSent: I’m asking the same question every time I see it
21:39 <TemptorSent> Postgres is your friend.
21:39 <jirutka> exactly!
21:40 <TemptorSent> What does the DB contain that it's up to 3.1G in the first place? Every version of every package?
21:41 <clandmeter> filelist of every pkg
21:41 <Shiz> ^this is why we don't want that in the APKINDEX
21:41 <Shiz> :P
21:41 <TemptorSent> Okay, every package EVER?
21:41 <Shiz> no
21:41 <Shiz> every current package
21:41 <Shiz> for 3.3-3.6 and edge
21:42 <jirutka> and the DB schema is not very well designed
21:42 <TemptorSent> Somehow, that seems beyond absurd, but I suppose it's not impossible.
21:42 <jirutka> yes
21:42 <TemptorSent> It should compress VERY well.
21:42 <jirutka> it’s sqlite, embedded DB for tiny things, not for something like this!
21:42 <jirutka> I’m really surprised that it still somehow works…
21:43 <TemptorSent> Well, given enough memory... :)
21:44 <clandmeter> the schema is so bad, it still works at 3.1G :)
21:44 <jirutka> i didn’t say that it’s bad, just not well designed…
21:45 <jirutka> there are even functional problems
21:45 <jirutka> like that bumping pkgrel also erases flag
21:45 <Shiz> is there any other schema you need than (id: int, branch: enum, arch: enum, repo: enum, pkgname, pkgver) and (pkgid: int, path)?
21:45 <jirutka> yes
21:46 <TemptorSent> Especially if you want it fast and enforcing relational integrity.
21:46 <jirutka> relational integrity? there’s no such thing in this db :/
21:46 <TemptorSent> Right.
21:48 <TemptorSent> For what it's primarily used for, the path and hash value for that file/link target for link should form a primay key
21:50 <TemptorSent> With the package relation being a secondary key.
21:50 <Shiz> primary keys have to be unique...
21:51 <TemptorSent> path + hash IS unique.
21:51 <TemptorSent> Or you have the same item :)
21:51 <Shiz> yes, which is often enough the case...
21:51 <TemptorSent> So, why store multiple copies of th metadata?
21:51 <Shiz> also, you're the only one talking about hashes here, i don't see why they need to be added
21:52 <TemptorSent> How else do you tell if a file changed?
21:52 <jirutka> sigh
21:52 <Shiz> you... don't?
21:52 <Shiz> it's a file list, not a file content list
21:53 <jirutka> however, storing hash of every file is not a bad idea, it may be useful for various things
21:53 <Shiz> if you want massive duplicate entries, sure
21:53 <Shiz> :P
21:53 <TemptorSent> If two packages have the same path, it's nice to know if it's in fact the same content or not.
21:53 <clandmeter> we could add many things that "could" be usefull
21:53 <jirutka> actually opposite…
21:54 <Shiz> TemptorSent: you're *again* pulling extra things into scope that is not the point of the discussion
21:54 <Shiz> please stop doing that
21:54 <TemptorSent> Determining whether the version in a given branch is different than the one you currently have isn't useful?
21:55 <jirutka> it is useful, just quite out of scope of pkgs.a.o…
21:55 <Shiz> it's not the point of the file list
21:55 <Shiz> we could add automated beverage making abilities to p.a.o, that doesn't mean it's relevant to it
21:55 <Shiz> please stop trying to pull extra things into scope in discussions about other things
21:55 <jirutka> ^ +1
21:56 <Shiz> it's fine to have those ideas, but have separate discussions for them
21:56 <Shiz> :P
21:56 <TemptorSent> If I have a file on my local machine, I take it's hash, and look at the one in the current package -- if they differ, I might upgrade because of a particular issue, otherwise, I might not care.
21:57 <TemptorSent> Is it a generic file list, or a specific $pkg-$pkgver vs path list?
21:58 <jirutka> file list per each individual pkg
21:58 <TemptorSent> If a file builds differently in one branch than another for the same package, I might want to know that too.
21:58 <Shiz> groan
21:58 <Shiz> please, if you want to have this discussion, start it another time
21:58 <TemptorSent> Using a real database makes asking useful questions much easier.
21:59 <Shiz> not when we are talking about other things
21:59 <clandmeter> pkgs filelist function is to search for filenames, it has not other function. if you need something more advance hook it into apk-tools or some other tool.
22:00 <TemptorSent> apk-tools can't help unless EVERY package you want to query is installed (which is impossible for many reasons)
22:01 <TemptorSent> When I think file list, I'm thinking at least as detailed as tar -tvf, and preferably better.
22:01 <jirutka> TemptorSent: we all know about it
22:02 <jirutka> TemptorSent: IIRC it’s planned to new major version of apk-tools
22:02 <clandmeter> and sqlite is maybe not optimal for large db's, but until now it works acceptable, and the major benefit is less maintenance then mariadb or postgress.
22:02 <TemptorSent> If I'm trying to diagnose something, being able to get as much detail as possible on what I SHOULD have from the web interface would be immeasurably helpful.
22:02 dsabogal joined
22:02 <Shiz> @Shiz │ it's fine to have those ideas, but have separate discussions for them
22:02 <TemptorSent> I find postgres to be very low maint.
22:02 <Shiz> please.
22:03 <clandmeter> yes, there has been talk to implement filelist into apk-tools as a separate index.
22:03 <TemptorSent> So you're going to consider redesigning the database without considering what information you'd like to be able to retrieve?
22:04 <clandmeter> but still, even if those indexes exist, apk tools wont have the functions to do more adv queries. (and i dont think fabled is planning to implement that).
22:07 minimalism joined
22:14 <Shiz> btw, question
22:14 <Shiz> why is it called nodejs and nodejs-current
22:14 <Shiz> shouldn't it be something like nodejs and nodejs-lts?
22:15 <jirutka> no
22:15 <jirutka> b/c nodejs is the default
22:16 <jirutka> nodejs-current (“current” is how upstream calls it) is the latest with short support period
22:16 <jirutka> https://github.com/nodejs/LTS
22:16 <Shiz> alright
22:17 <jirutka> some distributions do not provide “current” at all, just LTS named simply as “nodejs”
22:17 <Shiz> i'm almost thinking we should call it nodejs-lts with provides="nodejs"
22:17 <Shiz> :P
22:17 <jirutka> why?
22:18 <jirutka> i’d just confuse users imo
22:18 <Shiz> because semantically it seems more like nodejs is a virtual that could be fulfilled by either nodejs-lts or nodejs-current
22:18 <Shiz> better for dependencies etc
22:18 <jirutka> I think that we should promote stable version, not unstable
22:18 <Shiz> sure, and as such if you # apk add nodejs it will nodejs-lts by default
22:19 <jirutka> nodejs-current has shorter support period than our main repo, that’s why it’s in community
22:19 <Shiz> i know...
22:19 <jirutka> currenty nodejs-current provides=nodejs
22:20 <jirutka> there’s similar situation with nginx, just we don’t have nginx-mainline pkg (yet)
22:20 <jirutka> why to name it nginx-stable and nginx-mainline?
22:21 <Shiz> because a package without suffix is confusing imo
22:21 <jirutka> <Shiz>: "because semantically it seems more like nodejs is a virtual that could be fulfilled by either nodejs-lts or nodejs-current" … yeah, you’re right, but that would require proper support for “alternatives”…
22:21 <Shiz> i search for nodejs* in p.a.o, i see nodejs and nodejs-current
22:22 <Shiz> and i wonder what the difference is :P
22:22 <Shiz> if it was named nodejs-lts i could immediately see the difference
22:22 <jirutka> nodejs-current is not very good name :/
22:23 <jirutka> do you read descriptions? ;) “JavaScript runtime built on V8 engine - LTS version”
22:23 <jirutka> but once again, the main reason for this is our lack of proper support for “alternatives”
22:23 <Shiz> i don't think this is about alternatives, more about virtuals
22:23 <Shiz> :p
22:24 <Shiz> jirutka: descriptions only show when you hover over
22:24 <Shiz> and imo shouldnt be needed to understand the package purpose
22:24 <Shiz> :P
22:24 <jirutka> it’s tightly related
22:25 <jirutka> when you have pkg A and B, both provides=X, you can’t do apk add X
22:25 <jirutka> b/c there’s no mechanism how to decide what is the default
22:26 <jirutka> and since not many ppl understand this problem and we’re all very busy, it’s still not solved
22:27 <jirutka> so we’re still workarounding these limitations of apk :/
22:27 <TemptorSent> Virtuals should be used in cases where installing pkgX results in actually installing pkgX1 ... pkgXn. Alternatives should support 1 (or more) of N possible providers.
22:28 <jirutka> this reminds me that I said some time ago that I’ll document this, so I don’t have to explain it every time this topic appear again, but still haven’t done it :(
22:28 <jirutka> I need a time machine :(
22:29 <jirutka> or longer day or I don’t know
22:29 <TemptorSent> Just don't break down in the past.
22:30 <TemptorSent> Was the conversation logged perchance?
22:31 <jirutka> every conversation here is logged
22:31 <jirutka> but it’s almost impossible to find something in IRC logs…
22:32 <TemptorSent> Well, at least knowing the channel helps -- if it was this one, we might have a chance, if it was -offtopic, all bets are off.
22:32 <jirutka> this one
22:32 <jirutka> we usually don’t discuss on topic things in -offtopic
22:33 <TemptorSent> I recall a discussion on alternatives with kaniini recently.
22:33 <jirutka> yes
22:33 <TemptorSent> Is that the conversation you're referring to?
22:33 <jirutka> no
22:33 <jirutka> but we’ve discussed this alreday many times
22:33 tmh1999 joined
22:33 <jirutka> in past a year or more
22:35 <TemptorSent> Okay, so where should this get documented so you don't have to feel like the movie groundhog day?
22:35 <jirutka> on wiki…
22:36 <TemptorSent> Tag as 'apk_TODO'?
22:36 <jirutka> TODO:apk may be better
22:37 <jirutka> I’ve already created https://wiki.alpinelinux.org/wiki/TODO:py3_packages some time ago
22:37 <jirutka> but lists on this page are outdated
22:37 <TemptorSent> Okay, can we start an 'apk_internals' stub to link it to?
22:37 <jirutka> just fyi
22:37 <Shiz> we need to use the new wiki ;)
22:37 <Shiz> speaking of new wiki
22:38 <TemptorSent> New wiki?
22:38 <Shiz> i feel like it would be nice if we could get some semeantic organistaion in the urls there
22:38 <Shiz> https://github.com/alpinelinux/alpine-wiki
22:38 <TemptorSent> Agreed.
22:38 <Shiz> https://docs.alpinelinux.org/Home
22:38 <jirutka> there are SO MANY things needed to do with new wiki to make it usable AND maintainable long-term
22:39 <Shiz> the only thing i can think of is write a bot to merge PRs to it if they don't contain known bad stuff automatically
22:39 <Shiz> like a... wiki :P
22:39 <Shiz> aside from article migration
22:40 <jirutka> ?
22:40 <Shiz> ?
22:41 tmh1999 joined
23:00 <TemptorSent> See https://wiki.alpinelinux.org/wiki/Apk_internals
23:01 <TemptorSent> There's a stub to start documenting the internals of apk, and a link to the stub for TODO:apk.
23:03 leitao joined
23:19 <minimalism> just read the 3.6 news post, did UEFI not make it?
23:21 tmh1999 joined
23:23 <jirutka> Shiz: is there some way how to get version information from static library (*.a)?
23:23 <Shiz> no
23:24 <jirutka> Shiz: even when it’s contained in sources and available in runtime, so it must be there somewhere…?
23:24 <jirutka> Shiz: https://github.com/lua/lua/blob/master/lua.h#L21
23:26 <jirutka> I know that this is for preprocessor, but Lua provides lua variable _VERSION, so it must be here somewhere
23:28 <jirutka> ha, strings! but it just returns all strings without any context
23:29 <Shiz> i mean
23:29 <Shiz> not in a genric way
23:29 <jirutka> i need it only for valid Lua libraries
23:29 <jirutka> so i don’t need a generic way in this case
23:30 <jirutka> but it’d be great if it can determine that it’s really lua library and not just binary that happens to include string "Lua x.y"
23:35 tmh1999 joined
23:42 <Shiz> why do you need to determine this from the .a?
23:43 <jirutka> to verify that the given/found static library is in the correct version
23:58 <Shiz> i don't think symbol/string hackery is right...
23:59 <jirutka> me neither, so what is the right solution? :)