Highlights from the latest Copr release 2020-06-10

[Pavel Raiskup]

Hello!

On Jun 10, 2020, a new Copr release landed production.  Related client tooling
updates are here:

  https://bodhi.fedoraproject.org/updates/FEDORA-2020-390cce74d6
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-f90873700f
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3b8c2778f1
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-feca133c66
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8449e5d605

Here is the list of visible changes, and new features:

- Increased build task throughput.  The VM spawner is more flexible now.
  First, we don't allocate that many workers if they are not actually
  needed, but more importantly the upper limit for concurrently running
  workers has risen to 140 (including all architectures), previously we
  had ~70.  We'll see how things go from the backend perspective, but it is
  expected that we'll go even higher (waiting for a new HW in the new
  Fedora lab, cheaper VM instances in the future, etc.).  So the numbers will
  likely change; this is to make clear the current state of things.

- Copr project "runtime" dependencies were implemented.  Newly you can
  specify set of repositories your project depends on. Such repositories
  will be installed together with the copr project repo file (e.g., by
  'dnf copr enable YOU/YOUR_PROEJCT').  Those repositories can be other
  project in Copr or some 3rd party repository.  This is very similar to
  build-time dependencies implemented long time ago.  Take a look at
  blog post:

https://fedora-copr.github.io/posts/runtime-dependencies

- There's now more fair build scheduler.  Previously, no matter whether the
  "background" attribute was set or not for the build - once builder was
  allocated for a concrete copr user - copr never terminated the builder
  as long as the user kept filling the build queue with new tasks (and it
  blocked the quota for others).  Newly, there's a limit of at most
  eight consecutive builds or 30 minutes for one user (sandbox) on one
  builder and the builder is immediately terminated - which gives a chance
  to assign new builders to others' tasks (which have a higher priority at
  that point).

- Copr-cli supports batch build delete feature:

$ copr-cli delete build_id [build_id ...]

  Please use this instead of requesting removal of each build_id
  separately - it will be much faster because you will save the copr
  backend useless createrepo_c runs after each request.

- We also implemented a priority queue algorithm for Action tasks
  (non-build tasks, e.g., forking, build/project deleting, etc.).  This
  should solve several issues when the action queue gets temporarily too
  large to process immediately; namely the delayed "initial createrepo"
  action problem that previously caused an ugly build failures in freshly
  created copr projects.

- Cancel build feature was fixed, and the "cancel" request should reliably
  release all occupied builder machines (allowing them to be re-used, or
  terminated).

- Users are not allowed to disable chroot in a project that has some
  running builds against the disabled chroot.  The running builds need to
  be canceled first.  This change as done to avoid inconsistencies between
  frontend/backend, and wasted builder quota on useless tasks.

- More space for /var/cache/mock directory, so repeated builds on the same
  machine won't face the ENOSPC error on mock caches.  Considering that
  each builder can only do at most eight builds (then terminated), this
  problem should be finally fixed.

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: A few questions about a package update / policy questions / GCC 9 error

[Peter Pentchev]

On Wed, Jun 10, 2020 at 02:22:53PM -0400, Simo Sorce wrote:
> On Wed, 2020-06-10 at 14:16 -0400, Simo Sorce wrote:
> > On Wed, 2020-06-10 at 20:01 +0200, Dan Čermák wrote:
> > > "Nathanael D. Noblet"  writes:
> > > 
> > > > Hello,
> > > > 
> > > >   I maintain beanstalkd which is a message server of sorts. It recently
> > > > released a new version however some changes I'm not 100% sure about.
> > > > 
> > > >   When compiling I got the following GCC error.
> > > > 
> > > > usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> > > > specified bound 201 equals destination size [-Werror=stringop-
> > > > truncation]
> > > >   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> > > > (__dest));
> > > >   |  ^~
> > > > 
> > > > 
> > > > Results via google says that strncpy needs to have the third argument
> > > > less than the 2nd, so I've got this patch, similar to others:
> > > > 
> > > > --- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
> > > > +++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
> > > > @@ -12,7 +12,7 @@
> > > >  if (!t)
> > > >  return NULL;
> > > > 
> > > > -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> > > > +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> > > >  if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
> > > >  t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> > > >  twarnx("truncating tube name");
> > > > 
> > > > You'll notice it was already checking the len-1 for null. Can anyone
> > > > verify that my change won't cause some un-intended bug I don't
> > > > understand?
> > > 
> > > If I understand it correctly, then you are now invoking undefined
> > > behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
> > > check whether the following byte (that was never written to) is not
> > > equal to 0. I have not checked the code of beanstalkd, but the contents
> > > of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
> > > calloc() at best or random at worst. Irrespectively of that, the check
> > > now no longer does what it *should*: null terminate the string if it is
> > > not null terminated. It will now randomly null terminate it or not at
> > > all.
> > 
> > strncpy() is a truly awful API unfortunately, the change is
> > meaningless, but it is not random as Dan says.
> > 
> > The original form is more correct though, because now you can get
> > spurious warnings that the string have been truncated when that is not
> > true. (If t->name is not zeroized you will get the spurious warning for
> > any string shorter than MAX_TUBE_NAME_LEN, which is the opposite of
> > what the warning says.
> > 
> > The third argument to strncpy can be as long as the size of the buffer
> > you are writing into, the additional check you have there insures that
> > the string is terminated (even if that requires truncation).
> > 
> > So I would say you should drop your change and stop believing in random
> > google results :)
> 
> Sorry, hit send prematurely.
> 
> If you really want to avoid the warning instead of ignoring it, you
> should change the code this way:
> 
> strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> if (t->name[MAX_TUBE_NAME_LEN - 2] != '\0') {
> t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> twarnx("truncating tube name");
> }
> 
> NOTE: the -2 in the condition, this is needed because memory locations
> start counting from 0, so if you write N-1 bytes the Nth-1 byte is at
> the N-2 position when you start counting from 0.
> And that is the last position your strncpy wrote to, and if that is not
> 0 then potentially string truncation occurred.
> 
> You still want to zero the last available byte in that case and not the
> N-1 available byte, so you set N-1 to 0, not N-2.
> 
> N-1 is the Nth byte when you start counting from 0 and N is the size of
> the array.

...or use snprintf() and check! its! return! value! (sorry, I've had to
explain that to too many people over too many years).

Something like (completely, totally untested, but should give you an
idea):

  const int res = snprintf(t->name, MAX_TUBE_NAME_LEN, "%s", name);
  if (res < 0 || (size_t)res >= MAX_TUBE_NAME_LEN)
twarnx("truncating tube name");

...although, in all fairness, the two conditions should be checked
separately, since the first one (res < 0) indicates a serious error and
no meaningful characters at all written to t->name.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en

Re: A few questions about a package update / policy questions / GCC 9 error

[Simo Sorce]

