Greetings,
* Cord Beermann (c...@debian.org) wrote:
> As listmaster i can confirm that it is a big problem to deliver Mails to
> gmail/outlook/yahoo. Yahoo Subscribers are mostly gone by now because they
> bounced a lot, for gmail it is so much that we just ignore bounces because of
> those rules.
Greetings,
* Mattia Rizzolo (mat...@debian.org) wrote:
> Alternatively, I wonder if ARC nowadays is respected enough (and if
> Google cares about it)... I personally don't have any system with ARC
> under my care.
Sadly, no, they don't seem to care one bit about ARC, except possibly if
it's their
Greetings,
* Felix Lechner (felix.lech...@lease-up.com) wrote:
> Attached please find a WIP patch for wolfSSL support in postgresql-12.
Would really be best to have this off of HEAD if we're going to be
looking at it rather than v12. We certainly aren't going to add new
support for something new
Package: gcc-6
Version: 4:6.3.0-18+deb9u1
Severity: important
Greetings,
gcc is failing on powerpc64le-linux-gnu with a gcc dump. This bug is
preventing pgbackrest (and, likely, PostgreSQL itself as of current
HEAD, though I haven't had a chance to test it myself) from being able
to be built on
Package: ferm
Version: 2.2-3
Greetings,
The ferm system allows the inclusion of other files, including those
which might be outside of the /etc/ferm directory. When those files
change and the user issues a 'reload', the ferm cache should be updated.
This is not currently happening because the fe
* Christoph Berg (m...@debian.org) wrote:
> Re: Stephen Frost 2016-07-14 <20160714142721.gl4...@tamriel.snowman.net>
> > * Lucas Nussbaum (lu...@debian.org) wrote:
> > > (This might be related to the fact that I use a "user" login on my build
> > > mach
* Lucas Nussbaum (lu...@debian.org) wrote:
> (This might be related to the fact that I use a "user" login on my build
> machine)
Yes, it is.
We could possibly remove those tests, but I'm not really thrilled with
that idea. I'm not sure if it'd be at all sensible to try and write
something to che
Christian,
* Christian Hofstaedtler (z...@debian.org) wrote:
> * Stephen Frost [151006 04:12]:
> > That said, I do think it's worthwhile to see about fixing these
> > particular install failures, and the proposed change looks like it would
> > at least do that.
>
Christian,
Thanks for the quick reply!
* Christian Hofstaedtler (z...@debian.org) wrote:
> * Stephen Frost [151005 22:57]:
> > Any chance we could get this bug fixed? Looks like a pretty
> > straight-forward change.
>
> Only on the surface it's a straight-for
Greetings,
Any chance we could get this bug fixed? Looks like a pretty
straight-forward change.
Is there anything I can do to help?
Thanks!
Stephen
signature.asc
Description: Digital signature
Aaron,
* Aaron Zauner (a...@azet.org) wrote:
> I think we should take this discussion to an appropriate PostgreSQL
> mailing list (please feel free to include me in a thread if you start
> one). But I think it's best to close this bug for now. I agree that MD5
> needs to be replaced, but using pla
* Christoph Berg (m...@debian.org) wrote:
> Re: Stephen Frost 2015-03-04 <20150304145551.gu29...@tamriel.snowman.net>
> > > Just to put the idea out there; PGSQL currently links to OpenSSL for
> > > TLS, right? TLS has support for SRP [0] [1]. This could be us
* Michael Samuel (m...@miknet.net) wrote:
> I think the direction upstream is going with SCRAM (or similar) is
> fine, but either new hashes are required or using a customized code
> base that uses MD5(password|username) where the password would
> normally be directly input is needed.
For my 2c, I
Aaron,
* Aaron Zauner (a...@azet.org) wrote:
> Stephen Frost wrote:
> > We're currently looking at getting SCRAM support by implementing SASL,
> > but I'm worried that we'll then create a dependency on SASL that people
> > won't be happy with and there
Michael,
* Michael Samuel (m...@miknet.net) wrote:
> On 4 March 2015 at 15:22, Stephen Frost wrote:
> > That really just changes it back to the 'password' case though, doesn't
> > it? An attacker who can sniff the network would get the response from
> > t
Michael,
* Michael Samuel (m...@miknet.net) wrote:
> On 4 March 2015 at 12:33, Stephen Frost wrote:
> > To be clear, I *am* from the PostgreSQL community and I'd be happy to
> > discuss any useful suggestions about providing an alternative that
> > doesn't break th
* Michael Samuel (m...@miknet.net) wrote:
> - I don't recommend storing the password in cleartext
> - I *do* recommend exchanging the password in cleartext over the network
And I will continue to argue that it's far worse these days to send the
password in cleartext across the wire.
> This is bec
* Michael Samuel (m...@miknet.net) wrote:
> On 4 March 2015 at 12:03, Aaron Zauner wrote:
> >> Uh, no, using 'password' is far worse, and uniformly so, than using md5.
> >> I have no idea why anyone would think it's better to store a cleartext
> >> version of your password in the pg_authid data (n
Aaron,
* Aaron Zauner (a...@azet.org) wrote:
> Debian ships a set of Perl scripts to configure for PostgreSQL server
> configurations, these are quite outdated and are currently configuring
> authentication to use MD5 when 'password' should be used instead.
Uh, no, using 'password' is far worse,
* Charlie Brady (charl...@budge.apana.org.au) wrote:
> On Sun, 22 Feb 2015, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the postgresql package:
> >
> > #778850: Missing 20-column_privilege_leak.patch file in postgres
* Aaron M. Ucko (u...@debian.org) wrote:
> On behalf of the Washington, DC, US Debian developer community, I
> would like to request an official debian-dug-* list to supplant our
> current teams.debian.net list. (I'm sending a copy of this request to
> the list to solicit seconds from other member
* Lisandro Damián Nicanor Pérez Meyer (lisan...@debian.org) wrote:
> With all the due respect to Steve, considering the fact that he is a very
> involved contributor of Upstart and judging from his position on this
> subject,
> I also think he should step down from participating as a TC member i
Package: postgresql-common
Version: 141
postgresql-common provides a way to mark clusters as "auto", "manual",
or "disabled". When a cluster is marked as "disabled", however,
pg_checksystem will still try to verify that the cluster is valid and
will attempt to do things like check the filesystem
Marc,
* Marc Fournier (marc.fourn...@camptocamp.com) wrote:
> Since 1.5.3, pgsql2shp and shp2pgsql have moved from /usr/bin to
> /usr/lib/postgresql/X.Y/bin and have moved from the postgis package to
> the postgresql-X.Y-postgis package.
Wow, thanks for pointing that out- it's quite busted and i
Package: openmpi
Version: 1.4.2-3
Severity: wishlist
Please add support for Torque to the OpenMPI packages.
Build-Depends: libtorque2-dev
./configure [...] --with-tm
Thanks,
Stephen
signature.asc
Description: Digital signature
* Tom Feiner (feiner@gmail.com) wrote:
> As matthias mentioned in the upstream ticket you filed, the if_ plugin
> in the 1.3 series should do the right thing now.
No, it doesn't. *.max is *still* set to 1,000,000,000, which is wrong.
This is a counter since *boot* (or last overflow), not sinc
Package: munin
Version: 1.2.6-10
Severity: normal
The if_ module has problems with large values because it incorrectly
tells rrdtool that the maximum size allowed is the interface speed. As
the data being pulled from /proc/net/dev is the total number of bytes
transferred since boot (modulo overflo
Package: libmapnik0.5
Version: 0.5.0-2
Greetings,
In mapnik upstream r540, regex support appears to have been disabled
for filters:
http://trac.mapnik.org/changeset/540/trunk/include/mapnik/filter_parser.hpp
This breaks things for people upgrading to 0.5 from previous versions
where i
Package: tilecache
Version: 2.01-4
Greetings,
mapnik.rawdata(im) has been depreceated in favor of im.tostring() in
0.5. As that's the version in Debian, it'd be nice to have tilecache
updated accordingly. You can also use the first hunk from the patch
posted here:
http://openlayers.o
Package: x11-common
Severity: serious
tags 400632 -wontfix
Greetings,
The setuid usr/bin/X binary should not be shipped with x11-common
because it's not *needed* for X11 clients. That by itself is a good
enough reason. Put it in xserver-xorg-core or similar, not in
x11-common.
Additionally, x1
Greetings,
It looks like the referenced bug in python-central (#424906) was
closed out over a month ago. If that's been fixed can we get a
rebuild of player/stage on affected platforms? Looks like at least
amd64, mips, m68k, powerpc, s390.
Thanks,
Stephen
sign
Greetings,
aiui, even the 'mount' provided previously by mount would have
failed if portmap (well, lockd, I'm guessing) was unavailable.
Therefore, having mount only Recommend nfs-common is the
appropriate solution. Having nfs-common only Recommend portmap
doesn't make much sense since
Package: tech-ctte
Severity: normal
User: [EMAIL PROTECTED]
Usertags: Debian-exim
Greetings,
As outlined in bugs: #223831, #223963, #225031, #233803, #255493,
#262195, not everyone agrees with the concept of having a 'namespace'
for Debian-created system accounts. It would be of great bene
severity 400448 wishlist
reassign 400448 gnutls
thanks
* Mitar ([EMAIL PROTECTED]) wrote:
> Package: libnss-ldap
[...]
> When I configure CA directory with "tls_cacertdir" configuration option
> in /etc/libnss.conf file NSS querying (for example "finger mitar") takes
> very long (about 20 seconds
* Scott Anderson ([EMAIL PROTECTED]) wrote:
> Setting up nfs-common (1.0.7-12) ...
> Adding system user `statd' with uid 107...
> Adding new user `statd' (107) with group `nogroup'.
> useradd: /home/devel/openldap/openldap2-2.1.30/libraries/liblber/io.c:161:
> ber_free_buf: Assertion
> `((ber)->be
* Andrew Deason ([EMAIL PROTECTED]) wrote:
> Suppose I want to use krb5_ccname and SASL, so I can have a host
> authenticate with its host principal from a keytab. However, I don't want
> normal users to be able to read the host principal keytab; I just want
> libnss-ldap to use their own kerberos
* Jan Evert van Grootheest ([EMAIL PROTECTED]) wrote:
> Using these settings, udevd still reports about the ldap server being
> unreachable.
Right, that's expected, and perfectly reasonable.
> But the timeouts are now such that bootup is basically a snap. Each
> search takes about 1 second.
Go
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> Right, with the defaults... The idea was to reduce those. I've played
> with this some in preparation of 251-6. Try:
> reconn_maxconntries = 2
> reconn_tries = 1
> reconn_sleeptime = 1
> reconn_maxsleeptime = 8
I guess I cou
* Jan Evert van Grootheest ([EMAIL PROTECTED]) wrote:
> I've tried it.
I'm not sure you have...
> During boot udevd attempts to resolve a few groups (group scanner, group
> scanner, group scanner, group nvram, user tss, group tss, group fuse,
> group rdma, group rdma), as far as I understand th
* Steinar H. Gunderson ([EMAIL PROTECTED]) wrote:
> On Tue, Oct 03, 2006 at 11:28:34PM -0700, Steve Langasek wrote:
> > Can we just fix libnss-ldap already to use a sensible default bind policy,
> > please?
>
> Sure, I could do that (removing the boot-time workarounds), assuming the
> maintainer d
* Damyan Ivanov ([EMAIL PROTECTED]) wrote:
> Stephen Frost -- 3.10.2006 22:31 --:
> > It needs to be 600 if you want tight control on your LDAP directory such
> > that everyone has to connect using a password and you don't want that
> > password available to everyone.
* Steinar H. Gunderson ([EMAIL PROTECTED]) wrote:
> Please let me know ASAP if you have any objections; I'll be asking the RMs
> what's a reasonable delay for an NMU fixing problems introduced in my own
> NMU, but I guess I'll be able to upload sometime tomorrow.
It fixes RC bugs and therefore sho
* Damyan Ivanov ([EMAIL PROTECTED]) wrote:
> What I don't understand is why libnss-ldap.conf *needs* to be 0600 at
> all. A big warning in the file (todo) and debconf placing password in
> a separate file (done) should be enough, IMHO.
It needs to be 600 if you want tight control on your LDAP dire
* Damyan Ivanov ([EMAIL PROTECTED]) wrote:
> Right now, if I put password in /etc/libnss-ldap.conf (and therefore
> protect the file with 0600 permissions), only root can access ldap via
> nss. Others get assertions. This makes the password-along-everything
> setup highly unusable (to me).
>
> It
* Gabor Gombas ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 14, 2006 at 03:02:34PM -0400, Stephen Frost wrote:
>
> > Certainly possible.. If that's the case then there's nothing
> > libnss-ldap could do about it tho and this would be an issue with
> > libldap. Wha
* Gabor Gombas ([EMAIL PROTECTED]) wrote:
> Looking at the strace output, libnss-ldap.conf is parsed before
> /etc/ldap/ldap.conf. Is it possible that the parsing of
> /etc/ldap/ldap.conf resets the TLS options configured in
> libnss-ldap.conf?
Certainly possible.. If that's the case then there's
severity 383446 wishlist
thanks
* Paolo Cavallini ([EMAIL PROTECTED]) wrote:
> An utility, called mktemplate_gis, was included in previous unofficial
> releases of postgis. It can be
> useful, especially for new users, because it makes a template with GIS
> functions in the database, and
> sav
Package: mdadm
Version: 2.5.2-9
Severity: wishlist
Greetings,
Using hostname, or using the super-minor, can result in some serious
problems when attempting to assemble arrays. The hostname is a very
poor choice as it's not uncommon for a machine which is being upgraded
(ie: most of the h
* Julien Danjou ([EMAIL PROTECTED]) wrote:
> Severity: grave
Not every bug in libnss-ldap is 'grave', not even ones which make NSS
start having problems.
> I tried to upgrade to libnss-ldap 251-5 and the upgrade failed with a
> beautiful error:
>
> Setting up libnss-ldap (251-5) ...
> Can't loca
* Vedran Fura? ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > What do your configs look like,
What are the permissions on your libnss-ldap.conf?
> But the problem is not in login(1), if I log in with nscd and then disable
> it *every* started app will crash immediately wit
* Sjoerd Simons ([EMAIL PROTECTED]) wrote:
> I've rebooted one of the systems with the ipv6 module blacklisted. After that
> it still shows exactly the same behaviour (identicaly trace, just the ipv6
> addresses replaced by ipv4 addresses)...
Hmm, ok.
> > Can you check if there's a file in /var/l
* Sjoerd Simons ([EMAIL PROTECTED]) wrote:
> On Sun, Jul 02, 2006 at 08:00:22PM -0400, Stephen Frost wrote:
> > * Vedran Fura?? ([EMAIL PROTECTED]) wrote:
> > > After upgrade to version 251 I can't login as a user in ldap and even as
> > > root which is a loc
severity 376426 serious
tags +moreinfo
thanks
* Vedran Fura?? ([EMAIL PROTECTED]) wrote:
> After upgrade to version 251 I can't login as a user in ldap and even as
> root which is a local user. Login process dies with SIGPIPE.
> It only happens without nscd.
What do your configs look like, what v
* Michael Biebl ([EMAIL PROTECTED]) wrote:
> > case here? Also, have you tried waiting it out? Each request would end
> > up taking about 2 minutes, but technically it *should* give up
> > eventually..
>
> I waited for something like 10min without success. But honestly this
> wouldn't be a prope
* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> It does not want to time out. After each timeout, it just tries again and
> again.
Please try 251-5 and see if it helps.
Thanks,
Stephen
signature.asc
Description: Digital signature
* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> [pid 5186] connect(7, {sa_family=AF_INET,
> sin_port=htons(389), sin_addr=inet_addr("10.10.7.99")}, 16)
> = -1 ENETUNREACH (Network is unreachable)
>
> clearly means network is not setup properly to be able to
> reach LDAP server, since there's no mat
* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> Dne sobota 24 junij 2006 17:04 ste napisali:
> > Do you have a reasonably complete /etc/passwd and
> > /etc/shadow files for the local accounts?
>
> Yes, I am actually using local account for daily work.
>
> > Also, have you actually waited it out? Even
* Michael Biebl ([EMAIL PROTECTED]) wrote:
> Marco d'Itri wrote:
> > On Jun 24, Stephen Frost <[EMAIL PROTECTED]> wrote:
> >
> >> It's simply not possible for libnss-ldap to provide a correct answer
> >> before networking or the slapd daemon has
* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> My nsswitch.conf:
>
> passwd: compat ldap
> group: compat ldap
> shadow: compat ldap
>
> Other lines don't have ldap.
>
> I have no custom udev rules.
Do you have a reasonably complete /etc/passwd and /etc/shadow files for
the
* Gasper Zejn ([EMAIL PROTECTED]) wrote:
> After I installed libnss-ldap, udevd stalled at startup,
> waiting for libnss-ldap, which can't connect to a remote LDAP
> server, since networking is not yet set up at that time.
This is being discussed in #375077. libnss-ldap can be configured to
giv
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
> On Jun 24, maximilian attems <[EMAIL PROTECTED]> wrote:
>
> > > udev does not even know about LDAP, it just uses the libc interface.
> > > What do you think it should do?
> > > Possibly without horrible layering violations.
> > the errors happen when the
* Aurelien Jarno ([EMAIL PROTECTED]) wrote:
> The FHS is actually not very clear, as it says 64-bit libraries should
> be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib.
> This is a contradiction for a pure 64-bit system.
The FHS is very clear about the path to the 64bit linke
* Christian Perrier ([EMAIL PROTECTED]) wrote:
> Stephen, is there any chance that you could be able to reproduce this
> bug (Samba AD join failing (Memory fault))?
>
> I think that we can expect upstream to look at it only if it is
> reproduced with the last upstream version, namely 3.0.22 as in
Greetings,
It looks like now multipath is ignoring the prio_callout. This is
definitely very annoying considering 'multipath', at least, *used* to
work correctly with it.
===# multipath -v3 | grep prio
sda: getprio = /sbin/find_prio.sh %n (config file default)
sda: prio = 0
sdb: getprio =
Package: php-db
Version: 1.7.6-2
Severity: Important
Greetings,
DECLARE/FETCH doesn't work in PHP-DB because it is foolishly assumed
that only 'select', 'explain' and 'show' return records. This is
certainly not the case as 'fetch' (like, from a cursor) can also
return rows. The way to
Greetings,
Following up on the idea in the prior post, I've hacked up a script
which can go in /etc/mkinitramfs/scripts/local-top/ (called 'md',
attached) which will work without depending on the local mdadm.conf
file. This means the initrd image will work even if the mdadm.conf on
the
Package: mdadm
Version: 1.12.0-1
Severity: wishlist
Greetings,
Please find attached 'hook.md' and 'scripts.md'. These are scripts
which should be placed in the '/etc/mkinitramfs/hooks' and
'/etc/mkinitramfs/scripts/local-top' directories, respectively. These
will cause initrd images cre
Hey Martin,
* Martin Pitt ([EMAIL PROTECTED]) wrote:
> Stephen Frost [2006-02-06 20:52 -0500]:
> > Looks good. Is there any need to pass the username to use to connect to
> > the database as superuser? I'm guessing no but thought I might mention
> > it...
>
&
Hey Martin,
* Martin Pitt ([EMAIL PROTECTED]) wrote:
> Thanks for today's IRC discussion, I'll try to summarize and create a
> mini-spec:
Very nice, thanks. :)
> -- snip ---
> 1. Add and ship /etc/postgresql/pg_upgradecluster.d/. Scripts in that
> directory will be called with the foll
Package: postgresql-common
Version: 41
Severity: Wishlist
Greetings,
When using pg_upgradecluster to migrate from 8.0 to 8.1 I ran into some
problems. Mainly this was that I had PostGIS installed in the 8.0
database and had some tables with geometry columns which depended upon
PostGIS. When
Package: passwd
Version: 4.0.14-4
Severity: normal
Greetings,
Looks like something broke -o/--non-unique. useradd now refuses to
create a user with a duplicate uid even with -o or --non-unique are
supplied.
Thanks,
Stephen
signature.asc
Description: Digital sign
Package: postfix
Version: 2.2.8-6
Severity: important
Greetings,
The latest version of postfix assumes that it can create device nodes
(which it tries to do for /dev/random and /dev/urandom using tar). It
is not always the case that this is permitted in the environment in
which postfix i
* Luk Claes ([EMAIL PROTECTED]) wrote:
> Attached the patch for the version I intend to upload. Please respond if
> you don't want this NMU to happen, if you are working yourself on a
> patch or if you think that the attached patch won't work.
Geez, seems like we just did this. Oh well, looks alr
* Luk Claes ([EMAIL PROTECTED]) wrote:
> Yes, I did test it. Well, I think they are needed as they are used all
> over in the autotools.mk, the only way to get rid of them is to delete
> all DEB_AUTO_UPDATE lines, though I'm not sure if it would behave
> correctly...
We don't want to get rid of th
* Luk Claes ([EMAIL PROTECTED]) wrote:
> Attached the patch for the version I intend to upload. Please respond if
> you don't want this NMU to happen, if you are working yourself on a
> patch or if you think that the attached patch won't work.
I don't see any obvious reason why it won't work. I t
* Bastian Blank ([EMAIL PROTECTED]) wrote:
> > Is there some reason you can't have implement your personally preferred
> > policy of root.root 600 on just your own system? Is there some reason
> > for projecting your personal policies incompletely onto an arbitrary
> > subset of debian's users?
>
> > > > it's not their business to editorialize on the default setting.
[...]
> > If Tom could present an actual reason why it shouldn't be enabled, I'm sure
> > Martin (Pitt) would be interested. But Stephen Frost and Peter
> > Eisentraut as well as o
Greetings,
Kind of amusing that you decided to do this now, I've just recently
been working with Slony upstream to get things cleaned up so Debian
packages can be easily built from Slony. I've been working from CVS
but I've been told that the fixes will be back-patched into the stable
b
Package: tar
Version: 1.15.1-2
Severity: normal
Tags: patch
Greetings,
When creating a multivolume tar archive, if the file which ends up
being split across two tapes has a filename longer than 100
characters, tar exits with a fatal error.
Reading through this thread:
http://lists.gnu.
* Drew Scott Daniels ([EMAIL PROTECTED]) wrote:
> I'm just wondering if Majordomo/Majordomo2 would still be a useful
> package in Debian given that there's things like mailman, fml, ecartis
> and potentially other alternatives.
Erm, yes, of course it'd be a useful package to have in Debian.
* Russ Allbery ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I just compiled Debian's 4.1p1 ssh w/ Simon's latest gssapi-keyx
> > patch, and everything appears to have worked reasonably well, so,
> > please update the
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
> On Sep 20, Stephen Frost <[EMAIL PROTECTED]> wrote:
> > dpkg: error processing udev (--configure):
> >subprocess post-installation script returned error exit status 1
> Did you try to kill some process? I ca
Package: udev
Version: 0.070-2
Severity: Important
Greetings,
When installing udev for the first time on a system which has access
to snapshots of other partitions (on my SAN), and those snapshots were
disabled (which means IO failures when trying to read them), udev
failed to install rat
severity 327562 normal
done
hahahahhahaha
Enjoy,
Stephen
signature.asc
Description: Digital signature
Greetings,
I'd like to follow-up on the idea of maintaining the key exchange
patch as a local Debian patch to openssh. The current key exchange
patch does not introduce any new config options, is much smaller than
the older GSSAPI patches, and patches cleanly against current Debian
sour
Package: ssh-krb5
Version: 3.8.1p1-5
Severity: wishlist
Greetings,
I just compiled Debian's 4.1p1 ssh w/ Simon's latest gssapi-keyx
patch, and everything appears to have worked reasonably well, so,
please update the packages to the more recent versions...
Thanks,
S
Package: multipath-tools
Version: 0.4.2.4-2
Severity: normal
Greetings,
For some reason that I havn't been able to identify as yet, multipathd
appears to just outright ignore the prio_callout setting. Looking in
/var/cache/multipathd, it's empty, so perhaps that's the problem.
There's no
Package: multipath-tools
Version: 0.4.2.4-2
Severity: important
Greetings,
multipathd needs to be run prior to 'mountall.sh', which handles the
second-pass filesystem mounting. This means that it can't depend on
/var being available. Unfortunately, it appears that it's expecting
to be a
Package: multipath-tools
Version: 0.4.2.4-2
Severity: wishlist
Please upgrade to 0.4.4, it seems to have a number of improvements.
Thanks,
Stephen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: multipath-tools
Version: 0.4.2.4-2
Severity: important
Greetings,
multipathd is currently set up to run before modules are loaded. This
doesn't make much sense to me, and causes problems for any setup which
uses modules (and not initrd), which seems like it'd be a pretty
common
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) wrote:
> Can you please comment on the below?
The OpenMosix packages were intentionally kept out of sarge because
upstream's not terribly interested in the 2.4 patches and they're
working on a 2.6 version. The 2.6 version is expected to be somewhat
bett
* Christian Perrier ([EMAIL PROTECTED]) wrote:
>critical
> Questions that you really, really need to see (or else).
>
> Strictly speaking, the first password question pertains to the
> "critical" priority, because it does not have any reasonable default.
Well, actually, not
* Cyril Chaboisseau ([EMAIL PROTECTED]) wrote:
> when I try to build an html file with wml (which is just a Perl
> script), it segfaults
>
> $ cat 1.wml
> title
>
> $ wml -o 1.html 1.wml
> ** WML:Break: Error in Pass 2 (status=139, rc=0).
Just to note, this does *not* happen on i386, so far as
* Frank Lichtenheld ([EMAIL PROTECTED]) wrote:
> On Mon, Apr 25, 2005 at 10:00:33AM -0400, Stephen Frost wrote:
> > Just following up for those playing along at home. libnss-ldap and
> > libpam-ldap need to be linked against the same ldap (either 'ldap' or
> >
* Marco Amadori ([EMAIL PROTECTED]) wrote:
> Package: kernel-patch-openmosix
> Version: any
> Severity: wishlist
> Tags: fixed-upstream
>
> As announced here : http://sourceforge.net/forum/forum.php?forum_id=460497
> openMosix now supports 2.6 kernels.
>
> You can find the patches that should ap
Package: postgresql-common
Version: 7
Severity: Important
Tags: +experimental
Greetings,
Looks like if postgresql-common and postgresql-client-8.0 are
installed but postgresql-8.0 isn't then
/etc/postgresql-common/user_clusters never gets populated and you get
an 'Invalid PostgreSQL cluse
Greetings,
What's the status on the new upload? I need a working ulogd, like,
today, so if you're not uploading a new version very soon I'm gonna
have to build one myself. Do you have packages around anywhere yet
with the newer version?
Thanks,
Stephen
signatu
reassign 306258 libpam-ldap
retitle 306258 libpam-ldap needs to be linked against ldap_r
thanks
Greetings,
Just following up for those playing along at home. libnss-ldap and
libpam-ldap need to be linked against the same ldap (either 'ldap' or
'ldap_r'). I thought I had done this for both
* Tim Goodaire ([EMAIL PROTECTED]) wrote:
> I haven't been able to find an ITP for this. I've found an RFP for it
> though (278810). Is this what you're referring to?
Yes.
> Also, my ITP bug (305287) has already been closed on me. Apparently I
Yes, I closed it since it was a duplicate WNPP bug.
Package: postgresql-common
Version: 6
Severity: important
Tags: experimental
Greetings,
pg_ctlcluster has a rather serious flaw- it doesn't, and can't
apparently from perl (amazing as that is...) call initgroups(). This
means that if you want to have Postgres use PAM and pam_unix and
/et
1 - 100 of 124 matches
Mail list logo
