Bug#769375: RFS: lightmdeditor/1.0-2 [ITP]

2014-11-12 Thread Bhavyanshu Parasher
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "lightmdeditor"

* Package name   : lightmdeditor
  Version  : 1.0-2
  Upstream Author: Bhavyanshu Parasher 
* URL  : https://github.com/bhavyanshu/LightMd_Editor
* License : GPL-3
  Section  : editors

It builds those binary packages:

lightmdeditor - LightMd Editor is a markdown editor.
A markdown editor application which supports syntax highlighting,
multiple themes, focus mode and other features for distraction free
editing.


To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/lightmdeditor


Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/l/lightmdeditor/lightmdeditor_1.0-2.dsc

More information about this package can be obtained from 
https://github.com/bhavyanshu/LightMd_Editor


Regards,
Bhavyanshu Parasher


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/149a7b65893.f9239603110112.9076433042232922...@bhavyanshu.me



Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

2014-11-12 Thread Russ Allbery
Raphael Hertzog  writes:

> In fact, I believe they should be mostly disjoint. As a maintainer, I
> welcome help on all bugs.

> When I tag a bug help it's because I believe that I don't have the
> skills to fix it by myself and that external help is really needed to
> make some progress.

+1.

I use help as a sort of variant of wontfix.  It means that I'm not opposed
to a fix for that bug, but I'm not going to work on it, either because I
don't have the time or I don't have the necessary skills.  Therefore,
unless someone else works on it, it's not going to get fixed.

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


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878ujflkv6@hope.eyrie.org



Re: changes file issue when packaging for backports

2014-11-12 Thread quidame
Oops,

not Priority: but Urgency:

quidame  wrote:
> Hi,
> 
> I try to backport bilibop_0.4.22 source package (native). If only changes
> from 0.4.22 to 0.4.22~bpo70+1 are copied in to the changes file, lintian
> complains with the 'backports-changes-missing' error tag [1]. If I add
> -v0.4.21 dpkg-genchanges, the resulting changes file says:
> 
> Priority: medium
> [...]
> Closes: 750507 756086
> 
> This overrides the priority of thr bpo package (low, in wheezy-backports);
> medium is the priority of 0.4.22 in unstable. It claims to close two bugs
> that are already closed in 0.4.22; more, one of these bugs id specific to
> jessie/sid, and the bugfix is reverted in the bpo. should I edit the changes
> file to modify Priority: field and modify or remove Closes: field ? Or replave
> -v0.4.21 option by something more relevant (shortened changelog entry
> for 0.4.22) ? Or can I let it go 'as is' ?
> 
> Cheers,
> quidame 
> 
> [1] https://lintian.debian.org/tags/backports-changes-missing.html
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/n1r-8jve8c2...@safe-mail.net


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/n1r-nlwieok...@safe-mail.net



changes file issue when packaging for backports

2014-11-12 Thread quidame
Hi,

I try to backport bilibop_0.4.22 source package (native). If only changes
from 0.4.22 to 0.4.22~bpo70+1 are copied in to the changes file, lintian
complains with the 'backports-changes-missing' error tag [1]. If I add
-v0.4.21 dpkg-genchanges, the resulting changes file says:

Priority: medium
[...]
Closes: 750507 756086

This overrides the priority of thr bpo package (low, in wheezy-backports);
medium is the priority of 0.4.22 in unstable. It claims to close two bugs
that are already closed in 0.4.22; more, one of these bugs id specific to
jessie/sid, and the bugfix is reverted in the bpo. should I edit the changes
file to modify Priority: field and modify or remove Closes: field ? Or replave
-v0.4.21 option by something more relevant (shortened changelog entry
for 0.4.22) ? Or can I let it go 'as is' ?

Cheers,
quidame 

[1] https://lintian.debian.org/tags/backports-changes-missing.html


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/n1r-8jve8c2...@safe-mail.net



Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

