Bug#1073117: O: pagure -- git-centered forge using pygit2

[Sergio Durigan Junior]

Package: wnpp
Control: affects -1 + src:pagure
Severity: normal

After several years, I finally decided to orphan pagure :-(.

I haven't been using it as my personal forge anymore, and unfortunately
upstream development slowed down quite a bit after the main author and
maintainer stopped contributing regularly to the project.  But that is
not to say that upstream is dead; they are still working towards
preparing the next release.

Pagure is a big package with several components and an extensive list of
build dependencies (and an even bigger testsuite which I never managed
to make fully work on Debian).  It is not for the faint of heart, and
most of the time is usually spent fixing its (build) dependencies so
that it doesn't get removed from testing.

If I may, I would like to leave some suggestions for a future
maintainer.

- I never had the time to write dep8 tests, mainly because setting up
  the software is not trivial.  It would be great if the package had
  more Debian-centric testing.

- Speaking of the hurdles to setting up Pagure, I believe the package
  installation could be made a bit more automated using debconf.  I
  don't see a way to fully automate it (look at d/README.Debian), but
  there is certainly room for improvement.

I also left a brief TODO list inside d/README.source; feel free to
tackle any item there!

I wish the next maintainer can have as much fun with the package as I
did when I first made it for Debian!

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1068154: ITP: poke-elf -- GNU Poke pickle for editing ELF object files

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: poke-elf
  Version : 1.0
  Upstream Author : Jose E. Marchesi 
* URL : http://www.jemarch.net/poke-elf
* License : GPL-3+ and others
  Programming Lang: C
  Description : GNU Poke pickle for editing ELF object files

 poke-elf is a GNU poke pickle for editing ELF object files,
 executables, shared libraries and core dumps.  It supports many
 architectures and extensions.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#903999: RFC about DFSG-freeness of PHP license [Re: Bug#903999: ITP: php-doc -- Documentation for PHP]

[Sergio Durigan Junior]

Hello,

Disclaimer: I am not a lawyer and this is not legal advice.

I talked extensively to Athos during DebConf and, after looking at the
multiple licenses and nuances involved in this problem I believe:

1) Athos followed precisely the instructions from ftp-masters
(https://ftp-master.debian.org/php-license.html).  He also followed the
good practices pointed by Lintian.

2) IMO, it is possible to argue that php-doc is actually part of PHP
itself, judging by the fact that the project is hosted under the PHP
umbrella on the Microsoft Github repository.  If that's the case, then I
agree with Athos that we should extend the Lintian warning.

3) Ultimately, it is the ftp-master's job to determine whether php-doc's
license is suitable for Debian or not.  I don't think it's
necessary/beneficial to extend this discussion here.

Having said that, I will review and sponsor the package for Athos.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#986288: poke in Debian

[Sergio Durigan Junior]

On Monday, April 05 2021, Adam Borowski wrote:

> On Mon, Apr 05, 2021 at 11:59:00PM +0100, Sudip Mukherjee wrote:
>> On Fri, Apr 2, 2021 at 4:57 PM Hilko Bengen  wrote:
>> > Oh, I hadn't noticed because it was only uploaded to experimental. Will
>> > contact the packager.
>> 
>> I think that is because it is recommended not to upload anything to
>> unstable which is not meant for Bullseye.
>
> There's no difference for packages without a version in testing.

There isn't, but I'm not uploading anything to unstable until the freeze
is over, including packages that are new.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#927454: ITP: towncrier -- compiler for project news file

[Sergio Durigan Junior]

On Saturday, March 06 2021, Ben Finney wrote:

> On 05-Mar-2021, Sergio Durigan Junior wrote:
>
>> How are you?
>
> Thanks for asking. I'm not great, but it's all relative; pretty much
> everyone has had a bad 12 months more more. Hope you're well.

