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

[eylul]

Just wanted to say, yes I am still lurking here, and will start thinking 
on this. :)


Best

Eylul

On 17.10.2021 01:03, Erich Eickmeyer wrote:


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.
  o 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.
  o Rebasing on Breeze will also remove the need for Kvantum
and that overhead, bringing us in-line with the default
Plasma/Kwin theming engines.
  o 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


-- 
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] Virtual Instrument Gap

[eylul]

>
>>   The latest VSTs, both free and commercial ones from companies like
>> Spectrasonics and Arturia, do not run on the older versions of Windows
>> supported by Wine (Vista is the latest).  I have encountered other
>> problems
>
> I am sure wine goes beyond vista.
>
Wine definitely goes beyond vista. (outside of the realm of audio, in
gaming, Lutris, and Steam's proton both use wine, and actually it is a
lot more reliable in running software these days. I use it a few modern
games - most if not all of which does require windows 10, and for a 3D
printer software that is specific to my 3D printer). 

You can run winecfg to switch your default wine prefix
(/home//.wine) to windows 10. It was defaulted to windows 7 on
mine. (I don't work with the default prefix much as I tend to use lutris
and  playonlinux to install software), That should fix that issue hopefully?

Best

Eylul



-- 
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] Pre-Installed Application Review (effective for 20.10)

[eylul]

I would suggest adding:

1) Siril (photography) - astrophotography suite that does a series of
tasks related to it, including dealing with astrophotography specific
file formats, aligning and stacking of large number of images, dealing
with dark, flat and bias frames etc. (debian package: siril)

2) Hugin (photography) - panorama maker, also useful for making HDR
images, and aligning of some specific astrophotography and
non-astrophotography related aligning. (debian package hugin)

3) Godot (game design) - Godot is an open sourced gaming engine. it
looks like it finally is in debian repositories and we can put it in. :)
(current package is godot3. Godot 4.0 is expected to happen sometime in
the middle of 2020 through so worth watching)

4) Natron (video) - node based compositing software. (a commercial
example would be adobe after effects)  it has an active userbase. The
main problem is that it is not in the repos, but it is available as a
snap (and also as a flatpak)

There is some other software I would love to see in, but they don't have
repos/packages available so not sure it is feasible to discuss them.

Could we start with the full list of software and work off of it?  I am
worried we might miss less obvious overlaps or potential missing items.
For example we should probably look into video viewers (not sure we have
VLC installed by default) and what music players we have. I believe we
are not pre-installing some publishing packages like calibre, etc :)

Best

Eylul

On 11.05.2020 07:50, lukefro...@hushmail.com wrote:
> I have had good luck with Kdenlive for many years on several systems
> (hardware wise) and a very long-lived rolling OS install.
>
> On 5/10/2020 at 3:24 PM, "Erich Eickmeyer"  wrote:
>
> Hi all,
>
> So, first with the news: I'm done with the move and configuration
> of the
> seed to KDE Plasma. If there's anything Xfce left, it's mostly
> remnants
> at this point. Now, on to business.
>
> In an effort to cut-down on application purpose duplication, we
> need to
> review which applicationswe include by default.
>
> First, I would like to start off with the video editors. Currently, we
> have three applications that describe themselves as video editors:
> pitivi, openshot, and kdenlive. At one point in time, these may have
> served different purposes, but all three of them are video editors and
> describe themselves as such. My recommendation is to drop pitivi and
> openshot from the default install and use kdenlive as our video editor
> for a number of reasons: 1) It's more feature-full, 2) It's KDE
> software
> (by carrying Plasma we carry most of its libraries including the KDE
> Frameworks), and 3) as a flavor for creative *professionals* we
> need to
> be including the most professional software we can, and right now
> Kdenlive fits that bill. If people need functionality that is in
> one of
> the others, it's just a download away. The other objection I have for
> keeping Openshot is that it has a nag button for the "latest" version,
> which takes one to an appimage download, which isn't ideal.
>
> You will notice I leave Blender out of that discussion because,
> while it
> has video editing capabilities, it is primarily a 3D modeling and
> animation application, and video editing is not its default
> configuration. For this reason, we should leave Blender.
>
> Len and I have discussed removing the Calf plugins from the default
> install since lsp-plugins covers the things that Calf can do (and then
> some), and Calf has a tendency to be prone to crashing when used
> in Ardour.
>
> Gimp vs Krita: I recommend keeping both since, while both are equally
> capable of each other's functions, each has a different target
> audience.
> Whereas Gimp targets photo manipulation, Krita targets advanced
> graphical art. We could lump MyPaint in with this as well, but as
> Eylul
> has discussed with me, it fits a different niche altogether.
>
> Brasero: I don't understand why we've been carrying this since Xfburn
> was also installed. Now that we no longer carry Xfce, I recommend
> changing that out for K3b since, once again, KDE, and since it is a
> historically more powerful tool anyhow.
>
> Darktable vs Rawtherapee: Both are RAW image manipulation
> applications,
> with Darktable closely fitting the functionality of Adobe
> Lightroom. If
> we had to pick just one, I'd say Darktable as it seems to be the more
> professional of the two.
>
> Additionally, while we haven't carried Shotwell in a number of
> years, I
> think we could do with a photo catalog

Re: [ubuntu-studio-devel] Web design/theme contribution

[eylul]

Hi again,

Alright some additional things based on seeing the theme options from
the admin side. (thanks very much for the user account). Some of these
things might be items that was going to be handled during the ongoing
edits so if that is the case I apologize in advance. :)



Description/Banner:

Description text ("Ubuntu Studio provide the full range...") is not
editable. Generally it would be helpful if any text is editable. This is
useful for future proofing the site but also in case we end up needing a
translation.

Action: "Get Ubuntu Studio" and "Latest Version" is not editable. Link
text and url are not editable. I see that the links go to internal pages
with detailed links but it would be helpful if we can change this down
the line.

[optional] This is a question to the team. Do we ever see a situation
where we will want to have 2 versions announced: 1 latest stable and one
LTS on front page, as such need 2 subtitles in this category? Currently
the layout is hard coded to one subtitle. (e.g. only bionic or only
disco but not both)

Features:

[optional] allow extending total category count to 9 and reduce it to 3.
I don't expect us to need it, but it would be nice if we have options if
we end up with 7 categories or 3 categories. If this is easy to do it
would be very useful, but if it will cause a headache to code it really
isn't a huge deal, we can probably work around it and make sure we
always have between 4-6. :)

Footer:

custom social media links give random icons (e.g. mastodon is currently
showing as apple pay). Social media platforms come and go, and open
source software sometimes have its own unique platforms: launchpad,
telegram, fediverse etc. so it is pretty critical that we can speicify
the images ourselves. This way we can extend our iconset (I assume the
one used is a CC licensed one) or switch to one with more options
depending on our resources at the time.

If this is not feasible I'll argue that the text based social media
links might be better a solution for us as pretty as the icons look.

---

I hope this is helpful.

Best

Eylul


On 7/7/19 10:10 PM, Erich Eickmeyer wrote:
> Hi Shinta
>
> On 7/7/2019 7:45 AM, Shinta Carolinasari wrote:
>> Hi all,
>>
>> I apologize for the late progress.
>> We are keep working on it, and here's the latest progress:
>> http://ubuntustudio.playmain.com/
>>
>> There are outstanding things need to be done, it not finished yet, eg:
>> -inner pages refinement and create page template variations
>> -documentation
>> -make ubuntu fonts self hosted instead of google fonts
>> -bug fixings, polishing and optimization
>> -Testing, follow WP theme testing/checklist, cross browsers/device
>>
>> Please let me know if you have any feedback or suggestion based on
>> current progress.
>> In case you have expected due date when this need to be delivered,
>> please just let me know.
>>
>>
>>
>> Regards,
>> Shinta
>>
> Thanks for the update! I will note that (and this is me being nitpicky)
> we need to stick to the Ubuntu Branding Guidelines, and that the CoF
> logo, in order to show uniformity with Ubuntu and its official flavors,
> needs to remain within a black, white, or blue circle.
>
> Here's a link to the git repository with all of the official .svg
> versions of the logo:
> https://git.launchpad.net/~ubuntustudio-art/ubuntustudio-artwork/+git/current-standard/tree/
>
> I hope this helps. Otherwise, I'm in complete agreement with Len and
> others who have said this looks great. Also, as Len said, making the
> change staring with 20.04 LTS would be excellent timing. :)
>
> Thanks,
> Erich
> 
> Erich Eickmeyer
> Project Leader
> Ubuntu Studio
>
> ubuntustudio.org
>
>
-- 
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] Web design/theme contribution

[eylul]

Shinta,

We are all doing volunteer work here, delays do happen. I would say this
layout overall looks great both in desktop and mobile, it is nice to see
the original mockup in action. :) Thank you so much for your continued
hard work in this.

In terms of content of the blurbs I agree that the open source should be
last. I assume it was based on what we currently had on on live state
and old stage including open source comment being on the introduction
and some reasonable mockup where it didn't exist. Either way I assume
that content is modifiable and now that we have a layout, this will be a
good time to start reviewing the static content of the site for anything
that needs hasn't been updated in a long time. I'll take the lead on
that unless somebody would like to volunteer.

So related to that, if you haven't done so already, could you give me,
Len and/or Erich the password to the stage wordpress or create user
accounts for us so that we can see how the internal/updating side of the
theme works? (so that if there is something we need to be able to edit
easily that is not accessible -titles, contents, thumbnails of the
categories, footer text etc- we can let you know. - ) Also how does the
column system behave with different numbers of input other than 6. (I
think it is ok if it simply leaves the place blank but it would be good
to have the flexibility to have blurbs that are not multiples of 3
necessarily ;) )

Also we will need the CC/GPL licenses for the original artwork and
layout, and resource information on anything else that was used. I
assume we will also request work files of the artworks to be put so that
we can resize-reuse them as they are needed. So I assume the next stage
for that will be to give you access so that we can get the layout (and
the licenses) in the ubuntu studio website and art repos, and then the
layout can move to the main canonical servers from there when it is
finalized.

In terms of the main layout, I am going to perhaps suggest moving the
download box just under the title text, or moving both of them to right,
so that the download box is visible the moment the site is loaded. Right
now it is hidden until scrolled. Many will come to the site also
directly looking for the download link, so I would argue that it is
important to make that visible the moment right away. (this is less of a
concern on mobile device view, but it is on desktop view)

I am wondering if the download link section of the footer is
overwhelming the content on short pages, so it might be worth reducing
the height of that section and the text/icon to 50-70% of its current
sizes. Another thing about the download link is that making that the
background blue is miles brighter than any other background in the
website and as such a bit distracted. Shifting the blue gradient to be a
bit darker (without increasing the contrast of the background image) can
help both with legibility and again not overwhelming the content. That
being said I love the idea of putting a section like that there under
every page.

In terms of Mark's comments on time I assume we will put this up when we
can, especially as uploading of the layout is not something we can
sensitively time, but I assume the "deadline" for the new website is to
get it up in time for the next release (preferably some time before it
so that the contents updated any bugs found by the time release happens)
if at all possible. At the rate this is going I don't see a reason why
it cannot happen. :)

In terms of performance I cannot comment on desktop side as my computer
is a bit too strong so I didn't see the performance issues mentioned,
but on mobile it looked pretty lightweight overall and didn't run into
any major problems and was generally lighter than most websites I
encounter on phone. (I use firefox on android on a relatively new device).

I have a bit of a hectic next could of days but I'll try to test this
site in more detail both for accesibility and using some older computers
and give feedback as will I assume other people here in the ML will
continue to do so as well. Again, thanks for your hard work on this
layout, it looks great! :)

Best

Eylul


On 7/7/19 5:45 PM, Shinta Carolinasari wrote:
> Hi all,
>
> I apologize for the late progress.
> We are keep working on it, and here's the latest progress:
> http://ubuntustudio.playmain.com/
>
> There are outstanding things need to be done, it not finished yet, eg:
> -inner pages refinement and create page template variations
> -documentation
> -make ubuntu fonts self hosted instead of google fonts
> -bug fixings, polishing and optimization
> -Testing, follow WP theme testing/checklist, cross browsers/device
>
> Please let me know if you have any feedback or suggestion based on
> current progress.
> In case you have expected due date when this need to be delivered,
> please just let me know.
>
>
>
> Regards,
> Shinta
>
&g

Re: [ubuntu-studio-devel] Web design/theme contribution

[eylul]

Hi again!
> Yes, we are able to build the Wordpress theme/coding side, as well as
> design side, with supervision and assistance from you/ubuntu studio team.
> However, what you've mentioned in previous site/theme development
> workflow sounds limiting.
> Are we still restricted with the same constraint today?

As far as I know we any change we make to the theme needs to go through
IS submission procedure, so the requirement to be ability to change any
content (and ideally any images that might require changing) without
touching the theme remains. Making the theme easily editable is not a
solution unfortunately. Any theme needs to account for the fact that any
change to the website content/updates will be done via wordpress
structures. Just to note that, we also didn't have a lot of luck with
acceptance of plugins that gives access to css overrides or drag and
drop etc. Probably the best solution is to have custom fields on the
theme to fill out parts of the front page. (e.g. download link,
description, 6 software examples). Another approach obviously is to have
the css and layout inside the front page content, which is more than a
little hacky.

Anyhow now you begin to see why we sometimes went with more conservative
approaches.

> For source, and work files, yes, fortunately, the concept is created
> using software that available in Linux (Inkscape, Krita, etc).
> We will make sure all source assets are available and committed to a
> repo with an open license.
> One photo that you've mentioned in the concept is taken from unsplash
> (it's my favorite free stock photo). The license looks fine so far
> https://unsplash.com/license, attribution is not mandatory, but we can
> put credits somewhere in the site. or change it with another photo
> from your art asset repo.
> We also use random icons from fontawesome in the concept (as a draft).

It has less to do with if we can credit it or not and more that end
resulting theme will have to be licensed as GPL so everything used has
to be compatible with that. Unsplash unfortunately is a bit of a
question mark, so it might be safer to replace them.(they are not
against the spirit of GPL etc but that is not the question there) Some
links for the context, and welcome to the land of Open source license
compatibility issues. :)

