[ubuntu-studio-devel] Ubuntu Studio 24.04 LTS Released

[Erich Eickmeyer]

[image: This image has an empty alt attribute; its file name is
finalbanner.png]

The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio
24.04 LTS, code-named “Noble Numbat”. This marks Ubuntu Studio’s 34th
release. This release is a Long-Term Support release and as such, it is
supported for 3 years (36 months, until April 2027).

Since it’s just out, you may experience some issues, so you might want to
wait a bit before upgrading. Please see the release notes
 for a
more complete list of changes and known issues. Listed here are some of the
major highlights.
[image: This image has an empty alt attribute; its file name is
VirtualBox_ISOTest_22_04_2024_13_18_58.png]

You can download Ubuntu Studio 24.04 LTS from our download page
.
Special Notes

The Ubuntu Studio 24.04 LTS disk image (ISO) exceeds 4 GB and cannot be
downloaded to some file systems such as FAT32 and may not be readable when
burned to a standard DVD. For this reason, we recommend downloading to a
compatible file system. When creating a boot medium, we recommend creating
a bootable USB stick
 with
the ISO image or burning to a Dual-Layer DVD.

Minimum installation media requirements: Dual-Layer DVD or 8GB USB drive.

Images can be obtained from this link:
https://cdimage.ubuntu.com/ubuntustudio/releases/24.04/beta/

Full updated information, including Upgrade Instructions, are available in
the Release Notes
.


Please note that upgrading from 22.04 before the release of 24.04.1, due
August 2024, is unsupported.

Upgrades from 23.10 should be enabled within a month after release, so we
appreciate your patience.
New This ReleaseAll-New System Installer
[image: This image has an empty alt attribute; its file name is
VirtualBox_ISOTest_22_04_2024_10_00_48.png]

In cooperation with the Ubuntu Desktop Team, we have an all-new Desktop
installer. This installer uses the underlying code of the Ubuntu Server
installer ("Subiquity") which has been in-use for years, with a frontend
coded in "Flutter". This took a large amount of work for this release, and
we were able to help a lot of other official Ubuntu flavors transition to
this new installer.

Be on the lookout for a special easter egg when the graphical environment
for the installer first starts. For those of you who have been long-time
users of Ubuntu Studio since our early days (even before Xfce!), you will
notice exactly what it is.
PipeWire 1.0.4
[image: This image has an empty alt attribute; its file name is
Pipewire_logo.svg_.png]

Now for the big one: PipeWire is now mature, and this release contains PipeWire
1.0. With PipeWire 1.0 comes the stability and compatibility you would
expect from multimedia audio. In fact, at this point, we recommend PipeWire
usage for both Professional, Prosumer, and Everyday audio needs. At Ubuntu
Summit 2023 in Riga, Latvia, our project leader Erich Eickmeyer used
PipeWire to demonstrate live audio mixing with much success and has since
done some audio mastering work using it. JACK developers even consider it
to be "JACK 3".

PipeWire's JACK compatibility is configured to use out-of-the-box and is
zero-latency internally. System latency is configurable via Ubuntu Studio
Audio Configuration.

However, if you would rather use straight JACK 2 instead, that's also
possible. Ubuntu Studio Audio Configuration can disable and enable
PipeWire's JACK compatibility on-the-fly. From there, you can simply use
JACK via QJackCtl.

With this, we consider audio production with Ubuntu Studio so mature that
it can now rival operating systems such as macOS and Windows in ease-of-use
since it's ready to go out-of-the-box.
Deprecation of PulseAudio/JACK setup/Studio Controls

Due to the maturity of PipeWire, we now consider the traditional
PulseAudio/JACK setup, where JACK would be started/stopped by Studio
Controls and bridged to PulseAudio, deprecated. This configuration is still
installable via Ubuntu Studio Audio Configuration, but we do not recommend
it. Studio Controls may return someday as a PipeWire fine-tuning solution,
but for now it is unsupported by the developer. For that reason, we
recommend users not use this configuration. If you do, it is at your own
risk and no support will be given. In fact, it's likely to be dropped for
24.10.
Ardour 8.4
[image: This image has an empty alt attribute; its file name is ardour.png]

While this does not represent the latest release of Ardour, Ardour 8.4 is a
great release. If you would like the latest release, we highly
recommend purchasing
one-time or subscribing to Ardour

directly from the developers to help support this wonderful application.

[ubuntu-studio-devel] Ubuntu Studio 24.04 LTS Beta Released

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu 
Studio 24.04 LTS, codenamed “Noble Numbat”.


While this beta is reasonably free of any showstopper installer bugs, 
you will find some bugs within. This image is, however, mostly 
representative of what you will find when Ubuntu Studio 24.04 is 
released on April 25, 2024.



   Special Notes

The Ubuntu Studio 24.04 LTS disk image (ISO) exceeds 4 GB and cannot be 
downloaded to some file systems such as FAT32 and may not be readable 
when burned to a DVD. For this reason, we recommend downloading to a 
compatible file system. When creating a boot medium, we 
recommendcreating a bootable USB stick 
with 
the ISO image or burning to a Dual-Layer DVD.


Images can be obtained from this 
link:https://cdimage.ubuntu.com/ubuntustudio/releases/24.04/beta/


Full updated information, including*Upgrade Instructions,*are available 
in the*Release Notes 
*. 



*Please note that upgrading before the release of 24.04.1,**due August 
2024, is unsupported.*



   New Features This Release

 * *PipeWire*continues to improve with every release and is so robust
   it can be used for professional and prosumer use. Version 1.0.4
 * *Ubuntu Studio Installer*‘s included*Ubuntu Studio Audio
   Configuration
   *utility
   for fine-tuning the PipeWire setup or changing the configuration
   altogether now includes the ability to create or remove a dummy
   audio device. Version 1.9


   Major Package Upgrades

 * *Ardour*version 8.4.0
 * *Qtractor*version 0.9.39
 * *OBS Studio*version 30.0.2
 * *Audacity*version 3.4.2
 * *digiKam*version 8.2.0
 * *Kdenlive*version 23.08.5
 * *Krita*version 5.2.2

There are many other improvements, too numerous to list here. We 
encourage you to look around the freely-downloadable ISO image.



   Known Issues

 * Ubuntu Studio’s classic PulseAudio-JACK configuration cannot be used
   on Ubuntu Desktop (GNOME) due to a known issue with the
   ubuntu-desktop metapackage. (LP: #2033440
   )
 * We now discourage the use of the aforementioned classic
   PulseAudio-JACK configuration as PulseAudio is becoming deprecated
   with time in favor of PipeWire. PipeWire’s JACK configuration can be
   disabled to use JACK2 via QJackCTL for advanced users.
 * Due to the Ubuntu repositories being in-flux following the time_t
   transition and xz-utils security issue resolution, some items in the
   repository are uninstallable or causing other packaging conflicts.
   The Ubuntu Release Team is working around the clock to help resolve
   these issues, so patience is required.

Official Ubuntu Studio release notes can be found 
athttps://ubuntustudio.org/ubuntu-studio-24-04-LTS-release-notes/


Further known issues, mostly pertaining to the desktop environment, can 
be found at https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes/Kubuntu


Additionally, the main Ubuntu release notes contain more generic 
issues:https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890



   How You Can Help

Please test using the test cases onhttps://iso.qa.ubuntu.com. All you 
need is aLaunchpad account to get started.


Additionally, we need financial contributions. Our project lead, Erich 
Eickmeyer, is working long hours on this project and trying to generate 
a part-time income. Seethis post 
as to 
the reasons why andgo here to see 
how you can contribute financially (options are also in the sidebar).



   Frequently Asked Questions

*Q:*Does Ubuntu Studio contain snaps?
*A:*Yes. Mozilla’s distribution agreement with Canonical changed, and 
Ubuntu was forced to no longer distribute Firefox in a native .deb 
package. We have found that, after numerous improvements, Firefox now 
performs just as well as the native .deb package did.


Thunderbird has become a snap this cycle in order for the maintainers to 
get security patches delivered faster.


Additionally, Freeshow is an Electron-based application. Electron-based 
applications cannot be packaged in the Ubuntu repositories in that they 
cannot be packaged in a traditional Debian source package. While such 
apps do have a build system to create a .deb binary package, it 
circumvents the source package build system in Launchpad, which is 
required when packaging for Ubuntu. However, Electron apps also have a 
facility for creating snaps, which can be uploaded and included. 
Therefore, for Freeshow to be included in Ubuntu Studio, it had to be 
packaged as a snap.


*Q:*If I install this Beta release, will I have to reinstall when the 
final release comes out?
*A:*No. If you keep it 

[ubuntu-studio-devel] merging universe packages with new upstream versions before the 24.04 LTS feature freeze

[Matthias Klose]

The feature freeze for the 24.04 LTS release is approaching (Feb 29), 
however we have some packages which didn't see merges since the last 
Ubuntu LTS release, including packages with new upstream versions. 
Please have a look at


  https://merges.ubuntu.com/universe.html

and merge packages in time before the noble feature freeze.  When 
marking packages with "not needed", please include the version checked with.


Packages with just new Debian revisions should still be considered 
merging. As long as these don't introduce new features, these can still 
be done after feature freeze.


Thanks, Matthias

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Lukasz Zemczak]

Hello Ubuntu Studio!

At today's Technical Board meeting we have voted for the LTS status of
Ubuntu Studio for 24.04, and the vote has passed! So now it's all
official!

Congrats!

Cheers,

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Erich Eickmeyer]

Hi Lukasz,

Probably https://ubuntustudio.org/support at the appropriate time.

Thanks,
Erich

On 11/28/23 01:11, Lukasz Zemczak wrote:

Hey Erich!

This sounds very much like what I needed, thank you. I don't consider
this as a requirement, but do you think it would be possible to get
this support plan written down somewhere on a webpage or some
Studio-related wiki-page, so that it's easily accessible? That would
make it easier for users to know what kind of support to expect.
For contact/bug-filling information, I think the information present
right now is sufficient.

I think this is everything. This makes me feel confident that the
Ubuntu Studio team will be able to provide the necessary support for
the flavour for the length of the proposed LTS term (3 years) so I
could sign it off form the Technical Board POV.

Thanks!


On Fri, 24 Nov 2023 at 21:57, Erich Eickmeyer  wrote:

Hi Lukasz,

I'm going to use Xubuntu's one-paragraph example for this as it seems
reasonable and was approved by Steve, which sets a precedent.

Our support plan is limited to the Ubuntu Studio package set which is
generally updates and bugfixes to the multimedia packages we include, as
well as our own developed utilities (Ubuntu Studio Installer, Ubuntu
Studio Audio Configuration, etc.). We also assist Kubuntu with bugfixes
from time to time for the desktop environment and KDE application
packages as needed. Most packages come from Debian. We also backport
many packages to the backports repository for inclusion there.

I hope this is closer to what you're looking for and we can finally
settle this.

Erich

On 11/23/23 09:53, Lukasz Zemczak wrote:

Hello Erich!

I will be handling your LTS re-qualification from the TB side for Ubuntu Studio.

Thank you for providing information about your team and contacts, as
well as regarding the length of the LTS support. I think we almost
have everything to make a decision here. Per the requirements listed
here [1], the only thing missing from the 'support plan' POV would be
setting the expectations regarding the level of support Ubuntu Studio
would provide for the 3 years. Could we have like a wiki page or a
page on ubuntustudio outlining this? And mentioning the support
contacts and where to file bugs.

Thanks!

Cheers,

On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer  wrote:

Good morning Technical Board,

On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for 
24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am the primary 
contact with rosco2 as backup.

Thanks,
Erich
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
--
technical-board mailing list
technical-bo...@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board

On behalf of the Technical Board,


--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu



--
Łukasz 'sil2100' Zemczak
  Foundations Team
  Tools Squad Engineering Manager
  lukasz.zemc...@canonical.com
  www.canonical.com


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Lukasz Zemczak]

Hey Erich!

This sounds very much like what I needed, thank you. I don't consider
this as a requirement, but do you think it would be possible to get
this support plan written down somewhere on a webpage or some
Studio-related wiki-page, so that it's easily accessible? That would
make it easier for users to know what kind of support to expect.
For contact/bug-filling information, I think the information present
right now is sufficient.

I think this is everything. This makes me feel confident that the
Ubuntu Studio team will be able to provide the necessary support for
the flavour for the length of the proposed LTS term (3 years) so I
could sign it off form the Technical Board POV.

Thanks!


On Fri, 24 Nov 2023 at 21:57, Erich Eickmeyer  wrote:
>
> Hi Lukasz,
>
> I'm going to use Xubuntu's one-paragraph example for this as it seems
> reasonable and was approved by Steve, which sets a precedent.
>
> Our support plan is limited to the Ubuntu Studio package set which is
> generally updates and bugfixes to the multimedia packages we include, as
> well as our own developed utilities (Ubuntu Studio Installer, Ubuntu
> Studio Audio Configuration, etc.). We also assist Kubuntu with bugfixes
> from time to time for the desktop environment and KDE application
> packages as needed. Most packages come from Debian. We also backport
> many packages to the backports repository for inclusion there.
>
> I hope this is closer to what you're looking for and we can finally
> settle this.
>
> Erich
>
> On 11/23/23 09:53, Lukasz Zemczak wrote:
> > Hello Erich!
> >
> > I will be handling your LTS re-qualification from the TB side for Ubuntu 
> > Studio.
> >
> > Thank you for providing information about your team and contacts, as
> > well as regarding the length of the LTS support. I think we almost
> > have everything to make a decision here. Per the requirements listed
> > here [1], the only thing missing from the 'support plan' POV would be
> > setting the expectations regarding the level of support Ubuntu Studio
> > would provide for the 3 years. Could we have like a wiki page or a
> > page on ubuntustudio outlining this? And mentioning the support
> > contacts and where to file bugs.
> >
> > Thanks!
> >
> > Cheers,
> >
> > On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer  wrote:
> >> Good morning Technical Board,
> >>
> >> On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years 
> >> for 24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am 
> >> the primary contact with rosco2 as backup.
> >>
> >> Thanks,
> >> Erich
> >> --
> >> Erich Eickmeyer
> >> Project Leader - Ubuntu Studio
> >> Technical Lead - Edubuntu
> >> --
> >> technical-board mailing list
> >> technical-bo...@lists.ubuntu.com
> >> https://lists.ubuntu.com/mailman/listinfo/technical-board
> > On behalf of the Technical Board,
> >
> --
> Erich Eickmeyer
> Project Leader - Ubuntu Studio
> Technical Lead - Edubuntu
>


--
Łukasz 'sil2100' Zemczak
 Foundations Team
 Tools Squad Engineering Manager
 lukasz.zemc...@canonical.com
 www.canonical.com

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Aaron Rainbolt]

On 11/24/23 21:41, Steve Langasek wrote:

On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote:


SRUs in packages used by flavors (including flavor-specific packages) are
also common.

Speaking as a member of the SRU Team as well, I don't actually see evidence
of this.  There has been a run of SRUs right at the time of the mantic
release, related to release upgrades; and there was also a recent Lubuntu
SRU to lunar to fix *notifications* for release upgrades; but I can't think
of any other examples in the past few years.  This might be because it
happened that all of them were processed by other members of the SRU Team,
but that's statistically unlikely.  From my perspective, SRUs of core
packages in main are much more common.  Can you point to something I've
missed showing that flavor package SRUs are happening?


There are at least two high-profile fixes done in Lubuntu 22.04 via SRU, 
both of which were accepted by Chris Halse Rogers (RAOF).


There was a Calamares version update done via SRU in Lubuntu 22.04: 
https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1992507


There was an SRU for a highly problematic updater bug for Lubuntu 22.04 
that resulted in freezes when running updates and update notices not 
appearing anymore after an interrupted update (not do-release-upgrades, 
just normal package updates): 
https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255


tjaalton also helped out with an SRU for an updater problem when 
packages were to be removed: 
https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2012823


Together with the two SRUs you noted, this is at least *five* bugfixes 
pushed through by the Lubuntu team into the LTS over a year-and-a-half 
period, to keep the LTS working well for our end-users.(There may be 
even more I'm not aware of or don't remember, the ones I listed are just 
ones that were easy for me to remember and/or find.)


