2019-06-07 13:22:29 <Cogitri> So I'd like to suggest requiring patch headers to be added to patched
2019-06-07 13:22:51 <Cogitri> See https://exherbo.org/docs/eapi/exheres-for-smarties.html#applying_patches for some reasoning as to why (feel free to ignore the Exherbo specific parts like when to apply patches)
2019-06-07 13:23:06 <Cogitri> It's super nice knowing if a patch is upstream and what it's for
2019-06-07 13:23:13 <SpaceToast> Thanks :)
2019-06-07 13:23:27 <SpaceToast> I can't guarantee it'll make it in, but there's a good case for it and I'll include it in the draft
2019-06-07 13:23:33 <Cogitri> And it's just super annoying having to guess what a patch is for
2019-06-07 13:24:04 <Cogitri> Thanks. Ping me if there's something I can help with :)
2019-06-07 13:30:36 <SpaceToast> Will do :)
2019-06-07 22:51:34 <SpaceToast> Ping Cogitri - I'm thinking the idea is good, but would be interested in a different header type
2019-06-07 22:51:44 <SpaceToast> Would that be ok with you, or do you want that one specifically?
2019-06-07 22:52:49 <Cogitri> Ah, I'm totally fine with a different header type, that one was just an example. What do you have in mind?
2019-06-07 22:54:20 <SpaceToast> I'm thinking Source: with a standard format (Todo) + Remove When:
2019-06-07 22:54:38 <SpaceToast> And whatever is needed (loose format) explaining the reason for the patch and what it does
2019-06-07 22:55:30 <SpaceToast> Remove When could be anything from (1.0.0 is out) to bug_url is resolved to "musl support is added upstrean"
2019-06-07 22:58:02 <Cogitri> Hm, I feel like almost every time `Remove When` would point to an URL containing more info anyway, it's pretty hard to say when a patch should be removed in advance
2019-06-07 22:58:39 <SpaceToast> It's still more useful, imo
2019-06-07 22:59:03 <SpaceToast> Sometimes there isn't a url, and sometimes the fix is already merged, but no release has been made
2019-06-07 22:59:13 <Cogitri> Hm, alright
2019-06-07 22:59:15 <SpaceToast> Upstream is just very vague, and less informative
2019-06-07 22:59:53 <SpaceToast> (e.g in Remove When:, JUST a url wouldn't make sense
2019-06-07 23:00:09 <SpaceToast> It would be "the bug in this url is resolved" or "this PR is merged", etc)
2019-06-07 23:00:10 <Cogitri> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/wavwlmYNTjJVDwMtULLrfLPc >