2014-11-12 Thread Don Armstrong
On Wed, 12 Nov 2014, Stéphane Aulery wrote:
> Le mardi 11 novembre 2014 à 03:54:50, Don Armstrong a écrit :
> > On Wed, 12 Nov 2014, Stéphane Aulery wrote:
> > > Le mardi 11 novembre 2014 à 03:07:31, Don Armstrong a écrit :
> > > > 
> > > > The existing help tag is really for bugs for which the maintainer needs
> > > > or wants help; these are basically a superset of entry-point, and bugs
> > > > which are more difficult than it would be reasonable for a new
> > > > contributor to help.
> > > 
> > > Thanks. It will be good to mention in the documentation of BTS.
> > 
> > Please suggest a clearer wording if it's not clear enough.
> 
> Here is a proposal:

Excellent; thanks. I'm going to make these gender-neutral, and then I'll
commit them.

This is the last chance for someone to object to entry-point as the tag
name. If I hear no objections, I'll put this in place on Friday, around
18:00 UTC.

-- 
Don Armstrong  http://www.donarmstrong.com

Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112235405.ga32...@teltox.donarmstrong.com



Re: Depends on exact version

2014-11-12 Thread Henrique de Moraes Holschuh
On Wed, 12 Nov 2014, Roger Light wrote:
> Could you try ${binary:Version} instead?

(= ${binary:Version}) can break binNMUs.  Be careful.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112233246.ga19...@khazad-dum.debian.net



Re: Depends on exact version

2014-11-12 Thread Roger Light
Hi Daniel,

Could you try ${binary:Version} instead?

Cheers,

Roger


On Wed, Nov 12, 2014 at 9:30 PM, Daniel Lintott  wrote:
> I have a package which is split into two sources (a server and gui). The
> server version should match the gui version (upstream version) at all times.
>
> Because of this when I'm creating the meta-package that will depend on
> both the gui and server, should be versioned to to be the same upstream
> version.
>
> To try and achieve this I've used the following:
>
>> Depends: ${misc:Depends},
>>  gns3-gui (= ${source:Upstream-Version}),
>>  gns3-server (= ${source:Upstream-Version})
>
> as I'm not worried about what the Debian revision is... but this doesn't
> seem to work when it comes to aptitude.
>
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>>  gns3 : Depends: gns3-gui (= 1.1) but it is not going to be installed
>> Depends: gns3-server (= 1.1) but it is not going to be installed
>> E: Unable to correct problems, you have held broken packages.
>
> From apt-cache policy gns3-*:
>
>> gns3-gui:
>>   Installed: (none)
>>   Candidate: 1.1-1~exp1
>>   Version table:
>>  1.1-1~exp1 0
>> 100 http://echo.internal.serverb.co.uk/debian/ experimental/contrib 
>> amd64 Packages
>
>> gns3-server:
>>   Installed: (none)
>>   Candidate: 1.1-1~exp1
>>   Version table:
>>  1.1-1~exp1 0
>> 100 http://echo.internal.serverb.co.uk/debian/ experimental/contrib 
>> amd64 Packages
>
> Any idea where I've gone wrong here?
>
> Regards
>
> Daniel
>


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cah7zdyd8r8gc-vett0iwbbewkd+peu3mvc_zz9cb3wvtqro...@mail.gmail.com



Re: Depends on exact version

2014-11-12 Thread Andreas Cadhalpun

Hi Daniel,

On 12.11.2014 22:30, Daniel Lintott wrote:

I have a package which is split into two sources (a server and gui). The
server version should match the gui version (upstream version) at all times.

Because of this when I'm creating the meta-package that will depend on
both the gui and server, should be versioned to to be the same upstream
version.

To try and achieve this I've used the following:


Depends: ${misc:Depends},
  gns3-gui (= ${source:Upstream-Version}),
  gns3-server (= ${source:Upstream-Version})

[...]

Any idea where I've gone wrong here?


You require the exact upstream version (1.1).
This can't work, because there will always be the Debian revision added 
(1.1-1~exp1).


What should work better is '>= ${source:Upstream-Version}'.

However, that is not enough to guarantee that the upstream versions 
always match. One could then have e.g.:

gns3= 1.1-1
gns3-gui= 1.1-1
gns3-server = 1.2-1

