You are not logged in.
Pages: 1
I've always had trouble understanding how regexes work but never investigated how they worked.
Recently I noticed mesa 26.2 had been released. It fixes issues with rusticl that require patching llvm/libclc or building a downstream fork called mesa-libclc .
I was hoping archlinux devs had started on this and checked if there was a testing package for mesa.
Turns out it hasn't been flagged out-of-date yet by the bot and users can't flag repo packages out-of-date anymore.
content of https://gitlab.archlinux.org/archlinux/ … ecker.toml
[mesa]
source = "git"
git = "https://gitlab.freedesktop.org/mesa/mesa.git"
include_regex = 'mesa-\d+\.\d+\.[1-9]\d*'
#include_regex = 'mesa-.*' # Unstable
prefix = "mesa-"
from_pattern = '-([a-z])'
to_pattern = '\1'Current version of mesa is 26.2.0 and I can guess the [1-9] means that doesn't lead to 26.1.6 being flagged as out of date.
I have no idea what the rest of the expression does and this is a simple regex. Can someone point me to a tutorial for regexes ?
Last edited by Lone_Wolf (Yesterday 16:23:15)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I was going to recommend the man page (e.g., `man 7 regex`) but it seems that's a pretty high-level overview and doesn't seem to really define the syntax. So my top suggestion would b eto experiment (with sed, grep, ...). Create a short text file, and start running some grep / sed commands with regexes to see what they do. If you really have no background at all in using regexes, then the wikipedia page is a pretty good starting reference: https://en.wikipedia.org/wiki/Regular_expression
But also note that there are several "flavors" of regex. There is a lot of overlap between them, but also many striking differences. So knowing which tool the regex is being fed to and with which flags is essentially in order to write or unambiguously interpret a regex.
On top of that when a regex is stored in a config file - as is the case for this toml file here - there *may* be some escaping of special characters needed, and this will depend on the config parser, whether the regex is in quotes in the config file, and how many downstream parsing steps there are, among potentially other factors.
I believe that regex will match anything starting with "mesa-" followed by one or more digits, a dot, one or more digits, a dot, then one or more digits not starting with a zero. In other words I believe this would include every typically formatted version number except revision numbers starting with 0 (and I don't think a revision number would ever start with zero except in the case of the first release of a minor version). So the end result is to skip the very first release of each minor version.
In this case the relevant syntax elements are '\d' which is the same as '[0-9]'. The '+' following these means "one or more of these". The '*' following the last '\d' means "zero or more of these".
Last edited by Trilby (Yesterday 12:12:49)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I used this Web app to learn regex few years ago. I remember that it was pretty good at the time.
You might find what you are looking for.
Simplicity is the ultimate sophistication. — Leonardo da Vinci (1452–1519)
Offline
according to https://docs.mesa3d.org/relnotes.html the current regex is flawed by require the patch number at least 1 which fail on every .0 release
also it could be argued if the quantifiers could be removed, as:
- since 11.0.0 the patch number is always
- the minor was never two digits
- there were only very few versions every getting to a .10 patch
a regex matching all recent versions could be
\d{2}\.\d\.\d
which would ecen be sufficient for .1X patches as in the past there already was the next minor before the previous one got to .10
and by the current pace it'll be some time before we get to three digit major
Offline
according to https://docs.mesa3d.org/relnotes.html the current regex is flawed by require the patch number at least 1
Is that flawed, or functional? A regex that matches every possible input really wouldn't serve any purpose at all, would it?
And limiting the minor version to single digits based solely on the fact that there hasn't yet been a double-digit minor version would be a poor choice.
The goal of the regex is not to match everything currently listed on the releases page. Rather it is to match the desired subset of not only what is already there, but what could likely be there in the future.
Last edited by Trilby (Yesterday 13:45:26)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
POV: the regex might deliberately skip .0 releases to allow upstream to iron out the worst bugs before subjecting poor end users w/ it?
https://gitlab.archlinux.org/archlinux/ … 9d21c34a70
Offline
Thanks for the explanations and links, I have a lot to read the next days.
Marking as solved, but don't let that stop the discussion .
For clarity about mesa version numbering :
Starting with the first release of 2017, Mesa’s version scheme is year-based. Filenames are in the form mesa-Y.N.P.tar.gz, where Y is the year (two digits), N is an incremental number (starting at 0) and P is the patch number (0 for the first release, 1 for the first patch after that).
When a new release is coming, release candidates (betas) may be found in the same directory, and are recognizable by the mesa-Y.N.P-rcX.tar.gz filename.
Avoiding .0 releases could be an archlinux policy , though it brings a question to mind :
if "poor end users" skip .0 releases to avoid bugs who will report those bugs so devs can make .1 better then .0 ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
gentoo victims!![]()
Edit: to add some useful rationale, the patch replaces something that explicitly sought to exclude unstable releases and I trust that @heftig had an active reason to deliberately exclude .0 releases from the regexp.
Last edited by seth (Yesterday 16:28:04)
Offline
Pages: 1