Re: Minimization Objective report

[Igor Gnatenko]

On Wed, Sep 25, 2019 at 6:01 PM Adam Samalik  wrote:
>
> This is the Minimization Objective [0] update.
>
> Status: Discovery phase
>
> == Regular meeting canceled ==
>
> We have decided to cancel the regular Minimization Team Meeting [1] as we 
> prefer async discussions on #fedora-devel and de...@lists.fp.o. This makes it 
> more inclusive to people with other commitments or being in timezones that 
> prevent them attending the meeting at that specific time.
>
> == systemd-sysusers vs. containers ==
>
> We don't want Systemd in containers [2], but we recognise this is a 
> container-specific problem. So we're asking other groups — Containers SIG and 
> people working with OpenShift — for how they're approaching this problem.
>
> == Feedback Pipeline ==
>
> Feedback Pipeline [3] is now automated, refreshing every day.
>
> It also now includes sizes of individual packages in all reports, as well as 
> a timestamp.
>
> == pcre -> pcre2 ==
>
> Moving grep (one of the last packages using pcre) to pcre2. [4]

I'm curious if we should simply replace grep by ripgrep :)

> == How to get involved ==
>
> See if there is anything interesting to you on action plan [42], or reach
> out with something you think is useful but is missing there. Open a ticket
> in the tracker [43] or discuss in #fedora-devel on IRC.
>
> Cheers,
> Adam
>
>
> [0] Objective: https://docs.fedoraproject.org/en-US/minimization/
> [1] Meeting canceled: https://pagure.io/minimization/issue/14
> [2] systemd-sysusers vs. containers: https://pagure.io/minimization/issue/13
> [3] Feedback Pipeline: https://minimization.github.io/reports/
> [4] switching grep to pcre2: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1755491
> [42] Action plan: 
> https://docs.fedoraproject.org/en-US/minimization/action-plan/
> [43] Issue tracker: https://pagure.io/minimization/issues
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> 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: kata containers: adding a docker runtime

[Daniel Walsh]

On 9/25/19 8:26 PM, Tomasz Torcz wrote:
> On Wed, Sep 25, 2019 at 12:14:54PM +0200, Christophe de Dinechin wrote:
>> Hi Lokesh,
>>
>>
>> As you know, I have been working on bringing kata containers to Fedora.
>>
>> Since this adds a new runtime, the docker.service file would need to be
>> modified in order to be able to accommodate extra --add-runtime options.
>>
>> What approach would you recommend?
>   There's no Docker in Fedora anymore, so maybe don't bother?
>  

Podman, CRI-O, Buildah should be able to use the kata runtime.  If
moby-engine, the replacement for DOcker needs wants to use it, then it
should add the capability. 


BTW These are OCI runtimes, non "docker" runtimes. 
___
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

2020 Datacenter Move: Request for comments

[Kevin Fenzi]

Greetings, 

Fedora Infrastructure currently has the majority of its hardware in a 
datacenter in Arizona, USA.  Red Hat leases this space for use by a number of 
teams, including Fedora. However, they've been seeking a more modern and cost
effective location for some time and have decided on one: 
So, we will be migrating to a new datacenter located in Ashburn, Virginia
in 2020.

FESCo has approved a 2 week window for the actual move to take place 
( https://pagure.io/fesco/issue/2221 ): 2020-06-01 to 2020-06-15. 
This window is after Fedora 32 is released, but before any major
Fedora 33 Milestones. 

At a high level, our current plan is:
* Setup the new datacenter with networking/storage/management
* Populate the new datacenter with new hardware to replace old hardware that 
either wouldn’t survive the shipping or is due to be refreshed
* Ship some small shipment of hardware from the old datacenter to the new
that are not easily duplicated like signing hardware,
alternative arch builders, etc.
* Setup and have by the early part of the outage window a 
Minimum Viable Fedora Infrastructure (see below) using new hardware
and some old.
* Function in this minimal state as all the rest of the hardware is
shipped to the new datacenter.
* Re-add hardware to return to normal state.

We want to maintain continuity of service as best we can,
so we have defined a Minimal Viable Fedora which will move in advance
of the main hardware. Our intention is to reroute traffic to this setup
before moving the bulk of our hardware.

Our current list of what a Minimum Viable Fedora Infrastructure is:

* Mirroring fully functional. Users get metalinks, mirrors are crawled, etc
* The complete package lifecycle must work.
From commit to update installed on users machines.
We need this to push security and important bugfixes as well as to allow
maintainers to work toward Fedora 33.
* Our production openshift cluster must be up and running normally.
(This cluster has fas, bodhi and other important items in it)
* Builders will likely be constrained.
Ie, less of most arches.
Capacity will be re-added as soon as the hardware for it arrives.
* Rawhide composes take place as normal.
* Nameservers functional
* rabbitmq/fedora-messaging should be up and functional.
* Internal proxies must be functional (used by builders and other internal 
items)
* Mailing lists must be functional
* Backups must be functional
* OpenQA must be available to test updates/rawhide composes
* Wiki must be available for common bugs / qa

Other services not listed may or may not be up depending on capacity
and issues with more important services.

And explicitly some things will NOT be available during that window:

* Staging. There will be no staging, so no rolling out new services.
* Full capacity/number of builders
* External proxies in the new datacenter
* HA for some services.

We are sending this announcement not only to let you all be aware of this move, 
but to help us plan. If you see some service that you think is critical
to Fedora and cannot be down for 2 weeks, and isn't listed above
please let us know so we can adjust our plans. 

We want to make sure things that are critical keep running
smoothly for the Fedora community.

Feedback by next friday (2019-10-04) would be welcome. 

Thanks,

Kevin for CPE and the Fedora Infrastructure team.


signature.asc
Description: 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 31 compose report: 20190927.n.1 changes

[Fedora Branched Report]

OLD: Fedora-31-20190926.n.0
NEW: Fedora-31-20190927.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  1
Dropped packages:1
Upgraded packages:   49
Downgraded packages: 0

Size of added packages:  37.53 KiB
Size of dropped packages:96.51 MiB
Size of upgraded packages:   252.59 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: eralchemy-1.2.10-2.fc31
Summary: Entity Relation Diagrams generation tool
RPMs:eralchemy python3-eralchemy
Size:37.53 KiB


= DROPPED PACKAGES =
Package: mingw-wine-gecko-2.47-2.fc26
Summary: Gecko library required for Wine
RPMs:mingw32-wine-gecko mingw64-wine-gecko
Size:96.51 MiB


= UPGRADED PACKAGES =
Package:  ModemManager-1.10.6-2.fc31
Old package:  ModemManager-1.10.4-2.fc31
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 10.69 MiB
Size change:  34.22 KiB
Changelog:
  * Mon Sep 23 2019 Lubomir Rintel  - 1.10.6-1
  - Update to 1.10.6 release

  * Mon Sep 23 2019 Lubomir Rintel  - 1.10.6-2
  - Don't grab cdc_ether devices on Sierra QMI modems


Package:  NetworkManager-openconnect-1.2.6-2.fc31
Old package:  NetworkManager-openconnect-1.2.6-1.fc31
Summary:  NetworkManager VPN plugin for openconnect
RPMs: NetworkManager-openconnect NetworkManager-openconnect-gnome
Size: 2.48 MiB
Size change:  -2.16 KiB
Changelog:
  * Wed Sep 25 2019 David Woodhouse  - 1.2.6-2
  - Fix IPv6 nameserver support (#1753422)


Package:  R-curl-4.1-1.fc31
Old package:  R-curl-4.0-1.fc31
Summary:  A Modern and Flexible Web Client for R
RPMs: R-curl
Size: 2.03 MiB
Size change:  26.73 KiB
Changelog:
  * Wed Sep 18 2019 Elliott Sales de Andrade  - 4.1-1
  - Update to latest version


Package:  R-nycflights13-1.0.1-1.fc31
Old package:  R-nycflights13-1.0.0-3.fc31
Summary:  Flights that Departed NYC in 2013
RPMs: R-nycflights13
Size: 6.80 MiB
Size change:  1.58 KiB
Changelog:
  * Wed Sep 18 2019 Elliott Sales de Andrade  - 
1.0.1-1
  - Update to latest version


Package:  R-pkgdown-1.4.1-1.fc31
Old package:  R-pkgdown-1.4.0-1.fc31
Summary:  Make Static HTML Documentation for a Package
RPMs: R-pkgdown
Size: 511.37 KiB
Size change:  284 B
Changelog:
  * Wed Sep 18 2019 Elliott Sales de Andrade  - 
1.4.1-1
  - Update to latest version


Package:  R-tinytex-0.16-1.fc31
Old package:  R-tinytex-0.15-1.fc31
Summary:  Helper Functions to Install and Maintain 'TeX Live', and Compile 
'LaTeX' Documents
RPMs: R-tinytex
Size: 111.20 KiB
Size change:  204 B
Changelog:
  * Wed Sep 18 2019 Elliott Sales de Andrade  - 
0.16-1
  - Update to latest version


Package:  catfish-1.4.10-1.fc31
Old package:  catfish-1.4.8-2.fc31
Summary:  A handy file search tool
RPMs: catfish
Size: 278.00 KiB
Size change:  33.23 KiB
Changelog:
  * Tue Sep 17 2019 Mamoru TASAKA  - 1.4.10-1
  - 1.4.10


Package:  cockpit-203-1.fc31
Old package:  cockpit-202.1-1.fc31
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc 
cockpit-docker cockpit-kdump cockpit-machines cockpit-networkmanager 
cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport 
cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 16.88 MiB
Size change:  674.97 KiB
Changelog:
  * Wed Sep 18 2019 Marius Vollmer  - 203-1
  - shell: Display message when websocket fails early
  - machines: Implement adding virtual network interfaces


Package:  createrepo_c-0.15.1-1.fc31
Old package:  createrepo_c-0.14.2-2.fc31
Summary:  Creates a common metadata repository
RPMs: createrepo_c createrepo_c-devel createrepo_c-libs 
python3-createrepo_c
Size: 2.79 MiB
Size change:  7.20 KiB
Changelog:
  * Sat Aug 17 2019 Miro Hron??ok  - 0.14.2-3
  - Rebuilt for Python 3.8

  * Tue Sep 17 2019 Ales Matej  - 0.15.1-1
  - Update to 0.15.1
  - Allow pip to see installation of python3-createrepo_c
  - Imporove documentation
  - Switch off timestamping of documentation to avoid file conflics for 
createrepo_c-devel i686/x86_64 parallel installation
  - Remove dependency on deltarpm in favour of drpm


Package:  drpm-0.4.1-1.fc31
Old package:  drpm-0.3.0-19.fc31
Summary:  A library for making, reading and applying deltarpm packages
RPMs: drpm drpm-devel
Size: 1.10 MiB
Size change:  -23.82 KiB
Changelog:
  * Tue Sep 17 2019 Ales Matej  - 0.4.1-1
  - Update to 0.4.1
  - Add support for zstd
  - Fix number of bugs mainly with drpm_make and drpm_apply
  - Relicense to LGPLv2+


Package:  dtc-1.5.1-1.fc31
Old package:  dtc-1.4.7-3.fc30

Fedora-31-20190927.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/152 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20190926.n.0):

ID: 459545  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/459545
ID: 459550  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/459550
ID: 459572  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/459572

Old failures (same test failed in Fedora-31-20190926.n.0):

ID: 459500  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/459500
ID: 459536  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/459536
ID: 459539  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/459539

Soft failed openQA tests: 2/152 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-31-20190926.n.0):

