code should
tell a story to someone who is reading it and invite understanding. (I've
probably read too much Knuth, although I don't think Knuth's method of
doing this worked.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email
documentation for systemd seems quite good. This is more the code-level,
helping the programmer sort of documentation, which is a bit lower-level.
Both upstart and systemd seem to have excellent manuals and high-level
design and interface documentation.
--
Russ Allbery (r...@debian.org)
le of a nicely-written
and readable code base, although that's partly because much of it is
written the way I would have written that code.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.deb
ist **list);
^
In file included from /usr/include/mit-krb5/kadm5/admin.h:49:0,
from ./portable/kadmin.h:27,
from tests/tap/kadmin.c:36:
/usr/include/mit-krb5/kadm5/kadm_err.h:71:13: note: previous declaration of
‘initialize_ovk_error_table_r’ was here
extern voi
; Not yet reassigning to allow a sanity check on my conclusions :)
Your patch looks correct to me. It looks like this Autoconf probe was
relying on those functions being implemented as macros? I'm not sure how
the probe program could otherwise be successfully linked without including
the lin
nk with the Perl flags, not just
compile, or to define that macro in probes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
, but the general discussion and
intent looks right to me. Thank you for drafting this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
menus for other applications that don't inherently
support the XDG menu system.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ian Jackson writes:
> As agreed on IRC, I hereby call for votes on the rsolution below.
> There options are:
> A libjpeg-turbo to become default libjpeg implementaton (1:1)
> B libjpeg8/9 to remain default libjpeg implementaton (1:1)
> FD
I vote A, B, FD.
--
Ian Jackson writes:
> As discussed at the meeting, I hereby call for votes on this
> resolution (text below).
> There are two options
>Y Issue statement about (multiple) init system support
>FD
I vote Y, FD.
--
Russ Allbery (r...@debian.org) <ht
27;t think this
is important for your package, or if you're just not interested in working
on it, you can ignore it, but you do need to merge patches if someone else
wants to work on it." That would probably be useful.
--
Russ Allbery (r...@debian.org) <http:
on of Policy that way. I do think that
is intended to say that the package maintainer should write one, and
that's the most common interpretation that I've seen in debian-mentors as
well. They're not *required*, no, but that's true of any should.
--
Russ Allbery (r...
art of the reason why this bug was raised in Policy in the
first place is that none of them have actually happened, and that didn't
seem that likely to change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-
case, BTW. In that case,
Policy says that it is "recommended practice," which policy defines as
equivalent to "should." If anything, doc-base is probably less used by
end users than the traditional menu. (Personally, I think man pages are
more important than either, but man page
Ian Jackson writes:
> Russ Allbery writes ("Bug#741573: Two menu systems"):
>> I do think that "should" in Policy is stronger than that, and I don't
>> think just weakening "should" for all of Policy is the right solution
>> to this bug.
f those things too, and over time
I try to implement All The Things in my packages. But I also really
*enjoy* that sort of exacting attention to detail, and while that's a nice
quality for us to encourage, it's not clear to me that we want to make
that the bar to entry. And that&#
once we have that guidance, but I don't think
this is the place to decide how to do that or what the implications are
for all the other "should" statements in Policy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ave happened in the past, they've released an "end of life" security
advisory to notify Debian stable users that a given package will not
receive security support and should be considered insecure.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.or
Jonathan Nieder writes:
> Russ Allbery wrote:
>> So, I think the questions before the TC are:
>>
>> 1. Should programs that make sense in the context of a typical DE (I
>>realize there's some fuzziness around this) all have desktop files?
> Ah, I compl
ll then have to add the dh-autoreconf
build dependency when they update the debhelper compat level, and then the
rest of the machinery will be taken care of by the helpers if they're
used.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBS
onfig script to the
*-multidev package. It's been very nice for Heimdal to do that, since it
means I can test builds against both MIT and Heimdal very easily on the
same system without switching packages around. (Most things currently use
krb5-config since the *.pc files have only recently become us
com_err in Libs given that
krb5_get_error_message is a thing that's existed for years. The Heimdal
ones currently put everything in Libs, which makes them much less useful.
Jelmer, let me know if you'd like me to file a bug about that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.o
Package: heimdal-multidev
Version: 1.6~rc2+dfsg-2
Severity: normal
The convention for pkgconfig files is to list the libraries required
for dynamic linking to get the public ABI in Libs and the other
libraries requied for static linking in Libs.private. This prevents
over-linking binaries on syst
move their Requires to
Requires.private.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
sting with that information, but we have no
guarantee of that.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
change is enabled,
since in that case the lack of keys may be an intentional configuration
choice by the server administrator to force the use of Kerberos keys
instead of system-generated public keys.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUB
Package: xml2rfc
Version: 2.4.3-1
Severity: serious
Since python-lxml was upgraded to 3.3.1-1, xml2rfc no longer works.
It fails with the following backtrace:
Traceback (most recent call last):
File "/usr/bin/xml2rfc", line 225, in
main()
File "/usr/bin/xml2rfc", line 139, in main
xm
and tactical cases in the voting system,
but maybe it doesn't if we fix the FD dropping issue that we specifically
ran into.
An alternative would be to have an explicit cloture vote in the case of a
dispute over adding more options to a ballot, or some other similar level
of indirection such
to motivate
anyone to volunteer to do it, and therefore we'll have to live without the
benefits of having them.
If that feels like an unacceptable outcome, well, I think the right
reaction is to go do the work so that this outcome doesn't arise. Not to
try to write project rules to for
eason that I'm missing, but it may be best to respond there instead to
make it easier for those following the proposed GR discussion to see.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.d
Thorsten Glaser writes:
> Russ Allbery dixit:
>> But when providing project-wide guidance, we have an obligation to
>> worry about the error conditions as well. If multiple logind
>> implementations do *not* materialize, or if they do materialize but
>> then people
how
to properly split the packages up. I know that shibd can be run on a
separate host from the Apache module, but this isn't currently supported
by the package breakdown. Maybe this is a similar sort of case?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle
"Cantor, Scott" writes:
> On 3/3/14, 4:27 PM, "Russ Allbery" wrote:
>> Could you explain a bit more about what the use case is? I think I
>> understand, but I'm not sure. You're using libshibsp5, and you want
>> the standard configuration
ables in comments, which is perhaps dangerous.
Thanks, Ben!
Sam should weigh in if he feels differently, but as far as I'm concerned,
you should feel free to start fixing issues in the Git repository. I'm
happy to review and sponsor uploads of the package for you. I haven't had
a
install that way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
f time on, and generally not worth patching
upstream source to support.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
, so per Lintian's
normal design philosophy, we should only take those into account if they
don't stand in the way of detecting bugs in Debian. This clearly would
detect bugs in Debian. Also, now that reprepro is more widespread and
doesn't require this sort of workaround for not havin
install or provide desktop files, find that their
program appears in the menus, assume they're done, and move on, and the
menu quality in other integrations like fvwm will keep declining. I
believe this has been happening for the past couple of years, although
that's based on a gut feeling a
ers and the toolchain is
> updated. >>
> As far as I understand, the current practice for handling them is to
> move them to /usr/include// and the C preprocessor will look at
> this directory.
That's correct.
> Probably policy should say something about
the desktop file specification, but that's a
very vague impression. I'd be curious to hear the opinion of the desktop
environment maintainers on what we should tell maintainers of packages
like fvwm who want to integrate with desktop entries.
--
Russ Allbery (r...@debian.org)
ly
arbitrary code reformatting).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
tems and have upgrades of base-passwd not revert that change, so
I at least now have a mechanism to avoid audit problems that isn't as
annoying as it was previously. So I can cope with that.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
y can be fully usable at a time in practice, since
everything will force upgrading the plugins, and then the old version
won't work because it won't have plugins.
However, for the time being, the Apache module and shibd are probably the
only real users, so in practice this will generally
Sam Hartman writes:
>>>>>> "Russ" == Russ Allbery writes:
> Russ> This is what I did for now. I created a libshibsp-plugins
> Russ> package and a shibboleth-sp2-utils package and made the
> Russ> dependencies from libapache2-mod-shib2
st certainly don't want
to do. Coinstallability is a harder problem for Perl modules. (I'm
actually working on writing a brand new Perl module for Kerberos bindings
in part to be able to address this issue upstream.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.o
. See the first few paragraphs of
the ssh_config man page.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
UID)
That host block doesn't match that ssh command. Try changing it to:
Host foo foo.mydomain.com
and see if you get different behavior.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@li
h" to get past the two parsing
> runs, then "print options.gss_deleg_creds" - it comes out correctly
> depending on "Host" stanzas in ~/.ssh/config).
I use GSS-API daily and can confirm that it works as intended.
--
Russ Allbery (r...@debian.org) <h
Don Armstrong writes:
> On Tue, 18 Mar 2014, Russ Allbery wrote:
>> I looked into this further. The problem is that Perl::Tidy now always
>> attempts to create a log file in the current directory unless told to
>> create it elsewhere with the logfile parameter to its c
#x27;ll change that to build against 2.0 and 2.1 and upload without any
changes to the tests and see if the buildds are still happy. If so, I
think the FTBFS is spurious.
I've been monitoring the progress on the Ruby migration and thought I had
a bit of grace period before that became urgent, a
Christian Hofstaedtler writes:
> * Russ Allbery [140409 02:46]:
>> Hm. Those are timing-sensitive tests that can fail on extremely slow
>> systems, but I did have them tweaked so that they pass on all of Debian's
>> buildds.
> Actually this should be quite
_ruby --install in the override_dh_install rule. But
then everything worked great.
I also added the XB-Ruby-Versions header, since that seems to be best
practice these days (although I didn't manage to find it in the Ruby
packaging policy).
Now uploaded, with ruby-remctl built against 2.0 and 2
Source: krb5
Version: 1.12.1+dfsg-1
Severity: serious
When the documentation is built, 1.12.1+dfsg-1 fails to build with the
following error:
cd build/doc && make substhtml substpdf
make[1]: Entering directory '/«BUILDDIR»/krb5-1.12.1+dfsg/build/doc'
sed -e 's|@SRC@|../../src|g' \
-e 's|@DOC@
meant that dpkg-buildpackage fell back on
debian/rules build but didn't install B-D-I.
That said, adding python to B-D-I is still correct since the build uses
Python directly, not only via something provided by python-lxml.
--
Russ Allbery (r...@debian.org) <http://www.eyr
hy the maintainer felt that way about
the upstart changes?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
it.
> I guess it should be the same in all the initial login pam services.
I think so, yes.
Thanks for looking at this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
tick with it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
y formal statement. There are many, many, many things in
Debian about which the TC has not made any formal statement (deliberately,
and for the best).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.
rd, and am sorry that I've not been able to
drive that work. I had intended to be well into it by now.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Source: libduo-dev
Version: 1.9.6-1
Severity: minor
Description-en: Duo Security development libraries and header files
This package provides the develpment libraries and header files needed to
link against the Due Security library functions. Also includes the manpages
for library functions.
T
.
Let me know if I can assist with an NMU.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
eric
ties. It's used to select a winning option from the Schwartz set. Given
how Condorcet works, I don't believe there is a way to ensure the Schwartz
set always has only one member by manipulating the number of voters.
--
Russ Allbery (r...@debian.org) <http://ww
Package: libtest-strict-perl
Version: 0.23-1
Severity: normal
Test::Strict returns false positives for code that uses:
use 5.012;
or a later version. Per the Perl documentation:
"use VERSION" also enables all features available in the
requested version as defined by the "fe
y it's hard for your annotated compiler to figure this
out, but in this case this appears to be a false positive.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
t said, Policy could probably stand to provide more guidance on how to
interpret the results of dpkg-architecture -L and how they map to wildcard
strings.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ.
Package: firebird2.5-server-common
Version: 2.5.2.26540.ds4-12
Severity: normal
There's a fairly complicated set of package relationships here, so
bear with me.
The root bug that I'm reporting is that I just upgraded libreoffice
on a Debian jessie system and ended up with a new "firebird" system
es stuff
like this happens on a transient basis. If someone notices, they can just
delete the user, and no harm done. It's hardly the only system user that
gets created on a typical desktop system.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ependent) must depend on the expansion of
> perlapi-$Config{debian_abi} using
> the Config module. If $Config{debian_abi}
> is empty or not set, $Config{version} must be used.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle
+ expansion of perlapi-$Config{debian_abi} using
> the Config module. If $Config{debian_abi}
> is empty or not set, $Config{version} must be used.
>
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
e alternatives make sense for that.
It would be really nice to be able to co-install the basic clients,
though, which makes me think that the more administrator-oriented tools
(kadmin and ktutil) might make sense to split off into a separate package
that continues to conflict.
--
Benjamin Kaduk writes:
> On Sun, 1 Jun 2014, Russ Allbery wrote:
>> The ktutil is quite different, yes. (It would be nice if the MIT
>> version would support the Heimdal command-line interface, since it's
>> far more useful than the MIT version is.)
> If you wa
for all keytab management. I'm not sure how common that sort of
scenario is, though.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscr
ng to have alternatives available
for this so that I can coinstall both MIT and Heimdal clients, or
otherwise have some way of installing Heimdal kadmin (and preferrably
ktutil, which is much more useful than the MIT utility) while installing
the other MIT command-line utilities.
--
Russ Allb
ler flags or otherwise make -Wundef warnings not a fatal error.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
by the
standard, you'll probably get pushback against making it a rule.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ects consensus (or can solicit
> more input if they think it needs it).
I second this as well, although I think it's unnecessary at this point.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
t if they think it needs it).
> I didn't realise you can second your own proposal, but I'm happy to
> second my proposal in that case, so seconded too.
Yeah, we require three seconds, but the proposer can second. I usually
count the proposal as an implicit second if it'
ubious of your desire for all of this to be Lintian
warnings, since I don't think that matches Lintian's current criteria for
warnings, but I do think that the severity of the missing man page Lintian
warning may be a little overstated at the moment. I have no idea how one
would g
uble,
though.
> FWIW, I think policy should be distinguishing whether its
> recommendations are requirements for distribution (legal issues,
> dependency errors), proper practice (ie, it's a bug if you don't do
> this), or just a good idea to consider (a suggestion from experienced
> developers/packagers), but beyond that should just be documenting how
> to make optimal packages assuming infinite time and motivation.
That seems to roughly correspond to my categories above.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
just making that up? If not, then the source package and
library could go into main and just the nvidia-settings binary package
into contrib.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debi
much harder to use the code in any meaningful
way, but CSS doesn't have that sort of abstraction. At most you're losing
comments that may or may not have ever existed in the first place (most
likely not; most CSS I see in the wild has no comments anyway).
--
Russ Allbery (r...
Paul Wise writes:
> On Wed, 2014-05-14 at 21:44 -0700, Russ Allbery wrote:
>> Why?
> In addition, CSS minifiers can do a lot more than just removing
> whitespace and comments:
> https://yui.github.io/yuicompressor/css.html
None of those transforms other than remo
an opening brace, leading to the "}}" after foo closing the
brace of the function from Emacs's perspective.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Control: reassign -1 emacs24
Still applies to emacs24, except that the canonical documentation is in
emacs24-common now and the README.Debian is in (at least) the emacs24
package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, em
Package: puppet-module-puppetlabs-firewall
Version: 1.0.2-1
Severity: grave
With version 1.0.1 of iptables-persistent, this module fails with
the error:
Error: /Stage[main]/Firewall::Linux::Debian/Service[iptables-persistent]: Could
not evaluate: Could not find init script for 'iptables-persiste
e full one (5.18.2), even though policy has said otherwise.
> Proposed patch attached to make policy describe current practice.
Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
wit
n't moved accordingly.
> Proposed patch attached.
Seconded.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
effect on other packages: the
> site directories in /usr/local are in the realm of the local
> administrator, and I can't think of anything outside the perl source
> package that should need to use the core path.
Looks good to me. Seconded.
--
Russ Allbery (r...@debian.o
Bill Allombert writes:
> OK, this is a first attempt (with 25 line of context).
Seconded.
We should eventually have a whole multiarch section that describes *when*
one should do this, but this change is clearly correct in isolation.
--
Russ Allbery (r...@debian.org) &l
Bill Allombert writes:
> On Sun, Nov 15, 2009 at 06:00:13PM -0800, Russ Allbery wrote:
>> This is the case that we're talking about here. In other words,
>> *entirely* static binaries. What you get with gcc -static.
> Thus I propose the attached patch.
> (I used
flict between Bill and myself, so I don't think it's appropriate
for me to vote.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
"Cantor, Scott" writes:
> On 3/3/14, 4:56 PM, "Russ Allbery" wrote:
>> I am a little worried about downgrading the shibd dependency in
>> libapache2-mod-shib2 to recommends; maybe it should stay as depends for
>> now even though it's possible to run
Russ Allbery writes:
> shibboleth-sp2-common (new package)
> /etc/shibboleth
Oh, and also, I could move the contents of shibboleth-sp2-schemas into
this package as well, but it would require a transitional package to
handle the upgrades. I'm not sure it's worth it, but if
"Cantor, Scott" writes:
> On 3/16/14, 5:48 PM, "Russ Allbery" wrote:
>> libshibsp6 would depend on shibboleth-sp2-common. libapache2-mod-shib2
>> would depend on shibboleth-sp2-utils. Every other package would retain
>> its current contents and depe
"Cantor, Scott" writes:
> On 3/16/14, 10:31 PM, "Russ Allbery" wrote:
>> Hm, okay, in that case I'm inclined to change the -common package to
>> -runtime (which is a more typical convention for arch-dependent
>> supporting files for libraries), pu
hat the
library knew where to load them from, of course. It's not immediately
obvious to me how, although I'm guessing it's related to SHIBSP_LIBDIR.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-
ator r =
m_regex.begin(); r != m_regex.end(); ++r) {
^
handler/impl/TransformSessionInitiator.cpp:257:106: error: expected ';' before
')' token
for (vector< tuple >::const_iterator r =
m_regex.begin(); r != m_regex.end(); ++r) {
Michael Fladischer writes:
> On 2014-03-17 05:35, Russ Allbery wrote:
>> It seems a little weird that a shared library would force all programs
>> that want to use it to have to build in a particular standardization
>> mode. Are you sure that's the right path f
That's what I do personally. (If you're using a csh shell variant, you'll
need to put "env" in front of the setting.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: apache2
Version: 2.4.7-1
Severity: wishlist
In a discussion of the (very nice) Debian Apache configuration handling,
someone I was talking about this with mentioned that she had trouble
figuring out what the commands did because she was trying a2ensite -h.
Problem resolved with a pointer
901 - 1000 of 6091 matches
Mail list logo