https://creativecommons.org/2017/06/22/unsplash/

https://wptavern.com/unsplash-updates-its-license-raises-gpl-compatibility-concerns

Replacing the font with open licensed font shouldn't be too hard, but
let me know if you get stuck. 

I hope this is helpful and not too demoralizing. :)

Best

Eylul



-- 
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] Web design/theme contribution

[eylul]

Hi Erich and Shinta,

This is what we had https://ubuntustudio.azbulutlu.org/ a few years ago,
and again the main issue is that this was a few years ago. It was based
on the theme that existed for all ubuntu flavors at the time, and it was
actually collaboration of several people, not me alone. :) (there was
some newer cleaner graphics that replaced these, so this is not the
final version of the theme. I believe the latest version is somewhere in
the repos, somewhere.

The point is that while it was very pretty, it is a bit OLD :) and we
were working with a lot of technical limitations in terms of what we
could do within the constraints of the layout we were basing on, modules
we could use etc (and we were at the time trying to make sure it was
easy to update without having to get involved with the code). :) I do
like Shinta's design quite a lot. I might suggest some tweaks to make
content not be halfway visible when page is loaded, and maybe
verification of the order of things on first page, but these are pretty
minor, if they can handle the coding side of it as well, I think it
might be a good idea to go ahead with it. The proposed design looks very
coherent, and definitely has my vote as a user if nothing else. :)

In terms of what got stuck is that we lost communication with the IS at
some point (which made addition of some critical plugins to wordpress
not possible) and there was some disagreements about how to handle the
non-regular aspect of the install, and well we needed to synchronize
this to a git repository somewhere which... The shared of hosting and my
lack of knowledge of git at the time didn't help there.

Main thing if you guys go with this design is that Shinta we will need
from you (or at least this is what we decided at the time we needed,
Erich and the current team might have different opinions) will be work
files (preferably using FLOSS software) of all of the graphics (so that
the team can reuse, edit these assets if needed in future). Release
information clarifying these images are available in a CC by-SA or GPL
license, and to make sure any material you used that wasn't your own
creation (e.g. background photograph on the bottom or any part of the
illustration if they are not your own creation) have a compatible
license and attribution information for it. As this is a draft if you
used some random image, I believe we have some photographs available
somewhere of mixers and keyboards, in art assets repo I think? :)

I'll be also happy to help if any additional hands required for graphics
or programming, or just as a second eye from a usability perspective (my
experience with wordpress is a little better than it was back when I was
involved with this project ;) ) 

Hope this is of help. Glad to see some movement on this project, and
thank you Shinta for taking the initiative to reach out.

Best

Eylul



On 4/14/19 6:37 AM, Erich Eickmeyer wrote:
> Hi Shinta,
>
> On Sat, Apr 13, 2019 at 8:08 PM, Shinta Carolinasari
>  wrote:
>> Dear all, So I was looking for design-oriented Linux distro that has
>> good support on Wacom penabled and discovered Ubuntu Studio, and then
>> excited about it. Thanks for your effort for providing this great
>> Linux distro. Hopefully, the community remains active and growing.
>> While this distro is actively developed, I noticed that the website
>> design hasn't been updated for a while. Still nice, but feels a bit
>> outdated, eg: not adopting responsive design yet... while other
>> Ubuntu flavors family website (Lubuntu, etc) are. I believe there is
>> room for improvement on the website so it can be more modern thus
>> promote the distro better. Wondering if you have plan for website
>> redesign and open for a contribution? If so, we can help to
>> contribute web design as well as building the Wordpress theme. We
>> have an initial concept for the homepage. Please check at:
>> https://www.playmain.com/files/ubuntustudio/ubuntustudio-playmain-concept1.png
>>
> I absolutely love what you made. Believe it or not, there were plans a
> few years ago to replace the theme, but there were many roadblocks.
> One of our former (and possibly future?) core team members (Eylul) had
> designed an absolutely beautiful theme. I don't remember all of the
> reasons (perhaps others can chime-in?), but I do know that the theme
> was not easily replaced, as the Wordpress installation is non-standard.
> With the great strides we have taken in Ubuntu Studio over the past
> year, it might be a good time to look at the website again. As is my
> role in this, I can start working on coordination, but I do want to
> work with Eylul again with this. She's an amazing graphic artist and
> I'm sure would have a few ideas of her own.
>
> With that in mind, I welc ome your contribution, and would like to
> make a way to work together on what 

Re: [ubuntu-studio-devel] Audio Handbook

[eylul]

An epub file is essentially a zipped box of xhtml files. So you can open
it with ark and extract the html from it in a trivial way. :)

There was some changes done to the epub from the wiki in terms of
regularizing formatting and making the whole thing mobile friendly (and
converting the whole thing from wiki markdown/html mix to full html),
but I don't remember if these were ever reflected back to wiki.

Either way I hope this helps. :)

*goes back to vanish mode*

Best

Eylul

On 2/18/19 6:46 PM, Ross Gammon wrote:
> On 2/18/19 4:23 PM, Erich Eickmeyer wrote:
>> Hi Ross,
>>
>> On 2/18/2019 6:12 AM, Ross Gammon wrote:
>>> Hi,
>>>
>>> I finally got my Ubuntu Studio test machine up an running two weekends
>>> ago (there was a problem with my plugin video card which I haven't
>>> solved yet). With a fresh install of US 18.10, I started following the
>>> Audio Handbook. Naturally, I jotted down some TODO items.
>>>
>>> Where is the source stored? I see we have wiki format, and PDF & EPUB
>>> versions (and I remember the original was in Writer format).
>>> https://help.ubuntu.com/community/UbuntuStudio/AudioHandbook
>>>
>>> Would it be an idea to package the handbook so it can be put uploaded to
>>> our new ppa? Then there could be a version for each release (e.g. we
>>> should start explaining -controls & how to install on other flavours for
>>> Disco).
>>> The dominant form for documentation in packages is html, but I suppose
>>> we could package it in any form with an appropriate launcher.
>> The only source he ever gave us was in HTML, which was copied verbatim
>> to the wiki with a few edits.
>>
>> As for the source of the PDF & EPUB, that pretty much is the wiki, which
>> is why I recommend copying & pasting from the wiki to any new document.
>> The problem with going from any other format to the wiki is the special
>> flavor of markdown used, and I haven't found any way to autoformat from
>> any other format to that special markdown.
>>
>> That special markdown format is very much why I didn't consider
>> uploading the original files he gave me since it required hours of
>> painstaking manual conversion to the markdown. I figured any edits would
>> be done on the wiki and then could be copy/pasted into a writer document
>> for conversion to EPUB or PDF. Essentially, the way I see it, the wiki
>> is now the source.
> OK - thanks. It is probably the best way to get user (flyby) edits to
> improve things.
>
>> As far as packaging goes, wouldn't it be better just to make a link to
>> the wiki in our menu? That way it's kept up-to-date.
> Yes - but things will (could) change markedly between 18.04 and say
> 19.10 when it happens. Whilst the backports ppa will reduce this, it
> would at least be nice to be working on having the handbook covering the
> latest (e.g. what is in the autobuilders) whilst the published version
> reflects what has previously been released.
>

-- 
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] Meeting Agenda 2018-08-11 [cancelled]

[eylul]

Sorry about the delays on this, and sorry for missing the meeting, I am
actually on road tonight, and misjudged what part of the road would have
internet. Epub is actually finished and just uploaded it here until we
can move it to a PPA.

http://s.eyluldogruel.com/ubuntustudio/Ubuntu%20Studio%20Audio%20Handbook%20-%20Peter%20Reppert.epub

There was a lot of manual translation of markdown to html, and
formatting of last 2-3 chapters, so it might be best to have a second
set of eyes to check it to make sure nothing got garbled. As for pdf,
please go ahead. My plan was at this stage, converting the epub to docx
to open it in libreoffice and fix issues that way, but working from the
original odt can also be a solution. I am actually traveling this week,
so will have limited time, so if someone has the chance to go ahead and
get the pdf done before I get to it, feel free to. :)

I'd say mypaint and the pikopixel are 2 separate programs for very
separate usecases. MyPaint (despite the name) has nothing to do with
pixelart, and is a more lightweight and sketching oriented alternative
to Krita. :) As I said on chat I think it is a great idea to add it to
ubuntustudio. As for mypaint, not sure there is much we can do on short
term except removing it and keeping an eye on when it gets updated on
debian repos.

Best

Eylul


On 11-08-2018 23:01, Erich Eickmeyer wrote:
> Well, the decision was made to cancel this meeting. Since Len and I will be 
> very busy for the next couple weeks, we decided it would be a good idea to 
> cancel and have me do the write-up of our progress.
>
> === Package Uploads ===
>
> So, Ross marked ubuntustudio-controls as Fix Committed, and we're waiting on 
> a 
> sponsor to get that uploaded. I might ping someone in #ubuntu-motu to see if 
> someone wouldn't mind taking a look at it.
>
> This brings up the other issue of nobody on the team really being a MOTU and 
> that being a major barrier. So, I will be working on my Ubuntu membership and 
> MOTU applications sooner rather than later. For Ubuntu membership, they like 
> to see at least 6 months of sustained participation, so with me at 4-5, that 
> might be a factor. I'll work with Simon (tsimonq2) as he's on the membership 
> board.
>
> === Audio Handbook ===
>
> As far as I know, Eylul is still working on the epub and PDF forms of the 
> handbook. Eylul: Is there any way we could release the PDF now while you work 
> on the epub?
>
> === ubuntustudio-plasma ===
>
> I'm going to take-on some of this. I need to fix a file in the package, do 
> some building for myself, and then see where it leads. In the meantime, it 
> has 
> become a higher priority due to the GTK developers causing breakage in all 
> desktops that are not GNOME without any remorse (see https://lists.ubuntu.com/
> archives/ubuntu-desktop/2018-August/005402.html).  This has been a known 
> problem for Xubuntu in the past and is a problem for Ubuntu Budgie, but Solus 
> (upstream developers of Budgie) are aware of the problem and are working on a 
> fix.
>
> Unfortunately, this definitely a sign of things to come, and definitely a 
> hindrance to Xfce's move to GTK3. It has made our addition of Plasma much 
> more 
> apt than ever. Right now, if Xfce breaks, Xubuntu breaks. Since Studio is so 
> fragile right now, if Xubuntu breaks, Studio could very well die. I don't 
> want 
> to see that happen, and I know neither does anybody in this mailing list.
>
> With this, Plasma becomes a bit more of a priority. I'll do what I can to 
> work 
> with Simon on getting it seeded.
>
> === Website ===
>
> I have yet to email Eylul the Launchpad GIT upload rundown.
>
> I have initiated very early talks with Noah Chelliah on moving from 
> Canonical's hosting to his hosting at Altispeed. Noah is the president of 
> Altispeed and a personal friend of mine. Simon is his operations director, so 
> we have a couple of ins with that. This would potentially give us much more 
> control and the ability to move away from the security nightmare that is 
> Wordpress.
>
> === Packaging ===
>  
> Carla is still a work-in-progress as the wine bridges have become a pain. 
> Might have to postpone Carla from being included in 18.10, but either way 
> it's 
> a lower priority.
>
> Cadence, on the other hand, I feel is ready for upload. I was working with 
> Mathieu Trudel (cyphermox) on this, but I have yet to hear back from him. My 
> reasoning for prioritizing Cadence over Carla is that Cadence includes Catia, 
> which could replace the dead Patchage package.  Catia can be installed 
> separately from Cadence, so we could include it in our seeds 
>
> On the side, I've been working with the Calf developers who have released 
> 0.90.1. 0.90.0 was released back in November (majo

Re: [ubuntu-studio-devel] Ubuntu Studio For Musicians handbook

[eylul]

I think even if it is a living document (as it should be) it would be a
cool idea for it to have regular release versions to encourage people to
update and have an offline copy of. In addition to html, an epub would
be compatible with ebook readers and lightweight (which is nice when you
can have your computer you work on, and the reference next to it), it
should be pretty straightforward to convert it from epub to pdf too. (I
can help with formatting converting aspect of this, if/when it comes to
it and its pretty straightforward with calibre, when going from a
libreoffice file)

In the short term, we could probably attach a pdf/epub version of this
to a blog post on the website when it is finalized, and have the file
downloaded from there (or link it as pdf from one of the static pages
for support etc as well), until we can find a permanent home for the
living document version.

Just thinking out loud. :)

Best

Eylul


