Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Reinhard Tartler]

On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau  wrote:

> On 2019-01-09 6:54 a.m., Reinhard Tartler wrote:
> > Hi Juan,
> >
> > are you still working on this ITP? I was looking at skopeo as well,
> > and stumpled upon this ITP. I noticed that you created a repository on
> > salsa:
> >
> >
> https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go
> >
> > This package never got uploaded.
> >
> > However, I also noticed that there is another packaging repo in salsa,
> > which contains a similar package that did get uploaded:
> >
> >
> https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go
> > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go
> >
> > I wonder what the relationship between these two are. It seems that the
> > sjoerdsimons
> > version does declare it satisfies the import of the
> > github:ostreedev/ostree-go repo,
> > which makes me believe it is a fork.
>
> Looking at the upstream website will show you that yes it is a fork.
> (forked from ostreedev/ostree).
>
>

I'm slowly making progress towards to goal of packaging skopeo, and have
arrived at packaging the containers/image package. It also requires
compiling against the ostree-dev library (like containers/storage), but
this time it fails to build:

# github.com/sjoerdsimons/ostree-go/pkg/otbuiltin
In file included from /usr/include/glib-2.0/glib/glist.h:32,
 from /usr/include/glib-2.0/glib/ghash.h:33,
 from /usr/include/glib-2.0/glib.h:50,
 from src/
github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go:16:
src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h: In
function '_g_clear_object':
/usr/include/glib-2.0/glib/gmem.h:121:18: warning: passing argument 1 of
'g_object_unref' discards 'volatile' qualifier from pointer target type
[-Wdiscarded-qualifiers]
   (destroy) (_ptr);
\
  ^~~~
/usr/include/glib-2.0/gobject/gobject.h:672:36: note: in expansion of macro
'g_clear_pointer'
 #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr),
g_object_unref)
^~~
src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h:51:3:
note: in expansion of macro 'g_clear_object'
   g_clear_object(object_ptr);

   ^~


I noticed that a very similar error is mentioned in a commit message of the
upstream fork (ostreedev/ostree-go):

https://github.com/ostreedev/ostree-go/commit/7af23efc78cbcbf462ae58e30fc4b94e99f09436#diff-898ad6510d1fe82a218a36340e3b56ec


I strongly suspect that compiling against ostreedev/ostree-go would fix
this issue.

Given that https://github.com/sjoerdsimons/ostree-go/blob/master/README.md
clearly states:

Temporary repository for patches not yet merged in upstream ostree-go.
> Please don't use this one but use https://github.com/ostreedev/ostree-go
> instead


I wonder why we are are using this fork in the first place.

Hector, Andrej, Alex, can you please chime in? Can we avoid having two
copies of this library in the archive or is that the best way to proceed
for now?

Best,
-rt

Bug#922226: ITP: intel-mediasdk -- Intel Media SDK

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 

* Package name: intel-mediasdk
  Version : 18.4.0
  Upstream Author : Intel Corporation
* URL : https://github.com/Intel-Media-SDK/MediaSDK
* License : MIT
  Programming Lang: C
  Description : Intel Media SDK

Intel® Media SDK provides an API to access hardware-accelerated video decode,
encode and filtering on Intel® platforms with integrated graphics.

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 921564 RFP: libjs-chart -- simple yet flexible JavaScript charting
Bug #921564 [wnpp] RFP: libjs-chart
Changed Bug title to 'RFP: libjs-chart -- simple yet flexible JavaScript 
charting' from 'RFP: libjs-chart'.
> retitle 921563 RFP: libjs-ansi-up -- convert text with ANSI terminal codes 
> into colorful HTML
Bug #921563 [wnpp] RFP: libjs-ansi-up
Changed Bug title to 'RFP: libjs-ansi-up -- convert text with ANSI terminal 
codes into colorful HTML' from 'RFP: libjs-ansi-up'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
921563: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921563
921564: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921564
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#916692: #916692

[eamanu15]

Hi,


El sáb., 9 de feb. de 2019 a la(s) 08:45, Bernhard R. Link (
brl...@debian.org) escribió:

> Hi,
>
> any news on this one? Given the poor state the package is in,
> do you have the resources for an upload before buster release?
>
> Otherwise I plan to request a removal from testing once
> the soft freeze started (as autoremoval via #916691 did
> not happen).
>