We also maintain a Backports PPA for newer versions on LXQt for 22.04, 
which can be enabled by users manually via add-apt-repository (it's not 
enabled by default and never will be per TB policy). This involves 
backporting the entire LXQt stack to Jammy to help our users have a 
better experience with the LTS if they have to use the LTS and don't 
want to use interim releases. Ubuntu Studio has a similar Backports 
repository delivered via a PPA for some of the software it ships. 
Kubuntu also has something similar for newer versions of KDE on 22.04. 
These are non-trivial to implement and take a significant amount of work 
to make sure that our users have what they need and want in the LTS. I 
would consider this a form of support, and while I don't believe such 
repositories should be necessary to qualify for LTS status, it should be 
noted that it's something we do. We put a lot of effort into keeping the 
LTS releases working well.


Aaron


(I think this is very relevant to the question of LTS qualification, because
demonstrating a track record of active maintenance of the stable release of
a flavor goes a long way to establishing that the flavor team is delivering
something that meets users' needs for an LTS.)


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Mike Squires]

Speaking as a user for some time, on multiple systems, of Ubuntu Studio, 
I can attest that the 20.04 version was extremely stable during the time 
I used it.


I am currently using for somewhat different purposes Xubuntu 22.04, and 
this has been a bit less stable for me than Studio 20.04.  I'm 
continuing to use it, but I've run into some minor issues that seem to 
have been taken care of by updates.  The difference between that and 
Studio is that I didn't run into that kind of problem with Studio.


Experience - ignore this portion unless it's useful

I used Ubuntu Studio on three workstations and two laptops, most of the 
time using 20.04.  I switched to Xubuntu since moving to a new window 
manager was a bit much for me at this time.  Two workstations dual boot 
LINUX and MS Windows 10 x64; my wife uses it professionally as a 
psychologist and we both use it to play a game with friends.


My first computer was an IBM 740 terminal connected to the Caltech 
7040/7090 number cruncher; my first personal computer was an IMSAI 
8080/ADM5 combination used primarily for text processing.


My experience with UNIX is a bit weird; I started with a Tandy 16B about 
40 years ago running XENIX-68K which eventually supported an online 
archive of "netnews", especially mod.sources (to the extent that Telebit 
and USR modems can be considered to be "online").  That system 
eventually moved to Open Desktop and then to Microport before being retired.


I decided to retread and bought a Sun 4/110 workstation and used that, 
plus the XENIX experience, to get a job at the Indiana University 
Computer Science department as their PC specialist (my job before that 
time used MS-DOS).  The principal job was to assist staff with using 
PC's in a UNIX (SunOS/IRIS) environment which eventually resulted in the 
department purchasing a license of an MS Windows based XWindows package 
for secretarial staff to use for documents written in TeX.


At IU I learned about 386BSD and have used that, and it's versions, 
since its release.  My home server currently uses FreeBSD v 13, mainly 
due to its familiarity.


At work I continued to use MS Windows in its various versions until 
retirement.  After retirement I decided to start migrating clients to 
Ubuntu, especially Studio, since we have 2 or 3 desktops and 2 laptops 
and licensing costs were prohibitive once I left the university.  My 
other hobby is recording and performing live music which accounts for 
the interest in Studio.


Thanks for the work.

Mike Squires

--
Michael L. Squires, Ph.D., M.P.A.
michael.leslie.squi...@gmail.com
Member, Bloomington Friends Meeting (Quaker)
Member, Board of Directors, Arts Alliance
Known in the SCA as Alan Culross, KSCA, OP, CB, etc.
"Michael Leslie Squires" on Facebook
Web: www.siralan.org
UN*X at home since 1986 - ..!ncoast!sir-alan!mikes
812-369-5232 (cell) 812-333-6564 (home)


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Steve Langasek]

On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote:

> SRUs in packages used by flavors (including flavor-specific packages) are
> also common.

Speaking as a member of the SRU Team as well, I don't actually see evidence
of this.  There has been a run of SRUs right at the time of the mantic
release, related to release upgrades; and there was also a recent Lubuntu
SRU to lunar to fix *notifications* for release upgrades; but I can't think
of any other examples in the past few years.  This might be because it
happened that all of them were processed by other members of the SRU Team,
but that's statistically unlikely.  From my perspective, SRUs of core
packages in main are much more common.  Can you point to something I've
missed showing that flavor package SRUs are happening?

(I think this is very relevant to the question of LTS qualification, because
demonstrating a track record of active maintenance of the stable release of
a flavor goes a long way to establishing that the flavor team is delivering
something that meets users' needs for an LTS.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Sebastien Bacher]

Hey Erich,

I'm a relatively new member of the TB and not familiar with how flavors 
were granted LTS status in the past but let me share my perspective on 
what you wrote.


Le 24/11/2023 à 07:02, Erich Eickmeyer a écrit :


That said, this seems way too detailed for a repeated LTS. I will 
certainly follow this for Edubuntu since it's returning after 10 
years, but for Ubuntu Studio, and any other flavor with a prior LTS in 
the past two years, this should be a much lower bar.


Checking 
https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html 
what I see in this example is 7 bullet points and less than 20 lines of 
text (wrapped at 80chars), that doesn't seem a long or unachievable task 
to me. Could you be a specifics on what exactly is making the bar too 
high in your opinion?
To me it feels like it would have taken you less time to write those 
details than those emails...


That said, I'm not standing-down from this challenge, but revising it: 
I challenge the Technical Board to revisit and more clearly define 
exactly what "Flavor's support plan presented to Tech Board and 
approved; support planshould indicate period of time if beyond 18 
months (3yrs or 5yr), keycontacts, and setting expectations as to 
level of support." means with specifics, as the wording is too vague. 
Furthermore, the policy wording is clearly outdated ("18 months"), has 
been around too long without revision (2011) and the policy itself 
should probably be reworked in collaboration with the Flavor Leads as 
is the spirit of Ubuntu.


The page could be probably be a bit more specific on what is asked 
indeed. I think it's a fair ask for the TB to review the current wording 
and policy and see if we believe changes are needed. We do review 
mailing list activity and open questions during our IRC meetings so we 
should be able to pick it up next time


Cheers,
Sébastien Bacher
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Erich Eickmeyer]

Hi Lukasz,

I'm going to use Xubuntu's one-paragraph example for this as it seems 
reasonable and was approved by Steve, which sets a precedent.


Our support plan is limited to the Ubuntu Studio package set which is 
generally updates and bugfixes to the multimedia packages we include, as 
well as our own developed utilities (Ubuntu Studio Installer, Ubuntu 
Studio Audio Configuration, etc.). We also assist Kubuntu with bugfixes 
from time to time for the desktop environment and KDE application 
packages as needed. Most packages come from Debian. We also backport 
many packages to the backports repository for inclusion there.


I hope this is closer to what you're looking for and we can finally 
settle this.


Erich

On 11/23/23 09:53, Lukasz Zemczak wrote:

Hello Erich!

I will be handling your LTS re-qualification from the TB side for Ubuntu Studio.

Thank you for providing information about your team and contacts, as
well as regarding the length of the LTS support. I think we almost
have everything to make a decision here. Per the requirements listed
here [1], the only thing missing from the 'support plan' POV would be
setting the expectations regarding the level of support Ubuntu Studio
would provide for the 3 years. Could we have like a wiki page or a
page on ubuntustudio outlining this? And mentioning the support
contacts and where to file bugs.

Thanks!

Cheers,

On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer  wrote:

Good morning Technical Board,

On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for 
24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am the primary 
contact with rosco2 as backup.

Thanks,
Erich
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
--
technical-board mailing list
technical-bo...@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board

On behalf of the Technical Board,


--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Erich Eickmeyer]

Hi Seb,

On 11/24/23 06:40, Sebastien Bacher wrote:


Hey Erich,

I'm a relatively new member of the TB and not familiar with how 
flavors were granted LTS status in the past but let me share my 
perspective on what you wrote.


Le 24/11/2023 à 07:02, Erich Eickmeyer a écrit :


That said, this seems way too detailed for a repeated LTS. I will 
certainly follow this for Edubuntu since it's returning after 10 
years, but for Ubuntu Studio, and any other flavor with a prior LTS 
in the past two years, this should be a much lower bar.


Checking 
https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html 
what I see in this example is 7 bullet points and less than 20 lines 
of text (wrapped at 80chars), that doesn't seem a long or unachievable 
task to me. Could you be a specifics on what exactly is making the bar 
too high in your opinion?
To me it feels like it would have taken you less time to write those 
details than those emails...


I wasn't made aware of that email until Steve's reply, so I had no 
example to work from. Furthermore, this wasn't just about me as this 
affects all flavors. I've spoken to others who have been blindsided by 
this requirement that have been release managers for their respective 
flavors for as long as I have.


That said, I'm not standing-down from this challenge, but revising 
it: I challenge the Technical Board to revisit and more clearly 
define exactly what "Flavor's support plan presented to Tech Board 
and approved; support planshould indicate period of time if beyond 18 
months (3yrs or 5yr), keycontacts, and setting expectations as to 
level of support." means with specifics, as the wording is too vague. 
Furthermore, the policy wording is clearly outdated ("18 months"), 
has been around too long without revision (2011) and the policy 
itself should probably be reworked in collaboration with the Flavor 
Leads as is the spirit of Ubuntu.


The page could be probably be a bit more specific on what is asked 
indeed. I think it's a fair ask for the TB to review the current 
wording and policy and see if we believe changes are needed. We do 
review mailing list activity and open questions during our IRC 
meetings so we should be able to pick it up next time


This is essentially what I was looking for, but since I get ignored so 
often on these matters, I felt it needed further attention. And, indeed, 
it does affect volunteerism. While I do have a technical mind, I'm 
trained in the ways of supporting volunteers and I bleed community, so I 
will do whatever it takes to protect volunteers, not simply including 
myself.


With that, I thank you for the consideration on this matter.

--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Aaron Rainbolt]

On 11/23/23 23:02, Steve Langasek wrote:

On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote:

Hi Lukasz,
I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and
22.04 LTS this was never requested, and so as far as I know we would have to
start from scratch. Since I'm basically on the technical side for two
flavors now, I have to wear both those hats and come up with that policy for
both. Unfortunately, this wording for "support plan" is too vague and needs
to be more specific.

   Guidelines for Tech Board to designate flavor image as LTS

   * Flavor's support plan presented to Tech Board and approved; support plan
 should indicate period of time if beyond 18months (3yrs or 5yr), key
 contacts, and setting expectations as to level of support.

https://wiki.ubuntu.com/RecognizedFlavors?action=recall=5

This has been documented since 2011 as the standard to which flavors are
expected to be held.  If previously the Technical Board has been lax in
requiring this, that is not binding on the TB now.

The flavor communities for official Ubuntu flavors ARE expected to support
the flavors to their users for the lifetime of the release.  Rhetorically
speaking, you should not be expecting to throw a release over the wall as a
one-time artifact image and wash your hands of it.


I see what you're trying to get at here and I fully agree with what 
you're saying, but I would like to point out that it has *never* been 
the norm for any flavor that I know of to "throw a release over the wall 
as a one-time artifact image and wash your hands of it". The IRC (and if 
available, Matrix) rooms are frequently visited by flavor users and the 
developers provide support directly to those users, at least in the case 
of Ubuntu Studio, Lubuntu, Xubuntu, and Kubuntu. (I'm sure most if not 
all other flavors have something similar but those I know for a fact.) 
SRUs in packages used by flavors (including flavor-specific packages) 
are also common.


This isn't to say anything you've said is wrong here, but simply it 
might soften the blow to acknowledge that Ubuntu Studio *has* been 
supporting their releases up until now and will continue to do so. 
Otherwise this comes across as if you're saying "you can't *keep* giving 
shoddy support", when we try to give good support. (I know that's not 
what you're saying, for the record.)



This is all the more important for an LTS release, because LTS *means*
"long-term support".  If a flavor wants to have an LTS designation (and
participate in point releases), they need to be accountable to the larger
Ubuntu community that this actually means something.

If we get this wrong for a non-LTS release, the consequences are fairly
minor.  The user who installs a non-LTS image of a flavor is only promised
support for 9 months; they are not promised that the flavor will be
supported at all as part of the next 6-monthly release.  The flavor could
sunset in that time and there be no metapackage they can even upgrade to.
And if the flavor community fails to support their flavor for the full
9-month period, the impact on the rest of Ubuntu developers to pick up the
slack is also likely to be minor.

But if a flavor is an LTS release, meaning there is a public promise that it
is supported for 3 or 5 years, then it needs to be clear to users what
"supported" means for that flavor, and we need to be confident that the
flavor community is actually in a position to deliver on that promise.

With 10 distinct recognized community flavors, this is not something to be
left to chance.
^ that. I'm assuming the need for this requirement to be strictly 
enforced is due to the sudden addition of two new flavors recently with 
a third on the horizon, and the goal is to make sure the new flavors 
give good support and the old flavors can proudly show the support they 
already give.

This just creates extra work for *volunteers* that are otherwise working
jobs (e.g.  myself as a stay-at-home father/tutor for my son, my wife as a
full-time early childhood administrator).

All currently recognized flavors are welcome to participate in the 24.04
release as non-LTS flavors, with no additional requirement to document a
support plan.

If a flavor finds it overly onerous to *document* their LTS plans, I think
it's self-evident that they also should not be *calling* themselves an LTS
because they don't actually have capacity to commit to support.


I don't believe that's what Erich was complaining about. I think he's 
complaining about the vagueness of the request (which you've helped 
clarify some here, thank you!), and the difficulty of figuring out what 
exactly you're asking for. (And it's possible he doesn't understand what 
you're asking for, as he seems to think that this task is going to be 
difficult, and you seem to think it's going to be easy, so something 
must not be getting communicated.) If it's just "hey, write down what 
your definition of "support" is and put it 

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Erich Eickmeyer]

On 11/23/23 21:02, Steve Langasek wrote:

On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote:

Hi Lukasz,
I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and
22.04 LTS this was never requested, and so as far as I know we would have to
start from scratch. Since I'm basically on the technical side for two
flavors now, I have to wear both those hats and come up with that policy for
both. Unfortunately, this wording for "support plan" is too vague and needs
to be more specific.

   Guidelines for Tech Board to designate flavor image as LTS

   * Flavor's support plan presented to Tech Board and approved; support plan
 should indicate period of time if beyond 18months (3yrs or 5yr), key
 contacts, and setting expectations as to level of support.

https://wiki.ubuntu.com/RecognizedFlavors?action=recall=5

This has been documented since 2011 as the standard to which flavors are
expected to be held.  If previously the Technical Board has been lax in
requiring this, that is not binding on the TB now.


Terribly sorry, but in my six years of being release manager for Ubuntu 
Studio (as of 24.04) we have not once been asked this question, so we 
should not have to suffer this now. As such, we have nothing to work 
from, especially from my tenure. That's certainly not our fault either 
and we shouldn't be punished for the failures of TBs prior, so this 
should not be binding on us.


> setting expectations as to level of support

This is too vague and needs to be better defined, and that's really what 
I'm asking here. This is the responsibility of the TB to define, not the 
flavors, since this is not the flavors' policy but the TB's policy.


> This has been documented since 2011 as the standard to which flavors 
are expected to be held.


If I took that approach in my leadership of Ubuntu Studio, it probably 
wouldn't exist today, especially in its current form. I would never have 
had the team explore other desktop environments, and we certainly 
wouldn't be working on the advances in implementing PipeWire. A 12 
(almost 13!) year-old policy should be revisited and should probably be 
more collaborative as opposed to unilaterally imposed. I'm certain the 
flavors didn't agree to this, and now that the Flavor Sync meetings 
exist, I think it would be better worked on in collaboration with the 
flavor leads. I've been quoted as saying, "Just because something has 
worked in the past doesn't mean it will continue to work forever."



The flavor communities for official Ubuntu flavors ARE expected to support
the flavors to their users for the lifetime of the release.  Rhetorically
speaking, you should not be expecting to throw a release over the wall as a
one-time artifact image and wash your hands of it.

That's not what I'm suggesting.

This is all the more important for an LTS release, because LTS *means*
"long-term support".  If a flavor wants to have an LTS designation (and
participate in point releases), they need to be accountable to the larger
Ubuntu community that this actually means something.


Ubuntu Studio has successfully released two LTS images under my watch 
without this requirement, so I don't understand why this needs to be 
revisited under a microscope now, following paragraphs nonwithstanding.



