[EMAIL PROTECTED]
> It would be really handy to have archives of the debian mailing lists
> available as mbox archives.
The correct solution, until someone gets around to exporting the
mboxes, is to talk/grumble/whine about wanting the archive for some
specific month and list, where developers ca
[Brian Nelson]
> * Package name: qt-x11-opensource
> Version : 4.0 beta 2
> Upstream Author : Trolltech AS
Is there some reason for the "-opensource" in the name? That's a
pretty redundant designation for something in Debian main, don't you
think? I'd probably go with "qt4" or "
[Philippe COVAL]
> * Package name: connect
> Version : 1.93
That's a terrible package name. What will the GNUSTEP people do if
they ever want to package something that manages SMB client mounts?
signature.asc
Description: Digital signature
[W. Borgert]
> - Is it relevant, whether Python is compiled on a system with 2.6
> or 2.4 kernel? If so, how can I find out on which kernel the
> Debian package has been built?
Might or might not be relevant - depends on whether the python build
scripts attempt to detect the kernel capabilit
[Branden Robinson]
> > Branden Robinson <[EMAIL PROTECTED]>:
> > twofish
>
> Go ahead and file a bug for this one, please
Sorry, no can do - twofish isn't actually uncontroversially buggy. It
handles bullet lists in the de facto standard way, which I didn't like,
but I have since been persuad
[Zak B. Elep]
> In a related problem, I'm packaging the latest version of gtklp at
> 1.0c. My earlier package is 1.0 but using version 1.0rel (I was
> stupid, but I think I should have slapped upstream earlier for using
> a very inadequate versioning scheme).
I'd go with 1.0rel+1.0c. Fix it for
[martin f krafft]
> Parts of debian/rules are Ubuntu-specific (e.g. mv README.Debian
> README.Ubuntu) and we would love to have that removed.
The DISTRIB thing can be implemented quite easily without include files
or anything. Just say:
DISTRIB := $(shell something-that-prints-DEBIAN-or-UBUNT
[Jeroen van Wolffelaar]
> It seems like this list has a lot of false positives, take for example
> php-mail-mime:
>
> | Description: PHP PEAR module for creating and decoding MIME messages
> | Provides classes to deal with creation and manipulation of mime messages:
> | .
> | * mime.php: Crea
[Peter Samuelson]
> I'd like to file a mass bug for these, but it's on the order of 583
> binary packages in 430 source packages, so I obviously want to get
> some feedback first.
Jeroen van Wolffelaar pointed out to me that 430 source packages is a
bit much for a mass bug, es
Package: linda
Version: 0.3.10
Severity: wishlist
ObListCC: search for 'mass bug' below.
Lots of packages have a Description field that includes a bullet list.
There is no good way to do these, unfortunately, but lots of wrong
ways. In particular, you'll cause incorrect line wrapping in dselect
[Darren Salt]
> Back-porting to sarge using tools in sarge?
That doesn't sound so daunting. Anyone doing serious backporting will
need to start by backporting a few development tools, which is already
true from woody -> sarge - viz. debhelper 4.
signature.asc
Description: Digital signature
[Jason Lunz]
> I just figured out a way to do this for the ssh binary. Maybe this would
> work for you?
As others have pointed out, there is -Wl,-Bstatic and -Wl,-Bdynamic -
but even absent those, you can just refer to the .a files directly if
you wish. So instead of -Lopenbsd-compat/ -lopenbsd-
[Blunt Jackson]
> I am familiar with the nss issue, although that's not really relevant
> to this question. The nss issue, and the related question in the FAQ
> is that when statically linking to libc, there are still dynamic
> loads required -- but libc handles this for the application.
> (Presum
[Nikita V. Youshchenko]
> Maybe it's better just not to provide oss drivers for chips supported
> by alsa? AFAIK OSS will be removed from kernel soon...
It may or may not be removed soon - I note that it isn't listed in
Documentation/feature-removal-schedule.txt in kernel 2.6.11 yet.
Anyway, two
[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
[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 sa
[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
[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 o
[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
> pr
[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 lif
[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 bin
[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* th
[Otto Wyss]
> I've set the s attrtibute of halt since on my desktop any user may
> stop the system. But about each second month or so it's set back to
> it's original rights probably by a package upgrade. Is there a way to
> keep the access rights or any better way to handle these kind of
> proble
[Brian May]
> Whatever happened to the idea of even numbered kernels being
> "stable"?
You didn't get the memo? That's an obsolete standard - the 2.6.x line
of development has been much more aggressive than past stable series,
as far as allowed tree changes, and last July or so (I think it was),
[Ken Bloom]
> I'm confused. One making backports from sid to woody should backport
> a package in such a way that it is buildable with woody's
> build-essential.
Yes. Same will be true backporting to sarge. But if sarge
build-essential were to be updated to contain debhelper (>= 4), that
would
[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
signatu
> >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
[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, an
[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, fo
[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 themselv
[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_CT
[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
[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
[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 sp
[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.
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 s
[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 thr
[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 pr
it
"has been either closed or set to severity: fixed" since .
--
Peter Samuelson
501 - 539 of 539 matches
Mail list logo