If you want to prevent that, you can add appropriate Breaks:
gns3-server:
 Breaks: gns3-gui (< ${source:Upstream-Version})
gns3-gui:
 Breaks: gns3-server (< ${source:Upstream-Version})

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463e1dd.7040...@googlemail.com



Depends on exact version

2014-11-12 Thread Daniel Lintott
I have a package which is split into two sources (a server and gui). The
server version should match the gui version (upstream version) at all times.

Because of this when I'm creating the meta-package that will depend on
both the gui and server, should be versioned to to be the same upstream
version.

To try and achieve this I've used the following:

> Depends: ${misc:Depends},
>  gns3-gui (= ${source:Upstream-Version}), 
>  gns3-server (= ${source:Upstream-Version})

as I'm not worried about what the Debian revision is... but this doesn't
seem to work when it comes to aptitude.

> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  gns3 : Depends: gns3-gui (= 1.1) but it is not going to be installed
> Depends: gns3-server (= 1.1) but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.

From apt-cache policy gns3-*:

> gns3-gui:
>   Installed: (none)
>   Candidate: 1.1-1~exp1
>   Version table:
>  1.1-1~exp1 0
> 100 http://echo.internal.serverb.co.uk/debian/ experimental/contrib 
> amd64 Packages

> gns3-server:
>   Installed: (none)
>   Candidate: 1.1-1~exp1
>   Version table:
>  1.1-1~exp1 0
> 100 http://echo.internal.serverb.co.uk/debian/ experimental/contrib 
> amd64 Packages

Any idea where I've gone wrong here?

Regards

Daniel



signature.asc
Description: OpenPGP digital signature


Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

2014-11-12 Thread Stéphane Aulery
Le mardi 11 novembre 2014 à 03:54:50, Don Armstrong a écrit :
> On Wed, 12 Nov 2014, Stéphane Aulery wrote:
> > Le mardi 11 novembre 2014 à 03:07:31, Don Armstrong a écrit :
> > > 
> > > The existing help tag is really for bugs for which the maintainer needs
> > > or wants help; these are basically a superset of entry-point, and bugs
> > > which are more difficult than it would be reasonable for a new
> > > contributor to help.
> > 
> > Thanks. It will be good to mention in the documentation of BTS.
> 
> Please suggest a clearer wording if it's not clear enough.

Here is a proposal:

entry-point
The maintainer can easily solve this bug by himself, but he
wants to take it to new contributors who wish to get involved
in Debian. Bugs of any difficulty can be offered in order to
attract and increase skill.

The maintainer is committed to providing assistance to new
contributors. This gateway is a complement more accessible to
mentors.debian.net.

help
The maintainer is requesting help with dealing with this bug.
Either he does not have the skills and wishes collaboration,
or is overloaded and wants to delegate to someone who will
treat alone. For newcomers see entry-point.

-- 
Stéphane Aulery


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112184233.ga5...@free.fr



Bug#765958: marked as done (RFS: python-riemann-client/5.1.1-1 [ITP#764739])