If we get this wrong for a non-LTS release, the consequences are fairly
minor.  The user who installs a non-LTS image of a flavor is only promised
support for 9 months; they are not promised that the flavor will be
supported at all as part of the next 6-monthly release.  The flavor could
sunset in that time and there be no metapackage they can even upgrade to.
And if the flavor community fails to support their flavor for the full
9-month period, the impact on the rest of Ubuntu developers to pick up the
slack is also likely to be minor.

But if a flavor is an LTS release, meaning there is a public promise that it
is supported for 3 or 5 years, then it needs to be clear to users what
"supported" means for that flavor, and we need to be confident that the
flavor community is actually in a position to deliver on that promise.

With 10 distinct recognized community flavors, this is not something to be
left to chance.
This seems more like a lack of trust to me, which flies against the 
spirit of Ubuntu, but that's just how I feel about it. From Ubuntu 
Studio's perspective, I'm so far the longest tenured flavor lead, and 
I'm not going anywhere as far as I can see. However, I know what burned 
out the other leads, and it was stuff like this. Hence, I'm calling on 
the Community Council*before* it becomes a problem, if it isn't already.

This just creates extra work for *volunteers* that are otherwise working
jobs (e.g.  myself as a stay-at-home father/tutor for my son, my wife as a
full-time early childhood administrator).

All currently recognized flavors are welcome to participate in the 24.04
release as non-LTS flavors, with no additional requirement to document a

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Steve Langasek]

On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote:
> Hi Lukasz,

> I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and
> 22.04 LTS this was never requested, and so as far as I know we would have to
> start from scratch. Since I'm basically on the technical side for two
> flavors now, I have to wear both those hats and come up with that policy for
> both. Unfortunately, this wording for "support plan" is too vague and needs
> to be more specific.

  Guidelines for Tech Board to designate flavor image as LTS

  * Flavor's support plan presented to Tech Board and approved; support plan
should indicate period of time if beyond 18months (3yrs or 5yr), key
contacts, and setting expectations as to level of support.

https://wiki.ubuntu.com/RecognizedFlavors?action=recall=5

This has been documented since 2011 as the standard to which flavors are
expected to be held.  If previously the Technical Board has been lax in
requiring this, that is not binding on the TB now.

The flavor communities for official Ubuntu flavors ARE expected to support
the flavors to their users for the lifetime of the release.  Rhetorically
speaking, you should not be expecting to throw a release over the wall as a
one-time artifact image and wash your hands of it.

This is all the more important for an LTS release, because LTS *means*
"long-term support".  If a flavor wants to have an LTS designation (and
participate in point releases), they need to be accountable to the larger
Ubuntu community that this actually means something.

If we get this wrong for a non-LTS release, the consequences are fairly
minor.  The user who installs a non-LTS image of a flavor is only promised
support for 9 months; they are not promised that the flavor will be
supported at all as part of the next 6-monthly release.  The flavor could
sunset in that time and there be no metapackage they can even upgrade to. 
And if the flavor community fails to support their flavor for the full
9-month period, the impact on the rest of Ubuntu developers to pick up the
slack is also likely to be minor.

But if a flavor is an LTS release, meaning there is a public promise that it
is supported for 3 or 5 years, then it needs to be clear to users what
"supported" means for that flavor, and we need to be confident that the
flavor community is actually in a position to deliver on that promise.

With 10 distinct recognized community flavors, this is not something to be
left to chance.

> This just creates extra work for *volunteers* that are otherwise working
> jobs (e.g.  myself as a stay-at-home father/tutor for my son, my wife as a
> full-time early childhood administrator).

All currently recognized flavors are welcome to participate in the 24.04
release as non-LTS flavors, with no additional requirement to document a
support plan.

If a flavor finds it overly onerous to *document* their LTS plans, I think
it's self-evident that they also should not be *calling* themselves an LTS
because they don't actually have capacity to commit to support.

> I challenge that this technical requirement crosses the line from
> technical requirement into community encroachment, which is why the
> Community Council is CC'd on this email.

I have confidence that the Community Council will recognize that the LTS
label, and the decision about committment of Release Team resources to point
releases on behalf of flavors, is within the purview of the Release Team and
the Technical Board to decide.

> Also, do know that I see no ill-intent here as I do see good reasons for it,
> but I feel as though requiring extra work for volunteers when there is no
> precedent for something like this in the past seems like a bit of an
> overreach and an extremely vague request (support can mean anything from
> simple patches to 24/7 technical support which is a no-go). If there was
> precedent, then there would already be documentation for each flavor, but I
> believe a simple agreement for flavors to a blanket unified "support plan"
> would be more appropriate rather than requiring each flavor to come up with
> their own which would take more time and possibly definition than flavors
> should have to come up with.

We're not looking for an original essay here, we're looking for
documentation of a credible and sensible plan.  If you find it useful to
coordinate with other flavors to synchronize your support committments,
that's fine.  And there is certainly prior art.

https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or 

Re: [ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Lukasz Zemczak]

Hello Erich!

I will be handling your LTS re-qualification from the TB side for Ubuntu Studio.

Thank you for providing information about your team and contacts, as
well as regarding the length of the LTS support. I think we almost
have everything to make a decision here. Per the requirements listed
here [1], the only thing missing from the 'support plan' POV would be
setting the expectations regarding the level of support Ubuntu Studio
would provide for the 3 years. Could we have like a wiki page or a
page on ubuntustudio outlining this? And mentioning the support
contacts and where to file bugs.

Thanks!

Cheers,

On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer  wrote:
>
> Good morning Technical Board,
>
> On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for 
> 24.04. Our team is https://launchpad.net/~ubuntustudio-dev and I am the 
> primary contact with rosco2 as backup.
>
> Thanks,
> Erich
> --
> Erich Eickmeyer
> Project Leader - Ubuntu Studio
> Technical Lead - Edubuntu
> --
> technical-board mailing list
> technical-bo...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board

On behalf of the Technical Board,

-- 
Łukasz 'sil2100' Zemczak
 Foundations Team
 Tools Squad Engineering Manager
 lukasz.zemc...@canonical.com
 www.canonical.com

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Erich Eickmeyer]

Hi Lukasz,

I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and 
22.04 LTS this was never requested, and so as far as I know we would 
have to start from scratch. Since I'm basically on the technical side 
for two flavors now, I have to wear both those hats and come up with 
that policy for both. Unfortunately, this wording for "support plan" is 
too vague and needs to be more specific.


At first, I was simply going to request more specifics, but the more I 
thought about it (and took several hours to do so), the more I realized 
this is extra burden for volunteers that shouldn't be, and for that 
reason I'm challenging this request.


In the past, as far as I can find, there has been no precedent for 
anything like this, and I have yet to see any member of the Technical 
Board justify this move as it has never been requested before and I have 
no evidence of a prior request for this. It should not be up to the 
flavors to define a "support plan" further than what has been set as 
precedent in the past. This just creates extra work for *volunteers* 
that are otherwise working jobs (e.g. myself as a stay-at-home 
father/tutor for my son, my wife as a full-time early childhood 
administrator). I challenge that this technical requirement crosses the 
line from technical requirement into community encroachment, which is 
why the Community Council is CC'd on this email.


Please know, this is not an escalation for a Code of Conduct violation 
as, contrary to popular belief, the Code of Conduct is not the only 
responsibility of the Community Council, but also overall community 
health and oversight. I believe this situation amounts to a community 
health issue. I say this as a Community Council emeritus.


I feel like this move is one where the Technical Board, of which I note 
every member is a Canonical employee, is looking at it through the lens 
of people who are paid to work on Ubuntu and not as volunteer leaders, 
something in which I have expert experience and hold a college degree 
and am happy to advise on. I have even offered my knowledge on this 
matter several times in the past and been ignored, but that's another 
matter entirely. However, because I've been ignored in the past on other 
matters, that's why I feel Community Council involvement is appropriate.


Also, do know that I see no ill-intent here as I do see good reasons for 
it, but I feel as though requiring extra work for volunteers when there 
is no precedent for something like this in the past seems like a bit of 
an overreach and an extremely vague request (support can mean anything 
from simple patches to 24/7 technical support which is a no-go). If 
there was precedent, then there would already be documentation for each 
flavor, but I believe a simple agreement for flavors to a blanket 
unified "support plan" would be more appropriate rather than requiring 
each flavor to come up with their own which would take more time and 
possibly definition than flavors should have to come up with.


Thank you for understanding, and I hope we can come up with a solution.

Sincerely,
Erich Eickmeyer

On 11/23/23 09:53, Lukasz Zemczak wrote:

Hello Erich!

I will be handling your LTS re-qualification from the TB side for Ubuntu Studio.

Thank you for providing information about your team and contacts, as
well as regarding the length of the LTS support. I think we almost
have everything to make a decision here. Per the requirements listed
here [1], the only thing missing from the 'support plan' POV would be
setting the expectations regarding the level of support Ubuntu Studio
would provide for the 3 years. Could we have like a wiki page or a
page on ubuntustudio outlining this? And mentioning the support
contacts and where to file bugs.

Thanks!

Cheers,

On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer  wrote:

Good morning Technical Board,

On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for 
24.04. Our team ishttps://launchpad.net/~ubuntustudio-dev  and I am the primary 
contact with rosco2 as backup.

Thanks,
Erich
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
--
technical-board mailing list
technical-bo...@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board

On behalf of the Technical Board,


--
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio LTS Re-Qualification

[Erich Eickmeyer]

Good morning Technical Board,

On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 
years for 24.04. Our team is  
and I am the primary contact with rosco2 as backup.


Thanks,
Erich
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio 23.10 Released

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the release of Ubuntu 
Studio 23.10, code-named “Mantic Minotaur”. This marks Ubuntu Studio’s 
33rd release. This release is a regular release and as such, it is 
supported for 9 months (until July 2024).


Since it’s just out, you may experience some issues, so you might want 
to wait a bit before upgrading. Please see therelease notes 
for a 
more-complete list of changes and known issues.


You can download Ubuntu Studio 23.10 from ourdownload page 
.



   Upgrading

Instructions for upgrading are included in therelease notes 
.



   New This Release


 Ubiquity System Installer Returns

In the days where we used Xfce as our default desktop environment, our 
default system installer was one developed and used by most Ubuntu 
flavors called Ubiquity. However, when we switched to KDE’s Plasma 
Desktop as our default desktop environment, we wished to use the Qt 
version, but we found out it was hardcoded for Kubuntu’s branding. With 
that, we partnered with Lubuntu, which also uses a Qt-based desktop 
called LXQt, to use the Qt-based Calamares installer.


Unfortunately, we found that, despite the customization and user 
experience it provided, it lacked a few features Ubiquity provides:


 * A language chooser at boot, which changes the language for the live
   session and installer alike
 * An OEM mode for computer manufacturers
 * The ability to install without running the live session

This release, we worked hard to make sure the first time you boot Ubuntu 
Studio 23.10 is a pleasing one and that everything is themed correctly, 
including pushing changes to Ubiquity itself so that the GTK version of 
Ubiquity would work with our default theming as well as fixing a bug 
that affected other Ubuntu flavors with dark themes.


For the next release, we hope to switch to the same installerUbuntu 
Desktop (GNOME) andUbuntu Budgie 
are using, which is a graphical frontend for 
the text-based Subiquity installer used inUbuntu Server 
. We believe that unifying under a single 
codebase makes maintenance easier and creates a higher-quality 
experience for everyone.



 PipeWire Continues to Get Stronger

Pipewire logo.svg

PipeWire has gained numerous improvements, including fixes for prosumer 
and professional audio. The JACK compatibility now performs in 
real-time, and some FireWire features have now been implemented.


We also include a new utility, called the*Ubuntu Studio Audio 
Configuration*utility, found in the Ubuntu Studio Information menu. This 
can be used to configure the default/PipeWire Quantum/value, Enable or 
Disable the PipeWire-JACK compatibility layer (handy for using JACK by 
itself), or switch to the classic PulseAudio-JACK setup that was the 
default prior to 23.04.Click here for more information about that 
utility 



 In the Repositories: QPrompt

*QPrompt*is a Qt-based teleprompter application now available in the 
repositories. While a snap version does exist and is installable from 
Discover, the version in the repositories is more up-to-date. Since 
Discover does not see the version in the repositories, it needs to be 
installed from the command line by issuing the following command:


sudo apt install qprompt


   Backports PPA is Now Deprecated

As stated in the release announcement of Ubuntu Studio 23.04, that 
release was the last release in which packages would be backported to 
the Ubuntu Studio Backports PPA. As of this release, we will no longer 
be backporting packages from the next release to regular releases such 
as this release. As such, the backports PPA items have been removed from 
Ubuntu Studio Installer for this release. This simply means a longer 
wait for new software and that interval will be six months for regular 
releases.


In the future, we plan to utilize the official Ubuntu Backports 
Repository and backporting newer package versions there, except for 
Ardour Backports when new whole versions are released as they would 
still be backported to our Ardour Backports PPA.*The Ubuntu Backports 
Repository only supports LTS releases*. Therefore, we plan to backport 
only to 22.04 LTS and, in the future, only 24.04 LTS using the backports 
repository once it releases.


Furthermore, as of today, backports to the Backports PPA for 23.04 have 
stopped, and software for 23.04 in that PPA will be deleted when 23.04 
goes End-Of-Life (EOL) in January 2024. If you would like newer software 
and are running 23.04, we encourage you to upgrade when you receive the 
notification.



 Plasma Desktop Backports

Since we share the Desktop Environment with Kubuntu, simply adding the 
Kubuntu Backports 

Re: [ubuntu-studio-devel] [ubuntu-studio-users] Proposal to sunset #ubuntustudio-offtopic

[Erich Eickmeyer]

BabsKy, you bring up great points and are re-enforcing my case.

Honestly, I have yet to see one person arguing against combining. We 
rarely, if ever, get support questions in the devel channel, so I'm not 
worried there. Usually when that happens it's a matter of, "I need to 
reach the devs about such-and-such," in which case it's completely fine, 
and more than likely gets triaged into a bug report where it's more 
easily tracked (could still be handled from #ubuntustudio since we hang 
out there as well).


As for why I'd want to redirect people with support/help questions to 
#ubuntustudio, the biggest reason is because of eyeballs. As with any 
open source project, the more the better, and in this case, the more 
people available to troubleshoot a problem the better. There are twice 
as many people in #ubuntustudio as #ubuntustudio-offtopic, so you can 
clearly see the advantage there.


As of now, I have removed the page links on ubuntustudio.org for the 
community page which only served to be a link to #ubuntustudio-offtopic 
to remove the ambiguity. I believe that, in the future, removing Ubuntu 
Studio Café from the Ubuntu Studio Information menu would be next for 
all supported releases and 23.10, followed by the forwarding of the 
channel to #ubuntustudio.


I have yet to see any compelling reason to not move forward. Removing 
the link is the easiest to undo if there's any compelling reason to do 
otherwise, so if anybody has any reason not to move forward, please let 
me know. :)


-Erich

On 10/7/23 08:54, BabsKy wrote:

We have signage for our IT sessions that people don’t see. We used to hold our 
sessions on a mezzanine that had a sign on a stand smack in the middle at the 
bottom of the stairs, people would squeeze past the sign to come up to the 
mezzanine and then be surprised when we told them we were in a session. We 
currently use a separate room and always put signage on the door, at eye level, 
but people still don’t see it.
As for being aggressive, there are several possible reasons, in my experience;
1. English isn’t everyone’s first language and some don’t have a good 
understanding of it.
2. Mental health issues or physical brain damage/physical limitations, certain 
medication, can cause aggressive behaviour.
3. Lack of understanding, rooted in either 1 or 2 above, can cause frustration 
which can appear to be or lead to aggression.
4. Some people need handholding. Vague direction isn’t enough, you have to give 
unambiguous, “foolproof” direction. In this case that would be a link. I have 
one of these customers, he’s a nice man but has NO common sense whatsoever. He 
needs clear, step by step instructions. Although he often gets frustrated with 
himself he doesn’t get aggressive, but there are some that do. Maybe they’ve 
been spoilt and expect everything to be handed to them on a plate?

In an ideal world you wouldn’t have to change anything to satisfy the minority, 
if they would be satisfied? but we don’t live in an ideal world so combining 
may be the way to go?




On 7 Oct 2023, at 05:02, Erich Eickmeyer  wrote:

Yep, it was signposted very clearly, but apparently people didn't understand the difference between 
"community" and "support" and didn't see the bold letters in the community page saying "do not 
use this chat for technical support." Furthermore, this one person claimed the term "technical support" 
is subjective, which I'm still confused about.

Either way, I think removing the guesswork is the best way forward. One chat 
room, less ambiguity, keeping the development collaboration separate still.

-Erich

On 10/6/23 15:38, BabsKy wrote:

I didn’t even know there was a #ubuntustudio-offtopic!
Unfortunately there will always be people like that and I’m sure you’re not 
letting them get to you, it’s sad that this is the world we live in. I’m one of 
a team of volunteer IT trainers and we also have to deal with abuse 
occasionally, usually verbal but it has escalated once or twice.
I can understand users not being familiar with the correct avenues for help and 
can understand how frustrating it can be in that situation, so making it as 
easy as possible and the correct routes as clearly signposted as possible is 
all you can do.


On 5 Oct 2023, at 20:15, Erich Eickmeyer  wrote:

Hi all,

There was an incident the other day in which someone requested support in the 
#ubuntustudio-offtopic IRC channel. I answered their question but requested 
they move to #ubuntustudio since this gets more view (and is properly logged), 
but instead of doing the right thing and doing what was requested, this person 
decided to berate me, then threaten me which then got them kicked out and 
banned for violating the Ubuntu Code of Conduct, after which they continued to 
threaten me via private message, which then got them reported to staff and, 
likely, K-lined.

This, however, did get me thinking: this isn't the first time people have been 
confused about the purpose of 

Re: [ubuntu-studio-devel] [ubuntu-studio-users] Proposal to sunset #ubuntustudio-offtopic

[Erich Eickmeyer]

Yep, it was signposted very clearly, but apparently people didn't 
understand the difference between "community" and "support" and didn't 
see the bold letters in the community page saying "do not use this chat 
for technical support." Furthermore, this one person claimed the term 
"technical support" is subjective, which I'm still confused about.


Either way, I think removing the guesswork is the best way forward. One 
chat room, less ambiguity, keeping the development collaboration 
separate still.


-Erich

On 10/6/23 15:38, BabsKy wrote:

I didn’t even know there was a #ubuntustudio-offtopic!
Unfortunately there will always be people like that and I’m sure you’re not 
letting them get to you, it’s sad that this is the world we live in. I’m one of 
a team of volunteer IT trainers and we also have to deal with abuse 
occasionally, usually verbal but it has escalated once or twice.
I can understand users not being familiar with the correct avenues for help and 
can understand how frustrating it can be in that situation, so making it as 
easy as possible and the correct routes as clearly signposted as possible is 
all you can do.


On 5 Oct 2023, at 20:15, Erich Eickmeyer  wrote:

Hi all,

There was an incident the other day in which someone requested support in the 
#ubuntustudio-offtopic IRC channel. I answered their question but requested 
they move to #ubuntustudio since this gets more view (and is properly logged), 
but instead of doing the right thing and doing what was requested, this person 
decided to berate me, then threaten me which then got them kicked out and 
banned for violating the Ubuntu Code of Conduct, after which they continued to 
threaten me via private message, which then got them reported to staff and, 
likely, K-lined.

This, however, did get me thinking: this isn't the first time people have been 
confused about the purpose of #ubuntustudio-offtopic, though this is the first 
time someone has been so verbally violent about it. Additionally, 
#ubuntustudio-offtopic doesn't see much use other than Krytarik correcting my 
grammar. :)

With that, I propose sunsetting #ubuntustudio-offtopic and combining it with 
#ubuntustudio to make #ubuntustudio a support *and* discussion channel, but 
anything other than the topic of Ubuntu Studio would be requested to move to 
#ubuntu-offtopic for general chit-chat, as #ubuntu-offtopic is a much more 
active room. The general idea is to lower the confusion and to allow people to 
feel more welcome to discuss Ubuntu Studio in our main chat.

Let me know your thoughts.

Thanks in advance,
Erich
--
Erich Eickmeyer
Project Lead - Ubuntu Studio
Technical Lead - Edubuntu


--
ubuntu-studio-users mailing list
ubuntu-studio-us...@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users




--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Proposal to sunset #ubuntustudio-offtopic

[Mike Squires]

Sounds good to me.

Mike Squires

On 10/5/23 15:15, Erich Eickmeyer wrote:

Hi all,

There was an incident the other day in which someone requested support 
in the #ubuntustudio-offtopic IRC channel. I answered their question 
but requested they move to #ubuntustudio since this gets more view 
(and is properly logged), but instead of doing the right thing and 
doing what was requested, this person decided to berate me, then 
threaten me which then got them kicked out and banned for violating 
the Ubuntu Code of Conduct, after which they continued to threaten me 
via private message, which then got them reported to staff and, 
likely, K-lined.


This, however, did get me thinking: this isn't the first time people 
have been confused about the purpose of #ubuntustudio-offtopic, though 
this is the first time someone has been so verbally violent about it. 
Additionally, #ubuntustudio-offtopic doesn't see much use other than 
Krytarik correcting my grammar. :)


With that, I propose sunsetting #ubuntustudio-offtopic and combining 
it with #ubuntustudio to make #ubuntustudio a support *and* discussion 
channel, but anything other than the topic of Ubuntu Studio would be 
requested to move to #ubuntu-offtopic for general chit-chat, as 
#ubuntu-offtopic is a much more active room. The general idea is to 
lower the confusion and to allow people to feel more welcome to 
discuss Ubuntu Studio in our main chat.


Let me know your thoughts.

Thanks in advance,
Erich
--
Erich Eickmeyer
Project Lead - Ubuntu Studio
Technical Lead - Edubuntu




--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Proposal to sunset #ubuntustudio-offtopic

[Erich Eickmeyer]

Hi all,

There was an incident the other day in which someone requested support 
in the #ubuntustudio-offtopic IRC channel. I answered their question but 
requested they move to #ubuntustudio since this gets more view (and is 
properly logged), but instead of doing the right thing and doing what 
was requested, this person decided to berate me, then threaten me which 
then got them kicked out and banned for violating the Ubuntu Code of 
Conduct, after which they continued to threaten me via private message, 
which then got them reported to staff and, likely, K-lined.


This, however, did get me thinking: this isn't the first time people 
have been confused about the purpose of #ubuntustudio-offtopic, though 
this is the first time someone has been so verbally violent about it. 
Additionally, #ubuntustudio-offtopic doesn't see much use other than 
Krytarik correcting my grammar. :)


With that, I propose sunsetting #ubuntustudio-offtopic and combining it 
with #ubuntustudio to make #ubuntustudio a support *and* discussion 
channel, but anything other than the topic of Ubuntu Studio would be 
requested to move to #ubuntu-offtopic for general chit-chat, as 
#ubuntu-offtopic is a much more active room. The general idea is to 
lower the confusion and to allow people to feel more welcome to discuss 
Ubuntu Studio in our main chat.


Let me know your thoughts.

Thanks in advance,
Erich
--
Erich Eickmeyer
Project Lead - Ubuntu Studio
Technical Lead - Edubuntu


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Long time Ubuntu user stepping up to dev.

[Erich Eickmeyer]

Hi E,

I'm CCing this on the ubuntu-studio-devel@lists.ubuntu.com list because 
that's where it would've been more appropriate as Ubuntu Studio is 
supposed to be a team project, and joining that list and sending there 
would've been more appropriate and would not have gone unnoticed. I'm 
not the only person who does anything with this, I just happen to be the 
leader. You can join that list at 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel.


In addition, we highly encourage participation on irc.libera.chat in the 
#ubuntustudio-devel chatroom, as well as #ubuntustudio and 
#ubuntustudio-offtopic if you feel so inclined.


As far as updating from 18.04 (all Ubuntu releases are yy.mm and there 
are two per year, so specifying yy is imprecise) to 20.04, that's not a 
good idea as 18.04 of Ubuntu Studio is *LONG* end-of-life, and 20.04 of 
Ubuntu Studio went end-of-life in April since Ubuntu Studio only 
supports for 3 years on its LTS releases like all Ubuntu flavors that 
are not directly supported by Canonical.


Therefore, what you want to do is update to 22.04, but since 18.04 went 
EOL back in January 2019 for Ubuntu Studio (it wasn't an LTS for Ubuntu 
Studio for many reasons), and 18.04 for Ubuntu in general left standard 
support in April of this year, you'll have to do what's called an 
End-Of-Life upgrade. You'll be able to find instructions for that here: 
https://help.ubuntu.com/community/EOLUpgrades


However, if you would like to participate in development, I'd encourage 
testing and running the latest development release which is 23.10 beta 
currently. We go into Final Freeze this Thursday in anticipation of 
23.10's release on October 12. So far, most everything has been 
ironed-out, and I'm just watching Ubuntu's kernel team get the kernel 
tested for some fixes that are affecting USB and JACK interaction, even 
under PipeWire.


So, at this point, it's all testing all the time. The more eyes, the 
better. Glad to hear that you find it reliable, and would love to 
welcome you to the team!


Erich
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

On 10/2/23 13:12, Johny Bravo wrote:

Hello Erich;

My name is E.  I use an alias on here because of security issues I am
having with local internet and its causing my ubuntu to not load right
on top of issues.

So now I can't update from 18 to 20.   I need some help. I did a bunch
of stuff last night and I want to contribute mabey with doing this bug
trouble shoot with you then I can write about it steppig me up in the
community.

Thanks for the help and consideration.  I would like to over come all
gov. and exterior private organization tracking andd viewing of my
online traffic and my own systems. I am an ubuntu studio user and have
several cloud spaces that  I am trying to get through the massive
learning curve but am on Ubuntu for day to day use of my systems,
Microsoft cause I like V.S Code and google because they are very good at
what they do.

I also have other parts of my cloud as well and its just daunting all
the info.  The choices have costed me because there are just to many
good things to work with as far as packaging.

I am also an environementalist that believes in inovative businesss
savving the earth with  the will for the greater good of all men in
heart including honesty and fair trade.  I enjoy massive public events
and have banner space I am building and interested in sugestions for
server and AI archetecture and will of course that is availabele in kind
to Ubuntu and Ubuntu Studio.

But any ways back to the bug issue its just something small - I might
have it figured before I talk to you but just thought I would introduce
my self - good job - great product for the time piece! Amazing and
seemingly very good and reliable.

Johny Bravo borealoxy...@gmail.com


--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio 23.10 Beta Released

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu 
Studio 23.10, codenamed “Mantic Minotaur”.


While this beta is reasonably free of any showstopper installer bugs, 
you may find some bugs within. This image is, however, mostly 
representative of what you will find when Ubuntu Studio 23.10 is 
released on October 12, 2023.



   Special Notes

The Ubuntu Studio 23.10 disk image (ISO) exceeds 4 GB and cannot be 
downloaded to some file systems such as FAT32, and may not be readable 
when burned to a DVD. For this reason, we recommend downloading to a 
compatible file system. When creating a boot medium, we 
recommendcreating a bootable USB stick 
with 
the ISO image, or burning to a Dual-Layer DVD.


Images can be obtained from this 
link:https://cdimage.ubuntu.com/ubuntustudio/releases/23.10/beta/


Full updated information, including*Upgrade Instructions,*are available 
in the*Release Notes 
*. 




   New Features This Release

 * *PipeWire*‘s JACK support is now drastically improved and includes a
   real-time bridge between the JACK and ALSA components of PipeWire,
   and continues to improve with every release. Version 0.3.79
 * *Ubuntu Studio Installer*now includes an*Ubuntu Studio Audio
   Configuration
   *utility
   for fine-tuning the PipeWire setup or changing the configuration
   altogether. Version 1.9
 * *QPrompt*is now, while not included in the Ubuntu Studio .iso image,
   available in the repositories. QPrompt is free teleprompter software
   for video recording and television studios. Version 1.1.6


   Major Package Upgrades

 * *Ardour*version 7.5.0
 * *Qtractor*version 0.9.35
 * *OBS Studio*version 29.1.3
 * *Audacity*version 3.3.3
 * *digiKam*version 8.1.0
 * *Kdenlive*version 23.08.1
 * *Krita*version 5.1.5

There are many other improvements, too numerous to list here. We 
encourage you to look around the freely-downloadable ISO image.



   Known Issues

 * Ubuntu Studio’s classic PulseAudio-JACK configuration cannot be used
   on Ubuntu Desktop (GNOME) due to a known issue with the
   ubuntu-desktop metapackage. (LP: #2033440
   )

Official Ubuntu Studio release notes can be found 
athttps://ubuntustudio.org/ubuntu-studio-23-10-release-notes/


Further known issues, mostly pertaining to the desktop environment, can 
be found at https://wiki.ubuntu.com/ManticMinotaur/ReleaseNotes/Kubuntu 
(when 
available)


Additionally, the main Ubuntu release notes contain more generic 
issues:https://discourse.ubuntu.com/t/mantic-minotaur-release-notes/35534



   How You Can Help

Please test using the test cases onhttps://iso.qa.ubuntu.com. All you 
need is aLaunchpad account to get started.


Additionally, we need financial contributions. Our project lead, Erich 
Eickmeyer, is working long hours on this project and trying to generate 
a part-time income. Seethis post 
as to 
the reasons why andgo here to see 
how you can contribute financially (options are also in the sidebar).



   Frequently Asked Questions

*Q:*Does Ubuntu Studio contain snaps?
*A:*Yes. Mozilla’s distribution agreement with Canonical changed, and 
Ubuntu was forced to no longer distribute Firefox in a native .deb 
package. We have found that, after numerous improvements, Firefox now 
performs just as well as the native .deb package did.


Additionally, Freeshow is an Electron-based application. Electron-based 
applications cannot be packaged in the Ubuntu repositories in that they 
cannot be packaged in a traditional Debian source package. While such 
apps do have a build system to create a .deb binary package, it 
circumvents the source package build system in Launchpad, which is 
required when packaging for Ubuntu. However, Electron apps also have a 
facility for creating snaps, which can be uploaded and included. 
Therefore, for Freeshow to be included in Ubuntu Studio, it had to be 
packaged as a snap.


*Q:*If I install this Beta release, will I have to reinstall when the 
final release comes out?
*A:*No. If you keep it updated, your installation will automatically 
become the final release. However, if Audacity returns to the Ubuntu 
repositories before final release, then you might end-up with a 
double-installation of Audacity. Removal instructions of one or the 
other will be made available in a future post.


*Q*: Will you make an ISO with {my favorite desktop environment}?
*A:*To do so would require creating an entirely new flavor of Ubuntu, 
which would require going through the Official Ubuntu Flavor application 

[ubuntu-studio-devel] Re: PipeWire/JACK Findings (Was: Ubuntu Studio on Gnome (23.04))

[Erich Eickmeyer]

On Wednesday, July 12, 2023 12:15:42 PM PDT Ross Gammon wrote:
> On 7/12/23 19:49, Ross Gammon wrote:
> > On 7/12/23 19:46, Ross Gammon wrote:
> >> qpwgraph is a QT GUI interface to wireplumber which is in Lunar.
> > 
> > Correction - qpwgraph depends on pipewire itself and not wireplumber.
> > That was a wrong assumption on my part.
> > 
> > Ross
> 
> Well I had a play with qpwgraph and pipwire, and the some of the Ubuntu
> Studio audio tools with 23.04 (Lunar) on Gnome - and you can do stuff!
> 
> But I see what everyone means about pro-studios. It is all a bit clunky.
> and latency is a problem without an easy way to get in and fiddle with
> the settings. At least - one that I know of.
> 
> Apparently you can use some pipewire command line tools. But the manpage
> is light on information. I suppose your Ubuntu Studio Audio Config tool
> will help here - now I understand better what you were saying about the
> PIPEWIRE_QUANTUM variable.
> 
> With qpwgraph, I could make all of the connections that I used to make
> with The patch section of Carla. But everytime I clicked on another
> window, and then clicked back to qpwgraph, its window was un-maximised.
> 
> Hydrogen works.
> 
> I recorded an extra track into a previous Ardour project. Latency!
> 
> I recorded my electric guitar into an extra track via Guitarix. Same
> problem - naturally.
> 
> I played FluidSynth via the Virtual Keyboard without going into Ardour -
> there wasn't much point recording my virtual keyboard playing skills :-)
> No problems.
> 
> I didn't bother with any other effect/EQ plugins.
> 
> So. I didn't confirm what sample rate settings were being used. But if
> you can deal with the latency issue, you can do some rough/basic audio
> work on pipewire. For a true amateur like me - it would be OK after the
> latency is fixed.
> 
> Cheers,
> 
> Ross