On Wed, 2020-06-10 at 14:16 -0400, Simo Sorce wrote:
> On Wed, 2020-06-10 at 20:01 +0200, Dan Čermák wrote:
> > "Nathanael D. Noblet"  writes:
> > 
> > > Hello,
> > > 
> > >   I maintain beanstalkd which is a message server of sorts. It recently
> > > released a new version however some changes I'm not 100% sure about.
> > > 
> > >   When compiling I got the following GCC error.
> > > 
> > > usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> > > specified bound 201 equals destination size [-Werror=stringop-
> > > truncation]
> > >   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> > > (__dest));
> > >   |  ^~
> > > 
> > > 
> > > Results via google says that strncpy needs to have the third argument
> > > less than the 2nd, so I've got this patch, similar to others:
> > > 
> > > --- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
> > > +++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
> > > @@ -12,7 +12,7 @@
> > >  if (!t)
> > >  return NULL;
> > > 
> > > -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> > > +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> > >  if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
> > >  t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> > >  twarnx("truncating tube name");
> > > 
> > > You'll notice it was already checking the len-1 for null. Can anyone
> > > verify that my change won't cause some un-intended bug I don't
> > > understand?
> > 
> > If I understand it correctly, then you are now invoking undefined
> > behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
> > check whether the following byte (that was never written to) is not
> > equal to 0. I have not checked the code of beanstalkd, but the contents
> > of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
> > calloc() at best or random at worst. Irrespectively of that, the check
> > now no longer does what it *should*: null terminate the string if it is
> > not null terminated. It will now randomly null terminate it or not at
> > all.
> 
> strncpy() is a truly awful API unfortunately, the change is
> meaningless, but it is not random as Dan says.
> 
> The original form is more correct though, because now you can get
> spurious warnings that the string have been truncated when that is not
> true. (If t->name is not zeroized you will get the spurious warning for
> any string shorter than MAX_TUBE_NAME_LEN, which is the opposite of
> what the warning says.
> 
> The third argument to strncpy can be as long as the size of the buffer
> you are writing into, the additional check you have there insures that
> the string is terminated (even if that requires truncation).
> 
> So I would say you should drop your change and stop believing in random
> google results :)

Sorry, hit send prematurely.

If you really want to avoid the warning instead of ignoring it, you
should change the code this way:

strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
if (t->name[MAX_TUBE_NAME_LEN - 2] != '\0') {
t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
twarnx("truncating tube name");
}

NOTE: the -2 in the condition, this is needed because memory locations
start counting from 0, so if you write N-1 bytes the Nth-1 byte is at
the N-2 position when you start counting from 0.
And that is the last position your strncpy wrote to, and if that is not
0 then potentially string truncation occurred.

You still want to zero the last available byte in that case and not the
N-1 available byte, so you set N-1 to 0, not N-2.

N-1 is the Nth byte when you start counting from 0 and N is the size of
the array.

HTH,
Simo.

> > > Finally, they also now support socket activation. Which means I was
> > > looking at .service file which I had setup to use a sysconfig
> > > environment file. When I looked at it, I realized that the default was
> > > to listen to 0.0.0.0 which means someone could install and if not
> > > really careful / pre config or what not have a service listening where
> > > they maybe don't want to. I was thinking of changing this to 127.0.0.1
> > > with a note about how it should be modified. However I figure if I do
> > > that, anyone with this installed and unmodified who gets the update
> > > will suddenly have their service stop listening to the outside world.
> > > What should be done then? 
> > > 
> > > My thought is I leave it as 0.0.0.0 for all released versions (but what
> > > about epel7) and then in rawhide change to 127.0.0.1. I just don't like
> > > leaving the package like that for epel as well.
> > > 
> > > Any ideas/direction would be appreciated.
> > > 
> > > Sincerely,
> > > -- 
> > > Nathanael
> > > 
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > htt

Re: A few questions about a package update / policy questions / GCC 9 error

[Simo Sorce]

On Wed, 2020-06-10 at 20:01 +0200, Dan Čermák wrote:
> "Nathanael D. Noblet"  writes:
> 
> > Hello,
> > 
> >   I maintain beanstalkd which is a message server of sorts. It recently
> > released a new version however some changes I'm not 100% sure about.
> > 
> >   When compiling I got the following GCC error.
> > 
> > usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> > specified bound 201 equals destination size [-Werror=stringop-
> > truncation]
> >   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> > (__dest));
> >   |  ^~
> > 
> > 
> > Results via google says that strncpy needs to have the third argument
> > less than the 2nd, so I've got this patch, similar to others:
> > 
> > --- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
> > +++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
> > @@ -12,7 +12,7 @@
> >  if (!t)
> >  return NULL;
> > 
> > -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> > +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
> >  if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
> >  t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
> >  twarnx("truncating tube name");
> > 
> > You'll notice it was already checking the len-1 for null. Can anyone
> > verify that my change won't cause some un-intended bug I don't
> > understand?
> 
> If I understand it correctly, then you are now invoking undefined
> behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
> check whether the following byte (that was never written to) is not
> equal to 0. I have not checked the code of beanstalkd, but the contents
> of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
> calloc() at best or random at worst. Irrespectively of that, the check
> now no longer does what it *should*: null terminate the string if it is
> not null terminated. It will now randomly null terminate it or not at
> all.

strncpy() is a truly awful API unfortunately, the change is
meaningless, but it is not random as Dan says.

The original form is more correct though, because now you can get
spurious warnings that the string have been truncated when that is not
true. (If t->name is not zeroized you will get the spurious warning for
any string shorter than MAX_TUBE_NAME_LEN, which is the opposite of
what the warning says.

The third argument to strncpy can be as long as the size of the buffer
you are writing into, the additional check you have there insures that
the string is terminated (even if that requires truncation).

So I would say you should drop your change and stop believing in random
google results :)

> > Finally, they also now support socket activation. Which means I was
> > looking at .service file which I had setup to use a sysconfig
> > environment file. When I looked at it, I realized that the default was
> > to listen to 0.0.0.0 which means someone could install and if not
> > really careful / pre config or what not have a service listening where
> > they maybe don't want to. I was thinking of changing this to 127.0.0.1
> > with a note about how it should be modified. However I figure if I do
> > that, anyone with this installed and unmodified who gets the update
> > will suddenly have their service stop listening to the outside world.
> > What should be done then? 
> > 
> > My thought is I leave it as 0.0.0.0 for all released versions (but what
> > about epel7) and then in rawhide change to 127.0.0.1. I just don't like
> > leaving the package like that for epel as well.
> > 
> > Any ideas/direction would be appreciated.
> > 
> > Sincerely,
> > -- 
> > Nathanael
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

Re: Fedora Jam switch to GNOME

[Harsh Jain]

