adding Timekpr-nExT into Debian (edu?)

Replied to e-mail about inclusion into Debian. Let's see whether I need to do anything further.

You need to create a RFP request, <URL: https://wiki.debian.org/WNPP >...
It is the first step for getting a package into Debian.

You'll also need to "push" the guys...

Hello Eduards and Sim,

Thank you for writing and maintaining such a wonderful and much needed software program, and thank you for proposing its inclusion in Debian.

I'm a Debian developer with three young kids, and have been in search of a solution to limit their computer screen time under Linux, so I am quite interested in uploading timekpr-next to Debian.

Since Timekpr-nExT is written in Python, I think it is most appropriate to maintain the Debian packaging with the Python Applications Packaging Team (PAPT) (https://wiki.debian.org/Teams/PythonAppsPackagingTeam), eventually at https://salsa.debian.org/python-team/applications/timekpr-next (to be created).

But first, I'll need to file an ITP or "Intent to Package" bug report to WNPP.
The bulk of the packaging work has been done by Eduards, so thank you very much!
The adjustment to the debian/* are mostly for compliance with the latest Debian Policy 4.5.0.
Oh, and to resolve Lintian warnings and errors where necessary.

I'll report back when I have more information.

Cheers,

Anthony Fok

Debian bug to WNPP (Work-Needing and Prospective Package) filed:

ITP: timekpr-next -- Keep control of computer usage

https://bugs.debian.org/956939

Anthony, I'm about to release a new version 0.3.x in a one week's time (most likely). I saw that in that bug report You mentioned version 0.2.13. Does the version matter in this case or it's about package as such?

P.S. Couple of days ago I was testing this in Debian Mint edition as well, working as expected.

Hi Anthony,

thank you for taking this important task! Debian, and all its derivates,
indeed need timekpr-next.

All credits go to Eduards, not me. I've just suggested to include it to
Debian, that's it.

Best regards!

On Fri, 2020-04-17 at 01:52 +0000, Anthony Fok wrote:
> Your question #685282 on Timekpr-nExT changed:
> https://answers.launchpad.net/timekpr-next/+question/685282
>
> Anthony Fok proposed the following answer:
> Hello Eduards and Sim,
>
> Thank you for writing and maintaining such a wonderful and much needed
> software program, and thank you for proposing its inclusion in Debian.
>
> I'm a Debian developer with three young kids, and have been in search of
> a solution to limit their computer screen time under Linux, so I am
> quite interested in uploading timekpr-next to Debian.
>
> Since Timekpr-nExT is written in Python, I think it is most appropriate
> to maintain the Debian packaging with the Python Applications Packaging
> Team (PAPT) (https://wiki.debian.org/Teams/PythonAppsPackagingTeam),
> eventually at https://salsa.debian.org/python-team/applications/timekpr-
> next (to be created).
>
> But first, I'll need to file an ITP or "Intent to Package" bug report to WNPP.
> The bulk of the packaging work has been done by Eduards, so thank you very much!
> The adjustment to the debian/* are mostly for compliance with the latest Debian Policy 4.5.0.
> Oh, and to resolve Lintian warnings and errors where necessary.
>
> I'll report back when I have more information.
>
> Cheers,
>
> Anthony Fok
>

Hi Eduards,

I'll likely upload 0.2.13-1 initially, probably as soon as today. Being a new package uploaded to the Debian archive, timekpr-next will be in the NEW queue https://ftp-master.debian.org/new.html, pending manual verification and approval by the Debian FTP Masters, before being available for download from Debian. This process could take as little as one week, or could be one full week or more.

The Debian FTP Masters are especially diligent to ensure the package is DFSG compliant, and thus they are carefully checking to ensure all copyright attributions are accounted for. So, even though you have rewritten Timekpr-nExT from scratch, there are a couple of SVG files as well as debian/timekpr.init which list Savvas Radevic as the author; and a handful of the resource/locale/*/LC_MESSAGES/timekpr.po files has this line added on top: "Copyright (c) 2019 Rosetta Contributors and Canonical Ltd 2019", so I am currently documenting all these in debian/copyright using the new debian/copyright format ( https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ ).

I have total trust of your software: You've been keeping it very well-maintained over the years, so I'm sure it runs fine on Debian sid. :-D My main concern at the moment is to "get the foot in the door" and make sure I don't miss anything in debian/copyright, as I have had some initial uploads rejected by the FTP masters before.

Once the package is accepted into Debian, then we are free to upgrade to the latest 0.3.x or newer versions and upload as often as we want. I have added a debian/watch file which allows Debian to track and notify us when a new version is available, via tracker.debian.org, udd.debian.org, or the uscan command, etc. You are also welcome to become a Debian Maintainer and thus uploader of the timekpr-next package to Debian too!

It is probably too late to make it for the Ubuntu 20.04 LTS (focal) release, but after that, i.e. once the Ubuntu 20.10 cycle begins, Debian packages will resume being pulled into Ubuntu (universe) automatically, so Ubuntu will routinely get the latest timekpr-next releases too.

Please feel free to keep your PPA going for users of Ubuntu 20.04 LTS, 19.10, 19.04 etc. for some time yet.
Our upload to Debian will directly benefit Debian 11+ and Ubuntu 20.10+ but not users of older releases.
Older OS versions won't see timekpr-next unless they add your PPA,
or unless we were to try to backport timekpr-next ( https://wiki.ubuntu.com/UbuntuBackports )
but that is something I have never done and not ready to venture into yet.

I'll write more once I have the git repository on Salsa set up, and the package uploaded.

Thanks explanation and useful insight of the process, I'll try to clear things up, hopefully.

timekpr.init - not needed at all, somehow I left that file in, but I'll remove that in next release - it should have not been here in the first place :)
About PO files: I used "Translations" section of the launchpad, therefore when translations were done via e-mail by some users and myself, I uploaded them to translations section, when files are downloaded from there (some users contributed to translations via lauchpad), this line is added, I don't know what to do with that legally, it's just there.
SVG files - yes, I'm no artist, some files I have changed and some are left as they were from previous project.

Hope this helps.

Thank you Eduards!

No worries about copyright information at all. All I need to do is document them as they are, so, for example, I am adding the sections like the following to debian/copyright:

 Files: resource/icons/timekpr*.svg
 Copyright: © 2005 AJ Ashton
            © 2017 Anomie
            © 2008 Savvas Radevic <email address hidden>
            © 2018–2019 Eduards Bezverhijs <email address hidden>
 License: CC-PDDC
  Creative Commons Public Domain Dedication and Certification
  .
  Copyright-Only Dedication (based on United States law) or Public Domain
  Certification
  .
  ...........

 Files: resource/locale/fr/LC_MESSAGES/timekpr.po
        resource/locale/hu/LC_MESSAGES/timekpr.po
 Copyright: (c) 2019 Rosetta Contributors and Canonical Ltd 2019
 License: GPL-3.0+
 Comment:
  These files are distributed under the same license as the timekpr-next package.

(I bet Launchpad's translation tool Rosetta added that copyright header itself, so I am listing these files with that header in debian/copyright just to be safe.)

Debian's FTP masters' job is to make sure we packagers don't miss anything, i.e. the information in debian/copyright matches what are in the source files to the best of our ability. :-)

If that is fine, I can issue another 0.2.13 release which I just repackage the project without timekpr.init file.

Another thing that came into my mind: gnome is going to deprecate the system notification area altogether for third parties (clock, network, calendar, ... e.g. built-in stuff will the there, I suppose), so in current solution, which uses AppIndicator, icon for timekpr will not be visible at all.
Currently it requires an extension for icon to be visible in the first place. All of the rest DEs will work fine, because they still support AppIndicator or legacy StatusIcon (timekpr supports both currently).
I don't know whether this is an issue.

What are Your thoughts?

> If that is fine, I can issue another 0.2.13 release which I just repackage the project without timekpr.init file.

No need at all. I'm past that stage, and the addition or removal of timekpr.init does not affect my debian/copyright file. ;-)
Feel free to take it out in 0.3.x, but please leave 0.2.13 as is.

> Another thing that came into my mind: gnome is going to deprecate the system notification area
> ...
> I don't know whether this is an issue.
> What are Your thoughts?

I do not yet know either because I have not actually started running timekpr-next yet. :-D
But one possible solution is to package that extra extension for Debian too, and have timekpr-next Depends on it.

Worry not, it is not a one-time upload. Rather, it is the first of many future uploads. It is an iterative process, and we have at least 6 more months till the next release (Ubuntu 20.10). To give you an idea how frequently we update packages we care about, here is the Debian changelog of hugo the static website generator:

https://metadata.ftp-master.debian.org/changelogs//main/h/hugo/hugo_0.69.0-1_changelog

So yes, we will have lots of chance to fix any issues in future timekpr-next releases.

By the way, I changed debian/source/format to say "3.0 (quilt)" because it is not a Debian-only package and thus no need to be "native", and that allows us to have 0.2.13-1, 0.2.13-2, 0.2.13-3 etc. if needed for fixing packaging bugs. ;-)

Thank you very, very much Anthony! You did it with the speed of light!
Once timekpr-next is accepted and entered Debian, maybe you, Anthony, know where to inform broader public on Debian's information channels (mailing lists, IRC, blogs or whatever). I suppose there will be interested folks who might even contribute to the code of Timekpr-next and help Eduards in the long run!

Thanks to both of you!

Hurray! Timekpr-nExT was accepted into Debian two days ago:

https://tracker.debian.org/pkg/timekpr-next
https://packages.debian.org/sid/timekpr-next

To do:
* Make a source-only upload of 0.2.13-2 so it can enter testing (bullseye)
* Package v0.4.0

I'm not good at "public announcement", but please feel free to do so. :-)

Anthony - thank you very much for the upload to Debian!
Eduards - thank you for the Timekpr-nExT! I use it daily with my kids - so
much less stress!!!

On Fri, Jul 10, 2020 at 7:05 PM Anthony Fok <
<email address hidden>> wrote:

> Your question #685282 on Timekpr-nExT changed:
> https://answers.launchpad.net/timekpr-next/+question/685282
>
> Anthony Fok posted a new comment:
> Hurray! Timekpr-nExT was accepted into Debian two days ago:
>
> https://tracker.debian.org/pkg/timekpr-next
> https://packages.debian.org/sid/timekpr-next
>
> To do:
> * Make a source-only upload of 0.2.13-2 so it can enter testing (bullseye)
> * Package v0.4.0
>
> I'm not good at "public announcement", but please feel free to do so.
> :-)
>
> --
> You received this question notification because you asked the question.
>

Thanks, it seems that Ubuntu already imported that into Groovy.

The big question for me is: what I have to do next?
I see that Anthony already imported 0.4.0 version into debian (to which I just made instructions for Fedora / openSUSE :-D ).

I'll try to fix up things You patched / changed in Debian, so there will be no patches needed.
But besides that is there anything I have to do?

> I'll try to fix up things You patched / changed in Debian, so there will be no patches needed.

Thanks! You might like to refer to https://salsa.debian.org/python-team/applications/timekpr-next for the commits to the debian/ directory.

> But besides that is there anything I have to do?

Thanks for asking! I would recommend the following:

1. https://tracker.debian.org/pkg/timekpr-next lists 2 warnings from "AppStream hints"
    about "no-metainfo": This software component is missing a MetaInfo file to provide metadata about it.
    Please see https://appstream.debian.org/sid/main/issues/timekpr-next.html for details.

    I think the issue manifests in GNOME Software Center.
    For example, searching for "timekpr" currently finds two entries:
     - "(SU) Timekpr Control Panel (superuser mode)" (from timekpr-admin-su.desktop)
     - "Timekpr Control Panel" (from timekpr-admin.desktop)
    and neither is ideal.

    According to https://freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent ,
    the issue can be solved by providing a MetaInfo file called /usr/share/metainfo/timekpr-next.metainfo.xml

    It would be great if you could look into this when you have time.

2. Please consider fixing the following Lintian warnings and info:

W: timekpr-next: icon-size-and-directory-name-mismatch usr/share/icons/hicolor/64x64/apps/timekpr-client.png 128x128
W: timekpr-next: icon-size-and-directory-name-mismatch usr/share/icons/hicolor/64x64/apps/timekpr.png 128x128
W: timekpr-next: no-manual-page usr/bin/timekpra
W: timekpr-next: no-manual-page usr/bin/timekprc
W: timekpr-next: no-manual-page usr/bin/timekprd
I: timekpr-next: desktop-entry-contains-encoding-key usr/share/applications/timekpr-admin-su.desktop:3 Encoding
I: timekpr-next: desktop-entry-contains-encoding-key usr/share/applications/timekpr-admin.desktop:3 Encoding
I: timekpr-next: desktop-entry-lacks-keywords-entry usr/share/applications/timekpr-admin-su.desktop
I: timekpr-next: desktop-entry-lacks-keywords-entry usr/share/applications/timekpr-admin.desktop
I: timekpr-next: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/timekpr.service
I: timekpr-next: systemd-service-file-missing-documentation-key lib/systemd/system/timekpr.service

You may use the lintian-info command to get detailed information of the above.

3. Make README.md more descriptive.

    You know how on GitHub and GitLab many projects have a README.md
    which gives detailed description of the project, sometimes with installation instruction, etc.
    in Markdown and which gets nicely displayed by GitHub / GitLab?

    git.launchpad.net doesn't display README.md content unfortunately,
    but it would still be nice to have something that better describe the project.

    I think adding the URL https://launchpad.net/timekpr-next
    as well as the description you have written on that page
    would be a great start! :-)

