On Tue, 2003-08-26 at 01:01, Adam Heath wrote:
> Is there a debian machine I can access that has this problem?
Yes. You can use vore, unstable chroot.
p.
On Thu, 2003-08-21 at 09:52, GOTO Masanori wrote:
> My concern is (1) hppa build. If we can't get hppa glibc, we may need
> to drop it finally...
I don't think the hppa glibc is as inscrutable as all that. The main
problem seems to be that Carlos is the only person working on the bug,
and he is
On Wed, 2002-04-17 at 10:44, Simon Richter wrote:
> Well, my project goes much further, it is basically a "generic"
> autobuilder with a plugin for .dsc/.deb (just like APT is a generic
> package library with plugins for Debian).
What became of turtle -- do the Hurd people still use that?
p.
--
On Mon, 2002-04-15 at 22:43, Tomas Pospisek's Mailing Lists wrote:
> My knowledge of gcc-2.95 vs gcc-3.0 intricacies and C++ specialities is
> far too small to figure out what's going on here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140032
>
> and I estimate that I won't have
On Mon, 2002-04-08 at 12:53, Tom Cato Amundsen wrote:
> Just of curiosity, is the queue for the autobuilders available anywhere,
> either on the web or by logging into the machines?
Yes (kind of) - see http://auric.debian.org/~pb/shame/arm.html and
http://buildd.debian.org/stats/arm-all.txt
p.
On Mon, 2002-04-08 at 10:00, Tom Cato Amundsen wrote:
> Sorry, but the following packages have unmet dependencies:
> python-gnome: Depends: python-gdk-imlib (>= 0.6.8-17) but it is not
> going to be installed
> E: Sorry, broken packages
>
> Other archs are ok.
>
> python-gdk-imlib 0.6.8-17 for
On Sun, 2002-04-07 at 09:08, Stefano Zacchiroli wrote:
> BTW, on arm the package has been successfull rebuilt on April 2 and
> April 6, but the package is still reported as out of date on arm in
> update_excuses.html, anybody knows the reason?
Dunno, just some or other random delay. It's showing
On Thu, 2002-04-04 at 05:59, Branden Robinson wrote:
> If the kernel revs in such a way as to break
> ioctl numbers, there's no userland way around it, is there?
No. On the other hand, this virtually never happens. The kernel people
are usually quite disciplined about not making changes that wou
In message <[EMAIL PROTECTED]>, Wichert Akkerman writes:
>Bogus, if you compile them with the same options then will the the
>same. If you compile one with LFS and one without you can expect
>problems as you have demonstrated.
Well, yeah, but it seems dubious at best for Apache to be defining
_FI
In message <[EMAIL PROTECTED]>, Eric Van Buggenhaut writes:
>1) There's no auto-build of crafty because it's non-free.
>
>2) I was thinking about building it myself but there's no machine
>available (debussy.d.o is down - rameau.d.o runs potato)
Mmm. I suppose we should think about making rameau'
In message <[EMAIL PROTECTED]>, Ben Collins writes:
>On Sat, Dec 22, 2001 at 06:54:10PM +0000, Philip Blundell wrote:
>> G++ 2.95 is pretty broken in its own right. Just because it won't compile
>> something doesn't necessarily mean that the source is at faul
In message <[EMAIL PROTECTED]>, Mikael Hedin writes:
>Sorry, but the following packages have unmet dependencies:
> gcc-3.0: Depends: cpp-3.0 (>= 1:3.0.2-4) but it is not going to be installed
> Depends: cpp-3.0 (< 1:3.0.3) but it is not going to be installed
>E: Sorry, broken packages
>
In message <[EMAIL PROTECTED]>, Ben Collins writes:
>Don't discount sparc just because the code is broken. That's a bug in
>itself. Fix the code, get it to compile. SPARC is one of the most tested
>archs we have, so if it is broken there, you have some serious issues
>anyway, and covering it by not
>> en_UK is English as spoken in the United Kingdom.
>
>While en_GB is english as spoken in Great Britain. Perhpas one of the
>residents thereof can explain the difference.
Well, no. `GB' seems to be the ISO country code for the United Kingdom,
perverse as that might appear.
p.
pgptzf0wFL9
>Anyway: The problem is that a couple of the packages generated from
>isdnutils source are applicable for all architectures, and most are only
>usable where certain (ISDN) hardware is supported by the linux kernel.
>isdnlog-data falls under the second category, BUT it's data that's
>architecture-in
>Now, how are we going to support: If there's a version of libc6 that's
>known to use kernel headers incompatible with a particular
>kernel-headers-*, then a package compiled against those kernel headers
>should conflict with that libc6.
Eh? Why would this be useful?
p.
>Having version numbers in the kernel-headers package name is a consequence
>of having them in the kernel-image package name. The point of having them
>in the kernel-image package name should be pretty obvious...
Actually, I'm not even completely convinced that having them in the
kernel-image pa
>In short, how do you do them?
What do you want to do with them?
There are a whole load of wacky special source dependencies (*LINUX24-HEADERS
and so on) which seem to be trying to solve variants of this problem. But
this mechanism doesn't seem to be all that robust either.
I think the whole
>+ libch uploaded 288 days ago, out of date by 278 days!
> m68k package depends on libmysqlclient9, needs to be rebuilt against
> libmysqlclient10, presumably
It needs the build dependencies updating too, see #93850 (which has been closed
but I think is still applicable).
p.
>I'm packaging acl2, which can take several hours to compile on a PPro
>200. Would it be reasonable to exclude certain architectures as too
>slow? (acl2 is a theorem prover.)
No. The porters can make up their own minds about whether it's worth
compiling for their architecture. We already have p
In message <[EMAIL PROTECTED]>, Jon Eisenstein wr
ites:
>I recently filed a bug report (80092) against the nmh package regarding
>the location of its program files. It installs files into /usr/bin/mh,
>which isn't in the path, making running the program difficult until the
>reason is found.
The nm
Pierfrancesco Caci <[EMAIL PROTECTED]> wrote:
>connect(4, {sin_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6, "f
>e80::250:4ff:fe38:a630", &sin6_addr), sin6_flowinfo=htonl(0)}}, 24) = -1 EINVA
>L (Invalid argument)
What version of the kernel are you running? Your ping6 is using old-
Branden Robinson wrote:
>gcc won't build on arm, so XFree86 won't build on arm, so XFree86 can't go
>into testing, so LOTS of things can't go into testing.
The latest "2.95.3" gcc ought to be OK on ARM. I think it should be in woody
soon if it isn't already.
p.
Are there any maintainers in Cambridge who would be willing to sign my GPG key?
Thanks
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
24 matches
Mail list logo