2014-11-12 Thread Debian Bug Tracking System
Your message dated Wed, 12 Nov 2014 16:24:42 +
with message-id 
and subject line closing RFS: python-riemann-client/5.1.1-1 [ITP#764739]
has caused the Debian Bug report #765958,
regarding RFS: python-riemann-client/5.1.1-1 [ITP#764739]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
765958: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765958
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-riemann-client"

* Package name: python-riemann-client
 Version : 5.1.1-1
 Upstream Author : Sam Clements
* URL : https://github.com/borntyping/python-riemann-client
* License : MIT
 Section : python

It builds those binary packages:

  python-riemann-client - Riemann client library and command line tool
for Python

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/python-riemann-client


Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/p/python-riemann-client/python-riemann-client_5.1.1-1.dsc

I maintain the package on collab-maint. It can be found here:
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=collab-maint/python-riemann-client.git;a=summary

It depends on the python-click library, which I have also packaged. The
RFS for python-click is Bug#764958.


Regards,
  Alexandre Viau



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Package python-riemann-client has been removed from mentors.--- End Message ---


Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

2014-11-12 Thread Raphael Hertzog
On Tue, 11 Nov 2014, Don Armstrong wrote:
> The existing help tag is really for bugs for which the maintainer needs
> or wants help; these are basically a superset of entry-point, and bugs
> which are more difficult than it would be reasonable for a new
> contributor to help.
> 
> I suppose it would be reasonable for bugs which are tagged entry-point
> to also be tagged help, but I'm not going to mandate that.

In fact, I believe they should be mostly disjoint. As a maintainer, I
welcome help on all bugs.

When I tag a bug help it's because I believe that I don't have the skills
to fix it by myself and that external help is really needed to make some
progress.

On the contrary, a bug tagged "entry-point" is a bug that I can perfectly
fix by myself but that I don't handle immediately because I believe
that it would be a good task for a new contributor to jump in (and
possibly also because I have other more pressing things to do).

So we should possibly update the descriptions of the tags accordingly.
What do you think?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112101223.gi27...@home.ouaza.com



Re: Facilitating contributions by newcomers

2014-11-12 Thread Mattia Rizzolo
On Wed, Nov 12, 2014 at 9:50 AM, Christian Kastner  wrote:
> I'd argue it's good enough for the task itself, but searching for areas
> to contribute to could still be improved significantly.

I agree.

> For example,
> given the following list of motivations a new contributor might have
>
>"I want to help fix simple bugs in C programs."
>"I want to help fix difficult bugs in Java programs."
>"I want to help with translations."
>"I want to help multiarchify packages."

I think you all may be interested on http://harvest.ubuntu.com/opportunities/
Not sure on how it works, but it collects data from different services
(e.g., merges.u.c) other than the bug tracker, and it's able to
present opportunities in various fields, sorting them by different
criteria.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymeulmwsj10vsker-lgckbfm21wn_pzl0natndkagrtf...@mail.gmail.com



Re: Facilitating contributions by newcomers

2014-11-12 Thread Christian Kastner
On 2014-11-12 02:14, Don Armstrong wrote:
> On Wed, 12 Nov 2014, Christian Kastner wrote:
>> Going even further, what would you see as possible solutions for
>> augmenting bug reports tagged 'entry-point' with the information I
>> mention in first post, ie:
>>
>> On 2014-11-09 20:20, Christian Kastner wrote:
>> >   * A specific objective (bug fix, enhancement, debugging, cleanup,
>> > documentation, translation, ...). This should probably be tied to a
>> > Debian bug number.
>> >
>> >   * A description of the required skills (packaging, debugging, C, ...)
>> >
>> >   * A difficulty rating (1:low to 5:very high)
>> >
>> >   * An estimation for the amount of work to be done (hours, days)
>> >
>> >   * An urgency (influenced by severity, popcon, ...)
>> >
>> >   * A list of one or more mentors will to help.
>>
>> Personally, I think that the "required skills" and the "difficulty
>> rating" would be very valuable additions.
>>
>> It may be possible to infer the other attributes from the other metadata
>> eg: urgency ~ severity.
> 
> I'd suggest using the BTS's summary command, which enables you to
> nominate a message whose first paragraph will summarize the bug.
> 
> This is free form, but that's probably good enough (at least for
> starters).

I'd argue it's good enough for the task itself, but searching for areas
to contribute to could still be improved significantly. For example,
given the following list of motivations a new contributor might have

   "I want to help fix simple bugs in C programs."
   "I want to help fix difficult bugs in Java programs."
   "I want to help with translations."
   "I want to help multiarchify packages."
   
a search by the "entry-point" tag alone would indeed reduce the list of
issues to hundreds (thousands?) of entries, but that's still a lot. On
the other hand, if these were possible, I think the value should be
evident (FTR, all flags to how-can-i-help made up):

$ how-can-I-help --difficulty low --skills C
$ how-can-I-help --difficulty hard --skills Java
$ how-can-I-help --type translation
$ how-can-I-help --difficulty low --skills packaging

And, of course, a web interface for entry-point also wouldn't hurt, I
guess.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/0b0a7bc39a3fd47693eb1c524f69b...@kvr.at