On 06/03/2018 06:05 PM, Peter Reppert wrote:
> Here is the handbook in PDF format. 
> https://drive.google.com/open?id=1eKETJ5rhxHtntLvCATm7xu7JpuogOAcx
> Only two people have read it and they did not mark it up - it
> desperately needs some proofreading and editing. 
>
> Anyway, please give it a read.  To be clear - I was hoping to post
> this somewhere like wiki.ubuntustudio.com
> <http://wiki.ubuntustudio.com> - that is, I do not want to share a
> link to my Google Drive with all Ubuntu users! This should be hosted
> with other Ubuntu documentation.  I think a wiki would be great, but I
> don't see how to go about actually posting it and need step-by-step
> instructions.  So far I haven't found anything that makes sense as a
> place to upload this. Not to get too far ahead of things, but could
> this become part of the skeletal audio guide here:
> https://help.ubuntu.com/community/UbuntuStudio/UserGuide/Audio ?
> That is a great outline, by the way - I wouldn't want to alter it. 
>
> So: *DO* download this if you are on the Documentation team. *DO *feel
> free to upload it somewhere the team can access it. *DO NOT* post the
> link to my Google Drive on any Ubuntu public pages.  I will work on
> making an editable version of this, and will be very happy to try to
> post it to a Wiki, as soon as I see where and how to do so. Link,
> please?  I am hoping that once it has been reviewed a little, it ends
> up somewhere that new users can readily find it from the main Ubuntu
> Studio page, whatever that may entail. 
>
> Let me know if you have any trouble accessing the PDF. I gave it a
> quick check and everything seems to be there - it's a bit longer than
> I said.
>
> Thanks, and looking forward to your feedback!  Will get on IRC
> sometime this week, most likely. 
>
> Pete
>
> P.s. - at this point I should probably repeat that this PDF file is
> hereby officially public domain. This is a way of paying back for all
> the great software and contributions of others in the Ubuntu
> community. Once this becomes a group project, I hope credit will be 
> given as due (to all who work on it).
>
> On Sun, Jun 3, 2018 at 8:00 AM,
>  <mailto:ubuntu-studio-devel-requ...@lists.ubuntu.com>> wrote:
>
> Send ubuntu-studio-devel mailing list submissions to
>         ubuntu-studio-devel@lists.ubuntu.com
> <mailto:ubuntu-studio-devel@lists.ubuntu.com>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
> <https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel>
> or, via email, send a message with subject or body 'help' to
>         ubuntu-studio-devel-requ...@lists.ubuntu.com
> <mailto:ubuntu-studio-devel-requ...@lists.ubuntu.com>
>
> You can reach the person managing the list at
>         ubuntu-studio-devel-ow...@lists.ubuntu.com
> <mailto:ubuntu-studio-devel-ow...@lists.ubuntu.com>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ubuntu-studio-devel digest..."
>
>
> Today's Topics:
>
>    1. Re:  Saturday's Meeting (June 2, 2018) (Ross Gammon)
>    2. Re:  Ubuntu Studio For Musicians handbook (Ross Gammon)
>    3. Re:  Ubuntu Studio For Musicians handbook (Peter Reppert)
>    4. Re:  Ubuntu Studio For Musicians handbook (charlie)
>    5. Re:  Ubuntu Studio For Musicians handbook (Ralf Mardorf)
>
>
> --
>
> Message: 1
> Date: Sat, 2 Jun 2018 15:14:23 +0200
> From: Ross Gammon  <mailto:ubuntustu...@the-gammons.net>>
> To: ubuntu-studio-devel@lists.ubuntu.com
> <mailto:ubuntu-studio-devel@lists.ubu

Re: [ubuntu-studio-devel] DE testing: GNOME vs KDE

[eylul]

I do 2D and code-art as most of you know and I have discussed my current
use of KDE before. Not going to go into the general DE discussion as
my knowledge of gnome at this point is almost 2 years out of date.

Just wanted to point out that, the lack of wacom interface is an issue
we have noticed and discussed a couple of years ago, and had some plans
for. Gnome is currently the only actively developed basic gui for wacom
tablet as far as I know. The current solution for other DEs, and
honestly, for any sort of additional customization (e.g. app specific
settings to switch between) is via scripts using xsetwacom (unless
something did get added to gnome on that front.)

xsetwacom is relatively easy to use, but still is commandline at the end
of the day and thus not friendly to non-technical users.

One of the solutions to this especially since we discuss having multiple
DEs is to have a GUI for wacom customization that would be a front to
xsetwacom. Had some early notes on this here:
https://wiki.ubuntu.com/UbuntuStudio/FeatureDefinitions/WacomScripts
(which are now out of date). We were actually discussing integrating
such an interface to ubuntustudio settings, on graphics tab. it could
however also be stand-alone app, to make it more modular. I
unfortunately don't have time to work on this, but if anyone is
interested to work on it and think it worthwhile it is a way to go.

There was also another project to bring gnome wacom settings to XFCE but
looking over it seems to be abandoned.

Best

Eylul


On 05/20/2018 11:43 PM, Aleksander Pusz wrote:
> I'm 3D artist using FOSS software mostly. Currently I'm planning to
> switch completely to Linux and testing KDE and GNOME for production
> workflow. I was considering KDE as it "seems to be more technically
> advanced" (taking less RAM, faster etc.) but unfortunately I've found
> KDE frustrating.
>
> As modified Ubuntu interface was not an option I decided to go with
> vanilla GNOME to see how it's designed and Ubuntu is my way to go due
> to software availability.
>
> I feel that GNOME despite of being less customizable is simpler, more
> complete and more user experience oriented, more like ready to use
> product. From my point of view OS is a tool that has to be transparent
> and efficient.
>
> Here is list of features that are important to me and GNOME just
> supports them correctly:
> - GVsd is working (KDE has no GVsd equivalent)
> - wacom tablet is working and perfectly customizable
> - color management is working (currently KDE supports it too with
> colord-kde package)
> - font management is working (see:
> https://bugs.kde.org/show_bug.cgi?id=379524)
> - system keeps my wifi password automatically (no KDE wallet (!) thing
> for simple wifi password)
> - bluetooth mouse is connecting correctly and working after system
> suspend
> - system loads faster despite of taking more RAM
> - GNOME apps is stable
> - GNOME overview window/desktop management is carefully designed and
> extremely user-friendly, especially when I've got to manage lots of
> windows: it offers app favorites, windows and desktops management in
> one, no KDE setting/widget can match it and even new Windows 10 april
> update can't match it (my personal opinion)
> - there are extensive plans to make GNOME more lean and faster (see:
> https://wiki.gnome.org/Hackfests/Performance2018/Agenda)
> - as Phoronix tests show GNOME 3D speed is on par with KDE (see:
> https://www.phoronix.com/scan.php?page=article=bionic-kde-gnome=2)
> - some KDE user related things are impossible to change (see:
> https://bugs.kde.org/show_bug.cgi?id=377722 and
> https://bugs.kde.org/show_bug.cgi?id=378200)
>
> Ubuntu modifications I've done
> - switch to vanilla GNOME
> - installed GNOME tweaks
> - set hotkey for full-screen window option to save screen space (see:
> https://bugzilla.gnome.org/show_bug.cgi?id=791262)
> - configure mouse to use flat acceleration profile (see:
> https://gitlab.gnome.org/GNOME/gnome-control-center/issues/94)
> - installed qt5ct and added custom palette for Fusion QT theme
> - fiddled with tweaks a bit
>
> Best regs.
> Alex
>
>




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

Re: [ubuntu-studio-devel] Wallpaper

[eylul]

Thanks Len, Thomas, Erich and Set! :)

For Thomas's two comments, the icon WAS a bit off-centered. I must have
shifted it at some point, thank you for catching that. The color issue
is a bit trickier. There is actually a range of blue hues in there, and
that part is very intentional, opting for more depth (and clarity of the
icon without adding too much brightness contrast) over exact hue match.
I did however try to tone down the ultramarine tones down a little on
the new version, which will help with cohesiveness... hopefully? :D
Corrected version and extra screen background are linked below.

http://s.eyluldogruel.com/ubuntustudio/UbuntuStudio1804Corrected.jpg

http://s.eyluldogruel.com/ubuntustudio/UbuntuStudio1804_extrascreen.jpg

Set, I got your email just as I had uploaded these. :) They are not
seamless, but the goal was to make sure second screen could be on side,
bottom, or a different resolution and still work. I can try to make a
seamless version through if we need that too.

I do need to step out for next few hours but I will finish these with
any last corrections. I might need some help uploading (as I haven't
done it before but would like to as it is an easy case to learn it) but
will try to get that done later tonight (late night EU timezone) :)

Best

Eylul 


On 04/12/2018 06:40 PM, Set Hallström wrote:
> On April 12, 2018 1:17:46 AM GMT+02:00, eylul <ey...@ubuntustudio.org> wrote:
>> Hi!
>>
>> Here is a preview of the proposed wallpaper for 18.04.
>>
>>
>> You can view full resolution version
>> http://s.eyluldogruel.com/ubuntustudio/UbuntuStudio1804.jpg Created
>> using Inkscape, Krita and Darktable. I'll work on second screen part if
>> we plan to go ahead with it. Continue? Abort? :)
>>
>> As for additional wallpapers. I do have my photographs to offer
>> (probably the most up to date place to browse is my mastodon:
>> https://mastodon.art/@eylul/media, please ignore the occasional cat and
>> screenshot mixed in there. ;) ) Most of the images have high resolution
>> versions available, without watermark (obviously). A couple more people
>> also offered during the meeting, so we could pool different items in
>> and
>> pick a few if we opt to go for that route, either on this release on
>> 18.10.
>>
>> Best
>>
>> Eylul
>>
>>
>> On 04/07/2018 11:41 PM, Erich Eickmeyer wrote:
>>> Present: ErichEickmeyer, OvenWorks, eylul, alem, captain-tux_, pmd11
>>>
>>>   * Eylul to look into change or add wallpaper for 18.04
>>>   * Install-time package selection bug fixed, request for testers.
>>>   * ubuntustudio-controls to be updated for 18.10 to add the
>> following
>>> features:
>>>   o set cpu governor, turn on/off Intel Boost
>>>   o choose audio device
>>>   o run jack from session start (or not)
>>>   o hotplugging USB mics selecting a non-standard set of outputs
>>> for pulse-jack bridging
>>>   o Using more than one audio device even if internal
>>>   o bridging ALSA midi to jack midi
>>>   o a “Safely remove USB Audio Device” button
>>>   o Future improvements to include tabs for video use or graphics
>>> setups.
>>>   * Change in default DE or adding option of DE being considered for
>>> 18.10. Those discussed included
>>>   o Gnome Shell
>>>   o KDE Plasma
>>>   o MATE
>>>   * Adaptation of Ubuntu MATE welcome app for Ubuntu Studio being
>>> considered for 18.10, would replace “ubuntustudio-installer”.
>>>
>>>
>>> Anyone who can, please install the latest Daily ISO to test the
>>> install-time package selection. This is our final push to the RC on
>>> April 19th, so we need to find the bugs.
>>>
>>> Next meeting will be same time next week.
>>>
>>> 22:00 EEST/MSK in Helsinki, Moscow, Ankara 
>>> 21:00 CEST in Stockholm, Berlin, Paris, Madrid 
>>> 20:00 BST in London 
>>> 19:00 UTC/GMT 
>>> 15:00 EDT in New York, Toronto 
>>> 12:00 PDT in Los Angeles, Vancouver 
>>>
>>>
>>> Thanks,
>>> Erich
>>>
>>>
> Nice!
>
> On a side-note regarding double screen (if understand it correctly): if you 
> made it seamless that wouldn't be a problem and it would fit any screen or 
> setup... Just a suggestion :)
> --
> Set Hallström AKA Sakrecoer
>



-- 
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] GIMP vs MyPaint - Dependency conflicts

[eylul]

As much as I would really like to see 2.10 on release, this is a good
point.

From a 18.10 point of view, the main issue with snap in combination with
graphics programs used to be that snap could have issues with
integration of proprietary graphic drivers (e.g. of nvidia). This
information is several months old through so it is possible that the
issue is fixed.

Best

Eylul


On 04/11/2018 09:11 PM, Erich Eickmeyer wrote:
> I’ll let Jeremy know that we’d like to keep things as-is for this
> cycle, but we’ll experiment with snaps for 18.10.
>
>
>
>> On Apr 11, 2018, at 11:09 AM, Ross Gammon <ro...@ubuntustudio.org
>> <mailto:ro...@ubuntustudio.org>> wrote:
>>
>> In my view it is too late to make such a change. We release in two weeks.
>>
>> If the current versions of gimp (2.8) and mypaint install fine, I
>> would leave it that way. I thought is was only if gimp 2.10 was
>> installed that there was the clash with mypaint?
>>
>> I think it would be a good idea to create snaps for our priority
>> packages, and encourage upstream to maintain them. And then if
>> someone wants the latest and greatest, they can install it. Adding
>> relevant snaps to our seeds )instead of the Debian package) would be
>> a good test/goal for 18.10.
>>
>> On 11/04/18 19:50, Erich Eickmeyer wrote:
>>> Hi again,
>>>
>>> Speaking with Jeremy Bicha (and Ross, apparently you had a previous 
>>> conversation), GIMP 2.10 is supposed to be out shortly. However, since 
>>> libmypaint was split and the new version is dependent on a newer version, 
>>> having GIMP and MyPaint installed together breaks MyPaint until its 1.3 
>>> release.
>>>
>>> So, the question is whether or not we keep 2.8, change GIMP to a snap, or 
>>> remove MyPaint from the install.
>>>
>>> Thoughts?
>>>
>>> Erich
>>>
>>>
>>
>> -- 
>> 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
>
>
>



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

Re: [ubuntu-studio-devel] US still alive !

[eylul]

One of the biggest advantages of moving to mate would be being able to
use (and possibly adapt) the software center. Also it could help us
dodge the issues with menus. (hopefully? maybe?) It also seems that we
have people here who are also active on that side of the project which
is good! :) I remember it not being very flexible, but it could be a
compromise for polish, and as it is a relatively new project hopefully
flexibility will come as the project matures.

As for KDE as someone who is using KDE packages on top of UbuntuStudio I
can give some opinions on it.

I would love to see KDE as a possible desktop for ubuntustudio. It is
aesthethically nice. Widgets are very useful. It has quite a few tools I
use as an artist including the gwenview, and its file manager that is
able to view raws and krita files etc, as well as giving a GUI interface
to symlinking. It comes with a mobile phone synching tool. That being
said. I have had more crashes on it than I had on XFCE. I am also
running into some odd cursor scaling issues with high-res screen, but
honestly HI-DPI can still have issues on many of the desktop
environments. In short, as someone who has used KDE on top of
UbuntuStudio for at least a year, I am a bit cautious about recommending
a switch to KDE as default DE. (on my backup laptop I have XFCE with
some KDE tools like gwenview installed, that seems to be a slightly more
stable solution to maintain at least some of the advantages) KDE has
come a long way through so I am very curious to see where the project goes.

As for XFCE4 the human readable configuration is nice from a power user
level. I personally like that (and to this date, it is the only desktop
environment I created theme elements for, for this reason :) ) but at
the same time is that accessible to our current userbase? Is this
accessible to the userbase we aim to reach out at for this to be a
consideration? Or is a more beginner friendly approach to this (with
less choice as compromise, the way some of the other desktop
environments go with) the better suited to our audience? What about the
audience we try to reach out to? How much does the ability of configure
using commandline and human readable files bring as benefit to the
people it is accessible to? I don't think the answer to these questions
are straightforward in our case.