Ouch, sorry to read that :-(.  I hope you take good care of yourself,
and please don't feel pressured to work on this package just because of
my message.

>> I have a friend (who is also my namesake) who is interested in
>> having towncrier in the archive. Maybe you can give us/him some
>> pointers on the current status of the package so that he can help
>> you with it?
>
> Thank you for the prompt. I will get back onto this and bring it up to
> date.

Thanks, I really appreciate it, but as I said, please don't feel like
you need to do that.  Sérgio Cipriano is interested in helping with the
package (he is still learning, but I can attest that he's good and picks
things up really fast), so if you want to give us the lay of the land we
can take it from here, no problems.

Otherwise, if you feel like finishing the package, please know that you
can ping us if you need any help!

Thank you very much.  Take care!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#927454: ITP: towncrier -- compiler for project news file

[Sergio Durigan Junior]

On Friday, April 19 2019, Ben Finney wrote:

> * Package name: towncrier
>   Version : 19.2.0
>   Upstream Author : Amber Brown  and Contributors
> * URL or Web page : https://pypi.org/project/towncrier/
> * License : Expat
>   Description : compiler for project news file
>   Towncrier is a utility to produce useful, summarised news files for your
>   project. Rather than reading the VCS history as some newer tools do, or 
> having
>   one single file which developers all write to, towncrier reads “news 
> fragments”
>   which contain information *useful to end users*.
>   .
>   towncrier delivers the news which is convenient to those that hear it, 
> not
>   those that write it.
>   .
>   That is, a “news fragment” (a small file containing just enough 
> information to
>   be useful to end users) can be written that summarises what has changed 
> from
>   the “developer log” (which may contain complex information about the 
> original
>   issue, how it was fixed, who authored the fix, and who reviewed the 
> fix). By
>   compiling a collection of these fragments, towncrier can produce a 
> digest of
>   the changes which is valuable to those who may wish to use the software.

Hi Ben,

How are you?

I'm writing to check on the status of the towncrier package.  I noticed
that you have an apparently complete package on
https://salsa.debian.org/bignose/pkg-towncrier, but it hasn't been
uploaded and I can't find why.

I have a friend (who is also my namesake) who is interested in having
towncrier in the archive.  Maybe you can give us/him some pointers on
the current status of the package so that he can help you with it?

Thanks in advance,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#940613: Any updates?

[Sergio Durigan Junior]

On Sunday, February 28 2021, Gard Spreemann wrote:

> Hi,
>
> I see version 1.0 of this software was just released, and has been
> making its way around the web. It looks really neat! Do you think you'll
> be interested in picking back up your packaging efforts for after the
> Bullseye release? I'm happy to lend a hand.

Thank you for your interest.  I'm actually finishing the package right
now.  I should upload it to experimental in the next couple of days.

The problem is that we're in freeze now, so I can't upload it directly
to unstable, but I will talk to the release team and see if they can
make an exception for this one.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#982176: ITP: flask-oidc -- OpenID Connect support for Flask

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: flask-oidc
  Version : 1.4.0
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/flask-oidc
* License : BSD-2-clause
  Programming Lang: Python
  Description : OpenID Connect support for Flask

 This library should work with any standards compliant OpenID Connect
 provider.  It has been tested with:
 .
  * Google+ login
  * Ipsilon

This package is a dependency for Pagure. .I will maintain it with the
Python Team.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#976629: ITP: python-build -- Simple, correct PEP517 package builder

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-build
  Version : 0.1.0
  Upstream Author : Filipe Laíns 
* URL : https://github.com/pypa/build
* License : Expat
  Programming Lang: Python
  Description : Simple, correct PEP517 package builder

 python-build will invoke the PEP 517 hooks to build a distribution
 package. It is a simple build tool and does not perform any
 dependency management.

I will maintain this package with the Python Team.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#894786: RFP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-pytest-flake8 -- pytest plugin to check FLAKE8 
requirements
Control: owner -1 !
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

On Wednesday, April 04 2018, Julien Puydt wrote:

> * Package name: python-pytest-flake8
>   Version : 1.0.0
>   Upstream Author : Thorsten Lockert
> * URL : https://github.com/tholo/pytest-flake8
> * License : BSD
>   Programming Lang: Python
>   Description : pytest plugin to check FLAKE8 requirements
>
> This pytest plugin makes it possible to check source code for Flake8
> style guide enforcement.
>
> The newest path.py versions use that to check the sources ; I have a
> patch to disable that for now.

I will package this.  The current version is 1.0.6.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#969496: ITP: golang-github-aalpar-deheap -- Doubly ended heap implementation

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org, 
kanash...@debian.org

* Package name: golang-github-aalpar-deheap
  Version : 0.0~git20200318.9a0c288-1
  Upstream Author : Aaron Alpar
* URL : https://github.com/aalpar/deheap
* License : Expat
  Programming Lang: Go
  Description : Doubly ended heap implementation

 deheap provides the implementation of a doubly ended heap.
 Doubly ended heaps are heaps with two sides, a min side and a max side.
 Like normal single-sided heaps, elements can be pushed onto and pulled
 off of a deheap.  deheaps have an additional Pop function, PopMax,
 that returns elements from the opposite side of the ordering.
 .
 This implementation has emphasized compatibility with existing libraries
 in the sort and heap packages.
 .
 Performance of the deheap functions should be very close to the performance
 of the functions of the heap library

This package will be maintained under the Go team umbrella.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

[Sergio Durigan Junior]

On Tuesday, July 07 2020, Sudip Mukherjee wrote:

> Hi Sergio,

Hi Sudip,

> On Tue, Sep 17, 2019 at 05:30:01PM -0400, Sergio Durigan Junior wrote:
>> [ Forwarding.  ]
>> 
>> <#secure method=pgpmime mode=sign>
>> On Tuesday, September 17 2019, I wrote:
>> 
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Sergio Durigan Junior 
>> >
>> > * Package name: poke
>> >   Version : 0.1-beta
>> >   Upstream Author : Jose E. Marchesi
>> > * URL : http://www.jemarch.net/poke.html
>> > * License : GPL-3+
>> >   Programming Lang: C
>> >   Description : GNU poke -- An interactive, extensible editor for 
>> > binary data
>> >
>> >  GNU poke is an interactive, extensible editor for binary data. Not
>> >  limited to editing basic entities such as bits and bytes, it provides a
>> >  full-fledged procedural, interactive programming language designed to
>> >  describe data structures and to operate on them.
>
> Any idea when this can land? I attended a conference last year where
> Jose demonstrated this and it seemed pretty cool.

Unfortunately no.  GNU poke depends on jitter
(http://ageinghacker.net/git/cgit.cgi/jitter), which is not available in
Debian.  I was going to package it, but then got sidetracked.

I'm fairly busy with other stuff these days, but I will try to give it a
go this next weekend.  Let's see.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#962418: ITP: python-email-validator -- Robust email address syntax and deliverability validation library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-email-validator
  Version : 1.1.1
  Upstream Author : Joshua Tauberer 
* URL : https://github.com/JoshData/python-email-validator
* License : Public Domain
  Programming Lang: Python
  Description : Robust email address syntax and deliverability validation 
library

 This library validates that a string is of the form x...@y.com. This is
 the sort of validation you would want for an email-based login form
 on a website.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#940860: ITP: OSCAR -- Open Source CPAP Analysis Reporter

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: oscar
  Version : 1.1.0-testing-3
  Upstream Author : The OSCAR Team
* URL : https://www.sleepfiles.com/OSCAR/
* License : GPL-3
  Programming Lang: C++
  Description : Open Source CPAP Analysis Reporter (OSCAR)

 OSCAR is a Free Software, cross platform research tool for
 exploring data produced by CPAP (Continuous Positive Airway Pressure)
 machines, and related equipment, which are used in the treatment of
 sleep apnea and other sleep disorders.
 .
 OSCAR is a derivative of SleepyHead version 1.1.0, created when that
 was abandoned by Mark Watkins.

This software will replace SleepyHead.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

[Sergio Durigan Junior]

[ Forwarding.  ]

<#secure method=pgpmime mode=sign>
On Tuesday, September 17 2019, I wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Sergio Durigan Junior 
>
> * Package name: poke
>   Version : 0.1-beta
>   Upstream Author : Jose E. Marchesi
> * URL : http://www.jemarch.net/poke.html
> * License : GPL-3+
>   Programming Lang: C
>   Description : GNU poke -- An interactive, extensible editor for binary 
> data
>
>  GNU poke is an interactive, extensible editor for binary data. Not
>  limited to editing basic entities such as bits and bytes, it provides a
>  full-fledged procedural, interactive programming language designed to
>  describe data structures and to operate on them.
>
> -- 
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> http://sergiodj.net/
>

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: poke
  Version : 0.1-beta
  Upstream Author : Jose E. Marchesi
* URL : http://www.jemarch.net/poke.html
* License : GPL-3+
  Programming Lang: C
  Description : GNU poke -- An interactive, extensible editor for binary 
data

 GNU poke is an interactive, extensible editor for binary data. Not
 limited to editing basic entities such as bits and bytes, it provides a
 full-fledged procedural, interactive programming language designed to
 describe data structures and to operate on them.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#906907: ITP: pw -- A simple command-line password manager

[Sergio Durigan Junior]

On Wednesday, August 22 2018, Dashamir Hoxha wrote:

> Package: wnpp
> Severity: wishlist
>
> Description:
>   A simple command-line password manager that keeps passwords inside a
>   gpg encrypted tgz archive. The content of the archive is a directory tree
>   with a file for each password entry. The first line of the file is the
>   password, and the rest can optionally be additional or related info.
>   It provides commands for manipulating the passwords, allowing the user
>   to add, remove, edit, generate passwords etc.
>
> Repository: https://gitlab.com/dashohoxha/pw
> Documentation: https://dashohoxha.gitlab.io/pw/man/

What changed between this attempt and your last one?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903880

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#889780: O: stomper -- Python client implementation of the STOMP protocol

[Sergio Durigan Junior]

On Tuesday, February 06 2018, Tobias Frost wrote:

> The current maintainer of stomper, Simon Chopin  ,
> is apparently not active anymore.  Therefore, I orphan this package now.

Hi Tobias,

The stomper package is maintained by the Debian Python Modules Team
(DPMT); Simon is (was?) listed as an Uploader, not the maintainer.  I
don't think it's accurate to list the package as orphaned.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904877: ITP: trololio -- Trollius and asyncio compatibility library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: trololio
  Version : 1.0
  Upstream Author : ThinkChaos
* URL : https://github.com/ThinkChaos/Trololio
* License : Expat
  Programming Lang: Python
  Description : trololio -- Trollius and asyncio compatibility library

 Trololio provides a compatibility layer for Trollius and asyncio (aka
 Tulip). It addresses the differences listed in Trollius and Tulip:
 .
  * Allows the use of Trollius' syntax with asyncio.
  * Provides missing objects and aliases for the others.
  * Synchronizes debug environnement variables.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904066: ITP: python-openidc-client -- A Python OpenID Connect client with token caching and management

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-openidc-client
  Version : 0.6.0
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/python-openidc-client
* License : Expat
  Programming Lang: Python
  Description : A Python OpenID Connect client with token caching and 
management

 This package is a simple Python OpenID Connect client library with
 token caching and management.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904054: ITP: cccolutils -- Python Kerberos Credential Cache Collection Utilities

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: cccolutils
  Version : 1.4
  Upstream Author : https://pagure.io/cccolutils
* URL : Patrick Uiterwijk 
* License : GPL-2+
  Programming Lang: Python
  Description : Python Kerberos Credential Cache Collection Utilities

 This module provides Kerberos 5 credential cache collection utilities
 for Python 2.6+ and 3.
 .
 When a user authenticates to a Kerberos realm (eg. with kinit), the user
 has a short-lived credential in a cache (view it with klist).
 .
 You can use this cccolutils module to easily determine if the user has
 any valid Kerberos credentials, or what the username is for a particular
 Kerberos realm.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836408: ITP: jquery-caret.js -- library to query input caret position

[Sergio Durigan Junior]

On Tuesday, January 02 2018, Ben Finney wrote:

> On 02-Jan-2018, Sergio Durigan Junior wrote:
>> On Sunday, December 11 2016, Ben Finney wrote:
>> > I am still not clear about how this is meant to be used, so after
>> > it clears the NEW queue please experiment and report bugs if it is
>> > not working.
>> 
>> Do you think you could upload this to unstable?
>
> Can you confirm that, when you install the package, it works as
> expected (for Pagure, since that is your use case) without needing any
> changes?

Yeah, I'll test here.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836408: ITP: jquery-caret.js -- library to query input caret position

[Sergio Durigan Junior]

On Sunday, December 11 2016, Ben Finney wrote:

> Control: tags -1 + pending
>
> On 04-Sep-2016, Ben Finney wrote:
>
>> I have a complete package for this, and am interested to know whether
>> it meets the need of dependent packages
>
> This is now uploaded to ‘experimental’ at version “0.3.1+dfsg.1-1”. As
> of this writing it is waiting in the NEW queue.
>
> I am still not clear about how this is meant to be used, so after it
> clears the NEW queue please experiment and report bugs if it is not
> working.

Hey Ben,

Do you think you could upload this to unstable?  pagure still needs this
dependency, and it won't build right now because the package is in
experimental.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: recap

[Sergio Durigan Junior]

On Friday, December 29 2017, Pirate Praveen wrote:

> On 12/29/2017 11:45 PM, Sergio Durigan Junior wrote:
>
>> I would also like to notice that I'm still working on my personal copy
>> of the repository, located at:
>> 
>>   https://git.sergiodj.net/debian/pagure.git/
>> 
>> Although I appreciate the help from Boyuan Yang, I think the pagure.git
>> repository on collab-maint is very disorganized and hard to work on.
>> Since we're going to move from Alioth to salsa.debian.org anyway, I
>> think this is a good opportunity to readjust the current repository
>> (without losing Boyuan Yang's changes, of course).
>> 
>> Pirate, I am not yet a DD, so could you please create a "pagure" project
>> under the Debian group on salsa.debian.org and put me as the
>> responsible?  My username there is "sergiodj-guest".
>
> Created the repo and made you a master.
> https://salsa.debian.org/debian/pagure

Thanks, Pirate!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: recap

[Sergio Durigan Junior]

On Friday, December 29 2017, I wrote:

> On Friday, December 29 2017, I wrote:
>
>> On Thursday, December 28 2017, bill auger wrote:
>>
>>> at this point i think the first thing to do is to verify the packaging
>>> state of the dependencies noted previously (re-posted below) and to
>>> see that any remaining dependencies that need packaging should have
>>> themselves ITP issues attached to this one as blockers
>>>
>>> currently this ITP has ITP blockers:
>>> * 863244: ITP: libjs-cal-heatmap
>>> * 862880: ITP: node-at.js
>>>
>>> then perhaps to look over the TODO lists and see if any items can be ticked 
>>> off as completed
>>
>> More dependencies need to be added to the list.
>>
>> I'm specifically working on getting python-Pillow packaged; it's a new
>> dependency for pagure that was added recently.  I'm using the following
>> list:
>>
>>   https://pagure.io/pagure/blob/master/f/requirements.txt
>>
>> And python-Pillow has the following dependencies:
>>
>>   https://github.com/python-pillow/Pillow/blob/master/requirements.txt
>
> Well, as it turns out, python-pil *is* the Pillow fork, so please ignore
> what I said above.  We're good to go on this front.

I would also like to notice that I'm still working on my personal copy
of the repository, located at:

  https://git.sergiodj.net/debian/pagure.git/

Although I appreciate the help from Boyuan Yang, I think the pagure.git
repository on collab-maint is very disorganized and hard to work on.
Since we're going to move from Alioth to salsa.debian.org anyway, I
think this is a good opportunity to readjust the current repository
(without losing Boyuan Yang's changes, of course).

Pirate, I am not yet a DD, so could you please create a "pagure" project
under the Debian group on salsa.debian.org and put me as the
responsible?  My username there is "sergiodj-guest".

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#829046: recap

[Sergio Durigan Junior]

On Friday, December 29 2017, I wrote:

> On Thursday, December 28 2017, bill auger wrote:
>
>> at this point i think the first thing to do is to verify the packaging
>> state of the dependencies noted previously (re-posted below) and to
>> see that any remaining dependencies that need packaging should have
>> themselves ITP issues attached to this one as blockers
>>
>> currently this ITP has ITP blockers:
>> * 863244: ITP: libjs-cal-heatmap
>> * 862880: ITP: node-at.js
>>
>> then perhaps to look over the TODO lists and see if any items can be ticked 
>> off as completed
>
> More dependencies need to be added to the list.
>
> I'm specifically working on getting python-Pillow packaged; it's a new
> dependency for pagure that was added recently.  I'm using the following
> list:
>
>   https://pagure.io/pagure/blob/master/f/requirements.txt
>
> And python-Pillow has the following dependencies:
>
>   https://github.com/python-pillow/Pillow/blob/master/requirements.txt

Well, as it turns out, python-pil *is* the Pillow fork, so please ignore
what I said above.  We're good to go on this front.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#829046: recap

[Sergio Durigan Junior]

On Thursday, December 28 2017, bill auger wrote:

> at this point i think the first thing to do is to verify the packaging
> state of the dependencies noted previously (re-posted below) and to
> see that any remaining dependencies that need packaging should have
> themselves ITP issues attached to this one as blockers
>
> currently this ITP has ITP blockers:
> * 863244: ITP: libjs-cal-heatmap
> * 862880: ITP: node-at.js
>
> then perhaps to look over the TODO lists and see if any items can be ticked 
> off as completed

More dependencies need to be added to the list.

I'm specifically working on getting python-Pillow packaged; it's a new
dependency for pagure that was added recently.  I'm using the following
list:

  https://pagure.io/pagure/blob/master/f/requirements.txt

And python-Pillow has the following dependencies:

  https://github.com/python-pillow/Pillow/blob/master/requirements.txt

I'll make sure to open ITP's for each dep and add them as blockers of
this bug.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Thursday, December 28 2017, Sébastien wrote:

> Hello.
>
> Any news about this package?

Hey,

Yeah, I'm still working on packaging pagure.  I'm currently packaging
the missing Python dependencies.  Without them, there isn't much one can
do about packaging pagure itself.

As for pagure, I'm mostly happy about the state of the package.  IIRC
there were some failures happening on a specific test, and I confess I
don't know if the failure is still present or not.  I think there's
information about this on the ITP bug.

Another important thing that remains to be done is to verify all the
JavaScript dependencies and make sure that they're packaged for Debian.
I'm looking into helping with the package of node-rollup and its
dependencies, which is a necessary dependency to build one of pagure's
JS files (see the pagure/static/vendor folder upstream for a list of JS
deps).

I would welcome any help with these tasks, but please let's communicate
via this bug in order to avoid duplicating efforts.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#734117: RFP: python-check-manifest -- tool to check the completeness of MANIFEST.in for Python packages

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-check-manifest -- tool to check the 
completeness of MANIFEST.in for Python packages
Control: owner -1 !

On Friday, January 03 2014, Francois Marier wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name: python-check-manifest
>   Version : 0.17
>   Upstream Author : Marius Gedminas 
> * URL : https://github.com/mgedmin/check-manifest
> * License : MIT
>   Programming Lang: Python
>   Description : tool to check MANIFEST.in in a Python source package for 
> completeness

I intend to package this.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#849396: Acknowledgement (ITP: rspamd - rapid spam filtering system)

[Sergio Durigan Junior]

On Monday, October 30 2017, Diane E. Trout wrote:

> On Wed, 26 Jul 2017 16:42:07 +0200 Stefan Tatschner  mail.com> wrote:
>> On Wed, 01 Mar 2017 16:23:39 +0100 Bartosz Fenski 
>> wrote:
>> > Feel free to deal with upstream.
>> > I gave up.
>> > 
>> > No way to convince him to start using source of JS files used in
> web 
>> > interface.
>> 
>> What exactly is the problem here?
>> 
>> Stefan
>> 
>> 
>
> Probably this:
>
> https://github.com/vstakhov/rspamd/tree/master/interface/js/lib
>
> Checked in .min.js files
>
> Looks like first packager gave up trying to convince the developer not
> to do that.

This is becoming common practice among web developers, but there are
ways to circumvent this problem.  For example, one could exclude these
files from the package (via d/copyright), install the corresponding
Debian packages needed for these libraries, and patch the source files
that make use of the "*.min.js" files and make them use the system's
version.

The "problem" is that this approach requires the JavaScript depedencies
to be packaged for Debian, which means more work.  We already have
jquery packaged, but I don't know about the others.

FWIW, this is the approach I'm following other packages of mine.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#871597: RFP: mod_proxy_wstunnel - Apache Module for Websockets support module for mod_proxy

[Sergio Durigan Junior]

On Wednesday, August 09 2017, njos...@riseup.net wrote:

> * Package name: libapache2-mod-proxy-wstunnel
>   Version : 2.4.5
>   Upstream Author : Jim Jagielski
> * URL : https://github.com/apache/httpd/tree/2.4.x/modules/proxy
> * License : Apache-2.0
>   Programming Lang: C
>   Description : Websockets support module for|||mod_proxy|
>
> This module requires the service of mod_proxy. It provides support
> for the tunneling of web socket connections to a backend websockets server.

We already have mod-proxy-wstunnel packaged.  This bug is not correct,
please close it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Difficulties in packaging pagure

[Sergio Durigan Junior]

On Thursday, May 18 2017, Boyuan Yang wrote:

> 在 2017年5月18日星期四 +08 下午12:07:41，SJ Zhu 写道：
>> On Thu, May 18, 2017 at 11:59:36AM +0800, Boyuan Yang wrote:
>> > There are some problems: this packaging uses upstream source code directly
>> > from from Git repository, not the tarball upstream released on https://
>> > pagures.io.
>> 
>> Hi,
>> I import the source by `git archvie` and remove the minified js,
>> then import it to upstream branch like what sergiodj did.
>> 
>> PS. I think I forget to remove some files which filename is not matched
>> by "*.min.js"

Thanks for taking a look at the package and fixing some of the issues.

I'm now back from my vacation and can dedicate some time to pagure
again.

> I have several understandings on it:
>
> Option 1
> 
>
> * Will not use any bundled javascript libraries, no matter minified or not
> * Will depend on corresponding libjs-* packages and make symlinks to provide 
> removed javascript libraries
> * If that package does not exist, package them first

This is what I was trying to do from the beginning.  I packaged some
libjs-* packages last year, but not all of them.  Also, I was following
upstream and noticed that the they add extra dependencies/bump versions
of existing dependencies indiscriminately, which is not very good for
us.  I was trying to talk with upstream and come up with a saner
approach for this, but got sidetracked.

> Option 2
> 
>
> * Only minified javascripts are not acceptable
> * Will use tools like yui-compressor to generate minified js files without 
> using 
> libjs-* packages
> * Write d/copyright for unminified js files

> Option 3
> -
>
> * An mixture of 1 & 2
> * Use libjs-* if that lib has been packaged in Debian
> * If not packaged, use non-minified version and run processor to generate 
> minified js files

After a while, I was starting to wonder whether it would make sense to
follow this approach.  I noticed that packaging all the JS deps would
take a long time (at the time we didn't have Grunt packaged for Debian).

Anyway, I believe it may be possible to pursue the first option now that
Grunt is available.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Moving away from (unsupportable) FusionForge on Alioth?

[Sergio Durigan Junior]

On Sunday, May 14 2017, Boyuan Yang wrote:

> 在 2017年5月14日星期日 CST 下午3:04:26，Pirate Praveen 写道：
>> As far as I understand, the only thing that is blocking is non
>> availability of pagure package.
>> 
>> So helping fix this would help move this forward (currently pagure tests
>> are failing).
>> 
>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>> 
>> After we have the package, then DSA standard processes for new service
>> would follow, I assume.
>
> I'm a little bit confused. The bug forwarding address in #829046 points at 
> http://git.sergiodj.net/, however I couldn't find packaging for pagure 
> anywhere. Seems all deleted sometime before.

Hi guys,

I have recently-ish moved my private things to another server, and I
think the pagure repo got lost somehow.  I'm currently out of town but
I'll fix this as soon as I get back, next weekend.

> The repository on collab-maint stops at September 2016 and lacks the work 
> around December 2016.

I wasn't really using the collab-maint repository because I haven't
created it, but I can move the latest version of my repo there.

On Sunday, May 14 2017, Pirate Praveen wrote:

> On ഞായര്‍ 14 മെയ് 2017 08:20 വൈകു, Boyuan Yang wrote:
>> I'm a little bit confused. The bug forwarding address in #829046 points at 
>> http://git.sergiodj.net/, however I couldn't find packaging for pagure 
>> anywhere. Seems all deleted sometime before.
>
> I don't know why Sergio does not want to create a stable repo at alioth.

It's not that I don't want.  It's that this is my usual workflow when
packaging things on Debian: I do everything on a local git repo, and
then move to collab-maint when the package is ready.

>> The repository on collab-maint stops at September 2016 and lacks the work 
>> around December 2016.
>
> Sergio,
>  Can we finalize on collab-maint and not resetting history for every change?

Sure.  I'll move everything to collab-maint as soon as I get back home,
as I said earilier.

>> Could you tell me where can I find the proper packaging repository?
>
> I have pushed my copy here
> https://git.fosscommunity.in/praveen/pagure
>
> It was originally at git://git.sergiodj.net/debian/pagure-new.git

Thanks for doing that.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Saturday, December 24 2016, Pirate Praveen wrote:

> On ഞായര്‍ 25 ഡിസംബര്‍ 2016 12:01 രാവിലെ, Sergio Durigan Junior wrote:
>> Yep, I did it before building pagure.
>
> It is failing here on sbuild as well.

OK, managed to reproduce it here.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Saturday, December 24 2016, Pirate Praveen wrote:

> On ശനി 24 ഡിസംബര്‍ 2016 11:58 വൈകു, Sergio Durigan Junior wrote:
>> Hm, strange.  I'm using pbuilder/cowdancer to build the package, so it
>> should catch this.  I'll look into it.
>
> Did you update pbuilder recently? You have to run 'pbuilder update' often.

Yep, I did it before building pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Saturday, December 24 2016, Pirate Praveen wrote:

> On ശനി 24 ഡിസംബര്‍ 2016 07:26 വൈകു, Sergio Durigan Junior wrote:
>> Yep, I forgot :-/.  Anyway, pushed now.  Sorry about that.
>
> I'm still getting the same error,
>
> from html5lib.sanitizer import HTMLSanitizer
> ImportError: No module named sanitizer
>
> I don't see either python-bleach or python-html5lib is updated.
>
> This bug is still open
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 May be you have
> an older version of python-html5lib in your system. We have to fix this
> bug to proceed further.

Hm, strange.  I'm using pbuilder/cowdancer to build the package, so it
should catch this.  I'll look into it.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Saturday, December 24 2016, Pirate Praveen wrote:

> On ശനി 24 ഡിസംബര്‍ 2016 11:37 രാവിലെ, Sergio Durigan Junior wrote:
>> Well, I've done some tests here and I think I have a package that
>> builds.  I've updated pagure to an intermediary version, 2.6, and the
>> package builds fine on pbuilder/cowbuilder using the latest unstable.
>> You can find it here:
>> 
>>   http://git.sergiodj.net/?p=debian/pagure-new.git;a=summary
>> 
>> Can you give it a try?  I think we can go with that (even for stretch),
>> if you are OK with it.  The package contains bundled JS libraries, and
>> minifies them during the build, so it's not perfect in this aspect.  But
>> we can fix this later, when we have more time.
>
> I tried to build, but debian directory is missing there. May be you
> forgot to push new commits?

Yep, I forgot :-/.  Anyway, pushed now.  Sorry about that.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Saturday, December 24 2016, Pirate Praveen wrote:

> On ശനി 24 ഡിസംബര്‍ 2016 10:54 രാവിലെ, Sergio Durigan Junior wrote:
>> IMO, if you have time, here's what I would do:
>> 
>> - If you manage to get the building issue sorted out, and if there are
>>   no other critical issues, then I think the package is "good enough"
>>   (for a very relaxed definition of "good") to be put on stretch.  As
>>   Praveen said, we will have 2 months to fix remaining bugs.
>> 
>> - If it is not possible to fix the critical bugs, then I'd suggest going
>>   with the strectch-backports alternative.  It's not a bad option IMHO,
>>   and gives us even more time to really fix the underlying problems.
>
> Its too close to Dec 25, lets take the backports path.

Well, I've done some tests here and I think I have a package that
builds.  I've updated pagure to an intermediary version, 2.6, and the
package builds fine on pbuilder/cowbuilder using the latest unstable.
You can find it here:

  http://git.sergiodj.net/?p=debian/pagure-new.git;a=summary

Can you give it a try?  I think we can go with that (even for stretch),
if you are OK with it.  The package contains bundled JS libraries, and
minifies them during the build, so it's not perfect in this aspect.  But
we can fix this later, when we have more time.

>> Something really concerning me is the fact that pagure keeps adding JS
>> dependencies that are either not packaged on Debian, or that are
>> packaged as part of another, bigger package (usually some big ruby
>> extension or so).  And even in the second case, when the file is already
>> in Debian, it is not really following our guidelines; for example, the
>> .js and .min.js files are being shipped without being built from
>> source.
>
> We now have grunt and gulp in main (rollup and babel are on their way),
> so rebuilding them would be much easier than before (reimplementing the
> build in rules).
>
> The ruby ones are usually just wrappers for the js part. It would be
> easy to separate them if needed. ruby packages can just add a symlink
> instead of embedded copies when we package the js part separately.

Right, that's nice indeed, but it demands work anyway...  But it's
really good that grunt and gulp are now available.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Tuesday, December 20 2016, Pirate Praveen wrote:

> On തിങ്കള്‍ 19 ഡിസംബര്‍ 2016 11:07 വൈകു, Sergio Durigan Junior wrote:
>> Things are starting to calm down, and I intend to get back to packaging
>> pagure.  My intention is to get the latest version imported onto my
>> repository and work on it.  However, I don't think it will be possible
>> to finish everything by Dec 25th.  I know it would be good to get pagure
>> on stretch, but IMHO it is better to make sure everything is working
>> fine first.
>
> Dec 25 is the last day of uploading to sid so it can migrate to stretch
> before freeze. We have time till stretch release (at least 2 months
> more) to fix bugs. We should try our best to have it in stretch and if
> not have it in stretch-backports.

Hm, guys, I am not sure I'll be able to get this ready until the 25th.
There are still issues with the package and well, tomorrow is christmas
eve, so...

I'll keep trying to get the package in a good shape.  I think it is, but
as Praveen mentioned there is still at least one issue when building
it.  Also, I'm not even considering updating the package to the latest
version (2.10.1) now, because that will certainly introduce a lot of new
issues.

IMO, if you have time, here's what I would do:

- If you manage to get the building issue sorted out, and if there are
  no other critical issues, then I think the package is "good enough"
  (for a very relaxed definition of "good") to be put on stretch.  As
  Praveen said, we will have 2 months to fix remaining bugs.

- If it is not possible to fix the critical bugs, then I'd suggest going
  with the strectch-backports alternative.  It's not a bad option IMHO,
  and gives us even more time to really fix the underlying problems.

Something really concerning me is the fact that pagure keeps adding JS
dependencies that are either not packaged on Debian, or that are
packaged as part of another, bigger package (usually some big ruby
extension or so).  And even in the second case, when the file is already
in Debian, it is not really following our guidelines; for example, the
.js and .min.js files are being shipped without being built from
source.

Anyway, some food for thought.  I'll keep you posted if I manage to make
things work on my side.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Any update on pagure?

[Sergio Durigan Junior]

On Tuesday, December 20 2016, Alexandre Viau wrote:

> Hello,

Hey, Alexandre,

>> I'll see if I can continue my work tonight and let you know of any
>> progress.
>
> Any update on that?

I didn't have time to work on pagure that night.  I'll work on it
tomorrow (Wednesday).

> Should someone take over?
>
> As Praveen said, we just need a "good" package to be uploaded before the
> 25th. It can have bugs.

Right.  I'll just finish what I have here and propose it for upload,
then.  The package will have some rough edges here and there but it
should be usable.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: pagure dependencies (JavaScript libraries) packaged

[Sergio Durigan Junior]

On Monday, December 19 2016, Pirate Praveen wrote:

> On Mon, 12 Dec 2016 06:21:35 +1100 Ben Finney  wrote:
>> I don't understand Grunt or Gulp, but from what I could tell those
>> were just being used for typical build tasks. I do understand Make, so
>> I reproduced the build tasks in Debian's ‘rules’ makefile :-)
>
> Btw I just uploaded gulp also to debian (its in NEW). Well, the upstream
> provides a Gruntfile.js or Gulpfile.js, so usually you need to only
> remove hinting and styling tasks (jshint, jscs etc). For grunt, you also
> need to provide /usr/lib/nodejs as path for tasks (if someone helps make
> that default for grunt, we can remove that step as well).
>
>> Please try the library packages (they are currently in ‘experimental’)
>> and let me know whether they are sufficient to allow Pagure packaging
>> to continue.
>
> Since Sergio has been silent for sometime and freeze is approaching fast
> (we have only time till Dec 25, less than a week to get pagure into
> stretch), I will copy his repo to collab-maint and will try to upload it
> to experimental.

Hey guys,

First of all, thank you very much for all the work you have done these
last weeks.

I am sorry I was absent and did to participate; I have been very busy
with work and unable to concentrate on anything else.

Things are starting to calm down, and I intend to get back to packaging
pagure.  My intention is to get the latest version imported onto my
repository and work on it.  However, I don't think it will be possible
to finish everything by Dec 25th.  I know it would be good to get pagure
on stretch, but IMHO it is better to make sure everything is working
fine first.

I'll see if I can continue my work tonight and let you know of any
progress.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#837706: ITP: infinity-libi8x -- Infinity Note Execution Library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: infinity-libi8x
  Version : 
  Upstream Author : Gary Benson <gben...@redhat.com>
* URL : https://infinitynotes.org/wiki/Infinity
* License : LGPL-2.1+
  Programming Lang: C
  Description: Infinity Note Execution Library

  


This is still in alpha state so I plan to release it only on experimental
for now.

I'll talk to the author and decide the best plan to package this, since
it has not been released yet.  Maybe using the latest revision on the
repository is enough.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#837705: ITP: infinity -- Platform-independent system to export information to development tools

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: infinity
  Version : 0.0.3
  Upstream Author : Gary Benson <gben...@redhat.com>
* URL : https://infinitynotes.org/wiki/Infinity
* License : GPL-3+ and LGPL-2.1+
  Programming Lang: Python
  Description: Platform-independent system to export information to development 
tools

 Infinity is a platform-independent system for executables and shared
 libraries to export information to software development tools such as
 debuggers.
 .
 In Infinity, executable and shared library files contain Infinity
 notes in addition to their regular contents. Each Infinity note
 contains a function encoded in a platform-independent instruction set
 that note-consuming tools can load and execute.
 .
 This package provides I8C, a compiler for creating object files
 containing Infinity notes. This package also provides I8X, an execution
 environment that can be used to create unit tests for compiled notes.



This is going to be used as libthread_db replacement on GDB/GLIBC soon.

I thought about using a different name for the package, maybe
infinity-i8, but I'll stick with infinity for now.

It is still in alpha state so I plan to release it only on experimental
for now.

I'll also package libi8x, the client-side library.  ITP will come soon.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

On Tuesday, September 06 2016, Sean Whitton wrote:

> Hello,
>
> On Sat, Sep 03, 2016 at 12:35:06AM -0400, Sergio Durigan Junior wrote:
>> Yes, I use the upstream name as part of the package name.  In this case,
>> the upstream is At.js, so the package name becomes libjs-jquery-at.js.
>
> It might be advisable (for someone looking to fulfill this RFP) to keep
> the .js in the source package name but remove it from the binary package
> name.  Then someone looking to install or depend on the package doesn't
> have to keep track of which of the upstreams like to include the '.js'
> suffix.

I guess this is up to the packager/maintainer.  I myself prefer to
include the .js suffix in order to be as close as possible from
upstream.  My rationale is that someone who wants to include this
library as a dependency will either look for the upstream package name,
or look for some substring that is part of the upstream package name.

But either way, I guess this depends on the preference of the
maintainer.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Sunday, September 04 2016, Ben Finney wrote:

>> To be fair, I recently packaged selectize.js (which also depends on
>> Grunt), and I spent a big time creating a replacement for it using
>> only GNU tools available on Debian, but I don't feel like doing that
>> for every other library.
>
> Please join the discussion at the ‘pkg-javascript-devel’ forum
> 
> to join forces with others in tackling this problem.

To be honest, I do not have time nor interest now to spend my energy
solving this JS problem.  My total focus now is getting pagure ready for
Debian in the best way I can.  Also, from my recent experience packaging
some JS libs, I fear that the building issue will not be solved in the
near future.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836409: RFP: libjs-emojione -- Open source emoji set

[Sergio Durigan Junior]

On Sunday, September 04 2016, Ben Finney wrote:

> On 02-Sep-2016, Sergio Durigan Junior wrote:
>> Probably just a part of the upstream tarball needs to be packaged
>> (the JS part).
>
> What about the artwork, which seems to be the main point of the
> package? Or are you saying that this Debian package would include none
> of the artwork?

I was referring to the part of the package needed for pagure.  Of
course, whoever picks this RFP will have to choose whether she wants to
package everything.

> I have raised <URL:https://github.com/Ranks/emojione/issues/350> an
> issue upstream asking for clarification of the copyright status of the
> artwork.

I don't have a github account, but I'll keep an eye on the issue.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

On Friday, September 02 2016, Sean Whitton wrote:

> Dear Sergio,
>
> Is there some reason some of your package names have '.js' and some of
> them don't?

Hi Sean,

Yes, I use the upstream name as part of the package name.  In this case,
the upstream is At.js, so the package name becomes libjs-jquery-at.js.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

On Friday, September 02 2016, Andrew Shadura wrote:

> Hi,
>
> On 2 September 2016 at 19:17, Sergio Durigan Junior
> <sergi...@sergiodj.net> wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Sergio Durigan Junior <sergi...@sergiodj.net>
>>
>> * Package name: libjs-jquery-at.js
>>   Version : 1.4.1
>>   Upstream Author : Harold.Luo <chord@gmail.com>
>> * URL : https://github.com/ichord/At.js
>> * License : Expat
>>   Programming Lang: JavaScript
>>   Description: Autocompletion library to autocomplete mentions, smileys, etc
>
> It is actually in Debian already: ruby-jquery-atwho-rails, see
> https://bugs.debian.org/832583

Thanks for pointing that out.

It seems to me that the bug has not been fixed yet, right?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Friday, September 02 2016, Ben Finney wrote:

> On 02-Sep-2016, Sergio Durigan Junior wrote:
>> On Friday, September 02 2016, Alexander Wirt wrote:
>> 
>> > On Thu, 01 Sep 2016, Sergio Durigan Junior wrote:
>> >> Anyway, I talked to Alexandre Viau (aviau) about this and he
>> >> assured me that I could bundle the non-minified versions of JS
>> >> libraries needed by the package without problems, because
>> >> ftp-master is OK with this.
>> > Yeah, thats no problem as long as the source (non-monified) is
>> > available.
>
> I think Alexander's statement is only true for what will satisfy legal
> requirements for FTP master.
>
> For satisfying Debian Policy, though, that is not sufficient. Rather:
>
> 4.13. Convenience copies of code
>
> […]
> If the included code is already in the Debian archive in the form
> of a library, the Debian packaging should ensure that binary
> packages reference the libraries already in Debian and the
> convenience copy is not used. If the included code is not already
> in Debian, it should be packaged separately as a prerequisite if
> possible.
>
> On that basis I am requesting you to report RFPs for each of the
> bundled libraries, to package them as Policy §4.13 says.

I am filing the RFP's now.

Just to make things clear, I am totally in favour of packaging
everything we can.  To me, the "if possible" part of the paragraph you
posted is subjective and leaves things open for interpretation.

The real problem with the JS libs that are missing on Debian is their
dependency on Grunt.  To be fair, I recently packaged selectize.js
(which also depends on Grunt), and I spent a big time creating a
replacement for it using only GNU tools available on Debian, but I don't
feel like doing that for every other library.

Anyway, I just wanted to explain better why I think packaging the
missing JS libraries is going to be a huge hassle.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836409: RFP: libjs-emojione -- Open source emoji set

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-emojione
  Version : 2.2.6
  Upstream Author : Ranks.com
* URL : https://github.com/Ranks/emojione
* License : Expat
  Programming Lang: JavaScript and Creative Commons Attribution 4.0 
International
  Description: Open source emoji set

  

Probably just a part of the upstream tarball needs to be packaged (the
JS part).

This package is a dependency for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836408: RFP: libjs-jquery-caret.js -- Get caret position or offset from inputor

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-caret.js
  Version : 0.3.1
  Upstream Author : Harold.Luo <chord@gmail.com>
* URL : https://github.com/ichord/Caret.js
* License : Expat
  Programming Lang: JavaScript
  Description: Get caret position or offset from inputor

  

This package is a dependency for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-at.js
  Version : 1.4.1
  Upstream Author : Harold.Luo <chord@gmail.com>
* URL : https://github.com/ichord/At.js
* License : Expat
  Programming Lang: JavaScript
  Description: Autocompletion library to autocomplete mentions, smileys, etc

  

This package is a dependency for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836406: RFP: libjs-jquery-textcomplete -- Implement auto-complete support for textareas

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-textcomplete
  Version : 1.7.1
  Upstream Author : Yuku Takahashi
* URL : https://github.com/yuku-t/jquery-textcomplete
* License : Expat
  Programming Lang: JavaScript
  Description: Implement auto-complete support for textareas

  libjs-jquery-textcomplete implements auto-complete support for
  textareas.

This package is a dependency for pagure.

A better long description will have to be for this package.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Friday, September 02 2016, Alexander Wirt wrote:

> On Thu, 01 Sep 2016, Sergio Durigan Junior wrote:
>
>> On Thursday, September 01 2016, Alexander Wirt wrote:
>> 
>> > On Mon, 08 Aug 2016, Sergio Durigan Junior wrote:
>> >
>> > Hi,
>> > *snip*
>> >> Well, that's it.  I think I should be able to finish everything by the
>> >> end of the week, and then move to the sponsorship phase :-).
>> > Any updates on that package? 
>> 
>> Yes.
>> 
>> I spent a lot of time packaging some JavaScript dependencies, but
>> unfortunately I won't be able to package them all.  They are *really* a
>> hassle...
>> 
>> Anyway, I talked to Alexandre Viau (aviau) about this and he assured me
>> that I could bundle the non-minified versions of JS libraries needed by
>> the package without problems, because ftp-master is OK with this.
> Yeah, thats no problem as long as the source (non-monified) is available. 

There's a parallel conversation going on with Ben Finney and he wants me
to create RFP's for each missing JS lib so that we can decide which ones
are worth putting more effort to package.  We should probably coordinate
all of these conversations so that everybody is happy.

>> Having said that, I am now working on make pagure use the non-minified
>> JS libs (I've already proposed a patch upstream for this, which is being
>> discussed), and on finishing the other bits of the packaging.
> you don't have to, include the non-minified versions and minify them in the
> buildprocess and use them afterwards. 

Right, that's what I'll do, *if* upstream takes too long to release a
new version :-).  If they release a new version with my patch applied,
then I can use it.

>> As always, you can check the status of my work here:
>> 
>>   http://git.sergiodj.net/?p=debian/pagure.git;a=summary
>> 
>> I try to keep this repo relatively up-to-date.
>> 
>> So yeah, in a nutshell, here's what's missing:
>> 
>>   - Bundle the non-minified versions of the necessary JS libs (note that
>> most of the libs *are* on Debian)
>> 
>>   - Create the necessary symlinks for the libs that are already on
>> Debian
>> 
>>   - Install the conffiles, helper scripts and other stuff (see Fedora
>> package), probably on /usr/share/pagure
>> 
>>   - Write documentation about configuring pagure on Apache (at least)
>> 
>>   - Write documentation about configuring pagure with postfix (see
>> upstream docs; maybe just refer to them)
>> 
>>   - Test installation
>> 
>> Alexandre Viau told me he'd be glad to sponsor this package for me, so
>> that's it.
> Thanks for your work! I am really looking forward in testing it for alioth. 

My pleasure, I'm really looking forward to helping with alioth as well.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Thursday, September 01 2016, Ben Finney wrote:

> On 01-Sep-2016, Sergio Durigan Junior wrote:
>
>> I spent a lot of time packaging some JavaScript dependencies, but
>> unfortunately I won't be able to package them all. They are *really*
>> a hassle...
>
> Can you please:
>
> * Open a RFP bug report for each of the JavaScript libraries that are
>   not in Debian, that are needed for Pagure.
>
> * Set this bug report as blocked by all of those RFP bug reports.
>
> I would like that Pagure not start in a bad way, with bundled
> third-party code, if we can avoid it. I can respond to the RFP reports
> you open.

I can, but then my best estimate is that pagure will not be ready until
the freeze.  Actually, it may not be ready until next year, because, hm,
JS libraries are *really* nasty.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Thursday, September 01 2016, Alexander Wirt wrote:

> On Mon, 08 Aug 2016, Sergio Durigan Junior wrote:
>
> Hi,
> *snip*
>> Well, that's it.  I think I should be able to finish everything by the
>> end of the week, and then move to the sponsorship phase :-).
> Any updates on that package? 

Yes.

I spent a lot of time packaging some JavaScript dependencies, but
unfortunately I won't be able to package them all.  They are *really* a
hassle...

Anyway, I talked to Alexandre Viau (aviau) about this and he assured me
that I could bundle the non-minified versions of JS libraries needed by
the package without problems, because ftp-master is OK with this.

Having said that, I am now working on make pagure use the non-minified
JS libs (I've already proposed a patch upstream for this, which is being
discussed), and on finishing the other bits of the packaging.

I learned a valuable lesson: I will not say "I should be able to finish
everything by XYZ date" anymore :-).  I can say, however, that the
package is in a good shape and I consider it very close to being
finished.

As always, you can check the status of my work here:

  http://git.sergiodj.net/?p=debian/pagure.git;a=summary

I try to keep this repo relatively up-to-date.

So yeah, in a nutshell, here's what's missing:

  - Bundle the non-minified versions of the necessary JS libs (note that
most of the libs *are* on Debian)

  - Create the necessary symlinks for the libs that are already on
Debian

  - Install the conffiles, helper scripts and other stuff (see Fedora
package), probably on /usr/share/pagure

  - Write documentation about configuring pagure on Apache (at least)

  - Write documentation about configuring pagure with postfix (see
upstream docs; maybe just refer to them)

  - Test installation

Alexandre Viau told me he'd be glad to sponsor this package for me, so
that's it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#834865: ITP: libjs-jquery-selectize.js -- Extensible jQuery-based custom select UI control

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-selectize.js
  Version : 0.12.2
  Upstream Author : Brian Reavis <br...@thirdroute.com>
* URL : https://github.com/selectize/selectize.js
* License : Apache-2.0 and Expat
  Programming Lang: JavaScript
  Description: Extensible jQuery-based custom select UI control

 Selectize is an extensible jQuery-based custom select UI
 control. It's useful for tagging, contact lists, country selectors,
 and so on. The goal is to provide a solid & usable experience with a
 clean and powerful API.
 .
 Features
 .
  * Smart Option Searching / Ranking
 .
Options are efficiently scored and sorted on-the-fly (using
libjs-sifter.js). Want to search an item's title *and*
description?  No problem.
 .
  * Caret between items
 .
Order matters sometimes. Use the left and right arrow keys to move
between selected items.
 .
  * Select and delete multiple items at once
 .
Hold down the CTRL key to select more than one item to delete.
 .
  * Díåcritîçs supported
 .
Great for international environments.
 .
  * Item creation
 .
Allow users to create items on the fly (async saving is supported;
the control locks until the callback is fired).
 .
  * Remote data loading
 .
For when you have thousands of options and want them provided by
the server as the user types.
 .
  * Clean API and code
 .
Interface with it and make modifications easily.
 .
  * Extensible
 .
Plugin API for developing custom features (uses
libjs-microplugin.js).
 .
  * Touch Support

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#834466: ITP: libjs-sifter.js -- Library for textually searching arrays and hashes of objects

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-sifter.js
  Version : 0.4.1
  Upstream Author : Brian Reavis <br...@thirdroute.com>
* URL : https://github.com/brianreavis/sifter.js
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Library for textually searching arrays and hashes of objects

 Sifter is a client and server-side library (via UMD) for textually
 searching arrays and hashes of objects by property – or multiple
 properties. It's designed specifically for autocomplete. The process
 is three-step: score, filter, sort.
 .
  * Supports díåcritîçs.
 .
For example, if searching for "montana" and an item in the set has
a value of "montaña", it will still be matched. Sorting will also
play nicely with diacritics.
 .
  * Smart scoring.
 .
 Items are scored / sorted intelligently depending on where a match
 is found in the string (how close to the beginning) and what
 percentage of the string matches.
 .
  * Multi-field sorting.
 .
 When scores aren't enough to go by – like when getting results for
 an empty query – it can sort by one or more fields. For example,
 sort by a person's first name and last name without actually
 merging the properties to a single string.
 .
  * Nested properties.
 .
 Allows to search and sort on nested properties so you can perform
 search on complex objects without flattening them simply by using
 dot-notation to reference fields (ie. nested.property).

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#834417: ITP: libjs-microplugin.js -- Lightweight plugin / dependency system for libraries

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-microplugin.js
  Version : 0.0.3
  Upstream Author : Brian Reavis <br...@thirdroute.com>
* URL : https://github.com/brianreavis/microplugin.js
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Lightweight plugin / dependency system for libraries

 MicroPlugin is a lightweight drop-in plugin architecture for your
 JavaScript library. Plugins can declare dependencies to other plugins
 and can be initialized with options (in a variety of formats). It is
 AMD-compatible and it works identically in Node.js and in a browser.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#833976: ITP: libjs-jquery-dotdotdot -- jQuery plugin for ellipsis on multiple line content

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-dotdotdot
  Version : 1.8.3
  Upstream Author : Fred Heusschen
* URL : https://github.com/FrDH/jQuery.dotdotdot
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery plugin for ellipsis on multiple line content

 A jQuery plugin for advanced cross-browser ellipsis which handles
 multiple line contents depending on whether the text will overlap an
 element.
 .
 You can also add one or several CSS classes to HTML elements to
 automatically invoke the plugin's functionality and some extra
 features.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#833975: ITP: libjs-jquery-stupidtable -- jQuery table sorting plugin

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: libjs-jquery-stupidtable
  Version : 1.0.1
  Upstream Author : Joseph McCullough
* URL : https://github.com/joequery/Stupid-Table-Plugin
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery table sorting plugin

 Most table sorting plugins try to account for a limitless number of
 data types and their limitless ways of being presented. This leads to
 an extremely bloated code base with only a tiny portion of the code
 ever used by your project.
 .
 This plugin avoids that issue by letting you define your own ways of
 sorting table columns. The plugin internally recognizes "int",
 "string", "string-ins" (case-insensitive) and "float", so simple data
 tables will take very little effort on your part.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Sunday, August 07 2016, Ben Finney wrote:

> On 29-Jul-2016, Sergio Durigan Junior wrote:
>
>> Thanks for the help! I'll send you an e-mail as soon as I set up a
>> repository.
>
> I would also like to be able to contribute to maintenance of Pagure in
> Debian.
>
> Can you post an update to this bug report for how volunteers can help:
> repository (at Alioth?), discussion mailing list, etc.

OK, so here's a more detailed update.

I've advanced quite a bit in the packaging, but there are still some
things to do.

I'm using a temporary repository to push what I've done so far; it's
good because I can overwrite history if needed.  The URL is:

  <http://git.sergiodj.net/?p=debian/pagure.git;a=summary>

Eventually I'll move everything to collab-maint/pagure, which should be
the official repository anyway.

All the Python dependencies have finally been packaged, which is good
because I can fully build the package now.  However, there are still
some JavaScript libraries that are (a) not being shipped on Debian, and
(b) bundled in their minified version inside pagure.  This is bad, so my
next task is to package those libraries for Debian.  You can take a look
at them by going to the pagure/static directory on the source tree.

I decided to follow what Fedora does and split the package into several
subpackages.  The first one, pagure, should contain the core
functionality and work out-of-the-box.  Then, the user will also have
the possibility to install:

 - pagure-milters, which takes care of allowing users to comment on
   tickets/pull-requests by e-mail (instead of going to the web
   interface).  This package in specific also has a "problem": it
   depends on postfix to work properly, which is not good because Debian
   ships exim4 as the default MTA.  I've also been investigating how to
   use milters with exim4, and I *may* have a solution.

 - pagure-ev-server, which allows live refreshing of a page when someone
   is viewing it.

 - pagure-webhook-server, which sends notifications to third-party
   services (like fedmsg) using POST http reqs.

There's also the pagure-doc package.

I ran the full testsuite and found a few errors on Debian.  I'm in
constant communication with upstream, so they are aware and I should
send some patches in the next days.

I still have this TODO list:

 - Package missing JS libraries

 - Send patch upstream to use python-bcrypt instead of py-bcrypt to hash
   passwords

 - Take care of d/copyright

 - Correctly fill d/pagure-doc.doc-base

 - Review the *.init scripts and make sure they work

 - Review the *.postinst scripts and make sure they work

 - Write *.postrm scripts

 - Decide whether to run pagure-milters as user/group postfix.  Maybe
   decide that based on what the user is using as MTA, and change it
   accordingly on pagure-milters.postinst.  Same applies for
   pagure-milters.tmpfile.

 - Maybe include more systemd security features on *.service files.

 - Fix some lintian warnings/errors that I've seen

Well, that's it.  I think I should be able to finish everything by the
end of the week, and then move to the sponsorship phase :-).

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Sunday, August 07 2016, Ben Finney wrote:

> On 29-Jul-2016, Sergio Durigan Junior wrote:
>
>> Thanks for the help! I'll send you an e-mail as soon as I set up a
>> repository.
>
> I would also like to be able to contribute to maintenance of Pagure in
> Debian.
>
> Can you post an update to this bug report for how volunteers can help:
> repository (at Alioth?), discussion mailing list, etc.

Thanks for wanting to contribute.

Yesterday I've created a repository at alioth (collab-maint/pagure), but
it's still empty.  I should push my changes later today.

As for a mailing list, I haven't created anything.  So far, we're using
this bug to coordinate the collaboration.  But I can request the
creation of a group on alioth when the package is accepted.

I'll let you know when I push the code today.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#833475: ITP: python-trollius_redis -- Redis client for the PEP 3156 Python event loop ported to Trollius

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: python-trollius_redis
  Version : 0.1.4
  Upstream Author : Ben Jolitz <ben.jolitz+trollius_re...@gmail.com>
* URL : https://github.com/benjolitz/trollius-redis
* License : BSD-2-clause
  Programming Lang: Python
  Description : Redis client for the PEP 3156 Python event loop ported to 
Trollius

  Completely asynchronous, non-blocking client for a Redis server. It
  depends on trollius (asyncio compatible for PEP 3156). It supports
  Python 2 and 3 Trollius-using developers.
  .
  Features
  .
  * Works for the trollius asyncio-compatible (PEP3156) event loop
  * No dependencies except trollius
  * Connection pooling
  * Automatic conversion from unicode (Python) to bytes (inside Redis.)
  * Bytes and str protocols.
  * Completely tested
  * Blocking calls and transactions supported
  * Streaming of some multi bulk replies
  * Pubsub support

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Friday, July 29 2016, Alexandre Viau wrote:

> Hello,

Hi there,

> What is the status of Pagure packaging, and how can I help?

I'm packaging it.  I'll be unavailable during this weekend, but I intend
to get back to work on Tuesday.

> Do you have a repository where you have started to work on the packaging?

Not yet; everything is on my machine.  But I will create a temporary
repository for packaging; then I can let you know.

> Did you compile a list of dependencies, especially unavailable
> dependencies? If yes, can you post it here so that we can start filing ITPs?

I already filed ITPs and took care of all dependencies listed on the
requirements.txt file, so we should be good on that.

> I intend to contribute to this.

Thanks for the help!  I'll send you an e-mail as soon as I set up a
repository.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830825: ITP: python-openid-cla -- OpenID CLA extension for python-openid

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: python-openid-cla
  Version : 1.2
  Upstream Author : Patrick Uiterwijk <puiterw...@gmail.com>
* URL : https://github.com/puiterwijk/python-openid-cla
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenID CLA extension for python-openid

 Implementation of the OpenID CLA extension for python-openid.  The
 purpose of this extension is to allow retrieving a list of signed
 contributor license agreements.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829655: ITP: python-openid-teams -- OpenID teams extension for python-openid

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: python-openid-teams
  Version : 1.1
  Upstream Author : Patrick Uiterwijk <puiterw...@gmail.com>
* URL : https://github.com/puiterwijk/python-openid-teams
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenID teams extension for python-openid

 Implementation of the OpenID teams extension for python-openid.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829506: ITP: flask-multistatic -- A simple flask plugin for overriding static files

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: flask-multistatic
  Version : 1.0
  Upstream Author : Pierre-Yves Chibon <pin...@pingoured.fr>
* URL : https://pagure.io/flask-multistatic
* License : GPL-3+
  Programming Lang: Python
  Description : A simple flask plugin for overriding static files

 Simple flask plugin allowing to override static files, making theming
 flask applications really easy.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829492: ITP: flask-wtf -- Simple integration of Flask and WTForms

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: flask-wtf
  Version : 0.12
  Upstream Author : Dan Jacob, Hsiaoming Yang et al
* URL : https://github.com/lepture/flask-wtf
* License : BSD-3-clause
  Programming Lang: Python
  Description : Simple integration of Flask and WTForms

 Simple integration of Flask and WTForms, including CSRF, file upload
 and Recaptcha integration.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829153: ITP: straight.plugin -- A simple namespaced plugin facility for Python

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: straight.plugin
  Version : 1.4.1
  Upstream Author : Calvin Spealman <ironfro...@gmail.com> et al
* URL : https://github.com/ironfroggy/straight.plugin
* License : Expat (MIT)
  Programming Lang: Python
  Description : A simple namespaced plugin facility for Python

  straight.plugin is a Python plugin loader inspired by twisted.plugin
  with two important distinctions:

  - Fewer dependencies
  - Python 3 compatible

  The system is used to allow multiple Python packages to provide plugins
  within a namespace package, where other packages will locate and
  utilize. The plugins themselves are modules in a namespace package where
  the namespace identifies the plugins in it for some particular purpose
  or intent.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829033: ITP: fpaste -- Tool to paste text and files to the Fedora Pastebin

[Sergio Durigan Junior]

On Thursday, June 30 2016, Paul Wise wrote:

> On Thu, Jun 30, 2016 at 9:20 AM, Simon Richter wrote:
>
>> Can that be merged into the more generic "pastebinit" package?
>
> Looks like it already supports fpaste.org:
>
> $ pastebinit -l | grep fpaste
> - fpaste.org
>
> BTW, Sergio may not be subscribed to debian-devel, so CCing the bug
> might have been a good idea.

Thanks everybody who replied to the ITP!  (And I'm subscribed to
debian-devel, but thanks Paul for the reminder).

I closed the bug yesterday after Sandro Tosi pointed out the same thing:
that pastebinit already supports fpaste.org.  Even though I don't like
the way pastebinit works, I decided to withdraw the ITP.

Oh, it's worth mentioning that pastebinit's support for fpaste is
broken.  I reported a bug upstream about it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829033: ITP: fpaste -- Tool to paste text and files to the Fedora Pastebin

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: fpaste
  Version : 0.3.8.3
  Upstream Author : Jason 'zcat' Farrell <farre...@gmail.com>
* URL : https://pagure.io/fpaste
* License : GPL-3+
  Programming Lang: Python
  Description : Tool to paste text and files to the Fedora Pastebin

  fpaste is a command-line front-end for the Fedora Pastebin service at
  fpaste.org. It allows easy uploading of multiple files, or of
  copy text from stdin, without requiring a web browser. A unique
  fpaste link is returned, which can then be given to others who are
  offering help.

I should have a package ready soon.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#727169: RFP: lua-stdlib -- Standard Lua libraries

[Sergio Durigan Junior]

Control: retitle -1 ITP: lua-stdlib -- Standard Lua libraries
Control: owner -1 !

On Tuesday, October 22 2013, Axel Beckert wrote:

> * Package name: lua-stdlib
>   Version : v35
>   Upstream Author : Reuben Thomas et al.
> * URL or Web page : https://github.com/rrthomas/lua-stdlib
> * License : MIT
>   Description : Standard Lua libraries
>
> Upstream description:
>
>   This is a collection of Lua libraries for Lua 5.1 and 5.2. The
>   libraries are copyright by their authors 2000-2013 (see the AUTHORS
>   file for details), and released under the MIT license (the same
>   license as Lua itself). There is no warranty.
>
>   Stdlib has no prerequisites beyond a standard Lua system.
>
> I maintain GNU Zile in Debian. Upstream currently works on a
> reimplementation of Zile in Lua which seems to become "Zile 3".
>
> This library seems to be a dependency for that rewrite.

I am taking care of this package.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#827875: RFP: python-bugzilla -- Python library and command line tool for interacting with Bugzilla

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-bugzilla -- Python library and command line 
tool for interacting with Bugzilla
Control: owner -1 !

On Tuesday, June 21 2016, Iain R. Learmonth wrote:

> * Package name: python-bugzilla
>   Version : 1.2.2
>   Upstream Author : Cole Robinson
> * URL : https://github.com/python-bugzilla/python-bugzilla
> * License : GPL-2
>   Programming Lang: Python
>   Description : Python library and command line tool for interacting with 
> Bugzilla
>
> This package provides two features, a 'bugzilla' python module for
> talking to a Bugzilla instance over XMLRPC and /usr/bin/bugzilla command
> line tool for performing actions from the command line: create or edit
> bugs, various queries, etc.
>
> Releases are available at: https://pypi.python.org/pypi/python-bugzilla/1.2.2

I'll give this a try.  Probably should have something by the weekend.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#425456: ITP: newlisp -- a LISP like, general purpose scripting language

[Sergio Durigan Junior]

Control: retitle -1 ITP: newlisp -- a LISP like, general purpose scripting 
language

* Package name: newlisp
  Version : 10.7.0
  Upstream Author : Lutz Mueller 
* URL : http://www.newlisp.org/
* License : GPL and compatibles
  Programming Lang: C
  Description : a LISP like, general purpose scripting language

newLISP is a scripting language for developing web applications and
programs in general and in the domains of artificial intelligence (AI)
and statistics.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#423458: dnscap packaged

[Sergio Durigan Junior]

On Sunday, October 18 2015, Andrew Ruthven wrote:

> On Sat, 2015-10-17 at 02:34 -0400, Sergio Durigan Junior wrote:
>> It seems the work on this package has been pretty unstable.  I am
>> planning to work on packaging this (once and for all).  Does anybody
>> have anything against?
>
> Hi Sergio,
>
> I no longer require dnscap at work, but please go ahead and do the work
> that's required.

Alright Andrew, thanks for letting me know.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#423458: dnscap packaged

[Sergio Durigan Junior]

On Sunday, February 24 2013, Marc Haber wrote:

> On Fri, Oct 26, 2012 at 11:19:32AM +1300, Andrew Ruthven wrote:
>> Having it sponsored would be great.  I'm a DM, so I'll be able to
>> continue to maintain it once it is uploaded.  I should really get around
>> to becoming a DD.  ;)
>> 
>> The git repo is here:
>> http://git.catalyst.net.nz/dnscap.git
>> 
>> You can grab the source package and an amd64 binary from here:
>> http://magnus.catalyst.net.nz/~puck/dnscap_debian.tar.gz
>
> I apologize. I missed your message in October and hope that I'll get
> around to preparing the package in the next weeks.
>
> However, I have to sort out two bugs in other packages first (those
> are in wheezy and are therefore more important).