I requested the source on salsa but I have not response, and sincerely
I forgot this track.

Today, I will work on ITA this package. Sorry and thanks

Please can you sponsor me?

Regards!

>
> Bernhard R. Link
> --
> F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree

[Héctor Orón Martínez]

[Adding Sjoerd in CC]

Hello,

Missatge de Reinhard Tartler  del dia dc., 13 de febr.
2019 a les 13:22:
>
>
>
> On Wed, Jan 9, 2019 at 9:58 AM Alexandre Viau  wrote:
>>
>> On 2019-01-09 6:54 a.m., Reinhard Tartler wrote:
>> > Hi Juan,
>> >
>> > are you still working on this ITP? I was looking at skopeo as well,
>> > and stumpled upon this ITP. I noticed that you created a repository on
>> > salsa:
>> >
>> >
https://salsa.debian.org/go-team/packages/golang-github-ostreedev-ostree-go
>> >
>> > This package never got uploaded.
>> >
>> > However, I also noticed that there is another packaging repo in salsa,
>> > which contains a similar package that did get uploaded:
>> >
>> >
https://salsa.debian.org/go-team/packages/golang-github-sjoerdsimons-ostree-go
>> > https://tracker.debian.org/pkg/golang-github-sjoerdsimons-ostree-go
>> >
>> > I wonder what the relationship between these two are. It seems that the
>> > sjoerdsimons
>> > version does declare it satisfies the import of the
>> > github:ostreedev/ostree-go repo,
>> > which makes me believe it is a fork.
>>
>> Looking at the upstream website will show you that yes it is a fork.
>> (forked from ostreedev/ostree).
>>
>
>
> I'm slowly making progress towards to goal of packaging skopeo, and have
arrived at packaging the containers/image package. It also requires
compiling against the ostree-dev library (like containers/storage), but
this time it fails to build:
>
> # github.com/sjoerdsimons/ostree-go/pkg/otbuiltin
> In file included from /usr/include/glib-2.0/glib/glist.h:32,
>  from /usr/include/glib-2.0/glib/ghash.h:33,
>  from /usr/include/glib-2.0/glib.h:50,
>  from src/
github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go:16:
> src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h: In
function '_g_clear_object':
> /usr/include/glib-2.0/glib/gmem.h:121:18: warning: passing argument 1 of
'g_object_unref' discards 'volatile' qualifier from pointer target type
[-Wdiscarded-qualifiers]
>(destroy) (_ptr);
   \
>   ^~~~
> /usr/include/glib-2.0/gobject/gobject.h:672:36: note: in expansion of
macro 'g_clear_pointer'
>  #define g_clear_object(object_ptr) g_clear_pointer ((object_ptr),
g_object_unref)
> ^~~
> src/github.com/sjoerdsimons/ostree-go/pkg/otbuiltin/builtin.go.h:51:3:
note: in expansion of macro 'g_clear_object'
>g_clear_object(object_ptr);
>
>^~
>
>
> I noticed that a very similar error is mentioned in a commit message of
the upstream fork (ostreedev/ostree-go):
>
>
https://github.com/ostreedev/ostree-go/commit/7af23efc78cbcbf462ae58e30fc4b94e99f09436#diff-898ad6510d1fe82a218a36340e3b56ec
>
>
> I strongly suspect that compiling against ostreedev/ostree-go would fix
this issue.
>
> Given that https://github.com/sjoerdsimons/ostree-go/blob/master/README.md
clearly states:
>
>> Temporary repository for patches not yet merged in upstream ostree-go.
Please don't use this one but use https://github.com/ostreedev/ostree-go
instead
>
>
> I wonder why we are are using this fork in the first place.
>
> Hector, Andrej, Alex, can you please chime in? Can we avoid having two
copies of this library in the archive or is that the best way to proceed
for now?

https://github.com/sjoerdsimons/ostree-go is used by `debos`, an OS image
building tool. As you noticed Sjoerd attempted to work with upstream
https://github.com/ostreedev/ostree-go, but upstream has not been
responsive so far.
Sjoerd has only been taking care of the bits he needed for `debos` and not
committing to its upstream maintenance out of `debos` needs, therefore not
recommending general use of github.com/sjoerdsimons/ostree-go.

