Bug#946031: ITP: sgmllib3k -- Python 3 port of Python 2's sgmllib

2019-12-02 Thread Mikhail Gusarov
Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov 

* Package name: sgmllib3k
  Version : 1.0.0
  Upstream Author : Virgil Dupras 
* URL : https://pypi.org/project/sgmllib3k/
* License : PSF-2
  Programming Lang: Python
  Description : Python 3 port of Python 2's sgmllib

sgmllib was dropped from the Python standard library in Python 3. This
package provides a port of the library to Python 3.

This package is needed as a new dependency of archmage package version 0.4.0.

archmage < 0.4.0 required Python 2 and used sgmllib package from standard 
library,
archmage 0.4.0 supports Python 3, but requires this out-of-stdlib package.



Re: d/changelog and experimental

2019-12-02 Thread Russ Allbery
Paolo Greppi  writes:

> What is the best approach for d/changelog when releasing a package to
> unstable after it has been through a few iterations to experimental ?

> It would seem that the right thing to do is to keep all experimental
> changelog entries, and add a new one for unstable.

This is the typical practice, including all the intermediate experiments
or false starts in experimental.

I sympathize with wanting to clean up some of that, but as a project we
generally have decided to live with that.  Most users don't read the full
changelog anyway (user-visible notes should be in NEWS instead, which are
shown to more people via apt-listchanges), and removing versions from the
history has bad effects on the bug-tracking system, historical archives,
etc.

-- 
Russ Allbery (r...@debian.org)  



d/changelog and experimental

2019-12-02 Thread Paolo Greppi

What is the best approach for d/changelog when releasing a package to unstable 
after it has been through a few iterations to experimental ?

It would seem that the right thing to do is to keep all experimental changelog 
entries, and add a new one for unstable.

But sometimes experimental uploads are, well ... experimental, there may be 
changes that cancel out (I tried this but it did not work, then I tried that 
etc.).
So another way is to consolidate all experimental changelog entries into the 
unstable one, tidying it up.
Also as most people never see the experimental releases, they only care for 
what's new since the last release to unstable / stable.

On this topic I found nothing definitive in policy:
https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
except footnote 3 which does not really discuss experimental.

On debian-devel I found this old thread:
https://lists.debian.org/debian-devel/2005/01/msg00791.html
where different opinions are voiced.

What the best approach ?

Paolo

(originally posted as: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-November/037083.html)



Bug#946027: ITP: golang-github-nkovacs-streamquote -- Go package providing a streaming version of strconv.Quote

2019-12-02 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-nkovacs-streamquote
  Version : 1.0.0-1
  Upstream Author : Nikola Kovacs; The Go Authors
