also the behaviour explained at the end of my previous mail* was apllied perfectly to the KDE4 and KDE3 packages! in the past... for squeeze, etch and sarge*
if as progress of depends and policy analisis progress, users like me we can test in the way aditions or remotions was made over the main objetiv, the gitea/gogs package.. Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-09-20 13:49 GMT-04:00 PICCORO McKAY Lenz <mckaygerh...@gmail.com>: > 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 >> > >
