[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a5eb3ef5   
librabbitmq-0.5.2-2.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-22ba261c73   
drupal7-ckeditor-1.19-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-082ab81e5f   
php-robrichards-xmlseclibs1-1.4.3-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

php-phpseclib-2.0.27-1.el6
prosody-0.11.5-1.el6

Details about builds:



 php-phpseclib-2.0.27-1.el6 (FEDORA-EPEL-2020-cdd04820fb)
 PHP Secure Communications Library

Update Information:

**Version 2.0.27**  *SFTP: change the mode with a SETSTAT instead of MKDIR
(#1463) *SFTP: make it so extending SFTP class doesn't cause a segfault
(#1465) *Random::string didn't always return all the requested bytes (#1466)
  **Version 2.0.26**  *SFTP: another attempt at speeding up uploads
(#1455) *SSH2: try logging in with none as an auth method first (#1454) *
ASN1: fix for malformed ASN1 strings (#1456)

ChangeLog:

* Mon Apr  6 2020 Remi Collet  - 2.0.27-1
- update to 2.0.27
* Mon Mar 23 2020 Remi Collet  - 2.0.26-1
- update to 2.0.26




 prosody-0.11.5-1.el6 (FEDORA-EPEL-2020-6804a5d4bf)
 Flexible communications server for Jabber/XMPP

Update Information:

Prosody 0.11.5 ==  This release mostly adds command line flags to
force foreground or background operation, which replaces and deprecates the
`daemonize` option in the config file.  Fixes and improvements
--* prosody / mod_posix: Support for command-line flags
to override `daemonize` config option  Minor changes -*
mod_websocket: Clear mask bit when reflecting ping frames (fixes #1484:
Websocket masks pong answer)

ChangeLog:

* Mon Apr  6 2020 Robert Scheck  0.11.5-1
- Upgrade to 0.11.5 (#1816855)

References:

  [ 1 ] Bug #1816855 - prosody-0.11.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1816855


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: v4l2loopback kernel module in Fedora?

[stan via devel]

On Mon, 6 Apr 2020 23:47:53 -0400
Christopher  wrote:

> I actually got it working with v4l2loopback. It normally works quite

That's great!

> well. But, changing settings still crashes.

That's not.

> Literally, all I have to do is: File -> Settings -> toggle any setting
> (just to make "Apply" button available) -> click Apply
> This results in a Segmentation fault every time.
> In any case, the settings are usually saved first, so when I restart,
> it's fine. If I get the motivation, I'll file a bug against the
> RPMFusion package.

Strange that the behavior is so different, especially on something as
basic as changing settings.

> As for the original issue regarding packaging: there is a ticket being
> tracked to get it upstream into the kernel:
> https://github.com/umlaeute/v4l2loopback/issues/268

Interesting, though I probably won't ever have a use for it, I think
I'll try building it into a custom kernel just for fun.  Since it
doesn't seem to be changing a lot, once and done.
___
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

[Bug 987118] perl-5.18: File handles modified with binmode ':unix' leak

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-5.30.2-453.fc33|perl-5.30.2-453.fc33
   ||perl-5.30.2-452.fc32
 Resolution|--- |ERRATA
Last Closed||2020-04-07 05:05:12



--- Comment #33 from Fedora Update System  ---
FEDORA-2020-3472d53a15 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Qt 5.14.2 coming to rawhide

[Rex Dieter]

Rex Dieter wrote:

> FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> progress being done in side tag f33-build-side-21031
> 
> I figure it'll take at least a few days to get the core bits and all
> dependencies rebuilt.  Will provide status updates as warranted.

Fist batch of builds completed, bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c

Hope I did that right, with:
bodhi updates new --from-tag ...
according to https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/

There were a handful of failures, largely in 2 classes:
* FTBFS for reasons other than Qt itself
* a couple due to what I think are Qt 5.14.2 configuration issues (e.g. 
mscore), there's some issue with either translations or datadir in general 
where some full paths that should be /usr/share/... end up referenced as 
what appears to be a broken partial relative path looking like /../share/...

I'll be digging into both more in depth starting tomorrow.

-- Rex
___
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: v4l2loopback kernel module in Fedora?

[Christopher]

On Mon, Apr 6, 2020 at 1:00 PM stan via devel
 wrote:
>
> On Sun, 5 Apr 2020 21:44:16 -0400
> Christopher  wrote:
>
> > I'm probably going to abandon the effort anyway. obs-studio in Fedora
> > crashes constantly every time I try to change the settings and save,
> > so I couldn't figure out how to get it to work with v4l2loopback. I
>
> You are using obs in a different way than I am, but it works without
> issue here for my unsophisticated use.  I've never had a crash.  F31.  I
> am able to change settings, I changed the keymappings to use the left
> windows key, finally getting some use out of it.  I am using X, and I
> start obs from a terminal so if anything *does* go wrong, I see the
> output from the program.  I've been really pleased with its
> performance, though I'm sure I'm not really stressing it out the way
> you want to.

I actually got it working with v4l2loopback. It normally works quite
well. But, changing settings still crashes.
Literally, all I have to do is: File -> Settings -> toggle any setting
(just to make "Apply" button available) -> click Apply
This results in a Segmentation fault every time.
In any case, the settings are usually saved first, so when I restart, it's fine.
If I get the motivation, I'll file a bug against the RPMFusion package.

As for the original issue regarding packaging: there is a ticket being
tracked to get it upstream into the kernel:
https://github.com/umlaeute/v4l2loopback/issues/268
___
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: v4l2loopback kernel module in Fedora?

[Christopher]

On Mon, Apr 6, 2020 at 5:35 AM Momčilo Medić
 wrote:
>
> On Mon, 2020-04-06 at 04:40 -0400, Christopher wrote:
> > On Mon, Apr 6, 2020 at 3:59 AM Iñaki Ucar 
> > wrote:
> > > On Mon, 6 Apr 2020 at 03:53, Christopher <
> > > ctubb...@fedoraproject.org> wrote:
> > > > The previous packaging was on COPR, but it appears abandoned,
> > > > probably
> > > > because it's kind of worthless if it's not signed. And, it's a
> > > > lot of
> > > > manual work to self-sign and register the key with mokutil, and
> > > > even
> > > > more effort to figure out how to get DKMS to automatically sign
> > > > after
> > > > building, on kernel updates.
> > > >
> > > > I don't know enough about RPMFusion packaging. I use RPMFusion,
> > > > but
> > > > haven't looked into the contribution process. In particular, I
> > > > wonder
> > > > if their modules are signed by a key that's already trusted in
> > > > Fedora.
> > > > My guess is not, and then it's the same problem as with COPR.
> > >
> > > I don't know. But if you want to keep SecureBoot enabled, probably
> > > the
> > > only way to go is to work with upstream to get the module into the
> > > mainline kernel. If this module is as popular as it seems, it
> > > shouldn't be hard to find more people interested and more hands to
> > > do
> > > the necessary work.
> > >
> > > > I'm probably going to abandon the effort anyway. obs-studio in
> > > > Fedora
> > > > crashes constantly every time I try to change the settings and
> > > > save,
> > >
> > > Let me guess... GNOME Wayland session? I got a bug report in a Qt
> > > package I maintain with this kind of issue. It's fixed by setting
> > > QT_QPA_PLATFORM=xcb. Please, file a bug and tell obs' maintainer
> > > that
> > > the best way to workaround the lack of Wayland compatibility is to
> > > add
> > > that to obs' .desktop file as follows:
> > >
> > > Exec=env QT_QPA_PLATFORM=xcb obs-studio
> >
> > GNOME, but I think it happens in both Xorg and Wayland. I haven't
> > attempted to troubleshoot this. One thing at a time. :)
>
> Do let me know if you face any issues with OBS Studio under Fedora.
> I'm really trying to keep it in good shape, and up-to-date.
>
> If you experience any issues the best thing to do is to report a bug on
> RPMFusion.

Sure. Can do. Where's the issue tracker URL?
___
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

[Bug 1820788] perl-Rose-DB-Object-0.817 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-9645680d5e has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-9645680d5e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9645680d5e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1820787] perl-Rose-DB-0.783 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-a90b4a9d04 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-a90b4a9d04`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a90b4a9d04

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-04-07 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/04/07/report-389-ds-base-1.4.3.5-20200406gitc868a41.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[Bug 1820787] perl-Rose-DB-0.783 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-9e85c23a5d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-9e85c23a5d`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9e85c23a5d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1820788] perl-Rose-DB-Object-0.817 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-62f890cc77 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-62f890cc77`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-62f890cc77

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1814114] perl-Gtk3-0.037 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-11b578e45f has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-11b578e45f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-11b578e45f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1806473] perl-Gtk3-0.036-2.fc33 FTBFS: Can't find information for method TreeModel::sort_new_with_model at t/overrides.t line 466.

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-11b578e45f has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-11b578e45f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-11b578e45f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Bruno Wolff III]

On Mon, Apr 06, 2020 at 16:02:34 +0100,
 Leigh Griffin  wrote:


Our stakeholder and engagement point as a team is Fedora Council. If you
have issues with how this was handled from a relationship perspective then
please take that up with the Council. We have engaged with fesco in the
past at the request of Council and will engage with them in the future in a
similar manner.


I think this is a good idea. While it is clear a lot of people participating 
in this discussion don't like what or how things happened. We can't each 
decide how things are going to be or we will have a lot of conflicting 
action plans. Further arguing with Leigh doesn't seem likely to be very 
productive. Given the tone of some of the replies, Leigh has been 
surprisingly gracious in continuing to engage on this mailing list.


We should be taking this up with the council to see what is possible and 
how we might proceed forward. 
___

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: Urgently downgrade xorg-x11-drv-intel

[Paul Dufresne via devel]

Le 20-04-06 à 15 h 34, Adam Jackson a écrit :

On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
I think we have a fix for that. Let me poke at things a bit. 


Have read: 
https://www.phoronix.com/scan.php?page=news_item=Mesa-i915-OpenGL-2-Drop


In the link Alexei posted to Arch, the following workaround is given:

In /etc/drirc

...






...


And a link is given to show how to apply it to only some applications (like 
X!?):
https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/

I alse see the following change from Adam Jackson:
https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/c/c4ced62fa2de98fd727c917486e58b1e753d23f9?branch=master
that boost the git version from 20180618 to 20200205.

BTW, thanks I was searching for an example of package using a git version 
rather than a released archive!

Well, I don't have an opinion on the request from Alexei to downgrade the 
package before release... I am mostly trying to understand what is going on.

 

___
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: CPE Git Forge Decision

[Randy Barlow]

On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how 
the team historically worked. As a team we are being tasked more and 
more with adding what I call real value which is at a new app / service 
level that has scale, quality and requirements that historically a 
single developer could not call on. We had some superhuman developers in 
the past in the team that were able to do every single thing an 
application needed and produced some wonderful applications that in 
truth would have taken 10 or more developers to replicate. That team has 
moved on now and the old style of working was not going to meet the 
needs and wants of our stakeholders (in this case Fedora Council) and a 
repurposing of the team to make visible impacts was undertaken. So while 
we cannot have multiple commits across a plethora of services, we are 
not focusing our efforts on singular services at a time to generate a 
value proposition for the community. Sorry once again if you took my 
comment up as being a sleight, it was most definitely not intended and 
you have my sincere apologies.


There's more wrong with the above than I already pointed out. In this 
paragraph, you:


* Double down the message of implying the the work done in the past
  didn't add real value,
* Insult your current team, implying that they haven't reached the
  apparently "superhuman" standards of the past,
* Triple down on disparaging the efforts of past developers by implying
  that only now is the work of the CPE team having "visible impacts".
___
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: Announcing start of DNF 5 development

[Neal Gompa]

On Mon, Apr 6, 2020 at 8:08 PM Adam Williamson
 wrote:
>
> On Mon, 2020-04-06 at 23:56 +, Tom Seewald wrote:
> > Yep, I just ran "dnf info kernel" and then right after that "dnf
> > changelog kernel", in both cases dnf spent over 20 seconds syncing.
> > I haven't seen other package managers require this much network
> > traffic, and I wonder if a lot of it could be avoided.
>
> If you only want to query *locally installed* packages, you can just
> use rpm:
>
> rpm -qi kernel
> rpm -q --changelog kernel
>
> if you use DNF, it will get the info for packages that are in the
> repositories but not locally installed, as well. changelogs are kept
> and retrieved separately, I believe, as they aren't needed for any
> other operations, so that's why you see remote trips on both commands,
> I think.

With the exception of changelogs (which requires downloading other.xml
metadata), all query actions should be possible to perform with DNF
with --cacheonly flag, which will use the system cache or local user
cache if it hasn't expired yet.

I have heard from people that the cache is expiring prematurely in
some cases (thus forcing more metadata downloads), but I haven't been
able to reproduce it myself.



-- 
真実はいつも一つ！/ 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: Announcing start of DNF 5 development

[Adam Williamson]

On Mon, 2020-04-06 at 23:56 +, Tom Seewald wrote:
> Yep, I just ran "dnf info kernel" and then right after that "dnf
> changelog kernel", in both cases dnf spent over 20 seconds syncing. 
> I haven't seen other package managers require this much network
> traffic, and I wonder if a lot of it could be avoided.

If you only want to query *locally installed* packages, you can just
use rpm:

rpm -qi kernel
rpm -q --changelog kernel

if you use DNF, it will get the info for packages that are in the
repositories but not locally installed, as well. changelogs are kept
and retrieved separately, I believe, as they aren't needed for any
other operations, so that's why you see remote trips on both commands,
I think.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

On Mon, Apr 6, 2020 at 6:03 PM Adam Jackson  wrote:

> On Mon, 2020-04-06 at 16:28 -0400, Paul Dufresne via devel wrote:
> > Le 20-04-06 à 15 h 34, Adam Jackson a écrit :
> > > On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
> > > > Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
> > > > 2.1 used to be enabled on this hardware, but got dropped
> > > I think we have a fix for that. Let me poke at things a bit.
> > >
> > Euh... maybe that?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1762151#c20
>
> Yeah, applying that makes X start, but then the screen is all black
> instead of showing me anything.
>

OpenGL 2.1 and modesetting was disabled for the old Intel GMA because they
need software fragment shader, which hurts some program including Chrome.
It only make sense to enable it again if that issue is resolved or if the
itel driver is even worse. The easy alternative is still downgrading the
intel driver to a working state or following up on fixing it rather soon.
___
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: Announcing start of DNF 5 development

[Tom Seewald]

Yep, I just ran "dnf info kernel" and then right after that "dnf changelog 
kernel", in both cases dnf spent over 20 seconds syncing.  I haven't seen other 
package managers require this much network traffic, and I wonder if a lot of it 
could be avoided.
___
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: CPE Git Forge Decision

[Dan Čermák]

Leigh Griffin  writes:

>> If you had stopped at the first
>> objections and revisited the decision making process with the rest of
>> the community involved in an open manner, you would have been forgiven,
>> because everyone here is trying to assume good faith. Alas, you haven't
>> done that. Apologizing for your mistakes is a necessary step, but it's
>> not sufficient.
>>
>
> Ok let's scenario this out so as several people want us to restart and go
> again, largely because they disagree with the decision and Pagure is the
> choice that they would have made. If we re-engage now, I firmly believe we
> will get a whole new set of requirements to complement the existing
> requirements but scoped deliberately (as has been suggested by numerous
> replies) to a situation where Pagure is the only choice for Fedora.

And how will that be different from your initial set of requirements,
that had far too surprising similarities to GitLab EE's features?

I really don't like to jump in and start pointing fingers, but during
the initial discussion of the requirements, it was pointed out multiple
times that all of this looks like a pretense to ditch Pagure for
Gitlab. So honestly, I really don't see how that would make the process
so far more unfair (it would actually make it more fair to all Fedora
contributors who value Pagure & the associated values and who are
feeling increasingly ignored and betrayed).


Regards,

Dan


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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Miro Hrončok]

On 07. 04. 20 0:47, Justin Forbes wrote:

On Mon, Apr 6, 2020 at 5:24 PM Miro Hrončok  wrote:

On 06. 04. 20 23:53, Stephen Gallagher wrote:

* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.

As a side note (probably out of scope of this proposal), I think that if we have
RHEL packages in Fedora with not very responsive maintainers, the RHEL
maintainer should really try to get themselves involved in those (or start being
responsive in case the RHEL maintainers are the Fedora maintainers).


I think that is a desired side effect of ELN.


I hope it is. What I try to say is that if we "ignore" that packagers are not 
responsive by merging the fix and going away, we are postponing the problem.


Instead (or better: in addition to that), we should nudge the appropriate RHEL 
maintainers to offer help with the Fedora package (and initiate the 
nonresponsive maintainer procedure if that is the only way to participate).


With special emphasis on RHEL packagers who "maintain" the packages in Fedora, 
but are not responding (which happens quite often frankly).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: CPE Weekly: 2020-04-04

[Dan Čermák]

Ben Rosser  writes:

> On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel  wrote:
>>
>> - Original Message -
>> > From: "Nicolas Mailhot via devel" 
>> > To: "Development discussions related to Fedora" 
>> > 
>> > Cc: "Nicolas Mailhot" 
>> > Sent: Monday, April 6, 2020 9:10:56 AM
>> > Subject: Re: CPE Weekly: 2020-04-04
>> >
>> > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>> > >
>> > > It'd be interesting to see if the FESCo election system could be
>> > > repurposed to get a sense of all packagers' opinions, rather than
>> > > make assumptions on how the community as a whole feels based on a few
>> > > vocal members and their participation in the mailing lists.
>> >
>> >
>> > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
>> > so it’s the official place to reach Fedora packagers.
>>
>> That's not the point I was making.
>>
>> Not everyone is inclined to loudly argue their positions on the mailing
>> list. There have only been 12 unique participants to this thread and 57
>> to the other thread.
>>
>> That isn't indicative of the entire Fedora packager ecosystem. A lot of
>> people are staying silent.
>>
>>
>> I believe we need a different way to engage the rest of our packager
>> base.
>
> I'm a packager who has been staying silent, but I generally strongly
> agree with the points that Adam, Miro, Neal, and others have been
> making

As a $nobody that has stayed silent so far, I'd second this: essentially
everything that I would have said, has already been said and ignored
over and over and over again. Honestly, I don't see a point in repeating
the same things again, just to get a polite "we're terribly sorry how we
handled this, but no, we've decided to stick with gitlab"

> with a few caveats:
>
> * I don't _really_ mind if we wind up using Gitlab over Pagure, but if
> we do, I do feel pretty strongly that we should use Gitlab CE and
> self-host it-- I don't think it would be right for Fedora to use an
> externally hosted solution and I don't think we should use the
> enterprise edition.

I would very much prefer Pagure, mostly because it is one of the few
true FLOSS git forges and we're currently it's biggest user.

>
> * I don't like how this process has been conducted, and I think that
> official responses from CPE thus far haven't really made things
> better-- if anything, the "we apologize, but this is the decision
> we've made" attitude is making things worse.

Exactly. All threads that have unraveled so far only make me
increasingly frustrated and let me feel more and more powerless: if even
established and respected community members cannot make the CPE
reconsider and go back to the drawing board, then what on earth can I
do? Why should I even try to make a positive impact in the Fedora
community, if the CPE doesn't even consider our core values? What will
be ditched next for a proprietary SaaS solution? (yes I am exaggerating
on purpose with the last one)

>
> * I fear that, once again, we haven't adequately understood the
> consequences of replacing pagure and some of the features that were
> recently-- finally!-- added to it in order to replace missing pkgdb2
> functionality will again be lost for a long period of time... and
> nothing I've read in any of these threads so far has helped reassure
> me that's not the case.

Your fear has been confirmed multiple times by Leigh Griffin: there is
*no* plan or analysis yet how the currently required features of our
pagure dist-git can be implemented in gitlab and how much that will
cost (how that does not defeat the original purpose of this whole ordeal
is beyond me).

I honestly have nothing more to add to that, as imho the last paragraph
already tells us how this thing will end :-(


Dan


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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Neal Gompa]

On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher  wrote:
>
>
>
> On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:
>>
>> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
>> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
>> * Likewise, I think the Koji tags should be versioned too.
>>
>> I've personally been burned enough times by not having versioned
>> DistTags for personal rebuilds that I would strongly suggest you
>> reconsider having unversioned ones.
>
> Would you mind explaining some of the situations in which you were burned? 
> I’m not ruling this out, but I’d like a clear justification if we were to 
> change something.
>

So, prior to me building my packages in OBS and getting auto-bumping
Releases, I used to bump into issues all the time with building
openSUSE packages in an environment like Koji's, where the NVR is the
key for a unique package. openSUSE does *not* define a DistTag or the
%dist variable, so %{?dist} evaluates to nothing. If you're doing
rebuilds of your packages with no source changes from one release of
openSUSE to the next, or rebuilding for new Tumbleweed snapshots,
you're going to get collisions all the time, and builds will just fail
because the NVR already exists.

This is utter chaos and you *really* don't want that problem on your
hands. Having the freedom to do a rebuild cycle for ELN whenever you
want to rebootstrap to a new major without changing sources is a
hugely valuable thing to be able to do.

And honestly, I expect the ELN tree to exist for a long time once it's
in Fedora. So some of this is also planning for a future where we
always have Fedora ELN along with Rawhide and regular Fedora stable
releases.

What I'm confused about is the hangup with versioning the ELN tree.
Why is this a problem?

>
>>
>> Finally, there is no adequate explanation for why ELN content can't go
>> out to the mirrors like Rawhide content does. I'd vastly prefer that
>> simply to have similar levels of availability as consumers of ELN
>> content. I would prefer seeing it go to the mirror network like
>> everything else.
>
>
>
> It’s not so much that it *cannot* as that we are trying not to overload the 
> mirror network with content not useful to non-developers.
>

Unless you plan to get Red Hat to do CDN delivery of ELN, I think
you're going to want it on the mirror network anyway. Ultimately,
contributors like myself need to be able to *use* the content, and not
having it delivered via the mirror network means that it's going to be
painful for a large cross-section of contributors and developers.


-- 
真実はいつも一つ！/ 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Justin Forbes]

On Mon, Apr 6, 2020 at 5:24 PM Miro Hrončok  wrote:
>
> On 06. 04. 20 23:53, Stephen Gallagher wrote:
> > * Clarify that the time limit on PRs is only for determining if the
> > maintainer is responsive. If they reply, the timer is cleared.
>
> As a side note (probably out of scope of this proposal), I think that if we 
> have
> RHEL packages in Fedora with not very responsive maintainers, the RHEL
> maintainer should really try to get themselves involved in those (or start 
> being
> responsive in case the RHEL maintainers are the Fedora maintainers).
>

I think that is a desired side effect of ELN.
___
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: ELN Buildroot and Compose V4

[Miro Hrončok]

On 06. 04. 20 23:53, Stephen Gallagher wrote:

* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.


As a side note (probably out of scope of this proposal), I think that if we have 
RHEL packages in Fedora with not very responsive maintainers, the RHEL 
maintainer should really try to get themselves involved in those (or start being 
responsive in case the RHEL maintainers are the Fedora maintainers).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: ELN Buildroot and Compose V4

[Stephen Gallagher]

On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa  wrote:

> On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher 
> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > I've just published a fourth version[1] of the ELN proposal. With a
> > lot of input from Miro Hrončok, I think I've finally been able to
> > clarify some of the points that we were getting hung up on.
> >
> > Changes in this version of the proposal[2]:
> >
> > * Improve our explanation of why we are doing ELN in the first place
> > * Clarify the relationship with Rawhide
> > * Better describe what happens if packages don't build on ELN
> > * Explain our plan for when to use conditionals (this was getting a
> > larger share of the conversation than it warranted because we didn't
> > do a good job of explaining that they should be the exception and not
> > the rule)
> > * Clarify that the time limit on PRs is only for determining if the
> > maintainer is responsive. If they reply, the timer is cleared.
> > * Fixed the question about upstream features to make it clear that
> > what we meant is that new features should go upstream first, not be
> > implemented as a fork in ELN
> > * Added a section explaining how we will deal with side-tags
> > * Make it clear that we don't want to diverge wherever possible and
> > that any planned divergence should be discussed with the ELN SIG ahead
> > of time
> > * Cleaned up the contingency plan section.
> >
> > I hope that these changes will make our position more clear. Thank you
> > to everyone who has contributed to this discussion. I think the
> > feedback has been very valuable and I sincerely appreciate it.
> >
>
> This version of the proposal is nearly perfect, in my view.
>
> There are a couple of things I think should change:
>
> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
> * Likewise, I think the Koji tags should be versioned too.
>
> I've personally been burned enough times by not having versioned
> DistTags for personal rebuilds that I would strongly suggest you
> reconsider having unversioned ones.
>


Would you mind explaining some of the situations in which you were burned?
I’m not ruling this out, but I’d like a clear justification if we were to
change something.



> Finally, there is no adequate explanation for why ELN content can't go
> out to the mirrors like Rawhide content does. I'd vastly prefer that
> simply to have similar levels of availability as consumers of ELN
> content. I would prefer seeing it go to the mirror network like
> everything else.



It’s not so much that it *cannot* as that we are trying not to overload the
mirror network with content not useful to non-developers.



>
> Beyond that, this looks pretty good! Thanks for listening and
> incorporating everyone's feedback!
>

Thanks!


>
>
> --
> 真実はいつも一つ！/ 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
>
___
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: ELN Buildroot and Compose V4

[Miro Hrončok]

On 07. 04. 20 0:08, Neal Gompa wrote:

This version of the proposal is nearly perfect, in my view.

There are a couple of things I think should change:

* The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
.elnX (e.g. .eln9), or just plain .elX (e.g. .el9).


The good thing is that both:

  .eln.el9 > .eln
  .eln9 > .eln

So the two of the three mentioned schemes can be eventually enabled later 
without a sorting problem.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: ELN Buildroot and Compose V4

[Neal Gompa]

On Mon, Apr 6, 2020 at 5:56 PM Stephen Gallagher  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I've just published a fourth version[1] of the ELN proposal. With a
> lot of input from Miro Hrončok, I think I've finally been able to
> clarify some of the points that we were getting hung up on.
>
> Changes in this version of the proposal[2]:
>
> * Improve our explanation of why we are doing ELN in the first place
> * Clarify the relationship with Rawhide
> * Better describe what happens if packages don't build on ELN
> * Explain our plan for when to use conditionals (this was getting a
> larger share of the conversation than it warranted because we didn't
> do a good job of explaining that they should be the exception and not
> the rule)
> * Clarify that the time limit on PRs is only for determining if the
> maintainer is responsive. If they reply, the timer is cleared.
> * Fixed the question about upstream features to make it clear that
> what we meant is that new features should go upstream first, not be
> implemented as a fork in ELN
> * Added a section explaining how we will deal with side-tags
> * Make it clear that we don't want to diverge wherever possible and
> that any planned divergence should be discussed with the ELN SIG ahead
> of time
> * Cleaned up the contingency plan section.
>
> I hope that these changes will make our position more clear. Thank you
> to everyone who has contributed to this discussion. I think the
> feedback has been very valuable and I sincerely appreciate it.
>

This version of the proposal is nearly perfect, in my view.

There are a couple of things I think should change:

* The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
.elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
* Likewise, I think the Koji tags should be versioned too.

I've personally been burned enough times by not having versioned
DistTags for personal rebuilds that I would strongly suggest you
reconsider having unversioned ones.

Finally, there is no adequate explanation for why ELN content can't go
out to the mirrors like Rawhide content does. I'd vastly prefer that
simply to have similar levels of availability as consumers of ELN
content. I would prefer seeing it go to the mirror network like
everything else.

Beyond that, this looks pretty good! Thanks for listening and
incorporating everyone's feedback!



-- 
真実はいつも一つ！/ 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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

On Mon, 2020-04-06 at 16:28 -0400, Paul Dufresne via devel wrote:
> Le 20-04-06 à 15 h 34, Adam Jackson a écrit :
> > On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
> > > Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
> > > 2.1 used to be enabled on this hardware, but got dropped
> > I think we have a fix for that. Let me poke at things a bit.
> > 
> Euh... maybe that?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1762151#c20

Yeah, applying that makes X start, but then the screen is all black
instead of showing me anything. That seems to be true of the GLES2
glamor backend even for Xephyr on Skylake, so hopefully it shouldn't
take too much longer to figure out, and in the worst case we can
disable the GLES2 backend.

- ajax
___
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 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've just published a fourth version[1] of the ELN proposal. With a
lot of input from Miro Hrončok, I think I've finally been able to
clarify some of the points that we were getting hung up on.

Changes in this version of the proposal[2]:

* Improve our explanation of why we are doing ELN in the first place
* Clarify the relationship with Rawhide
* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)
* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.
* Fixed the question about upstream features to make it clear that
what we meant is that new features should go upstream first, not be
implemented as a fork in ELN
* Added a section explaining how we will deal with side-tags
* Make it clear that we don't want to diverge wherever possible and
that any planned divergence should be discussed with the ELN SIG ahead
of time
* Cleaned up the contingency plan section.

I hope that these changes will make our position more clear. Thank you
to everyone who has contributed to this discussion. I think the
feedback has been very valuable and I sincerely appreciate it.



[1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[2] 
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=570854=570256
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo
bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp
eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn
EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk
3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/
f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq
rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW
IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY
Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI
8ShPIeos
=+lwN
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've just published a fourth version[1] of the ELN proposal. With a
lot of input from Miro Hrončok, I think I've finally been able to
clarify some of the points that we were getting hung up on.

Changes in this version of the proposal[2]:

* Improve our explanation of why we are doing ELN in the first place
* Clarify the relationship with Rawhide
* Better describe what happens if packages don't build on ELN
* Explain our plan for when to use conditionals (this was getting a
larger share of the conversation than it warranted because we didn't
do a good job of explaining that they should be the exception and not
the rule)
* Clarify that the time limit on PRs is only for determining if the
maintainer is responsive. If they reply, the timer is cleared.
* Fixed the question about upstream features to make it clear that
what we meant is that new features should go upstream first, not be
implemented as a fork in ELN
* Added a section explaining how we will deal with side-tags
* Make it clear that we don't want to diverge wherever possible and
that any planned divergence should be discussed with the ELN SIG ahead
of time
* Cleaned up the contingency plan section.

I hope that these changes will make our position more clear. Thank you
to everyone who has contributed to this discussion. I think the
feedback has been very valuable and I sincerely appreciate it.



[1] https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[2] 
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=570854=570256
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6LpNgACgkQRduFpWgo
bRH4MAwAu1INM0mplL1yQiW2DMS148VubU5DkxRbaE3biZTvw5WzzbpxwpXr+nFp
eZf7IUyn5HCdtCAk1TQ4ga/TuV5VsaEEZ+a9p8PZfs4XTEMGpB7olP0Z8Jq1PWwn
EM6+4BAUWJ4JS7Q1+/CnEkUHA+1ZVeAzeb5bfSlcae2Vgx6evQMB4rEqAXdr16Qk
3Hi082+4SutmBv67cRA/JdRZmvUaHYtS4y5DrWAXOS23k8SHUCT/2O2f7NRPAoG/
f+04nG5JyUePY64pnVtDnsVMwETWiNSSs4V1dbKYe9Fj5H/jbvKIsvo8AWxw4BAq
rXCSIB3wMf08eM2KTaLvk0x+cz2BiSEZEDVdceffVXMwnUZulu/oeYDKdQg9OoHW
IQJbMoASgxRUXH1ZiMy8Q3SgQHvcu/YLmjS+djlVakLunhW7NfQjZB7txMyDi0PY
Hwn32C1kXnaoBJds4zB4QpWiJy5wI82CRL92Zvz0kiRPiO9TMCuj+t5kLZVmVTnI
8ShPIeos
=+lwN
-END PGP SIGNATURE-
___
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

Fedora 33 Self-Contained Change proposal: Network Time Security

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity

== Summary ==

Support for the Network Time Security (NTS) authentication mechanism
in the NTP client/server (chrony) and installer (anaconda).

== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]]
* Email: mlich...@redhat.com, mkol...@redhat.com

== Detailed Description ==

NTP is a widely used protocol for synchronization of clocks over
network. Authentication of NTP packets is important to prevent a
Man-in-the-middle (MITM) attacker from taking full control over the
client's clock (e.g. force it to jump to a distant future or past).
Several different authentication mechanisms have been specified for
NTP. The oldest and simplest one uses secret keys, where each client
has its own key which needs to be securely distributed to the server
and client. This means it is mostly limited to local networks. Autokey
is a newer mechanism based on public-key cryptography, but it was
shown to be insecure and it is rarely supported on public servers.

NTS is a new authentication mechanism
[https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp
specified by the IETF] for NTP. NTS has an NTS-KE protocol using
Transport Layer Security (TLS) to establish the keys and provide the
client with cookies which allow the NTP server to not keep any
client-specific state. NTP packets are authenticated using
Authenticated Encryption with Associated Data (AEAD). NTS is expected
to scale well to a  large numbers of clients. There are already some
public NTP servers with NTS support.

The default NTP client and server on Fedora is `chrony`. Support for
NTS is added in version 4.0. It uses the GnuTLS library for TLS and
the Nettle library for AEAD.

NTS authentication can be enabled on the client by adding the `nts`
option to the `server` or `pool` directive in ''/etc/chrony.conf''.
Until a standard port is assigned for NTS by IANA, the port may need
to be specified with the `ntsport` option. For example

`
server time.example.com iburst nts ntsport 12123
`

When using NTS-enabled NTP sources, any NTP source that is not trusted
and reachable over a trusted network should be disabled. This includes
servers provided by DHCP. They should be disabled by adding
`PEERNTP=no` to ''/etc/sysconfig/network''.

We can consider changing the default ''/etc/chrony.conf'' to use some
trusted public NTP servers with NTS support. There are public servers
provided by [https://www.cloudflare.com/time/ Cloudflare] and
[https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both
would be ok with Fedora using their servers by default (after some
testing and coordination). There is also a possibility that
pool.ntp.org will support NTS, although it is not very clear how
useful would NTS be in this case as the servers are owned by
individual contributors instead of a single trusted entity and
attackers can easily join the pool (some mitigations have been
proposed on the pool mailing list).

Potential issues with enabling NTS by default:
* Firewalls may block the NTS-KE port.
* ISPs may block or rate limit longer NTP packets as a mitigation for
amplification attacks using NTP mode 6 and 7. NTS-KE supports port
negotiation and an alternative port could be used to avoid this issue.
* Computers with no RTC (e.g. some ARM boards), or RTC that is too far
from the real time, will fail to verify TLS certificates. An option
could be added to disable the time checks before the first update of
the clock. This would have an impact on security.

== Benefit to Fedora ==

This change enables Fedora users to securely synchronize the system
clock to local or public NTP servers.

TBD: This change also makes the default configuration of the NTP client secure.

== Scope ==
* Proposal owners:

# Update `chrony` to 4.0 and enable the NTS support (adding dependency
on GnuTLS)
# TBD: Modify the default ''/etc/chrony.conf'' to use public servers
with NTS support
# Add an NTS option to the NTP settings in anaconda

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not needed for this Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Fedora systems updated from a previous version will use the new
''/etc/chrony.conf'' automatically if the installed file was not
modified. If it was modified, the users will need to update the file
manually or  rename ''/etc/chrony.conf.rpmnew'' to
''/etc/chrony.conf'' in order to enable NTS.

== How To Test ==

If the default configuration is modified for this Change, it needs to
be tested that it works correctly on most systems where the previous
default configuration using pool.ntp.org servers worked.

The installer needs to be tested that it enables NTS in
''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to
''/etc/sysconfig/network''.

The `chronyc -N sources` command can be used to 

Fedora 33 Self-Contained Change proposal: Network Time Security

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity

== Summary ==

Support for the Network Time Security (NTS) authentication mechanism
in the NTP client/server (chrony) and installer (anaconda).

== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]]
* Email: mlich...@redhat.com, mkol...@redhat.com

== Detailed Description ==

NTP is a widely used protocol for synchronization of clocks over
network. Authentication of NTP packets is important to prevent a
Man-in-the-middle (MITM) attacker from taking full control over the
client's clock (e.g. force it to jump to a distant future or past).
Several different authentication mechanisms have been specified for
NTP. The oldest and simplest one uses secret keys, where each client
has its own key which needs to be securely distributed to the server
and client. This means it is mostly limited to local networks. Autokey
is a newer mechanism based on public-key cryptography, but it was
shown to be insecure and it is rarely supported on public servers.

NTS is a new authentication mechanism
[https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp
specified by the IETF] for NTP. NTS has an NTS-KE protocol using
Transport Layer Security (TLS) to establish the keys and provide the
client with cookies which allow the NTP server to not keep any
client-specific state. NTP packets are authenticated using
Authenticated Encryption with Associated Data (AEAD). NTS is expected
to scale well to a  large numbers of clients. There are already some
public NTP servers with NTS support.

The default NTP client and server on Fedora is `chrony`. Support for
NTS is added in version 4.0. It uses the GnuTLS library for TLS and
the Nettle library for AEAD.

NTS authentication can be enabled on the client by adding the `nts`
option to the `server` or `pool` directive in ''/etc/chrony.conf''.
Until a standard port is assigned for NTS by IANA, the port may need
to be specified with the `ntsport` option. For example

`
server time.example.com iburst nts ntsport 12123
`

When using NTS-enabled NTP sources, any NTP source that is not trusted
and reachable over a trusted network should be disabled. This includes
servers provided by DHCP. They should be disabled by adding
`PEERNTP=no` to ''/etc/sysconfig/network''.

We can consider changing the default ''/etc/chrony.conf'' to use some
trusted public NTP servers with NTS support. There are public servers
provided by [https://www.cloudflare.com/time/ Cloudflare] and
[https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both
would be ok with Fedora using their servers by default (after some
testing and coordination). There is also a possibility that
pool.ntp.org will support NTS, although it is not very clear how
useful would NTS be in this case as the servers are owned by
individual contributors instead of a single trusted entity and
attackers can easily join the pool (some mitigations have been
proposed on the pool mailing list).

Potential issues with enabling NTS by default:
* Firewalls may block the NTS-KE port.
* ISPs may block or rate limit longer NTP packets as a mitigation for
amplification attacks using NTP mode 6 and 7. NTS-KE supports port
negotiation and an alternative port could be used to avoid this issue.
* Computers with no RTC (e.g. some ARM boards), or RTC that is too far
from the real time, will fail to verify TLS certificates. An option
could be added to disable the time checks before the first update of
the clock. This would have an impact on security.

== Benefit to Fedora ==

This change enables Fedora users to securely synchronize the system
clock to local or public NTP servers.

TBD: This change also makes the default configuration of the NTP client secure.

== Scope ==
* Proposal owners:

# Update `chrony` to 4.0 and enable the NTS support (adding dependency
on GnuTLS)
# TBD: Modify the default ''/etc/chrony.conf'' to use public servers
with NTS support
# Add an NTS option to the NTP settings in anaconda

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not needed for this Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

Fedora systems updated from a previous version will use the new
''/etc/chrony.conf'' automatically if the installed file was not
modified. If it was modified, the users will need to update the file
manually or  rename ''/etc/chrony.conf.rpmnew'' to
''/etc/chrony.conf'' in order to enable NTS.

== How To Test ==

If the default configuration is modified for this Change, it needs to
be tested that it works correctly on most systems where the previous
default configuration using pool.ntp.org servers worked.

The installer needs to be tested that it enables NTS in
''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to
''/etc/sysconfig/network''.

The `chronyc -N sources` command can be used to 

Re: Urgently downgrade xorg-x11-drv-intel

[Paul Dufresne via devel]

Le 20-04-06 à 15 h 34, Adam Jackson a écrit :

On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:


Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
2.1 used to be enabled on this hardware, but got dropped

I think we have a fix for that. Let me poke at things a bit.


Euh... maybe that?

https://bugzilla.redhat.com/show_bug.cgi?id=1762151#c20

___
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

Is there a way to mockbuild systemd?

[Göran Uddeborg]

I asked this in ask.fedoraproject
(https://ask.fedoraproject.org/t/is-there-a-way-to-mockbuild-systemd),
but FranciscoD suggested this might be a better place.

I'm trying to build a slightly modified version of systemd.  To start
with, I tried to do a fedpkg mockbuild of systemd without any
modification.  The build fails on the test-mountpoint-util test.

Is there a way around this? Is there a way to build systemd using mock?

The commands I run are these:

fedpkg clone systemd
cd systemd
fedpkg switch-branch f32
fedpkg mockbuild

The actual compilation succeeds, but the testing fails as mentioned.
If I keep the build root I found these lines in the error log.

ids of /proc/filesystems are 1256, 1281
the other path for mnt id 1281 is /proc
Assertion ‘path_equal(p, t)’ failed at src/test/test-mountpoint-util.c:94, 
function test_mnt_id(). Aborting.

According to this page
https://www.gitmemory.com/issue/systemd/systemd/11505/584844862 this
is because the build is done in a pid and mount namespace.  The site
is about Gentoo builds.
___
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 Introdction: nick black

[Nick Black]

Richard Shaw left as an exercise for the reader:
> Yes, there's a number of examples but audacity and sox are two. What we do
> at RPM Fusion is create a new package there that depends on the package in
> Fedora and either append -freeworld (just patent issues, like ffmpeg which
> are in the free repo), or append -nonfree for packages that depend on "free
> as in beer" instead of "free as in speech" libraries.
> 
> There are a few requirements though to make this work (and I'm not an
> expert here so correct me if I'm wrong!)
> 1. The library needs to be dlopen()'ed from the main package so it'll still
> function without the "extra" packages from RPM Fusion.
> 2. All the bits common to the main package need to be excluded from the RPM
> Fusion package since we can't (and don't want to) have redunded files in
> the package. This may look like "libnotcurses-ffmpeg.so. would be the only payload in the RPM Fusion -freeworld package.

This is exactly how I intend to structure my "notcurses-minimal"
for Debian, so it oughtn't be much extra work, excellent:

 https://github.com/dankamongmen/notcurses/issues/339

Alright, I'll look into this. BTW, while I've read the Packaging
Guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/,
there seem to be some operational details that I'm missing. For
instance, it seems I need file a bug once I have my source and
binary RPMs -- where can I find details on the necessary
information in that bug? Sorry if I've overlooked it :/.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
___
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: CPE Weekly: 2020-04-04

[Erinn Looney-Triggs]

With all of the other noise going on around this, I wanted to thank you 
folks for putting this out. Even this basic update shed light on a few 
things I had no idea about, communishift and rpmautospec. So thank you 
it is much appreciated that you are doing these.


-Erinn

On 4/4/20 1:02 PM, Aoife Moloney wrote:

# CPE Weekly 2020-04-04
---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-03-06

Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Check out our teams
info here https://docs.fedoraproject.org/en-US/cpe/


## GitForge Updates
Idea for note:
*There has been a lot of discussion this week on the devel and infra
lists about the decision to move to GitLab in the near future.
Firstly, let us apologize again to the communities for our drop in
communication between the requirement collecting phase and the
decision making phase. As we have said before, it was in no way, shape
or form an intentional lapse of communications. However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.
We do want to let you know that we deeply appreciate the requirements
you have given us and would like to ask you to continue engaging with
us while we are moving through our next steps with GitLab.
While the discussions on the lists are deeply emotional, they are
still incredibly valuable to us to truly comprehend the importance of
our next steps in ensuring we make the right choices in the coming
months.
Now more than ever, your guidance is needed to make sure we achieve
the best possible result for you and our team from this decision.
CPE management and I, our team's product owner, are also actively
engaging with the Fedora Council and soon the CentOS Board to make
sure that ALL of the developments and progress between us and GitLab
are publicly available.
We have a long way to go in this process and your feedback on our
progress will be vital to make sure we remain on course.
We hope in time you can understand our decision was made in good
intent for the betterment of both our team and the communities we
serve, and we hope to still be able to rely on you all as peers and
friends for feedback and guidance during this journey.*



## Fedora Updates
* Final Freeze starts 7th April 2020 @ 1400 UTC
* Pagure 5.9.1 release pushed to both staging and pagure.io
* the-new-hotness configuration was updated
https://pagure.io/fedora-infrastructure/issue/8783
* Michal Konečný has been working on mapping the fedora infrastructure
applications, his project, (which sounds really cool and useful!) can
be found here https://github.com/Zlopez/fedora-infra-map


### Data Centre Move
* Please note Communishift will be down from 13th April - 8th May to
facilitate the first shipment wave of our datacenter
* We are also still on track to switch to a reduced Fedora offering
from 25th May until est. 1st July\*.
* For a list of services we are planning to have available during this
window, please see mail thread in archive
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/PN6RL7XT3V7DVC7MK46H3QDEJPL5FRI6/
* We will not have staging available so we will not have capacity to
review or deploy new or upgraded features and applications during this
time.
* As always, please view our public schedule here for more a more
detailed overview
https://hackmd.io/@fedorainfra2020/rJpsA4FLL#First-draft-of-schedule-for-PHX2--gt-IAD2-move
* We found a password, we do not know whose it is, but we have turned
it into the lost and found.


### AAA Replacement
* First development phase complete & the team worked through 57 tickets in total
* The codebase was sent to our team first for demo and we will be
using feedback to develop the portal further
* During phase two we would like to change some codebases in existing
apps, and write documentation on how to upgrade applications to
redirect to the new API
* We would like to roll this request for feedback out to some
community maintainers during this phase too for another iteration on
the service and documentation
* Our work is publicly tracked here
https://github.com/orgs/fedora-infra/projects/6 so please stop by and
check out the progress we are making, and what we are looking at
working on next



### CI/CD

* Monitor-gating is still running in production and giving us some
data about the health of the packager workflow:
 * For example, these are the statistics between Monday and Wednesday:
39 messages retrieved
prod.monitor-gating.multi-build.end.failed  --  7
prod.monitor-gating.multi-build.end.succeeded  --  2
prod.monitor-gating.multi-build.start  --  10
prod.monitor-gating.single-build.end.failed  --  3
prod.monitor-gating.single-build.end.succeeded  --  7
prod.monitor-gating.single-build.start  --  10
* rpmautospec 0.0.1 

Re: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote:
> 
> 
> On Mon, Apr 6, 2020 at 12:57 PM Adam Jackson  wrote:
> > But the driver we default to on all the newer Intel chips should work
> > on yours too, though I'm not entirely sure whether you'll end up with
> > working 3D acceleration. And if you uninstall xorg-x11-drv-intel,
> > you'll fall back to the modesetting driver we use on the other Intel
> > chips, so, give it a shot?
> 
> Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
> 2.1 used to be enabled on this hardware, but got dropped

I think we have a fix for that. Let me poke at things a bit.

- ajax
___
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 Introdction: nick black

[Richard Shaw]

On Mon, Apr 6, 2020 at 8:03 AM Nick Black  wrote:

> Richard Shaw left as an exercise for the reader:
> > Up to you which way to go... I don't see packaging it in RPM Fusion as a
> > problem. I would think most people who would be interested in this
> package
> > would likely not have a problem enabling RPM Fusion.
>
> So, if you've seen the demo, that's not really at all the
> intended usage. The main goal is to facilitate really attractive
> versions of things like GTop, htop, s-tui, etc. I'd written some
> very substantial NCURSES programs, and found the process
> unpleasant and the results wanting. The primary goal was making
> things like
>
>  https://nick-black.com/dankwiki/index.php/Growlight and
>  https://nick-black.com/dankwiki/index.php/Omphalos
>
> look better and be easier to hack on. Neither, you'll note, uses
> fancy images or video :). So since this is primarily intended as
> a library fit for arbitrary systems applications, I'd probably
> want to aim for the "core" repo (assuming that core repo
> packages can only dep on projects in the core repo).
>
> Now, a "notcurses-noffmpeg" version in Core and a
> "notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
> thing ever done?
>

Yes, there's a number of examples but audacity and sox are two. What we do
at RPM Fusion is create a new package there that depends on the package in
Fedora and either append -freeworld (just patent issues, like ffmpeg which
are in the free repo), or append -nonfree for packages that depend on "free
as in beer" instead of "free as in speech" libraries.

There are a few requirements though to make this work (and I'm not an
expert here so correct me if I'm wrong!)
1. The library needs to be dlopen()'ed from the main package so it'll still
function without the "extra" packages from RPM Fusion.
2. All the bits common to the main package need to be excluded from the RPM
Fusion package since we can't (and don't want to) have redunded files in
the package. This may look like "libnotcurses-ffmpeg.so. decoding, which would be nice to retain.
>

Yup! Only the bits that NEED to go into the RPM Fusion -freeworld package
would be included.

Thanks,
Richard
___
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: CPE Git Forge Decision

[clime]

On Mon, 6 Apr 2020 at 17:52, Leigh Griffin  wrote:
>
>
>
> On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson  
> wrote:
>>
>> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
>> >
>> > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
>> > > CI? I.e. technical differences and advantages of each? If you did, can 
>> > > you,
>> > > please, publish it? It would be valuable info for the community and
>> > > something we can comment on.
>> > >
>> >
>> > Gitlab CI was not part of our evaluation, we are aware it's a service that
>> > is offered but did not evaluate it as it wasn't within the scope of our
>> > exercise.
>>
>> So, how does that track with this quote from the decision blog post?
>>
>> "Some top level requirements which helped us arrive at this decision
>> [to choose Gitlab]:
>>
>> There is a need for CentOS Stream to integrate with a kernel workflow
>> that is an automated bot driven merging solution (merge trains). This
>> allows for richer CI capabilities and minimises the need for human
>> interaction"
>>
>> If you did not evaluate Gitlab CI (and presumably CI capabilities of
>> the three systems more widely), how did the need for a CI feature -
>> that is what "merge trains" are - act as a "top level requirement"
>> which "helped us arrive at this decision"?
>
>
> I'm talking specifically about CI as a capability, in that specific 
> integrations at a CI level for hooks and other nice stuff which has several 
> known issues in Pagure at an API level, we evaluated that high level 
> requirement. Some stakeholders do not want to use the built in Gitlab CI as 
> we have CentOS CI used extensively and some have homebrewed systems that they 
> use. Hence why we did not go deep on CI at a very functional level outside of 
> known limitations and desires that came up as direct requirements.
>
> Merge trains and that capability is plugin / CI based and was explicit in 
> it's scope (it was called out as a need to have merge train functionality) Vs 
> CI in general as it was named as a need. We had discussed that Zuul was a 
> possibility around Pagure as part of that.

Discussed with whom, do you have logs? You didn't provide any material
from which the conclusions could be reproducibly drawn, you just came
and told us: "Hey, we decided this and this, you don't have any other
choice than to comply". It doesn't work like that or at least it
shouldn't, in my opinion.

It doesn't seem that you have considered CI future for Fedora _at
all_, i.e. work needed for pagure-based solution vs. work needed for
gitlab-based solution. Sorry but if you don't have a clear and
presentable vision of the different setups and how they compare to
each other with respect to initial setup, maintenance cost, and
feature set relevant for packager workflows, you shouldn't be making
decisions like those. Your "let's go to Gitlab" is shooting in the
dark at best.

clime

>
>
>>
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>> http://www.happyassassin.net
>> ___
>> 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
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> ___
> 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: Need help with getting packager permissions to bugzilla account

[Markku Korkeala]

Kevin Fenzi kirjoitti 6.4.2020 21:46:

On Mon, Apr 06, 2020 at 05:40:32PM +0300, Markku Korkeala wrote:

Hi,

I was sponsored to the packager group last year (FAS account 
korkeala),


that time I had an old bugzilla account which I used. Now that I tried

to do my first review, but it seems that I did not have privileges to 
assign


the review request to myself. I check that I did not have any bugzilla
permissions.

Then I changed my old bugzilla account email and Fedora account email 
so

I could

login using fresh email address and get a fresh account to the 
bugzilla,

hoping

that the permissions would be automatically transferred through SAML.
But still

no permissions.


Could someone help me get the correct packager permissions to the 
bugzilla?


Yep. You should be set now, I manually added the perms.

We have a script that is supposed to do this, but it's broken:

https://pagure.io/fedora-infrastructure/issue/8628



Works now, thank you!

--
Markku
___
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 Introdction: nick black

[stan via devel]

On Mon, 6 Apr 2020 09:03:54 -0400
Nick Black  wrote:

> Now, a "notcurses-noffmpeg" version in Core and a
> "notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
> thing ever done?

I think this is still true for audacity, mplayer, and chromium so they
get patented video codec support. Before mpeg was completely off patent,
there were other audio applications where this happened, with the
rpmfusion version adding support for mp3.
___
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

[Bug 1821367] perl-Dancer2-0.300001 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Dancer2-0.31-1.fc3
   ||3
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-04-06 19:04:18



--- Comment #3 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1490500


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Orphaning package procedure. (icewm, spring, springlobby)

[Kevin Fenzi]

On Mon, Apr 06, 2020 at 04:59:14PM +0300, Gilboa Davara wrote:
> Hello,
> 
> Due to the extreme time constraints that I'm forced to orphan most of my
> remaining packages.
> Namely icewm (which has an active co-maintainer), spring and springlobby.
> Following the procedure in wiki [1], I should use Pagure to orphan both
> packages.
> However, the list of projects in the Pagure is empty, and I can only view

What exact URL are you going to? 

it should be: 

https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings

where PACKAGE_NAME is one of the packages... 

> my list of active packages in
> https://src.fedoraproject.org/dashboard/projects
> 
> If possible, what is the correct procedure to orphan my packages and/or
> pass them to some willing co-maintainer?

Once we figure out what was unclear/wrong, sure! 

kevin


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: Need help with getting packager permissions to bugzilla account

[Kevin Fenzi]

On Mon, Apr 06, 2020 at 05:40:32PM +0300, Markku Korkeala wrote:
> Hi,
> 
> I was sponsored to the packager group last year (FAS account korkeala),
> 
> that time I had an old bugzilla account which I used. Now that I tried
> 
> to do my first review, but it seems that I did not have privileges to assign
> 
> the review request to myself. I check that I did not have any bugzilla
> permissions.
> 
> Then I changed my old bugzilla account email and Fedora account email so
> I could
> 
> login using fresh email address and get a fresh account to the bugzilla,
> hoping
> 
> that the permissions would be automatically transferred through SAML.
> But still
> 
> no permissions.
> 
> 
> Could someone help me get the correct packager permissions to the bugzilla?

Yep. You should be set now, I manually added the perms. 

We have a script that is supposed to do this, but it's broken: 

https://pagure.io/fedora-infrastructure/issue/8628

kevin


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: Self Introdction: nick black

[David Cantrell]

On Mon, Apr 06, 2020 at 09:03:54AM -0400, Nick Black wrote:

Richard Shaw left as an exercise for the reader:

Up to you which way to go... I don't see packaging it in RPM Fusion as a
problem. I would think most people who would be interested in this package
would likely not have a problem enabling RPM Fusion.


So, if you've seen the demo, that's not really at all the
intended usage. The main goal is to facilitate really attractive
versions of things like GTop, htop, s-tui, etc. I'd written some
very substantial NCURSES programs, and found the process
unpleasant and the results wanting. The primary goal was making
things like

https://nick-black.com/dankwiki/index.php/Growlight and
https://nick-black.com/dankwiki/index.php/Omphalos

look better and be easier to hack on. Neither, you'll note, uses
fancy images or video :). So since this is primarily intended as
a library fit for arbitrary systems applications, I'd probably
want to aim for the "core" repo (assuming that core repo
packages can only dep on projects in the core repo).

Now, a "notcurses-noffmpeg" version in Core and a
"notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
thing ever done?


That's kind of clunky, IMHO.  Splitting out the ffmpeg support as a
loadable runtime module like you see with gstreamer and gdk-pixbuf would
be easier to package and split between repos.  That might necessitate
splitting out the ffmpeg functionality as a separate source repo.  Or at least
release notcurses and notcurses-ffmpeg separately.


It's well maintained and the author is very helpful and responds to
questions quickly via the mailing list. It in combination with OpenColorIO
(which I also maintain) have been used in production of several animated
movies so you know it's very robust.


I remember being impressed by OpenImageIO when I last looked at
it (2013 or so). I'll take a look into it, thanks!


Unlike Debian, Fedora is hosted in the US so RPM Fusion exists to package
programs with patent/licensing issues (rpmfusion-free) including binary
blobs like the NVidia drivers (rpmfusion-nonfree).
Only fully FOSS without patent or licences issues can be packaged in Fedora.


Got it, so very similar to the "main" vs "non-free" split in
Debian, except it looks like FFmpeg ended up on the wrong side
of the divide in Fedora :).

It looks like GStreamer is in Core, and that would give me video
decoding, which would be nice to retain.

--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
___
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


--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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 Introdction: nick black

[David Cantrell]

On Mon, Apr 06, 2020 at 08:20:47AM -0400, Nick Black wrote:

(i don't see any of these posts thus far in 2020, so perhaps
they've fallen out of vogue? i'm merely blindly complying with
the instructions at [0]).

hello there in RPM land! i'm a longtime linux user/developer.
my first Linux install was RedHat 5.1 in the summer of 1998,
and i've been Free ever since. i primarily run Debian and Arch
these days, but do some RHEL work professionally, and am very
interested in ensuring my software runs on rawhide and friends.

my immediate motivation for joining the Fedora community is
packaging up a recent library of mine, "notcurses", best
summarized as a baby of ncurses and ffmpeg [1]. there's a demo
here [2] that you might find entertaining. i've written a book
which is available for purchase [3] or free download [4]. i've
spoken with Mssr. David Cantrell, a fellow Yellow Jacket, and
believe in him to have secured a sponsor.


Greetings and welcome!


i'd then like to look into getting my disk-management tool
"growlight" and perhaps my network security recon tool
"omphalos" into rawhide. more than that, i hope to become more
expert with this family of Linuxes.

hack on! --nick

[0] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[1] https://nick-black.com/dankwiki/index.php/Notcurses
[2] https://www.youtube.com/watch?v=-H1WkopWJNM=youtu.be
[3] https://www.amazon.com/dp/B086PNVNC9
[4] https://nick-black.com/htp-notcurses.pdf

--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
___
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


--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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-IoT-32-20200406.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

Old failures (same test failed in Fedora-IoT-32-20200405.0):

ID: 568509  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/568509

Passed openQA tests: 7/8 (x86_64)

New passes (same test not passed in Fedora-IoT-32-20200405.0):

ID: 568505  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/568505

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.24 to 0.09
Previous test data: https://openqa.fedoraproject.org/tests/567429#downloads
Current test data: https://openqa.fedoraproject.org/tests/568504#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Urgently downgrade xorg-x11-drv-intel

[Sérgio Basto]

On Mon, 2020-04-06 at 12:13 -0400, Alexei Podtelezhnikov wrote:
> > "a011" is precisely the last entry found in 
> > https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
> > which explains why Xorg picks "intel" as seen in the Xorg logs:
> > 
> > [  7821.917] (==) Matched intel as autoconfigured driver 0
> > [  7821.917] (==) Matched modesetting as autoconfigured driver 1
> > [  7821.917] (==) Matched fbdev as autoconfigured driver 2
> > [  7821.917] (==) Matched vesa as autoconfigured driver 3
> > 
> >  
> > >   Additionally, Xorg is also non-default, we use Wayland since
> > > some
> > > 
> > >   time.
> > 
> > That's correct, on the Fedora Workstation using GNOME - But Wayland
> > is a protocol, just like X11, it requires a display server which is
> > gnome-shell, and Alexei mentioned in the bug he's using another
> > spin instead, so no Wayland there.
> > 
> > So indeed, that bug would unlikely affect the default Fedora
> > Workstation.
> > 
> 
> You don't seem to mind shipping Fedora 32 with a broken git snapshot
> of the intel drivel. What are realistic chances to get it fixed
> eventually given apparent lack of testing? Therefore, I asked to
> downgrade it.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AUPYPJMFJZMHPEKN24LBABZKIEOV4NU5/
so I guess Intel drive is not the default drive ... 
I built and tested xorg-x11-drv-intel-2.99.917-43.20190621.fc31.src.rpm 
[1] for a long time without problems , you may try it ... . Now I
bought a new laptop so I can't test it anymore. 
HTH
[1] 
https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/build/942875/

> I can test modesetting on Gen3 GMA 3150 if that is easy. I dusted off
> this netbook for my kids' distant learning during COVID19. I would
> not be surprised if more old junk surfaces on your bugzilla soon.
> 
> 
> ___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
-- 
Sérgio M. B.

___
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

[Bug 1820788] perl-Rose-DB-Object-0.817 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-9645680d5e has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9645680d5e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[James Cassell]

On Mon, Apr 6, 2020, at 1:48 PM, Stephen John Smoogen wrote:
> 
> 
> On Mon, 6 Apr 2020 at 13:34, Robbie Harwood  wrote:
> > Aoife Moloney  writes:
> > 
> >  > * We found a password, we do not know whose it is, but we have turned
> >  > it into the lost and found.
> > 
> >  I'm sorry, what? Can you explain what this is and what it means?
> > 
> 
> This was something I slipped in to see if anyone was going to read any 
> part of things on the move or if everyone else was going to fixate on 
> the other parts. Thank you for reading past the first set of 
> paragraphs. 
> 

I'd assumed it was a joke. Or that maybe you found a file called "password" 
somewhere.

V/r,
James Cassell
___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Till Maas" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, April 6, 2020 1:39:49 PM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
> > - Original Message -
> > > From: "Miro Hrončok" 
> > > To: devel@lists.fedoraproject.org
> > > Sent: Monday, April 6, 2020 8:28:15 AM
> > > Subject: Re: CPE Weekly: 2020-04-04
> > > 
> > > On 06. 04. 20 14:19, Alex Scheel wrote:
> > > > That part isn't actually clear to me. There's certainly a vocal portion
> > > > against using GitLab
> > > 
> > > I think it's hard to see who's vocal against GitLab and who just wants a
> > > truly
> > > open decision process for this.
> > > 
> > > I've heard people who would love to get GitLab, but who are genuinely sad
> > > about how CPE management handled this.
> > 
> > Sure, can we have two positions in this voting system?
> > 
> >  1. I want GitLab,
> >  2. I want Pagure,
> >  3. I want something not listed here,
> >  4. I don't particularly care.
> 
> What do you want to do with this information? 

I'm not in CPE.

I'm curious what the _community's_ position is. There's a small portion of
people responding to this thread. We can make assumptions about what the
Fedora community thinks (and certainly we know what individuals of it think),
but until we have data, do we really know what the majority opinion is?

I value data over a few loud voices. :)

> Also I do not think it is
> a good idea to micro-manager CPE into a specific solution. IMHO it is
> more important to get the dist-git features that Fedora requested and
> probably also issue trackers for Fedora groups (for example Council,
> FESCo, ...) currently implemented in
> pagure.io), GIT repos with a git forge for Fedora (for example for docs,
> infra, releng). And it would be great to also ensure that Fedora
> contributors/Fedora Infra/CPE can contribute to these solutions to
> ensure that Fedora specific requirements can be met.

As I said elsewhere, I don't want to use this for a decision. I just
want to see what more than the ~60 people responding here and in the
other thread actually think about this issue.

I do agree, if this were a vote, it would boxes CPE in. But before the
Fedora community can engage with CPE, shouldn't the leadership (and those
of us arguing on the thread) understand what the rest of the Fedora
community thinks, such that we all can represent something cohesively to
CPE?

IMO, that was the step lacking from this process on the Fedora side.

> If it is easier to customize Gitlab to meet Fedora's dist-git
> requirements than to customize pagure, then it would be good for CPE
> to do this even if more people would like to prefer pagure. If it is the
> other way, then it could still make sense to use Gitlab for tasks used
> by pagure.io to benefit from better Gitforge features, there, but keep
> pagure for dist-git.
>
> Also, I do not have any idea how easy it is to get changes into Gitlab,
> so this is also something that needs to be taken into consideration.
> I find it somewhat troublesome that these questions are not answered,
> especially since the migration from pkgdb to pagure was very painful and
> is not yet completed.

Thanks for your opinion, your response has been recorded in this informal
poll. :)
 
> Kind regards
> Till
> ___
> 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

[Bug 1820787] perl-Rose-DB-0.783 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-a90b4a9d04 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a90b4a9d04


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Stephen John Smoogen]

On Mon, 6 Apr 2020 at 13:34, Robbie Harwood  wrote:

> Aoife Moloney  writes:
>
> > * We found a password, we do not know whose it is, but we have turned
> > it into the lost and found.
>
> I'm sorry, what?  Can you explain what this is and what it means?
>
>
This was something I slipped in to see if anyone was going to read any part
of things on the move or if everyone else was going to fixate on the other
parts. Thank you for reading past the first set of paragraphs.


-- 
Stephen J Smoogen.
___
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: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

On Mon, Apr 6, 2020 at 12:57 PM Adam Jackson  wrote:

>
> But the driver we default to on all the newer Intel chips should work
> on yours too, though I'm not entirely sure whether you'll end up with
> working 3D acceleration. And if you uninstall xorg-x11-drv-intel,
> you'll fall back to the modesetting driver we use on the other Intel
> chips, so, give it a shot?
>

Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL 2.1 used
to be enabled on this hardware, but got dropped

https://wiki.archlinux.org/index.php/intel_graphics#OpenGL_2.1_with_i915_driver

[   191.334] Require OpenGL version 2.1 or later.
[   191.334] (EE) modeset(0): Failed to initialize glamor at ScreenInit()
time.
[   191.334] (EE) Fatal server error:
[   191.334] (EE) AddScreen/ScreenInit failed for driver 0
[   191.335] (EE)
[   191.335] (EE) Please consult the Fedora Project support at
http://wiki.x.org  for help.
[   191.335] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   191.335] (EE)
[   191.355] (EE) Server terminated with error (1). Closing log file.
___
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: F32 ELF file analysis

[Steve Grubb]

On Monday, April 6, 2020 1:22:15 PM EDT Vít Ondruch wrote:
> Should I be able to see analysis for e.g. Ruby? I am asking, because I
> can't, so not sure if I am doing anything wrong.

Its likely not part of @Core package group. The analysis was run on a small 
subset of Fedora 32 to see what a minimal install would look like. This can 
certainly be run on a larger set of packages, but it would take some 
retooling to get them all. I am in the process of cleaning this up to put on 
github so that anyone can do this and see how things look on their system.

-Steve


> Dne 06. 04. 20 v 18:03 Steve Grubb napsal(a):
> > Just wanted to share with everyone the results of a data collection on 
> > various metrics of ELF files when installing just @Core group.
> >
> >
> >
> > http://people.redhat.com/sgrubb/analysis/f32-analysis.slides.html#/
> >
> >
> >
> > I recommend clicking on the "pop out" link and then you have more room to
> > see 
 the results. To use it grab SOURCERPM and dragh it just below
> > "count", then drag FILE under SOURCERPM, then grab STACK_PROT and drag
> > it to the right of count. Next click on the drop down and uncheck "ok".
> > Click apply. Now you have the listing of all files without the right
> > stack protector hardening.>
> >
> >
> > Go back into the STACK_PROT, check ok, click apply. Drag STACK_PROT back
> > to 
 where it came from, grab USES_SECCOMP, drag it to the right of
> > "count", click drop down, uncheck "no", click apply, now you have the
> > list of programs using seccomp for confinement.
> >
> >
> >
> > Have fun playing with the data. Just remember when you subset the data,
> > it 
 stays that way until you check all boxes. In case your curious,
> > this is exported from a Jupyter Notebook.
> >
> >
> >
> > -Steve
> >
> >
> >
> > ___
> > 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/de...@lists.fedoraproject.or
> g



___
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: CPE Weekly: 2020-04-04

[Till Maas]

On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
> - Original Message -
> > From: "Miro Hrončok" 
> > To: devel@lists.fedoraproject.org
> > Sent: Monday, April 6, 2020 8:28:15 AM
> > Subject: Re: CPE Weekly: 2020-04-04
> > 
> > On 06. 04. 20 14:19, Alex Scheel wrote:
> > > That part isn't actually clear to me. There's certainly a vocal portion
> > > against using GitLab
> > 
> > I think it's hard to see who's vocal against GitLab and who just wants a
> > truly
> > open decision process for this.
> > 
> > I've heard people who would love to get GitLab, but who are genuinely sad
> > about how CPE management handled this.
> 
> Sure, can we have two positions in this voting system?
> 
>  1. I want GitLab,
>  2. I want Pagure,
>  3. I want something not listed here,
>  4. I don't particularly care.

What do you want to do with this information? Also I do not think it is
a good idea to micro-manager CPE into a specific solution. IMHO it is
more important to get the dist-git features that Fedora requested and
probably also issue trackers for Fedora groups (for example Council,
FESCo, ...) currently implemented in
pagure.io), GIT repos with a git forge for Fedora (for example for docs,
infra, releng). And it would be great to also ensure that Fedora
contributors/Fedora Infra/CPE can contribute to these solutions to
ensure that Fedora specific requirements can be met.

If it is easier to customize Gitlab to meet Fedora's dist-git
requirements than to customize pagure, then it would be good for CPE
to do this even if more people would like to prefer pagure. If it is the
other way, then it could still make sense to use Gitlab for tasks used
by pagure.io to benefit from better Gitforge features, there, but keep
pagure for dist-git.

Also, I do not have any idea how easy it is to get changes into Gitlab,
so this is also something that needs to be taken into consideration.
I find it somewhat troublesome that these questions are not answered,
especially since the migration from pkgdb to pagure was very painful and
is not yet completed.

Kind regards
Till
___
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: CPE Weekly: 2020-04-04

[Robbie Harwood]

Aoife Moloney  writes:

> * We found a password, we do not know whose it is, but we have turned
> it into the lost and found.

I'm sorry, what?  Can you explain what this is and what it means?

Thanks,
--Robbie


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: CPE Git Forge Decision

[Sheogorath via devel]

On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > Some failure of process or communication must have occurred
> > somewhere along the lines, because open source should have been the
> > first and most important requirement. A proprietary software
> > solution is incompatible with the ethos and purpose of the Fedora
> > project. I ask CPE to revise its requirements list to include open
> > source as the first and most important requirement from the Fedora
> > community. If that's incompatible with CentOS's need for merge
> > request approvals or whatever else, then we need to accept that
> > sharing the same forge is simply not going to work.
> 
> Obviously open source is one of our key foundations. And it is part
> of who
> we are even before those foundations were drafted. Nonetheless, I
> want to
> gently discuss this a little bit. We make an entirely open source and
> free
> software operating system. We support and promote and advocate for
> open
> source and free content. But we can't do everything, and at some
> point, this
> becomes "this is why we can't have nice things". I see that you've
> made
> contributions to other open source projects on GitHub and (hosted)
> GitLab
> this month. Lots of Fedora contributors have and will continue to do
> so.
> Many use that as their main hosting. It's not ideal, but it's not the
> end of
> the world. I don't see Fedora making use of non-open hosted services
> as the
> end of the world either, if that is what is best for us.
> 
> We did communicate as the very top line of our gathered requirements
> that
> open source is essential to our community and central to our
> feedback. I'm
> not trying to be soft on that. Let's just not do purity-test level
> assessments and instead focus on our goals.
> 

I actually have just one question about this decision, because so far,
and I read a lot, but not all mails regarding this, haven't answered
that:

Let's say the scenario is that we run GitLab EE for Fedora. Can we
make sure that at least all customization and modifications that are
done by Fedora contributors or in the name of Fedora executed by the
Gitlab team, will end up in GitLab-foss i.e. open source?

And what really makes me wonder in the whole process: According to
various mails from the CPE the deal that will come out, like features,
price, … is not yet figured out. Not even the plan what GitLab version
CPE is about to go for. But the decision to go for GitLab is already
made? How does that work and isn't that basically torpedoing every
price negotiation?

Hope we can figure those questions out.

-- 
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt


signature.asc
Description: This is a digitally signed message part
___
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

libxc version 5 coming up: soname bump

[Susi Lehtola]

Hi,


libxc 5.0.0 has been released. Due to the addition of several new features, it
comes with an soname bump. Also, the Fortran libraries have changed from the
earlier release: now, the old F03 wrapper employing iso_c_binding is now shipped
as the F90 wrapper, as the old F90 wrapper based on a custom C-Fortran interface
has been obsoleted.

I'll push the package to rawhide in a week from now, i.e. on Mon Apr 13. If you
need help porting your package to the new version of libxc, you can ask me for
help. (I am also one of the main upstream developers.)
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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: F32 ELF file analysis

[Vít Ondruch]

Should I be able to see analysis for e.g. Ruby? I am asking, because I
can't, so not sure if I am doing anything wrong.


Vít


Dne 06. 04. 20 v 18:03 Steve Grubb napsal(a):
> Hello,
>
> Just wanted to share with everyone the results of a data collection on 
> various metrics of ELF files when installing just @Core group.
>
> http://people.redhat.com/sgrubb/analysis/f32-analysis.slides.html#/
>
> I recommend clicking on the "pop out" link and then you have more room to see 
> the results. To use it grab SOURCERPM and dragh it just below "count", then 
> drag FILE under SOURCERPM, then grab STACK_PROT and drag it to the right of 
> count. Next click on the drop down and uncheck "ok". Click apply. Now you 
> have the listing of all files without the right stack protector hardening.
>
> Go back into the STACK_PROT, check ok, click apply. Drag STACK_PROT back to 
> where it came from, grab USES_SECCOMP, drag it to the right of "count", click 
> drop down, uncheck "no", click apply, now you have the list of programs using 
> seccomp for confinement.
>
> Have fun playing with the data. Just remember when you subset the data, it 
> stays that way until you check all boxes. In case your curious, this is 
> exported from a Jupyter Notebook.
>
> -Steve
>
> ___
> 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

[Bug 1821367] perl-Dancer2-0.300001 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Dancer2-0.31-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=43064526


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[R P Herrold]

On Mon, 6 Apr 2020, Leigh Griffin wrote:

> We cannot take the view of a singular person and make changes based on
> that, we defer to them for prioritisation and their input. That's how the

But, having reviewed the 'wishlist' of criteria quoted last 
week, [in the thread with Ben Cotton's message last Friday -- 
I believe the URL to the list directly was posted in the 
thread: CPE Git Forge Decision, but cannot lay my hands on it 
presently], it very obviously had not been winnowed down or 
curated down into any sort of rank order priority, or even 
something as simple as an Agile set of cards, sorted into 
stacks:

- Must be present, showstopper if absent
- Expected, but not critical if absent
- Nice to have, but 'neh'

... so that task decomposition could proceed.  If it had been 
openly done, with actual stakeholders at the table, the 'Must 
be free sources' criteria would have been in that top pile, 
and remained there.  Without that 'polestar', other criteria 
were treated as critical

As an outsider (from CentOS 1 era), who votes in each Fedora 
election, it looks as a non-transparent result is being 
'justified' ex post

If there are unacceptible non-Free parts at Gitlab to the 
Fedora vision of attainable via no non-freely licensed 
package, I'd be studying how to relieve the non-free 
constraints in Gitlab, rather than 'fighting City Hall'

Just my thoughts,

-- Russ herrold
___
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

[Bug 1821367] New: perl-Dancer2-0.300001 is available

[bugzilla]

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

Bug ID: 1821367
   Summary: perl-Dancer2-0.31 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dancer2
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.31
Current version/release in rawhide: 0.30-3.fc33
URL: http://search.cpan.org/dist/Dancer2

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/5847/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1821367] perl-Dancer2-0.300001 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1676658
  --> https://bugzilla.redhat.com/attachment.cgi?id=1676658=edit
[patch] Update to 0.31 (#1821367)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[David Kaufmann]

On Mon, Apr 06, 2020 at 04:02:34PM +0100, Leigh Griffin wrote:
> Ok let's scenario this out so as several people want us to restart […]

In this context of "restarting the scenario":

> How do we accommodate that when our other stakeholders' needs are now
> not being met as a whole and when the original requirements needs are
> being satisfied by the choice of Gitlab (which will most likely be CE
> for Fedora).

This is to be taken with a grain of salt. There are quite a few people
in this thread mentioning that it conflicts with the Fedora mission
statement - which I'd see as being part of the original requirements
implicitely. This might be less problematic with GitLab CE, which I
assume seems to be the current plan.

> What happens then, how do you suggest we proceed at that point? The
> other stakeholder groups are already progressing with Gitlab and we
> can do that for them and pause the Fedora move in this direction if
> that was the scenario. What happens after months of debate if we
> cannot bridge that divide?

That is very easy. If it is not *possible* to have a common solution, it
is necessary to have separate solutions. Everything else would be
forcing a stakeholder to a solution not meeting their requirements.

And yes, if one stakeholder (eg. Fedora) just insists on Pagure, and
another stakeholder (maybe that internal RedHat group?) just insists on
GitLab, you can either force the decision, or have both.

> What happens when Pagure is sunset as the CPE team cannot run it /
> maintain it? I'm genuinely curious here as if this is a path the
> community want to go down then engage with Council on it but I think it
> could be harmful for the project as a whole.

If Fedora continues to use Pagure, and the RedHat internal group uses
GitLab, and CPE sunsets Pagure, this means, another team needs to take
over.
(Which is not a GDPR problem as long as there is no data in there which
is not allowed to be there anyway. Even then access can be provided, if
necessary)

After that the CPE does not have fedora-dist-management on their plate
anymore and can focus on different things.

Budget: Depending on what percentage of CPE teams duties are seen as
fedora-specific-dist-management that might also mean some reduction in
size of the CPE team in favor of the new fedora-dist-management-team.
(Can also be seen as some people switching from CPE to the new team)

Later it might be possible for migrating the RedHat internal group on
Pagure, or Fedora on GitLab, but that needs to come from inside the
community/team, and not be forced on a community/team.

> That's not my choice though and until otherwise told, we are
> progressing in this direction.

With this you're actively choosing to continue acting following *your*
decision.

As mentioned in another post, it might be best to pause the whole thing
for some time, an then try another path on how to proceed forward.
(There is no reset, what has been done can't be just "reversed")

And yes, this means not pushing for a solution in the "pause time", and
yes, this also means no dicussions with GitLab, and no trying to make
Pagure more GitLab like, no waiting until the dust settles to just
continue with the GitLab path, and no forcing the "pause time" to be so
long, that Pagure is chosen due to process stalling.

That means first focussing on how to resolve the situation, before
taking another step. It's obvious that there is a big problem right now,
and it needs to be addressed first.

If it is important to you that some formal body pauses the process and
not yourself, please either name that entity or preferably request a
statement about pausing or continuing the planned process yourself.
From other emails it seems this formal body is the Council, but I'd like
to have a confirmation for that assumption.

All the best,
David


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: v4l2loopback kernel module in Fedora?

[stan via devel]

On Sun, 5 Apr 2020 21:44:16 -0400
Christopher  wrote:

> I'm probably going to abandon the effort anyway. obs-studio in Fedora
> crashes constantly every time I try to change the settings and save,
> so I couldn't figure out how to get it to work with v4l2loopback. I

You are using obs in a different way than I am, but it works without
issue here for my unsophisticated use.  I've never had a crash.  F31.  I
am able to change settings, I changed the keymappings to use the left
windows key, finally getting some use out of it.  I am using X, and I
start obs from a terminal so if anything *does* go wrong, I see the
output from the program.  I've been really pleased with its
performance, though I'm sure I'm not really stressing it out the way
you want to.
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

On Mon, 2020-04-06 at 09:27 -0400, Alexei Podtelezhnikov wrote:
> Hi All,
> 
> Please urgently downgrade xorg-x11-drv-intel before shipping Fedora 32 and 
> spare users some pain. At least two very recent crash/segfault reports are 
> fixed by downgrading to the fc31 version of xorg-x11-drv-intel.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1820815
> https://bugzilla.redhat.com/show_bug.cgi?id=1818972

What happens if you uninstall xorg-x11-drv-intel?

The background here is that the intel driver hasn't had a release in
(checks) wow, over five years, which means its quality at any given
point is sort of unknown. You'd hope it would be converging on a good
state, and it does seem to have an ever-slowing change rate, but you
still end up with patches getting reverted after a month:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/d90a2ff1a6f338fa70fc9a110d9f7b0e622c8a57

And this mostly doesn't matter because we default to a different driver
for most Intel hardware released since about 2006, with the notable
exception of your (Alexei's) machine which was new as of about 2010.

But the driver we default to on all the newer Intel chips should work
on yours too, though I'm not entirely sure whether you'll end up with
working 3D acceleration. And if you uninstall xorg-x11-drv-intel,
you'll fall back to the modesetting driver we use on the other Intel
chips, so, give it a shot?

- ajax
___
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: PSA: please do not BuildRequires: qt5-devel

[Rex Dieter]

Iñaki Ucar wrote:

> On Mon, 6 Apr 2020 at 18:08, Rex Dieter  wrote:
>>
>> The qt5, qt5-devel metapackages were introduced a few releases ago as
>> merely a convenience for end-users, not intended to be used in official
>> fedora packages, but seems these have seen some non-trivial adoption
>> anyway.
>>
>> Personally, I objected to metapackage introduction at the fearing this
>> would
>> happen, and it has.  Appended is a current list of offenders.
> 
> So, is it fine if I just remove this line?
> 
> https://src.fedoraproject.org/rpms/rstudio/blob/master/f/rstudio.spec#_59

Probably, rstudio already has build dependencies on a bunch of other Qt5 
stuff.

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

[rpms/perl-String-CRC32] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1

[Paul Howarth]

pghmcfc closed without merging a pull-request against the project: 
`perl-String-CRC32` that you
are following.

Closed pull-request:

``
Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1
``

https://src.fedoraproject.org/rpms/perl-String-CRC32/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[rpms/perl-String-CRC32] PR #1: Spec file cleanups: Use make_build and make_install macros, use NO_PACKLIST=1

[Paul Howarth]

pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and 
make_install macros, use NO_PACKLIST=1` that you are following:
``
I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference. 
It's now pushed and built in Fedora.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-String-CRC32/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: PSA: please do not BuildRequires: qt5-devel

[Iñaki Ucar]

On Mon, 6 Apr 2020 at 18:08, Rex Dieter  wrote:
>
> The qt5, qt5-devel metapackages were introduced a few releases ago as merely
> a convenience for end-users, not intended to be used in official fedora
> packages, but seems these have seen some non-trivial adoption anyway.
>
> Personally, I objected to metapackage introduction at the fearing this would
> happen, and it has.  Appended is a current list of offenders.

So, is it fine if I just remove this line?

https://src.fedoraproject.org/rpms/rstudio/blob/master/f/rstudio.spec#_59

-- 
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: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

[James Cassell]

On Mon, Apr 6, 2020, at 12:05 PM, Petr Pisar wrote:
> On Mon, Apr 06, 2020 at 03:02:02PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Mar 31, 2020 at 12:13:16PM +0200, Daniel Mach wrote:
[snip]
> > > Setting eol_date to the future allows informing a user about
> > > upcoming obsoleting event so they can eventually migrate manually.
> > 
> > For some context (RHEL...) time-based obsoletes make plenty of sense.
> > But in Fedora we established a policy that obsoletion and other
> > significant stream changes happen at "release boundary", which for
> > each user is whenever they choose to upgrade, so not time-based.
> >
> That's a great motivation, but this is not how it works in the real world.
> 
> A packager asks for a branch and sets an end-of-life date. The date is
> enforced to align with a Fedora cadence. I.e. 4th and 10th month of a year. 
> The
> packager builds a module from that branch for _all_ Fedoras and pushes the
> builds to the stable repositories. Once the end-of-life day comes, the
> packager stops maintaining the stream. That day there is exactly one Fedora
> release that also reached the end of life. But all the newer Fedora releases
> are still supported, but the stream there is not. You have an unsupported
> stream in a supported Fedora release.
> 
> That's the outcome of decoupling a stream life cycle from a Fedora life cycle.
> 

My understanding of current policy is that it would not be permitted to have 
such a module in current fedora. It could only be included in a version of 
fedora where it will receive updates for the entire life cycle of that Fedora 
version.

V/r,
James Cassell
___
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 rawhide compose report: 20200406.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200405.n.0
NEW: Fedora-Rawhide-20200406.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  3
Dropped packages:0
Upgraded packages:   57
Downgraded packages: 0

Size of added packages:  6.00 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.14 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   13.48 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.raw.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.vmdk
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200405.n.0.ppc64le.qcow2

= ADDED PACKAGES =
Package: adobe-afdko-3.2.0-1.fc33
Summary: Adobe Font Development Kit for OpenType
RPMs:adobe-afdko
Size:4.59 MiB

Package: cxxopts-2.2.0-1.fc33
Summary: Lightweight C++ command line option parser
RPMs:cxxopts-devel
Size:122.37 KiB

Package: nuspell-3.0.0-5.fc33
Summary: Free and open source C++ spell checking library
RPMs:nuspell nuspell-devel
Size:1.29 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  bijiben-3.36.1-1.fc33
Old package:  bijiben-3.36.0-1.fc33
Summary:  Simple Note Viewer
RPMs: bijiben
Size: 2.10 MiB
Size change:  1.09 KiB
Changelog:
  * Sun Apr 05 2020 Kalev Lember  - 3.36.1-1
  - Update to 3.36.1


Package:  btrfs-progs-5.6-1.fc33
Old package:  btrfs-progs-5.4-2.fc32
Summary:  Userspace programs for btrfs
RPMs: btrfs-progs btrfs-progs-devel libbtrfs libbtrfsutil
Size: 7.02 MiB
Size change:  7.27 KiB
Changelog:
  * Sun Apr 05 2020 Neal Gompa  - 5.6-1
  - New upstream release


Package:  bucardo-5.6.0-1.fc33
Old package:  bucardo-5.4.1-14.fc32
Summary:  Postgres replication system for both multi-master and multi-slave 
operations
RPMs: bucardo
Size: 213.47 KiB
Size change:  4.09 KiB
Changelog:
  * Sun Apr 05 2020 Itamar Reis Peixoto  - 5.6.0-1
  - 5.6.0


Package:  calibre-4.13.0-1.fc33
Old package:  calibre-4.12.0-2.fc33
Summary:  E-book converter and library manager
RPMs: calibre
Size: 68.39 MiB
Size change:  -32.05 KiB
Changelog:
  * Sun Apr 05 2020 Kevin Fenzi  - 4.13.0-1
  - Update to 4.13.0. Fixes bug #1817929


Package:  cataclysm-dda-0.D.10491-1.20200405git0f1e6aa.fc33
Old package:  cataclysm-dda-0.D.10444-1.20200324git5cee241.fc33
Summary:  Turn-based survival game set in a post-apocalyptic world
RPMs: cataclysm-dda cataclysm-dda-data cataclysm-dda-tiles 
cataclysm-dda-tiles-data
Size: 57.87 MiB
Size change:  543.76 KiB
Changelog:
  * Sun Apr 05 2020 Artem Polishchuk  - 
0.D.10491-1.20200405git0f1e6aa
  - Update to 10491


Package:  chromium-80.0.3987.163-1.fc33
Old package:  chromium-80.0.3987.162-1.fc33
Summary:  A WebKit (Blink) powered web browser
RPMs: chrome-remote-desktop chromedriver chromium chromium-common 
chromium-headless chromium-libs chromium-libs-media
Size: 361.84 MiB
Size change:  69.66 KiB
Changelog:
  * Sat Apr 04 2020 Tom Callaway  - 80.0.3987.163-1
  - update to 80.0.3987.163


Package:  daggy-2.0.0-1.fc33
Old package:  daggy-1.1.3-4.fc33
Summary:  Data Aggregation Utility
RPMs: daggy daggy-devel
Added RPMs:   daggy-devel
Size: 848.90 KiB
Size change:  -190.75 KiB
Changelog:
  * Sun Apr 05 2020 Mikhail Milovidov 
  - Update to 2.0.0


Package:  dnfdragora-2.0.0-2.fc33
Old package:  dnfdragora-1.1.1-6.fc32
Summary:  DNF package-manager based on libYui abstraction
RPMs: dnfdragora dnfdragora-updater
Size: 461.86 KiB
Size change:  55.10 KiB
Changelog:
  * Sat Apr 04 2020 Neal Gompa  - 2.0.0-1
  - Rebase to 2.0.0 (#1703486)

  * Sun Apr 05 2020 Neal Gompa  - 2.0.0-2
  - Backport fix from upstream for crash on non-existing user prefs config file


Package:  dolphin-emu-5.0.11819-2.fc33
Old package:  dolphin-emu-5.0.11819-1.fc33
Summary:  GameCube / Wii / Triforce Emulator
RPMs: dolphin-emu dolphin-emu-data dolphin-emu-nogui
Size: 16.07 MiB
Size change:  1.83 KiB
Changelog:
  * Sun Apr 05 2020 Jeremy Newton  - 5.0.11819-2
  - Update bundled soundtouch to 2.1.2


Package:  drupal7-admin_theme-1.1-1.fc33
Old package:  drupal7-admin_theme-1.0-11.fc32
Summary:  Drupal allows you to define a different theme for admin pages
RPMs: drupal7-admin_theme
Size: 18.68 KiB
Size change:  -887 B
Changelog:
  * Sun Apr 05 2020 Shawn Iwinski  - 1.1-1
  - Update to 1.1 (RHBZ #1792395)


Package:  drupal7-backup_migrate-3.7-1.fc33
Old package:  drupal7-backup_migrate-3.5-5.fc32
Summary:  Backup the Drupal database and files or migrate them to another 
environment
RPMs: drupal7-backup_migrate
Size: 105.66 KiB
Size

Re: F32 ELF file analysis

[Jerry James]

On Mon, Apr 6, 2020 at 10:04 AM Steve Grubb  wrote:
> Just wanted to share with everyone the results of a data collection on
> various metrics of ELF files when installing just @Core group.

That is really cool.  Thanks for sharing this, Steve.
-- 
Jerry James
http://www.jamezone.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: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

>
> "a011" is precisely the last entry found in
> https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
> which explains why Xorg picks "intel" as seen in the Xorg logs:
>
> [  7821.917] (==) Matched intel as autoconfigured driver 0
> [  7821.917] (==) Matched modesetting as autoconfigured driver 1
> [  7821.917] (==) Matched fbdev as autoconfigured driver 2
> [  7821.917] (==) Matched vesa as autoconfigured driver 3
>
>
>>   Additionally, Xorg is also non-default, we use Wayland since some
>>   time.
>>
>
> That's correct, on the Fedora Workstation using GNOME - But Wayland is a
> protocol, just like X11, it requires a display server which is gnome-shell,
> and Alexei mentioned in the bug he's using another spin instead, so no
> Wayland there.
>
> So indeed, that bug would unlikely affect the default Fedora Workstation.
>

You don't seem to mind shipping Fedora 32 with a broken git snapshot of the
intel drivel. What are realistic chances to get it fixed eventually given
apparent lack of testing? Therefore, I asked to downgrade it.

I can test modesetting on Gen3 GMA 3150 if that is easy. I dusted off this
netbook for my kids' distant learning during COVID19. I would not be
surprised if more old junk surfaces on your bugzilla soon.
___
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: CPE Git Forge Decision

[clime]

On Mon, 6 Apr 2020 at 17:05, Leigh Griffin  wrote:

>
>
> On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
>
>> On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote:
>> [...]
>> > > Yes, this whole "decision" is in dictatorship relation to the
>> > > community.
>> > >
>> > > Not following the standard procedures caused that I and probably
>> > > many people in the community didn't pay much attention to it.
>> >
>> > We followed the procedures that were outlined to us.
>>
>> So you think "just following procedures" makes it all right and gives
>> you mandate to continuing to pursue a decision that the community is
>> telling you was wrong despite your following procedures?
>>
>
> Our stakeholder and engagement point as a team is Fedora Council. If you
> have issues with how this was handled from a relationship perspective then
> please take that up with the Council. We have engaged with fesco in the
> past at the request of Council and will engage with them in the future in a
> similar manner.
>
>
>>
>> > > I thought you are simply going to collect requirements and then we
>> > > will talk. Collecting the requirements was actually very useful.
>> > > Providing the analysis for the requirements would be useful.
>> > > Providing a recommendation would be ok. Providing a "decision" like
>> > > that crosses the line.
>> > >
>> > > It sends quite a bad message that no matter what you start doing for
>> > > the community and how useful it becomes, RH management can come at
>> > > any time and make your work vanish, which is what is happening here
>> > > with pagure on dist-git effort and probably also zuul efforts might
>> > > get replaced by Gitlab CI.
>> >
>> > We have nothing to do with zuul and Gitlab CI may be made available as
>> > a service if folks want to use it.
>>
>> It's not just about CI. You only commented about the least significant
>> point of the above paragraph and ignored the rest. That seems to be the
>> pattern with your communication. Please change that.
>>
>
> What point would you like me to comment on? Red Hat is not making work
> vanish, we are not deleting Pagure from the internet.
>

Note that I was explicit:

"RH management can come at any
time and make your work vanish, which is what is happening here with
pagure on dist-git effort and probably also zuul efforts might get
replaced by Gitlab CI."

You took it completely somewhere else.

clime


>
>
>>
>> [...]
>> > > But still, please, listen to what the community is telling you.
>> >
>> > We are.
>>
>> That's not the impression you are giving here.
>>
>> > > While you may have means to force your decision as RH management
>> > > representative, doing so can be damaging for both sides (RH and
>> > > Fedora).
>> >
>> > We are not forcing a decision. We are still engaged with the Fedora
>> > Council on next steps and factoring in the requirements of the
>> > community. Right now, our wider needs are saying we cannot support
>> > Pagure and we intend on replacing that with Gitlab from a CPE
>> > perspective.
>>
>> You are forcing a decision because you're refusing to revisit the
>> decision you have made *for* the community without the engagement that
>> the community feels was required.
>
>
> This decision is made for 2x communities, 1x internal stakeholder and the
> CPE team. This decision is impacting 4 groups. If you feel so strongly that
> the decision should be revisited in some way shape or form, make your
> protests known to the Fedora Council. We engage at that level.
>
>
>> If you had stopped at the first
>> objections and revisited the decision making process with the rest of
>> the community involved in an open manner, you would have been forgiven,
>> because everyone here is trying to assume good faith. Alas, you haven't
>> done that. Apologizing for your mistakes is a necessary step, but it's
>> not sufficient.
>>
>
> Ok let's scenario this out so as several people want us to restart and go
> again, largely because they disagree with the decision and Pagure is the
> choice that they would have made. If we re-engage now, I firmly believe we
> will get a whole new set of requirements to complement the existing
> requirements but scoped deliberately (as has been suggested by numerous
> replies) to a situation where Pagure is the only choice for Fedora. How do
> we accommodate that when our other stakeholders' needs are now not being
> met as a whole and when the original requirements needs are being satisfied
> by the choice of Gitlab (which will most likely be CE for Fedora). What
> happens then, how do you suggest we proceed at that point? The other
> stakeholder groups are already progressing with Gitlab and we can do that
> for them and pause the Fedora move in this direction if that was the
> scenario. What happens after months of debate if we cannot bridge that
> divide? What happens when Pagure is sunset as the CPE team cannot run it /
> maintain it? I'm genuinely 

Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

[Petr Pisar]

On Mon, Apr 06, 2020 at 03:02:02PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 31, 2020 at 12:13:16PM +0200, Daniel Mach wrote:
> > >>   # A string representing a Name of a module that is EOLed
> > >>   # MANDATORY
> > >>   module: nodejs
> > >>
> > >>   # A string representing a Stream of a module that is EOLed
> > >>   # MANDATORY
> > >>   stream: 11
> > >>
> > >>   # A string representing a Context of a module that is EOLed
> > >>   # If not specified, all contexts get EOLed.
> > >>   # NOTE: consider specifying a list of contexts
> > >>   # OPTIONAL
> > >>   context: aabbccddee
> > >>
> > >>   # A string representing UTC date in ISO 8601 format: -MM-DD[T 
> > >> ]HH:MMZ
> > >>   # It is strongly recommended to keep HH:MM to 00:00.
> > >>   # If not specified, the module is EOLed immediately.
> > >>   OPTIONAL
> > >>   eol_date: 2020-03-19T00:00Z
> > >
> > >Normally we want the obsoletes to happen when doing a 'dnf system-upgrade'
> > >operation, and not based on time. Does this allow us to tell dnf for this
> > >happen during an upgrade, but not before?
> > There are scenarios when you don't run system-upgrade and you still
> > want the obsoletes. Consider Rawhide. We'll need a way how to
> > trigger modular obsoletes even during normal upgrade/distro-sync
> > transactions.
> > 
> > Setting eol_date to the future allows informing a user about
> > upcoming obsoleting event so they can eventually migrate manually.
> 
> For some context (RHEL...) time-based obsoletes make plenty of sense.
> But in Fedora we established a policy that obsoletion and other
> significant stream changes happen at "release boundary", which for
> each user is whenever they choose to upgrade, so not time-based.
>
That's a great motivation, but this is not how it works in the real world.

A packager asks for a branch and sets an end-of-life date. The date is
enforced to align with a Fedora cadence. I.e. 4th and 10th month of a year. The
packager builds a module from that branch for _all_ Fedoras and pushes the
builds to the stable repositories. Once the end-of-life day comes, the
packager stops maintaining the stream. That day there is exactly one Fedora
release that also reached the end of life. But all the newer Fedora releases
are still supported, but the stream there is not. You have an unsupported
stream in a supported Fedora release.

That's the outcome of decoupling a stream life cycle from a Fedora life cycle.

-- Petr


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

F32 ELF file analysis

[Steve Grubb]

Hello,

Just wanted to share with everyone the results of a data collection on 
various metrics of ELF files when installing just @Core group.

http://people.redhat.com/sgrubb/analysis/f32-analysis.slides.html#/

I recommend clicking on the "pop out" link and then you have more room to see 
the results. To use it grab SOURCERPM and dragh it just below "count", then 
drag FILE under SOURCERPM, then grab STACK_PROT and drag it to the right of 
count. Next click on the drop down and uncheck "ok". Click apply. Now you 
have the listing of all files without the right stack protector hardening.

Go back into the STACK_PROT, check ok, click apply. Drag STACK_PROT back to 
where it came from, grab USES_SECCOMP, drag it to the right of "count", click 
drop down, uncheck "no", click apply, now you have the list of programs using 
seccomp for confinement.

Have fun playing with the data. Just remember when you subset the data, it 
stays that way until you check all boxes. In case your curious, this is 
exported from a Jupyter Notebook.

-Steve

___
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

[rpms/perl-Unix-Syslog] PR #1: Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1

[Paul Howarth]

pghmcfc closed without merging a pull-request against the project: 
`perl-Unix-Syslog` that you
are following.

Closed pull-request:

``
Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1
``

https://src.fedoraproject.org/rpms/perl-Unix-Syslog/pull-request/1
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org

[rpms/perl-Unix-Syslog] PR #1: Spec file cleanups: Use make_build, make_install macros, and use NO_PACKLIST=1

[Paul Howarth]

pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build, 
make_install macros, and use NO_PACKLIST=1` that you are following:
``
I merged this locally and fixed the typo in the ExtUtils::MakeMaker reference. 
It's now pushed and built in Fedora.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Unix-Syslog/pull-request/1
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Vascom]

I would like to take arduino.
I can make buildable again 1.8.5 version and may be update it to latest.

My FAS name: vascom -- Best regards, Vasiliy Glazov

вс, 29 мар. 2020 г. в 14:15, Miro Hrončok :
>
> According to the Fedora's Fails To Build From Source policy:
>
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The following packages will be orphaned on Monday 2020-04-06.
>
> Their F32FTBFS Bugzillas are in NEW state for the defined period of time and
> they have the necessary reminders. They were not successfully rebuilt in 
> Fedora
> 32 since the Bugzillas were opened.
>
> If you can fix your package to build, perform a build in koji, and either 
> create
> an update in bodhi, or close the relevant bug without creating an update, if
> updating is not appropriate. If you are working on a fix, set the status to
> ASSIGNED to acknowledge this and prevent the orphaning.
>
> Oprhaning is a easily revertible nondesctructiove action.
> Only packages orphaned for 6+ weeks will be retired (removed from) Fedora
> rawhide (i.e. not form Fedora 32).
>
> Maintainers by package:
> 0ad  ignatenkobrain pcpa pwalter
> CPUFreqUtility   f1ash
> GConf2   alexl caillon caolanm johnp mbarnes rhughes rstrode ssp 
> walters
> GREYCstoration   tnorth
> SDL2_gfx ignatenkobrain lkundrak
> abcm2ps  gemi
> adapta-gtk-theme atim
> afpfs-ng lkundrak
> aircrack-ng  ichavero
> antlr4   gil jkastner lef mizdebsk sdgathman
> apache-commons-dbutils mizdebsk spike
> apache-commons-email mizdebsk spike
> apache-commons-jcs   cquad jjelen
> apanov-edrip-fonts   frixxon nim
> apbs rathann timfenn
> arduino  giallu patches thozza
> artharoshansingh
> astrometry   lupinix
> astrometry-tycho2lupinix
> audacity dtimms gemi moezroy
> avalon-framework jerboaa jjelen mizdebsk
> avr-gdb  giallu tnorth trondd
> blessdrago01
> bmakelbazan
> boothjpokorny
> bygfoot  hguemar
> cassandra-java-driver acaringi hhorak jjanco
> castor   arobinso lef
> catimg   ignatenkobrain
> cdpr stahnma
> ckermit  brouhaha
> classloader-leak-test-framework acaringi praiskup
> clipstimn
> cmyktool duffy
> cog  bunnyapocalypse
> corianderdajt timn
> cp2k deji rathann tomspur
> dahdi-tools  bruno itamarjp jsmith
> dateshiftfab
> dibbler  ihrachyshka
> dieharderjhladky
> doccojamielinux patches
> drbd mhayden
> dsi  dbrasher
> echolinuxlucilanga
> echoping ixs
> eclipse-avr  bubeck
> eclipse-egit-github  mbooth
> eclipse-launchbarmbooth sopotc
> eclipse-m2e-core galileo mbooth mizdebsk
> eclipse-mylynarobinso jjohnstn kdaniel mbooth rgrunber
> eclipse-photran  akurtakov orion
> eclipse-ptp  jjohnstn kdaniel orion
> eclipse-pydevjjohnstn mbooth
> eclipse-remote   mbooth
> eclipse-subclipsekdaniel mbooth
> eclipse-testng   mbooth
> eclipse-tm-terminal  mbooth
> eclipse-webtools galileo mbooth
> elpa rathann
> emacs-mmmamdunn
> etcd avesh cypret eparis gscrivano jchaloup lsm5 strigazi 
> walters
> fcoe-utils   cleech
> fedora-jam-kde-theme eeickmeyer jvlomax
> flatbuffers  avsej
> foma vpv
> forbidden-apis   jvanek zzambers
> freeDiameter filiperosset
> fts  andreamanzi simonm
> gabedit  itamarjp rathann
> game-music-emu   kvolny moezroy
> gauche   gemi salimma
> gcolor2  cwickert
> gdigimchehab
> geronimo-jcdi-1.0-api jjelen lef
> ggz-gtk-client   bruno pwalter
> git-cola moceap ohaessler
> gluegen2 jamesturner246
> gmpc adrian
> gnomad2  snirkel
> gnomint  verdurin
> goaccess cicku echevemaster
> golang-github-influxdata-flux eclipseo
> golang-github-influxdata-influxdb eclipseo
> golang-github-nats-io-streaming eclipseo
> golang-github-opencontainers-runc eclipseo
> golang-k8s-kubernetes eclipseo
> golang-k8s-legacy-cloud-providers eclipseo
> golang-vitesseclipseo
> gplugin  ignatenkobrain
> gpsdrive nphilipp
> graphite2moceap vanoudt
> grsync   cwickert
> gticknphilipp renich
> gtkdialogmoceap
> gwgetcwickert
> hcc  tstellar
> hfsplusutils dwmw2
> hovercraft   ishcherb ralph
> hping3   pwouters
> hugo athoscr
> igt-gpu-toolsairlied lyude
> imageinfobrendt
> java-vashjgu
> 

PSA: please do not BuildRequires: qt5-devel

[Rex Dieter]

The qt5, qt5-devel metapackages were introduced a few releases ago as merely 
a convenience for end-users, not intended to be used in official fedora 
packages, but seems these have seen some non-trivial adoption anyway.

Personally, I objected to metapackage introduction at the fearing this would 
happen, and it has.  Appended is a current list of offenders.

Starting now as a preventative measure, I'm dropping the creation of these 
metapackages on f32+.  Maintainers of the packages below will need to adjust 
things appropriately.  In the *least*, replacing:
BuildRequires: qt5-devel
with
BuildRequires: qt5-qtbase-devel



# dnf repoquery --repoid=rawhide-source --arch=src --whatrequires qt5-devel
...
Panini-0:0.73.0-4.fc32.src
Pencil2D-0:0.6.4-3.fc32.src
ampache_browser-0:1.0.2-5.fc32.src
arc-gui-clients-0:0.4.6-21.fc32.src
cool-retro-term-0:1.1.1-4.fc32.src
cppcheck-0:1.90-5.fc32.src
cutecom-0:0.51.0-4.fc32.src
danmaq-0:0.2.3.1-8.fc32.src
dolphin-emu-0:5.0.11819-1.fc33.src
edb-0:0.9.21-5.fc32.src
fips-0:3.3.1-5.fc32.src
fmit-0:1.2.13-2.fc32.src
focuswriter-0:1.7.5-1.fc33.src
gcin-0:2.8.9-3.fc33.src
heimdall-0:1.4.2-9.fc32.src
icemon-0:3.3-2.fc32.src
jalv-0:1.6.4-2.fc32.src
klog-0:1.0-2.fc33.src
mozc-0:2.23.2815.102-9.fc32.src
mumble-0:1.3.0-1.fc33.src
musique-0:1.5-4.fc31.src
notepadqq-0:1.4.8-10.fc32.src
openal-soft-0:1.19.1-5.fc33.src
openscad-0:2019.05-9.fc33.src
ophcrack-0:3.8.0-4.fc32.src
plplot-0:5.15.0-9.fc33.src
prestopalette-0:0.1.31-7.fc32.src
pulseview-0:0.4.2-1.fc33.src
qgis-0:3.12.1-1.fc33.src
qtiocompressor-0:2.3.1-20.fc32.src
recorder-0:1.0.8-3.fc32.src
root-0:6.20.02-1.fc33.src
rstudio-0:1.2.5033-12.fc33.src
scap-workbench-0:1.2.1-2.fc32.src
scribus-0:1.5.6-0.6.fc33.src
speedcrunch-0:0.12-7.fc32.src
subversion-0:1.12.2-7.fc33.src
suil-0:0.10.6-2.fc32.src
unixODBC-gui-qt-0:0-0.22.20190111svn132.fc32.src
wt-0:4.3.0-1.fc33.src
xca-0:2.2.1-1.fc32.src
xpdf-1:4.02-3.fc32.src
zhu3d-0:4.2.6-17.fc32.src



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

[Bug 1820788] perl-Rose-DB-Object-0.817 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-62f890cc77 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-62f890cc77


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2020-04-06)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2020-04-06)
=

Meeting started by contyk at 15:00:22 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-06/fesco.2020-04-06-15.00.log.html


Meeting summary
---
* init process  (contyk, 15:00:28)

* #2369 Request: Postpone F32 Final Freeze by 3 ≤ N ≤ 7 days  (contyk,
  15:02:40)
  * AGREED: Fedora 32 Final Freeze is posponed to Thursday 2020-04-09
14:00 UTC (+9, 0, -0)  (contyk, 15:13:12)
  * ACTION: bcotton to update schedule  (bcotton, 15:13:24)

* #2364 F33 System-Wide Change: Introduce module Obsoletes and EOL
  (contyk, 15:14:16)
  * This topic needs more discussion and responses from the proposal
owners. We'll discuss this next week.  (contyk, 15:16:44)

* #2365 F33 System-Wide Change: ELN Buildroot and Compose  (contyk,
  15:17:43)
  * sgallagh will address mhroncok's comments and clarify the proposal;
we will vote next week; in case of no quorum, we commit to voting in
the ticket async.  (contyk, 15:24:47)

* Next week's chair  (contyk, 15:37:36)
  * ACTION: sgallagh will chair the next meeting.  (contyk, 15:39:19)
  * ACTION: mhroncok will chair the meeting of 2020-04-20  (contyk,
15:39:29)

* Open Floor  (contyk, 15:39:38)

Meeting ended at 15:41:11 UTC.


Action Items

* bcotton to update schedule
* sgallagh will chair the next meeting.
* mhroncok will chair the meeting of 2020-04-20


Action Items, by person
---
* bcotton
  * bcotton to update schedule
* mhroncok
  * mhroncok will chair the meeting of 2020-04-20
* sgallagh
  * sgallagh will chair the next meeting.


People Present (lines said)
---
* contyk (47)
* sgallagh (32)
* mhroncok (25)
* nirik (20)
* zodbot (19)
* adamw (13)
* zbyszek (9)
* dcantrell (8)
* decathorpe (7)
* ignatenkobrain (5)
* mboddu (4)
* bookwar (3)
* bcotton (3)
* frantisekz (2)
___
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: CPE Weekly: 2020-04-04

[Nicolas Mailhot via devel]

Le lundi 06 avril 2020 à 11:42 -0400, Alex Scheel a écrit :
> 
> I'm not sure why what happens outside Fedora infra has anything to do
> with the dist-git discussion. Are you suggesting that all
> contributors
> to all Fedora upstream should weigh in on this discussion as well? I
> mean, that'd be nice I suppose, but mostly this a discussion for
> people who interact with dist-git frequently. 

This should be discussion for the people who make Fedora tick. You can
make Fedora every week, or every month, but is is also perfectly fine
to push things every six months before stable branching and only land
sporadic fixes in between.

-- 
Nicolas Mailhot
___
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: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson 
wrote:

> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> >
> > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
> > > CI? I.e. technical differences and advantages of each? If you did, can
> you,
> > > please, publish it? It would be valuable info for the community and
> > > something we can comment on.
> > >
> >
> > Gitlab CI was not part of our evaluation, we are aware it's a service
> that
> > is offered but did not evaluate it as it wasn't within the scope of our
> > exercise.
>
> So, how does that track with this quote from the decision blog post?
>
> "Some top level requirements which helped us arrive at this decision
> [to choose Gitlab]:
>
> There is a need for CentOS Stream to integrate with a kernel workflow
> that is an automated bot driven merging solution (merge trains). This
> allows for richer CI capabilities and minimises the need for human
> interaction"
>
> If you did not evaluate Gitlab CI (and presumably CI capabilities of
> the three systems more widely), how did the need for a CI feature -
> that is what "merge trains" are - act as a "top level requirement"
> which "helped us arrive at this decision"?
>

I'm talking specifically about CI as a capability, in that specific
integrations at a CI level for hooks and other nice stuff which has several
known issues in Pagure at an API level, we evaluated that high level
requirement. Some stakeholders do not want to use the built in Gitlab CI as
we have CentOS CI used extensively and some have homebrewed systems that
they use. Hence why we did not go deep on CI at a very functional level
outside of known limitations and desires that came up as direct
requirements.

Merge trains and that capability is plugin / CI based and was explicit in
it's scope (it was called out as a need to have merge train functionality)
Vs CI in general as it was named as a need. We had discussed that Zuul was
a possibility around Pagure as part of that.


> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Daniel P. Berrangé" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 11:02:52 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 

> Watching the discussion in the other big thread, I feel it has become
> rather too toxic & negative, going over & over the same points, verging
> into personal insults, and repeatly beating people over the previous
> communication or process failures. I struggle to see anything positive
> coming from further contributors joining in that discussion thread,
> which I expect is why so many choose to remain silent.

Agreed on the toxicity and negativity, but I still think it is important
to get a sense of everyone's thoughts, not just those of us who participate
in this thread.

> Going for a formal vote on this topic would not be a good step at this
> point in time, as the issue is far too emotive & raw. A vote will serve
> to crystalize division instead of healing it & we need to consider what
> is viable, as voting for something that can't then be delivered is even
> worse.

I wasn't suggesting a formal vote. I was suggesting a survey, using an
existing mechanism. We could also use Google forms (like Modularity did),
but that'd make the results less visible and some people don't like
Google. Also, the voting mechanism ties into FAS ID's and has restrictions
on who can participate (users with two different groups right?). It'd be
hard to enforce something similar with Google forms.

> IMHO there needs to be a general cooling off period, followed by a fresh
> look at what the realistic options available to Fedora are, given the
> current decisions that have been made & the resources available to the
> project[1]. We need to be positive & constructive if we're to make any
> progress, and get out of the negative blame game we're in right now.

I think we need to involve everyone who CPE works with in one forum,
otherwise we'll likely arrive at maintaining two separate projects,
one just for Fedora and one for CentOS and Red Hat. Perhaps that is
what is best though, who knows.

> Regards,
> Daniel
> 
> [1] I'm not saying that we must go ahead with the decision to replace
> Pagure with GitLab. Just that we need to carefully consider where
> to go from here, as any decision needs to be sustainable for the
> project in the long term.
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange
> |:|
> |: https://libvirt.org -o-https://fstop138.berrange.com
> |:|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> |:|
> ___
> 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: Urgently downgrade xorg-x11-drv-intel

[Peter Robinson]

> > >Are they? We stopped using intel driver around F26, we use
> > > modesetting for Intel GPUs now.  The above is clearly non-default
> > > configuratiob.
> >
> > I am far from an expert on the subject, but I am pretty sure we did not stop
> > using intel driver when we use kernel mode setting. We just ask for the
> > kernel to do the change of video mode, but the intel driver still does the
> > drawing on display.
> >
> > Here on my i3-8100 computer, using as far as I know the graphics pipeline on
> > the CPU itself ( Mesa Intel® UHD Graphics 630 (CFL GT2) ) I have:
> >
> > [paul@localhost ~]$ lsmod | grep i915
> > i915 2617344  18
> > i2c_algo_bit   16384  1 i915
> > cec61440  1 i915
> > drm_kms_helper245760  1 i915
> > drm   655360  7 drm_kms_helper,i915
> > video  53248  2 asus_wmi,i915
>
>   Yes, that's the kernel side part. But in userland,
> we are NOT using xorg-x11-drv-intel for intel gen4 and up
> (if I understand
> https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
> correctly). Gen4 was released in 2006:
> https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen4

I think, from 2.99.917-22.20160119 it's actually from Gen 9+ (skylake)
which wouldn't cover GMA3150
___
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: CPE Weekly: 2020-04-04

[Leigh Griffin]

On Mon, Apr 6, 2020 at 4:34 PM Miro Hrončok  wrote:

> On 06. 04. 20 17:20, Leigh Griffin wrote:
> >
> > I'm reaffirming that I hear the concerns and that my team are taking
> them on
> > board. I am also reaffirming that our engagement point is with the
> Fedora
> > Council, not at the individual level as the Council is responsible for
> listening
> > and collating those concerns and speaking on behalf of the entire
> community.
>
> This only makes it more clear that you are not interested in engaging with
> the
> community directly, but you are deferring that to the Council. This is not
> "the
> process", this is just a way to justify not engaging. What you say here is
> not
> very friendly.
>

I am engaging with the community directly but we have agreed and
predetermined engagements with the Fedora Council to enact actual changes.
We cannot take the view of a singular person and make changes based on
that, we defer to them for prioritisation and their input. That's how the
relationship works between CPE and the Fedora Community and it's how formal
requests and feedback are routed.


>
> > It
> > is not for me to change how that process works so please reach out to
> your
> > Council reps and engage through that channel.
>
> Fedora has an established process for infra changes like this and you have
> chosen to bypass it entirely by talking directly to the Council.


As explained above we have our formal engagement process. I can bring this
up with Council in our next scheduled sync if the feeling is that we should
be engaging through other means. I'm happy to accomodate.


> And now you say
> "this is how this process works" -- well, in fact it isn't.
>
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
>
> https://pagure.io/Fedora-Council/tickets/issue/292#comment-640101


+1 on that ticket I would like to see clarity on this point so that we can
engage in the right way in the future. Our engagement was not designed to
side step known processes, it was taken at face value to engage with
Council as previously agreed on.


>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
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: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 10:57:40 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit :
> > 
> > In the last FESCo election, 273 ballots were cast [0]. According to
> > the
> > graph maintained by Matthew Miller [1], we have between 225 and 375
> > active maintainers in Fedora, depending on how you count.
> 
> That’s *weekly* activity. As in, the packager finished something, and
> was active a specific week landing the result in Fedora. It does not
> count all what happens outside Fedora infra before the result lands.

I'm not sure why what happens outside Fedora infra has anything to do
with the dist-git discussion. Are you suggesting that all contributors
to all Fedora upstream should weigh in on this discussion as well? I
mean, that'd be nice I suppose, but mostly this a discussion for people
who interact with dist-git frequently. 

I do recognize that perhaps a monthly contributor list might have higher
magnitude than 300. But there's still old bugs, new bugs, and random other
contributions that could count as activity besides pushing a Bodhi update.


My 2c.

- Alex

> 
> --
> Nicolas Mailhot
> ___
> 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 32 FTBFS packages to be orphaned in 1 week

[Vascom]

I would like to take arduino.
I can make buildable again 1.8.5 version and may be update it to latest.

My FAS name: vascom

--
Best regards,
Vasiliy Glazov
___
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 32 compose report: 20200406.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200405.n.0
NEW: Fedora-32-20200406.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  6
Dropped packages:0
Upgraded packages:   126
Downgraded packages: 0

Size of added packages:  10.29 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.57 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.43 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-32-20200406.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: cxxopts-2.2.0-1.fc32
Summary: Lightweight C++ command line option parser
RPMs:cxxopts-devel
Size:121.88 KiB

Package: goverlay-0.3-1.fc32
Summary: Project that aims to create a Graphical UI to help manage Linux 
overlays
RPMs:goverlay
Size:8.85 MiB

Package: intel-clear-sans-fonts-1.00-3.fc32
Summary: Clear Sans, a versatile font family for screen, print, and Web
RPMs:intel-clear-sans-fonts
Size:445.63 KiB

Package: python-scramp-1.1.0-1.fc32
Summary: An implementation of the SCRAM protocol
RPMs:python3-scramp
Size:20.32 KiB

Package: swt-chart-0.12.0-3.fc32
Summary: Eclipse SWTChart
RPMs:swt-chart
Size:440.00 KiB

Package: xmlrpc-1:3.1.3-24.fc32
Summary: Java XML-RPC implementation
RPMs:xmlrpc-client xmlrpc-common xmlrpc-javadoc xmlrpc-server
Size:448.14 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  FAudio-20.04-1.fc32
Old package:  FAudio-20.03-1.fc32
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 794.08 KiB
Size change:  1.11 KiB
Changelog:
  * Thu Apr 02 2020 Michael Cronenworth  - 20.04-1
  - Update to 20.04


Package:  PySolFC-2.8.0-2.fc32
Old package:  PySolFC-2.6.4-9.fc32
Summary:  A collection of solitaire card games
RPMs: PySolFC
Size: 6.36 MiB
Size change:  43.59 KiB
Changelog:
  * Tue Mar 24 2020 Shlomi Fish  2.8.0-1
  - New upstream version

  * Sat Mar 28 2020 Shlomi Fish  2.8.0-2
  - Fix or remove shebangs (RHBZ 1818150)
  - Correct the changelog


Package:  blender-1:2.82a-1.fc32
Old package:  blender-1:2.82-3.fc32
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-fonts blender-rpm-macros
Size: 171.88 MiB
Size change:  -126.74 KiB
Changelog:
  * Sat Mar 14 2020 Luya Tshimbalanga  - 1:2.82a-1
  - Update to 2.82a (#1810743)


Package:  breeze-icon-theme-5.68.0-1.fc32
Old package:  breeze-icon-theme-5.67.0-1.fc32
Summary:  Breeze icon theme
RPMs: breeze-icon-theme breeze-icon-theme-rcc
Size: 10.23 MiB
Size change:  151.22 KiB
Changelog:
  * Fri Mar 20 2020 Rex Dieter  - 5.68.0-1
  - 5.68.0


Package:  calcurse-4.6.0-1.fc32
Old package:  calcurse-4.5.1-2.fc32
Summary:  Text-based personal organizer
RPMs: calcurse
Size: 1.19 MiB
Size change:  10.28 KiB
Changelog:
  * Fri Mar 27 2020 Gwyn Ciesla  - 4.6.0-1
  - 4.6.0


Package:  chromium-80.0.3987.162-1.fc32
Old package:  chromium-80.0.3987.149-1.fc32
Summary:  A WebKit (Blink) powered web browser
RPMs: chrome-remote-desktop chromedriver chromium chromium-common 
chromium-headless chromium-libs chromium-libs-media
Size: 361.82 MiB
Size change:  -165.93 KiB
Changelog:
  * Wed Apr 01 2020 Tom Callaway  - 80.0.3987.162-1
  - update to 80.0.3987.162


Package:  eclipse-pydev-1:7.5.0-1.fc32
Old package:  eclipse-pydev-1:7.1.0-2.fc31
Summary:  Eclipse Python development plug-in
RPMs: eclipse-pydev
Dropped RPMs: eclipse-pydev-mylyn
Size: 29.36 MiB
Size change:  1.32 MiB
Changelog:
  * Sat Jun 01 2019 Mat Booth  - 1:7.2.1-1
  - Update to latest upstream release
  - Fix missing cython extension for python 2 users

  * Mon Jun 17 2019 Mat Booth  - 1:7.2.1-2
  - Rebuild against Lucene 8

  * Fri Jun 21 2019 Mat Booth  - 1:7.2.1-3
  - Fix failure to build against Eclipse 2019-06

  * Sun Sep 01 2019 Mat Booth  - 1:7.2.1-4
  - Temporarily disable cython debugging extension on F32 due to a problem
building against python 3.8

  * Mon Sep 09 2019 Mat Booth  - 1:7.3.0-1
  - Update to latest upstream release

  * Mon Sep 23 2019 Mat Booth  - 1:7.3.0-2
  - Ensure c++11 is used when building native part

  * Wed Nov 20 2019 Mat Booth  - 1:7.4.0-1
  - Update to latest upstream release

  * Sat Nov 23 2019 Mat Booth  - 1:7.4.0-2
  - Don't build python 2 extensions for Fedora >= 32

  * Tue Jan 28 2020 Fedora Release Engineering  - 
1:7.4.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Tue Mar 24 2020 Mat Booth  - 1:7.5.0-1
  - Update to latest upstream release
  - Drop mylyn extension
  - Drop python 2 cython extension support


Package:  ephemeral-6.3.2-1.fc32
Old package:  ephemeral-6.3.1-1.fc32
Summary:  Priv

Self Introduction: Ondřej Gajdušek

[Ondrej Gajdusek]

Hello,

My name is Ondrej Gajdusek. I currently work as a QE in Red Hat where I
work mainly with Foreman and Katello projects which are upstream projects
for the RH Satellite. I have some Python background so you can expect my
contributions mainly in the Python field. I look forward to contributing to
Fedora.

My current aim is to get the apypie [1] package into Fedora. So I would
appreciate any advice for the package review - bug 1821330.

Thank you,
Ondrej

[1] https://github.com/Apipie/apypie
___
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: CPE Weekly: 2020-04-04

[Miro Hrončok]

On 06. 04. 20 17:20, Leigh Griffin wrote:


I'm reaffirming that I hear the concerns and that my team are taking them on 
board. I am also reaffirming that our engagement point is with the Fedora 
Council, not at the individual level as the Council is responsible for listening 
and collating those concerns and speaking on behalf of the entire community.


This only makes it more clear that you are not interested in engaging with the 
community directly, but you are deferring that to the Council. This is not "the 
process", this is just a way to justify not engaging. What you say here is not 
very friendly.


It 
is not for me to change how that process works so please reach out to your 
Council reps and engage through that channel.


Fedora has an established process for infra changes like this and you have 
chosen to bypass it entirely by talking directly to the Council. And now you say 
"this is how this process works" -- well, in fact it isn't.


https://docs.fedoraproject.org/en-US/program_management/changes_policy/

https://pagure.io/Fedora-Council/tickets/issue/292#comment-640101


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

Hi,

On Mon, Apr 6, 2020 at 4:57 PM Tomasz Torcz  wrote:

>   Yes, that's the kernel side part. But in userland,
> we are NOT using xorg-x11-drv-intel for intel gen4 and up
> (if I understand
>
> https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
> correctly). Gen4 was released in 2006:
> https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen4
>

>From the Xorg logs attached to bug 1820815

[  7821.744] (--) PCI:*(0@0:2:0) 8086:a011:1043:83ac rev 2, ...

So that's a GMA3150, as found in Pineview chipsets circa 2010 according to
the wikipedia page linked above.

"a011" is precisely the last entry found in
https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
which explains why Xorg picks "intel" as seen in the Xorg logs:

[  7821.917] (==) Matched intel as autoconfigured driver 0
[  7821.917] (==) Matched modesetting as autoconfigured driver 1
[  7821.917] (==) Matched fbdev as autoconfigured driver 2
[  7821.917] (==) Matched vesa as autoconfigured driver 3


>   Additionally, Xorg is also non-default, we use Wayland since some
>   time.
>

That's correct, on the Fedora Workstation using GNOME - But Wayland is a
protocol, just like X11, it requires a display server which is gnome-shell,
and Alexei mentioned in the bug he's using another spin instead, so no
Wayland there.

So indeed, that bug would unlikely affect the default Fedora Workstation.

HTH,
Cheers
Olivier
___
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: Orphaning package procedure. (icewm, spring, springlobby)

[Artem Tim]

Hello. Gilboa, i would like to continue maintaining IceWM. And i interesting in 
'springlobby' package. Please add me as co-maintainer. FAS: atim.
___
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: CPE Git Forge Decision

[Randy Barlow]

On 4/6/20 11:17 AM, Leigh Griffin wrote:
It's a form of engagement among others that we are partaking in day in 
day out, week in week out.


Ironically, you have illustrated my point here with your response, which 
isn't engagement.


I have answered every question directly, if I missed one in the multiple 
threads and someone wants it answered, feel free to forward it onto me 
directly and I can answer it.


Much of what people are writing aren't questions, they are arguments. 
You have not been answering those, but have instead been replying with 
non-sequiters, like the above "It's a form of engagement among others…"



Everything is untrue when paraphrased to suit a narrative.


You said "The CPE relationship with stakeholders is unique, it's clear 
the visions are not aligned across all bodies (and we do not expect it 
to be) and we don't have a product." I've demonstrated that this is not 
true.


For sure 
stakeholder misalignment is part and parcel of Engineering life, CPEs 
stakeholder needs, our particular remit and how all of these things 
interact are industry unique in my experience and the kind of alignment 
needed might never be there that One would expect and hope for in a more 
traditional Engineering setting. I'm happy to debate that in a 
separate thread but I feel going into how the team is structured and how 
that relationship works is a distraction that this thread does not need. 


You introduced this distraction, I simply demonstrated that it was not true.
___
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: CPE Git Forge Decision

[Adam Williamson]

On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> 
> > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
> > CI? I.e. technical differences and advantages of each? If you did, can you,
> > please, publish it? It would be valuable info for the community and
> > something we can comment on.
> > 
> 
> Gitlab CI was not part of our evaluation, we are aware it's a service that
> is offered but did not evaluate it as it wasn't within the scope of our
> exercise.

So, how does that track with this quote from the decision blog post?

"Some top level requirements which helped us arrive at this decision
[to choose Gitlab]:

There is a need for CentOS Stream to integrate with a kernel workflow
that is an automated bot driven merging solution (merge trains). This
allows for richer CI capabilities and minimises the need for human
interaction"

If you did not evaluate Gitlab CI (and presumably CI capabilities of
the three systems more widely), how did the need for a CI feature -
that is what "merge trains" are - act as a "top level requirement"
which "helped us arrive at this decision"?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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