Bug#780606: Bug#792101: Done / Not Done

[Stefan Monnier]

> Just to be clear, this is not in Debian main, it is in contrib.

Thank you very much for that.  Happily running it on my BananaPi here now.
What is its status exactly: I see "contrib" described as "free but
depending on non-free code", but it's not clear exactly what non-free
code it relies on.

I see also that it's now in "unstable" (tho not yet in "testing",
apparently) and compiled for various architectures including the armhf
I'm using, which is great.  Until those JS packaging issues are
resolved, do you plan on keeping the package uptodate on
a regular basis?


Stefan

Bug#780606: Bug# [...]

[PICCORO McKAY Lenz]

2017-09-19 20:31 GMT-04:00 Michael Lustfield :

> To be blunt, I struggled very hard to follow the text you wrote..
> especially
> true for the github bug report. I have done my best to understand what the
> intended message was, but if I misunderstood then I apologize in advance.
>
sorry for my english and you indestand almost all

> On Mon, 18 Sep 2017 14:55:12 -0400
> PICCORO McKAY Lenz  wrote:
> > 1) makde a package that only use the downloaded sources that ship all
> > depends
>
> This sounds like you're suggesting that we actually make use of content
> within
> the vendor/ directories. If that's the case then we'll need to discuss
> DFSG in a
> bit more depth because this will cause a clear violation.In fact, I'm
> aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
>
right but only in a part.. i mean made the package and progressl
Make the package, and progressively go removing or adding dependencies and
objects according to what is going to work, for example in the case of
dependency: if today xxx.yyy is provided then in the already made gogs
package removing the xxx.yyy reference build in source, about the DFSG can
be check as being used it, due some maybe drop important funtionality

Each dependency needs to be individually packaged and reviewed for DFSG
> standards. This work has revealed a lot of issues that have now been
> resolved
> (in Gitea). Unfortunately, the author/owner of gogs has no interest in
> adopting
> these changes. (details need not be repeated here)
>
I also noted that gitea solved some problems inherints from gogs, but i
also noted that on every new releaqse as they introduced fixeds, same
amount of issues are newer due new features or bigfixeds itself

this can be a problem.., the differences between gogs and gitea are more
deep in development model but in funtionallity are pretty same..


> > the other way its that do not make usage of thos depends pacakges that
> > change too many in the time!
> I didn't follow this at all.
>
gogs and gitea used a specific commits of that depends.. and taking in
consideration that packages on debian are "too older or too newer" respect
the necesary..
so then, maybe we need a special packages mades for those? sound like a
duplication of work, but some examples maybe are owncloud and roundcube


> packaging I have been working on offers a gogs meta package that selects
> gitea.
> This does not mean gitea is pretending to be gogs. It is a
> relatively-compatible alternative.
>
i dont think this would be a good idea. its better a good made separation..
no relation


> gogs are focused on simplicity, no new features and only security fixeds
> > gitea are focused on new features and changes too many ..
>
> This is very much *not* the difference between the two. Gitea is a fork of
> gogs
> that was created for entirely different reasons. Many of those reasons are
> why
> gogs is not likely to ever exist in Debian repos.
>
i already know about the problem that raised the fork of gitea.. but gitea
are not a separate project different rom gogs.. the differences between
funtionalities are few, but in development are too many...


> Conforming to Debian policy does not come later, it comes first. Until I
> have a
> proper Debianized package, I will not release Gitea into Debian. I /do/
> however, have a lot of progress made and only a few more new dependencies
> that
> need to pass through NEW.
>
as i mention, to se real progress and funtionality (and if some ot the
current depends are not fit) we suggest Make the package, and progressively
go removing or adding dependencies and objects according to what is going
to work, for example in the case of dependency: if today xxx.yyy is
provided then in the already made gogs package removing the xxx.yyy
reference build in source, about the DFSG can be check as being used it,
due some maybe drop important funtionality
so you can made all of then in a personal repository in alliot or in
opensuse build service--


> If you would like to help, check out the "(un)reproducible" column here:
> https://udd.debian.org/dmd/?michael%40lustfield.net#versions

the complete log need DH_VERVOSE=1 due the test fail does not have a good
trace... the debug output only had pointer addresses, i cannot setup better
trace..

seems are realted to 64 bit addresses, so i disable the checks and try to
reproduce with the included in gogs, and does not able to reproduce.. due
in the sources only 64 bit adreses are used--

take in consideration that amount of go developer used 64bit by default, so
more i386 setups are need, but current debian does not fit my need on i385
(too many req) so i used squeeze and in this setup are running well gogs..
gitea does not!


> --
> Michael Lustfield
>

Bug#780606: Bug# [...]

[Michael Lustfield]

To be blunt, I struggled very hard to follow the text you wrote.. especially
true for the github bug report. I have done my best to understand what the
intended message was, but if I misunderstood then I apologize in advance.


On Mon, 18 Sep 2017 14:55:12 -0400
PICCORO McKAY Lenz  wrote:
> the insane amout of dependences make the work of this package a hard made..
> 
> but a way to do its:
> 
> 1) makde a package that only use the downloaded sources that ship all
> depends

This sounds like you're suggesting that we actually make use of content within
the vendor/ directories. If that's the case then we'll need to discuss DFSG in a
bit more depth because this will cause a clear violation.

In fact, I'm aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
and some of it never will. If this is something you're not equally aware of, I
would encourage you to review the source code within a gitea/gogs release.

Each dependency needs to be individually packaged and reviewed for DFSG
standards. This work has revealed a lot of issues that have now been resolved
(in Gitea). Unfortunately, the author/owner of gogs has no interest in adopting
these changes. (details need not be repeated here)

> 2) in the way the depends get packaged in debian, so make it depends on gogs

I do not believe we will ever see Gogs made available within Debian, at least
not given present-day circumstances.

Regardless, it would be woefully inappropriate for a gitea package to depend on
a gogs package to find build dependencies. Besides, the two have different
dependencies (gitea requires more because of more features).

It could be considered fortunate that the packaging I've done for gitea
dependencies is available for gogs. If gogs ever becomes a suitable candidate
for inclusion in Debian, there will likely be a relatively complete set of
dependencies already in place.

> the other way its that do not make usage of thos depends pacakges that
> change too many in the time!

I didn't follow this at all.


On Mon, 18 Sep 2017 15:08:21 -0400
PICCORO McKAY Lenz  wrote:

> Debian packaging pretend to made a simple gogs virtual package provided by
> gitea..
> 
> the gitea package roadmap pretend to separate from gogs, and are complety
> different..

I don't understand the usage of "pretend" in this context. The current
packaging I have been working on offers a gogs meta package that selects gitea.
This does not mean gitea is pretending to be gogs. It is a
relatively-compatible alternative.

I have not decided if I will keep this or not, but I consider worrying about it
to be about the lowest thing on my priorities list.

> gogs are focused on simplicity, no new features and only security fixeds
> gitea are focused on new features and changes too many ..

This is very much *not* the difference between the two. Gitea is a fork of gogs
that was created for entirely different reasons. Many of those reasons are why
gogs is not likely to ever exist in Debian repos. 


>>> < re: your github bug report >

Conforming to Debian policy does not come later, it comes first. Until I have a
proper Debianized package, I will not release Gitea into Debian. I /do/
however, have a lot of progress made and only a few more new dependencies that
need to pass through NEW.

If you would like to help, check out the "(un)reproducible" column here:
https://udd.debian.org/dmd/?michael%40lustfield.net#versions

Those issues need to be resolved before introducing additional packages into
Debian. Additional dependencies are needed for gitea.

-- 
Michael Lustfield