ID: 459513  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/459513
ID: 459615  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/459615

Passed openQA tests: 145/152 (x86_64)

Skipped non-gating openQA tests: 1 of 154

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
1 services(s) added since previous compose: 
dbus-:1.8-org.freedesktop.problems@0.service
  loaded active running dbus-:1.8-org.freedesktop.problems@0.service
1 services(s) removed since previous compose: 
dbus-:1.7-org.freedesktop.problems@0.service
  loaded active running dbus-:1.7-org.freedesktop.problems@0.service
Previous test data: https://openqa.fedoraproject.org/tests/458563#downloads
Current test data: https://openqa.fedoraproject.org/tests/459505#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
1 services(s) added since previous compose: 
dbus-:1.7-org.freedesktop.problems@0.service
  loaded active running dbus-:1.7-org.freedesktop.problems@0.service
1 services(s) removed since previous compose: 
dbus-:1.8-org.freedesktop.problems@0.service
  loaded active running dbus-:1.8-org.freedesktop.problems@0.service
System load changed from 0.67 to 0.25
Previous test data: https://openqa.fedoraproject.org/tests/458565#downloads
Current test data: https://openqa.fedoraproject.org/tests/459507#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
1 services(s) added since previous compose: pcscd.service
System load changed from 1.46 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/458578#downloads
Current test data: https://openqa.fedoraproject.org/tests/459520#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.48 to 0.51
Previous test data: https://openqa.fedoraproject.org/tests/458580#downloads
Current test data: https://openqa.fedoraproject.org/tests/459522#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used swap changed from 4 MiB to 6 MiB
Previous test data: https://openqa.fedoraproject.org/tests/458596#downloads
Current test data: https://openqa.fedoraproject.org/tests/459538#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used swap changed from 4 MiB to 5 MiB
System load changed from 0.61 to 0.43
Average CPU usage changed from 28.51904762 to 4.98571429
Previous test data: https://openqa.fedoraproject.org/tests/458598#downloads
Current test data: https://openqa.fedoraproject.org/tests/459540#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 1.17 to 1.76
Previous test data: https://openqa.fedoraproject.org/tests/458643#downloads
Current test data: https://openqa.fedoraproject.org/tests/459585#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: Question about package module development

[Kevin Kofler]

