Debian Bug report logs - #780606
ITP: gitea -- A painless self-hosted git service.

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Onur Aslan <onur@onur.im>

To: submit@bugs.debian.org

Subject: ITP: gogs -- self hosted Git service written in Go

Date: Mon, 16 Mar 2015 18:29:27 +0200

[Message part 1 (text/plain, inline)]

Package: wnpp
Severity: wishlist
Owner: Onur Aslan <onur@onur.im>

* Package name    : gogs
  Version         : 0.5.13
  Upstream Author : Jiahua Chen <u@gogs.io>
* URL             : http://gogs.io/
* License         : MIT
  Programming Lang: Go
  Description     : self-hosted Git service wrintte in Go

The goal of this project is to make the easiest, fastest, and most
painless way to set up a self-hosted Git service. With Go, this can be
done via an independent binary distribution across ALL platforms that Go
supports, including Linux, Mac OS X, and Windows.

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 780606@bugs.debian.org (full text, mbox, reply):

From: Onur Aslan <onur@onur.im>

To: 780606@bugs.debian.org

Subject: RFP: gogs -- self hosted Git service written in Go

Date: Tue, 16 Jun 2015 12:30:00 +0300

Control: retitle -1 RFP: gogs -- self hosted Git service written in Go
Control: noowner -1

gogs have insane dependencies and gogs only works when dependencies met
with a specific commit. I don't think it's even possible to make a
official Debian package for gogs atm.

Message #59 received at 780606@bugs.debian.org (full text, mbox, reply):

From: PICCORO McKAY Lenz <mckaygerhard@gmail.com>

To: 780606@bugs.debian.org

Subject: a way to going to package

Date: Mon, 18 Sep 2017 14:55:12 -0400

[Message part 1 (text/plain, inline)]

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
2) in the way the depends get packaged in debian, so make it depends on gogs

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

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

[Message part 2 (text/html, inline)]

Message #64 received at 780606@bugs.debian.org (full text, mbox, reply):

From: Michael Lustfield <michael@lustfield.net>

To: PICCORO McKAY Lenz <mckaygerhard@gmail.com>

Cc: 780606@bugs.debian.org, 792101@bugs.debian.org

Subject: Re: Bug# [...]

Date: Tue, 19 Sep 2017 17:31:02 -0700

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

Message #69 received at 780606@bugs.debian.org (full text, mbox, reply):

From: PICCORO McKAY Lenz <mckaygerhard@gmail.com>

To: Michael Lustfield <michael@lustfield.net>

Cc: 780606@bugs.debian.org, 792101@bugs.debian.org

Subject: Re: Bug# [...]

Date: Wed, 20 Sep 2017 13:49:31 -0400

[Message part 1 (text/plain, inline)]

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 all

> On 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 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
>

[Message part 2 (text/html, inline)]

Message #74 received at 780606@bugs.debian.org (full text, mbox, reply):

From: PICCORO McKAY Lenz <mckaygerhard@gmail.com>

To: Michael Lustfield <michael@lustfield.net>

Cc: 780606@bugs.debian.org, 792101@bugs.debian.org

Subject: Re: Bug# [...]

Date: Wed, 20 Sep 2017 13:56:31 -0400

[Message part 1 (text/plain, inline)]

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

> 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 all
>
>> On 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 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
>>
>
>

[Message part 2 (text/html, inline)]

Message #79 received at 780606@bugs.debian.org (full text, mbox, reply):

From: Michael Lustfield <michael@lustfield.net>

To: 780606@bugs.debian.org

Date: Tue, 5 Dec 2017 20:27:28 -0600

For anyone interested, I hit a pretty sizeable roadblock with javascript
packaging. I haven't been able to find anyone that can help me deal with these
issues so gitea packaging is dropping pretty low on my priorities list.

If anyone wants to help and knows anything about javascript packaging, I would
love (and very much need) some help.

-- 
Michael Lustfield

Message #84 received at 780606-close@bugs.debian.org (full text, mbox, reply):

From: Michael Lustfield <michael@lustfield.net>

To: 780606-close@bugs.debian.org

Subject: Bug#780606: fixed in gitea 1.3.2+dfsg-1

Date: Sat, 30 Dec 2017 22:00:14 +0000

Source: gitea
Source-Version: 1.3.2+dfsg-1

