Tobi writes:
> /usr/share/vdr-dev/dependencies.sh. But the shebang simply is nothing to
> worry about.
May I ask what's the reason you're using this kind of a convoluted
system? Wouldn't it be simpler to separate debian/make-special-vdr.sh
and debian/rules, and call debian/make-special-vdr.sh dir
On Thu, 2009-10-29 at 17:58 -0700, Steve Langasek wrote:
>
> > Not true. If you were not familiar with the special script, you
> would
> > have to read that entire script to understand what it does. OTOH, in
> the
> > make-only approach it is easier to discard the contents of
> > alternate-debian-
On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 27 Oct 2009, Kees Cook wrote:
> > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > > I would like to propose enabling[1] the GC
On Thu, Oct 29, 2009 at 03:54:23PM +, Matthew Johnson wrote:
> On Thu Oct 29 15:58, Michael Banck wrote:
> > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > > Are there any serious objections against just overriding and ignoring
> > > the Linitan warning about not having "make -f" in
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 614 (new: 16)
Total number of packages offered up for adoption: 151 (new: 3)
Total number of packages reques
Manoj Srivastava wrote:
> If I ahve the magic variables set, and call it as
> % make -f ./debian/rules,
> I get the standard behaviour. If I turn around and call it as
> % ./debian/rules,
> I get totally different behaviour.
True but if you DON'T set the magic variable, you g
On Tue, 27 Oct 2009, Kees Cook wrote:
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they als
On Thu, 2009-10-29 at 09:26 +, Stefano Zacchiroli wrote:
> On Tue, Oct 20, 2009 at 07:17:53AM +0200, Frank Lin PIAT wrote:
> > I have written a small script to make it easy to submit manpage
> > improvements (it's attached).
>
> Hi Franklin,
> in the end, have you decided where/how to ship t
Philipp Kern writes:
> On 2009-10-29, Goswin von Brederlow wrote:
>> We just had a similar issue (Architecture: linux-any) on irc yesterday
>> and the outcome was that linux-any will only work post squeeze because
>> the buildd need to grog that syntax too and run stable outside the
>> build chr
On Thu, 29 Oct 2009, Christoph Anton Mitterer wrote:
> On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote:
> > Well, the issue raised in LKML is that you absolutely should *not* enable
> > -fstack-protector-all unless you _really_ know what you're doing, and most
> > certainly not
On Thu, 2009-10-29 at 15:54 +, Matthew Johnson wrote:
> On Thu Oct 29 15:58, Michael Banck wrote:
> > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > > Are there any serious objections against just overriding and ignoring
> > > the Linitan warning about not having "make -f" in the she
On Thu, Oct 29 2009, Tobi wrote:
> But like Philipp, Lucas or Charles I believe, that the policy is too
> specific in requiring a fixed shebang line, instead of just stating, that
> debian/rules must be a Makefile which should execute itself when ran as a
> binary.
What no one has addres
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: algoscore
Version: 081112
Upstream Author: Jonatan Liljedahl
URL: http://www.bitminds.net/kymatica/index.php/Software/AlgoScore
License: GPL
Programming Language: C, Nasal
Description: GUI for algori
* Dmitry E. Oboukhov:
> Yes, my first _mail_ contained a mistake, src-code didn't.
>
> Full code here: http://svn.uvw.ru/mhddfs/trunk/src/debug.c
Is this really multi-threaded code? I think you still need to use
localtime_r etc. on GNU/Linux. We aren't Solaris (unfortunately).
--
To UNSUBSCR
Philipp Kern wrote:
> I didn't say that, right? Please don't lay words into my mouth. I said
> "here" to specify the concrete case of policy describing the first n bytes
> of debian/rules despite the interface being completely in accordance with
> the normal procedures (i.e. being a Makefile and
On 2009-10-29, Manoj Srivastava wrote:
> On Thu, Oct 29 2009, Philipp Kern wrote:
>> On 2009-10-29, Joerg Jaspert wrote:
>>> It is not an overridable error, and I haven't seen any reason yet to
>>> convince me to make it one. You do have some reasons, but none I have
>>> seen that would not be si
On 2009-10-29, Goswin von Brederlow wrote:
> We just had a similar issue (Architecture: linux-any) on irc yesterday
> and the outcome was that linux-any will only work post squeeze because
> the buildd need to grog that syntax too and run stable outside the
> build chroot.
However the newer sbuil
On Thu, Oct 29 2009, Philipp Kern wrote:
> On 2009-10-29, Joerg Jaspert wrote:
>> It is not an overridable error, and I haven't seen any reason yet to
>> convince me to make it one. You do have some reasons, but none I have
>> seen that would not be simple to do in make directly as well.
>>
>> As
Andres Mejia writes:
> On Thu, Oct 29, 2009 at 11:12 AM, Felipe Sateler wrote:
>> I need to build-depend on a version of libc. Since they have different
>> names in different architectures, I used linux-any kfreebsd-any and
>> hurd-any to avoid spelling the entire list. However, lintian warned m
On 2009-10-29, Joerg Jaspert wrote:
> It is not an overridable error, and I haven't seen any reason yet to
> convince me to make it one. You do have some reasons, but none I have
> seen that would not be simple to do in make directly as well.
>
> As long as you have those packages wherever, feel f
> Are there any serious objections against just overriding and ignoring
> the Linitan warning about not having "make -f" in the shebang line?
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I have
seen that would
On Thu, Oct 29, 2009 at 11:12 AM, Felipe Sateler wrote:
> I need to build-depend on a version of libc. Since they have different
> names in different architectures, I used linux-any kfreebsd-any and
> hurd-any to avoid spelling the entire list. However, lintian warned me
> about that. Is it safe t
>> I have a package which contains a code like following:
>>
>> #include
>>
>> FILE *file_handle;
>>
>> int foo(int something, const char *fmt, ...)
>> {
>> // some statements
>>
>> va_list ap;
>> int res = vfprintf(file_handle, fmt, ap);
>> va_end(ap);
>> return re
GJ> On Thu, 2009-10-29 at 18:33:12 +0300, Dmitry E. Oboukhov wrote:
>> I have a package which contains a code like following:
>>
>> #include
>>
>> FILE *file_handle;
>>
>> int foo(int something, const char *fmt, ...)
>> {
>> // some statements
>>
>> va_list ap;
GJ> Seems you a
"Dmitry E. Oboukhov" writes:
> I have a package which contains a code like following:
>
> #include
>
> FILE *file_handle;
>
> int foo(int something, const char *fmt, ...)
> {
> // some statements
>
> va_list ap;
> int res = vfprintf(file_handle, fmt, ap);
> va_end(ap);
>
Dmitry E. Oboukhov, le Thu 29 Oct 2009 18:33:12 +0300, a écrit :
> I have a package which contains a code like following:
>
>
>
> This code works fine by libc wouldn't be rebuilt (new versions, or new
> gcc - this moment is ambiguous to me).
> Then this code begins segfaulting into this place.
>
Felipe Sateler, le Thu 29 Oct 2009 12:12:33 -0300, a écrit :
> I need to build-depend on a version of libc. Since they have different
> names in different architectures, I used linux-any kfreebsd-any and
> hurd-any to avoid spelling the entire list.
That won't work for ia64 and alpha which have li
On Thu Oct 29 15:58, Michael Banck wrote:
> On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > Are there any serious objections against just overriding and ignoring
> > the Linitan warning about not having "make -f" in the shebang line?
>
> As long as you don't have an objection against hav
Hi!
On Thu, 2009-10-29 at 18:33:12 +0300, Dmitry E. Oboukhov wrote:
> I have a package which contains a code like following:
>
> #include
>
> FILE *file_handle;
>
> int foo(int something, const char *fmt, ...)
> {
> // some statements
>
> va_list ap;
Seems you are missing a v
>> Could we add 'ReBuild-Depends' statement into debian/control to
>> rebuild like packages when depends rebuild? But such kind of depends
>> require some changes in buildd system.
JV> This is only needed when the dependencies change something that would
JV> require a rebuild, not necessarily ever
On Thu, Oct 29, 2009 at 11:33 AM, Dmitry E. Oboukhov wrote:
> Could we add 'ReBuild-Depends' statement into debian/control to
> rebuild like packages when depends rebuild? But such kind of depends
> require some changes in buildd system.
This is only needed when the dependencies change something
I have a package which contains a code like following:
#include
FILE *file_handle;
int foo(int something, const char *fmt, ...)
{
// some statements
va_list ap;
int res = vfprintf(file_handle, fmt, ap);
va_end(ap);
return res;
}
This code works fine by libc wouldn'
I need to build-depend on a version of libc. Since they have different
names in different architectures, I used linux-any kfreebsd-any and
hurd-any to avoid spelling the entire list. However, lintian warned me
about that. Is it safe to use that (so a bug against lintian is
warranted)? Or should I l
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> Are there any serious objections against just overriding and ignoring
> the Linitan warning about not having "make -f" in the shebang line?
As long as you don't have an objection against having serious bugs filed
and your packages not be part
On Thu, 2009-10-29 at 21:35 +0900, Charles Plessy wrote:
> (The source packages needed the format 3.0 (quilt),
> for which good news are expected soon.)
Already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-requ.
Le Thu, Oct 29, 2009 at 08:02:46AM +0100, Michael Tautschnig a écrit :
>
> Debian Policy 4.9 guarantees that the behavior of debian/rules will be the
> same
> if called as either make -f debian/rules or simply debian/rules.
Is there any piece of our infrastructure that needs this feature ? If no
Processing commands for cont...@bugs.debian.org:
> reassign 552694 linux-2.6
Bug #552694 [general] Laser servo diskette drives have stopped working in
Debian Lenny
Bug reassigned from package 'general' to 'linux-2.6'.
> # /me is a bit wondering why you reassigned this to general instead to
> # th
Processing commands for cont...@bugs.debian.org:
> reassign 552694 general
Bug #552694 [kernel] Laser servo diskette drives have stopped working in Debian
Lenny
Warning: Unknown package 'kernel'
Bug reassigned from package 'kernel' to 'general'.
> --
Stopping processing here.
Please contact me i
Michael Tautschnig schrieb:
In an earlier post you mentioned a pbuilder build process: If that is what you
are using, why not go for pbuilder hooks?
This would surely be possible, but then the users compiling their own
packages will complain :-)
@all:
Thanks for your technical suggestions! T
Mathieu Malaterre wrote:
> I tried reproducing it here on my amd64 box using gcj-4.4 (testing)
> and gcc-snapshot but I cannot reproduce it here. I am guessing this is
> a hppa only issue. How should I handle that ?
The hppa architecture is not 100% stable ATM. People are working hard to
improve
Tobi writes:
> Fabian Greffrath wrote:
>
>> Why not so it the other way round, i.e. start two different scripts (or
>> the same script with different parameters) from a debian/rules Makefile
>> depending on the environment variable?
>
> Might be possible, but it would require major changes to deb
> Michael Tautschnig wrote:
>
> > Adhering to a standard actually decreases complexity. What may seem
> > "elegant" at
> > first makes it a lot harder for other people to step in. For example, the
> > VDR-solution IMHO doesn't decrease complexity, it merely hides it.
>
> Yes, it indeed hides som
On Tue, Oct 20, 2009 at 07:17:53AM +0200, Frank Lin PIAT wrote:
> I have written a small script to make it easy to submit manpage
> improvements (it's attached).
Hi Franklin,
in the end, have you decided where/how to ship this script? I'd
personally would like to see it in devscripts ... and I w
Francesco P. Lovergine (29/10/2009):
> I noted that kfreebsd-* are missing python binding generation for
> libkml. I already forced PYTHON choice at building time (which
> worked on other archs) but in this case it does not help. Any hints?
When it comes to missing .so, it might be outdated libt
Michael Tautschnig wrote:
> Adhering to a standard actually decreases complexity. What may seem "elegant"
> at
> first makes it a lot harder for other people to step in. For example, the
> VDR-solution IMHO doesn't decrease complexity, it merely hides it.
Yes, it indeed hides some complexity. Bu
https://buildd.debian.org/fetch.cgi?pkg=libkml;ver=1.0.1-3;arch=kfreebsd-amd64;stamp=1256787538
I noted that kfreebsd-* are missing python binding generation for libkml.
I already forced PYTHON choice at building time (which worked on other archs)
but
in this case it does not help. Any hints?
-
Hi there,
I am starring at:
https://buildd.debian.org/~luk/status/package.php?p=gdcm
->
https://buildd.debian.org/fetch.cgi?pkg=gdcm&arch=hppa&ver=2.0.13-1&stamp=1256783874&file=log&as=raw
Linking CXX shared library ../../bin/libvtkgdcmJava.so
make[3]: Leaving directory
`/build/buildd-gdcm_2.
Dmitry E. Oboukhov wrote:
> A few days ago i uploaded a package. but
> http://ftp-master.debian.org/new.html hasn't contained any information
> about it. Last package has a date 26 Oct. Is any script hangs up?
See http://blog.ganneff.de/blog/2009/10/27/debian-ftpmaster-meeting.html
Cheers,
FJP
>> A few days ago i uploaded a package. but
>> http://ftp-master.debian.org/new.html hasn't contained any information
>> about it. Last package has a date 26 Oct. Is any script hangs up?
JHR>
http://lists.debian.org/debian-infrastructure-announce/2009/10/msg3.html
JHR> And why didn't you ask
On 28/10/09 at 19:05 -0500, Manoj Srivastava wrote:
> Actually, there is. My states makefile can no longer
> include debian/rules, because, you see, it is not a makefile. There are
> other ways that it does not look like a makefile, walk like a makefile,
> or quack like one.
The debian/ru
Package: wnpp
Severity: wishlist
Owner: Enrico Zini
* Package name: cfget
Version : 0.7
Upstream Author : Enrico
* URL : http://www.enricozini.org/sw/cfget/
* License : GPL
Programming Lang: Python
Description : featureful tool to read values from conf
Am Mittwoch, den 28.10.2009, 19:05 -0500 schrieb Manoj Srivastava:
> > The solution we have right now is in some way "elegant", because you have
> > only to deal with a standard debian/rules and besides the different
> > shebang line there's nothing else to care about.
>
> Actually, there
On Thu, Oct 29, 2009 at 09:35:31AM +0300, Dmitry E. Oboukhov wrote:
> A few days ago i uploaded a package. but
> http://ftp-master.debian.org/new.html hasn't contained any information
> about it. Last package has a date 26 Oct. Is any script hangs up?
http://lists.debian.org/debian-infrastructure-
> Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
> >
> > Debian Policy 4.9 says about debian/rules:
> >
> > "It must start with the line #!/usr/bin/make -f, so that it can be
> > invoked by saying its name rather than invoking make explicitly."
>
> Dear all,
>
> I also do not understa
54 matches
Mail list logo
