Re: Small summer status overview + request for some opinions

[Tuomas Nurmi]

Hi everyone,

https://invent.kde.org/multimedia/amarok/-/blob/master/ChangeLog has been 
filling
up nicely and we're also clearly under 500 open bugs now. I merged a 
reimplemented
Similar Artists context applet earlier today, which was the final thing I wanted
to have included in the next version.

Although there haven't been that many new new features, there's been a huge 
amount
of Qt6 compatibility preparation work, however. That shouldn't affect Qt5/KF5
functionality, but it naturally carries some kind of regression risk 
(additionally,
minimum KF version has been bumped to 5.89), so I figured it's probably a good 
idea
to make the next release 3.1 already, and do a beta for it first. The beta will
be  tagged in a couple of days, with 3.1 release maybe in early August.

KF5.89's a nice dependency, as it's apparently still compatible with Kubuntu 
22.04
LTS. Maybe there'll be a 3.1.1 a bit later which doesn't yet raise the 
dependency,
but after that it's time to go to 5.108 so all the remaining deprecated KF parts
can be replaced ( https://invent.kde.org/multimedia/amarok/-/issues/8 ). That'll
probably be called 3.2 then, and maybe it will at least be buildable with 
Qt6/KF6
already.

Wishing everyone a nice week
Tuomas


Kirjoitit torstaina 27. kesäkuuta 2024 16.18.50 UTC+3:
> Hi everyone
> I thought I'd write a couple of words of status update here.
> 
> There's been some work on pruning outdated documentation in online resources 
> etc ongoing,
> and also removing outdated/unused bits in Amarok code, too.
> 3.0.2 will come probably in July; there are already a bunch of nice 
> improvements listed in
> Changelog: https://invent.kde.org/multimedia/amarok/-/blob/master/ChangeLog
> and some more will come before release. Open bugs/wishes are now at 503, and 
> it'll
> probably go under 500 before release. (I think I'll also close all the bugs 
> reported
> against the latest Windows version 2.8.0 from 2013 soon - no point in keeping 
> them open
> as they've been mostly fixed since, but not going to land on any Windows user 
> before someone
> wants to make Windows-3.0's happen)
> 
> Qt6 build keeps progressing a bit further, bit-by-bit, while everything's 
> still staying
> Qt5-compatible too. I have no idea yet if there will be a point when same 
> codebase can be
> built with Qt5 and Qt6, but at least getting as near as that as possible is 
> probably a good idea.
> 
> There's also one pending change I'd be very happy to hear more opinions on:
> https://invent.kde.org/multimedia/amarok/-/merge_requests/107
> As it kind of effects how credits / info on earlier contributors are 
> displayed, I'd be happy to
> hear if the idea of removing the openDesktop.org integration sounds 
> justifiable to other
> people, too, before merging (some screenshots demonstrating the state are 
> shown on the
> merge request).
> Additionally, I'd maybe like to remove the donors tab altogether. It lists 3 
> people who
> contributed to Roktober 2012 or earlier. Maybe it would be time to.
> 
> Wishing you a nice summer Thursday!
> Tuomas
> 

Re: Small summer status overview + request for some opinions

[Tuomas Nurmi]

Thank you for the comment, Pedro!
I agree with your take. Maybe the lists made more sense when they were actively
maintained, but I believe their actual content hasn't been touched since at 
least 2013,
and much (most?) of the development since has been done by people not on those 
lists.

Nowadays information about contributors in projects are more readily available 
than
before, thanks to all the nice git web interfaces etc.; [at least technically 
proficient]
people might be more likely to check out project's git repository to get to 
know the
people behind the project, than an extra tab in program's about dialog.

I merged the changes that removed the extra technical dependencies from the 
'extended
about dialog'. The author/contributor lists in their basic form aren't 
technically
problematic, however, so maybe they will stay along with the donors tab for 
now, and
maybe they'll be compacted/cleaned up more for Amarok 4, then.

Tuomas


Pedro de Carvalho Gomes kirjoitti lauantaina 29. kesäkuuta 2024 23.29.39 UTC+3:
> Hi Tuomas,
> 
> Thanks again for the nice effort. I think Sven already covered the 
> "donours" tab. So, about contributor, I give my humble opinion. I think 
> it's a bit pointless to keep it the software a list of contributors. 
> It's either outdated, or too long. I personally prefer to have 
> contributions listed by major release (as you kindly did for 3.0). If 
> so, a mention to "Amarok community", and links to relevant channels, 
> would be enough (again, a simple personal opinion)
> 
> Best,
> 
> Pedro
> 
> On 2024-06-27 15:18, Tuomas Nurmi wrote:
> > Hi everyone
> > I thought I'd write a couple of words of status update here.
> >
> > There's been some work on pruning outdated documentation in online 
> > resources etc ongoing,
> > and also removing outdated/unused bits in Amarok code, too.
> > 3.0.2 will come probably in July; there are already a bunch of nice 
> > improvements listed in
> > Changelog: https://invent.kde.org/multimedia/amarok/-/blob/master/ChangeLog
> > and some more will come before release. Open bugs/wishes are now at 503, 
> > and it'll
> > probably go under 500 before release. (I think I'll also close all the bugs 
> > reported
> > against the latest Windows version 2.8.0 from 2013 soon - no point in 
> > keeping them open
> > as they've been mostly fixed since, but not going to land on any Windows 
> > user before someone
> > wants to make Windows-3.0's happen)
> >
> > Qt6 build keeps progressing a bit further, bit-by-bit, while everything's 
> > still staying
> > Qt5-compatible too. I have no idea yet if there will be a point when same 
> > codebase can be
> > built with Qt5 and Qt6, but at least getting as near as that as possible is 
> > probably a good idea.
> >
> > There's also one pending change I'd be very happy to hear more opinions on:
> > https://invent.kde.org/multimedia/amarok/-/merge_requests/107
> > As it kind of effects how credits / info on earlier contributors are 
> > displayed, I'd be happy to
> > hear if the idea of removing the openDesktop.org integration sounds 
> > justifiable to other
> > people, too, before merging (some screenshots demonstrating the state are 
> > shown on the
> > merge request).
> > Additionally, I'd maybe like to remove the donors tab altogether. It lists 
> > 3 people who
> > contributed to Roktober 2012 or earlier. Maybe it would be time to.
> >
> > Wishing you a nice summer Thursday!
> > Tuomas
> >
> >
> >
> 

Re: Small summer status overview + request for some opinions

[Pedro de Carvalho Gomes]

Hi Tuomas,

Thanks again for the nice effort. I think Sven already covered the 
"donours" tab. So, about contributor, I give my humble opinion. I think 
it's a bit pointless to keep it the software a list of contributors. 
It's either outdated, or too long. I personally prefer to have 
contributions listed by major release (as you kindly did for 3.0). If 
so, a mention to "Amarok community", and links to relevant channels, 
would be enough (again, a simple personal opinion)


Best,

Pedro

On 2024-06-27 15:18, Tuomas Nurmi wrote:

Hi everyone
I thought I'd write a couple of words of status update here.

There's been some work on pruning outdated documentation in online resources 
etc ongoing,
and also removing outdated/unused bits in Amarok code, too.
3.0.2 will come probably in July; there are already a bunch of nice 
improvements listed in
Changelog: https://invent.kde.org/multimedia/amarok/-/blob/master/ChangeLog
and some more will come before release. Open bugs/wishes are now at 503, and 
it'll
probably go under 500 before release. (I think I'll also close all the bugs 
reported
against the latest Windows version 2.8.0 from 2013 soon - no point in keeping 
them open
as they've been mostly fixed since, but not going to land on any Windows user 
before someone
wants to make Windows-3.0's happen)

Qt6 build keeps progressing a bit further, bit-by-bit, while everything's still 
staying
Qt5-compatible too. I have no idea yet if there will be a point when same 
codebase can be
built with Qt5 and Qt6, but at least getting as near as that as possible is 
probably a good idea.

There's also one pending change I'd be very happy to hear more opinions on:
https://invent.kde.org/multimedia/amarok/-/merge_requests/107
As it kind of effects how credits / info on earlier contributors are displayed, 
I'd be happy to
hear if the idea of removing the openDesktop.org integration sounds justifiable 
to other
people, too, before merging (some screenshots demonstrating the state are shown 
on the
merge request).
Additionally, I'd maybe like to remove the donors tab altogether. It lists 3 
people who
contributed to Roktober 2012 or earlier. Maybe it would be time to.

Wishing you a nice summer Thursday!
Tuomas

Re: Small summer status overview + request for some opinions

[Tuomas Nurmi]

Hi Sven,
thank you for the response & information! Sure thing, the donor list itself 
doesn't
require more a than couple of lines of code either, so there's not much 
technical burden
there, it can stay for now.
I don't know if Qt6 version will be Amarok 4 or 3.something, but maybe I'll add 
a note/
reminder/TODO about this to code or something.

On the openDesktop.org/Attica integration removal MR: I think I'll wait to 
early next
week or so and unless any opinions or arguments are presented before that, 
merge it then.

Best regards
Tuomas


Sven Krohlas kirjoitti perjantaina 28. kesäkuuta 2024 7.17.18 UTC+3:
> Hi,
> 
> > Additionally, I'd maybe like to remove the donors tab altogether. It lists 
> > 3 people who
> > contributed to Roktober 2012 or earlier. Maybe it would be time to.
> 
> back then we promised the Roktober donors would be part of Amarok 3. We
> wrote lots of text about that in the campaign. So imho the Roktober
> donors can be removed in Amarok 4, whenever that will be. We should keep
> our promises.
> 
> https://amarok.kde.org/en/roktober/2012.html
> 
> Sorry my life has changed a bit since back then, I am only lurking on
> the list these days.
> 

Re: Small summer status overview + request for some opinions

[Sven Krohlas]

Hi,


Additionally, I'd maybe like to remove the donors tab altogether. It lists 3 
people who
contributed to Roktober 2012 or earlier. Maybe it would be time to.


back then we promised the Roktober donors would be part of Amarok 3. We
wrote lots of text about that in the campaign. So imho the Roktober
donors can be removed in Amarok 4, whenever that will be. We should keep
our promises.

https://amarok.kde.org/en/roktober/2012.html

Sorry my life has changed a bit since back then, I am only lurking on
the list these days.

Re: Amarok 3.0 "Castaway" released!

[Pedro de Carvalho Gomes]

Thanks Tuomas for the effort to bring Amarok back to life

The work has already been noticed:

https://entertainment.slashdot.org/story/24/05/03/0020208/back-from-the-dead-amarok-30-music-player-released

On 2024-04-29 22:15, Tuomas Nurmi wrote:

Hi everyone,
I am happy to announce the immediate availability of Amarok 3.0 "Castaway", the
first stable Qt5/KDE Frameworks 5 based Amarok. Many fixes for bugs old and new;
some new features, too.

You can find the full release announcement at
https://blogs.kde.org/2024/04/29/amarok-3.0-castaway-released/

Tarball available at
https://download.kde.org/stable/amarok/3.0.0/amarok-3.0.0.tar.xz.mirrorlist and
packages available in distribution repositories probably a bit later, too.


Now it's time to Rediscover Your Music in the 2020's!

On behalf of the "The Amarok Development Squad"
Tuomas

Re: Amarok 3.0 "Castaway" released!

[Martin Steigerwald]

Dear Tuomas, dear Amarok development team.

Tuomas Nurmi - 29.04.24, 22:15:33 CEST:
> I am happy to announce the immediate availability of Amarok 3.0
> "Castaway" […]

Thank you, that is wonderful!

I appreciate it!

Best,
-- 
Martin

Re: Amarok 3.0 "Castaway" released!

[Valorie Zimmerman]

Congratulations, Tuomas and "squad"! Very happy to see development
continue.

Amarok was my very first place to volunteer in FOSS, and I learned so much,
and met so many lovely people. "Long and winding road," as the song
says. ♥️

Valorie

On Mon, Apr 29, 2024 at 1:16 PM Tuomas Nurmi 
wrote:

> Hi everyone,
> I am happy to announce the immediate availability of Amarok 3.0
> "Castaway", the
> first stable Qt5/KDE Frameworks 5 based Amarok. Many fixes for bugs old
> and new;
> some new features, too.
>
> You can find the full release announcement at
> https://blogs.kde.org/2024/04/29/amarok-3.0-castaway-released/
>
> Tarball available at
> https://download.kde.org/stable/amarok/3.0.0/amarok-3.0.0.tar.xz.mirrorlist
> and
> packages available in distribution repositories probably a bit later, too.
>
>
> Now it's time to Rediscover Your Music in the 2020's!
>
> On behalf of the "The Amarok Development Squad"
> Tuomas
>
>
>
>

-- 
she/her. "Dwell on the beauty of life. Watch the stars, and see yourself
running with them." - Marcus Aurelius

Re: Amarok 3.0 beta (2.9.82) out now

[Dan]

Thanks for taking this on!

On Fri, Apr 12, 2024, 09:22 Tuomas Nurmi  wrote:

> Hi everyone,
> long time user, first time releaser here.
> I am happy to announce the immediate availability of Amarok 2.9.82!
>
> Source tarball from 2.9.82 tag (
> https://invent.kde.org/multimedia/amarok/-/
> tags/v2.9.82  )
> available at https://download.kde.org/unstable/amarok/2.9.82/
> amarok-2.9.82.tar.xz
> 
>
> There might be bugs. However, quite many have been fixed, too.
>
> Somewhat comprehensive ChangeLog for 2.9.71 -> 2.9.82 is available at
> https://
> invent.kde.org/multimedia/amarok/-/blob/master/ChangeLog?ref_type=heads#L13
>
>
> After some consideration, I decided to make it beta already, as we've had
> some
> years of alpha and it's been ready for day-to-day usage for years. I chose
> the
> number .82 as some widely used git builds for various distributions have
> been
> using .75 and .81.
>
> Depending on reactions, amount of fresh bug reports etc I'll see if there
> needs to be a beta2 / RC or if it'll be directly 3.0 next in some weeks.
>
>
>
> Cheers
> Tuomas Nurmi
>
>
>
>

Re: Planning an alpha2 (2.9.76)

[Tuomas Nurmi]

Okay, good to know, thank you.
I haven't yet received any response from Myriam, but should I not manage to 
contact anyone with amarok.kde.org access, I'll ask sysadmins next week if 
they can help with that.

Regarding alpha2 status code-wise, most of the things are merged, with 
https://invent.kde.org/multimedia/amarok/-/merge_requests/76 and https://
invent.kde.org/multimedia/amarok/-/merge_requests/31 still waiting but could 
probably be merged as-are. There are still some small things I might have a 
look at but nothing mandatory, so I think I'll try starting the release 
process for alpha2 late next week. And if it seems ok, actually no reason to 
wait too long, beta1 could follow in a week or so. (Or actually, maybe just 
release beta1 instead of alpha2, and 3.0 instead of beta1, and be prepared to 
do a patch version in a couple of weeks if bugs start to appear.)

Tuomas


Pedro de Carvalho Gomes kirjoitti perjantaina 5. huhtikuuta 2024 0.25.09 EEST:
> As far as I remember, the page was latest updated by Myriam Schweingruber
> 
> On 2024-04-03 11:22, Tuomas Nurmi wrote:
> > Hi everyone,
> > 
> > as things are coming together quite nicely, I'd like to ask if anyone has
> > any comments on the idea of a next release, which could be alpha2 at this
> > point.
> > 
> > There are still some MRs & things I'd like to have a look at before that
> > (a
> > short review of them a bit later in this mail), but I'd guess everything
> > would be set around mid-month (e.g. somewhere around 13th - 17th April)
> > 
> > Looking at https://invent.kde.org/multimedia/amarok/-/blob/master/
> > release_scripts/RELEASE_HOWTO most of the things seem clear (or not
> > relevant at the moment). Documentation at
> > https://invent.kde.org/sdk/releaseme is probably more up to date at some
> > places, and RELEASE_HOWTO can be updated accordingly when such things are
> > encountered during releasing.
> > 
> > Reading through the steps, I think (in addition to probably filing a
> > sysadmin request to get more bugzilla permissions for my account)
> > 
> >   * Update the amarok.kde.org front-page
> > 
> > is the only one where I don't have the required access myself. Would
> > anyone
> > have more insight on this step?
> > 
> > 
> > 
> > 
> > On improvements still a bit WIP / testing / comments pending:
> > 
> > Improvements to albums, current track, equalizer and photos context
> > applets
> > https://invent.kde.org/multimedia/amarok/-/merge_requests/65
> > received a fine comment related to HIG. I reflected the UI changes based
> > on it and will try some adjustments a bit later, before merging. (=1 more
> > commit and ready to be merged)
> > 
> > 
> > Fresh set of de-deprecations in MR!79: https://invent.kde.org/multimedia/
> > amarok/-/merge_requests/79
> > After that one, the only deprecated Qt thing left is
> > QNetworkConfigurationManager, for which's usecases the replacement
> > QNetworkInformation was introduced only in Qt 6.1, so that'll have to
> > wait.
> > (On KF side there's a bit more to do, especially related to KPluginInfo,
> > but they'd need bumping KF5 requirement quite a bit and are not worth the
> > effort right now, I think)
> > Although the changes (are/should be) pretty straightforward, I'd like to
> > merge them in a couple of days to have at least some time to receive any
> > possible issue reports from nightly build users before the alpha2 release
> > (= ready for merging after maybe some extra testing still)
> > 
> > 
> > Fix script console crashing when reopened.
> > https://invent.kde.org/multimedia/amarok/-/merge_requests/76
> > Due to fact that there's also pending warning in the dialog, which will
> > only be shown once on KF6, https://invent.kde.org/multimedia/amarok/-/
> > merge_requests/78 , and the fact that Amarok 2.0 scripts available on
> > store.kde.org (don't work? are not likely to work?), I'm pondering if the
> > button to open KNewStuff for scripts should be hidden, at least for the
> > moment.
> > 
> > I thought maybe getting the radio_station_service and librivox_service
> > working and included would have been a fitting goal, but reading Pedro's
> > take on this I'm not confident on that anymore. However, I didn't look
> > any deeper than what I've written on the MR and I definitely am not sure
> > about anything related to script engine, but I have no problem with the
> > idea of leaving it hidden for now.
> > Maybe the script console should still be left available as is, as it can
> > be
> > used to do something sensible with some of the API calls listed at
> > https://
> > community.kde.org/Amarok/Development/Script_API
> > 
> > 
> > 
> > There's also the earlier MR on fixing more stalling issues on random mode
> > which I haven't myself inspected yet, but will later
> > https://invent.kde.org/multimedia/amarok/-/merge_requests/31
> > 
> > 
> > And I'll also have a stab at playlist length display, as referred to on
> > bugs https://bugs.kde.org/show_bug.cgi?id=324452 No or wrong 

Re: Planning an alpha2 (2.9.76)

[Pedro de Carvalho Gomes]

As far as I remember, the page was latest updated by Myriam Schweingruber

On 2024-04-03 11:22, Tuomas Nurmi wrote:

Hi everyone,

as things are coming together quite nicely, I'd like to ask if anyone has any
comments on the idea of a next release, which could be alpha2 at this point.

There are still some MRs & things I'd like to have a look at before that (a
short review of them a bit later in this mail), but I'd guess everything would
be set around mid-month (e.g. somewhere around 13th - 17th April)

Looking at https://invent.kde.org/multimedia/amarok/-/blob/master/
release_scripts/RELEASE_HOWTO most of the things seem clear (or not relevant
at the moment). Documentation at https://invent.kde.org/sdk/releaseme is
probably more up to date at some places, and RELEASE_HOWTO can be updated
accordingly when such things are encountered during releasing.

Reading through the steps, I think (in addition to probably filing a sysadmin
request to get more bugzilla permissions for my account)

  * Update the amarok.kde.org front-page
is the only one where I don't have the required access myself. Would anyone
have more insight on this step?




On improvements still a bit WIP / testing / comments pending:

Improvements to albums, current track, equalizer and photos context applets
https://invent.kde.org/multimedia/amarok/-/merge_requests/65
received a fine comment related to HIG. I reflected the UI changes based on it
and will try some adjustments a bit later, before merging. (=1 more commit and
ready to be merged)


Fresh set of de-deprecations in MR!79: https://invent.kde.org/multimedia/
amarok/-/merge_requests/79
After that one, the only deprecated Qt thing left is
QNetworkConfigurationManager, for which's usecases the replacement
QNetworkInformation was introduced only in Qt 6.1, so that'll have to wait.
(On KF side there's a bit more to do, especially related to KPluginInfo, but
they'd need bumping KF5 requirement quite a bit and are not worth the effort
right now, I think)
Although the changes (are/should be) pretty straightforward, I'd like to merge
them in a couple of days to have at least some time to receive any possible
issue reports from nightly build users before the alpha2 release (= ready for
merging after maybe some extra testing still)


Fix script console crashing when reopened.
https://invent.kde.org/multimedia/amarok/-/merge_requests/76
Due to fact that there's also pending warning in the dialog, which will only
be shown once on KF6, https://invent.kde.org/multimedia/amarok/-/
merge_requests/78 , and the fact that Amarok 2.0 scripts available on
store.kde.org (don't work? are not likely to work?), I'm pondering if the
button to open KNewStuff for scripts should be hidden, at least for the moment.

I thought maybe getting the radio_station_service and librivox_service working
and included would have been a fitting goal, but reading Pedro's take on this
I'm not confident on that anymore. However, I didn't look any deeper than what
I've written on the MR and I definitely am not sure about anything related to
script engine, but I have no problem with the idea of leaving it hidden for
now.
Maybe the script console should still be left available as is, as it can be
used to do something sensible with some of the API calls listed at https://
community.kde.org/Amarok/Development/Script_API



There's also the earlier MR on fixing more stalling issues on random mode which
I haven't myself inspected yet, but will later
https://invent.kde.org/multimedia/amarok/-/merge_requests/31


And I'll also have a stab at playlist length display, as referred to on bugs
https://bugs.kde.org/show_bug.cgi?id=324452 No or wrong playlist length (time)
displayed when adding files per drag from outside Amarok
https://bugs.kde.org/show_bug.cgi?id=281143 Length of filtered playlist is not
calculated - total playlist length displayed
https://bugs.kde.org/show_bug.cgi?id=316751 Amarok does not show correct total
playing time of a playlist during the first loading,

a bit later, but before alpha2. (I've tried some prototypes and have an idea
what to do)

I'm happy to hear any comments or extra insight

Cheers
Tuomas

Re: Amarok - hunting for a boost

[Tuomas Nurmi]

Thank you Pedro,

Some thoughts on the comments, and additional comments:

Port to QT6/KF6: Yes, definitely a high priority. I hope a 6-based release can 
be achieved in 2024. But that'd be post-3.0, I'd figure.
I added some draft milestones to https://invent.kde.org/multimedia/amarok/-/
milestones , however, I consider those datest "latest at". I'd imagine alpha2 
could be released maybe mid-April.

On things I'd like to see in alpha2:
I've merged in quite a bit of various simple bugfixes, text fixes, de-
deprecations etc straightforward things.
I'm beginning to be quite happy with the context area merge request at 
https://invent.kde.org/multimedia/amarok/-/merge_requests/65 , myself, but 
comments on that are most welcome, as it touches the UI at multiple places (as 
does the OSD MR at https://invent.kde.org/multimedia/amarok/-/merge_requests/
73 , but not quite as extensively).
There's still something wrong with QML Image fetching photos from Flick in 
Photos applet; it gets HTTP result Forbidden for most images, even when curl 
with the same URL and with same HTTP headers works ok. This is also 
reproducible with a simple QML file run stand-alone with qmlscene-qt5. I tried 
various things, including setting up a QQmlNetworkAccessManagerFactory to use 
custom headers, but didn't have success there yet. (Maybe fetching the photos 
in the C++ engine and providing as Pixmaps to QML would be simpler.)

Additionally, I have also some other things on my list to look at before 
alpha2, but it's gotten quite a bit shorter in the last weeks.
(Open bugs/wishes have also gone from 643 to 579, with a couple of more having 
a fix pending merge.)


Scripting engine: I've had a quick look at it but didn't dive much deeper yet. 
I did some write-up on my observations when creating a fix for crash on re-
opening the script console, at https://invent.kde.org/multimedia/amarok/-/
merge_requests/76 , but I'm definitely not sure my observations are correct or 
valid. However, I guess a 3.0 can be released without complete scripting 
support (possibly disabling the KNewStuff button for scripts in settings window 
for now?)

Now that you mention the idea of scripts being QML based; I had a look at 
KSysguard SensorFaces ( https://develop.kde.org/docs/apps/sensor-faces/ ) 
listed by kpackagetool5 when I was inspecting some metadata changes, and they 
might be a possible reference in such implementation, allowing maybe also an 
uniform way for creating custom context applets. But that'd be post-3.0 
anyhow.


Embedded MariaDB: 
Although "The libmysqld embedded server library is deprecated as of MySQL 
5.7.19 and is removed in MySQL 8.0." ( https://dev.mysql.com/doc/refman/5.7/
en/libmysqld.html ), everything still seems to be available with MariaDB 11.2 
I currently have on my system.

I haven't yet found any current note of deprecation in MariaDB, at least on 
their related KB articles: 
https://mariadb.com/kb/en/embedded-mariadb-interface/ and 
https://mariadb.com/kb/en/mariadb-embedded/ , just "Starting 
with MariaDB 10.5 the embedded server library and related test binaries are no 
longer part of binary tarball release archives."

Also, there are somewhat recent changes (2 years ago) improving the embedded 
experience at https://github.com/mariadb-corporation/mariadb-connector-c/
commit/e19c93d31becad77311092f3281be5017c1b825c and the code still seems to be 
there in MariaDB 11.5 branch, too: https://github.com/MariaDB/server/tree/
11.5/libmysqld

So it would seem that while MySQL has removed the relevant pieces, MariaDB 
embedded remains usable at least for now.



Also a small comment on Phonon: 
Although a libphonon4qt6 exists, the fact that phonon-gstreamer backend is 
unsupported nowadays ( https://invent.kde.org/libraries/phonon-gstreamer/-/
issues/1 ) is not quite ideal. While phonon-vlc remains somewhat supported, 
the fact that it doesn't support ReplayGain (and some small papercut bugs) has 
kept me away from it. However, looking at https://invent.kde.org/libraries/
phonon-vlc/-/blob/master/src/audio/volumefadereffect.cpp I don't see why 
ReplayGain wouldn't be supported, so maybe I'll investigate what is actually 
the problem there before 3.0. Improving experience with phonon-vlc is a lot 
less effort than coming up with a new audio backend, anyhow.

Cheers
Tuomas



Pedro de Carvalho Gomes kirjoitti lauantaina 30. maaliskuuta 2024 23.13.51 
EEST:
> Welcome Tuomas. Thanks for you you energy to give a new boost to Amarok.
> 
> Here are some  thoughts, as I spent quite some time trying to make the
> first QT5 port:
> - the hardest thing to port from QT4 to QT5 were the plugins, as they
> were based on QTScript. I even tried to recreate it the script engine at
> QT5. But it's too much work. Not to mention that there might be security
> concerns. Maybe we should accept it, and completely drop the old
> scripting engine. And, if there's enough interest, thin

Re: Amarok - hunting for a boost

[Pedro de Carvalho Gomes]

Welcome Tuomas. Thanks for you you energy to give a new boost to Amarok.

Here are some  thoughts, as I spent quite some time trying to make the 
first QT5 port:
- the hardest thing to port from QT4 to QT5 were the plugins, as they 
were based on QTScript. I even tried to recreate it the script engine at 
QT5. But it's too much work. Not to mention that there might be security 
concerns. Maybe we should accept it, and completely drop the old 
scripting engine. And, if there's enough interest, think of a new one, 
based on QML
- a port from QT5 to QT6 doesn't seem very traumatic as it was from QT4 
to QT5. I believe this should have high priority
- as far I last saw, MariaDB-embeded was to reach end-of-life this year. 
Alternatives should be discussed immediately


Best,

Pedro

On 2024-03-23 14:16, Tuomas Nurmi wrote:

Hi everyone,

after last weekend's email, I've received encouragement, wise words and
various other forms of support from multiple people (Thank you!). I applied
for the developer access, which was granted, which is great.

I've updated the changelog today ( https://invent.kde.org/multimedia/amarok/-/
blob/master/ChangeLog ) to include some information on the changes since 2.9
(released in 2018).

In the following days/weeks, I plan to triage a number of Amarok bugs on
bugs.kde.org, and try and see if a 2.9.76 (alpha2) release can be organized in
April. If this succeeds, goal could be a beta or two and then hopefully the
long-awaited 3.0, maybe in Summer.

The focus on the road up to 3.0 should probably be on fixing bugs and trying to
ensure that everything keeps working with recent versions of required
libraries. There probably shouldn't be introduction of completely new strings
or features before 3.0 (Restoring some more functionalities lost during the
KF5 porting might be feasible. However, all my favourite functionalities are
there already, but I'll keep my eyes open in case something important comes
up).

After a KF5 based version is released, one can assess how much effort will a
Qt6/KF6 version require (fortunately, a notable amount of work to remove usage
of deprecated methods has been done during the last years, so it might not be
totally overwhelming)

Wishing you a nice Saturday, again!
Cheers
Tuomas


Tuomas Nurmi kirjoitti lauantaina 16. maaliskuuta 2024 13.00.38 EET:

Hi everyone,
according to statistics, I used Amarok to listen to a total of 111 days of
music last year. That's why I thought I'd try gathering some attention and
stirring up some discussion to get a little boost for its development
progress.

The current version 2.9.71, "3.0 Alpha" was released in February 2021.
However, there has been a notable amount of development going on since, the
current git state including additionally e.g. some functionality lost
initially between KDE4 and KF5 port replaced, fixes for crashes, support for
newer ffmpeg versions and so on. There's also (popular?) demand for a new
version, visible on e.g. the issue
https://invent.kde.org/multimedia/amarok/-/ issues/4

The fact that there hasn't been a new version tagged since also causes some
problems and disinformation to arise, with distributions packaging git at
various dates and existence of bugs depending on the git checkout date and
not the actual version number (see e.g. https://bugs.kde.org/show_bug.cgi?
id=481384 and https://bugs.kde.org/show_bug.cgi?id=08 )

Merge requests receive quite limited attention, and take a long time to get
merged. E.g. my MR!53 https://invent.kde.org/multimedia/amarok/-/
merge_requests/53 has been waiting in its current state since May 2023.
The MR freshens up the codebase a bit (without altering functionality yet)
and has received a considerable amount of testing (last year, 111 days of
playing music by me; also other people have chimed in in the MR
conversations). (Another merge request that does some similar work on e.g.
OSD related functionality is pending at
https://invent.kde.org/multimedia/amarok/-/ merge_requests/55 - it disables
some things on Wayland, where the
corresponding functionality cannot be implemented with KF5 libraries, I
believe; I've been planning to give the remaining comments some more
attention after the !53 is merged) There's also a recent simple crash fix
MR!59 by me pending at
https://invent.kde.org/multimedia/amarok/-/merge_requests/59

I also want to mention the recent nice work by Mihkel Tõnnov, whose MR!57
https://invent.kde.org/multimedia/amarok/-/merge_requests/57 fixes build
with recently released TagLib 2 and MR!60
https://invent.kde.org/multimedia/ amarok/-/merge_requests/60 which ports
things away from deprecated kcoreaddons_desktop_to_json.


I tried applying for a KDE developer access back in late 2020, but didn't
get it back then; I didn't refer to any supporter then though. I guess I
could try again sometime if needed.

In addition to code, I've had a look at the bugs at bugs.kde.org. There are
643 open bugs at the moment. However, with a quick assessment, 

Re: Amarok - hunting for a boost

[Tuomas Nurmi]

Hi everyone,

after last weekend's email, I've received encouragement, wise words and 
various other forms of support from multiple people (Thank you!). I applied 
for the developer access, which was granted, which is great.

I've updated the changelog today ( https://invent.kde.org/multimedia/amarok/-/
blob/master/ChangeLog ) to include some information on the changes since 2.9 
(released in 2018).

In the following days/weeks, I plan to triage a number of Amarok bugs on 
bugs.kde.org, and try and see if a 2.9.76 (alpha2) release can be organized in 
April. If this succeeds, goal could be a beta or two and then hopefully the 
long-awaited 3.0, maybe in Summer.

The focus on the road up to 3.0 should probably be on fixing bugs and trying to 
ensure that everything keeps working with recent versions of required 
libraries. There probably shouldn't be introduction of completely new strings 
or features before 3.0 (Restoring some more functionalities lost during the 
KF5 porting might be feasible. However, all my favourite functionalities are 
there already, but I'll keep my eyes open in case something important comes 
up).

After a KF5 based version is released, one can assess how much effort will a 
Qt6/KF6 version require (fortunately, a notable amount of work to remove usage 
of deprecated methods has been done during the last years, so it might not be 
totally overwhelming)

Wishing you a nice Saturday, again!
Cheers
Tuomas


Tuomas Nurmi kirjoitti lauantaina 16. maaliskuuta 2024 13.00.38 EET:
> Hi everyone,
> according to statistics, I used Amarok to listen to a total of 111 days of
> music last year. That's why I thought I'd try gathering some attention and
> stirring up some discussion to get a little boost for its development
> progress.
> 
> The current version 2.9.71, "3.0 Alpha" was released in February 2021.
> However, there has been a notable amount of development going on since, the
> current git state including additionally e.g. some functionality lost
> initially between KDE4 and KF5 port replaced, fixes for crashes, support for
> newer ffmpeg versions and so on. There's also (popular?) demand for a new
> version, visible on e.g. the issue
> https://invent.kde.org/multimedia/amarok/-/ issues/4
> 
> The fact that there hasn't been a new version tagged since also causes some
> problems and disinformation to arise, with distributions packaging git at
> various dates and existence of bugs depending on the git checkout date and
> not the actual version number (see e.g. https://bugs.kde.org/show_bug.cgi?
> id=481384 and https://bugs.kde.org/show_bug.cgi?id=08 )
> 
> Merge requests receive quite limited attention, and take a long time to get
> merged. E.g. my MR!53 https://invent.kde.org/multimedia/amarok/-/
> merge_requests/53 has been waiting in its current state since May 2023.
> The MR freshens up the codebase a bit (without altering functionality yet)
> and has received a considerable amount of testing (last year, 111 days of
> playing music by me; also other people have chimed in in the MR
> conversations). (Another merge request that does some similar work on e.g.
> OSD related functionality is pending at
> https://invent.kde.org/multimedia/amarok/-/ merge_requests/55 - it disables
> some things on Wayland, where the
> corresponding functionality cannot be implemented with KF5 libraries, I
> believe; I've been planning to give the remaining comments some more
> attention after the !53 is merged) There's also a recent simple crash fix
> MR!59 by me pending at
> https://invent.kde.org/multimedia/amarok/-/merge_requests/59
> 
> I also want to mention the recent nice work by Mihkel Tõnnov, whose MR!57
> https://invent.kde.org/multimedia/amarok/-/merge_requests/57 fixes build
> with recently released TagLib 2 and MR!60
> https://invent.kde.org/multimedia/ amarok/-/merge_requests/60 which ports
> things away from deprecated kcoreaddons_desktop_to_json.
> 
> 
> I tried applying for a KDE developer access back in late 2020, but didn't
> get it back then; I didn't refer to any supporter then though. I guess I
> could try again sometime if needed.
> 
> In addition to code, I've had a look at the bugs at bugs.kde.org. There are
> 643 open bugs at the moment. However, with a quick assessment, I figure
> somewhere between 200-400 could be easily closed as they're discussing a
> functionality removed since, or have otherwise become outdated. Having a new
> released version would naturally be nice here, too, but I've been planning
> to triage some of the most obviously outdated ones sometime soon.
> 
> 
> --
> 
> So, to summarize, I'd say
> - Amarok is a very nice music player and (has been one for more than two
> full decades)
> 
> - It would benefit from more hands testing and reviewing the pending pull
> requests on invent.kde.org (no special requirements, aside from the skills
> to build Amarok from git - shout out to everyone who has been doing it -
> you rock!)
> 
> - It would be awesome to 

Re: New attempt of an Alpha release

[Marian Kerler]

Hi all,
great. after long time I can hear my music with amarok again.
And the best: I compiled the first time some SW this big (I'm more the embedded 
system Engenier.) And it's works at the Moment fine.

Now I have to learn to find bugs, an reports them appropiate.

Best regrads.

Marian

Am Mittwoch, 27. Januar 2021, 22:40:52 CET schrieb Pedro de Carvalho Gomes:
> Hi all,
> 
> After long delay, finally I guess I will have the time to try to release
> the first Alpha of the KF5 port. Surely there are many bugs and things
> to polish. But apart from that, let me know if you have any concerns or
> comments.
> 
> Cheers,
> 
> Pedro

Re: New attempt of an Alpha release

[Myriam Schweingruber]

On Tue, 9 Feb 2021 at 21:45, Pedro de Carvalho Gomes 
wrote:

> Thanks Myriam! I have just hit the "send" button to announce the alpha to
> KDE's communication channels
>
> A small remark: it seems you let an orphan paragraph with text "Some
> important notes about this release:"
>
Click on "Read more" to see the full article, that is the default
publishing settings. If you want to see the full article only, I can change
this, but usually our release articles are quite long with ChangeLog
excerpts, so not very appealing for most users.

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Pedro de Carvalho Gomes]

Thanks Myriam! I have just hit the "send" button to announce the alpha 
to KDE's communication channels


A small remark: it seems you let an orphan paragraph with text "Some 
important notes about this release:"


Cheers,

Pedro

On 2021-02-08 22:58, Myriam Schweingruber wrote:




On Mon, 8 Feb 2021 at 22:44, Pedro de Carvalho Gomes 
mailto:pedrogome...@gmail.com>> wrote:


Great, thanks Myriam.  Let us know as soon as you publish, so I
can write to the announcement mailing lists

I just hit the Publish button now :-)

Regards, Myriam

--
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org 
Protect your freedom andsupport the work ofthe FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Myriam Schweingruber]

On Mon, 8 Feb 2021 at 22:44, Pedro de Carvalho Gomes 
wrote:

> Great, thanks Myriam.  Let us know as soon as you publish, so I can write
> to the announcement mailing lists
>
I just hit the Publish button now :-)

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Pedro de Carvalho Gomes]