I do agree with the issue of switching desktop environment as this will
break workflow for people, so this is definitely a very strong argument
on favor of staying with XFCE. I am not saying we shouldn't consider
doing it at all, but it isn't something we should not do lightly or
often. I would even put out a post about the intent to do that as with
requesting input before finalizing the decision if we decide to go that
route.

Also as a historical context, one of the discussions we had in past was
to make ubuntustudio packages desktop environment agnostic, and allowing
to chose on install. Ubuntustudio is the only ubuntu flavor that is not
structured around a desktop environment. This puts us into an
interesting position.  Installing a new desktop environment on top of
existing ubuntustudio not hard but cleaning the old one is nearly
impossible. Could we somehow make this process easier? On one hand it
would be really nice to have the ability to give the option to people
(with one default) but on other hand this can easily turn into a support
headache. Still something to think about. :)

Best

Eylul


On 04/03/2018 07:32 AM, Ralf Mardorf wrote:
> On Mon, 2 Apr 2018 16:09:24 -0700, Erich Eickmeyer wrote:
>> My proposal would be to move from Xfce to MATE
> Ubuntu Mate is pretty good these days. It's the distro and desktop
> environment I would recommend to users who want something working OOTB
> for mailing, browsing and office work and who don't want to go further
> into Linux. Actually I'm using Ubuntu Mate 17.10 from a DVD to
> backup my Ubuntu and Arch Linux installs and all my data. When making
> backups I test different live media from time to time and Ubuntu Mate is
> one of the better, if not the best OOTB working Linux.
>
> As far as I'm concerned, I'm using openbox only for my installs.
>
> I'm aware that for Xfce4 changed a lot within the last years. I once
> used it myself and for good reasons stopped using it. However, there is
> one good reason to stay with Xfce4, as long as it shouldn't become
> buggy, bloated or should suffer seriously from anything else.
>
> Users who decided to install Ubuntu Studio are used to Xfce4, migrating
> to another desktop environment does break their workflow and it would
> be tricky to run do-release-upgrade.
>
> Users who want Ubuntu Studio with another desktop environment or just a
> window manager such as openbox, could install another Ubuntu flavour,
> even use the server image and install the desired meta-packages, see
> https://packages.ubuntu.com/search?keywords=ubuntus

Re: [ubuntu-studio-devel] wineasio interesting app

[eylul]

On 04/01/2018 06:51 PM, Ralf Mardorf wrote:
> Hi,
>
> since building QjackCtl is easy to do, the rules and control files at
> https://tracker.debian.org/pkg/qjackctl are helpful to do this, for
> testing purpose consider to build a snap for QjackCtl, for usage with
> jackd/bus and jack clients, from the regular install, outside of the
> QjackCtl snap container.

This is good advice thanks!

> Suggestions based on hearsay, without any efforts to provide results,
> often tends to be close to bikeshedding. Before building a wineasio
> snap, try to find out why building wineasio has got tendencies to fail,
> maybe the issues are from that kind, that building it with it's own
> dependencies gains you nothing and first learn to build a snap for
> something real-time audio related that is easy to build, but requires
> communication via ALSA or jackd with clients and/or hardware.
>
> Regards,
> Ralf
>

While I don't want to single out Ralf, I am going to not ignore this
because this is something that does come up on FLOSS projects often.
Giving a partial answer and a place to start is not to making
suggestions based on hearsay. This type of gatekeeping comments, while
well meaning is what keeps especially beginners and intermediate skilled
people from sticking around long enough to gain more experience. That in
return results in volunteer attrition and as prevents knowledge from
being communicated. Let's try not to do that. Either way part of the
question was how to make something available for ubuntu studio users to
install via repos, and that was the answer to that part of the question.
These are the options. Whether which of them are technically viable is
the following question to answer.

Thanks :)

Best

Eylul


-- 
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] wineasio interesting app

[eylul]

Hi!

We are not dependent on xubuntu specifically. All the flavors have
access to the whole ubuntu repository. Some of our desktop side setup
inherits xubuntu packages as we use xfce. If wineasio is available on
ubuntu repos, users at least should be able to install it.

Generally the bottom line problem with any of these issues (similar to
the earlier comment about cadence, I'd honestly love to see Carla and
Godot game engine in repos too) we need someone to package them, for
debian or ubuntu.

Packaging for debian is a tricky issue. 1) We need people with
experience to package these programs. Ideally we should hold a workshop
to get more people trained in this sooner than later (I know I was
hoping for that when I joined the team but due to various reasons that
didn't happen :) ) but none of the programs mentioned above are easy,
introduction level cases. 2) Debian requirements can be strict and that
can conflict with some features of some of these programs. Also
sometimes new software or updates with substantial changes can take a
while to get approved as there needs to be a manual review of the
submitted packages. (People on mailing list might remember the issue
with Krita package)

If debian repos is not possible, it is possible to sometimes put things
directly into ubuntu repos. This is done on a case by case basis. We
could talk to Kubuntu team to learn about details of this procedure as
they do maintain a kubuntu repo.

I would be willing to help doing communication side of this if someone
wants to work on packaging, but especially if we have a repo it means a
responsibility and commitment to regularly update and maintain that
repo. Do we have people who can commit medium to long term to do this?
It won't be a one time task. :)

Of course there is also the option of snap packages that can be worth
investigating.

I hope this is helpful and not discouraging. :)

Best

Eylul


On 04/01/2018 02:48 PM, Thomas Pfundt wrote:
> On March 31, 2018 3:07 PM, Ralf Mardorf <ralf.mard...@alice-dsl.net> wrote: 
>> Hi
>>
>> it's probably missing for hysterical raisins. [...] 
>> I would recommend to test it and to do research how much wanted it 
>> is by Linux, especially Ubuntu users first. 
>>
>> The more packages you add, the harder it becomes to maintain/test all 
>> packages. Since Ubuntu Studio suffers from missing manpower [1], 
>> consider, if making Ubuntu Studio more bloated is a step into the right 
>> direction. 
>  
> Hi all, 
>  
> I would suggest that WineASIO is a great way for a lot of people using 
> Wine-compatible Windows DAWs and standalone VSTis to make them run on their 
> Linux installation without much hassle in a semi-professional environment. 
> I've used it myself for a long time after I switched, but from my 
> understanding, there are only two ways to get a working WineASIO 
> configuration on Ubuntu Studio: 
>  
> 1.) Add the Kxstudio repositories and install their "wine-rt" and "wineasio" 
> builds. (I believe that those only work in conjunction.) Problem: The 
> Kxstudio wine-rt build is completely outdated at this point (it was on 
> version 1.9.x the last time I installed it, the official release is at 3.x 
> now) and FalkXT, the maintainer of Kxstudio mentioned in some forum post that 
> the real-time patch became obsolete anyway with the Wine staging branch at 
> some point. 
>  
> 2.) Install wine from the official packages and build WineASIO from the 
> official Sourceforge. I've never tried this myself, but I've read that there 
> can be some issues involved with Ubuntu. I haven't bothered to find out 
> what's the catch, since I switched to Reaper for Linux for my DAW, which is 
> JACK-compatible and I can work with LinVst to run most of my plugins, but for 
> someone who is dependent on a certain VST, this could be a problem, if they 
> are unable to get WineASIO working or just switched and have no idea how to 
> do so at all. 
>  
> IMHO, a way 3 would be desirable: To install a recent version of the regular 
> Wine build either from the distro's repository or the official packages and 
> separately "sudo apt install wineasio" and register it to that Wine 
> installation. I think that's something that most newcomers would be 
> comfortable doing and the best solution to stay updated. 
>  
> If I understand it correctly, Ubuntu Studio is completely dependent on the 
> regular Xubuntu repository at this point? So, WineASIO would have to be added 
> as a package to Xubuntu to be available to Ubuntu Studio users for 
> installation? 
>  
> I would be willing to figure out what problems there are in building and 
> installing WineASIO from the official source and how to use it with the most 
> recent stable Wine version, however I'm not sure what else

Re: [ubuntu-studio-devel] Candace

[eylul]

I believe this was in our todo list. :) Some of the changes FalkTX is
making might actually make it easier for these to be included in the
debian repos. Another option is to see if we can get it into ubuntu repos.

Best

Eylul


On 03/30/2018 08:06 PM, Erich Eickmeyer wrote:
>
>
>> On Mar 30, 2018, at 7:17 AM, Set Hallström <s...@ubuntustudio.org
>> <mailto:s...@ubuntustudio.org>> wrote:
>>
>> On March 30, 2018 4:12:34 PM GMT+02:00, Set Sakrecoer
>> <pub...@sakrecoer.com <mailto:pub...@sakrecoer.com>> wrote:
>>> On March 30, 2018 12:17:51 PM GMT+02:00, Lord Jonathan Moore
>>> <jdm...@gmail.com <mailto:jdm...@gmail.com>> wrote:
>>>> Hi,
>>>>
>>>> I was looking at the replace-qjackctl-a blueprint and think Candace
>>>> would
>>>> be better it is faster to use than patchage. And looks more organized
>>>> with
>>>> a ladish session. I would like an opinion on ladish vs jack,
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> jdm7dv
>>>
>>> Hi Jonathan!
>>>
>>> Thanks for reaching out and taking the time to inveatigate the
>>> question!
>>>
>>> I kindof lost touch with music production at the same time i lost touch
>>> with ubuntu studio. I'm hoping to get chance to test Cadence. I think i
>>> remember hearing ladish development was sort of abandoned, but i might
>>> be very wrong...
>>>
>>> The rule of thumb is: if it fits in debian, it fits in UbuStu. This is
>>> because we pull packages from debian. I hope someone else can fill the
>>> many blanks.
>>>
>>> TL;DR i am not against it, but i'm not really fit for judging and i
>>> hope more ppl will get involved in giving you feedback.
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>> -- 
>>> 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
>>
>> Ps. Sorry, I mismanipulated my portable email client and by doing so
>> forgot to sign the previous email properly. public@sak***oer.com
>> <http://oer.com> is my alternative mailing list email address...
>>
>> Yours,
>> --
>> Set Hallström AKA Sakrecoer
>>
>> -- 
>> 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
>
> Jonathan,
>
> This is a great idea as the Jack developers are recommending Cadence
> over qjackctl anymore, and patchage seems to be unmaintained. Besides,
> Cadence seems to work with the PulseAudio-Jack bridge better than
> anything I’ve seen.
>
> FalkTX (the developer of KXStudio and Cadence) has Cadence in his
> KXStudio repos/PPA, which work directly with Debian iirc. Based on
> this, I’m fairly certain it can be run upstream to Debian and be made
> a part of the Ubuntu repos. I’ve been considering reaching-out to
> FalkTX to see if he would be willing to push Cadence upstream. Either
> way, I’m sure it can be done. Even Arch has it in their community repo.
>
> As for getting it into 18.04, it’s probably too late at this time, but
> perhaps that’s something we work on for the next release cycle.
>
> Thanks,
> Erich
>
>
>
>
>



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

Re: [ubuntu-studio-devel] Next cycle

[eylul]

Last email for tonight (morning?) replying quickly to parts that didn't
get covered in last 2 emails. :D


> Common for most of the blueprints was a possible need to provide an
> on/off toggle in -controls. I think it is OK that the -controls work is
> scattered across different blueprints (but then I am new to creating
> these things, so I am blissfully unaware of any future complications :-) ).

if there is a complication we'll learn from it for next round. No strong
opinions about blueprint organization as long as
it is not causing confusion (I don't think it does)
> I normally leave the old kernels there for a while before autoremoving
> them, just in case there is some incompatibility and I want to go back
> to them. But eventually you need to, or apt-get starts to have trouble
> working out what to do, and gets slow at updating the grub menu.
>
I see, I didn't notice it but it might be because I use relatively new
machines. *has no clear
solutions or ideas to try*

>
>> 5) https://blueprints.launchpad.net/ubuntustudio-look/+spec/new-wallpaper-a
>> This looks good to me. I volunteered for doing this (unless somebody
>> desperately wants to)
>> Original discussion was to have these ready for 18.04, but I can adjust
>> to have them ready
>> by 17.10. Just let me know which deadline I am working toward and I'll
>> make it.
> Well - Lens recommendation to avoid the rush for 18.04 and start now,
> which seems like a good idea. We have a bit of a bad record recently for
> getting things done (on time) :-)
> But 1804 is the real deadline.
Alright then I aim for 17.10, if there is a problem, or further
revisions are needed, we'll have extra time. If not we can make the
decision to put it for 17.10 or 18.04 when the images are ready.

>
> Thanks for the feedback. If there is no further feedback, we should just
> continue finalising them, and then someone for the core team can approve
> them.

Thanks again for doing this Ross. :)

Best,

Eylul

-- 
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] Next cycle

[eylul]

>  ---
> In thinking about auto mounting of media I realize that we probably
> don't need it. Automounted or not, the devices icon shows up in the
> file browser anyway... so what does automount gain besides opening a
> new window in the middle of things? Does it improve a workflow?
>
For example, I put a harddrive in, open the imaging or photography
software and can pull the file, without having to do the extra steps of
opening the file manager, going to the folder, closing the file manager
waiting for the device to mount switching back to the software, it mounts
while I load the software. Smoother experience. (e.g. when editing I 
usually browse through art directly in darktable, as it gives better options
for tagging, filtering, previewing etc. I only use file manager to import 
the files that are not there - some Darktable users don't even do that 
and use the folder import). Similar workflows exist for some project 
based software too.

out of curiosity through, is there a way to automount without starting a window
regardless, because it is a bit annoying.  

anyway tldr I don't think we can go terribly wrong with either choice here.
Just a question of which one is better in an imperfect world.  :) 

Eylul

-- 
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] Next cycle

[eylul]

There is a display option for security and other updates but I didn't
realize it did it even with checking for updates turned off.
Interesting! :)

Eylul