Coty Sutherland wrote:
> I'm working on (learning modularity) and developing a module for my
> package and created a not-so-great (super long) branch name in the
> dist-git rpm and module repo before I realized that it would be the
> stream's name too. Also, it seems that the incomplete module was picked up
> and included in F31; someone was nice enough to open a BZ and tell me it's
> broken. There are builds associated with the branch, so I probably can't
> delete it outright, but is there a way for me to hide (or something) that
> branch and use the correct one that I just requested? I think that `fedpkg
> retire` is the way to do it, but wanted to ask first since I can't find
> any supporting documentation. Or now that it's been included in F31 am I
> stuck with it (even thought it doesn't work)?

So Modularity will happily unleash experimental branches that were never 
intended to be released onto unsuspecting users of stable releases? How can 
this not be an absolute showstopper? This failed Modularity experiment needs 
to end NOW!

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

Re: Defining the future of the packager workflow in Fedora

[Jeremy Cline]

On Fri, Sep 27, 2019 at 10:57:21AM -0400, Neal Gompa wrote:
> On Fri, Sep 27, 2019 at 9:54 AM Panu Matilainen  wrote:
> >
> > On 9/26/19 10:05 PM, Jeremy Cline wrote:
> > > On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:
> > >> On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> > >>> The combination of these two makes no sense to me. I do plenty of
> > >>> work
> > >>> where I don't want to build it (specfile cleanup, patches,
> > >>> configuration
> > >>> changes, etc.). I want a build that goes to users be explicit.
> > >>>
> > >>> A better model, in my opinion, is to build every *tag*. To do a new
> > >>> kernel build I could make a tag like "kernel-5.4-rc1..." and the tag
> > >>> would be parsed into the specfile's NVR and built.
> > >>
> > >> I agree, and I really like the alternative suggestion here. Some people
> > >> in the thread have talked about how there are often conflicts between
> > >> branches due to the changelog, but the other common reason for
> > >> conflicts is the release field in my experience. If we use tags as an
> > >> explicit "I want this to go to users", then it solves both problems (I
> > >> consider sending all commits to end users a problem, because I often
> > >> make refactor commits that I would not want to churn users on.)
> > >
> > > The tag also provides a nice place to write release notes for the
> > > update. I suppose you could also add support for some sort of text tag
> > > inside commits (like when you mark a commit as fixing an issue in
> > > Git{Lab,Hub} and look at the commits between the new tag and old one so
> > > selective git commits could get sucked into the changelog as well.
> >
> > We've tossed around using tags for builds before in another context, but
> > the idea of tag annotations for populating the user-visible changelog is
> > an interesting and a totally novel idea AFAIK.
> >
> > On top of using tags to, well, tag content for building (it seems so
> > natural nothing could be more natural), we talked about calculating the
> > release number automatically from number of commits on that branch since
> > the last tag. The details seem to largely evade me, but changelog
> > population was planned around picking messages out of git commit
> > messages. Which has its issues. The tag annotations probably has its
> > own, but it's indeed an intriguing idea.
> >
> 
> This was the discussion Igor and I had at the openSUSE Summit in May.
> The unanswered question I had was if we can manipulate the data
> attached to a tag in Pagure UI and edit it after it was initially
> pushed. If annotations are also frozen like all other things in
> Dist-Git, then it fails as a usable mechanism.
> 

Or just make another tag with a newer release number. Of course, that
doesn't work with the auto-generated release number based on
commits-since-last-tag, but to me that's a "nice to have". You could
have it do that if a release isn't specified in the tag, though, so you
could have it all.
___
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 31 Final blocker status email #3

[Ben Cotton]

Action summary


Accepted blockers
-
1. mutter — can't turn zoom off once enabled — NEW
ACTION: upstream to diagnose and fix issue

2. distribution — Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed —
NEW
NEEDINFO: psabata, sgallagh

3. dnf — Revert skip_if_unavailable default back to true — ASSIGNED
ACTION: dnf maintainers to determine how to deliver dnf.conf that
overrides built-in defaults

4. gnome-control-center — Gnome Control Center crashes upon a typo in
Printers settings — NEW
ACTION: upstream to diagnose and fix issue

5. gnome-control-center — Apply button stays gray on Network configuration — NEW
ACTION: upstream to diagnose and fix issue

6. LiveCD — Workstation x86_64 live image is over size target — NEW
ACTION: QA to verify image is under size limit

7. mutter — Keyboard shortcuts NOT mapped to keyboard layouts — NEW
ACTION: upstream to diagnose and fix issue

8. sddm — Cannot start Fedora-KDE-Live (F31) in basic graphics mode on
BIOS machine — NEW
ACTION: QA and other participants to continue trying to isolate the problem

9. selinux-policy — Problem with time syncronization — POST
ACTION: alciregi to verify the problem is fixed in recent composes.


Proposed blockers
-
1. blivet-gui — bios boot partition can't be created at the disk
beginning, if a partition already exists in the middle of the disk —
ASSIGNED
ACTION: maintainer to diagnose and fix issue

2. dnf — dnf: configure_upgrade():
system_upgrade.py:410:configure_upgrade:TypeError: argument of type
'NoneType' is not iterable — MODIFIED
ACTION: QA to verify FEDORA-2019-6a6b241835 fixes the issue

3. gnome-screenshot — screenshots to clipboard don't work, clipboard
doesn't contain any data — NEW
ACTION: upstream to diagnose and fix issue

4. gnome-shell — Automatic workspaces are seriously broken — NEW
BLOCKED BY: https://bugzilla.redhat.com/show_bug.cgi?id=1754867

5. gnome-shell — numlock handling is seriously broken — NEW
ACTION: upstream to diagnose and fix issue

6. python-blivet — blivet unable to use all the usable freespace regions — NEW
ACTION: upstream to evaluate pull request #803

7. gnome-software — GNOME Software doesn't prepare offline updates — NEW
BLOCKED BY: https://bugzilla.redhat.com/show_bug.cgi?id=1752249

8. mutter — gnome-shell crashes when pressing Ctrl+Super in a GTK
application — NEW
ACTION: maintainers to build a new package that contains upstream fix

9. spice-vdagent — VM clipboard integration wipes clipboard contents
randomly and frequently (X11 host) — NEW
ACTION: QA to test if patches in comment 12 fix the issue

10. xorg-x11-server — Gnome Xorg session stuck immediately after login — NEW
NEEDINFO: ajax

Bug-by-bug detail
=

Accepted blockers
-
1. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=1749433 — NEW
can't turn zoom off once enabled

Zoom remains enabled, even after logging out and logging back in.
Issue filed upstream: https://gitlab.gnome.org/GNOME/mutter/issues/826

2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1747408 — NEW
Cannot upgrade to Fedora 31: package
exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires
libgit2.so.28()(64bit), but none of the providers can be installed

Accepted as a blocker by FESCo, even though it does not affect default
package sets. Discussion is ongoing about how to fix this. DNF team
says it's a problem with the modularity spec.

3. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=1752249 — ASSIGNED
Revert skip_if_unavailable default back to true

FESCo requested the default change be reverted before F31 final.
Upstream PR #1484
(https://github.com/rpm-software-management/dnf/pull/1484) enables the
defaults to be changed on a per-distro basis. dnf maintainers are
discussing how to deliver dnf.conf for particular distributions.

4. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=1750394 — NEW
Gnome Control Center crashes upon a typo in Printers settings

Typo in search field (e.g. 'socket>' instead of 'socket:') causes
application to crash. Filed upstream:
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/679

5. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=1750805 — NEW
Apply button stays gray on Network configuration

Wired network connections cannot be configured because the "apply"
button remains inactive. WiFi configuration works. File upstream:
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/677

6. LiveCD — https://bugzilla.redhat.com/show_bug.cgi?id=1751438 — NEW
Workstation x86_64 live image is over size target

Adding podman increased the size of the live image above the specified
maximum. A font pacakge was changed to optional in comps to reduce the
image size: https://pagure.io/fedora-comps/pull-request/414 .
Fedora-31-20190926.n.0 compose appears to be under limit.

7. mutter — htt

Re: Minimization Objective report

[Matthew Miller]

On Wed, Sep 25, 2019 at 05:52:31PM +0200, Adam Samalik wrote:
> == pcre -> pcre2 ==
> Moving grep (one of the last packages using pcre) to pcre2. [4]

Is this a perfectly drop-in compatible replacement from a user point of
view?


-- 
Matthew Miller

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

[Test-Announce] 2019-09-30 @ 16:00 UTC - Fedora 31 Blocker Review Meeting

[Adam Williamson]

# F31 Blocker Review meeting
# Date: 2019-09-30
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 10 proposed Final blockers and 4 proposed Final freeze
exception to review, so let's have a Fedora 31 blocker review meeting
on Monday!

If you have time today, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F31 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] 2019-09-30 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2019-09-30
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet last week and F31 is cranking up, so let's check in on
where we're at.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 31 status
3. Criteria proposals status
4. Test Day / community event status, onboarding call planning
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Question about package module development

[Jun Aruga]

>> Yes, you can hide the branch from the result of "dnf module list". I
>> asked it to someone to hide "private-jaruga-master" stream.
>> But I forget the way.
>
>
> Maybe someone else can help :D

I remembered the way after searching my past emails. :D
You can open a ticket on releng to hide it like this.

Untag modules/ruby stream private-jaruga-master from fedora-modular-30 repo
https://pagure.io/releng/issue/8279

-- 
Jun | He - His - Him
___
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: Defining the future of the packager workflow in Fedora

[Colin Walters]

On Thu, Sep 26, 2019, at 10:24 AM, Pierre-Yves Chibon wrote:

> I like this.
> It means that the build-system would have to generate the tarball of the 
> source
> and put it into dist-git at srpm-build time (I believe we still want to store 
> a
> copy of the sources used for a build).

https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
calls for defining mirrored git repositories as the canonical source - anything 
not stored in git upstream would be imported into git.
___
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: can we merge package.cfg into master

[Sérgio Basto]

On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto 
> wrote:
> > Hi,
> > epel 8 brings a new file called package.cfg, I strongly prefer to
> > keep
> > branches mergeable with fast forward , may we merge this into
> > master ?
> > like I did in pngquant [1]
> > 
> 
> It disables the normal build behavior for all non-master branches, so
> you don't want to do that.

Well , I want keep my branches mergeable ! 


> 
> -- 
> 真実はいつも一つ！/ 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
-- 
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

Help needed with reviewing 2 trivial Golang packages

[Robert-André Mauchin]

Hello,

I have 2 new dependencies for Rclone in needs of a review:

Review Request: golang-github-jzelinskie-whirlpool - Whirlpool cryptographic 
hashing library
https://bugzilla.redhat.com/show_bug.cgi?id=1755566

Review Request: golang-github-putdotio-putio - Put.io Go API client 
https://bugzilla.redhat.com/show_bug.cgi?id=1755569

I'll do any review in exchange.

Thanks!

Robert-André

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

A Gmane NNTP gatway test

[Petr Pisar]

This is a test message, please ignore it. (I'm trying to find out
why my last reply had mangled In-Reply-To header.)

-- Petr
___
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: can we merge package.cfg into master

[Neal Gompa]

On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto  wrote:
>
> Hi,
> epel 8 brings a new file called package.cfg, I strongly prefer to keep
> branches mergeable with fast forward , may we merge this into master ?
> like I did in pngquant [1]
>

It disables the normal build behavior for all non-master branches, so
you don't want to do that.


-- 
真実はいつも一つ！/ 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

can we merge package.cfg into master

[Sérgio Basto]

Hi, 
epel 8 brings a new file called package.cfg, I strongly prefer to keep
branches mergeable with fast forward , may we merge this into master ?
like I did in pngquant [1]

[1]
https://src.fedoraproject.org/rpms/pngquant/commits/master

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

Unresponsive Maintainer: bpereto

[Felix Kaechele via devel]

Hi fellow Fedorans,

I'm trying to contact Benjamin Pereto (FAS: bpereto), maintainer of 
borgbackup and borgmatic.




https://src.fedoraproject.org/user/bpereto

https://src.fedoraproject.org/rpms/borgmatic



I have started the non-responsive maintainer process as borgmatic has 
not seen an update in over a year and is currently suffering from broken 
dependencies and some packaging problems (such as not building for noarch).
I am maintaining an updated and fixed version here: 
https://copr.fedorainfracloud.org/coprs/heffer/borgmatic/


Borgbackup has an active co-maintainer but borgmatic does not.

I filed the corresponding non-responsive maintainer bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=179


If anyone knows how to contact Benjamin, please let me know.
I sent an email to his personal e-mail address about two months ago but 
received no response.


Regards,
Felix
___
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: Major update to LLVM appearing in F31 without any communication, appears to violate update policy

[Adam Williamson]

On Fri, 2019-09-27 at 08:50 -0700, Tom Stellard wrote:
> 
> The LLVM update has the necessary karma now and all the gating tests
> have passed.  Should I push this to stable now and then push the mesa
> update later or should we still try to combine the updates?

You can push LLVM and then mesa, it should be fine.
-- 
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: Major update to LLVM appearing in F31 without any communication, appears to violate update policy

[Pete Walter]

27.09.2019, 16:51, "Tom Stellard" :
> The LLVM update has the necessary karma now and all the gating tests
> have passed. Should I push this to stable now and then push the mesa
> update later or should we still try to combine the updates?

Yes, go for it and push it to stable. I'll submit mesa to stable after you've 
submitted llvm so they end up going out at the same time.

Thanks,
Pete
___
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: Major update to LLVM appearing in F31 without any communication, appears to violate update policy

[Martin Kolman]

On Thu, 2019-09-26 at 13:21 -0700, Adam Williamson wrote:
> On Thu, 2019-09-26 at 20:55 +0200, Hans de Goede wrote:
> > Hi Tom,
> > 
> > On 26-09-2019 20:47, Tom Stellard wrote:
> > > On 09/26/2019 11:24 AM, Adam Williamson wrote:
> > > > On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
> > > > > On 09/26/2019 11:03 AM, Adam Williamson wrote:
> > > > > > We are currently in the "Beta to Pre Release" phase of the release
> > > > > > cycle. The updates policy for this phase -
> > > > > > https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
> > > > > > says:
> > > > > > 
> > > > > > "From this point onwards maintainers MUST[1]:
> > > > > > 
> > > > > >  Avoid Major version updates, ABI breakage or API changes if at 
> > > > > > all
> > > > > > possible."
> > > > > > 
> > > > > > However, it seems a major new release of LLVM is appearing in F31 at
> > > > > > present, and AFAIK there has been no discussion or communication 
> > > > > > about
> > > > > > this at all.
> > > > > > 
> > > > > > LLVM 9 is currently in the buildroot, and an update with a very 
> > > > > > short
> > > > > > description has been submitted:
> > > > > > 
> > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-b83bd6b46c
> > > > > > 
> > > > > > (it just says "Update for LLVM 9 rebase.", which is odd since it 
> > > > > > *is*
> > > > > > the LLVM 9 rebase).
> > > > > > 
> > > > > > There is no Change for this, I can't find a mail about it anywhere,
> > > > > > it's just been sort of dumped in. Is there enough grounds for 
> > > > > > dumping
> > > > > > in a major new LLVM and violating the update policy at this point in
> > > > > > the F31 release?
> > > > > > 
> > > > > 
> > > > > There are compatibility packages included in the update, so there 
> > > > > should not
> > > > > be any ABI breakage from this update.  Also, what exactly is the main
> > > > > issue right now?  Is it the buildroot overrides?
> > > > 
> > > > This is what caused me to notice it, yes. Another update got built
> > > > against LLVM 9 because it was in the buildroot, which means that update
> > > > is now not installable without the LLVM 9 update:
> > > > 
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-52ecb9952b
> > > > 
> > > > openQA caught this, which put me onto the change.
> > > > 
> > > 
> > > Ok, what's the best way to resolve this issue?  Do you want me to
> > > cancel the update and overrides and re-submit after f31-final is out?
> 
> If there's a sufficient justification for including LLVM 9, we still
> can. I just wanted to flag up that it was happening and that it
> *shouldn't* happen without sufficient justification, and probably
> without more communication about it. Like, a mail to devel@ "hold onto
> your hats, we're going to upgrade llvm in f31 because X, Y, Z" would've
> helped.
> 
> > If I understand things correctly, there are currently separate
> > mesa and llvm updates for this in bodhi?  That is never a good
> > idea when there are ABI dependencies between 2 updates, bodhi does
> > allow you to add multiple builds in a single update.
> > 
> > So my 2 cents is that it would be best to cancel the separate
> > llvm bodhi update and add the llvm build to the mesa update, then
> > the update will be self contained / cleanly apply to current F31 stable.
> 
> So far as resolving this issue goes, the llvm update has like 11
> packages in it, the mesa update has 1. So it would make a deal more
> sense to unpush the *mesa* update and add a mesa build to the llvm
> update.
> 
> Note that Bodhi will not let you add a package to two updates - even if
> one of them is unpushed - so to get the exact same mesa build in an
> update you would need help from someone with superpowers who could go
> do nasty things in the database to override this. The easier trick is
> simply to bump and rebuild mesa with no changes, and add *that* mesa
> build to the llvm update.
AFAIK, there is also still a further potentially relevant Bodhi limitation, 
that you need to be on the maintainer list for all the packages you are adding 
to a Bodhi update.

So if maintainer A is only maintainer of LLVM and maintainer B is only 
maintainer
of mesa, they will not be able to put their packages into a single Bodhi update
themselves and will also have to ask a proven packages to do it. The resulting 
update
will also get "tainted" by this, rejecting any further changes from non-proven 
packagers.

(I really hope we can get at least this one fixed already. :P)

> 
> You *could* also just leave them separate so long as you make sure not
> to push the mesa update stable before the llvm one. It is better to get
> this right in the first place and put all the packages into one update,
> but if you wind up with them separate and are careful about the push
> order it won't cause any huge problems (it just causes things like
> openQA test failures that attract angry QA people :>)
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw

Re: Major update to LLVM appearing in F31 without any communication, appears to violate update policy

[Tom Stellard]

On 09/26/2019 01:21 PM, Adam Williamson wrote:
> On Thu, 2019-09-26 at 20:55 +0200, Hans de Goede wrote:
>> Hi Tom,
>>
>> On 26-09-2019 20:47, Tom Stellard wrote:
>>> On 09/26/2019 11:24 AM, Adam Williamson wrote:
 On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
> On 09/26/2019 11:03 AM, Adam Williamson wrote:
>> We are currently in the "Beta to Pre Release" phase of the release
>> cycle. The updates policy for this phase -
>> https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
>> says:
>>
>> "From this point onwards maintainers MUST[1]:
>>
>>  Avoid Major version updates, ABI breakage or API changes if at all
>> possible."
>>
>> However, it seems a major new release of LLVM is appearing in F31 at
>> present, and AFAIK there has been no discussion or communication about
>> this at all.
>>
>> LLVM 9 is currently in the buildroot, and an update with a very short
>> description has been submitted:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-b83bd6b46c
>>
>> (it just says "Update for LLVM 9 rebase.", which is odd since it *is*
>> the LLVM 9 rebase).
>>
>> There is no Change for this, I can't find a mail about it anywhere,
>> it's just been sort of dumped in. Is there enough grounds for dumping
>> in a major new LLVM and violating the update policy at this point in
>> the F31 release?
>>
>
> There are compatibility packages included in the update, so there should 
> not
> be any ABI breakage from this update.  Also, what exactly is the main
> issue right now?  Is it the buildroot overrides?

 This is what caused me to notice it, yes. Another update got built
 against LLVM 9 because it was in the buildroot, which means that update
 is now not installable without the LLVM 9 update:

 https://bodhi.fedoraproject.org/updates/FEDORA-2019-52ecb9952b

 openQA caught this, which put me onto the change.

>>>
>>> Ok, what's the best way to resolve this issue?  Do you want me to
>>> cancel the update and overrides and re-submit after f31-final is out?
> 
> If there's a sufficient justification for including LLVM 9, we still
> can. I just wanted to flag up that it was happening and that it
> *shouldn't* happen without sufficient justification, and probably
> without more communication about it. Like, a mail to devel@ "hold onto
> your hats, we're going to upgrade llvm in f31 because X, Y, Z" would've
> helped.
> 
>> If I understand things correctly, there are currently separate
>> mesa and llvm updates for this in bodhi?  That is never a good
>> idea when there are ABI dependencies between 2 updates, bodhi does
>> allow you to add multiple builds in a single update.
>>
>> So my 2 cents is that it would be best to cancel the separate
>> llvm bodhi update and add the llvm build to the mesa update, then
>> the update will be self contained / cleanly apply to current F31 stable.
> 
> So far as resolving this issue goes, the llvm update has like 11
> packages in it, the mesa update has 1. So it would make a deal more
> sense to unpush the *mesa* update and add a mesa build to the llvm
> update.
> 
> Note that Bodhi will not let you add a package to two updates - even if
> one of them is unpushed - so to get the exact same mesa build in an
> update you would need help from someone with superpowers who could go
> do nasty things in the database to override this. The easier trick is
> simply to bump and rebuild mesa with no changes, and add *that* mesa
> build to the llvm update.
> 
> You *could* also just leave them separate so long as you make sure not
> to push the mesa update stable before the llvm one. It is better to get
> this right in the first place and put all the packages into one update,
> but if you wind up with them separate and are careful about the push
> order it won't cause any huge problems (it just causes things like
> openQA test failures that attract angry QA people :>)
> 

The LLVM update has the necessary karma now and all the gating tests
have passed.  Should I push this to stable now and then push the mesa
update later or should we still try to combine the updates?

-Tom

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

Re: Defining the future of the packager workflow in Fedora

[Randy Barlow]

On Fri, 2019-09-27 at 10:26 +0200, Michal Konecny wrote:
> There is still possibility to use libraries.io 
> instead of Anitya, but there are some issues:
> - lack of downstream mapping (this could be easily solved by some 
> database with only downstream mapping)
> - lack of custom project additions (libraries.io can only watch
> projects 
> in sources they have already implemented)

libraries.io is open source:

https://github.com/librariesio

It would be good to work with them to add these features there, rather
than to make our own database with the downstream mapping. This way all
distros can benefit, and we also don't have to do all the work of
creating and maintaining our own project.


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

dogpile.cache has switched to the MIT license

[Randy Barlow]

I am updating dogpile.cache to 0.8.0 on Rawhide, and it has switched
from BSD to MIT:

https://github.com/sqlalchemy/dogpile.cache/commit/474a9a329f86e4c2d1cdf6e35e346979c9dd07c6
https://src.fedoraproject.org/rpms/python-dogpile-cache/c/b6bac12befdace274a1c21a215fc2e9a1236da0a?branch=master


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

Re: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Daniel P . Berrangé]

On Fri, Sep 27, 2019 at 10:53:32AM -0400, Neal Gompa wrote:
> On Fri, Sep 27, 2019 at 8:30 AM Daniel P. Berrangé  
> wrote:
> >
> > On Fri, Sep 27, 2019 at 01:26:09PM +0200, Jun Aruga wrote:
> > > > Does anyone know of, or have, any critical/important use cases that 
> > > > would
> > > be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
> > > here & I can forward feedback on. Or feel free to go direct to QEMU thread
> > > upstream.
> > >
> > > I am not a real user of ARM 32-bit. I just checked information for ARM
> > > 32-bit (armv7) use cases.
> > >
> > > ## Raspberry Pi
> > >
> > > > https://en.wikipedia.org/wiki/Raspberry_Pi
> > > > The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 
> > > > SoC with a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 
> > > > KB shared L2 cache.
> > > >
> > > > https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/
> > >
> > > It seems that the version 1.1 is the last model for 32-bit, and the
> > > announcement was 5 August 2015.
> > > I assume a considerable number of people using ARM 32-bit Raspberry Pi.
> >
> > Right, but I'm rather sceptical that people are running QEMU on the
> > 32-bit RPi boards. I might be less surprised about the Linux userspace
> > emulation being used, vs full VM, since the former is lower overhead.
> >
> >
> 
> Sorry to burst your bubble, but since the Raspberry Pi performs quite
> badly as a 64-bit device for the moment, I've used it with Fedora
> armv7hl instead of aarch64. I personally use the user emulation
> mostly, but I know of a couple of cases where system emulation is used
> (mainly for buildsys stuff).

Interesting, is there a particular reason why you run the emulation on
a Pi, as opposed to using more powerful x86 hardware for it ?  I'm not
saying you're wrong todo this, just trying to understand the motivation
people have.

Regards,
Daniel
-- 
|: 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

Re: Defining the future of the packager workflow in Fedora

[Neal Gompa]

