Hello All,
while preparing an upload of gcc-2.95 which fixes its worst problems
I wondered how many users of it are actually left. 9 packages in
unstable still declare a build dependency on gcc-2.95 or g++-2.95,
this makes it IMHO a plausible release goal to get rid of 2.95
maintenance for etch.
Dave Carrigan wrote:
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
this makes it IMHO a plausible release goal to get rid of 2.95
maintenance for etch.
No it is not. Just because debian packages don't use 2.95 doesn't mean
that end users have the same luxury.
The need
Steve M. Robbins wrote:
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
Malloc debugging, #285685 suggests it is broken for 300 days now,
either update or remove:
Steve M. Robbins [EMAIL PROTECTED]
ccmalloc Build-Depends: g++-2.95 [alpha arm i386
Ben Pfaff wrote:
Thiemo Seufer [EMAIL PROTECTED] writes:
Unacknowledged NMU for one year, either update or remove:
Ben Pfaff [EMAIL PROTECTED]
gcccheckerBuild-Depends: gcc-2.95
I recently filed a request to have this package removed. It is
not maintained upstream
Mark Brown wrote:
On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote:
The need for gcc-2.95 usually means the source code is broken (in C99
terms) and should be fixed. Do you have an example of an use case where
this is unfeasible, and which is important enough to justify
Nikita V. Youshchenko wrote:
Dave Carrigan wrote:
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
this makes it IMHO a plausible release goal to get rid of 2.95
maintenance for etch.
No it is not. Just because debian packages don't use 2.95 doesn't mean
Thiemo Seufer wrote:
Nikita V. Youshchenko wrote:
[snip]
Also, people have some code (old completed internal projects, etc), which
probably would never be ported to newer C++ standards (it's plainly too big
job), but which are still useful to keep working - e.g. for
demonstration
Moritz Muehlenhoff wrote:
In linux.debian.devel, you wrote:
The need for gcc-2.95 usually means the source code is broken (in C99
terms) and should be fixed. Do you have an example of an use case where
this is unfeasible, and which is important enough to justify continued
maintenance of
Nikita V. Youshchenko wrote:
The need for gcc-2.95 usually means the source code is broken (in C99
terms) and should be fixed. Do you have an example of an use case where
this is unfeasible, and which is important enough to justify continued
maintenance of gcc 2.95?
Device driver
Stephen Gran wrote:
This one time, at band camp, Rafael Laboissiere said:
I am moving this discussion to debian-devel, since I am not sure we
are really violating the Policy. Feel free to move it further to
debian-policy, if you think it is appropriate.
FWIW, Rafael, at first blush I
Marc Haber wrote:
[snip]
How is it possible for you to claim something is more secure
when you don't understand it well enough to say how it's different?
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Rafael Laboissiere wrote:
[Please, Cc: to me, I am not currently subscribed to debian-devel.]
* Thiemo Seufer [EMAIL PROTECTED] [2005-11-24 02:13]:
Stephen Gran wrote:
FWIW, Rafael, at first blush I have to say I agree with you. A
maintainer address in Debian is just a way to get
Stephen Gran wrote:
[snip]
The maintainer name and email address used in the changelog should
be the details of the person uploading this version. They are not
necessarily those of the usual package maintainer.
[snip]
I think that are two distinct concepts here. The
Stephen Gran wrote:
[snip]
And we are in danger of allowing policy to drive practice, rather than
vice versa.
The problem is, there are many packages currently being group
maintained. These groups generally have some sort of group contact
email address:
grep-dctrl -n -s Maintainer ''
Stephen Gran wrote:
This one time, at band camp, Thiemo Seufer said:
Btw, about this simple-minded test:
299 of those are maintained by the Debian Install System Team, and
nobody there felt compelled to put [EMAIL PROTECTED] in the changelog
for whatever reason.
What is the difference
Stephen Gran wrote:
This one time, at band camp, Thiemo Seufer said:
Stephen Gran wrote:
This one time, at band camp, Thiemo Seufer said:
Btw, about this simple-minded test:
299 of those are maintained by the Debian Install System Team, and
nobody there felt compelled to put
Isaac Clerencia wrote:
On Thursday, 24 November 2005 22:03, Stephen Gran wrote:
But the .dsc is. This stuff is easily traceable, if we want to. I can
see the benefit of having the same name in the Maintainer field and in the
changelog for some. I can see arguments against it, but none
Isaac Clerencia wrote:
On Thursday, 24 November 2005 22:36, Thiemo Seufer wrote:
I can see arguments against it, but none that make
it an RC bug.
Policy violations are RC by definition.
According to policy should's are not RC.
Policy 5.6.4 has no should.
Thiemo
--
To UNSUBSCRIBE
Brian May wrote:
Thiemo == Thiemo Seufer [EMAIL PROTECTED] writes:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Thiemo Sorry, but that's a snake oil rationale.
A: Why do you lock
Norbert Preining wrote:
Hi all!
On Mon, 28 Nov 2005, Miles Bader wrote:
nicely as texlive-lang-tibetan and texlive-fonts-recommended.
On Mon, 28 Nov 2005, Rogério Brito wrote:
texlive-binaries-source 96M
texlive-basicbin
What about texlive-bin-base?
As I said, it
Andrew Vaughan wrote:
On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote:
FWIW, Debian package names prefer e.g. foo-en-uk-doc over
foo-documentation-ukenglish. This allows to filter documentation
packages by name (doc-* or *-doc), and following the standardized
ISO abbreviations also seems
Norbert Preining wrote:
[snip]
For the language stuff: Here is a problem as some languages packages are
not *one* single language, but several (arabic, cjk, other). So would it
be the best solution to have
old:texlive-langX
new:texlive--lang
?
Arabic is ar, IIRC.
-english texlive-en-doc
Best wishes
Norbert
In [1], Thiemo Seufer asserts that FWIW, Debian package names prefer
e.g. foo-en-uk-doc over foo-documentation-ukenglish. I completely
disagree.
The point was about documentation and ukenglish.
There is already precedent for using
Thomas Viehmann wrote:
Hi,
Vincent Sanders wrote:
[1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm
taking a random (end of alphabet) sample from maybe-failed:
twinkle: requeue (probably libccrtp was stuck in NEW)
wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new
Steve Langasek wrote:
[snip]
So those should get added to P-a-s instead.
Well, but that'd be something for the buildd-admin to collect.
(Or maintainers of the packages, but that doesn't seem to fashionable
nowadays...)
Um... no. This is *porter* work; one does not have to be a buildd
Thomas Viehmann wrote:
Hi Steve,
Steve Langasek wrote:
Ok. Here's some feedback on some that I either disagree with, or don't see
enough rationale for. (This is why, ideally, the process should involve the
porters and the maintainers...)
Thanks. Doesn't hurt do get educated...
Steve Langasek wrote:
[snip]
-grub2: !hppa !ia64 m68k #
bootloader
+grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc #
bootloader for i386/powerpc [?]
Is a P-a-s entry some sort of a final verdict? I don't think it makes
Heiko Müller wrote:
Dear Thiemo,
we very much appreciate your work on the gcc-2.95 debian package.
For us - and probably also for other users in the scientific
community - the old compiler version is still of great value.
We use gcc-2.95 to compile C/C++ code with very large mathematical
Jeroen van Wolffelaar wrote:
[snip]
A similar issue I noted in the past is the big number of build failures
that don't get tagged 'Failed'. I tried working on classifying them, but
got bored so increadibly fast that I gave up, and decided for myself
this should be something the porters should
On Wed, Feb 22, 2006 at 08:47:31PM -0800, Steve Langasek wrote:
On Thu, Feb 23, 2006 at 12:22:27AM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 22 Feb 2006, Chris Stromsoe wrote:
for the entire lifetime of the current stable release. Will -17.1 be
making its way into stable any
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote:
[snip]
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Actually, I disagree. To me it makes perfect sense the way it
currently is, namely:
kernel-arch-libc
kernel and libc can be empty when
On Sun, Mar 26, 2006 at 03:09:11PM -0500, Steve M. Robbins wrote:
Hi,
I have another wishful thinking idea for build machines to float.
Suppose I get a bug report saying my package has failed to build on
architecture glooble. I don't personally have a globle machine. To
debug the
Ladislav Bodnar wrote:
On Tuesday 26 October 2004 22:15, Norbert Tretkowski wrote:
Just curious: any particular reason why the kernel version is
reported as 100 on
http://packages.debian.org/unstable/allpackages?
kernel-image-2.6-386 (100)
Linux kernel image for version 2.6
Darren Salt wrote:
I demand that Ron Johnson may or may not have written...
[snip]
But really, does the kernel use MMX?
Here, at least: linux/arch/i386/lib/memcpy.c
Which will only be used for CyrixIII and K7, and boils down to:
config MCYRIXIII
bool CyrixIII/VIA-C3
help
Goswin von Brederlow wrote:
[snip]
With cumulative patches you run into the problem that you need a new
cummulative patch for every day that contains most of what the
previous one did. That realy quickly becomes a space issue.
Errm, no, it doesn't need _one_ new cumulative patch. All the
William Ballard wrote:
On Thu, Dec 02, 2004 at 01:25:36AM +, Andrew M.A. Cater wrote:
The Christian Bible ought to be OK by most Islamic scholars - it's the
Crusader history that has caused most of the problems - but you
After 9/11 I saw a fellow named Tariq Ramadan on C-Span, and one
Goswin von Brederlow wrote:
[snip]
very hard (figure out how to make a minimal diff
from the daylies) or you need every days Packages file (apt-dupdate
does that).
It is not very hard to re-diff a few files to incorporate the changes
between old and new Packages file.
Then how do
Florian Weimer wrote:
* Andreas Barth:
Is this really a good idea? patch invokes ed(1) to process ed
scripts, and this might lead to execution of arbitrary commands.
It is agreed that the usage of patch and ed is _not_ the recommended
way for production code (but acceptable for
Frederik Dannemare wrote:
[snip]
I surely hope they would still do so. Another option could simply be to
proceed with the current way of uploading - but then let the buildd
rebuild the uploaded binary. Or is that somehow not feasible?
Actually, requiring a binary upload _plus_ rebuilding it
Frederik Dannemare wrote:
[snip]
Always build packages for uploads in a clean environment (a fresh
chroot if nothing else is available).
I absolutely agree. But it still doesn't have to be 100% problem-free
(letting buildd build all packages on all archs for distribution would
still be
Steinar H. Gunderson wrote:
On Sun, Feb 06, 2005 at 08:52:28AM -0500, Joey Hess wrote:
My feeling for some time has been that we should introduce a separate
section in the archive, or a separate archive and come up with the
infrastructure to upload -dbg packages to there, with separated
Thomas Bushnell BSG wrote:
Steve Langasek [EMAIL PROTECTED] writes:
Clearly not, or it wouldn't have failed to build on mips and mipsel. There
is nothing perfectly working about that version of libtool, and moreover,
its effects are not limited to the mips architectures -- as the
Wouter Verhelst wrote:
On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
Also, really huge stuff, like KDE, cannot be uploaded as frequently as
perhaps the maintainers would like because it kills the slower buildd's
for a few days.
Hypothetical daily KDE builds would also
Petter Reinholdtsen wrote:
[Thiemo Seufer]
Those would need to go into experimental, where no buildd problem
exists by definition.
I'm told there are some autobuilders for experimental,
And how would missing builds there be a problem?
and believe your definition of experimental need
Petter Reinholdtsen wrote:
[snip]
But at the moment, there are very few problems with the autobuilders,
it seem. The packages with missing builds on some archs are listedon
URL:http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz,
and it is not bad compared to earlier.
Brian Nelson wrote:
On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
But a total of eleven is insane.
It is sometimes hard to get them all to work, yes.
It also vastly increases the quality of the
Paul Hampson wrote:
On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote:
On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote:
Running such a system in parallel with the current systems (and comparing
the outputs) might be a good test for gcc-as-cross-compiler,
Petri Latvala wrote:
[snip]
Also, the first 16 bytes will differ in an ELF format .o, see
http://lists.debian.org/debian-devel/2004/09/msg00201.html
That's incorrect, strictly speaking. The first (magic) bytes have
to be identical, only the padding bytes could be different (but are
usually
Joel Aelwyn wrote:
[snip]
But that's OK. Our amd64 users just use the Alioth site instead of our
wonderful mirror network, and track it as unstable. I mean, it's so much
more effective to have it all hitting alioth for download, right? Thought
so.
You probably should inform yourself before
Kalle Kivimaa wrote:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Source code is source code. Obfuscated or not does not change that. It
fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you
would have to show that it is not source and the gcc already prooves
you wrong
Steve Halasz wrote:
Hi,
I've sent a few emails over the last month to [EMAIL PROTECTED] and
[EMAIL PROTECTED] requesting that grass be removed from
packages-arch-specific. But my pleas have fallen on deaf ears, or
perhaps overzealous spam filters. Are you guys out there? Is there
anyone
Jeroen van Wolffelaar wrote:
[snip]
I had try to randomly submit wishlist bugs for 6 packages to bts with
the tag patch pointing to the dehs site or attaching the watch file to
the bug.
Almost all of this bug was closed and the watch file was check (in some
cases fixed) and inserted
Christoph Berg wrote:
Re: Thiemo Seufer in [EMAIL PROTECTED]
Do *not* file 6229 bugs about the same subject. Never.
Why not? As wishlist bugs with patch this seems sensible to me.
I assume that you will hand-check the patches in those 6229 bug
reports that the watch files actually do
Lars Wirzenius wrote:
su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti:
Jeroen van Wolffelaar wrote:
Do *not* file 6229 bugs about the same subject. Never.
Why not? As wishlist bugs with patch this seems sensible to me.
Denial of service attacks on the bug tracking system
Lars Wirzenius wrote:
su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti:
Since preparation of the accompanying patches would take some time,
it is unlikely to cause denial of service or disruption.
If they are sent at a slow pace, then the disruption is less, it is
true
Pjotr Kourzanov wrote:
Dear Debian developers,
I gather there are some people out there with MIPS little-endian
machines (from mipsel drop discussion) and Debian on it. Do huge shared
libraries (containing 4 symbols) work for you? I am currently
investigating an issue I have with
Wouter Verhelst wrote:
Op za, 05-03-2005 te 14:26 +0100, schreef Thiemo Seufer:
Steve Halasz wrote:
Hi,
I've sent a few emails over the last month to [EMAIL PROTECTED] and
[EMAIL PROTECTED] requesting that grass be removed from
packages-arch-specific. But my pleas have fallen
Kevin B. McCarty wrote:
Josselin Mouette wrote:
Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit :
I appreciate the clarification. What is desirable, then, is for the
developer
to be able to statically link his or her own libraries, and third
party libraries,
but to
Hamish Moffatt wrote:
On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
All the work and support over all those years by all those users and porters
will be vanished with that stupid idea, imho.
Ingo, obviously you are pissed off. But really, is there much benefit in
Martin Michlmayr wrote:
[snip]
- a _clear_ plan about this migration (and have this plan before
sarge is out), including a clear timeplan (announcement on day X,
maintainers have Y months to upload, if they don't do it in Y
months, we'll have a time of Z people who'll NMU the
Hamish Moffatt wrote:
On Mon, Mar 14, 2005 at 12:06:18PM +, Martin Michlmayr wrote:
* Hamish Moffatt [EMAIL PROTECTED] [2005-03-14 23:00]:
But really, is there much benefit in making *releases* for the SCC
architectures?
For some SSC arches, it *might* not make a difference
Thiemo Seufer wrote:
Hamish Moffatt wrote:
On Mon, Mar 14, 2005 at 12:06:18PM +, Martin Michlmayr wrote:
* Hamish Moffatt [EMAIL PROTECTED] [2005-03-14 23:00]:
But really, is there much benefit in making *releases* for the SCC
architectures?
For some SSC arches, it *might
Hamish Moffatt wrote:
On Mon, Mar 14, 2005 at 01:33:16PM +0100, Thiemo Seufer wrote:
Hamish Moffatt wrote:
On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
All the work and support over all those years by all those users and
porters
will be vanished
Steve Langasek wrote:
[snip]
This change has superseded the previous SCC (second-class citizen
architecture) plan that had already been proposed to reduce the amount of
data Debian mirrors are required to carry; prior to the release of sarge,
the ftpmasters plan to bring scc.debian.org on-line
John Goerzen wrote:
[snip]
- the release architecture must have N+1 buildds where N is the number
required to keep up with the volume of uploaded packages
- the value of N above must not be 2
It seems to me that if an arch can keep up with builds, why impose this
artificial
Tollef Fog Heen wrote:
* Thiemo Seufer
| For anyone who uses Debian as base of a commercial solution it is a
| requirement. Grabing some random unstable snapshot is a non-starter.
You do realise this is exactly what Ubuntu is doing? (Grab «random»
snapshot; stabilise)
The stabilise
Goswin von Brederlow wrote:
[snip]
A release for an scc arch could come weeks or month later than the
main archs and be done by the porters alone. The only requirement for
it would be that only stable sources can be used (with a few
exceptions maybe for arch specific sources). Stable sources
Goswin von Brederlow wrote:
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Hamish Moffatt
| OK, that makes sense. Can you buy those architectures new? (Surely yes
| in the case of s390 at least, probably mipsel also as the mips CPU
| manufacturers are alive and well.)
[EMAIL
André Luiz Rodrigues Ferreira wrote:
2006/4/13, Pierre Habouzit [EMAIL PROTECTED]:
Le Jeu 13 Avril 2006 15:20, Linas Žvirblis a écrit :
I think this would be better than a meta package because it would
be available in the regular install, and it would avoid some of the
issues with
Ognyan Kulev wrote:
Hamish Moffatt wrote:
HAM is not an acronym, so Ham Radio would be more appropriate.
Even better (IMHO) is the full term Amateur Radio, but some may
disagree. I've CC'd debian-hams for their input also.
Is there a problem with using Amateur (Ham) Radio?
It is
Manoj Srivastava wrote:
On 14 Apr 2006, Thiemo Seufer told this:
Ognyan Kulev wrote:
Hamish Moffatt wrote:
HAM is not an acronym, so Ham Radio would be more appropriate.
Even better (IMHO) is the full term Amateur Radio, but some may
disagree. I've CC'd debian-hams for their input
Linas Žvirblis wrote:
Joey Hess wrote:
By this lie of reasoning the only task that Debian can afford to ship is
either KDE or Gnome.
No, not at all. That is not what I was trying to say. KDE and GNOME were
examples of something that did not happen overnight. They proved worthy
of
Anthony DeRobertis wrote:
On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:
For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
trust gcc not to screw up.
If gcc
Marc Haber wrote:
On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto [EMAIL PROTECTED]
wrote:
Richard A Nelson [EMAIL PROTECTED] writes:
On Wed, 3 May 2006, Colin Watson wrote:
The rest of the system accounts are happily running with /bin/false
There is now /bin/nologin which is more secure
Gabor Gombas wrote:
On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
You can surely explain why /bin/nologin is more secure than
/bin/false. I'm eager to learn.
I am curious why any of both would be more secure than /dev/null, a
place which makes it hard to smuggle
Gabor Gombas wrote:
On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
Such a binary is completely broken, and it would fail in a similiar way
for any sort of file it has no execute permission for, not only for
$SHELL.
Sure, but that does not change the fact
Frank Küster wrote:
Michael Banck [EMAIL PROTECTED] wrote:
On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]:
* License : GPL v2 or later
That will make it pretty useless for non-GPL
Frank Küster wrote:
Simon Josefsson [EMAIL PROTECTED] wrote:
Frank Küster [EMAIL PROTECTED] writes:
Michael Banck [EMAIL PROTECTED] wrote:
On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]:
* License
[EMAIL PROTECTED] wrote:
I have created a new page in the wiki to track info and status
http://wiki.debian.org/multiarch
I looked at the upstream standards proposal:
http://lackof.org/taggart/hacking/multiarch/
It's good.
I am particularly pleased by the specification:
The terms
Peter 'p2' De Schrijver wrote:
Being able to install multiple versions is some use to multiarch, but
could also be used for other things, such if two packages provide the
same binary (git for example).
Or to install multiple 'version 'numbers' of the same package.
The big problem
Carlos Correia wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florian Weimer escreveu:
| * Jeroen van Wolffelaar:
|
|
|Official packages of Sun Java are now available from the non-free
|section of Debian unstable, thanks to Sun releasing[11 Java under a new
|license: the Operating
Francesco Poli wrote:
On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote:
[For -legal people, the license is attached.]
Thanks.
[...]
Also, section 4 poses a major issue. If, for any reason, the Linux
kernel doesn't do something that Java requires, then we are obligated
to
Nathanael Nerode wrote:
[snip]
The installer can use whatever seems most appropriate (does it even log?):
The installer does log and puts the logs at /var/log/debian-installer/ on
the successfully installed system. If the installation fails, the logs (in
the installer ramdisk) are a valuable
Manoj Srivastava wrote:
On 25 May 2006, Andreas Tille spake thusly:
On Thu, 25 May 2006, Manoj Srivastava wrote:
It has come to my attention that Martin Kraff used an
unofficial, and easily forge-able, identity device at a large key
Is there any reason to revoke my signature I have
Lionel Elie Mamane wrote:
On Sat, May 27, 2006 at 04:07:22PM +0200, Martijn van Oosterhout wrote:
The obvious example is the UK, which insists on checking your
passport if you come from the mainland.
Passport or ID Card, that is.
The www.britishembassy.gov.uk website suggests EEA
Falk Hueffner wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Falk Hueffner a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error:
Martin Kittel wrote:
[snip]
B) most people compile their own kernels and don't bother registering
those with dpkg, e.g. via kernel-package, and therefore their systems,
-while actually running a suitable kernel- do not provide the required
virtual package.
With A) I absolutely agree, but
Moritz Muehlenhoff wrote:
In linux.debian.devel, you wrote:
Today the EU gets to vote on the same issue. They can elect to have a
thriving software industry well placed to replace the now crippled USA
as the dominant force in the software industry.
Europe, its time to choose.
It has
Helmut Wollmersdorfer wrote:
[snip]
The releases of Debian could use '9.9.9-9' like it is used for packages.
This should give enough flexibility. And if the release manager likes to
jump to 7.3.0.21-5 for etch - why not?
Then 9.9.9 would be the upstream version. I hope Debian releases stay
Antti-Juhani Kaijanaho wrote:
On 20050729T16+0200, Olaf van der Spek wrote:
On 7/29/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Florian Weimer [EMAIL PROTECTED] writes:
Doesn't that still make N a real variable in memory and does not get
optimized away like enums?
I
Marco d'Itri wrote:
On Jul 29, Steve Langasek [EMAIL PROTECTED] wrote:
Well, please note that posh is not the only shell that lacks support for
local. IIRC, it also breaks down under one or more of dash and busybox sh.
dash supports local, or at least supports it in the way it's used in
Sebastian Kuzminsky wrote:
Yet another thread about cogito-vs-git, sorry folks. Just killfile me
if I've worn out your patience.
Still there? Great!
Background: I'm the guy who maintains the cogito package. I had a problem
a while back because my upstream package wanted to install
Marco d'Itri wrote:
On Aug 25, Horms [EMAIL PROTECTED] wrote:
There are some architectures where 2.4 is required, its
because of these that it seems that we are stuck with 2.4 for Etch.
alpha (installer), m68k (2.6 only works on amiga), s390 (installer),
mips, mipsel
What does
Andreas Barth wrote:
[snip]
DEBIAN PACKAGE FROM REPOSITORY:
11 .rodata 000840cb 0021a180 0021a180 ...
21 .data 000233c0 003f1d60 003f1d60 ...
MY OWN RECOMPILED DEBIAN PACKAGE:
11 .rodata 000a43ad 001f3180
Stephane Chauveau wrote:
Thiemo Seufer wrote:
Andreas Barth wrote:
[snip]
DEBIAN PACKAGE FROM REPOSITORY:
11 .rodata 000840cb 0021a180 0021a180 ...
21 .data 000233c0 003f1d60 003f1d60 ...
MY OWN RECOMPILED DEBIAN PACKAGE:
11
Stephane Chauveau wrote:
Thiemo Seufer wrote:
The whole thing sounds like the result of hiding _GLOBAL_OFFSET_TABLE_
and _PROCEDURE_LINKAGE_TABLE_ in newer binutils.
I assume that you mean that the problem the problem is solved by using
the latest binutils
Petter Reinholdtsen wrote:
[Ondrej Sury]
I am unsure if such patch would be accepted upstream, since Cyrus
runs on more then Linux and *BSD variants.
Does Solaris/AIX/whatever(tm) has stdint.h?
I believe both SOlaris and AIX got it. It is a POSIX standard header.
Well, rather C99.
John Hasler wrote:
Petter Reinholdtsen writes:
We have the the same limitation in norwegian law, were the work need to
have (the norwegian expression) verkshøyde, which implies a certain
quality level as Andreas puts it.
Do you mean quality or originality?
The amount of creativity the
Jesús M. Navarro wrote:
Hi, Andreas:
El Martes, 06 Septiembre 2005 18:20, Andreas Schuldei escribió:
* Petter Reinholdtsen [EMAIL PROTECTED] [2005-09-06 17:39:06]:
Which I fail to understand, as the limited rights provided to me by
law should be sufficient for the wiki content in most
Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
Computer programs are exempted from that requirement.
The work needs to have some kind of creative art.
Without any quality judgement, correct. This doesn't leave anything
of interest out.
Trivial programs are also not
1 - 100 of 209 matches
Mail list logo