Hi Erich ,
Sorry , I thought the primary focus was to find a new de to shift to .
Improving Gnome in terms of reducing resource usage (and in general ) seems
pretty nice . I'd be happy to have another de I can work smoothly with :)
This might not be relevant but if you install pantheon de , you can switch
to gnome on the logout screen (even if you didn't install it ) and it
basically brings gnome shell with pantheon apps .
I felt it was a bit smoother than normal gnome ( I didn't test this
extensively but everything seemed to work fine ) .Maybe this can help in
some way ?
Thanks ,
Harsh

On Wed, 10 Jun, 2020, 22:10 ,  wrote:

> On Wed, 2020-06-10 at 22:01 +0530, Harsh Jain wrote:
> > Hi ,
> > I'm not too familiar with Fedora Jam but if you want to minimize
> > resource usage , shouldn't XFCE be a better choice since it's less
> > intensive with resources . Although Gnome has also reduced resource
> > usage since initial 3.x releases as well I think . It's just really
> > hard to decide between evrything (l'm de hopping currently as well) .
> > Again ,I'm sorry if none of this was useful .
> > Thanks ,
> > Harsh
> >
>
> Hi Harsh,
>
> I also lead Ubuntu Studio and we just moved away from Xfce to KDE
> Plasma because we wanted a more-functional desktop for creative
> professionals. The resource usage between Xfce and Plasma is neglegable
> (about 50MB difference) and KDE is a better choice for graphics artists
> (which Ubuntu Studio also covers.
>
> I think you missed the point though: the goal is to help GNOME improve.
> I've had conversations with people who want to see GNOME improve in
> this regard and want to work with me in improving it. So, this isn't
> about simply switching desktops, this is about helping another desktop
> improve its situation. If Jam is to switch, it's going to GNOME, that
> decision is already made. The "If" is what I'm working on, whether or
> not to actually go through with it.  If it does happen, the goal is to
> improve GNOME. One can always install whatever desktop they want and do
> "dnf groupinstall 'Audio Production'".
>
> I hoep that clears things up, as I think you missed the point. :)
>
> Erich
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Lukas Ruzicka]

>
> This is exactly the kind of feedback i'm looking for. Thanks! I do know
> that under Plasma and Xfce I've seen < 2ms latency with the right
> hardware (PCI cards, primarily). I've been able to push my Behringer
> UMC404HD (a USB interface) under 10 before. I have yet to do any formal
> testing on GNOME, but I'm glad to read what you wrote. Thanks!
>

Now, I am playing back a previously recorded project with 512 samples,
which gives the latency of 10ms and Ardour is performing fine
without any xruns. The project has 10 tracks and each track has about 3
plugins used. It is getting late here, but if you want, I can try to record
something tomorrow and see which latency I can go to before getting  xruns
and give the feedback here.

I agree that you do not want even one xrun in your session.

PS: I might find out that latency is no more an issue as it was before. I
guess I am using such benevolent settings just for sure.


>
> -Erich
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: A few questions about a package update / policy questions / GCC 9 error

[Dan Čermák]

"Nathanael D. Noblet"  writes:

> Hello,
>
>   I maintain beanstalkd which is a message server of sorts. It recently
> released a new version however some changes I'm not 100% sure about.
>
>   When compiling I got the following GCC error.
>
> usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> specified bound 201 equals destination size [-Werror=stringop-
> truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
>   |  ^~
> 
>
> Results via google says that strncpy needs to have the third argument
> less than the 2nd, so I've got this patch, similar to others:
>
> --- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
> +++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
> @@ -12,7 +12,7 @@
>  if (!t)
>  return NULL;
>
> -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
>  if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
>  t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
>  twarnx("truncating tube name");
>
> You'll notice it was already checking the len-1 for null. Can anyone
> verify that my change won't cause some un-intended bug I don't
> understand?

If I understand it correctly, then you are now invoking undefined
behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
check whether the following byte (that was never written to) is not
equal to 0. I have not checked the code of beanstalkd, but the contents
of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
calloc() at best or random at worst. Irrespectively of that, the check
now no longer does what it *should*: null terminate the string if it is
not null terminated. It will now randomly null terminate it or not at
all.

>
> Finally, they also now support socket activation. Which means I was
> looking at .service file which I had setup to use a sysconfig
> environment file. When I looked at it, I realized that the default was
> to listen to 0.0.0.0 which means someone could install and if not
> really careful / pre config or what not have a service listening where
> they maybe don't want to. I was thinking of changing this to 127.0.0.1
> with a note about how it should be modified. However I figure if I do
> that, anyone with this installed and unmodified who gets the update
> will suddenly have their service stop listening to the outside world.
> What should be done then? 
>
> My thought is I leave it as 0.0.0.0 for all released versions (but what
> about epel7) and then in rawhide change to 127.0.0.1. I just don't like
> leaving the package like that for epel as well.
>
> Any ideas/direction would be appreciated.
>
> Sincerely,
> -- 
> Nathanael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 elections voting now open

[Ben Cotton]

This is your final reminder that voting in the Fedora 32 election
cycle ends at 23:59 UTC on Thursday 11 June.

On Wed, May 27, 2020 at 8:16 PM Ben Cotton  wrote:
>
> Voting in the Fedora 32 elections is now open. Go to the Elections app
> to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 11 June.
> Don't forget to claim your "I Voted" badge when you cast your ballot.
> Links to candidate interviews are in the Elections app and on the
> Community Blog[2].
>
> [1] https://elections.fedoraproject.org/
> [2] 
> https://communityblog.fedoraproject.org/fedora-32-elections-voting-now-open/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

Hi Lukas,

On Wed, 2020-06-10 at 19:36 +0200, Lukas Ruzicka wrote:
> Hello,
> 
> I am using Fedora Workstation with the stock kernel and Gnome Desktop
> for my recording attempts with Ardour. I am using the Focusrite
> Scarlett USB sound card and I can get down to 40ms latency without
> getting any xruns (a couple of releases back, it was an xrun hell). I
> am aware that the 40ms are nothing really good, but since I only do
> some folkie stuff (upto 15 tracks) it is OK for me and I think that
> you can make music on Gnome Desktop.
> 
> However, I am totally aware that people like to use what they are
> used to.
> 
> Lukas
> 

This is exactly the kind of feedback i'm looking for. Thanks! I do know
that under Plasma and Xfce I've seen < 2ms latency with the right
hardware (PCI cards, primarily). I've been able to push my Behringer
UMC404HD (a USB interface) under 10 before. I have yet to do any formal
testing on GNOME, but I'm glad to read what you wrote. Thanks!

-Erich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Upcoming Fedora 33 Change proposal deadlines

[Ben Cotton]

This is your reminder that several Change proposal deadlines for
Fedora 33 are approaching.

* 2020-06-24: Proposal deadline for Changes requiring infrastructure changes
* 2020-06-30: Proposal deadline for Changes requiring mass rebuild
* 2020-06-30: Proposal deadline for System-Wide Changes
* 2020-07-21: Proposal deadline for Self-Contained Changes

For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

Hi Lukas,

On Wed, 2020-06-10 at 19:39 +0200, Lukas Ruzicka wrote:
> Well, does it mean that PipeWire is going to replace Jack? Because if
> not, 
> then it is a non-issue for recording anyway.
> 

As I understand it, Pipewire is going to act as a drop-in replacement
for Jack and Pulseaudio and be completely functionally equivalent to
both, solving the problem with Linux audio that we've had for decades
now.

--Erich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

Hi Kalev,

On Wed, 2020-06-10 at 19:20 +0200, Kalev Lember wrote:
> Hi Erich,
> 
> I think this is a great idea -- thanks for getting the discussion
> started!
> 
> I've always found it weird that the Jam spin is based on another
> desktop, different from what Fedora Workstation uses. I think it
> makes a lot of sense to switch over and try to improve the audio
> issues in GNOME. We have a lot of Fedora developers who are also
> GNOME upstream developers and this should create nice synergies.
> 
> As you may be aware, Wim Taymans has been working on pipewire that
> Workstation ships with, with the goal of improving the audio and
> video experience in Fedora Workstation and GNOME and Linux desktop in
> general. The Jam spin switching to GNOME makes a lot of sense in this
> context -- that way the Jam users can quickly give feedback on any
> pipewire issues and feature requests, hopefully improving the overall
> situation quickly.
> 
> Good idea and +1 from me.
> 
> -- 
> Kalev
> 

Thanks. That's exactly what has spurred this conversation. I've been
having conversations in off-list threads about pipewire. I'm highly
interesed in doing work on this, and I think perhaps this would be the
best way to collaborate and get feedback from the overall community of
musicians and audion enthusiasts.

So, perhaps a conversation can be had to create a second kickstart for
GNOME and keep the KDE kickstart?

But, that's the goal: to get users to give feature requests and issues
to pipewire. I am not sure that can be adequately accomplished in KDE
Plasma.

-Erich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Lukas Ruzicka]

offering. That's less about GNOME vs KDE and more about PipeWire still
> needing work to be broadly adopted.
>
>
Well, does it mean that PipeWire is going to replace Jack? Because if not,
then it is a non-issue for recording anyway.




>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Lukas Ruzicka]

