Everythings in the title :))

thanks for considering

Frederic

Picca Frédéric-Emmanuel dixit:

Not before bullseye. There are many regressions and problems
with the new releases. I plan on doing (at least) one more
upload with more individual fixes backported, though ☺

My current plan is to package 3.6.x after bullseye, providing
them to users via bullseye-backports and buster-backports-sloppy
as usual.

With enough time I’ll begin packaging these in experimental.

Thanks,
//mirabilos

Hi Thorsten,

It's been a little while. Do you still plan on working on this?

John Scott dixit:

Yes, as time permits. I’m even keeping my ear on a possible
inofficial (as the new Muse Group management is disinterested)
3.7 which is accumulating over a hundred fixes still. I’m
still wary of the regressions relative to 3.2 though which
I fear will require a nōntrivial amount of original work on
my side.

bye,
//mirabilos

Hi Thorsten,

Thorsten Glaser <tg@mirbsd.de> writes:

Furthering our discussion on IRC, if necessary, I'm interested in
helping out with updating Musescore3 later this summer.  There is also
notable interest on IRC in #debian-quebec for seeing this package
updated :) and also sadness at being forced to use upstream's AppImage,
in cases where 3.2.3+dfsg2-11 proves insufficient.

In an earlier update you mentioned that there were numerous regressions
and problems with these new releases.  Are these limited to non-dfsg
components (such as instrument samples) that need to be replaced, and
are there too many problems that it would make sense listing them?
Would it be useful to start a Musescore team to divide the workload,
assuming that it's divisible?  I'm guessing it's something painful like
tracking down many non-dfsg things before being able to important the
new upstream orig.tar.

Regards,
Nicholas

(warning, bit of rambling, plus I was interruped multiple times while
writing this and not fully awake yet either)

Nicholas D Steeves dixit:

No, they are core UX, such as note input mode.

I’ve got somewhat concrete plans. The situation with MuseScore 3 is
as follows:

• we currently have 3.2.3 in Debian, which is suitable for almost all
  workflows 3.6.2 (the current upstream release) is, with the notable
  exceptions being playable chord symbols and the new Leland font (we
  *do* have the new MScore font)

• our 3.2.3 is fully compatible with mu͒.com

• I personally have issues with the 3.3+ regressions as stated above

• upstream’s 3.6.2 is the last 3.x release they want to publish, they
  are politically interested in mu͒4 being the next release, but that’s
  nowhere near ready yet
  ‣ if a 4.x is released, we’ll have to keep 3.x anyway, for old scores,
    just like we need to keep 2.x around

• upstream’s 3.6.2 is also fully compatible with mu͒.com, other than
  some changes to mu͒.com’s backend code that sometimes also affect 3.2.3

• 3.6.2 is a rather old (2021-02-08) and *also* buggy release

• there’s a community 3.7 effort that’s already got no less than 323
  commits with bugfixes relative to 3.6.2
  ‣ this is what I’d probably work on if not for…
  ‣ this is completely unsupported on mu͒.com *and* by upstream formally
  ‣ it has no releases, only git snapshots, with occasional rebases,
    and occasionally introduces regressions on itself

At this point in time, I believe that keeping the 3.2.3 we have and
backporting bugfixes to that, in the musescore3 package, and packaging
musescore4 once it’s out, is (given effort/gain) the best thing to do.

You *can* help in identifying commits that have gone into 3.3+ that
correct issues, I’m aware of at least the frame vs. pagebreak one.
However, we *cannot* backport some changes because they alter the
file format and the mu͒.com (and 3.3+) importers will see it’s a 3.2
file and therefore expect certain issues to be present. I’m aware
there’s at least one change we cannot do.

Note that our 3.2 package already has about a hundred backported
fixes already, too… and also note that 3.3+ use QML much more, which
involves qtweb* stuff more…

We *can* package *either* 3.6.2 *or* the 3.7 community effort, but
almost certainly(?) not both, in addition to the aforementioned plan.
However:
• until the UX regressions are addressed (and we’re sure that there
  are no other regressions against the very stable 3.2 codebase we
  currently use), I’d prefer this to not replace the 3.2 package
  ‣ we do have musescore-snapshot, which we can use, even with sid
    ⇒ this name would fit the 3.7 community effort better ☻