IMO, you should try to work with upstream and package that one for
`skopeo`. If upstream ever takes Sjoerd patches we'll remove his version
from Debian archive and switch to upstream copy for `debos` which to be
honest I do not see happening any time soon.

If upstream also fails for you, I am open to take patches to support your
application into `golang-github-sjoerdsimons-ostree-go` Debian package
and/or Sjoerd might be willing to queue those patches in his fork.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Linda Lapinlampi]

On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> > I believe this package belongs in contrib, as its only use-case is with 
> > together with software outside of Debian main.
> 
> ...and now posting to the actual bugreport as well.

I'm not opposed to having this matrix-archive-keyring package in the
contrib area, although for comparison I should note leap-archive-keyring
has no rdepends, the keyring package is available from Debian's main
archive area and is valid for verifying package signatures from leap.se.
An example of a package from deb.leap.se is bitmask-core (which is not
available in Debian), and it's not in the contrib area in the leap.se
repository.

Maybe this is an error/bug in the leap-archive-keyring package, but it
does seem confusing. The other *-archive-keyring packages in Debian main
seem to be at least vaguely related to the Debian Project or its teams,
although they are all (with the exception of debian-archive-keyring)
meant to be used with third-party data sources (usually with APT).

As of yesterday, there is also this high-priority debconf(1) question
template in the matrix-archive-keyring package:

Template: matrix-archive-keyring/sources.list
Type: boolean
Default: false
_Description: Use APT data sources from Matrix.org?
 The Matrix.org Debian package repository distributes supplemental Matrix.org
 related packages intended to work with the Debian distribution, but require
 software software outside of the distribution to either build or function.
 These packages are digitally signed with keys from matrix-archive-keyring.
 .
 The Debian Project will be unable to directly support issues faced from using
 supplemental packages from this third-party repository. Packages from these
 APT sources may be non-conforming to the technical requirements set in the
 Debian Policy for the Debian distribution.

(Sorry if I fell under the assumption the package will be usable on
Debian only, and not derivative distributions with different names.)

