On Wed, Nov 04, 2009 at 08:08:46AM +0100, sean finney wrote:
> > We have webservers other than Apache.
When raising this kind of counter argument, is usually nice to also
provide (pointers to) solutions :-)
> and many of these other web servers provide a feature similar to Alias.
> with respect t
On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote:
> > Do you understand why people are getting annoyed ?
> They have a lot of bloody gall to be annoyed thatpeople file
> bugs about serious policy violations that they have signed up to
> follow, and neglected in their pac
On Tue, Nov 03, 2009 at 02:54:48PM -0800, John H. Robinson, IV wrote:
> > Reading ?5.3 of the above link, I wonder whether the following solution
> > would be appropriate:
> >
> > - ship under /etc/apache2/conf.d/ a snippet with an Alias dir mapping
> > the package name to a dir containing the s
hi zack,
On Tue, Nov 03, 2009 at 10:49:42PM +0100, Stefano Zacchiroli wrote:
> Reading §5.3 of the above link, I wonder whether the following solution
> would be appropriate:
>
> - ship under /etc/apache2/conf.d/ a snippet with an Alias dir mapping
> the package name to a dir containing the sta
On Tue, Nov 03 2009, Charles Plessy wrote:
> Le Tue, Nov 03, 2009 at 01:01:02PM -0600, Manoj Srivastava a écrit :
>>
>> when we do add such a lintian check to the blacklist, we also file serious
>> bugs against those packages in the archive; and aggressively work to either
>> fix the packages,
On Tue, Nov 03 2009, Joerg Jaspert wrote:
>> I don't think it's appropriate to make, for instance,
>> dir-or-file-in-var-www instantly fatal without following the usual
>> mass-bug-filing procedure. If you'd like mass bugs to be filed based
>> on these lintian tags but don't have time, let me know
רҵ´ú¿ª¸÷ÀàÕý¹æÆÕͨ.¹úË°·¢Æ± µãÊý´ÓÓÅ
ÁªÏµÈË:Ò¶ÏÈÉú
µç»°:159 99678 116
(ÈçÓдòÈÅ.¾´ÇëÁ½â)ËÑ
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-devel
> I don't think it's appropriate to make, for instance, dir-or-file-in-var-www
> instantly fatal without following the usual mass-bug-filing procedure. If
> you'd like mass bugs to be filed based on these lintian tags but don't have
> time, let me know if I can help (I can't promise to deal with a
If you maintain a debian package that directly uses libtiff or if you
maintain software that uses libtiff, it would be a great help if you
could test your packages against the version of libtiff in experimental,
4.0.0~beta4. If you find any problems, please report them as bugs
against the tiff pa
Le Tue, Nov 03, 2009 at 01:01:02PM -0600, Manoj Srivastava a écrit :
>
> when we do add such a lintian check to the blacklist, we also file serious
> bugs against those packages in the archive; and aggressively work to either
> fix the packages, or remove them from the archive.
It is very uncl
Hector Oron writes:
> Hello,
>
> 2009/11/2 Goswin von Brederlow :
>> Why do you need --sysroot support? Or what prevents a --sysroot of /
>> when using the multiarch directories?
>>
>> It seems like wasted work with multiarch being a release goal for
>> squeeze. Hop on the wagon and make it work
Stefano Zacchiroli wrote:
>
> Reading ?5.3 of the above link, I wonder whether the following solution
> would be appropriate:
>
> - ship under /etc/apache2/conf.d/ a snippet with an Alias dir mapping
> the package name to a dir containing the static content (a single html
> file, usually)
> -
On Tue, 03 Nov 2009 20:22:14 +0100
Goswin von Brederlow wrote:
> Hector Oron writes:
>
> > Hello,
> >
> > 2009/11/2 Goswin von Brederlow :
> >> Why do you need --sysroot support? Or what prevents a --sysroot
> >> of / when using the multiarch directories?
> >>
> >> It seems like wasted work wit
Hi
Dne Tue, 3 Nov 2009 22:49:42 +0100
Stefano Zacchiroli napsal(a):
> I'm looking at some of the dir-or-file-in-var-www bugs reported by
> Manoj. A recurrent pattern is that of packages that ship, as their
> static content, a single .html file, usually a form for triggering some
> CGI app. All o
On Tue, Nov 03, 2009 at 09:06:25PM +0100, Bernhard R. Link wrote:
> If you do an NMU you hopefully will look at the lintian output of your
> upload. With old or hardly maintained packages that will be complicated
> because you have to look at the lintian messages for the unmodified
> packages and f
On Tue, Nov 03 2009, Stefano Zacchiroli wrote:
> On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote:
>> > The ideal solution would be to have dak know the previous state and do
>> > not accept _regressions_ wrt the previous set of fatal upload errors
>> > (according to the proposed w
Package: wnpp
Severity: wishlist
Owner: Carl Chenet
* Package name: python-jabberbot
Version : 0.7
Upstream Author : Thomas Perl
* URL : http://thpinfo.com/2007/python-jabberbot/
* License : GPL
Programming Lang: Python
Description : easily write simp
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, ifupd...@packages.debian.org
Hi all,
As you may or may not know, I've been working on an alternative
implementation of ifup and ifdown, which I call 'ipcfg', for a few
months now[1]. The code is now nearly at t
* Stefano Zacchiroli [091103 17:32]:
> For packages that are now in the archive with lintian errors that would
> have prevented them to be uploaded, you're right. However, as a corner
> case, you can imagine a new lintian check added 10 years from now, and
> that check be used to refuse uploads. A
Since people didn't like the previous code, try the following version with
safer memory handling. It still segfaults when using the shared library and
doesn't when using the static one. Replacing the line above with the
commented out line works in both cases (since we're no longer relying on
SHA1
On Tue, Nov 03, 2009 at 12:29:46PM -0500, N N wrote:
> #include
> #include
>
> int main(int argc, char** argv) {
> unsigned char foo[10] = "boo";
> unsigned char* res = malloc(20);
> unsigned char* res2 = res;
> res = SHA1(foo, 3, 0);
> //res = SHA1(foo, 3, res);
>
> int i;
> for
On Oct 28, Guus Sliepen wrote:
> polipo and ircd-hybrid are the only ones that are problematic for me. I guess
> things have improved. Well, except for those daemons that are not listening on
> IPv6 at all of course...
ircds need custom configuration anyway, so this does not look like a
problem.
Hi,
On Tue, Nov 03, 2009 at 12:29:46PM -0500, N N wrote:
> Since people didn't like the previous code, try the following version with
> safer memory handling.
Debian-devel is not a bug-reporting or programming-discussion list.
Please post elsewhere.
thanks,
Michael
--
To UNSUBSCRIBE, emai
Stefano Zacchiroli wrote:
> On Tue, Nov 03, 2009 at 09:28:01AM +0900, Charles Plessy wrote:
> On Mon, Nov 02, 2009 at 05:00:53PM -0800, Russ Allbery wrote:
>> Surely the answer to that question is obvious: fix the bugs Lintian is
>> finding that prevent upload. They're the equivalent of RC bugs (
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: libqt4intf
Version: 1.72Qt4.5.2
Upstream Author: Jonatan Liljedahl
URL: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html
License: LGPL
Programming Language: C++, Pascal
Description: Qt4 in
On Mon, Nov 02, 2009 at 02:04:29PM +, Neil McGovern wrote:
> Have a read of
> http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html
Thanks for the pointer, I gave it a go.
I'm looking at some of the dir-or-file-in-var-www bugs reported by
Manoj. A recurrent pattern is that of packa
On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote:
> > The ideal solution would be to have dak know the previous state and do
> > not accept _regressions_ wrt the previous set of fatal upload errors
> > (according to the proposed wording). I'm not sure it is worth though,
>
>
On Tue, Nov 03 2009, Stefano Zacchiroli wrote:
> I don't think it is that simple. For once, we need to refine
> some of our guidelines (that's the easy part). Devref §5.11.1 authorizes
> to upload only changes that fix RC bugs older than X days, so if lintian
> is complaining about issues not cor
Hi.
Sorry to be late on that discussion (vacation time in between). I'm just
adding a few bits in case it would help.
Le lundi 19 octobre 2009 à 12:54 +0200, Joachim Breitner a écrit :
> Hi,
>
SNIP
> I thought about bts-link as well, of course, but there are some
> differences in what is tried
Hi.
Some more feedback, again.
Le lundi 19 octobre 2009 à 11:21 -0700, Don Armstrong a écrit :
> On Mon, 19 Oct 2009, Joachim Breitner wrote:
> > @dons: What are your requirements until you will accept this feature on
> > bugs.d.o, in terms of number of packages or clear consensus on d-devel
> >
N N writes:
> Apologies if this is the wrong list. If so, please direct me to the
> appropriate one.
>
> Consider the following C code:
>
> include
> #include
>
> int main(int argc, char** argv) {
> unsigned char foo[10] = "boo";
> printf("%s\n", SHA1(foo, 3, 0));
> }
>
> in file test-hmac
Hello,
2009/11/2 Goswin von Brederlow :
> Why do you need --sysroot support? Or what prevents a --sysroot of /
> when using the multiarch directories?
>
> It seems like wasted work with multiarch being a release goal for
> squeeze. Hop on the wagon and make it work for you too.
As you already kno
On Tue, 2009-11-03 at 07:31 +0100, Florian Weimer wrote:
> * Ben Hutchings:
>
> > You can disagree all you like, but I believe that the FTP team will
> > currently reject any new packages that use source code from their build-
> > dependencies.
>
> Surely this is not true because that would rule
On Tue, Nov 03, 2009 at 09:28:01AM +0900, Charles Plessy wrote:
> I reproduce here the one from Brian May, which I think is very
> relevant and was asked in many different ways, and always ignored:
>
>
> http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au
>
>
34 matches
Mail list logo