Hi Ross,

I experimented today with bridging PipeWire/JACK using Studio Controls and 
QJackControl.

I could get JACK started with QJackControl, but there appeared to be no 
automatic 
bridging of JACK to PipeWire. In fact, all PulseAudio emulation of PipeWire 
seemed 
to be killed when JACK was started as indicated by a lack of audio device as 
shown 
by both Plasma and pavucontrol.

Studio Controls, however, would not cooperate as Autojack would crash if it 
couldn't 
stop PulseAudio via systemd (if systemd returned an error). This indicates that 
PulseAudio is a hard dependency of Studio Controls and I need to adjust the 
packaging as such.

However, this much I did discover: It seems as though the PipeWire JACK 
emulation 
(pipewire-jack) can be started/stopped on the fly by removing the symlink the 
ubuntustudio-pipewire-config package creates and running ldconfig. This might 
be 
good for people who want to simply run JACK without PulseAudio as I could 
simply 
write a piece of the Ubuntu Studio Audio Configuration app to include a part to 
enable or disable pipewire-jack.

Honestly, this is great as now the professional audio people don't have to 
completely rip-out PipeWire anymore unless they want to bridge system audio to 
their JACK setup, in which case we can still leave 
ubuntustudio-pulseaudio-config 
around (doesn't solve the ubuntu-desktop hard dependency issue, I know, but 
I'll 
address that with them in a bug report). Simply unchecking a box in Ubuntu 
Studio 
Audio Configuration to turn-off pipewire-jack and starting JACK via 
QJackControl 
would leave people with a professional way to do what they need to do, so long 
as 
they know what they're doing (I still feel as though QJackControl doesn't have 
the 
best UX).

In an IRC channel, I saw some tips on how to reduce PipeWire's latency with 
ALSA, 
so if those items can be implemented in a systemwide config, I might  implement 
that as well.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu


signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Ross Gammon]

On 7/12/23 19:49, Ross Gammon wrote:

On 7/12/23 19:46, Ross Gammon wrote:

qpwgraph is a QT GUI interface to wireplumber which is in Lunar.


Correction - qpwgraph depends on pipewire itself and not wireplumber. 
That was a wrong assumption on my part.


Ross



Well I had a play with qpwgraph and pipwire, and the some of the Ubuntu 
Studio audio tools with 23.04 (Lunar) on Gnome - and you can do stuff!


But I see what everyone means about pro-studios. It is all a bit clunky. 
and latency is a problem without an easy way to get in and fiddle with 
the settings. At least - one that I know of.


Apparently you can use some pipewire command line tools. But the manpage 
is light on information. I suppose your Ubuntu Studio Audio Config tool 
will help here - now I understand better what you were saying about the 
PIPEWIRE_QUANTUM variable.


With qpwgraph, I could make all of the connections that I used to make 
with The patch section of Carla. But everytime I clicked on another 
window, and then clicked back to qpwgraph, its window was un-maximised.


Hydrogen works.

I recorded an extra track into a previous Ardour project. Latency!

I recorded my electric guitar into an extra track via Guitarix. Same 
problem - naturally.


I played FluidSynth via the Virtual Keyboard without going into Ardour - 
there wasn't much point recording my virtual keyboard playing skills :-) 
No problems.


I didn't bother with any other effect/EQ plugins.

So. I didn't confirm what sample rate settings were being used. But if 
you can deal with the latency issue, you can do some rough/basic audio 
work on pipewire. For a true amateur like me - it would be OK after the 
latency is fixed.


Cheers,

Ross




--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Ross Gammon]

On 7/12/23 19:46, Ross Gammon wrote:

qpwgraph is a QT GUI interface to wireplumber which is in Lunar.


Correction - qpwgraph depends on pipewire itself and not wireplumber. 
That was a wrong assumption on my part.


Ross

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Ross Gammon]

Hi Erich,

Thanks for that great description of where we are at!

I don't really want to remove ubuntu-desktop because if I forget to 
reinstall it before I upgrade to 23.10 (Gnome) I could end up with some 
sort of Frankenstein installation.


The machine mainly does emails, web browsing and chromecastng these 
days, so I don't need a pro-audio set up on it as such. I will probably 
stick with pipewire on this machine and see where it takes me.


On 7/9/23 20:53, Erich Eickmeyer wrote:

Hi Ross,



<...>


However, as I read the PipeWire release notes, it might be unnecessary 
to use PulseAudio altogether and we might be able to deprecate it as 
well. Ubuntu 23.04 contains PipeWire 0.3.65. PipeWire 0.3.71 was 
released on 17 May and contains the following notable highlight:



  * A new zero-latency jackdbus bridge was added. This works similar
to what PulseAudio has to offer and creates a sink/source when
jackdbus is started. It is however much more efficient and runs
the complete PipeWire graph as a synchronous JACK client with no
added latency.


<...>


Then, a week ago, PipeWire 0.3.72 was released with this notable highlights:


  * A new module-netjack2-driver and module-netjack2-manager were
added that are compatible with NETJACK2. This allows PipeWire to
become a NETJACK2 manager or a driver between JACK2 or PipeWire
servers.
  * Support was added for firewire devices with FFADO. This is
untested for now and MIDI is not implemented yet.


I see pipewire 0.3.73 is now in Mantic!

<...>

The Gnome Settings under the Sound section allow you to choose inputs 
and outputs, and adjust volumes in a similar way that you could in 
pavucontrol - which is good.


qpwgraph is a QT GUI interface to wireplumber which is in Lunar. 
Unfortunately the GTK equivalent (Helvum) is not yet packaged for 
Debian. I will have a go with qpwgraph and see where it gets me.


I need to find some money and time to build a new Ubuntu Studio test 
machine. I have a spare USB audio interface now. Then I could try and 
help out with some more potentially destructive testing on Mantic.


Cheers,

Ross

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Erich Eickmeyer]

Hi Ross,

I was following-up on this and what the implications are for Mantic an 
the future. Where the problem lies is that we have no implementation 
for a JACK-PipeWire bridge in the same way that we have a 
JACK-PulseAudio bridge, hence when using JACK proper (as opposed to the 
PipeWire emulation that is now the default), we need to remove PipeWire 
and install PulseAudio. However, it appears as though GNOME development 
has gone toward depending on PipeWire for the sound server and 
deprecating PulseAudio altogether, which is why we're finding ourselves 
in this situation.


However, as I read the PipeWire release notes, it might be unnecessary 
to use PulseAudio altogether and we might be able to deprecate it as 
well. Ubuntu 23.04 contains PipeWire 0.3.65. PipeWire 0.3.71 was 
released on 17 May and contains the following notable highlight:


A new zero-latency jackdbus bridge was added. This works similar to 
what PulseAudio has to offer and creates a sink/source when jackdbus 
is started. It is however much more efficient and runs the complete 
PipeWire graph as a synchronous JACK client with no added latency.


How this works, I'm not quite certain. I'm assuming that, if jackdbus 
is started, that PipeWire simply bridges itself. What's nice is the 
zero-latency bit since we know that PulseAudio adds quite a bit of 
latency.


Another highlight in that release is notable as well:

The JACK notify callback implementation was reworked to emulate 
better what JACK does, improving compatibility with ardour7 and the 
JACK stress test.


This was one of Robin's major concerns. With that, it seems as though 
PipeWire is making great strides toward the Pro Audio space.


Then, a week ago, PipeWire 0.3.72 was released with this notable 
highlights:


A new module-netjack2-driver and module-netjack2-manager were added 
that are compatible with NETJACK2. This allows PipeWire to become a 
NETJACK2 manager or a driver between JACK2 or PipeWire 
servers.Support was added for firewire devices with FFADO. This is 
untested for now and MIDI is not implemented yet.


I know these were items that Len was looking for, so it would be good 
to see these implemented somehow. Len is out until mid-July so once 
he's back I'd love to see some feedback or ideas on this.


For Mantic, I have taken the pieces that switch between the PipeWire 
config an the PulseAudio/JACK config and moved them to their own 
application (called Ubuntu Studio Audio Config). It also allows one to 
configure the PIPEWIRE_QUANTUM variable that sets the buffer and sample 
rate at boot, which currently defaults at 1024/48000 for the greatest 
compatibility. However, if we deprecate PulseAudio, then having the 
metapackages change the configuration would be moot because then all 
that would have to be done is adding/removing a symlink, running 
ldconfig, and a reboot in order to use JACK proper and having it bridge 
to PipeWire. That might take me doing some experimentation.


Anyhow, this is what I'm thinking Mantic (23.10) since, if it works, it 
would improve compatibility across all platforms and we wouldn't have 
to worry about the adding/removing of whole packages in order to avoid 
major conflicts like we are having to do in 23.04.

--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

On Sun, Jul 9 2023 at 08:22:13 AM -07:00:00, Erich Eickmeyer 
 wrote:

Hi Ross!

I see what's going on. They made pipewire-audio a hard Depends of 
ubuntu-desktop. pipewire-audio itself is a metapackage which has a 
hard Depends on pipewire-alsa. ubuntu-desktop having a hard Depends 
on pipewire-audio seems wrong. Unfortunately, I have no good fix for 
that.


However, it does seem as though it's not removing anything critical, 
so that's the good news, just the ubuntu-desktop metapackage. 
However, I do wonder why they made pipewire-audio a hard Depends as 
opposed to a Recommends.


Either way, what you have should still work. It looks scarier than it 
is, but it's still working exactly the way I designed it to work.

--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

On Sun, Jul 9 2023 at 10:53:37 AM +02:00:00, Ross Gammon 
 wrote:

Hi All,

As you may remember, one of my machines runs plain Ubuntu, has a 
spare USB Audio device plugged in, and I have been testing Ubuntu 
Studio on top of Gnome (ubuntustudio-installer did this for me 
several releases ago).


Last night I upgraded to 23.04 and as expected, saw that Studio 
Controls was removed. Running ubuntustudio-installer to install 
ubuntustudio-pulseaudio-config failed. To try and understand what 
might have gone wrong, I tried to install us-pulse*-config on the 
command line. It (apt) was going to remove ubuntu-desktop which I 
thought was a bad idea and said "no":


~$ sudo apt install ubuntustudio-pulseaudio-config
...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were 

Re: [ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Erich Eickmeyer]

Hi Ross!

I see what's going on. They made pipewire-audio a hard Depends of 
ubuntu-desktop. pipewire-audio itself is a metapackage which has a hard 
Depends on pipewire-alsa. ubuntu-desktop having a hard Depends on 
pipewire-audio seems wrong. Unfortunately, I have no good fix for that.


However, it does seem as though it's not removing anything critical, so 
that's the good news, just the ubuntu-desktop metapackage. However, I 
do wonder why they made pipewire-audio a hard Depends as opposed to a 
Recommends.


Either way, what you have should still work. It looks scarier than it 
is, but it's still working exactly the way I designed it to work.

--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

On Sun, Jul 9 2023 at 10:53:37 AM +02:00:00, Ross Gammon 
 wrote:

Hi All,

As you may remember, one of my machines runs plain Ubuntu, has a 
spare USB Audio device plugged in, and I have been testing Ubuntu 
Studio on top of Gnome (ubuntustudio-installer did this for me 
several releases ago).


Last night I upgraded to 23.04 and as expected, saw that Studio 
Controls was removed. Running ubuntustudio-installer to install 
ubuntustudio-pulseaudio-config failed. To try and understand what 
might have gone wrong, I tried to install us-pulse*-config on the 
command line. It (apt) was going to remove ubuntu-desktop which I 
thought was a bad idea and said "no":


~$ sudo apt install ubuntustudio-pulseaudio-config
...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:

  libwireplumber-0.4-0 qpwgraph
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libasound2-plugins libpulsedsp pavucontrol pipewire-media-session 
pulseaudio

  pulseaudio-module-bluetooth pulseaudio-module-jack pulseaudio-utils
  python3-alsaaudio python3-cffi python3-jack-client python3-pycparser
  studio-controls zita-njbridge
Suggested packages:
  pavumeter paprefs
The following packages will be REMOVED:
  pipewire-alsa pipewire-audio pipewire-jack pipewire-pulse 
ubuntu-desktop

  ubuntu-desktop-minimal ubuntustudio-pipewire-config wireplumber
The following NEW packages will be installed:
  libasound2-plugins libpulsedsp pavucontrol pipewire-media-session 
pulseaudio

  pulseaudio-module-bluetooth pulseaudio-module-jack pulseaudio-utils
  python3-alsaaudio python3-cffi python3-jack-client python3-pycparser
  studio-controls ubuntustudio-pulseaudio-config zita-njbridge
0 upgraded, 15 newly installed, 8 to remove and 0 not upgraded.
Need to get 142 kB/1,906 kB of archives.
After this operation, 8,530 kB of additional disk space will be used.
Do you want to continue? [Y/n]

I have not looked into the dependencies to see if there is a way to 
untangle this. Instead, I was wondering if it was worth playing with 
the pipewire setup. It is a test setup after all! Does anyone know of 
any good guidance on the workflows in this set up? What would I use 
to help all of the routing between pipewire, jack, and how to use 
Ardour/Hydrogen/Carla etc.?


From the packages listed for removal above, I assume that wireplumber 
in the answer?


I did see some discussion on LAD, but I was hoping for some blog with 
easy instructions, screenshots etc. :-)


Cheers,

Ross

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com 

Modify settings or unsubscribe at: 



-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio on Gnome (23.04)

[Ross Gammon]

Hi All,

As you may remember, one of my machines runs plain Ubuntu, has a spare 
USB Audio device plugged in, and I have been testing Ubuntu Studio on 
top of Gnome (ubuntustudio-installer did this for me several releases ago).


Last night I upgraded to 23.04 and as expected, saw that Studio Controls 
was removed. Running ubuntustudio-installer to install 
ubuntustudio-pulseaudio-config failed. To try and understand what might 
have gone wrong, I tried to install us-pulse*-config on the command 
line. It (apt) was going to remove ubuntu-desktop which I thought was a 
bad idea and said "no":


~$ sudo apt install ubuntustudio-pulseaudio-config
...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:

  libwireplumber-0.4-0 qpwgraph
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libasound2-plugins libpulsedsp pavucontrol pipewire-media-session 
pulseaudio

  pulseaudio-module-bluetooth pulseaudio-module-jack pulseaudio-utils
  python3-alsaaudio python3-cffi python3-jack-client python3-pycparser
  studio-controls zita-njbridge
Suggested packages:
  pavumeter paprefs
The following packages will be REMOVED:
  pipewire-alsa pipewire-audio pipewire-jack pipewire-pulse ubuntu-desktop
  ubuntu-desktop-minimal ubuntustudio-pipewire-config wireplumber
The following NEW packages will be installed:
  libasound2-plugins libpulsedsp pavucontrol pipewire-media-session 
pulseaudio

  pulseaudio-module-bluetooth pulseaudio-module-jack pulseaudio-utils
  python3-alsaaudio python3-cffi python3-jack-client python3-pycparser
  studio-controls ubuntustudio-pulseaudio-config zita-njbridge
0 upgraded, 15 newly installed, 8 to remove and 0 not upgraded.
Need to get 142 kB/1,906 kB of archives.
After this operation, 8,530 kB of additional disk space will be used.
Do you want to continue? [Y/n]

I have not looked into the dependencies to see if there is a way to 
untangle this. Instead, I was wondering if it was worth playing with the 
pipewire setup. It is a test setup after all! Does anyone know of any 
good guidance on the workflows in this set up? What would I use to help 
all of the routing between pipewire, jack, and how to use 
Ardour/Hydrogen/Carla etc.?


From the packages listed for removal above, I assume that wireplumber 
in the answer?


I did see some discussion on LAD, but I was hoping for some blog with 
easy instructions, screenshots etc. :-)


Cheers,

Ross

--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Backports PPA

[Ross Gammon]

Glad to hear the official Backports have been resurrected. Someone new 
to Ubuntu Studio and not aware of the ppa, is likely to follow the 
standard Ubuntu instructions to enable backports. Installing from a ppa 
is always a last resort for me.


