date:20210127

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Paul Howarth  ---
You can find perl(namespace::autoclean) in the Code Ready Builder/Powertools
repository.
EPEL8 depends on that repository being enabled.

https://fedoraproject.org/wiki/EPEL#Quickstart


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Christoph Karl


Hello,

On 27.01.21 17:17, Vít Ondruch wrote:

I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be
the preferred way. Would there be anybody really missing this
functionality?


For me even a step further:
I definitely want to know, which settings in my local environment have
an influence on the build.
To find them and to either fix them or make the build stable towards them.

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

[389-devel] 389 DS nightly 2021-01-28 - 95% PASS

2021-01-27 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/28/report-389-ds-base-2.0.2-20210128git827773829.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1921533] New: perl-JSON-Path-0.430 is available

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

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



Latest upstream release: 0.430
Current version/release in rawhide: 0.420-9.fc33
URL: http://search.cpan.org/dist/JSON-Path/

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


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)


On 27. 01. 21 19:30, Kevin Fenzi wrote:

On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote:

On 1/26/21 8:44 PM, Kevin Fenzi wrote:

So, the thread here kind of fell quiet with everything else going on.

It seems clear there's issues to address here before this change might
get approved. Here's my list:

* Try and change the storage format of the signatures to not take up
tons of room. I guess this would be in ima tools and sigul?



That'd be rpm upstream work.

On my F33 laptop, there are 331284 rpm-installed files. The IMA signature as
proposed is apparently 162 bytes per file in the hex-encoded format, this
makes for approximately 51 megabytes of data. My rpmdb is about 115
megabytes. That'd be almost 45% increase in size!


SO, I don't really understand... Patrick says in the Change:

"The size of the rpmdb increases from 22952 to 28416 bytes, a 20%
increase. This is on an install size of 1.7GB in total, so this 5MB
increase is a 0.3% size increase on the final installed system."

Is that just because he used the server install with fewer files?
Or is your or his math wrong here?


Not sure if relevant to the size of rpmdb, but this is the first Python build 
affected by the new signature reported by the compose report:


Package:  python3.9-3.9.1-2.fc34
Old package:  python3.9-3.9.1-1.fc34
Summary:  Version 3.9 of the Python interpreter
RPMs: python-unversioned-command python3 python3-debug python3-devel 
python3-idle python3-libs python3-test python3-tkinter

Size: 131.69 MiB
Size change:  6.56 MiB
Changelog:
  * Wed Jan 20 2021 Miro Hrončok  - 3.9.1-2
  - Security fix for CVE-2021-3177


And this is the one that went back:

Package:  python3.9-3.9.1-4.fc34
Old package:  python3.9-3.9.1-3.fc34
Summary:  Version 3.9 of the Python interpreter
RPMs: python-unversioned-command python3 python3-debug python3-devel 
python3-idle python3-libs python3-test python3-tkinter

Size: 123.94 MiB
Size change:  -6.90 MiB
Changelog:
  * Mon Jan 25 2021 Miro Hrončok  - 3.9.1-4
  - Rebuilt to be signed with Fedora 32 compatible signature,
to fix mock bootstrap chroot on Fedora 32 (and possibly EPELs)


(There was a -876.70 KiB change in the meantime.)

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

Fedora-Rawhide-20210127.n.1 compose check report

2021-01-27 Thread Fedora compose checker

Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
6 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 30/181 (x86_64), 28/123 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210124.n.0):

ID: 763006  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/763006
ID: 763011  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/763011
ID: 763015  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/763015
ID: 763023  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/763023
ID: 763024  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/763024
ID: 763027  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/763027
ID: 763033  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/763033
ID: 763034  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/763034
ID: 763035  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/763035
ID: 763037  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/763037
ID: 763057  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/763057
ID: 763110  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/763110
ID: 763115  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/763115
ID: 763117  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/763117
ID: 763136  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/763136
ID: 763204  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/763204
ID: 763205  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/763205
ID: 763209  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/763209
ID: 763257  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/763257
ID: 763262  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/763262
ID: 763268  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/763268
ID: 763315  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/763315
ID: 763316  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/763316
ID: 763329  Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/763329
ID: 763337  Test: aarch64 universal 
install_kickstart_firewall_configured@uefi
URL: https://openqa.fedoraproject.org/tests/763337
ID: 763338  Test: aarch64 universal install_kickstart_user_creation@uefi
URL: https://openqa.fedoraproject.org/tests/763338
ID: 763339  Test: aarch64 universal install_kickstart_firewall_disabled@uefi
URL: https://openqa.fedoraproject.org/tests/763339
ID: 763342  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/763342
ID: 763343  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/763343
ID: 763344  Test: aarch64 universal install_kickstart_hdd@uefi
URL: https://openqa.fedoraproject.org/tests/763344
ID: 763345  Test: aarch64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/763345
ID: 763346  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/763346
ID: 763347  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/763347

Old failures (same test failed in Fedora-Rawhide-20210124.n.0):

ID: 763049  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/763049
ID: 763060  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/763060
ID: 763113  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/763113
ID: 763178  Test: x86_64 universal install_cyrillic_language
URL:

[Bug 1920399] perl-Log-Report-1.32 is available

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1920399] perl-Log-Report-1.32 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-d183e95f5f has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-d183e95f5f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d183e95f5f

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Testing lua-filesystem 1.8.0

2021-01-27 Thread Michel Alexandre Salim

Hi all,

lua-filesystem has not been properly updated since 2015; we missed the
1.7.0 release in 2017 and the 1.8.0 release in April last year.

The changelogs seem to indicate this should be backward-compatible, but
if your package depends on the `lfs` module please test:

F32 https://bodhi.fedoraproject.org/updates/FEDORA-2021-aa4f097cbf
F33 https://bodhi.fedoraproject.org/updates/FEDORA-2021-01aeb6cf2b

This package is already in RHEL so there's no EPEL updates, but the
updated spec has been tested on EPEL8 as well.

Dependent packages:
```
❯ sudo dnf repoquery --whatrequires lua-filesystem
Lmod-0:8.4.1-1.fc33.x86_64
corsix-th-0:0.64-5.fc33.x86_64
lua-moonscript-0:0.5.0-6.fc33.noarch
lua-penlight-0:1.9.2-1.fc33.noarch
prosody-0:0.11.7-1.fc33.x86_64
prosody-0:0.11.7-2.fc33.x86_64
wordgrinder-0:0.7.2-6.fc33.x86_64
wordgrinder-0:0.8-1.fc33.x86_64
```

I've kept the stable autokarma to +3 and disabled the auto-promoting by
time to make sure this does not get accidentally promoted.

Thanks to Robert Scheck for helping modernize the spec (and is now co-
maintaining the package). I've further cleaned it up to match what will
be in the upcoming Lua packaging guidelines.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

2021-01-27 Thread Michel Alexandre Salim

On Wed, 2021-01-27 at 10:25 -0800, Kevin Fenzi wrote:
> On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim
> wrote:
> > On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote:
> > > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> > > > But that would involve at least six new steps that would've to
> > > > be
> > > > automated: 1) Creating a fork on src.fp.o (plus error handling
> > > > around
> > > > already existing forks), 2) Cloning the fork instead of the
> > > > main
> > > > repo,
> > > > 3) Automatically creating a PR after a git push, 4)
> > > > Automatically
> > > > merging the PR if CI passes, 5) Deleting the fork, 6)
> > > > Automatically
> > > > building the package in koji ...
> > > 
> > > Yeah, honestly, this is also a pretty serious hardship for the
> > > long
> > > tail of
> > > people maintaining a handful of infrequently updated packages.
> > > I'm
> > > hugely in
> > > favor of not checking in work in progress on the main or release
> > > branches,
> > > but let's not make more steps.
> > > 
> > Similar to the (optional) playground repo we have for epel8 --
> > would
> > having a 'rawhide-playground' repo help?
> 
> With what goals?
With the goal to have experimental commits go there, but on further
thought forking the package and doing such tests there is probably a
better idea.


Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Orphaning my ocaml packages

2021-01-27 Thread Michel Alexandre Salim

Hi all,

I've not been using Ocaml recently, and have not been able to give
these packages the attention they deserve.

I'll be orphaning them; in all cases there's only exactly one
comaintainer (Ding-Yi Chen) so they'll be the primary maintainer going
forward.

rpms/ocaml-biniou
rpms/ocaml-cppo
rpms/ocaml-easy-format
rpms/ocaml-xmlm
rpms/ocaml-yojson 

Thanks,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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

[Bug 1921396] New: perl-MooseX-Getopt-0.74-6.el8 cant be installed on RHEL8

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

Bug ID: 1921396
   Summary: perl-MooseX-Getopt-0.74-6.el8 cant be installed on
RHEL8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-MooseX-Getopt
  Assignee: p...@city-fan.org
  Reporter: re...@seznam.cz
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

Package perl-MooseX-Getopt-0.74-6.el8 can't be installed on RHEL8
It's dependency is missing - perl(namespace::autoclean)
(adding to copy p...@city-fan.org the owner of the package
perl-namespace-autoclean)


Version-Release number of selected component (if applicable):
perl-MooseX-Getopt-0.74-6.el8

How reproducible:
100%

Steps to Reproduce:
1.
# dnf install perl-MooseX-Getopt --enablerepo=*


Actual results:
Last metadata expiration check: 0:36:47 ago on Wed 27 Jan 2021 10:37:03 PM UTC.
Error: 
 Problem: conflicting requests
  - nothing provides perl(namespace::autoclean) needed by
perl-MooseX-Getopt-0.74-6.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use
not only best candidate packages)


Expected results:
package installed


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Mass rebuild failures on s390

On Wed, Jan 27, 2021 at 10:15:20PM +, Richard W.M. Jones wrote:
> Here are a couple of my packages which failed mass rebuild
> because of apparent problems with the s390 builder:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418
> 
> Could we automatically look for builds which fail this way
> and resubmit them please?

The plan is to wait for the entire mass rebuild to finish, then resubmit
all the failures. Hopefully that will fix at least most of the above
cases. 

kevin


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

Re: COMMERCIAL - Bosch - Architect

2021-01-27 Thread Sam Varshavchik


George Bastin writes:


Sorry Marius, it is not a violation of any law.


Right. By the way, banning everyone from an organization from using a  
mailing list: that's not a violation of any law, either. It would also not  
be a violation of any law to notify administrators of other mailing lists  
what a certain organization tends to use mailing lists for. This will also  
be perfectly legal.


You address is on a public mailing list, which anyone in the world can  
contact.


A "public mailing list" is not a synonym for being open to "anyone in the  
world can" to send any message, on any topic, to the mailing list. I'm  
wondering what you would think about me sending a picture of my cute kitty- 
cat to this mailing list. Would that be appropriate? How come? After all,  
this is a public mailing list, and that's the only justification you offered  
for your action, quote: this is a "public mailing list". There were no  
further constraints. So, if this is good enough for your email, it should be  
good enough for my email too, with a picture of my kitty-cat.





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

Re: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 4:17 PM, Richard W.M. Jones  
wrote:

> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> 

> > Hi,
> > I wonder, what would be the sentiment if I proposed to deprecated
> > the `fedpkg local` command. I don't think it should be used. Mock
> > should be the preferred way. Would there be anybody really missing
> > this functionality?
> 

> Why? I use it all the time. While I understand that it's not as
> complete a local test as mock, it a lot quicker and less disruptive.
> And if I want a real test I'll use a scratch build (because that's the
> only way to test a build across architectures).
> 

Agreed. Santa didn't bring me the s390x I asked for this year. :(

> TL;DR don't drop it.
> 

> Rich.
> 

> ---
> 

> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Richard W.M. Jones

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated
> the `fedpkg local` command. I don't think it should be used. Mock
> should be the preferred way. Would there be anybody really missing
> this functionality?

Why?  I use it all the time.  While I understand that it's not as
complete a local test as mock, it a lot quicker and less disruptive.
And if I want a real test I'll use a scratch build (because that's the
only way to test a build across architectures).

TL;DR don't drop it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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

Mass rebuild failures on s390

2021-01-27 Thread Richard W.M. Jones

Here are a couple of my packages which failed mass rebuild
because of apparent problems with the s390 builder:

https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709

https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418

Could we automatically look for builds which fail this way
and resubmit them please?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Josh Stone