Thanks for answer.

I'm already on 1. Recently I tried to make package for Fedora / openSUSE and borrowed the file created for older timekpr version (albeit legacy version), now it's almost done with the new version.
To me it seems that I need to create 2 appdata files that references the correct launcher for both (which will be almost the same).

About service and stuff, I'll look into it.

About README, yes I'll try to optimize the description in project page and put the same in README.

But I'll release these fixes along some additions to functionality, which I'm implementing slowly based on user suggestions. So that will come with next version (I dunno when :) ).

That's awesome! Thank you Eduards!

> But I'll release these fixes along some additions to functionality, which I'm implementing slowly
> based on user suggestions. So that will come with next version (I dunno when :) ).

For sure! All great things take time, so no hurries at all.

About the MetaInfo file: it turns out that there is online AppStream MetaInfo Creator
which will generate one for you!
It is mentioned in the docs, but I thought I'd mention it so that you don't miss it,
as creating one from scratch manually looks way too tedious and complicated for me. :-)

 * https://www.freedesktop.org/software/appstream/metainfocreator/#/

Oh, and I think you only need ONE single MetaInfo file.
You don't need to modify your existing *.desktop files.
The MetaInfo file is for GNOME Software Center, more like an AppStore listing,
with screenshot and everything,
for the purpose of helping users find your software.

Right now, AppStream (GNOME Software Center) is being a "smart ass"
and "stole" data from your launcher *.desktop files, which it really shouldn't have had.
But it is rather intriguing to me how AppStream did that, as if it had automatically
scoured the new timekpr-next package in Debian archive and updated an online
database somewhere... Hmm...

Cheers!