Information for packagers

[ErikReider]

I have no clue how this works in any sort of way so help would be very much appreciated. The main distro would be Arch (due to me primarily using it) and maybe Ubuntu and Fedora (I'll probably need to create a fedora build GitHub Action)

[lexa]

For building Fedora there is already a rpkg spec file: https://github.com/ErikReider/SwayNotificationCenter/blob/main/swaync.rpkg.spec and a copr repo. If you are ok, I could create a Gihub Action to update that copr whenever you push a new version of of SwayNotificationCenter.

You could also push the package in the official Fedora repository, that would be greatly appreciated.

[ErikReider]

I would really appreciate if you could pull it into official Fedora repository though

That would be preferred. Thanks @lexa for maintaining the copr repo :)

[lexa]

That would be preferred.

Sure, but that is rather difficult, especially for such niche package.

[ErikReider]

@lexa Hmmm. Is it possible to change the owner? Would the url change in that case?

[alekseifedotov]

The URL will change if we change the maintainer of the Copr package. I don't think there is such thing as changing the owner on Fedora copr.

[ErikReider]

If you @lexa would be willing to change the maintainer (or any similar option that also changes the URL), I'd be glad to take over it :)

[lexa]

@ErikReider Got really excited about this idea of officially maintained Fedora repo and made a mistake of posting from a wrong account.

I've prepared a PR to add Github Action for updating copr repo automatically: https://github.com/ErikReider/SwayNotificationCenter/pull/148

If you want to take over maintenance over copr, you need to get an account on copr.fedorainfracloud.org, as described in the PR.

[ErikReider]

Didn't I do that? I'll check

[ErikReider]

Should be there if I'm not mistaken:

[lexa]

sorry, overlooked that configuration.

[FilippoBonazziSUSE]

For openSUSE distros, work is ongoing in https://build.opensuse.org/package/show/X11:Wayland/SwayNotificationCenter. Hopefully the package will be in Factory (and then Tumbleweed) soon.

[werdahias]

I started work on a debian package which will make its way into the offical repos and ubuntus soon (tm). I need someone to review my work and upload it, then it should be good to go.

[ErikReider]

I need someone to review my work and upload it, then it should be good to go.

Someone like me or a package maintainer for Debian / Ubuntu?

[werdahias]

@ErikReider a package maintaiber for Debian

[FilippoBonazziSUSE]

FYI: The package is now available in openSUSE Tumbleweed, and can be installed with

sudo zypper install SwayNotificationCenter

[ErikReider]

FYI: The package is now available in openSUSE Tumbleweed, and can be installed with

sudo zypper install SwayNotificationCenter

That's awesome! Never actually thought that this project would take off like it's done :))

[akhiljalagam]

I added this to void-package and waiting for it to be merged into their main repo.
https://github.com/void-linux/void-packages/pull/40099

[ErikReider]

FYI: The package is now available in openSUSE Tumbleweed, and can be installed with

sudo zypper install SwayNotificationCenter

Sorry for the late reply, updated the README to include installation instructions for OpenSUSE users in 345b4ba

[bd-g]

For Arch, it looks like two things need to happen

1) Popularity metrics need to meet those defined in the Trusted User Guidelines, namely, reaching 1% popularity on pkgstats (currently 0.43) or by getting 10 votes on the AUR (currently at 9, likely the easier option).

2) Somehow finding a Trusted User who will adopt the package. Once popularity is met, we could try and contact a few through official channels (mailing lists, IRC, or the forums), or unofficial channels (Reddit, Twitter/Mastodon).

I'm willing to put work into this if we can get one more AUR vote!

[bd-g]

For Arch, it looks like two things need to happen

1. Popularity metrics need to meet those defined in the [Trusted User Guidelines](https://wiki.archlinux.org/title/AUR_Trusted_User_guidelines#The_TU_and_%5Bcommunity%5D,_guidelines_for_package_maintenance), namely, reaching 1% popularity on pkgstats (currently 0.43) or by getting 10 votes on the AUR (currently at 9, likely the easier option).

2. Somehow finding a Trusted User who will adopt the package. Once popularity is met, we could try and contact a few through official channels (mailing lists, IRC, or the forums), or unofficial channels (Reddit, Twitter/Mastodon).

I'm willing to put work into this if we can get one more AUR vote!

In terms of Trusted Users to contact, starting with these three (listed with the current packages they maintain) might be a good idea.

• Jerome Leclanche (jerome@leclan.ch)
  • sway
• Maxim Baz (archlinux@maximbaz.com)
  • sway
  • swaybg
  • swaylock
• Brett Cornwall (ainola@archlinux.org)
  • sway
  • swaybg
  • swayidle
  • swayimg
  • swaylock

[ErikReider]

For Arch, it looks like two things need to happen

1) Popularity metrics need to meet those defined in the Trusted User Guidelines, namely, reaching 1% popularity on pkgstats (currently 0.43) or by getting 10 votes on the AUR (currently at 9, likely the easier option).