Great, thanks Myriam.  Let us know as soon as you publish, so I can 
write to the announcement mailing lists


On 2021-02-06 14:05, Myriam Schweingruber wrote:

Sorry for being a bit slow these days, RL getting in the way...

I rephrased it to the following:

- Amarok now depends on MariaDB embedded, since MySQL embedded was 
discontinued. If you still have MySQL embedded, this will continue to 
work, as does a full MySQL Server, of course. Unfortunately we need to 
be prepared for MariaDB discontinuing the embedded version as well, 
and we are considering a port to a new DB backend;


- the script engine has been ported to Qt5's QJSEngine. Sadly the lack 
of features from Qt4's QScriptEngine makes the port limited, so there 
currently are not many scripts that are compatible. It's likely that a 
whole new scripting engine (using QML) will replace the current 
implementation.


I will publish this later today.

Regards, Myriam

--
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org 
Protect your freedom andsupport the work ofthe FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Heiko Becker]

On Wednesday, 3 February 2021 16:56:42 CET, Myriam Schweingruber wrote:

Please everyone, have a look at the article on the web page, the draft can
be found here:

https://amarok.kde.org/en/node/889


Thanks! A few notes:

* Not entirely sure how to phrase that best to avoid confusion, but there 
were *no* changes inside Amarok to discontinue support for MySQL embebbed. 
If you still have a version with it, it should work. Or if you want, with a 
full blown MySQL database server.


* "The upcoming 3.0 version will see a port to a new DB backend;"

To my knowledge, that's not (yet) true. Due to the aforementioned removal 
of the embedded lib from MySQL (and possibly from Mariadb in the future as 
a consequence) this would certainly be welcome. I heard somebody talk about 
working towards SQLite, which would also easily work in flatpaks, but 
probably comes with performance pains at least with huge collections. 
Anyway I haven't heard anything of that since quite some time.


* The new scripting engine does indeed use QML, but Pedro is the better 
person to talk to about this.


* Qt5/Qt4 looks nicer than QT5/QT4, is the official style by the QtC and 
would also be consisten with the usage in the first sentence.


Best regards,
Heiko

Re: New attempt of an Alpha release

[Myriam Schweingruber]

Sorry for being a bit slow these days, RL getting in the way...

On Thu, 4 Feb 2021 at 17:10, Pedro de Carvalho Gomes 
wrote:

> Thanks Myriam and Heiko! Here are few comments:
>
> * About the DB, I suggest the following text: "Mysql embedded has been
> discontinued, so will be MariaDB embedded in a near future. So the
> upcoming 3.0 version will see a port to a new DB backend;"
>
> * the new scripting engine does not use QML at the moment. But it
> probably will in the future because many features from Qt4 are not
> present in QJSEngine. For example, it does not export QT widgets. Thus
> scripts that contained windows or menus can't be exhibited. Using QML
> here would be the obvious alternative. But imposes big changes in the
> existing scripts.
>
> ...
>
> On 2021-02-04 12:08, Heiko Becker wrote:
> ...
> > Thanks! A few notes:
> >
> > * Not entirely sure how to phrase that best to avoid confusion, but
> > there were *no* changes inside Amarok to discontinue support for MySQL
> > embebbed. If you still have a version with it, it should work. Or if
> > you want, with a full blown MySQL database server.
> >
> > * "The upcoming 3.0 version will see a port to a new DB backend;"
> >
> > To my knowledge, that's not (yet) true. Due to the aforementioned
> > removal of the embedded lib from MySQL (and possibly from Mariadb in
> > the future as a consequence) this would certainly be welcome. I heard
> > somebody talk about working towards SQLite, which would also easily
> > work in flatpaks, but probably comes with performance pains at least
> > with huge collections. Anyway I haven't heard anything of that since
> > quite some time.
> >
> > * The new scripting engine does indeed use QML, but Pedro is the
> > better person to talk to about this.
> >
> > * Qt5/Qt4 looks nicer than QT5/QT4, is the official style by the QtC
> > and would also be consisten with the usage in the first sentence.
>

I rephrased it to the following:

- Amarok now depends on MariaDB embedded, since MySQL embedded was
discontinued. If you still have MySQL embedded, this will continue to work,
as does a full MySQL Server, of course. Unfortunately we need to be
prepared for MariaDB discontinuing the embedded version as well, and we are
considering a port to a new DB backend;