On Fri, Sep 27, 2019 at 9:54 AM Panu Matilainen  wrote:
>
> On 9/26/19 10:05 PM, Jeremy Cline wrote:
> > On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:
> >> On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> >>> The combination of these two makes no sense to me. I do plenty of
> >>> work
> >>> where I don't want to build it (specfile cleanup, patches,
> >>> configuration
> >>> changes, etc.). I want a build that goes to users be explicit.
> >>>
> >>> A better model, in my opinion, is to build every *tag*. To do a new
> >>> kernel build I could make a tag like "kernel-5.4-rc1..." and the tag
> >>> would be parsed into the specfile's NVR and built.
> >>
> >> I agree, and I really like the alternative suggestion here. Some people
> >> in the thread have talked about how there are often conflicts between
> >> branches due to the changelog, but the other common reason for
> >> conflicts is the release field in my experience. If we use tags as an
> >> explicit "I want this to go to users", then it solves both problems (I
> >> consider sending all commits to end users a problem, because I often
> >> make refactor commits that I would not want to churn users on.)
> >
> > The tag also provides a nice place to write release notes for the
> > update. I suppose you could also add support for some sort of text tag
> > inside commits (like when you mark a commit as fixing an issue in
> > Git{Lab,Hub} and look at the commits between the new tag and old one so
> > selective git commits could get sucked into the changelog as well.
>
> We've tossed around using tags for builds before in another context, but
> the idea of tag annotations for populating the user-visible changelog is
> an interesting and a totally novel idea AFAIK.
>
> On top of using tags to, well, tag content for building (it seems so
> natural nothing could be more natural), we talked about calculating the
> release number automatically from number of commits on that branch since
> the last tag. The details seem to largely evade me, but changelog
> population was planned around picking messages out of git commit
> messages. Which has its issues. The tag annotations probably has its
> own, but it's indeed an intriguing idea.
>

This was the discussion Igor and I had at the openSUSE Summit in May.
The unanswered question I had was if we can manipulate the data
attached to a tag in Pagure UI and edit it after it was initially
pushed. If annotations are also frozen like all other things in
Dist-Git, then it fails as a usable mechanism.

> In fact it was that discussion which prompted the development of
> automatic patch numbering and %patchlist support in spec files in rpm
> 4.15, since in the planned scheme merge conflicts on release number and
> changelog would be gone, and conflicts on patch numbers was identified
> as yet another redundant piece of data that's also often prone to
> unnecessary merge conflicts.
>
> The %changelog in specs really, really needs to die.
>

I would actually say that the spec in the SRPM should contain the
changelog, so that repeating the build from the exploded contents is
possible. But yes, it'd be nice if it wasn't there in the specs in
Git.


-- 
真実はいつも一つ！/ 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Neal Gompa]

On Fri, Sep 27, 2019 at 8:30 AM Daniel P. Berrangé  wrote:
>
> On Fri, Sep 27, 2019 at 01:26:09PM +0200, Jun Aruga wrote:
> > > Does anyone know of, or have, any critical/important use cases that would
> > be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
> > here & I can forward feedback on. Or feel free to go direct to QEMU thread
> > upstream.
> >
> > I am not a real user of ARM 32-bit. I just checked information for ARM
> > 32-bit (armv7) use cases.
> >
> > ## Raspberry Pi
> >
> > > https://en.wikipedia.org/wiki/Raspberry_Pi
> > > The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 SoC 
> > > with a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 KB 
> > > shared L2 cache.
> > >
> > > https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/
> >
> > It seems that the version 1.1 is the last model for 32-bit, and the
> > announcement was 5 August 2015.
> > I assume a considerable number of people using ARM 32-bit Raspberry Pi.
>
> Right, but I'm rather sceptical that people are running QEMU on the
> 32-bit RPi boards. I might be less surprised about the Linux userspace
> emulation being used, vs full VM, since the former is lower overhead.
>
>

Sorry to burst your bubble, but since the Raspberry Pi performs quite
badly as a 64-bit device for the moment, I've used it with Fedora
armv7hl instead of aarch64. I personally use the user emulation
mostly, but I know of a couple of cases where system emulation is used
(mainly for buildsys stuff).

> > ## Running Linux on smart phone device.
> >
> > Some articles about it.
> >
> > * 
> > https://developers.redhat.com/blog/2017/03/16/installing-linux-on-an-android-phone/
> > * https://www.quora.com/How-can-I-install-Fedora-on-my-smartphone
>
> Perhaps I'm wrong, but I got the impression most mid range & above Android
> phones are now 64-bit ARM.
>

They are.

> > > https://android.stackexchange.com/a/202022
> >
> > ARMv7 (32-bit) was 98.1% in entire share of android hardware on March 2017.
>
> I think things changed alot in smartphones over the last two years,
> though admittedly my experiance is biased towards my part of the world.
>
>

ARMv7 still dominates by a wide margin outside of North America,
Western Europe, Japan, and Australia.

> > > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06216.html
> > > Eventually this public don't need edge QEMU, it might keep using QEMU
> > v5.0.stable until all NAS/embedded devices are 64-bit...
> >
> > For example, how about releasing compat-qemu50 RPM if upstream will
> > drop armv7 on qemu 6.x?
> > It's like compat-openssl10 RPM for openssl (version 1.1) RPM.
> >
> > Maybe if some RPM packages need armv7 support, they can use
> > compat-qemu50 conditionally in the spec file.
>
> I'd be pretty strongly against providing any outdated QEMU builds in
> Fedora given the high frequency of security updates that need to be
> dealt with.

I agree here. It's probably just better to convince upstream to not
drop 32-bit host support.



-- 
真実はいつも一つ！/ 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: Question about package module development

[Coty Sutherland]

Thanks for responding!

On Fri, Sep 27, 2019 at 8:54 AM Jun Aruga  wrote:

> > I'm working on (learning modularity) and developing a module for my
> package and created a not-so-great (super long) branch name in the dist-git
> rpm and module repo before I realized that it would be the stream's name
> too.
>
> I faced similar situation. Ruby module was released as
> "private-jaruga-master" stream.
> Now the branch is empty, as we can not delete it.
> https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master


It appears that you retired the branch, which is what I was thinking of
doing.


>
>
> > Also, it seems that the incomplete module was picked up and included in
> F31
>
> Policy Decision: In-development streams
> https://pagure.io/modularity/issue/156#comment-600856
>
> Right now "master", "devel" and "rolling" stream names are used to
> test a module before releasing version "X.Y" stream.
> it's unofficial way. There is a discussion about it on above URL.
>

Thanks for that tip, I'll use the master branch for now then.


>
> > someone was nice enough to open a BZ and tell me it's broken.
>
> Agree. Some checks before releasing are useful.
>
> > but is there a way for me to hide (or something) that branch and use the
> correct one that I just requested?
>
> Yes, you can hide the branch from the result of "dnf module list". I
> asked it to someone to hide "private-jaruga-master" stream.
> But I forget the way.
>

Maybe someone else can help :D


>
> > but wanted to ask first since I can't find any supporting documentation.
> Or now that it's been included in F31 am I stuck with it (even thought it
> doesn't work)?
>
> This is the documentation. But I do not think it is covering your concerns.
> https://docs.fedoraproject.org/en-US/modularity/making-modules/


Yeah, I've already read that a few times, but there's nothing about removal.


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


-- 

Coty Sutherland, RHCSA, RHCE, JBCAA

Senior Software Engineer

Red Hat 

c...@redhat.com
@RedHat    Red Hat
  Red Hat


___
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: Unresponsive maintainer: Hannes Frederic Sowa

[Jiri Hladky]

No problem! Thanks for the quick resolution:-)

Jirka

On Fri, Sep 27, 2019 at 3:29 PM Hannes Frederic Sowa <
han...@stressinduktion.org> wrote:

> Hello,
>
> On Fri, Sep 27, 2019, at 11:21, Miro Hrončok wrote:
> > On 27. 09. 19 11:07, Jiri Hladky wrote:
> > > Hello Hannes,
> > >
> > > thanks for the quick response! I'm happy to take over the datamash
> package.
> > >
> > > Could you please give the admin rights by going to
> > > https://src.fedoraproject.org/rpms/datamash
> > > Settings -> Users & Groups -> Add User
> >
> > Or even
> >
> > Settings -> Give Project
> >
> > Jiri's username is jhladky.
>
> Done. Thanks for taking over!
>
> Hannes
>
___
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: Defining the future of the packager workflow in Fedora

[Martin Kolman]

On Fri, 2019-09-27 at 00:20 +0200, Dan Čermák wrote:
> Randy Barlow  writes:
> 
> > This suggestion gives a nice clean place to write the bodhi update
> > description, right in git. The commit messages can remain the way they
> > are today: authored for the audience of spec file contributors.
> > 
> > We could also support special syntax in the tag message to allow people
> > to specify the various bodhi update fields (severity, karma
> > requirements, whatever else) if they want to do that that way.
> 
> I *really* like this idea, as one could still push multiple
> "development" commits to git, but until one tags something, nothing is
> built & released.
And there is even at least one precendent, where Git tags are used to trigger
some process - the GitHub releases, that list all tags & provide archives for 
them.

So it seems like a sensible & already proven idea.

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

plplot soname bump in rawhide

[Orion Poplawski]

I will be updating plplot to 5.15.0 soon in rawhide.  This is a soname 
bump.  I will rebuild the 3 dependent packages:


gdl
psfex
scamp

Test builds here 
https://copr.fedorainfracloud.org/coprs/orion/plplot/builds/ mostly 
worked (despite some copr infrastructure failures)


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: Defining the future of the packager workflow in Fedora

[Panu Matilainen]

On 9/26/19 10:05 PM, Jeremy Cline wrote:

On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:

On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:

The combination of these two makes no sense to me. I do plenty of
work
where I don't want to build it (specfile cleanup, patches,
configuration
changes, etc.). I want a build that goes to users be explicit.

A better model, in my opinion, is to build every *tag*. To do a new
kernel build I could make a tag like "kernel-5.4-rc1..." and the tag
would be parsed into the specfile's NVR and built.


I agree, and I really like the alternative suggestion here. Some people
in the thread have talked about how there are often conflicts between
branches due to the changelog, but the other common reason for
conflicts is the release field in my experience. If we use tags as an
explicit "I want this to go to users", then it solves both problems (I
consider sending all commits to end users a problem, because I often
make refactor commits that I would not want to churn users on.)