* URL : https://github.com/nkovacs/streamquote
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go package providing a streaming version of strconv.Quote

 This package provides a streaming version of strconv.Quote.
 .
 It allows you to quote the data in an io.Reader and write it out to an
 io.Writer without having to store the entire input and the entire output
 in memory.
 .
 Its primary use case is go.rice (https://github.com/GeertJohan/go.rice)
 and similar tools, which need to convert lots of files, some of them
 quite large, to go strings.
 .
 converter := streamquote.New()
 converter.Convert(inputfile, outfile)
 .
 Unlike strconv.Quote, it does not add quotes around the output.


Rationale:
 Needed for upgrading golang-github-geertjohan-go.rice to 1.0.0,
 which in turn is needed by golang-github-alecthomas-chroma 0.6.8,
 which in turn is needed by hugo 0.59.0 and up.



Bug#946016: ITP: golang-github-gorilla-csrf -- provides Cross Site Request Forgery (CSRF) prevention middleware for Go web applications & services

2019-12-02 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-gorilla-csrf
  Version : 1.6.2-1
  Upstream Author : Gorilla Web Toolkit
* URL : https://github.com/gorilla/csrf
* License : BSD-3-clause
  Programming Lang: Go
  Description : Cross Site Request Forgery (CSRF) prevention middleware for 
Go
 gorilla/csrf is a HTTP middleware library that provides cross-site request
 forgery (CSRF) protection.  It includes:
 .
  * The csrf.Protect middleware/handler provides CSRF protection on routes
attached to a router or a sub-router.
  * A csrf.Token function that provides the token to pass into your response,
whether that be a HTML form or a JSON response body.
  * ... and a csrf.TemplateField helper that you can pass into your
html/template templates to replace a {{ .csrfField }} template tag
with a hidden input field.
 .
 gorilla/csrf is designed to work with any Go web framework, including:
 .
  * The Gorilla toolkit
  * Go's built-in net/http package
  * Goji - see the tailored fork https://github.com/goji/csrf
  * Gin
  * Echo
  * ... and any other router/framework that rallies around Go's http.Handler
interface.
 .
 gorilla/csrf is also compatible with middleware 'helper' libraries
 like Alice and Negroni.


Rationale: Needed by golang-github-alecthomas-chroma 0.6.8 and up.



Bug#946014: ITP: pyao -- Python interface to the Audio Output library

2019-12-02 Thread Jamie Wilkinson
Package: wnpp
Severity: wishlist
Owner: Jamie Wilkinson 

* Package name: pyao
  Version : 0.82
  Upstream Author : Christian Schmitz  
* URL : http://www.xiph.org/ogg/vorbis/download/
* License : GPL-3
  Programming Lang: C
  Description : Python interface to the Audio Output library

 This module makes the libao (Audio Output) functions available
 in Python. With this module you can write Python applications
 that use the cross platform audio output library.
 
pyao was removed from the archive due to python3 incompatibility. I used it, 
and would like it to return to the archive! This upload addressds the pytbon3 
issue as well as updating the package to modern standards.

Packaging will be done on a public git repo just as soon as I have figured that 
out, and will be reflected in the control file.



Bug#946001: ITP: golang-github-alecthomas-kong-hcl -- A Kong configuration loader for HCL

2019-12-02 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-alecthomas-kong-hcl
  Version : 0.2.0-1
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/kong-hcl
* License : Expat
  Programming Lang: Go
  Description : A Kong configuration loader for HCL (Go library)
 github.com/alecthomas/kong-hcl is a Kong configuration loader for HCL
 implemented for the Go programming language.
 .
 It may be used like so:
 .
 var cli struct {
 Config kong.ConfigFlag `help:"Load configuration."`
 }
 parser, err := kong.New(&cli, kong.Configuration(konghcl.Loader,
 "/etc/myapp/config.hcl", "~/.myapp.hcl))

Rationale:
* Needed by golang-github-alecthomas-chroma-dev and chroma 0.6.8,
  and in turn by Hugo 0.59.



Bug#945998: ITP: golang-github-niklasfasching-go-org -- Org mode parser with HTML & pretty-printed Org rendering

2019-12-02 Thread Anthony Fok
Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-niklasfasching-go-org
  Version : 0.1.8-1
  Upstream Author : Niklas Fasching
* URL : https://github.com/niklasfasching/go-org
* License : Expat
  Programming Lang: Go
  Description : Org mode parser with HTML & pretty-printed Org rendering
 github.com/niklasfasching/go-org an Org mode parser written in Go.
 .
 Take a look at https://niklasfasching.github.io/go-org/ for some examples
 and an online Org → HTML demo (Wasm based).
 .
 Please note that the goal for the HTML export is to produce sensible HTML
 output, not to exactly reproduce output the output of org-html-export.

Binary packages:
 * golang-github-niklasfasching-go-org-dev
 * go-org

Rationale:
 * golang-github-niklasfasching-go-org-dev is needed by hugo 0.59 and up.



Re: virtualbox, backports, and fasttrack

2019-12-02 Thread Pirate Praveen



On 2019, ഡിസംബർ 2 6:08:13 AM IST, Jonathan Nieder  wrote:
>Hi,
>
>Pirate Praveen wrote:
>> On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz  wrote:
>>> Hi Lucaus,
>
 I hope that  will make quick
 progress and turn into an official service soon.
>>>
>>> basically a good idea, but
>>
>> I'm part of the Fast Track team and I'll try to answer your
>questions.
>
>Thanks much for this.  I'm excited to see the idea moving forward.
>
>>> - what are your requirements for packages that are being uploaded
>there?
>>
>> buster-fasttrack suite:
>>
>> If a package cannot be part of a stable release because we cannot
>provide
>> security updates for the entire stable lifecylce then that package
>cannot be
>> in testing or backports. Those packages get security updates along
>with new
>> upstream versions and such software can be in FastTrack.
>
>Does the package need to be in unstable or experimental to be in
>fasttrack?  Or can I upload a package to fasttrack without being in
>Debian at all?
>
>(Asking in order to better understand how this works.  My first guess
>would have been "has to be in unstable or experimental".  Looking at
>the mailing list post you linked to, it's "has to be in unstable",
>which seems reasonable enough, I suppose.)

In general, the package has to be in unstable, we allow packages from 
experimental as exceptions, when a new version cannot be in unstable because it 
is blocked by transitions or freeze. We also allow packages in fast track 
temporarily when packages need to clear backports-new (usually when a package 
in fast track has a security release and we want to push it to users as soon as 
possible).

>
>> We have not really thought about removals yet (probably we have not
>reached
>> that stage yet as we only have one package there ie, gitlab and it is
>> maintained well.). But we could follow the same rules as testing and
>> backports (except for the meta rc bug that is present only to prevent
>> testing migration).
>
>Who should I contact if I need to remove a package?  E.g. is there a
>request tracker queue or debbugs virtual package for this?

We use salsa issues as mentioned in the website.

https://salsa.debian.org/fasttrack-team/support/issues We have not been 
monitoring it closely, but we should start monitoring it closely now as I can 
see a new issue for virtual box there.

>What are the criteria for being able to upload?  Is there a keyring
>for developers who can upload to fasttrack?

For now, its fast track team members who can upload. We can give other DDs 
upload access on request. Use the issue tracker.

>Where should users report bugs?  (My preference would be "all packages
>in fasttrack are uploaded by members of the packaging team for the
>corresponding package in unstable, and bug reports are accepted in the
>ordinary bug tracking system".)

I prefer that too. It is up to each maintainer how they want it.

>What user-facing recommendations are provided?  If a user wants to
>stop using fasttrack, can they upgrade to unstable and remove
>fasttrack from sources.list? 

It is untested, again up to each maintainer. For gitlab, I have to use 
experimental as many dependency updates are blocked by pending transitions.

> Can packages in fasttrack depend on
>other packages in fasttrack, or only on packages in stable +
>stable-backports?

It can depend on other packages in fast track.

>Is there a mailing list for day-to-day discussion?

We use irc/matrix group for this, but if a mailing list is preferred, we could 
probably create one.

#debian-fasttrack on oftc is used. It is bridged to Matrix group  
#debian-fasttrack:poddery.com

>> Secutity issues are fixed by uploading new upstream releases.
>
>What architectures are supported?  Are there autobuilders available?

It is on our to do list. Currently amd64 and binary uploads only. More could be 
added if there is interest.

>Is there a way to build releases with an embargoed security fix in
>secret?  (It's fine if the answer is "no".)  Is there a way to upload
>binary packages to avoid waiting for autobuilders to act on a security
>release?  

For now its binary included upload only.

> Is there an announcement list for uploads addressing
>security issues?

Not yet. We could start one. For now gitlab new releases are announced via 
wiki.debian.org/gitlab


>Thanks,
>Jonathan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.