> 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
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-
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
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
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
>> 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
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
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.
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?
-
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
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
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
> 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
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
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
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
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
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
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
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.
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
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
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'
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
>> 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
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
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
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
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.
>
"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);
>
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
>> 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
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
> 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 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
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 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
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 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
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
* 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
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
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
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, 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
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, 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
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
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
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
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
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, 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-
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
54 matches
Mail list logo
