Re: Build-Depend'ing on libasound2-dev just for Linux
Le vendredi 16 septembre 2005 à 00:33 +0200, Aurelien Jarno a écrit : > > Of course, using type-handling for generating a control file in the > > clean target is a crazy idea. The sane way to use it is: > > Build-Depends: libasound2-dev | not+linux Sorry, I meant not+linux-gnu. > It is maybe a crazy idea, but it is the only one that work. What you > suggest simply doesn't work, as not+linux is a provided package, and the > autobuilders are not able to see it. In short a package with such a > build-dependency will FTBFS on non linux architectures, if built by an > autobuilder. In this case, it is enough to do something like: Build-Depends: type-handling, libasound2-dev | not+linux-gnu -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Mail Delivery (failure [EMAIL PROTECTED])
Centro Domus informa dell'avvenuta ricezione della mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]
On Sep 16, Stephen R Marenka <[EMAIL PROTECTED]> wrote: > For the record, -O2 seems to work fine. The segfaults only seem to > apply to -O3 and better (at least in my experience). I wish. See #323016. -- ciao, Marco signature.asc Description: Digital signature
Re: Reviving the Debian FAQ
On Thu, Sep 15, 2005 at 07:22:44PM -0400, Kamaraju Kusumanchi wrote: > How can I do that? Are there some instructions that I need to follow or > just say in the document that others are free to copy the contents? I am > sorry but I am very new to licensing and stuff like that. Just add a license blurb to the document (header or footer, your choice). You can reuse the blurb in the index of the FAQ or the Securing Debian Manual: http://www.debian.org/doc/manuals/debian-faq/index.en.html http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html Which is basicly the GPL but applying it to documentation, for more information see: http://www.fsf.org/licensing/licenses/gpl.html and http://www.fsf.org/licensing/licenses/index_html Regards Javier signature.asc Description: Digital signature
hoi gia ve may bay
hien tai toi dang o Nhat Ban. visa cua toi duoc gia han den nam 2007. toi vua qua Nhat ngay 19.7.2005. xin vui long cho toi biet gia ve may bay, ve khu hoi, di tu Nhat ve thanh pho HCM hien thoi. cam on ban nhieu. mong hoi am nhanh.__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
hoi gia ve may bay
toi dang o Nhat, cuoi thang nay ve Vietnam, toi muon biet gia ve may bay khu hoi tu Nhat ve thanh pho Ho chi minh hien tai la bao nhieu? va neu co the thi xin vui long cung cap cho toi gia ve cua tat ca cac hang may bay, dac biet la Thai Airline. cam on nhieu. monh hoi am som. Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort.
Debian 3.1 - avr-gnu tools compilation errors
Hi, I work under Debian 3.1. I've got compilation errors: 1. simulavr-0.1.2.2: /usr/local/avr/simulavr-0.1.2.2/src/disp/disp.c - error 'KEY-ENTER' undeclared etc. (multiple errors) 2. gdb-avr-6.3: /usr/local/avr/gdb-avr-6.3/gdb-6.3 - configure error: no termcap library found 3. insight-6.1: -- multiple errors in: /usr/local/AVR/source/insight-6.1/tk/generic/tk3d.c (e.g. request for 'borderTable' in something not a structure) Could anyone help? Thanks in advance. -- Best regards Oleg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is gcc-3.4 in the unstable chroot on crest.debian.org OK?
> On Wed, Sep 14, 2005 at 02:20:30PM -0700, Rob Browning wrote: > > If I compile a trivial foo.c in the unstable chroot with gcc-3.4, and > > then immediately try to run it, it segfaults. > > You've hit #327780. > > m68k-build: could anyone with root on crest please downgrade binutils in > all chroots to a working version? Thx. I've downgraded the user unstable chroot; testing and buildd unstable were fine. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]
On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote: > Stephen R Marenka wrote: > This seems to affect one of the packages I sponsor as well: > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557 > > If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it > make more sense to upload a patched gcc-4.0 for m68k that silently > changes the optimization level back to 2 untile the problem with the > compiler can be fixed rather than upload and recompile a large number of > packages for every architecture? Given that gcc-4.0 -O3 also generate wrong code on i386, there is no need for a m68k specific hack. Every package that use -O3 will have to be rebuild on all plateform anyway when gcc has stabilized. On m68k, gcc is just nice enough to do an ICE instead of random code generation. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]
On Fri, Sep 16, 2005 at 07:09:29AM -0500, Bill Allombert wrote: > On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote: > > Stephen R Marenka wrote: > > This seems to affect one of the packages I sponsor as well: > > > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557 > > > > If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it > > make more sense to upload a patched gcc-4.0 for m68k that silently > > changes the optimization level back to 2 untile the problem with the > > compiler can be fixed rather than upload and recompile a large number of > > packages for every architecture? > > Given that gcc-4.0 -O3 also generate wrong code on i386, there is no > need for a m68k specific hack. Every package that use -O3 will have to > be rebuild on all plateform anyway when gcc has stabilized. On m68k, gcc > is just nice enough to do an ICE instead of random code generation. *g* That makes me feel a whole lot better :-) (anyway, binary search is running now; with a bit of luck, I should have the result and a fix "soon") -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Patch² : Maintaining a patch for a debian package
Hello, I have a couple Debian packages that I need to patch with custom local changes. The patches are small and I hence can follow the security updates from the security team. However, I wonder if there's already a way to automatically manage such kind of packages. Ideally, when running aptitude (or a wrapper), and if my patched package 'A' is updated, then the updated sources of 'A' would be downloaded, my custom patch applied, and then 'A' would be automatically rebuild and installed. Of course, if there's a conflict, the process would stop with an error. Is this kind of auto-patching already implemented? Maybe apt-fu could be used for that task, but it's apparently discontinued. Any suggestions or best practices? :) TIA, -- Sylvain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Patch² : Maintaining a patch for a debian package
On Fri, Sep 16, 2005 at 04:12:44PM +0200, Sylvain Beucler wrote: > I have a couple Debian packages that I need to patch with custom local > changes. The patches are small and I hence can follow the security > updates from the security team. [...] > > Is this kind of auto-patching already implemented? Maybe apt-fu could > be used for that task, but it's apparently discontinued. > apt-src ? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
possible problem with dlopen() and/or gcc 4
Hi *, sorry for bothering you all on this problem that is only slightly debian-related (involves two of my packages) but I really need some help here. I am the current maintainer for ogre (libogre5 & other packages) and the upstream for the PyOgre bindings (that I am also packaging). After the big switch to gcc 4 PyOgre programs started to segfault and I had to link ogre plugins into the PyOgre Python module (_ogre.so) _explicitly_ to make the segfault disappear. Let me explain a little better: ogre provides various rendering backend and on Debian we use the OpenGL one, located in shared object in /usr/lib/OGRE/RenderSystem_GL.so The render system is loaded at runtime (dlopen()) by the main ogre library (libOgreMain.so.5) and for normal C++ program all goes well. The Python module is usually linked with libOgreMain.so.5 only (as the C programs are) to produce a shared object that is dlopen()ed by Python (_ogre.so). Now, the extact segfault location depends on the Python script and on the exact versions of the ogre libraries (and compile options and so on) but it always happens inside the render system shared module (i.e., inside RenderSystem_GL.so). If _ogre.so is explicitly liked against RenderSystem_GL.so the segfault disappears. I double checked all the involved libraries and it seems that they are all linked with libstdc++.so.6 so it does not seem to be a library conflict (gcc 3.3 vs gcc 4.0). My wildest guess is that a dlopen() from a dlopen()ed shared object can do something bad but I can't find any reference to similar problems. Ideas? federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] I came like Water, and like Wind I go. -- Omar Khayam signature.asc Description: This is a digitally signed message part
Debian packages of MaxDB 7.6 in experimental - Call for testers
Hi, Debian packages of the 7.6.00 release series of the MaxDB database system are now available in the experimental distribution. Next to the source package, there are binary packages for i386 and ia64 available. While you can have both the maxdb-server-7.5.00 and maxdb-server-7.6.00 package installed alongside each other, the packages from the 7.6.00 release series will replace most of the packages that are now provided by packages built from the maxdb-7.5.00 source package. Therefore it is important to have the new 7.6.00 packages well tested before making them available in unstable to avoid unpleasant surprises. My intention is to keep the new maxdb-7.6.00 packages in experimental for at least a month (for the most part of that time I will be on vacation and unavailable anyway) and if necessary do another upload to experimental after that time. If no major problems have been discovered until then I will prepare a new upload that will then go directly to unstable. Please take the time and have a go with the packages on a test machine, especially if you are already using packages from the 7.5.00 release series. Of course, I am most interested in any problems you encounter when having the 7.5.00 packages already installed. Thanks for your help and good luck with the packages, Martin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How can I build a package from source that require the source of another (library) package?
Hello fellow developers, I have a problem on which I need advice. Pathan is a library that implements XPath functionality in c++. It is available both as a separate tarball as well as bundled with the Berkeley DB XML sources provided by Sleepycat Software. The pathan build script require a path to the xerces source code tree. I have tried to find a way to build the pathan library without providing the xerces source but failed. Is there anything I can do to work around this source dependency? I can always give up the idea of an independent build of the pathan library and ship it as part of dbxml where the source include both pathan and xerces (and berkeley db, and xquery; in the same source, sic; talk about bloat). Any advice is welcome. -- Tomas Fasth <[EMAIL PROTECTED]> GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504 signature.asc Description: OpenPGP digital signature
Re: How can I build a package from source that require the source of another (library) package?
On Fri, Sep 16, 2005 at 09:34:30PM +0200, Tomas Fasth wrote:
[...]
> Pathan is a library that implements XPath functionality in c++. It
> is available both as a separate tarball as well as bundled with the
> Berkeley DB XML sources provided by Sleepycat Software. The pathan
> build script require a path to the xerces source code tree. I have
> tried to find a way to build the pathan library without providing
> the xerces source but failed.
[...]
Can you intead build-depend on libxerces26-dev and give it the path
to the headers that package installs?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