- the script engine has been ported to Qt5's QJSEngine. Sadly the lack of
features from Qt4's QScriptEngine makes the port limited, so there
currently are not many scripts that are compatible. It's likely that a
whole new scripting engine (using QML) will replace the current
implementation.

I will publish this later today.

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Pedro de Carvalho Gomes]

Thanks Myriam and Heiko! Here are few comments:

* About the DB, I suggest the following text: "Mysql embedded has been 
discontinued, so will be MariaDB embedded in a near future. So the 
upcoming 3.0 version will see a port to a new DB backend;"


* the new scripting engine does not use QML at the moment. But it 
probably will in the future because many features from Qt4 are not 
present in QJSEngine. For example, it does not export QT widgets. Thus 
scripts that contained windows or menus can't be exhibited. Using QML 
here would be the obvious alternative. But imposes big changes in the 
existing scripts.


Once Myriam publishes the release at the main page, then I will notify 
all the relevant places


Cheers,

Pedro

On 2021-02-04 12:08, Heiko Becker wrote:


On Wednesday, 3 February 2021 16:56:42 CET, Myriam Schweingruber wrote:
Please everyone, have a look at the article on the web page, the 
draft can

be found here:

https://amarok.kde.org/en/node/889


Thanks! A few notes:

* Not entirely sure how to phrase that best to avoid confusion, but 
there were *no* changes inside Amarok to discontinue support for MySQL 
embebbed. If you still have a version with it, it should work. Or if 
you want, with a full blown MySQL database server.


* "The upcoming 3.0 version will see a port to a new DB backend;"

To my knowledge, that's not (yet) true. Due to the aforementioned 
removal of the embedded lib from MySQL (and possibly from Mariadb in 
the future as a consequence) this would certainly be welcome. I heard 
somebody talk about working towards SQLite, which would also easily 
work in flatpaks, but probably comes with performance pains at least 
with huge collections. Anyway I haven't heard anything of that since 
quite some time.


* The new scripting engine does indeed use QML, but Pedro is the 
better person to talk to about this.


* Qt5/Qt4 looks nicer than QT5/QT4, is the official style by the QtC 
and would also be consisten with the usage in the first sentence.


Best regards,
Heiko

Re: Important: ChangeLog from now on, and some other reminders

[Heiko Becker]

On Wednesday, 3 February 2021 17:11:15 CET, Myriam Schweingruber wrote:

Hi all,

starting from the 2.9.0.71 tag, please use the ChangeLog again for all
major changes.

It is essential to keep track of feature additions and removals, major
commits and changes in the underlying structure (DB changes, etc.) and of
course all fixed bugs.

I sadly lost a bit track on the status of the commit hooks, so somebody
more knowledgeable than me should chime in here and provide the
necessary information, especially if there have been changes from the
previous use of hooks, as documented here:
https://invent.kde.org/multimedia/amarok
/-/blob/master/HACKING/commit-template


https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages 
is probably the canonical source of truth,  at least community wide.



It would also be useful to check on the documentation in the HACKING folder
(see above) and correct any outdated material (or ping me to tell me what
should be changed so I can do it).

The same goes for all the other mandatory files like README (very important
for dependencies like MariaDB embedded...*cough*)


I'll try to have a look tonight and adjust some outdated things.

Best regards,
Heiko

Re: New attempt of an Alpha release

[Heiko Becker]

On Wednesday, 3 February 2021 16:56:42 CET, Myriam Schweingruber wrote:

Please everyone, have a look at the article on the web page, the draft can
be found here:

https://amarok.kde.org/en/node/889


Thanks! A few notes:

* Not entirely sure how to phrase that best to avoid confusion, but there 
were *no* changes inside Amarok to discontinue support for MySQL embebbed. 
If you still have a version with it, it should work. Or if you want, with a 
full blown MySQL database server.


* "The upcoming 3.0 version will see a port to a new DB backend;"

To my knowledge, that's not (yet) true. Due to the aforementioned removal 
of the embedded lib from MySQL (and possibly from Mariadb in the future as 
a consequence) this would certainly be welcome. I heard somebody talk about 
working towards SQLite, which would also easily work in flatpaks, but 
probably comes with performance pains at least with huge collections. 
Anyway I haven't heard anything of that since quite some time.


* The new scripting engine does indeed use QML, but Pedro is the better 
person to talk to about this.


* Qt5/Qt4 looks nicer than QT5/QT4, is the official style by the QtC and 
would also be consisten with the usage in the first sentence.


Best regards,
Heiko

Re: New attempt of an Alpha release

[Heiko Becker]

Hello Myriam, hello all,

On Monday, 1 February 2021 02:26:30 CET, Myriam Schweingruber wrote:

Another question: have the translators and distributions been notified? I
know it is just an alpha release, but this would at least give them time to
prepare for future releases.
Was there an embargo notice for the tarball or was it sent as immediate
release? it's still OK to make an immediate release for an alpha, but for
any future releases we should consider an embargo period of at least two
weeks to give translators and distributions time to prepare (and for
ourselves to prepare the website and announcements)


I concurr that we should improve upon that in the future. However I don't 
think there's much harm in having it ommitted it this time. There weren't 
that many string changes and it's essentially a very rought tech preview 
intended for early testing anyway, so let distros test in advance doesn't 
make that much sense (IMO).


Best regards,
Heiko

Re: New attempt of an Alpha release

[Myriam Schweingruber]

Please everyone, have a look at the article on the web page, the draft can
be found here:

https://amarok.kde.org/en/node/889

I will wait til tomorrow to publish it on the website, unless you find
errors and/or omissions.

Regards, Myriam

On Wed, 3 Feb 2021 at 16:18, Myriam Schweingruber  wrote:

> Sorry for the late answer,
>
> On Mon, 1 Feb 2021 at 13:28, Pedro de Carvalho Gomes <
> pedrogome...@gmail.com> wrote:
>
>> Hi Myriam
>>
>> I have just written to kde-distro-packag...@kde.org. But not
>> translations. There was no embargo, and the file for 2.9.71 is already
>> available. I will be attentive to that for the next releases.
>>
>> About the release notes, it might be important to stress the facts below:
>>
>> - this alpha depends on MariaDB embedded since MySQL embedded was
>> discontinued. And that the final version shall include a port to a new DB
>> backend.
>>
>> - the script engine has been ported to the QT5's QJSEngine. But the lack
>> of features from QT4's QScriptEngine makes the port limited, and thus the
>> scripts that are compatible. It's likely that a whole new scripting engine
>> (probably using QML) might replace the current implementation
>>
> I will try to come up with something , thanks for the pointers :-)
>
> Regards, Myriam
> --
> Pronouns: she/her
> Proud member of the Amarok and KDE Community:
> https://www.kde.org
> Protect your freedom and support the work of the FSFE:
> https://www.fsfe.org 
>


-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and​ support the work of​ ​​the​ FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Heiko Becker]

On Monday, 1 February 2021 00:31:01 CET, Heiko Becker wrote:

On Sunday, 31 January 2021 23:15:19 CET, Pedro de Carvalho Gomes wrote:
I managed to figure out what changed from Kdelibs4 to KF5. I 
have updated those at release_scripts/RELEASE_HOWTO. Probably 
there are things I missed, so feel free to improve it. Up to 
now I have uploaded to the download server, and created the 
ticket:


https://phabricator.kde.org/T14088


Nice! I just moved it, so that it appears on download.kde.org:
https://download.kde.org/unstable/amarok/2.9.71/amarok-2.9.71.tar.xz.mirrorlist