We believe that the bug you reported is fixed in the latest version of
gitea, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 780606@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Lustfield <michael@lustfield.net> (supplier of updated gitea package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 14 Mar 2017 02:01:23 -0500
Source: gitea
Binary: gitea gitea-common golang-code.gitea-gitea-dev
Architecture: source all amd64
Version: 1.3.2+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <pkg-go-maintainers@lists.alioth.debian.org>
Changed-By: Michael Lustfield <michael@lustfield.net>
Description:
 gitea      - Painless self-hosted git service
 gitea-common - Painless self-hosted git service - common files
 golang-code.gitea-gitea-dev - Painless self-hosted git service -- source
Closes: 780606 792101
Changes:
 gitea (1.3.2+dfsg-1) unstable; urgency=medium
 .
   * Initial release (Closes: #780606, #792101)
Checksums-Sha1:
 2f82a678a1b661ca71c06ddfe9f84cceed382583 6499 gitea_1.3.2+dfsg-1.dsc
 dda70fca01df1ef7d939fc8a9b777030b3bdf16d 1186848 gitea_1.3.2+dfsg.orig.tar.xz
 bda4b2b05afebc987132e49362122e6c80b0bfa0 1016532 gitea_1.3.2+dfsg-1.debian.tar.xz
 5bf25e2b2639a74fcbaa37aaaf820cf61bf29545 1575616 gitea-common_1.3.2+dfsg-1_all.deb
 286fdd1792a64af65982640f2f4e49f722745fe8 2300636 gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 6e9e6cc297b6c6ef5adb4cfed6bbf6739333cce8 20720 gitea_1.3.2+dfsg-1_amd64.buildinfo
 d0f646aeee7b70769ce604a88b8e75dfb63bfc78 6073960 gitea_1.3.2+dfsg-1_amd64.deb
 d7e7251817f59452193bbe850cf8319391bc63fd 359364 golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb
Checksums-Sha256:
 98f85a2e86c36bccfc61bf81afb2a734b7fc4c515d6bc9ed8c90352ed5da9890 6499 gitea_1.3.2+dfsg-1.dsc
 090d701efb51f3b4289dec4ea92e59308a1040a34e3e8b4c118f7135a11c7ffc 1186848 gitea_1.3.2+dfsg.orig.tar.xz
 9c4c754df59955e163d322f170cf49a552e4832c47546ce0af41a855736ffc10 1016532 gitea_1.3.2+dfsg-1.debian.tar.xz
 45b9f3864c81a981a5e0821a49e841c1d9a541bfcbd8291d64f4c2f851f6591e 1575616 gitea-common_1.3.2+dfsg-1_all.deb
 3e292f56017990e928c38db90eb8c3c19760d57727108406dc8915ebcd1c7866 2300636 gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 6ddc0af4ddb03b5d537794a0ea991893f87a89e03b91130c1c98d21763d203d4 20720 gitea_1.3.2+dfsg-1_amd64.buildinfo
 349a60afd1bcb349b4a81b5671abe39b623801c056fa5b19f8e5d2df466de720 6073960 gitea_1.3.2+dfsg-1_amd64.deb
 3c3db779868e98fc2300e09512a5725bf06e8586c1cca8a3b88610932d8b0554 359364 golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb
Files:
 583cc9a26bff489d7304bce40d835c33 6499 contrib/devel extra gitea_1.3.2+dfsg-1.dsc
 d3393c24b24528164a9c323dde532017 1186848 contrib/devel extra gitea_1.3.2+dfsg.orig.tar.xz
 a1b990512471038824decaede8a3959c 1016532 contrib/devel extra gitea_1.3.2+dfsg-1.debian.tar.xz
 58c95a1cfc09b4e29e62be09377c45c7 1575616 contrib/devel extra gitea-common_1.3.2+dfsg-1_all.deb
 69e754ad2faf0c0f2dee469176172894 2300636 contrib/debug optional gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 42a25efc9033adcbfdb2c64b72221b94 20720 contrib/devel extra gitea_1.3.2+dfsg-1_amd64.buildinfo
 886777892282b8c2499511e7c210a60d 6073960 contrib/devel extra gitea_1.3.2+dfsg-1_amd64.deb
 d6d770f915dd622a386dc60a807f1b16 359364 contrib/devel extra golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCAA0FiEEBs1j101ZjEpH5CyWA6iJGnZa0IUFAlpIAFoWHG1pY2hhZWxA
bHVzdGZpZWxkLm5ldAAKCRADqIkadlrQhVy8EACCOwB+zQH6dGqR6Qx9QGtXSVUt
1/nN8mtX42CdfeAxMsF+pfprUg677ghaUZUWu8H/LOzdoKaY7Y4qKsbcAgiEpblP
xJlO9rW6GY8Bn0jBoP/ZbvmW9NElzS9GYvOIcc4w6ptJSu3Ok9Xxut6lvkK9RaSD
FXPsaZx0DUTbDkj343oNe0YGIHWVZR39c+aLnrJARidc6Mx2VwYjLYXodVEyrEVV
4pFaqTB8Zqnsqsazq2p81EzF3VWymmFs/WoOSz+RthNAB+N0O3H7HseYn6bVyin1
AIR3gHSNjk60YoG+4UahyMAnZM2fzc4MVOehre3EkYdY7YqLrBnONbw/tw17zm2u
9TAvddEDzn/j6VWmQk/XFvHnu13u/6bhv/hmkOisZmRjpdW8jZEh8omklDa2mZcU
xGj2fP1Qb+5VghHE+QaDHTlIdG8Swku3KHrNGmJLTSSOsKxcW/pREbf92GoqnKtW
uuQy+f31EUEI/SFzj/CgcbWP3fowYnfk6DPG5Cvy3+lbvCH+AcNTM/YaJdLJofh9
GJbSsZITbp+al24T5VOJ7U/RRuQDw48V2fmI8GJ9lpeeqqPsg+XdmhaiQViKUCk+
ixPEpTQbCwwPuU1GHIUaRzuJI4uVwBHBT5jKe/Zh9K8brlvaF/U3tIbSwbngdBZD
VpBF2VvlcxgwiQW3Gw==
=DcIt
-----END PGP SIGNATURE-----

Message #89 received at 792101-close@bugs.debian.org (full text, mbox, reply):

From: Michael Lustfield <michael@lustfield.net>

To: 792101-close@bugs.debian.org

Subject: Bug#792101: fixed in gitea 1.3.2+dfsg-1

Date: Sat, 30 Dec 2017 22:00:14 +0000

Source: gitea
Source-Version: 1.3.2+dfsg-1

We believe that the bug you reported is fixed in the latest version of
gitea, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 792101@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Lustfield <michael@lustfield.net> (supplier of updated gitea package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 14 Mar 2017 02:01:23 -0500
Source: gitea
Binary: gitea gitea-common golang-code.gitea-gitea-dev
Architecture: source all amd64
Version: 1.3.2+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <pkg-go-maintainers@lists.alioth.debian.org>
Changed-By: Michael Lustfield <michael@lustfield.net>
Description:
 gitea      - Painless self-hosted git service
 gitea-common - Painless self-hosted git service - common files
 golang-code.gitea-gitea-dev - Painless self-hosted git service -- source
Closes: 780606 792101
Changes:
 gitea (1.3.2+dfsg-1) unstable; urgency=medium
 .
   * Initial release (Closes: #780606, #792101)
Checksums-Sha1:
 2f82a678a1b661ca71c06ddfe9f84cceed382583 6499 gitea_1.3.2+dfsg-1.dsc
 dda70fca01df1ef7d939fc8a9b777030b3bdf16d 1186848 gitea_1.3.2+dfsg.orig.tar.xz
 bda4b2b05afebc987132e49362122e6c80b0bfa0 1016532 gitea_1.3.2+dfsg-1.debian.tar.xz
 5bf25e2b2639a74fcbaa37aaaf820cf61bf29545 1575616 gitea-common_1.3.2+dfsg-1_all.deb
 286fdd1792a64af65982640f2f4e49f722745fe8 2300636 gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 6e9e6cc297b6c6ef5adb4cfed6bbf6739333cce8 20720 gitea_1.3.2+dfsg-1_amd64.buildinfo
 d0f646aeee7b70769ce604a88b8e75dfb63bfc78 6073960 gitea_1.3.2+dfsg-1_amd64.deb
 d7e7251817f59452193bbe850cf8319391bc63fd 359364 golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb
Checksums-Sha256:
 98f85a2e86c36bccfc61bf81afb2a734b7fc4c515d6bc9ed8c90352ed5da9890 6499 gitea_1.3.2+dfsg-1.dsc
 090d701efb51f3b4289dec4ea92e59308a1040a34e3e8b4c118f7135a11c7ffc 1186848 gitea_1.3.2+dfsg.orig.tar.xz
 9c4c754df59955e163d322f170cf49a552e4832c47546ce0af41a855736ffc10 1016532 gitea_1.3.2+dfsg-1.debian.tar.xz
 45b9f3864c81a981a5e0821a49e841c1d9a541bfcbd8291d64f4c2f851f6591e 1575616 gitea-common_1.3.2+dfsg-1_all.deb
 3e292f56017990e928c38db90eb8c3c19760d57727108406dc8915ebcd1c7866 2300636 gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 6ddc0af4ddb03b5d537794a0ea991893f87a89e03b91130c1c98d21763d203d4 20720 gitea_1.3.2+dfsg-1_amd64.buildinfo
 349a60afd1bcb349b4a81b5671abe39b623801c056fa5b19f8e5d2df466de720 6073960 gitea_1.3.2+dfsg-1_amd64.deb
 3c3db779868e98fc2300e09512a5725bf06e8586c1cca8a3b88610932d8b0554 359364 golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb
Files:
 583cc9a26bff489d7304bce40d835c33 6499 contrib/devel extra gitea_1.3.2+dfsg-1.dsc
 d3393c24b24528164a9c323dde532017 1186848 contrib/devel extra gitea_1.3.2+dfsg.orig.tar.xz
 a1b990512471038824decaede8a3959c 1016532 contrib/devel extra gitea_1.3.2+dfsg-1.debian.tar.xz
 58c95a1cfc09b4e29e62be09377c45c7 1575616 contrib/devel extra gitea-common_1.3.2+dfsg-1_all.deb
 69e754ad2faf0c0f2dee469176172894 2300636 contrib/debug optional gitea-dbgsym_1.3.2+dfsg-1_amd64.deb
 42a25efc9033adcbfdb2c64b72221b94 20720 contrib/devel extra gitea_1.3.2+dfsg-1_amd64.buildinfo
 886777892282b8c2499511e7c210a60d 6073960 contrib/devel extra gitea_1.3.2+dfsg-1_amd64.deb
 d6d770f915dd622a386dc60a807f1b16 359364 contrib/devel extra golang-code.gitea-gitea-dev_1.3.2+dfsg-1_all.deb

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCAA0FiEEBs1j101ZjEpH5CyWA6iJGnZa0IUFAlpIAFoWHG1pY2hhZWxA
bHVzdGZpZWxkLm5ldAAKCRADqIkadlrQhVy8EACCOwB+zQH6dGqR6Qx9QGtXSVUt
1/nN8mtX42CdfeAxMsF+pfprUg677ghaUZUWu8H/LOzdoKaY7Y4qKsbcAgiEpblP
xJlO9rW6GY8Bn0jBoP/ZbvmW9NElzS9GYvOIcc4w6ptJSu3Ok9Xxut6lvkK9RaSD
FXPsaZx0DUTbDkj343oNe0YGIHWVZR39c+aLnrJARidc6Mx2VwYjLYXodVEyrEVV
4pFaqTB8Zqnsqsazq2p81EzF3VWymmFs/WoOSz+RthNAB+N0O3H7HseYn6bVyin1
AIR3gHSNjk60YoG+4UahyMAnZM2fzc4MVOehre3EkYdY7YqLrBnONbw/tw17zm2u
9TAvddEDzn/j6VWmQk/XFvHnu13u/6bhv/hmkOisZmRjpdW8jZEh8omklDa2mZcU
xGj2fP1Qb+5VghHE+QaDHTlIdG8Swku3KHrNGmJLTSSOsKxcW/pREbf92GoqnKtW
uuQy+f31EUEI/SFzj/CgcbWP3fowYnfk6DPG5Cvy3+lbvCH+AcNTM/YaJdLJofh9
GJbSsZITbp+al24T5VOJ7U/RRuQDw48V2fmI8GJ9lpeeqqPsg+XdmhaiQViKUCk+
ixPEpTQbCwwPuU1GHIUaRzuJI4uVwBHBT5jKe/Zh9K8brlvaF/U3tIbSwbngdBZD
VpBF2VvlcxgwiQW3Gw==
=DcIt
-----END PGP SIGNATURE-----

Message #94 received at 780606@bugs.debian.org (full text, mbox, reply):

From: Michael Lustfield <michael@lustfield.net>

To: 780606@bugs.debian.org, 792101@bugs.debian.org

Subject: Done / Not Done

Date: Sat, 30 Dec 2017 16:49:19 -0600

Just to be clear, this is not in Debian main, it is in contrib. In order for
Gitea to reach main, it needs the following two bugs resolved.

- Vue.js: https://bugs.debian.org/871459 (in progress)
- Semantic-UI: https://bugs.debian.org/871462 (need help)
  + https://wiki.debian.org/Javascript/Nodejs/Tasks/semantic-ui

If anyone wants to help get Gitea into Debian main, those two bugs need to be
resolved. The second bug (871462) can be easily broken down into (many) smaller
nodejs packages, just check the wiki page. I'd be more than happy to review and
sponsor anyone willing to help out.

-- 
Michael Lustfield

Send a report that this bug log contains spam.