The tag also provides a nice place to write release notes for the
update. I suppose you could also add support for some sort of text tag
inside commits (like when you mark a commit as fixing an issue in
Git{Lab,Hub} and look at the commits between the new tag and old one so
selective git commits could get sucked into the changelog as well.


We've tossed around using tags for builds before in another context, but 
the idea of tag annotations for populating the user-visible changelog is 
an interesting and a totally novel idea AFAIK.


On top of using tags to, well, tag content for building (it seems so 
natural nothing could be more natural), we talked about calculating the 
release number automatically from number of commits on that branch since 
the last tag. The details seem to largely evade me, but changelog 
population was planned around picking messages out of git commit 
messages. Which has its issues. The tag annotations probably has its 
own, but it's indeed an intriguing idea.


In fact it was that discussion which prompted the development of 
automatic patch numbering and %patchlist support in spec files in rpm 
4.15, since in the planned scheme merge conflicts on release number and 
changelog would be gone, and conflicts on patch numbers was identified 
as yet another redundant piece of data that's also often prone to 
unnecessary merge conflicts.


The %changelog in specs really, really needs to die.

- Panu -
___
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: Unresponsive maintainer: Hannes Frederic Sowa

[Hannes Frederic Sowa]

Hello,

On Fri, Sep 27, 2019, at 11:21, Miro Hrončok wrote:
> On 27. 09. 19 11:07, Jiri Hladky wrote:
> > Hello Hannes,
> > 
> > thanks for the quick response! I'm happy to take over the datamash package.
> > 
> > Could you please give the admin rights by going to
> > https://src.fedoraproject.org/rpms/datamash
> > Settings -> Users & Groups -> Add User
> 
> Or even
> 
> Settings -> Give Project
> 
> Jiri's username is jhladky.

Done. Thanks for taking over!

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

CPE Team Weekly Update

[Aoife Moloney]

Hi everyone,

I’d like to introduce myself first, my name is Aoife Moloney and I recently
started with the Community Platform Engineering (CPE) team. My role within
this team is going to be a hybrid role of a Product Owner / Project Manager.

As part of that, I want to send a weekly update to the lists to give an
insight into what the CPE team have worked on over the past week or so.
This will also be mirrored as a higher level blog to give maximum
visibility.

We, as a team, welcome your input and comments and please do let us know
how we can improve this community facing information segment!

As you know, the CPE team looks after interests in both Fedora and CentOS,
so this update is also going to include work done on areas that are not
your Community, but for transparency, we are including it :)


High Level Project Updates:

Fedora:

Rawhide Gating:  


   -

   First work around merging side tags has been completed
   -

  Open PR  that needs
  to be finished
  -

   We need to update our staging environment which broke when we branched
   F31 in production:
   -

  Tracked in: https://pagure.io/releng/issue/8838
  -

  Koji stuck/full: https://pagure.io/fedora-infrastructure/issue/8240
  -

   Overview page of the remaining blockers and dependencies organized at:
   -

  https://hackmd.io/Gbuu9JOPR--Y2yNCBEYI5A?view
  -

 Input welcome for anything that would be missing
 -

  https://github.com/fedora-infra/bodhi/projects/3
  -

 High priority items in the “Ready” column are all hard-dependency
 for pushing multi-builds to production


repoSpanner 


   -

   Race condition discovered has been fixed and tested
   -

   Test suite has a number of issues which are being triaged and worked
   through at the moment
   -

   Performance testing is next on our agenda


Application Retirements


   -

   Badges has had some further conversations with community members and we
   are aligning on a handover date
   -

   Packagedb-cli is being retired this week
   -

   Documentation for onboarding contributors to Community OpenShift was
   started with a good mail thread on Fedora Devel
   -

   Pastebin: Ongoing conversations with future maintainer, expecting an
   update in the next 2 weeks
   -

   Elections: Ben Cotton is taking this over and the CPE team are assisting
   with moving this to Communishift
   -

   Fedocal still needs your help, we need a Maintainer here urgently
   -

  If no one steps up by October 15th, we will be looking at
  decommissioning it!
  -

   Nuancier, we possibly have identified a maintainer here and the team are
   engaging in a conversation



Misc highlights from various parts of the ecosystem:


   -

   FPDC had some light work on it, an instance of Kinto (
   http://docs.kinto-storage.org/en/stable/) was deployed in staging at
   https://fpdc.stg.fedoraproject.org/v1/
   -

   Fedora Container base image update for F30, F31 and F32. (Dockerhub
   https://github.com/docker-library/official-images/pull/6702,
   Registry.fp.o https://pagure.io/releng/issue/8846)
   -

   Rawhide compose failures, due to podman gating, filed
   https://github.com/fedora-infra/bodhi/issues/3512 on it
   -

   Announced F31 Beta freeze over, adjusted thing
   -

   F31 Beta saw the team help in various places, everything went smoothly!
   -

   Fixed pagure stunnel to use tls1.1/1.2 and a valid cert
   https://pagure.io/fedora-infrastructure/issue/8231
   -

   Fixed pagure event server to use valid cert with intermediate:
   https://pagure.io/fedora-infrastructure/issue/8224
   -

   Mdapi app fully moved to OpenShift:
   https://pagure.io/fedora-infrastructure/issue/8238
   -

   Branched versioned Fedora docs for F31
   -

   Worked on updates to Fedora contributor docs
   -

   Progressing more fedmsg → fedora messaging conversions on our scripting
   -

   Fixed the Koji rpm.sign fedora-messaging message (
   https://pagure.io/fedora-infrastructure/issue/8158)
   -


CentOS:


   -

   CentOS 8 was released this week :)
   -

  Core artifacts (repos and install media) were refreshed and sent to
  the mirrors
  -

  CentOS Stream was built and staged
  -

  Cloud and Container images are outstanding, coming up next
  -

  Sources and debuginfo content synced to the mirrors
  -

  Armhfp enablement coming soon
  -

   Activities related to releasing CentOS 7.7 (17-September) and
   subsequently CentOS 8 (24-September) consumed the entire teams time!


-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
devel mailing list -- devel@lists.fedoraproj

Re: Question about package module development

[Jun Aruga]

> I'm working on (learning modularity) and developing a module for my package 
> and created a not-so-great (super long) branch name in the dist-git rpm and 
> module repo before I realized that it would be the stream's name too.

I faced similar situation. Ruby module was released as
"private-jaruga-master" stream.
Now the branch is empty, as we can not delete it.
https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master

> Also, it seems that the incomplete module was picked up and included in F31

Policy Decision: In-development streams
https://pagure.io/modularity/issue/156#comment-600856

Right now "master", "devel" and "rolling" stream names are used to
test a module before releasing version "X.Y" stream.
it's unofficial way. There is a discussion about it on above URL.

> someone was nice enough to open a BZ and tell me it's broken.

Agree. Some checks before releasing are useful.

> but is there a way for me to hide (or something) that branch and use the 
> correct one that I just requested?

Yes, you can hide the branch from the result of "dnf module list". I
asked it to someone to hide "private-jaruga-master" stream.
But I forget the way.

> but wanted to ask first since I can't find any supporting documentation. Or 
> now that it's been included in F31 am I stuck with it (even thought it 
> doesn't work)?

This is the documentation. But I do not think it is covering your concerns.
https://docs.fedoraproject.org/en-US/modularity/making-modules/

--
Jun
___
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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Daniel P . Berrangé]

On Fri, Sep 27, 2019 at 01:26:09PM +0200, Jun Aruga wrote:
> > Does anyone know of, or have, any critical/important use cases that would
> be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
> here & I can forward feedback on. Or feel free to go direct to QEMU thread
> upstream.
> 
> I am not a real user of ARM 32-bit. I just checked information for ARM
> 32-bit (armv7) use cases.
> 
> ## Raspberry Pi
> 
> > https://en.wikipedia.org/wiki/Raspberry_Pi
> > The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 SoC 
> > with a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 KB 
> > shared L2 cache.
> >
> > https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/
> 
> It seems that the version 1.1 is the last model for 32-bit, and the
> announcement was 5 August 2015.
> I assume a considerable number of people using ARM 32-bit Raspberry Pi.

Right, but I'm rather sceptical that people are running QEMU on the
32-bit RPi boards. I might be less surprised about the Linux userspace
emulation being used, vs full VM, since the former is lower overhead.


> ## Running Linux on smart phone device.
> 
> Some articles about it.
> 
> * 
> https://developers.redhat.com/blog/2017/03/16/installing-linux-on-an-android-phone/
> * https://www.quora.com/How-can-I-install-Fedora-on-my-smartphone

Perhaps I'm wrong, but I got the impression most mid range & above Android
phones are now 64-bit ARM.

> > https://android.stackexchange.com/a/202022
> 
> ARMv7 (32-bit) was 98.1% in entire share of android hardware on March 2017.

I think things changed alot in smartphones over the last two years,
though admittedly my experiance is biased towards my part of the world.


> > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06216.html
> > Eventually this public don't need edge QEMU, it might keep using QEMU
> v5.0.stable until all NAS/embedded devices are 64-bit...
> 
> For example, how about releasing compat-qemu50 RPM if upstream will
> drop armv7 on qemu 6.x?
> It's like compat-openssl10 RPM for openssl (version 1.1) RPM.
> 
> Maybe if some RPM packages need armv7 support, they can use
> compat-qemu50 conditionally in the spec file.

I'd be pretty strongly against providing any outdated QEMU builds in
Fedora given the high frequency of security updates that need to be
dealt with.

Regards,
Daniel
-- 
|: 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

Re: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Jun Aruga]

> For example, how about releasing compat-qemu50 RPM if upstream will
> drop armv7 on qemu 6.x?
> It's like compat-openssl10 RPM for openssl (version 1.1) RPM.
>
> Maybe if some RPM packages need armv7 support, they can use
> compat-qemu50 conditionally in the spec file.

Sorry. Typo.

s/compat-qemu50/compat-qemu5/

Jun
___
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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Jun Aruga]

> Does anyone know of, or have, any critical/important use cases that would
be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
here & I can forward feedback on. Or feel free to go direct to QEMU thread
upstream.

I am not a real user of ARM 32-bit. I just checked information for ARM
32-bit (armv7) use cases.

## Raspberry Pi

> https://en.wikipedia.org/wiki/Raspberry_Pi
> The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 SoC with 
> a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 KB shared L2 
> cache.
>
> https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/

It seems that the version 1.1 is the last model for 32-bit, and the
announcement was 5 August 2015.
I assume a considerable number of people using ARM 32-bit Raspberry Pi.

## Running Linux on smart phone device.

Some articles about it.

* 
https://developers.redhat.com/blog/2017/03/16/installing-linux-on-an-android-phone/
* https://www.quora.com/How-can-I-install-Fedora-on-my-smartphone

