Re: Can we collaborate with Debian better?

[Erich Eickmeyer]

er about triaging our bugs and
> > sending what we can up to Debian. That being said, I disagree with the
> > solution of completely automating it.
> > 
> > > 2. As I just discovered, when Ubuntu rebuilds the archive for a release,
> > > 
> > > packages that FTBFS are silently dropped. There's no bug report on
> > > either of the two bug trackers. I'm upstream for a project that has
> > > been excluded from 24.04 because of this gap in the process. There
> > > really should be a bug report filed, so that the problem can be
> > > fixed
> > > before the release (what Debian does for their releases). And this
> > > should be filed on the Debian bug tracker, if that's where the
> > > maintenance happens.
> > 
> > This entirely falls on the Ubuntu Archive Administrators. To my
> > understanding as an Ubuntu Developer, if we want a package removed, it
> > is best practice to either have a Debian removal bug or an Ubuntu
> > removal bug explaining the rationale. Whether this is enforced is up to
> > the Archive Administrator doing the removal, since the only known public
> > documentation says nothing about filing bugs:
> > https://wiki.ubuntu.com/ArchiveAdministration#Removals
> > 
> > To say that packages that FTBFS are indiscriminately removed during
> > transitions ignores the fact that usually, we do have to file a bug if
> > we want an AA to remove a package.
> > 
> > > I don't know how hard the above is, but the current situation isn't
> > > great for either of us.
> > > 
> > > Related question: is there any way to get my packages included into some
> > > sort of noble "updates", or something like that?
> > > 
> > > I'm looking at the "mrcal" source package that had an ininteresting
> > > FTBFS bug due to some dependency changing its interface. There was a
> > > Debian bug report filed and quickly fixed, but this happened too late
> > > 
> > > for noble:
> > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398
> > > 
> > > The fix is to update the "mrbuild" package to at least 1.9. Is it
> > > possible to get an updated "mrbuild" and "mrcal" into 24.04?
> > > 
> > > If I'm misinterpreting what's going on, please let me know. Right now I
> > > 
> > > see this:
> > >dima@shorty:~$ rmadison -u ubuntu mrbuild | grep noble
> > >
> > > mrbuild | 1.8-1 | noble/universe| source, all
> > >
> > >dima@shorty:~$ rmadison -u ubuntu libmrcal-dev | grep noble
> > >
> > > libmrcal-dev | 2.4.1-1build1 | noble-proposed/universe| arm64,
> > 
> > ppc64el, riscv64
> > 
> > > The latest mrcal IS 2.4.1, but here it's in "noble-proposed" and not for
> > > amd64 for some reason.
> > 
> > I would highly suggest filing a bug against the package in Launchpad
> > following the Stable Release Update procedure:
> > https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
> > 
> > If you can articulate your case and the rationale for the update well,
> > it is unlikely that it will be rejected.
> > 
> > Best regards,
> > --
> > Simon Quigley
> > si...@tsimonq2.net
> > @tsimonq2:ubuntu.com on Matrix
> > tsimonq2 on LiberaChat and OFTC
> > 5C7A BEA2 0F86 3045 9CC8
> > C8B5 E27F 2CF8 458C 2FA4
> > 
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

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

[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
<https://ubuntustudio.org/ubuntu-studio-24-04-LTS-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
<https://ubuntustudio.org/download>.
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
<https://ubuntu.com/tutorials/create-a-usb-stick-on-ubuntu#1-overview> 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
<https://ubuntustudio.org/ubuntu-studio-24-04-LTS-release-notes/>.
<https://wiki.ubuntu.com/GroovyGorilla/Beta/UbuntuStudio>

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
<https://community.ardour.org/download?platform=linux=x86_64=compiled=options>
direc

[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 
<https://ubuntu.com/tutorials/create-a-usb-stick-on-ubuntu#1-overview>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 
<https://ubuntustudio.org/ubuntu-studio-24-04-LTS-release-notes/>*. 
<https://wiki.ubuntu.com/GroovyGorilla/Beta/UbuntuStudio>


*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
   <https://ubuntustudio.org/ubuntu-studio-installer/#audioconfig>*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
   <https://launchpad.net/bugs/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 <https://launchpad.net/>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 
<https://ubuntustudio.org/2023/09/a-message-from-the-project-lead/>as to 
the reasons why andgo here <https://ubuntustudio.org/contribute/>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 t

Re: Upcoming upload of glibc 2.39 in noble-proposed

[Erich Eickmeyer]

Hi Simon,

So, not that this relieves stress on anyone as we're all going to want 
to beat this (or wait for the long, long queues), but I assume you mean 
Friday, February 2nd?


On 1/31/24 09:07, Simon Chopin wrote:

Hi there!

Small timeline update: I'm actually aiming at uploading the new glibc on
Friday, 3rd, so two days from now.


Hi folks!

As usual in this time of the cycle, the new version of glibc is about to
be released upstream (scheduled next Thursday, Feb 1st), and should thus be
uploaded to the archive shortly thereafter, presumably around Feb 7th.

Have a look at the upstream changelog if you're interested in the
details:

https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=199f079f2764ccd2a1973fdd927bc291fdd1d0a9;hb=HEAD

Note that we are not impacted by the libcrypt removal as we
haven't built libcrypt for glibc for a while. If some of your projects
use a third-party malloc implementation, see at bottom to try a
snapshot.

A number of potential issues have already been identified through a test
rebuild done with a development snapshot of glibc. All glibc-related
regressions have been identified and reported (thanks to Ravi Kant
Sharma for his tremendous help on that front), and we're currently
working our way through the list:

https://bugs.launchpad.net/ubuntu/+bugs?field.tag=test-rebuild-glibc-noble

There's a fresh snapshot package available in a PPA:

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc

(i386 build is currently broken, WIP)


This upload usually has the immediate consequence of blowing up the
autopkgtest huge queue, meaning any other package that uses this queue
for its rdep tests will be directly impacted. In addition, the added
load usually means there's a higher failure rate on tests (e.g. timeouts
due to resource attrition). Furthermore, it is possible that a package
built after the glibc upload would pick up a versioned dependency on the
newer glibc due to changes in ABIs for existing functions. In that case,
said package would need to wait until glibc has migrated, which can take
a little while.

Feel free to reach out to me (schopin) on IRC if you have questions.

Cheers,
Simon


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


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-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: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?

[Erich Eickmeyer]

Hi Steve,

On 11/25/2023 1:38 PM, Steve Langasek wrote:

Having seen no objections to the proposal, I have filed an RT to have the
ubuntu-motu mailing list address redirected to ubuntu-devel-discuss.

On Wed, Oct 18, 2023 at 09:26:29PM -0700, Erich Eickmeyer wrote:

With my IRC op team hat on: let's be careful about the IRC channels which
are ultimately goverened by the IRC council (i.e. not a Canonical decision
except for what the IRC council has delegated to certain devel teams). While
I would be in favor of closing #ubuntu-motu and forwarding to #ubuntu-devel,
#ubuntu-next is a support channel (not a devel channel) and the volunteer
support in #ubuntu and #ubuntu-next would not be too keen to lose that one.
But, again, that's a discussion to be had with the IRC council.

What would be the process for asking #ubuntu-motu to be closed/redirected?


I'm fairly certain a request to ubuntu-irc@lists.u.c would do the trick, 
and a request in #ubuntu-ops wouldn't hurt either. I'd cite this mailing 
list thread for the rationale.


I hope that helps! :) Erich -- Erich Eickmeyer Project Leader - Ubuntu 
Studio Technical Lead - Edubuntu
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-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)

