Re: Changing version scheme for the evolution projects

[Sasa Ostrouska via desktop-devel-list]

On Fri, Oct 21, 2022 at 7:55 AM Milan Crha via desktop-devel-list
 wrote:
>
> On Mon, 2022-09-19 at 08:21 +0200, Milan Crha via desktop-devel-list
> wrote:
> > Maybe.
>
> Hi,
> just to close this thread with a conclusion: there had been multiple
> opinions (I received some also as private responses), and because I do
> not have any strong reason for the change and the most opinions were in
> a way "why to make any change", thus I decided to _not_ change anything
> and keep the versions as it is now.
> Bye,
> Milan

Hi, good to hear that. Thanks.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.34.4

[Sasa Ostrouska via desktop-devel-list]

On Wed, Feb 19, 2020 at 7:55 PM Michael Catanzaro  wrote:
>
> On Wed, Feb 19, 2020 at 11:57 am, Matthias Clasen via release-team
>  wrote:
> > There next (and last) stable 3.34 update is planned for end of
> > March, see https://wiki.gnome.org/ThreePointThirtyfive
>
> Small correction: we're going to be doing something new and continuing
> 3.34 releases through the 3.38 development cycle, up until the release
> of 3.38. That is, we're going to be supporting two stable releases at a
> time. This is to provide extended support for the GNOME runtime.
>
Hi Michael

If I understood it correctly this will be a very positive and good
thing in my opinion.
So we will end up having 3.34.x releases for the period of other year or so.
But wont this be something making people prefer a newer release like 3.36.x
series over the 3.34.x ?

Rgds
Saxa
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Sound Juicer support and/or EoL

[Sasa Ostrouska via desktop-devel-list]

On Tue, Dec 3, 2019 at 11:14 PM Kevin Degeling  wrote:
>
> Hey All,
>
> After reporting an issue related to Sound Juicer, I discovered that the 
> project has been mostly abandoned. There is still a valuable pull request 
> open (https://gitlab.gnome.org/GNOME/sound-juicer/merge_requests/2) but for 
> the most part active maintainance has stopped. This puts the application on a 
> crossroads:
>
> - Approve pending pull requests and assign a new owner, if only for minimal 
> maintainance.
> - End of Life the project, and inform all downstream projects (Fedora, Ubuntu 
> et al) te remove it from their repositories in future releases.
>
> I lean towards the first. The application is mostly functional so I wouldn't 
> throw the baby out with the bath water. A few small patches (Like the one 
> linked) can keep it going for a few more years.
>
Hi, yeah I think that the problem today is that cd rip and burning for
music is a bit outdated, probably would be better to transform it to a
phone transfer
music app or a burning to USB one. YOu know what I mean, but surely
its a nice app, I used it in the past quite some.

> Kind regards,
>
> Kevin
>
> ps. First time ever on a mailing list, so please let me know if I'm way to 
> formal or if I make a very Dutch impression.
Welcome, all was ok :)
Rgds
Saxa

> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python 2 support in GNOME build tools

[Sasa Ostrouska via desktop-devel-list]

On Wed, Jul 25, 2018 at 8:30 PM, Nirbheek Chauhan <
nirbheek.chau...@gmail.com> wrote:

> On Wed, Jul 25, 2018 at 11:56 PM Sasa Ostrouska  wrote:
> >
> > Hi I don't know how this is relevan, but since I am building gnome for
> Slackware, I want to advise that we will also have in Slackware next release
> > Python3 as up to the 14.2 release there is only python2.
> >
>
> I'm not sure what you mean, Slackware has had Python 3 for a very long
> time, fwict it has been available since 13.37 which was released in
> 2011: https://slackbuilds.org/repository/13.37/python/python3/
>
> Hi, slackbuilds.org is not official slackware package, and not always is
updated and keept up with all the security patches. What I mean is that
from Slackwares next stable release
we have python3 distributed with the official slackware release, which was
not the case up to now.

In dropline gnome we had in the past to build up our ownpackage of python3.


> Cheers,
> Nirbheek
>
Rgds
Saxa
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python 2 support in GNOME build tools

[Sasa Ostrouska via desktop-devel-list]

Hi I don't know how this is relevan, but since I am building gnome for
Slackware, I want to advise that we will also have in Slackware next release
Python3 as up to the 14.2 release there is only python2.

Rgds
Saxa

On Wed, Jul 25, 2018 at 5:42 PM, Christoph Reiter via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Thanks everyone for chiming in!
>
> I think we have all distros/OSes covered now and can make an informed
> decision based on that.
>
> I've opened a proposal MR for glib to drop Python 2 support
> https://gitlab.gnome.org/GNOME/glib/merge_requests/196
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Build situation and BuildStream