Hello,

I am using Fedora Workstation with the stock kernel and Gnome Desktop for
my recording attempts with Ardour. I am using the Focusrite Scarlett USB
sound card and I can get down to 40ms latency without getting any xruns (a
couple of releases back, it was an xrun hell). I am aware that the 40ms are
nothing really good, but since I only do some folkie stuff (upto 15 tracks)
it is OK for me and I think that you can make music on Gnome Desktop.

However, I am totally aware that people like to use what they are used to.

Lukas

On Wed, Jun 10, 2020 at 7:21 PM Kalev Lember  wrote:

> Hi Erich,
>
> I think this is a great idea -- thanks for getting the discussion started!
>
> I've always found it weird that the Jam spin is based on another desktop,
> different from what Fedora Workstation uses. I think it makes a lot of
> sense to switch over and try to improve the audio issues in GNOME. We have
> a lot of Fedora developers who are also GNOME upstream developers and this
> should create nice synergies.
>
> As you may be aware, Wim Taymans has been working on pipewire that
> Workstation ships with, with the goal of improving the audio and video
> experience in Fedora Workstation and GNOME and Linux desktop in general.
> The Jam spin switching to GNOME makes a lot of sense in this context --
> that way the Jam users can quickly give feedback on any pipewire issues and
> feature requests, hopefully improving the overall situation quickly.
>
> Good idea and +1 from me.
>
> --
> Kalev
>
>
> On Wed, Jun 10, 2020 at 6:10 PM  wrote:
>
>> Hi all,
>>
>> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
>> multiple reasons for this, and I think part of it would be beneficial
>> to the overall GNOME and Fedora communities as it would be a way to be
>> helping improve the situation in GNOME that exist as the biggest
>> objections from the community of musicians and Linux audio enthusiasts
>> in the overall community.
>>
>> The biggest objections are resource usage, since the more resources
>> that are in use, the more it tends to interfere with real-time audio
>> processes, causing buffer overruns and/or underruns. These overruns and
>> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
>> cause pops during recording. When doing real-time audio work, you want
>> to have as low of latency as possible which requires as small of a
>> buffer as possible. The goal is to have a small buffer to get minimal
>> latency while avoiding Xruns.
>>
>> Unfortunately, GNOME has, since 3.0, traditionally interfered with
>> these processes and caused Xruns. My goal, by moving Fedora Jam from
>> Plasma to GNOME, is to help GNOME improve this situation.
>>
>> The other reason for switching away from Plasma is the overall negative
>> attitude I see from Fedora KDE users and former Fedora KDE
>> contributors. It seems to be an attitude against the progress of
>> improving the Linux desktop for the better, and simply complaining. I
>> know some of this attitude comes from Red Hat dropping KDE from being a
>> desktop in REHL, among other changes. That attitude is regressive, and
>> does nothing to help the community if all you do is complain. I could
>> name names, but for the sake of the "Friends" foundation, I will not.
>>
>> Anyhow, I'd love to see a discussion about this as well as any guidance
>> toward making this change. I know there would have to be a new
>> kickstart along with Koji pointing toward said kickstart. I could make
>> the kickstart, but I think I'd need Koji to look for it.
>>
>> Thanks and best regards,
>> Erich
>> 
>> Erich Eickmeyer
>> Fedora Jam
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines

Re: Fedora Jam switch to GNOME

[Neal Gompa]

On Wed, Jun 10, 2020 at 1:29 PM  wrote:
>
> Hi Kalev,
>
> On Wed, 2020-06-10 at 19:20 +0200, Kalev Lember wrote:
> > Hi Erich,
> >
> > I think this is a great idea -- thanks for getting the discussion
> > started!
> >
> > I've always found it weird that the Jam spin is based on another
> > desktop, different from what Fedora Workstation uses. I think it
> > makes a lot of sense to switch over and try to improve the audio
> > issues in GNOME. We have a lot of Fedora developers who are also
> > GNOME upstream developers and this should create nice synergies.
> >
> > As you may be aware, Wim Taymans has been working on pipewire that
> > Workstation ships with, with the goal of improving the audio and
> > video experience in Fedora Workstation and GNOME and Linux desktop in
> > general. The Jam spin switching to GNOME makes a lot of sense in this
> > context -- that way the Jam users can quickly give feedback on any
> > pipewire issues and feature requests, hopefully improving the overall
> > situation quickly.
> >
> > Good idea and +1 from me.
> >
> > --
> > Kalev
> >
>
> Thanks. That's exactly what has spurred this conversation. I've been
> having conversations in off-list threads about pipewire. I'm highly
> interesed in doing work on this, and I think perhaps this would be the
> best way to collaborate and get feedback from the overall community of
> musicians and audion enthusiasts.
>
> So, perhaps a conversation can be had to create a second kickstart for
> GNOME and keep the KDE kickstart?
>
> But, that's the goal: to get users to give feature requests and issues
> to pipewire. I am not sure that can be adequately accomplished in KDE
> Plasma.
>

I'd be concerned about the viability of PipeWire if we don't have work
going upstream in KDE to leverage it, though. The majority of creative
software is Qt5/KF5 based, and not having PipeWire support first class
in that ecosystem would be massively damaging to the quality of the
offering. That's less about GNOME vs KDE and more about PipeWire still
needing work to be broadly adopted.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Kalev Lember]

Hi Erich,

I think this is a great idea -- thanks for getting the discussion started!

I've always found it weird that the Jam spin is based on another desktop,
different from what Fedora Workstation uses. I think it makes a lot of
sense to switch over and try to improve the audio issues in GNOME. We have
a lot of Fedora developers who are also GNOME upstream developers and this
should create nice synergies.

As you may be aware, Wim Taymans has been working on pipewire that
Workstation ships with, with the goal of improving the audio and video
experience in Fedora Workstation and GNOME and Linux desktop in general.
The Jam spin switching to GNOME makes a lot of sense in this context --
that way the Jam users can quickly give feedback on any pipewire issues and
feature requests, hopefully improving the overall situation quickly.

Good idea and +1 from me.

-- 
Kalev


On Wed, Jun 10, 2020 at 6:10 PM  wrote:

> Hi all,
>
> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
> multiple reasons for this, and I think part of it would be beneficial
> to the overall GNOME and Fedora communities as it would be a way to be
> helping improve the situation in GNOME that exist as the biggest
> objections from the community of musicians and Linux audio enthusiasts
> in the overall community.
>
> The biggest objections are resource usage, since the more resources
> that are in use, the more it tends to interfere with real-time audio
> processes, causing buffer overruns and/or underruns. These overruns and
> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
> cause pops during recording. When doing real-time audio work, you want
> to have as low of latency as possible which requires as small of a
> buffer as possible. The goal is to have a small buffer to get minimal
> latency while avoiding Xruns.
>
> Unfortunately, GNOME has, since 3.0, traditionally interfered with
> these processes and caused Xruns. My goal, by moving Fedora Jam from
> Plasma to GNOME, is to help GNOME improve this situation.
>
> The other reason for switching away from Plasma is the overall negative
> attitude I see from Fedora KDE users and former Fedora KDE
> contributors. It seems to be an attitude against the progress of
> improving the Linux desktop for the better, and simply complaining. I
> know some of this attitude comes from Red Hat dropping KDE from being a
> desktop in REHL, among other changes. That attitude is regressive, and
> does nothing to help the community if all you do is complain. I could
> name names, but for the sake of the "Friends" foundation, I will not.
>
> Anyhow, I'd love to see a discussion about this as well as any guidance
> toward making this change. I know there would have to be a new
> kickstart along with Koji pointing toward said kickstart. I could make
> the kickstart, but I think I'd need Koji to look for it.
>
> Thanks and best regards,
> Erich
> 
> Erich Eickmeyer
> Fedora Jam
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Mattia Verga via devel]

Re-posting to astronomy list:

Il 08/06/20 11:00, Miro Hrončok ha scritto:
> astronomy-backgrounds orphan   1 weeks ago
> astronomy-bookmarks   orphan   1 weeks ago
Do we want to continue maintaining these two? They're fancy, but I don't 
think they're really useful.
> nightfall orphan   1 weeks ago
This one seems to be dead, project URL is no more active.
> redmode   orphan   1 weeks ago
Anyone interested in maintain it?
> siril astro-sig, lkundrak, lupinix,1 weeks ago
> orphan
I'm taking this one, since it's quite important. Hopefully, I will find 
the time to learn how to use it, one day or another...
> xstar lkundrak, orphan 1 weeks ago
> xvarstar  orphan   1 weeks ago

Anyone interested in maintain them?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

Hi Iñaki

On Wed, 2020-06-10 at 18:52 +0200, Iñaki Ucar wrote:
> On Wed, 10 Jun 2020 at 18:46, Neal Gompa  wrote:
> > I would personally be very sad if Fedora Jam switched from KDE to
> > GNOME. To me, KDE has always been the home for creatives, and it
> > shows
> > with the excellent Qt/KDE based software for auditory and visual
> > creativity. From my perspective, KDE is the environment that
> > creative
> > people can feel at home in.
> 
> Same here, as a musician and Fedora KDE user. :(
> 

This is exactly the kind of feedback I was looking for. Thank you!

Nothing is set in stone, I just wanted to probe the community and see
what people thought. :)

-Erich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

Hi Neal,

On Wed, 2020-06-10 at 12:44 -0400, Neal Gompa wrote:
> On Wed, Jun 10, 2020 at 12:10 PM  wrote:
> > Hi all,
> > 
> > I'm considering moving Fedora Jam from KDE Plasma to GNOME. There
> > are
> > multiple reasons for this, and I think part of it would be
> > beneficial
> > to the overall GNOME and Fedora communities as it would be a way to
> > be
> > helping improve the situation in GNOME that exist as the biggest
> > objections from the community of musicians and Linux audio
> > enthusiasts
> > in the overall community.
> > 
> > The biggest objections are resource usage, since the more resources
> > that are in use, the more it tends to interfere with real-time
> > audio
> > processes, causing buffer overruns and/or underruns. These overruns
> > and
> > underruns are known as Xruns. The fewer Xruns, the better, as Xruns
> > cause pops during recording. When doing real-time audio work, you
> > want
> > to have as low of latency as possible which requires as small of a
> > buffer as possible. The goal is to have a small buffer to get
> > minimal
> > latency while avoiding Xruns.
> > 
> > Unfortunately, GNOME has, since 3.0, traditionally interfered with
> > these processes and caused Xruns. My goal, by moving Fedora Jam
> > from
> > Plasma to GNOME, is to help GNOME improve this situation.
> > 
> 
> I would personally be very sad if Fedora Jam switched from KDE to
> GNOME. To me, KDE has always been the home for creatives, and it
> shows
> with the excellent Qt/KDE based software for auditory and visual
> creativity. From my perspective, KDE is the environment that creative
> people can feel at home in.

This is exactly the kind of feedback I'm looking for. Thank you!

> > The other reason for switching away from Plasma is the overall
> > negative
> > attitude I see from Fedora KDE users and former Fedora KDE
> > contributors. It seems to be an attitude against the progress of
> > improving the Linux desktop for the better, and simply complaining.
> > I
> > know some of this attitude comes from Red Hat dropping KDE from
> > being a
> > desktop in REHL, among other changes. That attitude is regressive,
> > and
> > does nothing to help the community if all you do is complain. I
> > could
> > name names, but for the sake of the "Friends" foundation, I will
> > not.
> > 
> 
> As a Fedora KDE user, I hope I'm not lumped in that bucket. :)
> 
> While I am *deeply* disappointed at Red Hat for removing KDE from
> RHEL, that is mostly because people seem to think KDE is no good
> because Red Hat dropped it rather than it being due to lack of
> engineers to support it.
> 
> However, one thing I have been very disappointed about is the
> attitude
> of some folks who are not actively involved or contributing to Fedora
> KDE disparaging virtually everyone else and the work they do. In
> general, it's very much against our tenants, our expectation of being
> excellent to each other, and our philosophy as a community.
> 
> As a member of many major groups in Fedora, including the KDE SIG, I
> do not personally tolerate such disparagement. If there is a
> technical
> foundation for disagreement, then there's something to discuss, but
> personally attacking people is never okay. If I have the ability to
> do
> something about it, I will.
> 

Always good to read you. :)

You are definitely not in that bucket. I see your contributions as
nothing but productive and constructive.

> > Anyhow, I'd love to see a discussion about this as well as any
> > guidance
> > toward making this change. I know there would have to be a new
> > kickstart along with Koji pointing toward said kickstart. I could
> > make
> > the kickstart, but I think I'd need Koji to look for it.
> > 
> 
> The mechanics of making such a change are fairly straightforward:
> change the fedora-jam KS to switch from the KDE base to the GNOME
> base
> in the fedora-kickstarts repository:
> https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-jam_kde.ks
> 
> You'll need to re-rationalize your customizations on top of that, but
> it's doable.

The kickstart is definitely what I would be working in, and the
customizations in there are pretty minimal as you can see.

That said, this whole thing isn't set-in-stone, I just wanted to probe
the community to see what people thought. :)

-Erich

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Iñaki Ucar]

On Wed, 10 Jun 2020 at 18:46, Neal Gompa  wrote:
>
> I would personally be very sad if Fedora Jam switched from KDE to
> GNOME. To me, KDE has always been the home for creatives, and it shows
> with the excellent Qt/KDE based software for auditory and visual
> creativity. From my perspective, KDE is the environment that creative
> people can feel at home in.

Same here, as a musician and Fedora KDE user. :(

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Qiyu Yan

[Robin Lee]

On Thursday, June 11, 2020, Qiyu Yan  wrote:
> I am Qiyu Yan, mail: yanqiy...@gmail.com, a 5-yesr Fedora user and a
undergraduate student in Physics.
>
> I started doing packaging because I want to setup development environment
for my lab's computers, the software I first packaged is geant4 on copr
http://copr.fedorainfracloud.org/coprs/yanqiyu/geant4/
>
> By improving the package forked from someone else, I started to know how
to do packaging. (geant4 is a complexed software, I need more time to
package it well)
>
> But I am not trying to join devel to bring geant4 to official repository
here:
>
> I want to make an open-source anti-censorship proxy software [Trojan](
https://github.com/trojan-gfw/trojan) [GPL-3.0 license] available to
Fedora's official repositories. Will that be  possible? (Its named as
trojan but it is a proxy, which pretends to be a TLS server which makes it
possible to bypass China, or any other government's censorship)
>
> Fedora's official repositories already have a python3-shadowsocks with
similar functions, but that project is likely to be out of maintenance. I
think having a new one will be great.
>
> I have made it to be able to build on [koji](
https://koji.fedoraproject.org/koji/taskinfo?taskID=45580956) what to do
next to carry on?
>
> And I want to add more proxy software, such as [V2ray](
https://github.com/v2ray/v2ray-core) and [Shadowsocks-libev](
https://github.com/shadowsocks/shadowsocks-libev) later.
>
> Why I want to build those proxies into fedora's official repository? That
is because downloading those software from GitHub or COPR will be extremely
slow, but if them can enter official repository, they will be mirrored into
China, which will make it easier to install for Chinese users.
>
> And they are not a Chinese only software, they are also useful when you
don't want someone else to know if you are using a proxy, wireguard or
IPSec just do encryption but not confuse possible attackers.
>

Welcome!
You can follow this guide[0] and submit your first review request.

[0] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Neal Gompa]

On Wed, Jun 10, 2020 at 12:10 PM  wrote:
>
> Hi all,
>
> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
> multiple reasons for this, and I think part of it would be beneficial
> to the overall GNOME and Fedora communities as it would be a way to be
> helping improve the situation in GNOME that exist as the biggest
> objections from the community of musicians and Linux audio enthusiasts
> in the overall community.
>
> The biggest objections are resource usage, since the more resources
> that are in use, the more it tends to interfere with real-time audio
> processes, causing buffer overruns and/or underruns. These overruns and
> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
> cause pops during recording. When doing real-time audio work, you want
> to have as low of latency as possible which requires as small of a
> buffer as possible. The goal is to have a small buffer to get minimal
> latency while avoiding Xruns.
>
> Unfortunately, GNOME has, since 3.0, traditionally interfered with
> these processes and caused Xruns. My goal, by moving Fedora Jam from
> Plasma to GNOME, is to help GNOME improve this situation.
>

I would personally be very sad if Fedora Jam switched from KDE to
GNOME. To me, KDE has always been the home for creatives, and it shows
with the excellent Qt/KDE based software for auditory and visual
creativity. From my perspective, KDE is the environment that creative
people can feel at home in.

> The other reason for switching away from Plasma is the overall negative
> attitude I see from Fedora KDE users and former Fedora KDE
> contributors. It seems to be an attitude against the progress of
> improving the Linux desktop for the better, and simply complaining. I
> know some of this attitude comes from Red Hat dropping KDE from being a
> desktop in REHL, among other changes. That attitude is regressive, and
> does nothing to help the community if all you do is complain. I could
> name names, but for the sake of the "Friends" foundation, I will not.
>

As a Fedora KDE user, I hope I'm not lumped in that bucket. :)

While I am *deeply* disappointed at Red Hat for removing KDE from
RHEL, that is mostly because people seem to think KDE is no good
because Red Hat dropped it rather than it being due to lack of
engineers to support it.

However, one thing I have been very disappointed about is the attitude
of some folks who are not actively involved or contributing to Fedora
KDE disparaging virtually everyone else and the work they do. In
general, it's very much against our tenants, our expectation of being
excellent to each other, and our philosophy as a community.

As a member of many major groups in Fedora, including the KDE SIG, I
do not personally tolerate such disparagement. If there is a technical
foundation for disagreement, then there's something to discuss, but
personally attacking people is never okay. If I have the ability to do
something about it, I will.

> Anyhow, I'd love to see a discussion about this as well as any guidance
> toward making this change. I know there would have to be a new
> kickstart along with Koji pointing toward said kickstart. I could make
> the kickstart, but I think I'd need Koji to look for it.
>

The mechanics of making such a change are fairly straightforward:
change the fedora-jam KS to switch from the KDE base to the GNOME base
in the fedora-kickstarts repository:
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-jam_kde.ks

You'll need to re-rationalize your customizations on top of that, but
it's doable.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[erich]

On Wed, 2020-06-10 at 22:01 +0530, Harsh Jain wrote:
> Hi ,
> I'm not too familiar with Fedora Jam but if you want to minimize
> resource usage , shouldn't XFCE be a better choice since it's less
> intensive with resources . Although Gnome has also reduced resource
> usage since initial 3.x releases as well I think . It's just really
> hard to decide between evrything (l'm de hopping currently as well) .
> Again ,I'm sorry if none of this was useful . 
> Thanks ,
> Harsh 
> 

Hi Harsh,

I also lead Ubuntu Studio and we just moved away from Xfce to KDE
Plasma because we wanted a more-functional desktop for creative
professionals. The resource usage between Xfce and Plasma is neglegable
(about 50MB difference) and KDE is a better choice for graphics artists
(which Ubuntu Studio also covers.

I think you missed the point though: the goal is to help GNOME improve.
I've had conversations with people who want to see GNOME improve in
this regard and want to work with me in improving it. So, this isn't
about simply switching desktops, this is about helping another desktop
improve its situation. If Jam is to switch, it's going to GNOME, that
decision is already made. The "If" is what I'm working on, whether or
not to actually go through with it.  If it does happen, the goal is to
improve GNOME. One can always install whatever desktop they want and do
"dnf groupinstall 'Audio Production'".

I hoep that clears things up, as I think you missed the point. :)

Erich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Harsh Jain]

Hi ,
I'm not too familiar with Fedora Jam but if you want to minimize resource
usage , shouldn't XFCE be a better choice since it's less intensive with
resources . Although Gnome has also reduced resource usage since initial
3.x releases as well I think . It's just really hard to decide between
evrything (l'm de hopping currently as well) . Again ,I'm sorry if none of
this was useful .
Thanks ,
Harsh

On Wed, 10 Jun, 2020, 21:40 ,  wrote:

> Hi all,
>
> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
> multiple reasons for this, and I think part of it would be beneficial
> to the overall GNOME and Fedora communities as it would be a way to be
> helping improve the situation in GNOME that exist as the biggest
> objections from the community of musicians and Linux audio enthusiasts
> in the overall community.
>
> The biggest objections are resource usage, since the more resources
> that are in use, the more it tends to interfere with real-time audio
> processes, causing buffer overruns and/or underruns. These overruns and
> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
> cause pops during recording. When doing real-time audio work, you want
> to have as low of latency as possible which requires as small of a
> buffer as possible. The goal is to have a small buffer to get minimal
> latency while avoiding Xruns.
>
> Unfortunately, GNOME has, since 3.0, traditionally interfered with
> these processes and caused Xruns. My goal, by moving Fedora Jam from
> Plasma to GNOME, is to help GNOME improve this situation.
>
> The other reason for switching away from Plasma is the overall negative
> attitude I see from Fedora KDE users and former Fedora KDE
> contributors. It seems to be an attitude against the progress of
> improving the Linux desktop for the better, and simply complaining. I
> know some of this attitude comes from Red Hat dropping KDE from being a
> desktop in REHL, among other changes. That attitude is regressive, and
> does nothing to help the community if all you do is complain. I could
> name names, but for the sake of the "Friends" foundation, I will not.
>
> Anyhow, I'd love to see a discussion about this as well as any guidance
> toward making this change. I know there would have to be a new
> kickstart along with Koji pointing toward said kickstart. I could make
> the kickstart, but I think I'd need Koji to look for it.
>
> Thanks and best regards,
> Erich
> 
> Erich Eickmeyer
> Fedora Jam
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Qiyu Yan

[Qiyu Yan]

I am Qiyu Yan, mail: yanqiy...@gmail.com, a 5-yesr Fedora user and a 
undergraduate student in Physics.

I started doing packaging because I want to setup development environment for 
my lab's computers, the software I first packaged is geant4 on copr 
http://copr.fedorainfracloud.org/coprs/yanqiyu/geant4/

By improving the package forked from someone else, I started to know how to do 
packaging. (geant4 is a complexed software, I need more time to package it well)

But I am not trying to join devel to bring geant4 to official repository here:

I want to make an open-source anti-censorship proxy software 
[Trojan](https://github.com/trojan-gfw/trojan) [GPL-3.0 license] available to 
Fedora's official repositories. Will that be  possible? (Its named as trojan 
but it is a proxy, which pretends to be a TLS server which makes it possible to 
bypass China, or any other government's censorship)

Fedora's official repositories already have a python3-shadowsocks with similar 
functions, but that project is likely to be out of maintenance. I think having 
a new one will be great. 

I have made it to be able to build on 
[koji](https://koji.fedoraproject.org/koji/taskinfo?taskID=45580956) what to do 
next to carry on?

And I want to add more proxy software, such as 
[V2ray](https://github.com/v2ray/v2ray-core) and 
[Shadowsocks-libev](https://github.com/shadowsocks/shadowsocks-libev) later.

Why I want to build those proxies into fedora's official repository? That is 
because downloading those software from GitHub or COPR will be extremely slow, 
but if them can enter official repository, they will be mirrored into China, 
which will make it easier to install for Chinese users. 

And they are not a Chinese only software, they are also useful when you don't 
want someone else to know if you are using a proxy, wireguard or IPSec just do 
encryption but not confuse possible attackers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Jam switch to GNOME

[erich]

Hi all,

I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
multiple reasons for this, and I think part of it would be beneficial
to the overall GNOME and Fedora communities as it would be a way to be
helping improve the situation in GNOME that exist as the biggest
objections from the community of musicians and Linux audio enthusiasts
in the overall community.

The biggest objections are resource usage, since the more resources
that are in use, the more it tends to interfere with real-time audio
processes, causing buffer overruns and/or underruns. These overruns and
underruns are known as Xruns. The fewer Xruns, the better, as Xruns
cause pops during recording. When doing real-time audio work, you want
to have as low of latency as possible which requires as small of a
buffer as possible. The goal is to have a small buffer to get minimal
latency while avoiding Xruns.

Unfortunately, GNOME has, since 3.0, traditionally interfered with
these processes and caused Xruns. My goal, by moving Fedora Jam from
Plasma to GNOME, is to help GNOME improve this situation.

The other reason for switching away from Plasma is the overall negative
attitude I see from Fedora KDE users and former Fedora KDE
contributors. It seems to be an attitude against the progress of
improving the Linux desktop for the better, and simply complaining. I
know some of this attitude comes from Red Hat dropping KDE from being a
desktop in REHL, among other changes. That attitude is regressive, and
does nothing to help the community if all you do is complain. I could
name names, but for the sake of the "Friends" foundation, I will not.

Anyhow, I'd love to see a discussion about this as well as any guidance
toward making this change. I know there would have to be a new
kickstart along with Koji pointing toward said kickstart. I could make
the kickstart, but I think I'd need Koji to look for it.

Thanks and best regards,
Erich

Erich Eickmeyer
Fedora Jam
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

A few questions about a package update / policy questions / GCC 9 error

[Nathanael D. Noblet]

Hello,

  I maintain beanstalkd which is a message server of sorts. It recently
released a new version however some changes I'm not 100% sure about.

  When compiling I got the following GCC error.

usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
specified bound 201 equals destination size [-Werror=stringop-
truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
(__dest));
  |  ^~


Results via google says that strncpy needs to have the third argument
less than the 2nd, so I've got this patch, similar to others:

--- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
+++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
@@ -12,7 +12,7 @@
 if (!t)
 return NULL;

-strncpy(t->name, name, MAX_TUBE_NAME_LEN);
+strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
 if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
 t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
 twarnx("truncating tube name");

You'll notice it was already checking the len-1 for null. Can anyone
verify that my change won't cause some un-intended bug I don't
understand?

Finally, they also now support socket activation. Which means I was
looking at .service file which I had setup to use a sysconfig
environment file. When I looked at it, I realized that the default was
to listen to 0.0.0.0 which means someone could install and if not
really careful / pre config or what not have a service listening where
they maybe don't want to. I was thinking of changing this to 127.0.0.1
with a note about how it should be modified. However I figure if I do
that, anyone with this installed and unmodified who gets the update
will suddenly have their service stop listening to the outside world.
What should be done then? 

My thought is I leave it as 0.0.0.0 for all released versions (but what
about epel7) and then in rawhide change to 127.0.0.1. I just don't like
leaving the package like that for epel as well.

Any ideas/direction would be appreciated.

Sincerely,
-- 
Nathanael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Datacenter move day 2

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 10 June 2020 at 08:24, Kevin Fenzi wrote:
> Greetings everyone. 
> 
> Just a quick recap of our day 2 datacenter move. 

Thanks for all your hard work and for providing these (not so little)
updates!

I hope you get some well-deserved rest after all is done.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Stefano Figura (returntrip)

[Alessio]

Hello Stefano. Welcome!

Ciao,
A.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Stefano Figura (returntrip)

[Germano Massullo]

Hi Stefano, welcome among Fedora contributors!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Stefano Figura (returntrip)

[Stefano Figura via devel]

Hi Folks,

I have recently started working on packaging Alacritty (together with Michel 
Alexandre Salim, which has been of great help both as a sponsor and as a 
mentor) and submitted a few rust packages to the Fedora project.

Beside that, I have created a few PRs for the Silverblue Docs/Site repos and I 
enjoy providing help in the Silverblue IRC channel and forums.

I have been a Linux user since around 2005 but have not done any packaging (or 
serious development) before that. 

This is all new to me, so please be patient! :)

Thanks!

Kind Regards,
Stefano___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Unretire: R-AnnotationDbi

[Tom Callaway]

Hello Fedorans,

It is my intent to revive R-AnnotationDbi, as it is needed to update
R-biomaRt. I've already done the review request here:

https://bugzilla.redhat.com/show_bug.cgi?id=1845360

Thanks,
Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Artur Iwicki]

Welp, too late, I already took it. I tried to trigger the retirement procedure, 
but I can't get write access to git-scm, so I decided to just file a releng 
ticket: https://pagure.io/releng/issue/951
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Datacenter move day 2

[Dan Horák]

On Wed, 10 Jun 2020 12:55:08 +0200
Dan Horák  wrote:

> On Wed, 10 Jun 2020 12:46:15 +0200
> Dan Horák  wrote:
> 
> > On Wed, 10 Jun 2020 12:17:42 +0200
> > Dan Horák  wrote:
> > 
> > > On Tue, 9 Jun 2020 23:24:57 -0700
> > > Kevin Fenzi  wrote:
> > > 
> > > > Greetings everyone. 
> > > > 
> > > > Just a quick recap of our day 2 datacenter move. 
> > > > 
> > > > Today was the buildsystem and all it's assocated things. 
> > > > 
> > > > As for builders in the new datacenter, we have 32 buildvm's, 40
> > > > buildvm-ppc64's, the same number of s390x (15) and 15 each of
> > > > buildvm-a64 (aarch6) and buildvm-a32 (armv7/armhfp). So, likely
> > > > arm builds are going to be the last to finish for many. Luckily
> > > > this only needs to last us a few weeks until we can get the rest
> > > > of our arm builders shipped and re-added. 
> > > 
> > > I see only the 2nd group (KVM) of s390x builders being enabled, is
> > > that right?
> > 
> > and they are experiencing the "incomplete srpm" issue frequently :-(
> 
> might be a problem with their cache

and Smooge fixed the cache config, so the s390x builders work again


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora QA Global Onboarding Call 2020-06-10 1700-1900UTC

[Sumantro Mukherjee]

Hey All,

This is a gentle reminder that the Fedora QA onboarding call is
happening *today* at 1700-1900 UTC.  We will focus on helping the new
contributors to start contributing right away. The meeting will be on
Bluejeans, with a 'hackmd'[1] for text notes. The agenda is already on
the hackmd and is designed to ensure that newcomers can make the most
without any prerequisites.

To join the meeting, just open the hackmd and find the bluejeans URL.

 Let's make the most of today's session and make Fedora better!

[1] https://hackmd.io/3V3xwrEcRtyf381wJvZr1g


-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Datacenter move day 2

[Dan Horák]

On Wed, 10 Jun 2020 12:46:15 +0200
Dan Horák  wrote:

> On Wed, 10 Jun 2020 12:17:42 +0200
> Dan Horák  wrote:
> 
> > On Tue, 9 Jun 2020 23:24:57 -0700
> > Kevin Fenzi  wrote:
> > 
> > > Greetings everyone. 
> > > 
> > > Just a quick recap of our day 2 datacenter move. 
> > > 
> > > Today was the buildsystem and all it's assocated things. 
> > > 
> > > As for builders in the new datacenter, we have 32 buildvm's, 40
> > > buildvm-ppc64's, the same number of s390x (15) and 15 each of
> > > buildvm-a64 (aarch6) and buildvm-a32 (armv7/armhfp). So, likely
> > > arm builds are going to be the last to finish for many. Luckily
> > > this only needs to last us a few weeks until we can get the rest
> > > of our arm builders shipped and re-added. 
> > 
> > I see only the 2nd group (KVM) of s390x builders being enabled, is
> > that right?
> 
> and they are experiencing the "incomplete srpm" issue frequently :-(

might be a problem with their cache


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Datacenter move day 2

[Dan Horák]

On Wed, 10 Jun 2020 12:17:42 +0200
Dan Horák  wrote:

> On Tue, 9 Jun 2020 23:24:57 -0700
> Kevin Fenzi  wrote:
> 
> > Greetings everyone. 
> > 
> > Just a quick recap of our day 2 datacenter move. 
> > 
> > Today was the buildsystem and all it's assocated things. 
> > 
> > As for builders in the new datacenter, we have 32 buildvm's, 40
> > buildvm-ppc64's, the same number of s390x (15) and 15 each of
> > buildvm-a64 (aarch6) and buildvm-a32 (armv7/armhfp). So, likely arm
> > builds are going to be the last to finish for many. Luckily this
> > only needs to last us a few weeks until we can get the rest of our
> > arm builders shipped and re-added. 
> 
> I see only the 2nd group (KVM) of s390x builders being enabled, is
> that right?

and they are experiencing the "incomplete srpm" issue frequently :-(


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Datacenter move day 2

[Dan Horák]

On Tue, 9 Jun 2020 23:24:57 -0700
Kevin Fenzi  wrote:

> Greetings everyone. 
> 
> Just a quick recap of our day 2 datacenter move. 
> 
> Today was the buildsystem and all it's assocated things. 
> 
> As for builders in the new datacenter, we have 32 buildvm's, 40
> buildvm-ppc64's, the same number of s390x (15) and 15 each of
> buildvm-a64 (aarch6) and buildvm-a32 (armv7/armhfp). So, likely arm
> builds are going to be the last to finish for many. Luckily this only
> needs to last us a few weeks until we can get the rest of our arm
> builders shipped and re-added. 

I see only the 2nd group (KVM) of s390x builders being enabled, is that
right?


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Kevin Kofler]

John M. Harris Jr wrote:
> What's even more wild is that you can't easily disable it. Even though
> it's supposed to be disabled ("vendor preset: disabled") it's actually
> built into systemd, as a static unit.

Have you tried masking the units? Disabling tends to have only limited 
success (because it only disables the unit loading by itself, but not it 
getting loaded by other units), masking is more effective.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [ELN] Opt out python2.7 from ELN

[Vít Ondruch]

You should probably open PR modifying this file:

https://github.com/minimization/content-resolver-input/blob/master/configs/view-eln.yaml

But I would expect that somebody else from the ELN provided more prompt
guidance on questions like these ...


Vít


Dne 08. 06. 20 v 16:49 Miro Hrončok napsal(a):
> Hello,
>
> as a maintainer of the python2.7 package I was surprised to see it
> being built for ELN and I like to start a discussion on whether and
> how can I opt out this deprecated package from ELN.
>
> Since there is no tracker or dedicated mailing list, I am following
> the advice given somewhere else on devel, to use this list, possibly
> with the [ELN] marker in subject.
>
> Thanks,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Leigh Scott]

> I use Cinnamon as the main DE on one of my machines, and the package
> doesn't look like something that requires a lot of maintenance, so I'll take 
> it.

Please don't do that, cinnamon-themes is a dead package

https://github.com/linuxmint/cinnamon-themes

mint-themes provides cinnamon-themes  
https://src.fedoraproject.org/rpms/mint-themes/blob/master/f/mint-themes.spec#_35
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org