Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Information for packagers #144

Open
ErikReider opened this issue Jul 11, 2022 · 34 comments
Open

Information for packagers #144

ErikReider opened this issue Jul 11, 2022 · 34 comments
Labels
help wanted Extra attention is needed packaging Packaging issues / suggestions

Comments

@ErikReider
Copy link
Owner

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)

@ErikReider ErikReider added help wanted Extra attention is needed packaging Packaging issues / suggestions labels Jul 11, 2022
@lexa
Copy link
Contributor

lexa commented Jul 11, 2022

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
Copy link
Owner Author

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
Copy link
Contributor

lexa commented Jul 11, 2022

That would be preferred.

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

@ErikReider
Copy link
Owner Author

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

@alekseifedotov
Copy link

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
Copy link
Owner Author

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 pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 20, 2022
lexa pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 20, 2022
lexa pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 20, 2022
lexa pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 20, 2022
lexa pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 20, 2022
@lexa
Copy link
Contributor

lexa commented Jul 20, 2022

@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: #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.

lexa pushed a commit to lexa/SwayNotificationCenter that referenced this issue Jul 23, 2022
ErikReider pushed a commit that referenced this issue Jul 23, 2022
Co-authored-by: Aleksei Fedotov <[email protected]>
@ErikReider
Copy link
Owner Author

Didn't I do that? I'll check

@ErikReider
Copy link
Owner Author

Should be there if I'm not mistaken:
image

@lexa
Copy link
Contributor

lexa commented Jul 23, 2022

sorry, overlooked that configuration.

@FilippoBonazziSUSE
Copy link

FilippoBonazziSUSE commented Aug 23, 2022

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
Copy link
Contributor

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
Copy link
Owner Author

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
Copy link
Contributor

@ErikReider a package maintaiber for Debian

@FilippoBonazziSUSE
Copy link

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

sudo zypper install SwayNotificationCenter

@ErikReider
Copy link
Owner Author

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
Copy link

I added this to void-package and waiting for it to be merged into their main repo.
void-linux/void-packages#40099

@ErikReider
Copy link
Owner Author

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
Copy link
Contributor

bd-g commented Jan 11, 2023

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
Copy link
Contributor

bd-g commented Jan 11, 2023

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.

@ErikReider
Copy link
Owner Author

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
Copy link
Contributor

bd-g commented Jan 13, 2023

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
Copy link
Owner Author

Sounds easy enough! 🤜🪵

@bd-g
Copy link
Contributor

bd-g commented Jan 13, 2023

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 Add COPYING and README to pkgbuild install #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
Copy link
Owner Author

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
Copy link
Contributor

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
Copy link
Owner Author

A heads up: #352 adds sassc as a dependency

@FilippoBonazziSUSE
Copy link

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
Copy link
Owner Author

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

@ErikReider
Copy link
Owner Author

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

#327

@ErikReider ErikReider pinned this issue Dec 15, 2023
@ErikReider
Copy link
Owner Author

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

@ErikReider ErikReider changed the title Packaged in distro repos Information for packagers Feb 10, 2024
@MrPenguin07
Copy link
Contributor

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
Copy link

Nice one!

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

@ErikReider
Copy link
Owner Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed packaging Packaging issues / suggestions
Projects
None yet
Development

No branches or pull requests

8 participants