> https://android.stackexchange.com/a/202022

ARMv7 (32-bit) was 98.1% in entire share of android hardware on March 2017.

> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06216.html
> Eventually this public don't need edge QEMU, it might keep using QEMU
v5.0.stable until all NAS/embedded devices are 64-bit...

For example, how about releasing compat-qemu50 RPM if upstream will
drop armv7 on qemu 6.x?
It's like compat-openssl10 RPM for openssl (version 1.1) RPM.

Maybe if some RPM packages need armv7 support, they can use
compat-qemu50 conditionally in the spec file.

Jun
___
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: Defining the future of the packager workflow in Fedora

[Daniel P . Berrangé]

On Fri, Sep 27, 2019 at 12:40:42PM +0200, Martin Kolman wrote:
> On Thu, 2019-09-26 at 16:24 +0200, Pierre-Yves Chibon wrote:
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> > > > Good Morning Everyone,
> > > > 
> > > > At Flock, a few of us met to discuss a future vision of the packager 
> > > > workflow.
> > > > This discussion was triggered by the realization that a number of 
> > > > initiatives
> > > > are happening around packaging in Fedora but there is no real shared 
> > > > vision on
> > > > what we want the packager UX/workflow to be.
> > > > The lack of vision on the packager workflow means we could deploy 
> > > > something
> > > > today, thinking it is the improvement over the current workflow but 
> > > > would
> > > > prevent us from (or make it harder to) doing other changes afterwords 
> > > > that would
> > > > be even more beneficial..
> > > > 
> > > > So once that concern was raised, we took some time during the Fedora
> > > > Infrastructure hackfest to gather the people interested around a white 
> > > > board and
> > > > brainstorm on what a future packager workflow could look like.
> > > > 
> > > > We tried not to link this process to any tool in particular as well as 
> > > > focus on
> > > > the what and why rather than any how.
> > > > 
> > > > Here is what the vision we came to and that we would like to discuss:
> > > > 
> > > > ○ Every changes to dist-git is done via pull-requests
> > > > ○ Pull-requests are automatically tested
> > > > ○ Every commit to dist-git (ie: PR merged) is automatically built in 
> > > > koji
> > > > ○ Every build in koji results automatically in an update in bodhi
> > > > ○ Every update in bodhi is automatically tested
> > > > ○ If the tests pass, the update is automatically pushed to the 
> > > > repository
> > > 
> > > For packages I maintain, my preference is to touch dist-git as little
> > > as possible. Ideally I would never touch dist-git at all & rather wish
> > > it didn't exist at all in its current form of spec+patchfiles.
> > > 
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > branch with patches cherry-picked into it. This is used to auto-generate
> > > patches for the Fedora RPM, at the same time updating the patch file list
> > > in the RPM spec. The only manual step is adding the changelog entry &
> > > bumping release number.
> > > 
> > > The ideas above around associating CI with pull requests make a lot of
> > > conceptual sense & align with modern github/gitlab software development
> > > best practices followed by non-distro software upstreams. Automatically
> > > triggering builds from merged PRs similarly makes sense, especially
> > > if that can automate bumping spec release number & adding a changelog
> > > entry based on the pull request subject.
> > > 
> > > 
> > > Obviously I can still use my upstream git repo branch and change the
> > > scripts to generate a pull request to dist-git instead.  The downside
> > > is if the PR fails, I now how to rebase my real git repo & re-submit
> > > and new PR.
> > > 
> > > So if we're talking "ideal" long term vision though, I'd rather eliminate
> > > the dist-git repo intermediate step as IMHO it adds no value, only 
> > > complexity
> > > for the sake of historical compat with the way Red Hat distros has worked
> > > dating back years. Its time to say goodbye to this historical way as the
> > > world has moved on since this spec+patches approach was invented in the
> > > days of CVS source control.
> > > 
> > > Allow packagers to have a clone of the upstraem git repo, and use the
> > > pull-requests and run Fedora CI testing against the Fedora branch of
> > > the upstream repo instead of against dist-git.
> > > 
> > > In this way, maintaining packages in Fedora would be functionally 
> > > identical
> > > to how an upstream project maintains their own stable branches. The only
> > > Fedora difference would be that the branch would need to include the RPM
> > > spec file in some well defined place.
> > 
> > I like this.
> > It means that the build-system would have to generate the tarball of the 
> > source
> > and put it into dist-git at srpm-build time (I believe we still want to 
> > store a
> > copy of the sources used for a build).
> If we want to generate tarballs, we need to think about translations as well.
> While some projects do have translations as part of their source code 
> repository,
> others currently pull them in at tarball build time. This would have to be 
> accounted
> for or otherwise the resulting tarball would miss the translations.

Personally I'd avoid re-generating tarballs as it is a huge can of
worms IMHO. There are many ways upstreams generate their tarballs, often
including generated files for certain desirable reasons. This is very
common with autotools in particular. Just auto-generating patches is
likely to be more relia

Re: Defining the future of the packager workflow in Fedora

[Martin Kolman]

On Thu, 2019-09-26 at 16:24 +0200, Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > > 
> > > At Flock, a few of us met to discuss a future vision of the packager 
> > > workflow.
> > > This discussion was triggered by the realization that a number of 
> > > initiatives
> > > are happening around packaging in Fedora but there is no real shared 
> > > vision on
> > > what we want the packager UX/workflow to be.
> > > The lack of vision on the packager workflow means we could deploy 
> > > something
> > > today, thinking it is the improvement over the current workflow but would
> > > prevent us from (or make it harder to) doing other changes afterwords 
> > > that would
> > > be even more beneficial..
> > > 
> > > So once that concern was raised, we took some time during the Fedora
> > > Infrastructure hackfest to gather the people interested around a white 
> > > board and
> > > brainstorm on what a future packager workflow could look like.
> > > 
> > > We tried not to link this process to any tool in particular as well as 
> > > focus on
> > > the what and why rather than any how.
> > > 
> > > Here is what the vision we came to and that we would like to discuss:
> > > 
> > > ○ Every changes to dist-git is done via pull-requests
> > > ○ Pull-requests are automatically tested
> > > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
> > > ○ Every build in koji results automatically in an update in bodhi
> > > ○ Every update in bodhi is automatically tested
> > > ○ If the tests pass, the update is automatically pushed to the repository
> > 
> > For packages I maintain, my preference is to touch dist-git as little
> > as possible. Ideally I would never touch dist-git at all & rather wish
> > it didn't exist at all in its current form of spec+patchfiles.
> > 
> > Instead I prefer a clone of the master upstream git repo and maintain a
> > branch with patches cherry-picked into it. This is used to auto-generate
> > patches for the Fedora RPM, at the same time updating the patch file list
> > in the RPM spec. The only manual step is adding the changelog entry &
> > bumping release number.
> > 
> > The ideas above around associating CI with pull requests make a lot of
> > conceptual sense & align with modern github/gitlab software development
> > best practices followed by non-distro software upstreams. Automatically
> > triggering builds from merged PRs similarly makes sense, especially
> > if that can automate bumping spec release number & adding a changelog
> > entry based on the pull request subject.
> > 
> > 
> > Obviously I can still use my upstream git repo branch and change the
> > scripts to generate a pull request to dist-git instead.  The downside
> > is if the PR fails, I now how to rebase my real git repo & re-submit
> > and new PR.
> > 
> > So if we're talking "ideal" long term vision though, I'd rather eliminate
> > the dist-git repo intermediate step as IMHO it adds no value, only 
> > complexity
> > for the sake of historical compat with the way Red Hat distros has worked
> > dating back years. Its time to say goodbye to this historical way as the
> > world has moved on since this spec+patches approach was invented in the
> > days of CVS source control.
> > 
> > Allow packagers to have a clone of the upstraem git repo, and use the
> > pull-requests and run Fedora CI testing against the Fedora branch of
> > the upstream repo instead of against dist-git.
> > 
> > In this way, maintaining packages in Fedora would be functionally identical
> > to how an upstream project maintains their own stable branches. The only
> > Fedora difference would be that the branch would need to include the RPM
> > spec file in some well defined place.
> 
> I like this.
> It means that the build-system would have to generate the tarball of the 
> source
> and put it into dist-git at srpm-build time (I believe we still want to store 
> a
> copy of the sources used for a build).
If we want to generate tarballs, we need to think about translations as well.
While some projects do have translations as part of their source code 
repository,
others currently pull them in at tarball build time. This would have to be 
accounted
for or otherwise the resulting tarball would miss the translations.

> 
> Three questions though:
> - What about the upstream projects that still only publish a tarball at 
> release?
>   Should the packager explode that tarball into a git repo?
>   Do we keep the current way of uploading the tarball?
> - Won't this make pull-request for new update harder? Suddenly you have the 
> diff
>   of both all of the upstream changes as well as the spec file and potential
>   patches.
>   In most cases the spec file and the patches is what will matter but for 
> large
>   code-base the diff could be quite significant then.
> - Do you have in mind 

Re: Defining the future of the packager workflow in Fedora

[Martin Kolman]