Oh, I forgot one more thing. I didn't find the key you signed the tarball 
with on any keyserver (maybe I didn't look hard enough?) Can you please 
upload it, packagers will most likely ask you otherwise.

Re: New attempt of an Alpha release

[Heiko Becker]

On Sunday, 31 January 2021 23:15:19 CET, Pedro de Carvalho Gomes wrote:
I managed to figure out what changed from Kdelibs4 to KF5. I 
have updated those at release_scripts/RELEASE_HOWTO. Probably 
there are things I missed, so feel free to improve it. Up to now 
I have uploaded to the download server, and created the ticket:


https://phabricator.kde.org/T14088


Nice! I just moved it, so that it appears on download.kde.org:
https://download.kde.org/unstable/amarok/2.9.71/amarok-2.9.71.tar.xz.mirrorlist

Once the file is placed at the correct directory, I'll continue 
with the release note and notify packagers. Probably I need help 
with updating Amarok's own material: web pages, wiki, IRC 
channel... I'd appreciate if you or Myriam can help me with 
that.


I don't have access to the web page either, nor am I op of the IRC 
channels.


Best regards,
Heiko

Re: New attempt of an Alpha release

[Myriam Schweingruber]

Hi all,

On Sun, 31 Jan 2021 at 23:15, Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi Heiko,
>
> I managed to figure out what changed from Kdelibs4 to KF5. I have
> updated those at release_scripts/RELEASE_HOWTO. Probably there are
> things I missed, so feel free to improve it. Up to now I have uploaded
> to the download server, and created the ticket:
>
> https://phabricator.kde.org/T14088
>
> Once the file is placed at the correct directory, I'll continue with the
> release note and notify packagers. Probably I need help with updating
> Amarok's own material: web pages, wiki, IRC channel... I'd appreciate if
> you or Myriam can help me with that.
>
>
Great, looking forward to trying this out. I can add a release note to the
web page, any specific wishes for the text? Ditto for the IRC channels, I
can update the channel notes.

Another question: have the translators and distributions been notified? I
know it is just an alpha release, but this would at least give them time to
prepare for future releases.
Was there an embargo notice for the tarball or was it sent as immediate
release? it's still OK to make an immediate release for an alpha, but for
any future releases we should consider an embargo period of at least two
weeks to give translators and distributions time to prepare (and for
ourselves to prepare the website and announcements)

Regards, Myriam
-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: New attempt of an Alpha release

[Pedro de Carvalho Gomes]

Hi Heiko,

I managed to figure out what changed from Kdelibs4 to KF5. I have 
updated those at release_scripts/RELEASE_HOWTO. Probably there are 
things I missed, so feel free to improve it. Up to now I have uploaded 
to the download server, and created the ticket:


https://phabricator.kde.org/T14088

Once the file is placed at the correct directory, I'll continue with the 
release note and notify packagers. Probably I need help with updating 
Amarok's own material: web pages, wiki, IRC channel... I'd appreciate if 
you or Myriam can help me with that.


Cheers,

Pedro

On 2021-01-31 14:32, Heiko Becker wrote:

Hi Pedro,

do you know how? I noticed that the docs for that mostly speak about 
KDELibs4 times (which kind of makes sense, considering there wasn't a 
Qt5/KF5 release yet). If you want I could do the release and update 
the docs in the process, or if you want to do it yourself put at least 
the tarball on the download server (and save you the sysadmin ticket).


Best regards,
Heiko

On Wednesday, 27 January 2021 22:40:52 CET, Pedro de Carvalho Gomes 
wrote:

Hi all,

After long delay, finally I guess I will have the time to try to 
release the first Alpha of the KF5 port. Surely there are many bugs 
and things to polish. But apart from that, let me know if you have 
any concerns or comments.


Cheers,

Pedro

Re: New attempt of an Alpha release

[Heiko Becker]

Hi Pedro,

do you know how? I noticed that the docs for that mostly speak about 
KDELibs4 times (which kind of makes sense, considering there wasn't a 
Qt5/KF5 release yet). If you want I could do the release and update the 
docs in the process, or if you want to do it yourself put at least the 
tarball on the download server (and save you the sysadmin ticket).


Best regards,
Heiko

On Wednesday, 27 January 2021 22:40:52 CET, Pedro de Carvalho Gomes wrote:

Hi all,

After long delay, finally I guess I will have the time to try 
to release the first Alpha of the KF5 port. Surely there are 
many bugs and things to polish. But apart from that, let me know 
if you have any concerns or comments.


Cheers,

Pedro

Re: Code contributions - what's the process?

[Ben Cooksley]

On Sun, Dec 13, 2020 at 1:35 AM Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi Ben,
>

Hi all,


> Sure, I can merge Tuomas' changes till he's able to. I just did the first
> (Heiko did the other one).
>

Thanks for confirming this Pedro.
I see there are currently some active requests currently awaiting review -
have these been missed by any chance?

Thanks,
Ben

> Cheers,
>
> Pedro
> On 2020-12-12 07:24, Ben Cooksley wrote:
>
> On Thu, 10 Dec 2020, 10:37 pm Pedro de Carvalho Gomes, <
> pedrogome...@gmail.com> wrote:
>
>> Hi Tuomas,
>>
>
> Hi Pedro,
>
> Dan is sort of correct in his reply. The development has been very slow
>> the last years. As you may see, it has been 2.5 years since the last
>> release. About one year ago I have started to send contributions, to try to
>> help Amarok to get going. It's in my plans to release a new alpha version
>> this December still.
>>
>> If you want to contribute, I'd be glad to review your merge requests.
>> Also, I'd ask you to do the same with mine. In theory, that's a part of the
>> process. We should always having someone reviewing our changes before
>> merging. But given the current scenario, I also think it's fair to push the
>> changes yourself without someone's approval after a week.
>>
>
> Tuomas currently doesn't have a Developer account, so wouldn't be able to
> push the changes himself.
>
> Would you be able to review the first few reviews so we can proceed with
> getting him a Developer account?
>
> Cheers,
>>
>> Pedro
>>
>
> Thanks,
> Ben
>
>
>> On 2020-12-10 02:36, Dan Meltzer wrote:
>>
>> Hello,
>>
>> Development has pretty much ended over last 5-10 years.  You may see a
>> response from one of the general kde developers who pokes at amarok, but
>> there's not really anyone actively developing/managing the project at this
>> point, unless something has changed that I'm unaware of.
>>
>> Thanks,
>>
>> On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi  wrote:
>>
>>> Hello everyone!
>>>
>>>
>>> I recently did some small bugfixes on Amarok and submitted merge
>>> requests on
>>> invent.kde.org, but they haven't received much attention yet. I tried
>>> also on
>>> the IRC channel, but received limited response.
>>>
>>> (The merge requests are https://invent.kde.org/multimedia/amarok/-/
>>> merge_requests/17
>>>  and
>>> https://invent.kde.org/multimedia/amarok/-/
>>> merge_requests/18
>>>  -
>>> updated them to current head already a couple of times,
>>> but I'm new to gitlab, did I do it right?)
>>>
>>> The contribution how-tos I came across are out of date and contain
>>> various
>>> dead links. What's the process nowadays? What to do when I have new code
>>> &
>>> fixes submitted as merge requests, should I notify someone or send a
>>> message
>>> somewhere? I plan to keep doing some bugfixing (scratching my own itches
>>> on
>>> the KF5 version mostly) in the following weeks and months.
>>>
>>>
>>> Cheers
>>> Tuomas Nurmi
>>>
>>>
>>>
>>>

Re: To forked projects from Amarok

[Pedro de Carvalho Gomes]

Hi Sylvain,

Thanks for the nice words. We're are trying to make Amarok have a new 
release after more than two years. Still the development has been slow, 
given the short number of contributors, and that people contribute by 
their own possibilities.


Clementine and Strawberry are nice projects. But they have been forked 
away from Amarok too long ago. Thus, it's not trivial for any project to 
directly benefit from the other. But if any developer from either shows 
such interest, I'd be glad to discuss possibilities.


Cheers,

Pedro

On 2020-12-20 21:38, Sylvain S wrote:

Hi there.

Amarok is for sure my favourite music player of all time.
I've been very happy to see that it came back with the original neat interface.

In the meantime, while it was not attended for very much, I have
found two other projects forked from it that happened to carry on their own :
Clementine and Strawberry.

https://www.strawberrymusicplayer.org/
https://github.com/strawberrymusicplayer/strawberry

https://www.clementine-player.org/
https://github.com/clementine-player/Clementine

I have notified on both github projects pages that Amaro is back.
Perhaps some effort could be gained from investigating what changes/upgrade
were made by these maintainers ?

Thanks to all

Sylvain S

Re: Code contributions - what's the process?

[Tuomas Nurmi]

Hi everyone!

I've been following the replies but just realized I forgot to answer yet.
Thank you for your responses, everyone, and thank you for the merges Heiko & 
Pedro!
Reviewing merge requests, alpha version in December: Sounds good, I'm happy to 
help.
(Gazing through Amarok changelog, I see I was a bit more active during late 
'00's and not that much during the last decade, but I think I'll do more 
contributing on this decade, again :D)

Have a nice week!
Tuomas


Pedro de Carvalho Gomes kirjoitti lauantaina 12. joulukuuta 2020 14.35.25 EET:
> Hi Ben,
> 
> Sure, I can merge Tuomas' changes till he's able to. I just did the
> first (Heiko did the other one).
> 
> Cheers,
> 
> Pedro
> 
> On 2020-12-12 07:24, Ben Cooksley wrote:
> > On Thu, 10 Dec 2020, 10:37 pm Pedro de Carvalho Gomes,
> > 
> > mailto:pedrogome...@gmail.com>> wrote:
> > Hi Tuomas,
> > 
> > Hi Pedro,
> > 
> > Dan is sort of correct in his reply. The development has been very
> > slow the last years. As you may see, it has been 2.5 years since
> > the last release. About one year ago I have started to send
> > contributions, to try to help Amarok to get going. It's in my
> > plans to release a new alpha version this December still.
> > 
> > If you want to contribute, I'd be glad to review your merge
> > requests. Also, I'd ask you to do the same with mine. In theory,
> > that's a part of the process. We should always having someone
> > reviewing our changes before merging. But given the current
> > scenario, I also think it's fair to push the changes yourself
> > without someone's approval after a week.
> > 
> > Tuomas currently doesn't have a Developer account, so wouldn't be able
> > to push the changes himself.
> > 
> > Would you be able to review the first few reviews so we can proceed
> > with getting him a Developer account?
> > 
> > Cheers,
> > 
> > Pedro
> > 
> > Thanks,
> > Ben
> > 
> > On 2020-12-10 02:36, Dan Meltzer wrote:
> >> Hello,
> >> 
> >> Development has pretty much ended over last 5-10 years.  You may
> >> see a response from one of the general kde developers who pokes
> >> at amarok, but there's not really anyone actively
> >> developing/managing the project at this point, unless something
> >> has changed that I'm unaware of.
> >> 
> >> Thanks,
> >> 
> >> On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi  >> 
> >> > wrote:
> >> Hello everyone!
> >> 
> >> 
> >> I recently did some small bugfixes on Amarok and submitted
> >> merge requests on
> >> invent.kde.org , but they haven't
> >> received much attention yet. I tried also on
> >> the IRC channel, but received limited response.
> >> 
> >> (The merge requests are
> >> https://invent.kde.org/multimedia/amarok/-/
> >> merge_requests/17
> >> 
> >> and https://invent.kde.org/multimedia/amarok/-/
> >> merge_requests/18
> >> 
> >> - updated them to current head already a couple of times,
> >> but I'm new to gitlab, did I do it right?)
> >> 
> >> The contribution how-tos I came across are out of date and
> >> contain various
> >> dead links. What's the process nowadays? What to do when I
> >> have new code &
> >> fixes submitted as merge requests, should I notify someone or
> >> send a message
> >> somewhere? I plan to keep doing some bugfixing (scratching my
> >> own itches on
> >> the KF5 version mostly) in the following weeks and months.
> >> 
> >> 
> >> Cheers
> >> Tuomas Nurmi

Re: Activitifilter for invent notifications

[Heiko Becker]

Hi Myriam, hi all,

On 11.12.20 12:58, Myriam Schweingruber wrote:

Hi all,

as you can see here: https://invent.kde.org/sysadmin/activityfilter 

to get notifications about commits and merge requests directly into this 
mailing list, we need to create a thread to make sure everybody is 
comfortable with.


[..]

I suggest the following activity to be sent to the mailing list:
Commits
Issues
Merge Requests


While I like the reduced volume for the plasma and kde-frameworks lists, I 
don't really have an opinion on Merge Requests and Issues (depends on what 
the latter are used for, considering bugs.kde.org is still the intended bug 
tracker and amarok-bugs exist) here, but I do think that a mail to the 
mailing list for *every* commit is too much. While development currently 
might be slow its still conceivable that huge batches might appear in the 
future, without that being interesting for everyone subscribed. The ones 
interested in that level of detail could still configure a personal 
activity filter or use gitlab's notifications.


Regards,
Heiko

Re: Code contributions - what's the process?

[Pedro de Carvalho Gomes]

Hi Ben,

Sure, I can merge Tuomas' changes till he's able to. I just did the 
first (Heiko did the other one).


Cheers,

Pedro

On 2020-12-12 07:24, Ben Cooksley wrote:
On Thu, 10 Dec 2020, 10:37 pm Pedro de Carvalho Gomes, 
mailto:pedrogome...@gmail.com>> wrote:


Hi Tuomas,


Hi Pedro,

Dan is sort of correct in his reply. The development has been very
slow the last years. As you may see, it has been 2.5 years since
the last release. About one year ago I have started to send
contributions, to try to help Amarok to get going. It's in my
plans to release a new alpha version this December still.

If you want to contribute, I'd be glad to review your merge
requests. Also, I'd ask you to do the same with mine. In theory,
that's a part of the process. We should always having someone
reviewing our changes before merging. But given the current
scenario, I also think it's fair to push the changes yourself
without someone's approval after a week.


Tuomas currently doesn't have a Developer account, so wouldn't be able 
to push the changes himself.


Would you be able to review the first few reviews so we can proceed 
with getting him a Developer account?


Cheers,

Pedro


Thanks,
Ben


On 2020-12-10 02:36, Dan Meltzer wrote:

Hello,

Development has pretty much ended over last 5-10 years.  You may
see a response from one of the general kde developers who pokes
at amarok, but there's not really anyone actively
developing/managing the project at this point, unless something
has changed that I'm unaware of.

Thanks,

On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi mailto:tuo...@norsumanageri.org>> wrote:

Hello everyone!


I recently did some small bugfixes on Amarok and submitted
merge requests on
invent.kde.org , but they haven't
received much attention yet. I tried also on
the IRC channel, but received limited response.

(The merge requests are
https://invent.kde.org/multimedia/amarok/-/
merge_requests/17

and https://invent.kde.org/multimedia/amarok/-/
merge_requests/18

- updated them to current head already a couple of times,
but I'm new to gitlab, did I do it right?)

The contribution how-tos I came across are out of date and
contain various
dead links. What's the process nowadays? What to do when I
have new code &
fixes submitted as merge requests, should I notify someone or
send a message
somewhere? I plan to keep doing some bugfixing (scratching my
own itches on
the KF5 version mostly) in the following weeks and months.


Cheers
Tuomas Nurmi

Re: Code contributions - what's the process?

[Ben Cooksley]

On Thu, 10 Dec 2020, 10:37 pm Pedro de Carvalho Gomes, <
pedrogome...@gmail.com> wrote:

> Hi Tuomas,
>

Hi Pedro,

Dan is sort of correct in his reply. The development has been very slow the
> last years. As you may see, it has been 2.5 years since the last release.
> About one year ago I have started to send contributions, to try to help
> Amarok to get going. It's in my plans to release a new alpha version this
> December still.
>
> If you want to contribute, I'd be glad to review your merge requests.
> Also, I'd ask you to do the same with mine. In theory, that's a part of the
> process. We should always having someone reviewing our changes before
> merging. But given the current scenario, I also think it's fair to push the
> changes yourself without someone's approval after a week.
>

Tuomas currently doesn't have a Developer account, so wouldn't be able to
push the changes himself.

Would you be able to review the first few reviews so we can proceed with
getting him a Developer account?

Cheers,
>
> Pedro
>

Thanks,
Ben


> On 2020-12-10 02:36, Dan Meltzer wrote:
>
> Hello,
>
> Development has pretty much ended over last 5-10 years.  You may see a
> response from one of the general kde developers who pokes at amarok, but
> there's not really anyone actively developing/managing the project at this
> point, unless something has changed that I'm unaware of.
>
> Thanks,
>
> On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi  wrote:
>
>> Hello everyone!
>>
>>
>> I recently did some small bugfixes on Amarok and submitted merge requests
>> on
>> invent.kde.org, but they haven't received much attention yet. I tried
>> also on
>> the IRC channel, but received limited response.
>>
>> (The merge requests are https://invent.kde.org/multimedia/amarok/-/
>> merge_requests/17
>>  and
>> https://invent.kde.org/multimedia/amarok/-/
>> merge_requests/18
>>  - updated
>> them to current head already a couple of times,
>> but I'm new to gitlab, did I do it right?)
>>
>> The contribution how-tos I came across are out of date and contain
>> various
>> dead links. What's the process nowadays? What to do when I have new code
>> &
>> fixes submitted as merge requests, should I notify someone or send a
>> message
>> somewhere? I plan to keep doing some bugfixing (scratching my own itches
>> on
>> the KF5 version mostly) in the following weeks and months.
>>
>>
>> Cheers
>> Tuomas Nurmi
>>
>>
>>
>>

Re: Activitifilter for invent notifications

[Erik Hovland]

Sounds like a great idea. OK by me.

Thanks

Erik

On Fri, Dec 11, 2020 at 3:59 AM Myriam Schweingruber  wrote:

> Hi all,
>
> as you can see here: https://invent.kde.org/sysadmin/activityfilter
> to get notifications about commits and merge requests directly into this
> mailing list, we need to create a thread to make sure everybody is
> comfortable with.
>
> So please, everyone, step up and voice your consent and/or concerns about
> this feature.
>
> PRO: we would, as in the past, get automatic notifications of commit
> messages and Merge Requests (including the followup discussions) to this
> mailing list.
> CON: this discussion is set up mainly for privacy concerns, as mailing
> lists are public and it would be much more work for the sysadmins if they
> had to clean up messages from the mailing list archives if somebody wanted
> their messages to be erased.
>
> I suggest the following activity to be sent to the mailing list:
> Commits
> Issues
> Merge Requests
>
> FWIW: we had this in the past and it truly makes it much easier to follow
> and handle development.
> Regards, Myriam
>
> --
> Pronouns: she/her
> Proud member of the Amarok and KDE Community:
> https://www.kde.org
> Protect your freedom and support the work of the FSFE:
> https://www.fsfe.org 
>


-- 
Erik Hovland
e...@hovland.org
http://hovland.org/

Re: Activitifilter for invent notifications

[Kerler Marian]

Hi, maybe a Others Newsletter Like system, but the notifications to this 
Mailinglist is OK for me.

MfG
Kerler Marian

Am 11. Dezember 2020 12:58:53 MEZ schrieb Myriam Schweingruber :
>Hi all,
>
>as you can see here: https://invent.kde.org/sysadmin/activityfilter
>to get notifications about commits and merge requests directly into
>this
>mailing list, we need to create a thread to make sure everybody is
>comfortable with.
>
>So please, everyone, step up and voice your consent and/or concerns
>about
>this feature.
>
>PRO: we would, as in the past, get automatic notifications of commit
>messages and Merge Requests (including the followup discussions) to
>this
>mailing list.
>CON: this discussion is set up mainly for privacy concerns, as mailing
>lists are public and it would be much more work for the sysadmins if
>they
>had to clean up messages from the mailing list archives if somebody
>wanted
>their messages to be erased.
>
>I suggest the following activity to be sent to the mailing list:
>Commits
>Issues
>Merge Requests
>
>FWIW: we had this in the past and it truly makes it much easier to
>follow
>and handle development.
>Regards, Myriam
>
>-- 
>Pronouns: she/her
>Proud member of the Amarok and KDE Community:
>https://www.kde.org
>Protect your freedom and support the work of the FSFE:
>https://www.fsfe.org 

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Code contributions - what's the process?

[Ben Cooksley]

On Fri, Dec 11, 2020 at 2:51 AM Myriam Schweingruber  wrote:

> Hi all,
>

Hi Myriam,


>
> On Thu, 10 Dec 2020 at 10:37, Pedro de Carvalho Gomes <
> pedrogome...@gmail.com> wrote:
>
>> Hi Tuomas,
>>
>> Dan is sort of correct in his reply. The development has been very slow
>> the last years. As you may see, it has been 2.5 years since the last
>> release. About one year ago I have started to send contributions, to try to
>> help Amarok to get going. It's in my plans to release a new alpha version
>> this December still.
>>
>> If you want to contribute, I'd be glad to review your merge requests.
>> Also, I'd ask you to do the same with mine. In theory, that's a part of the
>> process. We should always having someone reviewing our changes before
>> merging. But given the current scenario, I also think it's fair to push the
>> changes yourself without someone's approval after a week.
>>
> FWIW: I think we were not aware of the merge requests until you mentioned
> it in the bug report. I haven't found a way to make merge requests appear
> in the devel mailing list, so it is usually a good idea to actually talk
> about it here for the time being.
> If anyone has an idea how I can get all notifications from invent to show
> up in this mailing list I would be glad to know
>

Please see https://invent.kde.org/sysadmin/activityfilter

Cheers,
Ben


>
> Regards, Myriam
>
> --
> Pronouns: she/her
> Proud member of the Amarok and KDE Community:
> https://www.kde.org
> Protect your freedom and support the work of the FSFE:
> https://www.fsfe.org 
>

Re: Code contributions - what's the process?

[Myriam Schweingruber]

Hi all,

On Thu, 10 Dec 2020 at 10:37, Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi Tuomas,
>
> Dan is sort of correct in his reply. The development has been very slow
> the last years. As you may see, it has been 2.5 years since the last
> release. About one year ago I have started to send contributions, to try to
> help Amarok to get going. It's in my plans to release a new alpha version
> this December still.
>
> If you want to contribute, I'd be glad to review your merge requests.
> Also, I'd ask you to do the same with mine. In theory, that's a part of the
> process. We should always having someone reviewing our changes before
> merging. But given the current scenario, I also think it's fair to push the
> changes yourself without someone's approval after a week.
>
FWIW: I think we were not aware of the merge requests until you mentioned
it in the bug report. I haven't found a way to make merge requests appear
in the devel mailing list, so it is usually a good idea to actually talk
about it here for the time being.
If anyone has an idea how I can get all notifications from invent to show
up in this mailing list I would be glad to know

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: Code contributions - what's the process?

[Pedro de Carvalho Gomes]

Hi Tuomas,

Dan is sort of correct in his reply. The development has been very slow 
the last years. As you may see, it has been 2.5 years since the last 
release. About one year ago I have started to send contributions, to try 
to help Amarok to get going. It's in my plans to release a new alpha 
version this December still.


If you want to contribute, I'd be glad to review your merge requests. 
Also, I'd ask you to do the same with mine. In theory, that's a part of 
the process. We should always having someone reviewing our changes 
before merging. But given the current scenario, I also think it's fair 
to push the changes yourself without someone's approval after a week.


Cheers,

Pedro

On 2020-12-10 02:36, Dan Meltzer wrote:

Hello,

Development has pretty much ended over last 5-10 years.  You may see a 
response from one of the general kde developers who pokes at amarok, 
but there's not really anyone actively developing/managing the project 
at this point, unless something has changed that I'm unaware of.


Thanks,

On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi > wrote:


Hello everyone!


I recently did some small bugfixes on Amarok and submitted merge
requests on
invent.kde.org , but they haven't received
much attention yet. I tried also on
the IRC channel, but received limited response.

(The merge requests are https://invent.kde.org/multimedia/amarok/-/
merge_requests/17
 and
https://invent.kde.org/multimedia/amarok/-/
merge_requests/18
 -
updated them to current head already a couple of times,
but I'm new to gitlab, did I do it right?)

The contribution how-tos I came across are out of date and contain
various
dead links. What's the process nowadays? What to do when I have
new code &
fixes submitted as merge requests, should I notify someone or send
a message
somewhere? I plan to keep doing some bugfixing (scratching my own
itches on
the KF5 version mostly) in the following weeks and months.


Cheers
Tuomas Nurmi

Re: Code contributions - what's the process?

[Dan Meltzer]

Hello,

Development has pretty much ended over last 5-10 years.  You may see a
response from one of the general kde developers who pokes at amarok, but
there's not really anyone actively developing/managing the project at this
point, unless something has changed that I'm unaware of.

Thanks,

On Wed, Dec 9, 2020, 16:41 Tuomas Nurmi  wrote:

> Hello everyone!
>
>
> I recently did some small bugfixes on Amarok and submitted merge requests
> on
> invent.kde.org, but they haven't received much attention yet. I tried
> also on
> the IRC channel, but received limited response.
>
> (The merge requests are https://invent.kde.org/multimedia/amarok/-/
> merge_requests/17
>  and
> https://invent.kde.org/multimedia/amarok/-/
> merge_requests/18
>  - updated
> them to current head already a couple of times,
> but I'm new to gitlab, did I do it right?)
>
> The contribution how-tos I came across are out of date and contain various
> dead links. What's the process nowadays? What to do when I have new code &
> fixes submitted as merge requests, should I notify someone or send a
> message
> somewhere? I plan to keep doing some bugfixing (scratching my own itches
> on
> the KF5 version mostly) in the following weeks and months.
>
>
> Cheers
> Tuomas Nurmi
>
>
>
>

Re: [KDE/amarok] Replace qtscript with qt qml (#10)

[Myriam Schweingruber]

Hi Pedro,

On Mon, 21 Sep 2020 at 22:55, Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi Myrian,
>
> I deeply apologize. But as I have told you before, I am not directly
> creating these PR to the official Amarok mirror at Github. I can see
> that these are triggered when I push to my personal repo, but I couldn't
> identify more than this yet.
>
> I'll send more time investigating this, so I don't disturb it further
>
> Why don't you use a branch on our gitlab instance instead for your Amarok
work? You can use this as much as a gitlab personal repository, and it
would avoid causing this kind of "side-effects".

Regards, Myriam


-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: [KDE/amarok] Replace qtscript with qt qml (#10)

[Pedro de Carvalho Gomes]

Hi Myrian,

I deeply apologize. But as I have told you before, I am not directly 
creating these PR to the official Amarok mirror at Github. I can see 
that these are triggered when I push to my personal repo, but I couldn't 
identify more than this yet.


I'll send more time investigating this, so I don't disturb it further

Pedro

Den 2020-09-21 kl. 18:11, skrev Myriam Schweingruber:
really? Please, please verify where you pull or push, the Github 
mirror of KDE is definitely the wrong place


Regards, Myriam

On Mon, 21 Sep 2020 at 15:53, Pedro Gomes > wrote:


@pcgomes  pushed 45 commits.

  * 848286f


Merge pull request #29 from pcgomes/replace_Qtscript_with_QtQml
  * 6aebf1f


Use https for bugs.kde.org 
  * 2b62863


Merge pull request #30 from pcgomes/replace_Qtscript_with_QtQml
  * 5f51f43


Update README
  * e980395


Update README
  * 5b8e981


Merge pull request #31 from pcgomes/replace_Qtscript_with_QtQml
  * 7aed1c2


configurePhonon needs to display kcm_pulseaudio module rather
than kcm_phonon.
  * 99b74f1


Fix compilation error for older Qt versions
  * 03536f7


Merge pull request #33 from RobertAJMarshall/fixScriptCompile
  * 252eafa


Merge pull request #32 from RobertAJMarshall/fixPhononConfig
  * 3ac1d3b


Amarok 2.9.70+1SNAPSHOT20200630174341+0200
  * 1c4b8ef


Merge pull request #34 from
pcgomes/2.9.70+1SNAPSHOT20200630174341+0200
  * 99653e7


Amarok 2.9.70+1SNAPSHOT20200630174341+0200
  * cee1427


Merge branch '2.9.70+1SNAPSHOT20200630174341+0200' of
https://github.com/pcgomes/amarok into
2.9.70+1SNAPSHOT20200630174341+0200
  * 9445ba8


2.9.70+1SNAPSHOT20200630174341+0200
  * 3739558


Merge pull request #35 from
pcgomes/2.9.70+1SNAPSHOT20200630174341+0200
  * 6a3ba0c


Merge pull request #36 from pcgomes/replace_Qtscript_with_QtQml
  * 7c91e0e


Amarok 2.9.70+1SNAPSHOT20200701124447+0200
  * 7d8d2e4


Merge pull request #37 from
pcgomes/2.9.70+1SNAPSHOT20200701124447+0200
  * 358dcf3


Drop old copy of Qt modeltest
  * aead085


qVariantFromValue() -> QVariant::fromValue()
  * 12a162e


Remove metadependency that breaks Neon
  * 8ee1993


Merge pull request #38 from
pcgomes/2.9.70+1SNAPSHOT20200703102146+0200
  * 5678b64


SVN_SILENT made messages (.desktop file) - always resolve ours
  * 0e2ef25


SVN_SILENT made messages (.desktop file) - always resolve ours
  * fb5b5ab

Re: [KDE/amarok] Replace qtscript with qt qml (#10)

[Myriam Schweingruber]

really? Please, please verify where you pull or push, the Github mirror of
KDE is definitely the wrong place

Regards, Myriam

On Mon, 21 Sep 2020 at 15:53, Pedro Gomes  wrote:

> @pcgomes  pushed 45 commits.
>
>- 848286f
>
> 
>Merge pull request #29 from pcgomes/replace_Qtscript_with_QtQml
>- 6aebf1f
>
> 
>Use https for bugs.kde.org
>- 2b62863
>
> 
>Merge pull request #30 from pcgomes/replace_Qtscript_with_QtQml
>- 5f51f43
>
> 
>Update README
>- e980395
>
> 
>Update README
>- 5b8e981
>
> 
>Merge pull request #31 from pcgomes/replace_Qtscript_with_QtQml
>- 7aed1c2
>
> 
>configurePhonon needs to display kcm_pulseaudio module rather than
>kcm_phonon.
>- 99b74f1
>
> 
>Fix compilation error for older Qt versions
>- 03536f7
>
> 
>Merge pull request #33 from RobertAJMarshall/fixScriptCompile
>- 252eafa
>
> 
>Merge pull request #32 from RobertAJMarshall/fixPhononConfig
>- 3ac1d3b
>
> 
>Amarok 2.9.70+1SNAPSHOT20200630174341+0200
>- 1c4b8ef
>
> 
>Merge pull request #34 from pcgomes/2.9.70+1SNAPSHOT20200630174341+0200
>- 99653e7
>
> 
>Amarok 2.9.70+1SNAPSHOT20200630174341+0200
>- cee1427
>
> 
>Merge branch '2.9.70+1SNAPSHOT20200630174341+0200' of
>https://github.com/pcgomes/amarok into
>2.9.70+1SNAPSHOT20200630174341+0200
>- 9445ba8
>
> 
>2.9.70+1SNAPSHOT20200630174341+0200
>- 3739558
>
> 
>Merge pull request #35 from pcgomes/2.9.70+1SNAPSHOT20200630174341+0200
>- 6a3ba0c
>
> 
>Merge pull request #36 from pcgomes/replace_Qtscript_with_QtQml
>- 7c91e0e
>
> 
>Amarok 2.9.70+1SNAPSHOT20200701124447+0200
>- 7d8d2e4
>
> 
>Merge pull request #37 from pcgomes/2.9.70+1SNAPSHOT20200701124447+0200
>- 358dcf3
>
> 
>Drop old copy of Qt modeltest
>- aead085
>
> 
>qVariantFromValue() -> QVariant::fromValue()
>- 12a162e
>
> 
>Remove metadependency that breaks Neon
>- 8ee1993
>
> 
>Merge pull request #38 from pcgomes/2.9.70+1SNAPSHOT20200703102146+0200
>- 5678b64
>
> 
>SVN_SILENT made messages (.desktop file) - always resolve ours
>- 0e2ef25
>
> 
>SVN_SILENT made messages (.desktop file) - always resolve ours
>- fb5b5ab
>
> 
>SVN_SILENT made messages (.desktop file) - always resolve ours
>- df34fd7
>
> 
>Summary: Fix crash when closing dialog to edit filter
>- 4ae1085
>
> 
>Fix breadcrumb widget for left menu
>- 3b5d5e1
>
> 
>appdata: use canonical help URL
>- bf340b7
>
> 

Re: [KDE/amarok] Replace qtscript with qt qml (#10)

[Myriam Schweingruber]

Hi Pedro,

is there a reason you made these pull requests on Github? Github is only a
mirror of the KDE repositories, the git instance we now use is on Gitlab...

Regards, Myriam

On Wed, 16 Sep 2020 at 16:44, Pedro Gomes  wrote:

> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/KDE/amarok/pull/10
> Commit Summary
>
>- Restore compilation job and fix old dependency to
>amarok_lastfm_shared_export.h
>- Restore compilation job and fix old dependency to
>amarok_lastfm_shared_export.h
>- Remove unsupported neighbour method, remove deprecated groups ref and
>- Remove remaining references to neighbours
>- Fix segfault when destroying LastFmService
>- Merge pull request #1 from pcgomes/lastfm_service
>- Replaced static exports with a generated export header
>- Merge pull request #2 from pcgomes/lastfm_service
>- Fix crash for wrongly connecting Token::destroyed signal
>- Fix dialog's layout and resizing
>- Fix double dialog box for transcoding
>- Merge pull request #3 from pcgomes/fix_import_to_collecton
>- Fix Copying dialog at filebrowser to open
>- Fix importing of files to local collection
>- Fix sizing issues and wrong layout
>- Remove include to removed widget
>- Merge pull request #4 from pcgomes/fix_import_to_collecton
>- Merge branch 'master' of /home/pedro/tmp/amarok-cgit
>- Merge branch 'master' of /home/pedro/tmp/amarok-official
>- Added config for .deb package for Kubuntu 19.10
>- Merge pull request #5 from pcgomes/packaging_for_kubuntu_19.10
>- Merge branch 'master' of amarok-gitlab
>- Added info about unstable repo
>- Merge pull request #6 from pcgomes/update_description
>- Merge branch 'master' of /home/pedro/tmp/amarok-gitlab
>- Fix the define used to distinguish MariaDB from Mysql
>- Merge pull request #7 from pcgomes/fix_detection_mariadb_10.1
>- Merge branch 'master' of /home/pedro/tmp/amarok-gitlab
>- Add dockerfiles for cross-distro builds
>- Merge pull request #8 from pcgomes/add_dockerfiles
>- Merge branch 'master' of /home/pedro/tmp/amarok-gitlab
>- Fix Breadcrumb widget
>- Merge pull request #9 from pcgomes/fix_breadcumb_widget_spacing
>- Fix Dockerfile to use master branch
>- Merge pull request #10 from pcgomes/add_dockerfiles
>- Added Ubuntu 20.04 Dockerfile
>- Merge pull request #11 from pcgomes/add_dockerfiles
>- Add missing compat package for Mariadb
>- Merge pull request #12 from pcgomes/dockerfiles
>- Fix stylesheet
>- Reorganized packaging and Dockerfiles
>- Merge pull request #13 from pcgomes/fix_playlistdock
>- Merge pull request #14 from pcgomes/distribution
>- Fixed changelogs
>- Merge pull request #15 from pcgomes/distribution
>- SVN_SILENT made messages (.desktop file) - always resolve ours
>- Replaced QtScript* refs with QJS* and added class to replace
>QTScriptEngineDebugger
>- Merge branch 'master' of https://invent.kde.org/kde/amarok
>- Merge pull request #16 from pcgomes/distribution
>- Change minor version to 70 to avoid conflict with other ppas
>- Merge pull request #17 from pcgomes/distribution
>- Replaced QtScript* refs with QJS* and added class to replace
>QTScriptEngineDebugger
>- Fix breadcumb widget
>- Merge branch 'master' into fix_breadcumb_widget
>- Merge pull request #18 from pcgomes/fix_breadcumb_widget
>- Merge branch 'replace_Qtscript_with_QtQml' of
>https://github.com/pcgomes/amarok into replace_Qtscript_with_QtQml
>- - Fixed several qScriptRegisterMetaType with lambda-functions
>- First compiling version
>- Functioning script console
>- First functional version with radio station service script
>- Merge branch 'master' of https://invent.kde.org/multimedia/amarok
>- Summary: Fix crash when closing dialog to edit filter
>- Merge pull request #19 from
>pcgomes/bug_421456-crash_when_exiting_edit_filter_dialog
>- * Set new release 2.9.70+1SNAPSHOT20200612103823+0200
>- Merge pull request #20 from pcgomes/distribution
>- Added missing time and author to changelogs
>- Merge pull request #21 from pcgomes/distribution
>- Fix forgotten versions at changelog files
>- Merge pull request #22 from pcgomes/distribution
>- Replaced QtScript* refs with QJS* and added class to replace
>QTScriptEngineDebugger
>- - Fixed several qScriptRegisterMetaType with lambda-functions
>- First compiling version
>- Functioning script console
>- First functional version with radio station service script
>- Merge branch 'master' of https://invent.kde.org/multimedia/amarok
>- Merge branch 'master' of https://github.com/pcgomes/amarok
>- Fix crash when changing from categories with child submenu
>- Merge pull request #23 from pcgomes/fix_breadcumb_widget
>- Release 

Re: amarok.po just a small detail

[Myriam Schweingruber]

On Wed, 19 Aug 2020 at 09:10, Albert Astals Cid  wrote:

> El dimarts, 18 d’agost de 2020, a les 21:55:40 CEST, Iñigo Salvador
> Azurmendi va escriure:
> > Hello,
> >
> >
> > Translating   amarok.po  I have found this two strings:
> >
> >
> > #92Whether to show background images in the browser pane
> >
> >
> >
> > #505  Show background images in the browser panel
> >
> >
> >
> >
> > «pane» and «panel» have different translations (pane <> panel).
> > Is this on purpouse or is it a typo ?
>
> It's a typo, both should be pane or both should be panel, since both are
> referring to the same thing.
>
>
> This is indeed a typo, both should be pane, as it refers to the Context
View pane in the middle.

Thanks for spotting this.

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: amarok.po just a small detail

[Albert Astals Cid]

El dimarts, 18 d’agost de 2020, a les 21:55:40 CEST, Iñigo Salvador Azurmendi 
va escriure:
> Hello,
> 
> 
> Translating   amarok.po  I have found this two strings:
> 
> 
> #92Whether to show background images in the browser pane
> 
> 
> 
> #505  Show background images in the browser panel
> 
> 
> 
> 
> «pane» and «panel» have different translations (pane <> panel).
> Is this on purpouse or is it a typo ?

It's a typo, both should be pane or both should be panel, since both are 
referring to the same thing.

Cheers,
  Albert

> 
> 
> Thank you.
> 
> 

Re: Amarok scripting port to QJSEngine concluded

[Myriam Schweingruber]

Hi Pedro,

On Tue, 21 Jul 2020 at 11:28, Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi all,,
>
> Here follows a brief update about my work at Amarok scripting engine. I
> have ported back Amarok.Lyrics interface, and have been writing my own
> QTScript extensions. With that I plan to have previous scripts, such as
> Ultimate Lyrics, running over QJSEngine without any modification.
>
> The port of QTScript extensions is not easy; I have to do it
> class-by-class upon usage at the scripts. Therefore I will select few of
> the most popular scripts and only port the classes/methods needed by
> those. Other scripts and their requirements will be ported upon requests.


As long as you port the built-in scripts that should be enough. You can
always contact the authors of the original scripts if they would give a
hand, as most scripts are 3rd-party anyway

Finally, I ask the other member about the revision process. I know we
> have shortage of people. Still many merge requests are simply not moving
> forward.


I know, but unfortunately I can't really help with this, as I am not a
developer.

> Thus I ask if there's something I can do to speed it up, such
> as publish at Phabricator. Or even if I anyone oppose to the policy of
> merging without peer approval if no response for more than X weeks.
>

Since the switch to Gitlab, Phabricator should not be used anymore for new
merge requests, as https://invent.kde.org/ boards should ultimately replace
it. Also not all old merge requests are necessarily to be integrated AFAIK,
I seem to remember at least one being not exactly up to date with current
git master.

I can acknowledge your merge requests if you want though, it will just not
really be a code review. If the tests run smoothly and the merges are not
likely to break Continuous Integration I think you should go ahead.

Regards, Myriam

-- 
Pronouns: she/her
Proud member of the Amarok and KDE Community:
https://www.kde.org
Protect your freedom and support the work of the FSFE:
https://www.fsfe.org 

Re: Amarok scripting port to QJSEngine concluded

[Pedro de Carvalho Gomes]

Hi all,,

Here follows a brief update about my work at Amarok scripting engine. I 
have ported back Amarok.Lyrics interface, and have been writing my own 
QTScript extensions. With that I plan to have previous scripts, such as 
Ultimate Lyrics, running over QJSEngine without any modification.


The port of QTScript extensions is not easy; I have to do it 
class-by-class upon usage at the scripts. Therefore I will select few of 
the most popular scripts and only port the classes/methods needed by 
those. Other scripts and their requirements will be ported upon requests.


Finally, I ask the other member about the revision process. I know we 
have shortage of people. Still many merge requests are simply not moving 
forward. Thus I ask if there's something I can do to speed it up, such 
as publish at Phabricator. Or even if I anyone oppose to the policy of 
merging without peer approval if no response for more than X weeks.


Regards,

Pedro

Den 2020-06-24 kl. 11:34, skrev Pedro de Carvalho Gomes:

Hi all,

I have concluded the port from QTScript, which is deprecated, to
QJSEngine. I tried to mimic the old script behavior as close as
possible, and I think I mostly succeeded.

Few things couldn't be ported yet. Here are the most important ones:

- QJSEngine doesn't have a script debugger widget. Such was used by
the script console. Probably it can be reimplemented by reusing the
QML debugger from KDevelop.

-  QJSEngine doesn't have an equivalent to QTScript's extensions,
which are loaded with Importer.loadQtBinding (qt.core, qt.network,
qt.gui, etc). I believe it's possible to simulate those by exporting
classes from those packages (If I find a list of which class is at
which package, things would be easier).

- Amarok.Lyrics had been removed from the scripting API when the new
C++ lyrics engine was added. I think it should be restored it and
combined it with the current lyrics engine

I believe the code is in good shape, and may be incorporated to
master. And thus shipped with the next alpha release for testing. Here
is the link to merge request:

https://invent.kde.org/multimedia/amarok/-/merge_requests/9

If you want to try it, I have created packages for Ubuntu 18.04, 19,10
and 20.04:
https://launchpad.net/~pgomes/+archive/ubuntu/amarok/+packages

I also provided few Dockerfiles for trying in other distros:
https://github.com/pcgomes/amarok/tree/master/distribution/docker

As usual, all feedback and support is welcome.

Cheer,

Pedro

Re: Replacement of QTScript continues

[Pedro de Carvalho Gomes]

Hi all,

I finally concluded the first version of the scripting engine porting
to QJSEngine. It now has a functional console, and it runs
successfully the "Cool Stream" script ( at radio_station_service
folder). I took the chance to remove some services from the playlist
that are no longer available.

Still there's some way ahead. The most important task is to define a
replacement for QTScript Bindings (imported with
"Importer.loadQtBinding"). These were how QT classes were exported to
scripts. Many old scripts make use of these, and would complain if
there's no equivalent functionality. For now I think the best solution
is to write our own "Importer.loadQtBinding" and expose the most
common QT classes. But probably this approach should be desincouraged
in favor of a QML-based approach. Still for the purpose of the next
release this should work.

For the brave ones, the changes are here:
https://invent.kde.org/multimedia/amarok/-/commits/replace_Qtscript_with_QtQml

Cheers,

Pedro

On Fri, Jun 5, 2020 at 10:20 PM Pedro de Carvalho Gomes
 wrote:
>
> Hi all,
>
> I write to update about my work on replacing QTScript with QJSEngine.
> I have just pushed to the branch a substantial change, which includes:
> - fully functional Script console with JS console logging
> - loading of old scripts (though with errors, depending on what's used)
>
> If you have the interest, take a look at the working branch:
> https://invent.kde.org/multimedia/amarok/-/tree/replace_Qtscript_with_QtQml
>
> There's still quite some work ahead. At least if the goal is to
> minimize changes to older scripts. The main issue is that the
> QJSEngine API provides *way less* features than QScriptEngine. Also,
> the documentation is not so complete.
>
> One example: QScriptEngine had "newFunction" which allowed any
> method/function to be exposed to the script engine. There's no such at
> QJSEngine, but I managed to implement an equivalent solution by
> 1) creating a QObject with a Q_INVOKE method,
> 2) exporting the object: QJSValue scriptObj = engine->newQObject( myQObj );
> 3) get a reference to the method: QJSValue scriptFunction =
> scriptObj.property("methodName");
> 4) create a global property to the method:
> engine->globalObject().setProperty("functionName", scriptFunction);
>
> The main issue I have now is that QJSEngine does not have an
> equivalent to QScriptContext. This provides invocation information
> that is necessary; especially a reference to the "this" JS object.
> Without it I can't think of a solution that avoids rework at all
> current scripts.
>
> Another issue is that there's no direct equivalent to QtBindings.
> These is specifically useful to manipulate QT widgets via script.
> However those should naturally be replaced with some QML equivant,
> though I couldn't look at it yet.
>
> If there are more people interested, I'd be really glad to help bring
> on board. There's a lot of fun stuff to work with.
>
> Cheers,
>
> Pedro

Re: building amarok

[Robert Marshall]

Pedro

Thanks

I have the following installed

dpkg -l '*maria*' | grep ^i
ii  libmariadb-dev 1:10.3.22-1ubuntu1 amd64MariaDB database 
development files
ii  libmariadb3:amd64  1:10.3.22-1ubuntu1 amd64MariaDB database 
client library
ii  libmariadbclient-dev:amd64 1:10.3.22-1ubuntu1 amd64MariaDB database 
development files (transitional package)
ii  libmariadbd19:amd641:10.3.22-1ubuntu1 amd64MariaDB embedded 
database, shared library
ii  mariadb-client-core-10.3   1:10.3.22-1ubuntu1 amd64MariaDB database 
core client binaries
ii  mariadb-common 1:10.3.22-1ubuntu1 all  MariaDB common 
metapackage

This is with ubuntu 20.04

for the cmake I'm using

cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde -DCMAKE_BUILD_TYPE=debugfull 
-DWITH_MP3Tunes=OFF -DKDE4_BUILD_TESTS=OFF ..

I guess I no longer need that KDE4_BUILD_TESTS now that I'm attempting to build 
against Qt5

What more do you want to see of installed packages? - I have rather a lot of 
dev packages I've pastebinned a list here (being the output of dpkg -l '*-dev*' 
| grep ^i )

https://pastebin.com/EbHVzBpT

Myriam - thanks for directing this to the correct mailing list - I
posted it to the gmane list gmane.comp.kde.amarok.devel which I
assumed was the dev list but is clearly not so (I see it's
ama...@kde.org) - I'll see if the gmane admins can either rename that
group or otherwise unscramble the confusion!

(I don't think I'm on the -devel list let's see if this works...)

Robert
-- 
Robert Marshall   twitter: @rajm

Pedro de Carvalho Gomes writes:
 > Hi Robert,
 > 
 > First of all, mysql deprecated its embedded library after version 5.7.
 > This means that Amarok no longer can compile against newer versions.
 > The alternative is MariaDB, which still has an equivalent to
 > Mysql-embedded. So, please install all mariadb dependencies,
 > especially the devel packages.
 > 
 > Second: can you provide your environment? Distro, installed packages,
 > full cmake command, and so. Amarok should be easy to compile if you
 > have the right packages installed; but this is the hard part and
 > depends on your distribution.
 > 
 > Cheers,
 > 
 > Pedro
 > 
 > On Fri, Jun 5, 2020 at 10:47 PM Myriam Schweingruber  wrote:
 > >
 > > FYI, I think building from source should go to the devel mailing list, as 
 > > it is not exactly basic user stuff
 > >
 > > Regards, Myriam
 > >
 > > -- Forwarded message -
 > > From: Robert Marshall 
 > > Date: Fri, 5 Jun 2020 at 17:00
 > > Subject: building amarok
 > > To: 
 > >
 > >
 > > I'm attempting to build amarok from source using Pedro's version from
 > > github https://github.com/pcgomes/amarok
 > >
 > > Am having (so far ;) )  issues
 > >
 > > Initially I was using mysql.h from libmysqlclient-dev
 > > then realised - guessing from a missing #define that I needed the
 > > mariadb version I installed libmariadb-dev but now I'm getting
 > >
 > > CMake Error at 
 > > /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 
 > > (message):
 > >   Could NOT find MySQL (missing: MYSQL_LIBRARIES MYSQL_INCLUDE_DIR)
 > >
 > > so with mysql it could find the sql libraries but now it still appears
 > > to be looking for them? A pointer to what I'm not seeing would be 
 > > appreciated!
 > >
 > > Robert
 > > --
 > > Robert Marshall   twitter: @rajm
 > >
 > >
 > >
 > > --
 > > Proud member of the Amarok and KDE Community
 > > Protect your freedom and support the work of the FSFE:
 > > http://www.fsfe.org
 > > Please don't send me proprietary file formats,
 > > use ISO standard ODF instead (ISO/IEC 26300)
 > 

Re: building amarok

[Pedro de Carvalho Gomes]

Hi Robert,

First of all, mysql deprecated its embedded library after version 5.7.
This means that Amarok no longer can compile against newer versions.
The alternative is MariaDB, which still has an equivalent to
Mysql-embedded. So, please install all mariadb dependencies,
especially the devel packages.

Second: can you provide your environment? Distro, installed packages,
full cmake command, and so. Amarok should be easy to compile if you
have the right packages installed; but this is the hard part and
depends on your distribution.

Cheers,

Pedro

On Fri, Jun 5, 2020 at 10:47 PM Myriam Schweingruber  wrote:
>
> FYI, I think building from source should go to the devel mailing list, as it 
> is not exactly basic user stuff
>
> Regards, Myriam
>
> -- Forwarded message -
> From: Robert Marshall 
> Date: Fri, 5 Jun 2020 at 17:00
> Subject: building amarok
> To: 
>
>
> I'm attempting to build amarok from source using Pedro's version from
> github https://github.com/pcgomes/amarok
>
> Am having (so far ;) )  issues
>
> Initially I was using mysql.h from libmysqlclient-dev
> then realised - guessing from a missing #define that I needed the
> mariadb version I installed libmariadb-dev but now I'm getting
>
> CMake Error at 
> /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 
> (message):
>   Could NOT find MySQL (missing: MYSQL_LIBRARIES MYSQL_INCLUDE_DIR)
>
> so with mysql it could find the sql libraries but now it still appears
> to be looking for them? A pointer to what I'm not seeing would be appreciated!
>
> Robert
> --
> Robert Marshall   twitter: @rajm
>
>
>
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)

Re: Move to gitlab?

[Myriam Schweingruber]

on that subject, I hope you all follow the current Thread "Migration to
Gitlab -- Update" on the sysadmin@, kde-core-devel@ and kde-devel@ mailing
lists

These mailing lists are not high volume, and at least kde-corel-devel or
kde-devell should be in your focus

Regards, Myriam
" on


On Fri, 8 May 2020 at 10:21, Pedro de Carvalho Gomes 
wrote:

> I have already dropped Phabricator and the old repo in favor of
> Gitlab. I guess most of active people did the same since I see Pull
> requests being created at Gitlab
>
> On Fri, May 8, 2020 at 1:20 AM Myriam Schweingruber 
> wrote:
> >
> > Hi all,
> >
> > On Thu, 7 May 2020 at 11:18, Heiko Becker  wrote:
> >>
> >> Hello,
> >>
> >> having asked multiple people for their email addresses and the general
> >> awkwardness of arc, I begin to wonder if Amarok should move to gitlab.
> The
> >> move will happen anyway at some point, but we could already start and
> some
> >> projects already have done so: https://invent.kde.org/
> >>
> > I am all for it, the sooner the better. Do we still have requests on
> phabricator that need our attention? If not, we should just move and be
> done with it. AFAIK a short mail to the sysadmins should be enough to get
> this done.
> >
> > Regards, Myriam
> >
> > --
> > Proud member of the Amarok and KDE Community
> > Protect your freedom and support the work of the FSFE:
> > http://www.fsfe.org
> > Please don't send me proprietary file formats,
> > use ISO standard ODF instead (ISO/IEC 26300)
>


-- 
Proud member of the Amarok and KDE Community
Protect your freedom and​ support the work of​ ​​the​ FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Move to gitlab?

[Pedro de Carvalho Gomes]

I have already dropped Phabricator and the old repo in favor of
Gitlab. I guess most of active people did the same since I see Pull
requests being created at Gitlab

On Fri, May 8, 2020 at 1:20 AM Myriam Schweingruber  wrote:
>
> Hi all,
>
> On Thu, 7 May 2020 at 11:18, Heiko Becker  wrote:
>>
>> Hello,
>>
>> having asked multiple people for their email addresses and the general
>> awkwardness of arc, I begin to wonder if Amarok should move to gitlab. The
>> move will happen anyway at some point, but we could already start and some
>> projects already have done so: https://invent.kde.org/
>>
> I am all for it, the sooner the better. Do we still have requests on 
> phabricator that need our attention? If not, we should just move and be done 
> with it. AFAIK a short mail to the sysadmins should be enough to get this 
> done.
>
> Regards, Myriam
>
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)

Re: Move to gitlab?

[Myriam Schweingruber]

Hi all,

On Thu, 7 May 2020 at 11:18, Heiko Becker  wrote:

> Hello,
>
> having asked multiple people for their email addresses and the general
> awkwardness of arc, I begin to wonder if Amarok should move to gitlab. The
> move will happen anyway at some point, but we could already start and some
> projects already have done so: https://invent.kde.org/
>
> I am all for it, the sooner the better. Do we still have requests on
phabricator that need our attention? If not, we should just move and be
done with it. AFAIK a short mail to the sysadmins should be enough to get
this done.

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: New release

[Heiko Becker]

On Wednesday, 6 May 2020 00:45:43 CEST, Heiko Becker wrote:

Finally: I strongly agree that we should release an Alpha version as
soon as possible. We should just merge the open pull requests, a
release it. I know how to create tags and so. But I don't know what
version would it be. Nor I am familiar with KDE's procedures and
announcements. Maybe you and Heiko can help me with that, and we'll be
able to have a first Alpha this weekend. What do you say?


Creating the tag is easy, but we also need to grab the translations
from SVN and sign the tarball. But there's a script for that, releaseme.

Version-wise, I'd say we could go with 2.9.70, but somebody is probably
using that already and *.80 often indicates beta versions of releases
by KDE. So I suggest .71, which gives us plenty of possible alpha
versions before reaching .80.


Oh, if you could join #amarok.dev on freenode (I suppose it's bridged to 
Matrix) we can coordinate this in a more real time fashion.

Re: New release

[Heiko Becker]

Hey,

On Tuesday, 5 May 2020 12:46:07 CEST, Pedro de Carvalho Gomes wrote:

Hi Myriam and others,

I have pushed the working branch to replace QTScript:
https://invent.kde.org/kde/amarok/-/tree/replace_Qtscript_with_QtQml


Nice. Sorry, I know I promised to look into that, but even in these
pandemic times my time is almost fully occupied by other things and
projects. 


About my PPA, I was using 2.9.1* for the candidate packages. This may
have caused confusion, soI have changed the versioning of my snapshots
to 2.9.70*. Currently there are packages for 20.04 (focal) and 19.10
(eoan). Maybe today I'll also add one for Bionic (18.04). Feedback is
very welcome.


I don't know anything about Ubuntu, so I can't comment on that.


Finally: I strongly agree that we should release an Alpha version as
soon as possible. We should just merge the open pull requests, a
release it. I know how to create tags and so. But I don't know what
version would it be. Nor I am familiar with KDE's procedures and
announcements. Maybe you and Heiko can help me with that, and we'll be
able to have a first Alpha this weekend. What do you say?


Creating the tag is easy, but we also need to grab the translations
from SVN and sign the tarball. But there's a script for that, releaseme.

Version-wise, I'd say we could go with 2.9.70, but somebody is probably
using that already and *.80 often indicates beta versions of releases
by KDE. So I suggest .71, which gives us plenty of possible alpha
versions before reaching .80.

I don't have access to the CMS of the website, but I guess Myriam could
help out with that?

Rregards,
Heiko

Re: New release

[Pedro de Carvalho Gomes]

Hi Myriam and others,

I have pushed the working branch to replace QTScript:
https://invent.kde.org/kde/amarok/-/tree/replace_Qtscript_with_QtQml

About my PPA, I was using 2.9.1* for the candidate packages. This may
have caused confusion, soI have changed the versioning of my snapshots
to 2.9.70*. Currently there are packages for 20.04 (focal) and 19.10
(eoan). Maybe today I'll also add one for Bionic (18.04). Feedback is
very welcome. Especially from the fix to Breadcrumb widget (for
instance, when showing directories when browsing local giles), which
wasn't merged to gitlab yet.

Finally: I strongly agree that we should release an Alpha version as
soon as possible. We should just merge the open pull requests, a
release it. I know how to create tags and so. But I don't know what
version would it be. Nor I am familiar with KDE's procedures and
announcements. Maybe you and Heiko can help me with that, and we'll be
able to have a first Alpha this weekend. What do you say?

Cheers,

Pedro

On Sat, May 2, 2020 at 1:13 PM Myriam Schweingruber  wrote:
>
> Hi Pedro,
>
>
> On Fri, 1 May 2020 at 23:38, Pedro de Carvalho Gomes  
> wrote:
>>
>> Hi Heiko and others,
>>
>> I started a branch to port from QTScript to QJS*. It's gonna be quite
>> some work, and I don't even have a compiling version yet. I tell this
>> so we avoid duplicated work. I may push the branch to Gitlab whenever
>> someone wants to join the effort.
>
>
> Please do right away, we should work on Gitlab as much as possible in the 
> open, and it will make review and others joining much easier.
>
> Thanks a lot for your effort.
>
> BTW, your PPA has no installation candidate, anything else I should take care 
> of to try that?
>
> ...
>>
>>
>> I keep you posted of any meaningful progress.
>>
> Thanks a lot for your effort.
>
> FWIW: we should not wait for this work to be done to make an alpha release 
> ASAP, simply to get more visibility of your efforts and get more people on 
> board. If they don't know there is work in progress, nobody will join, so we 
> really need to put that Alpha out.
>
> Regards, Myriam
>
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)

Re: New release

[Myriam Schweingruber]

Hi Pedro,


On Fri, 1 May 2020 at 23:38, Pedro de Carvalho Gomes 
wrote:

> Hi Heiko and others,
>
> I started a branch to port from QTScript to QJS*. It's gonna be quite
> some work, and I don't even have a compiling version yet. I tell this
> so we avoid duplicated work. I may push the branch to Gitlab whenever
> someone wants to join the effort.
>

Please do right away, we should work on Gitlab as much as possible in the
open, and it will make review and others joining much easier.

Thanks a lot for your effort.

BTW, your PPA has no installation candidate, anything else I should take
care of to try that?

...

>
> I keep you posted of any meaningful progress.
>
> Thanks a lot for your effort.

FWIW: we should not wait for this work to be done to make an alpha release
ASAP, simply to get more visibility of your efforts and get more people on
board. If they don't know there is work in progress, nobody will join, so
we really need to put that Alpha out.

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: New release

[Pedro de Carvalho Gomes]

Hi Heiko and others,

I started a branch to port from QTScript to QJS*. It's gonna be quite
some work, and I don't even have a compiling version yet. I tell this
so we avoid duplicated work. I may push the branch to Gitlab whenever
someone wants to join the effort.

So far I have identified few points about the port:
- there's no equivalent to QScriptDebugger at QJS* I have already
written a skeleton to replace it. I see two possible ways to go here:
a) try to reuse KDevelop's widgets (for local variables, code, stack
analysis, etc), and logic from its QML plugin (for controlling
debugging), or b) check which widgets QScriptDebugger has, and use
them, and copy the logic from QTcreator
- there's no way to the "this" reference from a JSValue function. I
mean, one can invoke a JSValue function and set the "this" with
JSValue.callWithInstance(). But one cannot retrieve the JS "this" from
an exported method that is called within the engine. I still don't
know a good way to solve this
- there are few minor incompatibilites more, which are not so bad. For
example, QJSEngine has no correspondance to QScriptEngine's ownership
(ValueOwnership). However QmlEngine has a similar notion
(ObjectOwnership). So using QmlEngine, which inherites from QJSEngine,
is an alternative. Another missing feature is a way to set a default
prototype for a given class (before there was setDefaultPrototype)

