Re: Rescue Plan for apt-listbugs

[Jan Hauke Rahm]

On Mon, Oct 04, 2010 at 11:29:28PM +0200, Francesco Poli wrote:
> Hi everybody,
> I need help.
> 
> I am not a DD, nor a DM; nonetheless, I am one of the two current
> co-maintainers of apt-listbugs.
> The other one is Ryan Niebur.
> 
> My problem is that I've lost contact with him: he seems to be currently
> (almost) MIA.

FWIW, I have been working with him as well and found him rather inactive
lately. I've now contacted him and will see where this leads.

Francesco, if you fear someone's MIA, please feel free to contact (or
CC) the MIA team at m...@qa.debian.org. I just happened to see your
concerns here.

Hauke
on behalf of Debian QA/MIA

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: RFS: ripit, a textbased audio CD ripper (updated package) 2nd attempt

[Sven Hoexter]

On Mon, Oct 04, 2010 at 11:29:10PM +0200, Elimar Riesebieter wrote:

Hi,

> I am looking once again for a sponsor for the new version 3.9.0-1 of
> my package "ripit". It should be uploaded to experimental, please.

Uploaded. Thanks. :)

Sven
-- 
And I don't know much, but I do know this:
With a golden heart comes a rebel fist.
 [ Streetlight Manifesto - Here's To Life ]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101005084257.gb1...@marvin.lan

Re: Rescue Plan for apt-listbugs

[Manuel A. Fernandez Montecelo]

Hi,

Just copying the reply to the original author... he already said that he's 
not subscribed to the mailing list ;)

Cheers.


On Tuesday 05 October 2010 09:27:57 Jan Hauke Rahm wrote:
> On Mon, Oct 04, 2010 at 11:29:28PM +0200, Francesco Poli wrote:
> > Hi everybody,
> > I need help.
> > 
> > I am not a DD, nor a DM; nonetheless, I am one of the two current
> > co-maintainers of apt-listbugs.
> > The other one is Ryan Niebur.
> > 
> > My problem is that I've lost contact with him: he seems to be currently
> > (almost) MIA.
> 
> FWIW, I have been working with him as well and found him rather inactive
> lately. I've now contacted him and will see where this leads.
> 
> Francesco, if you fear someone's MIA, please feel free to contact (or
> CC) the MIA team at m...@qa.debian.org. I just happened to see your
> concerns here.
> 
> Hauke
> on behalf of Debian QA/MIA

-- 
Manuel A. Fernandez Montecelo 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201010051054.30340.manuel.montez...@gmail.com

Re: Review of gnome-gmail

[Michael Tautschnig]

Hi Niels, hi list,

[...]

> 
> Thanks for your interest in Debian. It looks like you have not received
> any feedback on nor found a sponsor for your package yet. I have spent
> some time reviewing your package and got a few comments for you, which I
> hope you find useful.
> 
> Please note that I am not a Debian Developer (DD), so I cannot sponsor
> your package even if you address all my comments/remarks. Also neither
> python nor GNOME is my strong suit, so there are possibly some
> python/GNOME specific things that I have missed in my review.
> 