On 05/20/2017 03:37 AM, Len Ovens wrote:
> On Sat, 20 May 2017, eylul wrote:
>
>> cron based updates where you can set up the time, and reminders about
>> system being out of date. All of these are good ideas.
>
> The reminders are already there. Turn off your updates for a week
> (less?) and you will see that there are reminders. (I wonder how I
> knew that ;)
>
>
> -- 
> Len Ovens
> www.ovenwerks.net
>
>


-- 
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] Next cycle

[eylul]

I had a long email written refuting this (which unfortunately went to
Len instead of the mailing list :D).

I don't feel we are a good representative of the skill level of a
general user here. (this ML is mostly developers or at least expert
users, and that reflects on arguments so far). If the choice is
inconvenience and slight risk of breaking (again these are only security
updates, not all updates) vs potential risk of security issues with far
more serious consequences I think it is best to give users solutions
that require minimal maintenance by default, and allow them to override
if they choose to. (not everyone has the skillset nor the interest to
keep up with security issues and what each update does) I am well aware
I am being outvoted here so this will probably be my last comment on the
topic but I still feel strongly still that the best solution is to keep
the auto-updates on by default. I do understand all your points about
why giving easier opt-out to users is a good idea through, and I agree.

I also think that having controls on ubuntustudio-controls to turn
updates on and off is something we can have a consensus on, regardless
of decision? (I actually like a lot of what Len suggested about having
cron based updates where you can set up the time, and reminders about
system being out of date. All of these are good ideas.

Another idea related to this might be to have an introduction screen to
help people finalize their setup. (it would be also good to introduce
the users to audio setup in the controls from the get go). Some of the
other flavors have a similar tools available. I also like the idea of
writing a documentation that Ross suggested (which would make a good
blog post around the launch time).

Eylul





On 05/20/2017 03:02 AM, lukefro...@hushmail.com wrote:
> I have never, ever left auto updating turned on because i often can't
> spare the bandwidth, may be using an IP address I  don't want to make 
> non-Tor connections from, or cannot spare the CPU load on the netbook.
> I have yet to have a use case where I could get away with it on something
> other than a server(for which it may be crucial).
>
> On 5/19/2017 at 5:59 PM, "Len Ovens" <l...@ovenwerks.net> wrote:
>> On Fri, 19 May 2017, Ross Gammon wrote:
>>
>>> On 05/17/2017 12:38 AM, eylul wrote:
>>>> Disabling auto-updates should NEVER be the default, period. It 
>> would
>>>> leave users system vulnerable to attacks.
>> Strongly dissagree on that one. Auto updates are performed on no 
>> real time 
>> schedule and often happen while the user is trying to do 
>> something. If 
>> auto updating _must_ be done then it should be moved to cron and 
>> the user 
>> should be asked to choose the time. If autoupdates are turned off, 
>> there 
>> _is_ a warning Icon that shows up in the top bar that says "hey 
>> you 
>> haven't updated for a while would you like to check for updates." 
>> That is 
>> good enough. The user can choose when that happens. This also 
>> avoids the 
>> "hey I need Chromium so a can join a meeting on hangouts but I 
>> can't 
>> download it because some other process is up dating my system for 
>> some 
>> unknown amount of time."
>>
>>> Fair enough (considering there are other use cases for US than 
>> audio work).
>>
>> Auto update can be anoying no matter what kind of work is being 
>> done. It 
>> slows compile times, graphic render times (so video too) and 
>> introduces 
>> those "it works most of the time but every once in a while" kinds 
>> of bugs.
>>
>>>> Users can turn off the auto-updates if they want to.(Go to
>>>> "software" -> "Updates". You can change how often the 
>> system
>>>> checks for updates, it currently only downloads and installs
>>>> automatically security updates, and displays the rest.) 
>> Advanced users
>>>> can make that choice. It is not ours to make.
>> It is very much our choice to make. High disk/network/cpu load 
>> activities 
>> should _never_ be run without user request on a work machine. The 
>> user 
>> should have to work hard to screw up their system, it should not 
>> be done 
>> for them (automatically).
>>
>>> Well - I prefer to check what the updates are before installing 
>> them.
>>> Sometimes, they can be quite disruptive (e.g. temporarily 
>> disabling
>>> something). It might be better to pull the internet cable out 
>> instead ;-)
>>
>> Yup, one more reason for no auto updating.
>>
>>  ---
>> In thinking about auto mounting of media 

Re: [ubuntu-studio-devel] Next cycle

[eylul]

Ross,

Thanks so much, for doing this. I am adding some comments here in this
email. I can also reflect changes to the blueprints accordingly, but
posting them here first, in case there is anything else that needs to be
discussed before changing. I hope this helps.  :)

Best

Eylul

--

1)
https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-mounting-a

This looks mostly good to me. My original comment was that it is more
intuitive for non-audio users to auto-mount but that if this causes
errors for the audio users (rather than a minor inconvenience or extra
step) then we should remove it.

I also mentioned ability to turn auto-mount on and off easily would be a
good addition to ubuntustudio-controls. which could be its own blueprint
if we accept it, or added to the -controls blueprint.


2)
https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/auto-updating-a
This needs revision.

Disabling auto-updates should NEVER be the default, period. It would
leave users system vulnerable to attacks.

Users can turn off the auto-updates if they want to.(Go to
"software" -> "Updates". You can change how often the system
checks for updates, it currently only downloads and installs
automatically security updates, and displays the rest.) Advanced users
can make that choice. It is not ours to make.

The issue is the leftover kernels, and how to clean them. (so the
blueprint should probably reflect that, rather than being about
auto-updating)

Len asked me before what is my current efi is looking like: my /boot/efi
section is currently using 29mb out of a much bigger area. I cannot look
inside at the moment (I need to look up how to do that)

I recently ran autoremove through. It looked like it was removing some
of the old kernels. (I am not sure if running autoremove risks breaking
the system by accidentally deleting another package, assuming this works).

Either way never ran into any issue related to this nor did I hear
anyone ever having any problem with this. So my suggestion is to really
let this be. (unless we happen to stumble upon an elegant solution to
remove them)

Either way, not everybody who uses this distro are developers or very
experienced users. So pllease no disabling auto-updates for security
updates, that is a VERY bad idea.


3)
https://blueprints.launchpad.net/ubuntustudio-dev-tools/+spec/package-tracker-a
No problems that I can see (does this also mean we are moving our
package versioning system to git, or is that separate?)


4)
https://blueprints.launchpad.net/ubuntustudio-controls/+spec/improve-controls-a
This looks like what Len recommended we do before, but then again, not
my expertise area.


5) https://blueprints.launchpad.net/ubuntustudio-look/+spec/new-wallpaper-a
This looks good to me. I volunteered for doing this (unless somebody
desperately wants to)
Original discussion was to have these ready for 18.04, but I can adjust
to have them ready
by 17.10. Just let me know which deadline I am working toward and I'll
make it.


6)
https://blueprints.launchpad.net/ubuntustudio-default-settings/+spec/change-default-theme
This looks good to me.

In terms of HiDPI, we can add a separate blueprint about reviewing other
problems encountered in HiDPI. (in preparation for solving them by 18.04
latest)

the discussion earlier was a more long term issue review:
- Lack of scaling on OS level by application means many programs are
nearly unusuable. (old GTK2 software that is not maintained, and
anything java
based being the biggest problems right now - and no avoiding them is not
a viable option at the moment :) )
- GTK3 has better support for HiDPI
- GTK2 has SOME support for HiDPI (and ardour is not switching to GTK3)

All I can think in terms of actionable items is that

a) we should probably use GTK3 for any new code we write/maintain as
UbuntuStudio
b) keep an eye on ardour and any other software that uses GTK2 to file
bugs if they are well maintained, or find replacements.

Anything beyond that is probably out of the scope of what we can do. 




On 05/15/2017 11:31 PM, Ross Gammon wrote:
> And I forgot to say - it would be great to add suggestions to them and
> especially links to useful resources on the web, so anyone can pick
> one of the tasks up and "have a go!".
>
>
> On 15/05/17 22:28, Ross Gammon wrote:
>> OK - I have done the first draft of some blueprints for the Artful
>> 17.10 release based on Len's list. You can see them listed (with
>> links) under the "Current Development Release" section here:
>>
>> https://wiki.ubuntu.com/UbuntuStudio/Blueprints
>>
>> Alternatively, you can access them using the dependency tree on this
>> page:
>> https://blueprints.launchpad.net/ubuntustudio/+spec/ubuntustudio-topic-a
>>
>> I had some troubles incorporating all of the feedback from eylul &
>> lukefromdc, and 

[ubuntu-studio-devel] HiDPI (previously: Re: Next cycle)

[eylul]

*nods* GTK2 and java are the 2 major desktop env. independent culprits,
from what I can tell, which unfortunately are still around in many
applications.

Eylul


On 04/14/2017 12:32 AM, lukefro...@hushmail.com wrote:
> GTK3 itself brings hidpi support to its widgets. That means GTK3 desktops
> should support it. I only have 1920x1080 as my largest monitor, but 
> GtkInspector
> allows testing hidpi scaling, with 1.0 and 2.0 times default size options. I 
> can
> verify that this works in MATE for mate-panel and Caja (desktop/folder icons) 
> though double-sizing everything runs out of space fast on my monitor.
>
> GNOME (Ubuntu default), Cinnamon, and now MATE all use Gtk3 and should
> all offer at least partial hidpi support. Not sure if this works for 
> everything, and
> Gtk2 apps will remain problematic no matter what the desktop environment.
>
> On 4/13/2017 at 5:10 PM, "eylul" <ey...@ubuntustudio.org> wrote:
>> Len thanks for this. A lot of interesting thoughts here. Opinions, 
>> etc
>> ahead. :)
>>
>>> Auto mounting - we used to make sure there was no auto mounting 
>> of USB
>>> drives, cds or dvds. But since we have started borrowing 
>> xubuntu's
>>> desktop, that has come back in. IMO this is bad for audio use at 
>> least
>>> (anything auto is). However, I realize I am audio centric. How 
>> does
>>> this align with graphics/video use which are in general not real 
>> time
>>> or low latency tasks.
>> Yes, it is best for design/art people to have automount (its 
>> already
>> hard to bring design/art people to unfamiliar ground, more 
>> intuitive
>> behavior, the better), turning it off could be a good addition to 
>> the
>> -controls through if it is feasible? If not I think it is worth
>> discussing pros and cons and more details on what the problem is. 
>> If it
>> is seriously hindering audio creators, I'll take not hindering one 
>> side
>> in price of being a bit less intuitive to other side.
>>> Auto updating - same as above. But to add to it, I noticed that
>>> autoupdating installs new kernels in background. However, there 
>> seems
>>> to be no background old kernel clean up. I don't use efi myself, 
>> but I
>>> understand that efi uses a separate boot partition of minimal 
>> size and
>>> could become full with no warning... perhaps making updates or 
>> booting
>>> broken. I would guess this not just a Studio problem... though 
>> if it
>>> is then the solution must be hanging around already. Needs study 
>> in
>>> any case.
>> considering autoupdates fixes security issues among other things I 
>> would
>> go with they need to stay. In terms of the kernel issue, I do use 
>> efi, I
>> never ran out of space in that manner until now, but still filing 
>> a bug
>> about this could be useful?
>>> whisker menu - I still hate it :) But if we are going to keep it 
>> (I
>>> always go back to the system menu on my systems) can we at least
>>> resize it so that the menu categories are all visible by 
>> default...
>>> and enable hover so that click on category is not needed. I 
>> understand
>>> that having the search window there is nice for some people... 
>> but I
>>> just don't seem to come up with valuable search terms ever... my 
>> brain
>>> and whoever sets seach data just don't match. (probably means I'm
>>> abnormal)
>> My personal disagreement with this aside (I actually use the 
>> search bar
>> to launch a program often) :D I would caution against hover in
>> particular as it is a gesture that is inaccessible to touchscreens
>> (which are becoming more and more common on laptops). I assume 
>> this is
>> why whisker went with this approach actually.
>>> Can we change the default theme to Moheli or similar? There are 
>> two
>>> things I like in a theme:
>>> The window with focus stands out - menu bar is a different 
>> colour
>>> The border needs to be wide enough to be easy to grab
>>>
>>> More than one workpace by default - I understand that I may work 
>> a bit
>>> different than others doing development on more than one project 
>> at a
>>> time. It is not unusual for me to have 30 or more windows open 
>> at one
>>> time. IDEs do try to make things so this is not needed... but my
>>> workflow is just that way. This is why being able to resize 
>> windows
>>> and see which is focused are important.
>&

Re: [ubuntu-studio-devel] Next cycle

[eylul]

Len thanks for this. A lot of interesting thoughts here. Opinions, etc
ahead. :)

> Auto mounting - we used to make sure there was no auto mounting of USB
> drives, cds or dvds. But since we have started borrowing xubuntu's
> desktop, that has come back in. IMO this is bad for audio use at least
> (anything auto is). However, I realize I am audio centric. How does
> this align with graphics/video use which are in general not real time
> or low latency tasks.
Yes, it is best for design/art people to have automount (its already
hard to bring design/art people to unfamiliar ground, more intuitive
behavior, the better), turning it off could be a good addition to the
-controls through if it is feasible? If not I think it is worth
discussing pros and cons and more details on what the problem is. If it
is seriously hindering audio creators, I'll take not hindering one side
in price of being a bit less intuitive to other side.
>
> Auto updating - same as above. But to add to it, I noticed that
> autoupdating installs new kernels in background. However, there seems
> to be no background old kernel clean up. I don't use efi myself, but I
> understand that efi uses a separate boot partition of minimal size and
> could become full with no warning... perhaps making updates or booting
> broken. I would guess this not just a Studio problem... though if it
> is then the solution must be hanging around already. Needs study in
> any case.
considering autoupdates fixes security issues among other things I would
go with they need to stay. In terms of the kernel issue, I do use efi, I
never ran out of space in that manner until now, but still filing a bug
about this could be useful?
>
> whisker menu - I still hate it :) But if we are going to keep it (I
> always go back to the system menu on my systems) can we at least
> resize it so that the menu categories are all visible by default...
> and enable hover so that click on category is not needed. I understand
> that having the search window there is nice for some people... but I
> just don't seem to come up with valuable search terms ever... my brain
> and whoever sets seach data just don't match. (probably means I'm
> abnormal)
My personal disagreement with this aside (I actually use the search bar
to launch a program often) :D I would caution against hover in
particular as it is a gesture that is inaccessible to touchscreens
(which are becoming more and more common on laptops). I assume this is
why whisker went with this approach actually.
>
> Can we change the default theme to Moheli or similar? There are two
> things I like in a theme:
> The window with focus stands out - menu bar is a different colour
> The border needs to be wide enough to be easy to grab
>
> More than one workpace by default - I understand that I may work a bit
> different than others doing development on more than one project at a
> time. It is not unusual for me to have 30 or more windows open at one
> time. IDEs do try to make things so this is not needed... but my
> workflow is just that way. This is why being able to resize windows
> and see which is focused are important.
>
> I understand that xubuntu is aimed at mainstream either browsing or
> one other app fullscreen use and so the desktop we end up with
> reflects that. As content creators, how do the rest of us set up their
> desktops? Should changes be made? or am I really the odd one out?
for me as an artists its usually only one, or two windows (e.g. drawing
+ reference image), and often 2 windows means 2 screens if possible. (at
least that has been my experience so far). I need the screen estate to
see what I am doing, more often than not. When doing creative coding it
ends up more of a mess with language references, and code and preview
window etc. :) Usually through if I have 20 windows up, it is because I
have been getting distracted and doing 3 things at once (for which now I
am trying to use workspaces and KDE activities) Window focus/menu bar
aspect is not critical for me in either direction but hard to grab
borders are an issue regardless of how many windows one work with tbh.
(I have been using my own window styling in XFCE for a while now so I
didn't realize this was still a problem) TLDR, wouldn't oppose switching
themes if it will improve usability.

I am going to side track here, and say, combined with the previous
point, it might be a good idea for us to discuss how EXACTLY we use our
desktop and share experiences at some point and even reach out to our
users if we get the chance. That way we can hopefully find out what are
bottlenecks for a lot of people in terms of efficiency and what are
diverging personal choices. :)
>
> Also in the world of themes. Are there any high DPI or better variable
> DPI centric themes available? While I do not use a high DPI monitor
> (mine are only 1600X900), I would expect both graphics and video
> creators to use them... actually it would be very nice for mixbus-32c
> too. SO at least 

Re: [ubuntu-studio-devel] check-in and reminder release candidate on April 6th

[eylul]

Quick update: behind testing, but the release notes are up.

https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes/UbuntuStudio feel free
to add, remove, edit, etc to make sure we didn't miss any other changes.

Also, got in touch with Set about the website, both Krytarik and I have
administrator access, so we should be able to post tomorrow or when needed.

Thanks.

Best

Eylul


On 04/02/2017 11:52 AM, Ross Gammon wrote:
> On 03/31/2017 10:36 AM, eylul wrote:
>> I will be around for testing April 11,12,13th, and will be available in
>> chatroom the (european) evenings during that time. Will probably try to
>> do some more tests before that too if I can.
>>
>> I'll also start the notes so that we can all add items on it. (nag me if
>> it is not done by next tuesday). (unfortunately probably not much help
>> on development side tasks).
> Thanks for volunteering for that. It can easily be forgotten in the rush
> of testing the ISO images.
>
>> we should probably also email users ML to see if there is anybody who
>> can help us test there as well. :)
> Done - just now
>
>> On 03/30/2017 01:56 PM, Ross Gammon wrote:
>>> Thanks Eylul - you must have read my mind!
>>>
>>> On 29/03/17 20:43, eylul wrote:
>>>> Hi!
>>>>
>>>> Zesty release is right around the corner and we will have release
>>>> candidates out starting April 6th. Where are we with things? Who do we
>>>> have available to test the week of April 6th/13th?
>>>>
>>>> Best
>>>>
>>>> Eylul
>>> I am afraid I have availability problems for this particular release
>>> week. I might have some time on the 6th to test the first Release
>>> Candidate. And I should be back on the 13th to try and help with the
>>> release, but with no guarantee that I will have much time to spare.
>>>
>>> So it would be great to have some volunteers for testing one or two of
>>> the days during that week. Please reply to this message if you can,
>>> otherwise we might need to inform the Ubuntu Release Team that we
>>> would like to defer our release until after the Easter Holidays.
>>>
>>> There are also some tasks that I am aware of that we could be doing
>>> this week to help prepare for a good release.
> [...]
>
>>> Development:
>>> 1. Len did some excellent work on ubuntustudio-controls this cycle,
>>> but we needed to revert back to something like the state it was at
>>> Revision 128. I tried to do this, but may have made some mistakes
>>> (r130). It crashed when I tested it, and I haven't had time to get
>>> back on it. It may be too late to get a freeze exception for this, but
>>> if someone was keen to try.
> Prepared & waiting for the Release Team to confirm the Freeze Exception.
> We should maybe ping them on IRC next week.
>
>>> 2. There has been a mass rebuild of the archive, and there are a few
>>> build failures of our packages that someone could look into:
>>> http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170322.1-zesty.html#ubuntustudio
>>>
>>> http://qa.ubuntuwire.com/ftbfs/#ubuntustudio
>>>
>>> Testing:
>>> 1. No-one from the team (that I am aware of) did any real testing of
>>> the Final Beta, so the Ubuntu Release Team asked that we give the
>>> daily ISOs a good bash between now and the release:
>>> http://iso.qa.ubuntu.com/qatracker/milestones/369/builds
>>> 2. We could do with a smoke test of our important applications. There
>>> are test cases that can be used here:
>>> http://packages.qa.ubuntu.com/qatracker/milestones/370/builds
>>> Testing
>>> Please submit a bug if you find something bad, and let us know. Please
>>> also record your results if you found no problems, then others can
>>> decide to concentrate on untested ones if they are short of time.
>>>
>>> Bugs:
>>> Lots of people have already reported bugs against our packages:
>>> https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs
>>> Feel free to triage some of these bugs to see if any of our packages
>>> contain serious bugs, and let us know. There is some advice here for
>>> triaging bugs in Launchpad:
>>> https://wiki.ubuntu.com/Bugs/Triage/
>>>
>>> I hope we can all "muck in" and make it a good release!
> Do we have someone to man the website & blog about the release?
>
> Also, our support for the Ubuntu Studio Trusty 14.04 (LTS) release ends
> with the release of 17.04 (3 years). We should announce this here, the
> users list and on the website ahead of time.
>
> Cheers,
>
> Ross
>



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

Re: [ubuntu-studio-devel] check-in and reminder release candidate on April 6th

[eylul]

belated answer to this since my hosting service email system went down
yesterday.

I will be around for testing April 11,12,13th, and will be available in
chatroom the (european) evenings during that time. Will probably try to
do some more tests before that too if I can.

I'll also start the notes so that we can all add items on it. (nag me if
it is not done by next tuesday). (unfortunately probably not much help
on development side tasks).

we should probably also email users ML to see if there is anybody who
can help us test there as well. :)


Best

Eylul


On 03/30/2017 01:56 PM, Ross Gammon wrote:
> Thanks Eylul - you must have read my mind!
>
> On 29/03/17 20:43, eylul wrote:
>> Hi!
>>
>> Zesty release is right around the corner and we will have release
>> candidates out starting April 6th. Where are we with things? Who do we
>> have available to test the week of April 6th/13th?
>>
>> Best
>>
>> Eylul
>
> I am afraid I have availability problems for this particular release
> week. I might have some time on the 6th to test the first Release
> Candidate. And I should be back on the 13th to try and help with the
> release, but with no guarantee that I will have much time to spare.
>
> So it would be great to have some volunteers for testing one or two of
> the days during that week. Please reply to this message if you can,
> otherwise we might need to inform the Ubuntu Release Team that we
> would like to defer our release until after the Easter Holidays.
>
> There are also some tasks that I am aware of that we could be doing
> this week to help prepare for a good release.
>
> Release:
> We could prepare some release notes based on the last release
> (https://wiki.ubuntu.com/YakketyYak/ReleaseNotes/UbuntuStudio), and
> the Final Beta release
> (https://wiki.ubuntu.com/ZestyZapus/Beta2/UbuntuStudio). Then they
> would only need a final tweak and check on the day of the release
> (updating known bugs & package versions).
>
> Development:
> 1. Len did some excellent work on ubuntustudio-controls this cycle,
> but we needed to revert back to something like the state it was at
> Revision 128. I tried to do this, but may have made some mistakes
> (r130). It crashed when I tested it, and I haven't had time to get
> back on it. It may be too late to get a freeze exception for this, but
> if someone was keen to try.
> 2. There has been a mass rebuild of the archive, and there are a few
> build failures of our packages that someone could look into:
> http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170322.1-zesty.html#ubuntustudio
>
> http://qa.ubuntuwire.com/ftbfs/#ubuntustudio
>
> Testing:
> 1. No-one from the team (that I am aware of) did any real testing of
> the Final Beta, so the Ubuntu Release Team asked that we give the
> daily ISOs a good bash between now and the release:
> http://iso.qa.ubuntu.com/qatracker/milestones/369/builds
> 2. We could do with a smoke test of our important applications. There
> are test cases that can be used here:
> http://packages.qa.ubuntu.com/qatracker/milestones/370/builds
> Testing
> Please submit a bug if you find something bad, and let us know. Please
> also record your results if you found no problems, then others can
> decide to concentrate on untested ones if they are short of time.
>
> Bugs:
> Lots of people have already reported bugs against our packages:
> https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs
> Feel free to triage some of these bugs to see if any of our packages
> contain serious bugs, and let us know. There is some advice here for
> triaging bugs in Launchpad:
> https://wiki.ubuntu.com/Bugs/Triage/
>
> I hope we can all "muck in" and make it a good release!
>
> Cheers,
>
> Ross
>
> PS: I have probably forgotten something. Oh yeah - is there someone
> around from the website team to blog about the release once it happens?
>



-- 
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] check-in and reminder release candidate on April 6th

[eylul]

Hi!

Zesty release is right around the corner and we will have release
candidates out starting April 6th. Where are we with things? Who do we
have available to test the week of April 6th/13th?

Best

Eylul



-- 
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] Meeting Jan 17 19:30 UTC

[eylul]

Meeting minutes are here:

https://ubottu.com/meetingology/logs/ubuntustudio-devel/2017/ubuntustudio-devel.2017-01-17-19.31.moin.txt

next meeting will be in January 31st. as usual if you'd like to make it
to meetings but time doesn't work, please let me know. :)

Best

E.



On 01/17/2017 10:29 PM, eylul wrote:
> Happening now.
>
>
>
> On 01/15/2017 11:29 PM, eylul wrote:
>> There will be a meeting this week, even if it is a quick check-in.
>>
>> Jan 17, 19:30 UTC
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20170117T1930=1
>>
>>
>> 16.04.2 is coming up soon, and we have other updates I believe. :) If
>> you have an update you want to add but can't make to the meeting, feel
>> free to add to this thread.
>>
>> Best
>>
>> Eylul
>>
>>
>



-- 
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] Meeting Jan 17 19:30 UTC

[eylul]

Happening now.



On 01/15/2017 11:29 PM, eylul wrote:
> There will be a meeting this week, even if it is a quick check-in.
>
> Jan 17, 19:30 UTC
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20170117T1930=1
>
>
> 16.04.2 is coming up soon, and we have other updates I believe. :) If
> you have an update you want to add but can't make to the meeting, feel
> free to add to this thread.
>
> Best
>
> Eylul
>
>


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

[eylul]

Ok I think I see better what your objection is. I do fully agree with
keeping the interface as simple as possible.

The main concern i have is that, for the basic user, there is a fine
line between keeping it simple and user getting stuck in presets that
doesn't work for them with no recourse except very advanced solutions
that are not accessible to them. For example the point xruns happen
depends from hardware to hardware (unless I misunderstand). Similarly
the 44.1k vs 48k issue depends on if the user uses more professional
hardware or hobbyist tools to do their work. Then adding cases where
users might have external soundcards (or soundcard like devices) or
those that don't. We simply cannot offer a preset for every possible
case, not without having a giant list, which would be a lot more opaque
and still not cover every case. I mean in an ideal world we would have a
database of devices recognized, and have smart presets that does that,
but we simply do not have resources to do it, not in short term at least.

It is easy for us linux veterans in open source communities to find
writing a startup script from scratch as an easy and straightforward
solution, but believe me that is not the case for a lot of people out
there. :) Allowing the user to tweak the presets with guidance in the UI
is a good solution we can offer. They might not be able to tweak the
settings by themselves and understand but at least when they come to
forums or IRC, there is a place where they can be guided without a lot
of explanation.

What makes it approach useful vs fish and fowl, is in how we execute it.
I do agree that we need to be careful to not overdo with customization
options. I don't think we are there yet with overly complicated. All the
same, I would watch carefully and ask for a lot of feedback from a
variety of users when we put this out in the wild, and what type of
support requests we get, whatever we end up deciding.

I think what you are suggesting is that we are not creating a DAW here
like Cubase or Logic Pro, and I agree, it is not the same approach. I
was curious if there was a commercial software similar to JACK that you
were referring to. The idea here is that jack is part of the audio
setup, rather than something solely used for audio specific software,
which is a different approach.

In terms of Jack MIDI - ALSA MIDI bridges, etc, that is something that
is indispensable for those of us who works regularly with a midi
keyboard regardless of expertise level. It was one of the first things I
had to figure out when creating my own setup. :)

Actually writing this I just realized: The clarification that was
missing until now is that we are not only targeting users who record
audio input in a professional or semi professional studio setup, but
also composers who work with midi (or a mixture of midi and recorded
sound), those who do creative coding with live performances, those who
prepare podcasts. All of which need jack for audio connectivity, but not
necessarily in the same way. :)

Best

Eylul


On 01/16/2017 12:10 AM, Ralf Mardorf wrote:
> On Sun, 15 Jan 2017 22:16:40 +0300, eylul wrote:
>> I'd rather not call inexperienced users, or people who don't have a lot
>> of time to go read "lazy". They are users all the same. Not everybody
>> has to become experts.
> Correct and that's why those users want an easy to use GUI, without
> cryptic options and especially without options that don't make sense at
> all.
>
>> Anyway the solution for such users is profiles (from your suggestion we
>> will have 2 or 3). Ideally a beginner user will not have to create or
>> modify their setup at all.
>>
>> This next level of complexity is for users who need a little bit more
>> customization due to their specific hardware or simply use cases we
>> haven't thought of, yet doing so without having to go to scripting and
>> still with tools to easily make decision. It is also a good place to
>> start understanding the underlying structure for the user who wants to
>> learn more.
> Wrong! This would be a "neither fish nor fowl" strategy. Provide sane
> defaults without options that actually just cause doubts, by those
> using defaults, because they don't understand the details. The clueless
> user wants the Apple approach, the experienced user wants the Linux
> approach. Both have in common to follow a clear KISS principle. If you
> mix both approaches, the result is crap.
>> In terms of commercial solutions UIs you are referring to, can you
>> clarify which products you are thinking of? or if possible at all
>> screenshots would be helpful. While we don't want to copy verbatim
>> design solutions, it is helpful to know what people switching from
>> industry standard commercial software to ubuntustudio would expect to
>> find.
> In regards to sample rate, la

[ubuntu-studio-devel] Meeting Jan 17 19:30 UTC

[eylul]

There will be a meeting this week, even if it is a quick check-in.

Jan 17, 19:30 UTC
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20170117T1930=1


16.04.2 is coming up soon, and we have other updates I believe. :) If
you have an update you want to add but can't make to the meeting, feel
free to add to this thread.

Best

Eylul


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

[eylul]

I'd rather not call inexperienced users, or people who don't have a lot
of time to go read "lazy". They are users all the same. Not everybody
has to become experts.

Anyway the solution for such users is profiles (from your suggestion we
will have 2 or 3). Ideally a beginner user will not have to create or
modify their setup at all.

This next level of complexity is for users who need a little bit more
customization due to their specific hardware or simply use cases we
haven't thought of, yet doing so without having to go to scripting and
still with tools to easily make decision. It is also a good place to
start understanding the underlying structure for the user who wants to
learn more.

In terms of commercial solutions UIs you are referring to, can you
clarify which products you are thinking of? or if possible at all
screenshots would be helpful. While we don't want to copy verbatim
design solutions, it is helpful to know what people switching from
industry standard commercial software to ubuntustudio would expect to find.

Best

Eylul


On 01/15/2017 08:14 PM, Ralf Mardorf wrote:
> On Sun, 15 Jan 2017 17:22:12 +0100, Dennis Schulmeister-Zimolong wrote:
>> Hi Ralf,
>>
>> On Sun, 15 Jan 2017 16:56:52 +0100
>> Ralf Mardorf <ralf.mard...@alice-dsl.net> wrote:
>>
>>> For experienced audio users and novices willing to learn your app is
>>> crap. The target group are users who don't have a clue and who are
>>> unwilling to learn. You need to make it easy for them, but actually
>>> you make it harder, by mixing jack settings, with settings that are
>>> not directly related to jack and by providing the same choice jack
>>> provides. Don't!
>>>
>>> Provide a first choice, 1. music production, 2. other
>>> audio productions (radio etc.) and 3. audio for anything else. Don't
>>> provide to chose between PA bridge and things like this. Disable PA
>>> for music production and enable it for other audio productions and
>>> don't launch Jack at all, for anything else.  
>> I can't help but find your answer here unfair and biased. All in all I
>> think the proposed UI really helps to make things easier, not only for
>> people who are "too lazy to learn the details" and options like ALSA
>> MIDI or PA bridge are not as unreasonable as you think. They are
>> options anyway.
>>
>> I agree with you on the 32-bit bit depth setting. Other than that I
>> like the proposed UI much better than what you are suggesting here. In
>> fact your proposal is an even more "dumb" UI. What's the difference
>> between music and audio production anyway? Where do you know from, that
>> I don't also need low-latency in an audio production context? Or that I
>> don't need to listen to some web-audio on my monitor speakers while
>> working on a new song? You don't, and that's why the original proposal
>> gives me the choice to enable the features I want, while striping away
>> some of the more obscure jack parameters.
>>
>> Dennis
>>
> Hi,
>
> the available options require some additional short information, but
> apart from this, noob-friendly GUIs provided by the most successful
> proprietary platforms work the way as I suggested. If expert
> options are needed, then this app makes no sense at all, especially in
> regards to low latency, there's a lot more to take into account.
> Btw. before writing an application, it's most important to have a clear
> idea about what it should provide and for what purpose it should be
> provided. To conceptualize when already writing the app is the ultimate
> guarantor that "you" or somebody else ask yourself "how does you know,
> what I need?". Asking this questions actually means, that at best you
> know what you need, but maybe you even don't know this, but you
> definitively don't care about a target group, for an app that should
> provide settings, that are fundamental part of the distro.
>
> If you keep the other options as are, then you could also provide a
> selection of bit depth. Some combinations, for some tasks and for some
> target groups simply don't make sense. The "how do you know?" question
> is part of a concept.
>
> When producing music, it makes not much sense to listen to web radio at
> the same time. If you produce web radio, it could make sense for
> comparison purpose, hence "Provide a first choice, 1. music production,
> 2. other audio productions (radio etc.) and 3. audio for anything
> else". Apart from the pre selected pulseaudio or no pulsaudio, the used
> frames could still be chosen, so in this regards latency isn't
> affected. If you really want to fine tune, optimize latency, then start
> with building a rt patched kernel, unbind devices, stop unneeded
> services ...
>
> Regards,
> Ralf
>



-- 
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] Meeting Dec 20th 19:30UTC

[eylul]

Reminder, meeting in a few minutes! :)

Best

Eylul


-- 
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] weekly meeting Dec 6

[eylul]

Thanks for letting us know Ross.

It was just me and Krytarik this week. Meeting minutes below. (apologies
for meetingology artifacts on the log we did have a couple of technical
hiccups :D)

Next week's meeting will be at at 20 Dec 2016, 19:30UTC.

(https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20161220T1930=1)

As usual please let me know in this thread, if you want to attend but
time doesn't work. Also please feel free to add agenda items, updates,
summaries etc, before the meeting, and we will put them on the log
during the meeting. :)

See all of you next week.

Best

Eylul

---

== Meeting information ==
 * #ubuntustudio-devel: "UbuntuStudio weekly check-in", 13 Dec at 19:10  
20:04 UTC
 * Full logs at 
[[http://ubottu.com/meetingology/logs/ubuntustudio-devel/2016/ubuntustudio-devel.2016-12-13-19.10.log.html]]



== Meeting summary ==

=== Welcome and Agenda ===
The discussion about "Welcome and Agenda" started at 19:21.

 * '''meetingology''' (19:21)
 * '''Agenda''' (19:21)

=== Team updates ===
The discussion about "Team updates" started at 19:24.

  * not much from me this week, just some UI brainstorming with OvenWerks on 
-controls.
  * OvenWerks has been working on ubuntustudio-controls, see the ML for details 
of progress.
  * CFHowlett is working on a dry run of image uploads for the wallpaper contest

=== Active Projects ===
The discussion about "Active Projects" started at 19:33.

 * '''Ubuntustudio-controls''' (19:33)
 * '''website''' (19:50)
  * ''ACTION:'' Sakrecoer or Krytarik will email Community Council about the 
issue of ignored ticket. (pending approval from Sakrecoer as project lead)
 * '''Wallpaper contest''' (19:56)

=== Todo for next week and milestones ===
The discussion about "Todo for next week and milestones" started at 20:02.

  * Next meeting will be at 20 Dec 2016, 19:30UTC. 
(https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntustudio+meeting=20161220T1930=1)


On 12/11/2016 09:25 PM, Ross Gammon wrote:
>
> I can't make it this week due to work
>
>



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

[eylul]

Len,
Lets assume I am an user. :)
I want to create a new boot setup (with system tweaks). I have to set up
the system tweaks, twice on each tab. (or change the boot setup, then be
mystified why settings aren't affected as I change them).

Similarly presets doesn't help me at all, if I want to switch back and
forth between 2 setups.(unless I want a preset change that also affects
audio setup AND tablet setup AND boot setup). I have to change things
manually to use the in session tweaks (and potentially look up every
time what correct setting is).

This is why it is important that the system tweaks are its own profile,
where there can be a default one to use in boot.

Similarly the current preset solution requires me to recreate the audio
setup (and graphics setup) each time I create a preset for any reason.
It makes much more sense for these to have their own profiles, and
having a default one on boot. (then underlying structure can deal with
issues like: does this mean jack is started on boot or not).

Also each of these have different change rates:
* Boot decision is something that will likely rarely change.
* For audio: there might be a couple of profiles that switches back and
forth (for 2 recording setups with different sample rates, or a graphics
or gaming profile that turns off zita to avoid extra processing power
waste. :D)
* Graphic tablet setup on the other hand, ideally changes every time one
switches software! (one of the primary aspects of more professional
tablets is that they have shortcuts buttons on the side and most
artists/designers like to adjust them to various shortcuts by program
basis. Some open source programs do allow their own overrides but not all)

Ralf is right in that too many choices will cause more user problems in
the end, and that the GUI needs to be arranged based on how users
perceive what they are doing, rather than how we know things actually
work under the hood. Some extra options (in this case, under the ability
to create a profile) for advance user will be there but even then it
needs to not assume user knows what happens under the hood.

E.g.: checkbox to change CPU profile to performance: What is my CPU
profile when it is unchecked? (ergo, why I had a drop down menu for
selecting CPU profile in my wireframe).

I hope these are helpful, rather than discouraging. By the way 2
relevant concepts to this design discussions.
https://en.wikipedia.org/wiki/Decision_fatigue
https://en.wikipedia.org/wiki/Pareto_principle (80/20 rule)

I'll try to finish a layout draft based on what you sent, later today. :)

Best

Eylul


On 12/07/2016 08:13 AM, Ralf Mardorf wrote:
> Don't try to solve user problems that don't exist!
>
> Consider to join the Ubuntu users and some Ubuntu flavour users mailing
> lists.
>
> On Tue, 6 Dec 2016 16:09:39 -0800 (PST), Len Ovens wrote:
>> Audio setup:
>>  Master audio interface
>>  Second choice master (disable unless master is USB)
>>  sample rate (default to 48000)
>>  On USB Audio plugin set USB AI to jack master enable
>>  Choose if other audio IFs should autorun zita-ajbridge
>>  Jack runs at boot enable (this should be default for Studio)
> Apart from the fact, that it might conflict with Linux howtos, a
> beginner would be overwhelmed. What is a master interface, what is zita?
>
> What files will be overwritten?
> .config/rncbc.org/QjackCtl.conf? /etc/modprobe.d/alsa-base.conf? 
> /etc/default/rtirq? ...?
>
> Less is more. An advantage of Linux are human readable and
> writeable configurations and a good documentation. Another advantage is
> that Linux requires some amount of self-responsibility, such as reading
> the fine manual.
>
> Constructs like "Second choice master (disable unless master is USB)"
> are an indication for a bad GUI running wild.
>
> GUIs not necessarily make things easier for the inexperienced user,
> they could make things more complicated.
>
>>  /etc/init.d/ubuntustudio-controls would be the actual file
>> that set system things during boot
> Ubuntu now only supports systemd and no other init system,
> so /etc/init.d is an approach against the Ubuntu policy. Ubuntu
> flavours must follow the Ubuntu policy. It is planned to replace all
> init scripts by systemd units, not to add additional init scripts. The
> latest release even doesn't give the choice between upstart and
> systemd anymore, only systemd is available. There still is init script
> compatibility, but systemd is not only the default, in addition upstart
> can't be chosen anymore, it doesn't exist anymore.
>
> Regards,
> Ralf
>



-- 
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] Meeting Tuesday, Nov 29 at 19:00 UTC

[eylul]

Yeah, the meeting announcement was directly via email, which is why I
used the

https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntu+Studio+Meeting=20161129T19=1

format in my initial email when linking to the world clock.

The link format you mentioned is a good one to keep in mind through if
we get more serious with meetings in future and have agenda at the wiki
etc. So thanks for the suggestion! :)

Looking forward to see everyone on tuesday. :)

Best

Eylul


On 11/27/2016 08:45 PM, Ralf Mardorf wrote:
> On Sun, 27 Nov 2016 13:11:40 +0100, Set Hallstrom wrote:
>> Thanks for your feedback Ralf.
>> How does one put such a a nifty link in a text-mail?
> My apologies,
>
> I wasn't clear with this.
>
> If Ubuntu announces a meeting, they sometimes link to a web site, e.g.
> for a video conference and this website includes the clock.
>
> The clock in the upper left corner at
>
> http://summit.ubuntu.com/uos-1611/meeting/22714/architecture-discussions/
>
> links to
>
> http://www.timeanddate.com/worldclock/
>
> Assuming a user shouldn't fake the IP, then for an email
>
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntu+Studio+Meeting=20161129T19=1
>
> is the better choice.
>
> Regards,
> Ralf
>



-- 
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] Meeting Tuesday, Nov 29 at 19:00 UTC

[eylul]

Hi everyone,

We will be doing a check-in meeting at Tuesday, Nov. 29 at 19:00UTC
(what time is this for me?
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=Ubuntu+Studio+Meeting=20161129T19=1>)

This is optional but something that some of us find useful to keep
working regularly toward Zesty. Feel free to drop by if you can make it. :)

Best

Eylul

PS: if you can't make it to this hour but really do want to make it to
meetings let us know and we'll see what we can do. :)