I keep you posted of any meaningful progress.

Cheers,

Pedro

On Tue, Apr 14, 2020 at 4:04 AM Heiko Becker  wrote:
>
> Hey Pedro and all,
>
> On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote:
> > I think the main reason for the delay of a new version is now
> > concluded (or at least in a decent state), which was the port to KF5.
> > There's also one major issue, which is the deprecation of mysql
> > embedded.
>
> Myriam asked for a release as well. It's not much work to create and
> release a tarball and I'm happy to do it, but I'm bit concerned about
> expectations. IMHO it should "only" be an alpha release. There are still
> rough edges and one problem (besides the mentioned mysqle issue) is
> scripting. QtScript is deprecated and will go away and there are currently
> no Qt5 bindings for it anyway. Possible solutions are
>
> - Get rid of it alltogether
> - There's a patch on phab to add bindings extracted from Qcad which still
> uses QtScript, https://phabricator.kde.org/D24817 and needs at least some
> license headers and some glue
> - Port to the QJS* classes from QtQml (one simple example for a Plasma
> runner [1])
>
> Any opinions on that?
> Personally I'd prefer the last option because it isn't likely to cause an
> outcry and should be somewhat future-proof (i.e. possibly meaning less work
> to port to Qt6). I don't know how feasible that would be in Amarok's case
> though, but I hope to find some time for that in the next week.
>
> > I went after Mariadb's plans for the embedded library. I couldn't find
> > any mention to it. Only references to 10.5 series mirroring Mysql 8,
> > which is the version that dropped Mysql embedded. However Mariadb 10.4
> > contains the embedded library, and is supported until June 2024 (see
> > https://mariadb.com/kb/en/new-and-old-releases/)
>
> I just checked out the 10.5 branch of Mariadb and it looks like the
> embedded server is still present there.
>
> > I wonder if Amarok could release a version with dependency to Mariadb
> > <= 10.4. Then we prioritize the port to the alternative to
> > mariadb/mysql. This would bridge the 2-year gap from the previous
> > release. Also it would bring Amarok back to distros that are not
> > shipping it because it doesn't have an official KF5 versions (namely
> > Ubuntu).
>
> I think there's no need to declare such a dep on our side at the moment. It
> sufficient to check if it's present or not in our cmake code, which we
> already do.
>
> Regards,
> Heiko
>
> [1]
> https://cgit.kde.org/plasma-workspace.git/commit/?id=605fb9acd867e22e171184a08d9dfd2d1d4e893e

