[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture: line.
I suppose it'd be nice to be able to use !foo in the Architecture: line
for cases where something is known not to
[Steve Langasek]
The four most common porting problems for software are endianness
(differs between i386/amd64 and powerpc), word size (differs between
i386/powerpc and amd64), char signedness (differs between i386/amd64
and powerpc), and use of non-PIC code in shared libs (which is a
[Henrique de Moraes Holschuh]
Not from what I know of dist-cc. You just need dist-cc, and nothing
else. dist-cc just offloads the number-crunching, so it uses no data
from the non-master node. AFAIK anyway (which is NOT much on dist-cc
matters).
Right. distcc runs the C preprocessor on
[Pierre Habouzit]
I mean that you have no way to say for huge source packages : you
only need to build this , this, this and this pacakge. since the
changes I've made won't affect the others.
As far as mirror bandwidth goes (including end user bandwidth *from*
the mirrors), that's a problem
[Pierre Habouzit]
As far as mirror bandwidth goes (including end user bandwidth *from*
the mirrors), that's a problem for rsync/zsync to solve.
1- binary backages do not have the same name (so rsync/apt-get are lost)
It's still a problem for rsync/zsync to solve. I didn't mean to say
[Tollef Fog Heen]
Assume makes an ass of u an' me.
Why do people keep circulating this saying? It makes no sense.
Normally, assuming only ever has the power to make an ass of the person
who did the assuming, i.e. me, not u and me. And even then, it's
not like you could get very far in life
[Norbert Preining]
The last question I have (for now):
- How can I install binaries for non-Debian architectures-os
combinations (win32, i386-solaris, ...) USING the pacakge management
system?
Is there a way at all -- or is there no way for this?
The real problem is *building* these
[Norbert Preining]
Ok, so the solution is to go for a `double' way:
- Package debian packages the debian way, ignoring other arch/os
combinations.
- Build some `non-standard' debian packages which have to be provided in
a different way (our web server or something else) which put
[Christoph Berg]
[0] [EMAIL PROTECTED]:~ $host archive.debian.org
archive.debian.org has address 208.185.25.38
[0] [EMAIL PROTECTED]:~ $host 208.185.25.38
38.25.185.208.in-addr.arpa domain name pointer raff.debian.org.
google has no trouble finding mirrors for it, though.
Peter
even in cases where it *is* documented, this is not by any
stretch of the imagination a typical use case.
[Peter 'p2' De Schrijver]
That's not true. Firmware can created by anyone and requires only
documentation and a compiler/linker for the target processor. In many
cases the CPU
[Miguel Gea Milvaques]
I don't undestand why software loading files (as we are talking) must
be in contrib. An example: xpdf, if you have not a pdf file you could
not use it, only it gave us a blank page. You could read a lot of
different files, a free pdf files or a non-free pdf files, and
[William Ballard]
I like my transactions to have ACID consistency and dpkg does not
have this by design - apt does.
You keep using that word. I do no think it means what you think it
means. Let's see how ACID-compliant apt install runs are
Atomicity - no. Your install does not, for
[Roger Leigh]
I've been using Debian with UTF-8 only locales for over 12 months
now. I now consider it fine for general use, with respect to
terminal and application support. Unlike a couple of years ago, most
things work perfectly.
Some apps like 'screen' do not just configure themselves
[Matthew Garrett]
Defining the character set as utf-8 means that any non-unicode
capable application is going to have issues, yes.
Postulate an app that is ignorant of character sets - we'll call it
aptitude. Fixing it to make it accept utf-8 and spit out the correct
encoding for its LC_CTYPE
We seem to be moving to a de facto standard of UTF-8 for non-ASCII
characters in debian/control files. This is not specified in Policy
[1], but for hopefully obvious reasons, consistency is a Good Thing,
and UTF-8 seems to be the best solution for this sort of thing.
In my sid control files, I
[Peter Samuelson]
I suggest that the affected source packages[3] be run through the
command 'iconv -f ORIGINAL_CHARSET -t utf-8' as soon as convenient.
Ehhh, I see I have already ruined my credibility by pasting the wrong
source package list. The real list is much shorter.
Apologies,
Peter
[Steinar H. Gunderson]
Transliterating is somewhat of a kludge (and I think in most cases
UTF-8 is a much better solution); OTOH I'd rapidly get confused in
the list of Japanese maintainers if their names weren't
transliterated.
I think it's a valid choice for a maintainer who natively
[Marco d'Itri]
Would people support a mass bug at minor severity?
Make it normal.
Given that Policy recommends debian/changelog to be utf-8, coupled with
the observation (which I had not thought of) that various tools may
require a maintainer's name in debian/control and debian/changelog to
[Thaddeus H. Black]
Would Peter permit me a mild dissent? I prefer Latin-1.
Dissents are fine. (:
The reason to go with UTF-8 is for consistency. Tools that wish to
render text onto the screen ought to be able to depend on knowing the
encoding that text is in. See below for why I (and many
[cas]
on every non-linux machine i have to use, the first thing i do is
download and compile all the GNU tools including tar. i then change
the PATH setting to include /usr/local/bin/gnu at the start.
I used to do that, but then I got burned by 'df'. Debugging that one
involved wading
[Tom Lees [EMAIL PROTECTED]]
however, this does still leave a big problem: how to handle the
upgrade from 0.8i to 0.8final. If you are currently using LVM 0.8i,
then upgrade to 0.8final, LVM will stop working unless you also
recompile your kernel.
Aye, there's the rub. It's a design problem
: fixed since DDMM.
--
Peter Samuelson
sampo.creighton.edu!psamuels
601 - 622 of 622 matches
Mail list logo