On Thu, 2019-09-26 at 18:26 +0200, Ben Rosser wrote:
> On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon  
> wrote:
> > On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon  
> > > wrote:
> > > > There is a clear initial rejection of a PR-only contribution model. I 
> > > > hear that
> > > > and that may mean that we never go this way. I'm honestly fine with 
> > > > that :)
> > > > I do want to see why that is a show-stopper and if we can find ways to 
> > > > not have
> > > > it be a show-stopper.
> > > > 
> > > > When we work on upstream projects, I think it's pretty standard now to 
> > > > always go
> > > > via PRs, even for your own branch.
> > > > So that tests are run, so that other member of the community can see, 
> > > > comment,
> > > > review the change.
> > > > What is so different in Fedora that we cannot move to this model?
> > > > Is it a tooling issue?
> > > > Is it something else?
> > > 
> > > Most packages in Fedora are effectively one-person projects (modulo
> > > rebuild scripts and other automated tooling). My experience when
> > > working on a personal project is that I don't use PRs for changes even
> > > if I do develop a change in a branch, rather than master; it's a lot
> > > of unnecessary overhead. There are no "other members" of the
> > > community. No one is reviewing the change other than me.
> > 
> > Would this change if the PR was automatically tested for you without you 
> > having
> > to do anything?
> 
> No, not really? For a personal project, a continuous integration
> system can be set up to run tests on _all_ of my commits, regardless
> of whether or not they're to master or to a development branch. What's
> the benefit of creating a pull request here?
> 
> That being said, packages are slightly different. If it wasn't
> necessary to use the web interface to make a pull request and if
> fedpkg could do it for me [1], and automatically merge it when the
> build succeeds... that might be nice. But if manual work is required
> to create a pull request-- filling out a form on Pagure, manually
> forking a project, etc.-- I think it's a lot of overhead. And I
> wouldn't want to do it for most of my packages.
> 
> Ben Rosser
> 
> [1] And, in an ideal world, do it without needing an API key but
> rather authenticating to Pagure via some other mechanism that doesn't
> require manually downloading a key, but I digress...
If we are talking packager quality of live imporvements, I would vote for this 
as one of the
improvements - unification of the ~5 methods of authetication one might need to 
apply when working
with fedpkg at the moment.

Ideally there should be one method, most likely kerberos, that autheticates the 
user with FAS
and should be used for everything. While its true that some of the services 
(Pagure, COPR) use
API keys, this should be an implementation detail in this case. You authorize 
Pagure & COPR
with your FAS account once (or possibly this happens automatically) and don't 
have to care
about API keys unless you are wiritng some automated tool that needs them.


> ___
> 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: Defining the future of the packager workflow in Fedora

[Fabien Boucher]

On Fri, Sep 27, 2019 at 11:56 AM Miro Hrončok  wrote:

> Yes. I've em-mailed you about the problem when it was happening, asking
> you to
> disable it, there was no reply and I managed to build it at the end.
>
>
So, I apologize. I missed your email.
___
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: Defining the future of the packager workflow in Fedora

[Miro Hrončok]

On 27. 09. 19 11:50, Fabien Boucher wrote:

I remember that during the Python 3.8 rebuilds in the side tag, one package 
had
this automated somehow already. I was bumping the release/changelog and 
trying
to build it in the side tag at least 5 times, but I was building with
--background, so the automation always got the NEVR in Koji first.

I guess it is python-gear ? Where I'm experimenting some automation based on 
Zuul CI.
There is a job triggered to build in Koji when master ref change. This job can 
be trigger

instead when a PR is closed/merged, that way direct push will not trigger a 
build.


Yes. I've em-mailed you about the problem when it was happening, asking you to 
disable it, there was no reply and I managed to build it at the end.


--
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: Defining the future of the packager workflow in Fedora

[Fabien Boucher]

On Fri, Sep 27, 2019 at 12:03 AM Miro Hrončok  wrote:

> I remember that during the Python 3.8 rebuilds in the side tag, one
> package had
> this automated somehow already. I was bumping the release/changelog and
> trying
> to build it in the side tag at least 5 times, but I was building with
> --background, so the automation always got the NEVR in Koji first.
>
>
I guess it is python-gear ? Where I'm experimenting some automation based
on Zuul CI.
There is a job triggered to build in Koji when master ref change. This job
can be trigger
instead when a PR is closed/merged, that way direct push will not trigger a
build.
___
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: Unresponsive maintainer: Hannes Frederic Sowa

[Miro Hrončok]

On 27. 09. 19 11:07, Jiri Hladky wrote:

Hello Hannes,

thanks for the quick response! I'm happy to take over the datamash package.

Could you please give the admin rights by going to
https://src.fedoraproject.org/rpms/datamash
Settings -> Users & Groups -> Add User


Or even

Settings -> Give Project

Jiri's username is jhladky.


--
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: Unresponsive maintainer: Hannes Frederic Sowa

[Jiri Hladky]

Hello Hannes,

thanks for the quick response! I'm happy to take over the datamash package.

Could you please give the admin rights by going to
https://src.fedoraproject.org/rpms/datamash
Settings -> Users & Groups -> Add User

Thanks a lot!
Jiri


On Fri, Sep 27, 2019 at 4:53 AM Hannes Frederic Sowa <
han...@stressinduktion.org> wrote:

> Hello Jiri,
>
> On Thu, Sep 26, 2019, at 13:28, Jiri Hladky wrote:
> > I'm trying to contact Hannes Frederic Sowa, maintainer of datamash
> package:
> >
> > https://src.fedoraproject.org/user/stressinduktion
> > https://src.fedoraproject.org/rpms/datamash
> >
> > I have started the nonresponsive maintainer process due to lack of
> > contact through bugzilla
> > mail:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1755871
> >
> > My primary concern is to build datamash for EPEL-8:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1747561
> >
> > Does anyone know how to contact Hannes Frederic Sowa?
>
> Sorry, mails with tags have been going to a directory I haven't looked
> into for a while.
>
> Do you want to take over datamash, feel free to do so, I currently don't
> have much time for that.
>
> Sorry for annoying you and that you had to take this process,
> Hannes
>
___
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

Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)

[Daniel P . Berrangé]

The upstream QEMU community is raising the possibility of deprecating,
and subsequently deleting, support for running emulation guests on
32-bit *hosts*. Running 32-bit guests would *not* be affected.

See this thread:

  https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06168.html

IOW, if you have a armv7/i686/ppc *host* machine, you would no longer be
able to use QEMU for either full machine system emulation (TCG), nor linux
userspace emulators (TCG). Potentially KVM for 32-bit *host* would be
dropped too, but QEMU might deal with that separately, to align with
kernel support for KVM on 32-bit.

In simple terms, we're talking this proposed matrix for running virtual
machines or linux userspace with emulated CPU architectures:

   | Host 32-bit | Host 64-bit
  -+-+
  Guest 32-bit |   dropped   | supported
  Guest 64-bit |   dropped   | supported

Given that i686 is no longer composed in Fedora, that leaves armv7 as the
Fedora host arch which would be affected.

If upstream goes ahead, we have 2 releases with deprecation[1], so the earliest
it would be deleted is the QEMU release in Aug 2020, which would be Fedora 33
timeframe IIUC. At that time any RPM with a dependancy on QEMU on 32-bit would
need some %ifarch, or ExclusiveArch magic.

I'm assuming there's nothing in Fedora infra that uses 32-bit hosts, as
IIUC, our armv7 koji builders are all on aarch64 hosts.

Does anyone know of, or have, any critical/important use cases that would
be disrupted by QEMU dropping 32-bit *host* support ? If so, let me know
here & I can forward feedback on. Or feel free to go direct to QEMU thread
upstream.

Regards,
Daniel

[1] https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
-- 
|: 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

Re: Defining the future of the packager workflow in Fedora

[Petr Pisar]

On 2019-09-26, Pierre-Yves Chibon  wrote:
> ○ Every changes to dist-git is done via pull-requests

Pull requests are great for proposing your changes to foreign packages.
It does not make sense when maintaining the code. Either when doing
a mass changes like rebuilding all Perl packages against a new perl or
when pushing your own changes. It will become a bureaucracy that adds
a delay and complexity and spams you mailbox. Who is going to merge all
the requests? How do you automate it? We would need "koji watch-task"
for merging the pull requests. I will repeat it: pull requests are
great when you need a review. Otherwise it only consusmes resources.

I'm strongly against this.

> ○ Pull-requests are automatically tested

Nice. But i think this already happens.

> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji

How do you want to implement waiting on propagating build root overrides?

> ○ Every build in koji results automatically in an update in bodhi

How do I merge related updates into on if more packages must be
tested and delivered as one unit? That very often happens with the
overrides.

I smell automated side-tags that has never been implemented.

> ○ Every update in bodhi is automatically tested

This is already a reality.

> ○ If the tests pass, the update is automatically pushed to the repository
>
This also already happens.

-- Petr
___
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: Defining the future of the packager workflow in Fedora

[Michal Konecny]

On 2019-09-26 20:35, Jeremy Cline wrote:

On Thu, Sep 26, 2019 at 09:08:16AM -0700, Adam Williamson wrote:

On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:

Ah right, that makes a lot of sense.

I can imagine automatically detecting the new upstream release, building
that, and presenting the packager with a easy-to-review PR that you just
click "merge" on instead of pointing the specfile at a new tarball.

This already basically happens, at least for things that are hooked up
to anitya:
https://bugzilla.redhat.com/show_bug.cgi?id=1751432
https://fedoraproject.org/wiki/Upstream_release_monitoring

You get a bug report with a patch attached, and it runs a scratch
build. This is great for simple release bumps, but there's still all
sorts of cases where it's not enough or you're just doing something
else.

I do have a little[0] experience with anitya, but it's not nearly as
hooked up as it could be and honestly Libraries.io generally does
better for tracking upstreams, it just lacks the mapping to downstreams.
Maybe we could add that and use it, or continue with anitya.

What I'd really like to see is a lot more "cleverness" from it regarding
versions and automatic backporting to various Fedora releases based on
semantic versioning. Also there's still manual steps you need to do as a
maintainer like downloading and then uploading the tarball.
As a current maintainer I thought about this one and I have already work 
in progress [0] that adds ability to create PR in dist-git directly 
using packit. With Fedora CI in place, this will be automatically 
tested. To get this work I'm missing mostly time to do it and new 
version of Pagure to be deployed.


Anitya still needs plenty of love, but right now Fedora Infra has 
priorities elsewhere. There is still possibility to use libraries.io 
instead of Anitya, but there are some issues:
- lack of downstream mapping (this could be easily solved by some 
database with only downstream mapping)
- lack of custom project additions (libraries.io can only watch projects 
in sources they have already implemented)


Michal

[0] - https://github.com/fedora-infra/the-new-hotness/pull/235


[0] https://github.com/release-monitoring/anitya/graphs/contributors
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
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