The programs have to be relinked with openssl.
Fair enough.
So, there should be bugs filed against the packages which have to be
relinked.
While that is true, that still does not prevent someone from
upgrading either the packages which depend upon libssl09 or
libssl09 and not the dependent
BTW, one great thing about Linux is, fsck is incredibly fast compared to BSD
:-)
You haven't seen soft-updates on FreeBSD, have you?
The proliferation of ident daemons (midentd, oidentd, pidentd) in
Debian necessitates the introduction of a virtual package that these
packages can provide and conflict with (since you can only
[reasonably] run one ident daemon at once). While ident-daemon
seems more intuitive, the name
This is unnecessary unless something actually is going to depend on it. None
of these packages overlap in their fs name space. The only thing they have
in common is the inetd.conf entry. This is easily managed with update-inetd,
just like finger and others.
How are multiple identd packages
Roxen does, at least if you have different IP numbers, I can't get IP-less
vistual hosting to work with ftp sessions. And as a ISP the security issues
of
You can't get name-based virtual hosting with FTP. The protocol doesn't
transmit a hostname.
The primary MTA? does that mean that more than one MTA can be installed on
Debian at once? I thought they all conflicted with each other.
They do, and that should change.
The apparent solution to something like bug#45344 is to have all
the packages providing an identd to conflict with one another.
While reasonable in most cases, this has the horrible side effect
of not letting the administrator have multiple identds on the
system. What if I have a machine with
Okay, then solve the problem of which one should actually work on the
standard port? You can't use update-alternatives if the software is
Well, I would prefer that things didn't start listening for connections
without asking first, but I can't imagine that that's a popular suggestion.
Of course. Now if you built them yourself, dpkg wouldn't touch them.
If I wanted to build them myself, I would use Slackware.
If I repackage them I will need to remove the Conflicts line from
the control files every single time I upgrade.
People who want such complex setups should have enough
If you want to run two httpd's, popd's or mta's, you'll probably have to
do more than the usual tweaking to the package setup anyway, so what is
really the big deal of having to:
1. `apt-get source foo`
2. edit various files, mostly in debian/
3. add an epoch to the package version
4.
And of course you can always do dpkg --force-conflicts. I believe that's what
the --force commands are really there for: special situations.
Broken situations. Sure, you can --force dpkg to overwrite files
from another package. But Debian prefers to fix the problem instead.
a) I would not test a new daemon on a working machine, I would use a separate
So?
b) if you know what you are doing, compile the packages by hand, fix their
install scripts, and remove the conflicts. You are trying to circumvent the
norm.
If I wanted to compile them by hand, why would I
Because as everyone knows the last 10% takes 90% of the work and often ends up
hurting the other 90%.
Then it's being done wrong.
The point is Debian needs to work for as many people as possible. We are
doing
Yes, that's exactly the point.
apt-get source qpopper
[...]
dpkg -i
Ok, let's bring this back to implementation. How would you propose we handle
this? Currently daemons install, set themselves up, and begin running.
a) we can prompt.
b) we leave everything off and let the admin turn it on (not an option for
obvious reasons)
c) first come first serve --
the we-know-better-than-you attitude is what redhat and caldera (and
microsoft, for that matter) does. it sucks. debian has always done
better than that - our way is to encourage people to learn to do it for
themself by not trying to hide the fact that knowledge and experience is
required
debian's attitude is: if you want something different, DIY. and more
importantly, it lets you DIY.
Err.. what Unix DOESN'T let you DIY?
read the rest of my message. the bit that ranted about unix's that
get in the way of DIY. RH is one. sun's Netra is another...both are
examples of how NOT to do configuration management on unix.
No. You're talking about doing something your way and then having
it wrecked by the RH/whatever
There is currently no default -- it varies on a per-package basis.
I note that
### to run vtund as a server on port 5000, uncomment the following line:
#--server-- 5000
isn't uncommented by default.
Or are you saying something else?
I was merely pointing out the irony of one of Craig's packages
not enabling the daemon by default.
it isn't useful to run the vtund server until it is configured. there
is no standard configuration which is suitable for shipping as a
default - it MUST be customised for each site, each tunnel must be setup
individually.
When did useful enter this discussion?
pipsecd starts the daemon
[Craig flaming Doctor What deleted]
if someone doesn't want a service enabled then they should not install
the package that provides that service. if they want the service, then
install the appropriate package. simple. their choice to install or not
install.
now what is so fucking
No, this is silly. When you install a package, it is for use. If you
don't intend to use it, why install it?
Perhaps you can explain where this idea comes from.
Of course, if I want to evaluate a daemon, I can --unpack the package
into /usr/local/testfun and manually enable it, evaluate it,
The buildd maintainer is one of the 'notoriously difficult to reach'
people in Debian. If you were interested in trying, contacting the
mailing list for the port is the obvious next step.
What can the people on such a mailing list do about buildd issues?
--
To UNSUBSCRIBE, email to [EMAIL
The job of the buildd admin is to make sure packages are built. Mostly
that's automated, which is great, which means the buildd admin's job is
mostly to keep the automation working.
Dan was a really good buildd admin. Maybe he knows what he's talking
about.
--
To UNSUBSCRIBE, email to
developer, and I can use it to access the pkg-perl repository on
svn.debian.org without any trouble. When I became a Debian developer, I
got a new Alioth ID rra. It's now also been added to the pkg-perl
repository. But it doesn't work with svn.debian.org.
Assuming nothing is wrong, you may
True. However, the issue in question is whether or not it would be
better if they maintained in teams.
I imagine that it would not be better.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I intend to orphan the following packages:
bricolage
dbacl
libcache-mmap-perl
libmasonx-interp-withcallbacks-perl
libparams-callbackrequest-perl
libstring-crc32-perl
scottfree
ttf-kacst
ttf-paktype
If you want one of these, upload it with yourself as Maintainer.
Immediately.
--
To
Thanks to those who saved me the time and hassle of filing some wnpp
bugs.
bricolage
#348948
dbacl
#348949
libcache-mmap-perl
#348951
libmasonx-interp-withcallbacks-perl
#348952
libparams-callbackrequest-perl
#348953
libstring-crc32-perl
#348954
scottfree
#348950
--
To
Package: zsh (debian/main).
Maintainer: Clint Adams [EMAIL PROTECTED]
58941 core dump with function mycd() {builtin cd $@ echo $PWD}
[STRATEGY] Fixed in the next .deb. Already fixed upstream. (Mar15MH)
That is a week ago, has it been fixed since then?
My apologies. I've been
No real reason? Only one package can listen in on port 25, and
Only one package can listen on port 25 of one IP. It is possible to
have multiple packages listening on different ports or different IPs.
Why a new zsh was introduced in potato-proposed-updates ? It's not
compatible with thw previous version...
What do you mean, it's not compatible?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The completion control system has changed, along with a few other
minor details. I am myself a zsh user and have since made the
adjustment; I'm not sure the attitude others have towards their
zshrc's. A number of the mechanisms used prior to zsh-3.1.x to
control the completion behavior are no
I've opened a bug against zsh for the aforementioned behavior.
Fine. We can move the discussion there then.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adding readline support, while you're at it, would be really nice:-)
It isn't readline, but check out the nslookup function that comes with zsh.
I'm interested in constructive feedback.
I think fix_maintainer in utils.py should do something to compensate
for raw Latin-1 in the Maintainer field, or packages containing such
should be rejected.
(Please CC: me, I no longer track debian-devel)
Your M-F-T is broken.
I am contemplating the upload of a version of coreutils that will have
support for file acls. (I.e., mv cp -p will preserve acls, and ls -l
How about selinux support?
You can't distribute text with the word fuck in it anywhere to minors in
the
US?
Truly remarkable. Are there any minors reading this? Where do I hand myself
in?
Well, you would need to check the penal codes of each individual state
wherein such a minor resides; some states will allow
It's prurient, not puritan.
dict prurient will explain.
Thank you for misinterpreting the wordplay.
Please take this discussion to another mailing list or end it
completely. These arguments have been rehashed within Debian
since what I believe to be its original inception 7 years ago,
when
Do you think moria still has a place in Debian? Or do you gather it
might be better removed?
A better question is whether Mr. Koeneke is willing to relicense his
code under a free software license so that moria and angband and
derivatives can finally be free.
--
To UNSUBSCRIBE, email to
ii debianutils2.12.0 Miscellaneous utilities specific to Debian
ii exim 3.36-13An MTA (Mail Transport Agent)
Is there anyone who encountered the same problem or is this
Alpha specific or even specific to my machine?
This should be fixed in debianutils
Nevertheless, I don't know if it's a problem of the manpage system or of
the manpage writers, and how the writers could circumvent/solve the
problem. And this information would be useful before I start filing
bugs, or!?
This is a bug in the manpages themselves. The unformatted source
Overly terse answers (and your previous dismissals of questions as
trivial despite attempts to explain why they are non-trivial) do not
reassure anyone that you are capable of packaging a critical system
component, especially in an ambitiously different way.
I'm reassured.
- how to run the DELAYED queue (to give the possibility of deleting
things from it or to see what's in it)
- how to give developers the possibility of seeing what's in the queue
(daily rsyncs are not good enough for this; I've frequently pulled
packages from the accepted queue to
Please cc [EMAIL PROTECTED] about bugs.debian.org problems in future.
Can you supply some message-ids or subject lines or something so that we
can investigate? master's e-mail doesn't appear to be generally broken.
I wonder, though, if all five (!) MXs are doing the right thing.
I've had at
argument (publicly critising volunteers who are busy is not
productive, even if you point is otherwise valid).
The hell it isn't.
I couldn't find any way to authenticate db.debian.org when using direct LDAP
(TLS doesn't seem to be supported), but nonetheless this is damn convenient.
(requires python-ldap)
Or, for people who don't want python installed.
#!/bin/zsh
for i in ${(M)${(ps:\n\n:)${$(ldapsearch -LLL -x -h
+ Warning: Your 'echo' command is slightly broken.
+ It interprets escape sequences per default. We already
+ tried 'echo -E' but had no real success. If errors occur
That's not broken; that's POSIX-conformant.
ATM kdemultimedia (and therefore kde) is uninstallable on any arch
except amd64 because libtunepimp2c2a has not been built. I see from
the changelog of libtunepimp3 that it was renamed, so shouldn't
libtunepimp3 provide and replace libtunepimp2c2a or the dependencies
of noatun, juk. amarok,
In every single patch system I've encountered, you can run debian/rules
patch and get the patched source. It's only one more command and I consider
it universal for all patch systems deployed in Debian.
In some cases, this will fail if you don't have the build-dependencies
installed.
--
To
Which installation method are you using in dselect? In think you have to
specify the directory debian/dists/unstable as base directory and select
distributions main, contrib, and non-free.
This would be nice, but the Packages files seem to be set up for /debian to
be the base directory.
--
What should this do in your opinion? For me, print is something
quite different:
That's because you're not using zsh. It prints each argument,
using newline as an output separator. Also you could use print -N
if you prefer NULs instead of newlines.
print -N **/*.c | xargs -0 echo
is
I think that should be in non-free, until license issues are cleared.
(CellB, Netvideo, XML Parser)
Is it possible to port openmash to a free XML parser?
(I didn't see any non-commercial clauses in the CellB or Netvideo
licenses).
My concern is that locally compiled apps built against C++ libraries
other than libstdc++ will silently stop working on upgrade. This is
certainly not the most important issue facing us in the transition, but
so far it seems to me that people are regarding it as so *un*important
that it's
So, where is that public-domain software for extracting ZOO-files?
Somebody must find it and then create Debian-package of it. IMHO
creating new ZOO-archives is not very important for us.
IIRC, the ZOO extracters were Ooz and Looz.
Has anyone had any luck building libwww-perl against perl 5.80
yet?
Check http://ftp-master.debian.org/~bod/perl/pool/libw/libwww-perl/
Incidentally, the libdbi-perl there has a lower delta (1.1) than the one
in sid (2).
Incidentally, the libdbi-perl there has a lower delta (1.1) than the one
in sid (2).
Entrirely possible. In any case that staging repository is now gone.
I forgot to specify that -2 is built for 5.6.
Maybe a newer MU came out in between or something. I don't have the NMU
anymore, but IIRC it was a simple rebuild.
Yes, two newer MU's actually. The latter was a rebuild for 5.8;
unfortunately the build-deps weren't updated, so it was autobuilt
inconsistently.
#87667 gstreamerfiled: 546, changed 546
As an example, this package was uploaded to experimental on friday,
and has been packaged upstream for about a year. It was last changed
62 days ago.
Why experimental?
might it be more friendly to tab'ers to rename the dir base-doc instead
of doc-base
That seems like overkill. Just do something like
zstyle ':completion:*' ignored-patterns 'doc-base'
And if you use zsh, you don't need to bother with mmv or rename, since
there's zmv.
Anyway, it's similar to the 'rename' command that someone else mentioned.
It renames multiple files like converting all the files in a directory
from upper to lower case
mmv \* \#l1
zmv '(*)' '${(L)1}'
rename 's/\.c$/.x/' cumbersome?
Come on. s///? Backslash? $? Not one, but two single quotes?
One may as well type for i in *.c ; mv $i ${i/.c(#e)/.x} or
for i (*.c) { mv $i ${i%c}x }
I really would rather type ren *.c *.x. But then, I don't think in
perl.
Why do they need to coexist with the other implementation? They could
simply conflict.
They shouldn't.
No, it's not. Low end disks are cheap. High end disks still aren't.
Bandwidth still isn't. Especially when you're spending donated
resources rather than your own.
Odd, then, that Debian has turned down resource donations in the past.
How did this killing happen? Certainly not by denying them space on
Debian's servers. In fact, Mozilla killed Netscape because Netscape,
Poor John Galt is fooled by Branden into thinking that Netscape is
dead.
Yeah, it's really a pity that we failed to convert mid-end ethernet cards
and mid-end machines into high-end harddisks, and it's so trivial, isn't
it?
I seem to remember at least two occasions where offers of the use of
machine, rackspace, and bandwidth were turned down. I think in most
texi2html's behavior changed recently: if it is invoked with
-split=chapter, old versions place the HTML files in the same
directory as the documentation source, whereas new versions place the
generated files in a subdirectory.
To get the old behavior, one can use
--output . --split=chapter
So I want to highjack the package.
Any meanings?
Do it. Pop the trunk.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FWIW, this is just about the same response I got from upstream when I
asked them about the issue. The solution is of course to get rid of
libdb and use tdb or something equivalent.
Maybe you should convince bogofilter upstream to keep supporting tdb.
They're dropping it on the grounds that
Does this make sense to anyone but me?
It seems unnecessary for shared libraries to have priorities if they're
useless without programs which depend upon them.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
I don't see your point, and you seem to have missed mine.
My point is that there's no need for a package with no user-level
functionality of its own, such as a library, to have a priority
of its own.
If an Important package such as 'at' depends on libelf0 for whatever
dubious reason, libelf0
For Deity, I suppose we could make pattern-matching work in the policy file.
I think that would be preferable to simple directory exclusion.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Well, you're going to need a script to implement that policy. Probably
the best way to handle this is to provide a way to tell the package system
that you have deliberately removed a file, and that this file should not
be replaced. I wouldn't expect this in version 1.0 .
What exactly is the
bare minimum doesn't extend to a compilation environment.
or to printing, IMO.
* netbase and netstd should both be there, they are standard
on Unix
It seems as though the implicit definition of standard Unix system
omits a declaration of intended usage.
--
TO UNSUBSCRIBE FROM THIS
Should we notify the maintainers to better go back to 4.2 for sarge?
Don't bother notifying me; I won't be switching anything back to 4.2.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Why? (technical reasons, please). Not that I am assuming there is enough
evidence to downgrade anything but OpenLDAP just yet, but your reply seems
to imply that even if there were, you would still not downgrade.
If there were anything besides FUD, I'd consider it on its own merits,
but all
Only now I would trust BDB 4.2 with any mission critical data... but then, I
am the one which still builds Cyrus 2.1 against BDB 3.2 for stability (Cyrus
2.2 will be built against BDB 4.2).
IIRC, BDB 3.3 addresses very serious problems in 3.2, but we can't have
3.3 in Debian without a painful
I'll do that (they also used 1.7b which means second release candidate
for 1.7), but I probably won't be able to rewrite history and make 1.55
disappear...
I had this problem before and used the equivalent of 1.70.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Well, I did not talk about regular snapshots, but about direct exports.
Some tools in Debian (like darcs-buildpackage, thank you John for
this) make it possible to make such SCM builds. However the Autotools
output is not versioned, so not included in the tarball.
It is possible to run
I may do that too, but its architecture support is abysmal compared to
Debian, so I have no choice in the matter at this point (and lack the
time to port ubuntu to all my archs).
Perhaps the SCC plan will help make that choice easier for you.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
On Wed, Mar 25, 2009 at 11:44:19AM -0400, Mike O'Connor wrote:
yes, usually it should. It doesn't always. I have tried to file bugs
when I find them in the archive. The citadel related packages are a
recent example of this. Unfortunately they don't always get filed. In
my mind it would be
On Wed, Mar 25, 2009 at 02:32:19PM -0400, Mike O'Connor wrote:
I cannot. I can say that I opened RC bugs and made sure others from the
FTP team and from Release and Stable Release were aware of exactly what
was happening. The uploader was upstream, so upstream was being made
aware as well.
On Thu, Mar 26, 2009 at 09:04:05AM +0100, Bernhard R. Link wrote:
I think removing a package from a distribution should need more reasons
than a REJECT of that package.
Why? In both cases, the package is undistributable. How does it make
more sense to keep an undistributable version in the
On Thu, Mar 26, 2009 at 08:12:29PM +0100, Adeodato Simó wrote:
Right, but my proposed script should cater for both workflows (letting
the tools write your debian/changelog, or writing it by hand), since the
bug closure will *always* be in debian/changelog.
That is not true; for those of us who
On Mon, Apr 27, 2009 at 02:48:36PM +0200, Michal Čihař wrote:
Definitely not the only one which mandates this.
Please list others so I can mock them.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
But moving the 32-bit libs to /usr/lib32 does not make us
standards-conformant on amd64, because the FHS (yuckily) standardized on
storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs
in /usr/lib64.
That
On Wed, Mar 11, 2009 at 06:11:18PM +, Clint Adams wrote:
Thoughts?
I am going to assume from the lack of responses to this that no one
but the bug submitters care.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
On Wed, May 20, 2009 at 08:50:09PM +0200, Magnus Holmgren wrote:
Hmm, would that mean gpg --enable-dsa2 --cert-digest-algo SHA256 or
something?
Also, does gpg have an option to make it output the hash algorithms of key
(ID) signatures? I can't seem to find one.
Feed a key to gpg
On Sun, May 31, 2009 at 08:32:25AM -0500, John Goerzen wrote:
presumably the same reasons. evince either never had it, or it is
patched out in Debian. I would be happy with us patching okular to
http://bugs.debian.org/413953
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
On Tue, Jun 02, 2009 at 06:59:03AM -0300, David Bremner wrote:
Like the following, you mean?
dulcinea:~/tmp % rm *
zsh: sure you want to delete all the files in /home/bremner/tmp [yn]?
Just for the record, this is widely regarded as having been a poor
design decision, and is only
On Wed, Jun 03, 2009 at 01:59:15AM +0200, Sjors Gielen wrote:
May I ask why this is seen as a poor design decision? (Assuming that zsh
only asks this if the shell is interactive)
Because it gives a false sense of security, trains people to be less
careful, and doesn't handle all similar use
On Tue, Jul 21, 2009 at 06:14:27AM -0700, Russ Allbery wrote:
Except that every package in Debian that explicitly uses bash has no
declared dependency on bash because it's essential. I think attempting to
go through and add all those dependencies and test would be a huge waste
of time and
On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
Why?
Because:
On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
If the goal is to make *bash* removable, then I can understand why that
would be helpful to some people since it's the heavier shell by far. None
of
On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
Patches will be considered.
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst
[not replying off-list because that seems counterproductive and arrogant]
On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote:
Actually, if it's invoked as /bin/sh, it is supposed to be
Bourne-compatible. That's my experience with the current version:
Not much effort is put into
I would think that the same things that attract a technical individual
could attract a non-technical individual. Desire to learn. Desire to
contribute. Desire to build skills for resume or future employment.
And so on. The thing is that the current NM process is heavily biased
toward
Newly orphaned:
conquest - a real-time, multi-player space warfare game
xmaddressbook - X-based (Motif) address book
zsh30 - zsh 3.0
xmaddressbook also needs someone to take over as upstream.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
I created one package. When I try to perform the below
command, come this error:
pc101:# fakeroot debian/rules binary
fakeroot: FAKEROOTKEY set to 818929733
fakeroot: nested operation not yet supporte
Any suggestion ?
Are you trying to run fakeroot within fakeroot?
--
To
Hi,
The command:
pc01:package/fakeroot debian/rules
fakeroot: FAKEROOTKEY set to 818929733
fakeroot: nested operation not yet supported
Att,
Faria
Let's try this another way. Why is FAKEROOTKEY already set?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Not sure why on earth you would want to do this, but it seems to work
OK on etch. Maybe this is only supported with recent versions of
fakeroot?
No, it's only appearing to work OK. You'll lose state between the
different fakeroot invocations and that's why the error message is
there until we
I doubt that.
You can easily run into this problem by using
make-kpkg --rootcmd fakeroot modules-image
and the nvidia module will fail with
Does this happen every time?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 10253 matches
Mail list logo
