The phrase, “Imported from arch”, means Arch’s core (vs AUR), correct?
If a package is imported directly from Arch, why would a Manjaro user need to request an update? Wouldn’t the package be automatically updated and go through the Manjaro cycle of Unstable, Testing, Stable.
Regarding #2
These updates would be packages from AUR, git, sourceforge or other?
For example, take tzclock (pacman -Si tzclock), it is in the community repo, version 4.2, and the packager is @manjaro.
By happenstance, I saw the tzclock news, “25/feb/2022: current version is 4.3”. It is 4.3 in the AUR. Using branch-compare, it is 4.2 in Unstable, Testing, and Stable. Will Manjaro update this package in the future without any user notification?
In general
If the packager is neither a @arch id or @manjaro id, what does that mean for the package and future updates? I think I counted 37 different domains, including “Unknown Packager” and “Xyne” in the Manjaro sync repository.
This thread is here to request updates for packages that are in the official repositories of Manjaro and that are imported directly from Arch Linux 12.
AUR has nothing to do with it. Is Arch linux: core, community, extra and multilib.
Some have overlay packages, some have less dependencies and can be pushed right away to stable, some might have security fixes, so, someone from the team has to trigger those updates manually so the mirrors get updated. At least that is how i understand it.
That package is maintained by @linux-aarhus … So you could ask to be updated in
Care to give exact examples? The thing is:
So, would be interesting to know either you rebuild some packages by yourself, or what exact packages you notice to have the Unknown Packager …
Yes. However, we do have some packages in the Manjaro repos that we’ve imported from the AUR. Either that or we packaged it first, then someone added it to the AUR later.
A security fix may need to be pushed to all branches.
The 4.3 update is now in the unstable branch.
All Manjaro packagers have a Manjaro email address. Not all Arch packagers do like Xyne.
One of our packagers forgot to do that awhile back, but it has been remedied since.
community disable-tracker
community maia-console
community manjaro-lxde-config
community manjaro-lxde-desktop-settings
community manjaro-lxqt-theme-arc-maia
community manjaro-lxqt-theme-kvflatred
community manjaro-openbox-config
community manjaro-openbox-desktop-settings
community manjaro-users-artwork-wallpapers
community norse-theme
multilib lib32-kmod
Malformed email on Packager
extra manjaro-artwork-extra
extra manjaro-artwork-icons
extra manjaro-artwork-openbox
community le3cell-artwork-wallpapers
community manjaro-circle-icons
extra plymouth-theme-manjaro-very-elegant
community asunder
I understand the reason for the email obfuscating. It is probably more historical, because on newer packages it isn’t.
I think I’ll just go with if a package is out of date and isn’t in unstable, ask on the forum :-). If it is in unstable (use manjaro branch compare), just let the package go through the stages.