On 1/27/21 2:04 PM, Otto Urpelainen wrote:
> The other option of not using 'git add .' can also be described as 
> mentally filtering out all the irrelevant unstaged changes to find the 
> ones that should actually be added. That adds cognitive burden, slows 
> things down and leads to mistakes every now and then. It does not help 
> to say "do not make mistakes" if the task is inherently error-prone. 
> Such filtering is something a computer should do, which leads us back to 
> .gitignore.

FWIW, 'git add -u' (--update) will limit you to files that are already
part of the repo. You still need to pay attention if there really are
new files though, like a new patch.
___
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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 4:04 PM, Otto Urpelainen  wrote:

> Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40:
> 

> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch vondr...@redhat.com 
> > wrote:
> > 

> > > Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> > > 

> > > > Question; What problem would be solved by removing fedpkg local that 
> > > > isn't addressed by documentation?
> > > 

> > > It would ensure, that people are using stable and predictable
> > > environment for Fedora development, keeping their system intact.
> > > This proposal was triggered specifically by comment from this ticket [1]:
> > > 

> > >  I still have a workflow issue, because running `fedpkg 
> > > local`generates a
> > >  huge amount of files that, in most repositories, are not in
> > >  `.gitignore`, leading to mistakes like this.
> > > 

> > > 

> > > This is simply not good user experience.
> > 

> > If the user doesn't 'git add .', or has a correct .gitignore, this should 
> > be a non issue.
> 

> Me being the quoted person with a workflow issue, I still think there is
> a workflow issue.
> 

> Setting .gitignore is possible of course, but rather annoying and
> repetitive. Each package has its own repository, so there are a lot of
> .gitignore files to configure. Also, the names that need to be ignored
> depend on package version, so it is either messy globbing (or perhaps
> regexing, if that is supported?) or updating every time version
> increases. And 'fedpkg local' generates multiple files and directories
> at repository root, yet another multiplier. Doing it manually every time
> means spending time with ignore rules instead of packaging software.
> 

> The other option of not using 'git add .' can also be described as
> mentally filtering out all the irrelevant unstaged changes to find the
> ones that should actually be added. That adds cognitive burden, slows
> things down and leads to mistakes every now and then. It does not help
> to say "do not make mistakes" if the task is inherently error-prone.
> Such filtering is something a computer should do, which leads us back to
> .gitignore.
> 

> Perhaps a script could create the correct ignore globs for all
> repositories in one go and that would be it, and have it in the template
> for new repositories, too? Just an idea, perhaps not worth the effort
> and complexity.
> 

> It would help much if 'fedpkg local' would only generate anything in a
> single directory with constant name - 'build' or whatever.
> 

> (Oh, and for the original question about deprecating 'fedpkg local' - I
> don't know. Before this discussion started, I was happily using 'fedpkg
> local' and did not even know what mock was. I have to get in terms with
> mock to form an opinion.)
> 


The only times I use the git command in fedpkg is to merge between branches, or 
add/remove packages. If you're just doing changes to things already tracked, 
such as the spec, sources, patches, scripts, etc, fedpkg commit will add them 
for you. It also spits out a warning if you commit a spec with a Patch not 
tracked in git, which is nice.


> Otto
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Simo Sorce

On Wed, 2021-01-27 at 17:17 +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated the 
> `fedpkg local` command. I don't think it should be used. Mock should be 
> the preferred way. Would there be anybody really missing this functionality?

Sorry I a completely against this.

I use fedpkg local very often, and mock is something I never use.
If I need a clean build environemnt I simply launch a scratch build in koji.

When I used fedpkg local I very much do not care for a clena
environment and may *very* well depend on the actual packages I have
currently installed.

In short, I am not amused by this proposal, it is about removing an
extremely useful tool.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Otto Urpelainen


Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40:
 
‐‐‐ Original Message ‐‐‐

On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch  
wrote:


Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):


Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?


It would ensure, that people are using stable and predictable
environment for Fedora development, keeping their system intact.

This proposal was triggered specifically by comment from this ticket [1]:

 I still have a workflow issue, because running `fedpkg local`generates a
 huge amount of files that, in most repositories, are not in
 `.gitignore`, leading to mistakes like this.
 
This is simply not good user experience.




If the user doesn't 'git add .', or has a correct .gitignore, this should be a 
non issue.



Me being the quoted person with a workflow issue, I still think there is 
a workflow issue.


Setting .gitignore is possible of course, but rather annoying and 
repetitive. Each package has its own repository, so there are a lot of 
.gitignore files to configure. Also, the names that need to be ignored 
depend on package version, so it is either messy globbing (or perhaps 
regexing, if that is supported?) or updating every time version 
increases. And 'fedpkg local' generates multiple files and directories 
at repository root, yet another multiplier. Doing it manually every time 
 means spending time with ignore rules instead of packaging software.


The other option of not using 'git add .' can also be described as 
mentally filtering out all the irrelevant unstaged changes to find the 
ones that should actually be added. That adds cognitive burden, slows 
things down and leads to mistakes every now and then. It does not help 
to say "do not make mistakes" if the task is inherently error-prone. 
Such filtering is something a computer should do, which leads us back to 
.gitignore.


Perhaps a script could create the correct ignore globs for all 
repositories in one go and that would be it, and have it in the template 
for new repositories, too? Just an idea, perhaps not worth the effort 
and complexity.


It would help much if 'fedpkg local' would only generate anything in a 
single directory with constant name - 'build' or whatever.


(Oh, and for the original question about deprecating 'fedpkg local' - I 
don't know. Before this discussion started, I was happily using 'fedpkg 
local' and did not even know what mock was. I have to get in terms with 
mock to form an opinion.)


Otto
___
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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Zbigniew Jędrzejewski-Szmek

+1 to everything that Gwyn said.

'fedpkg local' is just so immensely useful for initial package developement.

I also use it a lot for systemd & friends: I *want* to build packages
against the local environment and install them locally without pulling
in any other package updates, and I want to be able to debug build or
test failures in the host environment.

(I also use mock in various configurations, and copr, and scratch
builds, etc. I find mock immensely useful too, but in a later phase of
package development. Different tools have different tradeoffs.)

Zbyszek
___
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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Ken Dreyer

On Wed, Jan 27, 2021 at 9:17 AM Vít Ondruch  wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?

Seems like this is a speed-vs-correctness thing.

I prefer "fedpkg mock" personally, because it's closer to what Koji
does, but it is definitely slower.

What if the pyrpkg --help text for the local sub-command steered new
users away from "local"? Or at least explained the caveats involved?

- Ken
___
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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Robbie Harwood

Vít Ondruch  writes:

> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?

I would miss it.  It's nontrivially faster to `fedpkg local` than
`fedpkg mockbuild` since I don't have to wait for dnf multiple times.
The overhead can be quite high.

Thanks,
--Robbie


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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread David Howells

Vít Ondruch  wrote:

> I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg
> local` command. I don't think it should be used. Mock should be the preferred
> way. Would there be anybody really missing this functionality?

Mock is waaay overkill a lot of the time.  It's a lot simpler and easier just
to do fedpkg local.  The main thing wrong with fedpkg local is that it likes
to put stuff in the user's homedir - something it shouldn't do unless it's
actually run there.  That's a pain if the user's homedir is on a network
filesystem.

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

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote:
> On 1/26/21 8:44 PM, Kevin Fenzi wrote:
> > So, the thread here kind of fell quiet with everything else going on.
> > 
> > It seems clear there's issues to address here before this change might
> > get approved. Here's my list:
> > 
> > * Try and change the storage format of the signatures to not take up
> > tons of room. I guess this would be in ima tools and sigul?
> > 
> 
> That'd be rpm upstream work.
> 
> On my F33 laptop, there are 331284 rpm-installed files. The IMA signature as
> proposed is apparently 162 bytes per file in the hex-encoded format, this
> makes for approximately 51 megabytes of data. My rpmdb is about 115
> megabytes. That'd be almost 45% increase in size!

SO, I don't really understand... Patrick says in the Change: 

"The size of the rpmdb increases from 22952 to 28416 bytes, a 20%
increase. This is on an install size of 1.7GB in total, so this 5MB
increase is a 0.3% size increase on the final installed system."

Is that just because he used the server install with fewer files?
Or is your or his math wrong here?

kevin


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

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim wrote:
> On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote:
> > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> > > But that would involve at least six new steps that would've to be
> > > automated: 1) Creating a fork on src.fp.o (plus error handling
> > > around
> > > already existing forks), 2) Cloning the fork instead of the main
> > > repo,
> > > 3) Automatically creating a PR after a git push, 4) Automatically
> > > merging the PR if CI passes, 5) Deleting the fork, 6) Automatically
> > > building the package in koji ...
> > 
> > Yeah, honestly, this is also a pretty serious hardship for the long
> > tail of
> > people maintaining a handful of infrequently updated packages. I'm
> > hugely in
> > favor of not checking in work in progress on the main or release
> > branches,
> > but let's not make more steps.
> > 
> Similar to the (optional) playground repo we have for epel8 -- would
> having a 'rawhide-playground' repo help?

With what goals?

I think it would just make more work/use more resources. 

kevin


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

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On Wed, Jan 27, 2021 at 01:26:17PM +0100, Petr Menšík wrote:
> What about ability to opt-in into %prep checking on push?
> Could we add some new rules to gating.yaml for example, allowing few
> checks on push?

If it's something that runs locally before accepting the commit, I think
that would be fine. 

Gating/CI is too late, and I don't really want our git server to parse
spec files.

> Most of package I manage are tiny or small, prep check should not take
> longer than 10s on most of them. I made mistake of omitting patch our
> source file multiple time.
> 
> Could similar check be enabled either by dist-git file or project
> settings on package sources?
> 
> I never did any check, but I think the most of packages are quite small.
> How many packages could have significant size of sources? If we have
> opt-in first and opt-out for large packages later, would it work?

First I think it will need someone to create such a hook, but yeah, for
many packages a prep test pre-commit would be good I would think. 

kevin
--
> 
> On 1/26/21 6:32 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jan 26, 2021 at 03:59:18PM +, Jonathan Wakely wrote:
> >> On 25/01/21 19:58 +0100, Miro Hrončok wrote:
> ...
> >>
> >> Not for the first time, I wonder why we don't have a git server hook
> >> that rejects a push if it fails %prep. For large packages the %prep is
> >> too slow, but we could at least check for the common mistake of adding
> >> a patch to the .spec and forgetting to git add the actual .patch file.
> >> Why do we allow that, instead of just refusing the push?
> >>
> >> Does anybody have a valid reason to want to be able to push a .spec
> >> that refers to a missing .patch file? Surely it's always an accident
> >> (as happened with libreoffice last week) and we should use tooling to
> >> help us avoid such accidents?
> > 
> > I don't think we should do a full %prep (because that sometimes sources
> > can be huge and people do some preprocessing in %prep that might take
> > a few minutes). But we should check that Source* and Patch* is defined
> > and the spec file is syntactically valid. This would go a long way towards
> > avoiding stupid mistakes, without significant cost.
> > 
> > Zbyszek
> > 
> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 




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



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

Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories

On Wed, Jan 27, 2021 at 10:47:07AM +0100, Kamil Paral wrote:
> On Tue, Jan 26, 2021 at 7:06 PM Kevin Fenzi  wrote:
> 
> > > Adding normal packages are requirements for a devel package just to make
> > it
> > > multilib feels... unclean? Perhaps I'm misunderstanding something. In
> > order
> > > to have the logic self-contained, why don't we add something like
> > > "Provides: multilib(x86_64, i686)" into affected packages and make pungi
> > > process that?
> >
> > Feel free to suggest it to rpm. ;)
> >
> 
> Why rpm? Isn't that entirely in our hands, what Provides we assign to
> Fedora packages and what meaning we give it?

Sure I suppose... although it would be nice to coordinate with other rpm
using distros. 

> > I'd personally just like to drop i686 entirely, but I don't think
> > everyone else is ready for that.
> >
> 
> No no no, I'm not willing to give up my games collection! :-)

See! :) 

kevin


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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread J. Bruce Fields

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?

For what it's worth, when I do a search for "how to build a fedora
kernel", the first three hits I get are:

https://fedoraproject.org/wiki/Building_a_custom_kernel

https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
https://fedoramagazine.org/building-fedora-kernel/

which all use "fedpkg local".

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

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a):

Hi,

This would describe my usual workflow as well. fedpkg local is great for
checking soname did not change, patches apply, to debugging why my test
suites fail and how they behave. mock usual does not have even vim


You have vim on your host with your configuration, why would you need it 
in mock?




, let
alone gdb or something better.



GDB works in mock just fine.

Vít




In other words, i use fedpkg local a lot and would miss it much. I
understand what mockbuild is for, but for any iterative improvements
done to my package, fedpkg local is much better. Don't remove it,
please. Especially in bind, which includes latex documentation building,
are installed dependencies slowing one iteration significantly.

On 1/27/21 5:43 PM, Daniel P. Berrangé wrote:

On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:

On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
 wrote:

It's needed for testing builds against versions of packages not yet in mock. I 
use it almost every day. Losing it would make things like testing solib bumps 
harder.

I've done local test builds for soname bumps and similar things lots
of times, and I've never used (or thought about using) fedpkg local
for that.
I used "mock --chain" or a combination of "mock --postinstall
--no-clean" for those builds ... which is much closer to what koji
will do with your builds, and gives every build the clean environment
it deserves >:-)

If you want to closely replicate that koji will do, then no disagreement
that use of mock is the right tool (or just a koji scratch-build). That
just isn't a requirement much of the time though.

For adhoc development and debugging of RPM spec changes/updates, mock
gets in the way and slows things down. I could easily do 10-20 "local"
runs while getting an complex change working, and then finish off with
just one or two mock build or koji scratch-build to validate it in a
pristine build root env at the end.


Regards,
Daniel



___
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


OpenPGP_signature
Description: OpenPGP digital 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

Intention to orphan brutalchess and stockfish packages

2021-01-27 Thread Raphael Groner

Hi,

unfortunately there's not enough available time for me to actively maintain 
gaming packages. As I'm more and more loosing interest in gaming especially 
with Linux (preferences clearly go into mobile gaming) I decided to orphan two 
of my long standing packages.

. brutalchess - chess game
- unreadable game menu: https://bugzilla.redhat.com/show_bug.cgi?id=1874279

. stockfish - famous chess engine for various frontends
- stockfish-12 is available: https://bugzilla.redhat.com/show_bug.cgi?id=1875192

Please feel free to pick them if you still think there are of any usefulness in 
Fedora.

Regards,
Raphael
___
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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Justin Forbes

On Wed, Jan 27, 2021 at 10:18 AM Vít Ondruch  wrote:
>
> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?
>

I would greatly miss this functionality. Outside of the obvious speed
benefits of skipping mock setup, the bigger issue is various new
buildreqs get brought into packages, and comparing fedpkg local to
fedpkg mockbuild results are a great way to see if those buildreqs are
required, and what the impact is on the build with and without them.
Sure, I can just run rpmbuild commands by hand, but I have gotten used
to and appreciate the simplicity of fedpkg local.

Justin
___
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: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:00:42PM +0100, Vít Ondruch wrote:
> 
> Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > > Hi,
> > > 
> > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > `fedpkg local` command. I don't think it should be used. Mock should be 
> > > the
> > > preferred way. Would there be anybody really missing this functionality?
> > While I understand that mock has the benefit of providing a well
> > defined build environment, with less scope for things going wrong,
> > that just isn't important to me most of the time. In fact I often
> > want to build against what I have installed locally, explicitly
> > *not* against what mock has in its build root.
> > 
> > So overall "fedpkg local" has the benefit that it is much faster
> > to run the build and simpler to get it to build what I want.
> 
> 
> While there is certainly penalty in using mock, running repetitive builds
> together with `--no-clean` option will hardly slow you down. Just a few
> numbers.
> 
> 1) Starging from scratch after `mock --scrub=all`, every package have to be
> downloaded and installed:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 
> ... snip ...
> 
> real    0m47,188s
> user    0m41,841s
> sys    0m6,040s
> 
> ~~~
> 
> 
> 2) With warm cache, only the BRs are installed, running right after the
> previous build:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 
> ... snip ...
> 
> real    0m13,182s
> user    0m9,885s
> sys    0m2,701s
> 
> ~~~
> 
> 
> 3) Without build root cleanup:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
> 
> ... snip ...
> 
> real    0m7,563s
> user    0m6,139s
> sys    0m1,194s
> 
> ~~~
> 
> 
> I think this is acceptable penalty for keeping my system unpolluted and
> giving me easy opportunity to start from scratch if I messed up or if my
> dependencies have changed or what not.

"keep my system unpolluted" is not a goal that's relevant, so it
doesn't justify the overhead of using mock.

The act of doing a build doesn't pollute my system. Installing the
package I built and testing it can pollute it, but that part is the
same even if I'm using mock to perform the build.  None of this
takes place in my important host, it is in a throwaway VM because
I need a full running OS install for testing the resulting package
no matter how it is built.

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: Proposal to deprecated `fedpkg local`

Hi,

This would describe my usual workflow as well. fedpkg local is great for
checking soname did not change, patches apply, to debugging why my test
suites fail and how they behave. mock usual does not have even vim, let
alone gdb or something better.

In other words, i use fedpkg local a lot and would miss it much. I
understand what mockbuild is for, but for any iterative improvements
done to my package, fedpkg local is much better. Don't remove it,
please. Especially in bind, which includes latex documentation building,
are installed dependencies slowing one iteration significantly.

On 1/27/21 5:43 PM, Daniel P. Berrangé wrote:
> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
>> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
>>  wrote:
>>>
>>> It's needed for testing builds against versions of packages not yet in 
>>> mock. I use it almost every day. Losing it would make things like testing 
>>> solib bumps harder.
>>
>> I've done local test builds for soname bumps and similar things lots
>> of times, and I've never used (or thought about using) fedpkg local
>> for that.
>> I used "mock --chain" or a combination of "mock --postinstall
>> --no-clean" for those builds ... which is much closer to what koji
>> will do with your builds, and gives every build the clean environment
>> it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 
> 
> 
> Regards,
> Daniel
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Petr Pisar

On Wed, Jan 27, 2021 at 04:43:35PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> >  wrote:
> > >
> > > It's needed for testing builds against versions of packages not yet in 
> > > mock. I use it almost every day. Losing it would make things like testing 
> > > solib bumps harder.
> > 
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 
> 
Exactly. I also use "fedpkg local" in my pet virtual machine. Pretty often.
It's faster, more interactive, easier for debugging.

Does mock still need root (membership in mock group)?

-- Petr


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

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:33:30PM +0100, Vít Ondruch wrote:
> 
> Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> > 
> > Question; What problem would be solved by removing fedpkg local that isn't 
> > addressed by documentation?
> > 
> 
> It would ensure, that people are using stable and predictable environment
> for Fedora development, keeping their system intact.

"keeping their system intact" isn't a goal for me.

My work is already inside a throwaway VM, because after doing a
local build, I want to install the package and actually attempt
to use it in a real running system.

> 
> This proposal was triggered specifically by comment from this ticket [1]:
> 
> ~~~
> 
> I still have a workflow issue, because running `fedpkg local`generates a
> huge amount of files that, in most repositories, are not in `.gitignore`,
> leading to mistakes like this.
> 
> ~~~
> 
> This is simply not good user experience.

The fault in this case is not the existance of "fedpkg local", rather
it is a combination of poor default locations for "fedpkg local" when
unpacking the RPM, and poor .gitignore contents.

eg it'll create a .build-$SOMEVERSION.log file every time, and unpack
the tarball into the base directory, neither of which are in the git
ignore list. And the results get put into an x86_64/ (or other arch)
subdirectory which again isn't in the gitignore.

It should be easy to make fedpkg local only ever create files within
a "build/" sub-directory and have this subdir be in the dist-git
.gitignore file out of the box.

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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> 

> > Question; What problem would be solved by removing fedpkg local that isn't 
> > addressed by documentation?
> 

> It would ensure, that people are using stable and predictable
> environment for Fedora development, keeping their system intact.
> 

> This proposal was triggered specifically by comment from this ticket [1]:
> 

> 

> I still have a workflow issue, because running `fedpkg local`generates a
> huge amount of files that, in most repositories, are not in
> `.gitignore`, leading to mistakes like this.
> 

> 

> 

> This is simply not good user experience.
> 


If the user doesn't 'git add .', or has a correct .gitignore, this should be a 
non issue.

> Vít
> 

> [1] https://src.fedoraproject.org/rpms/rubygem-jekyll/pull-request/4
> 

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



signature.asc
Description: OpenPGP digital 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

[Bug 1921203] perl-Graph-0.9717 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Skipping the scratch build because an SRPM could not be built: ['rpmbuild',
'-D', '_sourcedir .', '-D', '_topdir .', '-bs',
'/var/tmp/thn-jvm43ph4/perl-Graph.spec'] returned 1: b'error: line 5: unclosed
macro or bad line continuation\n'


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1921203] New: perl-Graph-0.9717 is available

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

Bug ID: 1921203
   Summary: perl-Graph-0.9717 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Graph
  Keywords: FutureFeature, Triaged
  Assignee: athoscribe...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@users.sourceforge.net, athoscribe...@gmail.com,
igor.ra...@gmail.com,
perl-devel@lists.fedoraproject.org,
w...@gouldfamily.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.9717
Current version/release in rawhide: 0.97.16-1.fc34
URL: http://search.cpan.org/dist/Graph/

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


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):


Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?



It would ensure, that people are using stable and predictable 
environment for Fedora development, keeping their system intact.


This proposal was triggered specifically by comment from this ticket [1]:

~~~

I still have a workflow issue, because running `fedpkg local`generates a 
huge amount of files that, in most repositories, are not in 
`.gitignore`, leading to mistakes like this.


~~~

This is simply not good user experience.


Vít



[1] https://src.fedoraproject.org/rpms/rubygem-jekyll/pull-request/4




OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:26 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 17:57 Gwyn Ciesla via devel napsal(a):
> 

> > -- 
> > Gwyn Ciesla
> > she/her/hers
> >  
> > in your fear, seek only peace 
> > in your fear, seek only love
> > -d. bowie
> > 

> > Sent with ProtonMail Secure Email.
> > 

> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch  
> > wrote:
> > 

> > > You can do this in mock without messing with your system. You can use 
> > > `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command 
> > > you want to use`. You can use `mock your.srpm --short-circuit=install` 
> > > and similar. You can use `mock shell --unpriv` if you want to tinker 
> > > more. Mock is everything you ever wanted to develop for Fedora.
> > > 

> > > So could you please share with us specifics of your workflow which makes 
> > > it unique and which really requires `fedpkg local`? I can't imaging that 
> > > intentionally breaking the host system due to testing soname bump is the 
> > > right thing to do.
> > 

> > Ok, let's say I have to update a library, let's say LibRaw, and the soname 
> > changes.
> > 

> > I fire up a rawhide VM
> 

> This is the first difference, with Mock, you don't need to fire VM.
> 

> > , and clone the LibRaw repo, update the spec
> 

> Second difference is that you are cloning locally.
> 

> > , build
> 

> At this place, you call `fedpkg srpm` followed by `mock LibRaw.srpm`
> 

> > , and install it
> 

> `mock -i /var/lib/cache/mock/fedora-rawhide-x86_64/results/LibRaw.rpm`
> 

> > . Then I clone the dependant repos, update their specs, and build them.

These are all more cumbersome to type quickly. fedpkg mockbuild solves that but 
I doesn't support the options you use. fedpkg local does what I and apparently 
many others need.

> You clone them locally and you call the `mock dependant.srpm --no-clean`. 
> Please note that the --no-clean is essential here, because otherwise the BR 
> would be cleaned up as well as the results directory previously used for 
> installation. But of course you can save the build results somewhere.
> 

> >   Failures are immediately apparent, and I can quickly work on patches or 
> > obtain logs of failures for sending upstream. I can easily get into the 
> > source tree to examine files
> 

> Sure you can with mock, you have everything at 
> `/var/lib/cache/mock/fedora-rawhide-x86_64/root`
> 

> > , quickly test tweaks to build commands, etc. Once it all builds, I do a 
> > mock chain build, then an srpm koji scratch build, and if all is well, I 
> > commit, push, and chain-build in koji.
> 

> No difference here.
> 

> > I always use mock for final smoketesting and rooting out missed 
> > BuildRequires, but being forced to use mock for the whole process would 
> > greatly lengthen the process.
> 

> This is where I disagree. You would save you troubles using VM. Mock is more 
> lightweight providing you everything you need.
> 

> BTW, I should note here that I am not user of `fedpkb mockbuild`. I believe 
> that using mock directly is not harder. The same way as I am using `git 
> commit` where others could prefer `fedpkg commit`.
> 

> Vít



signature.asc
Description: OpenPGP digital 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

dropping selinux-policy strict version requirement

2021-01-27 Thread Ken Dreyer

Hi folks,

Many applications ship their own "-selinux" sub-package. These
subpackages usually set a minimal dependency on the exact
selinux-policy version in the buildroot.

In Ceph's case, we have:

  Requires(post): selinux-policy-base >= %{_selinux_policy_version}

This version requirement causes problems in two scenarios:

1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
uninstallable on RHEL.

2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
package will be uninstallable on RHEL 8 EUS.

Is it safe to drop the exact version requirement here and just depend
on an unversioned "selinux-policy-base"?

I can't find any official Fedora Packaging Guideline on this. I opened
https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.

- Ken
___
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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:10 AM, Fabio Valentini  
wrote:

> On Wed, Jan 27, 2021 at 6:04 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org wrote:
> 

> > Great! And you can keep doing that! That's a good thing to have. fedpkg 
> > local also works without network access, like on a train, if you have all 
> > your BuildRequires in place.
> 

> If that's all you want, why not use plain rpmbuild (either -ba for
> .spec file or -ra for .src.rpm file)?
> 


That doesn't work in the fedpkg clone, it requires installing the SRPM locally.

> Additionally, with features like %generate_buildrequires becoming more
> widely used, mock is certainly the easiest way to build those packages
> ...
> 

> Fabio
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 17:57 Gwyn Ciesla via devel napsal(a):



--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie


Sent with ProtonMail  Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch 
 wrote:


You can do this in mock without messing with your system. You can use 
`mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf 
command you want to use`. You can use `mock your.srpm 
--short-circuit=install` and similar. You can use `mock shell 
--unpriv` if you want to tinker more. Mock is everything you ever 
wanted to develop for Fedora.


So could you please share with us specifics of your workflow which 
makes it unique and which really requires `fedpkg local`? I can't 
imaging that intentionally breaking the host system due to testing 
soname bump is the right thing to do.


Ok, let's say I have to update a library, let's say LibRaw, and the 
soname changes.


I fire up a rawhide VM



This is the first difference, with Mock, you don't need to fire VM.



, and clone the LibRaw repo, update the spec



Second difference is that you are cloning locally.



, build



At this place, you call `fedpkg srpm` followed by `mock LibRaw.srpm`



, and install it



`mock -i /var/lib/cache/mock/fedora-rawhide-x86_64/results/LibRaw.rpm`



. Then I clone the dependant repos, update their specs, and build them.



You clone them locally and you call the `mock dependant.srpm 
--no-clean`. Please note that the --no-clean is essential here, because 
otherwise the BR would be cleaned up as well as the results directory 
previously used for installation. But of course you can save the build 
results somewhere.



  Failures are immediately apparent, and I can quickly work on patches 
or obtain logs of failures for sending upstream. I can easily get into 
the source tree to examine files



Sure you can with mock, you have everything at 
`/var/lib/cache/mock/fedora-rawhide-x86_64/root`



, quickly test tweaks to build commands, etc. Once it all builds, I do 
a mock chain build, then an srpm koji scratch build, and if all is 
well, I commit, push, and chain-build in koji.



No difference here.




I always use mock for final smoketesting and rooting out missed 
BuildRequires, but being forced to use mock for the whole process 
would greatly lengthen the process.



This is where I disagree. You would save you troubles using VM. Mock is 
more lightweight providing you everything you need.



BTW, I should note here that I am not user of `fedpkb mockbuild`. I 
believe that using mock directly is not harder. The same way as I am 
using `git commit` where others could prefer `fedpkg commit`.



Vít




OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:16 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 18:03 Gwyn Ciesla via devel napsal(a):
> 

> > --
> > Gwyn Ciesla
> > she/her/hers
> > 

> > 
> > 

> > in your fear, seek only peace
> > in your fear, seek only love
> > -d. bowie
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, January 27, 2021 11:00 AM, Vít Ondruch vondr...@redhat.com 
> > wrote:
> > 

> > > Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> > > 

> > > > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > > > 

> > > > > Hi,
> > > > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > > > `fedpkg local` command. I don't think it should be used. Mock should 
> > > > > be the
> > > > > preferred way. Would there be anybody really missing this 
> > > > > functionality?
> > > > > While I understand that mock has the benefit of providing a well
> > > > > defined build environment, with less scope for things going wrong,
> > > > > that just isn't important to me most of the time. In fact I often
> > > > > want to build against what I have installed locally, explicitly
> > > > > not against what mock has in its build root.
> > > > > So overall "fedpkg local" has the benefit that it is much faster
> > > > > to run the build and simpler to get it to build what I want.
> > > > > While there is certainly penalty in using mock, running repetitive
> > > > > builds together with `--no-clean` option will hardly slow you down. 
> > > > > Just
> > > > > a few numbers.
> > > 

> > > 1.  Starging from scratch after `mock --scrub=all`, every package have to
> > > be downloaded and installed:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> > > ... snip ...
> > > real    0m47,188s
> > > user    0m41,841s
> > > sys    0m6,040s
> > > 

> > > 

> > > 2.  With warm cache, only the BRs are installed, running right after the
> > > previous build:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> > > ... snip ...
> > > real    0m13,182s
> > > user    0m9,885s
> > > sys    0m2,701s
> > > 

> > > 3.  Without build root cleanup:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
> > > ... snip ...
> > > real    0m7,563s
> > > user    0m6,139s
> > > sys    0m1,194s
> > > 

> > > 

> > > I think this is acceptable penalty for keeping my system unpolluted and
> > > giving me easy opportunity to start from scratch if I messed up or if my
> > > dependencies have changed or what not.
> > 

> > Great! And you can keep doing that! That's a good thing to have. fedpkg 
> > local also works without network access, like on a train, if you have all 
> > your BuildRequires in place.
> 

> No difference here. Mock works fine without network, if you have your
> caches populated.

True.

Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?

> Vít
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:03 Gwyn Ciesla via devel napsal(a):



--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:00 AM, Vít Ondruch  
wrote:


Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):


On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:


Hi,
I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be the
preferred way. Would there be anybody really missing this functionality?
While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
not against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.

While there is certainly penalty in using mock, running repetitive
builds together with `--no-clean` option will hardly slow you down. Just
a few numbers.

1.  Starging from scratch after `mock --scrub=all`, every package have to
 be downloaded and installed:
 
 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
 
 ... snip ...
 
 real    0m47,188s

 user    0m41,841s
 sys    0m6,040s
 
 
2) With warm cache, only the BRs are installed, running right after the

previous build:

 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
 
 ... snip ...
 
 real    0m13,182s

 user    0m9,885s
 sys    0m2,701s
 
 
3) Without build root cleanup:


 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
 
 ... snip ...
 
 real    0m7,563s

 user    0m6,139s
 sys    0m1,194s
 
 
I think this is acceptable penalty for keeping my system unpolluted and

giving me easy opportunity to start from scratch if I messed up or if my
dependencies have changed or what not.



Great! And you can keep doing that! That's a good thing to have. fedpkg local 
also works without network access, like on a train, if you have all your 
BuildRequires in place.



No difference here. Mock works fine without network, if you have your 
caches populated.



Vít





OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 17:59 Colin Walters napsal(a):

On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch wrote:

You can do this in mock without messing with your system. You can use
`mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf
command you want to use`. You can use `mock your.srpm
--short-circuit=install` and similar. You can use `mock shell --unpriv`
if you want to tinker more. Mock is everything you ever wanted to
develop for Fedora.

So could you please share with us specifics of your workflow which
makes it unique and which really requires `fedpkg local`? I can't
imaging that intentionally breaking the host system due to testing
soname bump is the right thing to do.

Personally I spend 95% of my time inside an unprivileged pet "toolbox" style container
with podman; I very very rarely execute any commands on the "host" context.

I can imagine, I am using Mock as the "pet toolbox style container". For
Fedora development, `mock --init` is more convenient then `podman build`
or what is the right command.

And mock doesn't really nest well (nested containers in general are possible
but still involve some tricky compromises).

So I use `fedpkg local` a lot, and I also often install these packages into my
dev container *or* I just skip RPM entirely and `sudo make install`. For
CoreOS stuff I use
https://coreos.github.io/coreos-assembler/working/#using-overrides a lot which
makes it convenient to take these built binaries and launch them in qemu.

This of course gets into the broader overlap between mock/podman and
Koji/Kubernetes which is also touched on in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
=)

It'd all be much more obvious if the RPM buildroot was just:
```
FROM registry.fedoraproject.org/fedora-buildroot:33
RUN yum builddep foo.spec
RUN fedpkg local