[Sasa Ostrouska]

On Wed, Apr 26, 2017 at 8:51 AM, Tristan Van Berkom <
tristan.vanber...@codethink.co.uk> wrote:

> Hi Sasa,
>
> Hi Tristan !


> On Tue, 2017-04-25 at 17:45 +0000, Sasa Ostrouska wrote:
> > Woow, long one really. Ok, I think the idea is really good. Of course
> > a lot of work. I as a maintainer of a gnome desktop version for
> > Slackware would like to ask how this would handle the distros which
> > do not use systemd ?
>
> I did not expect this question, but I'm glad you asked it :)
>
> I want just to clarify that I do not intend change this discussion about
if use or not use systemd and
personally i have nothing against it, its just that the distro i use do not
supply it. I think similar situation
is with *BSD .

Firstly, I can say that a new build tool is not going to magically make
> GNOME work better on all distros, however it *can* help us to
> understand the problem better and raise awareness, both for GNOME
> developers and for distro developers/integrators.
>
> Correct, I would personally like to see it be easier buildable on my
distro. But there are some things
which Slackware does not have and on some parts of gnome it is a
dependency. In some cases I can
add this to Slackware and I do it for many years already. But in cases of
an init system is a bit difficult
because it requires too much low level changes. Therefore the idea of
minimum and well defined dependencies
is really good in my opinion.


> Here's how I think we can greatly improve the integrator's experience:
>
> > >   For CI
> > >   ~~
> [...]
> > >   Further than this, I should mention there is some movement to
> implement
> > >   Source plugins to represent distro packaging sources, e.g. the dpkg
> > >   source plugin[4]. With this plugin in place, I suspect it will be
> > >   very easy to run tests of building and running GNOME against various
> > >   third party distributions and versions of those. Imagine we could
> have
> > >   a board somewhere which displays which distributions GNOME builds on
> > >   without failing tests (we could always know when GNOME master is
> failing
> > >   against debian sid, or latest fedora, etc).
>
> So, my vision of how we can improve communication and collaboration
> between GNOME and it's consuming distros works something like this:
>
>   o We would have a dedicated CI system which would build and hopefully
> run GNOME on a series of "subscribed" distros.
>
>   o An interested party (distro representative/contibutor) would have
> to ensure that BuildStream have a 'Source' plugin which handles
> importing of distro packages in the package format which that
> distro uses.
>

This is ok with me, and I am ready to pick it up. Especially for doing the
needed
packages.


> The requirements to meet for implementing a Source plugin are
> outlined in the comments of the 'dpkg source' issue[4].
>
> Ok will take a look at it.


>   o The interested party then subscribes to the CI, by providing
> a simple patch to some YAML which says:
>
>   - This is variant 'slackware'
>   - This is how you obtain the 'slackware' base to build on
> (using the appropriate Source plugin to do the work).
>
> and then adding 'slackware' to a list of variants that the
> CI server should try building.
>
> Perfect, seems fine to me.


>   o For every distro that passes some CI, a bootable image could
> be downloadable too, so one could easily try out the latest GNOME
> on a variety of bleeding edge versions of distros and compare the
> experience (this could be fun pretty quickly :))
>
> Yep, thats good.


> I think it would be great if this CI was centralized and hosted by
> GNOME in some way, even though I'm sure that most distros have their
> own forms of CI, this would provide a venue for GNOME developers to
> collaborate with distros directly and have a better understanding of
> what kind of changes break distros in what ways.
>
> Agreed.


> Now of course in such a utopian future, it would be important to
> understand that GNOME running CI against a variety of distros, does not
> equate to GNOME making a promise to never break distros.
>
> Correct.


> If a CI fails in this context then it could be for any of the following
> reasons:
>
>   o It is a legitimate integration bug in the distro
>   o It is a legitimate bug somewhere in GNOME
>   o The distro did not provide what GNOME requires
>   o GNOME failed to communicate it's requirements clearly enough
>
> So in closing, no this would not magically make GNOME easier to work
> with when integrating on non-systemd distributions, at least not at
> firs

Re: GNOME Build situation and BuildStream

[Sasa Ostrouska]

Woow, long one really. Ok, I think the idea is really good. Of course a lot
of work. I as a maintainer of a gnome desktop version for Slackware would
like to ask how this would handle the distros which do not use systemd ?

Rgds
Saxa
www.droplinegnome.org

On Tue, Apr 25, 2017 at 4:38 PM, Tristan Van Berkom <
tristan.vanber...@codethink.co.uk> wrote:

> TL;DR: We are working to improve build tooling for GNOME software
> development, and
>are very interested in GNOME developer community feedback on the
> BuildStream
>approach we are taking, and how to achieve a successful transition.
>
>
> Hi all,
>
> By now many participants of this list are already aware of our efforts
> on
> the BuildStream tooling from reading my blog posts ([0] and [1]), which we
> aspire
> to use in GNOME to improve GNOME's developer experience as well as
> improving the
> process around maintaining GNOME releases.
>
> At this time I would like to start a more open conversation about our
> plans,
> ensure that we are all aligned on what the best approach should be for
> building
> GNOME and also look at how we can implement a better build story for GNOME,
> hopefully over the following months.
>
> There is a lot to say here as it's a big topic, so to structure this a bit,
> I'll talk about:
>
>   o What are the existing use cases of building GNOME ?
> o What are the pain points related to these use cases ?
>   o How do we plan to address these pain points using BuildStream ?
>   o How would we implement BuildStream in GNOME with a smooth transition ?
>
>
> What are the existing use cases of building GNOME ?
> ~~~
>
>   o A developer uses JHBuild to build and hack on parts of
> GNOME on their local laptop or desktop machine, which
> can be any linux distro.
>
> Pain Points:
>
> * Non deterministic set of dependencies cause builds to fail in
>   random unpredictable ways, which can be off putting for newcomers
>   and also an annoyance to seasoned developers who want to fix some
>   specific bug, but get caught up fixing other bugs instead.
>
> * It's difficult to debug core components such as the interactions
>   of gnome-keyring, Linux-PAM, GDM, GNOME Session, GNOME Shell.
>
>   Manual tinkering is needed, you either need a separate machine or
>   a VM you've setup manually to recreate login scenarios and
>   gnome-initial-setup scenarios, ensuring a seamless handoff to the
>   initial user with their online accounts setup and all of this.
>
>   o The release team needs to build and publish GNOME releases
>
> Pain Points:
>
> * Non deterministic dependencies again make things unclear as to
>   what exactly we are releasing.
>
>   E.g., we might know that this vector of GNOME module versions
>   work well on some specific distro it has been tried with, but
>   we can't know for sure that the result of a JHBuild of GNOME
>   will behave the same on any person's distro.
>
>   By the same logic, it becomes difficult as time passes to
>   build older releases of GNOME in the future on more modern
>   dependency sets.
>
> * Current tooling does not allow for any distinction from
>   a specific version of something (be it a commit sha in a git
>   repository or a specific tarball), and a symbolic branch name.
>
>   With JHBuild (or flatpak-builder for that matter), you must
>   either specify a symbolic branch, or a specific commit.
>
>   To advertise a specific release involves a lot of tedious
>   editing of build metadata to communicate new versions of a stable
>   or development release set manually.
>
>   o The Flatpak maintainers currently maintain their own set
> of build metadata to build the GNOME SDK and runtime.
>
> Pain Points:
>
> * Arguably the flatpak maintainership should not be accountable
>   for maintaining the GNOME Runtime and SDK builds. I think we
>   mostly agree by now that it would be great to have the GNOME
>   release team have control of their own flatpak builds.
>
>   There is however a large overlap of libraries and tooling
>   which must appear in the GNOME Runtimes/SDKs and must also
>   appear on an operating system running GNOME (libraries and
>   services to support the display manager, the shell,
>   the session, control center, etc.).
>
>   Maintaining these sets of build metadata in separate formats
>   and separate repositories is both burdensome and error prone:
>   releases are not communicated atomically and nothing guarantees
>   that GNOME 3.24 moduleset versions and GNOME 3.24 flatpak runtime
>   versions coincide at all times.
>
>   o Application module maintainers need to either build Flatpaks
> of their module or at least provide some flatpak-builder json
> for a third party to build it on your behalf.
>
> Pain Points:
>
>

Re: gnome-settings-daemon now split up

[Sasa Ostrouska]

On Tue, Oct 11, 2016 at 9:25 AM, Bastien Nocera  wrote:

> Hey,
>
> gnome-settings-daemon 3.23.2 is now released. The major change is that
> instead of launching a single big daemon, gnome-session will now launch
> a number of smaller daemons.
>
> Eventually, those daemons will be started as needed (through timers, or
> D-Bus autostart) via systemd --user, as announced last cycle. For now,
> the changes should be safe to deploy on Linux and non-Linux platforms.
>
> Will it be pssible to use GSD without systemd ?

Rgds
Saxa


> Note that gnome-settings-daemon 3.23.2 requires gnome-session 3.23.2
> and is incompatible with older releases. The GNOME Classic session file
> has not been updated yet:
> https://bugzilla.gnome.org/show_bug.cgi?id=772736
>
> Cheers
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list