search

Borim7 / radio-tray

RadioTray a simple music streaming player
Other
5 stars 0 forks source link

Get radiotray back into offical repo #7

Open Borim7 opened 3 years ago

Borim7 commented 3 years ago

Some information on how to get radiotray back into debian repository

List of sponsor teams: https://wiki.debian.org/Teams/#Packaging_teams

candidates

Tasks

Apply debian patches:

Find a sponsor

Reason of removal

https://ftp-master.debian.org/removals-2020.txt

[Date: Sat, 07 Mar 2020 03:15:43 +0000] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

 radiotray |    0.7.3-6 | source, all
Closed bugs: 953209

------------------- Reason -------------------
RoQA; Depends on pygtk, dead upstream, unmaintained
----------------------------------------------
Also closing bug(s): 687007 725614 763396 783452 783454 849086 885507 938329
Also closing WNPP bug(s):

Old Debian Bugs:

paravoid commented 3 years ago

Thank you for reviving radiotray!

I'd start by:

If you are unable to find a sponsor through mentors, I'd be happy to look into it myself (I am a Debian Developer). Feel free to reach out to me at (my GitHub username) at debian.org.

Borim7 commented 3 years ago

Thanks for the hints, this looks like a plan ^^

Ideally debian/ should not be part of the upstream repository, although the tooling has advanced enough to ignore it.

When the debian folder should not be part of an upstream project, what is the recommended place for the files needed to build a debian package?

paravoid commented 3 years ago

Unfortunately there is no "great" answer. Debian's Upstream Guide has this to say:

Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on Debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).

You could keep it in a separate branch (e.g. debian/sid), and effectively use a native git git-buildpackage workflow. The downside of this is that other Debian contributors would not be able to make commits to the project (but contributors to the upstream repo could). An alternative would be to keep it in a branch in an entirely separate repository hosted in Debian's GitLab (salsa.debian.org). Finally, a perhaps easy alternative would be to keep an example debian directory in this repository, but strip it from any release tarballs that you make.

Borim7 commented 3 years ago

Finally, a perhaps easy alternative would be to keep an example debian directory in this repository, but strip it from any release tarballs that you make.

This approach is already used. The source tarball generated during building the radiotray package does not contain the debian folder. The problem is that github generate the tarball automatically as an exact copy of the git repository.

During my first release I have tried to add the debian package to the release, but github blocked it. Since this I had focused to get radiotray working and kept github as it is. Currently I simple do not know how to change this github behaviour.

Updating the package to target Debian sid (debhelper 13, python3.9, pybuild etc.) - if possible, get rid of cdbs and target a dh-only package (should be trivial)

I think cdbs is not used for creating the radiotray package. It is only listed in the control file, because it was listed before and I was not sure for what it is used. Building the debian package works without cdbs in the control file and I did not find any reference to cdbs, except the readme and control file. So I guess the dependency can be removed.

Also is pybuild already used for creating the debian package.

Borim7 commented 1 year ago

Asking packaging teams lead to no reply. Try now directly via Debian Mentor: https://mentors.debian.net/intro-maintainers/

dev-rke commented 1 year ago

@Borim7 I read all the things you already did to publish the application again - thanks for your effort!

When reading https://mentors.debian.net/sponsors/ they mentioned some should try to join a packaging team first - propably it will be easier to be mentioned there. When looking at https://wiki.debian.org/Teams/#Packaging_teams if found the https://wiki.debian.org/Teams/PythonTeam Did you already asked there if they may support sponsoring?

Borim7 commented 1 year ago

Yes I have already asked the PythonTeam but did not get any response. I got little feedback on the ITP issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031899

Sadly not the hoped kind of feedback

dev-rke commented 1 year ago

Yes, i already saw the feedback. As i was not able to find a ticket for the packaging teams, propably the ticket already has been closed or is lost? Maybe the packaging teams were not able to review your request. So i'd recommend to give it another try asking the python packaging team. What do you think?

calculusultra commented 4 months ago

Thanks for reviving this app. Installed it today on Debian Testing, everything works smoothly. I also could re-use my old radiotray bookmarks list. I only had to install an old package from buster-oldstable, which is "gir1.2-appindicator3-0.1". Any progress on the integration into the official Debian repos?