2017-09-19 20:31 GMT-04:00 Michael Lustfield <mich...@lustfield.net>:

> 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 <mckaygerh...@gmail.com> 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
>

Reply via email to