I think this is a prime example of how things could work, ideally. There is
absolutely no need for reviews to be only done by DDs! In fact, I think there
already was a proposal (I couldn't dig it up in a brief search, though) that for
each RFS people should do a review of someone else's RFS/package. Again, no need
to be a DD to do this. All you need a DD for is *sponsoring*. Surely any sponsor
will not upload the package without doing another brief review, but this one
will really take a lot less time. 

[...] (very detailed and hopefully helpful review)

@David: Once all the issues reported by Niels are fixed, I'd offer to do the
sponsoring. Please ping me via private mail, should I miss your email to the
list.

Best regards,
Michael



pgpeG1yT0REMz.pgp
Description: PGP signature

Re: Four days

[Michael Tautschnig]

[...]

> 
> I think a possibly good solution would be to set up a
> mentors.debian.net bug page (similar to other debian resources such as
> [0]).  That would make it much clearer which mentoring tasks are still
> open.  It would also make it possible categorize new submissions, which
> would help potential mentors focus on their areas of interest.
> 

What about something similar to the wnpp weekly newsletter? Now this would
either need to be done using some information from mentors.d.n or, and maybe
preferrably, by checking the list archives. And no, unfortunatly I'm not going
to implement any of this, but maybe someone else likes this idea as well and
finds the time...

Sorry,
Michael



pgpbt1wl2ypcS.pgp
Description: PGP signature

Re: Four days

[Johan Van de Wauw]

On Sat, Oct 2, 2010 at 1:00 AM, Asheesh Laroia  wrote:

>
> And what other cultural improvements can we make to debian-mentors? What
> else can we do to make this place supportive and helpful for the progress of
> y'all mentees into sparkly Debian contributors and developers?

Not something that is implemented overnight, but I think there should
be a solution for new packages which are often useful for users, but
not (yet?) up to debian high standards. I really like the way ubuntu's
launchpad ppas are set up: anyone with an account can create an
archive and upload his source packages.
 If such an archive gives the chance to users to report bugs and also
the usage (eg popcon, download stats) of packages in that archive, it
could be used by sponsors to pick packages which actually have users.
And if it is not picked up by a sponsor at least the users can enjoy
the packaging work which was done.
Apart from that, I believe users in some cases better reviewers than
sponsors. A sponsor may complain about the standards version which is
not up to date with the latest version and/or some lintian errors, but
may not notice bugs which really limit the usability of the
application.

One could argue that such a packages - if they had a copyright review
- could go to experimental, but if a system like launchpad ppas would
exist (where you can upload new versions of a package without needing
a sponsor) the barrier is lowered even more.

What I dislike about this ppa system (and coming more on topic) is
that it does not really encourage towards becoming an official package
and also doesn't learn about how to work with these official packages.
Eg closing bugs by doing an upload, ...


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimea+unwnwnanxuq8vuv3=bzbkpt9ixyyykc...@mail.gmail.com

creating a manpage from a GFDL text

[gustavo panizzo]

Hi folks,

i would like to create a man page for vavoom, based on a wiki page
licensed as GNU Free Documentation License 1.2.
What can i do? GFDL is not free for debian, and my pkg is for main.

thanks!
-- 
1AE0 322E B8F7 4717 BDEA  BF1D 44BB 1BA7 9F6C 6333



signature.asc
Description: Digital signature

Re: RFS: matrixssl

[zeus]

Michal Čihař  writes:

> Hi
>
> please keep the discussion on the list.

Sorry forgot to check.

>> > Quick look at the package:

>> This it's the funny part, I had some troubles trying to understand
>> what's the NMU didn't find a place to understand and then fix this issue.
>
> See .

Understood, removed the NMU, thanks for the link didn't found it before.

>> What do you mean with "unstable in freeze"? If you think that it should
>> be in other place just tell me and we will put it in other place.
>
> Generally uploading new library version to unstable while freeze is not
> a good idea. See freeze announcement for more details -
> .

By what you said I presume that I should put experimental in the
changelog? but I'm sure that it must go in unstable, why it will not go
there?


>> > 3. You dropped dietlibc support without single mention in changelog/NEWS
>> 
>> Didn't know if you should mention that or where mention it, maybe I
>> should not drop the support, whats your thoughts about it?
>
> I have no idea whether it was used or not, but it seems like some major
> feature removal, so it would deserve at least note in changelog or
> NEWS, see
> .

Done. Maybe I'll added the diet support later if someone ask or if I
found it useful for the monkey project.

>> 
>> > 4. Manually creating postinst/postrm is really not needed, just use
>> > debhelper.
>> 
>> Ok, I'll take a more deep look on all the tools of debhelper maybe I
>> missed something.

Done!. It was a lot more easy, thanks it was a lot better =)

>> > 5. Why is there another tarball and debian directory in .orig.tar.gz?
>> > Please check how the source package should look like.
>> 
>> I was running a command to generate de .origin.tar.gz maybe I forgot
>> some option to run, I'll check more about that
>
> You don't need to generate orig.tar.gz, that should be just renamed
> upstream tarball.

I'm not sure if I understood properly but does this means that I have to
create a .tar.gz file with the debian directory inside? or just use some
debian tools to put the debian directory inside? can you point me with
the official documentation about this? Can you point me with a document
with more details about this?

>> > 6. Ever heard about lintian?
>> > I: matrixssl source: binary-control-field-duplicates-source field 
>> > "section" in package libmatrixssl3.1 
>> > I: matrixssl source: duplicate-long-description libmatrixssl3.1-dev 
>> > libmatrixssl3.1 libmatrixssl3.1-doc 
>> > I: matrixssl source: missing-debian-source-format 
>> > W: matrixssl source: changelog-should-not-mention-nmu 
>> > I: matrixssl source: debian-watch-file-is-missing
>> 
>> Of course, but I didn't saw those problems, can you send me the options
>> I should use ?
>
> The I: warnings are generated by passing -I option to lintian. They are
> usually good things to fix, but not necessarily a bugs.

I used the opcion -L ">wishlist" I want to fix the wishlist bugs later
cause I need to read more and don't want to stop the process while you
review or help me with this package I can do other fix like the ones on
wishlist =)

The dget line for package with the fixes.

dget
http://mentors.debian.net/debian/pool/main/m/matrixssl/matrixssl_3.1.2-2.dsc

Are you at IRC sometime in the day to chat about this and ask you a few
things more faster? or you prefer the ml?

Well, thanks for all  your help it's so nice that someone help you with
this things =)

Regards,


pgph0GGZzjJrv.pgp
Description: PGP signature

Re: creating a manpage from a GFDL text

[Alexander Reichle-Schmehl]

Hi!

Am 05.10.2010 17:17, schrieb gustavo panizzo :

> i would like to create a man page for vavoom, based on a wiki page
> licensed as GNU Free Documentation License 1.2.
> What can i do? GFDL is not free for debian, and my pkg is for main.

Well... As a starting point you could read the outcome of
http://www.debian.org/vote/2006/vote_001 or
http://www.debian.org/News/2006/20060316 ;)


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cab4797.2040...@schmehl.info

Re: creating a manpage from a GFDL text

[Sven Joachim]

On 2010-10-05 17:17 +0200, gustavo panizzo  wrote:

> Hi folks,
>
> i would like to create a man page for vavoom, based on a wiki page
> licensed as GNU Free Documentation License 1.2.
> What can i do? GFDL is not free for debian, and my pkg is for main.

GFDL without invariant sections is fine for main, so you can probably go
ahead.  The other option is writing a manpage from scratch, of course.

Sven


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbh0k5lc@turtle.gmx.de

Re: creating a manpage from a GFDL text

[gustavo panizzo]

am i reading this correctly? 
http://www.debian.org/vote/2006/vote_001

is possible to include documentation licensed as GFDL 1.2 :)

On Tue, Oct 05, 2010 at 12:17:06PM -0300, gustavo panizzo  wrote:
> Hi folks,
> 
> i would like to create a man page for vavoom, based on a wiki page
> licensed as GNU Free Documentation License 1.2.
> What can i do? GFDL is not free for debian, and my pkg is for main.
> 
> thanks!
> -- 
> 1AE0 322E B8F7 4717 BDEA  BF1D 44BB 1BA7 9F6C 6333
> 



-- 
1AE0 322E B8F7 4717 BDEA  BF1D 44BB 1BA7 9F6C 6333



signature.asc
Description: Digital signature

Re: creating a manpage from a GFDL text

[Boyd Stephen Smith Jr.]

On Tuesday 05 October 2010 10:17:06 gustavo panizzo  wrote:
> i would like to create a man page for vavoom, based on a wiki page
> licensed as GNU Free Documentation License 1.2.
> What can i do? GFDL is not free for debian, and my pkg is for main.

You could package the documentation in a separate "-doc" package that is in 
non-free and Suggest (or maybe Recommend) it from the core package.

You could get the owners of the copyright to relicense the work.

You could get debian-legal to review the licensing and see if this use of the 
GFDL is appropriate for main.  Sometimes a license that is normally 
appropriate for main can be disallowed due to the interpretation of the 
copyright holder.  (ISTR, Pine's license being like this.)  It is possible the 
converse could be true as well.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: creating a manpage from a GFDL text

[Alexander Reichle-Schmehl]

Hi!

Am 05.10.2010 17:54, schrieb Boyd Stephen Smith Jr.:

>> i would like to create a man page for vavoom, based on a wiki page
>> licensed as GNU Free Documentation License 1.2.
>> What can i do? GFDL is not free for debian, and my pkg is for main.
> You could package the documentation in a separate "-doc" package that is in 
> non-free and Suggest (or maybe Recommend) it from the core package.

Just for completeness: A package in main must not recommend a package
not in main.  Don't know the spot in the policy about that, but it was a
release goal for Lenny.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cab4c81.4020...@debian.org

Re: Four days

[Asheesh Laroia]

On Tue, 5 Oct 2010, Michael Tautschnig wrote:


[...]



I think a possibly good solution would be to set up a
mentors.debian.net bug page (similar to other debian resources such as
[0]).  That would make it much clearer which mentoring tasks are still
open.  It would also make it possible categorize new submissions, which
would help potential mentors focus on their areas of interest.



What about something similar to the wnpp weekly newsletter? Now this would
either need to be done using some information from mentors.d.n or, and maybe
preferrably, by checking the list archives. And no, unfortunatly I'm not going
to implement any of this, but maybe someone else likes this idea as well and
finds the time...


Your idea hinges on getting mailing list archives automatically. I have a 
similar idea that I know I'm not going to get to any time in the next few 
months. But it's a pretty simple script.


It would be really cool to have a web page that listed the subject lines 
of threads on debian-mentors that have gotten no response. Different 
colors indicate different ages:


* Black: The message is between 0 and 2 days old
* Yellow: The message is between 2 and 4 days old
* Red: The message is older than 4 days
* Green: The message has already gotten a reply

If you want to write up a script (I would use Python), I can imagine how 
you'd go about doing it... except I don't know how you can download MBOX 
archives of Debian lists. (I actually struggled with this in the summer of 
2006, now that I think about it.)


Does anyone know where an mbox archive of the debian-mentors list can be 
found? If so I can provide further tips to someone who wants to help us 
visualize the "Four days" goal. (-:


I don't have time to write it myself, but if there's an easy way to make 
the mbox list archives available to people, I would happily mentor someone 
who wanted to write such a thing. We could publish the resulting HTML page 
on my people.debian.org/~paulproteus/ site.


-- Asheesh.

--
You are always busy.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1010051209080.25...@rose.makesad.us

Re: Four days

[Asheesh Laroia]

On Tue, 5 Oct 2010, Johan Van de Wauw wrote:


On Sat, Oct 2, 2010 at 1:00 AM, Asheesh Laroia  wrote:



And what other cultural improvements can we make to debian-mentors? What
else can we do to make this place supportive and helpful for the progress of
y'all mentees into sparkly Debian contributors and developers?


Not something that is implemented overnight, but I think there should
be a solution for new packages which are often useful for users, but
not (yet?) up to debian high standards. I really like the way ubuntu's
launchpad ppas are set up: anyone with an account can create an
archive and upload his source packages.
If such an archive gives the chance to users to report bugs and also
the usage (eg popcon, download stats) of packages in that archive, it
could be used by sponsors to pick packages which actually have users.
And if it is not picked up by a sponsor at least the users can enjoy
the packaging work which was done.
Apart from that, I believe users in some cases better reviewers than
sponsors. A sponsor may complain about the standards version which is
not up to date with the latest version and/or some lintian errors, but
may not notice bugs which really limit the usability of the
application.

One could argue that such a packages - if they had a copyright review
- could go to experimental, but if a system like launchpad ppas would
exist (where you can upload new versions of a package without needing
a sponsor) the barrier is lowered even more.

What I dislike about this ppa system (and coming more on topic) is
that it does not really encourage towards becoming an official package
and also doesn't learn about how to work with these official packages.
Eg closing bugs by doing an upload, ...


That's a really good set of ideas. I really like the point that users know 
what's wrong with a program! And you make a good point that packaging 
work, even if it is not ready for the archive, can help users quite a bit.


http://debexpo.workaround.org/ is the homepage for a 2008 Summer of Code 
project that was a redesigned mentors.debian.net website. I'm trying to 
get to know the codebase so I can write up some guides for how people can 
help.


I think that the plan for debexpo is to have that sort of personal package 
archive functionality in there.


I bet that we can get debexpo finished and usable within a month (even if 
that means disabling features that aren't usable yet). So this is the 
Asheesh promise of October: debexpo by November 5.


And I can use y'all's help in succeeding at it. (-: If you want to grab 
the source now, then by all means go ahead. First things first, you should 
grab it and try to see if the test suite passes.


-- Asheesh.

--
You need more time; and you probably always will.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1010051228250.25...@rose.makesad.us

Re: Four days

[Asheesh Laroia]

On Mon, 4 Oct 2010, Michal Čihař wrote:

Lack of interested mentors is indeed an issue. Nobody has unlimited time 
and chooses what attracts him. For me it usually means things I know and 
test or which I find interesting after reading RFS email.


It is. At the same time, I think that we can increase the number of DDs 
who want to sponsor or review packages by asking nicely on debian-devel 
and making this list more fun to be on.


Well it would be definitely useful having better tracked package reviews 
and problems found on earlier upload, so that it is clearly visible if 
there are still some not fixed issues.


That makes sense. We can solve that through some technology, like "REVU" 
.


I'm running out of cycles to maintain more technology, so instead I will 
try to reconfigure the expectations on the mailing list so that mentees 
know what to expect. So mentees -- if you think you've solved the problems 
raised on the list, and you think someone should upload it, but no one did 
-- reply within the thread four days later to say that your expectations 
have been broken. (-:


Remember: Communicate! (And all, thanks for such an interesting thread.)

-- Asheesh.

--
Q:  What's tiny and yellow and very, very, dangerous?
A:  A canary with the super-user password.

Re: Rescue Plan for apt-listbugs

[Francesco Poli]

On Tue, 5 Oct 2010 10:54:29 +0200 Manuel A. Fernandez Montecelo wrote:

[...]
> Just copying the reply to the original author... he already said that he's 
> not subscribed to the mailing list ;)

Thanks a lot!

[...]
> On Tuesday 05 October 2010 09:27:57 Jan Hauke Rahm wrote:
> > On Mon, Oct 04, 2010 at 11:29:28PM +0200, Francesco Poli wrote:
[...]
> > > My problem is that I've lost contact with him: he seems to be currently
> > > (almost) MIA.
> > 
> > FWIW, I have been working with him as well and found him rather inactive
> > lately. I've now contacted him and will see where this leads.

Thanks to Jan, for trying to get in touch with Ryan, even though I must
confess that I lost hope to get any useful answer from Ryan...  :-(

> > 
> > Francesco, if you fear someone's MIA, please feel free to contact (or
> > CC) the MIA team at m...@qa.debian.org. I just happened to see your
> > concerns here.

I will certainly consider contacting the MIA team sooner or later.
But, in the meanwhile, I want to rescue apt-listbugs from this impasse!


-- 
 http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
 Need some pdebuild hook scripts?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp1XrhveUfI7.pgp
Description: PGP signature

Re: RFS: btag -- interactive command-line based multimedia tag editor

[David Bremner]

On Fri, 1 Oct 2010 00:50:15 -0300, Fernando Lemos  wrote:

> * Package name: btag
>   Version : 1.0.0-1
>   Upstream Author : Fernando Tarlá Cardoso Lemos 
> * URL : http://github.com/fernandotcl/btag
> * License : BSD
>   Section : sound

Hi Fernando;

I'm not a DD, but hopefully this review can make it easier to sponsor
your package.

Your package

- compiles clean in a sid chroot
- lintian clean with version 2.4.3
- the man page looks good
- I did a successful test run on some mp3's, and seemed to work.

Some comments

- It should be documented what extensions/formats are supported.  I
  tried some m4a's and it didn't work. Probably this should be in the
  long description.

- The file LICENSE has one  in it that looks like it
  should be replaced. This is probably a minor thing to be reported to
  upstream.

Thanks for your Debian packaging efforts.

d



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hhwh8fk@convex-new.cs.unb.ca

Re: Four days

[Vincent Carmona]

2010/10/5 Johan Van de Wauw :
> On Sat, Oct 2, 2010 at 1:00 AM, Asheesh Laroia  wrote:
>
> Not something that is implemented overnight, but I think there should
> be a solution for new packages which are often useful for users, but
> not (yet?) up to debian high standards. I really like the way ubuntu's
> launchpad ppas are set up: anyone with an account can create an
> archive and upload his source packages.
>  If such an archive gives the chance to users to report bugs and also
> the usage (eg popcon, download stats) of packages in that archive, it
> could be used by sponsors to pick packages which actually have users.
> And if it is not picked up by a sponsor at least the users can enjoy
> the packaging work which was done.
> Apart from that, I believe users in some cases better reviewers than
> sponsors. A sponsor may complain about the standards version which is
> not up to date with the latest version and/or some lintian errors, but
> may not notice bugs which really limit the usability of the
> application.
>
> One could argue that such a packages - if they had a copyright review
> - could go to experimental, but if a system like launchpad ppas would
> exist (where you can upload new versions of a package without needing
> a sponsor) the barrier is lowered even more.
>
> What I dislike about this ppa system (and coming more on topic) is
> that it does not really encourage towards becoming an official package
> and also doesn't learn about how to work with these official packages.
> Eg closing bugs by doing an upload, ...
>

My first package was accepted recently.
I think I would not attempt packaging for debian if ppa does not existed.

My experience goes through 3 steps:

build a simple deb file by in vocking "dpkg-deb --build" on "destdir" install.
Use ppa to learn the process of packaging (d/rules...). My ppa
packages are ugly but they install wanted files.
Join a team and begin to learn clean packaging.

-- 
Vincent Carmona


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikvnp7u7gp7uryb-fmvcvy7fgz5rtrvh=ctc...@mail.gmail.com

Re: RFS: ripit, a textbased audio CD ripper (updated package) 2nd attempt

[Elimar Riesebieter]

* Sven Hoexter [101005 10:42 +0200]:
> On Mon, Oct 04, 2010 at 11:29:10PM +0200, Elimar Riesebieter wrote:
> 
> Hi,
> 
> > I am looking once again for a sponsor for the new version 3.9.0-1 of
> > my package "ripit". It should be uploaded to experimental, please.
> 
> Uploaded. Thanks. :)

Thanks for your cooperation ;-)

Elimar

-- 
.~.
/V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101005184233.gb4...@gandalf.home.lxtec.de

Re: Four days

[Michael Tautschnig]

[...] (great ideas w/ color codes)

> 
> If you want to write up a script (I would use Python), I can imagine
> how you'd go about doing it... except I don't know how you can
> download MBOX archives of Debian lists. (I actually struggled with
> this in the summer of 2006, now that I think about it.)
> 

[...]

Well, you probably couldn't do that back in 2006, but as you're a DD you can
just go to master.debian.org and look at /home/debian/lists/debian-mentors/

:-)

Best,
Michael


pgpEJAEdgFArz.pgp
Description: PGP signature

Re: Four days

[Don Armstrong]

On Sun, 03 Oct 2010, Paul Wise wrote:
> Another demotivator is people who treat the archive as a dumping
> ground for their pet package; do a one-shot upload to get it in and
> essentially leave it orphaned after that. I tried to avoid that by
> having a policy of not sponsoring anything, but I still have a few
> such packages on my DDPO page. I'm not sure how to avoid that but
> actually upload stuff regularly.

This is actually my biggest concern with many RFS, and why I rarely
sponsor packages. We need some sort of method to indicate to sponsees
that the reason why their package isn't being sponsored is because
people think that it's not suitable for the archive instead of that
people are just ignoring it.

We probably should do a better job of identifying these packages and
responding to the RFS to tell people that it's of questionable
importance (or clearly no importance) and then channeling them into
assistance to Debian that is of greater importance. [It's also
difficult to break it to people that the work that they've done
probably isn't needed and keep them positive about contributing to the
project... though I think the sooner this happens, the less painful it
will be.]

It'd probably also be good to know in the RFS whether it's a new
package or an upload for an existing package. [The latter should
always get sponsored; the former may need guidance.]


Don Armstrong

-- 
LEADERSHIP -- A form of self-preservation exhibited by people with
autodestructive imaginations in order to ensure that when it comes to
the crunch it'll be someone else's bones which go crack and not their
own. 
 -- The HipCrime Vocab by Chad C. Mulligan 
(John Brunner _Stand On Zanzibar_ p256-7)

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101005194038.gc3...@rzlab.ucr.edu

Re: RFS: cppcheck, new upstream version 1.45

[Reijo Tomperi]

Reijo Tomperi wrote:

Dear mentors,

I am looking for a sponsor for my package "cppcheck".

* Package name: cppcheck
 Version : 1.25-1
 Upstream Authors: Daniel Marjamäki 
   Reijo Tomperi 
* URL : http://cppcheck.wiki.sourceforge.net/
* License : GPL 3
 Section : devel

It builds these binary packages:
cppcheck   - C/C++ code analyzer

The package appears to be lintian clean.

The upload would fix these bugs: 503730


Hi,

New upstream version was released, so I made a new Debian package of it.

I'm again looking for a sponsor for it.

It is lintian clean and builds with cowbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cppcheck
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.45-1.dsc

--
Reijo










--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cab9845.2070...@users.sourceforge.net

Re: RFS: ase - Allegro Sprite Editor

[Oscar Morante]

Hi Paul,
Thanks for your advice.

On Sat, Oct 02, 2010 at 08:35:35AM +0800, Paul Wise wrote:
> On Sat, Sep 25, 2010 at 11:57 AM, Kan-Ru Chen  wrote:
> 
> > The files under third_party/freetype should be mentioned, too.
> 
> In addition, we do not like embedded code copies in Debian. Please
> ensure that, at minimum, the package does not build against any
> embedded code copies, the best way to do that is rm -rf during
> debian/rules build.

I've already patched the makefiles to link against debian libraries
except for one "vaca" which isn't packaged and I don't think it's
interesting/worth packaging.  Anyway I'll remove the other libraries
during debian/rules build to be sure that I'm doing it right.

> Best practice would be to get upstream to remove
> any embedded code copy dependencies from the tarball. If they need
> them for platforms without a sane packaging and repository system then
> they can add a second tarball containing all the dependencies.

Upstream is very responsive, I'll ask.

-- 
Oscar Morante
"Self-education is, I firmly believe, the only kind of education there is."
  -- Isaac Asimov.


signature.asc
Description: Digital signature

Bug in frozen package - aim at backports/volatile?

[Stefan Ott]

Hey list

I have a small question: I'm aware that Debian is currently frozen,
thus no new features can be added to squeeze. However, I maintain a
package [1] (I'm also the upstream maintainer) which has an annoying
but non-critical bug. The package is a parser for TV show episode
information and one of the sources recently changed some minor detail
in their data which messes up my tool's output.

Anyway.

I just released a new upstream version [2] which fixes that bug (and
that bug only) and don't really like the idea of shipping a buggy
version of my package with squeeze, thus I'm wondering whether it's
possible to have a fixed version included in squeeze (probably not) or
if I should aim at squeeze-backports or volatile (since the package
depends on volatile external data).

I realize that according to the policy the package cannot enter
squeeze. I'm just wondering whether it's a reasonable approach (from a
user's point of view) to have an updated version in volatile (or
backports) at the time squeeze is released.

(Also, note that according to popcon there are very people currently
using the package, thus the issue is probably not that relevant in
this case, but I guess there might be other packages with similar
issues.)

[1] http://packages.qa.debian.org/e/episoder.html
[2] http://code.google.com/p/episoder/wiki/ChangeLog

cheers
-- 
Stefan Ott
http://www.ott.net/

"You are not Grey Squirrel?"


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

Re: RFS: btag -- interactive command-line based multimedia tag editor

[Fernando Lemos]

Hey David,

On Tue, Oct 5, 2010 at 2:10 PM, David Bremner  wrote:
> I'm not a DD, but hopefully this review can make it easier to sponsor
> your package.

Thanks for your input, it's really appreciated.

> - It should be documented what extensions/formats are supported.  I
>  tried some m4a's and it didn't work. Probably this should be in the
>  long description.

You're right. I've adapted btag to use the list of supported
extensions supplied by TagLib instead of using hardcoded file
extensions. This means btag 1.0.1 should now support every format
TagLib supports. I've updated the long description to reflect this.

> - The file LICENSE has one  in it that looks like it
>  should be replaced. This is probably a minor thing to be reported to
>  upstream.

Indeed. I've fixed that upstream, it's fixed in 1.0.1 too.

I've packaged 1.0.1 and uploaded it to mentors.debian.net. I'm still
looking for an sponsor, so here's an up-to-date RFS template for the
sake of completeness:

* Package name: btag
  Version : 1.0.1-1
  Upstream Author : Fernando Tarlá Cardoso Lemos 
* URL : http://github.com/fernandotcl/btag
* License : BSD
  Section : sound

It builds these binary packages:
btag   - interactive command-line based multimedia tag editor

The package appears to be lintian clean.

The upload would fix these bugs: 594749

My motivation for maintaining this package is: I don't tag my music
often, but when I do, it's a tedious task. btag makes it easier for
me, and I think other people might be interested. Having the package
in Debian would also mean more exposure to the project, and that's
always welcome.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/b/btag
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/b/btag/btag_1.0.1-1.dsc

I would be glad if someone uploaded this package for me.


Kinds regards,
Fernando.


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

Re: RFS: matrixssl

[Paul Wise]

On Tue, Oct 5, 2010 at 11:40 PM,   wrote:

> By what you said I presume that I should put experimental in the
> changelog? but I'm sure that it must go in unstable, why it will not go
> there?

Please read the freeze announcement:

http://lists.debian.org/debian-devel-announce/2010/08/msg0.html

Switching to a new ABI is a major change that should not happen in
unstable during the freeze. experimental is available for work that is
targetted at the squeeze+1 release (wheezy).

> I'm not sure if I understood properly but does this means that I have to
> create a .tar.gz file with the debian directory inside? or just use some
> debian tools to put the debian directory inside? can you point me with
> the official documentation about this? Can you point me with a document
> with more details about this?

He means that you should use the same tarball as the one upstream
released. I would guess that the one you uploaded has a different
md5sum to the one that upstream released.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikv7kpba=sd=zwge7fsro-meguieun99ab6j...@mail.gmail.com

Re: RFS: btag -- interactive command-line based multimedia tag editor

[Kan-Ru Chen]

Hi Bremner,

Thanks for the review!

Hi Fernando,

Thanks for the Debian packaging work, the package is indeed in a very
good shape!

Uploaded.

Cheers,
Kanru


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

Re: Bug in frozen package - aim at backports/volatile?

[Boyd Stephen Smith Jr.]

In , Stefan Ott 
wrote:
>I have a small question: I'm aware that Debian is currently frozen,
>thus no new features can be added to squeeze. However, I maintain a
>package [1] (I'm also the upstream maintainer) which has an annoying
>but non-critical bug. The package is a parser for TV show episode
>information and one of the sources recently changed some minor detail
>in their data which messes up my tool's output.
>
>I just released a new upstream version [2] which fixes that bug (and
>that bug only) and don't really like the idea of shipping a buggy
>version of my package with squeeze, thus I'm wondering whether it's
>possible to have a fixed version included in squeeze (probably not) or
>if I should aim at squeeze-backports or volatile (since the package
>depends on volatile external data).

If the upstream diff is small, it only fixes bugs, and the package a 
relatively few reverse-Depends, the chance the release team will allow the new 
package to enter testing is large.  In any case, such a small, bugfix-only 
diff would be appropriate for unstable, even if it isn't ultimately approved 
for entering testing.

The "freeze" before release is more of a "slush" compared to what happens 
after release.  Imagine the consternation of releasing git-core in 5.0.6 for 
i386 with a grave bug that wasn't in 5.0.5 -- it can't be fixed in the core 
stable repository until 5.0.7 is released.  (The fix is relegated to s-p-u, 
security, volatile, etc.)  See bug 595728. :P
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.