Re: trying to build amarok git master against ubuntu eoan

[Pedro de Carvalho Gomes]

Hi, I have created the attached Dockerfile that builds for Eoan. Use
it as a reference to build your own Amarok with Mariadb Embedded
replacing Mysql Embedded (which is no longer supported).

As an alternative, I have been creating my own packages at Lauchpad.
Here's my PPA: https://launchpad.net/~pgomes/+archive/ubuntu/amarok

On Wed, Apr 29, 2020 at 1:10 AM Alan Ezust  wrote:
>
> Hi, I managed to figure out what to install to get cmake to run and started 
> building amarok.
> It fails around 86% because of the mysql embedded stuff.
>
> What is the right way to disable the mysql embedded storage module?
> I tried editing the cmakelists.txt file and set the option to OFF like this:
>
> option(WITH_MYSQL_EMBEDDED "Build the embedded database library -- highly 
> recommended" OFF)
>
> is that the right way to disable modules in the amarok build? or do I pass a 
> command line argument to cmake when I run it?
>
> I'm getting this:
>
> [ 86%] Linking CXX shared module 
> ../../../../../bin/amarok_storage-mysqlestorage.so
> c++: error: [OPTIONS]: No such file or directory
> make[2]: *** 
> [src/core-impl/storage/sql/mysqlestorage/CMakeFiles/amarok_storage-mysqlestorage.dir/build.make:130:
>  bin/amarok_storage-mysqlestorage.so] Error 1
> make[1]: *** [CMakeFiles/Makefile2:8923: 
> src/core-impl/storage/sql/mysqlestorage/CMakeFiles/amarok_storage-mysqlestorage.dir/all]
>  Error 2
> make[1]: *** Waiting for unfinished jobs
>
>
>
>


Dockerfile
Description: Binary data

Re: New release

[Pedro de Carvalho Gomes]

Hi Jonathan,

I have just fixed the issue with Mariadb 10.1 and now it compiles fine
at Ubuntu 18.4 LTS. The attached docker file for Neon in case you
have trouble.

Regards,

Pedro

On Fri, Apr 17, 2020 at 12:37 PM Jonathan Riddell  wrote:
>
> Oh yes I didn't realise libmaridadb actually just installs with the same name 
> of libmysqld.
>
> Compiling with mariadb 10.1 on the current Ubuntu LTS I get a compile error 
> but with mariadb 10.3 on the about to be released Ubuntu LTS it compiles fine.
>
> Jonathan
>
>
>


Dockerfile
Description: Binary data

Re: New release

[Jonathan Riddell]

Oh yes I didn't realise libmaridadb actually just installs with the same
name of libmysqld.

Compiling with mariadb 10.1 on the current Ubuntu LTS I get a compile error
but with mariadb 10.3 on the about to be released Ubuntu LTS it compiles
fine.

Jonathan

Re: New release

[Pedro de Carvalho Gomes]

Hi Heiko,

Thanks for the input. I like the idea of the alpha release. First,
because I think that Amarok is already at a usable state. But also to
make it clear that Amarok is not EOL.

About MariaDB: I haven't checked out the 10.5 branch. But I downloaded
the official binaries, and it no loger has libmysqd/libmariadbd. It
seems that the code is inactive, but simple wasn't removed.

I agree that replacing QtScripts is a more urgent matter than
replacing Mysql/MariaDB since it's no longer being supported.
Moreover, I agree with your opinion of porting to QJs. Surely it is
more work, but it work that stays longer. I volunteer to help you with
that. Do you have ideas on how we can share the task?

Regards,

Pedro

On Tue, Apr 14, 2020 at 4:04 AM Heiko Becker  wrote:
>
> Hey Pedro and all,
>
> On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote:
> > I think the main reason for the delay of a new version is now
> > concluded (or at least in a decent state), which was the port to KF5.
> > There's also one major issue, which is the deprecation of mysql
> > embedded.
>
> Myriam asked for a release as well. It's not much work to create and
> release a tarball and I'm happy to do it, but I'm bit concerned about
> expectations. IMHO it should "only" be an alpha release. There are still
> rough edges and one problem (besides the mentioned mysqle issue) is
> scripting. QtScript is deprecated and will go away and there are currently
> no Qt5 bindings for it anyway. Possible solutions are
>
> - Get rid of it alltogether
> - There's a patch on phab to add bindings extracted from Qcad which still
> uses QtScript, https://phabricator.kde.org/D24817 and needs at least some
> license headers and some glue
> - Port to the QJS* classes from QtQml (one simple example for a Plasma
> runner [1])
>
> Any opinions on that?
> Personally I'd prefer the last option because it isn't likely to cause an
> outcry and should be somewhat future-proof (i.e. possibly meaning less work
> to port to Qt6). I don't know how feasible that would be in Amarok's case
> though, but I hope to find some time for that in the next week.
>
> > I went after Mariadb's plans for the embedded library. I couldn't find
> > any mention to it. Only references to 10.5 series mirroring Mysql 8,
> > which is the version that dropped Mysql embedded. However Mariadb 10.4
> > contains the embedded library, and is supported until June 2024 (see
> > https://mariadb.com/kb/en/new-and-old-releases/)
>
> I just checked out the 10.5 branch of Mariadb and it looks like the
> embedded server is still present there.
>
> > I wonder if Amarok could release a version with dependency to Mariadb
> > <= 10.4. Then we prioritize the port to the alternative to
> > mariadb/mysql. This would bridge the 2-year gap from the previous
> > release. Also it would bring Amarok back to distros that are not
> > shipping it because it doesn't have an official KF5 versions (namely
> > Ubuntu).
>
> I think there's no need to declare such a dep on our side at the moment. It
> sufficient to check if it's present or not in our cmake code, which we
> already do.
>
> Regards,
> Heiko
>
> [1]
> https://cgit.kde.org/plasma-workspace.git/commit/?id=605fb9acd867e22e171184a08d9dfd2d1d4e893e

Re: Move to gitlab?

[Heiko Becker]

Hello Pedro,

On Dienstag, 14. April 2020 15:49:33 CEST, Pedro de Carvalho Gomes wrote:

Thank you and the sysadmins for the move to Gitlab.

Is the plan to continue with Phabricator for code review, or will this
be moved to Gitlab?


I think we can finish the reviews which started on Phabricator there but 
everything new should go to gitlab (I already removed the .arcconfig file 
because of that).


Regards,
Heiko

Re: New release

[Heiko Becker]

Hello Jonathan,

On Dienstag, 14. April 2020 12:53:22 CEST, Jonathan Riddell wrote:

For KDE neon we're about to move to a new Ubuntu LTS base which seems to
have mariadb 10.3
https://launchpad.net/ubuntu/+source/mariadb-10.3
So this should work for us but I don't think the current Amarok master
builds against mariadb so I've not been able to compile it to test.


Current master should build against mariadb, at least it does here and I 
know it does on OpenSUSE, too. If not, please let me know.


Regards,
Heiko

Re: Move to gitlab?

[Pedro de Carvalho Gomes]

Hi Heiko,

Thank you and the sysadmins for the move to Gitlab.

Is the plan to continue with Phabricator for code review, or will this
be moved to Gitlab?

Regards,

Pedro

On Thu, Mar 26, 2020 at 11:53 PM Heiko Becker  wrote:
>
> Hello,
>
> having asked multiple people for their email addresses and the general
> awkwardness of arc, I begin to wonder if Amarok should move to gitlab. The
> move will happen anyway at some point, but we could already start now and
> some projects already have done so: https://invent.kde.org/
>
> Regards,
> Heiko

Re: New release

[Myriam Schweingruber]

Hi all,


On Tue, 14 Apr 2020 at 04:04, Heiko Becker  wrote:

> Hey Pedro and all,
>
> On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote:
> ...
>
> Myriam asked for a release as well. It's not much work to create and
> release a tarball and I'm happy to do it, but I'm bit concerned about
> expectations. IMHO it should "only" be an alpha release.


That makes perfect sense, I was even suggesting it to be a technical
preview, but that's roughly what alpha is anyway

There are still
> rough edges and one problem (besides the mentioned mysqle issue) is
> scripting. QtScript is deprecated and will go away and there are currently
> no Qt5 bindings for it anyway. Possible solutions are
>
> - Get rid of it alltogether
> - There's a patch on phab to add bindings extracted from Qcad which still
> uses QtScript, https://phabricator.kde.org/D24817 and needs at least some
> license headers and some glue
> - Port to the QJS* classes from QtQml (one simple example for a Plasma
> runner [1])

Any opinions on that?

The initial idea was always to port it, so QJS makes perfect sense, but
will also make this more work

...
> > I went after Mariadb's plans for the embedded library. I couldn't find
> > any mention to it. Only references to 10.5 series mirroring Mysql 8,
> > which is the version that dropped Mysql embedded. However Mariadb 10.4
> > contains the embedded library, and is supported until June 2024 (see
> > https://mariadb.com/kb/en/new-and-old-releases/)
>
> I just checked out the 10.5 branch of Mariadb and it looks like the
> embedded server is still present there.
>
> > I wonder if Amarok could release a version with dependency to Mariadb
> > <= 10.4. Then we prioritize the port to the alternative to
> > mariadb/mysql. This would bridge the 2-year gap from the previous
> > release. Also it would bring Amarok back to distros that are not
> > shipping it because it doesn't have an official KF5 versions (namely
> > Ubuntu).
>
> I think there's no need to declare such a dep on our side at the moment.
> It
> sufficient to check if it's present or not in our cmake code, which we
> already do.
>
> +1 from me here too, we should not hardcode a dependency. But the issue
might be that some distros don't ship this version yet, so a warning needs
to be issued to the distros on release announcement

Nice to see some movement here, thanks a bunch to all who make this
happening :-)

FWIW: we still have a Development channel on IRC: #amarok.dev, please use
it instead of #amarok which is meant for user support
Stay safe an healthy everyone!

Regard, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: New release

[Jonathan Riddell]

For KDE neon we're about to move to a new Ubuntu LTS base which seems to
have mariadb 10.3
https://launchpad.net/ubuntu/+source/mariadb-10.3
So this should work for us but I don't think the current Amarok master
builds against mariadb so I've not been able to compile it to test.

Jonathan

Re: New release

[Heiko Becker]

Hey Pedro and all,

On Sonntag, 12. April 2020 09:51:33 CEST, Pedro de Carvalho Gomes wrote:

I think the main reason for the delay of a new version is now
concluded (or at least in a decent state), which was the port to KF5.
There's also one major issue, which is the deprecation of mysql
embedded.


Myriam asked for a release as well. It's not much work to create and 
release a tarball and I'm happy to do it, but I'm bit concerned about 
expectations. IMHO it should "only" be an alpha release. There are still 
rough edges and one problem (besides the mentioned mysqle issue) is 
scripting. QtScript is deprecated and will go away and there are currently 
no Qt5 bindings for it anyway. Possible solutions are


- Get rid of it alltogether
- There's a patch on phab to add bindings extracted from Qcad which still 
uses QtScript, https://phabricator.kde.org/D24817 and needs at least some 
license headers and some glue
- Port to the QJS* classes from QtQml (one simple example for a Plasma 
runner [1])


Any opinions on that?
Personally I'd prefer the last option because it isn't likely to cause an 
outcry and should be somewhat future-proof (i.e. possibly meaning less work 
to port to Qt6). I don't know how feasible that would be in Amarok's case 
though, but I hope to find some time for that in the next week.



I went after Mariadb's plans for the embedded library. I couldn't find
any mention to it. Only references to 10.5 series mirroring Mysql 8,
which is the version that dropped Mysql embedded. However Mariadb 10.4
contains the embedded library, and is supported until June 2024 (see
https://mariadb.com/kb/en/new-and-old-releases/)


I just checked out the 10.5 branch of Mariadb and it looks like the 
embedded server is still present there.



I wonder if Amarok could release a version with dependency to Mariadb
<= 10.4. Then we prioritize the port to the alternative to
mariadb/mysql. This would bridge the 2-year gap from the previous
release. Also it would bring Amarok back to distros that are not
shipping it because it doesn't have an official KF5 versions (namely
Ubuntu).


I think there's no need to declare such a dep on our side at the moment. It 
sufficient to check if it's present or not in our cmake code, which we 
already do.


Regards,
Heiko

[1] 
https://cgit.kde.org/plasma-workspace.git/commit/?id=605fb9acd867e22e171184a08d9dfd2d1d4e893e

Re: Move to gitlab?

[Heiko Becker]

On Freitag, 27. März 2020 04:09:04 CET, Myriam Schweingruber wrote:

Hi Heiko,

On Thu, 26 Mar 2020 at 23:53, Heiko Becker  wrote:


Hello,

having asked multiple people for their email addresses and the general
awkwardness of arc, I begin to wonder if Amarok should move to gitlab. The
move will happen anyway at some point, but we could already start now and
some projects already have done so: https://invent.kde.org/


I am all for it, but this needs to be coordinated with the sysadmins.


Since nobody objected I filed a sysadmin ticket and they quickly moved 
Amarok to gitlab. I'll write a separate mail for visibility so that 
hopefully nobody wonders why they can't push to git.kde.org anymore.



FWIW: it would be a good idea to make a technical preview release (aka
Alpha) once this move is done, unless you suggest to do this before.


I wrote something about that in reply to Pedro's mail.

Regards,
Heiko

Re: Move to gitlab?

[Myriam Schweingruber]

Hi Heiko,

On Thu, 26 Mar 2020 at 23:53, Heiko Becker  wrote:

> Hello,
>
> having asked multiple people for their email addresses and the general
> awkwardness of arc, I begin to wonder if Amarok should move to gitlab. The
> move will happen anyway at some point, but we could already start now and
> some projects already have done so: https://invent.kde.org/
>
>
> I am all for it, but this needs to be coordinated with the sysadmins.

FWIW: it would be a good idea to make a technical preview release (aka
Alpha) once this move is done, unless you suggest to do this before.

Regards, Myriam



-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: SQLite Pilot V1

[Pedro de Carvalho Gomes]

Hi Leo,

Your learning was certainly not in vain. It has been a while that Amarok
developers are discussing about moving out from Mysql Embedded, including
MariaDB's replacement. The reason is that it is likely that MariaDB will
drop support for libmariadbd since Mysql did it. Thus, an Sqlite backend
seems like the best replacement as default DB. I think Myriam can say more
about this.

I will take a look at your code as soon as I have some time.

Regards,

Pedro

