Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On Mon, Sep 25, 2023 at 14:03:26 +0200, Ulrich Mueller wrote: > > On Sun, 24 Sep 2023, Jonas Stein wrote: > > >> # Removal on 2023-10-21. Bug #667687, #667689. > > > We should use "after" instead of "on": > > > # Removal after T > > I wonder if we even need to specify the wording in such detail. For any > tools parsing the file, it might be enough to say that the line must > contain, in this order: > > - "Removal" (case insensitive?) as the first word, > - exactly one date in -MM-DD format, > - optionally, the word "bug" followed by one or more bug numbers. > With the scheme above, the following would be valid (among other more nonsensical looking things): # Removal before -MM-DD. Bug #1, #2 IMO it definitely should require a word with similar meaning to "on" or "after". How exactly that gets worded in the end, IDK. Maybe it'll end up as "exactly one of 'on' or 'after'" or something like that. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Sun, 24 Sep 2023, Jonas Stein wrote: >> # Removal on 2023-10-21. Bug #667687, #667689. > We should use "after" instead of "on": > # Removal after T I wonder if we even need to specify the wording in such detail. For any tools parsing the file, it might be enough to say that the line must contain, in this order: - "Removal" (case insensitive?) as the first word, - exactly one date in -MM-DD format, - optionally, the word "bug" followed by one or more bug numbers. Ulrich
[gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Hi all, # Removal on 2023-10-21. Bug #667687, #667689. We should use "after" instead of "on": # Removal after T -- Best, Jonas OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Hi all,
I want to suggest a standard format for profiles/package.mask, for
multiple reasons:
Sounds sensible. +1
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
Can we drop this? Or, at least, relax this.
I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can not
remember any situation where the date being in UTC matters. Plus, if you
want accurate timestamps, then the git commit/author date is here for
you. :)
I think for the same reason UTC full timestamp makes sense:
The person who adds an entry to the package.mask file does not care
about a few hours and simply rounds the time up.
The scripts which evaluate the .mask file have a proper time stamp. For
a script it is trivial to work with time, if you have UTC in a standard
format. But it is painful, if you just have a date and do not know the
timezone.
So I think you and I really want UTC here.
--
Best,
Jonas
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Sat, 23 Sep 2023, Alex Boag-Munroe wrote: > I'm confused, you're against adding "massive header blocks" but you're > fine with Arthur's 9 line entry but not my 8 line one. Your 8 line entry was this (please correct me if you meant to refer to an entry from a different message): --- 8< --- # [PREAMBLE] # Timestamp: 2023-09-21 15:07:42+00:00 # Author: Arthur Zamarin # Justification: Very broken, no idea why packaged, need to drop ASAP. # The project is done with supporting this package. # Bugs: 667687, 667689 # Packages: dev-lang/python dev-lang/python --- >8 --- And Arthur's was this: --- 8< --- # Arthur Zamarin (2023-09-21) # Very broken, no idea why packaged, need to drop ASAP. The project # is done with supporting this package. See for history bug #667889. # # As a better plan, you should migrate to dev-lang/perl, which has # better compatibility with dev-lang/ruby when used with dev-lang/lua # bindings. # Removal on 2023-10-21. Bug #667687, #667689. dev-lang/python --- >8 --- Of course it is longer when it contains 4 additional lines of explanation. > My idea was a stop gap to add something easily parsed once the > comments are stripped but keeping the comments in place currently for > backwards compatibility. Yes, understood. I think we should keep the "simple line-based file" format [1] with comments. If we would change it to something completely different, we would also impose that format on users' (public or private) overlays. Also, we'd either have to change the files in /etc/portage (not sure how popular that would be) or live with two different and incompatible formats in profiles and user configuration. Ulrich [1] https://projects.gentoo.org/pms/8/pms.html#x1-480005.2.5 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On Sat, 23 Sept 2023 at 08:03, Ulrich Mueller wrote: > This seems rather restrictive, adds unnecessary redundancy, and would > make it hard to type an entry without the aid of special tools. > > Also, there are other files like use.mask which probably shouldn't have > a completely different format. Their entries often have the author/date > line plus a one line comment which says all that is needed. Adding > massive header blocks there would be excessive. > > IMHO Arthur's original proposal was fine. Let's not over-complicate > things. > > Ulrich I'm confused, you're against adding "massive header blocks" but you're fine with Arthur's 9 line entry but not my 8 line one. My idea was a stop gap to add something easily parsed once the comments are stripped but keeping the comments in place currently for backwards compatibility. Since parsing was part of the OP it made sense to me to suggest an "already existing made for humans to read/write while tools can already parse it" structure. What special tools do you think are needed to write it? I wrote the above in Kate after double checking the configparser docs. A standard template would be trivial. -- Ninpo
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Arthur Zamarin writes: > [[PGP Signed Part:Undecided]] > On 22/09/2023 17.50, Alex Boag-Munroe wrote: >> On Fri, 22 Sept 2023 at 15:37, Sam James wrote: >>> >>> >>> Alex Boag-Munroe writes: >>> Any reason for the parseable parts to not be in an established human readable/editable format? e.g. the config ini style format, or TOML? >>> >>> The only issue really is that depending on how it's done (do we do >>> it for the whole file, or just comments), it may need a new (profile) >>> EAPI which will take a while to implement and deploy. >>> >>> If it's just for comments, then we can do it immediately though. >>> To crib from the OP example with something configparser understands: [PREAMBLE] Timestamp: 2023-09-21 15:07:42+00:00 Author: Arthur Zamarin Justification: Very broken, no idea why packaged, need to drop ASAP. The project is done with supporting this package. Bugs: 667687, 667689 Removal Date: 2023-10-21 Packages: dev-lang/python The format is well documented already and simple to check for validity, so any GLEP would just need to cover correct keys/values. >>> >>> But yeah, I agree it's worth thinking about a proper format rather than >>> fragile text mangling going into the future. >>> >> Perhaps eventually it could/should be used for the whole file but as >> an interim/beginning there's no reason you couldn't start with >> comments: >> >> # [PREAMBLE] >> # Timestamp: 2023-09-21 15:07:42+00:00 >> # Author: Arthur Zamarin >> # Justification: Very broken, no idea why packaged, need to drop ASAP. >> # The project is done with supporting this package. >> # Bugs: 667687, 667689 >> # Packages: dev-lang/python >> dev-lang/python >> >> This simply adds a pre parse step of stripping the comments then >> feeding directly into configparser or probably more suitable, TOML >> since TOML has better syntax for directly delivering things like a >> "Packages:" key as a list. >> >> Redoing a bunch of package.* parsing probably wasn't in scope of the >> OP but I've always wondered and this felt an opportune moment to >> ask/suggest :) > > Thanks for the idea. Yes, it was out of scope such suggestions for me > originally, but thinking more about it, I take it more positively. > Please let me (and others) to consider it for some days, cause this is > very interesting proposal. Things to consider is how much effort it is > to file in future, which format to use, etc. > It's fine with me if we just go with the original for now, but I think the awkwardness (which is not your fault, but the nature of wrangling free-form text) of the specification shows that we should at some point move to something structured. But I don't consider it a blocker for doing something better than the status quo. Maybe we'll be better off just going straight for Exherbo-style p.mask in future: https://ciaranm.wordpress.com/2011/03/27/classifying-repository-masks/ Ultimately, text munging sucks and there's only so much we can do to polish it. But your original proposal is a good improvement on how things are now. >> -- >> Ninpo >>
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes: > [[PGP Signed Part:Undecided]] >> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote: > >> Perhaps eventually it could/should be used for the whole file but as >> an interim/beginning there's no reason you couldn't start with >> comments: > >> # [PREAMBLE] >> # Timestamp: 2023-09-21 15:07:42+00:00 >> # Author: Arthur Zamarin >> # Justification: Very broken, no idea why packaged, need to drop ASAP. >> # The project is done with supporting this package. >> # Bugs: 667687, 667689 >> # Packages: dev-lang/python >> dev-lang/python > > And I thought my suggestion to use XML was far-fetched and an obvious > joke. :( This is rather disrespectful to someone (who is a new contributor as well) making a suggestion in earnest. You could've dropped this sentence and the rest of your critique would stand. Please consider phrasing in future. > > This seems rather restrictive, adds unnecessary redundancy, and would > make it hard to type an entry without the aid of special tools. > > Also, there are other files like use.mask which probably shouldn't have > a completely different format. Their entries often have the author/date > line plus a one line comment which says all that is needed. Adding > massive header blocks there would be excessive. > > IMHO Arthur's original proposal was fine. Let's not over-complicate > things. > > Ulrich > > [[End of PGP Signed Part]]
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote: > Perhaps eventually it could/should be used for the whole file but as > an interim/beginning there's no reason you couldn't start with > comments: > # [PREAMBLE] > # Timestamp: 2023-09-21 15:07:42+00:00 > # Author: Arthur Zamarin > # Justification: Very broken, no idea why packaged, need to drop ASAP. > # The project is done with supporting this package. > # Bugs: 667687, 667689 > # Packages: dev-lang/python > dev-lang/python And I thought my suggestion to use XML was far-fetched and an obvious joke. :( This seems rather restrictive, adds unnecessary redundancy, and would make it hard to type an entry without the aid of special tools. Also, there are other files like use.mask which probably shouldn't have a completely different format. Their entries often have the author/date line plus a one line comment which says all that is needed. Adding massive header blocks there would be excessive. IMHO Arthur's original proposal was fine. Let's not over-complicate things. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 22/09/2023 17.50, Alex Boag-Munroe wrote: > On Fri, 22 Sept 2023 at 15:37, Sam James wrote: >> >> >> Alex Boag-Munroe writes: >> >>> Any reason for the parseable parts to not be in an established human >>> readable/editable format? e.g. the config ini style format, or TOML? >> >> The only issue really is that depending on how it's done (do we do >> it for the whole file, or just comments), it may need a new (profile) >> EAPI which will take a while to implement and deploy. >> >> If it's just for comments, then we can do it immediately though. >> >>> >>> To crib from the OP example with something configparser understands: >>> [PREAMBLE] >>> Timestamp: 2023-09-21 15:07:42+00:00 >>> Author: Arthur Zamarin >>> Justification: Very broken, no idea why packaged, need to drop ASAP. >>> The project is done with supporting this package. >>> Bugs: 667687, 667689 >>> Removal Date: 2023-10-21 >>> Packages: dev-lang/python >>> >>> The format is well documented already and simple to check for >>> validity, so any GLEP would just need to cover correct keys/values. >>> >> >> But yeah, I agree it's worth thinking about a proper format rather than >> fragile text mangling going into the future. >> > Perhaps eventually it could/should be used for the whole file but as > an interim/beginning there's no reason you couldn't start with > comments: > > # [PREAMBLE] > # Timestamp: 2023-09-21 15:07:42+00:00 > # Author: Arthur Zamarin > # Justification: Very broken, no idea why packaged, need to drop ASAP. > # The project is done with supporting this package. > # Bugs: 667687, 667689 > # Packages: dev-lang/python > dev-lang/python > > This simply adds a pre parse step of stripping the comments then > feeding directly into configparser or probably more suitable, TOML > since TOML has better syntax for directly delivering things like a > "Packages:" key as a list. > > Redoing a bunch of package.* parsing probably wasn't in scope of the > OP but I've always wondered and this felt an opportune moment to > ask/suggest :) Thanks for the idea. Yes, it was out of scope such suggestions for me originally, but thinking more about it, I take it more positively. Please let me (and others) to consider it for some days, cause this is very interesting proposal. Things to consider is how much effort it is to file in future, which format to use, etc. > -- > Ninpo > -- Arthur Zamarin arthur...@gentoo.org Gentoo Linux developer (Python, pkgcore stack, Arch Teams, GURU) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On Fri, 22 Sept 2023 at 15:37, Sam James wrote: > > > Alex Boag-Munroe writes: > > > Any reason for the parseable parts to not be in an established human > > readable/editable format? e.g. the config ini style format, or TOML? > > The only issue really is that depending on how it's done (do we do > it for the whole file, or just comments), it may need a new (profile) > EAPI which will take a while to implement and deploy. > > If it's just for comments, then we can do it immediately though. > > > > > To crib from the OP example with something configparser understands: > > [PREAMBLE] > > Timestamp: 2023-09-21 15:07:42+00:00 > > Author: Arthur Zamarin > > Justification: Very broken, no idea why packaged, need to drop ASAP. > > The project is done with supporting this package. > > Bugs: 667687, 667689 > > Removal Date: 2023-10-21 > > Packages: dev-lang/python > > > > The format is well documented already and simple to check for > > validity, so any GLEP would just need to cover correct keys/values. > > > > But yeah, I agree it's worth thinking about a proper format rather than > fragile text mangling going into the future. > Perhaps eventually it could/should be used for the whole file but as an interim/beginning there's no reason you couldn't start with comments: # [PREAMBLE] # Timestamp: 2023-09-21 15:07:42+00:00 # Author: Arthur Zamarin # Justification: Very broken, no idea why packaged, need to drop ASAP. # The project is done with supporting this package. # Bugs: 667687, 667689 # Packages: dev-lang/python dev-lang/python This simply adds a pre parse step of stripping the comments then feeding directly into configparser or probably more suitable, TOML since TOML has better syntax for directly delivering things like a "Packages:" key as a list. Redoing a bunch of package.* parsing probably wasn't in scope of the OP but I've always wondered and this felt an opportune moment to ask/suggest :) -- Ninpo
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Alex Boag-Munroe writes: > Any reason for the parseable parts to not be in an established human > readable/editable format? e.g. the config ini style format, or TOML? The only issue really is that depending on how it's done (do we do it for the whole file, or just comments), it may need a new (profile) EAPI which will take a while to implement and deploy. If it's just for comments, then we can do it immediately though. > > To crib from the OP example with something configparser understands: > [PREAMBLE] > Timestamp: 2023-09-21 15:07:42+00:00 > Author: Arthur Zamarin > Justification: Very broken, no idea why packaged, need to drop ASAP. > The project is done with supporting this package. > Bugs: 667687, 667689 > Removal Date: 2023-10-21 > Packages: dev-lang/python > > The format is well documented already and simple to check for > validity, so any GLEP would just need to cover correct keys/values. > But yeah, I agree it's worth thinking about a proper format rather than fragile text mangling going into the future. > Just a thought.
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Any reason for the parseable parts to not be in an established human readable/editable format? e.g. the config ini style format, or TOML? To crib from the OP example with something configparser understands: [PREAMBLE] Timestamp: 2023-09-21 15:07:42+00:00 Author: Arthur Zamarin Justification: Very broken, no idea why packaged, need to drop ASAP. The project is done with supporting this package. Bugs: 667687, 667689 Removal Date: 2023-10-21 Packages: dev-lang/python The format is well documented already and simple to check for validity, so any GLEP would just need to cover correct keys/values. Just a thought. -- Ninpo
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes: >> On Fri, 22 Sep 2023, Ulrich Mueller wrote: > >> On Fri, 22 Sep 2023, Florian Schmaus wrote: >>> Some, including me, consider timestamps without timezone specifiers to >>> be in local time (either of the consumer or producer of the >>> timestamp). Hence, if you really must have UTC here, then at least >>> consider making it explicit my requiring the 'Z' timezone specifier >>> (which, if you want to be ISO compatible, probably means that the >>> timestamp must include HH:MM too). > >> How about converting package.mask to XML? The xs:date type would allow >> a date followed by a time zone [1]. > >> /me hides > > Seriously, this isn't a hill I am willing to die on. I still prefer UTC > there, but I'd be fine if the wording said "should" instead of "must". Yes, I want the UTC bit in there, but it's fine if it's "should" and not "must". I was trying to articulate that before but I didn't do so very clearly. > > Ulrich
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Fri, 22 Sep 2023, Ulrich Mueller wrote: > On Fri, 22 Sep 2023, Florian Schmaus wrote: >> Some, including me, consider timestamps without timezone specifiers to >> be in local time (either of the consumer or producer of the >> timestamp). Hence, if you really must have UTC here, then at least >> consider making it explicit my requiring the 'Z' timezone specifier >> (which, if you want to be ISO compatible, probably means that the >> timestamp must include HH:MM too). > How about converting package.mask to XML? The xs:date type would allow > a date followed by a time zone [1]. > /me hides Seriously, this isn't a hill I am willing to die on. I still prefer UTC there, but I'd be fine if the wording said "should" instead of "must". Ulrich
[gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Hi,
On 2023/09/22 13:16, Florian Schmaus wrote:
On 21/09/2023 21.40, Arthur Zamarin wrote:
If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list
FWIW, I would assume the last-rite date to be the date where the
package's last rites where initiated, i.e., where it was p.masked. The
removal date would be the date on which the packages was cleaned from
the tree.
other bugs relevant to the last-rite. So I think a format of: "Removal
on ${REMOVAL_DATE}.
I now we, myself included, often wrote "Removal on…", however, I
wonder if we should reflect reality and write "Removal after…" instead.
+1
"on or after" would probably be most accurate though but gets very wordy.
Kind regards,
Jaco
[gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 21/09/2023 21.40, Arthur Zamarin wrote:
If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list
FWIW, I would assume the last-rite date to be the date where the
package's last rites where initiated, i.e., where it was p.masked. The
removal date would be the date on which the packages was cleaned from
the tree.
other bugs relevant to the last-rite. So I think a format of: "Removal
on ${REMOVAL_DATE}.
I now we, myself included, often wrote "Removal on…", however, I wonder
if we should reflect reality and write "Removal after…" instead.
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Fri, 22 Sep 2023, Florian Schmaus wrote: > Some, including me, consider timestamps without timezone specifiers to > be in local time (either of the consumer or producer of the > timestamp). Hence, if you really must have UTC here, then at least > consider making it explicit my requiring the 'Z' timezone specifier > (which, if you want to be ISO compatible, probably means that the > timestamp must include HH:MM too). How about converting package.mask to XML? The xs:date type would allow a date followed by a time zone [1]. /me hides [1] https://www.w3.org/TR/xmlschema-2/#deviantformats signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 22/09/2023 08.39, Florian Schmaus wrote: Some, including me, consider timestamps without timezone specifiers to be in local time (either of the consumer or producer of the timestamp). Hence, if you really must have UTC here, then at least consider making it explicit my requiring the 'Z' timezone specifier. I forgot the to include the motivation for doing so: Timestamps with a timezone specifier make it clear to the producer of the timestamp that they should produce an offset-ed timestamp and make it evident to the consumer of the timestamp which timezone it is in. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 21/09/2023 23.48, Sam James wrote:
Ulrich Mueller writes:
On Thu, 21 Sep 2023, Florian Schmaus wrote:
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
Can we drop this? Or, at least, relax this.
I think UTC makes a lot of sense in an international context like ours.
It does, but mostly if you also care about the hour and minute of the
timestamp [1].
It also avoids flapping of the date between entries (i.e. a newer entry
having an older date than the previous one).
This appears to be mainly an esthetic issue (and probably also rarely
happens).
the same time, I'd like us to standardise on UTC
But why? Which problem does it solve for p.mask entries?
I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can
not remember any situation where the date being in UTC matters. Plus,
if you want accurate timestamps, then the git commit/author date is
here for you. :)
Users consume p.mask entries directly rather than via git.
Correct. But how many users reading p.mask entries thought about the
timezone the date timestamp is in? I'd assume at most only a few,
because it is not relevant to know if its +00 or +02 or -07.
Some, including me, consider timestamps without timezone specifiers to
be in local time (either of the consumer or producer of the timestamp).
Hence, if you really must have UTC here, then at least consider making
it explicit my requiring the 'Z' timezone specifier (which, if you want
to be ISO compatible, probably means that the timestamp must include
HH:MM too).
- Flow
1: That is probably why I don't see a timezone specifier for calendar
dates in ISO 8601.
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
Ulrich Mueller writes:
> [[PGP Signed Part:Undecided]]
>> On Thu, 21 Sep 2023, Florian Schmaus wrote:
>
>>> The first line of the "#"-prefixed explanation block must be of the
>>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>>> format -MM-DD, in UTC timezone.
>>
>
>> Can we drop this? Or, at least, relax this.
>
> I think UTC makes a lot of sense in an international context like ours.
> It also avoids flapping of the date between entries (i.e. a newer entry
> having an older date than the previous one).
Yes, I don't think we need to punish people for getting it wrong, but at
the same time, I'd like us to standardise on UTC - saying this as
someone who isn't in UTC half of the year.
That means others are free to correct it if they notice it's the
wrong date and so on.
>> I usually just enter my locale date here and like to avoid having to
>> think about that UTC is potentially in a different date. I also can
>> not remember any situation where the date being in UTC matters. Plus,
>> if you want accurate timestamps, then the git commit/author date is
>> here for you. :)
Users consume p.mask entries directly rather than via git.
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
> On Thu, 21 Sep 2023, Florian Schmaus wrote:
>> The first line of the "#"-prefixed explanation block must be of the
>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>> format -MM-DD, in UTC timezone.
>
> Can we drop this? Or, at least, relax this.
I think UTC makes a lot of sense in an international context like ours.
It also avoids flapping of the date between entries (i.e. a newer entry
having an older date than the previous one).
> I usually just enter my locale date here and like to avoid having to
> think about that UTC is potentially in a different date. I also can
> not remember any situation where the date being in UTC matters. Plus,
> if you want accurate timestamps, then the git commit/author date is
> here for you. :)
signature.asc
Description: PGP signature
[gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On 21/09/2023 21.40, Arthur Zamarin wrote:
Hi all
I want to suggest a standard format for profiles/package.mask, for
multiple reasons:
Sounds sensible. +1
The first line of the "#"-prefixed explanation block must be of the
format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
format -MM-DD, in UTC timezone.
Can we drop this? Or, at least, relax this.
I usually just enter my locale date here and like to avoid having to
think about that UTC is potentially in a different date. I also can not
remember any situation where the date being in UTC matters. Plus, if you
want accurate timestamps, then the git commit/author date is here for
you. :)
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