• ftpmasters might eventually protest the addition of even more
  musescoreXXX packages; we have justifyable reason for at least
  musescore{2,3,4} and probably -snapshot
• losing mu͒.com support is certainly a disservice to users, but so
  is updating to a >1-year-old known-buggy version :~

We could, on the other hand, package git master (“to be 4.x”) now
already, to get a feeling for it. I’d treat it as almost completely
new packaging project; certainly for d/copyright at least (much of
the old code was removed, almost all of it was moved path‑ and file‐
name-wise, and all was reindented). We could do it as m-snapshot in
experimental, or even as musescore4, going through ftpmaster review
for it (but maybe not this early yet?). Things to watch out:
• qtweb* stuff (not portable to all architectures, disable)
  ‣ also: phones home, e.g. I disabled the Start Centre in 3.x
    because it loads from yandex.ru and lately also Google Analytics
• phoning home in general (update checker, etc.)
• parts of the playback functionality is now a “freeware” binary
  add-on plugin only available from their in-program download store
• … maybe more

If you have interest in *that*, it might be more long-term beneficial.
They just (end of March 2022) released the first alpha of it. And I’ll
be available for help and review, too, of course. My current focus is
on backporting fixes to our known-good 3.2.3 version, though.

Hmm. I seem to have lost my mental thread here. Eh, anyway, written
a lot already — tell me what you think.

Hi Thorsten,

Sorry for the extremely belated reply.  I did read your reply soon after
you sent it :)

Thorsten Glaser <tg@debian.org> writes:

No worries, and I appreciate your detailed explanation!

Oh, wow, yeah, that sounds like this would need a lot of work.

[snip rationale for sticking with 3.2.3]

Oh my.

Ah, now I see what you mean about 4.x being upstream focus.

Agreed!

If I run into a bug then I'll dig for new commits.

Wow, that's amazing.  Thank you again for your work :)

Agreed, it sounds like we'd be worse off with 3.6.2 or 3.7 at this
time.

Agreed, from what you're saying it sounds like it's still too early.

Oh my...

Wow, that plugin doesn't sound very nice...  I wonder why it can't be
released under a dfsg-compatible license?

This is a perfect conclusion.  Thank you very much for taking the time
to explain all of the outstanding issues, and once again I'm sorry for
taking so long to reply.

Yes, I completely agree; This sounds like a case where the Debian model
of a stable base plus backported fixes results in a more reliable tool
than running the latest available release.  Also, it sounds like it will
be best to wait for the future-4.x series' first beta before starting to
work on a musecore4 package.

Would you please consider keeping this bug open in case other people
wonder why things are the way they are with Musescore in Debian?

Regards,
Nicholas

Nicholas D Steeves dixit:

No problem, we are all doing this in our spare time…

They focus on it to the exclusion of 3.x support. It was similar
in the late stages of 3.x alphas for 2.x, but not as bad; they had
a working 2.x and users wanted fixes, and they gave them fixes, but
this resulted in 3.0 being delayed for over a year so they didn’t
want to repeat it. (Of course, 4.0 is still very much away, so it’s
obviously not (just) that…)

Thanks! Same here, I have a few queued up and just noticed an
error for the status line when capodaster is used which I’ll fix
since the status line code is from me (and the capo code apparently
was slapped on without fixing internal pitch housekeeping).

Ostensibly (the formal answer I got to this when asking on the .org
forums) because “that would then require the sound libraries to also
be open-sourced”, which is obviously wrong. I called Daniel Ray out
on it but he never answered. Months later in an interview for Scoring
Notes, he’s indicated it is so they can use it in a commercial product
of Muse Group where the playback engine is basically the USP of their
iOS äpp, vs competitor äpps. So he lied, as I thought.

I agree, and most users agreed when I explained this to them.

Those who need chord playback or those other rare new-in-3.x features
can use the chords-to-notes plugin or use the upstream-provided
containerised images, which upstream promotes over the packaging
efforts anyway. (I feel underappreciated sometimes. I hinted at
licence compatibility problems for these, but I don’t really want
to stick time into *that* given the Debian packages are fine.)

Sure!

bye,
//mirabilos

No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc