On Fri, Dec 11, 2020 at 10:53 PM Loren Burkholder
wrote:
>
> Hi all,
>
> I have created a program called TotalReqall. Its purpose is to aid
> memorization of things. To this end, it includes the Sword library for
> accessing the Bible (because it actually started as a Bible memory-only app)
> a
On Sat, Dec 12, 2020 at 1:12 PM Albert Astals Cid wrote:
>
> El dissabte, 12 de desembre de 2020, a les 2:23:48 CET, Loren Burkholder va
> escriure:
> > It is not religion based per se.
>
> find_package(sword REQUIRED)
>
> "The SWORD Project is the CrossWire Bible Society's free Bible software
>
d
to 'fix' that:
- At a certain point I removed the entire ~/.local/share/kscreen/ directory
- Upgrading various components. Currently I'm running kscreen 5.17,
plasma-desktop 5.14
Hope it helps.
Regards,
- Johan Ouwerkerk
tched and
not who does the scratching...
But it does require very active maintainers and it may not be a good
fit for all projects. :)
Regards,
- Johan Ouwerkerk
admin stuff). But many
drive-by contributors and newbies or even seasoned contributors won't
be deterred at all from not having commit access to the main repo.
Additionally I suspect not many people will object to a maintainer
taking their changes but landing them in different commits or a
s
there's no need why projects should stick to a global default.
So if you're the maintainer you could nudge the default towards what
makes sense for your project and its dominant workflow. Go to Settings
(side bar) > General > Squashing and merging. Apparently that has been
a feature of Gitlab core since version 11.
Regards,
- Johan Ouwerkerk
d 2020 you
are supposed to see something to the effect of `Copyright 2019-2020
Johan Ouwerkerk`, and suppose that in 10 years time I contribute again
to that file then would become `Copyright 2019-2020, 2030 Johan
Ouwerkerk`.
What you don't do is bump a `Copyright` year indicator just be
On Fri, Aug 14, 2020 at 5:33 PM Carl Schwan wrote:
>
> Le vendredi, août 14, 2020 4:44 PM, Francois Blanchette
> a écrit :
>
> > Hi Carl,
> >
> > Thank you for your reply.
> >
> > Yes I meant port it to KDE because it is a qt 5.15 compliant
> > application already.
> > And yes i want to make LGC
On Wed, Jun 24, 2020 at 6:50 PM Albert Astals Cid wrote:
>
> +1 a
> SPDX-License-Identifier: BSD-3-Clause
> sounds like a great idea for default default CMakeLists.txt header
>
> Cheers,
> Albert
>
+1. Based on some discussion quite a while ago on Matrix/IRC we went
with BSD-2-Clause for Keys
On Wed, May 20, 2020 at 11:41 PM Albert Astals Cid wrote:
>
> El dimecres, 20 de maig de 2020, a les 6:07:28 CEST, Ivan Romanov va escriure:
> > IANA doesn't provide any licesnse info.
>
> If there's no license info, that means that we can't ship it. Please remove
> it from our repositories ASAP
On Mon, May 18, 2020 at 8:59 PM Ivan Romanov wrote:
>
> Hello.
>
> Today I added generated file to QCA repo. This commit
> https://invent.kde.org/libraries/qca/-/commit/cf929ce541b48e36a54691a37b31211d17334bf7.
> And got such email mesage: The files marked with a * at the end have a
> non valid li
On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote:
>
> Following lengthy discussion in the original thread, it was agreed
> that the original sysadmin proposal of various categories would be
> implemented, with repositories organised according to that structure.
>
> You can find this documented a
On Sun, May 3, 2020 at 4:12 PM Gerold Jens Wucherpfennig
wrote:
> Am 03.05.20 um 16:00 schrieb Stefan Brüns:
> > On Sonntag, 3. Mai 2020 15:50:40 CEST Gerold Jens Wucherpfennig wrote:
> > LSB is dead, dead, dead ...
> >
> > Have a look at os-release:
> > https://www.freedesktop.org/software/system
On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote:
>
> Hi,
>
> There is a widespread problem across many text strings to be translated: some
> isolated words are gender invariable in English, but not in many languages.
>
> For example, let's consider this case of a cascade menu:
>
> New
>
>
On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote:
>
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I
> >> thought it was the common thing to do :?
> >
> > I do too
>
On Tue, Apr 28, 2020 at 1:09 PM Adriaan de Groot wrote:
>
> One actor is "tooling", as Albert has pointed out. Whatever the resulting
> structure is, it needs to be communicated to tool authors on time for tools to
> be updated, released, and rolled out for use. Tools mentioned so far:
> - kdesrc
On Mon, Apr 27, 2020 at 2:32 PM Piyush Aggarwal
wrote:
>
> How long do redirects like this one work? If they will keep working
> indefinitely, then maybe we can have all the repos at flat URLs for once and
> then move them to respective subgroups?
I don't think this works if you want $repo to a
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote:
>
> >
> > We may need to do on-the-fly conversion of the kde: repo paths if they
> > won't be expressible as 'kde:foo' in the future, but we should have the
> > information needed to do this in kdesr
On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote:
>
> On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk
> wrote:
> >
> > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk
> > wrote:
> > >
> > > Yes the only reason why a cleanup script might b
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote:
>
> Yes the only reason why a cleanup script might be needed is if the
> logical path used to express the repo in dependency information
> changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> remapped to `fra
On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote:
>
> On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
>
> >
> > A cleanup script could be handy. I think kdesrc-build will
> > automatically pick up new repo paths from metadata and that should
> >
On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez
wrote:
>
> How would it work during the "grace period"? Keeping an outdated read-only
> mirror on the old URL? I have done some research into redirecting or
> remapping from the old URL to the new one so we can keep it working for a
> longer perio
On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote:
>
> Yes, the hostname git.kde.org will be fully retired as part of this
> transition.
>
> From my understanding kdesrc-build will automatically pick this up
> once we update sysadmin/repo-metadata to show the new repository
> paths.
> This is so
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote:
>
> Should anyone have any questions on the above, please let us know.
>
Does the migration also mean that `git.kde.org` push URL will be
retired and would need to be remapped to `invent.kde.org`?
In that case, it would be good to have a grace
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote:
>
> To help assist with this, it would be appreciated if all holders of a
> KDE Developer account could please login on our Gitlab instance (at
> https://invent.kde.org/) and ensure they are listed as a 'Developer'
> of the KDE group. You can do
On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau
wrote:
>
> Personally I am still unsure what the actual issue is. Why are redirects
> needed at all. Why all the address changes all the time?
>
It is part of the HTTP spec for servers to be able to inform clients
that resource /foo/bar has
On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote:
>
> Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > I updated:
> >
> > https://community.kde.org/Policies/API_to_Avoid
> >
> > Which had no mention of this.
> >
> > David
>
> I think that you made an error
>
> "networkAccess
On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer wrote:
> Now I will fix my latest revision and merge to master. Still: 19 commits
> are not compiling anymore.
>
> Or am I missing something here?
>
> How would we deal with that? Is "short-lived branches" (as you stated
> below) enough to reduce
On 14.10.2019 21:22, Frederik Schwarzer wrote:
> If however, master had seen commits as well, fast-forwarding is
> performing a rebase ... is that correct?
The workflow would be: whenever master is updated, you rebase your
local feature/work branch and force-push to the remote copy of the
feature/
Yes, please, pretty please with cherry on top. :)
Regards,
-Johan
On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote:
>
> I find the merge behavior to be not what we've been doing in phabricator so
> given the idea is to maintain our workflows i'd appreciate if we can agree on
> continu
Xattr.cmake PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/128554/diff/
Testing
---
Without xattr development headers cmake now complains when building with
kdesrc-build.
With xattr development headers installed, cmake & compilation steps pass with
kdesrc-build.
Thanks,
Johan Ouwerkerk
> On Aug. 2, 2016, 1:03 p.m., Vishesh Handa wrote:
> > Ship It!
>
> Johan Ouwerkerk wrote:
> Should I push to master, or to another branch?
Nevermind, there's only the one branch. :)
- Johan
---
This is an
/r/128554/#review97999
---
On July 29, 2016, 5:50 p.m., Johan Ouwerkerk wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewb
ke PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/128554/diff/
Testing (updated)
---
Without xattr development headers cmake now complains when building with
kdesrc-build.
With xattr development headers installed, cmake & compilation steps pass with
kdesrc-build.
Thanks,
Johan Ouwerkerk
/FindXattr.cmake PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/128554/diff/
Testing
---
Thanks,
Johan Ouwerkerk
I don't think kdesrc-build inspects the cmake files to discover deps,
it relies on the project metadata GIT repo instead. So
--include-dependencies only applies to the dependencies discovered
through the project metadata repo, and then only those which
kdesrc-build knows how to build.
Any other de
36 matches
Mail list logo