On Thu, Mar 5, 2020 at 2:13 AM subscription1 
wrote:

> Hi Pedro,
>
> Your MariaDB solution works as far as I can tell. Wish I knew this before
> I spent 2 months on the SQLite solution;-(
>
> Still, learned a lot in the process
>
> Here is what I did
>
> 1) Installed Kubuntu 19.10 (on a VM)
>
> 2) Installed all prerequiste software as per your docker; the only thing I
> added was libphonon4qt5-dev
>
> apt-get install -y cmake extra-cmake-modules g++ git libmariadb-dev
> libmariadbd-dev pkg-config  \
> qtdeclarative5-dev qtscript5-dev libqt5svg5-dev qtquickcontrols2-5-dev
> qtwebengine5-dev  \
> libkf5archive-dev libkf5attica-dev libkf5codecs-dev libkf5config-dev
> libkf5configwidgets-dev libkf5coreaddons-dev libkf5crash-dev \
> libkf5dbusaddons-dev libkf5declarative-dev libkf5dnssd-dev
> libkf5globalaccel-dev libkf5guiaddons-dev libkf5i18n-dev
> libkf5iconthemes-dev \
> libkf5kcmutils-dev libkf5kio-dev libkf5newstuff-dev
> libkf5notifications-dev libkf5notifyconfig-dev libkf5package-dev
> libkf5solid-dev \
> libkf5texteditor-dev libkf5threadweaver-dev libkf5widgetsaddons-dev
> libkf5windowsystem-dev libkf5wallet-dev kirigami2-dev \
> gettext libtag1-dev libtag-extras-dev libavcodec-dev libavformat-dev
> libavdevice-dev libavutil-dev libswscale-dev libpostproc-dev \
> libgpod-dev libgdk-pixbuf2.0-dev libmygpo-qt-dev libmtp-dev
> libcurl4-openssl-dev libxml2-dev libssl-dev libgcrypt20-dev \
> libfftw3-dev libloudmouth1-dev libofa0-dev liblastfm5-dev libgmock-dev
> libphonon4qt5-dev
>
> 3) cloned amarok
>
> 4) built/installed amarok (my dev environment is under /kdedev)
>
> cmake -DCMAKE_INSTALL_PREFIX=$HOME/kdedev -j4
> -DCMAKE_VERBOSE_MAKEFILE=TRUE -DCMAKE_BUILD_TYPE=Debug
> -DMYSQLCONFIG_EXECUTABLE=/usr/bin/mariadb_config
> -DMYSQL_INCLUDE_DIR=/usr/include/mariadb ../../src/amarok/
>
> cmake --build .
>
> make install
>
> amarok runs, I can add my music and play from a random playlist. Have not
> done any extesnive testing, but think you have found a solution for
> installation for (U/Ku)bunto without the embedded MySql.
>
> Thanks,
>
> Leo
>
>
> On 28/2/20 1:46 am, Pedro de Carvalho Gomes wrote:
>
> Hi,
>
> Is this branch available somewhere? I may take a lot and help you with
> that.
>
> About the (K)Ubuntu 19+: indeed it comes with Mysql 8, which no longer
> supports Mysql Embedded. Still Ubuntu 19.10 provides MariaDB 10.3 as
> alternative, which has a compatible library (libmariadbd) that works
> exactly the same as mysql
>
> At the following bug report I have attached a Docker image for Ubuntu
> 19.10 that builds Amarok packages with MariaDB. Even if you are not
> familiar with Docker, you can use it as a reference to build your own
> Amarok. Let me know if you have issues building it.
>
> https://bugs.kde.org/show_bug.cgi?id=414407
>
> Pedro
>
> On Tue, Feb 25, 2020 at 8:20 PM subscription1 
> wrote:
>
>> Given that there is no support for the embedded MySql in (native) Ubuntu
>> 19+ I've started an implementation of SQLite as a possible alternative.
>>
>> I've created a branch that creates the SQLite DB, loads albums and
>> creates/plays dynamic playlists.
>>
>> There is (obviously) more work to do, but it's a start,
>>
>> Not sure where this should go next (if at all).
>>
>> Cheers,
>>
>> Leo
>>
>>

Re: SQLite Pilot V1

[subscription1]

Hi Pedro,

Your MariaDB solution works as far as I can tell. Wish I knew this 
before I spent 2 months on the SQLite solution;-(


Still, learned a lot in the process

Here is what I did

1) Installed Kubuntu 19.10 (on a VM)

2) Installed all prerequiste software as per your docker; the only thing 
I added was libphonon4qt5-dev


apt-get install -y cmake extra-cmake-modules g++ git libmariadb-dev 
libmariadbd-dev pkg-config  \
    qtdeclarative5-dev qtscript5-dev libqt5svg5-dev 
qtquickcontrols2-5-dev qtwebengine5-dev  \
    libkf5archive-dev libkf5attica-dev libkf5codecs-dev 
libkf5config-dev libkf5configwidgets-dev libkf5coreaddons-dev 
libkf5crash-dev \
    libkf5dbusaddons-dev libkf5declarative-dev libkf5dnssd-dev 
libkf5globalaccel-dev libkf5guiaddons-dev libkf5i18n-dev 
libkf5iconthemes-dev \
    libkf5kcmutils-dev libkf5kio-dev libkf5newstuff-dev 
libkf5notifications-dev libkf5notifyconfig-dev libkf5package-dev 
libkf5solid-dev \
    libkf5texteditor-dev libkf5threadweaver-dev libkf5widgetsaddons-dev 
libkf5windowsystem-dev libkf5wallet-dev kirigami2-dev \
    gettext libtag1-dev libtag-extras-dev libavcodec-dev 
libavformat-dev libavdevice-dev libavutil-dev libswscale-dev 
libpostproc-dev \
    libgpod-dev libgdk-pixbuf2.0-dev libmygpo-qt-dev libmtp-dev 
libcurl4-openssl-dev libxml2-dev libssl-dev libgcrypt20-dev \
    libfftw3-dev libloudmouth1-dev libofa0-dev liblastfm5-dev 
libgmock-dev libphonon4qt5-dev


3) cloned amarok

4) built/installed amarok (my dev environment is under /kdedev)

cmake -DCMAKE_INSTALL_PREFIX=$HOME/kdedev -j4 
-DCMAKE_VERBOSE_MAKEFILE=TRUE -DCMAKE_BUILD_TYPE=Debug 
-DMYSQLCONFIG_EXECUTABLE=/usr/bin/mariadb_config 
-DMYSQL_INCLUDE_DIR=/usr/include/mariadb ../../src/amarok/


cmake --build .

make install

amarok runs, I can add my music and play from a random playlist. Have 
not done any extesnive testing, but think you have found a solution for 
installation for (U/Ku)bunto without the embedded MySql.


Thanks,

Leo


On 28/2/20 1:46 am, Pedro de Carvalho Gomes wrote:

Hi,

Is this branch available somewhere? I may take a lot and help you with 
that.


About the (K)Ubuntu 19+: indeed it comes with Mysql 8, which no longer 
supports Mysql Embedded. Still Ubuntu 19.10 provides MariaDB 10.3 as 
alternative, which has a compatible library (libmariadbd) that works 
exactly the same as mysql


At the following bug report I have attached a Docker image for Ubuntu 
19.10 that builds Amarok packages with MariaDB. Even if you are not 
familiar with Docker, you can use it as a reference to build your own 
Amarok. Let me know if you have issues building it.


https://bugs.kde.org/show_bug.cgi?id=414407

Pedro

On Tue, Feb 25, 2020 at 8:20 PM subscription1 
mailto:llsub...@zudiewiener.com>> wrote:


Given that there is no support for the embedded MySql in (native)
Ubuntu
19+ I've started an implementation of SQLite as a possible
alternative.

I've created a branch that creates the SQLite DB, loads albums and
creates/plays dynamic playlists.

There is (obviously) more work to do, but it's a start,

Not sure where this should go next (if at all).

Cheers,

Leo

Re: SQLite Pilot V1

[subscription1]

Hi Pedro,

The branch is available at

g...@github.com:poldi171254/SQLiteV1.git

I've add SQLiteDev.txt to the HACKING folder; it explains how to build 
this version


I'll try your Docker image shortly and will let you know how I go.

Cheers,

Leo

On 28/2/20 1:46 am, Pedro de Carvalho Gomes wrote:

Hi,

Is this branch available somewhere? I may take a lot and help you with 
that.


About the (K)Ubuntu 19+: indeed it comes with Mysql 8, which no longer 
supports Mysql Embedded. Still Ubuntu 19.10 provides MariaDB 10.3 as 
alternative, which has a compatible library (libmariadbd) that works 
exactly the same as mysql


At the following bug report I have attached a Docker image for Ubuntu 
19.10 that builds Amarok packages with MariaDB. Even if you are not 
familiar with Docker, you can use it as a reference to build your own 
Amarok. Let me know if you have issues building it.


https://bugs.kde.org/show_bug.cgi?id=414407

Pedro

On Tue, Feb 25, 2020 at 8:20 PM subscription1 
mailto:llsub...@zudiewiener.com>> wrote:


Given that there is no support for the embedded MySql in (native)
Ubuntu
19+ I've started an implementation of SQLite as a possible
alternative.

I've created a branch that creates the SQLite DB, loads albums and
creates/plays dynamic playlists.

There is (obviously) more work to do, but it's a start,

Not sure where this should go next (if at all).

Cheers,

Leo

Re: SQLite Pilot V1

[Pedro de Carvalho Gomes]

Hi,

Is this branch available somewhere? I may take a lot and help you with that.

About the (K)Ubuntu 19+: indeed it comes with Mysql 8, which no longer
supports Mysql Embedded. Still Ubuntu 19.10 provides MariaDB 10.3 as
alternative, which has a compatible library (libmariadbd) that works
exactly the same as mysql

At the following bug report I have attached a Docker image for Ubuntu 19.10
that builds Amarok packages with MariaDB. Even if you are not familiar with
Docker, you can use it as a reference to build your own Amarok. Let me know
if you have issues building it.

https://bugs.kde.org/show_bug.cgi?id=414407

Pedro

On Tue, Feb 25, 2020 at 8:20 PM subscription1 
wrote:

> Given that there is no support for the embedded MySql in (native) Ubuntu
> 19+ I've started an implementation of SQLite as a possible alternative.
>
> I've created a branch that creates the SQLite DB, loads albums and
> creates/plays dynamic playlists.
>
> There is (obviously) more work to do, but it's a start,
>
> Not sure where this should go next (if at all).
>
> Cheers,
>
> Leo
>
>

Re: Help with code revision process

[Myriam Schweingruber]

Hi Pedro,

On Fri, 14 Feb 2020 at 13:12, Pedro de Carvalho Gomes <
pedrogome...@gmail.com> wrote:

> Hi,
>
> Yesterday I created three Review Requests. However only one of them has an
> associated bugtrack ID.
>

Thanks a lot for these. Did you check the bug database if those are related
to existing bugs? If yes it should be easy to add the ID to close the bugs
on commit, but it is not a hard requirement


> And none has an associated Phabricator task. Are these required for the
> review process?
>

No, not a hard requirement either.

> What's the usual procedure to submit a PR?
>

You did quite well AFAICS, now we need somebody to review the code.

FWIW: it's always good to test build to avoid breaking it o commit



-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: embedded MySql alternatives

[Bennett Piater]

On Thursday, January 9, 2020 1:03:36 PM CET Myriam Schweingruber wrote:
> If as Soren says SQLite has improved and is really scaling to large
> collections (we talk in several thousands of tracks, DJ sampling can get
> very large indeed), I have nothing against it, but we need to keep the
> server option for those who want it.
> 
> We would also have to provide a migration tool from MySQL embedded to
> whatever we chose for the future, one that is non-developer proof. This has
> not always been smooth in the past...

I second SQLite. It's one of the most underrated/misunderstood pieces of 
software that I have encountered.

It scales very well with database size in my experience, the only real 
limitation is scalability with _client processes_.
And even then, we are talking large numbers, like web servers with over 100K 
requests/day - and only when considering concurrent _writes_.

For the default use-case of Amarok (on a single machine), I think SQLite would 
be the optimal choice.

See also:
https://www.sqlite.org/whentouse.html
https://www.sqlite.org/about.html

Cheers,
Bennett

signature.asc
Description: This is a digitally signed message part.

Re: embedded MySql alternatives

[Myriam Schweingruber]

Hi Pedro,

On Thu, 9 Jan 2020 at 12:56, Pedro de Carvalho Gomes 
wrote:

> Hi Myriam,
>
> What about deprecating Mysql embedded, and supporting MariaDB instead? It
> seems the natural path since it still has libmysqld.
>
> The problem lies in the "still" has, how can we be sure this will persist
in the future? Also I am not sure all distros have replaced MySQL with
MariaDB.

If as Soren says SQLite has improved and is really scaling to large
collections (we talk in several thousands of tracks, DJ sampling can get
very large indeed), I have nothing against it, but we need to keep the
server option for those who want it.

We would also have to provide a migration tool from MySQL embedded to
whatever we chose for the future, one that is non-developer proof. This has
not always been smooth in the past...

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: embedded MySql alternatives

[subscription1]

Hi Myriam,

Maybe as a starting point somebody could just outline the requirements 
for the replacement of the embedded MySQL i.e.


Capacity, Speed, Ease of use (i.e. usable by non-techos), available on 
all amarok platforms, etc.


Or to look at this differently, indicate the reasons why SQLite couldn't 
do the job.


Cheers,

Leo


On 7/1/20 2:30 am, Myriam Schweingruber wrote:

Hi Leo,

On Sun, 5 Jan 2020 at 10:11, subscription1 > wrote:


Given that the embedded MySql has disappeared from the latest
Ubuntu release the only other alternative to install Amarok on
this (and later) releases I can see is to

 1. Make amarok installation dependant on a MySQL server installation
 2. Use something like Sqlite as the default

I don't really have a solution, but I know we deliberately changed 
from SQLite wich was default in Amarok 1.x to MySQL embedded with the 
option of MySQL Server due to the bad scaling of SQLite. Many users of 
Amarok requested that change, some having enormous databases that were 
very slow to handle with SQLite.


We probably have to choose the first option, but giving the users the 
option to use an existing MySQL server installation or creating one 
just for Amarok. There also is software in place (probably outdated) 
to use Akonadi which we waited to get usable before adopting it, 
something which even Kmail is still struggling with, unless Akonadi is 
used with PostgreSQL.
Of course another option would be to change to PostgreSQL which scales 
quite well and might be a better solution. This looks like something 
we would need to ask the users TBH.


Regards, Myriam

PS. Unless we find a better embedded database system, of course...
--
Proud member of the Amarok and KDE Community
Protect your freedom andsupport the work ofthe FSFE:
http://www.fsfe.org 

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: embedded MySql alternatives

[Pedro de Carvalho Gomes]

Hi Myriam,

What about deprecating Mysql embedded, and supporting MariaDB instead? It
seems the natural path since it still has libmysqld.

Regards,

Pedro

On Mon, Jan 6, 2020 at 4:31 PM Myriam Schweingruber  wrote:

> Hi Leo,
>
> On Sun, 5 Jan 2020 at 10:11, subscription1 
> wrote:
>
>> Given that the embedded MySql has disappeared from the latest Ubuntu
>> release the only other alternative to install Amarok on this (and later)
>> releases I can see is to
>>
>>1. Make amarok installation dependant on a MySQL server installation
>>2. Use something like Sqlite as the default
>>
>> I don't really have a solution, but I know we deliberately changed from
> SQLite wich was default in Amarok 1.x to MySQL embedded with the option of
> MySQL Server due to the bad scaling of SQLite. Many users of Amarok
> requested that change, some having enormous databases that were very slow
> to handle with SQLite.
>
> We probably have to choose the first option, but giving the users the
> option to use an existing MySQL server installation or creating one just
> for Amarok. There also is software in place (probably outdated) to use
> Akonadi which we waited to get usable before adopting it, something which
> even Kmail is still struggling with, unless Akonadi is used with PostgreSQL.
> Of course another option would be to change to PostgreSQL which scales
> quite well and might be a better solution. This looks like something we
> would need to ask the users TBH.
>
> Regards, Myriam
>
> PS. Unless we find a better embedded database system, of course...
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> 
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)
>

Re: Amarok-devel Digest, Vol 407, Issue 1

[Bennett Piater]

On 2020-01-08 13:00, amarok-devel-requ...@kde.org wrote:

How about leaving the website as it is for now? I don't know where you
checked, but 2.9 is the latest version specified, the screenshots have 
not
been changed because there were no UI changes done between versions. So 
if

it bothers you it says 2.7 instead of 2.9, change that?

As for the kf5 port: it is mostly done, and several distros already 
ship an

unofficial release, we simply don't have a finished version, but we
certainly should do a tech preview alpha just to get things rolling 
faster

again.

Currently we are faced with the big problem of MySQL embedded having 
been

deprecated upstream, and we need to make a substantial change for the
database, which is currently been decided upon.


Where is that discussion taking place, if I may ask?


So instead of removing the website which I strongly oppose, how about a
static page mentioning the latest 2.9 release with screenshot numbering
updated, and a link to kft5 master in git? Also worth mentioning would 
be

the rolling release distros who already ship the kf5 version.


FWIW, arch linux dropped amarok to AUR (unsupported) with the comment 
that upstream looks basically dead and the qt5 version was never 
properly finished.

So the communication could certainly do with an improvement.

Cheers,
Bennett

Re: Regarding amarok.kde.org website

[Myriam Schweingruber]

Hi Niccolò,

sorry for the late reply, life got in the way.

FWIW: taking the discussion to the developer malign list instead of the
user support mailing list this was posted to...

On Sat, 28 Dec 2019 at 06:12, Veggero Nylo 
wrote:

> Hi,
> There's an ongoing effort to make the kde.org website more modern and
> consistent in style. Amarok is one of the websites that should be ported to
> the new website and updated is some parts, e.g. the screenshot section
> currently states that 2.7 is the current stable version instead of 2.9.
> Since Amarok is currently deprecated until the porting is finished
> according to October's Apps update,
>

erm, Amarok was never part of the Apps, it has always been in Extragear,
and it is certainly not deprecated. Telling developers their product is
deprecated is not exactly the proper way to do it, it should be the other
way round, no?

> I thinking that maybe the best option could be to disable the
> amarok.kde.org website until the porting is finished, and then make the
> new version when the KF5 version is available to avoid putting resources in
> a product that's currently deprecated.
> What is your opinion on this?
>

How about leaving the website as it is for now? I don't know where you
checked, but 2.9 is the latest version specified, the screenshots have not
been changed because there were no UI changes done between versions. So if
it bothers you it says 2.7 instead of 2.9, change that?

As for the kf5 port: it is mostly done, and several distros already ship an
unofficial release, we simply don't have a finished version, but we
certainly should do a tech preview alpha just to get things rolling faster
again.

Currently we are faced with the big problem of MySQL embedded having been
deprecated upstream, and we need to make a substantial change for the
database, which is currently been decided upon.

So instead of removing the website which I strongly oppose, how about a
static page mentioning the latest 2.9 release with screenshot numbering
updated, and a link to kft5 master in git? Also worth mentioning would be
the rolling release distros who already ship the kf5 version.

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: embedded MySql alternatives

[Soren Harward]

Sorry, I meant "baloo's scanning capabilities, which are much better than
strigi's were."

--
Soren Harward
stharw...@gmail.com

On Mon, Jan 6, 2020, 11:02 Soren Harward  wrote:

> I've done testing with SQLite in other applications, and I don't think the
> problems we had with it 10 years ago are relevant anymore due to
> improvements in both hardware and software. I've got a private branch where
> I started porting Amarok's code over to SQLite a couple of years ago, but
> didn't finish it. It's still a worthy goal.
>
> The other thing I started doing in that branch is using baloo for file
> scanning and metadata extraction, with only Amarok-specific data like play
> counts stored in the SQLite DB. That, I think, is the best way to go so
> Amarok doesn't duplicate strigi's pretty good scanning capabilities.
>
> --
> Soren Harward
> stharw...@gmail.com
>
> On Mon, Jan 6, 2020, 10:31 Myriam Schweingruber  wrote:
>
>> Hi Leo,
>>
>> On Sun, 5 Jan 2020 at 10:11, subscription1 
>> wrote:
>>
>>> Given that the embedded MySql has disappeared from the latest Ubuntu
>>> release the only other alternative to install Amarok on this (and later)
>>> releases I can see is to
>>>
>>>1. Make amarok installation dependant on a MySQL server installation
>>>2. Use something like Sqlite as the default
>>>
>>> I don't really have a solution, but I know we deliberately changed from
>> SQLite wich was default in Amarok 1.x to MySQL embedded with the option of
>> MySQL Server due to the bad scaling of SQLite. Many users of Amarok
>> requested that change, some having enormous databases that were very
>> slow to handle with SQLite.
>>
>> We probably have to choose the first option, but giving the users the
>> option to use an existing MySQL server installation or creating one just
>> for Amarok. There also is software in place (probably outdated) to use
>> Akonadi which we waited to get usable before adopting it, something which
>> even Kmail is still struggling with, unless Akonadi is used with PostgreSQL.
>> Of course another option would be to change to PostgreSQL which scales
>> quite well and might be a better solution. This looks like something we
>> would need to ask the users TBH.
>>
>> Regards, Myriam
>>
>> PS. Unless we find a better embedded database system, of course...
>> --
>> Proud member of the Amarok and KDE Community
>> Protect your freedom and support the work of the FSFE:
>> http://www.fsfe.org
>> 
>> Please don't send me proprietary file formats,
>> use ISO standard ODF instead (ISO/IEC 26300)
>>
>

