nt to nitpick that (why?), such a restriction is acceptable
according to the DFSG. for example, many authors choose to license
their software under a 'modified GPL' or 'GPL-with-some-exceptions'.
sean
--
signature.asc
Description: Digital signature
I agree that a debian-webapp list
> should be created.
i also think such an idea would be very useful, and i would certainly
join up in said list.
sean
--
[1] prepending to php_include_path in a debian-centric config file is an easy
way to achieve this for php pages.
[2] http
aid, the maintainer seems set in his ways, and maybe
there's something i don't know. if you really feel the maintainer should
be forced to fix the problem as was proposed, there does exist a means
of arbitrating this argument[1][2].
sean
--
[1]
http://www.nl.debian.org/doc/manua
e tech committee if he really cares) still holds.
sean
--
signature.asc
Description: Digital signature
he project just
for the packaging/policy repository.
so, that said, i'm going to go ahead and apply for an alioth project
for the packaging related stuff, as i was planning on doing so anyway.
if folks wouldn't mind a list hosted there, i can set it up.
sean
--
signature.asc
Description: Digital signature
d
dbconfig-common. the former will probably be absorbed into this project
(with the blessing of the maintainer, of course).
sean
signature.asc
Description: Digital signature
ems RC bugs are required for both of them...
if there's a problem, please file a bug about it instead of making
vague remarks like this.
sean
--
signature.asc
Description: Digital signature
g that would make
me think it an unsuitable candidate for unstable.
sean
--
signature.asc
Description: Digital signature
was generated, right? if the key was really kept somewhere Safe, there
would be no risk of the first key's compromise affecting it.
sean
--
signature.asc
Description: Digital signature
authenticity is a better approach in that case.
sean
--
signature.asc
Description: Digital signature
terested.
currently, the best place to put web documents would be a subdirectory
øf /usr/share/package (not *just* /usr/share/package, because you may
need to store non-web documents as part of your package too).
sean
--
signature.asc
Description: Digital signature
he qa infrastructure,
what should i report a wishlist bug against to ask for this info
on the qa page?
sean
--
signature.asc
Description: Digital signature
release
update) for 2 is going to happen, and 3 doesn't make me all too happy
as a "solution".
so, questions, comments, suggestions all welcome,
sean
--
signature.asc
Description: Digital signature
ain. if there are problems, please stop
making vague asides report the bugs.
sean
--
signature.asc
Description: Digital signature
o be frowned upon.
i do like your suggestion of bind mounts though, and will probably
do that myself in the future.
sean
--
signature.asc
Description: Digital signature
7;s my thoughts. anyone who jumps from mysql-server in woody to
mysql-server-4.1 in a completely new release of debian without
dist-upgrading their system first should *expect* for there to be a
problem, and at the very least we've gone out of our way to identify it
and tell them what they ha
ne searches, and people who wanted to search
everything could do a scope=sub on the base dn.
> Opinions, further suggestions?
- what are you currently doing wrt indexing?
- what underlying db format are you using?
sean
--
signature.asc
Description: Digital signature
ots under
/srv that i use frequently for building on combinations of architectures
and releases. i even have a chroot to play my favorite 32-bit windows games
via cedega.
sean
--
signature.asc
Description: Digital signature
e into the applications that need this variable a default
location of /usr/share/rnamotif/enfdata/, and then allow the user to
override this value via the same environment variable.
sean
--
signature.asc
Description: Digital signature
dingly.
sean
--
signature.asc
Description: Digital signature
o do if you use these build tools". i think you'll find most people
will gravitate towards doing so (debhelper is a good example of this),
and those who don't probably have a good reason (either because the tool
can't do what they want or maybe they've found a better
#x27; suggestion in
> my mail. What did you read?
guess that's what i get for jumping into a conversation without reading
a bit further back. i read part of a mail quoted in another email that
seemed to imply otherwise and guess i took that out of context. my bad.
sean
--
ly that "This program is released under the GPL with the
additional exemption that compiling, linking, and/or using
OpenSSL is allowed." If you are using GPL software developed by
others, you may want to ask the copyright holder for permission
to use their soft
dates available.
- debian will look very bad until it is fixed, and deservingly so.
sean
--
signature.asc
Description: Digital signature
is brought up *before* it was brought to an end?
sean
--
signature.asc
Description: Digital signature
hing, but a real fix
would be to patch apt to allow for this. such a patch would also make
it easier to distribute the packages list via other methodst too.
anyway if there are more people interested in working on this, i'd be
willing to put my code in cvs/svn and start up an alioth project.
of package management, and i'd to keep it that way
and let apt/aptitude/whatever handle all the really hard stuff.
sean
--
signature.asc
Description: Digital signature
add onto the
previously mentioned conditions, something like "if at all possible,
one month advanced warning before termination of services". obviously
this isn't a contract, so we couldn't bind anyone to this, but i think
most people would be willing to do us the favor of warni
that someone else reported earlier (iirc they were told it
should be cleared up in 24 hours, and that was also around a week ago).
sean
--
signature.asc
Description: Digital signature
way, sorry to adding to the noise on all of this...
sean
--
signature.asc
Description: Digital signature
i think you should also spend some time looking at these
bugs individually, this should get you what you want:
ldapsearch -h bugs.debian.org -x -b dc=bugs,dc=debian,dc=org
'(&(debbugspackage=$package)(debbugsstate=open))' debbugsid debbugssubmitter
but be prepared to wait a bit for th
nuke their settings.
that said, this sounds like a somewhat superficial configuration
setting, and i would wonder if all the effort to do things the right way
would provide would be worth it.
sean
--
signature.asc
Description: Digital signature
ollowing standard policy rules) is an acceptable alternative.
sean
--
signature.asc
Description: Digital signature
,
> > actually.
>
> If you use debconf, you can't use dpkg conffile handling, which I find a
> disadvantage (speaking as a user/admin, not as a packager.)
but you can still use ucf, which gives very much the same style
of handling as dpkg's conffile handling.
gt; Is it allowed to write it to a file in root's home dir?
>
> Mail it to root.
that's a horrible idea. root's mail often is forwarded, which then
puts the password on the wire, likely in the clear.
sean
--
signature.asc
Description: Digital signature
of
the debian release back to the first release.
but then again, ianarm.
sean
--
signature.asc
Description: Digital signature
onfig-common
mailing list: [EMAIL PROTECTED]
sean
--
signature.asc
Description: Digital signature
he 20th or so i'll be in lund, but don't think i'll have the time to
be making it to stockholm any time soon...
sean
--
signature.asc
Description: Digital signature
am happy to
> > announce that dak, our archive management software, finally supports
> > the use of the tilde ('~') in version numbers.
>
> Should we really start using this feature even though it violates
> section 5.6.12 of the Policy?
i'd say we should u
ew file in the control section of the deb
which contained a series of globs which could be used to match such
files. then, if a query through dpkg -S fails to find an owner of
a file it could go through the potentially longer process of searching
through these files, reporting all matches.
erve as informational to an admin asking "where the heck
did this file come from?"
sean
signature.asc
Description: Digital signature
dition to other things), put in plugins/libraries/programs
that override what might otherwise be a default behaviour of the
packaged software. there's no point in providing a place for them
to override configuration settings, since they are the ones providing
the configuration in the first place.
On Wed, Aug 16, 2006 at 04:31:51PM -0500, Ron Johnson wrote:
> IIRC, "security updates" do just (and *only*) that: fix *security*
> bugs, not *feature* bugs.
they do fix bugs caused by regressions in security updates though.
sean
signature.asc
Description: Digital signature
in the next few days.
fwiw, below are the affected package(r)s according to
grep-aptavail/dd-list.
sean
Cameron Dale <[EMAIL PROTECTED]>
torrentflux
David Gil <[EMAIL PROTECTED]>
acidbase
phpgacl
John Goerzen <[EMAIL PROTECTED]>
bacula
Debian Nagios M
translated per se) would doing some kind of locale check +
iconv be an acceptable way around the problem? for example:
to_lang=`locale | grep LANG`
translated_string=`echo string_to_translate | iconv -f C -t $to_lang`
thanks,
sean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
being
present (as a metapackage)?
input appreciated,
sean
signature.asc
Description: This is a digitally signed message part
mething like 40 conffiles shared between the packages. but having
asked on #d-d a few times as well as here and not having heard anything,
i'm afraid i'm going to have to bite the bullet on this one as frank
suggests.
sean
signature.asc
Description: This is a digitally signed message part
ucf and might as well just use ucf then.
thanks,
sean
signature.asc
Description: This is a digitally signed message part
e site has
> been down for some time now. :/)
my guess is that they no longer exist in there (and are instead in
nagios-plugins-foo.conffilels), but i'll double check and report back on
that.
thanks,
sean
signature.asc
Description: This is a digitally signed message part
e both more
ambitious and less careful.
sean
signature.asc
Description: This is a digitally signed message part
from what i can tell, hence the posting of
this question.
sean
signature.asc
Description: This is a digitally signed message part
e locally modified versions, or don't work with
the latest versions... fun!
sean
signature.asc
Description: This is a digitally signed message part
sonsibility
to specify the additional DirectoryIndex.
iirc DirectoryIndex does/can append to the list of index files, right?
if so i'd have no problem slipping this into the php/apache module
configuration files if that's the agreed course of action. but whether
or not this makes
has accidentally gone AWOL from
some of the SAPI packages (fix coming shortly).
sean
signature.asc
Description: This is a digitally signed message part
it's in fact
not just a nice addition but an essential one given that LSB-compatible
scripts among others silently assume this is already the case.
sean
signature.asc
Description: This is a digitally signed message part
re are any new developments i'd suggest staying with what
is presently being done, and after etch maybe we can sit down and
revisit this.
sean
signature.asc
Description: This is a digitally signed message part
by default. of
course this means we'd need to have small cgi somewhere to act as
a POST<->SMTP gateway, but that's not exactly the most complicated
thing in the world to put together. maybe we already have one?
it's a shame this is coming up now though.
sean
s
as a bug and it's been fixed for a couple weeks now. in fact
i think the fix has finally made it to etch (5.2.0-something).
sean
signature.asc
Description: This is a digitally signed message part
e, and
maybe cloned to the relevant linux-modules packages for the sake of
documenting it. really i don't see any reason why the packages in
question should ship the files at all, if they're going to be updated
as part of the package installation/configuration.
sean
signatur
off invoke-rc.d on each of them during upgrade,
and ignore the return codes? if you really cared i suppose you
couldtest before calling invoke-rc.d too, but the point is i
don't think it's a great deal of work to do so.
sean
signature.asc
Description: Digital signature
ysklogd syslog-ng"
for s in $sysloginits; do
test -x /etc/init.d/$s && invoke-rc.d $s restart || true
done
(granted, the init scripts are actually named differently than the
package names, but you should see my point)
sean
signature.asc
Description: Digital signature
x27;d hold off on that just yet... i think that some reasonable
discussion with the folks on debian-policy will yield either
an alteration or a removal of this latest change.
sean
signature.asc
Description: Digital signature
mail admins saying "the mail server is busy
enough right now, thanks".
sean
signature.asc
Description: Digital signature
utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a
-lnsl -lresolv -lradiusclient -lssl -lcrypto
gcc -Wall -g -O2 -o check_radius check_radius.o netutils.o utils.o
-L/home/sean/nagiosplug/plugins ../lib/libnagiosplug.a ../lib/libcoreutils.a
-lresolv /usr/lib/gcc/i486-linux-gnu/4.0.2
ying this in the build-depends makes
things a bit harder for backporting to sarge. also, people will continue
to have problems compiling the package (or orig upstream) from source,
hence my hoping that there was a better way.
sean
--
signature.asc
Description: Digital signature
time this summer the webapps-common package will be making its way
into unstable (like dbconfig-common but for dealing with setting up
"sites"), you can get more info on the above mentioned list.
sean
signature.asc
Description: Digital signature
nest* solution out there, but it works, and there's
nothing wrong with it from a technical/policy perspective. the real
solution would be for dpkg to finally get around to implementing
"reconfigure" being passed to postinst (istr docs mentioning that this
would "some day" happen), but this will break many, many things.
sean
signature.asc
Description: Digital signature
default.
this would be the reasonable approach if the user already exists.
sean
--
signature.asc
Description: Digital signature
ntscripts.
>
> If so, create the user in preinst and it'll work just fine.
the next sentence, which you conveniently cut out, explains exactly why
this won't work just fine :)
sean
signature.asc
Description: Digital signature
ide to clear this
> bit." ?
no, i'd say put that in README.Debian, explaining why it may be needed
and why you've chosen to include it or not include it. if the local
admin really cares about setuid bits, they probably have something
watching for them anyway.
sean
--
ssue
between now and then.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379788
thanks,
sean
--
signature.asc
Description: Digital signature
, and it in fact seems to have fixed a couple problems from
which i was quietly suffering on my thinkpad.
sean
--
signature.asc
Description: Digital signature
ay you could use the standard
packages used by the native architectures, as long as the maintainer
scripts in question don't call any architecture-specific binaries provided
by the package.
sean
--
signature.asc
Description: Digital signature
yet. postrm would be run after, if
only it still existed after the rm :)
sean
--
signature.asc
Description: Digital signature
en
# show debconf note that explains the situation
fi
?
sean
signature.asc
Description: Digital signature
On Mon, 2003-06-02 at 15:28, Robert McQueen wrote:
> My concern is that even if you distribute
> in source form, you're still condoning ignoring part of Gaim's license,
> which seems highly dubious. So as well as saying "Debian will never ship
> this" as a Debian developer, I was also saying "pleas
I just updated to X.org. With apt. Automatically. Woohoo!! I mean full
on xserver-xorg too. I did not touch ANYTHING.
X team you rock. This is why I started using Debian 7 years ago. This is
what keeps me here.
One and only one snag. purging the xfree86-common package failed because
it was t
On Fri, Jul 15, 2005 at 08:11:15PM +0200, Nico Golde wrote:
> no of course not but it would be good to have a reference
> value.
it seems something that would be most appropriate as a guideline
supplied in the debian developers' reference.
sean
--
signature.asc
Descripti
and use libcurl, you should report bugs against them.
sean
--
signature.asc
Description: Digital signature
e a
wishlist bug against libcurl asking to compile against gnutls
instead, but it's up to the maintainer in question to decide.
sean
--
signature.asc
Description: Digital signature
hi,
On Mon, Jul 18, 2005 at 11:06:13AM +0200, Torsten Landschoff wrote:
> On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote:
> > this is definitely NOT a reason to NMU libcurl. remember that it is
> > your package that is "broken". of course you could still fi
hi,
On Mon, Jul 18, 2005 at 03:40:30PM +0200, Olaf van der Spek wrote:
> On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote:
> > yes, and the same with libmysqlclient, which is why there's no longer ssl
> > support in the mysql packages :(
>
> Wouldn't it be
ther when another similar style license
problem comes out.
> Should it be worst to announce this to debian-devel-announce?
no.
sean
--
signature.asc
Description: Digital signature
ou to do, but it neither solves
the problem in the larger scheme of things nor would i consider it an
obligation on your part to do so.
sean
--
signature.asc
Description: Digital signature
ries that i've been doing lately, and think of
it as an important feature. of course important feature does not
necessarily equal policy amendment, but i'd like to know either way so
my code doesn't break on systems where /bin/sh has been replaced from
a minimalistic shell.
sean
--
signature.asc
Description: Digital signature
open for
further discussion. if you feel like condensing the general consensus
into a paragraph or two to go into this document, i'd be appreciative.
sean
--
[1] http://people.debian.org/~seanius/policy/dbapp-policy.html
signature.asc
Description: Digital signature
m is so bad, as long as you don't mind
dropping the data during removal as well as purges.
sean
--
signature.asc
Description: Digital signature
because everyone else is doing it...
On Tue, Aug 02, 2005 at 06:46:20PM -0400, Joey Hess wrote:
> sean finney <[EMAIL PROTECTED]>
>cacti
>cacti-cactid
>sugarplum
all three have now been uploaded with proper dependencies.
sean
--
signature.asc
De
file is a complicated or
arbitrary format, there's a feature in cvs youmight be interested
in (contact me on the alioth list to hear more about that if necessary)
sean
--
[1] /usr/share/doc/dbconfig-common/dbconfig-common-using.html
[2] [EMAIL PROTECTED]
signature.asc
Description: Digital signature
this case, however, you are reducing a set of simple and non-intensive
system commands from 5 to 3 (and possibly introducing some non-posixish
stuff according to Miquel). i can't guarantee you christian or i would
bother to include it. reduce it to one fairly understandable command and
maybe :)
sean
signature.asc
Description: Digital signature
course this would all be so much simpler if we could actually use the
> power of modern shells (post 1993) in init scripts - subprocesses
> wouldn't be required at all
it is a /bin/bash script, so i suppose bashisms are allowed, provided
that there aren't other reasons christian or i would object to them.
sean
--
signature.asc
Description: Digital signature
as i said,
it is a *bash* script...
sean
--
signature.asc
Description: Digital signature
in fact, the vast majority of init scripts do not even use
sed (i can't quantitatively say this for regexes though).
sean
--
signature.asc
Description: Digital signature
On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> /run/bootchart, but there seems to be some resistance to actually trying to
> standardize on /run :)
what about /dev/shm?
sean
--
signature.asc
Description: Digital signature
On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
> sean finney <[EMAIL PROTECTED]> writes:
> > On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> >> /run/bootchart, but there seems to be some resistance to actually trying to
> >> standard
ou could try and detect for a failure and
spit out a warning, or even better provide a clean way to determine the
behaviour of the daemon when the package is installed.
sean
--
signature.asc
Description: Digital signature
than "all rights reserved". the best way to specify what the terms
of use, copying, modification, and/or redistribution are is via
a license.
sean
--
signature.asc
Description: Digital signature
ng the upgrade,
if not provided an easy upgrade path... as otherwise it will break
everything from sound to networking to who knows what else for many people.
sean
signature.asc
Description: Digital signature
hi,
i guess i could just do it and find out, but figure asking first doesn't
exactly hurt. can we build/upload amd64 binary packages to unstable yet?
sean
--
signature.asc
Description: Digital signature
s in a production environment?
sean
signature.asc
Description: Digital signature
101 - 200 of 1219 matches
Mail list logo
