Sponsor for DMX - The Context Machine

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Sponsor for DMX - The Context Machine

Juergen Neumann
Hi all!

I would like to file an ITP for DMX - The Context Machine [1], formerly
known as DeepaMehta [2]. As this will be my first project for Debian I
am kindly looking for a sponsor. So far I barely managed to create a
first lintian compliant result [3]. I will be happy to improve. :-)

Thank you very much in advance!

Juergen

[1] https://git.dmx.systems/dmx-platform/dmx-platform
[2] https://www.deepamehta.de/
[3] https://github.com/dmx-systems/dmx-build-deb

--
GnuPG KeyID: CD914C6C
Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C

Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Andrey Rahmatullin-3
On Sat, Apr 04, 2020 at 02:46:26PM +0200, Juergen Neumann wrote:
> Hi all!
>
> I would like to file an ITP for DMX - The Context Machine [1], formerly
> known as DeepaMehta [2]. As this will be my first project for Debian I
> am kindly looking for a sponsor. So far I barely managed to create a
> first lintian compliant result [3]. I will be happy to improve. :-)
Please note thet the usual workflow is:

1. File an ITP.
2. Do the work.
3. Publish the package.
4. Look for sponsors, usually starting with filing an RFS.

See https://mentors.debian.net/intro-maintainers for more details on this
workflow.

Looks like your git repo doesn't contain a source package tree, only some
teemplates for it, you'll need a proper source package, correctly
buildable in a minimal sid chroot, to get it sponsored.
You also need to run lintian on the source package, not just on the binary
ones.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Fabrice BAUZAC-STEHLY-2
In reply to this post by Juergen Neumann
Juergen Neumann writes:

> Hi all!
>
> I would like to file an ITP for DMX - The Context Machine [1], formerly
> known as DeepaMehta [2]. As this will be my first project for Debian I
> am kindly looking for a sponsor. So far I barely managed to create a
> first lintian compliant result [3]. I will be happy to improve. :-)
>
> Thank you very much in advance!
>
> Juergen
>
> [1] https://git.dmx.systems/dmx-platform/dmx-platform
> [2] https://www.deepamehta.de/
> [3] https://github.com/dmx-systems/dmx-build-deb

Hello Juergen,

I'm still quite new to Debian packaging and certainly can't talk for
the Debian project but I'll try to give you some advice nevertheless.
I hope the following advice is correct Debian-wise; sorry if I'm
making mistakes, please correct me in that case.

I can see in the README of dmx-build-deb:

    dmx-build-deb builds Debian packages from DMX binary files and
    loads them into the public repository at DMX Systems.

Debian packages normally build software from source, not binary.  That
is required for your package to be part of Debian proper (the "main"
section).  If that's impossible though, there is the "contrib" section
where such packages can be uploaded.  It is recommended to build from
source whenever possible.

Also, I guess a Debian package should not load anything to some other
repository.

Your debian/README.source is basically a template.  You should either
remove it or write something interesting there.  README.source is the
place where you document specifics of your package with regards to how
it should be built.

debian/control, debian/copyright are templates (@@PACKAGENAME@@,
@@CONFLICTS@@, ...).  It looks like it is instantiated through
.gitlab-ci.yml.  I guess it is OK in principle, but remember that you
have to upload a Debian-compliant source package in any case.

I'm not sure whether a Debian package can be named "dmx-latest"; I
guess it should just be named "dmx".

Debian takes copyright and license information very seriously; if
there is any doubt on the license of some file, it might need to be
removed from the set of packaged files through a +dfsg modification.
Therefore it is highly advised that the license of each source file in
the upstream source code be very clear.  The safest if you can is to
add to each nontrivial source file the copyright line of each
contributor with the years of contributions, and indicate which
license applies to this file (and in particular if it is AGPL3 strict
or "AGPL3 or later"); this is the case for the GNU project.  Many
projects don't do that, which may make it more difficult to be
uploaded to Debian (sometimes a little more, sometimes a whole lot
more).  The clearer the better, and as a bonus it saves a lot of time
to the people who are in charge of verifying the license of the
software: if you can do that then that's the best; if not, try to be
as clear as possible and cross fingers.

It is not mandatory, but it is possible to format debian/copyright
with a machine-readable format [1]