2) Somehow finding a Trusted User who will adopt the package. Once popularity is met, we could try and contact a few through official channels (mailing lists, IRC, or the forums), or unofficial channels (Reddit, Twitter/Mastodon).

I'm willing to put work into this if we can get one more AUR vote!

Is it really that "easy"?! Wow! Would I need to modify the PKGBUILD in any kind of way?

[bd-g]

Is it really that "easy"?! Wow! Would I need to modify the PKGBUILD in any kind of way?

tldr; slight change to build pipeline to release artifacts, and including License and Readme in the package release

I'm just googling around, no expert here, just want to see your project included in community :) but it doesn't seem like too big of a change. For example, look at the official PKGBUILD for swayidle, which is in [community]. I see only three differences.

1. Slight difference in source files from builds. For example, when swayidle has a release, there are additional artifacts created, e.g. swayidle-1.8.0.tar.gz{.sig}. These are then directly used in the build process. So we might need to alter our release pipeline to produce these artifacts, and then they would get used by the PKGBUILD as below. .

   source=(
       "https://github.com/ErikReider/SwayNotificationCenter/releases/download/$pkgver/$pkgname-$pkgver.tar.gz"{,.sig}
   )

2. Of course, there are valid pgp keys from the Trusted User - that would get added by the Trusted User who sponsors the project.
3. Adding the License and ReadMe to the package. I would suggest renaming COPYING to LICENSE to follow convention, and then changing the package in PKGBUILD to something like below

   package() {
       DESTDIR="$pkgdir/" ninja -C build install
       install -Dm644 "$pkgname-$pkgver/LICENSE" -t "$pkgdir/usr/share/licenses/$pkgname"
       install -Dm644 "$pkgname-$pkgver/README.md" -t "$pkgdir/usr/share/doc/$pkgname"
   }

[ErikReider]

Sounds easy enough! 🤜🪵

[bd-g]

A couple notes:

1. I'm not sure the best way to produce the signature file on the releases, but I bet the Trusted Users are well versed in that. Could ask them when asking for sponsorship of the package?

2. Running namcap on the PKGBUILD has this output. Can we remove these dependencies for just arch? Not sure if they are old dependencies or just needed for Fedora, Debian, etc. If you're fine removing them for just the arch build, I could push another commit to #200

   swaync W: Dependency included and not needed ('gobject-introspection')
   swaync W: Dependency included and not needed ('libgee')

Other than that, I think we could just reach out now to the three Trusted Users I listed above. Do you want to do that @ErikReider since it is your package? Great job by the way!

[ErikReider]

I wonder why libgee and gobject-introspection aren't needed. They shouldn't be provided by any other of the dependencies right?

I can reach out to some of them. I'll just need to find some time to do it 😅

[MrPenguin07]

Someone seems to keep you updated for Gentoo in the guru (semi-official) overlay, currently serving v0.9.0

I made myself a -9999 ebuild for master git, as this is where the action is... anyone else interested holla, otherwise I may see if any maintainer interested in adding it.

[ErikReider]

A heads up: #352 adds sassc as a dependency

[FilippoBonazziSUSE]

Thanks for the heads up, very much appreciated. If you can make sure to explicitly mention this in the release notes once this is released, we can adjust the packaging.

[ErikReider]

Also, gvfs is a new dependency to get MPRIS covers to work: #310

[ErikReider]

Also, just as a safety valac/vala >= 0.56 but shouldn't be that important for your packages

327

[ErikReider]

New Release! I added the new dependencies to the release notes :)

[MrPenguin07]

New Release! I added the new dependencies to the release notes :)

Appreciate the heads up re. deps.

Gentoo users may check out my -9999 live git ebuild here; mrpenguin ebuild overlay

[FilippoBonazziSUSE]

Nice one!

A question regarding sassc. Does it mean that we need to change our downstream css files into something else?

[ErikReider]

Nice one!

A question regarding sassc. Does it mean that we need to change our downstream css files into something else?

It's just used to compile the scss file -> regular css so it's only used at build-time. So no, regular css styles work as usual :)