2019-06-07 23:00:20 <SpaceToast> Yes
2019-06-07 23:00:27 <SpaceToast> Source would be a standardized format
2019-06-07 23:00:58 <Cogitri> Alright, sounds good to me
2019-06-07 23:01:13 <SpaceToast> Something like [distribution:] [John <email> Doe] [URL to something containing the patch or a link to it, preferably the latter]
2019-06-07 23:01:25 <SpaceToast> With one or more elements required
2019-06-07 23:01:44 <SpaceToast> Okay, Ty :)
2019-06-07 23:01:49 <SpaceToast> I'll ping you again once I have a draft
2019-06-07 23:03:18 <Cogitri> Thanks!
2019-06-08 17:21:27 <SpaceToast> ping Cogitri - current draft for the "best packaging practices" page is here: https://minio.toastin.space/shared/best.html
2019-06-08 17:21:38 <SpaceToast> you may notice a section relevant to you at the end
2019-06-08 17:21:40 <SpaceToast> does that look ok?
2019-06-08 17:23:57 <Cogitri> What's the `family` in `Source: [distribution: ] [Name <email> Family] [URL]` for?
2019-06-08 17:25:30 <SpaceToast> John Doe
2019-06-08 17:25:32 <SpaceToast> Doe being the family
2019-06-08 17:25:37 <SpaceToast> (as in family name)
2019-06-08 17:25:42 <SpaceToast> I dislike the name/surname distinction sort
2019-06-08 17:26:13 <SpaceToast> since it implies that the family is necessarily more important (see: etymology of "sur" - "above" etc)
2019-06-08 17:26:41 <Cogitri> Ah, but isn't it `Full name <email>` everywhere else?
2019-06-08 17:26:50 <_ikke_> Isn't "John Doe <john@doe.com>" more common?
2019-06-08 17:27:03 <SpaceToast> oh, I might be blanking
2019-06-08 17:27:09 <SpaceToast> my bad, will fix
2019-06-08 17:27:21 <Cogitri> Yup, what ikke said
2019-06-08 17:27:24 <SpaceToast> s/Family//
2019-06-08 17:27:30 <Cogitri> Seems good to me otherwise, thank you!
2019-06-08 17:27:31 <SpaceToast> I think I was thinking of <Nickname>
2019-06-08 17:28:53 <SpaceToast> _ikke_: does this look ok? `[[Name] ["Nickname"] [Family Name] <Email>]`
2019-06-08 17:29:02 <SpaceToast> i.e Email is the important part, you can include all this other information, in that format
2019-06-08 17:29:18 <SpaceToast> if not I'll just keep `Name <email>`
2019-06-08 17:34:46 <mps> Isn't 'e-mail address' enough
2019-06-08 17:35:48 <SpaceToast> it depends
2019-06-08 17:35:58 <SpaceToast> e-mail is the original spelling, and it's "electronic mail", but english does evolve
2019-06-08 17:36:11 <SpaceToast> email is a far more common spelling, to the point that the AP stylebook recommends email
2019-06-08 17:36:20 <SpaceToast> several newspapers as well
2019-06-08 17:36:21 <mps> some doesn't want to write their full names when sending patches
2019-06-08 17:36:55 <SpaceToast> that's why I explicitly mark them as optional
2019-06-08 17:37:19 <mps> ah, then it is ok
2019-06-08 17:37:19 <SpaceToast> [something] is commonly used in cli environments (like manual pages and --help outputs) to mark optional content
2019-06-08 17:37:40 <SpaceToast> as per the comments below - you must *at least* have an email or a URL
2019-06-08 17:37:45 <SpaceToast> everything else is just bonus information :)
2019-06-08 17:38:01 <mps> ok, read through elinks, and thought it added brackets
2019-06-08 17:38:37 <mps> personally I prefer full names, but know that some doesn't
2019-06-08 17:40:19 <SpaceToast> latest iteration: `Source: [distribution: ] [Name] ["Nickname"] [Family Name] [<Email>] [URL]`
2019-06-08 17:40:31 <SpaceToast> with "at least one of Email or URL being required"
2019-06-08 17:41:10 <Cogitri> Seems good to me
2019-06-08 17:41:21 <SpaceToast> ty :)
2019-06-09 02:32:40 <tcely> ( <Email> | <URL> )
2019-06-09 02:32:40 <tcely> ^^ the usual way to say one is required
2019-06-09 02:32:58 <SpaceToast> tcely++, let me patch that in
2019-06-09 02:33:20 <SpaceToast> it wasn't an option initially because they weren't next to each other
2019-06-09 02:33:41 <SpaceToast> done, ty :)
2019-06-09 02:33:59 <tcely> yw
2019-06-09 02:37:02 <SpaceToast> no <>s around URL, but that's because the <>s in Email are literal
2019-06-09 02:37:09 <SpaceToast> (i.e literally <toast@toastin.space>)
2019-06-09 03:14:56 <tcely> Literals usually get quoted to distinguish them from NF syntax
2019-06-09 03:15:39 <SpaceToast> well this isn't really meant to exactly replicate stuff
2019-06-09 03:15:44 <SpaceToast> maybe I'll add an example with everything present
2019-06-13 19:13:56 <SpaceToast> re: https://github.com/alpinelinux/aports/pull/8780#pullrequestreview-249535101 - this opens up an interesting conversation
2019-06-13 19:14:17 <SpaceToast> as of right now, there definitely is a "majority" of things done a specific way, but certainly not all
2019-06-13 19:14:23 <SpaceToast> lots of inconsistencies around as well
2019-06-13 19:14:58 <SpaceToast> things that should ideally be decided (and documented once they have been decided):
2019-06-13 19:15:05 <SpaceToast> 1. How should constants be quoted?
2019-06-13 19:15:20 <SpaceToast> 2. How should non-constants be quoted?
2019-06-13 19:15:35 <SpaceToast> 3. How should interpolations be quotes (things like "$srcdir"/cargo)
2019-06-13 19:15:54 <SpaceToast> currently, 1 is highly inconsistent (for instance, pkgname is a constant, and is *un*quoted)
2019-06-13 19:15:58 <SpaceToast> I propose the following:
2019-06-13 19:16:29 <SpaceToast> 1. Constants are either unquoted, or quoted with single-quotes. Single quotes are required if the constant contains anything besides [a-zA-Z\.]
2019-06-13 19:16:41 <SpaceToast> 2. non-constants are quoted with double-quotes, always.
2019-06-13 19:17:00 <SpaceToast> 2. interpolations are quoted, in their entirety, with double-quotes, always. (like "$srcdir/cargo")
2019-06-13 19:17:05 <SpaceToast> s/2./3./
2019-06-13 19:17:45 <SpaceToast> the reasoning for 1 and 2 is that double-quotes thus signal that escaping is done, while single or missing quotes constants
2019-06-13 19:18:00 <SpaceToast> the reasoning for 3 is that having full ""s delinates individual arguments
2019-06-13 19:18:41 <SpaceToast> this is a departure from the general majority, and I would be fine with whatever is ultimately decided - just saying what I think should happen and explaining why; point being that we probably *should* decide on a specific standard as to increase consistency and avoid future bickering
2019-06-13 19:19:09 <SpaceToast> ncopa: ^ opinions? (I'll be at work quite late tomorrow, so waiting until potentially even Monday for any response is fine)
2019-06-13 19:20:46 <SpaceToast> also, for 1, I mean [a-zA-Z0-9\.\-] (alphanumerics, periods and dashes)
2019-06-13 19:23:59 <Cogitri> I'd go for "" even for constants, simply because we already use that everywhere
2019-06-13 19:24:22 <SpaceToast> well, we don't though
2019-06-13 19:24:28 <SpaceToast> see pkgname for instance - typically unquoted
2019-06-13 19:24:40 <SpaceToast> what we use everywhere right now is more complex than `always ""`
2019-06-13 19:24:43 <Cogitri> And it'd be a bit confusing to have pkgdesc='something' only to have pkgdesc="$pkgdesc - subpackage" later on
2019-06-13 19:25:10 <SpaceToast> not to anyone that knows shell, which should probably be a requirement for... writing shell
2019-06-13 19:26:14 <Cogitri> Then I'd argue that you don't necessarily have to know SH to understand (simple) APKBUILDs :)
2019-06-13 19:26:52 <SpaceToast> certainly, the distinction between '' and "" isn't something a casual peruser need to understand to understand the general intent, if they don't intend to change it (and thus partake in writing)
2019-06-13 19:27:20 <Cogitri> I haven't encountered single quotes anywhere during the time I've worked on Alpine yet tbh
2019-06-13 19:27:22 <SpaceToast> either way, I'm fine with ""s for constants (given that it's plopped into a similar structure to my proposed 1, because again - pkgname and the like *are* constants)
2019-06-13 19:27:27 <_ikke_> SpaceToast: well, until they wonder why '$foo' does not work as expected
2019-06-13 19:27:45 <SpaceToast> _ikke_: in that case, they are *writing* APKBUILDs and thus should have a general understanding of shell :)
2019-06-13 19:28:21 <Cogitri> Huh, did Ikke write something? Doesn't show up for me :c
2019-06-13 19:28:36 <SpaceToast> '' is less error prone for that exact reason - you could always have an upstream package description that includes a verbatim `$`, for instance
2019-06-13 19:28:44 <_ikke_> Cogitri: yes, I did write something
2019-06-13 19:28:51 <Cogitri> Ah, now it does
2019-06-13 19:29:41 <Cogitri> SpaceToast: Escaping that in that rare occasions seems easier than explaining with '$variable' doesn't work
2019-06-13 19:30:08 <SpaceToast> I don't think saying "single-quotes forbid escaping and are thus useful for constants" is that big of a burden
2019-06-13 19:30:17 <SpaceToast> in fact, that explanation could be written right next to wherever we put the specification :)
2019-06-13 19:30:25 <SpaceToast> (probably the best-practices page)
2019-06-13 19:31:02 <_ikke_> I don't think we should say always use ' or always use "
2019-06-13 19:31:12 <Cogitri> Sadly I doubt that the best case (everyone reading all of the guide) will apply :)
2019-06-13 19:31:40 <Cogitri> Hm, I feel like some consistency would be nice, ikke
2019-06-13 19:32:17 <SpaceToast> _ikke_: let me re-iterate my proposal regarding constants: 1. Constants are either unquoted, or quoted with single-quotes. Single quotes are required if the constant contains anything besides [a-zA-Z0-9_\.\-]
2019-06-13 19:32:32 <SpaceToast> Cogitri: well, "please read best practices guide" is very low-effort :)
2019-06-13 19:33:09 <SpaceToast> and consistency is what at least 2 people clearly desire, and something ncopa has spoken in favor of in the past (though to get his exact opinion we'll need to wait until at least tomorrow)
2019-06-13 19:39:03 <Cogitri> Yup, but it'd be consistent with our current behaviour to not use single quotes
2019-06-13 19:42:25 <SpaceToast> well, as mentioned, I'm fine with any spec :) I'm just here to propose what I believe to be the most technically correct one
2019-06-13 19:42:51 <SpaceToast> (and give justification, of course)
2019-06-13 19:42:59 <Cogitri> I'd personally vote for make what we currently use the spec
2019-06-13 19:43:15 <Cogitri> s/use/most commonly use/
2019-06-13 19:44:36 <SpaceToast> so that would be "" for constants that have chars besides [a-zA-Z0-9_\.\-], "" for interpolations being assigned to variables and "expansion"unquoted for non-assignments
2019-06-13 19:45:01 <SpaceToast> that just seems really awkward, but I'll defer to whatever ncopa and/or the rest of the core team figure (so long as it is a complete spec that can be applied, of course)
2019-06-14 07:59:17 <ncopa> ugh... should I calculate a week of time spent on discussion how to use quotes?
2019-06-14 08:01:04 <Cogitri> Not really
2019-06-14 08:07:41 <clandmeter> best practices is good but i dont like to see a gazillion commits saying: "repo/foobar: update quotes to follow best practices"
2019-06-14 08:09:04 <mps> clandmeter: also I don't like these i.e. commit msg says just 'modernize'
2019-06-14 08:09:59 <Cogitri> mps: Well, people complain if you require them to modernize during updates too
2019-06-14 08:10:16 <clandmeter> you cannot always prevent modernize due to changes.
2019-06-14 08:10:20 <Cogitri> So I think it makes sense to modernize the thing in one go instead of complaining about it when someone updates the thing
2019-06-14 08:10:25 <clandmeter> some apkbuilds are very old.
2019-06-14 08:10:48 <Cogitri> Yup, and very crude
2019-06-14 08:11:04 <mps> I agree with SpaceToast's observations but also think that Cogitri's 'I'd personally vote for make what we currently most commonly use the spec'
2019-06-14 08:11:17 <Cogitri> Currently working through perl-*
2019-06-14 08:12:21 <mps> I'm not against changes but personally prefer change when the pkg upgraded or fixed
2019-06-14 08:12:37 <Cogitri> Well, I honestly think we should go back to more productive discussions :)
2019-06-14 08:12:56 <clandmeter> or do something else productive
2019-06-14 08:12:58 <clandmeter> :)
2019-06-14 08:13:53 <clandmeter> Cogitri: you manager on bugs.a.o right?
2019-06-14 08:14:01 <clandmeter> or whatever the title is
2019-06-14 08:14:06 <mps> yes, but I have first to wake up ;)
2019-06-14 08:14:16 <Cogitri> Yup
2019-06-14 08:14:17 <desultory> so, why not make single quotes the standard for new apkbuilds, and leave it to maintainer discretion when/if to "modernize" existing instances?
2019-06-14 08:14:31 <Cogitri> Btw, do you happen to know why I can't assign bugs to myself, clandmeter?
2019-06-14 08:14:55 <clandmeter> Cogitri: care to check out gitlab.a.o?
2019-06-14 08:15:05 <Cogitri> desultory: Hm, that still breaks the habits of most contributors
2019-06-14 08:15:09 <clandmeter> hehe
2019-06-14 08:15:10 <Cogitri> clandmeter: sure thing!
2019-06-14 08:15:23 <clandmeter> algitbot: shut up
2019-06-14 08:15:34 <clandmeter> you are holding it wrong
2019-06-14 08:15:45 <clandmeter> ok let me get you a pw
2019-06-14 08:15:59 <clandmeter> smtp is disabled
2019-06-14 08:16:12 <clandmeter> Cogitri: what is your username on bugs?
2019-06-14 08:16:19 <desultory> Cogitri: how? "do this in new packages, and if you remember/care to when changing old ones" doesn't seem all that bad.
2019-06-14 08:16:28 <Cogitri> clandmeter: Cogitri
2019-06-14 08:17:14 <clandmeter> ah you are rasmus
2019-06-14 08:17:21 <clandmeter> i need to get used to these new names...
2019-06-14 08:17:49 <desultory> Cogitri: alternately, "we officially don't care about which qutes you use unless it matters in the circumstances in which they're used" would be about the least "disruptuive" to habit policy which could be made in this case.
2019-06-14 08:18:11 <Cogitri> desultory: Seeing that about no one uses the proposed style right now I don't really see a point in suddenly enforcing it
2019-06-14 08:19:10 <desultory> Cogitri: so you'd be in favor of "we officially don't care"?
2019-06-14 08:19:16 <Cogitri> desultory: Yup, I think that matches our current, implicit, policy well I think
2019-06-14 08:19:35 <Cogitri> <desultory "cogitri: alternately, "we offici"> Meant to reply to this ^
2019-06-14 08:19:42 <Cogitri> Mobile net is a bit shoddy right now
2019-06-14 08:20:05 <Cogitri> clandmeter: Heh, no worries
2019-06-14 08:21:58 <clandmeter> Cogitri: pmed pw
2019-06-14 08:25:22 <Cogitri> Uhh..where? I haven't received something yet
2019-06-14 08:31:11 <clandmeter> Cogitri: can you pm me?
2019-06-14 08:31:18 <clandmeter> i guess you are using matrix?
2019-06-14 08:32:03 <Cogitri> Yup
2019-06-14 08:33:28 <clandmeter> i cannot help you with that :)
2019-06-14 08:34:40 <mps> clandmeter: looks like import from bugs.a.o went good
2019-06-14 08:34:44 <clandmeter> we have a thelounge instance for alpine devs who like to use it.
2019-06-14 08:36:24 <mps> ehm, my last msg belongs to infra
2019-06-14 08:36:37 <Cogitri> Hm, I pinged you via irc though
2019-06-14 08:36:46 <clandmeter> im not getting anything
2019-06-14 08:36:53 <clandmeter> its normal for matrix though
2019-06-14 08:37:17 <clandmeter> i can send you an email
2019-06-14 09:53:08 <SpaceToast> well, maxice8 is (was?) demanding consistency
2019-06-14 09:53:27 <SpaceToast> I'm fine with "we officially don't care", but would ask one of you to them that if that's the case :)
2019-06-14 09:53:52 <SpaceToast> s/them/tell them/
2019-06-19 16:48:09 <errn0> Hello.. there is a type in "https://beta.docs.alpinelinux.org/user-handbook/0.1a/index.html" - SLAAC section... "an method" should be "a method"
2019-06-19 16:48:20 <errn0> typo*
2019-06-19 16:51:39 <SpaceToast> good catch, thanks, will correct it once I get off work
2019-06-19 16:52:06 <errn0> nvm
2019-06-19 17:03:24 <_ikke_>  Is it just me, or are you bound to mispell typo when you want to point one out?
2019-06-19 17:05:43 <errn0> _ikke_: Talking to me? Yeah.. My keyboard skills suck xD
2019-06-19 17:06:22 <errn0> Touchscreen actually!
2019-06-19 17:06:28 <errn0> xD
2019-06-19 17:09:19 <_ikke_> It happens to me as well :)
2019-06-19 17:09:29 <_ikke_> "Hey, you made a type here"
2019-06-19 22:03:01 <SpaceToast> errn0: typo fixed, do enjoy :)
2019-06-20 21:37:33 <tcely> I mistyped typo so often as tyop, that I started using that intentionally after a while. ;-)