On Sun, May 05, 2024 at 11:20:28AM +0200, Daniel Sahlberg wrote:
> What about this new topic for #svn?
>
> [[[
> The Apache® Subversion® version control system (
> https://subversion.apache.org/) | Read the book: http://www.svnbook.org/ |
> FAQ: https://subversion.apache.org/faq.html | This
ntained in the topic. Redirecting questions to the mailing
list via the topic line should work well enough.
The #svn-dev channel might still be useful for quick communication
during bursts of increased project activity. I would keep it around.
Cheers,
Stefan
On Sun, Mar 10, 2024 at 07:59:38PM -0400, Nathan Hartman wrote:
> There is at least a week before I can begin working on it, so there is
> time for the dev community to respond.
I will be around to help with testing/signing. Thanks for picking this up!
On Wed, Jan 10, 2024 at 09:44:51AM +0100, Johan Corveleyn wrote:
> Interesting discussion. I agree it should at least be documented, and
> perhaps be made a bit more clear from the output of 'revert' (but not
> sure how far we can go without breaking compat). Changing the current
> behavior is
On Sat, Dec 09, 2023 at 11:00:00AM -0700, Nathan Hartman wrote:
> The 1.14.3 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thanks!
Summary: +1 to release
Tested:
On Sat, Nov 11, 2023 at 05:08:28PM +0100, Daniel Sahlberg wrote:
> ne_openssl.o isn't built, the build fails already when running configure on
> neon.
Can you show the cofigure log? E.g. via paste.apache.org?
I am also in #svn-dev on Libera IRC if you want to chat there.
On Sat, Nov 11, 2023 at 04:34:07PM +0100, Stefan Sperling wrote:
> On Sat, Nov 11, 2023 at 04:23:52PM +0100, Daniel Sahlberg wrote:
> > As for the original problem, updating to the latest version of the Neon
> > library doesn't help, I still get the same linking e
On Sat, Nov 11, 2023 at 04:23:52PM +0100, Daniel Sahlberg wrote:
> As for the original problem, updating to the latest version of the Neon
> library doesn't help, I still get the same linking error. I''m sure there
> is something fishy with my Debian install...
Which libssl is your build trying
On Sat, Nov 11, 2023 at 04:07:52PM +0100, Stefan Sperling wrote:
> On Sat, Nov 11, 2023 at 04:00:58PM +0100, Stefan Sperling wrote:
> > On Sat, Nov 11, 2023 at 03:53:09PM +0100, Stefan Sperling wrote:
> > > If neon requests OPENSSL_API_COMPAT 0x1000L and also calls
>
On Sat, Nov 11, 2023 at 04:00:58PM +0100, Stefan Sperling wrote:
> On Sat, Nov 11, 2023 at 03:53:09PM +0100, Stefan Sperling wrote:
> > If neon requests OPENSSL_API_COMPAT 0x1000L and also calls
> > OPENSSL_init_ssl() then that is a bug in neon.
>
> The neon version
On Sat, Nov 11, 2023 at 03:53:09PM +0100, Stefan Sperling wrote:
> If neon requests OPENSSL_API_COMPAT 0x1000L and also calls
> OPENSSL_init_ssl() then that is a bug in neon.
The neon version used by Makefile.svn is quite old.
Newer releases are available here: https://notroj.github.i
On Sat, Nov 11, 2023 at 02:22:55PM +0100, Daniel Sahlberg wrote:
> Hi,
>
> I'm separating this out to a new thread since it doesn't relate to the
> upcoming release, but I'm doing the work trying to reproduce Nathan's
> problem.
>
> I've installed Debian Bullseye (on Hyper-V, but that shouldn't
rating system platforms during -rc testing.
Regards,
Stefan
ts command line
via a hook script.
And I would say if anyone reached into internals they will well be
able to deal with updates that break things for them and adapt their
code. It's not going to be a hugely complicated effort for them.
We never promised such compatibility in the first place, as far as I know.
Cheers,
Stefan
On Mon, Jan 09, 2023 at 11:19:48AM +0100, Johannes von Rotz wrote:
> Hello
>
> I was trying to compile subversion with the HP ANSI C compiler on HP-UX
> yesterday, which complained about the if-statement in question requiring a
> scalar value or something. Unfortunately, I'm unable to recite the
On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00:
> > I think it would be better to have such details spelled out in English
> > in a manner that is easy to understand for anyone, with illustrating
> &
On Wed, Apr 27, 2022 at 11:43:02PM -0400, Nathan Hartman wrote:
> On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg
> wrote:
> >
> > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf :
> >>
> >> As to the general rule, I think we're missing a piece: the overlap
> >> period. We should say something
only 1.15 and 1.14 would be supported.
Cheers,
Stefan
On Thu, Apr 21, 2022 at 08:25:32PM +0300, Sergey Raevskiy wrote:
> I've noticed that in some cases a working copy can become inoperable
> after merge text conflict resolution with `svn_wc_conflict_choose_merged'
> option.
>
> The problem can occur in the following scenario:
>
> 1. There is a
gt; is also always welcome, even though a signature won't be useful in this
> > case.
> >
> > Cheers,
> > Stefan
> >
> I'm a little bit confused... Per HACKING we need three +1 votes from PMC
> members, at least one of which is for each platform (Windows and Unix). W
ndows or other platforms which have not yet been covered in
some way, this would be very welcome. Testing from people outside the PMC
is also always welcome, even though a signature won't be useful in this case.
Cheers,
Stefan
On Sat, Apr 02, 2022 at 09:28:15AM -0400, Mark Phippard wrote:
> The 1.14.2 release artifacts are now available for testing/signing.
>
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
Summary: +1 to release
Tested: [bdb |
On Sat, Apr 02, 2022 at 09:27:18AM -0400, Mark Phippard wrote:
> The 1.10.8 release artifacts are now available for testing/signing.
>
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thanks!
Summary: +1 to release
On Fri, Apr 01, 2022 at 06:08:14PM +0200, Johan Corveleyn wrote:
> I suppose the "modified for better performance" refers to some
> optimisations done by Morten Kloster, who then later submitted the
> patch adding this comment in r1128862. His optimisations were more
> related to the LCS algorithm
On Fri, Apr 01, 2022 at 05:04:49PM +0200, Johan Corveleyn wrote:
> Yes, I suppose this is the case: Patience feeds different (smaller)
> things to LCS. Because, as far as I understand, Myers' way of
> calculating the LCS is fundamentally "somewhat" quadratic (according
> to the Myers paper from
then we don't need to list
revision numbers.
I don't believe any important information was dropped. But if you see
an entry that is now missing information, please feel free to fix it
to your liking.
Cheers,
Stefan
On Fri, Apr 01, 2022 at 04:17:45PM +0200, Johan Corveleyn wrote:
> - Perhaps the fundamental diff algorithm in SVN is fine, but it has a
> performance bug / low-level inefficiency? I think that should be
> explored first, because it might fix most of this problem without
> requiring a discussion
On Fri, Apr 01, 2022 at 12:44:24PM +0200, Johan Corveleyn wrote:
> On Tue, Jun 8, 2021 at 5:58 PM Johan Corveleyn wrote:
> > On Tue, Jun 8, 2021 at 3:24 PM Stefan Sperling wrote:
> > > On Tue, Jun 08, 2021 at 02:57:34PM +0200, Johan Corveleyn wrote:
> > > > Okay, I
On Thu, Mar 31, 2022 at 09:21:58AM -0400, Nathan Hartman wrote:
> On Thu, Mar 31, 2022 at 9:09 AM Nathan Hartman
> wrote:
> > My bad. Hopefully r1899430 fixes it.
> >
> > How do I manually run backport.pl?
>
> Let me rephrase that question: How do I manually trigger it so we
> don't have to
ged and all
> tests passed for me:
>
> r1877310 r1883355 r1878379 r1883719 r1883722 r1884610 r1881534
> r1883838 r1883989 r1886460 r1886582 r1887641 r1890013 r1889629
> r1892470 r1892471 r1892541 r1894734 r1897449 r1898633 r1899227
>
> So hopefully all those (or the subset that fixes the broken tests)
> will be approved and merged soon...
Anyone should feel free to merge+commit approved changes.
I have often bypassed the backport merge bot while doing RM work.
This bot is just a nice-to-have convenience and its absence should not
prevent us from making progress.
Cheers,
Stefan
On Mon, Mar 21, 2022 at 04:46:55PM -0400, Mark Phippard wrote:
> On Mon, Mar 21, 2022 at 4:31 PM Stefan Sperling wrote:
> > This might be a swig problem? Perhaps the version of swig and the
> > version of python don't work well together? Not sure.
>
> HACKING implies I s
>
> Since I have not been able to dry run the entire process I am still
> unsure what else I will run into and how I would solve those problems.
I believe you are already far enough down the road that any remaining
issues will be ironed out.
It is not unusual for an RM to deal with problems like you are seeing.
Sometimes the environment changes and we have to adapt the script.
Updates to the release process documentation usually happen when a
release is made and the RM runs into issue like this. Otherwise, we
mostly leave these docs alone.
Provided you don't get stuck for too long and will be able to get help
when you need it, I don't think there is anything you should worry about.
Cheers,
Stefan
On 19.02.2022 16:31, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, Feb 19, 2022 at 16:11:59 +0100:
I guess I'm a little late to this discussion, but I just upgraded today to
the svn trunk and saw the new APIs.
From what I understand is that new clients can choose which WC format to use
the env variable or set it to the
newest format.
I figure this would mostly affect windows users, but still I think this
would be worth to implement.
Stefan
ch as
URLs having become unusable, SVN will error out when trying to use the
external. There is little we can do about that, as it is somewhat
inherent in the design of the externals feature. Any external that is
valid today could become invalid tomorrow.
Regards,
Stefan
aware that our /subversion subtree of the ASF
SVN repository is open for all ASF committers. You should already have
write access. So once we are done discussing this change, you will be
able to add this change to trunk yourself.
Cheers,
Stefan
On Wed, Feb 09, 2022 at 08:01:26AM -0500, Mark Phippard wrote:
> Anyway, my feeling has been that one of the blockers to being RM is
> motivation. My feeling has been that it is a fair amount of work that
> might not go anywhere because we do not have enough interest in
> reviewing and signing the
On Wed, Feb 09, 2022 at 07:23:55AM -0500, Mark Phippard wrote:
> 2. We need a RM to produce the release. Only a handful of people have
> done this and I am not one of them so I cannot comment on how hard
> this is. It does feel like this entire process could be completely
> automated though. As
se and the proposed functionalty overlaps.
So I would prefer if the existing 'svn auth' command was extended.
I like your proposal.
Cheers,
Stefan
On Tue, Jan 11, 2022 at 12:22:38AM -0500, Nathan Hartman wrote:
> On Mon, Jan 10, 2022 at 6:44 AM wrote:
> >
> > Author: stsp
> > Date: Mon Jan 10 11:44:46 2022
> > New Revision: 1896877
> >
> > URL: http://svn.apache.org/viewvc?rev=1896877=rev
> > Log:
> > Fix misleading -r option documentation
And if you need
any help, just let me know. (I have not yet looked into details; I suspect
that right_source might be bogus or simply invalid?)
Cheers,
Stefan
more than a year now since the 1.14 release, so if 1.15 is maybe
due soon I'll wait with the TSVN release. If not I'll have to make an
"out-of-sync" release.
Stefan
situation well, and it is very useful for us to have all the
important points listed in one message.
Cheers,
Stefan
On Fri, Aug 27, 2021 at 06:01:21PM +0200, Stefan Sperling wrote:
> Consider an asymmetric home internet connection with more download
> than upload capacity. The server may well be able to send the
> original full text much faster than the client could upload it.
> So with a suffic
On Fri, Aug 27, 2021 at 06:42:34PM +0300, Evgeny Kotkov wrote:
> Mark Phippard writes:
>
> > Suppose I am using this feature for binaries, which I think is the
> > main use case. Using whatever tool I produce a modified version of my
> > binary file. At this point in time, there is nothing in
On Fri, Aug 27, 2021 at 11:38:57AM +, Daniel Shahaf wrote:
> The solution to "credentials can't be used to commit with" is not
> *necessarily* "cache a password for a different username". It could
> also be that the authz file has a business logic error («r» rather than
> «rw»), or that the
On Thu, Aug 26, 2021 at 04:08:34PM -0400, Nathan Hartman wrote:
> On Thu, Aug 26, 2021 at 6:30 AM Stefan Sperling wrote:
> > One consequence is that when Alice mistypes the --username option, or
> > mistypes the username or password at the prompt, invalid credentials will
>
On Thu, Aug 26, 2021 at 04:17:16PM +0200, Daniel Sahlberg wrote:
> Den tors 26 aug. 2021 kl 16:10 skrev Stefan Sperling :
>
> > On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote:
> > > I get the feeling I'm missing something, but I still don't understand
>
On Thu, Aug 26, 2021 at 12:15:39PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 26 Aug 2021 10:30 +00:00:
> > And while we are considering read-only vs. read-write access:
> > Plaintext passwords or not, in my contrived scenario Eve could always
> > t
On Thu, Aug 26, 2021 at 02:41:44PM +0200, Johan Corveleyn wrote:
> I get the feeling I'm missing something, but I still don't understand
> what authz has to do with the problem at hand here (i.e. detecting
> expired passwords so we can ask the user for the new one).
The problem is that some
On Thu, Aug 26, 2021 at 10:11:44AM +0200, Branko Čibej wrote:
> On 25.08.2021 21:01, Mark Phippard wrote:
> > On Wed, Aug 25, 2021 at 3:16 AM Johan Corveleyn wrote:
> >
> > > > Is there a way to test whether one has rw access without actually doing
> > > > a commit or a revprop edit? It's
is unlikely to get as the same level of exposure
as a built-in command would receive.
> Stefan - I recall the previous behavior being to warn the user that
> password is being stored in plaintext during entry. That seems like it
> would somewhat mitigate the evil actor using an official sv
On Tue, Aug 24, 2021 at 12:16:48PM +0200, Johan Corveleyn wrote:
> But: obviously I have disabled, in the runtime config area, the
> warning prompt that "Your password will be stored in plaintext" (I
> have disabled it system-wide, in /etc/subversion). Yes, we know this
> and we accept it. I would
On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote:
> Thanks, those are good efforts (and thanks to both Daniels for writing
> them), but I'm afraid those workarounds are not good enough. The thing
> is: this is not for me alone. This needs to be handled in buildscripts
> that can be
nt. Not all communication with users
occurs via public channels.
> For reference, here is the e-mail where Stefan Sperling mentions the change
> in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I
> would encourage everyone to re-read that message since it has a good
> s
On Sat, Aug 21, 2021 at 09:38:56PM +0200, Daniel Sahlberg wrote:
> > @@ -3028,12 +3028,12 @@ conflict_tree_get_details_local_missing(
> >deleted_basename,
> >conflict->pool);
> >
d to your proposal.
The code could still be tweaked later in follow-up commits if anyone
comes up with new ideas.
Cheers,
Stefan
On Tue, Jun 08, 2021 at 05:58:14PM +0200, Johan Corveleyn wrote:
> Also: one of the last things that Morten Kloster committed in 2011 was
> another performance improvement, namely "restarting the LCS" in some
> specific cases. At the time, I didn't have enough time to review this
> properly, and
> subversion_msvc.ncb
>
> C:\Devel\tortoisesvn\ext>
> ]]]
>
> As a side note there are already a bunch of ignores for build directories,
> Release/Debug just above and there is also a "db4-win32" so I think there
> is a precedence to add these. Any opinions?
I don't see any reason against adding these. +1
Cheers,
Stefan
On Tue, Jun 08, 2021 at 02:57:34PM +0200, Johan Corveleyn wrote:
> Okay, I focused on the first revision causing the annotate to differ,
> and with some debug logging:
> - p went up to 139
> - length[0]=1942, length[1]=1817
>
> Now, 1942 lines on the left and 1817 on the right doesn't seem all
>
ove parameters, it takes my system's diff about 50 seconds
> to come up with something that looks reasonable at a glance; svn's
> diff has been crunching away for a while now...
Thank you Nathan, this is incredibly useful!
Would you consider committing this tool to our repository, e.g. somewhere
within the tools/dev/ subtree?
Thanks,
Stefan
On Sat, Jun 05, 2021 at 08:56:24PM +0200, Johan Corveleyn wrote:
> Hmm, I tried this patch with my "annotate large XML file with deep
> history test", but the result isn't the same as with 1.14. I'd have to
> investigate a bit more to find out where it took another turn, and
> what that diff looks
On Wed, Jun 02, 2021 at 02:20:12PM +0200, Stefan Sperling wrote:
> The patch below implements an effort limit for Subversion's LCS diff.
Here is an updated version of this patch. I took a closer look at
other diff implementations again, and realized that they don't use
a fixed limit but one wh
I've heard of several instances where users complain that 'svn update'
takes an extraordinary amount of time to run (in terms of hours).
At elego we have received files which reproduce such behaviour.
These files are XML files that are almost 100MB in size. While versioning
such data is not the
On Sun, May 30, 2021 at 09:30:58PM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > Nathan Hartman wrote:
> >>> + http://libera.chat;>Matrix or
> >>
> >> How does this URL work? Does it have to be opened from within a Matrix app?
>
On Sun, May 30, 2021 at 09:26:25AM -0400, Nathan Hartman wrote:
> On Sun, May 30, 2021 at 3:40 AM wrote:
> > + http://libera.chat;>Matrix or
>
>
> How does this URL work? Does it have to be opened from within a Matrix app?
>
> (My browser doesn't know what to do with it, but I don't have
On Wed, May 26, 2021 at 05:29:49PM +0200, Daniel Sahlberg wrote:
> I can draft a short news item and put it on staging. I think it should be
> low key ("we have decided to move"), or does someone think we should make a
> statement ("we move because XXX is a [insert suitable invective]")?
We don't
On Wed, May 26, 2021 at 10:52:42AM +0200, Stefan Sperling wrote:
> On Wed, May 26, 2021 at 10:41:28AM +0200, Daniel Sahlberg wrote:
> > Considering latest development (the channel takeovers mentioned by Stefan
> > Sperling in another part of the thread), I'd suggest that we switch
On Wed, May 26, 2021 at 10:41:28AM +0200, Daniel Sahlberg wrote:
> Considering latest development (the channel takeovers mentioned by Stefan
> Sperling in another part of the thread), I'd suggest that we switch the
> website. I would go for a more drastic change than Nathan's patch (which
On Wed, May 26, 2021 at 09:42:36AM +0200, Stefan Sperling wrote:
> On Mon, May 24, 2021 at 08:10:40PM +, Daniel Shahaf wrote:
> > I've gone ahead and moved wayita to libera.
> >
> > I wanted to keep a copy on freenode, but forgot to change the pointer to
> > t
On Mon, May 24, 2021 at 08:10:40PM +, Daniel Shahaf wrote:
> I've gone ahead and moved wayita to libera.
>
> I wanted to keep a copy on freenode, but forgot to change the pointer to
> the sqlite database, and I'm not sure whether it's possible to use the
> same set of factoids for two
On Fri, May 21, 2021 at 03:02:08PM +0200, Branko Čibej wrote:
> Every time I hear (or read) someone explaining how "one of my companies is
> funding this free service", I grab my wallet and run away. "Monetizing"
> community-lead and -created services has been a thing since before the
> Internet.
On Thu, May 20, 2021 at 04:15:23PM +0100, Julian Foad wrote:
> For contrast:
> "The Panic Over Freenode Isn’t Justified and Its Reaction Mostly
> Disproportionate"
> http://techrights.org/2021/05/19/freenode-and-cancel-culture/
>
> It took me a while to find an article that covered the issue in
On Thu, May 20, 2021 at 11:43:43AM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > Keeping a matrix bridge to the current freenode channels alive means we're
> > not actually leaving this network. To support the former freenode staff it
> > makes more sense
this risk, but in
the end we will always have to rely on a healthy community to operate the
service for us, whether the service uses a "modern web" ad-hoc federation
style, or the traditional federation style of IRC which requires close
coordination and bonds of trust between admins.
Cheers,
Stefan
On Sun, Apr 11, 2021 at 07:55:33AM +0200, Stefan Sperling wrote:
> Just adding another thing: It looks like task.c has undefined symbols
> during linking if APR is built without support for threads:
I see that this has been fixed now. Thank you!
On Thu, Apr 08, 2021 at 08:01:43PM +, Daniel Shahaf wrote:
> Good morning Stefan,
>
> stef...@apache.org wrote on Thu, Apr 08, 2021 at 14:35:52 -:
> > Initial, single-theaded implementation of the svn_task__t API.
>
> I've committed some minor fixes in r1
.some time _to_ make the workers cancel..."
Thank you for the review. Things should be fixed in r1888523.
-- Stefan^2.
On 06.04.21 21:14, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Mon, Apr 05, 2021 at 21:17:23 +0200:
+static svn_error_t *output_processed(
+ svn_task__t **task,
+ svn_cancel_func_t cancel_func,
+ void *cancel_baton,
+ apr_pool_t *result_pool,
+ apr_pool_t *scratch_pool
On 06.04.21 21:00, Stefan Fuhrmann wrote:
On 06.04.21 08:12, Nathan Hartman wrote:
>
tasks-used-optimized-wc-status.patch applied with some offsets, so is
against a slightly out-of-date trunk, but applied without conflicts.
But my build had many test failures:
Summary of test resu
On 06.04.21 08:12, Nathan Hartman wrote:
On Mon, Apr 5, 2021 at 3:17 PM Stefan Fuhrmann wrote:
See attachment (I may have used a somewhat outdated trunk).
tasks-prepwork.patch refactors some utility code to make it reusable.
tasks-main.patch is the new svn_task__t API, implementation
On 05.04.21 20:19, Nathan Hartman wrote:
On Mon, Apr 5, 2021 at 6:00 AM Stefan Fuhrmann <mailto:stef...@apache.org>> wrote:
Hi all,
Way back in 2014, I started work on an SVN equivalent to apr_thread_pool
and came back to it recently. The key features are output and
know
how responsive I can be in case things go wrong. So, I would very much like
somebody dedicate time to reviewing it this week, give feedback etc.
Any takers?
-- Stefan^2.
On Tue, Feb 16, 2021 at 08:18:04PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Feb 16, 2021 at 12:12:35 +0100:
> > On Mon, Feb 15, 2021 at 07:47:48PM +, Daniel Shahaf wrote:
> > > s...@apache.org wrote on Fri, Feb 12, 2021 at 10:40:16 -:
> > >
On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling :
> > On Mon, Feb 15, 2021 at 07:46:08PM +, Daniel Shahaf wrote:
> > > The entity referred to by the tag wasn't created in 2021. So,
> > > I
o known as CVS-2020-17525
>
> s/S/E/
Thank you! This typo is also fixed now and part of the backport proposal.
Thanks,
Stefan
into the Incubator, or the date it
> was
> promoted to TLP.
>
> Thanks for RMing,
>
> Daniel
>
Thanks for checking.
I think in both of these cases it would have helped to have more specific
instructions for how to update these files in our release manager's manual
of the community guide.
Thanks,
Stefan
On Sun, Feb 14, 2021 at 05:28:06PM -0600, Greg Stein wrote:
> Hey all,
>
> This is a very strange error that we're seeing in Infra, on the ASF svn
> server. It appears that the presence of a particular file in a commit
> causes a failure.
>
> Please see:
>
On Sat, Feb 13, 2021 at 04:50:10PM +0100, Branko Čibej wrote:
> On 13.02.2021 15:32, Evgeny Kotkov wrote:
> > My attempt to fix this is by making checkout stream data to both pristine
> > and
> > the (projected) working file, so that the actual install would then happen
> > as
> > just an atomic
On Thu, Feb 11, 2021 at 11:02:32AM +, Private List Moderation wrote:
> Irrelevant.
Given that this discussion doesn't seem to be going anywhere and the
same arguments from May 2020 are just being rehashed, I guess we will
simply stop using the announce@ mailing list.
On Thu, Feb 11, 2021 at 10:31:24AM +0100, Daniel Sahlberg wrote:
> Den tors 11 feb. 2021 kl 10:11 skrev Stefan Sperling :
>
> > On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote:
> > > It is indeed a chicken-and-egg problem. However I would suggest to split
ent form.
It may help to break some text into more paragraphs with meaningful headers,
and/or perhaps put boxes around some of the details that don't really matter
when someone is trying to get an overview of the procedure.
Regards,
Stefan
to find our releases.
At the moment I sent the announcement at least one distribution (Suse Linux)
already had RPMs with the security fix ready to go because we had sent security
pre-notifications in private about a week earlier.
Cheers,
Stefan
ng is now in order.
Thank you!
Stefan
privileges.
Regards,
Stefan
On Wed, Feb 10, 2021 at 03:20:41PM -, announce-ow...@apache.org wrote:
>
> Hi! This is the ezmlm program. I'm managing the
> annou...@apache.org mailing list.
>
> I'm working for my owner, who can be reached
> at announce-ow...@apache.org.
>
>
es not contain links for the version in the
email.
Also, the standard name for the KEYS file is KEYS - no prefix, no suffix.
Please correct the download page, check it, and submit a corrected announce
mail.
Thanks,
Sebb.
<<<<< <<<<<
Date
subversion-1.10.7.zip.asc
For this release, the following people have provided PGP signatures:
Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
BA3C 15B1 337C F0FB 222B
subversion-1.14.1.zip.asc
For this release, the following people have provided PGP signatures:
Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
BA3C 15B1 337C F0FB
On Thu, Feb 04, 2021 at 01:57:16PM +0100, Stefan Sperling wrote:
> The 1.10.7 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
Summary: +1 to release
Tested:
On Thu, Feb 04, 2021 at 01:56:21PM +0100, Stefan Sperling wrote:
> The 1.14.1 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thanks!
Summary: +1
1 - 100 of 4519 matches
Mail list logo
