Re: Backports service becoming official

[Mike Hommey]

On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> On 06/09/10 at 20:32 +0300, Andrei Popescu wrote:
> > On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > > relevant to backported packages still have to be reported to the
> > > > debian-backports [3] list, which have now also been moved to
> > > > lists.debian.org [4].
> > > 
> > > What are the BTS limitations ?  Perhaps it could be improved to
> > > support backports too.  Using mailing lists for this is a bit 1980's :-)
> > 
> > From what I understand it's the version tracking and the fact that 
> > backports can have a different Maintainer then the "regular" package.
> 
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
> 
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).

Seconded.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907065946.ga4...@glandium.org

Re: Backports service becoming official

[Paul Wise]

On Tue, Sep 7, 2010 at 1:46 PM, Lucas Nussbaum  wrote:

> Now that backports are becoming official, I think that it is the right
> time to reconsider

Some other possibilities;

Move *-backports (and *-volatile) into the main archive like they are in Ubuntu.

Merge the backports website into www.debian.org or wiki.debian.org.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Backports service becoming official

[Iustin Pop]

On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
> 
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).

Good idea, I like it.

iustin


signature.asc
Description: Digital signature

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Andrea Gasparini]

Andrea Colangelo wrote, Tuesday 07 September 2010
> > * URL : http://www.home.unix-ag.org/simon/

http://www.home.unix-ag.org/simon/woof.html


Josselin Mouette wrote, Tuesday 07 September 2010:
> Oh yeah. We didn’t have enough webservers in the archive.

Joss, you could even be right, but that doesn't seem the best way to state 
your thoughts. 
WIth this tone I guess the OP wouldn't simply consider your mail.


brian m. carlson wrote, Tuesday 07 September 2010:
> We have a lot of web servers in Debian.  Could you provide a long
> description for the package that helps an adminstrator decide why she
> might want to install woof instead of some other lightweight web
> server?

Brian, it lacks the long description, right, we'll provide one asap.
Though, it serves just one file a given number of times, and then shutdown. 
It's something useful for distributing file in a LAN, if you don't want to 
install and setup a complete/complex webserver.


Mauro Lizaur wrote, Tuesday 07 September 2010:
>Such as:
> $ python -m SimpleHTTPServer [port]

Thanks Mauro, we could drop all our webservers, now. :)

Bye!
-- 
-gaspa-
---
 https://launchpad.net/~gaspa -
- HomePage: http://gaspa.yattaweb.it --


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009071001.32465.ga...@yattaweb.it

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Marco d'Itri]

On Sep 07, Andrea Gasparini  wrote:

> Brian, it lacks the long description, right, we'll provide one asap.
> Though, it serves just one file a given number of times, and then shutdown. 
> It's something useful for distributing file in a LAN, if you don't want to 
> install and setup a complete/complex webserver.
Installing lighttpd or something like it requires much less time than
learning the existence of this one.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

RE: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Chris Carr]

Are we in danger of making the best the enemy of the good? Packaging
winetricks as-is would be helpful: making it a part of the packaging system,
keeping it up-to-date, maybe adding a man page. 

Massive integration of distributable libraries into wine, and/or the
creation of a wine-nonfree package with more of same, are great ideas. But
they're also a lot more work than just packaging winetricks. So maybe let
the simple one be done first, and take the pressure off those who need more
time to do the trickier work?

If the new winetricks package were to be called wine-nonfree, that would lay
the foundations for later efforts ...

Chris Carr
 

> -Original Message-
> From: Andreas Barth [mailto:a...@not.so.argh.org] 
> Sent: 05 September 2010 14:05
> To: Adam Borowski
> Cc: debian-devel@lists.debian.org; 595...@bugs.debian.org
> Subject: Re: Bug#595427: ITP: winetricks -- Quick and dirty 
> script todownload and install variousredistributable runtime libraries
> 
> * Adam Borowski (kilob...@angband.pl) [100905 11:04]:
> > It's a massive script, so the file count of 1 doesn't 
> really matter.  Also,
> > it needs to update more often than wine proper, as it 
> refers to outside
> > locations.
> > 
> > I'd vote for having it as a separate package.
> 
> It'd rather make sense to create a wine-nonfree which includes the
> libraries that we are allowed to redistribute, and downloads the
> others.
> 
> Then it makes of course sense to have it as an seperate package (and
> with e.g. cmake I'm even not sure if we couldn't take the free version
> of it into wine proper).
> 
> In other words, there will be some massive integration effort into
> debian, so winetricks won't look like the current script. Which is
> something that should be done.
> 
> 
> 
> Andi
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact 
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/20100905130527.gl15...@mails.so.argh.org
> 
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/b585aca71ccf4f16ae9aa789a202d...@lbcamden.net

Bug#595907: ITP: webhoneypot -- The Dshield Web Honeypot Project.

[christian]

Package: wnpp
Severity: wishlist
Owner: Christian Pohl 


* Package name: webhoneypot
  Version : 0.1.123
  Upstream Author : Johannes Ulrich
* URL : http://sites.google.com/site/webhoneypotsite
* License : GPLv2
  Programming Lang: PHP
  Description : The Dshield Web Honeypot Project.

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907080154.13339.56159.report...@aringill.pohlcity.local

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Andreas Barth]

* Chris Carr (ranting...@gmail.com) [100907 10:20]:
> Are we in danger of making the best the enemy of the good? Packaging
> winetricks as-is would be helpful: making it a part of the packaging system,
> keeping it up-to-date, maybe adding a man page. 
> 
> Massive integration of distributable libraries into wine, and/or the
> creation of a wine-nonfree package with more of same, are great ideas. But
> they're also a lot more work than just packaging winetricks. So maybe let
> the simple one be done first, and take the pressure off those who need more
> time to do the trickier work?
> 
> If the new winetricks package were to be called wine-nonfree, that would lay
> the foundations for later efforts ...

I agree that starting with the current scripts is for starters. But we
should do it in a way that is prepared for doing it right, and then
starting with the easier parts of replacing the scripts with the right
libraries.

Obviously there are some very low hanging fruits within the
winetricks-scripts (basically everything that is downloaded from an
open source site).


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907082346.gq2...@mails.so.argh.org

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo Tomaselli]

On Tuesday 07 September 2010 00:22:26 brian m. carlson wrote:

> We have a lot of web servers in Debian.  Could you provide a long
> description for the package that helps an adminstrator decide why she
> might want to install woof instead of some other lightweight web
> server?

I maintain a similar package (weborf), but yet with some differences.

Weborf uses a basedirectory param while woof can use a directory or a file.
Weborf will not limit the number of connections.
Woof would tar a directory and weborf would produce an html list of files.
Weborf does not support file upload in the same way. The user would be forced 
to use a CGI script. Or, weborf supports the PUT method, but no browser does.
Weborf is also meant to be used as a normal webserver, and woof is not.

I think the upload option and the tar of directory are quite convenient.


Bye

-- 
Salvo Tomaselli


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

Re: Backports service becoming official

[Sune Vuorela]

On 2010-09-07, Lucas Nussbaum  wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
>
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in

I'm not planning to ever provide backports of any of my packages, and
while others are welcome to do it, I do not in any way want to be
bothered by their bugs or upload emails or anything.

So, please keep current way.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni8bu8r.rvp.nos...@sshway.ssh.pusling.com

Re: Any one getting aptitude frozen on "update" with Translation-en bzip2 ?

[Jon Dowland]

Why have you CCed debian-devel? The rest of the thread is not on there.  Please
stop cluttering -devel with separate mails on this topic. We have a bug number,
that's where discussion can take place, should any be necessary.

-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907083655.gb6...@deckard.alcopop.org

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Adam Borowski]

On Tue, Sep 07, 2010 at 09:20:21AM +0100, Chris Carr wrote:
> If the new winetricks package were to be called wine-nonfree, that would lay
> the foundations for later efforts ...

Except that it would be a serious misnomer.

First, many of the packages there are free software.  29 out of 120, by my
count.

Then, in the usual Debian parlance, "nonfree" usually suggests proprietary
gratis distributable things.  Winetricks includes a mix of distributable,
non-distributable and even non-gratis software (the last cathegory requires
that you have a valid Windows license).

In the past, there was opposition to shipping random free software for
Windows inside Debian, for good reasons.  And since most of the rest in
undistributable, packaging winetrick as a big installer (in main!) is
probably the best idea.


Meow,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907085016.ga18...@angband.pl

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Josselin Mouette]

Le mardi 07 septembre 2010 à 10:25 +0200, Salvo Tomaselli a écrit :
> I maintain a similar package (weborf), but yet with some differences.
> 
> Weborf uses a basedirectory param while woof can use a directory or a file.
> Weborf will not limit the number of connections.
> Woof would tar a directory and weborf would produce an html list of files.
> Weborf does not support file upload in the same way. The user would be forced 
> to use a CGI script. Or, weborf supports the PUT method, but no browser does.
> Weborf is also meant to be used as a normal webserver, and woof is not.
> 
> I think the upload option and the tar of directory are quite convenient.

Oh, please. If you want to setup such schemes, why would you not want to
spend 5 minutes to configure apache or lighttpd instead of spending at
least the same time to configure such an obscure piece of software?

If all you care about is sharing a few files in the simplest way, there
are much better tools to do it, like gnome-user-share.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283849228.5236.38.ca...@meh

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo Tomaselli]