Hi there,

It seems the work on this package has been pretty unstable.  I am
planning to work on packaging this (once and for all).  Does anybody
have anything against?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#780060: [RFS] SleepyHead (ITP: #780060)

[Sergio Durigan Junior]

On Monday, October 12 2015, Andreas Tille wrote:

> On Sun, Oct 11, 2015 at 11:11:42PM -0400, Sergio Durigan Junior wrote:
>> 
>> This is because of #800738.  I fixed it locally but forgot to adjust
>> debian/rules to workaround this issue.  Should also be fixed.
>
> The package builds now.  Thanks for fixing. 
>
> Please note that there is no point in creating a new changelog entry if
> there was no package uploaded.  I dropped the new entry - please pull.

Yeah, I was not sure whether or not it made sense to do that.  On the
one hand, if I had not done that, we would have a tag pointing to a
Debian release (debian/0.9.8-1) and then we would have commits after
this tag.  On the other hand, we would have a second Debian release
without having released the first.

I think the solution would be to retag the latest commit as
debian/0.9.8-1, maybe?

> I get some lintian informations when using lintian with -I option:
>
> I: sleepyhead source: debian-watch-file-is-missing

This is because upstream is still not releasing versioned source
tarballs.  I've made a request to the author, and he told me he is going
to start doing that in the next releases.

> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead calender calendar
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead Libaries Libraries
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead consistancy 
> consistency
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead succesfully 
> successfully
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead independant 
> independent
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead seperately 
> separately
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead softwares software
> I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead GNU Public License 
> GNU General Public License

These are all spelling errors.  I can obviously patch the package
locally and send a patch upstream, but I don't think it's worth delaying
the release because of this (IMHO).

> I: sleepyhead: description-synopsis-might-not-be-phrased-properly

I can fix this.

> I: sleepyhead: possible-documentation-but-no-doc-base-registration

The package has really no documentation (unfortunately).  The three
files that are listed in debian/docs are very simple (rudimentary, I'd
say) texts; that's why I did not register a doc-base.  If you think it
is worth, I can silence this info.

> Since you confirmed to be upstream (or closely connected to upstream) if
> I remember correctly, you might even be easily able to fix the spelling
> issues.

I'm not upstream, I'm just becoming more involved with it.  I will send
patches fixing the spelling errors, and I'll patch the package locally
as well.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: [RFS] SleepyHead (ITP: #780060)

[Sergio Durigan Junior]

On Monday, October 12 2015, Andreas Tille wrote:

> On Mon, Oct 12, 2015 at 12:33:21PM -0400, Sergio Durigan Junior wrote:
>> > Please note that there is no point in creating a new changelog entry if
>> > there was no package uploaded.  I dropped the new entry - please pull.
>> 
>> Yeah, I was not sure whether or not it made sense to do that.  On the
>> one hand, if I had not done that, we would have a tag pointing to a
>> Debian release (debian/0.9.8-1) and then we would have commits after
>> this tag.  On the other hand, we would have a second Debian release
>> without having released the first.
>
> Only packages that really made it to unstable should be tagged.  So
> please remove the tag until the package is accepted.
>  
>> I think the solution would be to retag the latest commit as
>> debian/0.9.8-1, maybe?
>
> Yes.  But as I said *after* ftpmaster has accepted the package.

Right, thanks for the clarification.

>> > I: sleepyhead source: debian-watch-file-is-missing
>> 
>> This is because upstream is still not releasing versioned source
>> tarballs.  I've made a request to the author, and he told me he is going
>> to start doing that in the next releases.
>
> OK.  What we are doing in this case is documenting this like
>
> debian/watch:
>
> # upstream is still not releasing versioned source
> # tarballs.  I've made a request to the author, and he told me he is going
> # to start doing that in the next releases.

Hm, OK.  

>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead calender 
>> > calendar
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead Libaries 
>> > Libraries
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead consistancy 
>> > consistency
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead succesfully 
>> > successfully
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead independant 
>> > independent
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead seperately 
>> > separately
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead softwares 
>> > software
>> > I: sleepyhead: spelling-error-in-binary usr/bin/SleepyHead GNU Public 
>> > License GNU General Public License
>> 
>> These are all spelling errors.  I can obviously patch the package
>> locally and send a patch upstream, but I don't think it's worth delaying
>> the release because of this (IMHO).
>
> Ahh, you are right.  I somehow assumed you are part of the upstream
> team.  I'd recommend to simply forward these issues.

I've already sent a patch fixing these issues.

I decided not to patch the package because that will involve some manual
work on resolving conflicts.  Upstream will likely release a new version
soon anyway.

>> > I: sleepyhead: description-synopsis-might-not-be-phrased-properly
>> 
>> I can fix this.
>> 
>> > I: sleepyhead: possible-documentation-but-no-doc-base-registration
>> 
>> The package has really no documentation (unfortunately).  The three
>> files that are listed in debian/docs are very simple (rudimentary, I'd
>> say) texts; that's why I did not register a doc-base.  If you think it
>> is worth, I can silence this info.
>
> May be it makes sense to provide a lintian-override.  I do not want
> to be over-picky.  Just mentioning the options to a newbie.

OK.

>> > Since you confirmed to be upstream (or closely connected to upstream) if
>> > I remember correctly, you might even be easily able to fix the spelling
>> > issues.
>> 
>> I'm not upstream, I'm just becoming more involved with it.  I will send
>> patches fixing the spelling errors, and I'll patch the package locally
>> as well.
>
> Fine.  Just ping me once you think you are finished with theses things.

It's all done.  I've pushed the new commits to the repository.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: [RFS] SleepyHead (ITP: #780060)

[Sergio Durigan Junior]

On Monday, October 12 2015, Andreas Tille wrote:

>> > Fine.  Just ping me once you think you are finished with theses things.
>> 
>> It's all done.  I've pushed the new commits to the repository.
>
> Uploaded.
>
> Thanks for your preparation

Thank you, Andreas.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: [RFS] SleepyHead (ITP: #780060)

[Sergio Durigan Junior]

On Sunday, October 11 2015, Andreas Tille wrote:

> Hi Sergio,

Hey Andreas,

> thanks for preparing sleepyhead packaging.

My pleasure.

> On Sun, Oct 11, 2015 at 03:06:19AM -0400, Sergio Durigan Junior wrote:
>> As promised, here is the RFS for SleepyHead.  I have just pushed my
>> local repository to /debian-med/sleepyhead.git, and now I would
>> appreciate if you could take a look and let me know what you think.  IMO
>> it is ready to be uploaded.  I haven't uploaded the actual package
>> (.deb/.changes) anywhere, but I can do that if needed.
>
> I think the two README files are not very well designed.  In
> README.source which is targeting at Debian developers something is said
> about sdcards which is most probably some advise for users.  Please move
> this information to README.Debian.  In turn the infromation about
> patches and quality of code should rather be in README.source.

Sigh, that's what you get when you do things tired.  I'm sorry about
that; as may be obvious, I switched the filenames when writing the
advices.  This is now fixed.

> So far for the minor issues.  The majir issue is that the package does
> not build in a pbuilder chroot:
>
> ...
>  debian/rules build
> dh build --buildsystem=qmake --builddirectory=_build/
>dh_testdir -O--buildsystem=qmake -O--builddirectory=_build/
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/build/sleepyhead-0.9.8'
> dh_auto_configure -- ..
> dh_auto_configure: error: unable to chdir to _build
> debian/rules:17: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 2
> ...

This is because of #800738.  I fixed it locally but forgot to adjust
debian/rules to workaround this issue.  Should also be fixed.

Could you give it another try?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: ITP: sleepyhead -- Software for sleep tracking with focus on CPAP treatment

[Sergio Durigan Junior]

On Tuesday, September 29 2015, Andreas Tille wrote:

> Hi Sergio,

Hey Andreas,

> I think this package is health related and thus a target for the Debian
> Med team.  Since we currently do not have a better task (category in
> Blends terminilogy) the package might be mentioned in the tools task[1].
> We might consider a new task like "therapy" or so.

A quick look at Blends tells me that maybe this software could fit in
the 'Medical data' task (because its purpose is to analyse the data
generated by CPAP machines), although 'Tools' is a good option as well.

> I would recommend maintaining the package in the Debian Med team and use
> our VCS (either Git or SVN at your preference).  Here[2] you can find a
> policy how to join the team and and what workflow we use.

Sure, no problem.  I will make sure to subscribe to the mailing list and
request membership of the Debian Med group on Alioth.

Thanks for the tips,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: ITP: sleepyhead -- Software for sleep tracking with focus on CPAP treatment

[Sergio Durigan Junior]

On Monday, September 28 2015, Paul Wise wrote:

> On Mon, Sep 28, 2015 at 8:08 AM, Sergio Durigan Junior wrote:
>
>> Further comments: the package bundles some libraries, so it will need to
>> be adjusted to meet DFSG.
>
> FYI: library bundling isn't a DFSG issue, unless the library is
> non-free of course. If the libraries are non-free then there is a DFSG
> issue even if they aren't bundled. So the DFSG and library bundling
> are orthogonal topics. Of course, bundling of libraries is against
> Debian policy:
>
> https://wiki.debian.org/EmbeddedCodeCopies

Thanks, Paul.  Then I should have said "Debian policy" instead of DFSG.
Anyway, the point is that it is possible to build the software without
the bundled libraries, so I prefer to do it this way.

Thanks

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#780060: ITP: sleepyhead -- Software for sleep tracking with focus on CPAP treatment

[Sergio Durigan Junior]

Control: retitle -1 ITP: sleepyhead -- Software for sleep tracking with focus 
on CPAP treatment

Owner: sergi...@sergiodj.net

* Package name: sleepyhead
  Version : 0.9.8 (git branch)
  Upstream Author : Mark Watkins
* URL : http://sourceforge.net/projects/sleepyhead/
* License : GPLv3
  Programming Lang: C++
  Description : Software for sleep tracking with focus on CPAP treatment
  
Further comments: the package bundles some libraries, so it will need to
be adjusted to meet DFSG.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#788931: RFP: libdigest-md5-perl - Perl interface to the MD5 Algorithm

[Sergio Durigan Junior]

On Tuesday, June 16 2015, Svetlana A. Tkachenko wrote:

> The Digest::MD5 module allows you to use the RSA Data Security
> Inc. MD5 Message Digest algorithm from within Perl programs. The
> algorithm takes as input a message of arbitrary length and produces as
> output a 128-bit "fingerprint" or "message digest" of the input.
>
> Note that the MD5 algorithm is not as strong as it used to be. It has
> since 2005 been easy to generate different messages that produce the
> same MD5 digest. It still seems hard to generate messages that produce
> a given digest, but it is probably wise to move to stronger algorithms
> for applications that depend on the digest to uniquely identify a
> message.
>
> The Digest::MD5 module provide a procedural interface for simple use,
> as well as an object oriented interface that can handle messages of
> arbitrary length and which can read files directly.

I can understand the reason for wanting this module packaged, but I am
also a bit concerned about providing more tools to "encourage" the use
of MD5.  As has been mentioned above, this algorithm is not strong and
contains several security flaws.

There's an interesting discussion going on the coreutils mailing list
about a possible substitute:

  

Anyway, my two cents.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#784405: Status report

[Sergio Durigan Junior]

Heya,

I just figured I'd send a status report on this ITP.  I have already
created (and tested) a Debian package for rnetclient.  Now, I am waiting
on Thadeu Cascardo (DD) to review the package and probably submit it to
the official repository.

I expect Cascardo to be able to take a look at the package this next
weekend.  I will report back when I have more information.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mm710t2@sergiodj.net

Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

[Sergio Durigan Junior]

On Thursday, May 07 2015, Henrique de Moraes Holschuh wrote:

 That is actually a pretty good solution!  I am still learning the terms
 and the whole process here, but jessie-updates, according to:
 
   https://www.debian.org/News/2011/20110215
   (thanks to Cascardo for providing the link)
 
 would indeed be the ideal place for rnetclient, according to this
 criterion:
 
   - Packages that need to be current to be useful (e.g. clamav).

 I am well versed with stable-updates, I upload to it several times per
 year due to intel-microcode.  Unless there is previous arrangement with
 the stable release managers, an upload to stable-proposed-updates it is
 not always going to be fast enough for this.  keep current doesn't
 mean rush into stable every time, after all.

Oh, sure, I did not mean to lecture you, I am well aware of your Debian
fame.  Sorry if it sounded like that.

As for being fast enough, Receita Federal usually gives 2 months to
prepare and submit your tax report, and the majority of the population
usually wait until the last week to fulfill their duties, so maybe it is
reasonable to expect that, if rnetclient enters the stable-updates repo
in the middle of the timeframe of 2 months (i.e., 1 month after RFB
published the proprietary versions of the softwares), we will still have
plenty of users benefitted by this.  Does this sound feasible?

 IMHO, it would be far better to have someone maintain the debian
 packaging of this stuff upstream, in a apt-gettable repository that
 can be added to sources.list.  Such a repository, although unofficial,
 could be both Debian and Ubuntu-friendly, and target also the LTS
 branches of Debian and Ubuntu.  This side-steps all the issues I raised.

It seems that the only remaining issue was deciding which repository
would be a better fit for the program, and if the proposal of putting it
in the stable-updates is accepted, then we're golden.

I had considered the option of maintaining the Debian infrastructure
upstream when I saw your first message (actually, even before I posted
the ITP!), but I still think it is more beneficial to have rnetclient in
the official repository.  It would, for example, be much harder to be
able to provide ports for different architectures just like Debian does
but without using Debian's infrastructure; I could mention other good
to have things as debbugs here, but I think you've got the point :-).

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qru9pi@sergiodj.net

Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

[Sergio Durigan Junior]

[ Cc'ing Thadeu Cascardo, who developed rnetclient and is a DD. ]

On Thursday, May 07 2015, Henrique de Moraes Holschuh wrote:

 On Wed, May 6, 2015, at 01:51, Sergio Durigan Junior wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Sergio Durigan Junior sergi...@sergiodj.net
 
 * Package name: rnetclient
   Version : 2015.1
   Upstream author : Thadeu Cascardo, Sergio Durigan Junior, Alexandre Oliva
 * URL : http://wiki.libreplanetbr.org/rnetclient/
 * License : GPLv3+
   Programming Lang: C
   Description : A Client to submit the Brazilian Income Tax Report
 to the Brazilian Tax Authority
 
 rnetclient is a Free Software that can be used to submit the Brazilian
 Income Tax Report to the Brazilian Tax Authority (Receita Federal).  It
 is the outcome of reverse-engineering ReceitaNet, the official and
 proprietary software that Receita Federal develops.

 What's the real point of this package?  One actually needs to install
 the tax-report-building program from RFB (IRPF20xx) to have anything for
 rnetclient to transmit, at which point you might as well install
 ReceitaNet since you're already running RFB-provided java code anyway.

Hey, Henrique!

Thanks for the comments.

The real point of this package is to provide freedom for those who have
to declare their income tax in Brazil.  Of course, as you have
mentioned, rnetclient solves one side of the equation, which is
sending the report to the Receita Federal.  As for the other side (which
is preparing the report), you do not necessarily have to install the
proprietary version of the program that is published by the Receita
Federal; instead, you can install IRPF-Livre, a Free Software made by
Alexandre Oliva (since 2007):

  http://www.fsfla.org/svn/fsfla/software/irpf-livre-2015/

Every year, he releases a new code to be tested.  The reports generated
by IRPF-Livre can be successfully transmited by rnetclient, as has been
tested by Alexandre Oliva and others.  Unfortunately, IRPF-Livre is not
a Debian package (yet?), but then again, the proprietary version is
obviously not on Debian either.

 Also, what's the official position of RFB regarding the existence, and
 use of this program?

There is no official position about both programs so far, to the extent
of my knowledge.  What exists (or existed; I don't remember all the
details now) is a lawsuit by Alexandre Oliva who has been trying to make
RFB release the code of the proprietary softwares mentioned above.  But
this is offtopic to this discussion, I think.

 Regardless of whether the process of reverse engineering the ReceitaNet
 protocol is legal or not (I don't know, so I am not assuming anything),

IANAL, but in general reverse engineering is not forbidden in Brazil.  I
found some documents about this, and I can provide them if needed.

 actually connecting to RFB servers using this program might well not be
 legal.

 Not to mention it can cause harm to rnetclient users if RFB decides
 that they object to tax reports submited through rnetclient, and we
 might find ourselves in legal trouble over that as well, there's the
 whole enticing others to use the rnetclient program angle that could
 be played against Debian (in this case, it might well end up being
 directed at Brazillian DDs since RFB won't be able to target SPI or
 Debian itself).

That is indeed a good point; I don't know if Debian as a project is
willing to take this risk.  I mean, there is always a risk of RFB
deciding that they won't accept tax reports made by IRPF-Livre and/or
submitted by rnetclient; in this case, we would have to think in another
option.  As I said, Alexandre Oliva has been doing IRPF-Livre since
2007, and last year some people used rnetclient to submit their reports,
and nothing unusual happened.  I think it is not very...  dangerous (I
did not want to use that word, but...) for Debian to have rnetclient on
its repositories, but that is a personal opinion of someone who is
starting to contribute to Debian.

 Also, ReceitaNet is often updated, it went from version 4 (tax report of
 2014) to version 7 (tax report of 2015), rnetclient would have to be
 kept up-to-date if such changes in ReceitaNet are in any way related to
 the protocol or servers it should connect to submit the tax report. 
 This can cause operational issues if rnetclient makes it to Debian
 stable, since the program must be working perfectly during the tax
 submission window.

Yes, that is another good point.  I don't know what would be the best
way to solve this.  I know rnetclient in stable would probably not be
updated as frequent as it should.

 In fact, the upstream homepage has this notice (loosely translated from
 pt_BR):
 Version 2015.0 did not support fully the tax report format for 2015.
 This problem has been fixed in version 2015.1. We wait reports of both
 sucessful and non-sucessful use of rnetclient 2015.1 in our mailing
 list.

Yes, but I don't see what's the problem.  rnetclient has

Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

[Sergio Durigan Junior]

On Thursday, May 07 2015, Frederic Peters wrote:

 What's the real point of this package?  One actually needs to install
 the tax-report-building program from RFB (IRPF20xx) to have anything for
 rnetclient to transmit, at which point you might as well install
 ReceitaNet since you're already running RFB-provided java code anyway.

 It looks like the initial part wouldn't require network access; this
 would be quite an important difference.

I'm not sure I understood the sentence, but yeah, the program used to
prepare the tax report indeed does not need network access.

 Regardless of whether the process of reverse engineering the ReceitaNet
 protocol is legal or not (I don't know, so I am not assuming anything),
 actually connecting to RFB servers using this program might well not be
 legal.

 I don't know anything about Brazilian reverse engineering, or others,
 laws, and what would apply here.  But I wouldn't stop at regardless
 it is legal or not and might not well be legal without any details.

Thanks, that's my feeling as well.  And that's why those programs were
developed.  But as I said in my reply to Henrique, reverse engineering
is not against the Brazilian copyright law.

 Also, ReceitaNet is often updated, it went from version 4 (tax report of
 2014) to version 7 (tax report of 2015), rnetclient would have to be
 kept up-to-date if such changes in ReceitaNet are in any way related to
 the protocol or servers it should connect to submit the tax report. 
 This can cause operational issues if rnetclient makes it to Debian
 stable, since the program must be working perfectly during the tax
 submission window.
 
 In fact, the upstream homepage has this notice (loosely translated from
 pt_BR):
 Version 2015.0 did not support fully the tax report format for 2015.
 This problem has been fixed in version 2015.1. We wait reports of both
 sucessful and non-sucessful use of rnetclient 2015.1 in our mailing
 list.

 This makes it an appropriate candidate for jessie-updates.

That is actually a pretty good solution!  I am still learning the terms
and the whole process here, but jessie-updates, according to:

  https://www.debian.org/News/2011/20110215
  (thanks to Cascardo for providing the link)

would indeed be the ideal place for rnetclient, according to this
criterion:

  - Packages that need to be current to be useful (e.g. clamav).

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qsuivo@sergiodj.net

Bug#784405: ITP: rnetclient -- Client to submit the Brazilian Income Tax Report to the Brazilian Tax Authority

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior sergi...@sergiodj.net

* Package name: rnetclient
  Version : 2015.1
  Upstream author : Thadeu Cascardo, Sergio Durigan Junior, Alexandre Oliva
* URL : http://wiki.libreplanetbr.org/rnetclient/
* License : GPLv3+
  Programming Lang: C
  Description : A Client to submit the Brazilian Income Tax Report
to the Brazilian Tax Authority

rnetclient is a Free Software that can be used to submit the Brazilian
Income Tax Report to the Brazilian Tax Authority (Receita Federal).  It
is the outcome of reverse-engineering ReceitaNet, the official and
proprietary software that Receita Federal develops.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw1i2trt@sergiodj.net