It would be nice to also produce a "-doc" package containing the
documentation [2], so that people with internet connectivity issues
can still read the documentation.

Through .gitlab-ci.yml you auto-generate debian/changelog.  I doubt an
auto-generated changelog can be used if you want your package
integrated in Debian: end users should be able to modify your package
at will, and add what they want to the changelog.

In debian/postinst it looks like a password is stored into
/etc/dmx/config.properties, but I don't see any provision (such as
umask 077) to make sure it is not world-readable before "chmod 750
/etc/dmx".  For you to check...

debian/rules contains comments from the template; you should probably
clean them up.

I don't know debconf, but at what point is the equality between
dmx/initial_admin_password and dmx/initial_admin_password_again
checked?

Once you have built the source package and the binary package(s)
locally, you should run "lintian -EviIL+pedantic" to see if you have
any important things to fix.

One of the first things you need to make clear is how you want to
create your package(s):

- By building the upstream source (main)?  By packaging the upstream
  binary (contrib)?

- How do you organize the packaging files and your workflow for
  creating packages: with origtargz(1), uupdate(1), git-dpm,
  git-buildpackage, something else...?

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[2] https://dmx.readthedocs.io/en/latest/

Hope this helps!

Best regards
--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Andrey Rahmatullin-3
On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY wrote:
> - By building the upstream source (main)?  By packaging the upstream
>   binary (contrib)?
Pre-built binaries are for non-free, not for contrib. Contrib is strictly
DFSG-free.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Fabrice BAUZAC-STEHLY-2
Andrey Rahmatullin writes:

> On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY wrote:
>> - By building the upstream source (main)?  By packaging the upstream
>>   binary (contrib)?

> Pre-built binaries are for non-free, not for contrib. Contrib is strictly
> DFSG-free.

Here the binaries seem to be free software (AGPL3 or GPL3).  Are you sure?

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Andrey Rahmatullin-3
On Sun, Apr 05, 2020 at 12:16:16PM +0200, Fabrice BAUZAC-STEHLY wrote:

> Andrey Rahmatullin writes:
>
> > On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY wrote:
> >> - By building the upstream source (main)?  By packaging the upstream
> >>   binary (contrib)?
>
> > Pre-built binaries are for non-free, not for contrib. Contrib is strictly
> > DFSG-free.
>
> Here the binaries seem to be free software (AGPL3 or GPL3).  Are you sure?
Then what would stop them from being included in main if that was the only
requirement?
There is only one difference between main and contrib: "packages in main
must not require or recommend a package outside of main for compilation or
execution". Do you know about some rebuildability requirements being true
only for main but not for contrib?

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sponsor for DMX - The Context Machine

Juergen Neumann
Hi Andrey and Farbrice,

thank you very much for your feedback and your valuable hints. Yes, the
DMX sources are free software in the public. If in that case, building
from the binaries was ok, it would make things a bit easier on my end.
If not, I can start to work on managing the whole process from source.

Let me know, what you think.

Thx,

Juergen

Am Sonntag, den 05.04.2020, 15:24 +0500 schrieb Andrey Rahmatullin:

> On Sun, Apr 05, 2020 at 12:16:16PM +0200, Fabrice BAUZAC-STEHLY
> wrote:
> > Andrey Rahmatullin writes:
> >
> > > On Sat, Apr 04, 2020 at 11:36:03PM +0200, Fabrice BAUZAC-STEHLY
> > > wrote:
> > > > - By building the upstream source (main)?  By packaging the
> > > > upstream
> > > >   binary (contrib)?
> > > Pre-built binaries are for non-free, not for contrib. Contrib is
> > > strictly
> > > DFSG-free.
> >
> > Here the binaries seem to be free software (AGPL3 or GPL3).  Are
> > you sure?
>
> Then what would stop them from being included in main if that was the
> only
> requirement?
> There is only one difference between main and contrib: "packages in
> main
> must not require or recommend a package outside of main for
> compilation or
> execution". Do you know about some rebuildability requirements being
> true
> only for main but not for contrib?
>
--
GnuPG KeyID: CD914C6C
Fingerprint: C1CC EF1D 1443 7279 72E7 ABDC A2DA 0328 CD91 4C6C