2017-09-19 20:31 GMT-04:00 Michael Lustfield <michael@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 allOn Mon, 18 Sep 2017 14:55:12 -0400
PICCORO McKAY Lenz <mckaygerhard@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 progresslMake 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 funtionalityEach 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 itselfthis 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 roundcubepackaging 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 funtionalityso 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