Re: embedded MySql alternatives

[Soren Harward]

I've done testing with SQLite in other applications, and I don't think the
problems we had with it 10 years ago are relevant anymore due to
improvements in both hardware and software. I've got a private branch where
I started porting Amarok's code over to SQLite a couple of years ago, but
didn't finish it. It's still a worthy goal.

The other thing I started doing in that branch is using baloo for file
scanning and metadata extraction, with only Amarok-specific data like play
counts stored in the SQLite DB. That, I think, is the best way to go so
Amarok doesn't duplicate strigi's pretty good scanning capabilities.

--
Soren Harward
stharw...@gmail.com

On Mon, Jan 6, 2020, 10:31 Myriam Schweingruber  wrote:

> Hi Leo,
>
> On Sun, 5 Jan 2020 at 10:11, subscription1 
> wrote:
>
>> Given that the embedded MySql has disappeared from the latest Ubuntu
>> release the only other alternative to install Amarok on this (and later)
>> releases I can see is to
>>
>>1. Make amarok installation dependant on a MySQL server installation
>>2. Use something like Sqlite as the default
>>
>> I don't really have a solution, but I know we deliberately changed from
> SQLite wich was default in Amarok 1.x to MySQL embedded with the option of
> MySQL Server due to the bad scaling of SQLite. Many users of Amarok
> requested that change, some having enormous databases that were very slow
> to handle with SQLite.
>
> We probably have to choose the first option, but giving the users the
> option to use an existing MySQL server installation or creating one just
> for Amarok. There also is software in place (probably outdated) to use
> Akonadi which we waited to get usable before adopting it, something which
> even Kmail is still struggling with, unless Akonadi is used with PostgreSQL.
> Of course another option would be to change to PostgreSQL which scales
> quite well and might be a better solution. This looks like something we
> would need to ask the users TBH.
>
> Regards, Myriam
>
> PS. Unless we find a better embedded database system, of course...
> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> 
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)
>

Re: embedded MySql alternatives

[Myriam Schweingruber]

Hi Leo,

On Sun, 5 Jan 2020 at 10:11, subscription1  wrote:

> Given that the embedded MySql has disappeared from the latest Ubuntu
> release the only other alternative to install Amarok on this (and later)
> releases I can see is to
>
>1. Make amarok installation dependant on a MySQL server installation
>2. Use something like Sqlite as the default
>
> I don't really have a solution, but I know we deliberately changed from
SQLite wich was default in Amarok 1.x to MySQL embedded with the option of
MySQL Server due to the bad scaling of SQLite. Many users of Amarok
requested that change, some having enormous databases that were very slow
to handle with SQLite.

We probably have to choose the first option, but giving the users the
option to use an existing MySQL server installation or creating one just
for Amarok. There also is software in place (probably outdated) to use
Akonadi which we waited to get usable before adopting it, something which
even Kmail is still struggling with, unless Akonadi is used with PostgreSQL.
Of course another option would be to change to PostgreSQL which scales
quite well and might be a better solution. This looks like something we
would need to ask the users TBH.

Regards, Myriam

PS. Unless we find a better embedded database system, of course...
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and support the work of the FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Translations tracking for Amarok 2.8

[Heiko Becker]

Hello Luigi,

On Sonntag, 17. November 2019 20:05:58 CET, Luigi Toscano wrote:

We are still tracking the translations of the last Qt4 Amarok branch (2.9).

Can I safely assume that the next version, whenever it happens, will be
Qt5-based (master), which means that we can stop tracking that branch for
translations?


yes, I think that's a safe bet.

Best regards,
Heiko

Re: Deprecating Old Amarok Versions

[Jonathan Riddell]

On Thu, 3 Oct 2019 at 11:47, Myriam Schweingruber  wrote:
> Indeed, and some distros have already jumped the gun and ship a master
build without notifying their users that they ship a pre-beta version...
> About the bugs: those were already there in the Qt4 version, just not
that noticeable. What we need to do is port those pesky Plasma widgets to
QML. It's certainly not hard, but tiresome, at least the most used ones
need a port so we can make a tech preview release. Also, Qt6 is already
around the corner...
> As for the Qt4 versions: we didn't deprecate it on purpose, as there were
still distros shipping it, Suse and Debian are the last to have finally
jumped on the Qt5-wagon. Not talking about CentOS, as they lag behind
pretty much everything anyway...

It's up to distros what they do with our software, we can't control them,
but we can make a clear recommendation.  And once the dependencies no
longer exist in a supported way we should be responsible for the
applications that use that deps which we ship.

> So far I don't think we ever removed tarballs, moving to the attic makes
far more sense.

Of course that would be the way to do it.

> Did I mention that Amarok was never shipped with KDE application releases
anyway, so I don't see any urgency in here.

It doesn't especially matter who makes the releases.

> I let the sysadmins decide what is best...

We shouldn't burden sysadmins with even more policy decisions.

Jonathan


Regards, Myriam


> --
> Proud member of the Amarok and KDE Community
> Protect your freedom and support the work of the FSFE:
> http://www.fsfe.org
> 
> Please don't send me proprietary file formats,
> use ISO standard ODF instead (ISO/IEC 26300)
>

Re: Missing icons outside of DE

[Heiko Becker]

Hey,

sorry for the late answer.

On Dienstag, 30. April 2019 11:37:03 CEST, Bennett Piater wrote:

Hi! I'm running Amarok KF5 2.9.7* without DE (i3wm, qt5ct, archlinux).
I cannot see most icons, e.g. in the settings menu or top-level 
library selection.

I do see some, such as the play button or the caret to expand trees.
Other KF5 applications work fine, e.g. Okular or Dolphin.

Any idea what could be wrong, whether Amarok is at fault, or 
where I could report this?


AFAIK the Qt platform plugin influences the used icons. For i3 and others 
that's probably none. Does exporting XDG_CURRENT_DESKTOP=KDE make a 
difference or, since you mentioned qt5ct, QT_QPA_PLATFORMTHEME="qt5ct"?



*: commit is f0d3e6f069dd2e60b299ea855e5ac4759582923e, built from
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=amarok


Regards,
Heiko

Re: Sponsorship

[Myriam Schweingruber]

Hi Valorie,

On Tue, 20 Nov 2018 at 21:47, Valorie Zimmerman <
valorie-zimmer...@kubuntu.org> wrote:

> This could be spam, or it could be a serious offer. I don't have the means
> to follow up, myself. The website https://icons8.com/ does exist. -v
>

Seems legit, but I think they should contact the e.V., as we do not handle
money ourselves anyway. As other donations have shown it is perfectly OK to
donate to a specific project within KDE.
Especially since they are based in the US, this would be too much hassle to
try to handle it ourselves.

The only slight bother I have is them talking about "Open Source", but the
only actual application they have is proprietary, and I can't find any
license on the website but the
https://creativecommons.org/licenses/by-nd/3.0/ one which is the most
restricted possible creative commons licenses. And this is only for the
actual icons. Using the icons as an "established Open Source" project
requires setting a link back to them, which is something we would only do
for actual sponsors. I really very much prefer the e.V. to handle any
further steps.

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Amarok 2.9.0 "Hibernaculum" released

[Mark Kretschmann]

So if you don't want to go through the hassle of checking it out from Git,
you could simply delete that one line in the source code, as indicated by
Heiko's linked patch.

Sorry for the trouble :)

Mark


On Fri, Mar 9, 2018 at 8:42 AM, Heiko Becker  wrote:

> Hello Michał,
>
> On 03/08/18 12:57, Michał Zając wrote:
> > /root/amarok/amarok-2.9.0/src/playlist/proxymodels/SortAlgorithms.cpp:
> > In member function ‘bool Playlist::multilevelLessThan::operator()(const
> > QAbstractItemModel*, int, int) const’:
> > /root/amarok/amarok-2.9.0/src/playlist/proxymodels/
> SortAlgorithms.cpp:98:21:
> > error: expected primary-expression before ‘__attribute__’
> >  __attribute__ ((fallthrough));
> >  ^
> > src/CMakeFiles/amaroklib.dir/build.make:2716: recipe for target
> > 'src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o'
> > failed
> > make[2]: ***
> > [src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o]
> > Error 1
> > CMakeFiles/Makefile2:369: recipe for target
> > 'src/CMakeFiles/amaroklib.dir/all' failed
> > make[1]: *** [src/CMakeFiles/amaroklib.dir/all] Error 2
> > Makefile:138: recipe for target 'all' failed
> > make: *** [all] Error 2>
> > Am I the only one getting this?
>
> Unfortunately not, but it's already fixed in the 2.9 branch:
> https://cgit.kde.org/amarok.git/commit/?h=2.9=
> f047cd8219d9537bb33bba3883bedf6231a0ed5f
> (Or you can switch to gcc7).
>
> Regards,
> Heiko
>

Re: Amarok 2.9.0 "Hibernaculum" released

[Heiko Becker]

Hello Michał,

On 03/08/18 12:57, Michał Zając wrote:
> /root/amarok/amarok-2.9.0/src/playlist/proxymodels/SortAlgorithms.cpp:
> In member function ‘bool Playlist::multilevelLessThan::operator()(const
> QAbstractItemModel*, int, int) const’:
> /root/amarok/amarok-2.9.0/src/playlist/proxymodels/SortAlgorithms.cpp:98:21:
> error: expected primary-expression before ‘__attribute__’
>                      __attribute__ ((fallthrough));
>                      ^
> src/CMakeFiles/amaroklib.dir/build.make:2716: recipe for target
> 'src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o'
> failed
> make[2]: ***
> [src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o]
> Error 1
> CMakeFiles/Makefile2:369: recipe for target
> 'src/CMakeFiles/amaroklib.dir/all' failed
> make[1]: *** [src/CMakeFiles/amaroklib.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2>
> Am I the only one getting this?

Unfortunately not, but it's already fixed in the 2.9 branch:
https://cgit.kde.org/amarok.git/commit/?h=2.9=f047cd8219d9537bb33bba3883bedf6231a0ed5f
(Or you can switch to gcc7).

Regards,
Heiko

Re: Amarok 2.9.0 "Hibernaculum" released

[Michał Zając]

/root/amarok/amarok-2.9.0/src/playlist/proxymodels/SortAlgorithms.cpp: In
member function ‘bool Playlist::multilevelLessThan::operator()(const
QAbstractItemModel*, int, int) const’:
/root/amarok/amarok-2.9.0/src/playlist/proxymodels/SortAlgorithms.cpp:98:21:
error: expected primary-expression before ‘__attribute__’
 __attribute__ ((fallthrough));
 ^
src/CMakeFiles/amaroklib.dir/build.make:2716: recipe for target
'src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o'
failed
make[2]: ***
[src/CMakeFiles/amaroklib.dir/playlist/proxymodels/SortAlgorithms.cpp.o]
Error 1
CMakeFiles/Makefile2:369: recipe for target
'src/CMakeFiles/amaroklib.dir/all' failed
make[1]: *** [src/CMakeFiles/amaroklib.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Am I the only one getting this?

On Thu, Mar 8, 2018 at 12:26 PM, Stefano Pettini 
wrote:

> Thank you for taking case of the release!
>
> Stefano
>
> On Wed, Mar 7, 2018 at 8:49 PM, Heiko Becker  wrote:
>
>> Hello everybody,
>>
>> as it may be customary for the upcoming season the Amarok team did some
>> spring cleaning and is proud to announce the immediate release of Amarok
>> 2.9.0. While we realize that the clock has run out on KDELibs 4 and Qt
>> 4, we wanted to bring 20+ bug fixes from 18 contributors to our users
>> before the next major release will harness all the shiny new things
>> provided by Qt 5 and KDE Frameworks 5. In fact, the port is already
>> progressing nicely in the Git 'kf5' branch, which is soon to become the
>> new ‘master’ branch. We welcome everybody willing to help out to check
>> out the source code and improve the next major version of Amarok!
>>
>>
>> Download:
>> 
>> https://download.kde.org/stable/amarok/2.9.0/src/amarok-2.9.0.tar.xz
>>
>> SHA-256:
>> e3678de79db36956bc8588b9905726ace1b9188e7fdf89eaea265f1cb03116fd
>> GPG fingerprint:
>> D81C0CB38EB725EF6691C385BB463350D6EF31EF
>>
>>
>> List of important changes since 2.8.90:
>> -
>> - Fixed "Open Last-fm webpage" of similar artist
>> (https://bugs.kde.org/show_bug.cgi?id=354849)
>> - VFAT-safe file and directory names cannot end with dot
>> (https://bugs.kde.org/show_bug.cgi?id=388465)
>> - Fixed transcoding to AAC format by switching to the latest 'aac'
>> ffmpeg encoder (https://bugs.kde.org/show_bug.cgi?id=374670)
>> - Fix crash during musicbrainz search
>> (https://bugs.kde.org/show_bug.cgi?id=328359)
>> - Fix Gpodder credential service without kwallet
>> (https://git.reviewboard.kde.org/r/122797/)
>> - Fix Bug 302299 - Autoscrolling Lyrics are scrolling down if a song is
>> rated via Context Browser's Current Track
>> (https://bugs.kde.org/show_bug.cgi?id=302299)
>> - Fix Collection Browser auto-expand after search expanding too little
>> (https://bugs.kde.org/show_bug.cgi?id=335217)
>> - Fix MPRIS2 DesktopEntry value
>> (https://bugs.kde.org/show_bug.cgi?id=365275)
>> - Organize tracks / Guess tags presets persisted properly
>> (https://bugs.kde.org/show_bug.cgi?id=226144)
>> - Use transparent background for lyrics browser
>> (https://bugs.kde.org/show_bug.cgi?id=314854)
>> - Handle numeric fields properly in filter creation dialogs
>> (https://bugs.kde.org/show_bug.cgi?id=341661)
>> - Substitute deprecated MySQL option --myisam-recover
>> (https://bugs.kde.org/show_bug.cgi?id=354255)
>> - Disable non SSL connections in wikipedia applet
>> (https://bugs.kde.org/show_bug.cgi?id=348313)
>> - Fix build with gcc6 (https://bugs.kde.org/show_bug.cgi?id=363054)
>> - Fix untranslatable string in Organize Collection Dialog
>> (https://bugs.kde.org/show_bug.cgi?id=331443)
>> - Fix for the infinite loop in case a home-burned or old audio CD is
>> inserted (https://bugs.kde.org/show_bug.cgi?id=339190)
>> - Fix tabs applet and change it to use https
>> (https://bugs.kde.org/show_bug.cgi?id=358408)
>> - Fix Taglib version check (https://bugs.kde.org/show_bug.cgi?id=351013)
>> - Fix amarok build with LibOFA using ffmpeg 3+
>> (https://git.reviewboard.kde.org/r/129626)
>> - Make Qt4Webkit optional (https://phabricator.kde.org/D10923)
>>
>
>

Re: Amarok 2.9.0 "Hibernaculum" released

[Stefano Pettini]

Thank you for taking case of the release!

Stefano

On Wed, Mar 7, 2018 at 8:49 PM, Heiko Becker  wrote:

> Hello everybody,
>
> as it may be customary for the upcoming season the Amarok team did some
> spring cleaning and is proud to announce the immediate release of Amarok
> 2.9.0. While we realize that the clock has run out on KDELibs 4 and Qt
> 4, we wanted to bring 20+ bug fixes from 18 contributors to our users
> before the next major release will harness all the shiny new things
> provided by Qt 5 and KDE Frameworks 5. In fact, the port is already
> progressing nicely in the Git 'kf5' branch, which is soon to become the
> new ‘master’ branch. We welcome everybody willing to help out to check
> out the source code and improve the next major version of Amarok!
>
>
> Download:
> 
> https://download.kde.org/stable/amarok/2.9.0/src/amarok-2.9.0.tar.xz
>
> SHA-256:
> e3678de79db36956bc8588b9905726ace1b9188e7fdf89eaea265f1cb03116fd
> GPG fingerprint:
> D81C0CB38EB725EF6691C385BB463350D6EF31EF
>
>
> List of important changes since 2.8.90:
> -
> - Fixed "Open Last-fm webpage" of similar artist
> (https://bugs.kde.org/show_bug.cgi?id=354849)
> - VFAT-safe file and directory names cannot end with dot
> (https://bugs.kde.org/show_bug.cgi?id=388465)
> - Fixed transcoding to AAC format by switching to the latest 'aac'
> ffmpeg encoder (https://bugs.kde.org/show_bug.cgi?id=374670)
> - Fix crash during musicbrainz search
> (https://bugs.kde.org/show_bug.cgi?id=328359)
> - Fix Gpodder credential service without kwallet
> (https://git.reviewboard.kde.org/r/122797/)
> - Fix Bug 302299 - Autoscrolling Lyrics are scrolling down if a song is
> rated via Context Browser's Current Track
> (https://bugs.kde.org/show_bug.cgi?id=302299)
> - Fix Collection Browser auto-expand after search expanding too little
> (https://bugs.kde.org/show_bug.cgi?id=335217)
> - Fix MPRIS2 DesktopEntry value
> (https://bugs.kde.org/show_bug.cgi?id=365275)
> - Organize tracks / Guess tags presets persisted properly
> (https://bugs.kde.org/show_bug.cgi?id=226144)
> - Use transparent background for lyrics browser
> (https://bugs.kde.org/show_bug.cgi?id=314854)
> - Handle numeric fields properly in filter creation dialogs
> (https://bugs.kde.org/show_bug.cgi?id=341661)
> - Substitute deprecated MySQL option --myisam-recover
> (https://bugs.kde.org/show_bug.cgi?id=354255)
> - Disable non SSL connections in wikipedia applet
> (https://bugs.kde.org/show_bug.cgi?id=348313)
> - Fix build with gcc6 (https://bugs.kde.org/show_bug.cgi?id=363054)
> - Fix untranslatable string in Organize Collection Dialog
> (https://bugs.kde.org/show_bug.cgi?id=331443)
> - Fix for the infinite loop in case a home-burned or old audio CD is
> inserted (https://bugs.kde.org/show_bug.cgi?id=339190)
> - Fix tabs applet and change it to use https
> (https://bugs.kde.org/show_bug.cgi?id=358408)
> - Fix Taglib version check (https://bugs.kde.org/show_bug.cgi?id=351013)
> - Fix amarok build with LibOFA using ffmpeg 3+
> (https://git.reviewboard.kde.org/r/129626)
> - Make Qt4Webkit optional (https://phabricator.kde.org/D10923)
>

Re: Amarok 2.9.0 "Hibernaculum" released

[Heiko Becker]

On 03/07/18 22:44, Alex Arvelaez wrote:
> How do I stop cmake from building the tests? I'm getting an error about
> missing libgmock, I tried passing -DKDE4_BUILD_TESTS=OFF to cmake but
> it didn't do much.

-DBUILD_TESTING=OFF (which is the canonical cmake option for that)

Cheers,
Heiko

Re: Amarok 2.9.0 "Hibernaculum" released

[stefan]

Hi,


Apparently you need a pretty new libmygpo-qt and add this pull request:
https://github.com/gpodder/libmygpo-qt/pull/12


I finally had time to check out the Merge Request. If nothing else comes 
up in the porting, I will soon release a 1.10 version and then KF5 
Amarok can depend on this version :)


Stefan

Re: Amarok 2.9.0 "Hibernaculum" released

[Alex Arvelaez]

On Wed, Mar 07, 2018 at 10:13:38PM +0100, Heiko Becker wrote:
> Hi Alex,
> 
> > I got the source code right away but when I try to build the kf5 branch I
> > get an error that it can't find FindMygpo-qt5.cmake (I installed
> > libmygpo-qt5-devel, I'm using Fedora). I searched through my system and
> > indeed there's no FindMygpo-qt5. Any idea where I can find that file?
> > Google didn't give me much to go with :-)
> 
> I wanted to look into this, but wanted to do the release first.
> Apparently you need a pretty new libmygpo-qt and add this pull request:
> https://github.com/gpodder/libmygpo-qt/pull/12
> But it's an optional dependency and you should be able to build without
> it for now, if you don't need the feature of course.

Oh I see, thanks. I managed to find Mygpo-qt5Config.cmake in my system
and passed -DMygpo-qt5_DIR=/path/to/Mygpo-qt5Config.cmake and it got it
to start building that way(will this cause issues?).

How do I stop cmake from building the tests? I'm getting an error about
missing libgmock, I tried passing -DKDE4_BUILD_TESTS=OFF to cmake but
it didn't do much.

Regards,

Alex

Re: Amarok 2.9.0 "Hibernaculum" released

[Heiko Becker]

Hi Alex,

> I got the source code right away but when I try to build the kf5 branch I
> get an error that it can't find FindMygpo-qt5.cmake (I installed
> libmygpo-qt5-devel, I'm using Fedora). I searched through my system and
> indeed there's no FindMygpo-qt5. Any idea where I can find that file?
> Google didn't give me much to go with :-)

I wanted to look into this, but wanted to do the release first.
Apparently you need a pretty new libmygpo-qt and add this pull request:
https://github.com/gpodder/libmygpo-qt/pull/12
But it's an optional dependency and you should be able to build without
it for now, if you don't need the feature of course.

Cheers,
Heiko