I think this is problematic for Rawhide development, because I don't
think we have fresh image often enough. Once you have to used DNF/YUM,
you are loosing the advantage you could possibly get.

```
And so if you want a pristine build locally you just use a wrapper tool which
scripts unprivileged podman. (Yes, this loses RPM caching if done naively but
has other massive advantages, such as being able to trivially spin up a shell
on a remote Kube cluster that is *exactly* the build environment, etc.)

Thank you for sharing this perspective, because this is definitely
scenario I would have on my mind.

Vít

OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Fabio Valentini

On Wed, Jan 27, 2021 at 6:04 PM Gwyn Ciesla via devel
 wrote:
> Great! And you can keep doing that! That's a good thing to have. fedpkg local 
> also works without network access, like on a train, if you have all your 
> BuildRequires in place.

If that's all you want, why not use plain rpmbuild (either -ba for
.spec file or -ra for .src.rpm file)?

Additionally, with features like %generate_buildrequires becoming more
widely used, mock is certainly the easiest way to build those packages
...

Fabio
___
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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 11:00 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> 

> > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > 

> > > Hi,
> > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > `fedpkg local` command. I don't think it should be used. Mock should be 
> > > the
> > > preferred way. Would there be anybody really missing this functionality?
> > > While I understand that mock has the benefit of providing a well
> > > defined build environment, with less scope for things going wrong,
> > > that just isn't important to me most of the time. In fact I often
> > > want to build against what I have installed locally, explicitly
> > > not against what mock has in its build root.
> > 

> > So overall "fedpkg local" has the benefit that it is much faster
> > to run the build and simpler to get it to build what I want.
> 

> While there is certainly penalty in using mock, running repetitive
> builds together with `--no-clean` option will hardly slow you down. Just
> a few numbers.
> 

> 1.  Starging from scratch after `mock --scrub=all`, every package have to
> be downloaded and installed:
> 

> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 

> ... snip ...
> 

> real    0m47,188s
> user    0m41,841s
> sys    0m6,040s
> 

> 

> 

> 2) With warm cache, only the BRs are installed, running right after the
> previous build:
> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 

> ... snip ...
> 

> real    0m13,182s
> user    0m9,885s
> sys    0m2,701s
> 

> 

> 

> 3) Without build root cleanup:
> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm 
> -n
> 

> ... snip ...
> 

> real    0m7,563s
> user    0m6,139s
> sys    0m1,194s
> 

> 

> 

> I think this is acceptable penalty for keeping my system unpolluted and
> giving me easy opportunity to start from scratch if I messed up or if my
> dependencies have changed or what not.
> 


Great! And you can keep doing that! That's a good thing to have. fedpkg local 
also works without network access, like on a train, if you have all your 
BuildRequires in place.

> Vít
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

Actually, I forgot `mock --enablerepo=local some.srpm` which download 
the freshest packages for the build root directly from Koji.



Vít


Dne 27. 01. 21 v 17:50 Vít Ondruch napsal(a):


You can do this in mock without messing with your system. You can use 
`mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf 
command you want to use`. You can use `mock your.srpm 
--short-circuit=install` and similar. You can use `mock shell 
--unpriv` if you want to tinker more. Mock is everything you ever 
wanted to develop for Fedora.


So could you please share with us specifics of your workflow which 
makes it unique and which really requires `fedpkg local`? I can't 
imaging that intentionally breaking the host system due to testing 
soname bump is the right thing to do.



Vít


Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
"fedpkg local lets me cycle through build failures faster in the 
early stages"


Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
> wrote:





-- 
Gwyn Ciesla

she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini
mailto:decatho...@gmail.com>> wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org
 wrote:
>

> > It's needed for testing builds against versions of packages
not yet in mock. I use it almost every day. Losing it would make
things like testing solib bumps harder.
>

> I've done local test builds for soname bumps and similar things
lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean
environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle
through build failures faster in the early stages. I'd really
hate to see it go; If others don't use it, they can keep not
using it. :)

>

> Fabio
>

> 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





--
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.

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


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list --

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:

Hi,

I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be the
preferred way. Would there be anybody really missing this functionality?

While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
*not* against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.



While there is certainly penalty in using mock, running repetitive 
builds together with `--no-clean` option will hardly slow you down. Just 
a few numbers.


1) Starging from scratch after `mock --scrub=all`, every package have to 
be downloaded and installed:


~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm

... snip ...

real    0m47,188s
user    0m41,841s
sys    0m6,040s

~~~


2) With warm cache, only the BRs are installed, running right after the 
previous build:


~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm

... snip ...

real    0m13,182s
user    0m9,885s
sys    0m2,701s

~~~


3) Without build root cleanup:

~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n

... snip ...

real    0m7,563s
user    0m6,139s
sys    0m1,194s

~~~


I think this is acceptable penalty for keeping my system unpolluted and 
giving me easy opportunity to start from scratch if I messed up or if my 
dependencies have changed or what not.




Vít





OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Colin Walters

On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch wrote:
> You can do this in mock without messing with your system. You can use 
> `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf 
> command you want to use`. You can use `mock your.srpm 
> --short-circuit=install` and similar. You can use `mock shell --unpriv` 
> if you want to tinker more. Mock is everything you ever wanted to 
> develop for Fedora.
> 
> So could you please share with us specifics of your workflow which 
> makes it unique and which really requires `fedpkg local`? I can't 
> imaging that intentionally breaking the host system due to testing 
> soname bump is the right thing to do.

Personally I spend 95% of my time inside an unprivileged pet "toolbox" style 
container with podman; I very very rarely execute any commands on the "host" 
context.

And mock doesn't really nest well (nested containers in general are possible 
but still involve some tricky compromises).

So I use `fedpkg local` a lot, and I also often install these packages into my 
dev container *or* I just skip RPM entirely and `sudo make install`.  For 
CoreOS stuff I use 
https://coreos.github.io/coreos-assembler/working/#using-overrides a lot which 
makes it convenient to take these built binaries and launch them in qemu.

This of course gets into the broader overlap between mock/podman and 
Koji/Kubernetes which is also touched on in 
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
 =)

It'd all be much more obvious if the RPM buildroot was just:
```
FROM registry.fedoraproject.org/fedora-buildroot:33
RUN yum builddep foo.spec
RUN fedpkg local
```
And so if you want a pristine build locally you just use a wrapper tool which 
scripts unprivileged podman.  (Yes, this loses RPM caching if done naively but 
has other massive advantages, such as being able to trivially spin up a shell 
on a remote Kube cluster that is *exactly* the build environment, etc.)

___
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: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch  
wrote:

> You can do this in mock without messing with your system. You can use `mock 
> -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command you want 
> to use`. You can use `mock your.srpm --short-circuit=install` and similar. 
> You can use `mock shell --unpriv` if you want to tinker more. Mock is 
> everything you ever wanted to develop for Fedora.
> 

> So could you please share with us specifics of your workflow which makes it 
> unique and which really requires `fedpkg local`? I can't imaging that 
> intentionally breaking the host system due to testing soname bump is the 
> right thing to do.

Ok, let's say I have to update a library, let's say LibRaw, and the soname 
changes.

I fire up a rawhide VM, and clone the LibRaw repo, update the spec, build, and 
install it. Then I clone the dependant repos, update their specs, and build 
them.  Failures are immediately apparent, and I can quickly work on patches or 
obtain logs of failures for sending upstream. I can easily get into the source 
tree to examine files, quickly test tweaks to build commands, etc. Once it all 
builds, I do a mock chain build, then an srpm koji scratch build, and if all is 
well, I commit, push, and chain-build in koji.

I always use mock for final smoketesting and rooting out missed BuildRequires, 
but being forced to use mock for the whole process would greatly lengthen the 
process.

> Vít
> 

> Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
> 

> > "fedpkg local lets me cycle through build failures faster in the early 
> > stages"
> > 

> > Totally agree.
> > 

> > On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
> >  wrote:
> > 

> > > -- 
> > > Gwyn Ciesla
> > > she/her/hers
> > >  
> > > in your fear, seek only peace 
> > > in your fear, seek only love
> > > -d. bowie
> > > 

> > > Sent with ProtonMail Secure Email.
> > > 

> > > ‐‐‐ Original Message ‐‐‐
> > > On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini 
> > >  wrote:
> > > 

> > > > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> > > > devel@lists.fedoraproject.org wrote:
> > > >
> > > 

> > > > > It's needed for testing builds against versions of packages not yet 
> > > > > in mock. I use it almost every day. Losing it would make things like 
> > > > > testing solib bumps harder.
> > > >
> > > 

> > > > I've done local test builds for soname bumps and similar things lots
> > > > of times, and I've never used (or thought about using) fedpkg local
> > > > for that.
> > > > I used "mock --chain" or a combination of "mock --postinstall
> > > > --no-clean" for those builds ... which is much closer to what koji
> > > > will do with your builds, and gives every build the clean environment
> > > > it deserves >:-)
> > > 

> > > That's a great thing to do, but fedpkg local lets me cycle through build 
> > > failures faster in the early stages. I'd really hate to see it go; If 
> > > others don't use it, they can keep not using it. :)
> > > 

> > > >
> > > 

> > > > Fabio
> > > >
> > > 

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

> > --
> > 

> > --
> > -
> > 

> > Radovan Sroka
> > Software Engineer | Security Technologies | Red Hat, Inc.
> > 

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



signature.asc
Description: OpenPGP digital signature
___
devel mailing

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Dan Horák

On Wed, 27 Jan 2021 16:43:35 +
Daniel P. Berrangé  wrote:

> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> >  wrote:
> > >
> > > It's needed for testing builds against versions of packages not yet in 
> > > mock. I use it almost every day. Losing it would make things like testing 
> > > solib bumps harder.
> > 
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 

that describes my workflow too :-)


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

Re: Proposal to deprecated `fedpkg local`

You can do this in mock without messing with your system. You can use 
`mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command 
you want to use`. You can use `mock your.srpm --short-circuit=install` 
and similar. You can use `mock shell --unpriv` if you want to tinker 
more. Mock is everything you ever wanted to develop for Fedora.


So could you please share with us specifics of your workflow which makes 
it unique and which really requires `fedpkg local`? I can't imaging that 
intentionally breaking the host system due to testing soname bump is the 
right thing to do.



Vít


Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
"fedpkg local lets me cycle through build failures faster in the early 
stages"


Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:





-- 
Gwyn Ciesla

she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini
mailto:decatho...@gmail.com>> wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org
 wrote:
>

> > It's needed for testing builds against versions of packages
not yet in mock. I use it almost every day. Losing it would make
things like testing solib bumps harder.
>

> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean
environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle through
build failures faster in the early stages. I'd really hate to see
it go; If others don't use it, they can keep not using it. :)

>

> Fabio
>

> 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





--
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.

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


OpenPGP_signature
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
>  wrote:
> >
> > It's needed for testing builds against versions of packages not yet in 
> > mock. I use it almost every day. Losing it would make things like testing 
> > solib bumps harder.
> 
> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean environment
> it deserves >:-)

If you want to closely replicate that koji will do, then no disagreement
that use of mock is the right tool (or just a koji scratch-build). That
just isn't a requirement much of the time though.

For adhoc development and debugging of RPM spec changes/updates, mock
gets in the way and slows things down. I could easily do 10-20 "local"
runs while getting an complex change working, and then finish off with
just one or two mock build or koji scratch-build to validate it in a
pristine build root env at the end. 


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

[Bug 1921174] New: perl-Mojolicious-8.72 is available

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

Bug ID: 1921174
   Summary: perl-Mojolicious-8.72 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 8.72
Current version/release in rawhide: 8.71-1.fc34
URL: https://metacpan.org/release/Mojolicious

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


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be the
> preferred way. Would there be anybody really missing this functionality?

While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
*not* against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.

I view these ways of building as targetting partially overlapping
sets - neither can handle all scenarios effectively, so both are
desirable to have.

IOW by all means steer people towards use of mock as the preferred
option to avoid less experienced people getting burnt by local
install problems, but please don't take away "fedpkg local" as I
use it practically every day.

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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Radovan Sroka

"fedpkg local lets me cycle through build failures faster in the early
stages"

Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:

>
>
>
> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini <
> decatho...@gmail.com> wrote:
>
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> > devel@lists.fedoraproject.org wrote:
> >
>
> > > It's needed for testing builds against versions of packages not yet in
> mock. I use it almost every day. Losing it would make things like testing
> solib bumps harder.
> >
>
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
>
> That's a great thing to do, but fedpkg local lets me cycle through build
> failures faster in the early stages. I'd really hate to see it go; If
> others don't use it, they can keep not using it. :)
>
> >
>
> > Fabio
> >
>
> > 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
>


-- 
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote:
> https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List

I have updated 
https://fedoraproject.org/wiki/Mailing_list_guidelines#Commercial_messages
to be more clear.


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

Re: Proposal to deprecated `fedpkg local`




-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini  
wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org wrote:
> 

> > It's needed for testing builds against versions of packages not yet in 
> > mock. I use it almost every day. Losing it would make things like testing 
> > solib bumps harder.
> 

> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle through build 
failures faster in the early stages. I'd really hate to see it go; If others 
don't use it, they can keep not using it. :)

> 

> Fabio
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Fabio Valentini

On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
 wrote:
>
> It's needed for testing builds against versions of packages not yet in mock. 
> I use it almost every day. Losing it would make things like testing solib 
> bumps harder.

I've done local test builds for soname bumps and similar things lots
of times, and I've never used (or thought about using) fedpkg local
for that.
I used "mock --chain" or a combination of "mock --postinstall
--no-clean" for those builds ... which is much closer to what koji
will do with your builds, and gives every build the clean environment
it deserves >:-)

Fabio
___
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: Proposal to deprecated `fedpkg local`

It's needed for testing builds against versions of packages not yet in mock. I 
use it almost every day. Losing it would make things like testing solib bumps 
harder.


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, January 27, 2021 10:17 AM, Vít Ondruch  
wrote:

> Hi,
> 

> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?
> 

> Vít
> 

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



signature.asc
Description: OpenPGP digital 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: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Fabio Valentini

On Wed, Jan 27, 2021 at 5:17 PM Vít Ondruch  wrote:
>
> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?

I would certainly not miss it, and it would cause much less confusion
for new packagers if it was not there, in my experience.
So +1 to deprecating / removing the "local" command, or even making it
print "This used to be a dangerous command, and is probably not what
you want. Please use the mockbuild command instead".

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

Proposal to deprecated `fedpkg local`


Hi,

I wonder, what would be the sentiment if I proposed to deprecated the 
`fedpkg local` command. I don't think it should be used. Mock should be 
the preferred way. Would there be anybody really missing this functionality?



Vít




OpenPGP_signature
Description: OpenPGP digital 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: COMMERCIAL - Bosch - Architect

2021-01-27 Thread George Bastin

Sorry Marius, it is not a violation of any law. 

You address is on a public mailing list, which anyone in the world can contact.

I apologise if any offence was caused.

-Original Message-
From: PGNet Dev  
Sent: 27 January 2021 16:06
To: fedora...@cloud-foo.de; devel@lists.fedoraproject.org
Subject: Re: COMMERCIAL - Bosch - Architect

And you're spamming MY 'private mailbox' now?

Who made you the consumer police?

Now, get lost, troll.

On 1/27/21 11:01 AM, Marius Schwarz wrote:
> Am 27.01.21 um 16:53 schrieb PGNet Dev:
>>
>> And that somehow justifies 'notifying the legal department' as a 1st 
>> response?
> 
> Yeap, because he spammed my private mailbox too.  As an Ex-Bosch employe i 
> know that Bosch is a good company, who won't tolerate spamming in their name 
> and it was also a violation of customer protection laws in Germany. He can be 
> happy, that it didn't go directly to the feds.
> 
> How a about a public -1 now?
> 
> Best regards,
> Marius
___
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: COMMERCIAL - Bosch - Architect

2021-01-27 Thread PGNet Dev


And you're spamming MY 'private mailbox' now?

Who made you the consumer police?

Now, get lost, troll.

On 1/27/21 11:01 AM, Marius Schwarz wrote:

Am 27.01.21 um 16:53 schrieb PGNet Dev:


And that somehow justifies 'notifying the legal department' as a 1st response?


Yeap, because he spammed my private mailbox too.  As an Ex-Bosch employe i know 
that Bosch is a good company, who won't tolerate spamming in their name and it 
was also a violation of customer protection laws in Germany. He can be happy, 
that it didn't go directly to the feds.

How a about a public -1 now?

Best regards,
Marius

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

[Bug 1915252] perl-Tie-Cycle-1.226 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Tie-Cycle-1.226-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-01-27 16:01:48




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2021-01-27)

2021-01-27 Thread Neal Gompa

=
#fedora-meeting-2: FESCO (2021-01-27)
=


Meeting started by King_InuYasha at 15:01:56 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-27/fesco.2021-01-27-15.01.log.html
.



Meeting summary
---
* init process  (King_InuYasha, 15:02:28)

* #2545 F34 Change: Localization measurement and tooling
  (King_InuYasha, 15:06:56)
  * AGREED: Localization measurement tooling makes sense to have, given
that the localization team is developing and maintaining it (+7, 0,
-0)  (King_InuYasha, 15:17:38)

* #2547 F34 Change: Signed RPM Contents  (King_InuYasha, 15:18:55)
  * AGREED: This change is rejected for F34, please resubmit again for
the F35 cycle, ideally amended wrt the received feedback (+7, 0, 0)
(King_InuYasha, 15:27:32)

* Next week's chair  (King_InuYasha, 15:28:13)
  * ACTION: zbyszek will chair next meeting  (King_InuYasha, 15:35:17)

* Open Floor  (King_InuYasha, 15:35:32)
  * LINK:
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html
(mhroncok, 15:36:23)
  * LINK: https://pagure.io/releng/fedora-scm-requests/issue/31913 has
rawhide in the body I'll s ehow it is processed  (mhroncok,
15:41:26)
  * LINK: https://koji.fedoraproject.org/koji/taskinfo?taskID=60535019
(zbyszek, 15:46:14)

Meeting ended at 15:52:57 UTC.




Action Items

* zbyszek will chair next meeting




Action Items, by person
---
* zbyszek
  * zbyszek will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* King_InuYasha (48)
* mhroncok (29)
* nirik (24)
* zbyszek (18)
* zodbot (17)
* decathorpe (11)
* bcotton (6)
* sgallagh (4)
* dcantrell (4)
* cverna (2)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


-- 
Neal Gompa (FAS: ngompa)
___
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: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 10:53:52AM -0500, PGNet Dev wrote:
> And that somehow justifies 'notifying the legal department' as a 1st response?

No. I agree that that's an overreaction. 

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

[EPEL-devel] Re: RHEL contacting EPEL maintainers when package goes into RHEL


On 20. 01. 21 15:27, Troy Dawson wrote:

This last week in the EPEL Steering Committee meeting, we talked about
what happens when an EPEL package gets pulled in and released in RHEL.
There were a couple of people who said that had happened to them and
they were totally un-aware that it was going to happen.

I contacted a couple people in Red Hat and found out that part of the
New Package procedure includes an EPEL check.  If the package is in
EPEL they are supposed to contact the EPEL maintainer.  They are also
supposed to have the NVR higher than the EPEL version.

This is a new procedure, implemented in June 2020.

If you are a EPEL package maintainer, and your package was pulled into
RHEL 7 or 8, and you were not contacted, please let me know.  Red Hat
wants this procedure to work, because when things go wrong, it affects
their customers.

Their current way of finding out who to contact is to do the following

   curl https://src.fedoraproject.org/_dg/bzoverrides/rpms/
example
  $ curl https://src.fedoraproject.org/_dg/bzoverrides/rpms/git-lfs
   {
 "epel_assignee": "carlwgeorge",
 "fedora_assignee": "qulogic"
   }

If anyone knows of a better way to find the EPEL maintainer, please
let me know and I'll pass it on.


Apparently, the EPEL maintainer receives an automated message like this:


This is an email notification that the new package: pybind11 is being
added to RHEL 8.4.0 and also exists in EPEL 8. You may want to remove
pybind11 from EPEL 8 or at least confirm that the pybind11
Version-Release will cleanly upgrade from and replace the EPEL package.


This also happens when the package is only added to a modular non-default 
stream. Is there a way the message could be adapted to:


 - discourage immediate retirement (RHEL 8.4 is not yet out, also CentOS Linux)
 - mention that removal is not always desired (especially with modular packages)

?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: COMMERCIAL - Bosch - Architect

2021-01-27 Thread PGNet Dev


On 1/27/21 10:44 AM, Matthew Miller wrote:

On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote:

I thought it was a public mailing list, I noted the subject was Commercial
in the Header as stated on the Fedora Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List



Sure seems reasonable to a 1st read here.

At best the 'Guidelines' lack clarity.




That paragraph doesn't mean that the list can be used for general commercial 
messages.
https://fedoraproject.org/wiki/Mailing_list_guidelines#Stay_on-topic still
also applies. If this job posting is directly relevant to Fedora (rather
than just "some people in Fedora may have relevant skills"), that should be
directly called out.


And that somehow justifies 'notifying the legal department' as a 1st response?



However, going out of your way to try to sabotage another person’s livelihood 
is way out of line.


+1 to that.
___
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: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote:
> I thought it was a public mailing list, I noted the subject was Commercial
> in the Header as stated on the Fedora Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List

That paragraph doesn't mean that the list can be used for general commercial 
messages.
https://fedoraproject.org/wiki/Mailing_list_guidelines#Stay_on-topic still
also applies. If this job posting is directly relevant to Fedora (rather
than just "some people in Fedora may have relevant skills"), that should be
directly called out.

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

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-27 Thread Neal Gompa

On Wed, Jan 27, 2021 at 2:14 AM Pavel Raiskup  wrote:
>
> On Tuesday, January 26, 2021 9:46:49 PM CET Neal Gompa wrote:
> > Yes. This is breaking *everything*. Regardless of whether the plugin
> > is installed, RPM now thinks the generated packages are invalid and
> > cannot do anything with them. This has also broken package builds on
> > COPR and the openSUSE Build Service.
>
> Can't speak for OBS, but Fedora Copr has builders on Fedora 33 for some
> time.  What issues do you have in mind, I thought that RPM on F33 should
> be OK?
>

The openSUSE Build Service runs on SUSE Linux Enterprise 15, which is
afflicted in the same way that RHEL 8 is, since they have the same
version of RPM.


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

Solved: new koji problem: 404 errors on downloadlinks

2021-01-27 Thread Marius Schwarz


Am 27.01.21 um 16:29 schrieb Marius Schwarz:



https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

which just retruns a 404:

$ curl -I 
http://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Wed,*27 Jan 2021 15:28:45 GMT***


looks like it got fixed @15:40 GMT


best regards,
Marius


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

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote:
> And this would be on EVERYBODY's database whether you use the
> feature or not, also slowing down every single rpm query somewhat as
> a whole lot more data has to be pulled from disk, and there's no way
> to get rid of the weight once its there. The height of the insult is
> that the data is essentially useless in the rpmdb, it's only
> relevant during installation, for the (presumably few) people who
> actually enable the feature. And of course that extra weight in
> every single package is carried around in mirrors and each and every
> package download too, again whether you use the feature or not.

It seems like having this in a separate database that is pulled down on
demand would basically solve the problem.


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

RE: COMMERCIAL - Bosch - Architect

2021-01-27 Thread George Bastin

Apologies Marius

I thought it was a public mailing list, I noted the subject was Commercial in 
the Header as stated on the Fedora Guidelines:

https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List

However, going out of your way to try to sabotage another person’s livelihood 
is way out of line.


George


From: Marius Schwarz 
Sent: 27 January 2021 15:27
To: devel@lists.fedoraproject.org
Subject: Re: COMMERCIAL - Bosch - Architect

Am 27.01.21 um 15:37 schrieb Stephen John Smoogen:

The following is an official statement.

This list is NOT meant for these sorts of emails. Please do not post either CV 
or requests for hiring on this list. We will be deleting all further posts in 
this vein


The legal departement of Bosch has already informed yesterday.

best regards,
Marius
___
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

new koji problem: 404 errors on downloadlinks

2021-01-27 Thread Marius Schwarz



The new firefox build 85.0.4 :

https://koji.fedoraproject.org/koji/buildinfo?buildID=1680475

offers this link:

https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

which just retruns a 404:

$ curl -I 
http://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Wed,*27 Jan 2021 15:28:45 GMT**
*

best regards,
Marius

___
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: COMMERCIAL - Bosch - Architect

2021-01-27 Thread Marius Schwarz


Am 27.01.21 um 15:37 schrieb Stephen John Smoogen:


The following is an official statement.

This list is NOT meant for these sorts of emails. Please do not post 
either CV or requests for hiring on this list. We will be deleting all 
further posts in this vein




The legal departement of Bosch has already informed yesterday.

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

[Bug 1921135] New: Upgrade perl-Test-Inline to 2.214

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

Bug ID: 1921135
   Summary: Upgrade perl-Test-Inline to 2.214
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Inline
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, lxt...@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.213 version. Upstream released 2.214. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git



On 1/27/21 2:22 PM, Miro Hrončok wrote:
> On 27. 01. 21 13:45, Petr Menšík wrote:
>> I think one reason against maintainer's pull requests is poor tooling to
>> work with them. Filled fedpkg proposal to include ability to fork and
>> add personal fork to current repository or add when cloning [1].
>> I think current way discourages its use, because too many manual steps
>> have to be done before making PR.
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1920997
>>
>> On 1/25/21 4:30 PM, Miro Hrončok wrote:
...
>>
>> Is there already way to configure maintainer's fork branch to auto merge
>> and production build, once CI finishes successfully?
>>
>> I think adding required steps into build process, where developer has to
>> watch for results and make manual steps is the problem. If I could just
>> push my change to my fork and let it autoprocess, I would use it when
>> not in hurry. But I demand first not involving multiple manual steps to
>> make production built from PR.
>>
>> Could there be way as a maintainer to add a comment [build] to merged
>> PR, and pagure would start a new build? I think it does not matter who
>> started the build, but whose changes are included.
>>
>> If I could just mark good looking changes and it would try to process
>> it, just notifying me whether successfully or not, I would use PR more
>> often. If I have to watch PR CI results myself and do manual steps
>> depending of its result, it discourages me. Would like some bot to do
>> that.
>>
>> There seems to be support for [citest] for retriggering CI on package.
>> Could something similar be used to autobuild PR of people with commit
>> rights on explicitly enabled branches?
> 
> Zuul can merge and build PRs automatically when CI passes.
> 
> https://fedoraproject.org/wiki/Zuul-based-ci
> 

Great! Never heard of this.

It seems somehow clumsy to be configured just for personal forks, but it
seems it provides required features. Configuration seems more
complicated than I would like, but I will try to use it for some proof
of concept. Thanks for mentioning it.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
Description: OpenPGP digital 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

Schedule for Wednesday's FESCo Meeting (2021-01-27)

2021-01-27 Thread Neal Gompa

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2021-01-27 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Title of issue
https://pagure.io/fesco/issue/###
DECISION (+X, Y, -Z)

F34 Change: LXQt 0.16.0
https://pagure.io/fesco/issue/2546
DECISION (+5, 0, -0)

Proposal for voting: Gate critical path update pushes on openQA test results
https://pagure.io/fesco/issue/2548
DECISION (+8, 0, -0)

Proposal: maintaining provenpackager status
https://pagure.io/fesco/issue/2549
DECISION (+7, 0, -0)

F35 Change: PHP 8.0
https://pagure.io/fesco/issue/2550
DECISION (+6, 0, -0)

F34 Change: Comp Neuro Container Image
https://pagure.io/fesco/issue/2553
DECISION (+8, 0, -0)

F34 Change: Scale ZRAM to Full Memory Size
https://pagure.io/fesco/issue/2554
DECISION (+7, 0, -0)

Request to postpone the mass rebuild to Jan 25th, 2021
https://pagure.io/fesco/issue/2555
DECISION (+8, 0, -0)

= Followups =

#2545 F34 Change: Localization measurement and tooling
https://pagure.io/fesco/issue/2545

#2547 F34 Change: Signed RPM Contents
https://pagure.io/fesco/issue/2547

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

-- 
Neal Gompa (FAS: ngompa)
___
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: COMMERCIAL - Bosch - Architect

2021-01-27 Thread Stephen John Smoogen

The following is an official statement.

On Wed, 27 Jan 2021 at 09:10, George Bastin 
wrote:

> Dear colleagues at Fedora,
>
>
>
> I am hoping to discuss a *Senior Security and Systems
> Architect/Engineering* opportunity I am working on directly with *Robert
> Bosch Car Multimedia GmbH* with you!
>
>
>
> The position has a strong focus on *Open Source Technologies*, and Bosch
> need someone who is highly skilled and passionate in this area.
>
>
>

This list is NOT meant for these sorts of emails. Please do not post either
CV or requests for hiring on this list. We will be deleting all further
posts in this vein


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

Python Classroom Lab help needed: proj-data is suddenly 569M


Hello,

when debugging an unexpected significant file size grow of the Python Classroom 
Lab [1], I've realized the following package changes since Fedora 33:


 proj
-proj-datumgrid
+proj-data-at
+proj-data-au
+proj-data-be
+proj-data-br
+proj-data-ca
+proj-data-ch
+proj-data-de
+proj-data-dk
+proj-data-es
+proj-data-eur
+proj-data-fi
+proj-data-fo
+proj-data-fr
+proj-data-is
+proj-data-jp
+proj-data-nc
+proj-data-nl
+proj-data-nz
+proj-data-pt
+proj-data-se
+proj-data-sk
+proj-data-uk
+proj-data-us

And /usr/share/proj is huge:

[fedora-34]$ du -h /usr/share/proj
569M/usr/share/proj

[fedora-33]$ du -h /usr/share/proj
14M /usr/share/proj


When I attempt to remove proj, I get:

===
 Package   Arch  VersionRepositorySize
===
Removing:
 proj  x86_647.2.1-1.fc34   @anaconda 13 M
Removing dependent packages:
 python3-gdal  x86_643.2.1-3.fc34   @anaconda4.1 M
Removing unused dependencies:
 SuperLU   x86_645.2.1-14.fc33  @anaconda467 k
 armadillo x86_6410.1.2-1.fc34  @anaconda 99 k
 arpackx86_643.7.0-8.fc33   @anaconda625 k
 cfitsio   x86_643.470-3.fc33   @anaconda1.7 M
 freexlx86_641.0.6-1.fc33   @anaconda 70 k
 gdal-libs x86_643.2.1-3.fc34   @anaconda 26 M
 geos  x86_643.9.0-1.fc34   @anaconda2.2 M
 hdf-libs  x86_644.2.15-3.fc33  @anaconda682 k
 libdapx86_643.20.6-2.fc33  @anaconda2.1 M
 libgeotiffx86_641.6.0-3.fc34   @anaconda344 k
 libgtax86_641.0.9-5.fc33   @anaconda 75 k
 libkmlx86_641.3.0-29.fc33  @anaconda1.2 M
 libpq x86_6413.1-1.fc34@anaconda715 k
 librttopo x86_641.1.0-1.fc34   @anaconda518 k
 libspatialite x86_645.0.0-3.fc34   @anaconda 16 M
 mariadb-connector-c   x86_643.1.11-1.fc34  @anaconda539 k
 mariadb-connector-c-confignoarch3.1.11-1.fc34  @anaconda497
 minizip   x86_642.10.2-1.fc34  @anaconda354 k
 netcdfx86_644.7.3-5.fc34   @anaconda1.9 M
 ogdi  x86_644.1.0-4.fc33   @anaconda871 k
 proj-data-at  noarch7.2.1-1.fc34   @anaconda2.1 M
 proj-data-au  noarch7.2.1-1.fc34   @anaconda118 M
 proj-data-be  noarch7.2.1-1.fc34   @anaconda749 k
 proj-data-br  noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-ca  noarch7.2.1-1.fc34   @anaconda 94 M
 proj-data-ch  noarch7.2.1-1.fc34   @anaconda1.6 M
 proj-data-de  noarch7.2.1-1.fc34   @anaconda 74 M
 proj-data-dk  noarch7.2.1-1.fc34   @anaconda9.9 M
 proj-data-es  noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-eur noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-fi  noarch7.2.1-1.fc34   @anaconda288 k
 proj-data-fo  noarch7.2.1-1.fc34   @anaconda1.5 k
 proj-data-fr  noarch7.2.1-1.fc34   @anaconda1.2 M
 proj-data-is  noarch7.2.1-1.fc34   @anaconda5.5 M
 proj-data-jp  noarch7.2.1-1.fc34   @anaconda420 k
 proj-data-nc  noarch7.2.1-1.fc34   @anaconda1.1 M
 proj-data-nl  noarch7.2.1-1.fc34   @anaconda1.1 M
 proj-data-nz  noarch7.2.1-1.fc34   @anaconda 14 M
 proj-data-pt  noarch7.2.1-1.fc34   @anaconda431 k
 proj-data-se  noarch7.2.1-1.fc34   @anaconda2.2 M
 proj-data-sk  noarch7.2.1-1.fc34   @anaconda1.2 M
 proj-data-uk  noarch7.2.1-1.fc34   @anaconda4.8 M
 proj-data-us  noarch7.2.1-1.fc34   @anaconda224 M
 unixODBC  x86_642.3.9-1.fc34   @anaconda1.4 M
 uriparser x86_640.9.4-2.fc33   @anaconda160 k
 xerces-c  x86_643.2.3-2.fc33   @anaconda3.5 M

Transaction Summary
===
Remove  48 Packages

Freed space: 637 M


When I only remove the data, I get:

Python Classroom Lab help needed: proj-data is suddenly 569M


Hello,

when debugging an unexpected significant file size grow of the Python Classroom 
Lab [1], I've realized the following package changes since Fedora 33:


 proj
-proj-datumgrid
+proj-data-at
+proj-data-au
+proj-data-be
+proj-data-br
+proj-data-ca
+proj-data-ch
+proj-data-de
+proj-data-dk
+proj-data-es
+proj-data-eur
+proj-data-fi
+proj-data-fo
+proj-data-fr
+proj-data-is
+proj-data-jp
+proj-data-nc
+proj-data-nl
+proj-data-nz
+proj-data-pt
+proj-data-se
+proj-data-sk
+proj-data-uk
+proj-data-us

And /usr/share/proj is huge:

[fedora-34]$ du -h /usr/share/proj
569M/usr/share/proj

[fedora-33]$ du -h /usr/share/proj
14M /usr/share/proj


When I attempt to remove proj, I get:

===
 Package   Arch  VersionRepositorySize
===
Removing:
 proj  x86_647.2.1-1.fc34   @anaconda 13 M
Removing dependent packages:
 python3-gdal  x86_643.2.1-3.fc34   @anaconda4.1 M
Removing unused dependencies:
 SuperLU   x86_645.2.1-14.fc33  @anaconda467 k
 armadillo x86_6410.1.2-1.fc34  @anaconda 99 k
 arpackx86_643.7.0-8.fc33   @anaconda625 k
 cfitsio   x86_643.470-3.fc33   @anaconda1.7 M
 freexlx86_641.0.6-1.fc33   @anaconda 70 k
 gdal-libs x86_643.2.1-3.fc34   @anaconda 26 M
 geos  x86_643.9.0-1.fc34   @anaconda2.2 M
 hdf-libs  x86_644.2.15-3.fc33  @anaconda682 k
 libdapx86_643.20.6-2.fc33  @anaconda2.1 M
 libgeotiffx86_641.6.0-3.fc34   @anaconda344 k
 libgtax86_641.0.9-5.fc33   @anaconda 75 k
 libkmlx86_641.3.0-29.fc33  @anaconda1.2 M
 libpq x86_6413.1-1.fc34@anaconda715 k
 librttopo x86_641.1.0-1.fc34   @anaconda518 k
 libspatialite x86_645.0.0-3.fc34   @anaconda 16 M
 mariadb-connector-c   x86_643.1.11-1.fc34  @anaconda539 k
 mariadb-connector-c-confignoarch3.1.11-1.fc34  @anaconda497
 minizip   x86_642.10.2-1.fc34  @anaconda354 k
 netcdfx86_644.7.3-5.fc34   @anaconda1.9 M
 ogdi  x86_644.1.0-4.fc33   @anaconda871 k
 proj-data-at  noarch7.2.1-1.fc34   @anaconda2.1 M
 proj-data-au  noarch7.2.1-1.fc34   @anaconda118 M
 proj-data-be  noarch7.2.1-1.fc34   @anaconda749 k
 proj-data-br  noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-ca  noarch7.2.1-1.fc34   @anaconda 94 M
 proj-data-ch  noarch7.2.1-1.fc34   @anaconda1.6 M
 proj-data-de  noarch7.2.1-1.fc34   @anaconda 74 M
 proj-data-dk  noarch7.2.1-1.fc34   @anaconda9.9 M
 proj-data-es  noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-eur noarch7.2.1-1.fc34   @anaconda1.0 M
 proj-data-fi  noarch7.2.1-1.fc34   @anaconda288 k
 proj-data-fo  noarch7.2.1-1.fc34   @anaconda1.5 k
 proj-data-fr  noarch7.2.1-1.fc34   @anaconda1.2 M
 proj-data-is  noarch7.2.1-1.fc34   @anaconda5.5 M
 proj-data-jp  noarch7.2.1-1.fc34   @anaconda420 k
 proj-data-nc  noarch7.2.1-1.fc34   @anaconda1.1 M
 proj-data-nl  noarch7.2.1-1.fc34   @anaconda1.1 M
 proj-data-nz  noarch7.2.1-1.fc34   @anaconda 14 M
 proj-data-pt  noarch7.2.1-1.fc34   @anaconda431 k
 proj-data-se  noarch7.2.1-1.fc34   @anaconda2.2 M
 proj-data-sk  noarch7.2.1-1.fc34   @anaconda1.2 M
 proj-data-uk  noarch7.2.1-1.fc34   @anaconda4.8 M
 proj-data-us  noarch7.2.1-1.fc34   @anaconda224 M
 unixODBC  x86_642.3.9-1.fc34   @anaconda1.4 M
 uriparser x86_640.9.4-2.fc33   @anaconda160 k
 xerces-c  x86_643.2.3-2.fc33   @anaconda3.5 M

Transaction Summary
===
Remove  48 Packages

Freed space: 637 M


When I only remove the data, I get:

Re: COMMERCIAL - Bosch - Architect

2021-01-27 Thread Nurmukhamed Artykaly

Hello
May you consider my cv

https://www.hdfilm.kz/cv.pdf

Отправлено с iPhone

> 27 янв. 2021 г., в 20:09, George Bastin  
> написал(а):
> 
> 
> Dear colleagues at Fedora,
>  
> I am hoping to discuss a Senior Security and Systems Architect/Engineering 
> opportunity I am working on directly with Robert Bosch Car Multimedia GmbH 
> with you!
>  
> The position has a strong focus on Open Source Technologies, and Bosch need 
> someone who is highly skilled and passionate in this area.
>  
> It is an ideal role for a Package Maintainer.
>  
> The salary ranges from 80,000 EUR – 120,000 EUR + Bonus and benefits.
>  
> Would you be open to considering a relocation to Germany?
>  
> Please do forward a copy of your CV to review, and I can happily give you a 
> brief call to discuss.
>  
>  
> George Bastin
> geo...@luckhurstdigital.com
> +447500058379
>  
> ___
> 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

COMMERCIAL - Bosch - Architect

2021-01-27 Thread George Bastin

Dear colleagues at Fedora,

I am hoping to discuss a Senior Security and Systems Architect/Engineering 
opportunity I am working on directly with Robert Bosch Car Multimedia GmbH with 
you!

The position has a strong focus on Open Source Technologies, and Bosch need 
someone who is highly skilled and passionate in this area.

It is an ideal role for a Package Maintainer.

The salary ranges from 80,000 EUR – 120,000 EUR + Bonus and benefits.

Would you be open to considering a relocation to Germany?

Please do forward a copy of your CV to review, and I can happily give you a 
brief call to discuss.


George Bastin
geo...@luckhurstdigital.com
+447500058379

___
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

Container Plumbing Days call for speakers.

2021-01-27 Thread Daniel Walsh

Announcing Free Open Source Micro Virtual Conference `Container Plumbing 
Days` sponsored byRed Hat. March 9-10, 2021. Looking for speakers. Low 
level talks, from the container engine down to the OS. Not orchestrators.


http://containerplumbing.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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git


On 27. 01. 21 13:45, Petr Menšík wrote:

I think one reason against maintainer's pull requests is poor tooling to
work with them. Filled fedpkg proposal to include ability to fork and
add personal fork to current repository or add when cloning [1].
I think current way discourages its use, because too many manual steps
have to be done before making PR.

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

On 1/25/21 4:30 PM, Miro Hrončok wrote:

On 25. 01. 21 16:19, Stephen Gallagher wrote:

I'm fully in favor of this and I'd really like to see us add some
degree of CI gating to support it.


Note that unfortunately CI gating happens too late. It has no capability
to block commits that fail to build, because it only tests successful
builds and because it only tests already pushed changes. CI on Pull
Requests can solve this, but many packagers seem to be very much agianst
the idea of sending PRs to packages they maintain themselves :(



Is there already way to configure maintainer's fork branch to auto merge
and production build, once CI finishes successfully?

I think adding required steps into build process, where developer has to
watch for results and make manual steps is the problem. If I could just
push my change to my fork and let it autoprocess, I would use it when
not in hurry. But I demand first not involving multiple manual steps to
make production built from PR.

Could there be way as a maintainer to add a comment [build] to merged
PR, and pagure would start a new build? I think it does not matter who
started the build, but whose changes are included.

If I could just mark good looking changes and it would try to process
it, just notifying me whether successfully or not, I would use PR more
often. If I have to watch PR CI results myself and do manual steps
depending of its result, it discourages me. Would like some bot to do that.

There seems to be support for [citest] for retriggering CI on package.
Could something similar be used to autobuild PR of people with commit
rights on explicitly enabled branches?


Zuul can merge and build PRs automatically when CI passes.

https://fedoraproject.org/wiki/Zuul-based-ci

--
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: unrecognized DWARF version in .debug_info at 6

2021-01-27 Thread Sandro Mani




If apitrace has its own old bundled copy of libbacktrace, better it should
update it to the latest version, which is
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libbacktrace;h=7c4b8fb2fed26a7412bbed1f23976a0f568d0111;hb=HEAD
Incomplete DWARF5 support was added to it in December 2019 and important
bugfixes 9 days ago.


Thanks for your replies, I'll update the bundled libbacktrace and submit 
a PR upstream.


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

List of long term FTBFS packages to be retired in a week


Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (= 1 week 
from now).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


Note that some listed packages are orphaned and hence may be retired even 
sooner.

The packages in rawhide were not successfully built at least since Fedora 32.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

 Package (co)maintainersLatest build
=
boo elsupergomez, orphan, tpokorra  Fedora 31
sugar-flipstickscallkalpa, chimosky, pbrobinson, tuxbrewr   Fedora 31
sugar-getiabookscallkalpa, chimosky, pbrobinson, tuxbrewr   Fedora 31
sugar-infoslicercallkalpa, chimosky, pbrobinson, tuxbrewr   Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides   callkalpa, chimosky, pbrobinson, tuxbrewr   Fedora 31

No packages require the above mentioned packages.

Affected (co)maintainers
callkalpa: sugar-ruler, sugar-infoslicer, sugar-starchart, sugar-getiabooks, 
sugar-view-slides, sugar-flipsticks
chimosky: sugar-ruler, sugar-infoslicer, sugar-starchart, sugar-getiabooks, 
sugar-view-slides, sugar-flipsticks

elsupergomez: boo
pbrobinson: sugar-view-slides, sugar-getiabooks, sugar-flipsticks, 
sugar-infoslicer
tpokorra: boo
tuxbrewr: sugar-view-slides, sugar-getiabooks, sugar-flipsticks, 
sugar-infoslicer
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: unrecognized DWARF version in .debug_info at 6

2021-01-27 Thread Jakub Jelinek

On Wed, Jan 27, 2021 at 05:54:48AM -0700, Jeff Law wrote:
> On 1/27/21 5:48 AM, Sandro Mani wrote:
> > Apitrace is currently failing to build, with [1]
> >
> > Test project 
> > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu
> > Start 1: libbacktrace_btest
> > 1/6 Test #1: libbacktrace_btest ...***Exception: SegFault  0.11 
> > sec
> > unrecognized DWARF version in .debug_info at 6
> >
> > Some dwz issues were mentioned in the runup to the mass rebuild, is this a 
> > related issue?
> More likely it doesn't understand dwarf5.  GCC changed from defaulting
> from dwarf-v4 to dwarf-v5.
> 
> I don't offhand recall if apitrace has a copy of GCC's libbacktrace or
> its own complete reimplementation.  If it's the former, then you might
> consider resyncing with GCC or picking up these changes from
> gcc.gnu.org/git/gcc.git:
> 
> 
> commit bfde774667fbce6d7d326c8a36a098138e224a95
> Author: Ian Lance Taylor 
> Date:   Mon Jan 18 14:45:57 2021 -0800
> 
>     libbacktrace: don't fail tests if dwz fails
>    
>     * Makefile.am (%_dwz): If dwz fails, use uncompressed debug
> info.
>     * Makefile.in: Regenerate.
>     * configure: Regenerate.
> 
> commit 325e70b47c6c321710c7b9c792b8fbee95cecd63
> Author: Ian Lance Taylor 
> Date:   Mon Jan 18 14:38:10 2021 -0800
> 
>     libbacktrace: use correct directory/filename for DWARF 5
>    
>     PR debug/98716
>     * dwarf.c (read_v2_paths): Allocate zero entry for dirs and
>     filenames.
>     (read_line_program): Remove parameter u, change caller.  Don't
>     subtract one from dirs and filenames index.
>     (read_function_entry): Don't subtract one from filenames index.

unrecognized DWARF version means that
2019-12-13  Ian Lance Taylor  

Add DWARF 5 support.
must be missing there too.

Jakub
___
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: unrecognized DWARF version in .debug_info at 6

2021-01-27 Thread Jakub Jelinek

On Wed, Jan 27, 2021 at 01:48:55PM +0100, Sandro Mani wrote:
> Hi
> 
> Apitrace is currently failing to build, with [1]
> 
> Test project 
> /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu
> Start 1: libbacktrace_btest
> 1/6 Test #1: libbacktrace_btest ...***Exception: SegFault  0.11 
> sec
> unrecognized DWARF version in .debug_info at 6
> 
> Some dwz issues were mentioned in the runup to the mass rebuild, is this a 
> related issue?

If apitrace has its own old bundled copy of libbacktrace, better it should
update it to the latest version, which is
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libbacktrace;h=7c4b8fb2fed26a7412bbed1f23976a0f568d0111;hb=HEAD
Incomplete DWARF5 support was added to it in December 2019 and important
bugfixes 9 days ago.

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

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

2021-01-27 Thread Robert Marcano via devel


On 1/25/21 5:53 AM, Peter Boy wrote:

With Fedora 33 network configuration is by default persisted in 
/etc/NetworkManager/system-connections/*.nmconnection files. The old 
/etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being 
processed for the time being, but obviously it is time to migrate.
(cf 
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh).


Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ?


You can "migrate" using nmcli:

Save the output of `nmcli connection show `, then 
create a new empty one a do a diff of the new `nmcli connection show 
` with the old one. Set set the differences on the 
new connection with `nmcli connection modify ...`







Most items are simple to migrate, but servers in particular sometimes have 
unusual configurations, e.g.

- for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa"
- and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in 
route-{ifname}   file

How do I handle that kind of config items in *.nmconnection ? The "search engine I 
trust" couldn't answer that for me (or I couldn’t ask the right question).



Thanks
Peter


___
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: unrecognized DWARF version in .debug_info at 6

2021-01-27 Thread Jeff Law

On 1/27/21 5:48 AM, Sandro Mani wrote:
>
> Hi
>
> Apitrace is currently failing to build, with [1]
>
> Test project 
> /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu
> Start 1: libbacktrace_btest
> 1/6 Test #1: libbacktrace_btest ...***Exception: SegFault  0.11 
> sec
> unrecognized DWARF version in .debug_info at 6
>
> Some dwz issues were mentioned in the runup to the mass rebuild, is this a 
> related issue?
More likely it doesn't understand dwarf5.  GCC changed from defaulting
from dwarf-v4 to dwarf-v5.

I don't offhand recall if apitrace has a copy of GCC's libbacktrace or
its own complete reimplementation.  If it's the former, then you might
consider resyncing with GCC or picking up these changes from
gcc.gnu.org/git/gcc.git:

commit bfde774667fbce6d7d326c8a36a098138e224a95
Author: Ian Lance Taylor 
Date:   Mon Jan 18 14:45:57 2021 -0800

    libbacktrace: don't fail tests if dwz fails

    * Makefile.am (%_dwz): If dwz fails, use uncompressed debug
info.
    * Makefile.in: Regenerate.
    * configure: Regenerate.

commit 325e70b47c6c321710c7b9c792b8fbee95cecd63
Author: Ian Lance Taylor 
Date:   Mon Jan 18 14:38:10 2021 -0800

    libbacktrace: use correct directory/filename for DWARF 5

    PR debug/98716
    * dwarf.c (read_v2_paths): Allocate zero entry for dirs and
    filenames.
    (read_line_program): Remove parameter u, change caller.  Don't
    subtract one from dirs and filenames index.
    (read_function_entry): Don't subtract one from filenames index.
Jeff
___
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

unrecognized DWARF version in .debug_info at 6

2021-01-27 Thread Sandro Mani


Hi

Apitrace is currently failing to build, with [1]

Test project 
/builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu
Start 1: libbacktrace_btest
1/6 Test #1: libbacktrace_btest ...***Exception: SegFault  0.11 sec
unrecognized DWARF version in .debug_info at 6

Some dwz issues were mentioned in the runup to the mass rebuild, is this a 
related issue?

Thanks
Sandro

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=60502198

___
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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

I think one reason against maintainer's pull requests is poor tooling to
work with them. Filled fedpkg proposal to include ability to fork and
add personal fork to current repository or add when cloning [1].
I think current way discourages its use, because too many manual steps
have to be done before making PR.

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

On 1/25/21 4:30 PM, Miro Hrončok wrote:
> On 25. 01. 21 16:19, Stephen Gallagher wrote:
>> I'm fully in favor of this and I'd really like to see us add some
>> degree of CI gating to support it.
> 
> Note that unfortunately CI gating happens too late. It has no capability
> to block commits that fail to build, because it only tests successful
> builds and because it only tests already pushed changes. CI on Pull
> Requests can solve this, but many packagers seem to be very much agianst
> the idea of sending PRs to packages they maintain themselves :(
> 

Is there already way to configure maintainer's fork branch to auto merge
and production build, once CI finishes successfully?

I think adding required steps into build process, where developer has to
watch for results and make manual steps is the problem. If I could just
push my change to my fork and let it autoprocess, I would use it when
not in hurry. But I demand first not involving multiple manual steps to
make production built from PR.

Could there be way as a maintainer to add a comment [build] to merged
PR, and pagure would start a new build? I think it does not matter who
started the build, but whose changes are included.

If I could just mark good looking changes and it would try to process
it, just notifying me whether successfully or not, I would use PR more
often. If I have to watch PR CI results myself and do manual steps
depending of its result, it discourages me. Would like some bot to do that.

There seems to be support for [citest] for retriggering CI on package.
Could something similar be used to autobuild PR of people with commit
rights on explicitly enabled branches?

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

OpenPGP_signature
Description: OpenPGP digital 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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git