Thanks Houben, I appreciate your efforts!
Sam
Quoting Rens Houben (2020-12-22 16:07:00)
> Hello,
>
> I've come across the same bug while trying to set up a new service at work.
>
> After some digging (we've currently got a mishmash of Jessie and Buster
> system
= /var/uwsgi
Sam
Quoting Vlastimil Zima (2020-11-06 15:36:47)
> Package: uwsgi-emperor
> Version: 2.0.19.1-3+b1
> Followup-For: Bug #969372
>
> Hi Thomas,
>
> indeed, I have a number of vassals configured, actually I use emperor
> for web development for several years now.
Confirmed, this might render any mercurial server unusable in the
future.
signature.asc
Description: signature
So, I have now two machines where this bug happens, but on a third one
(my notebook) there seems to be no problem, despite all of them showing
6.8-1 as the installed version (via `dpkg --list | grep mercurial`).
Any recommendations how to make a differential-diagnosis between two
systems? I think
Follow up:
As a work-around, the following seems to get things to work again (not
tested in-depth though):
Change line /usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py:32
from
_deactivated = True
to
_deactivated = False
This allows at least to hg command to be calle
not clear that I'm reading the
right documents or that I'm reading them correctly, so if this bug is
clasified incorrectly, please accept my apologies!
Cheers & God bless
Sam "SammyTheSnake" Penny
[1]
http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
about getting copyright assignments so this can
probably be cleared up.
--Sam
To be clear I've contacted upstream off-list and we'll see what we find
in the next few days.
package needs a rebuild against the newer ruby2.3-
dev. I've uploaded a new version to mentors.debian.net and requested an
upload from my sponsor. In the meantime, a simple rebuild will fix this
on your own system.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69
Status is that I didn't find the time to get moonshot-trust-router dealt
with before buster and so I had deprioritized it.
There is in fact a new upstream, and it does fix the issue.
Blocking on moonshot-trust-router is silly: no one wants the version in
unstable anyway.
Is it possible to remove op
So what's happening here is that a k5_mutex_lock is getting an invalid
argument error calling a series of wrappers that basically all boil
down to pthread_mutex_lock.
So, basically somehow pthread_mutex_lock is getting passed a bad mutex.
This appears to be happening in the credentials cache cod
thenticate it.
So, my guess is that adapting that test to set up an autofs-ldap that
uses gss auth to ldap probably isn't too incredibly hard.
I don't know autofs at all, and for example I don't know how to set up
the directory to have the right info.
If you or the submitter can easily help, it would be appreciated.
If not, I'll look into it.
--Sam
I'd value the autofs configuration much more than the directory setup
instructions.
I have no desire to go install centos7 to debug a Debian bug:-) and have
some familiarity with setting up LDAP.
What I don't have is familiarity configuring autofs.
Package: xtables-addons-dkms
Version: 2.11-3
Severity: grave
Justification: renders package unusable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
DKMS make.log for xtables-addons-2.11 for kernel 4.9.0-1-amd64 (x86_64)
Mon 16 Jan 13:34:05 GMT 2017
make: Entering directory '/usr/src/linux-header
and dirty patch to rescan after login.
From 1392f5c0f1822e7c306ae6d9bdd3ede6f90b37c2 Mon Sep 17 00:00:00 2001
From: Sam Hartman
Date: Fri, 20 Jan 2017 17:24:05 -0500
Subject: [PATCH] Read certs again on token login
PKCS11_login destroys all certs and keys retrieved from the token. So
after logging
> "Andreas" == Andreas Beckmann writes:
Andreas> The fix should be easy: your package is using adduser or
Andreas> deluser from the adduser package, which is only priority
Andreas> important. Using useradd or userdel from the passwd package
Andreas> (priority required) should f
> "Theodore" == Theodore Ts'o writes:
the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.
Theodore> This isn't a problem with the kernel.
I don't think that was Adrian's point.
I thi
>>>>> "Theodore" == Theodore Ts'o writes:
Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>>
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if
> "Sebastian" == Sebastian Ramacher writes:
Sebastian> To better understand the impact of this change, I was
Sebastian> wondering which tools / image builders in the archive
Sebastian> would be affected by this change. I've cloned the bug to
Sebastian> vmdb2, but what about o
> "Adrian" == Adrian Bunk writes:
Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
>> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
>> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>> > > ... > > Reasons: > > ...
Replying off list, because I don't think it matters much for the RT
discussion.
> "Russ" == Russ Allbery writes:
Russ> Yes, I'm probably understating the difficulty of making this
Russ> change in practice inside image building software as it's
Russ> currently constructed.
R
> "Adrian" == Adrian Bunk writes:
Adrian> Below is my attempt to give an overview of the situation,
Adrian> feel free to amend/correct if anything is missing or wrong.
I believe your summary is correct and includes the issues I am aware of.
I believe I am following things enough tha
> "Theodore" == Theodore Ts'o writes:
Theodore> So enabling what may be convenient, but ultimately an
Theodore> anti-pattern is something that hopefully in the long-term
Theodore> Debian should be trying to *avoid*.
That's certainly true.
I am not entirely convinced that using c
control: tags -1 wontfix
> "bigon" == bigon writes:
bigon> It seems that your package libpam-modules-bin is shipping
bigon> files (.service, .socket or .timer) in
bigon> /usr/lib/systemd/system.
I think we're talking about pam_namespace.service.
I don't think dh_installsystemd
me.
Thanks for that.
If I've mischaracterized the severity of the potential harm above, let
me know.
I don't want a broken pam, but I also consider this kind of move
moderate risk.
--Sam
> "Bastian" == Bastian Germann writes:
Bastian> The main license does not have a GPL version. However,
Bastian> there are several files licensed under specific (L)GPL
Bastian> versions and also other licenses included. Debian Policy
Bastian> requires to document every contain
> "Moritz" == Moritz Mühlenhoff writes:
Moritz> Not moving to 6.1.x (which is most likely the next Linux
Moritz> kernel LTS) is by far a worse regression since it applies to
Moritz> every single Debian system.
Moritz> As a community distro without paid, full time kernel
Mo
en.
Again, feel free to ignore this message entirely if it does not move the
conversation forward.
I'm just seeing a stuck issue and proposing a way to try and unstick it.
--Sam
signature.asc
Description: PGP signature
eplacements you are
thinking of?
I'm also having a bit of trouble trying to understand how the various
hook directories work (power.d, sleep.d, etc). If I install pm-utils
and use another mechanism like say systemctl suspend to suspend my
system, do the pm-utils hooks get called or not?
--Sam
ed to
reload the config while dpkg was still writing it out?
sssd_pac crash: sssd_pac dies after about five minutes with the "The
last reference on a connection was dropped without closing the
connection. This is a bug in an application. [...] Most likely, the
application called unref() too many times and removed a reference
belonging to libdbus, since this is a shared connection." If this
persists after a reboot I'll file a separate bug for it.
--
Sam Morris
/intro-maintainers (read 1-2, start at 3)
>
>
Hi Michael, I don't understand this. Wouldn't it be easier if you
orhpaned the package since it's already in stable?
Thanks,
Sam.
FYI linked issue and summary of issue from upstream perspective:
https://github.com/rsnapshot/rsnapshot/issues/279#issuecomment-860001348
This is due to improper use of setuptools_scm in docs/conf.py. This is
fixed [1] in version 0.16.8, along with other build errors. Please
consider packaging the new version.
[1]
https://github.com/pimutils/vdirsyncer/commit/b1214cd693d7a6c6693da3d070e8b9965a84a88e
7be83fd6167f02ad256 Mon Sep 17 00:00:00 2001
From: Sam Hartman
Date: Wed, 24 Feb 2021 14:29:53 -0500
Subject: [PATCH] debian/libpam-modules.preinst|templates: pam_tally
deprecation
* Add a facility to detect enabled profiles that contain a particular module
* If a profile contains an enabl
In adapting your first patch, I narrowed things down a bit.
I search /etc/pam.d files containing only a-z0-9A-Z, which I believe
should catch all the active pam.d files but not editor backups, .pam-new
files and the like.
I also specifically recommend looking at pam_faillock.
--Sam
> "Martin" == Martin Schurz writes:
Martin> I have added pam_tally to common-auth and the upgrade did
Martin> not stop when installing the new libpam-modules. I believe
Martin> the regex is missing these files, since it does not contain
Martin> a "-" in the permitted character
control: tags -1 confirmed
I haven't explicitly reproduced this, but based on the description I am
confident this is an issue.
What happened is that upstream dropped an internal symbol
krb5int_c_combine_keys that is used by the old library.
So once libk5crypto3 is upgraded, libkrb5-3 breaks.
In
Package: podman
Version: 3.0.0~rc2+dfsg1-2+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s...@robots.org.uk
After upgrading to podman 3, I can't run any containers any more.
$ podman run --rm -it docker.io/library/debian:10
Error: failed to connect to container
Package: src:freeipa
Followup-For: Bug #970230
Control: tag -1 + patch
This should let freeipa build on armel again:
$ diff -u debian/rules.old debian/rules
--- debian/rules.old2020-11-11 13:26:32.112603329 +
+++ debian/rules2020-11-11 13:26:37.020620794 +
@@ -99,7 +99,7 @@
control: reassign -1 libapache2-mod-auth-kerb
control: found -1 libapache2-mod-auth-kerb/5.4-2.4
control: retitle -1 FTBFS with krb5 1.18: significant use of internal
APIs and data structures
control: affects -1 libkrb5-3
Hi.
Kerberos 5 1.18 significantly refactors the replay cache implementatio
control: tags -1 patch
Here's a patch that I believe will get libapache-mod-auth-kerb working
with the latest krb5. I'll go upload a krb5 that fixes the breaks
relationship.
I'd appreciate it if someone who actually uses libapache-mod-auth-kerb
will test this patch.
If it gets tested, I'll NMU.
control: tags -1 pending
I've uploaded to delayed/3, using your minimal patch.
Thanks.
--Sam
package: libapache-mod-auth-kerb
severity: serious
version: 5.4-2.4
tags: security
justification: unmaintained with security weaknesses
Hi. As part of a recent krb5 transition, I took a look at
libapache-mod-auth-kerb.
As part of that transition, libapache-mod-auth-kerb was removed from
testing.
aving to deal with one README is going
to even make the headache list.
You said that you're running into dpkg issues.
I'm sympathetic to that, but I'd like to find a way that your needs and
mine can both be met.
--Sam
control: severity -1 normal
Will remove this file early in buster.
Package: mariadb-server-10.1
Version: 10.1.22-3
Severity: grave
Tags: newcomer upstream
Justification: causes non-serious data loss
Dear Maintainer,
A critical MySQL bug was discovered in InnoDB storage engine (related to
statistics calculation) some weeks ago.
This bug affects MariaDB 10.1 as
There was a trust router release in October.
At one level, this release is probably functional enough that it would
be nice to have included in stretch.
At another level,there have been enough upstream bugs files that I
don't think it's stable enough to include and support for the lifetime
of
. Hopefully by the
end of the year.
-- Sam
On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello wrote:
> Source: maradns
> Severity: grave
> Version: 2.0.13-1.2
> Tags: security upstream
>
> Hi,
>
> The following vulnerability was published for MaraDNS:
> http://seclists.org
Github bug: https://github.com/samboy/MaraDNS/issues/33
Please go here to get the latest updates from upstream about this issue.
On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme wrote:
> Hello there,
>
> I have just become aware of this bug. Right now, I can reproduce the crash
> in C
ee there is probably a bug in MaraDNS -- but I
will not treat this as an "all hands on deck" packet-of-death level
security bug until we can send an actual packet of death over UDP to kill
MaraDNS.
On Sat, Dec 3, 2016 at 6:04 AM, Sam Trenholme wrote:
> Github bug: https://gi
CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.
Here’s the deal: The reporter had to patch MaraDNS before he was able
to crash her.
The patch, however, treats MaraDNS’ special buffer-overflow-resistant
“js_string” as if it were an ordinary string — but it’s not. Here’
of death” back then if there was one.
— Sam
On Mon, Dec 5, 2016 at 5:27 AM, Ondřej Surý wrote:
> Sam and others,
>
> I most deeply apologize, you are right in your assessment.
>
> I somehow missed the extra four additional sanity checks at the
> beginning of the getudp() func
he
package in case some series issue comes up. According to http://ismsnde
adyet.com/ service is 'mostly' dead: the MSNP11 protocol, which PyMSNt
uses, no longer works. I will request that the package be removed.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A
Take a look at the stretch branch of
git://git.debian.org/git/pkg-k5-afs/debian-krb5-2013.git
Shall I upload that to stable-security?
Actually, on that note, why does this bug merit a DSA?
It like the other bugs is a simple KDC crash from an authenticated
attacker.
It seems like it should be handled the same.
I can absolutely prepare a stable point update request for stretch.
Is there still going to be a last point release to jessie?
If so I'll look into that too; I'd definitely like to get an update in.
If your upload goes in tomorrow, it will superceed mine which will never
get processed.
If you miss a day, yours will still replace mine.
Interestingly I have a similar problem on CentOS 7 when trying to
compile kpatch for kernel 4.9:
```
~/git/kpatch # uname -aLinux nas 4.9.0-1.el7.elrepo.x86_64 #1 SMP Sun
Dec 11 15:43:54 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
~/git/kpatch # make
make -C kpatch-build
make[1]: Entering dire
Thanks!!! This fix worked for me on the Google Cloud Debian spin, which uses
jessie-backports.
On Sun, 5 Feb 2017 00:57:35 -0500 Darrin Swanson
wrote:
I was able to fix this issue with the information from the following link:
http://unix.stackexchange.com/questions/342403/openjdk-8-jre-headl
> "Sebastian" == Sebastian Andrzej Siewior writes:
Sebastian> control: tags -1 patch
Sebastian> On 2016-06-26 12:23:04 [+0200], Kurt Roeckx wrote:
>> OpenSSL 1.1.0 is about to released. During a rebuild of all
>> packages using OpenSSL this package fail to build. A log of th
> "Petter" == Petter Reinholdtsen writes:
>> I think shortly after the release of buster, we can close this
>> bug and let moonshot-trust-router migrate into testing.
Petter> Did this time arrive?
Mostly.
I'm working through all the moonshot software and updating it to new
upstr
Package: gkeyring
Version: 0.4-1-gf4ce4c7-1
Severity: serious
Justification: Policy 7.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The package appears to be missing a dependency on python-gnomekeyring.
- -- System Information:
Debian Release: stretch/sid
APT prefers testing-debug
APT po
penssl
1.0.
--Sam
Package: openssh-server
Severity: serious
Justification: Policy 8.2
Dear Maintainer,
Due to a change in how some options are handled in sshd_config, upgrading to
buster can result in the user getting locked out of their system if the config
is not updated.
Probably the most likely cause (and w
Package: openssh-server
Severity: serious
Justification: Policy 8.2
Dear Maintainer,
Due to a change in how some options are handled in sshd_config, upgrading to
buster can result in the user getting locked out of their system if the config
is not updated.
Probably the most likely cause (and wha
rd and get the patch uploaded or let someone else do so.
Thanks for all your hard work,
--Sam
Guido let me know if you need any help or prod me on IRC if I'm needed.
Will certainly test the result, but if you get stuck would be happy to
spend time on this.
>>>>> "Guido" == Guido Günther writes:
Guido> Hi,
Guido> On Mon, Apr 15, 2019 at 02:38:27PM -0400, Sam Hartman wrote:
>> control: severity -1 serious
>>
>> justification: libvirtd upgrades from stretch to buster break
>
When I marked the bug RC, I thought it was happening all the time; I
then went to reproduce yet again in a controlled environment to be more
in a position to test a fix.
That's when I discovered things are more complex.
Obviously if this is a fringe situation, then it shouldn't be RC.
control: severity -1 normal
Hi. I ran a number of other upgrades today of libvirtd from stretch to
buster and was not able to reproduce the problem in the environments I
thought would cause it.
I don't know what's up, but I don't think characterizing this as RC
given the data we have is correct.
master accept a request
to remove the package?
--Sam
signature.asc
Description: PGP signature
4ff..c30a279 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+electrum (3.2.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * On startup print a warning that this version in insecure and then
+exit, Closes: #928518
+
+
+ -- Sam Hartman Mon, 06 May 2019
control: reassign -1 libpam-yubico
control: severity -1 grave
control: retitle -1 pam_yubico fails to install module in multiarch path
control: found -1 2.23-1
> "Rowan" == Rowan Wookey writes:
Rowan> It appears that in Bullseye pam isn't checking /lib/security.
> "Rowan" == Rowan Wookey writes:
Rowan> Fair enough, I couldn't find any docs on the policy of
Rowan> /lib/security or any news on it not being scanned in
Rowan> Bullseye, is there something about that somewhere?
I don't know.
I had mostly been not paying attention to PAM but it
> "Hideki" == Hideki Yamane writes:
control: tags -1 -patch -pending
I NACK this proposed NMU.
This many years after multiarch, I think it is entirely reasonable for
PAM to drop support for non-multiarch paths at the transition between
buster and bullseye.
As I said earlier in the bug, I'm h
> "Hideki" == Hideki Yamane writes:
>> I think Steve is quite familiar with multiarch and while he
>> hasn't commented yet I'm assuming he dropped those patch lines as
>> part of removing unnecessary upstream deltas.
Hideki> I want his comment, too.
Okay, let's hold off unti
> "Steve" == Steve Langasek writes:
Steve> For the record, I did not intentionally drop those lines,
Steve> this was a matter of a mis-merge.
Okay, if it was a miss-merge, let's see if we can fix.
I'm reasonably busy this morning but will try to prepare something later
today based on
control: clone -1 -2
control: retitle -2 mis-merge in patches prevents reading /lib/security
control: reassign -2 pam
control: found -2 1.4.0-1
control: severity -2 important
control: severity -1 serious
Steve said that it was not an intentional change to prevent finding pam
modules in /lib/securi
ttered throughout the day ions, but it sounded
like Benjamin Kaduk
might be available to help.
If not, I'll have some time and be back to general availability by
Sunday.
--Sam
package: libxcrypt
version: 1:4.4.22-1
severity: serious
justification: breaks login
See bug #992848.
Because of the way libpam0g calls libxcrypt any existing sha256 hash
will be rejected at login as expired.
I'm going to fix this in pam using the linux-pam upstream fix, but
libxcrypt should not m
Package: debspawn
Version: 0.5.0-1
Severity: serious
Justification: Significant data loss
I used debspawn interact to interactively explore what I needed to do to get a
new upstream package building.
To make that easier, I mounted my source trees and debian working environment
in the container.
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
Johannes> Hi,
Johannes> our CI runs for the DPKG_ROOT tests failed today because
Johannes> pam FTBFS. I rebuilt pam locally in a fresh sbuild chroot
Johannes> without any modifications and arrived at the same build
.
Up to date information on MaraDNS’s security is available at
https://maradns.samiam.org/security.html
On Sat, Nov 2, 2019 at 6:54 AM Sam Trenholme wrote:
> Upstream here: Please close this bug.
>
> One can close this bug by removing the Python2 dependency.
>
> MaraDNS does not
nderstand that it's frustrating to have had this discussion
with systemd maintainers and then turn around and need to have it with a
release team member.
And I did try to read the systemd discussions. If you had clearly
articulated in that discussion why you needed c/r/p libsystemd0 at a
level deeper than "because it doesn't work the other way," then I'd be
pushing back on Julien harder.
--Sam
> "Mark" == Mark Hindley writes:
>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system? One
>> of the concerns is what happens if apt deci
s and
take a look at what is #if 0'd you can see the naming differences.
I don't know what would happen if you built a elogind that used systemd
naming. I don't know what the next hurtle would be.
--Sam
>>>>> "Mark" == Mark Hindley writes:
Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0. I'm running
>> unstable or testing. The latest libsystemd0 isn't building on m
> "Thorsten" == Thorsten Glaser writes:
Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote:
>> libelogind0 can be coninstalled with libsystemd0. However, it is
>> fragile because the file that needs to be diverted out of the way
>> is libsystemd.so.0.26.0 (the actual library fi
>>>>> "Mark" == Mark Hindley writes:
Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.
I'd like to push back on the phrasing here.
What i'm hear
> "Michael" == Michael Biebl writes:
Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael> wrote:
>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing t
Santiago,
That is correct. Changing 'VERSION_ID=10' to 'VERSION_ID=10.1' in
/etc/os-release is what I am asking.
---
Respectfully,
Sam Doran
> On Nov 8, 2019, at 06:16, Santiago Vila wrote:
>
> Hi.
>
> Just to be sure: The proposed change would be
Acknowledged.
DPL is taking up all my Debian time at the moment.
It's not the end of the world if moonshot-trust-router falls out of
testing, but hopefully I'll get to this before it happens.
It's almost certainly simple.
control: tags -1 patch
> "peter" == peter green writes:
peter> Tags 944714 +patch Thanks.
peter> The easy fix here is to remove -Werror, in the long term of
peter> course migration to a non-deprecated type should be
peter> considered but that is IMO an issue for upstream not
control: tags -1 moreinfo
control: severity -1 normal
Hi. Your bug is a little short on details, and I was not able to
reproduce. I took a new sid chroot, added i386 as an architecture, and
installed libkrb5support0:i386 by
apt install libkrb5support0:i386
I ended up with krb5 1.16.1-1 and lib
ocket, because that is an arch
+all package with no ABI dependencies. We don't want shared library
+dependencies on an arch all package because it breaks the ability to
+do binary NMUs for library transitions, Closes: #877469
+
+ -- Sam Hartman Tue, 11 Dec 2018 08:50:44 -05
Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
for Debian weekend tasks.
>>>>> "Sebastian" == Sebastian Andrzej Siewior writes:
Sebastian> On 2018-12-11 18:26:24 [-0500], Sam Hartman wrote:
>> Fixing moonshot-gss-eap and getting a new moonshot-ui is next up
>> for me for Debian weekend tasks.
Sebastian> This
I'm working on porting moonshot-ui from gnome-keyring to libsecret.
It's somewhat involved because upstream needs to support both
interfaces--they have a long tail of operating systems they need to work
on. Also, the existing code could use some refactoring to be cleaner.
I'm probably 70% of th
Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the
removal requests.
They are both basically broken in unstable, so there's no reason to
block.
Built fine I have not yet tested against moonshot
On December 3, 2018 8:52:10 AM EST, "Cantor, Scott" wrote:
>On 12/1/18, 4:48 AM, "Pkg-shibboleth-devel on behalf of wf...@niif.hu"
>on behalf of wf...@niif.hu> wrote:
>
>> Please let me know if you need any help; for example I can see that
>> vers
1 - 100 of 922 matches
Mail list logo