On Tuesday 07 September 2010 10:10:22 Marco d'Itri wrote:
> Installing lighttpd or something like it requires much less time than
> learning the existence of this one.
Not really.

The default installation of lighttpd would put itself in the autostart, maybe 
i just wanted to share a file and it would take time for me to change the 
configuration for avoiding autostart and create a new config file. And of 
course i should also know how to do that.

I've tried copying the default configuration and i had to: remove the pid file 
directive, change the default port (sometimes also a non-root user might wish 
to share a file).
With this option in the conffile:
server.port = 8080

Trying to start lighthttpd as user like this:
$ lighttpd -f myconf.conf 
2010-09-07 10:53:30: (network.c.358) can't bind to port: :: 80 Permission 
denied

So no. I think you are wrong.

Bye
-- 
Salvo Tomaselli


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

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[David Goodenough]

On Tuesday 07 September 2010, Adam Borowski wrote:
> On Tue, Sep 07, 2010 at 09:20:21AM +0100, Chris Carr wrote:
> > If the new winetricks package were to be called wine-nonfree, that 
would
> > lay the foundations for later efforts ...
> 
> Except that it would be a serious misnomer.
> 
> First, many of the packages there are free software.  29 out of 120, by 
my
> count.
> 
> Then, in the usual Debian parlance, "nonfree" usually suggests 
proprietary
> gratis distributable things.  Winetricks includes a mix of distributable,
> non-distributable and even non-gratis software (the last cathegory 
requires
> that you have a valid Windows license).
That is not true.  Winetricks is itself entirely free, and is just a simple
script.  It then downloads the other materials from public web sites,
but by no measure can those other materials be regarded as part of
wine-tricks - Microsoft would have something to say about that if it
were claimed that they were part.

David
> 
> In the past, there was opposition to shipping random free software for
> Windows inside Debian, for good reasons.  And since most of the rest in
> undistributable, packaging winetrick as a big installer (in main!) is
> probably the best idea.
> 
> 
> Meow,


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201009071013.15478.david.goodeno...@btconnect.com

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo Tomaselli]

On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote:
> Oh, please. If you want to setup such schemes, why would you not want to
> spend 5 minutes to configure apache or lighttpd instead of spending at
> least the same time to configure such an obscure piece of software?
> 
> If all you care about is sharing a few files in the simplest way, there
> are much better tools to do it, like gnome-user-share.

1 you are assuming to have root permissions (read my previous email)
2 you are assuming to be working on a desktop
3 you are assuming you want to share the same file all the time. But this 
might not be the case, and change the configuration every time you want to 
share a different file could annoying.

-- 
Salvo Tomaselli


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

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Stefano Zacchiroli]

[ adding back the ITP to Cc: ]

On Tue, Sep 07, 2010 at 10:56:15AM +0200, Salvo Tomaselli wrote:
> The default installation of lighttpd would put itself in the autostart, maybe 
> i just wanted to share a file and it would take time for me to change the 
> configuration for avoiding autostart and create a new config file. And of 
> course i should also know how to do that.

Fair enough. Note that nobody here is saying "thou shall not package
this". We are just very cautious because adding a new web server to the
archive might easily become a security PITA (ask the security team for
some horror stories on the subject of "yet another web server"). So what
we are saying is just that "it should be worth it" wrt other software
offerings already in the archive.

On a related topic, please remember that long descriptions are meant to
help sysadms to decide whether they want to install a package or not. In
this specific case, and giving the availability of competitor tools,
your long description should explain why one might want to prefer woof
over other packages.

If I were the packager, I would skim through the output of "debtags
search web::server" and try to convince myself that the new one I'm
adding really has distinguishing features (things like "ease of
configuration" might of course qualify as a features). Once done, I
would mention my reasons in the long description. ... and that's also
why it's wise to have long descriptions ready at ITP-submission time:
thread like this one might have been avoided completely, thanks to a
convincing long description :-)

Thanks for your packaging work!
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Holger Levsen]

apt-cache show sendfile gerstensaft


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

Re: Backports service becoming official

[Holger Levsen]

Hi,

On Dienstag, 7. September 2010, Sune Vuorela wrote:
> On 2010-09-07, Lucas Nussbaum  wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same rules of packages ownership as for
> > normal packages ("normal" backport maintainer = maintainer of the
> > package in unstable).

+1

> I'm not planning to ever provide backports of any of my packages, and
> while others are welcome to do it, I do not in any way want to be
> bothered by their bugs or upload emails or anything.

That's a valid stand.

> So, please keep current way.

That I dont think it is. I think you not wanting t be bothered by backports of 
your packages is quite an exception, so I would propose some additional 
header to BTS mails about backports, so you can setup your filters to ignore 
those mails.


cheers,
Holger



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

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Stéphane Glondu]

Le 07/09/2010 11:37, Holger Levsen a écrit :

apt-cache show sendfile gerstensaft


It seems to use its own protocol and needs special software on both 
sides. On the other hand, wget or curl is installed on all systems... 
and HTTP works also for non-Linux systems.


--
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c860a6b.8000...@glondu.net

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Jean-Christophe Dubacq]

On 07/09/2010 11:17, Salvo Tomaselli wrote:
> On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote:
>> Oh, please. If you want to setup such schemes, why would you not want to
>> spend 5 minutes to configure apache or lighttpd instead of spending at
>> least the same time to configure such an obscure piece of software?
>>
>> If all you care about is sharing a few files in the simplest way, there
>> are much better tools to do it, like gnome-user-share.
> 
> 1 you are assuming to have root permissions (read my previous email)
> 2 you are assuming to be working on a desktop
> 3 you are assuming you want to share the same file all the time. But this 
> might not be the case, and change the configuration every time you want to 
> share a different file could annoying.
> 
What about using nc ?
nc -l  < /etc/passwd

http://localhost:/ => bingo.

We will probably not convince you, but there are way too many
alternatives to make the packaging effort worth the time.
-- 
Jean-Christophe Dubacq


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c860dbe.4090...@free.fr

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Mauro Lizaur]

2010-09-07, Stefano Zacchiroli:

> [ adding back the ITP to Cc: ]
> 
> On Tue, Sep 07, 2010 at 10:56:15AM +0200, Salvo Tomaselli wrote:
> > The default installation of lighttpd would put itself in the autostart, 
> > maybe 
> > i just wanted to share a file and it would take time for me to change the 
> > configuration for avoiding autostart and create a new config file. And of 
> > course i should also know how to do that.
> 
> Fair enough. Note that nobody here is saying "thou shall not package
> this". We are just very cautious because adding a new web server to the
> archive might easily become a security PITA (ask the security team for
> some horror stories on the subject of "yet another web server"). So what
> we are saying is just that "it should be worth it" wrt other software
> offerings already in the archive.
> 
> On a related topic, please remember that long descriptions are meant to
> help sysadms to decide whether they want to install a package or not. In
> this specific case, and giving the availability of competitor tools,
> your long description should explain why one might want to prefer woof
> over other packages.
> 

+1

[plus]

2010-09-07, Andrea Gasparini:
> >Such as:
> > $ python -m SimpleHTTPServer [port]
> Thanks Mauro, we could drop all our webservers, now. :)

I guess we could, but it wouldn't be a very smart move to be honest.
Please, read the paragraphs written by Stefano, he made some interesting
points.

Also what I meant with that line was that when I need to copy a file to
(let's say) my cellphone in a simple (and/or stupid) way, this can easily 
be achieved with that Python module. But at the same time, waiting for you 
to answer the question we all have: What does it do?

Proptip: 
Perhaps the usage of the following words might help you to convince us all.
 * scalable (This one is a sure-shot)
 * non-blocking
 * über-fast
 * «web2.0 ready» (I guess this one is kinda demodé these days anyway)
 * «Sarcasm inside» (Hope Intel doesn't get mad over this)

Saludos,
Mauro

--
JID: lavaram...@nube.usla.org.ar | http://lizaur.github.com/
2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907101944.ge20...@cacavoladora.org

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo 'LtWorf' Tomaselli]

On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
> What about using nc ?
> nc -l  < /etc/passwd
> 
> http://localhost:/ => bingo.
> 
> We will probably not convince you, but there are way too many
> alternatives to make the packaging effort worth the time.
you convinced me, and i was well aware of that.
But how can i convince someone with an apple that he has to download gcc and 
compile nc or even worst convince someone with windows?
-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei


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

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Mike Hommey]

On Tue, Sep 07, 2010 at 12:27:14PM +0200, Salvo 'LtWorf' Tomaselli wrote:
> On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
> > What about using nc ?
> > nc -l  < /etc/passwd
> > 
> > http://localhost:/ => bingo.
> > 
> > We will probably not convince you, but there are way too many
> > alternatives to make the packaging effort worth the time.
> you convinced me, and i was well aware of that.
> But how can i convince someone with an apple that he has to download gcc and 
> compile nc or even worst convince someone with windows?

Someone with an apple or windows doesn't need a debian package of woof.
And someone with debian has nc.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907103528.ga20...@glandium.org

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Michael Tautschnig]

> On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
> > What about using nc ?
> > nc -l  < /etc/passwd
> > 
> > http://localhost:/ => bingo.
> > 
> > We will probably not convince you, but there are way too many
> > alternatives to make the packaging effort worth the time.
> you convinced me, and i was well aware of that.
> But how can i convince someone with an apple that he has to download gcc and 
> compile nc or even worst convince someone with windows?