Choosing "yes" here would obviously enable the contrib bits from the
default of "false". And as I said, packages from Matrix.org are already
in the contrib area (Section: contrib/*).

If this debconf(1) question makes it a hard-requirement of contrib
archive area, I could split the main parts (keyring) and the debconf(1)
question (sources.list) to seperate packages in main and contrib
sections respectively if that is more desirable.

I have currently set the package's "Section:" to "contrib/misc", in any
case.

What do you think?

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Ansgar]

On Wed, 2019-02-13 at 15:41 +, Linda Lapinlampi wrote:
> Template: matrix-archive-keyring/sources.list
> Type: boolean
> Default: false
> _Description: Use APT data sources from Matrix.org?
>  The Matrix.org Debian package repository distributes supplemental Matrix.org
>  related packages intended to work with the Debian distribution, but require
>  software software outside of the distribution to either build or function.
>  These packages are digitally signed with keys from matrix-archive-keyring.
>  .
>  The Debian Project will be unable to directly support issues faced from using
>  supplemental packages from this third-party repository. Packages from these
>  APT sources may be non-conforming to the technical requirements set in the
>  Debian Policy for the Debian distribution.

More important is the question if the system should /trust/ the keys.

IMHO installing a non-Debian keyring should *not* make the keys trusted
by APT by default (i.e. with the default answer if debconf is used).

ubuntu-keyring does that; most other keyrings sadly do not follow this.

Ansgar

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Holger Levsen]

On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
> 
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).

agreed.

> ubuntu-keyring does that; most other keyrings sadly do not follow this.

file bugs?


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#821397: sway 1.0-rc1

[Birger Schacht]

hi

On 2/9/19 7:25 PM, Birger Schacht wrote:
>>> There are new lintian warnings:
>>>
>>> I: sway: file-references-package-build-path usr/bin/sway
>>> [...]
>>> I think this refers to the occurrence of strings like:
>>> ../sway/commands/exec.c
>>> in the binaries. This is a relative path and the lintian warning is
>>> about reproducability, so i think this is a false negative?
>>

Just FTR, I was totally wrong about this, it actually bakes the build
path into the binary in
https://github.com/swaywm/sway/blob/d168d65f2c0297bf5662c0f48f5f53705e54a376/common/log.c#L102

But there is a TODO about this
https://github.com/swaywm/sway/blob/d168d65f2c0297bf5662c0f48f5f53705e54a376/include/log.h#L36

cheers,
Birger

Bug#922244: ITP: intel-cm-compiler -- Intel C-for-Media compiler

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 

* Package name: intel-cm-compiler
  Version : git
  Upstream Author : Intel Corporation
* URL : https://github.com/intel/cm-compiler
* License : MIT
  Programming Lang: C
  Description : Intel C-for-Media compiler

 The Intel(R) C-for-Media compiler is a open source compiler that
 implements C-for-Media (CM) programming language. CM is a new GPU
 kernel programming language for Intel HD Graphics.

Processed: src:cava: Please rename the source package

[Debian Bug Tracking System]

Processing control commands:

> reopen 829287
Bug #829287 {Done: Bart Martens } [wnpp] RFP: cava -- 
terminal audio visualiser
Bug reopened
Ignoring request to alter fixed versions of bug #829287 to the same values 
previously set

-- 
829287: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829287
922245: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922245
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#916692: ITA: cuyo -- Tetris-like game

[eamanu15]

Control: tags -1 pending

Processed: ITA: cuyo -- Tetris-like game

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending
Bug #916692 [wnpp] ITA: cuyo -- Tetris-like game
Added tag(s) pending.

-- 
916692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Linda Lapinlampi]

On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
> 
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).

I've agreed, it's the problem I'm trying to solve with this
matrix-archive-keyring package. As said in the OP of Bug#922155 (ITP):

> I have made this package install an OpenPGP-armored keyring to
> /usr/share/keyrings (instead of /etc/apt/trusted.gpg.d);

Since they are not in Dir::Etc::trusted or Dir::Etc::trustedparts, the
system won't trust the Matrix archive keys for APT by default (unless
the sysadmin has explicitly configured otherwise). By default,
sources.list(5) entries will need to specifically have

[signed-by:/usr/share/keyrings/matrix-archive-keyring.gpg]

for APT to trust the data sources with this package.

To clarify, trust to keys in the matrix-archive-keyring package is all a
multi-step opt-in:

1. Using the keyring to manually verify packages from Matrix.org (yes)
2. Trusting the keyring for Matrix.org APT sources (default: no)
3. Trusting the keyring for any APT sources (default: hell no)

What the Internet says to do and what's currently happening in practice:

1. Using the repository key to manually verify packages from Matrix.org
2. Trusting the repository key for Matrix.org APT sources (yes, but...)
3. Trusting the repository key for any APT sources (yikes)

There is an additional low priority debconf(1) question in
matrix-archive-keyring if #3 should be true, but with sane default of
"false" and a warning about it being unnecessary in most cases.
Although it's so trivial, I'm open to removing this option altogether if
desired for lacking much real use.

The other debconf(1) question (#2) serves to answer if the user should
trust packages from the third-party repository. If you meant the
description of that question does not adequately ask if the user should
/trust/ packages from that repository (instead of just mentioning they
are supplemental packages which are not officially supported), would you
like me to change the description for the release to point out trust
more prominently? The alternative may be a seperate contrib package for
a sources.list source.

> ubuntu-keyring does that; most other keyrings sadly do not follow this.

I'd suggest to file bugs. I've found many issues in the past few days.

Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository

[Jonas Smedegaard]

Quoting Linda Lapinlampi (2019-02-13 16:41:06)
> On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> > > I believe this package belongs in contrib, as its only use-case is 
> > > with together with software outside of Debian main.
> > 
> > ...and now posting to the actual bugreport as well.
> 
> I'm not opposed to having this matrix-archive-keyring package in the 
> contrib area, although for comparison I should note 
> leap-archive-keyring has no rdepends, the keyring package is available 
> from Debian's main archive area and is valid for verifying package 
> signatures from leap.se. An example of a package from deb.leap.se is 
> bitmask-core (which is not available in Debian), and it's not in the 
> contrib area in the leap.se repository.
> 
> Maybe this is an error/bug in the leap-archive-keyring package, but it 
> does seem confusing. The other *-archive-keyring packages in Debian 
> main seem to be at least vaguely related to the Debian Project or its 
> teams, although they are all (with the exception of 
> debian-archive-keyring) meant to be used with third-party data sources 
> (usually with APT).

Thanks for comparing with similar packages: That indicates you go that 
extra mile in striving towards perfection in your packaging - Cool!

Please file bugreports for such other packages that you notice - should 
be fine filing such bugs with high severity, since it is a violation of 
a "must" in Debian Policy § 2.2.1.


> As of yesterday, there is also this high-priority debconf(1) question 
> template in the matrix-archive-keyring package:
> 
> Template: matrix-archive-keyring/sources.list
> Type: boolean
> Default: false
> _Description: Use APT data sources from Matrix.org?
>  The Matrix.org Debian package repository distributes supplemental Matrix.org
>  related packages intended to work with the Debian distribution, but require
>  software software outside of the distribution to either build or function.
>  These packages are digitally signed with keys from matrix-archive-keyring.
>  .
>  The Debian Project will be unable to directly support issues faced from using
>  supplemental packages from this third-party repository. Packages from these
>  APT sources may be non-conforming to the technical requirements set in the
>  Debian Policy for the Debian distribution.

Cool!


> (Sorry if I fell under the assumption the package will be usable on 
> Debian only, and not derivative distributions with different names.)
> 
> Choosing "yes" here would obviously enable the contrib bits from the 
> default of "false". And as I said, packages from Matrix.org are 
> already in the contrib area (Section: contrib/*).
> 
> If this debconf(1) question makes it a hard-requirement of contrib 
> archive area, I could split the main parts (keyring) and the 
> debconf(1) question (sources.list) to seperate packages in main and 
> contrib sections respectively if that is more desirable.
> 
> I have currently set the package's "Section:" to "contrib/misc", in 
> any case.
> 
> What do you think?

The addition of a debconf question - with default being false - seems an 
excellent improvement over the package silently activating the keys (if 
that was the previous behaviour - I am only guessing here).

I find the keys themselves to be the reason for the package belonging in 
contrib, however - regardless of adding that nice debconf message.

Thanks a lot for your contribution to Debian!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#902174: #902174: RFP: mes

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

Hi!

I have resurrected the debian package descriptions for Nyacc,
MesCC-tools and Mes, and updated them to the latest versions.

It would be great if you could take a look at them.

The descriptions are available on a `wip-debian' branch for

https://gitlab.com/janneke/nyacc
https://gitlab.com/janneke/mescc-tools
https://gitlab.com/janneke/mes   # for convenience, canonical git at
  https://git.savannah.gnu.org/git/mes.git

Meanwhile a lot has happened with Mes: it has become a GNU package and
now drives the Reduced Binary Seed bootstrap of the GNU Guix system, see
http://joyofsource.com/reduced-binary-seed-bootstrap.html

Anyway, the latest release of Mes (v0.19) does not build and install
well on Debian; so you'll need not only the debian/ directory for Mes
but also the state of the git archive it lives in.  If that's a problem
we can do a 0.19.1 release -- we're expecting a nice 0.20 release within
a month or so.

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#916692: #916692

[eamanu15]

Control: tags -1 +help

Hello,

I tag help because I am having some problems while build
this package.

when I make `sbuild -s -A` I have errors like this:

dpkg-source: error: cannot represent change to data/pics/iwaAlles.xcf:
binary file contents changed

and warnings like this:
dpkg-source: warning: executable mode 0755 of 'data/pics/itrVorderrand.xpm'
will not be represented in diff

What is the meaning of it?

I create the repo on salsa for this package:
https://salsa.debian.org/eamanu-guest/cuyo

Thanks!
regards!

El mié., 13 de feb. de 2019 a la(s) 09:52, eamanu15 (
emmanuelaria...@gmail.com) escribió:

> Hi,
>
>
> El sáb., 9 de feb. de 2019 a la(s) 08:45, Bernhard R. Link (
> brl...@debian.org) escribió:
>
>> Hi,
>>
>> any news on this one? Given the poor state the package is in,
>> do you have the resources for an upload before buster release?
>>
>> Otherwise I plan to request a removal from testing once
>> the soft freeze started (as autoremoval via #916691 did
>> not happen).
>>
>
> I requested the source on salsa but I have not response, and sincerely
> I forgot this track.
>
> Today, I will work on ITA this package. Sorry and thanks
>
> Please can you sponsor me?
>
> Regards!
>
>>
>> Bernhard R. Link
>> --
>> F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC
>>
>
>
> --
> Arias Emmanuel
> http://eamanu.com
> Github/Gitlab; @eamanu
> Debian: @eamanu-guest
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Processed: Re: Bug#916692: #916692

[Debian Bug Tracking System]

Processing control commands:

> tags -1 +help
Bug #916692 [wnpp] ITA: cuyo -- Tetris-like game
Added tag(s) help.

-- 
916692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

opensnitch -- Port of the Little Snitch application firewall

[jonathan vlan]

Debian Bug report logs - #909567 <909...@bugs.debian.org>
hola opensnitch package, for debian buster ,  works perfectly in debian
buster , parrot os , kali linux .  /  I have not tried it on debian stretch
or on ubuntu

Need installation of :
apt-get install  libnetfilter-queue1 libnetfilter-conntrack3
python3-slugify python-pyqt5 libc6 python3.7

Package : opensnitch_1.0.deb
https://sourceforge.net/projects/unknownos/files/opensnitch/

sorry for my bad english

Bug#918887: RFA:quickml -- Very-easy-to-use mailing list system

[Bekks Oruta]

I would be willing to adopt this package if you would assist me to get started.

Emeka


On Thu, 10 Jan 2019 19:57:12 +0900 Kenshi Muto  wrote:
>  Package: wnpp
>  Severity: normal
>
>  I request a maintainer for quickml package.
>  This program is implemented in Ruby language.
>
>  Unfortunately upstream development was dead
>  a long long time ago.
>  Codes are bit old and would be better to update for
>  newer Ruby version.
>
>  Even so, I believe this list server software is
>  very unique and useful.
>
>  Thanks,
>  - --
>  Kenshi Muto
>  km...@debian.org
>
>> -BEGIN PGP SIGNATURE-
>>  Comment: Processed by Mailcrypt 3.5.9 
>>
>>  iQIzBAEBCAAdFiEEnMxcIsEJVbWPVaUbHSHIPcRS4PwFAlw3JQQACgkQHSHIPcRS
>>  4PzuJBAAk7yDEjofjQpEC2x3XO9f/PxJF+bKWImtkbrpq313vOC4Gw0o/KJWYe7N
>>  6AdO5ZeJnxzobIfWdMUWSKErTAcM5yIA1kZBGunCrWK5YIRhPML8zlALjEDMFzhU
>>  ZscRiBwKKyGP0pwWg7Xdkn4K/Ze86F4IfNfLfYIauqQLkNfdIkJ+thxq7hYWb7ld
>>  ovc9uYDkqrUu5WKikJT9lKKJJ9EaGO9/+SjEkP2eotzy/4B0Q+Y+GeolRmkq5kJk
>>  OgA8V6MjcyefUfj2x6YgjZFACxDSqf14BRRDqiJzPDvV9a3/y3kd0IPpl5mjYWDi
>>  l2/KdsyHdQwsYqhaDW0bBwfaS6CttfbyMNMBUGY7pzbRF+17G0RArIxxDEV7YQSW
>>  NtFo8MX0VDvVPz1n0cVyehh1tUiYmoRvENXZJ73WiwkjdAWQdEIwcQWqxTWzs5oh
>>  gU795mIhbyrD9/PfvitzrRNIJJPrxmZCHaC+Zjbt+0l92lRwqybzOnVCcOT8swP9
>>  f2n1h7jJrflfn6zeJzeZfBZaERGETaC0w5wdAYIDEk+ts6G7it8uPQV2wdLiQRNo
>>  y8BeHCsmFc+GDQXtfGCGKTYilBb0wi72+w/n0/oXWm1DeT9DYR1Ct9uQIPPnWhUm
>>  3t8xh3+2eTaxPscB/Xke50hC/wueBYCwZO6xVZFJfq8dTpH1mkE=
>>  =Jvro
>>  -END PGP SIGNATURE-
 End of forwarded message