On 11/09/2016 09:02 PM, Ross Gammon wrote:
>
> My availability chops and changes week on week depending on work and
> family commitments, but I will try and make it as often as I can.
>
> 16:00 - 22:00 (UTC) weekdays, 9:00 - 22:00 (UTC) stand the best chance.
>
> Cheers,
>
> Ross
>
> On 08/11/16 00:25, eylul wrote:
>> Best times for me are 13:00-16:00(CET) and 19:00 - midnight(CET) any
>> day of the week. I can adjust to a bit before or after these times,
>> if needed through. :)
>>
>> Eylul
>>
>> On 11/06/2016 05:11 PM, Set Hallstrom wrote:
>>> Hi list!
>>>
>>> So it seems from the "17.04 cycle" thread that we are all going to be
>>> busier than we have been the past cycle. Eylul suggested we set-up
>>> regular IRC meeting and i think it is an excellent idea. It would make
>>> our lives easier.
>>>
>>> I wish we could have them on a weekly basis, and if I may express a
>>> preference, it would be Sundays evening CET. But i reckon we need to
>>> find a common ground... The only times i can absolutely _not_ is
>>> weekdays (mon-fri) between 2am and 6pm CET.
>>>
>>> How about you guys?
>>>
>>>
>>>
>>
>>
>>
>
>
>

-- 
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] Art Team! 10th Birthday Wallpaper Contest

[eylul]

This looks great overall! Now some comments:

1) works should also be licensed with an open license. (we can narrow
that down further to something like CC-SA, CC and CC0 and GPL only)
Submitters should at least specify what the license is if not add a copy
of the license file.

2) any source images or resources used must also be either original
work, or compatible with the license of the work they are submitted, and
credited if the open license of the 3rd party source requires it so.
This might not be necessary to clarify in announcement but when
submitting the work the artists explicitly confirms they have not used
anything that is not properly licensed, and we should have a place for
them to add the 3rd party credits. This should also prevent people from
using photographs that they don't own as basis of their work.

3) The whole "this must be original artwork no photography" part is
jarring (and is likely to cause offense) considering photography is art.
Using photography is not some bad thing, its just not what we want in
this contest :) So, instead of a "no photography" how about clarifying.

"General Guidelines

The contest is open to paintings and illustrations created with any open
sourced 2-D and 3-D software. Both representative and abstract works are
allowed.

Submissions must include sourcefiles..."

I hope these ideas help, and thanks again for working on this. :)

Best

Eylul


On 11/21/2016 10:36 AM, C. F. Howlett wrote:
> Hey UbuntuStudio:
>
> I'm preparing to run a wallpaper contest for the 10th Year of Ubuntu 
> Studio (17.04 for those who were unaware).
>
>
> I learned some valuable lessons from the 16.04 contest so this time will 
> be a bit different in the hopes of yielding some truly outstanding 
> results.  Please review the draft announcement below and provide feedback.
>
>
> *
>
>
> Digital Artist Call
> Ubuntu Studio 17.04 Wallpapers
>
> Would you like YOUR artwork to be prominently featured on millions of 
> desktops?  Yes?  Read on!
>
> With the forthcoming 17.04 release, Ubuntu Studio, the Linux for 
> Creative Humans, celebrates Ten (!) years of life!  We ask your help to 
> polish the look and feel of our favorite OS.  Over the next few months, 
> we will call on your brains and creative impulses.  Here’s one way YOU 
> can add your own special flair; create, design and submit a 
> custom-designed US desktop wallpaper!
>
> General Guidelines
>
> Only ORIGINAL art will be considered – no derivatives
> NO photographs!  (But photo-realistic creations are acceptable.)
> Art must be created in open-source software, e.g. those included Ubuntu 
> Studio.
> Submissions must include source files.
> One or more of the general work-flow elements (audio, graphics, video) 
> must be incorporated in the design.  Liliu Hua, an UbuntuKylin artist, 
> did this quite elegantly.  Zoom in to see the magic. [url filtered] Look 
> closely.
> Only ONE submission per artist.
>
> Ten wallpapers will be selected and packaged for 17.04.  The submission 
> deadline is February 28th, 2017.
>
> Additional technical specifications can be found on the Art Team wiki. 
> [url filtered]
>
> You can view previous contributions at the Ubuntu Studio Flickr 
> collection. [url filtered]
>

-- 
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] Fwd: Re: Ubuntu Online Summit: Call for sessions

[eylul]

This is a good idea.

E.

On 11/09/2016 09:13 PM, Ross Gammon wrote:
>
> Would it be an idea to propose a blueprint session for UOS to discuss
> plans?
>
>
>  Forwarded Message 
> Subject:  Re: Ubuntu Online Summit: Call for sessions
> Date: Wed, 9 Nov 2016 10:10:14 +0100
> From: Daniel Holbach 
> To:   ubuntu-community-t...@lists.ubuntu.com, Ubuntu Developers
> 
>
>
>
> Hello everbody,
>
> On 02.11.2016 17:21, Daniel Holbach wrote:
> > as announced a few weeks ago, Ubuntu Online Summit is going to happen
> > 
> >   15-16 November 2016
> > 
> > and all details are going to be up on http://summit.ubuntu.com/
> > 
> > Now is a good time to register
> > (http://summit.ubuntu.com/uos-1611/registration/) and add your sessions
> > (http://summit.ubuntu.com/getinvolved/propose-a-session/).
> > 
> > If you have any questions, reach out to myself, Michael Hall or Alan Pope.
>
> here's another friendly last-minute nudge. Get your sessions in!
>
> Have a great day,
>  Daniel
>
> -- 
> Get started with Snapcraft! Check https://snapcraft.io
> Follow @snapcraftio on twitter.com/facebook.com/G+
>
> -- 
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-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: [ubuntu-studio-devel] Weekly IRC meetings

[eylul]

Best times for me are 13:00-16:00(CET) and 19:00 - midnight(CET) any day
of the week. I can adjust to a bit before or after these times, if
needed through. :)

Eylul

On 11/06/2016 05:11 PM, Set Hallstrom wrote:
> Hi list!
>
> So it seems from the "17.04 cycle" thread that we are all going to be
> busier than we have been the past cycle. Eylul suggested we set-up
> regular IRC meeting and i think it is an excellent idea. It would make
> our lives easier.
>
> I wish we could have them on a weekly basis, and if I may express a
> preference, it would be Sundays evening CET. But i reckon we need to
> find a common ground... The only times i can absolutely _not_ is
> weekdays (mon-fri) between 2am and 6pm CET.
>
> How about you guys?
>
>
>

-- 
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] debian package for Krita

[eylul]

Ross,

Thanks for this explanation. :) Will start with contacting with Kubuntu
Team then.

Best

E.

On 11/02/2016 10:46 PM, Ross Gammon wrote:
>
> Hi All,
>
> Krytarik (via Set) pointed me to a Release Team conversation on IRC
> about Krita just before the Yakkety release. Apparently it was Failing
> To Build From Source (FTBFS).
>
> From memory, it is complicated because krita is moving from one source
> package to another (calligra to somewhere else). Also, the calligra
> package has an epoch in the version (1:2.9.11-0ubuntu2
> <https://launchpad.net/ubuntu/+source/calligra/1:2.9.11-0ubuntu2>),
> which means that it is never automatically synced from Debian. It is
> effectively maintained in Ubuntu.
>
> I think it would be best to get in touch with the Kubuntu Team to find
> out what they know.
>
> Regards,
>
> Ross
>
>
> On 02/11/16 16:02, eylul wrote:
>> Hi Len!
>>
>> the current situation is: there is a krita package that has krita 3.0.1
>> that is stuck in debian new package queue.
>>
>> Calligra package lost, then regained the old version of Krita (2.9.x)
>> from what we can tell. (most of this hit the ubuntu repos the week of
>> release)
>>
>> Not sure if this helps explaining
>>
>> Eylul
>>
>>
>>
>> On 11/02/2016 05:56 PM, Len Ovens wrote:
>>> On Wed, 2 Nov 2016, treb...@tuxfamily.org wrote:
>>>
>>>> ... zip ...
>>>>> Is there any contact on debian side we can reach out to, to help get
>>>>> the
>>>>> package approved?
>>>>>
>>>> ... zap ...
>>>>
>>>> All the information you need at this point are here :
>>>> https://packages.qa.debian.org/c/calligra.html
>>>>
>>>> Hope that helps.
>>> I am more confused than ever. My understanding (possibly wrong) was
>>> that there was now a version of Krita That did not require (or
>>> include) Calligra. So a pointer to a page about Calligra makes no sense.
>>>
>>> It is this version of Krita without the no longer supported Calligra
>>> we are interested in, not Calligra itself.
>>>
>>> Clear as mud...
>>>
>>> -- 
>>> Len Ovens
>>> www.ovenwerks.net
>>>
>>>
>
>
>

-- 
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] debian package for Krita

[eylul]

Hi Len!

the current situation is: there is a krita package that has krita 3.0.1
that is stuck in debian new package queue.

Calligra package lost, then regained the old version of Krita (2.9.x)
from what we can tell. (most of this hit the ubuntu repos the week of
release)

Not sure if this helps explaining

Eylul



On 11/02/2016 05:56 PM, Len Ovens wrote:
> On Wed, 2 Nov 2016, treb...@tuxfamily.org wrote:
>
>> ... zip ...
>>>
>>> Is there any contact on debian side we can reach out to, to help get
>>> the
>>> package approved?
>>>
>> ... zap ...
>>
>> All the information you need at this point are here :
>> https://packages.qa.debian.org/c/calligra.html
>>
>> Hope that helps.
>
> I am more confused than ever. My understanding (possibly wrong) was
> that there was now a version of Krita That did not require (or
> include) Calligra. So a pointer to a page about Calligra makes no sense.
>
> It is this version of Krita without the no longer supported Calligra
> we are interested in, not Calligra itself.
>
> Clear as mud...
>
> -- 
> Len Ovens
> www.ovenwerks.net
>
>


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

[eylul]

One nitpick I would have is to perhaps in audio, graphics, video scenes,
maybe darken the screenshots so that the text is a little more visible.
(not a lot, just a tiny bit).

Overall this looks really nice through!!! We could put this into the
front page as it is! :)

Eylul


On 09/10/2016 10:19 PM, Set Hallstrom wrote:
> lördagen den 10:e september 2016 kl. 21:03:49 CEST, One Chamois
> <onecham...@gmail.com> skrev:
>> Hello everyone!
>>
>>
>> https://youtu.be/_Q2qA6JZl8g
>
>
> holy  kazo!
>
> wow! ... WOW! short, precise, good looking and loopable!
>
> i'm in awe, so my spontaneous reaction is 'awesome'! :) <3
>
>


-- 
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] Image copyright information and website

[eylul]

Hi Geirdal,

I know you are busy :), but could you give us the attribution links for
the photographs and other 3rd party resources you used to create the
website background images, sometime this week? Even if they are public
domain, it would be best to have the record of that somewhere, and if
they are creative commons, we need to be able to attribute them.

Also would everybody have any objections to getting the new site moving
out of stage to ubuntustudio.org, sometime before the end of this week?

Best

Eylul



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

[eylul]

Hi!

So, the bulk of the website is done, and it would be great to deploy it 
before we have to focus on the release. This gives us until the end of 
September or so.


Below is an overview of what needs done. Feel free to add to this.


TODO BEFORE DEPLOY:

* We need the links/licenses on stock images used in creation of the 
background images, before we can put the site up. Even if these are 
CC-0, it is best to have that information stored somewhere. If they are 
other forms of creative commons, depending on the license we might need 
to credit them.


The keyboard photo belongs to Set. Geirdal could you give us links to 
the rest of stock photos you used, so that we have a record of that 
information?



CONTENT REVIEW:

A good portion of the content of the website has either been 
substantially edited, or written from scratch. Here is a list of all 
static pages, with some notes where extra scrutiny is especially needed.


Could we commit to finish this review by end of August?

0) General:

* is the footer correct?

* is the menu correct?

* are we missing any critical pages or content before putting up the site?

1) Front page: http://www.ubuntustudio.zequence.net/

* is "downloads" link working?

* are social media accounts correct?

* feature tour and general information had a few eyes on it already, but 
it wouldn't hurt to review.


2) Downloads: http://www.ubuntustudio.zequence.net/downloads/

* are links working? (especially the ones to 16.04).

* the text is copy pasted and reformatted from the current site, but it 
can use a quick review.


3) Support: http://www.ubuntustudio.zequence.net/support/

Contribute: http://www.ubuntustudio.zequence.net/contribute/

* double checking of outside links, especially making sure webchat and 
mailing list links work.


* these two went through some reviewing already but there are also new 
content. Thus, it wouldn't hurt to check.


4) Merchandise: http://www.ubuntustudio.zequence.net/merchandise/

* is the "legal" section information correct?

* any other missing/incorrect information?


PLUGIN AND THEME

* From what I understand, we do need to have the Live Compositor plugin 
and the child theme uploaded to the main site, before we can move the 
content.



Thanks :)

Best,

eylul



--
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] Hellotux shop

[eylul]

Hi!



I really love the home page you did. However, for the rest of the 
website, I would go with a white background under dark text, even if 
the general background is dark. Yes, many applications we have in 
Ubuntu Studio have a dark theme, but a website is not a 
terminal/application and perhaps you should should try a more "easy to 
read" style ;-)


Actually there can be arguments made for both dark and light backgrounds 
for readability. Some (about half of people) prefer light backgrounds, 
and a lot of sites uses dark text on white, true. :) However, there is 
still value for dark on light layouts if carefully done, especially in 
terms of less strain on eyes when reading, for text heavy content.


A white layer on dark with dark text is probably not the best through 
regardless, if I am understanding your suggestion correctly, in that it 
would be a contrast on the borders that competes with the content for 
user's focus. There is also an argument to be made to not switch layouts 
and color schemes that drastically between pages (more so than we have 
already done anyway). :)




Is it based on Wordpress too ? Will you ask to Canonical to host it ?



Its Wordpress, and it will be hosted at ubuntustudio.org, so I guess yes?

Best

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