I had to think a little bit about the decision not to backport to 
non-LTS releases. If someone installs a backport on an LTS, then 
upgrades their system to each intermediate release, they will only ever 
be 6 months behind the latest upstream release until they are back on 
the LTS (and re-enable backports).


If someone is more desperate than that, they can probably ask here on 
the list for a special ppa, or we can provide a link to instructions to 
do it for themselves?


Cheers,

Ross

PS: Sorry about the delay. I missed the email amongst all the automated 
build emails! :-)


On 29.03.2023 17.04, Erich Eickmeyer wrote:


Hi All,


As you all know, for the past several years, we've been maintaining a 
backports PPA for our users to add to their systems to get updated 
software. This has worked well for several reasons.



However, the Ubuntu Backporters team has been resurrected and is very 
active. To give it a try, I backported studio-controls from Lunar to 
22.04 LTS and was successful.



With that, I believe this should be the way we should backport 
packages in the future, and perhaps even sunset the backports PPA. One 
thing to keep in mind is that the official backports repository only 
supports LTS releases, which means we would only be backporting only 
to the latest supported LTS and not the regular releases.



Another approach could be backporting via the backports repo for the 
LTS releases but keeping the backports PPA active for the regular 
releases, but I'd rather not do this as it just feels sloppy and a 
work-around to change process.



I'd love to hear your thoughts about this. Thanks!


--

Erich Eickmeyer

Project Leader - Ubuntu Studio

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] How to get debug information in Ubuntu Studio?

[rsbrux]

Ever since I installed Ubuntu Studio 22.04 LTS, Discover has crashed if I close 
it immediately after performing updates without changing the selected category 
in the navigation pane left from "Updates" to something else (e.g. 
"Applications").

I attempted to report this to bugs.kde.org, but am unable to provide the 
requested debug information. (Please see the bug report 
  for the gory details.)

For a few weeks now, KDE Plasma has been crashing occasionally immediately 
after login.  Again, I am unable to generate a useful trace or bug report.

I have attempted to follow some instructions I found on askubuntu 

  for installing debug symbols without success.

What do I need to install and/or configure to get useful bug reports and/or 
crash traces in Ubuntu Studio 22.04 LTS?

Thanks in advance for any suggestions or references.

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 135138816 bytes (5135138816)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193614080 bytes (5693614080)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131640832 bytes (5131640832)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193521920 bytes (5693521920)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio 23.04 Beta Released!

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu
Studio 23.10, codenamed “Lunar Lobster”.

While this beta is reasonably free of any showstopper installer bugs, you
may find some bugs within. This image is, however, mostly representative of
what you will find when Ubuntu Studio 23.04 is released on April 20, 2023.
Special notes:

The Ubuntu Studio 22.10 disk image (ISO) exceeds 4 GB and cannot be
downloaded to some file systems such as FAT32, and may not be readable when
burned to a DVD. For this reason, we recommend downloading to a compatible
file system. When creating a boot medium, we recommend creating a bootable
USB stick
 with
the ISO image, or burning to a Dual-Layer DVD.

Images can be obtained from this link:
https://cdimage.ubuntu.com/ubuntustudio/releases/23.04/beta/

Full updated information, including Upgrade Instructions, are available in
the Release Notes
.

New Features This Release

   - PipeWire is now enabled with JACK support by default. More on that here
   .
   - Ubuntu Studio Installer has been completely rewritten from the
   ground-up and can be used to remove components you don’t want. Version
   1.4
   - Patchance, a simple patchbay for JACK (works with Pipewire with JACK).
   version 1.0.0
   - We have changed back to the Materia theme first used in Ubuntu Studio
   19.04, this time using the dark theme by default.
   - Entirely new Login Screen and Lock Screen Theme based on the Materia
   theme. This is to differentiate from the Breeze theme traditionally used in
   KDE Plasma and used mostly in Kubuntu, as to set our default setup apart
   and to not simply be “Kubuntu with a bunch of extra packages.”

Major Package Upgrades

   - Darktable version 4.2.1
   - Gimp version 2.10.34
   - Ardour version 7.3.0
   - OBS Studio version 29.0.2
   - Audacity version 3.2.4
   - digiKam version 8.0.0-beta1
   - Kdenlive version 22.12.3
   - Krita version 5.1.5

There are many other improvements, too numerous to list here. We encourage
you to look around the freely-downloadable ISO image.
Known Issues

   - digiKam is a beta release of 8.0.0. As such, it may have undocumented
   bugs. We hope these bugs get ironed out by the time 8.0.0 stable comes out,
   and the digiKam developers have set a goal for April 2023 for a release.
   When the 8.0.0 stable release of digiKam becomes available, we hope to
   provide these to you as a Stable Release Update. If you would like a stable
   version of digiKam now, a snap of 7.8.0 is available
   .

Official Ubuntu Studio release notes can be found at
https://ubuntustudio.org/ubuntu-studio-23-04-release-notes/

Further known issues, mostly pertaining to the desktop environment, can be
found at https://wiki.ubuntu.com/LunarLobster/ReleaseNotes/Kubuntu (when
available)

Additionally, the main Ubuntu release notes contain more generic issues:
https://discourse.ubuntu.com/t/kinetic-kudu-release-notes/27976
Frequently Asked Questions

Q: Does KDE Plasma use more resources than your former desktop environment
(Xfce)?
A: In our testing, the increase in resource usage is negligible, and our
optimizations were never tied to the desktop environment.

Q: Does Ubuntu Studio contain snaps?
A: Yes. Mozilla’s distribution agreement with Canonical changed, and Ubuntu
was forced to no longer distribute Firefox in a native .deb package. We
have found that, after numerous improvements, Firefox now performs just as
well as the native .deb package did.

Additionally, Freeshow is an Electron-based application. Electron-based
applications cannot be packaged in the Ubuntu repositories in that they
cannot be packaged in a traditional Debian source package. While such apps
do have a build system to create a .deb binary package, it circumvents the
source package build system in Launchpad, which is required when packaging
for Ubuntu. However, Electron apps also have a facility for creating snaps,
which can be uploaded included. Therefore, for Freeshow to be included in
Ubuntu Studio, it had to be packaged as a snap.

Q: If I install this Beta release, will I have to reinstall when the final
release comes out?
A: No. If you keep it updated, your installation will automatically become
the final release. However, if Audacity returns to the Ubuntu repositories
before final release, then you might end-up with a double-installation of
Audacity. Removal instructions of one or the other will be made available
in a future post.

Q: Will you make an ISO with {my favorite desktop environment}?
A: To do so would require creating an entirely new flavor of Ubuntu, which
would require going through the Official Ubuntu Flavor application process.
Since we’re completely volunteer-run, we don’t have the 

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131669504 bytes (5131669504)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193368320 bytes (5693368320)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131620352 bytes (5131620352)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193368320 bytes (5693368320)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Backports PPA

[Erich Eickmeyer]

Hi All,

As you all know, for the past several years, we've been maintaining a backports 
PPA for 
our users to add to their systems to get updated software. This has worked well 
for 
several reasons.

However, the Ubuntu Backporters team has been resurrected and is very active. 
To give it 
a try, I backported studio-controls from Lunar to 22.04 LTS and was successful.

With that, I believe this should be the way we should backport packages in the 
future, and 
perhaps even sunset the backports PPA. One thing to keep in mind is that the 
official 
backports repository only supports LTS releases, which means we would only be 
backporting only to the latest supported LTS and not the regular releases.

Another approach could be backporting via the backports repo for the LTS 
releases but 
keeping the backports PPA active for the regular releases, but I'd rather not 
do this as it 
just feels sloppy and a work-around to change process.

I'd love to hear your thoughts about this. Thanks!

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio


signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131554816 bytes (5131554816)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193368320 bytes (5693368320)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131689984 bytes (5131689984)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 191066368 bytes (5691066368)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131444224 bytes (5131444224)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 97847552 bytes (5597847552)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131485184 bytes (5131485184)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 97888512 bytes (5597888512)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131472896 bytes (5131472896)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 93743360 bytes (5593743360)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131272192 bytes (5131272192)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 93415680 bytes (5593415680)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131247616 bytes (5131247616)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 93774080 bytes (5593774080)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133029376 bytes (5133029376)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 95574272 bytes (5595574272)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133389824 bytes (5133389824)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 95574272 bytes (5595574272)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133389824 bytes (5133389824)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 95545600 bytes (5595545600)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133400064 bytes (5133400064)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 95578368 bytes (5595578368)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133416448 bytes (5133416448)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 95576320 bytes (5595576320)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 133363200 bytes (5133363200)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 90585344 bytes (5590585344)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 125062656 bytes (5125062656)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 125052416 bytes (5125052416)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 123160064 bytes (5123160064)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Steve Langasek]

On Mon, Mar 13, 2023 at 11:21:39AM -0700, Erich Eickmeyer wrote:
> > > My point is that lowlatency shouldn't be grouped-in to these flavors, but
> > > should be given higher priority and grouped-in with generic since it's
> > > still used in desktop systems by default and is directly affecting the
> > > testing of an official flavor of Ubuntu. This was one of the reasons we
> > > had to miss testing week because we didn't even have kernel parity.

> > Impossible. we run out of disk space and cannot complete the
> > lowlatency builds with generic any more. Thus it is now treated
> > exactly like all other derivatives.

> If you ran out of disk space perhaps you should have requested more disk
> space?  I'd think that's something that should have been easily
> accommodated by IS.

This is running out of package space *during package builds*.  The Launchpad
build instances, for sanity of operability, are all pre-provisioned and
one-size-fits-all.  There is no capability in Launchpad to request more disk
space for a particular package build (the information is not even available
at the time the VM is instantiated what build will be done on it).  This is
a longstanding design decision that the Kernel Team has no power to change
and the Launchpad Team has no capacity to address in any sort of near term.
Your choices for Lunar are to have the lowlatency kernel flavor as a
separate source package or to have it not at all.

> because disk space shouldn't be a limitation in this day and age.

That is not constructive or realistic.

> > We do not invest additional engineering & resource time, to prioritise
> > lowlatency flavour, over other flavours, which have more images and
> > higher usage.

> Well, thanks, that alienates an entire user base and a whole official
> flavor of Ubuntu, which basically puts you at odds with the community. 
> I'm sure that's not your intention, but seeing as how Ubuntu is a
> community-driven distribution, you probably should rethink this.

All the other community flavors in Ubuntu use the generic kernel flavor. 
You are asking the Ubuntu Kernel Team to do something which first of all is
not possible from an engineering perspective, but secondly would involve
them committing to provide additional labor for a specific community flavor
which, from a community governance perspective, is not in your power to
require.

What Dimitri is communicating is that the support the lowlatency kernel
flavor receives is the same, no better no worse, as the support provided
for all of the kernel flavors that actually provide the funding for the
Kernel Team to do that work.

If you want to have a conversation about the Ubuntu Studio team taking
responsibility for a community-maintained kernel flavor, we could have that
conversation.  But it's not reasonable to ask that the Kernel Team make a
HIGHER committment to the lowlatency kernel in the service of Ubuntu Studio,
than they do to the kernels for paying customers.


That said, with my Release Team hat on, I will state clearly that I am not
happy with the state of kernels in the devel series; either in lunar, or in
other series of the recent past.  We have a pretty consistent history of
kernel security updates being synced from the stable release to
devel-proposed and then languishing there for months with insufficient
effort to get them migrated to the release pocket, with the result that
Ubuntu Developers who dogfood our development releases have the least
secure systems out of the box of any Ubuntu users, from the time a new
series opens to the time the Kernel Team releases kernels to the devel
series based on the new upstream version that's targeted for the next
release.

Dimitri as one of the few core-devs on the Kernel Team is who I see
primarily engaging with the Release Team to get kernels in the devel series
unstuck from -proposed.  But it's not on him personally to manage this,
there's a systemic issue of undercommitment of resources to the devel
series.

And complaining about the state of where things are now in the lunar release
pocket isn't going to change anything.  It would be a misinvestment to work
on rebasing the other kernel flavors on 6.1 now with a 6.2 upload around the
corner.

> > > reason (two blockers this round). To not have kernel equality here could
> > > cause false positives in kernel-level testing. JACK and the audio stack,
> > > in particular, are directly affected by the kernel, and what might work
> > > in 6.1 might not work in 5.19 with various devices. This could cause
> > > false bug reports and create a lot more problems for triage.

I think it's reasonable for you to decide not to invest time in testing
against a kernel that is not the final kernel for the release, where you
believe that will result in wasted time due to false-positives.

But 6.1 is also not the final kernel for the release, so I don't see any
reason that being at parity with the generic kernel in the release pocket
*right now* would make a 

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Thomas Ward]

A general reminder to *everyone* with my Community Council hat on:

Whether you are Canonical, an Ubuntu Flavor team member, or just a 
general community member, if you feel yourself starting to get hostile / 
aggressive in tone, step back and take a breather.


There are an increasing number of times I myself see conflict between 
people - whether it involves Canonical employees, Ubuntu Flavor teams, 
or otherwise - spilling into the lists, and it seems people are starting 
to skirt against CoC with those cases.


My advice is, on this case, Dimitri and Erich, both of you can go take a 
breather for a bit, and calm a little before returning to this.


(I'm not a fan of seeing this level of dissent / aggressiveness between 
people on the public lists, and as Philipp and Mauro at the Canonical 
Community Team know, this is an issue that seems to be becoming systemic 
and we have to remind people about the CoC and how to be nice towards 
others, or at least be constructive without coming off as hostile).



Thomas Ward
Ubuntu Community Council Member

On 3/13/23 14:48, Steve Langasek wrote:

On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote:

We pushed 6.1 out, and migrated, on generic only, to migrate lots of
packages in proposed, specifically nvidia & everything entangled with
it, and thus unblock autopkgtesting of all the userspace packages
which were otherwise failing on v5.19. There is no intention to port
all flavours to 6.1.

Again, this is one of the reasons we had do miss testing week among another

it was a mistake to skip testing week. you should have tested ubuntu
studio during the testing week like all the other flavours did. As
there are a lot of changes in lunar, that landed and affect ubuntu
studio. For example, all cloud images which use various cloud kernel
flavours, based on v5.19 did participate.
Can you explain who made the call to skip testing week? as to me, it
seemed, it's a requirement to release a flavour. Is studio going to
skip Lunar release?

Testing week is not a release-team-driven activity and flavor engagement in
it has no bearing on a flavor's eligibility for inclusion in a stable
release.

Flavors are required to hit a beta milestone and a release milestone.  How
they conduct their activities to ensure that these milestones are releasable
is for them to decide.




--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Steve Langasek]

On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote:
> > > We pushed 6.1 out, and migrated, on generic only, to migrate lots of
> > > packages in proposed, specifically nvidia & everything entangled with
> > > it, and thus unblock autopkgtesting of all the userspace packages
> > > which were otherwise failing on v5.19. There is no intention to port
> > > all flavours to 6.1.

> > Again, this is one of the reasons we had do miss testing week among another

> it was a mistake to skip testing week. you should have tested ubuntu
> studio during the testing week like all the other flavours did. As
> there are a lot of changes in lunar, that landed and affect ubuntu
> studio. For example, all cloud images which use various cloud kernel
> flavours, based on v5.19 did participate.

> Can you explain who made the call to skip testing week? as to me, it
> seemed, it's a requirement to release a flavour. Is studio going to
> skip Lunar release?

Testing week is not a release-team-driven activity and flavor engagement in
it has no bearing on a flavor's eligibility for inclusion in a stable
release.

Flavors are required to hit a beta milestone and a release milestone.  How
they conduct their activities to ensure that these milestones are releasable
is for them to decide.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Dimitri John Ledkov]

On Mon, 13 Mar 2023 at 17:54, Erich Eickmeyer  wrote:
>
> On Monday, March 13, 2023 10:29:50 AM PDT Dimitri John Ledkov wrote:
> > Ideally all flavours would be at 6.2 already, but due to various
> > reasons they are not.
>
> This is understandable and perfectly reasonable.
>
> > This is not unique to lowlatency flavour, and applies to kvm, azure,
> > raspi, and many more kernel flavours all of which are still on v5.19
> > in Lunar.
>
> My point is that lowlatency shouldn't be grouped-in to these flavors, but
> should be given higher priority and grouped-in with generic since it's still
> used in desktop systems by default and is directly affecting the testing of an
> official flavor of Ubuntu. This was one of the reasons we had to miss testing
> week because we didn't even have kernel parity.
>

Impossible. we run out of disk space and cannot complete the
lowlatency builds with generic any more. Thus it is now treated
exactly like all other derivatives.

We do not invest additional engineering & resource time, to prioritise
lowlatency flavour, over other flavours, which have more images and
higher usage.

> > We pushed 6.1 out, and migrated, on generic only, to migrate lots of
> > packages in proposed, specifically nvidia & everything entangled with
> > it, and thus unblock autopkgtesting of all the userspace packages
> > which were otherwise failing on v5.19. There is no intention to port
> > all flavours to 6.1.
>
> Again, this is one of the reasons we had do miss testing week among another

it was a mistake to skip testing week. you should have tested ubuntu
studio during the testing week like all the other flavours did. As
there are a lot of changes in lunar, that landed and affect ubuntu
studio. For example, all cloud images which use various cloud kernel
flavours, based on v5.19 did participate.

Can you explain who made the call to skip testing week? as to me, it
seemed, it's a requirement to release a flavour. Is studio going to
skip Lunar release?

> reason (two blockers this round). To not have kernel equality here could cause
> false positives in kernel-level testing. JACK and the audio stack, in
> particular, are directly affected by the kernel, and what might work in 6.1
> might not work in 5.19 with various devices. This could cause false bug
> reports and create a lot more problems for triage.
>
> > in Lunar, no further 6.1 builds will be done for any kernel flavour
> > for the time being. And v6.2 landing, across all flavours, is in
> > progress.
>
> Understandable. I'm just trying to prevent the problem at hand in the future,
> hence requesting that the decision to split the lowlatency into a lesser 
> flavor
> be reverted and have it built and treated as if it were the generic kernel
> since it is installed by default in an official flavor of Ubuntu on desktop
> systems. It is just clear to me that it truly does not get equal treatment,
> which confirms my fears, which is why I want the decision that was made
> reverted so that proper testing can proceed as it was before this change.

It was not a choice to split it, but necessity.
We had to split lowlatency into a separate build, as generic &
lowlatency from a single builder was unable to complete anymore due to
build-time, disk usage, and upload time.
It's either split builds, or no builds at all.
Thus a revert, would just cause generic & lowlatency fail to build
from source, always.

-- 
okurrr,

Dimitri

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Erich Eickmeyer]

On Monday, March 13, 2023 11:03:00 AM PDT Dimitri John Ledkov wrote:
> On Mon, 13 Mar 2023 at 17:54, Erich Eickmeyer  wrote:
> > On Monday, March 13, 2023 10:29:50 AM PDT Dimitri John Ledkov wrote:
> > > Ideally all flavours would be at 6.2 already, but due to various
> > > reasons they are not.
> > 
> > This is understandable and perfectly reasonable.
> > 
> > > This is not unique to lowlatency flavour, and applies to kvm, azure,
> > > raspi, and many more kernel flavours all of which are still on v5.19
> > > in Lunar.
> > 
> > My point is that lowlatency shouldn't be grouped-in to these flavors, but
> > should be given higher priority and grouped-in with generic since it's
> > still used in desktop systems by default and is directly affecting the
> > testing of an official flavor of Ubuntu. This was one of the reasons we
> > had to miss testing week because we didn't even have kernel parity.
> 
> Impossible. we run out of disk space and cannot complete the
> lowlatency builds with generic any more. Thus it is now treated
> exactly like all other derivatives.
 
If you ran out of disk space perhaps you should have requested more disk 
space? I'd think that's something that should have been easily accommodated by 
IS. If it's a matter of ISO image space, then you need to be using iso_level=3 
per the change I collaborated with to ubuntu-cdimage prior to 22.04's release 
which future-proofed all Ubuntu .iso images beyond the 4GB level. Either way, 
it sounds like you're either not communicating your needs to the right team(s) 
or doing something wrong, because disk space shouldn't be a limitation in this 
day and age.

> We do not invest additional engineering & resource time, to prioritise
> lowlatency flavour, over other flavours, which have more images and
> higher usage.

Well, thanks, that alienates an entire user base and a whole official flavor of 
Ubuntu, which basically puts you at odds with the community. I'm sure that's 
not your intention, but seeing as how Ubuntu is a community-driven 
distribution, you probably should rethink this.

> > > We pushed 6.1 out, and migrated, on generic only, to migrate lots of
> > > packages in proposed, specifically nvidia & everything entangled with
> > > it, and thus unblock autopkgtesting of all the userspace packages
> > > which were otherwise failing on v5.19. There is no intention to port
> > > all flavours to 6.1.
> > 
> > Again, this is one of the reasons we had do miss testing week among
> > another
> 
> it was a mistake to skip testing week. you should have tested ubuntu
> studio during the testing week like all the other flavours did. As
> there are a lot of changes in lunar, that landed and affect ubuntu
> studio. For example, all cloud images which use various cloud kernel
> flavours, based on v5.19 did participate.
>
> Can you explain who made the call to skip testing week? as to me, it
> seemed, it's a requirement to release a flavour. Is studio going to
> skip Lunar release?

That was my call as Ubuntu Studio flavor lead to skip testing week. I found out 
two days before the start of testing week (Feature Freeze) that a major 
component of our test case (studio-controls) was not going to work properly 
with the pipewire setup due to health issues on the part of the lead 
developer, so to have users use the ISO tracker without a modified test case, 
which needs to happen anyhow, would lead to poor test results. Basically, we 
were not ready for testing week.

As far as a requirement to release a flavor? We usually have had testing weeks 
after beta release. Honestly, this is between us and the release team.
 
> > reason (two blockers this round). To not have kernel equality here could
> > cause false positives in kernel-level testing. JACK and the audio stack,
> > in particular, are directly affected by the kernel, and what might work
> > in 6.1 might not work in 5.19 with various devices. This could cause
> > false bug reports and create a lot more problems for triage.
> > 
> > > in Lunar, no further 6.1 builds will be done for any kernel flavour
> > > for the time being. And v6.2 landing, across all flavours, is in
> > > progress.
> > 
> > Understandable. I'm just trying to prevent the problem at hand in the
> > future, hence requesting that the decision to split the lowlatency into a
> > lesser flavor be reverted and have it built and treated as if it were the
> > generic kernel since it is installed by default in an official flavor of
> > Ubuntu on desktop systems. It is just clear to me that it truly does not
> > get equal treatment, which confirms my fears, which is why I want the
> > decision that was made reverted so that proper testing can proceed as it
> > was before this change.
> It was not a choice to split it, but necessity.
> We had to split lowlatency into a separate build, as generic &
> lowlatency from a single builder was unable to complete anymore due to
> build-time, disk usage, and upload time.
> It's either split builds, or 

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Erich Eickmeyer]

On Monday, March 13, 2023 10:29:50 AM PDT Dimitri John Ledkov wrote:
> Ideally all flavours would be at 6.2 already, but due to various
> reasons they are not.

This is understandable and perfectly reasonable.

> This is not unique to lowlatency flavour, and applies to kvm, azure,
> raspi, and many more kernel flavours all of which are still on v5.19
> in Lunar.

My point is that lowlatency shouldn't be grouped-in to these flavors, but 
should be given higher priority and grouped-in with generic since it's still 
used in desktop systems by default and is directly affecting the testing of an 
official flavor of Ubuntu. This was one of the reasons we had to miss testing 
week because we didn't even have kernel parity.

> We pushed 6.1 out, and migrated, on generic only, to migrate lots of
> packages in proposed, specifically nvidia & everything entangled with
> it, and thus unblock autopkgtesting of all the userspace packages
> which were otherwise failing on v5.19. There is no intention to port
> all flavours to 6.1.

Again, this is one of the reasons we had do miss testing week among another 
reason (two blockers this round). To not have kernel equality here could cause 
false positives in kernel-level testing. JACK and the audio stack, in 
particular, are directly affected by the kernel, and what might work in 6.1 
might not work in 5.19 with various devices. This could cause false bug 
reports and create a lot more problems for triage.

> in Lunar, no further 6.1 builds will be done for any kernel flavour
> for the time being. And v6.2 landing, across all flavours, is in
> progress.

Understandable. I'm just trying to prevent the problem at hand in the future, 
hence requesting that the decision to split the lowlatency into a lesser flavor 
be reverted and have it built and treated as if it were the generic kernel 
since it is installed by default in an official flavor of Ubuntu on desktop 
systems. It is just clear to me that it truly does not get equal treatment, 
which confirms my fears, which is why I want the decision that was made 
reverted so that proper testing can proceed as it was before this change.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu Revival

signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Dimitri John Ledkov]

Ideally all flavours would be at 6.2 already, but due to various
reasons they are not.

This is not unique to lowlatency flavour, and applies to kvm, azure,
raspi, and many more kernel flavours all of which are still on v5.19
in Lunar.

We pushed 6.1 out, and migrated, on generic only, to migrate lots of
packages in proposed, specifically nvidia & everything entangled with
it, and thus unblock autopkgtesting of all the userspace packages
which were otherwise failing on v5.19. There is no intention to port
all flavours to 6.1.

in Lunar, no further 6.1 builds will be done for any kernel flavour
for the time being. And v6.2 landing, across all flavours, is in
progress.

On Mon, 13 Mar 2023 at 17:02, Erich Eickmeyer  wrote:
>
> Hi everyone,
>
> I'm bringing this up as a matter of concern for the Ubuntu Studio daily
> images. I believe sometime after the release of 22.04, the lowlatency kernel
> was split from the build of the generic kernel. From what I understand it was
> to make the build process easier and shorter, but I could be misremembering.
> While that would make sense were the lowlatency kernel *not* being used on
> desktop systems by default, the reality is that it is being used as such.
>
> My main concerns at the time was that the lowlatency kernel would not have
> testing or quality control parity with the generic kernel. I have been assured
> multiple times that the quality controls have not changed, so this is not a
> quality control concern, so please do not misunderstand my concern here.
>
> What I'm looking at now is a situation where the daily builds of lunar for
> Ubuntu Studio are not at kernel parity with other flavors simply because it
> builds using the lowlatency kernel. For instance, I can look at any other
> flavor and see the 6.1 generic kernel whereas Ubuntu Studio is still sitting 
> at
> 5.19 lowlatency. This means my testers aren't even testing on something
> *anywhere close* to what the final kernel will be, which, albiet, is expected
> to be 6.2. However, to be unable to test in parity with the other flavors is
> highly disappointing and is a huge setback.
>
> So, please, rather than treating the lowlatency kernel as a secondary,
> derivative kernel, I would like to kindly request that it be brought back to
> an equal kernel and built with the generic kernel since it's still being
> installed in desktop systems by default so that it can be tested on live
> images. That way, we could test it correctly and Ubuntu Studio isn't left
> behind as it is currently.
>
> Thank you in advance,
> Erich
> --
> Erich Eickmeyer
> Project Leader - Ubuntu Studio
> Technical Lead - Edubuntu--
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
okurrr,

Dimitri

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Erich Eickmeyer]

Hi everyone,

I'm bringing this up as a matter of concern for the Ubuntu Studio daily 
images. I believe sometime after the release of 22.04, the lowlatency kernel 
was split from the build of the generic kernel. From what I understand it was 
to make the build process easier and shorter, but I could be misremembering. 
While that would make sense were the lowlatency kernel *not* being used on 
desktop systems by default, the reality is that it is being used as such.

My main concerns at the time was that the lowlatency kernel would not have 
testing or quality control parity with the generic kernel. I have been assured 
multiple times that the quality controls have not changed, so this is not a 
quality control concern, so please do not misunderstand my concern here.

What I'm looking at now is a situation where the daily builds of lunar for 
Ubuntu Studio are not at kernel parity with other flavors simply because it 
builds using the lowlatency kernel. For instance, I can look at any other 
flavor and see the 6.1 generic kernel whereas Ubuntu Studio is still sitting at 
5.19 lowlatency. This means my testers aren't even testing on something 
*anywhere close* to what the final kernel will be, which, albiet, is expected 
to be 6.2. However, to be unable to test in parity with the other flavors is 
highly disappointing and is a huge setback.

So, please, rather than treating the lowlatency kernel as a secondary, 
derivative kernel, I would like to kindly request that it be brought back to 
an equal kernel and built with the generic kernel since it's still being 
installed in desktop systems by default so that it can be tested on live 
images. That way, we could test it correctly and Ubuntu Studio isn't left 
behind as it is currently.

Thank you in advance,
Erich
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu

signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 123110912 bytes (5123110912)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] CD image ubuntustudio/focal/dvd failed to build on 20230312

[noreply+ubuntu-cdimage]

= Building live filesystems =
Sun Mar 12 18:17:02 UTC 2023
ubuntustudio-amd64 on Launchpad starting at 2023-03-12 18:17:02
ubuntustudio-amd64: 
https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntustudio/+build/423011
Traceback (most recent call last):
  File "/srv/cdimage.ubuntu.com/bin/../lib/cdimage/build.py", line 706, in 
build_image_set_locked
live_successful = run_live_builds(config)
  File "/srv/cdimage.ubuntu.com/bin/../lib/cdimage/livefs.py", line 414, in 
run_live_builds
lp_build.lp_refresh()
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line 
757, in lp_refresh
super(Entry, self).lp_refresh(new_url, etag)
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line 
336, in lp_refresh
representation = self._root._browser.get(
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line 
448, in get
response, content = self._request(url, extra_headers=headers)
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line 
438, in _request
raise error
lazr.restfulclient.errors.BadRequest: HTTP Error 400: Bad request
Response headers:
---
-content-encoding: gzip
cache-control: no-cache
connection: close
content-length: 90
content-type: text/html
date: Sun, 12 Mar 2023 18:25:41 GMT
server: Apache/2.4.18 (Ubuntu)
status: 400
vary: Accept-Encoding
---
Response body:
---
b'400 Bad request\nYour browser sent an invalid 
request.\n\n'
---


-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 123135488 bytes (5123135488)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 123108864 bytes (5123108864)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 123024896 bytes (5123024896)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122822144 bytes (5122822144)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122785280 bytes (5122785280)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122789376 bytes (5122789376)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122666496 bytes (5122666496)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122678784 bytes (5122678784)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] LiveFS ubuntustudio/lunar/amd64 failed to build on 20230304

[noreply+ubuntu-cdimage]

https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntustudio/+build/419978
RUN: /usr/share/launchpad-buildd/bin/builder-prep 
Kernel version: Linux lcy02-amd64-084 5.4.0-139-generic #156-Ubuntu SMP Fri Jan 
20 17:27:18 UTC 2023 x86_64
Buildd toolchain package versions: launchpad-buildd_230~623~ubuntu20.04.1 
python3-lpbuildd_230~623~ubuntu20.04.1 sbuild_0.79.0-1ubuntu1 
git-build-recipe_0.3.6 git_1:2.25.1-1ubuntu3.10 dpkg-dev_1.19.7ubuntu3.2 
python3-debian_0.1.36ubuntu1.
Syncing the system clock with the buildd NTP service...
 4 Mar 18:27:29 ntpdate[1853]: adjust time server 10.131.248.1 offset 0.99 
sec
RUN: /usr/share/launchpad-buildd/bin/in-target unpack-chroot --backend=lxd 
--series=lunar --arch=amd64 LIVEFSBUILD-419978 --image-type lxd 
/home/buildd/filecache-default/627e2dab98eb80cb3e66288512e6ec74c0fb7628
Creating target for build LIVEFSBUILD-419978
To start your first container, try: lxc launch ubuntu:20.04
Or for a virtual machine: lxc launch ubuntu:20.04 --vm

