regards
Philipp Kern
[1]
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-guidelinesdiff -Nru python-gbulb-0.5.3/CHANGELOG.md python-gbulb-0.6.1/CHANGELOG.md
--- python-gbulb-0.5.3/CHANGELOG.md 2017-02-22 12:07:07.0 +0100
+++ python-gbulb-0.6.1/CHANGELOG.md 2018-08-10
On 10.09.2018 09:20, Philipp Kern wrote:
> [+mirrors@]
>
> On 07.09.2018 14:42, Julien Cristau wrote:
>> Control: retitle -1 choose-mirror: hide mirror selection by default
>>
>> On 09/04/2018 11:07 AM, Julien Cristau wrote:
>>> If switching the mirror question
ence the different ABI version. And it'd really help us if the ABI
version were to be bumped with every upload.)
Kind regards and thanks
Philipp Kern
ions by default.
What's mirroradm's take on this?
Kind regards and thanks
Philipp Kern
e correct way would be to fetch the PAC and execute it to
determine the proxy for the host. Of course that'd require interpreting
Javascript.
Kind regards
Philipp Kern
ensible escalation points to solve
problems for the users and the bandwidth to do so. That concern is
especially grave if we're going to auto-hide the question by default.
Defaulting is something that makes sense to me.
Kind regards
Philipp Kern
[0] https://rt.debian.org/Ticket/Display.html?id=710
he same time we then need to attenuate our feedback.
Anticipating the consequences requires a certain familiarity that new
contributors don't have. Still automatic pre-release testing is
something very useful.
Kind regards
Philipp Kern
[1]
https://salsa.debian.org/installer-team/debootstrap/merge_requests/16#note_35325
Hi,
On 20.07.2018 20:26, Andrej Shadura wrote:
> On 26 June 2018 at 17:25, Andrej Shadura wrote:
>> On 26 June 2018 at 17:12, Philipp Kern wrote:
>>>>> I suppose
>>>>>
>>>>> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#n
On 2018-07-31 10:46, Philipp Kern wrote:
On 2018-07-31 09:24, Philipp Kern wrote:
I buy the argument for attached removable file systems. It looks like
today fstrim iterates over /proc/self/mountinfo and trims all
non-pseudo/non-netfs. On the other hand enough guides on the internet
say
On 2018-07-31 09:24, Philipp Kern wrote:
I buy the argument for attached removable file systems. It looks like
today fstrim iterates over /proc/self/mountinfo and trims all
non-pseudo/non-netfs. On the other hand enough guides on the internet
say that to have a working system with an SSD, you
I think the appropriate protection against a weekly(!) cronjob that
TRIMs your disk are a) backups and b) a filesystem that supports
snapshots and can recover from corruption. Keeping blocks around also
just makes forensics easier. (It's a double-edged sword.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 18.07.2018 20:38, ju xor wrote:
> Philipp Kern:
>> On 2018-07-18 18:24, ju xor wrote:
>>> Philipp Kern:
>>>> Should this live in some kind of tor-* namespace?
>>> no
>> Without any rationale? :(
> i'm not sure what you mean, but in case
On 20.07.2018 10:18, Marco d'Itri wrote:
> On Jul 20, Philipp Kern wrote:
>> Make sure that glibc splits out libcrypt into its own package, have libc6
>> depend on it and then provide libcrypt1? (Because it's really providing
>> libcrypt's ABI from another package.) Versi
libcrypt into its own package, have
libc6 depend on it and then provide libcrypt1? (Because it's really
providing libcrypt's ABI from another package.) Versioning might be
tricky, though.
Kind regards
Philipp Kern
On 2018-07-18 18:24, ju xor wrote:
Philipp Kern:
Should this live in some kind of tor-* namespace?
no
Without any rationale? :(
Kind regards
Philipp Kern
.
Kind regards and thanks
Philipp Kern
On 2018-07-16 15:58, Andrey Rahmatullin wrote:
Can we assume you didn't look at the code trying to follow the logic
and
you don't have the full picture?
Can we please stop here? It takes grace to take back the request.
Kind regards and thanks
Philipp Kern
On 16.07.2018 15:14, Dashamir Hoxha wrote:
> On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <mailto:pk...@debian.org>> wrote:
>
> rather than trying to appeal to authority like Marc - I could have been
> wrong -, I will point out that my first point was not actually a
'/home/pkern/.pw/pw.tgz': No such file or directory
> gpg: symmetric encryption of '/home/pkern/.pw/pw.tgz' failed: No such file or
> directory
But as soon as tar writes incomplete output (which it totally can, it's
a Tape ARchiver) you have silent corruption.
Kind regards
Philipp Kern
mething that handles a
user's secrets.
> Whoever stops auditing this Bash application because it does not> start with
> `set -e`, does not have the right skills and experience
for> reviewing/auditing it.
And these ad hominems are just unhelpful.
Kind regards
Philipp Kern
le anyway if
your home directory contains a space, but this script will break in
interesting ways. :)
I did not look at the original code of pass, but I don't find this code
handling secrets confidence inspiring, to be honest.
Kind regards
Philipp Kern
[0]
https://lists.zx2c4.com/pipermail/password-store/2016-January/001932.html
no plans to forcefully upgrade systems
> to a merged-usr setup on stretch → buster upgrades.
I suppose this point still stands. :)
Kind regards
Philipp Kern
r.launchpad.net/~ubuntu-core-dev/partman-crypto/ubuntu/revision/736
>
> Could the Ubuntu patch please also be included in Debian?
> Adding this patch also partially solves bug #869897.
This has been discussed on [1] and was subsequently merged.
Kind regards and thanks
Philipp Kern
[1]
On 2018-06-26 15:20, Andrej Shadura wrote:
On 26 June 2018 at 14:59, Philipp Kern wrote:
On 2018-06-23 19:01, Andrej Shadura wrote:
On Sat, 23 Nov 2013 17:07:16 +0100 =?ISO-8859-1?Q?Arno_T=F6ll?=
wrote:
On 22.11.2013 12:48, Danel Lintott wrote:
> Is there anything else we need to do to
e anything wrong with the
package, or with buildds, or elsewhere?
I suppose
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd
might help you?
Kind regards and thanks
Philipp Kern
their users to use a hard-coded fe80::1 default
gateway. (And ifupdown supports this correctly.)
Kind regards
Philipp Kern
it differently if
they need it. So the question is if we can prevent people from shooting
themselves into the foot and making their life actively worse with this
change.
Kind regards
Philipp Kern
compile from the new postinst.
What's the consequence from deleting the files and only recreating them
later? Longer startup time of the interpreter in that short window?
Because if it's worse, it'd be good to have py3clean only delete the
obsolete files in the postinst?
Kind regards
Philipp Kern
integrate udev with debhelper so
that the correct snippet could be generated for various packages'
postinsts instead of everyone who ships a rules file hand-rolling it. Of
course if people actually need to write complicated rules to select the
rules to re-trigger, that seems much more difficult to
On 5/21/18 3:06 PM, Cyril Brulebois wrote:
> Philipp Kern <pk...@debian.org> (2018-05-21):
>> So what's the current contract with apt? ASCII-armored files need to go
>> into .asc and binary files into .gpg? Is the right way to infer ASCII
>> armor to grep for the prea
d want to preserve?
(I sort of agree that we should drop files into the right place, on the
other hand the fix would be "apt-install gnupg" with the current setup.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 5/20/18 12:30 PM, Hideki Yamane wrote:
> On Sun, 20 May 2018 10:14:13 +0200
> Philipp Kern <pk...@debian.org> wrote:
>> So the way it works with your patch is that local variables are
>> inherited by called functions (but not the caller). So from and dest
>&g
On 5/20/18 1:24 AM, Hideki Yamane wrote:
> On Sat, 19 May 2018 20:18:17 +0200
> Philipp Kern <pk...@debian.org> wrote:
>> You local'ed from and dest and now don't pass it anymore to
>> wgetprogress. How does this work?
> It is passed to wget via $@
So the w
On 19.05.2018 07:14, Hideki Yamane wrote:
> On Mon, 14 May 2018 00:48:53 +0200
> Philipp Kern <pk...@debian.org> wrote:
>> any new about incorporating Raphael's suggestion? There's still a grave
>> bug opened against debootstrap right now (on a version that is in testin
Hi,
On 2018-05-15 00:09, Frank Terbeck wrote:
Axel Beckert wrote:
Philipp Kern wrote:
[...]
My gut feeling is that this is because I did not autocomplete in the
old shell yet but now the module is gone.
Yes, that's the same conclusion I came to.
At least with a new shell complist.so
after an attempted completion.
Would it be possible to make sure that the autocompletion system loads
the module on startup rather than on-demand? Is there a drawback to this
approach?
Kind regards and thanks
Philipp Kern
to push or if willingly kept
> it out for now...
Unmarking pending for this reason.
Kind regards and thanks
Philipp Kern
"$PRIVATEKEY" "$@"
> fi
> if [ -n "$CERTIFICATE" ]; then
> set -- "$CERTIFICATE" "$@"
> fi
> if [ -n "$CHECKCERTIF" ]; then
> set -- "$CHECKCERTIF" "$@"
> fi
> if wgetprogress "$@"; then
> [...]
>
> Here we should be safe even if those 3 variables do contain spaces.
any new about incorporating Raphael's suggestion? There's still a grave
bug opened against debootstrap right now (on a version that is in testing).
Kind regards and thanks
Philipp Kern
tag 886016 + pending
thanks
Hi,
On 2/21/18 2:10 PM, Julien Cristau wrote:
> On 02/15/2018 11:31 AM, Philipp Kern wrote:
>> On 2018-01-01 17:01, Julien Cristau wrote:
>>> following patch looks at the Acquire-By-Hash field in (In)Release to get
>>> Packages from the by-
script to fail rather than to
continue with bad input (because it's set -e), it does not. Something
else might fail or you just include the wrong output into your disk
image like in my case today.
So pretty please, could we get a mode that is less surprising, in case
you still don't want to change the default? :)
Kind regards and thanks
Philipp Kern
ot, please fixup?
#thanks
That can't be done on the wanna-build side, uploads to the archive
needs
to be signed. Time to reassign this bug to ftp.debian.org?
Agreed. Doing so now.
Kind regards
Philipp Kern
Which seems to be true.
Kind regards
Philipp Kern
[1]
https://buildd.debian.org/status/fetch.php?pkg=gcc-6-cross-ports=all=27=1521635505=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=gcc-6-cross-ports=all=27=1522939979=0
On 9/3/17 11:40 AM, Philipp Kern wrote:
> On 2017-09-02 23:48, Holger Levsen wrote:
>> On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
>>> > Not yet. We people from the reproducible team couldn't find a way to
>>> > usefully talk to ftp-masters
Philipp Kern
[0] https://salsa.debian.org/pkern/pybuildd/-/jobs/11056
On 2018-03-30 20:02, Luca Boccassi wrote:
On Mon, 2018-03-26 at 18:45 +0200, Philipp Kern wrote:
I would like to understand better what the current set of packages
helps
with, though. It is true that I hadn't considered that you are
shipping
so many packages right now. However, you seem to also
practically that's probably not a problem here because a new sourceful
build would be pushed to all architectures mostly at once anyway.
Kind regards
Philipp Kern
ernatives level, unless I miss something.
Kind regards and thanks for all your replies so far!
Philipp Kern
expect that they at least ship the 32-bit libGL libraries. That they get
rid of the i386 driver support isn't really surprising as long as they
at least keep compatibility with 32-bit binaries. Now of course that
page does not say that, but alas it's also a topic different from the
one described in the bug. =)
Kind regards
Philipp Kern
y more that I probably missed in the proposal. :)
Kind regards and thanks
Philipp Kern
[1] We had a bunch of regressions with newer drivers in the past that
made them dead on arrival, like missing repaints in terminals for a
fraction of the cards.
Hi,
On 2/5/18 4:26 PM, Philipp Kern wrote:
> Since forever users of NVIDIA on Debian accepted that package upgrades
> break newly spawned binaries because the interface between the client
> library and the kernel driver is strictly versioned. The kernel module
> will emit an API mi
arly_cpio stuff at the beginning of the file that doesn't look like
gzip garbage, then it's working.
dracut -N works because it just includes all microcode.
Kind regards
Philipp Kern
well on a traditional filesystem if not
sharded by, say, hash prefix).
Instead it would need to restrict itself to only attempt metadata
fetches by-hash by passing some sort of flag around.
Kind regards and thanks
Philipp Kern
ries from unstable
I already filed a bug upstream about this: [1]. I know about the option
space here. I will likely deactivate the editor, assuming that this
works. Otherwise I'll ask for binary removal.
I'll note that technically it doesn't need a serious bug because testing
migration will be
t; is not a bad one. ;-)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
s not access the network. I have honestly no clue how I'd
successfully test for that locally.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 01.02.2018 10:30, Ansgar Burchardt wrote:
> Philipp Kern writes:
>> On 31.01.2018 01:11, Ansgar Burchardt wrote:
>>> I'm not sure if buildds are already configured to upload to the security
>>> archive via ssh as they do for the main archive. It might be a good
>
e it'd help if there would be some guidance on how to do
things today. I'm (somewhat) happy to fix it upstream if needed.
Kind regards and thanks
Philipp Kern
ent setup entails and if you wrote your own SSH daemon for uploads.
In that case we should be able to figure something out.
Alternatively I suppose DSA could also provide something through
stunnel, but then I think we'd be back to encrypted FTP.
Kind regards and thanks
Philipp Kern
with older machines. I'll try to restart
the discussion again.
What's the venue to have this discussion in? :)
Kind regards and thanks
Philipp Kern
On 2018-01-16 10:28, Emilio Pozuelo Monfort wrote:
On 16/01/18 09:41, Philipp Kern wrote:
ignore_arches: mips64el hurd-i386 alpha hppa m68k powerpcspe ppc64 sh4
sparc64 x32
Can we drop mips64el from that list? It's been a supported
architecture for a while.
[...]
I suppose the actual delta
uld be +kfreebsd-amd64 +kfreebsd-i386 +ia64
+powerpc, right?
Kind regards
Philipp Kern
will need to wait a few years until this
> becomes true I guess).
That's actually an excellent idea. We'll try that out. I actually wrote
code for it already and it's a pretty straightforward approach, but
we'll take another stab at attempting to reduce time to first byte
latency first.
Kind regards and thanks a lot!
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 01/09/2018 01:58 PM, Raphael Hertzog wrote:
> On Mon, 08 Jan 2018, Philipp Kern wrote:
>>> I'm putting debian-wb-t...@lists.debian.org in copy to hear their thoughts
>>> about this. Do you think it's possible to add headers like:
>>>
>>> X-Deb
art where you commented out the problematic line. In that case the
variable set and setup_merged_usr would simply be skipped.
Kind regards
Philipp Kern
is that buildd treats the exit of sbuild as an infrastructure
failure and hence keeps retrying. But none of the buildds can build it.
Did you file a bug somewhere to raise chroot disk space?
Kind regards
Philipp Kern
Hi,
On 12/21/2017 11:02 AM, Philipp Kern wrote:
> At work our packages and package lists are served by a web service that
> has relatively high time to first byte latency. Once it starts
> transmitting the bytes are pushed in a fast way but fetching the bytes
> in the first place t
ld require
depending on another library like nghttp2. So it would likely need to
live in its own apt transport.
Happy to hear your thoughts on how to solve this. And please keep up the
great work. :)
Kind regards and thanks
Philipp Kern
[1] Note that HTTP/2 makes encryption mandatory.
signa
n and make that work somehow. I'm not sure what the
blockers there would be but that would seem to be theoretically
beneficial to various other ports as well.
Kind regards
Philipp Kern
[0]
https://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/74f007db22182c6b86257e
On 11/06/2017 09:46 AM, Philipp Kern wrote:
> Package: thunderbird
> Version: 1:52.4.0-1
> X-Debbugs-Cc: intrig...@debian.org, si...@sdeziel.info
>
> Whenever I start Thunderbird I get the following denial from AppArmor:
>
> [ 172.585316] audit: type=1400 audit(150995776
profile="thunderbird//lsb_release" name="/usr/bin/python3.6" pid=4268
comm="lsb_release" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
According to the profile python3.[0-9] is allowed to be read, but not
mapped, so it can't actually be executed.
K
t;l" fsuid=1000 ouid=1000
target="/home/pkern/.gnupg/.#lk0x559de00c2e10.desktop.kern.pm.14200"
Even after canceling the operation the denials continue until I kill the
gpg2 process in the background.
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 10/28/2017 11:31 AM, Julian Andres Klode wrote:
> On Fri, Oct 27, 2017 at 11:24:51PM +0200, Philipp Kern wrote:
>> The other half of the point is that sid is symlinked to various suites,
>> so when we fix debootstrap we'd have a script divergence for the coming
>> release.
Hi Simon,
On 11/01/2017 10:55 PM, Simon Deziel wrote:
> On 2017-11-01 05:38 PM, Philipp Kern wrote:
>> Package: thunderbird
>> Version: 1:52.4.0-1
>> X-Debbugs-Cc: intrig...@debian.org, si...@sdeziel.info
>>
>> I'm using thunderbird with apparmor ena
On 11/01/2017 10:38 PM, Philipp Kern wrote:
> I'm using thunderbird with apparmor enabled and I get the following deny
> with the proprietary nvidia driver installed and active once on every
> application startup:
>
> [37152.076369] audit: type=1400 audit(1509571965.982:138):
>
ibGL, I'd understand why this
happens. (The unfortunate fact that the AppArmor profile needs to know
about all dependencies of the libraries the application loads.) I don't
obviously see it in the final process map or the ldd output, though.
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 10/31/2017 01:30 PM, Philipp Kern wrote:
> I turned on AppArmor and Thunderbird stopped opening links for me. dmesg
> has the following denial message:
>
> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
> apparmor="DENIED" operation="exec"
t I suppose some kind of rule
is missing to make the log lines go away?
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
would be to let browser packages ship a file that allows
their execution and then the installed ones are automatically available
to Thunderbird (or another browser-spawning program). In this case
Chrome would need to start shipping such a file.
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 10/27/2017 9:52 PM, Julian Andres Klode wrote:
> On Fri, Oct 27, 2017 at 09:40:00PM +0200, Philipp Kern wrote:
>> [ +jak +deity ]
>>
>> On 2017-10-25 12:38, Petr Cech wrote:
>>> apt 1.6~alpha removed binary package apt-transport-https and therefor
>>
onal package for now.
Kind regards and thanks
Philipp Kern
could install a SIGSYS signal handler to print
which syscall was blocked, but did not find anything yet.
Does a seccomp kill land in dmesg?
Kind regards
Philipp Kern
ts, or it needs to be a separate arch-all package).
Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
exists in Debian, although only on i386 and amd64. I don't think there's
a policy today that precludes you from forcing users to build arch:all
on amd64 for technical reasons.
Kind
booting on s390.
If I understand it correctly, this is now obsoleted by the fact that
qemu dropped s390-virtio and runs with their own s390-ccw rom now that's
built from the qemu source. Is that correct? Can we close the s390-tools
bug at least? And I suppose arrange for s390-ccw.rom to be shipped f
).
>
> Could you please take a look?
So what's -10 as an errno on sparc64? I find it odd that I should work
around breakage on an architecture by disabling the doc build. Did you
file a bug against gtk-doc-tools as well so that this bug can be marked
as blocked by it?
I grant you the general r
uration, I think. This mechanism loses the key
agility we have with debian-archive-keyring and the reference of a file
updatable by a package instead of a single key but that's maybe fair in
the context of local configuration[*].
Kind regards
Philipp Kern
[*] But nevertheless I guess also invent
e=libinfinity-0.6
> /bin/bash: gtkdoc-mktmpl: command not found
> Makefile:736: recipe for target 'tmpl-build.stamp' failed
> make[5]: *** [tmpl-build.stamp] Error 127
FWIW, to reset the timer: A new libinfinity fixing this is in NEW since
a week.
Kind regards
Philipp Kern
.
https://packages.qa.debian.org/o/openssl/news/20170824T211015Z.html
seems to have pushed this onto client applications? I.e. it's no longer
hard disabled but client applications need to explicitly enable them?
Kind regards
Philipp Kern
On 2017-09-10 20:49, Henrique de Moraes Holschuh wrote:
On Sun, 10 Sep 2017, Philipp Kern wrote:
On 09/10/2017 02:32 PM, Philipp Kern wrote:
> 3) Add a patch to dracut.sh (/usr/bin/dracut) because intel-microcode
> uses the .initramfs suffix for the ucode files where it requests early
>
gt;
> I suggest the debian installer should be able to deal with link local ipv6
> addresses.
You redacted your link-local address to be dead:beef::. I suppose what
you actually mean is one with a fe80:: prefix? (I.e. it'd have been more
helpful to redact the MAC/actual address.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 09/10/2017 02:32 PM, Philipp Kern wrote:
> 3) Add a patch to dracut.sh (/usr/bin/dracut) because intel-microcode
> uses the .initramfs suffix for the ucode files where it requests early
> loading. Given that hostonly is the default for dracut, only including
> microcode for
_src=$(get_ucode_file)
+_src="$(get_ucode_file)*"
[[ $_src ]] || break
[[ -r $_fwdir/$_fw/$_src ]] || break
fi
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 2017-09-02 23:48, Holger Levsen wrote:
On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
> Not yet. We people from the reproducible team couldn't find a way to
> usefully talk to ftp-masters people, whom never replied to any of the
> questions in the thread at #763822 (
e so.
>
> (Indeed, it wouldn't be too much of a stretch to justify removing
> *non*-HTTP support!)
>
>> Marga's been looking into this lately, see #802591 & #802596.
>
> These have now been closed :)
Yup, and should have fixed this issue with them. Explicitly addin
e mitigating controls.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
on. And
change it to make brute force attacks harder.
Of course in any kind of company context I would despise *rules* (which
this comment is not - it's just a suggestion) because they lower security.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
e is broken. Do you use
the current UEFI BIOS? If not, I'd at least try to upgrade it.
Also the installer's syslog (/var/log/installer/syslog* on the installed
system) would be helpful to see.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 2017-07-21 15:51, Antoine Beaupré wrote:
On 2017-07-20 18:15:00, Philipp Kern wrote:
On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
Let's not jump the gun here. We're not shipping NSS in
ca-certificates,
just a tiny part of it: one text file, more or less.
Yeah, and the consensus
e whole point of that was that
adding LE directly isn't actually critical. (And people should use the
chain provided by ACME rather than relying on certificates shipped by
Debian.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
uldn't check in any other tools using ca-certificates. We also do not
sync the NSS version or backport the cert checks when such distrusts
happen. So we can only react in a similar way when the time for full
distrust has come (which is sort of the case now with these two),
otherwise we diver
101 - 200 of 2048 matches
Mail list logo