[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

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 <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

-- 
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: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?

[Erich Eickmeyer]

On Thu, Oct 19 2023 at 01:12:41 AM -03:00:00, Athos Ribeiro 
 wrote:

On Tue, Oct 17, 2023 at 05:44:12PM -0700, Steve Langasek wrote:


I'd therefore like to propose we close this mailing list and forward 
the
address on to ubuntu-devel-disc...@lists.ubuntu.com 
<mailto:ubuntu-devel-disc...@lists.ubuntu.com>, which at least has a
larger subscriber base and is more likely to result in users getting 
help

with their questions.

Opinions?


+1

I´d go further and propose the same for the IRC channel - retire it 
and

redirect people to #ubuntu-devel.

Maybe that should be another discussion including the #ubuntu+1-maint
(the discussions seem to happen in #ubuntu-release) and #ubuntu-next 
(->

#ubuntu-devel) channels too.

--
Athos Ribeiro



I'm 100% in agreement with Steve's proposal on the merge of 
ubuntu-motu@ to ubuntu-devel-discuss@.


With my IRC op team hat on: let's be careful about the IRC channels 
which are ultimately goverened by the IRC council (i.e. not a Canonical 
decision except for what the IRC council has delegated to certain devel 
teams). While I would be in favor of closing #ubuntu-motu and 
forwarding to #ubuntu-devel, #ubuntu-next is a support channel (not a 
devel channel) and the volunteer support in #ubuntu and #ubuntu-next 
would not be too keen to lose that one. But, again, that's a discussion 
to be had with the IRC council.


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

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

[ubuntu-studio-devel] Ubuntu Studio 23.10 Released

[Erich Eickmeyer]

untu, simply adding the 
Kubuntu Backports will help you with keeping the desktop environment and 
its components up to date with the latest versions:


 * |sudo add-apt-repository ppa:kubuntu-ppa/backports|
 * |sudo apt upgrade|


 More Updates

There are many more updates not covered here but are mentioned in 
theRelease Notes 
<https://ubuntustudio.org/ubuntu-studio-23-10-release-notes/>. We highly 
recommend reading those release notes so you know what has been updated 
and know any known issues that you may encounter.



   Get Involved!

A wonderful way to contribute is to get involved with the project 
directly! We’re always looking for new volunteers to help with 
packaging, documentation, tutorials, user support, and MORE!Check out 
all the ways you can contribute! <https://ubuntustudio.org/contribute/>


Our project leader, Erich Eickmeyer, is now working on Ubuntu Studio 
part-time, and is hoping that the users of Ubuntu Studio can give enough 
to generate a monthly part-time income. Your donations are appreciated! 
If other distributions can do it, surely we can! See the sidebar for 
ways to give!



   Special Thanks

Huge special thanks for this release go to:

 * *Eylul Dogruel*: Artwork, Graphics Design
 * *Ross Gammon*: Upstream Debian Developer, Testing, Email Support
 * *Sebastien Ramacher*:**Upstream Debian Developer
 * *Dennis Braun*: Upstream Debian Maintainer
 * *Rik Mills*: Kubuntu Council Member, help with Plasma desktop
 * *Len Ovens:* Studio Controls
 * *Mauro Gaspari*: Tutorials, Promotion, and Documentation, Testing
 * *Krytarik Raido*: IRC Moderator, Mailing List Moderator
 * *Erich Eickmeyer*: Project Leader, Packaging, Development,
   Direction, Treasurer


   Frequently Asked Questions

*Q:*Does Ubuntu Studio contain snaps?
*A:*Yes. Mozilla’s distribution agreement with Canonical changed about a 
year ago, 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 which is required when 
packaging for Ubuntu. However, Electron apps also have a facility for 
creating snaps, which can be uploaded to the snap store. Therefore, for 
FreeShow to be included in Ubuntu Studio, it had to be packaged as a snap.


*Q*: Will you ever make an ISO image 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 time or 
resources to do this. Instead, we recommend you download theofficial 
flavor for the desktop environment of your choice 
<https://ubuntu.com/download/flavours>and useUbuntu Studio Installer 
<https://ubuntustudio.org/ubuntu-studio-installer>to get Ubuntu 
Studio./Please note that this process does not convert that flavor to 
Ubuntu Studio but adds its tools, features, and benefits to the existing 
flavor installation/.


*Q:*What if I don’t want all these packages installed on my machine?
*A:*Simply use the*Ubuntu Studio Installer 
<https://ubuntustudio.org/ubuntu-studio-installer/>*to remove the 
features of Ubuntu Studio you don’t want or need by unchecking the boxes!
-- 
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-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

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

[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 
<https://ubuntu.com/tutorials/create-a-usb-stick-on-ubuntu#1-overview>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 
<https://ubuntustudio.org/ubuntu-studio-23-10-release-notes/>*. 
<https://wiki.ubuntu.com/GroovyGorilla/Beta/UbuntuStudio>



   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
   <https://ubuntustudio.org/ubuntu-studio-installer/#audioconfig>*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
   <https://launchpad.net/bugs/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 
<https://wiki.ubuntu.com/LunarLobster/ManticMinotaur/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 <https://launchpad.net/>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 
<https://ubuntustudio.org/2023/09/a-message-from-the-project-lead/>as to 
the reasons why andgo here <https://ubuntustudio.org/contribute/>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 requir

[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)

[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 pac

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 
<mailto:ubuntu-studio-devel@lists.ubuntu.com>
Modify settings or unsubscribe at: 
<https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel>


-- 
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: Question to flavours: touch-base on flavour participation for 23.10!

[Erich Eickmeyer]

On Wednesday, May 3, 2023 8:11:45 AM PDT Graham Inggs wrote:
> Hello flavours!
> 
> As we do around the start of every new cycle, I am reaching out to all
> the current official Ubuntu flavours to confirm active participation
> in the upcoming Ubuntu release - 23.10.
> 
> Working towards a release requires a lot of effort, so we'd like to
> make sure all the flavours are ready, properly staffed and have enough
> time allocated to make 23.10 happen for their users. This is why,
> similarly to last year, I will need a confirmation follow-up message
> about Mantic Minotaur participation from every flavour, that is:
> 
>  * Edubuntu
>  * Kubuntu
>  * Lubuntu
>  * Ubuntu Budgie
>  * Ubuntu MATE
>  * Ubuntu Unity
>  * Ubuntucinnamon
>  * Ubuntukylin
>  * Ubuntustudio
>  * Xubuntu
> 
> If you have any concerns regarding your participation, feel free to
> reach out to me or anyone else from the ubuntu-release team.
> 
> Thank you!
> 
> Graham

Edubuntu and Ubuntu Studio are go

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


signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

My math was wrong. 2300 UTC.

On Thu, Mar 16 2023 at 09:31:52 AM -07:00:00, Erich Eickmeyer 
 wrote:

Hi Paride,

As I understand it, this wasn't supposed to go out until EoD US 
Pacific Time (UTC -0700) which would place it at basically UTC 1100, 
if my math is correct. With that, could we have some more time before 
this officially goes into effect?


Ubuntu Studio is still trying to get the .svg for the official 
wallpapers with the lobster mascot to make our own derivatives, as 
are other flavors, and it would be rather silly to file a UIFe for 
something so trivial and only delay something that would've taken 
mere hours at most.


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

On Thu, Mar 16 2023 at 05:04:29 PM +01:00:00, Paride Legovini 
 wrote:

Hello Ubuntu developers,

Effective NOW, we are officially under the User Interface Freeze for 
Lunar:


   <https://wiki.ubuntu.com/UserInterfaceFreeze>

In order to help ensure our documentation is accurate for the 
release,

please notify the documentation team and translation teams of any
further changes to artwork, text strings, or UI designs that will be
made between now and the release, and please make such changes only
where necessary.

On behalf of the Ubuntu Release team,

--
Paride Legovini

--
ubuntu-devel-announce mailing list
ubuntu-devel-annou...@lists.ubuntu.com 
<mailto:ubuntu-devel-annou...@lists.ubuntu.com>

<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>


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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

Hi Paride,

As I understand it, this wasn't supposed to go out until EoD US Pacific 
Time (UTC -0700) which would place it at basically UTC 1100, if my math 
is correct. With that, could we have some more time before this 
officially goes into effect?


Ubuntu Studio is still trying to get the .svg for the official 
wallpapers with the lobster mascot to make our own derivatives, as are 
other flavors, and it would be rather silly to file a UIFe for 
something so trivial and only delay something that would've taken mere 
hours at most.


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

On Thu, Mar 16 2023 at 05:04:29 PM +01:00:00, Paride Legovini 
 wrote:

Hello Ubuntu developers,

Effective NOW, we are officially under the User Interface Freeze for 
Lunar:


   <https://wiki.ubuntu.com/UserInterfaceFreeze>

In order to help ensure our documentation is accurate for the release,
please notify the documentation team and translation teams of any
further changes to artwork, text strings, or UI designs that will be
made between now and the release, and please make such changes only
where necessary.

On behalf of the Ubuntu Release team,

--
Paride Legovini

--
ubuntu-devel-announce mailing list
ubuntu-devel-annou...@lists.ubuntu.com 
<mailto:ubuntu-devel-annou...@lists.ubuntu.com>

<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>


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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

Excellent, Brian. Thank you!

On Thu, Mar 16 2023 at 09:59:24 AM -07:00:00, Brian Murray 
 wrote:

On Thu, Mar 16, 2023 at 09:31:52AM -0700, Erich Eickmeyer wrote:

 Hi Paride,

 As I understand it, this wasn't supposed to go out until EoD US 
Pacific Time
 (UTC -0700) which would place it at basically UTC 1100, if my math 
is
 correct. With that, could we have some more time before this 
officially goes

 into effect?


There was some miscommunication among the mailing list moderators and
the email was allowed through a bit earlier than planned. Yes, you can
have a few more hours.

Brian


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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

Excellent, Brian. Thank you!

On Thu, Mar 16 2023 at 09:59:24 AM -07:00:00, Brian Murray 
 wrote:

On Thu, Mar 16, 2023 at 09:31:52AM -0700, Erich Eickmeyer wrote:

 Hi Paride,

 As I understand it, this wasn't supposed to go out until EoD US 
Pacific Time
 (UTC -0700) which would place it at basically UTC 1100, if my math 
is
 correct. With that, could we have some more time before this 
officially goes

 into effect?


There was some miscommunication among the mailing list moderators and
the email was allowed through a bit earlier than planned. Yes, you can
have a few more hours.

Brian


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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

My math was wrong. 2300 UTC.

On Thu, Mar 16 2023 at 09:31:52 AM -07:00:00, Erich Eickmeyer 
 wrote:

Hi Paride,

As I understand it, this wasn't supposed to go out until EoD US 
Pacific Time (UTC -0700) which would place it at basically UTC 1100, 
if my math is correct. With that, could we have some more time before 
this officially goes into effect?


Ubuntu Studio is still trying to get the .svg for the official 
wallpapers with the lobster mascot to make our own derivatives, as 
are other flavors, and it would be rather silly to file a UIFe for 
something so trivial and only delay something that would've taken 
mere hours at most.


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

On Thu, Mar 16 2023 at 05:04:29 PM +01:00:00, Paride Legovini 
 wrote:

Hello Ubuntu developers,

Effective NOW, we are officially under the User Interface Freeze for 
Lunar:


   <https://wiki.ubuntu.com/UserInterfaceFreeze>

In order to help ensure our documentation is accurate for the 
release,

please notify the documentation team and translation teams of any
further changes to artwork, text strings, or UI designs that will be
made between now and the release, and please make such changes only
where necessary.

On behalf of the Ubuntu Release team,

--
Paride Legovini

--
ubuntu-devel-announce mailing list
ubuntu-devel-annou...@lists.ubuntu.com 
<mailto:ubuntu-devel-annou...@lists.ubuntu.com>

<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>


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

Re: Lunar Lobster (23.04) UI Freeze

[Erich Eickmeyer]

Hi Paride,

As I understand it, this wasn't supposed to go out until EoD US Pacific 
Time (UTC -0700) which would place it at basically UTC 1100, if my math 
is correct. With that, could we have some more time before this 
officially goes into effect?


Ubuntu Studio is still trying to get the .svg for the official 
wallpapers with the lobster mascot to make our own derivatives, as are 
other flavors, and it would be rather silly to file a UIFe for 
something so trivial and only delay something that would've taken mere 
hours at most.


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

On Thu, Mar 16 2023 at 05:04:29 PM +01:00:00, Paride Legovini 
 wrote:

Hello Ubuntu developers,

Effective NOW, we are officially under the User Interface Freeze for 
Lunar:


   <https://wiki.ubuntu.com/UserInterfaceFreeze>

In order to help ensure our documentation is accurate for the release,
please notify the documentation team and translation teams of any
further changes to artwork, text strings, or UI designs that will be
made between now and the release, and please make such changes only
where necessary.

On behalf of the Ubuntu Release team,

--
Paride Legovini

--
ubuntu-devel-announce mailing list
ubuntu-devel-annou...@lists.ubuntu.com 
<mailto:ubuntu-devel-annou...@lists.ubuntu.com>

<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>


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

Re: 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

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

Re: 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-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[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

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-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 
<http://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] Ardour 7.1 Backports Available

[Erich Eickmeyer]

Our friends at Ardour have released Version 7.1, and we would like to offer
them huge congratulations! While the source code and their own builds were
available on release day, many of you have been waiting for Ardour 7 to
come to Ubuntu’s repositories.

That day has come. Ardour 7.1 will be landing in Ubuntu Lunar Lobster (future
23.04) and will be on Ubuntu Studio’s daily spins of Lunar Lobster very
soon.

Unfortunately, *it is not possible to backport Ardour 7.1 into Ubuntu 22.04
LTS or 22.10*, nor would we want to. This is because if we do, we might
disrupt the workflow of people who are currently working with projects in
6.9 that are relying on its functionality and sound. Ardour 7.1 projects
are not backwards compatible with Ardour 6.9 projects; once a 6.9 project
is opened in 7.1, it is converted to a 7.1 project and cannot be used in
6.9 again unless restored from a backup.

This is also the reason we will not be releasing Ardour 7.1 into Ubuntu
Studio’s main Backports PPA
. However, we
are giving Ardour its own Backports PPA so that users may upgrade Ardour in
their Ubuntu (Studio) 22.04 LTS or 22.10 installation whenever they are
ready.

To upgrade Ardour to 7.1, open a terminal and type the following:

sudo add-apt-repository ppa:ubuntustudio-ppa/ardour-backports
sudo apt upgrade

If at any point you change your mind and want to revert to Ardour 6.9 (and
hopefully haven’t converted any projects):

sudo apt install ppa-purge
sudo ppa-purge ppa:ubuntustudio-ppa/ardour-backports

Enjoy Ardour 7.1! If you find it useful, please consider downloading and
paying for the official package from Ardour themselves
.
They more than deserve it!
-- 
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 22.10 Released

[Erich Eickmeyer]

ng
   - Simon Quigley: Packaging, Ubuntu Core Developer
   - Eylul Dogruel: Artwork, Graphics Design
   - Ross Gammon: Upstream Debian Developer, Testing, Email Support
   - Sebastien Ramacher: Upstream Debian Developer
   - Dennis Braun: Debian Package Maintainer
   - Rik Mills: Kubuntu Council Member, help with Plasma desktop
   - Mauro Gaspari: Tutorials, Promotion, and Documentation, Testing
   - Aaron Rainbolt: Testing and bug reporting, IRC Support
   - Krytarik Raido: IRC Moderator, Mailing List Moderator
   - Erich Eickmeyer: Project Leader, Packaging, Direction, Treasurer

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 which is required when packaging for Ubuntu.
However, Electron apps also have a facility for creating snaps, which can
be uploaded to the snap store. Therefore, for FreeShow to be included in
Ubuntu Studio, it had to be packaged as a snap.

Q: Will you ever make an ISO image 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 time or resources
to do this. Instead, we recommend you download the official flavor for the
desktop environment of your choice <https://ubuntu.com/download/flavours>
and use Ubuntu Studio Installer
<https://ubuntustudio.org/ubuntu-studio-installer> to get Ubuntu Studio.
Please note that this process does not convert that flavor to Ubuntu Studio
but adds its tools, features, and benefits to the existing flavor
installation.

Q: What if I don't want all these packages installed on my machine?
A: Simply use the Ubuntu Studio Feature Uninstaller to remove the features
of Ubuntu Studio you don't want or need!
-- 
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 22.10 Beta Released (CORRECTED)

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu
Studio 22.10, codenamed “Kinetic Kudu”.

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 22.10 is released on October 20, 2022.
Special notes:

The Ubuntu Studio 22.10 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 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/22.10/beta/

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

Regarding Pipewire

One of our goals this release was to create some kind of switch between our
traditional PulseAudio/JACK setup and Pipewire, but this did not come to
fruition as we had quite a few other bugs to squash as a result of the
transition to ffmpeg 5. Additionally, we had a lot of clean-up after the
transition to Python 3.10 in 22.04 LTS among other bugs. Sadly, that’s
where our attention went and Pipewire support had to be deprioritized for
this release.
New Features This Release

   - Ubuntu Studio Installer now includes Ubuntu Studio Feature Uninstaller to
   remove features of Ubuntu Studio that you don’t need. This is a
   long-requested feature that will be detailed in the official release
   announcement when Ubuntu Studio 22.10 releases on October 20th.
   - Q Light Controller Plus version 4.12.5
   - Freeshow version 0.5.6
   - openLP version 2.9.5

Major Package Upgrades

   - Darktable version 4.0.0
   - OBS Studio version 28.0.1
   - Audacity version 3.1.3
   - digiKam version 8.0.0 development snapshot (pre-release, see notes
   below)
   - Kdenlive version 22.08.1
   - Krita version 5.1.1

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

   - digiKam is a development snapshot of 8.0.0. As such, it likely has
   undocumented bugs. We hope these bugs get ironed out by the time 8.0.0 beta
   comes out, but we are not sure when that will be as the digiKam developers
   have not released a timeline or release date. When the 8.0.0 beta or stable
   release of digiKam becomes available, we hope to provide these to you as
   Stable Release Updates. This came from the transition to ffmpeg 5 as prior
   versions of digiKam do not support ffmpeg 5. 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-22-10-release-notes/

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

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, Audacity 2.4.2, due to incompatibilities with ffmpeg 5, had
to be removed from the official Ubuntu repositories this cycle. For that
reason, we worked hard with the snap packager to include it in Ubuntu
Studio 22.10. Therefore, Audacity 3.1.3 is included as a snap. Watch this
bug  to
track Audacity’s reintroduction into the Ubuntu repositories. Right now, it
is on-pace to happen before the release of Ubuntu 22.10. When this happens,
we fully intend to drop the snap and re-include the .deb package in Ubuntu
Studio. Watch Ubuntu Studio News  for
updates.

Finally, 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. 

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

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu
Studio 22.10, codenamed “Kinetic Kudu”.

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 22.10 LTS is released on October 20,
2022.

Ubuntu Studio 22.04 LTS will be Ubuntu Studio’s first Long-Term
Support(LTS) release with the KDE Plasma Desktop Environment.
Special notes:

The Ubuntu Studio 22.10 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 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/22.10/beta/

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

Regarding Pipewire

One of our goals this release was to create some kind of switch between our
traditional PulseAudio/JACK setup and Pipewire, but this did not come to
fruition as we had quite a few other bugs to squash as a result of the
transition to ffmpeg 5. Additionally, we had a lot of clean-up after the
transition to Python 3.10 in 22.04 LTS among other bugs. Sadly, that’s
where our attention went and Pipewire support had to be deprioritized for
this release.
New Features This Release

   - Ubuntu Studio Installer now includes Ubuntu Studio Feature Uninstaller to
   remove features of Ubuntu Studio that you don’t need. This is a
   long-requested feature that will be detailed in the official release
   announcement when Ubuntu Studio 22.10 releases on October 20th.
   - Q Light Controller Plus version 4.12.5
   - Freeshow version 0.5.6
   - openLP version 2.9.5

Major Package Upgrades

   - Darktable version 4.0.0
   - OBS Studio version 28.0.1
   - Audacity version 3.1.3
   - digiKam version 8.0.0 development snapshot (pre-release, see notes
   below)
   - Kdenlive version 22.08.1
   - Krita version 5.1.1

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

   - digiKam is a development snapshot of 8.0.0. As such, it likely has
   undocumented bugs. We hope these bugs get ironed out by the time 8.0.0 beta
   comes out, but we are not sure when that will be as the digiKam developers
   have not released a timeline or release date. When the 8.0.0 beta or stable
   release of digiKam becomes available, we hope to provide these to you as
   Stable Release Updates. This came from the transition to ffmpeg 5 as prior
   versions of digiKam do not support ffmpeg 5. 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-22-10-release-notes/

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

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, Audacity 2.4.2, due to incompatibilities with ffmpeg 5, had
to be removed from the official Ubuntu repositories this cycle. For that
reason, we worked hard with the snap packager to include it in Ubuntu
Studio 22.10. Therefore, Audacity 3.1.3 is included as a snap. Watch this
bug  to
track Audacity’s reintroduction into the Ubuntu repositories. Right now, it
is on-pace to happen before the release of Ubuntu 22.10. When this happens,
we fully intend to drop the snap and re-include the .deb package in Ubuntu
Studio. Watch Ubuntu Studio News  for
updates.

Finally, 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 

Re: [ubuntu-studio-devel] Testing Ubuntu Studio 22 nvidia drivers

[Erich Eickmeyer]

On Thursday, September 22, 2022 7:35:26 PM PDT Juan DCG wrote:
> Dear,
> 
> I had problems with recenty launched 22.04, with nvidia drivers.
> 
> My solution was wait some time to test again to upgrade and hope it was
> fine, and nvidia drivers works fine.
> 
> Now, months later, I have the same problem, I boot on recovery mode in
> lowlatency kernel and try to fix and it seems to me all rigth but I end on
> an eternal black screen.
> 
> The problem is that nvidia drivers doesn't work with Ubuntu Studio 22.04
> low latency kernel and the X server not load.
> 
> Any guides, tips or tricks or explain better the problem and how to fix it
> or other testing approach?
> 
> Thanks,

Wrong mailing list.

You want ubuntu-studio-us...@lists.ubuntu.com

This is for development collaboration, not general help.

Moreover, we don't develop or touch anything you mentioned (the kernel or 
nvidia drivers) so we wouldn't be able to help with that anyhow.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council



-- 
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: Digikam 8.0.0~git snapshots (was +1 Maintenance Report)

[Erich Eickmeyer]

On Sunday, September 18, 2022 4:33:37 PM PDT Steve Langasek wrote:
> On Sun, Sep 18, 2022 at 08:51:51AM -0700, eeickme...@ubuntu.com wrote:
> > qtav was a dependency of digikam (another high-profile application),
> > which now FTBFS/dep-waits due to this removal.
> A brief look at the digikam 8.0.0~git20220917-0ubuntu1 indicates to me that
> qtav has been vendored, under core/libs/video/qtav, and that a
> build-dependency on libqtav-dev is no longer required.  Removing the build
> dependency results in an unrelated failure:
> 
>   CMake Error at CMakeLists.txt:289 (add_subdirectory):
> The source directory
> 
>   /tmp/digikam-8.0.0~git20220917/po
> 
> does not contain a CMakeLists.txt file.
> 
> Removing the build-dependency from the version in the release pocket results
> in a successful build.

Thanks, Steve. This actually pointed me in the right direction.

For some reason, when KDE's tarball creation tool generated the git snapshot 
tarball, it failed to create the necessary CMakeLists.txt files, so I just 
fixed 
the tool to force the creation. To be fair, the tool is only made for proper 
releases, not git snapshots.

The reason KDE has a separate tool to create their release tarballs is because 
they do their translations in a separate repository and the tool pulls the 
translations from there. In the case of a git snapshot the translations are 
incomplete, but I'd rather have some translations than none, so it gets a 
fuzzy set of commonly translated phrases and previously-existing translations 
from prior releases to generate translations where it can. Hence the tarball 
now has a po directory where it didn't exist before.

Either way, we now have digikam built with these translations in the release 
pocket. I estimate one more snapshot prior to Beta freeze. The digikam team 
estimates a beta release "in the coming weeks" so that might be a post-Beta 
upload or an SRU, and then a final release would almost certainly be an SRU 
upload. The good news is, like us, they are currently feature-frozen.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi Matthias! Great to hear from you!

On Friday, September 9, 2022 8:31:32 AM PDT Matthias Klumpp wrote:
> Hi everyone!
> 
> 1) PackageKit should remove unused stuff automatically during regular
> upgrades on APT-based systems (the backend is configured that way
> already)

Definitely a good step.

> 2) AppStream supports a way to not only signal that a new OS release
> is available, but also provide a basic changelog. What it does not
> (and can not (yet?) provide is specific instructions as to *how* to
> jump to a new release, as that is very distribution specific. See
> https://www.freedesktop.org/software/appstream/docs/sect-Metadata-OS.html
> 3) PackageKit is theoretically able to upgrade a system, see
> https://www.freedesktop.org/software/PackageKit/gtk-doc/Transaction.html#Tra
> nsaction.UpgradeSystem - we would preferably implement this via the
> offline-upgrades
> mechanism nowadays though. The specific mechanism to jump between
> distro releases once existed in the PackageKit APT backend, but was
> removed ages ago because it was very buggy and needed a rewrite
> anyway.

I think we're in the clear on this piece now. I was able to package distro-
release-notifier from Harald Sitter et al (https://invent.kde.org/system/
distro-release-notifier) which uses the existing backend of Ubuntu's update-
notifier. This means that it doesn't have to use appstream and launches the 
proper do-release-upgrade GUI frontend. I have tested it in 20.04 and it works 
properly, so I intend to get this into Ubuntu Studio (and discuss it further 
with Kubuntu so they don't end up in this situation again).

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi Matthias! Great to hear from you!

On Friday, September 9, 2022 8:31:32 AM PDT Matthias Klumpp wrote:
> Hi everyone!
> 
> 1) PackageKit should remove unused stuff automatically during regular
> upgrades on APT-based systems (the backend is configured that way
> already)

Definitely a good step.

> 2) AppStream supports a way to not only signal that a new OS release
> is available, but also provide a basic changelog. What it does not
> (and can not (yet?) provide is specific instructions as to *how* to
> jump to a new release, as that is very distribution specific. See
> https://www.freedesktop.org/software/appstream/docs/sect-Metadata-OS.html
> 3) PackageKit is theoretically able to upgrade a system, see
> https://www.freedesktop.org/software/PackageKit/gtk-doc/Transaction.html#Tra
> nsaction.UpgradeSystem - we would preferably implement this via the
> offline-upgrades
> mechanism nowadays though. The specific mechanism to jump between
> distro releases once existed in the PackageKit APT backend, but was
> removed ages ago because it was very buggy and needed a rewrite
> anyway.

I think we're in the clear on this piece now. I was able to package distro-
release-notifier from Harald Sitter et al (https://invent.kde.org/system/
distro-release-notifier) which uses the existing backend of Ubuntu's update-
notifier. This means that it doesn't have to use appstream and launches the 
proper do-release-upgrade GUI frontend. I have tested it in 20.04 and it works 
properly, so I intend to get this into Ubuntu Studio (and discuss it further 
with Kubuntu so they don't end up in this situation again).

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Friday, September 9, 2022 3:09:32 AM PDT Julian Andres Klode wrote:
> On Thu, Sep 08, 2022 at 08:46:31PM -0700, Erich Eickmeyer wrote:
> > Hi Aleix,
> > 
> > On Thursday, September 8, 2022 1:30:02 PM PDT Aleix Pol wrote:
> > > Note that Discover is just using PackageKit, so it's a problem to
> > > address
> > > there.
> > > 
> > > If despite having Discover be "very, very flawed" you want to have a
> > > discussion one day about how to make it fit for your purpose, I'll be
> > > happy to join and see what can be done.
> > 
> > That was not meant as an insult to your work, and I'm terribly sorry if it
> > arrived that way. Honestly, Discover is a fine piece of software,
> > especially as a software store and I quite enjoy using it as such.
> > However, I think you're right, my observations toward the "very, very
> > flawed" might be better directed at PackageKit since it doesn't have the
> > capability to do autoremove like I'm suggesting for software updates.
> 
> It's not hard to implement, it's basically
> 
>bool doAutoRemove = _config->FindB("APT::Get::AutomaticRemove", false);
>bool doAutoRemoveKernels =
> _config->FindB("APT::Get::AutomaticRemove::Kernels", false); bool
> hideAutoRemove = _config->FindB("APT::Get::HideAutoRemove");
> 
>std::unique_ptr kernelAutoremovalMatcher;
>if (doAutoRemoveKernels && !doAutoRemove)
>{
>   kernelAutoremovalMatcher =
> APT::KernelAutoRemoveHelper::GetProtectedKernelsFilter(Cache, true); }
> 
>Cache->MarkAndSweep();
> 
>SortedPackageUniverse Universe(Cache);
>// look over the cache to see what can be removed
>for (auto const : Universe)
>{
>   if (Cache[Pkg].Garbage)
>   {
> if(Pkg.CurrentVer() != 0 || Cache[Pkg].Install())
>if(Debug)
>   std::cout << "We could delete " <<  APT::PrettyPkg(Cache, Pkg)
> << std::endl; if (doAutoRemove || (kernelAutoremovalMatcher != nullptr &&
> (*kernelAutoremovalMatcher)(Pkg))) {
>if(Pkg.CurrentVer() != 0 &&
>   Pkg->CurrentState != pkgCache::State::ConfigFiles)
>   Cache->MarkDelete(Pkg, purgePkgs, 0, false);
>else
>   Cache->MarkKeep(Pkg, false, false);
> }
> 
> 
> at the right place after calling Upgrade().
> 
> Though I don't know maybe it needs the following code bits too where we
> recover packages we now have broken.
> 
>// we could have removed a new dependency of a garbage package,
>// so check if a reverse depends is broken and if so install it again.
> 
> Probably it makes sense to extract the non-CLI bits of DoAutoremove() in
> apt-private to apt-pkg, so PackageKit and others just have one function to
> call to do any autoremovals that should be done by policy.

Right. We definitely want to be careful here. The strength of update-manager is 
that it presents the user with a checkbox list of packages to remove and gives 
them the option whether or not to remove those packages. Autoremoving 
wholesale is not what I'm looking for here, and I guess I should've 
communicated that better.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Friday, September 9, 2022 3:09:32 AM PDT Julian Andres Klode wrote:
> On Thu, Sep 08, 2022 at 08:46:31PM -0700, Erich Eickmeyer wrote:
> > Hi Aleix,
> > 
> > On Thursday, September 8, 2022 1:30:02 PM PDT Aleix Pol wrote:
> > > Note that Discover is just using PackageKit, so it's a problem to
> > > address
> > > there.
> > > 
> > > If despite having Discover be "very, very flawed" you want to have a
> > > discussion one day about how to make it fit for your purpose, I'll be
> > > happy to join and see what can be done.
> > 
> > That was not meant as an insult to your work, and I'm terribly sorry if it
> > arrived that way. Honestly, Discover is a fine piece of software,
> > especially as a software store and I quite enjoy using it as such.
> > However, I think you're right, my observations toward the "very, very
> > flawed" might be better directed at PackageKit since it doesn't have the
> > capability to do autoremove like I'm suggesting for software updates.
> 
> It's not hard to implement, it's basically
> 
>bool doAutoRemove = _config->FindB("APT::Get::AutomaticRemove", false);
>bool doAutoRemoveKernels =
> _config->FindB("APT::Get::AutomaticRemove::Kernels", false); bool
> hideAutoRemove = _config->FindB("APT::Get::HideAutoRemove");
> 
>std::unique_ptr kernelAutoremovalMatcher;
>if (doAutoRemoveKernels && !doAutoRemove)
>{
>   kernelAutoremovalMatcher =
> APT::KernelAutoRemoveHelper::GetProtectedKernelsFilter(Cache, true); }
> 
>Cache->MarkAndSweep();
> 
>SortedPackageUniverse Universe(Cache);
>// look over the cache to see what can be removed
>for (auto const : Universe)
>{
>   if (Cache[Pkg].Garbage)
>   {
> if(Pkg.CurrentVer() != 0 || Cache[Pkg].Install())
>if(Debug)
>   std::cout << "We could delete " <<  APT::PrettyPkg(Cache, Pkg)
> << std::endl; if (doAutoRemove || (kernelAutoremovalMatcher != nullptr &&
> (*kernelAutoremovalMatcher)(Pkg))) {
>if(Pkg.CurrentVer() != 0 &&
>   Pkg->CurrentState != pkgCache::State::ConfigFiles)
>   Cache->MarkDelete(Pkg, purgePkgs, 0, false);
>else
>   Cache->MarkKeep(Pkg, false, false);
> }
> 
> 
> at the right place after calling Upgrade().
> 
> Though I don't know maybe it needs the following code bits too where we
> recover packages we now have broken.
> 
>// we could have removed a new dependency of a garbage package,
>// so check if a reverse depends is broken and if so install it again.
> 
> Probably it makes sense to extract the non-CLI bits of DoAutoremove() in
> apt-private to apt-pkg, so PackageKit and others just have one function to
> call to do any autoremovals that should be done by policy.

Right. We definitely want to be careful here. The strength of update-manager is 
that it presents the user with a checkbox list of packages to remove and gives 
them the option whether or not to remove those packages. Autoremoving 
wholesale is not what I'm looking for here, and I guess I should've 
communicated that better.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 9:41:23 AM PDT Erich Eickmeyer wrote:
> On Thursday, September 8, 2022 3:28:46 AM PDT Harald Sitter wrote:
> > https://invent.kde.org/system/distro-release-notifier may help
> 
> Thanks, Harald! I'm working on a package for this now. I wonder why it never
> got packaged as I don't see anything resembling it in the archives? Either
> way, this needs to be packaged yesterday. I might try to get this into
> Kinetic with an FFe if it works.
> 

I have good news! Per my testing, I have packaged this and was able to make a 
functioning package. I tested it on 20.04 and it was able to detect that an 
upgrade to 22.04.1 was available. I'm going to go ahead and proceed with 
getting this into the NEW queue and attempt a few FFe's and SRUs to get it 
backported so that we don't end up in a huge mess for 22.04 when upgrade time 
comes. I do realize that an entirely new package for an existing release is 
usually a huge NACK, but I feel in this case it might be justified since we 
have two flavors missing out on some major release upgrade functionality.

I might be asking the release team how they feel about this, but if anyone 
from the release team that has been watching this thread wants to reach out to 
me with some insight, just reply to me directly.

So, this solves one problem, and it's probably the more immediate problem, so 
for the topic of release upgrade notifications, I'll drop the ubuntu-devel@ 
from this part of the thread (which may come as a relief to some :) ).

But thanks to Harald Sitter for making me aware of this gem! I'm wondering why 
it was never packaged before as it seems fairly essential.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 9:41:23 AM PDT Erich Eickmeyer wrote:
> On Thursday, September 8, 2022 3:28:46 AM PDT Harald Sitter wrote:
> > https://invent.kde.org/system/distro-release-notifier may help
> 
> Thanks, Harald! I'm working on a package for this now. I wonder why it never
> got packaged as I don't see anything resembling it in the archives? Either
> way, this needs to be packaged yesterday. I might try to get this into
> Kinetic with an FFe if it works.
> 

I have good news! Per my testing, I have packaged this and was able to make a 
functioning package. I tested it on 20.04 and it was able to detect that an 
upgrade to 22.04.1 was available. I'm going to go ahead and proceed with 
getting this into the NEW queue and attempt a few FFe's and SRUs to get it 
backported so that we don't end up in a huge mess for 22.04 when upgrade time 
comes. I do realize that an entirely new package for an existing release is 
usually a huge NACK, but I feel in this case it might be justified since we 
have two flavors missing out on some major release upgrade functionality.

I might be asking the release team how they feel about this, but if anyone 
from the release team that has been watching this thread wants to reach out to 
me with some insight, just reply to me directly.

So, this solves one problem, and it's probably the more immediate problem, so 
for the topic of release upgrade notifications, I'll drop the ubuntu-devel@ 
from this part of the thread (which may come as a relief to some :) ).

But thanks to Harald Sitter for making me aware of this gem! I'm wondering why 
it was never packaged before as it seems fairly essential.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi Aleix,

On Thursday, September 8, 2022 1:30:02 PM PDT Aleix Pol wrote:
> Note that Discover is just using PackageKit, so it's a problem to address
> there.
> 
> If despite having Discover be "very, very flawed" you want to have a
> discussion one day about how to make it fit for your purpose, I'll be
> happy to join and see what can be done.
> 

That was not meant as an insult to your work, and I'm terribly sorry if it 
arrived that way. Honestly, Discover is a fine piece of software, especially as 
a software store and I quite enjoy using it as such. However, I think you're 
right, my observations toward the "very, very flawed" might be better directed 
at PackageKit since it doesn't have the capability to do autoremove like I'm 
suggesting for software updates.

Ubuntu's update-manager does have this capability, as it's using apt directly 
on the backend as opposed to using PackageKit as an abstraction layer. This 
may be why it has an advantage in terms of functionality that PackageKit (and 
Discover, by extension) cannot provide in this regard.

This has the benefit of removing outdated kernel packages which prevents a 
user's /boot volume from overfilling. One usually sees a separate /boot volume 
on LVM or encrypted LVM/LUKS systems. This is not something that Discover does 
automatically, which unfortunately causes a user to have to remember to run 
"apt autoremove" from the command line manually, if they even know to do that. 
unattended-upgrades is supposed to take care of this, but it doesn't always 
work in my experience.

At any rate, those are my thoughts at the moment. Thanks for chiming-in, and 
let me know if you have any more thoughts on the matter. :)

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi Aleix,

On Thursday, September 8, 2022 1:30:02 PM PDT Aleix Pol wrote:
> Note that Discover is just using PackageKit, so it's a problem to address
> there.
> 
> If despite having Discover be "very, very flawed" you want to have a
> discussion one day about how to make it fit for your purpose, I'll be
> happy to join and see what can be done.
> 

That was not meant as an insult to your work, and I'm terribly sorry if it 
arrived that way. Honestly, Discover is a fine piece of software, especially as 
a software store and I quite enjoy using it as such. However, I think you're 
right, my observations toward the "very, very flawed" might be better directed 
at PackageKit since it doesn't have the capability to do autoremove like I'm 
suggesting for software updates.

Ubuntu's update-manager does have this capability, as it's using apt directly 
on the backend as opposed to using PackageKit as an abstraction layer. This 
may be why it has an advantage in terms of functionality that PackageKit (and 
Discover, by extension) cannot provide in this regard.

This has the benefit of removing outdated kernel packages which prevents a 
user's /boot volume from overfilling. One usually sees a separate /boot volume 
on LVM or encrypted LVM/LUKS systems. This is not something that Discover does 
automatically, which unfortunately causes a user to have to remember to run 
"apt autoremove" from the command line manually, if they even know to do that. 
unattended-upgrades is supposed to take care of this, but it doesn't always 
work in my experience.

At any rate, those are my thoughts at the moment. Thanks for chiming-in, and 
let me know if you have any more thoughts on the matter. :)

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 3:28:46 AM PDT Harald Sitter wrote:
> https://invent.kde.org/system/distro-release-notifier may help
> 

Thanks, Harald! I'm working on a package for this now. I wonder why it never 
got packaged as I don't see anything resembling it in the archives? Either 
way, this needs to be packaged yesterday. I might try to get this into Kinetic 
with an FFe if it works. 

It doesn't, however, solve the problem with the package autoremoval feature 
that Discover lacks and Update Manager gives. I guess this would be a feature 
request in the upstream KDE Discover bugzilla. It's a "nice-to-have" and not 
quite as high priority as a whole Ubuntu/Distro Release Notification.

Thanks, this is at least a lead in the KDE direction. I'd just like to see 
what kind of options we have from the Ubuntu side as well since I'd expect 
Ubuntu, as our main community, to be our #1 advocates and supporters.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 3:28:46 AM PDT Harald Sitter wrote:
> https://invent.kde.org/system/distro-release-notifier may help
> 

Thanks, Harald! I'm working on a package for this now. I wonder why it never 
got packaged as I don't see anything resembling it in the archives? Either 
way, this needs to be packaged yesterday. I might try to get this into Kinetic 
with an FFe if it works. 

It doesn't, however, solve the problem with the package autoremoval feature 
that Discover lacks and Update Manager gives. I guess this would be a feature 
request in the upstream KDE Discover bugzilla. It's a "nice-to-have" and not 
quite as high priority as a whole Ubuntu/Distro Release Notification.

Thanks, this is at least a lead in the KDE direction. I'd just like to see 
what kind of options we have from the Ubuntu side as well since I'd expect 
Ubuntu, as our main community, to be our #1 advocates and supporters.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 3:39:30 AM PDT Neal Gompa wrote:
> On Thu, Sep 8, 2022 at 6:29 AM Harald Sitter  wrote:
> > https://invent.kde.org/system/distro-release-notifier may help
> > 
> > On Thu, Sep 8, 2022 at 3:09 AM Erich Eickmeyer  
wrote:
> > > Hi all,
> > > 
> > > 
> > > In Kubuntu and Ubuntu Studio, we rely on Discover and the Discover
> > > Notifier to run our GUI-based package updates. I don't care if you
> > > personally use apt periodically from the terminal, a case can be made
> > > that we expect our users to use Discover to do their updates.
> > > 
> > > 
> > > Unfortunately, Discover is very, very flawed. It uses packagekit as its
> > > backend and its upgrader is designed to do one thing: upgrade packages.
> > > By comparison, the Ubuntu Update Manager will give the user the option
> > > to remove unused packages, unused kernels. and even notify of new
> > > Ubuntu releases, which is something that Discover cannot do since it's
> > > built to be as distribution-agnostic as possible.
> Plasma Discover *can* support all these things. That is dependent on
> the PackageKit backend and whether your distribution ships AppStream
> metadata to identify your operating system and its upgrade path. This
> is something that is being worked on for Fedora KDE, so I'm aware of
> the possibility.
> 

I'm not sure about that. The way that Ubuntu does the notification is Update 
Manager monitors http://changelogs.ubuntu.com/meta-release-lts[1] or _http://
changelogs.ubuntu.com/meta-release_ depending on whether or not /etc/update-
manager/release-upgrades has been set to "Prompt=lts" or "Prompt=normal" 
respectively. This can be set via the frontend software-properties[-qt]. So, 
unless this 
can be converted to AppStream metadata, I'm not sure this is completely useful, 
nor 
am I sure the team would be willing to implement something there.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


[1] http://changelogs.ubuntu.com/meta-release-lts


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

Re: [ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

On Thursday, September 8, 2022 3:39:30 AM PDT Neal Gompa wrote:
> On Thu, Sep 8, 2022 at 6:29 AM Harald Sitter  wrote:
> > https://invent.kde.org/system/distro-release-notifier may help
> > 
> > On Thu, Sep 8, 2022 at 3:09 AM Erich Eickmeyer  
wrote:
> > > Hi all,
> > > 
> > > 
> > > In Kubuntu and Ubuntu Studio, we rely on Discover and the Discover
> > > Notifier to run our GUI-based package updates. I don't care if you
> > > personally use apt periodically from the terminal, a case can be made
> > > that we expect our users to use Discover to do their updates.
> > > 
> > > 
> > > Unfortunately, Discover is very, very flawed. It uses packagekit as its
> > > backend and its upgrader is designed to do one thing: upgrade packages.
> > > By comparison, the Ubuntu Update Manager will give the user the option
> > > to remove unused packages, unused kernels. and even notify of new
> > > Ubuntu releases, which is something that Discover cannot do since it's
> > > built to be as distribution-agnostic as possible.
> Plasma Discover *can* support all these things. That is dependent on
> the PackageKit backend and whether your distribution ships AppStream
> metadata to identify your operating system and its upgrade path. This
> is something that is being worked on for Fedora KDE, so I'm aware of
> the possibility.
> 

I'm not sure about that. The way that Ubuntu does the notification is Update 
Manager monitors http://changelogs.ubuntu.com/meta-release-lts[1] or _http://
changelogs.ubuntu.com/meta-release_ depending on whether or not /etc/update-
manager/release-upgrades has been set to "Prompt=lts" or "Prompt=normal" 
respectively. This can be set via the frontend software-properties[-qt]. So, 
unless this 
can be converted to AppStream metadata, I'm not sure this is completely useful, 
nor 
am I sure the team would be willing to implement something there.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


[1] http://changelogs.ubuntu.com/meta-release-lts


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

Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi all,

In Kubuntu and Ubuntu Studio, we rely on Discover and the Discover Notifier to 
run 
our GUI-based package updates. I don't care if you personally use apt 
periodically 
from the terminal, a case can be made that we expect our users to use Discover 
to 
do their updates.

Unfortunately, Discover is very, very flawed. It uses packagekit as its backend 
and 
its upgrader is designed to do one thing: upgrade packages. By comparison, the 
Ubuntu Update Manager will give the user the option to remove unused packages, 
unused kernels. and even notify of new Ubuntu releases, which is something that 
Discover cannot do since it's built to be as distribution-agnostic as possible. 

The lack of notification of new releases means when Release Upgrades are 
enabled, 
Kubuntu and Ubuntu Studio users are not notified whether their systems are set 
to 
upgrade to regular releases or LTS releases. This is especially problematic for 
users 
that simply don't know any better. We simply take for granted that we upgrade 
our 
systems, but new users don't necessarily know that they have to do that, and 
they 
don't necessarily pay attention to release announcements. We can't take that 
for 
granted that they automatically know that or are paying attention; it's not 
basic 
knowledge.

I have been seeing, with high levels of frequency, users showing-up in the 
#kubuntu 
chat with EOL systems, and users showing up running 20.04 not understanding 
why they aren't getting a notification to upgrade to 22.04. We need to do 
better 
from a development standpoint and not let this happen. Users need to be 
notified 
from their systems, not externally.

Years ago, update-manager-qt was a thing, and I'm sure update-notifier-qt was 
as 
well. I decided to experiment with both. Unfortunately, I ran into a few 
issues, 
namely that neither exists anymore. Beyond that, using the GTK equivalents, I 
ran 
into a couple of other issues:

 *  update-notifier doesn't even show in the system tray when there are 
updates 
on my system, even after a reboot or a relog. Only if I force it by executing 
it does it 
show, but it doesn't go away after running update-manager.
 *  update-manager runs well, but it pops-up a kdialog while running (see 
attached screenshot). Perhaps a bug/relic from old days, but definitely 
something 
that needs to be resolved.

Honestly, if these things can be resolved and the Qt equivalents can be 
resurrected, 
then it would be a huge boon to the users. Not only would they have a more 
robust 
upgrade management system, but they would also have the benefit of a Release 
Upgrade notifier when those times come.

Of course, if someone has a better solution and would rather re-invent the 
wheel, 
then sure, but I don't think re-inventing the wheel is ever a good solution and 
would 
rather see collaboration and cooperation first, as is the Ubuntu spirit.

I added ubuntu-devel@ to this discussion since the packages in question are in 
"main" and would require the help of some core devs to get some work done. 

Thanks for hearing me out,
Erich

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


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

[ubuntu-studio-devel] Upgrade Notifications for Kubuntu and Ubuntu Studio

[Erich Eickmeyer]

Hi all,

In Kubuntu and Ubuntu Studio, we rely on Discover and the Discover Notifier to 
run 
our GUI-based package updates. I don't care if you personally use apt 
periodically 
from the terminal, a case can be made that we expect our users to use Discover 
to 
do their updates.

Unfortunately, Discover is very, very flawed. It uses packagekit as its backend 
and 
its upgrader is designed to do one thing: upgrade packages. By comparison, the 
Ubuntu Update Manager will give the user the option to remove unused packages, 
unused kernels. and even notify of new Ubuntu releases, which is something that 
Discover cannot do since it's built to be as distribution-agnostic as possible. 

The lack of notification of new releases means when Release Upgrades are 
enabled, 
Kubuntu and Ubuntu Studio users are not notified whether their systems are set 
to 
upgrade to regular releases or LTS releases. This is especially problematic for 
users 
that simply don't know any better. We simply take for granted that we upgrade 
our 
systems, but new users don't necessarily know that they have to do that, and 
they 
don't necessarily pay attention to release announcements. We can't take that 
for 
granted that they automatically know that or are paying attention; it's not 
basic 
knowledge.

I have been seeing, with high levels of frequency, users showing-up in the 
#kubuntu 
chat with EOL systems, and users showing up running 20.04 not understanding 
why they aren't getting a notification to upgrade to 22.04. We need to do 
better 
from a development standpoint and not let this happen. Users need to be 
notified 
from their systems, not externally.

Years ago, update-manager-qt was a thing, and I'm sure update-notifier-qt was 
as 
well. I decided to experiment with both. Unfortunately, I ran into a few 
issues, 
namely that neither exists anymore. Beyond that, using the GTK equivalents, I 
ran 
into a couple of other issues:

 *  update-notifier doesn't even show in the system tray when there are 
updates 
on my system, even after a reboot or a relog. Only if I force it by executing 
it does it 
show, but it doesn't go away after running update-manager.
 *  update-manager runs well, but it pops-up a kdialog while running (see 
attached screenshot). Perhaps a bug/relic from old days, but definitely 
something 
that needs to be resolved.

Honestly, if these things can be resolved and the Qt equivalents can be 
resurrected, 
then it would be a huge boon to the users. Not only would they have a more 
robust 
upgrade management system, but they would also have the benefit of a Release 
Upgrade notifier when those times come.

Of course, if someone has a better solution and would rather re-invent the 
wheel, 
then sure, but I don't think re-inventing the wheel is ever a good solution and 
would 
rather see collaboration and cooperation first, as is the Ubuntu spirit.

I added ubuntu-devel@ to this discussion since the packages in question are in 
"main" and would require the help of some core devs to get some work done. 

Thanks for hearing me out,
Erich

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


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] Double options in System Settings -> [Network] Settings

[Erich Eickmeyer]

On Friday, September 2, 2022 8:31:35 AM PDT rsbrux wrote:
> This problem
> (https://www.reddit.com/r/ManjaroLinux/comments/vqms9s/double_options_in_sy
> stem_settings_network_settings/) also exists in Ubuntu Studio 22.04.1.  What
> are the chances of getting it fixed?

I, personally, have not seen that in Ubuntu Studio or Kubuntu.

If it exists in both Manjaro *and* Ubuntu Studio, then the logical conclusion 
is that it's potentially an upstream bug in KDE Plasma. We can't fix it here 
unless it's fixed there first, and even then, the Kubuntu team maintains the 
packages in question with the KDE stack.

You'll have to mention the version of Plasma (5.24) when reporting the bug.

Please report this to KDE at https://bugs.kde.org.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council



-- 
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] mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

Thanks, Steve! I'll go ahead and proceed with the +us plan seeing as how 
+repack just simply didn't seem like a good description. :)

On Saturday, August 27, 2022 4:12:09 PM PDT Steve Langasek wrote:
> Hi Erich,
> 
> Given the options the Debian maintainer presented, it sounds like they are
> not planning themselves on fixing this in the current upstream version.
> 
> Having checked that this is the case, I think it's ok for us in Ubuntu to
> upload with a new tarball versioned as +repack (or +us - ubuntu source,
> analagous to the +ds extension used in Debian), relying on the fact that we
> are unlikely to need to sync any critical fixes from Debian between now and
> the packaging of the next upstream release.
> 

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

Hi all,

I emailed the Debian maintainer, and he came back with 3 options for himself:

1. Wait for the next upstream release
 - Not an option for us, the release cadence on this is ~3 months, meaning the 
next would be due in October, post beta-freeze, and considering we're beyond 
feature freeze, this is still a no-go.

2. Adding a permanent epoch
 - This doesn't solve the problem as an epoch doesn't fix the tarball 
necessarily. Simply adding a suffix, as Gianfranco pointed out, would. Besides 
that, I'd avoid this at all costs.

3. Upload a new git snapshot
 - A git snapshot would also be ill-advised as that's the problem already. 
What we have is basically a git snapshot of the release *without* the required 
submodules, therefore an incomplete release tarball.

I found the response I got interesting and questionable, and not one I'd 
expect from someone I'd think to be a seasoned packager. I explained to him 
that none of his proposals would work and why, but did explain that a re-
upload with a +repack suffix on the correct tarball would work. I'm awaiting 
his 
next response, which is why I'm willing to give this a few more days.

Honestly, the interaction didn't leave me with a whole lot of confidence that 
the issue will be fixed, so I'm wholly prepared to fix the issue myself. using 
option #2 that Gianfranco gave and just maintain it until Debian releases a 
new version in the future, assuming the same mistake doesn't happen again. As 
I said, I'm willing to give it a few more days, but as I said, I'm not 100% 
confident we can rely on Debian in this case.

Erich

On Saturday, August 27, 2022 4:36:00 AM PDT Gianfranco Costamagna wrote:
> Hello, I suggest to ask Debian maintainer how to better solve it. 
> You can1 ask upstream to do a new release and tag 2 repack the source adding
> it with +repack suffix3 pack the complete tarball with a different
> compression algoritm4 use multiple tarballs for your source (e.g. Nodejs) 
> In any case better ask and do it on Debian first and then sync, otherwise
> we will be bitten by mismatches of tarball checksums. G.
> 
> Sent from Yahoo Mail on Android
> 
>   On Sat, Aug 27, 2022 at 6:57, Erich Eickmeyer
> wrote: Hi all,
> 
> 
> During my testing this evening of kdenlive 22.08, I found two issues:
> 
> 
> kdenlive now needs a recommends on mediainfo. No big deal, bug filed (LP:
> #1987934), I can practically take care of that in my sleep.
> 
> 
> However, it also needs a module in mlt: glaxnimate. Upon investigation,
> glaxnimate requires a build-dep on qt5base-dev and a build flag enabled
> (-DMOD_GLAXNIMATE=ON). It was at this point that I discovered that the
> glaxnimate submodule is *entirely missing* from the source tarball, and
> that the wrong tarball was grabbed by the Debian maintainer upstream from
> https://github.com/mltframework/mlt/releases/tag/v7.8.0. It seems as though
> the maintainer grabbed the github tagged source code tarball (released June
> 22nd) and not the intended tarball with all submodules, which came later
> (July 3rd).
> 
> 
> Since this tarball is obviously incorrect, how do we fix this situation? The
> maintainer will obviously have to be alerted to the error, but that doesn't
> solve the immediate problem with versioning in the archive. As this is a
> universe package, I'm more than happy to take care of it as long as I know
> how to version it.
> 
> 
> I can take care of all the necessary steps to write a bug report on this,
> but this seemed like a unique situation that I needed some advice on first,
> and seemed like it needed more explanation than I can provide on IRC.
> 
> 
> Thanks,
> 
> Erich

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

That's correct. mlt's glaxnimate module requires a build flag, and kdenlive 
22.08 will pop up a window if it cannot find it. That said, local builds are 
irrelevant in this discussion.

On Saturday, August 27, 2022 9:41:27 AM PDT lukefro...@hushmail.com wrote:
> For reference, I have local builds of kdenlive and MLT,and it looks like
> glaxnimate is not built by default. The source files are present in my mlt
> tarball but were not built and nothing by that name appears in my finished
> build. Didn't get any cmake or build errors about it either. Obviously
> anyone wanting to use this module needs this fixed.


-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

Sure! That actually sounds reasonable. I'll contact the maintainer and see 
what they say.

On Saturday, August 27, 2022 4:36:00 AM PDT Gianfranco Costamagna wrote:
> Hello, I suggest to ask Debian maintainer how to better solve it. 
> You can1 ask upstream to do a new release and tag 2 repack the source adding
> it with +repack suffix3 pack the complete tarball with a different
> compression algoritm4 use multiple tarballs for your source (e.g. Nodejs) 
> In any case better ask and do it on Debian first and then sync, otherwise
> we will be bitten by mismatches of tarball checksums. G.
> 



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] mlt has an incomplete/incorrect tarball

[Erich Eickmeyer]

Hi all,

During my testing this evening of kdenlive 22.08, I found two issues:

kdenlive now needs a recommends on mediainfo. No big deal, bug filed (LP: 
#1987934[1]), 
I can practically take care of that in my sleep.

However, it also needs a module in mlt: glaxnimate. Upon investigation, 
glaxnimate 
requires a build-dep on qt5base-dev and a build flag enabled 
(-DMOD_GLAXNIMATE=ON). 
It was at this point that I discovered that the glaxnimate submodule is 
*entirely missing* 
from the source tarball, and that the wrong tarball was grabbed by the Debian 
maintainer 
upstream from https://github.com/mltframework/mlt/releases/tag/v7.8.0[2]. It 
seems as 
though the maintainer grabbed the github tagged source code tarball (released 
June 
22nd) and not the intended tarball with all submodules, which came later (July 
3rd).

Since this tarball is obviously incorrect, how do we fix this situation? The 
maintainer will 
obviously have to be alerted to the error, but that doesn't solve the immediate 
problem 
with versioning in the archive. As this is a universe package, I'm more than 
happy to take 
care of it as long as I know how to version it.

I can take care of all the necessary steps to write a bug report on this, but 
this seemed like 
a unique situation that I needed some advice on first, and seemed like it 
needed more 
explanation than I can provide on IRC.

Thanks,
Erich

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


[1] https://launchpad.net/bugs/1987934
[2] https://github.com/mltframework/mlt/releases/tag/v7.8.0


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: Adding logo images to base-files?

[Erich Eickmeyer]

On Tuesday, June 14, 2022 6:06:21 AM PDT Sebastien Bacher wrote:
> Le 14/06/2022 à 02:09, Erich Eickmeyer a écrit :
> >> Just chiming-in here from a Flavor Lead perspective. It seems like this
> >> could be something that could be implemented via update-alternatives,
> >> similar to how plymouth themes and distributor-logo and are controlled.
> 
> How are flavor handling /etc/os-release today? LOGO isn't the only thing
> there they might want to set differently from Ubuntu (pretty_name,
> support_url, bug_report_url are other examples).
> 

Currently, we're not, and I for one am OK with it. As far as I am concerned, 
the OS *should* be reporting itself as Ubuntu since it *is* Ubuntu. We're not 
trying to disguise ourselves as a different distro, but as a different out-of-
the-box configuration of said distro. In Studio, we don't try to hide that as 
much as other flavors might. That said, I don't know of a single flavor that 
does change-out /etc/os-release.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Adding logo images to base-files?

[Erich Eickmeyer]

On Monday, June 13, 2022 5:08:37 PM PDT Erich Eickmeyer wrote:
> On Monday, June 13, 2022 4:44:04 PM PDT Steve Langasek wrote:
> > Hi Seb,
> > 
> > On Mon, Jun 13, 2022 at 09:44:30PM +0200, Sebastien Bacher wrote:
> > > Hey there,
> > > 
> > > I'm trying to see how we can fix https://launchpad.net/bugs/1931582 in
> > > Ubuntu, which is about adding a LOGO= entry to os-release.
> > > 
> > > I think it somewhat would make sense to provide the logos (plural
> > > because
> > > following
> > > https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/985
> > > it
> > > makes sense to have -text/-dark/text-dark variants.) in the same package
> > > as
> > > the key is defined?
> > > 
> > > Checking the current logo images it would be ~15kB of svg (or maybe png)
> > > files added to the package.
> > > 
> > > Would that sound something reasonable?
> > 
> > This seems ok in terms of the impact on the size of the base system (i.e.
> > negligible), but I wonder about the interfaces here.  Flavors have their
> > own individual logos, which they use for plymouth/grub themes for
> > example.  If we add LOGO to /etc/os-release, do we have to worry about
> > other upstreams picking this up and using it in other contexts where it's
> > less appropriate, because we want flavors to be able to customize
> > appearance independently of base-files?
> 
> Just chiming-in here from a Flavor Lead perspective. It seems like this
> could be something that could be implemented via update-alternatives,
> similar to how plymouth themes and distributor-logo and are controlled.
> 
> In fact, there are multiple ways alternatives could be used by flavors with
> simple alternatives registrations, if only they were utilized.
> 
> Just my two pennies. :)

Heh, meant that to go to the ML.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Question to flavors: touch-base on flavor participation for 22.10!

[Erich Eickmeyer]

Ubuntu Studio is good for 22.10.

On Wednesday, May 11, 2022 2:40:07 AM PDT Graham Inggs wrote:
> Hello flavors!
> 
> As we do around the start of every new cycle, I am reaching out to all
> the current official Ubuntu flavors to confirm active participation in
> the upcoming Ubuntu release - 22.10.
> 
> Working towards a release requires a lot of effort, so we'd like to
> make sure all the flavors are ready, properly staffed and have enough
> time allocated to make 22.10 happen for their users. This is why,
> similarly to last year, I will need a confirmation follow-up message
> about kinetic participation from every flavor, that is:
> 
>  * Kubuntu
>  * Xubuntu
>  * Ubuntu Studio
>  * Lubuntu
>  * Ubuntu Kylin
>  * Ubuntu MATE
>  * Ubuntu Budgie
> 
> If you have any concerns regarding your participation, feel free to
> reach out to me or anyone else from the ubuntu-release team.
> 
> Thank you!
> 
> Graham


-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

[ubuntu-studio-devel] Ubuntu Studio 22.04 LTS Released!

[Erich Eickmeyer]

:

   - Len Ovens: Studio Controls, Ubuntu Studio Installer, Coding
   - Thomas Ward: Packaging, Ubuntu Core Developer for Ubuntu Studio
   - Eylul Dogruel: Artwork, Graphics Design, Website Lead
   - Ross Gammon: Upstream Debian Developer, Guidance, Testing
   - Sebastien Ramacher: Upstream Debian Developer
   - Dennis Braun: Debian Package Maintainer
   - Rik Mills: Kubuntu Council Member, help with Plasma desktop
   - Mauro Gaspari: Tutorials, Promotion, and Documentation, Testing
   - Brian Hechinger: Testing and bug reporting
   - Chris Erswell: Testing and bug reporting
   - Robert Van Den Berg: Testing and bug reporting, IRC Support
   - Krytarik Raido: IRC Moderator, Mailing List Moderator
   - Erich Eickmeyer: Project Leader, Packaging, Direction, Treasurer
-- 
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 22.04 LTS Beta Released

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu
Studio 22.04 LTS, codenamed “Jammy Jellyfish”.

While this beta is reasonably free of any showstopper DVD build or
installer bugs, you may find some bugs within. This image is, however,
reasonably representative of what you will find when Ubuntu Studio 22.04
LTS is released on October 22, 2021.

Ubuntu Studio 22.04 LTS will be Ubuntu Studio’s first Long-Term
Support(LTS) release with the KDE Plasma Desktop Environment.
Special notes:

   - Due to the change in desktop environment, directly upgrading to Ubuntu
   Studio 22.04 LTS from 20.04 LTS is not supported and will not be supported.
However, upgrades from Ubuntu Studio 21.10 will be supported. See the
   Release Notes for more information. Anecdotally, some people have had
   success upgrading from 20.04 LTS to a later version, so your mileage may
   vary.
   - The Ubuntu Studio 22.04 LTS disk image (ISO) exceeds 4.0 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 creating a bootable
   USB stick
    with
   the ISO image.

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

Full updated information is available in the Release Notes
.

New Features

Ubuntu Studio 22.04 LTS includes the new KDE Plasma 5.24 LTS desktop
environment. This is a beautiful and functional upgrade to previous
versions, and we believe you will like it.

Studio Controls is upgraded to 2.3.0 and includes numerous bug fixes.

OBS Studio is upgraded to version 27.2.3 and works with Wayland sessions.
While Wayland is not currently the default, it is available as unsupported
and experimental.

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

   - At this time, the installer (Calamares) will crash when attempting an
   installation on a manually-partitioned btrfs file system. (LP: #1966774
   )
   - MyPaint crashes upon launching (LP: #1967163
   ), may be resolved after an update.
   - There are a few cosmetic issues thatshould be resolved before final
   release.

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

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


Additionally, the main Ubuntu release notes contain more generic issues:
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
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 initial launch, Firefox performs just as well as the
native .deb package did.

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.
Please Test!

This release we are participating in Ubuntu Testing Week, which begins as
soon as this beta is released. During this testing cycle we will work with
the amazing folks at the Ubuntu Hideout Discord
(https://discord.gg/ubuntu). They
have created a #testing-cycles channel in Discord and had a very
good response with users coming forward and helping with testing. They
have expressed a desire to have the Ubuntu Hideout Discord community make
an even greater impact during this release.

Whether or not you choose to participate on Discord is up to you. If you do
find something that is a legitimate bug, please open a terminal and type
“ubuntu-bug (package name)” to file the bug report since this collects
valuable information we need when debugging. If you get a popup while
something is running saying that something has crashed, don’t hesitate to
click on the “send bug report” button.
-- 
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: We're out of space

[Erich Eickmeyer]

Hi everyone,

Just wanted to mention that our out-of-space issues have been resolved by 
bumping the ISO 9660 level to 3, which allows for file sizes of up to 400GiB. 
Our 4GiB squashfs hits a measly 1% of that, so it's going to be a while before 
we hit another limit. :)

Special thanks to Steve Langasek and Łukasz Zemczak for helping find and test 
the solution and merging the fix to ubuntu-cdimage. I believe this will help 
all Ubuntu images rolling forward, not just Ubuntu Studio. :)

On Thursday, March 24, 2022 4:26:13 PM PDT Steve Langasek wrote:
> Ok.  Brian Murray has addressed the source of this problem; the new images
> were building successfully and being published, but incorrectly being
> published as .img instead of .iso with the .iso being copied forward from
> the previous directory.
> 
> I have removed the wrongly-named '.img' files.  The next daily build will
> produce .iso files again.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Ubuntu Studio: We're out of space

[Erich Eickmeyer]

Hi everyone,

Just wanted to mention that our out-of-space issues have been resolved by 
bumping the ISO 9660 level to 3, which allows for file sizes of up to 400GiB. 
Our 4GiB squashfs hits a measly 1% of that, so it's going to be a while before 
we hit another limit. :)

Special thanks to Steve Langasek and Łukasz Zemczak for helping find and test 
the solution and merging the fix to ubuntu-cdimage. I believe this will help 
all Ubuntu images rolling forward, not just Ubuntu Studio. :)

On Thursday, March 24, 2022 4:26:13 PM PDT Steve Langasek wrote:
> Ok.  Brian Murray has addressed the source of this problem; the new images
> were building successfully and being published, but incorrectly being
> published as .img instead of .iso with the .iso being copied forward from
> the previous directory.
> 
> I have removed the wrongly-named '.img' files.  The next daily build will
> produce .iso files again.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: We're out of space

[Erich Eickmeyer]

On Thursday, March 24, 2022 4:26:13 PM PDT Steve Langasek wrote:
> Ok.  Brian Murray has addressed the source of this problem; the new images
> were building successfully and being published, but incorrectly being
> published as .img instead of .iso with the .iso being copied forward from
> the previous directory.
> 
> I have removed the wrongly-named '.img' files.  The next daily build will
> produce .iso files again.

Thanks, Steve. Additionally, please increase the limit of the image size as 
we've decided USB media is OK for our purposes (discussed in a separate 
email). This should be reminiscent of when Ubuntu Studio had to go with the 
DVD route many years ago when other flavors were still on CDs.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: We're out of space

[Erich Eickmeyer]

On Thursday, March 24, 2022 4:26:13 PM PDT Steve Langasek wrote:
> Ok.  Brian Murray has addressed the source of this problem; the new images
> were building successfully and being published, but incorrectly being
> published as .img instead of .iso with the .iso being copied forward from
> the previous directory.
> 
> I have removed the wrongly-named '.img' files.  The next daily build will
> produce .iso files again.

Thanks, Steve. Additionally, please increase the limit of the image size as 
we've decided USB media is OK for our purposes (discussed in a separate 
email). This should be reminiscent of when Ubuntu Studio had to go with the 
DVD route many years ago when other flavors were still on CDs.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Ubuntu Studio: We're out of space

[Erich Eickmeyer]

On Thursday, March 24, 2022 1:18:27 PM PDT Len Ovens wrote:
> On Thu, 24 Mar 2022, Erich Eickmeyer wrote:
> >> If it's going to only be usable on a USB stick, then let's fix how we
> >> build
> >> it and avoid all the indirection that exists ONLY so that it can be used
> >> on
> >> optical media.
> 
> As 32bit systems are no longer supported anyway, I am not sure there are
> any 64bit systems that can not load from a USB stick. The only reason I
> have a DVD player/writer is because I have a PCIe PATA card and the DVD is
> used for playing media just because of the pain in find blank DVD/CDs and
> formating data to put it on there in the first place is also a pain. The
> new full size case my son bought doesn't even have a cd/dvd bay.
> 
> So anyway, A bootable USB install media format limited only by the USB
> stick size makes sense to me too. The only problem I see with that (I
> really don't know if it would even be a problem) is, would current
> windows/mac based USB stick writing tools still be able to create a
> bootable USB stick? I am assuming dd would still be able to write the
> whole image to the stick. I more advanced utility could format the whole
> stick, making it persistant too, though  making it persistant after the
> fact might be a better route. (I personally have no need for this but the
> question does pop up from time to time)
> 
> Len
> 

With that, we've got the two most active people working on Ubuntu Studio 
(myself and Len) who are onboard with the USB media idea. USB media is much 
cheaper than it used to be, and more readily available than DVD-/+Rs. I'm OK 
with increasing the size. We'll edit the ubuntustudio.org website to specify 
that they may want to use a USB stick.

Let's go with that, if you wouldn't mind, Steve. Thanks!

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: We're out of space

[Erich Eickmeyer]

Hi Jonathan,

On Thursday, March 24, 2022 7:52:33 AM PDT Jonathan Aquilina wrote:
> Hi Guys,
> 
> More a long time lurker here and I used to use studio in the past.
> 
> Wouldnt it be easier to strip everything to bare bones and allow the user to
> choose what apps to install on first login by popping up the package
> manager GUI?

In my original email that's what I proposed, but it's way too late to do that 
in 22.04 LTS with Beta Freeze being Monday.

However, instead of popping-up Discover or Muon, it would be something more 
akin to ubuntustudio-installer for people to pick what they need. 
Unfortunately, that defeats the purpose of having a live image to try things  
prior to installation, so keep that in mind.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: Second Jammy Jellyfish test rebuild

[Erich Eickmeyer]

On Thursday, March 24, 2022 6:05:06 AM PDT Graham Inggs wrote:
> The second test rebuild of Jammy Jellyfish was started on March 17,
> 2022 for all architectures, all components. The rebuild is finished
> for the main component, and finished for universe/multiverse on amd64
> and i386, and still running on the other architectures.
> 
> Results (please also look at the superseded builds) can be found at
> 
> https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jamm
> y-jammy.html
> 
> A number of builds failed without logs, and these will be retried.
> 
> Additional build failures for packages in jammy-proposed (not yet
> migrated to jammy) can be found at
> 
> http://qa.ubuntuwire.com/ftbfs/
> 
> Please help fixing the build failures.
> 
> Graham

I'm seeing a lot of failed arm64 builds without build logs. In the past when 
I've seen this, I've merely retried the build and it has succeeded. This shows 
a pattern in that it's likely we've got a buggy build server.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Ubuntu Studio: We're out of space

[Erich Eickmeyer]

On Wednesday, March 23, 2022 11:56:30 PM PDT Steve Langasek wrote:
> On Wed, Mar 23, 2022 at 10:28:06PM -0700, Erich Eickmeyer wrote:

> If this is all because of the 'OVERSIZED' warning, I've addressed that on
> IRC.  The header on https://cdimage.ubuntu.com/ubuntustudio/dvd/current/
> explains further:
> 
>   Warning: This image is oversized (which is a bug) and will not fit onto a
>   single-sided single-layer DVD.  However, you may still test it using a
>   larger USB drive or a virtual machine.
> 
> If Ubuntu Studio decide they don't care about the image fitting on a DVD, we
> can simply raise the size limit.  But in that case, I don't think we should
> call the image build itself a 'dvd' any more; and I also think that in
> short order (but not necessarily for 22.04) we should stop building this as
> a hybrid image since it's no longer practical to use it on optical media. 
> If it's going to only be usable on a USB stick, then let's fix how we build
> it and avoid all the indirection that exists ONLY so that it can be used on
> optical media.

We have discussed going with the USB stick route. However, what spurred this 
is because not only the OVERSIZED warning, but also because the images are 
merely copies of the 20220322 image and are not updating upon build. I thought 
this was due to the oversize warning. Either way, this is very concerning as 
we can't correctly test the builds due to a resolved bug involving automount 
conflicting with Calamares.

> > HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@,
> > there is another ISO format that works for DVD: ISO 13346, aka UDF.  This
> > allows for a virtually unlimited filesize, although I've seen anecdotal
> > mentions of 1024GB (1TB).  This would be preferable, and on behalf of
> > Ubuntu Studio, we request this switch if able, or even an alternative.  I
> > realize this is short notice prior to beta,
> 
> I've established that it's not actually necessary here, but for the record
> it would be completely impossible to make that switch in time for beta.  We
> have never built a UDF-format image, none of the tools are installed on the
> image build server to support this format, we have certainly never done a
> hybrid image with UDF (which means the easiest implementation would be a
> *non*-hybrid image, so if it's not a hybrid image why not just do a USB
> image instead? see above), and various parts of our installer-specific
> initramfs code assumes iso9660.

Fair. I honestly didn't expect that, but it was a thought.

> > It seems that Ubuntu Kylin shares our plight.
> 
> The only shared plight is that both flavors currently have images that are
> oversized for the limits that have been declared in the code...

Again, fair.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: [ubuntu-studio-devel] Ubuntu Studio: We're out of space

[Erich Eickmeyer]

On Wednesday, March 23, 2022 11:56:30 PM PDT Steve Langasek wrote:
> On Wed, Mar 23, 2022 at 10:28:06PM -0700, Erich Eickmeyer wrote:

> If this is all because of the 'OVERSIZED' warning, I've addressed that on
> IRC.  The header on https://cdimage.ubuntu.com/ubuntustudio/dvd/current/
> explains further:
> 
>   Warning: This image is oversized (which is a bug) and will not fit onto a
>   single-sided single-layer DVD.  However, you may still test it using a
>   larger USB drive or a virtual machine.
> 
> If Ubuntu Studio decide they don't care about the image fitting on a DVD, we
> can simply raise the size limit.  But in that case, I don't think we should
> call the image build itself a 'dvd' any more; and I also think that in
> short order (but not necessarily for 22.04) we should stop building this as
> a hybrid image since it's no longer practical to use it on optical media. 
> If it's going to only be usable on a USB stick, then let's fix how we build
> it and avoid all the indirection that exists ONLY so that it can be used on
> optical media.

We have discussed going with the USB stick route. However, what spurred this 
is because not only the OVERSIZED warning, but also because the images are 
merely copies of the 20220322 image and are not updating upon build. I thought 
this was due to the oversize warning. Either way, this is very concerning as 
we can't correctly test the builds due to a resolved bug involving automount 
conflicting with Calamares.

> > HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@,
> > there is another ISO format that works for DVD: ISO 13346, aka UDF.  This
> > allows for a virtually unlimited filesize, although I've seen anecdotal
> > mentions of 1024GB (1TB).  This would be preferable, and on behalf of
> > Ubuntu Studio, we request this switch if able, or even an alternative.  I
> > realize this is short notice prior to beta,
> 
> I've established that it's not actually necessary here, but for the record
> it would be completely impossible to make that switch in time for beta.  We
> have never built a UDF-format image, none of the tools are installed on the
> image build server to support this format, we have certainly never done a
> hybrid image with UDF (which means the easiest implementation would be a
> *non*-hybrid image, so if it's not a hybrid image why not just do a USB
> image instead? see above), and various parts of our installer-specific
> initramfs code assumes iso9660.

Fair. I honestly didn't expect that, but it was a thought.

> > It seems that Ubuntu Kylin shares our plight.
> 
> The only shared plight is that both flavors currently have images that are
> oversized for the limits that have been declared in the code...

Again, fair.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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: We're out of space

[Erich Eickmeyer]

Hi everyone,

Two years ago, at Ubuntu Studio,we decided switch our default desktop 
environment to KDE Plasma. Unfortunately, that is coming back to bite us.

At the time, it seemed like a good idea, as both Plasma and Xfce were around 
the 
same size in disk space, and we also decided, Ubuntu Studio isn't tied to its 
desktop 
environment.

The problem that I'm seeing is that the ISO 9660 spec, the standard on which 
all of 
our ISO images are built, has a hard limit of 4096MB per file size. In our 
case, the 
squashfs file size is exceeding that. This is resulting in failed builds. 

HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@, there is 
another ISO format that works for DVD: ISO 13346, aka UDF. This allows for a 
virtually unlimited filesize, although I've seen anecdotal mentions of 1024GB 
(1TB). 
This would be preferable, and on behalf of Ubuntu Studio, we request this 
switch if 
able, or even an alternative. I realize this is short notice prior to beta, but 
we don't 
have much choice as the amount I'm having to remove is basically nullifying 
Ubuntu 
Studio's reason to exist in that we're having to severely limit the amount of 
tools we 
can carry. It seems that Ubuntu Kylin shares our plight.

To emphasize this note, the squashfs file size is only going to get larger. 
Kubuntu is 
already at 3.5GB (more on that later), and if current pace holds, they'll have 
the 
same problem Ubuntu Studio has now in two years. In fact, Ubuntu Desktop isn't 
far 
behind at 3.3GB, meaning this is going to become a problem for *everyone* 
sooner 
rather than later. 

Basically, the ISO 9660 limitation can no longer be ignored and we need to find 
a 
new solution, not in the future, but *now*. When one flavor suffers, we all 
suffer, 
regardless of commercial support.

The table below shows the official flavors and their corresponding image size 
as of 
this writing, from smallest to largest:

Xubuntu: 1.9GB
Lubuntu: 2.4GB
Ubuntu Budgie:   2.7GB
Ubuntu MATE: 2.8GB
Ubuntu (GNOME):  3.3GB
Kubuntu: 3.5GB
Ubuntu Kylin:3.9+GB (shows as oversized)
Ubuntu Studio:   4.0+GB (shows as oversized)

You can see that KDE Plasma (Kubuntu) is taking up so much space that it's 
leaving 
us with very few tools to put on the image. This wasn't a huge problem at 
first, but 
as soon as we seeded the Firefox Snap it became a reality, taking a whopping 
156MB *compressed space*, meaning that's about how much room it takes in the 
squashfs, if not more. If the trend continues and more apps become snaps, we 
can 
only expect this to grow, meaning the ISO 9660 standard is no longer a viable 
option for anyone.

For the Ubuntu Studio team, if the above requests cannot be accommodated (or 
won't be because nobody cares about Studio), then we have to look at perhaps 
switching DE *again*. 

Another option I'm looking at, which wouldn't work for 22.04 LTS as it's just 
too late, 
is making a welcome application that people can install the metapackages that 
they 
need for their particular workflows while still keeping the Studio 
optimizations that 
make us Studio (lowlatency kernel, etc). However, I've spent several evenings 
going 
through the seed trying to trim excess, and I am just out of excess to trim.

Thoughts? We need answers, and fast. Beta freeze is Monday, and we're running 
out of time.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


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

[ubuntu-studio-devel] Ubuntu Studio: We're out of space

[Erich Eickmeyer]

Hi everyone,

Two years ago, at Ubuntu Studio,we decided switch our default desktop 
environment to KDE Plasma. Unfortunately, that is coming back to bite us.

At the time, it seemed like a good idea, as both Plasma and Xfce were around 
the 
same size in disk space, and we also decided, Ubuntu Studio isn't tied to its 
desktop 
environment.

The problem that I'm seeing is that the ISO 9660 spec, the standard on which 
all of 
our ISO images are built, has a hard limit of 4096MB per file size. In our 
case, the 
squashfs file size is exceeding that. This is resulting in failed builds. 

HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@, there is 
another ISO format that works for DVD: ISO 13346, aka UDF. This allows for a 
virtually unlimited filesize, although I've seen anecdotal mentions of 1024GB 
(1TB). 
This would be preferable, and on behalf of Ubuntu Studio, we request this 
switch if 
able, or even an alternative. I realize this is short notice prior to beta, but 
we don't 
have much choice as the amount I'm having to remove is basically nullifying 
Ubuntu 
Studio's reason to exist in that we're having to severely limit the amount of 
tools we 
can carry. It seems that Ubuntu Kylin shares our plight.

To emphasize this note, the squashfs file size is only going to get larger. 
Kubuntu is 
already at 3.5GB (more on that later), and if current pace holds, they'll have 
the 
same problem Ubuntu Studio has now in two years. In fact, Ubuntu Desktop isn't 
far 
behind at 3.3GB, meaning this is going to become a problem for *everyone* 
sooner 
rather than later. 

Basically, the ISO 9660 limitation can no longer be ignored and we need to find 
a 
new solution, not in the future, but *now*. When one flavor suffers, we all 
suffer, 
regardless of commercial support.

The table below shows the official flavors and their corresponding image size 
as of 
this writing, from smallest to largest:

Xubuntu: 1.9GB
Lubuntu: 2.4GB
Ubuntu Budgie:   2.7GB
Ubuntu MATE: 2.8GB
Ubuntu (GNOME):  3.3GB
Kubuntu: 3.5GB
Ubuntu Kylin:3.9+GB (shows as oversized)
Ubuntu Studio:   4.0+GB (shows as oversized)

You can see that KDE Plasma (Kubuntu) is taking up so much space that it's 
leaving 
us with very few tools to put on the image. This wasn't a huge problem at 
first, but 
as soon as we seeded the Firefox Snap it became a reality, taking a whopping 
156MB *compressed space*, meaning that's about how much room it takes in the 
squashfs, if not more. If the trend continues and more apps become snaps, we 
can 
only expect this to grow, meaning the ISO 9660 standard is no longer a viable 
option for anyone.

For the Ubuntu Studio team, if the above requests cannot be accommodated (or 
won't be because nobody cares about Studio), then we have to look at perhaps 
switching DE *again*. 

Another option I'm looking at, which wouldn't work for 22.04 LTS as it's just 
too late, 
is making a welcome application that people can install the metapackages that 
they 
need for their particular workflows while still keeping the Studio 
optimizations that 
make us Studio (lowlatency kernel, etc). However, I've spent several evenings 
going 
through the seed trying to trim excess, and I am just out of excess to trim.

Thoughts? We need answers, and fast. Beta freeze is Monday, and we're running 
out of time.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


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] New Logo

[Erich Eickmeyer]

Hi all,

As many of you know, Ubuntu has revealed a logo revamp[1]. Since we are a part 
of 
Ubuntu (not a separate distribution as some assume on first glance), it seemed 
to 
be time for us to follow suit. It's not mandatory, but stylistically it makes 
sense to be 
on the same page as to not fall behind.

As such, I requested the .svg source files from Canonical and was able to get 
my 
hands on them. Using the same styles and fonts, I was able to come up with the 
"tag" and two variations of the wordmark with the tag that you can see in the 
attached PDF. Both variations with the wordmark are based on how Canonical will 
be styling the Canonical logo going forward, as they are doing away with the 
aubergine circle and going with the Ubuntu logo, labeled as "Canonical Ubuntu" 
in 
their wordmark. So, I'm simply following that pattern.

I don't know which of the other official flavors will be following suit, but 
all of this 
happened sometime in 2010-2012 before. I guess this might be a way of setting 
the 
example, but we'll see.

Also, I know many of you won't be a fan of this, but the way I see it is 
keeping 
aligned with the umbrella branding as to keep with the "Ubuntu" name which we 
remain a part of.

Thanks everyone!
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


[1] https://ubuntu.com/blog/a-new-look-for-the-circle-of-friends


UbuntuStudio_2022_Logos.pdf
Description: Adobe PDF document


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

/boot disk partition size

[Erich Eickmeyer]

Hi all,

Many of you know me as the leader of Ubuntu Studio and member of the Ubuntu 
Community Council. However, in my day job, I'm the User Experience and 
Packaging director for the Kubuntu Focus project.

For those of you unfamiliar, Kubuntu Focus is a line of laptop computers that 
come with Kubuntu preinstalled. This makes us an OEM for Kubuntu, and Ubuntu 
by extension. 

With that in mind, I work for Michael Mikowski in this regard. He's a highly 
experienced developer and system administrator, but is not currently an Ubuntu 
member or Ubuntu developer and cannot post on this list, which is why I'm 
acting as an intermediary with both my Ubuntu developer and Kubuntu Focus hats 
on.

With that in mind, please read the forwarded message below to understand the 
context for this. Please respond to this message not only to the mailing list, 
but to mmikow...@kfocus.org as well.

Thanks,
Erich
-
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

-- Forwarded message -
From: Michael Mikowski 
Date: Thu, Feb 10, 2022, 18:38
Subject: /boot disk partition size
To: 


Hi Everyone:

Members of the Ubuntu Foundations Team asked me to clarify the issue with /
boot. You can see the bugs filed at https://launchpad.net/bugs/1959971 and
https://launchpad.net/bugs/1960089. *Personal Background:*
I currently lead the Kubuntu Focus <https://kfocus.org> engineering
efforts, and have been a professional product engineer specializing in
mission-critical HP/HA/HV systems for decades. You can see a overview of my
experience at https://michaelmikowski.com.

*My Assessments:*

*0. This is a low-cost, high-return proposal.* People have pushed back
against increasing the /boot partition, but I find most of the reasoning
does not consider the true impact of a small /boot partition to the
complete product.

*1. The cost to provide the space needed is minimal for almost all FDE
systems. *So why not just do it? Of course, there is more work to be done
for the rest of the product (guide users on kernel selection; improve the
kernel cleaning logic), but this is an important component that is required
in any complete solution. It would provide substantial relief to many users
immediately.

*2. An overfull /boot partition is catastrophic for many users.* Many
cannot recover their system because they don't have a rescue disk or
knowledge of ext4, chroot, LUKS, lvm, cryptesetup, package management, and
more. These people either reload the OS or give up.

*3. This happens frequently, even when everything works as designed*, and
even when just using a single kernel flavor. While on IRC yesterday
discussing this, 3 unsolicited individuals stepped in to comment about how
this is needed. And those are advanced developers who know better. Search
for 'ubuntu full /boot partition' and check out how frequently this
continues to occur.

*4. There are many use cases where multiple kernel flavors will occur*,
such as when the users switches from HWE to OEM to address hardware issues,
or they install lowlatency for studio work. When this happens, the current
size boot partition is highly likely to fill. This can corrupt the system
and require a rescue disk for recovery.

Check out the DFMEA which is used to assess the severity of a failure mode:
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1959971/comments/7

Finally, I assure you the calculations for kernel boot-file-set sizes (180M
with Nvidia GPU) are correct for 20.04, and will be correct for 22.04
unless the compression technique has been changed. It seems perfectly
reasonable to expect this size to grow to 200M or more over the next 2
years. Also, the headroom + safety factor specified (10 kernel file-sets
total) is reasonable when you consider that systems that reboot less
frequently will accumulate kernels and that a single upgrade can install
multiple additional kernel images.

Sincerely, Mike


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

[ubuntu-studio-devel] Thoughts for 22.04 "Jammy Jellyfish"

[Erich Eickmeyer]

Hi everyone!


It's been a wild two years. We've done quite a bit to get to where we are now, 
and we only 
continue to grow both in popularity and in the team! Granted, it's mostly Len 
and myself 
on a day-to-day basis, but we seem to be getting more and more help, and this 
past go-
around with 21.10 that was in testing. I'm so glad to see so much participation!


As I look to 22.04 and the challenges that has taken place in the past, I've 
been 
considering a few thoughts, primarily having to do with our ISO size, which is 
coming 
close to exceeding the technical limits. In fact, we even had to cut some stuff 
from this 
past release.


With that, I'm going to look into things we can do to mitigate that going 
forward, and I'm 
starting with our default theming and wallpaper.


 *  Wallpaper can go back to JPG. I remember a couple years ago we went to 
PNG by 
default, but this is now hurting us. On this note, I'd like to hold a new 
wallpaper contest 
for this cycle.
 *  We should make a new default wallpaper. If Eylul doesn't see this, I'll 
reach out to her 
via Telegram to see if she'd like to take the reigns on this one
 *  We currently bring in another theme for our default theme: Materia with 
the Papirus 
icons. I've been playing around with rebasing onto KDE's default Breeze with a 
different 
color scheme and continuing with the Papirus icons. I like the results I'm 
seeing so far. The 
reason for the different color scheme is twofold: 
 1. Identity separate from Kubuntu
 2. The default Breeze colors are on the cool side and not good for 
photography or 
video production since they can fool the eye.
 *  Based on that, I have found a color scheme based on Adwaita 
(default GNOME 
colors) that is very neutral. I plan on incorporating that, and so far the 
results have been 
very nice.
 *  Rebasing on Breeze will also remove the need for Kvantum and 
that overhead, 
bringing us in-line with the default Plasma/Kwin theming engines.
 *  I plan on auditing our reverse dependencies for items we're 
still bringing-in that 
don't need to be there. It was discovered that we were still depending on an 
Xfce library, 
which we removed, and you will notice that the Elementary icons are still 
installed by 
default despite moving to Papirus over two years ago.


If any of you can think of some default-installed applications that we don't 
really need as 
their function is duplicated elsewhere, I'd love to know.


Also, we will be moving forward with removing "Publishing". For those worried 
about 
Musescore, that will not be removed as it's still part of the audio/music 
category/
metapackage.


Thanks, everyone! I think 22.04 will turn out to be a great LTS release.


-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council


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 21.10 Released

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio
21.10, code-named “Impish Indri”. This marks Ubuntu Studio’s 30th release.
This release is a regular release, and as such it is supported for nine
months until July 2022.

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
<https://ubuntustudio.org/ubuntu-studio-21-10-release-notes/> for a
complete list of changes and known issues.

You can download Ubuntu Studio 21.10 from our download page
<https://ubuntustudio.org/download>.

If you find Ubuntu Studio useful, please consider making a contribution.
<https://ubuntustudio.org/contribute/>
Upgrading

Due to the change in desktop environment that started after the release of
20.04 LTS, direct upgrades from supported releases prior to 21.04 are not
supported.

We have had anecdotal reports of successful upgrades from 20.04 LTS (Xfce
desktop) to later releases (Plasma desktop), but this will remain at your
own risk.

Instructions for upgrading are included in the release notes
<https://ubuntustudio.org/ubuntu-studio-21-10-release-notes/>.
New This Release

This release includes Plasma 5.22.5, the full-featured desktop environment
made by KDE. The theming uses the Materia theme and icons are Papirus icons.
Audio

Studio Controls has seen further development as its own independent project
and has been updated to version 2.2.7. This version has an all-new layout
and features, including JACK over network and MIDI over network.
Ardour 6.9

Ardour has been updated to version 6.9 and includes a ton of bugfixes and
enhancements. For more information, check out the official release
announcement <https://ardour.org/whatsnew.html>.
Other Notable Updates

Carla has been upgraded to version 2.4.0 Full release announcement at
kx.studio.
<https://kx.studio/News/?action=view=carla-plugin-host-v240-is-here>
Video
OBS Studio

Included this cycle is OBS Studio 27.0.1, which includes support for the
upcoming (currently experimental) Wayland compositor via PipeWire. More
information at the official release announcement.
<https://obsproject.com/blog/obs-studio-27-released>

For those that would like to use the advanced audio processing power of
JACK with OBS Studio, OBS Studio is JACK-aware!
More Updates

There are many more updates not covered here but are mentioned in the
Release Notes. We highly recommend reading those release notes so you know
what has been updated and know any known issues that you may encounter.
Get Involved!

A great way to contribute is to get involved with the project directly!
We’re always looking for new volunteers to help with packaging,
documentation, tutorials, user support, and MORE! Check out all the ways
you can contribute! <https://ubuntustudio.org/contribute/>
Special Thanks

Huge special thanks for this release go to:

   - Len Ovens: Studio Controls, Ubuntu Studio Installer, Coding
   - Thomas Ward: Packaging, Ubuntu Core Developer for Ubuntu Studio
   - Eylul Dogruel: Artwork, Graphics Design, Website Lead
   - Ross Gammon: Upstream Debian Developer, Guidance, Testing
   - Sebastien Ramacher: Upstream Debian Developer
   - Dennis Braun: Debian Package Maintainer
   - Rik Mills: Kubuntu Council Member, help with Plasma desktop
   - Mauro Gaspari: Tutorials, Promotion, and Documentation, Testing
   - Brian Hechinger: Testing and bug reporting
   - Chris Erswell: Testing and bug reporting
   - Robert Van Den Berg: Testing and bug reporting, IRC Support
   - Krytarik Raido: IRC Moderator, Mailing List Moderator
   - Erich Eickmeyer: Project Leader, Packaging, Direction, Treasurer
-- 
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] Full ISO and some proposals

[Erich Eickmeyer]

On Thursday, September 30, 2021 10:38:27 AM PDT Ross Gammon wrote:
> Sounds like a good plan to me!
>
> [snip]
>
> This change will probably mean matching changes in the installer graphics 
and project website.

To be fair, that's relatively trivial. :) The designers of our new website 
theme made that almost a no-brainer, and removing the graphics from calamares 
is pretty simple as well. We've got time, this wouldn't take effect until 22.04 
anyhow.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] Full ISO and some proposals

[Erich Eickmeyer]

Hi all,

We hit a limit. Apparently, between Sunday the 26th and Monday the 27th, the 
squashfs hit the technical limit of 4.0GB on our ISO image. Per ISO 9660, this 
is a hard limit as the file system is incapable of having a single file more 
than 4GB in size (the squashfs acts as a single file on the root of the ISO). 
Unfortunately, this means we need to take a hard look at what we preinstall by 
default and start eliminating some items.

As an emergency, I went ahead and removed a few duplicate items and one fairly 
large item, but it opened my eyes to a bigger picture issue. More on that 
later.

In terms of deduplicating functionality, I removed jackd (not jackd2) since 
you can only have one anyhow. Also, I removed lmms which, in mine and Len's 
opinion, is an application that is stuck in the past using the older ladpsa 
(LV1) plugins and refuses to get any update. This is in favor of Ardour as our 
DAW of choice.

Other items:

 * Switched from ksysguard to the new plasma-systemmonitor for the desktop
 * Removed raysession in favor of agordejo and new-session-manager combined, 
which provides the same functionality with more backend support.
 * Removed simple-scan in favor of skanlite (a KDE scanner app)

However, this is just a bandaid.

My proposal is that we drop publishing as a category of apps that we install 
beginning with 22.04. My reasoning is that we're not very well-known for being 
a desktop publishing platform, and it blurs the line between "studio" and 
general-purpose. Moreover, people doing desktop publishing aren't exactly 
looking at Ubuntu Studio as we rarely see any questions about it. In fact, 
when people are reviewing Studio, they're a little surprised and perplexed to 
see such tools.

Len pointed out that while we could remove the publishing items, he feared 
that items in the graphics category would get removed. I assured him  that 
this is not the case; that while there's some overlap, removing the publishing 
meta would not remove any graphics items since the graphics meta still pullse 
those items in.

Removing the publishing meta would remove the following from the ISO:

 * scribus
 * calibre
 * pdfshuffler
 * plume-creator

I know this doesn't sound like much, but I think it would be good to save some 
space and no longer support desktop publishing as a category of items we 
install by default.

Let me know what you think.
Erich

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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] Fwd: Organic Ubuntu Studio t-shirt

[Erich Eickmeyer]

Hey everyone,

For those of you who are actively contributing to this project, HelloTux wants 
to sell us some Organic Cotton T-Shirts. See the forwarded message below.

Quantities are limited, so Gabor wanted to make sure we got first crack at 
them.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

--  Forwarded Message  --

Subject: Organic Ubuntu Studio t-shirt
Date: Thursday, July 29, 2021, 10:36:09 AM PDT
From: Gabor Kum 
To: Erich Eickmeyer 

Hello,

We received a lot of emails asking when will we make organic cotton 
t-shirts. I decided to make some with Ubuntu Studio embroidered on them 
for ourselves and for our mailing list subscribers.

This is not something we should announce on the website or on the social 
channels, but if you (or any project member) want one or two from them, 
we can arrange it. They are made on-demand, as this is not a permanent 
offer. We plan to collect orders until next Tuesday (03-08-2021), and 
ship them on the beginning of the next week.

You can find them here, but they are not available from the Ubuntu 
Studio category of our website: 
https://www.hellotux.com/ubuntu_studio_organic_tshirt

Please check the sizing twice! They are a smaller sizing than our usual 
Ubuntu Studio t-shirts! (This is one of the reasons why they are not 
announced publicly.)

-- 
Best regards,

Gabor KUM
owner of HELLOTUX
https://www.hellotux.com


-


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 Education [Was, Re: Proposal: sunset the backports pockets]

[Erich Eickmeyer]

Hi Steve,

On Tuesday, July 20, 2021 8:20:33 AM PDT Steve Langasek wrote:
> Hi Erich,
> 
> This seems largely orthogonal to the point of the thread, but I think it
> warrants a response.

Yes, wasn't the point I was trying to make, but I can definitely speak to this 
a little.

> On Mon, Jul 19, 2021 at 10:18:36AM -0700, Erich Eickmeyer wrote:
> > Additionally, sunsetting things like this are sure ways to permanently
> > kill
> > them. I look at Edubuntu as a prime example: it was sunset, and those that
> > have wished to revive it have been denied that simply because "it died
> > before, what's to prevent that from happening again?".
> 
> With both my Technical Board and Release Team hats, I am entirely unaware of
> any efforts to resurrect Edubuntu.  So, who was wishing to revive it, and
> who dissuaded them?

Me. Before I got involved with Ubuntu Studio, even though Studio was a better 
fit for myself personally, I saw Edubuntu dying a very painful death. I was 
looking out for my son, 4 years old at the time and needing an educational 
desktop that fit well for someone like him. I reached out to the flavor leads 
about how to take over and was ultimately stonewalled without a response.

> That said, when talking about an official flavor, which implies an ongoing
> resource committment from the larger Ubuntu developer community (i.e. the
> Release Team), it's entirely appropriate to ask questions about the level of
> committment from those proposing the flavor.
> 
> > Somebody made an "Ubuntu Education Remix" because they felt they could
> > never revive Edubuntu because they'd be denied that ability.
> 
> Well, in order to be able to call itself an Ubuntu remix, it must be using
> software only from the Ubuntu archive.  When I google for this and download
> the iso, inspecting it shows that it hasn't enabled any archives aside from
> Ubuntu... but the customizations to the live environment (which are
> primarily branding) are done by modifying the contents of the squashfs
> directly, with no packaging associated with it.  And there is very little
> educational software I can see having been added (the only thing I managed
> to work out from the package list was epoptes-client).  There is an
> interesting mix of package selection, with ubuntu-unity-desktop as the only
> metapackage installed but packages preinstalled from a wide number of the
> different desktop flavors of Ubuntu.  I'm sorry to say I don't see much here
> that looks like the seed for a revived Edubuntu.

I got the name wrong, he called it UbuntuEd.

https://discourse.ubuntu.com/t/ubuntu-education-ubuntued/17063

Rudra Sawant was trying to resurrect it. I had some discussions with him in 
one of the IRC channels about it (I don't remember exactly which or when 
otherwise I'd link the conversation), maybe turning it into Edubuntu, but he 
felt as though he'd get into trouble by trying to do that, mostly from 
trademark standpoints (already using Ubuntu in the name would potentially do 
that). I assured him that it wasn't the case. Apparently nothing has come of 
it, but my whole point was that it seemed like, at the time, people wanted it 
to die. 

Of course, after Edubuntu's demise, that left Ubuntu Studio as the only 
existing flavor that does not depend on a desktop environment for its 
definition, meaning it's the last of its kind. I'm glad I saved it from certain 
death and it's now thriving. Even then, I was discouraged from leading it and 
getting it going again, mostly from people outside of Ubuntu.

However, the example was to show that it's hard to resurrect a project in 
Ubuntu once it's completely dead. I see that potentially happening in 
Backports, but it looks as though Dan Streetman and the SEG are going to be 
taking over, so, while my objections are contested, it seems as though it's 
moot since the backports pocket will have life.

That said, it would be nice to see if we could lower the bar, at least from a 
perceptual standpoint, for people wishing to contribute in such a way. Early 
on, I saw the bar as unattainable, and I, in some ways, still feel as though 
there is a certain amount of gatekeeping which, no matter how well-
intentioned, is detrimental to Ubuntu as a whole when it comes to attracting 
new contributors who simply need to learn. Maybe it's a lack of willing 
mentorship or a feeling of inadequacy to mentor for some, but the perceptual 
bar for contribution is fairly high, and that does need to be fixed.

Of course, that's fairly orthagonal to this discussion altogether.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Proposal: sunset the backports pockets

[Erich Eickmeyer]

Hi Robie,

On Monday, July 19, 2021 10:56:39 AM PDT Robie Basak wrote:
> Hi Erich,
> 
> On Mon, Jul 19, 2021 at 10:18:36AM -0700, Erich Eickmeyer wrote:
> > TL;DR: Don't sunset the backports, but reform the process.
> 
> Ubuntu is a meritocracy. We invite anybody, from any company, to
> participate in any aspect of the project.
> 
> I would be happy to see the backports process stay, with reform that
> actually works. Like you, I would prefer that, so in that sense, I
> completely agree with you.
> 
> However, somebody needs to drive that reform. Nobody has. The last time
> the topic of reform came up, nobody apart from me bothered to respond to
> the thread.
> 
> There are many people making many suggestions in this thread now, but
> still so far, nobody has volunteered. I don't think that anybody has
> disagreed that the current situation is actively damaging to our
> community.
> 
> *Given that* nobody is stepping up to reform the process, I think that
> sunsetting the process is the least worst option. It might be a
> difficult, unwelcome decision, but it is one that needs to be made.
> 
> I appreciate the points you're making. However, unless you (or somebody
> else qualified) are actively volunteering to step in and drive the
> reform, I cannot give your position much weight. Because how can I,
> knowing that nobody volunteering means that the current harmful
> situation will continue? To me, when you say you want reform, I hear
> that the status quo will continue because nobody will step up to drive
> that reform, and for me that is unacceptable.
> 
> Please don't block an improvement by requesting work that nobody is
> volunteering to do.

When was the last time this was brought up? I don't remember seeing anything 
on any public mailing lists, discourse, the fridge, Planet Ubuntu, or even 
Ubuntu Weekly News about this. This tells me that it was never brought-up 
publicly, aka no call for volunteers. If that's the case, then that's the 
failure, not people like me saying it's a bad idea.

I would 100% volunteer if it aligned with my day job, which it might, but I 
cannot make any promises at this time. It also aligns with my position as a 
flavor lead since Ubuntu Studio currently maintains its own backports 
repository via a PPA, which is not an ideal situation, but it kindof works and 
it beats jumping through hoops to get anything into the official backports repo.

What I'm saying is that you might be posting to these mailing lists, but 
that's not *public enough* to get the attention this needs to drum-up qualified 
volunteers. Not everybody who is qualified is subscribed to these lists.

So, yes, I will block a so-called "improvement" when it comes down to quitting 
vs exhausting all other options, because, in my opinion, quitting is not an 
option.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Proposal: sunset the backports pockets

[Erich Eickmeyer]

Hi Robie,

On Monday, July 19, 2021 5:05:49 AM PDT Robie Basak wrote:
> Dear Ubuntu Developers,
> 
> As far as I am aware, the Ubuntu Backports Team has been inactive for
> years now, and backports requests and uploads just languish in
> Launchpad. Thomas Ward last proposed an effort to revitalise it over two
> years ago, but with no response. I believe he's no longer available to
> contribute now.
> 
> My concern is that the backports documentation and process still exist,
> so users and contributors are being misled into thinking that something
> will happen, when it won't.
> 
> I would be very happy for the backports process to continue, but I think
> it's time to accept that it isn't happening, call a spade a spade, and
> shut the process down and document this properly to stop misleading
> users about it.
> 
> For example, I just handled LP: #1902198 having received an out-of-band
> ping, and looking at https://bugs.launchpad.net/focal-backports there
> are multiple recent requests that we know are not going to be answered
> from a backports pocket perspective.
> 
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.
> 
> Robie

I'm throwing my Flavor Lead hat on for this one.

I hate this idea.

The Backports have historically been a very difficult process, so difficult 
that 
at least two flavors (Ubuntu Studio and Kubuntu) have created their own 
backport process and a PPA for those who wish to opt-in. In my opinion, this 
should never have been necessary and those flavors should have had a better way 
to backport. These things don't happen because people are unable to follow the 
process, but because the process is a bottleneck.

Bottlenecks and restrictions are great way to make ideas die because those 
that would use it get fed-up with the extremely high bar that must be met in 
order to do anything. 

Additionally, sunsetting things like this are sure ways to permanently kill 
them. I look at Edubuntu as a prime example: it was sunset, and those that 
have wished to revive it have been denied that simply because "it died before, 
what's to prevent that from happening again?". Somebody made an "Ubuntu 
Education Remix" because they felt they could never revive Edubuntu because 
they'd be denied that ability.

With that, I'd rather see the Backports reformed, not sunset. As with any 
process, if it's not working then perhaps the problem is in the process not 
the idea. Throwing away a good idea because it's not working now is just 
giving up, aka quitting. I was raised never to give up. I didn't give up on 
Ubuntu Studio, and now it's thriving. I believe giving up on Backports would 
be a mistake.

Now, with my OEM (Kubuntu Focus, aka my day job) hat on:

I still hate this idea.

At Kubuntu Focus, we rely on the LTS because those in the scientific and 
artificial intelligence communities rely on packages in external repositories 
that are only made for the LTS. It is astoundingly frustrating when we get 
support tickets asking why XYZ isn't in Ubuntu when a newer version of the 
software that includes a feature they need isn't available to them without 
going to an unsupported repository. That's bad customer service and makes us 
(Kubuntu Focus AND Ubuntu) look bad, because now we're scrambling to provide a 
software solution for a customer rather than just having it for them.

Now, with my Community Council hat on:

How much of the community was aware there even is a backports process? I'd say 
very, very few. To me, that means somebody (I don't know who) dropped the ball 
in the community management aspect of this. As somebody who has a degree in 
this very thing, I find that unacceptable on many levels.

All of that to come to this:

Do not do this. That's basically "thowing the baby out with the bathwater." 
Instead, reform the process. Make the bar a little lower. Instead of 
bottlenecking the process, maybe allow people to actually backport. Not with 
direct repository access, but by lowering the bar in the process. The backport 
process, as it stands, it very, very restrictive. In some ways, it's more 
restrictive than an SRU, which seems backwards to me.


TL;DR: Don't sunset the backports, but reform the process.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Re: Question to flavors: touch-base on flavor participation for 21.10!

[Erich Eickmeyer]

On Friday, May 14, 2021 2:57:25 AM PDT Lukasz Zemczak wrote:
> Hello flavors!
> 
> As we do around the start of every new cycle, I am reaching out to all
> the current official Ubuntu flavors to confirm active participation in
> the upcoming Ubuntu release - 21.10.
> 
> Working towards a release requires a lot of effort, so we'd like to
> make sure all the flavors are ready, properly staffed and have enough
> time allocated to make 21.10 happen for their users. This is why,
> similarly to last year, I will need a confirmation follow-up message
> about impish participation from every flavor, that is:
> 
>  * Kubuntu
>  * Xubuntu
>  * Ubuntu Studio
>  * Lubuntu
>  * Ubuntu Kylin
>  * Ubuntu MATE
>  * Ubuntu Budgie
> 
> If you have any concerns regarding your participation, feel free to
> reach out to me or anyone else from the ubuntu-release team.
> 
> Thank you!
> 
> Cheers,

Studio is still alive and well, having recovered very well from its near-death 
experience. :)

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

Ubuntu Studio 18.04 Extended Support ends

[Erich Eickmeyer]

When Ubuntu Studio 18.04 was released, it was determined that it should not be 
a Long-Term Support release due to the lack of team and experience of new 
people adding to the project. As such, support ended in January 2019.

However, the new team created an Ubuntu Studio Backports PPA to attempt to 
help with at least some support for the 18.04 release, which was based on 
Ubuntu 18.04 LTS. With that, we gave those who relied on 18.04 a life boat 
until 20.04 LTS could be released, which happened just over a year ago. At 
that time, users of 18.04 were encouraged to upgrade, and packages for 18.04 
in the Ubuntu Studio Backports PPA were frozen.

As of today, all 18.04 packages in the Ubuntu Studio Backports PPA have been 
removed. If you have not done so, please upgrade to 20.04 LTS as soon as 
possible.

-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

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

[ubuntu-studio-devel] Ubuntu Studio 21.04 Released!

[Erich Eickmeyer]

The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio
21.04, code-named “Hirsute Hippo”. This marks Ubuntu Studio’s 29th release.
This release is a regular release, and as such it is supported for nine
months until January 2022.

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
<https://ubuntustudio.org/21-04-release-notes> for a complete list of
changes and known issues.

You can download Ubuntu Studio 20.04 from our download page
<https://ubuntustudio.org/download>.

If you find Ubuntu Studio useful, please consider making a contribution.
<https://ubuntustudio.org/contribute/>
Upgrading

Due to the change in desktop environment this release, direct upgrades from
release prior to 20.10 are not supported.

In the coming weeks, you should see a prompt to upgrade from 20.10 during
your regular updates. If you wish to update at that time, click “Install
Upgrade”.
New This Release

This release includes Plasma 5.21.4, the full-featured desktop environment
made by KDE. The theming uses the Materia theme and icons are Papirus icons.
Audio

Studio Controls has seen further development as its own independent project
and has been updated to verison 2.1.4.
Ardour 6.6+ (Future 6.7 Snapshot)

Ardour has been updated to version 6.6+, meaning this is a git snapshot of
what will eventually be Ardour 6.7. This had to be done because Ardour 6.5
started to fail to build with a newer library introduced into the Ubuntu
archives, and could only be resolved with this snapshot. We hope to have
Ardour 6.7 in via official updates once released.
New Application: Agordejo

Agordejo is new to Ubuntu Studio this release. It was brought-in for those
unsatisfied with RaySession’s audio session management but found New
Session Manager’s interface to be too old and clunky. Agordejo comes in and
provides the best of both worlds: Legacy NSM compatibility and advanced
session management for your audio sessions.
Other Notable Updates

Carla has been upgraded to version 2.3. Full release announcement at
kx.studio.
<https://kx.studio/News/?action=view=carla-plugin-host-v23-is-here>
VideoOBS Studio

Included this cycle is OBS Studio 26.1.2, which includes the ability to use
OBS as a virtual webcam in another application! (requires administrative
access to machine to create loopback device)

For those that would like to use the advanced audio processing power of
JACK with OBS Studio, OBS Studio is JACK-aware!
More Updates

There are many more updates not covered here but are mentioned in the
Release Notes. We highly recommend reading those release notes so you know
what has been updated and know any known issues that you may encounter.
Get Involved!

A great way to contribute is to get involved with the project directly!
We’re always looking for new volunteers to help with packaging,
documentation, tutorials, user support, and MORE! Check out all the ways
you can contribute! <https://ubuntustudio.org/contribute/>
Special Thanks

Huge special thanks for this release go to:

   - Len Ovens: Studio Controls, Ubuntu Studio Installer, Coding
   - Thomas Ward: Packaging, Ubuntu Core Developer for Ubuntu Studio
   - Eylul Dogruel: Artwork, Graphics Design, Website Lead
   - Ross Gammon: Upstream Debian Developer, Guidance, Testing
   - Dennis Braun: Debian Package Maintainer
   - Rik Mills: Kubuntu Council Member, help with Plasma desktop
   - Mauro Gaspari: Tutorials, Promotion, and Documentation, Testing
   - Krytarik Raido: IRC Moderator, Mailing List Moderator
   - Erich Eickmeyer: Project Leader, Packaging, Direction, Treasurer
-- 
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] Big thanks to Dennis Braun and Ross Gammon!

[Erich Eickmeyer]

Hi Ross and Dennis,

I just wanted to thank you both for taking some packages I had downstream in 
Ubuntu and upstreaming them to Debian. Dennis, you've been doing some great 
work, and for that I'm thankful!

I most recently saw dragonfly-reverb making its way into sid, and when the 
build was complete I did a quick syncpackage. Of course, the very next day 
(today), dragonfly-reverb 3.2.4 was released (looks like a fairly trivial 
bugfix), so now the package is a wee bit out of date. :)

Anyhow, I've also noticed numerous other packages (dpf-plugins, among others). 
Since I got a job working on the Kubuntu Focus laptop, these packages getting 
upstreamed reduces my maintenance workload on Ubuntu Studio.  Granted, after 
Debian Import Freeze the workload is slightly higher, but every little bit 
that you're doing helps.

Dennis, I'd love to include you as part of the Ubuntu Studio team since your 
work is directly affecting Ubuntu Studio. What do you think?

And big thanks to Ross for being the amazing DD and sponsoring these packages. 
You do amazing with supporting Ubuntu Studio from the Debian side, and I'm 
glad you're on the team.

As you both probably know, there are numerous other packages which could stand 
to be upstreamed as well. If you see anything that is Ubuntu-only, feel free 
to take it on.

Again, thank you both. Also CC'd the ubuntu-studio-devel mailing list so that 
others could see the work that you're doing. :)
-- 
Erich Eickmeyer
Project Leader, Ubuntu Studio
Council Member, Ubuntu Community Council

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: Call for testing: ubiquity-based 20.04.2.0 desktop image respins

[Erich Eickmeyer]

Hi Lukasz,

I'm 100% certain Ubuntu Studio should also be affected as we weren't using 
Calamares until 20.10.

Also, for some reason, the test cases for 20.04.2 weren't lining up with that 
and had taken-on the Calamares workflow, which would be in error.

Sorry if this adds more work, but this is definitely an oversight. :)

Thanks,
Erich

On Wednesday, February 10, 2021 3:53:21 AM PST Lukasz Zemczak wrote:
> Hello everyone,
> 
> As some of you know, shortly after release of 20.04.2 a regression in
> the ubiquity installer was discovered [1], leading to certain systems
> failing to install the Linux kernel (when the connected to the
> internet during the installation), resulting in unbootable systems.
> The issue was found to be in the OEM-archive handling.
> 
> We think we have fixed the issue and, since this is a rather serious
> issue, decided to re-spin all the affected ubiquity-based desktop
> flavors. The images are now available on the ISO tracker's 20.04.2.0
> milestone:
> http://iso.qa.ubuntu.com/qatracker/milestones/421/builds
> 
> We'd appreciate the usual help with testing of the images.
> 
> As we have not anticipated a re-spin and the focal-updates gates were
> open for a day, there are a few additional changes besides the new
> ubiquity package, so please keep that in mind. The manifest diffs
> (showing which packages have been upgraded between .2 and .2.0) are
> available here:
> 
>  * Ubuntu: https://paste.ubuntu.com/p/KyTyYddqgm/
>  * Kubuntu: https://paste.ubuntu.com/p/F2FNJPSKdy/
>  * Ubuntu Kylin: https://paste.ubuntu.com/p/THNn5RZ3zp/
>  * Ubuntu Mate: https://paste.ubuntu.com/p/C2gn5dgj4D/
>  * Xubuntu: https://paste.ubuntu.com/p/y3gtPQ87jS/
> 
> Thank you!
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1915114



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

Re: [ubuntu-studio-devel] ardour backport ppa for 20.10

[Erich Eickmeyer]

Hi Wouter,

The main Ubuntu Studio Backports PPA has Ardour 6.5 for 20.10. This extra PPA 
was meant only for users of 20.04 LTS since it comes with Ardour 5.12.

Thanks,
Erich
--
Erich Eickmeyer
Project Leader
Ubuntu Studio


On Tuesday, February 9, 2021 2:14:52 PM PST you wrote:
> Hello,
> 
> I am not sure if this a suitable place to ask this, if not I am very
> sorry to have bothered you.
> 
> I am contacting you because I saw that you are a maintainer of the
> Ardour Backports PPA, as you were mentioned as the uploader for the
> latest release. I was wondering if it would be possible to make this PPA
> also available for ubuntu studio 20.10.
> 
> I noticed that on my ubuntu studio 20.10 install the latest Ardour
> version now is 6.3 while on a ubuntu 20.04 install, I am able to use the
> backport PPA to get version 6.5, which has VST3 plugin support. So if it
> would not be too much effort (I don't know what goes into this), I think
> it might be nice to make the PPA also available for 20.10 to ensure that
> you can use the latest version of Ardour on 20.10.
> 
> Thanks for the work you do on Ubuntu Studio, I enjoy using the software
> a lot.
> 
> Wouter Koenders



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] Fwd: Call for testing: 20.04.2 release candidate images ready!

[Erich Eickmeyer]

FYI all, this is for Focal (Xfce Desktop)

--  Forwarded Message  --

Subject: Call for testing: 20.04.2 release candidate images ready!
Date: Tuesday, February 2, 2021, 10:19:03 AM PST
From: Lukasz Zemczak 
To: ubuntu-devel , ubuntu-release , Ubuntu Quality 

Hello everyone!

I'm only sending this e-mail now as previously we were still resolving
some unexpected issues regarding the .2 point-release. After a rough
start, we now have a *hopefully* stable set of 20.04.2 release
candidate images built and published on the .2 milestone:

http://iso.qa.ubuntu.com/qatracker/milestones/420/builds

Please pick your favorite flavor and start testing! And be sure to
report your results on the isotracker.

As with every recent release, we have a discourse thread for tracking
progress which we try to keep up to date as much as possible:

https://discourse.ubuntu.com/t/focal-fossa-20-04-2-lts-point-release-status-tracking/

Best regards,

-- 
Łukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemc...@canonical.com
 www.canonical.com

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

-

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] supercollider documentation - help files

[Erich Eickmeyer]

Hi Bart,

On Mon, 2021-01-18 at 10:39 +0100, bart deruyter wrote:
> Hello,
> 
> before submitting a bug report, I'd like to check if I'm the only
> one.
> In ubuntustudio 20.10, just like in 19.04 the help browser of the
> supercollider ide, the help files do not render here as they should.
> Search entries have no results and the document browser does not
> render anything and some other issues.
> 
> The culprit probably is a packaging issue, since after copying the
> HelpSource directory, which I downloaded from github, to
> /usr/share/SuperCollider seems to have fixed the problem.
> 
> grtz,
> Bart
> 
> 
> https://esmiltania.be
> On Twitter
> On Google+

Two problems:

1) You're asking the wrong list. Support questions belong in the Ubuntu Studio 
Users list, not the development list. This list is for collaboration between 
developers, not support questions.

2) The packaging for Supercollider, per 
https://launchpad.net/ubuntu/+source/supercollider, is actually done by the 
Debian Multimedia Team (https://wiki.debian.org/DebianMultimedia). The Ubuntu 
Studio team doesn't even touch it, except to include it in the ISO image.

So, while you're asking the wrong place, I'm happy to point you in the right 
direction.

Thanks,
Erich

--
Erich Eickmeyer
Project LeaderUbuntu Studio
Council MemberUbuntu Community Council


-- 
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] FW: [ubuntu-studio-users] rakarrack with segfault [1]

[Erich Eickmeyer]

FYI, everyone, This is harassment. Please do not engage Ralf Mardorf. He is toxic to this community and is not welcome here. From: Ralf MardorfSent: Thursday, January 14, 2021 10:55 PMTo: mei-m...@posteo.de; eeickme...@ubuntu.comSubject: [ubuntu-studio-users] rakarrack with segfault [1] Hans, do yourself a favour, stay a way from Ubuntu Studio. Rakarrack is under development, seehttps://sourceforge.net/p/guitarix/git/ci/b17009df6013687010911cdcf63494438566b87d/it works very well under Arch Linux [2] and apart from this it workedwithin the last years without any issues at all. It's not Rakarrack that suffers from bitrot, it's Ubuntu Studio! You could take a look at Guitarix, yes. You might like Guitarix, yes.But no, it's not a replacement for Rakarrack. Erich is resistent against learning anything about pro-audio or Linux,he banned me for correcting him, spread lies about me and UbuntuStudio isn't anymore what it was a long time ago. Regards,Ralf [1]Hi Hans, On 11/17/20 7:15 AM, Hans Schneidhofer wrote:> hi list,> > wanted to try rakarrack but it does not start, only the error message> memory access error appears.> Where to find this "segfault"-message, so I could find out, whats the> reason for that ?> > Has anyone an idea of this behavior ?> > Have installed ubuntustudio 20.04 lts on an AMD-Mainboard with an> AM3+- Prozessor 4-core, 8 GB RAM.> > Or is it better to use guitarix ?> > bye hans> > It's 100% better to use guitarix, which is actively developed.rakarrack development ceased several years ago, is suffering frombitrot, and is really no longer compatible. It was dropped in 20.10 andonward, and probably should've been dropped from 20.04, but it's toolate now. -- Erich EickmeyerProject Leader Ubuntu StudioCouncil Member Ubuntu Community Council [2][rocketmouse@archlinux ~]$ pacman -Qi guitarix Name    : guitarixVersion : 0.42.1-1Description : A simple mono guitar amplifier and FX for JACK using FaustArchitecture    : x86_64URL : https://guitarix.orgLicenses    : GPL3Groups  : ladspa-plugins  lv2-plugins  pro-audioProvides    : guitarix2  libgxw.so=0-64  libgxwmm.so=0-64  ladspa-host  lv2-hostDepends On  : atkmm  bluez-libs  cairo  cairomm  gcc-libs  glibc  glibmm  gtkmm3  libsigc++  libx11  pangomm  ttf-roboto  libavahi-common.so=3-64  libavahi-gobject.so=0-64  libboost_iostreams.so=1.75.0-64  libcurl.so=4-64  libfftw3f.so=3-64  libgdk-3.so=0-64  libgdk_pixbuf-2.0.so=0-64  libgio-2.0.so=0-64  libglib-2.0.so=0-64  libgobject-2.0.so=0-64  libjack.so=0-64  liblilv-0.so=0-64  liblo.so=7-64  liblrdf.so=2-64  libpangocairo-1.0.so=0-64  libpango-1.0.so=0-64  libsndfile.so=1-64  libzita-convolver.so=4-64  libzita-resampler.so=1-64Optional Deps   : new-session-manager: for session managementRequired By : NoneOptional For    : dragonfly-reverb  lsp-plugins  ninjas2Conflicts With  : guitarix2Replaces    : guitarix2Installed Size  : 57.59 MiBPackager    : David Runge Build Date  : Wed 06 Jan 2021 17:38:03 CETInstall Date    : Thu 07 Jan 2021 12:22:28 CETInstall Reason  : Explicitly installedInstall Script  : NoValidated By    : 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

[ubuntu-studio-devel] Fwd: [Ubuntustudio-ppa] bug Studio Controls in Ubuntu Studio 20.10 can't open

[Erich Eickmeyer]

This came to the Ubuntu Studio PPA list.

Len, any chance you can address this?

Thanks!
Erich
--
Erich Eickmeyer
Project LeaderUbuntu Studio
Council MemberUbuntu Community Council

 Forwarded Message 
From: DJ Recycle 
To: ubuntustudio-...@lists.launchpad.net
Subject: [Ubuntustudio-ppa] bug Studio Controls in Ubuntu Studio 20.10 
can't open
Date: Wed, 13 Jan 2021 16:43:21 +0700

> Traceback (most recent call last): 
>  File "/usr/local/bin/studio-controls", line 1420, in  
>us = StudioControls() 
>  File "/usr/local/bin/studio-controls", line 426, in __init__ 
>jack.set_error_function(callback=self.jack_error) 
>  File "/usr/lib/python3/dist-packages/jack.py", line 2835, in
> set_error_function 
>_set_error_or_info_function(callback,
> _lib.jack_set_error_function) 
>  File "/usr/lib/python3/dist-packages/jack.py", line 2874, in
> _set_error_or_info
> _function 
>def callback_wrapper(msg): 
> SystemError: ffi_prep_closure(): bad user_data (it seems that the
> version of the 
> libffi library seen at runtime is different from the 'ffi.h' file
> seen at compile
> -time)
> 
> -- 
> Mailing list: https://launchpad.net/~ubuntustudio-ppa
> Post to : ubuntustudio-...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntustudio-ppa
> More help   : https://help.launchpad.net/ListHelp


-- 
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] Future of Jamin

[Erich Eickmeyer]

Hi Ross,

On 1/5/21 8:28 AM, Ross Gammon wrote:

Hi,

I was taking a look at some of the build failures for our packages
(archive rebuild for GCC-10), and Jamin is one that is failing.

Upstream have not committed anything since 2015 (sourceforge) and I
could not find a valid fork.

Jamin was removed from Debian Testing in 2017 and nobody has stepped
into maintain the package there (Jonas has stepped down). It was kicked
out of testing for the same GCC-10 issue.

It is likely that it will be removed from Debian.

Should we preemptively remove Jamin from our seeds? I assume it's
typical use case of taking over mastering from Ardour is no longer
important?

Regards,

Ross


Probably not a bad idea. I'll remove it promptly. Bitrot is a thing. 
Looks like it's working on 20.04 but I don't really use it myself. 
Unless anybody objects, I'll go ahead and remove it.


UNRELATED: I'm applying for MOTU, would appreciate an endorsement. :) 
https://wiki.ubuntu.com/Eickmeyer/MOTUApplication


Erich
--
Erich Eickmeyer
Project Leader  Ubuntu Studio
Council Member  Ubuntu Community Council


--
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