/usr/lib/python3/dist-packages/pylxd/models/operation.py:76: UserWarning: 
Attempted to set unknown attribute "location" on instance of "Operation"
  warnings.warn(
RUN: /usr/share/launchpad-buildd/bin/in-target mount-chroot --backend=lxd 
--series=lunar --arch=amd64 LIVEFSBUILD-419978
Starting target for build LIVEFSBUILD-419978
/usr/lib/python3/dist-packages/pylxd/models/operation.py:76: UserWarning: 
Attempted to set unknown attribute "location" on instance of "Operation"
  warnings.warn(
Error: Instance is not running
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "type" on instance of "Container"
  warnings.warn(
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "project" on instance of "Container"
  warnings.warn(
Error: Instance is not running
Error: Instance is not running
Error: Instance is not running
RUN: /usr/share/launchpad-buildd/bin/in-target override-sources-list 
--backend=lxd --series=lunar --arch=amd64 LIVEFSBUILD-419978 'deb 
http://ftpmaster.internal/ubuntu lunar main universe'
Overriding sources.list in build-LIVEFSBUILD-419978
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "type" on instance of "Container"
  warnings.warn(
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "project" on instance of "Container"
  warnings.warn(
RUN: /usr/share/launchpad-buildd/bin/in-target update-debian-chroot 
--backend=lxd --series=lunar --arch=amd64 LIVEFSBUILD-419978
Updating target for build LIVEFSBUILD-419978
Get:1 http://ftpmaster.internal/ubuntu lunar InRelease [267 kB]
Get:2 http://ftpmaster.internal/ubuntu lunar/main amd64 Packages [1392 kB]
Get:3 http://ftpmaster.internal/ubuntu lunar/main Translation-en [510 kB]
Get:4 http://ftpmaster.internal/ubuntu lunar/universe amd64 Packages [15.2 MB]
Get:5 http://ftpmaster.internal/ubuntu lunar/universe Translation-en [5930 kB]
Fetched 23.3 MB in 47s (490 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following NEW packages will be installed:
  gcc-13-base
The following packages will be upgraded:
  adduser advancecomp apt bash binutils binutils-common
  binutils-x86-64-linux-gnu coreutils cpp cpp-12 dash debconf diffutils dpkg
  dpkg-dev fakeroot g++ g++-12 gcc gcc-12 gcc-12-base gpg gpg-agent gpgconf
  gpgv grep hostname libacl1 libapt-pkg6.0 libasan8 libatomic1 libattr1
  libaudit-common libaudit1 libbinutils libcap-ng0 libcap2 libcc1-0
  libcrypt-dev libcrypt1 libcryptsetup12 libctf-nobfd0 libctf0 libdb5.3
  libdpkg-perl libfakeroot libgcc-12-dev libgcc-s1 libgcrypt20 libgnutls30
  libgomp1 libgprofng0 libitm1 liblsan0 liblzma5 libmpfr6 libncurses6
  libncursesw6 libp11-kit0 libpcre2-8-0 libperl5.36 libquadmath0 libreadline8
  libselinux1 libsemanage-common libsemanage2 libsqlite3-0 libssl3
  libstdc++-12-dev libstdc++6 libsystemd-shared libsystemd0 libtinfo6 libtsan2
  libubsan1 libudev1 libzstd1 linux-libc-dev lsb-base lto-disabled-list
  ncurses-base ncurses-bin openssl perl perl-base perl-modules-5.36
  pkgbinarymangler readline-common sed sensible-utils systemd systemd-sysv
  sysvinit-utils tzdata xz-utils zlib1g
96 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 97.6 MB of archives.
After this operation, 6901 kB of additional disk space will be used.
Get:1 http://ftpmaster.internal/ubuntu lunar/main amd64 bash amd64 
5.2.15-2ubuntu1 [795 kB]
Get:2 http://ftpmaster.internal/ubuntu lunar/main amd64 coreutils amd64 
9.1-1ubuntu2 [1407 kB]
Get:3 http://ftpmaster.internal/ubuntu lunar/main amd64 liblzma5 amd64 
5.4.1-0.0 [125 kB]
Get:4 http://ftpmaster.internal/ubuntu lunar/main amd64 gcc-13-base amd64 
13-20230215-1ubuntu2 [18.7 kB]
Get:5 http://ftpmaster.internal/ubuntu lunar/main amd64 libgcc-s1 amd64 

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 122588672 bytes (5122588672)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 16052480 bytes (5516052480)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] LiveFS ubuntustudio/lunar/amd64 failed to build on 20230302

[noreply+ubuntu-cdimage]

https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntustudio/+build/419231
RUN: /usr/share/launchpad-buildd/bin/builder-prep 
Kernel version: Linux lcy02-amd64-080 5.4.0-139-generic #156-Ubuntu SMP Fri Jan 
20 17:27:18 UTC 2023 x86_64
Buildd toolchain package versions: launchpad-buildd_230~623~ubuntu20.04.1 
python3-lpbuildd_230~623~ubuntu20.04.1 sbuild_0.79.0-1ubuntu1 
git-build-recipe_0.3.6 git_1:2.25.1-1ubuntu3.10 dpkg-dev_1.19.7ubuntu3.2 
python3-debian_0.1.36ubuntu1.
Syncing the system clock with the buildd NTP service...
 2 Mar 18:27:28 ntpdate[1870]: adjust time server 10.131.248.1 offset 0.000123 
sec
RUN: /usr/share/launchpad-buildd/bin/in-target unpack-chroot --backend=lxd 
--series=lunar --arch=amd64 LIVEFSBUILD-419231 --image-type lxd 
/home/buildd/filecache-default/627e2dab98eb80cb3e66288512e6ec74c0fb7628
Creating target for build LIVEFSBUILD-419231
To start your first container, try: lxc launch ubuntu:20.04
Or for a virtual machine: lxc launch ubuntu:20.04 --vm

/usr/lib/python3/dist-packages/pylxd/models/operation.py:76: UserWarning: 
Attempted to set unknown attribute "location" on instance of "Operation"
  warnings.warn(
RUN: /usr/share/launchpad-buildd/bin/in-target mount-chroot --backend=lxd 
--series=lunar --arch=amd64 LIVEFSBUILD-419231
Starting target for build LIVEFSBUILD-419231
/usr/lib/python3/dist-packages/pylxd/models/operation.py:76: UserWarning: 
Attempted to set unknown attribute "location" on instance of "Operation"
  warnings.warn(
Error: Instance is not running
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "type" on instance of "Container"
  warnings.warn(
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "project" on instance of "Container"
  warnings.warn(
Error: Instance is not running
Error: Instance is not running
Error: Instance is not running
RUN: /usr/share/launchpad-buildd/bin/in-target override-sources-list 
--backend=lxd --series=lunar --arch=amd64 LIVEFSBUILD-419231 'deb 
http://ftpmaster.internal/ubuntu lunar main universe'
Overriding sources.list in build-LIVEFSBUILD-419231
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "type" on instance of "Container"
  warnings.warn(
/usr/lib/python3/dist-packages/pylxd/models/_model.py:134: UserWarning: 
Attempted to set unknown attribute "project" on instance of "Container"
  warnings.warn(
RUN: /usr/share/launchpad-buildd/bin/in-target update-debian-chroot 
--backend=lxd --series=lunar --arch=amd64 LIVEFSBUILD-419231
Updating target for build LIVEFSBUILD-419231
Ign:1 http://ftpmaster.internal/ubuntu lunar InRelease
Ign:1 http://ftpmaster.internal/ubuntu lunar InRelease
Ign:1 http://ftpmaster.internal/ubuntu lunar InRelease
Err:1 http://ftpmaster.internal/ubuntu lunar InRelease
  Could not connect to ftpmaster.internal:80 (10.131.66.192), connection timed 
out
Reading package lists...
W: Failed to fetch http://ftpmaster.internal/ubuntu/dists/lunar/InRelease  
Could not connect to ftpmaster.internal:80 (10.131.66.192), connection timed out
W: Some index files failed to download. They have been ignored, or old ones 
used instead.
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
RUN: /usr/share/launchpad-buildd/bin/in-target buildlivefs --backend=lxd 
--series=lunar --arch=amd64 LIVEFSBUILD-419231 --project ubuntustudio-dvd 
--datestamp 20230302
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  apparmor apt-utils attr busybox-initramfs cpio dbus dbus-bin dbus-daemon
  dbus-session-bus-common dbus-system-bus-common dbus-user-session dctrl-tools
  debootstrap dirmngr distro-info distro-info-data dmidecode dmsetup
  dosfstools fdisk gdisk genisoimage germinate gettext gettext-base git
  git-man gnupg gnupg-l10n gnupg-utils gpg-wks-client gpg-wks-server gpgsm
  initramfs-tools initramfs-tools-bin initramfs-tools-core klibc-utils kmod
  kpartx libaio1 libbrotli1 libbsd0 libcbor0.8 libcurl3-gnutls libdbus-1-3
  libedit2 liberror-perl libexpat1 libfido2-1 libfuse2 libfuse3-3 libglib2.0-0
  libicu71 libklibc libksba8 libldap-2.5-0 liblzo2-2 libmagic-mgc libmagic1
  libmpdec3 libnghttp2-14 libpam-systemd libparted2 libpopt0 libpsl5
  libpython3-stdlib libpython3.10-minimal libpython3.10-stdlib librtmp1
  libsasl2-2 libsasl2-modules-db libsquashfuse0 libssh-4 liburing2 libxml2
  libyaml-0-2 linux-base live-build lsb-release media-types mtools
  openssh-client parted python-apt-common python3 python3-apt python3-blinker
  python3-cffi-backend python3-cryptography python3-distro python3-germinate
  python3-httplib2 python3-jwt python3-launchpadlib python3-lazr.restfulclient
  python3-lazr.uri python3-minimal python3-oauthlib 

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 16052480 bytes (5516052480)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 16472320 bytes (5516472320)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 8667392 bytes (5508667392)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 7788800 bytes (5507788800)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116139520 bytes (5116139520)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116137472 bytes (5116137472)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116137472 bytes (5116137472)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116137472 bytes (5116137472)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 2752768 bytes (5502752768)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 116137472 bytes (5116137472)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 2201856 bytes (5502201856)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] MuseScore 4

[Dr. Stewart Thompson]

Musescore is now only available as an Appimage and isn't as well supported as 
previously on Linux, it's missing some features from the Windows and MacOS 
versions. So it can't cause too much trouble to a system but I'm not sure how 
much help you would get compared to the past as a lot of users I know jumped 
ship when that happened. It had always been on an equal footing before. 

On 17 February 2023 15:33:03 GMT, Ross Gammon  
wrote:
>Hi Paul,
>
>Just to be clear. It is possible to package Musescore 4 in Ubuntu (without 
>waiting for Debian), and maybe put it in a ppa. But that would require 
>somebody with the necessary time and skills to volunteer.
>
>Installing stuff from upstream (from the musecore website) can be risky, 
>especially if you are running an older Ubuntu release. There could be 
>incompatibilities in the version of libraries that Musescore 4 relies on. Will 
>upstream support you in this case? Ubuntu certainly cannot support you. If you 
>are desperate to use Musescore 4 (you cannot wait for Debian), then I would 
>ask around if anyone has had success using the upstream version of Musescore 4 
>on your version of Ubuntu before doing it. Otherwise you may have to uninstall 
>it later and clean up any mess yourself.
>
>Regards,
>
>Ross
>
>On 14.02.2023 23.02, Erich Eickmeyer wrote:
>> Hi Paul,
>> 
>> Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so 
>> "latest" may not be a good idea. Post-release updates are only considered if 
>> they are fixes for security vulnerabilities, high impact bug fixes, or 
>> unintrusive bug fixes with substantial benefit.
>> 
>> Furthermore, that package comes unchanged from Debian, which means there 
>> isn't an Ubuntu developer that touches it. So, this is really up to if 
>> Debian picks it up, but then it will only land in a later release. 
>> Additionally, Debian is coming up on their bi-yearly freeze in which they 
>> begin their release process for their next version, so there's probably not 
>> a whole lot of activity to be happening until later this year once that 
>> freeze starts.
>> 
>> All of that to say it's entirely out of our hands at this point on the 
>> Ubuntu Studio level as we're not the ones dealing with it; we're just 
>> putting it on the .iso image.
>> 
>> I hope you understand and I hope that helps.
>> 
>> --
>> Erich Eickmeyer
>> Project Leader
>> Ubuntu Studio
>> 
>> 
>> On Tue, Feb 14 2023 at 01:05:32 PM -08:00:00, Paul DeShaw 
>>  wrote:
>>> Greetings,
>>> 
>>> Are there any plans to put the latest MuseScore version into the 
>>> repository? Or should I just install it directly from musescore.org 
>>> ? I'm running last year's LTS--it's gotten so slow 
>>> and glitchy I am reluctant to upgrade--so maybe that's why Synaptic isn't 
>>> showing the latest MuseScore.
>>> 
>>> ~PD
>> -- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] MuseScore 4

[Ross Gammon]

Hi Paul,

Just to be clear. It is possible to package Musescore 4 in Ubuntu 
(without waiting for Debian), and maybe put it in a ppa. But that would 
require somebody with the necessary time and skills to volunteer.


Installing stuff from upstream (from the musecore website) can be risky, 
especially if you are running an older Ubuntu release. There could be 
incompatibilities in the version of libraries that Musescore 4 relies 
on. Will upstream support you in this case? Ubuntu certainly cannot 
support you. If you are desperate to use Musescore 4 (you cannot wait 
for Debian), then I would ask around if anyone has had success using the 
upstream version of Musescore 4 on your version of Ubuntu before doing 
it. Otherwise you may have to uninstall it later and clean up any mess 
yourself.


Regards,

Ross

On 14.02.2023 23.02, Erich Eickmeyer wrote:

Hi Paul,

Packages in Ubuntu may not be the latest. Ubuntu aims for stability, 
so "latest" may not be a good idea. Post-release updates are only 
considered if they are fixes for security vulnerabilities, high impact 
bug fixes, or unintrusive bug fixes with substantial benefit.


Furthermore, that package comes unchanged from Debian, which means 
there isn't an Ubuntu developer that touches it. So, this is really up 
to if Debian picks it up, but then it will only land in a later 
release. Additionally, Debian is coming up on their bi-yearly freeze 
in which they begin their release process for their next version, so 
there's probably not a whole lot of activity to be happening until 
later this year once that freeze starts.


All of that to say it's entirely out of our hands at this point on the 
Ubuntu Studio level as we're not the ones dealing with it; we're just 
putting it on the .iso image.


I hope you understand and I hope that helps.

--
Erich Eickmeyer
Project Leader
Ubuntu Studio


On Tue, Feb 14 2023 at 01:05:32 PM -08:00:00, Paul DeShaw 
 wrote:

Greetings,

Are there any plans to put the latest MuseScore version into the 
repository? Or should I just install it directly from musescore.org 
? I'm running last year's LTS--it's gotten so 
slow and glitchy I am reluctant to upgrade--so maybe that's why 
Synaptic isn't showing the latest MuseScore.


~PD
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 118181376 bytes (5118181376)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 2117888 bytes (5502117888)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 41424384 bytes (5041424384)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 1919232 bytes (5501919232)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 41424384 bytes (5041424384)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 428288 bytes (5500428288)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: [ubuntu-studio-devel] MuseScore 4

[Erich Eickmeyer]

Hi Paul,

Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so 
"latest" may not be a good idea. Post-release updates are only 
considered if they are fixes for security vulnerabilities, high impact 
bug fixes, or unintrusive bug fixes with substantial benefit.


Furthermore, that package comes unchanged from Debian, which means 
there isn't an Ubuntu developer that touches it. So, this is really up 
to if Debian picks it up, but then it will only land in a later 
release. Additionally, Debian is coming up on their bi-yearly freeze in 
which they begin their release process for their next version, so 
there's probably not a whole lot of activity to be happening until 
later this year once that freeze starts.


All of that to say it's entirely out of our hands at this point on the 
Ubuntu Studio level as we're not the ones dealing with it; we're just 
putting it on the .iso image.


I hope you understand and I hope that helps.

--
Erich Eickmeyer
Project Leader
Ubuntu Studio


On Tue, Feb 14 2023 at 01:05:32 PM -08:00:00, Paul DeShaw 
 wrote:

Greetings,

Are there any plans to put the latest MuseScore version into the 
repository? Or should I just install it directly from musescore.org 
? I'm running last year's LTS--it's gotten so 
slow and glitchy I am reluctant to upgrade--so maybe that's why 
Synaptic isn't showing the latest MuseScore.


~PD


-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] MuseScore 4

[Paul DeShaw]

Greetings,

Are there any plans to put the latest MuseScore version into the
repository? Or should I just install it directly from musescore.org? I'm
running last year's LTS--it's gotten so slow and glitchy I am reluctant to
upgrade--so maybe that's why Synaptic isn't showing the latest MuseScore.

~PD
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 41424384 bytes (5041424384)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 41424384 bytes (5041424384)

-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel