99 Replies
@antheas @bsherman @M2 Hey so there's a lot of coreos in this upstream chart:
that's the pink line, it's more than fedora server and us. I think we should get ucore sorted out on countme if we can.
this is the issue https://github.com/ublue-os/ucore/issues/202
GitHub
Monitor usage in Fedora's CountMe metrics · Issue #202 · ublue-os...
Our machines are pushing metrics to Fedora's servers. Bluefin, Aurora and Bazzite are being recorded as separate distros, however I believe UCore is counted under CoreOS. It would be awesome to...
@Lorbus your skillset would be useful here. 😄
i think we have examples in bluefin/bazzite... per the issue... i just never dove into it
who was the other person doing charts, 4 digit number as a nick
Maybe me?
I really do have a talent for bad and/or non memorable nicknames
@Niko
haha yes!
we just need to figure out what os-release changes to make, but we have to account for announcing because apparently people use sysexts?
yeah, i have added announcements to the repo README
but that's usually not until something is actually done, not ahead of time
and i can probably pick it up this weekend... i just haven't spent the time to follow what bluefin/bazzite do
I think we'll just be setting the os-release, wait a few weeks for it to start showing up in the stats
yeah that seems like the right path forward. Not sure about the sysext stuff, haven't used any of that yet. If they are id-specific, they'll likely break. Maybe they can be changed to allow for multiple IDs?
Travier used to have them be any. But he changed it to be fedora.
Yeah I think that's to distinguish between sysexts for servers and desktops, maybe it can just be
CoreOS || uCore for the server ones?It's the ID that we need to change for countme and that's coded to fedora for travier.
Actually could probably just change variant or something else
I think we have an “ID_LIKE” key in os-release on universal blue desktops, we could suggest support for that in travier’s repo, or does that need to be upstream change?
Actually, I'm thinking we may be able to do this without changing ID. Keeping compat with sysexts
Ok? But it would still allow uCore to differentiate in countme?
Things get even trickier if we start thinking about a CentOS based uCore too LOL
so I believe fedora normally differentiates with variant_id
since everything uses ID=fedora
so... are aurora/bluefin/bazzite changing countme incorrectly?
I thought it was intentional to avoid using their trademark perhaps?
I thought it was intentional to avoid using their trademark perhaps?
that might be....
I don't think shipping ID=fedora infringes on their TM tbh
fedora references are literally everywhere in Bluefin
because that's where most of the packages come from
but IANAL
so far, neither Red Hat nor Fedora have sued anyone for fair use of their stuff
yeah there is a ton of stuff that is fundamentally fedora that we would never be able to move away from if using fedora as a base
It was intentional to get other counting services to differentiate us
I was correct it was intentional, incorrect about why 🙂
makes sense 🙂 so we need to figure out how to have our own ID and still be able to use @Timothée Ravier 's sysexts with uBlue OSes
if the only goal is to be able to count in countme, variant would be fine
we get both columns -
so it's
and more columns that i left out for brevity
hmm so if we were to switch coreOS to uCore it'd be from:
to
ah so travier must have linked it to the os_variant, because core os's os_name is Fedora Linux still FYI
we could switch it to:
so as to not break anything, but we're kinda getting into hack territory here. (keep the
os_variant: coreos, which sysexts are looking for, but change the os_name from Fedora Linux to uCore...)Suggested here for prosperity https://github.com/ublue-os/ucore/issues/261
GitHub
Suggestion: change os_name to uCore · Issue #261 · ublue-os/ucore
Hi! Goal is to know how many ucore nodes are running with countme. The first few columns of countme data look like this: week_start,week_end,hits,os_name,os_version,os_variant so for bazzite: 2025-...
i can probably figure out how to do that if we're down. it's a bit of a workaround though.
sick! travier says sysexts don't check the variant! https://github.com/ublue-os/ucore/issues/261
GitHub
Suggestion: change os_name to uCore · Issue #261 · ublue-os/ucore
Hi! Goal is to know how many ucore nodes are running with countme. The first few columns of countme data look like this: week_start,week_end,hits,os_name,os_version,os_variant so for bazzite: 2025-...
for your consideration: https://github.com/ublue-os/ucore/pull/262
GitHub
Update install-ucore.sh to include variant_id for countme by nikodu...
Suggestion to close #261 and #202.
implements the learnings from above ticket thread
LGTM
i left a review requesting a few small changes, but I very much appreciate your PR and everyone chiming in to help make a good change here
I think this approach may be really good for uCore, because we could use the same exact change on a CentOS based uCore in the future... it would still be
centos but variant is ucoreof course!
hopping in here for a quicker discussion than in PR
I can't find any prior art in bazzite or bluefin for editing "variant" - I thought variant_id was variant?
i'm of course happy to add a string change to variant, but not sure it exists?
the other re-ordering change is done!
VARIANT is the pretty name (e.g. "Silverblue" vs id silverblue)
yeah but there's just never any edits to it that i can find so far?
- https://github.com/search?q=repo%3Aublue-os%2Fbluefin%20os-release&type=code
- https://github.com/search?q=repo%3Aublue-os%2Fbazzite%20os-release&type=code
Bluefin does it here: https://github.com/ublue-os/bluefin/blob/main/build_files/base/00-image-info.sh#L41-L54
yeah but that's only variant_id, same as in the PR? https://github.com/ublue-os/bluefin/blob/main/build_files/base/00-image-info.sh#L41C1-L41C70
probably an oversight I imagine
should be fine to change, nothing really depends on that afaik
Bluefin still has "Silverbue"
mind PRing in
CODE_NAME = "Deinonychus"
that needs an update
@Kyle Gospo let's use archeopteryx for something else, I need the dino names to match achillobatorVERSION_CODENAME="Deinonychus" for Bluefin? will doI'll move to bluefin-dev
it's just
CODE_NAME afaict?not on my sys
wrong line: https://github.com/ublue-os/bluefin/blob/117dad95b80090864c86c29d07694982f4ef5b84/build_files/base/00-image-info.sh#L52
it looks like VERSION_CODENAME is the same for all versions, not sure that's intended?
https://github.com/ublue-os/bluefin/pull/2586
I agree that the desktops (bluefin, bazzite, aurora) don't modify
VARIANT but they are also modifying ID which we are actively avoiding with the uCore countme effort.
arguably, the ucore situation is cleaner right nowshouldn't the VARIANT also be changed for Bluefin/Aurora though?
I'd also use ID=fedora for Blueifn/Aurora, so sysexts can work
probably? but it would take some looking at the various setups to see how these values are used... because they ARE used.
i understand this, but also, the ship has sailed somewhat...
when the "desktops" above made the change, sysext was NOT so restrictive... and those countme metrics are already flowing, etc... so any changes to them are more impactful and should be evaluated separately from the uCore discussion
IMO we should make these two work steps.
- change the variant_id for now so we can count.
- change the variant ublue-wide once we have a unified plan and we're sure things won't break?
for the sysext goal specifically, personally, i think we'd be better served by a patch to sysext to respect
ID_LIKEI think the cleanest way would be to change systemd to allow for matching ID against ID_LIKE
yea
exactly
I can get on that
but not today
is it ok to merge this with the re-ordering then @bsherman , or prefer we figure out how to edit the variant on this same PR? https://github.com/ublue-os/ucore/pull/262/files
any change in sd will take time to percolate anyway, I'd merge
uCore has never modified anything in os-release save for the PRETTY_NAME
other than being based on ostree Fedora, it has little in common with the desktop projects.
and as I've mentioned, I think VARIANT and VARIANT_ID fit uCore well... sure maybe they could have been used for the desktops if this was discussed way back when, but now...? I'm not eager to try to shove uCore into the same constraints the desktops have
happy to add
sed -i "s|^VARIANT=.*|VARIANT=$IMAGE_NAME|" /usr/lib/os-release?yes, I'd prefer to add the
VARIANT="uCore" to the PR... but then I think it's merge wworthy
VARIANT is like the "pretty" VARIANT_ID 🙂got it 🙂
that would be awesome... thank you!
I think @M2 and I had definitely discussed that sysext respecting
ID_LIKE would be the right thing, but we have not dove into iti'm being picky here, but i really want
uCore not ucore which is in $IMAGE_NAME
the script is a bit janky... it only exports IMAGE_NAME=ucore for use by packages.sh which will likely be going away soon.
So, ideally, I'd suggest this:
oh! and I just realized I missed something big
this won't apply to ucore Minimal... re-reading code for a momentya there seem to be 2 other duplicate files?
they aren't duplicate, they build on each other...
install-ucore-minimal.sh runs for all 3 images (minimal, ucore, and hci)
then install-ucore.sh runs building FROM ucore-minimal
finally install-ucore-hci.sh runs building FROM ucore
sorry, this is what I get for switching back and forth from my day job
oh no way! i didn't see they built on each other sorry
so maybe i should only do it in ucore-minimal.sh?
well, now i'm thinking about it... trying to decide if it's valuable to know each type of ucore or if we just want to know ucore in general...
i wouldn't break it up too much. IMO even LTS vs. non-LTS is too much in countme data
yeah, that's what I'm concered about
well, actually that may make sense as they're separate build processes
but DX vs non-DX
idk it's up to you. but i'd count it all as ucore until you have 10,000+ nodes on it. at that i'd split it up more 🙂
yeah, i think that's probably the right way... until that kind of need arises, we can infer relative popularity by looking at ghcr image pulls
so the new changes would be
removed from
install-ucore.sh but added to install-ucore-minimal.sh and don't touch the PRETTY_NAME line in any of the install scripts
(edit: added terminating | on VARIANT_ID line)OK, I caved and just did it: https://github.com/systemd/systemd/pull/37648
thanks so much guys
draft for now, not feeling like writing a test rn 😂 reviews are welcome already though
sorry my dayjob pulled me back in
oh damn! you already did a systemd pull!! super cool @Lorbus 🙂
moved to ucore-minimal @bsherman https://github.com/ublue-os/ucore/pull/262/files
it should be in both, otherwise all ucore images will get VARIANT_ID=ucore-minimal
right, i commented on github
this should be good to go now. I'll wait to see if maintainers want a test for this.
thank you very much! that's great! and will benefit more than just the Universal Blue project
like this?
https://github.com/ublue-os/ucore/pull/262/files
bug whackamole going on over here lol
not sure if i need doublequotes on that or not
it can be exactly like I did here: https://discord.com/channels/1072614816579063828/1375521409136328745/1377375096842227885
@Niko I added another comment on the PR, it's the wrong way around now
@bsherman implemented exactly as you had it
😂 i'm so sorry, but I had a typo above
I'll reply
feel free to edit the PR lol
or i can
github pairing badge opportunity
good catch @bsherman I had ack'd it already 🙈
I should go to bed but now I'm too excited about my sd PR 😂
sorry i also missed - i was distracted by the dayjob
I feel bad because I typo'd in this chat which created the confusion
the more reviewers, the merrier 🙂
yeah, it's the way it goes...
for future, the way I catch things like this, especially with regex (even simple regex) just copy/paste and run it, it's always so easy to miss something with regex
@M2 @jmac need an additional "approver" review: https://github.com/ublue-os/ucore/pull/262
GitHub
feat: Update install-ucore.sh to include variant_id for countme by ...
Suggestion to close #261 and #202.
btw @Niko if you put
Closes: #261 #202 in the PR description those issues will be auto-closed upon merge.
actually, it'd have to be Closes: #261, Closes: #202thank you both! done!
and @Lorbus , I added closes 261, but i'll quickly add a ucore counter to /countme before i close #202
this should close 202 https://github.com/ublue-os/countme/pull/49
GitHub
add ucore to the growth_global, will be populated over the coming w...
Closes: ublue-os/ucore#202
LGTM
once a system starts reporting, do you know how long it takes to see something in the report?
I think basically a week. the data is weekly. if a single system reports this week, it'll show up in next week's countme data.