mich...@apple[12:50]:~$ uname -o
Darwin
mich...@apple[12:50]:~$ which nc
/usr/bin/nc

And, well, even a Windows version exists, see
http://en.wikipedia.org/wiki/Netcat#Variants

Best,
Michael



pgppAc17iV6IZ.pgp
Description: PGP signature

Re: scanlite / scangui - what is the difference?

[Kai Wasserbäch]

Dear Hans-J.,
I'm the maintainer of Skanlite (I assume you meant Skanlite). Skanlite is
(AFAIK) the standalone "replacement" for Kooka, which uses libksane for
accessing scanners. I started maintaining Skanlite, when I was missing Kooka
from Squeeze (Kooka is the KDE 3.x standalone scanning application and was
without upstream development for some time). After asking the Debian KDE
maintainers on IRC I was directed towards Skanlite, which wasn't in Debian back
then.

I didn't find "scangui" on the KIPI homepage [0], but from your description I'd
say it is another interface for libksane, which integrates with KIPI-aware
programs. But I might be mistaken, as I'm on vacation right now and my internet
connections is somewhat limited.

Kind regards,
Kai Wasserbäch


[0] http://www.kipi-plugins.org/drupal/node/1



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: deb...@carbon-project.org
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo Tomaselli]

On Tuesday 07 September 2010 12:54:37 Michael Tautschnig wrote:
> mich...@apple[12:50]:~$ uname -o
> Darwin
> mich...@apple[12:50]:~$ which nc
> /usr/bin/nc
> 
> And, well, even a Windows version exists, see
> http://en.wikipedia.org/wiki/Netcat#Variants
Have you considered how many windows and mac users would run away yelling if 
you'd tell them to open a terminal and type something in it?

Bye
-- 
Salvo Tomaselli


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

Re: Bug#594733: bzip2: missing symlink

[Anibal Monsalve Salazar]

On Tue, Sep 07, 2010 at 07:46:30AM +1000, Aníbal Monsalve Salazar wrote:
>On Mon, Sep 06, 2010 at 02:20:48PM -0400, Michael Gilbert wrote:
>>
>>attached is a patch for lib64bz2-1.0 also.
>>
>>best wishes,
>>mike
>
>Thank you. I already knew it. Your patch is already in bzip2_1.0.5-5.
>I'm working on it as it doesn't work.

When I checked the build logs for i386[0], powerpc[1], s390[2] and
sparc[3], the link wasn't created in the binary package lib64bz2-1.0[4].

If you see the log for amd64[5], the link was created in the binary
package lib32bz2-1.0[6].

I don't know why is that.

I tried to build bzip2_1.0.5-5 using my i386 unstable pbuilder chroot
and it failed. I then installed gcc-multilib in my chroot manually and
was able to build lib64bz2-1.0_1.0.5-5_i386.deb with the symlink.

dpkg -c lib64bz2-1.0_1.0.5-5_i386.deb | grep /usr/lib64/libbz2.so.1
-rw-r--r-- root/root 66208 2010-09-07 18:01 ./usr/lib64/libbz2.so.1.0.4
lrwxrwxrwx root/root 0 2010-09-07 18:01 ./usr/lib64/libbz2.so.1.0 -> 
libbz2.so.1.0.4
lrwxrwxrwx root/root 0 2010-09-07 18:01 ./usr/lib64/libbz2.so.1 -> 
libbz2.so.1.0.4

Does someone know why the auto builders [i386 powerpc s390 sparc]
don't create the symlink? Is it related to gcc-multilib?

[0] 
https://buildd.debian.org/fetch.cgi?pkg=bzip2&arch=i386&ver=1.0.5-5&stamp=1283691193&file=log&as=raw
[1] 
https://buildd.debian.org/fetch.cgi?pkg=bzip2&arch=powerpc&ver=1.0.5-5&stamp=1283691516&file=log&as=raw
[2] 
https://buildd.debian.org/fetch.cgi?pkg=bzip2&arch=s390&ver=1.0.5-5&stamp=1283691252&file=log&as=raw
[3] 
https://buildd.debian.org/fetch.cgi?pkg=bzip2&arch=sparc&ver=1.0.5-5&stamp=1283691817&file=log&as=raw
[4] http://packages.debian.org/search?keywords=lib64bz2-1.0
[5] 
https://buildd.debian.org/fetch.cgi?pkg=bzip2&arch=amd64&ver=1.0.5-5&stamp=1283691154&file=log&as=raw
[6] http://packages.debian.org/search?keywords=lib32bz2-1.0


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907120938.ga20...@debian.org

Bug#595932: ITP: drupal6-mod-lightbox2 -- Overlay images on the current Drupal page

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-lightbox2
  Version : 1.9
  Upstream Author : Stella Power (http://drupal.org/user/66894)
* URL : http://drupal.org/project/lightbox2
* License : GPL
  Programming Lang: PHP
  Description : Overlay images on the current Drupal page

The Lightbox2 module is a simple, unobtrusive script used to overlay images on 
the current page. It's a snap to setup and works on most modern browsers.

The module places images above your current page, not within. This frees you 
from the constraints of the layout, particularly column widths. It keeps users 
on the same page. Clicking to view an image and then having to click the back 
button to return to your site is bad for continuity (and no fun!).

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907121519.14819.28434.report...@home-br0

Re: Backports service becoming official

[Raphael Hertzog]

Hi,

On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
> 
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).

Well, I'm not sure NMU versioning would apply but +1 in general. Anyone
providing a backport is de-facto a co-maintainer of the package and should
subscribe to the PTS of the package. That way he would also be informed of
security bugs that need to be investigated for his backport.

On Tue, 07 Sep 2010, Paul Wise wrote:
> On Tue, Sep 7, 2010 at 1:46 PM, Lucas Nussbaum  
> wrote:
> 
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider
> 
> Some other possibilities;
> Move *-backports (and *-volatile) into the main archive like they are in 
> Ubuntu.
> 
> Merge the backports website into www.debian.org or wiki.debian.org.

+1 as well, I always thought that was the plan since the beginning. It's just a 
new
suite and it would benefit from the default mirror network. And 500
more packages are not going to make a difference on the current mirrors
IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907123832.ga13...@rivendell

Re: Backports service becoming official

[Henrique de Moraes Holschuh]

On Tue, 07 Sep 2010, Sune Vuorela wrote:
> I'm not planning to ever provide backports of any of my packages, and
> while others are welcome to do it, I do not in any way want to be
> bothered by their bugs or upload emails or anything.

Which would call for filtering, not for keeping the bad status-quo.

On the other hand, as the regular maintainer of a package, it is your
responsability to raise the red flags when weird stuff happens to your
packages (such as unexpected uploads, weird bug reports or anything else
that might mean someone is playing dirty tricks).  You cannot very well
do that if you're not paying attention.

IMO, backports should be coordinated with the main maintainer.  In fact,
I believe the backporter ought to become a co-maintainer, listed in
uploaders, and doing his share of the work.

> So, please keep current way.

No, the current way is extremely user-unfriendly, and very backport
maintainer-unfriendly.  It exists only because there was no way to do it
properly before.

If we need to teach some of our infrastructure to deal with different
branches, so be it.  We'll all be much better off in the long run.

-- 
  "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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907130523.gb25...@khazad-dum.debian.net

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Josselin Mouette]

Le mardi 07 septembre 2010 à 11:17 +0200, Salvo Tomaselli a écrit :
> On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote:
> > Oh, please. If you want to setup such schemes, why would you not want to
> > spend 5 minutes to configure apache or lighttpd instead of spending at
> > least the same time to configure such an obscure piece of software?
> > 
> > If all you care about is sharing a few files in the simplest way, there
> > are much better tools to do it, like gnome-user-share.
> 
> 1 you are assuming to have root permissions (read my previous email)

No. gnome-user-share does not need root permissions.

> 2 you are assuming to be working on a desktop

Well that’s usually the case when you don’t have root permissions.

> 3 you are assuming you want to share the same file all the time. But this 
> might not be the case, and change the configuration every time you want to 
> share a different file could annoying.

That’s precisely why gnome-user-share was written. Thanks for making my
point.

Now if you could give a hand in maintaining important packages, like
apache2 and its 90 open bugs, it would help more than packaging your pet
web server which will be of use for at best 2 users.

Maybe we could increase the distribution quality by requiring anyone
making an ITP to be part of a core package’s maintenance team.

Cheers,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1283865506.5236.47.ca...@meh

Bug#595942: ITP: drupal6-mod-imagecache -- Makes different sized alternatives of the same images in Drupal

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-imagecache
  Version : 2.0~beta10
  Upstream Author : Andrew Morton (http://drupal.org/user/34869)
* URL : http://drupal.org/project/imagecache
* License : GPL
  Programming Lang: PHP
  Description : Makes different sized alternatives of the same images in 
Drupal

This module lets you make different sized alternatives of the same images. It 
requires an image 
manipulation library such as GD2 or ImageMagick and requires clean urls to be 
enabled. You can 
use imagecache with any image uploaded to Drupal, so you can use it with Image 
module as well as 
normally uploaded images using the Upload module, but the most common way 
is to use it with CCK and Imagefield.

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907133515.20402.61918.report...@home-br0

Bug#595943: ITP: drupal6-mod-imageapi -- imageapi module for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-imageapi
  Version : 1.8
  Upstream Author : Andrew Morton (http://drupal.org/user/34869)
* URL : http://drupal.org/project/imageapi
* License : GPL
  Programming Lang: PHP
  Description : imageapi module for Drupal 6

This API is meant to be used in place of the API provided by
image.inc. You probably do not need to install this module unless
another module are you using requires it. It provides no new features
to your Drupal site. It only provides an API other modules can
leverage. Currently GD2 and ImageMagick support are distributed with
ImageAPI.

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907134255.20992.34107.report...@home-br0

Re: dash Debian package - RC bugs

[Gerrit Pape]

On Tue, Aug 31, 2010 at 04:34:25PM +0100, Ian Jackson wrote:
> Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> > I can't help, I don't understand.  I yesterday followed up to a mail
> > that was additionally addressed to the 
> > mailing list and got an automatic reply telling me that the mail cannot
> > be delivered because I'm not subscribed.  Not a bounce, but an automatic
> > reply to the address in the From: header, not the envelope sender
> > address.  How do you call this?
> 
> I would call it a "bounce".

I don't.  Last time I checked, non-delivery reports aka delivery
notifications aka bounces aka auto replies should work on the envelope
only, i.e. send the notification aka bounce to the envelope sender
address, ideally with an empty return path.  I think it has something to
do with loops, automatic mailers, and not parsing the headers as that is
a lot more prone to errors.  But this is long ago, think might have
changed since.

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907141002.19880.qm...@eb1ada02336c29.315fe32.mid.smarden.org

Re: dash Debian package - RC bugs

[Ralf Hildebrandt]

* Gerrit Pape :
> On Tue, Aug 31, 2010 at 04:34:25PM +0100, Ian Jackson wrote:
> > Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> > > I can't help, I don't understand.  I yesterday followed up to a mail
> > > that was additionally addressed to the 
> > > mailing list and got an automatic reply telling me that the mail cannot
> > > be delivered because I'm not subscribed.  Not a bounce, but an automatic
> > > reply to the address in the From: header, not the envelope sender
> > > address.  How do you call this?
> > 
> > I would call it a "bounce".
> 
> I don't.  Last time I checked, non-delivery reports aka delivery
> notifications aka bounces aka auto replies should work on the envelope
> only, i.e. send the notification aka bounce to the envelope sender
> address, ideally with an empty return path.

Exactly. That and nothing else is a bounce.

> I think it has something to do with loops, automatic mailers, and not
> parsing the headers as that is a lot more prone to errors.

Yep.

> But this is long ago, think might have changed since.

Nope

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907143321.ge17...@charite.de

Bug#595952: ITP: drupal6-mod-imagecache-actions -- imagecache_actions module for Drupal 6

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 


* Package name: drupal6-mod-imagecache-actions
  Version : 1.7
  Upstream Author : Dan Morrison (http://drupal.org/user/33240)
* URL : http://drupal.org/project/imagecache_actions
* License : GPL
  Programming Lang: PHP
  Description : imagecache_actions module for Drupal 6

Imagecache.module provides the most commonly-used processes needed for
basic image manipulation.

This package provides a suite of additional processes that can be
added to the imagecache pipeline, including:

 * Watermarking
 * Overlays
 * Text overlay
 * Color-shifting
 * Brighten/Darken
 * Alpha blending
 * Canvas manipulation
 * Background
 * File Format switcher
 * Rounded corners (transparent)
 * Aspect Switcher new 2009-08
 * Custom Actions

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907145903.24985.20227.report...@home-br0

Re: scanlite / scangui - what is the difference?

[Hans-J. Ullrich]

Am Dienstag, 7. September 2010 schrieb Kai Wasserbäch:
> Dear Hans-J.,
> I'm the maintainer of Skanlite (I assume you meant Skanlite). Skanlite is
> (AFAIK) the standalone "replacement" for Kooka, which uses libksane for
> accessing scanners. I started maintaining Skanlite, when I was missing
> Kooka from Squeeze (Kooka is the KDE 3.x standalone scanning application
> and was without upstream development for some time). After asking the
> Debian KDE maintainers on IRC I was directed towards Skanlite, which
> wasn't in Debian back then.
> 
> I didn't find "scangui" on the KIPI homepage [0], but from your description
> I'd say it is another interface for libksane, which integrates with
> KIPI-aware programs. But I might be mistaken, as I'm on vacation right now
> and my internet connections is somewhat limited.
> 
> Kind regards,
> Kai Wasserbäch
> 
> 
> [0] http://www.kipi-plugins.org/drupal/node/1


Hello Kai, 

scangui is part of the kipi-plugins. "apt-file search scangui" will show you.

I suppose, the KDE-people integrated your skanlite in KDE (which is ok, as it 
is GPL). See in the menu (I have German KDE, so it is below "Bilder einlesen" 
below "Grafik". 

In the other hand, skanlite should be deinstalled, when kipi-plugins are 
installed, and other round. Just to avoid double-applications. 

Maybe this is clearing things a bit.

Best regards

Hans


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009071746.33399.hans.ullr...@loop.de

Re: Backports service becoming official

[Steve Langasek]

On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> That I dont think it is. I think you not wanting t be bothered by
> backports of your packages is quite an exception,

I don't think it is.  I have no problem with people backporting any of my
packages that are useful to them, but I shouldn't have to read bug mail for
them.  I have enough bugs of my own.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#595958: ITP: paml -- Phylogenetic Analysis by Maximum Likelihood

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: paml
* URL : http://abacus.gene.ucl.ac.uk/software/paml.html
* License : academics only
  Description : Phylogenetic Analysis by Maximum Likelihood

PAML is a package of programs for phylogenetic analyses of DNA or protein 
sequences using maximum likelihood. It is maintained and distributed for 
academic use free of charge by Ziheng Yang.
PAML is not good for tree making. It may be used to estimate parameters and 
test hypotheses to study the evolutionary process, when you have reconstructed 
trees using other programs such as PAUP*, PHYLIP, MOLPHY, PhyML, RaxML, etc. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907155413.9324.91805.report...@toshiba.siemens

Re: Backports service becoming official

[Ludovico Cavedon]

On 09/06/2010 10:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
> 
> Of course, that doesn't remove the possibility for people to upload NMU
> backports when the maintainer is not responsive/interested in providing
> a backport. But then the normal rules of NMUs should apply (in
> particular, the NMUer must not change the Maintainer field, and should
> monitor the bugs of the package).

+1

Cheers,
Ludovico



signature.asc
Description: OpenPGP digital signature

Re: Backports service becoming official

[Bernd Zeimetz]

On 09/07/2010 05:57 PM, Steve Langasek wrote:
> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>> That I dont think it is. I think you not wanting t be bothered by
>> backports of your packages is quite an exception,
> 
> I don't think it is.  I have no problem with people backporting any of my
> packages that are useful to them, but I shouldn't have to read bug mail for
> them.  I have enough bugs of my own.

Chances are good that htese bugs affect your package in testing, too. Why ignore
them? Instead you should be happy that your package receives more testing.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8670d9.6050...@bzed.de

Re: Backports service becoming official

[Jan Hauke Rahm]

Hi,

On Tue, Sep 07, 2010 at 02:38:32PM +0200, Raphael Hertzog wrote:
> On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same rules of packages ownership as for
> > normal packages ("normal" backport maintainer = maintainer of the
> > package in unstable).
> > 
> > Of course, that doesn't remove the possibility for people to upload NMU
> > backports when the maintainer is not responsive/interested in providing
> > a backport. But then the normal rules of NMUs should apply (in
> > particular, the NMUer must not change the Maintainer field, and should
> > monitor the bugs of the package).
> 
> Well, I'm not sure NMU versioning would apply but +1 in general. Anyone
> providing a backport is de-facto a co-maintainer of the package and should
> subscribe to the PTS of the package. That way he would also be informed of
> security bugs that need to be investigated for his backport.
> 
> On Tue, 07 Sep 2010, Paul Wise wrote:
> > On Tue, Sep 7, 2010 at 1:46 PM, Lucas Nussbaum  
> > wrote:
> > 
> > > Now that backports are becoming official, I think that it is the right
> > > time to reconsider
> > 
> > Some other possibilities;
> > Move *-backports (and *-volatile) into the main archive like they are in 
> > Ubuntu.
> > 
> > Merge the backports website into www.debian.org or wiki.debian.org.
> 
> +1 as well, I always thought that was the plan since the beginning. It's just 
> a new
> suite and it would benefit from the default mirror network. And 500
> more packages are not going to make a difference on the current mirrors
> IMO.

+1 to everything.

Hauke

-- 
 .''`.   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

Bug#595963: RFP: yanone-kaffeesatz -- TTF and OTF font in four weights

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: yanone-kaffeesatz
  Version : 2010-05-26
  Upstream Author : Jan Gerner
* URL or Web page : http://www.yanone.de/typedesign/kaffeesatz/
* License : SIL OFL 1.1 (previously CC-BY 2.0)
  Description : TTF and OTF font in four weights

>From the website of the font:

»Yanone Kaffeesatz« was first published in 2004 and is my first ever
finished typeface. Its Bold is reminiscent of 1920s coffee house
typography, while the rather thin fonts bridge the gap to present
times. Lacking self confidence and knowledge about the type scene I
decided to publish the family for free under a Creative Commons
License. A decision that should turn out one of the best I ever made. It
has been downloaded over 100,000 times to date from this website alone,
and you can witness Kaffeesatz use on German fresh-water gyms, Dubai
mall promos and New Zealand McDonald’s ads. And of course on coffee and
foodstuff packaging and café design around the globe.

[...]

In 2010 I decided to re-release the typeface under the SIL Open Font
License to make it possible to include in software bundles or web font
services like Google’s Font Directory.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4mxv62i@kiva6.ethz.ch

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Fernando Lemos]

On Tue, Sep 7, 2010 at 7:35 AM, Mike Hommey  wrote:
> On Tue, Sep 07, 2010 at 12:27:14PM +0200, Salvo 'LtWorf' Tomaselli wrote:
>> On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
>> > What about using nc ?
>> > nc -l  < /etc/passwd
>> >
>> > http://localhost:/ => bingo.
>> >
>> > We will probably not convince you, but there are way too many
>> > alternatives to make the packaging effort worth the time.
>> you convinced me, and i was well aware of that.
>> But how can i convince someone with an apple that he has to download gcc and
>> compile nc or even worst convince someone with windows?
>
> Someone with an apple or windows doesn't need a debian package of woof.
> And someone with debian has nc.

That, and you don't really need nc on the client side. I believe most
browsers would download the file even though nc won't send any HTTP
headers. If that's not the case, try something like:

printf 'HTTP/1.0 200 OK\nContent-Type: application/octet-stream\n\n' |
cat - /etc/passwd | nc -l 


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

Re: Backports service becoming official

[Gerfried Fuchs]

Hi!

* Simon McVittie  [2010-09-06 19:33:34 CEST]:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> > What are the BTS limitations ?
> 
> I assume the relevant limitation is that in the BTS' data model, each source
> package has a single maintainer, whereas the maintainer of a backport isn't
> necessarily anything to do with the maintainer of the original package (who'd
> end up receiving backport-specific bug reports, if using the BTS).

 To me the solution is to see the person who does the backport as a part
of the packaging team. There is the need for having a communication
channel between the people anyway. Actually more and more packages are
moved into team maintenance and I'm pretty puzzled about the strong
objection on these grounds. And it would be very helpful for people that
store the packages in VCSes to have the backport changes in a seperate
branch so things won't get lost. It's IMHO the most natural thing to
do.[1][2][3]

[1] http://git.debian.org/?p=logcheck/logcheck.git;a=heads
[2] http://git.debian.org/?p=users/jgoerzen/bacula;a=heads
[3] http://git.deb.at/w/pkg/ejabberd.git/heads

 Yes, more than often enough bugs that appear in the backport do also
apply to the package in testing, so claiming that heaven would fall onto
our heads is pretty much uncalled for. In the outrageous most times
packages on backports don't have any changes, at all, and the bugs that
are only relevant for the backports version can be reduced to not
adjusted dependencies.

 I don't want to lie that bugs might not be backport specific. Just
recently the backport of iceweasel affected gnucash throug the new
libglib. This though was solved in close relationship with the involved
package maintainers and is thus a good example for how things can go
well.

 So the only limitation that really should bother us is the version
tracking. But then, like said, most bugs aren't really backports
specific, so setting a found version to the version without the ~bpo.*
part of the version string is easy to do for the time being.

 I really would like to see us trying to work together more effectively
instead of objecting to things right ahead without even knowing wether
it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
from it.

 Of course, this is my private opinion and not enpowered with any hat or
role you might see me attached with these days. Even though I really
would wish that people would collaborate more.

 Enjoy!
Rhonda
-- 
https://flattr.com/thing/47066/Debian-BTS-cleaning-up


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907183034.ga31...@anguilla.debian.or.at

Re: Backports service becoming official

[Alexander Wirt]

Lucas Nussbaum schrieb am Tuesday, den 07. September 2010:

Hi, 

> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > > relevant to backported packages still have to be reported to the
> > > > debian-backports [3] list, which have now also been moved to
> > > > lists.debian.org [4].
> > > 
> > > What are the BTS limitations ?  Perhaps it could be improved to
> > > support backports too.  Using mailing lists for this is a bit 1980's :-)
> > 
> > From what I understand it's the version tracking and the fact that 
> > backports can have a different Maintainer then the "regular" package.
> 
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
I completly disagree here. backports are different and I don't think I'll
ever treat them as you like. Thats exactly the type of bureaucracy I feared
when I got asked if I want to have backports official.

Don't expect that to happen until I am responsible for backports.

Alex


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907170724.ga12...@nelson.snow-crash.org

Re: Backports service becoming official

[Iustin Pop]

On Tue, Sep 07, 2010 at 08:35:05PM +0200, Gerfried Fuchs wrote:
>  I really would like to see us trying to work together more effectively
> instead of objecting to things right ahead without even knowing wether
> it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
> from it.

Well said. Especially since the people objecting to this seem (note
seem) to be the people who don't actually do backports…

regards,
iustin (who is very happy to care about backports too)


signature.asc
Description: Digital signature

Bug#595972: ITP: pd-libdir -- provides support for the libdir library format for Pd

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 


* Package name: pd-libdir
  Version : 1.9
  Upstream Author : Hans-Christoph Steiner 
* URL : http://puredata.info/
* License : BSD
  Programming Lang: C
  Description : provides support for the libdir library format for Pd

 The 'libdir' loader is a Pure Data loader which supports the libdir
 library format.  The libdir library format aims to be a common
 library format for Pd which works with objects written in any
 language, including Pd. This library format was designed to be easy
 to create, install, and use. It should work when installed into the
 global path (i.e. pd/extra) or when copied locally into a project
 folder. It should work with objects written in any supported language
 (i.e. binaries, .pd, and the various loaders like pdlua and
 tclpd). Also, starting with Pd 0.43 and Pd-extended 0.42, the Help
 Browser dynamically builds itself based on the libraries that are
 installed.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907183033.12245.88196.report...@blinky.at.or.at

Re: Backports service becoming official

[Steve Langasek]

On Tue, Sep 07, 2010 at 07:05:29PM +0200, Bernd Zeimetz wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
> > On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> >> That I dont think it is. I think you not wanting t be bothered by
> >> backports of your packages is quite an exception,

> > I don't think it is.  I have no problem with people backporting any of my
> > packages that are useful to them, but I shouldn't have to read bug mail for
> > them.  I have enough bugs of my own.

> Chances are good that htese bugs affect your package in testing, too.

[citation needed]

> Why ignore them? Instead you should be happy that your package receives
> more testing.

I was responding to the claim that maintainers not wanting to receive mail
about backports of their packages that they weren't involved in was
exceptional.  I'm not interested in a discussion of how you think I "should"
feel about such backports.

Frankly, backports are no different than Ubuntu, Debian Edu, or Emdebian in
this regard.  It's great that such things exist and that people are finding
other ways to put the Debian packages I maintain to use in other contexts
besides those for which they were created; and it's also great when Debian
maintainers collaborate with such derivers to make packages better for
everyone.  But when someone takes my package and uploads it somewhere other
than the main Debian archive, they incur *all* the responsibilities of
maintaining that package, including the responsibility of appropriately
triaging bug reports and forwarding them to the maintainer when relevant.
You don't get to decide that I should spend my limited Debian time triaging
bugs for someone else's version of my package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#595976: ITP: pd-ekext -- Pd objects for music information retrieval and polyphony control

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 


* Package name: pd-ekext
  Version : 0.1
  Upstream Author : Ed Kelly 
* URL : http://puredata.info/
* License : GPL-3+
  Programming Lang: C, Pd
  Description : Pd objects for music information retrieval and polyphony 
control

 This library is a collection of objects for analyzing audio to get musical
 information, like spectrum and peak information, to generate sound based on
 analysis, like Linear-Predictive Coding, and for working with polyphony.




Subject: ITP: pd-comport -- Pd object for reading and writing to serial ports
Package: wnpp
Owner: "Hans-Christoph Steiner" 
Severity: wishlist


* Package name: pd-comport
  Version : 0.1
  Upstream Author : Winfried Ritsch, Institute for Electronic Music - Graz
* URL : http://puredata.info
* License : LGPL-2.1+
  Programming Lang: C
  Description : Pd object for reading and writing to serial ports

 comport is a cross-platform object for Pure Data that allows you to read and
 write bytes and lists of data to /dev/tty* devices including serial port,
 USB-serial devices, Bluetooth-serial, etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907184552.12381.54865.report...@blinky.at.or.at

Bug#595978: ITP: pd-comport -- Pd object for reading and writing to serial ports

[Hans-Christoph Steiner]

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 


* Package name: pd-comport
  Version : 0.1
  Upstream Author : Winfried Ritsch, Institute for Electronic Music - Graz
* URL : http://puredata.info/
* License : LGPL-2.1+
  Programming Lang: C
  Description : Pd object for reading and writing to serial ports

 comport is a cross-platform object for Pure Data that allows you to read and
 write bytes and lists of data to /dev/tty* devices including serial port,
 USB-serial devices, Bluetooth-serial, etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907185230.12846.14180.report...@blinky.at.or.at

Re: Backports service becoming official

[Sune Vuorela]

On 2010-09-07, Bernd Zeimetz  wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
>> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>>> That I dont think it is. I think you not wanting t be bothered by
>>> backports of your packages is quite an exception,
>> 
>> I don't think it is.  I have no problem with people backporting any of my
>> packages that are useful to them, but I shouldn't have to read bug mail for
>> them.  I have enough bugs of my own.
>
> Chances are good that htese bugs affect your package in testing, too.

Chances are also good that my package is affected by the bugs in ubuntu,
in fedora and in upstream bugtracking system. it doesn't mean that I
want to handle them.
I have already more bugs than I can handle.

And once again, I would like to announce a 0-day bug triage policy for
all my bugs. So knock yourself out.

The day the bugcount for Qt + KDE in debian is below 100 non-forwarded 
bugs, we can start soliciting for more bug reports. Until then, I have
enough already.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni8d451.rvp.nos...@sshway.ssh.pusling.com

Bugs in Backported Packages [Was: Re: Backports service becoming official]

[Don Armstrong]

On Tue, 07 Sep 2010, Steve Langasek wrote:
> But when someone takes my package and uploads it somewhere other
> than the main Debian archive, they incur *all* the responsibilities
> of maintaining that package, including the responsibility of
> appropriately triaging bug reports and forwarding them to the
> maintainer when relevant. You don't get to decide that I should
> spend my limited Debian time triaging bugs for someone else's
> version of my package.

There are separate aspects to bugs in backported packages.

A. Where the bug exists:
  1) Main version only
  2) Backported version only
  3) Both
B. Where the bug is filed
  1) Main version
  2) Backported version

The main maintainer cares about A.1 & A.3, but (optionally?) not A.2;
the backported maintainer cares about A.2 & A.3, but probably not 1.

Currently, the BTS does not correctly handle backport branches (we
also don't properly handle -p-u or security).

Ideally, it would be possible to have bugs filed against the BTS, with
the assumption that if a bug was filed only against a backport version
(B.2), it was the backported version maintainer's responsibility to
deal with the bug, and fix the versions as appropriate if it actually
affects the main version of the package.

If the bug only affects the backport, then it should have a special
tag set (backport), and maintainers who didn't want to know about the
backport branch could filter out bug mail (and bugs) which had that
tag set.

An alternative solution is to just have reportbug mail the backport
bug reporting mailing list, and have people bounce messages as
appropriate to the BTS.


Don Armstrong

-- 
We were at a chinese resturant.
He was yelling at the waitress because there was a typo in his fortune
cookie.
 -- hugh http://www.gapingvoid.com/Moveable_Type/archives/000321.html

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


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

Re: Backports service becoming official

[Russ Allbery]

Bernd Zeimetz  writes:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:

>> I don't think it is.  I have no problem with people backporting any of
>> my packages that are useful to them, but I shouldn't have to read bug
>> mail for them.  I have enough bugs of my own.

> Chances are good that htese bugs affect your package in testing,
> too. Why ignore them?

That depends a lot on the backport.  I think that's probably true of many
of them, but there are some packages that pose special backporting
problems and risks, where the bugs are likely to be around
backport-specific things.  I'm thinking of, for instance, the OpenLDAP
packages, where backporting is likely to cause issues with the database
upgrades and BerkeleyDB format.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4mxz632@windlord.stanford.edu

Re: Backports service becoming official

[Russ Allbery]

Gerfried Fuchs  writes:

>  To me the solution is to see the person who does the backport as a part
> of the packaging team. There is the need for having a communication
> channel between the people anyway. Actually more and more packages are
> moved into team maintenance and I'm pretty puzzled about the strong
> objection on these grounds. And it would be very helpful for people that
> store the packages in VCSes to have the backport changes in a seperate
> branch so things won't get lost. It's IMHO the most natural thing to
> do.[1][2][3]

> [1] http://git.debian.org/?p=logcheck/logcheck.git;a=heads
> [2] http://git.debian.org/?p=users/jgoerzen/bacula;a=heads
> [3] http://git.deb.at/w/pkg/ejabberd.git/heads

If there's any complexity in the backport, that's probably true.  But I'll
note here that for all the backports I do for my packages, all the changes
in the backport are mechanical (and automated) and maintaining that in a
VCS is just more trouble than it's worth, so I don't bother.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwxlz5zp@windlord.stanford.edu

Re: Bugs in Backported Packages

[Sebastian Harl]

Hi,

On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> An alternative solution is to just have reportbug mail the backport
> bug reporting mailing list, and have people bounce messages as
> appropriate to the BTS.

Imho, this is the most sensible approach for now. The number of bugs
reported to backports-users was rather low in the past, so there is not
much benefit from spending a lot of time on something that's gonna safe
a bit of time only. If this happens to change at some point in the
future, we can still think about more "advanced" ways of handling this.

An, imho, nice addition could be to let reportbug also send the bug
report to the last (couple of) uploaders of the backport. This could be
done by sending an E-mail to @backports.d.o (not yet
available!). Afaik, the code for generating those kinds of aliases is
already available and would just have to be set up on backports.d.o.

Just my 2¢ …

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: Bugs in Backported Packages

[Michael Gilbert]

On Tue, 7 Sep 2010 21:56:21 +0200, Sebastian Harl wrote:
> Hi,
> 
> On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> > An alternative solution is to just have reportbug mail the backport
> > bug reporting mailing list, and have people bounce messages as
> > appropriate to the BTS.
> 
> Imho, this is the most sensible approach for now. The number of bugs
> reported to backports-users was rather low in the past, so there is not
> much benefit from spending a lot of time on something that's gonna safe
> a bit of time only. If this happens to change at some point in the
> future, we can still think about more "advanced" ways of handling this.

Doing a quick look at the backports mailing list archive, there are less
than 10 bugs reported per month on average.  That is for hundreds of
packages. Doing some fuzzy math, if you have a package that got
backported, you may see an additional 10/100 = 0.1 bug reports per
month (or roughly one bug per year). I don't see how that could be
remotely considered overburdensome.

Backports has now been declared "officially" supported by the project
as a whole.  That made it the collective responsibility of all
Debian Developers whether or not individuals in particular like it or
not.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907161848.5ead8268.michael.s.gilb...@gmail.com

Re: Bugs in Backported Packages

[Sebastian Harl]

Hi,

On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote:
> On Tue, 7 Sep 2010 21:56:21 +0200, Sebastian Harl wrote:
> > On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> > > An alternative solution is to just have reportbug mail the backport
> > > bug reporting mailing list, and have people bounce messages as
> > > appropriate to the BTS.
> > 
> > Imho, this is the most sensible approach for now. The number of bugs
> > reported to backports-users was rather low in the past, so there is not
> > much benefit from spending a lot of time on something that's gonna safe
> > a bit of time only. If this happens to change at some point in the
> > future, we can still think about more "advanced" ways of handling this.
> 
> Doing a quick look at the backports mailing list archive, there are less
> than 10 bugs reported per month on average.  That is for hundreds of
> packages. Doing some fuzzy math, if you have a package that got
> backported, you may see an additional 10/100 = 0.1 bug reports per
> month (or roughly one bug per year). I don't see how that could be
> remotely considered overburdensome.

Just to make that clear: I did not talk about any burden for the package
maintainers but the burden for the BTS maintainers/developers to add
support for bpo. Whether or not the infrastructure for that (in the BTS)
might be useful nonetheless is a different topic but I don't think bpo
warrants the effort.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: Bugs in Backported Packages

[Michael Gilbert]

On Tue, 7 Sep 2010 22:27:47 +0200, Sebastian Harl wrote:
> Hi,
> 
> On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote:
> > On Tue, 7 Sep 2010 21:56:21 +0200, Sebastian Harl wrote:
> > > On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> > > > An alternative solution is to just have reportbug mail the backport
> > > > bug reporting mailing list, and have people bounce messages as
> > > > appropriate to the BTS.
> > > 
> > > Imho, this is the most sensible approach for now. The number of bugs
> > > reported to backports-users was rather low in the past, so there is not
> > > much benefit from spending a lot of time on something that's gonna safe
> > > a bit of time only. If this happens to change at some point in the
> > > future, we can still think about more "advanced" ways of handling this.
> > 
> > Doing a quick look at the backports mailing list archive, there are less
> > than 10 bugs reported per month on average.  That is for hundreds of
> > packages. Doing some fuzzy math, if you have a package that got
> > backported, you may see an additional 10/100 = 0.1 bug reports per
> > month (or roughly one bug per year). I don't see how that could be
> > remotely considered overburdensome.
> 
> Just to make that clear: I did not talk about any burden for the package
> maintainers 

My response was directed toward the complaints about mail/bug overload
elsewhere in this thread.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907163212.a8d5fa25.michael.s.gilb...@gmail.com

Re: Bugs in Backported Packages

[Steve Langasek]

On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote:
> Doing a quick look at the backports mailing list archive, there are less
> than 10 bugs reported per month on average.  That is for hundreds of
> packages. Doing some fuzzy math, if you have a package that got
> backported, you may see an additional 10/100 = 0.1 bug reports per
> month (or roughly one bug per year). I don't see how that could be
> remotely considered overburdensome.

A single package I'm comaintainer of that has a backports.org backport has
received at least 12 bug reports to the BTS over the past year referencing
bpo versions (not counting any that might have been retargeted using
found/notfound after being filed).  The reason there are few bug reports on
the mailing list is because these *already* come to the BTS.

For the package in question, the backports are done by a fellow
comaintainer, so I'm not complaining about the bug traffic; but that doesn't
mean it's *right* for that traffic to be going to the BTS by default.

> Backports has now been declared "officially" supported by the project
> as a whole.  That made it the collective responsibility of all
> Debian Developers whether or not individuals in particular like it or
> not.

False.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bugs in Backported Packages

[Russ Allbery]

Steve Langasek  writes:

> For the package in question, the backports are done by a fellow
> comaintainer, so I'm not complaining about the bug traffic; but that
> doesn't mean it's *right* for that traffic to be going to the BTS by
> default.

I wonder if we could apply some logic such as if the backports uploader is
also listed in Maintainer or Uploaders for the regular Debian package,
send the bug reports to the BTS, otherwise send them to backports-users
and the backport uploader.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqwpxnuj@windlord.stanford.edu

Re: Bugs in Backported Packages

[Michael Gilbert]

On Tue, 7 Sep 2010 13:48:09 -0700, Steve Langasek wrote:
> On Tue, Sep 07, 2010 at 04:18:48PM -0400, Michael Gilbert wrote:
> > Doing a quick look at the backports mailing list archive, there are less
> > than 10 bugs reported per month on average.  That is for hundreds of
> > packages. Doing some fuzzy math, if you have a package that got
> > backported, you may see an additional 10/100 = 0.1 bug reports per
> > month (or roughly one bug per year). I don't see how that could be
> > remotely considered overburdensome.
> 
> A single package I'm comaintainer of that has a backports.org backport has
> received at least 12 bug reports to the BTS over the past year referencing
> bpo versions (not counting any that might have been retargeted using
> found/notfound after being filed).  The reason there are few bug reports on
> the mailing list is because these *already* come to the BTS.
> 
> For the package in question, the backports are done by a fellow
> comaintainer, so I'm not complaining about the bug traffic; but that doesn't
> mean it's *right* for that traffic to be going to the BTS by default.
> 
> > Backports has now been declared "officially" supported by the project
> > as a whole.  That made it the collective responsibility of all
> > Debian Developers whether or not individuals in particular like it or
> > not.
> 
> False.

So you're saying that a move to debian.org actually does not make it
officially part of Debian (even though a lot of blogs are claiming just
that)? If that's the case then I agree that there is no collective
responsibility. That's good since it eliminates what was going to be a
significant additional burden for the security team.

What would be required to finally declare it "officially" supported?  A
vote?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907171314.55c860c5.michael.s.gilb...@gmail.com

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Stephen Kitt]

On Tue, 7 Sep 2010 10:13:15 +0100, David Goodenough
 wrote:
> On Tuesday 07 September 2010, Adam Borowski wrote:
> > Then, in the usual Debian parlance, "nonfree" usually suggests
> > proprietary gratis distributable things.  Winetricks includes a mix of
> > distributable, non-distributable and even non-gratis software (the last
> > cathegory requires that you have a valid Windows license).
> That is not true.  Winetricks is itself entirely free, and is just a simple
> script.  It then downloads the other materials from public web sites,
> but by no measure can those other materials be regarded as part of
> wine-tricks - Microsoft would have something to say about that if it
> were claimed that they were part.

There are even certain winetricks commands which don't install anything at
all, they simply change settings in the given wine prefix.

(Taken in context though I don't think Adam had a significantly different
positions from yours, David; the idea here as I understand it was to package
redistributable downloads referenced by winetricks in a Debian package, which
would go into non-free to avoid having to figure out how to rebuild
everything using tools in main, but to which a "nonfree" qualifier wouldn't
be applicable.)

> On Tuesday 07 September 2010, Adam Borowski wrote:
> > In the past, there was opposition to shipping random free software for
> > Windows inside Debian, for good reasons.  And since most of the rest in
> > undistributable, packaging winetrick as a big installer (in main!) is
> > probably the best idea.

I agree, I don't think it would be appropriate to try to package the
DFSG-free Windows software installable via winetricks (such as 7-zip); in any
case, packaging winetricks needn't involve shipping random free software for
Windows inside Debian.

There are other considerations which haven't been brought up in this thread
so far.

One big objection I can see is that many of winetricks's uses involve
downloading third-party software from web sites and installing it
automatically on the user's system; admittedly the user is requesting it, but
there's a good chance many users will simply be using winetricks because they
are following instructions from a forum post somewhere, so even that doesn't
necessarily mean much. (A similar argument applies to simply letting wine
download wine-gecko rather than packaging it properly in Debian.) That might
be fixable but it's a huge endeavour and it wouldn't earn us any bonus points
with upstream (I'm thinking along the lines of packaging redistributable
components properly, and stripping winetricks of references to
non-redistributable downloads - which would mean our winetricks wouldn't be
the same as upstream's, and following common instructions involving
winetricks wouldn't work in Debian).

Another objection is that providing winetricks increases the support burden;
this could be turned into an advantage (compared to users simply downloading
winetricks themselves) by adding code to (or around) winetricks so that any
changes made to wine prefixes using winetricks can be traced in bug reports.
(In a similar fashion to kernel tainting...)

winetricks also generally only works well with recent versions of wine, so
it's only really sensible to package it once we manage to keep up with wine!

(These last two are simply the first two warnings given on
http://wiki.winehq.org/winetricks .)

All this is rather negative, but I'm not sure myself whether
packaging winetricks would be a good idea or not! I do think that if it does
get packaged, it should be in its own package (since its releases aren't
synchronised with wine, as has been pointed out previously). Alternatively,
one way of "packaging" it could be to add a winetricks installer (and
updater) to the wine package...

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907231101.7f988...@sk2.org

Re: Bugs in Backported Packages

[Timo Juhani Lindfors]

Michael Gilbert  writes:
> Doing a quick look at the backports mailing list archive, there are less
> than 10 bugs reported per month on average.  That is for hundreds of
> packages. Doing some fuzzy math, if you have a package that got
> backported, you may see an additional 10/100 = 0.1 bug reports per
> month (or roughly one bug per year). I don't see how that could be
> remotely considered overburdensome.

I am not using backports precisely because they lack a bug tracker. If
backports gets a bug tracker then I'm probably going to use them and
you can expect more bug reports :-)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/847hixi6he@sauna.l.org

Bug#596011: ITP: tinyeartrainer -- A tool to learn recognizing musical intervals

[Tiago Bortoletto Vaz]

Package: wnpp
Severity: wishlist
Owner: Tiago Bortoletto Vaz 


* Package name: tinyeartrainer
  Version : 0.1.0
  Upstream Author : Jonas Wagner 
* URL : http://29a.ch/tinyeartrainer
* License : GPL
  Programming Lang: Python
  Description : A tool to learn recognizing musical intervals

 Tiny Ear Trainer is a tiny piece of software that helps you to recognize
 musical intervals.
 .
 Implemented features include associating colors to intervals and learning mode
 which plays interval together with color and name. Harmonic and melodic
 intervals are supported. It uses fluidsynth/soundfonts for playback.
 .
 Tiny Ear Trainer works with JACK Audio Connection Kit.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907215316.2713.35737.report...@x61

Re: how to best handle this library update?

[Peter Samuelson]

[sean finney]
> 1) split out the c++ libraries, make the c++ library conflict with the older
> version of libxmlrpc-c3 (conflicting files) make the -dev package
> depend on both libraries, and hope that a half dozen binNMU's fix the
> problem quickly enough.
> 2) do (1) but also fake an abi break in the c libraries, renaming this
> package as well (i could leave the SONAME the same though, right?
> allowing the old libraries to stay while the transition takes place.

If you keep the same SONAME for the C library, it will have to Breaks
(or Conflicts) libxmlrpc-c3, so that won't really accomplish the
seamless upgrade you want with 2).

I think what you want is 2), keeping the C SONAME, but adding Breaks +
Replaces (but not Provides, since you aren't providing the C++ lib),
followed by a round of binNMU.  Preferably not in unstable until after
squeeze, unless it's actually targeted to squeeze at this late date, as
this is a library transition that can prevent migration of any of your
rdepends.

Peter


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907215239.gk3...@p12n.org

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Andreas Barth]

* Stephen Kitt (st...@sk2.org) [100907 23:27]:
> I agree, I don't think it would be appropriate to try to package the
> DFSG-free Windows software installable via winetricks (such as 7-zip); in any
> case, packaging winetricks needn't involve shipping random free software for
> Windows inside Debian.

For example, 7zip is only used to extract Visual C++ 2005 Trial files.
Why can't we use e.g. p7zip for that, which is already packaged in
Debian?  I think that would be way better.


So, part of the task would involve to replace dependencies on "some"
windows software by Software already in Debian. (As one could even
associate file extensions with linux software, it's quite possible to
write wrapper scripts that can be called from windows and execute
normal debian code.)


Of course, this isn't possible for all usages of winetricks, but the
more the better. (And it's not necessary to have all work done for the
first upload - this is something that could be done step by step.)


> Another objection is that providing winetricks increases the support burden;
> this could be turned into an advantage (compared to users simply downloading
> winetricks themselves) by adding code to (or around) winetricks so that any
> changes made to wine prefixes using winetricks can be traced in bug reports.
> (In a similar fashion to kernel tainting...)

That should be done as well.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907220100.gn15...@mails.so.argh.org

Re: Bugs in Backported Packages

[Steve Langasek]

On Tue, Sep 07, 2010 at 05:13:14PM -0400, Michael Gilbert wrote:
> > > Backports has now been declared "officially" supported by the project
> > > as a whole.  That made it the collective responsibility of all
> > > Debian Developers whether or not individuals in particular like it or
> > > not.

> > False.

> So you're saying that a move to debian.org actually does not make it
> officially part of Debian (even though a lot of blogs are claiming just
> that)? If that's the case then I agree that there is no collective
> responsibility. That's good since it eliminates what was going to be a
> significant additional burden for the security team.

No, I'm saying that being "officially part of Debian" does not make it
"officially supported by the project as a whole" or "the cllective
responsibility of all Debian Developers".

> What would be required to finally declare it "officially" supported?  A
> vote?

That would be far preferable to having people declaring randomly on mailing
lists that backports are now "our collective responsibility".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Salvo Tomaselli]

On Tuesday 07 September 2010 15:18:26 Josselin Mouette wrote:
> No. gnome-user-share does not need root permissions.
I use kde. After installing your gnome-user-share it i couldn't find how to 
start it. I found a configuration window but netstat -l doesn't show anything 
listening.
Also no man page provided -> too complex for me, really.

The netcat thing is much easier. At least man nc exists.

> Well that’s usually the case when you don’t have root permissions.
Long example:
i own a box that has no screen and uses ssh. There are many entries in 
/etc/shadow but only one of the users knows the root password.


> Now if you could give a hand in maintaining important packages, like
> apache2 and its 90 open bugs, it would help more than packaging your pet
> web server which will be of use for at best 2 users.
I didn't do the ITP.

> Maybe we could increase the distribution quality by requiring anyone
> making an ITP to be part of a core package’s maintenance team.
You could indeed suggest that, but some people just don't have enough time or 
skills to be usefull in a core package, and your proposal wouldn't lead to a 
better maintenance of core packages but just to the dropping of less important 
packages.

Bye
-- 
Salvo Tomaselli


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

Re: Bugs in Backported Packages

[Michael Gilbert]

On Tue, 7 Sep 2010 15:03:56 -0700 Steve Langasek wrote:

> On Tue, Sep 07, 2010 at 05:13:14PM -0400, Michael Gilbert wrote:
> > > > Backports has now been declared "officially" supported by the project
> > > > as a whole.  That made it the collective responsibility of all
> > > > Debian Developers whether or not individuals in particular like it or
> > > > not.
> 
> > > False.
> 
> > So you're saying that a move to debian.org actually does not make it
> > officially part of Debian (even though a lot of blogs are claiming just
> > that)? If that's the case then I agree that there is no collective
> > responsibility. That's good since it eliminates what was going to be a
> > significant additional burden for the security team.
> 
> No, I'm saying that being "officially part of Debian" does not make it
> "officially supported by the project as a whole" or "the cllective
> responsibility of all Debian Developers".

You're missing my point.  My concern is the stonewalling of the
collective effort of those working to make backports a well-supported,
user-friendly part of the Debian ecosystem. And all of in the name of a
solved problem: email management.  I just don't get it.

Your campaign was effective against the useful package emails, and I
don't really want to see that happen again.

Let the collective do its work without interference.  Please :)

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100907205756.5406657b.michael.s.gilb...@gmail.com

Re: Bugs in Backported Packages

[Don Armstrong]

On Tue, 07 Sep 2010, Sebastian Harl wrote:
> Just to make that clear: I did not talk about any burden for the
> package maintainers but the burden for the BTS
> maintainers/developers to add support for bpo. Whether or not the
> infrastructure for that (in the BTS) might be useful nonetheless is
> a different topic but I don't think bpo warrants the effort.

These bits will eventually happen, because they are necessary to
implement CUT and some of the other nice things that I'd personally
like to see. They haven't happened yet because I'm lacking time to
really implement them all, unfortunatly.


Don Armstrong

-- 
Fate and Temperament are two words for one and the same concept.
 -- Novalis [Hermann Hesse _Demian_]

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


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

Re: Backports service becoming official

[Paul Wise]

On Wed, Sep 8, 2010 at 3:52 AM, Russ Allbery  wrote:

> If there's any complexity in the backport, that's probably true.  But I'll
> note here that for all the backports I do for my packages, all the changes
> in the backport are mechanical (and automated) and maintaining that in a
> VCS is just more trouble than it's worth, so I don't bother.

That is another thing I had wanted; automated rebuild-only backports
for those cases where shibs were bumped or similar.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#596030: ITP: mono-uia-atspi -- At-spi UIA source

[Ray Wang]

Package: wnpp
Severity: wishlist
Owner: Ray Wang 


* Package name: mono-uia-atspi
  Version : 2.1
  Upstream Author : Mono Accessibility 
* URL : http://www.mono-project.com/Accessibility
* License : MIT/X
  Programming Lang: C#
  Description : At-spi UIA source

 At-spi UIA source client side



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100908032925.5802.78802.report...@ray-laptop

Re: Bugs in Backported Packages

[Steve Langasek]

On Tue, Sep 07, 2010 at 08:57:56PM -0400, Michael Gilbert wrote:
> On Tue, 7 Sep 2010 15:03:56 -0700 Steve Langasek wrote:

> > On Tue, Sep 07, 2010 at 05:13:14PM -0400, Michael Gilbert wrote:
> > > > > Backports has now been declared "officially" supported by the project
> > > > > as a whole.  That made it the collective responsibility of all
> > > > > Debian Developers whether or not individuals in particular like it or
> > > > > not.

> > > > False.

> > > So you're saying that a move to debian.org actually does not make it
> > > officially part of Debian (even though a lot of blogs are claiming just
> > > that)? If that's the case then I agree that there is no collective
> > > responsibility. That's good since it eliminates what was going to be a
> > > significant additional burden for the security team.

> > No, I'm saying that being "officially part of Debian" does not make it
> > "officially supported by the project as a whole" or "the cllective
> > responsibility of all Debian Developers".

> You're missing my point.  My concern is the stonewalling of the
> collective effort of those working to make backports a well-supported,
> user-friendly part of the Debian ecosystem. And all of in the name of a
> solved problem: email management.

Thank you for volunteering to write the procmail rules for me that discard
all emails from bug reports filed only against bpo versions of packages,
with no false positives.  I trust you will have them available by next week.

> Let the collective do its work without interference.  Please :)

Ah, appeals to the silent majority.  How droll.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bugs in Backported Packages [Was: Re: Backports service becoming official]

[Steve Langasek]

On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> On Tue, 07 Sep 2010, Steve Langasek wrote:
> > But when someone takes my package and uploads it somewhere other
> > than the main Debian archive, they incur *all* the responsibilities
> > of maintaining that package, including the responsibility of
> > appropriately triaging bug reports and forwarding them to the
> > maintainer when relevant. You don't get to decide that I should
> > spend my limited Debian time triaging bugs for someone else's
> > version of my package.

> There are separate aspects to bugs in backported packages.

> A. Where the bug exists:
>   1) Main version only
>   2) Backported version only
>   3) Both
> B. Where the bug is filed
>   1) Main version
>   2) Backported version

> The main maintainer cares about A.1 & A.3, but (optionally?) not A.2;
> the backported maintainer cares about A.2 & A.3, but probably not 1.

> Currently, the BTS does not correctly handle backport branches (we
> also don't properly handle -p-u or security).

> Ideally, it would be possible to have bugs filed against the BTS, with
> the assumption that if a bug was filed only against a backport version
> (B.2), it was the backported version maintainer's responsibility to
> deal with the bug, and fix the versions as appropriate if it actually
> affects the main version of the package.

> If the bug only affects the backport, then it should have a special
> tag set (backport), and maintainers who didn't want to know about the
> backport branch could filter out bug mail (and bugs) which had that
> tag set.

That sounds pretty sensible to me.  Thanks for putting the effort into this.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bugs in Backported Packages

[Christian PERRIER]

Quoting Steve Langasek (vor...@debian.org):

> A single package I'm comaintainer of that has a backports.org backport has
> received at least 12 bug reports to the BTS over the past year referencing
> bpo versions (not counting any that might have been retargeted using
> found/notfound after being filed).  The reason there are few bug reports on
> the mailing list is because these *already* come to the BTS.


Are you talking about samba, Steve?

If so, you're right that we get some bug reports about our bpo
packagesbut it happens that backports are done by your
comaintainer..:-)...and we already noticed several times that these
bugs helped us (OK, often me, indeed) working on bugs on our testing
packages. We even sometimes ask users who report issues on packages in
stable to try teproducing them with backports;.:)

So, in that case of a package where backports are very important to
users, I think that having the bugs in the BTS is a benefit. It indeed
goes along with the fact that the regular maintainers (at least one of
them) cared enough abotu backports to do the work him|herself.

If you're not talking about samba, then most of what I'm saying is not
adapted.

How about a kind of opt-in system where bugs sent to bpo packages
would by default *not* be sent inserted in the BTSunless the
maintainer (the "official" one) accepts this. That could be done with
a special control field in debian/control of the backported package
(that would assume some kind of pre-agreement between the main
maintainer and the backport uploader).



signature.asc
Description: Digital signature