New font package

[Iñaki Ucar]

Hi,

I've submitted a new font package for review [1], but I have 0
experience with fonts (I need it to unbundle it from [2]), and I found
the documentation about font packages a little bit outdated. It's a
pretty simple font (OFL, single family with a couple of styles), but
it would be great if someone with experience in font packaging could
take the review.

Iñaki

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1807239
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1803528
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

State of FMN (FedMSG Notifications) and Replacement

[Clement Verna]

Hi all,

FMN (https://apps.fedoraproject.org/notifications) is currently one of the
main blocking point for dropping fedmsg in favour of fedora-messaging.
FMN is quite important to the community and the composition of Fedora
because it gives emails and notifications on commits, composes, builds and
updates via email and other tools.

However, the code base is written in Python 2.7 and not maintained anymore.
Currently the service has to run on a Fedora 28 system to continue running.
This causes multiple problems and concerns, and needs to be addressed
before the datacenter move in June.

In order to start putting together a specification for a replacement, we
should try to look at the minimum requirements for a notification system.
For example the current system supports sending notifications to IRC,
emails and SSE (Server Sent Event), Can we live without SSE ? Can we live
without IRC ? Do we need it to monitor everything it does currently or just
a subset of items that the community has found useful.

Let's use this thread to brainstorm ideas on what we need.

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

Re: [Test-Announce] New Release Freeze Times

[Thomas Moschny]

Am Di., 25. Feb. 2020 um 20:37 Uhr schrieb Matthew Miller
:
> > Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> > AM? Which is still confusing me after having known about it for decades.
>
> It's the opposite, which furthers your point. :)

That does not seem to be very clear:
https://www.npl.co.uk/resources/q-a/is-midnight-12am-or-12pm
https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

- Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-Cloud-30-20200226.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Include non-RPM content in buildroot

[Randy Barlow]

On 2/25/20 3:12 PM, Ankur Sinha wrote:

Basically, packages do not pass review merely because they use good
licenses.


Note that I just said that I thought it was the primary purpose, not the 
only purpose.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unannounced SONAME bump in cantor: libcantorlibs.so.23 → 24

[Adam Williamson]

On Tue, 2020-02-25 at 16:11 +0100, Kevin Kofler wrote:
> Fabio Valentini wrote:
> > The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> > and rawhide bumped the SONAME of a shared library as mention in
> > $SUBJECT (maintainers in CC).
> > 
> > At least LabPlot still needs to be rebuilt on both f32 and rawhide
> > (maintainers in CC).
> 
> Cantor is really an application rather than a public library. It is 
> interesting that LabPlot now links to libcantorlibs, that is something that 
> the Cantor maintainers (KDE SIG, basically) will have to keep in mind. 
> Hopefully this can be coordinated in a better way next time.

If a library is not intended for use by other things, it should not be
installed to the well-known public shared library path. It should be
installed somewhere private to the application and the application
should handle including it in its own library path when appropriate.

If it installs to /usr/lib64 then it's a public library, whether the
author intended that or not...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Spam on closed bugzilla reports

[Jeff Fearn]

On 25/2/20 20:54, Richard W.M. Jones wrote:
> On Mon, Feb 24, 2020 at 10:07:15PM -0800, Luya Tshimbalanga wrote:
>> Hello team,
>>
>> It looks like spammers use closed bug report for their ads as seen
>> in this one:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1644013
>>
>> Can someone maintaining bugzilla investigate the issue?
> 
> There's a self-service way to fix this (I see it's already been done
> in this case, but here it is for the record):
> 
> (1) On the comment click on the little label icon ("Tags").
> 
> (2) Type "spam" into the field and press enter.
> 
> This will hide the comment as spam.
> 
> These spam comment reports are aggregated by the BZ maintainers and
> they will block the spammers' accounts eventually.

This last bit is not quite correct, the blocking happens automatically
when thresholds are exceeded.

https://bugzilla.redhat.com/page.cgi?id=faq.html#getting-help-spam2

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

Re: Seeking co-maintainer for libffi package

[Florian Weimer]

* Richard Shaw:

> While API/ABI breaking changes within a release is discouraged, it's
> still might be the right thing to do.

libffi within a Fedora release?  That seems rather ... involved because
Python depends on it.

I don't think we'll need ABI changes for CET support, and we plan to
port CET support into Fedora 31's (and 32's) libffi 3.1 version.  But I
won't be able to work on this before April at least.

The justification for the first soname bump (to .7) does not appear to
be correct to me: introducing symbol versioning does not need a soname
bump with the GNU ELF implementation, and the aarch64 change only
affects Mach-O targets, not ELF targets.  The ELF ABI is in fact
unchanged.

If I'm counting correctly, we currently use only 20 out of 36 bytes for
the aarch64 trampoline, so there's room for future BTI support as well.

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

Fedora-32-20200225.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 25/160 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200224.n.0):

ID: 527306  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/527306
ID: 527316  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/527316
ID: 527331  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/527331
ID: 527342  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/527342
ID: 527436  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/527436

Old failures (same test failed in Fedora-32-20200224.n.0):

ID: 527318  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/527318
ID: 527339  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527339
ID: 527349  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/527349
ID: 527357  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527357
ID: 527366  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/527366
ID: 527373  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/527373
ID: 527385  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/527385
ID: 527388  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/527388
ID: 527390  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/527390
ID: 527391  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/527391
ID: 527400  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/527400
ID: 527401  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527401
ID: 527408  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/527408
ID: 527413  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/527413
ID: 527416  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527416
ID: 527429  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/527429
ID: 527441  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527441
ID: 527448  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527448
ID: 527449  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/527449
ID: 527454  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/527454
ID: 527455  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/527455

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

New soft failures (same test not soft failed in Fedora-32-20200224.n.0):

ID: 527294  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/527294
ID: 527295  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527295
ID: 527297  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/527297
ID: 527299  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527299
ID: 527302  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/527302
ID: 527323  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/527323
ID: 527352  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/527352
ID: 527384  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/527384
ID: 527402  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/527402

Old soft failures (same test soft failed in Fedora-32-20200224.n.0):

ID: 527303  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/527303
ID: 527354  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/527354
ID: 527375  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/527375
ID: 527437  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://open

Re: Orphaning 'antimony' package

[Elliott Sales de Andrade]

On Tue, 25 Feb 2020 at 12:55, Antonio Trande  wrote:
>
> Hi all.
>
> Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
> package since today.

Actually, it's orphaned *and retired*. This is not insurmountable for
anyone who wishes to take over, but one does not necessarily imply the
other.

> Feel free to take it.
>
> --
> ---
> Antonio Trande

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[James Cassell]

On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > So these are the results of our current investigations, we are very much 
> > eager
> > to get your feedback on them and even more eager if you have ideas on how to
> > approach/solve some of the challenges mentioned here.
> 
> This all sounds great. I'd also love for there to be a standard way of
> tagging specific git commit log messages as meant for user consumption, and
> use that to prepopulate the bodhi release notes field (with an eventual eye
> towards making this the single source of Fedora package change information).
> 

Indeed, it is unfortunate that the Bodhi info for EOL releases is currently 
lost.

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

Re: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

[Richard W.M. Jones]

On Tue, Feb 25, 2020 at 12:22:10PM -0800, Michel Alexandre Salim wrote:
> > On February 25, 2020 3:38 AM Richard W.M. Jones  wrote:
> > 
> >  
> > In the previous mass build LWT FTBFS because the tests failed on POWER
> > and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
> > version of LWT (https://bugzilla.redhat.com/1755859).  The new version
> > is noted as an API break, although I don't know how that will affect
> > other packages.
> > 
> > Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
> > scratch build.  The tests even pass on all arches:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170
> > 
> Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 
> later if necessary?

Well I can push it to Rawhide.  I will see how it goes before doing
other branches, as it may require other dependent packages to be
updated also because of the ABI break (I don't know if this is true or
not - will need to see).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

[Michel Alexandre Salim]

> On February 25, 2020 3:38 AM Richard W.M. Jones  wrote:
> 
>  
> In the previous mass build LWT FTBFS because the tests failed on POWER
> and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
> version of LWT (https://bugzilla.redhat.com/1755859).  The new version
> is noted as an API break, although I don't know how that will affect
> other packages.
> 
> Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
> scratch build.  The tests even pass on all arches:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41885170
> 
Sounds great. I'd say push this for Rawhide and FC32, and maybe update FC31 
later if necessary?

Best,

-- 
Michel Alexandre Salim 
 profile: https://keybase.io/michel_slm 
 GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20200225.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 18/160 (x86_64), 1/2 (arm)

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

ID: 527154  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/527154
ID: 527190  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/527190

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

ID: 527156  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/527156
ID: 527211  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/527211
ID: 527223  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/527223
ID: 527226  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/527226
ID: 527228  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/527228
ID: 527229  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/527229
ID: 527238  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/527238
ID: 527239  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527239
ID: 527246  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/527246
ID: 527251  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/527251
ID: 527254  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/527254
ID: 527267  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/527267
ID: 527279  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527279
ID: 527286  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/527286
ID: 527287  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/527287
ID: 527292  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/527292
ID: 527293  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/527293

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

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

ID: 527132  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/527132
ID: 527133  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527133
ID: 527137  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/527137
ID: 527140  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/527140
ID: 527158  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/527158
ID: 527161  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/527161
ID: 527170  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/527170
ID: 527222  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/527222
ID: 527240  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/527240

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

ID: 527135  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/527135
ID: 527141  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/527141
ID: 527192  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/527192
ID: 527213  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/527213
ID: 527275  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/527275
ID: 527278  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/527278
ID: 527285  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/527285

Passed openQA tests: 123/160 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200224.n.0):

ID: 527134  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/527134
ID: 527138  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/527138
ID: 527139  Test: 

Re: Include non-RPM content in buildroot

[Ankur Sinha]

On Tue, Feb 25, 2020 14:41:34 -0500, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > > One thing that comes to my mind with this proposal is that we still need
> > > some way to vet licenses. Today, this is done via the package review
> > > process, and in my mind is the primary purpose of package review. If we
> > > started having upstream compatible registries, I suppose we could 
> > > introduce
> > > a review process for adding packages to the registries to solve this
> > > concern.
> > Vetting of licenses is only one aspect of the review but not its sole
> > purpose. Apart from all the other checks to ensure that the software
> > follows current best practices in software development, we also verify
> > the correctness of the software during the review.
> 
> That's true, but I think fundamentally I agree with Randy: if the software
> is terrible in some way but still useful to users (hello, Chromium!), we
> probably want to find some room for it in Fedora somehow. 

Sure, but only if it works (correctness).

> But we absolutely need to be sure about licenses.

Yes, the legal requirement merely sets the lowest bar for inclusion of
software: it must be legally allowed to be even considered for
inclusion. So, it is a compulsory part of the review process, but so are
other checks. I give correctness as an example because it's easiest to
understand: if the software is legally acceptable, but doesn't build or
work properly, then it doesn't pass the review either.

Basically, packages do not pass review merely because they use good
licenses.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: Autoclosure of review requests?

[Mattia Verga via devel]

Il 24/02/20 23:04, Ben Cotton ha scritto:

> In the weekly Fedora program update that I publish on 
> communityblog.fedoraproject.org, I have started to include a count of the 
> open package review requests. As of this moment, there are ~1300 open review 
> requests. Some of these were opened in 2006.

Have a look at https://mattia.fedorapeople.org/review_stats/

These pages were generated by the script at 
https://pagure.io/Fedora-Infra/review_stats which should replace (?) the actual 
script that generates https://fedoraproject.org/PackageReviewStatus/

In general, both the old and new pages can give you a hint of why a review 
ticket is stuck. The newer script hides less tickets than the older.

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Matthew Miller]

On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> So these are the results of our current investigations, we are very much eager
> to get your feedback on them and even more eager if you have ideas on how to
> approach/solve some of the challenges mentioned here.

This all sounds great. I'd also love for there to be a standard way of
tagging specific git commit log messages as meant for user consumption, and
use that to prepopulate the bodhi release notes field (with an eventual eye
towards making this the single source of Fedora package change information).

-- 
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: Non installable package on F31: python3-i3ipc

[Eduard Lucena]

Thanks for the answer.

I make a comment in the bug.

El mar., 25 feb. 2020 a las 16:42, Scott Talbert ()
escribió:

> On Tue, 25 Feb 2020, Eduard Lucena wrote:
>
> > Hello team,
> >
> > I'm writing this here, because I don't know of any other place, so if
> there
> > is another place to report it, I'll listen to go there.
> >
> > I'm trying to install the package: python3-i3ipc
> >
> > $ sudo dnf info python3-i3ipc
> > Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22
> PM
> > -03.
> > Available Packages
> > Name : python3-i3ipc
> > Version  : 1.5.1
> > Release  : 4.fc31
> > Architecture : noarch
> > Size : 29 k
> > Source   : python-i3ipc-1.5.1-4.fc31.src.rpm
> > Repository   : fedora
> > Summary  : An improved Python library to control i3wm
> > URL  : https://github.com/acrisci/i3ipc-python
> > License  : BSD
> > Description  :
> >  : i3's interprocess communication (or ipc) is the interface
> > i3wm uses to receive
> >  : commands from client applications such as i3-msg. It also
> > features
> >  : a publish/subscribe mechanism for notifying interested
> > parties of window
> >  : manager events.
> >  :
> >  : i3ipc-python is a Python library for controlling the
> window
> > manager. This
> >  : project is intended to be useful for general scripting,
> and
> > for applications
> >  : that interact with the window manager like status line
> > generators, notification
> >  : daemons, and pagers.
> >
> >
> > But I get the following error:
> >
> > $ sudo dnf install python3-i3ipc
> > Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22
> PM
> > -03.
> > Error:
> >  Problem: conflicting requests
> >   - nothing provides python3.7dist(enum-compat) needed by
> > python3-i3ipc-1.5.1-4.fc31.noarch
> > (try to add '--skip-broken' to skip uninstallable packages)
> >
> > I'm reporting it, because the package is coming from the Fedora repo, not
> > from a 3rd party repos, so I assume that we should provide it and should
> be
> > installable.
> >
> >
> > If this is the wrong place, please guide me to the right place. Thanks a
> lot
> > for your efforts and time to keep fedora great.
>
> Usually the best place to report a bug about a specific package is
> bugzilla.  It appears this bug has already been reported.  However, it has
> been open for a few months without any response:
> https://bugzilla.redhat.com/show_bug.cgi?id=1770839
>
> Scott



-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Citing RPM in academic text

[Ankur Sinha]

Hello,

We're drafting a submission to CNS*2020[1] about NeuroFedora. Would
anyone know if there's a way to formally cite RPM?

Google Scholar gives me this document by Mark Ewing and Eric Troan[2]
from 1996. Should one keep citing this, or does someone know a newer
publication that we should use?


[1] https://www.cnsorg.org/cns-2020
[2] http://mirror.ircam.fr/pub/rpm/docs/paper.ps.gz

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: Non installable package on F31: python3-i3ipc

[Scott Talbert]

On Tue, 25 Feb 2020, Eduard Lucena wrote:


Hello team,

I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.

I'm trying to install the package: python3-i3ipc

$ sudo dnf info python3-i3ipc
Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Available Packages
Name         : python3-i3ipc
Version      : 1.5.1
Release      : 4.fc31
Architecture : noarch
Size         : 29 k
Source       : python-i3ipc-1.5.1-4.fc31.src.rpm
Repository   : fedora
Summary      : An improved Python library to control i3wm
URL          : https://github.com/acrisci/i3ipc-python
License      : BSD
Description  :
             : i3's interprocess communication (or ipc) is the interface
i3wm uses to receive
             : commands from client applications such as i3-msg. It also
features
             : a publish/subscribe mechanism for notifying interested
parties of window
             : manager events.
             :
             : i3ipc-python is a Python library for controlling the window
manager. This
             : project is intended to be useful for general scripting, and
for applications
             : that interact with the window manager like status line
generators, notification
             : daemons, and pagers.


But I get the following error:

$ sudo dnf install python3-i3ipc
Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Error:
 Problem: conflicting requests
  - nothing provides python3.7dist(enum-compat) needed by
python3-i3ipc-1.5.1-4.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

I'm reporting it, because the package is coming from the Fedora repo, not
from a 3rd party repos, so I assume that we should provide it and should be
installable.


If this is the wrong place, please guide me to the right place. Thanks a lot
for your efforts and time to keep fedora great.


Usually the best place to report a bug about a specific package is 
bugzilla.  It appears this bug has already been reported.  However, it has 
been open for a few months without any response:

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

Scott___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Include non-RPM content in buildroot

[Matthew Miller]

On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > One thing that comes to my mind with this proposal is that we still need
> > some way to vet licenses. Today, this is done via the package review
> > process, and in my mind is the primary purpose of package review. If we
> > started having upstream compatible registries, I suppose we could introduce
> > a review process for adding packages to the registries to solve this
> > concern.
> Vetting of licenses is only one aspect of the review but not its sole
> purpose. Apart from all the other checks to ensure that the software
> follows current best practices in software development, we also verify
> the correctness of the software during the review.

That's true, but I think fundamentally I agree with Randy: if the software
is terrible in some way but still useful to users (hello, Chromium!), we
probably want to find some room for it in Fedora somehow. But we absolutely
need to be sure about licenses.


-- 
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: [Test-Announce] New Release Freeze Times

[Matthew Miller]

On Sat, Feb 22, 2020 at 11:06:30AM +0100, Fabio Valentini wrote:
> I assume 00:00 UTC was confusing for people used to the AM/PM (12h) time
> format instead of the 24h format.
> 
> For people used to 24h clocks, it's completely obvious that 00:00 is the
> beginning of the day, and 24:00 is the end of the day (= equivalent to
> 00:00 of the following day).
> 
> Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> AM? Which is still confusing me after having known about it for decades.

It's the opposite, which furthers your point. :)



-- 
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: Autoclosure of review requests?

[Till Maas]

On Mon, Feb 24, 2020 at 05:04:26PM -0500, Ben Cotton wrote:

> The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
> excludes review request bugs. Having a large number of open, ancient review
> requests isn't exactly harmful, but it's not very helpful either.
> 
> Before I make a proposal to FPC, I thought I'd open a conversation here.
> What does a reasonable cleanup of review requests look like?
> 
> My initial thought is to close all review requests that were opened >2
> years ago, to be performed at the EOL closure for each release.

Here are my thoughts: It depends on who is waiting.

If the submitter is not responding to a reviewer, it makes sense to
close the review request rather soon (maybe after 6 weeks).

If the reviewer is not responding after the submitter updated the review
request, the request should be unassigned to show that it is available
for other reviewers. This should happen rather soon for review requests
from new packagers (blocking NEEDSPONSOR) to keep newcomers on the hook
(maybe after 2 weeks).

If the review request is not moving forward in general, the submitter
should be asked if they still have interest and only if there is no
response, it should be closed. Maybe after 6-12 months.

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

Logs for Open NeuroFedora Meeting: 1600 UTC on Tuesday 25th February

[Aniket Pradhan]

Hello there

Here are the logs for today's meeting.

HTML Logs: 
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.log.html
HTML Minutes: 
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.html

Minutes in plain text are pasted below.

=
#fedora-neuro: NeuroFedora 2020-02-25
=


Meeting started by MeWjOr at 16:00:16 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.log.html
.



Meeting summary
---
* Agenda Summary  (MeWjOr, 16:01:45)
  *

https://lists.fedoraproject.org/archives/list/neurofed...@lists.fedoraproject.org/thread/S3P27DFONJTKADIPJNNOVEQSYRQHOR35/
(MeWjOr, 16:03:07)
  * Introductions and roll call  (MeWjOr, 16:03:17)
  * Tasks from last meeting  (MeWjOr, 16:03:21)
  * Pagure tickets  (MeWjOr, 16:03:28)
  * Bugs  (MeWjOr, 16:03:34)
  * Neuroscience query of the week
https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
16:03:43)
  * Open floor  (MeWjOr, 16:03:47)

* Introductions and roll call  (MeWjOr, 16:03:59)

* Tasks from last meeting on 2020-02-11  (MeWjOr, 16:07:12)
  * Minutes:

https://meetbot.fedoraproject.org/fedora-neuro/2020-02-11/neurofedora.2020-02-11-16.04.html
(MeWjOr, 16:07:29)
  * MeWjOr write event report, send to ML, submit to Mindshare ---
Written a draft so far... Will review and add more stuff soon
(MeWjOr, 16:08:37)
  * MeWjOr e-mail ML with other discussion points that came up during
FOSDEM --- Done  (MeWjOr, 16:08:47)
  * LoKoMurdoK file ticket with Mindshare requesting some NeuroFedora
swag --- waiting for a reply from mindshare  (MeWjOr, 16:09:46)
  * Once the badge has been imported to badges, I'll be able to award
them: https://pagure.io/fedora-badges/issue/678#comment-628475
(FranciscoD, 16:11:06)
  * FranciscoD ask bt0 alciregi if they know how badges are to be given
out manually --- Done.  (MeWjOr, 16:11:12)
  * LoKoMurdoK comment on the ticket thanking riecatnor and asking what
needs to be next: how do we give the badges out, manually to start
with. --- done. Waiting for the badges team to push the badge online
(MeWjOr, 16:11:19)
  * Everyone look for nice brain images with a CC license for the banner
image --- let's do this over this week?  (MeWjOr, 16:11:55)
  * ACTION: lbazan ping on the mindshare ticket for swag  (MeWjOr,
16:13:48)
  * ACTION: Everyone look for nice brain images with a CC license for
the banner image  (MeWjOr, 16:13:52)
  * FranciscoD take care of all the other tickets this week --- I'll
help you with this  (MeWjOr, 16:14:17)
  * ACTION: FranciscoD, MeWjOr take care of all the other tickets this
week  (MeWjOr, 16:14:52)
  * FranciscoD write abstract for CNS*2020 this week also --- did you
write it?  (MeWjOr, 16:15:16)
  * ACTION: FranciscoD finalize the draft of the abstract for CNS*2020
this week also  (MeWjOr, 16:16:00)
  * FranciscoD add some packaging tickets to kanban for folks to test
out --- You added the FTBFS bugs, so great  (MeWjOr, 16:16:30)
  * FranciscoD send a list of FTBFS bugs to ML --- done. ^.^  (MeWjOr,
16:16:45)
  * FranciscoD send out logs, update tickets --- done.  (MeWjOr,
16:17:31)

* Pagure tickets  (MeWjOr, 16:21:04)
  *

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
(MeWjOr, 16:21:14)
  * LinkedIn Group Research
https://pagure.io/neuro-sig/NeuroFedora/issue/338  (MeWjOr,
16:21:53)
  * ACTION: dan1mal create the LinkedIn group and  post it on the
ticket.  (MeWjOr, 16:25:29)
  * Once the group is active, we will have to add it to
neuro{,blog}.fp.o as well  (MeWjOr, 16:28:45)
  * Estimating team resources:
https://pagure.io/neuro-sig/NeuroFedora/issue/337  (MeWjOr,
16:29:27)
  * LINK:

https://neuroblog.fedoraproject.org/2019/08/07/open-position-neurofedora-is-looking-for-a-spin-lab-master.html
(FranciscoD, 16:38:10)
  * Use teams.fedoraproject.org (Taiga) kanban board for better planning
--- https://pagure.io/neuro-sig/NeuroFedora/issue/336  (MeWjOr,
16:41:36)
  * The next issues are for the comp-neuro lab... Featured apps, banner
images, screenshots, summary and content  (MeWjOr, 16:43:37)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/307  (MeWjOr,
16:49:24)
  * Figure out badges rule to award badge automatically to pagure group
members: https://pagure.io/neuro-sig/NeuroFedora/issue/250  (MeWjOr,
16:51:18)

* Open bugs  (MeWjOr, 16:52:39)
  * Open bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr, 16:52:50)
  * LINK: https://koji.fedoraproject.org/koji/packageinfo?packageID=2729
(FranciscoD, 16:54:34)
  * AGREED: ?  (MeWjOr, 16:57:25)
  * AGREED:   (MeWjOr, 16:57:30)
  * AGREED:   (MeWjOr, 16:57:33)
  * AGREED: Drop paraview from the image  (MeWjOr, 16:57:51)
  * AGRE

[Test-Announce] Fedora 32 Branched 20200225.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200225.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200221.n.0: anaconda-32.24.1-1.fc32.src, 20200225.n.0: 
anaconda-32.24.2-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200225.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

python27 license change

[Miro Hrončok]

Hello. I have updated the python27 package to use the bundled wheels of pip and 
setuptools, so we can update setuptools in rawhide to a version that no longer 
works with Python 2.


Unfortunately, that changes the license from "Python" to this beast:

Python and MIT and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and (ASL 2.0 
or BSD)


Technically however, nothing should change (there was a pre-exisitng hard 
requirement on pip/setuptools with such licenses (now combined)).

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

Non installable package on F31: python3-i3ipc

[Eduard Lucena]

Hello team,

I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.

I'm trying to install the package: python3-i3ipc

$ sudo dnf info python3-i3ipc
Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Available Packages
Name : python3-i3ipc
Version  : 1.5.1
Release  : 4.fc31
Architecture : noarch
Size : 29 k
Source   : python-i3ipc-1.5.1-4.fc31.src.rpm
Repository   : fedora
Summary  : An improved Python library to control i3wm
URL  : https://github.com/acrisci/i3ipc-python
License  : BSD
Description  :
 : i3's interprocess communication (or ipc) is the interface
i3wm uses to receive
 : commands from client applications such as i3-msg. It also
features
 : a publish/subscribe mechanism for notifying interested
parties of window
 : manager events.
 :
 : i3ipc-python is a Python library for controlling the window
manager. This
 : project is intended to be useful for general scripting, and
for applications
 : that interact with the window manager like status line
generators, notification
 : daemons, and pagers.


But I get the following error:

$ sudo dnf install python3-i3ipc
Last metadata expiration check: 0:03:09 ago on Tue 25 Feb 2020 02:18:22 PM
-03.
Error:
 Problem: conflicting requests
  - nothing provides python3.7dist(enum-compat) needed by
python3-i3ipc-1.5.1-4.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

I'm reporting it, because the package is coming from the Fedora repo, not
from a 3rd party repos, so I assume that we should provide it and should be
installable.


If this is the wrong place, please guide me to the right place. Thanks a
lot for your efforts and time to keep fedora great.

Best Regards,
Eduard "X3MBoy" Lucena


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 & Containers

[Clement Verna]

On Tue, 25 Feb 2020 at 17:07, Michal Schorm  wrote:

> Hello,
>
> Will anybody be able to explain to me the current state of the
> containers & containerization in Fedora, please?
>

Hi Michal,

As you mention in the points below the current state of building containers
in Fedora needs a lot of work. I started the Container SIG couple years
ago, but we did not managed to build a good momentum to it. For a year or
so we had a few people attending meeting and going through some of the
tasks but 2019 has been hard on us and all the container activities have
had a lower priority for each of the members

So currently the SIG is kind of dead . I personally try to focus on the
Fedora base image and make sure it has regular releases and I try to
respond to the bugs on BZ. For layered images I just keep OSBS up to date
and running, but I cannot really work on the tooling improvement and policy
improvement.

If this is something you really would like to see improving, maybe you can
try to resurrect the Container SIG and start with the list of issues you
have listed :-).

Hope that helps.
Clément


>
> I have some questions, but the more I searched for whom & where to
> ask, the more confused I became.
>
> --
>
> 1) There ́s an IRC on freenode, '#fedora-containers' channel.
> The TOPIC set contains the following message:
> "The place for container runtimes and application containers.
> Forums @ https://discussion.fedoraproject.org/c/containers,
> visit the site @ https://containers.fedoraproject.org
> (website operational at some point in August)."
> However no link mentioned are accessible.
>
> 2) There is 'Fedora Container & Tools Documentation' [1]
> It is only half-filled with information, some part missing entirely.
> Even parts as 'Container Guidelines' [2].
> Btw the wiki gladly redirects there ^ [3].
> Btw there are some scratch notes about the guidelines from damn 2017
> [4], which google offers me rather than the actual guidelines (because
> they don't exist)
>
> 3) So ... who is in charge of it? Whom to contact? How? Where?
> Does Fedora count with Containers or does it already thrown it overboard?
>
> 4) The container I am maintainer of (in pagure in 'container'
> namespace) is not branched automatically. The last branch is 'f30',
> but now I want to update it and add the missing branches. I have no
> idea how should I do it though, since (1) (2) are such a mess.
> I can try 'git push', but anyway, it won't solve the issue, it's not
> branched automatically.
>
> 5) The Dockerfile (are we still using this name? shouldn't it be
> 'containerfile' now, with podman?)
> starts with line like:
> " FROM registry.fedoraproject.org/f30/."
> How can I substitute the Fedora release version with a variable, so I
> can share the same content amongst branches for different Fedora
> releases?
>
> [1] https://docs.fedoraproject.org/en-US/containers/
> [2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/
> [3] https://fedoraproject.org/wiki/Container:Guidelines
> [4] https://fedoraproject.org/wiki/Talk:Container:Guidelines
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Downgrading from rawhide

[Andreas Tunek]

Den tis 25 feb. 2020 kl 16:10 skrev Christophe de Dinechin <
dinec...@redhat.com>:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.
>
>
I did just that a couple of days ago and everything seems to work for me. I
had some slow boot and GDM issues first, but the GDM issues seem to be
solved.

/Andreas

> --
> Cheers,
> Christophe de Dinechin (IRC c3d)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

Orphaning 'antimony' package

[Antonio Trande]

Hi all.

Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
package since today.
Feel free to take it.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.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: Seeking co-maintainer for libffi package

[Richard Shaw]

On Tue, Feb 25, 2020 at 9:57 AM Anthony Green  wrote:

> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer.   I'm looking for help with libffi
> packaging.  Specifically, we need to roll out a new ABI-breaking
> release (required for ARM64 and Intel CET support), and I don't have
> the volunteer time available to create the requisite compat packages,
> monitor all of the rebuilds, etc.   It would be best if this person
> had some Fedora packaging experience under their belt, given some of
> the complexities involved and the criticality of libffi to the whole
> platform.
>

While API/ABI breaking changes within a release is discouraged, it's still
might be the right thing to do. You could create a side tag and make sure
all dependent packages have been rebuilt or ported over first, and them
merge them back in with a single bodhi update.

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Miro Hrončok]

On 25. 02. 20 15:27, Fabio Valentini wrote:

Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet


Unfortunately, that breaks rawhide users.

--
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: Seeking co-maintainer for libffi package

[Antonio Trande]

Add me as co-maintainer, please.
I'm using libffi as dependency for a couple of packages.

On 25/02/20 16:56, Anthony Green wrote:
> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer.   I'm looking for help with libffi
> packaging.  Specifically, we need to roll out a new ABI-breaking
> release (required for ARM64 and Intel CET support), and I don't have
> the volunteer time available to create the requisite compat packages,
> monitor all of the rebuilds, etc.   It would be best if this person
> had some Fedora packaging experience under their belt, given some of
> the complexities involved and the criticality of libffi to the whole
> platform.
> 
> Thanks!
> 
> AG
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.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: Ideas and proposal for removing changelog and release fields from spec file

[Miro Hrončok]

On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:

Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).


I don't consider that an issue. It's not super elegant, but since we do 
distro-sync on upgrades, it shuld be fine.


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

AAA: FAS Replacement project update

[Sarah Finn]

Hi all,

Please see the latest AAA FAS replacement project update below:

AAA: FAS replacement project update 2/25/20


The month of February was a very busy month for the CPE AAA team and
community contributors working on this initiative. Great progress was made
in the development phase of the AAA: FAS replacement build. Sprint 2 and 3
resulted in the completion of multiple user stories which added user
functionality to join groups, change email address and password, disable
account, database access along with putting a mapping solution in place for
users moving from the current FAS to the new FAS (potential name
incoming!). We also came to the end of developing our wireframes and
mapping our user experience flow. Unit tests were carried out regarding
password controller and the current codebase.

We received great support from the wider CPE team as well as Patrick
Uiterwijk to allow us progress with user stories by gaining permissions and
merging PR’s for the integration of CentOS CI. Christian Heimes assisted us
greatly with sharing his knowledge regarding FREE IPA and answered numerous
questions to allow us to move forward.

Sprint 4 began on Thursday the 20th of February. This sprint will focus on
development tasks which will include working on FAS Json, Free IPA,  API,
Fedora Messaging integration, continuous deployment to stage environment,
developing a secure coding tool to ensure code adheres to best practice, as
well as continuing working on user functionality user stories. Please see
our github board here to
view current activity.

We also received some sad news since our last update, that we are losing a
team member, Rick Elrod, as he moves on to pastures new with the Ansible
team. Rick provided an excellent POC for AAA which is leaving us in good
shape to continue on as planned. Thanks Rick and we will hopefully still
see you around as a contributor going forward. We also welcomed a new team
member Leonardo (Leo) Rossetti who joined at the start of Sprint 4 and has
already hit the ground running. Leo is currently working on our FAS JSON
user stories.

Regarding delivery of AAA, we may look at a phased release , this current
phase focus is on the development of AAA to be delivered by 3/31/20. It is
looking likely that the deployment of AAA will happen in a later phase due
to requiring System Admin assistance. We are likely to gain this on the
completion of the Colo Move (which is our planned data center move),
approximately in mid April. We are enquiring to see if deploying to staging
is possible within this phase to allow for a long testing period. I will
provide an update on this in our next blog. The integration of CentOS will
be worked on within an additional phase following the completion of AAA
centric stories for Fedora.

On a final note, I would like to commend the CPE AAA team on their
collaboration
and productivity throughout this initiative even in the face of unknowns,
team changes, cross team dependencies and other challenges, they continued
to proactively work together and find solutions to keep this initiative
moving forward.

We welcome all feedback, thoughts and contributions as we progress through
this project. Please feel free to comment on any issue to log your
thoughts.


For more information regarding outstanding issues, please see here.

To view our current scrum board, please see here.


Thanks all,
-- 

Sarah Finn

She/Her

Agile Practitioner

Red Hat 

Waterford, Ireland

sf...@redhat.com
M: 0879830832
@RedHat    Red Hat
  Red Hat


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

Re: Fedora & Containers

[Michal Schorm]

Hidden from sight of any mortal man, I've found 'Fedora Container SIG'
with as little information as possible [1], although they state, they have 
notes from 2019 DevConf meetup [2], but locked [3].

Atleast I found first place of discussion! [4]
... if you can say that about bunch of threads with 8k views on single thread, 
but no more than 100 replies in all topics & threads together.

[1] https://fedoraproject.org/wiki/Container_SIG
[2] https://fedoraproject.org/wiki/Container_SIG#Notes_from_meetings
[3] https://public.etherpad-mozilla.org/p/fedoracontainerSIG
[4] https://discussion.fedoraproject.org/c/server/containers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 & Containers

[Michal Schorm]

Hello,

Will anybody be able to explain to me the current state of the
containers & containerization in Fedora, please?

I have some questions, but the more I searched for whom & where to
ask, the more confused I became.

--

1) There ́s an IRC on freenode, '#fedora-containers' channel.
The TOPIC set contains the following message:
"The place for container runtimes and application containers.
Forums @ https://discussion.fedoraproject.org/c/containers,
visit the site @ https://containers.fedoraproject.org
(website operational at some point in August)."
However no link mentioned are accessible.

2) There is 'Fedora Container & Tools Documentation' [1]
It is only half-filled with information, some part missing entirely.
Even parts as 'Container Guidelines' [2].
Btw the wiki gladly redirects there ^ [3].
Btw there are some scratch notes about the guidelines from damn 2017
[4], which google offers me rather than the actual guidelines (because
they don't exist)

3) So ... who is in charge of it? Whom to contact? How? Where?
Does Fedora count with Containers or does it already thrown it overboard?

4) The container I am maintainer of (in pagure in 'container'
namespace) is not branched automatically. The last branch is 'f30',
but now I want to update it and add the missing branches. I have no
idea how should I do it though, since (1) (2) are such a mess.
I can try 'git push', but anyway, it won't solve the issue, it's not
branched automatically.

5) The Dockerfile (are we still using this name? shouldn't it be
'containerfile' now, with podman?)
starts with line like:
" FROM registry.fedoraproject.org/f30/."
How can I substitute the Fedora release version with a variable, so I
can share the same content amongst branches for different Fedora
releases?

[1] https://docs.fedoraproject.org/en-US/containers/
[2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/
[3] https://fedoraproject.org/wiki/Container:Guidelines
[4] https://fedoraproject.org/wiki/Talk:Container:Guidelines

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

Seeking co-maintainer for libffi package

[Anthony Green]

Hello -- I'm the current Fedora maintainer for libffi, as well as the
upstream author/maintainer.   I'm looking for help with libffi
packaging.  Specifically, we need to roll out a new ABI-breaking
release (required for ARM64 and Intel CET support), and I don't have
the volunteer time available to create the requisite compat packages,
monitor all of the rebuilds, etc.   It would be best if this person
had some Fedora packaging experience under their belt, given some of
the complexities involved and the criticality of libffi to the whole
platform.

Thanks!

AG

-- 
Anthony Green 
Senior Principal Solutions Architect, Financial Services
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Downgrading from rawhide

[Richard W.M. Jones]

On Tue, Feb 25, 2020 at 04:09:32PM +0100, Christophe de Dinechin wrote:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
> 
> I tried
> 
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
> 
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.

I have downgraded at least a subset of packages from Rawhide to a
released Fedora in the past, and it can work.

However last week when I did this libvirt broke all networking when
doing this (requiring a reboot and IIRC some manual config file
changes to recover).  Now this wasn't necessarily libvirt's fault
because we only test and it's only guaranteed that things like RPM
scriptlets will work in the forwards direction.  While it's _nice_
that they should work in the reverse direction, it's not required and
it's very rarely tested.

So basically it may work, if it doesn't you get to keep all the pieces,
and it has broken in the past.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Open NeuroFedora Meeting: 1600 UTC on Tuesday, 25th February

[Aniket Pradhan]

Hello there

We will be starting in about 15-20 minutes. It would be great if
people could join the meeting. :D

On Mon, Feb 24, 2020 at 6:48 PM Aniket Pradhan
 wrote:
>
> Hey there!
>
> You are invited to attend the next Open NeuroFedora team meeting this
> week on Tuesday at 1600UTC in #fedora-neuro on IRC (Freenode):
>
> https://webchat.freenode.net/?channels=#fedora-neuro
>
> You can convert the meeting time to your local time using:
> $ date --date='TZ="UTC" 1600 next Tue'
>
> or use this link:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting&iso=20200225T16&p1=%3A&ah=1
>
> The meeting will be chaired by @major. The agenda for the meeting is:
>
> - Introductions and roll call.
> - Tasks from last week's meeting: NA
> - Pagure tickets:
> https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
> - Neuroscience query of the week.
> - Next meeting day, and chair.
> - Open floor.
>
> In the "Neuroscience query of the week" section, attendees can ask
> about/discuss a neuroscience topic that they are curious about.
>
>
> We hope to see you there! :D
>
> --
> Thanks
> Regards
>
> Aniket Pradhan
> http://home.iiitd.edu.in/~aniket17133/
> Aliases: MeWjOr/major
>
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments



-- 
Thanks
Regards

Aniket Pradhan
http://home.iiitd.edu.in/~aniket17133/
Aliases: MeWjOr/major

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Downgrading from rawhide

[Stephen John Smoogen]

On Tue, 25 Feb 2020 at 10:10, Christophe de Dinechin 
wrote:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.
>
>
There are no promises that it will work and no promises that it won't work.
Depending on how far and how much difference there is.. it will most likely
not work without a lot of manual intervention as packagers and packages are
not required to be backwards compatible.



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


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

Re: Downgrading from rawhide

[Florian Weimer]

* Christophe de Dinechin:

> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first sight, it
> seems to be somewhat successful.

Due to bug 1652867, you may have to run ldconfig in the resulting shell
if you downgrade from rawhide most time of the year (but not currently).

Other things are likely to break, too, though.

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

Downgrading from rawhide

[Christophe de Dinechin]

Is there any documented procedure to safely downgrade from rawhide to
the latest release?

I tried

# dnf update --releasever=32 fedora-release
# dnf distro-sync --allowerasing --skip-broken

Does something like that have any chance of working? At first sight, it
seems to be somewhat successful.

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

[Test-Announce] Fedora 32 Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 32 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now on all Fedora 32 packages must be
submitted to updates-testing and pass the relevant requirements[3]
before they will be marked as 'stable' and moved to the fedora
repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Finally, today is the '100% code complete deadline' Change
Checkpoint[5], meaning that Fedora 32 Changes must now be code
complete, meaning all the code required to enable the new change is
finished. The level of code completeness is reflected as tracker bug
state ON_QA. The change does not have to be fully tested by this
deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-translated projects should
not now be changed for Fedora 32.

Mohan Boddu

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unannounced SONAME bump in cantor: libcantorlibs.so.23 → 24

[Kevin Kofler]

Fabio Valentini wrote:
> The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> and rawhide bumped the SONAME of a shared library as mention in
> $SUBJECT (maintainers in CC).
> 
> At least LabPlot still needs to be rebuilt on both f32 and rawhide
> (maintainers in CC).

Cantor is really an application rather than a public library. It is 
interesting that LabPlot now links to libcantorlibs, that is something that 
the Cantor maintainers (KDE SIG, basically) will have to keep in mind. 
Hopefully this can be coordinated in a better way next time.

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

Re: Autoclosure of review requests?

[Fabio Valentini]

On Tue, Feb 25, 2020 at 3:43 PM Ben Cotton  wrote:
>
>
>
> On Mon, Feb 24, 2020, 17:32 Fabio Valentini  wrote:
>>
>>
>> It sounds like you are both not aware that there's actually an
>> existing policy that covers stalled Review Requests:
>> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

(snip)

> Ah ha! I thought I remembered seeing something before, but it wasn't on 
> docs.fp.o when I was looking yesterday. That's a separate bug to fix. :-)

I got to thank my firefox browser history. It's an endless repository
of knowledge :-)

> The problem with the existing policy is that it's geared toward review 
> requests that someone is actively paying attention to. If neither there's no 
> reviewer and the submitter just walks away from it, this policy is never 
> executed.
>
> What I'm suggesting is a backstop to that.

Sure, I think it's reasonable to close Review Requests that haven't
been touched in over year, or something like that.
The creation date alone might not be accurate enough, as some old
requests are actually getting picked up and are being worked on.

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

Re: Autoclosure of review requests?

[Ben Cotton]

On Mon, Feb 24, 2020, 17:32 Fabio Valentini  wrote:

>
> It sounds like you are both not aware that there's actually an
> existing policy that covers stalled Review Requests:
> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews


Ah ha! I thought I remembered seeing something before, but it wasn't on
docs.fp.o when I was looking yesterday. That's a separate bug to fix. :-)

The problem with the existing policy is that it's geared toward review
requests that someone is actively paying attention to. If neither there's
no reviewer and the submitter just walks away from it, this policy is never
executed.

What I'm suggesting is a backstop 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: Ideas and proposal for removing changelog and release fields from spec file

[Fabio Valentini]

On Tue, Feb 25, 2020 at 3:12 PM Pierre-Yves Chibon  wrote:
>
> On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  
> > wrote:
> > >
> > > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> > >
> > > >   - You can easily opt-in by using the macros
> > >
> > > Please keep opt-in as a mandatory need for such a change.
> > >
> > >
> > > To be clear, I will be (perhaps the only) one to not use it.
> > >
> > >
> > > For now spec file are self-contained, which is nice.
> > >
> > > I don't like the idea of generated / external stuff related
> > > to "storage" or "build system"
> > >
> > >
> > > Sorry, to be again the old bad guy which don't like changes.
> > >
> > > Remi
> >
> > FWIW, I agree. Maybe I'm getting old as well >:-D
> >
> > I don't think it's a good idea to use any information from outside the
> > dist-git repository as a source of truth for anything.
> > The big benefit of only using the git repository as source of
> > information is that it is immutable, reproducible, and cannot be
> > changed after commits have been pushed.
> > The git repository data is also available for working on packages
> > *offline*, in contrast to having to ask koji for the number of builds
> > since X ...
>
> The way I see it is this:
> With the number of commits+number of build idea, you get the same results
> locally and in bodhi.
> Locally fedpkg build or rpmbuild -ba will override the existing RPM
> In koji, it will simply append a .1 to the release to avoid overriding the
> existing RPM.
> But the content and release, except for two characters, will be the same.

(snip)

> That being said, there seems to be a consensus forming about wanting to rely
> only on number of commits (though, we still have the upgrade path issue to 
> sort
> out).

Hi Pierre,

After reporting a few upgrade path bugs for (I think) fedora 28 and
29, I was told that "we don't care about upgrade path anymore", since
"dnf system-upgrade" operates in "distro-sync" mode by default, since
a few releases ago.

So I don't see upgrade path as a (big) concern here. There may be
package downgrades at system-upgrade time, but that's already the case
today - most of the time because either people forget to build for
fedora-branched after the branch point, or because they forget to
submit bodhi updates after update-testing activation point. Whereas
those two are "real" downgrades, any downgrades caused by the new
commit counting would only be "downgrade by number but upgrade in
content".

Fabio

Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet 😈️

> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  wrote:
> >
> > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> >
> > >   - You can easily opt-in by using the macros
> >
> > Please keep opt-in as a mandatory need for such a change.
> >
> >
> > To be clear, I will be (perhaps the only) one to not use it.
> >
> >
> > For now spec file are self-contained, which is nice.
> >
> > I don't like the idea of generated / external stuff related
> > to "storage" or "build system"
> >
> >
> > Sorry, to be again the old bad guy which don't like changes.
> >
> > Remi
> 
> FWIW, I agree. Maybe I'm getting old as well >:-D
> 
> I don't think it's a good idea to use any information from outside the
> dist-git repository as a source of truth for anything.
> The big benefit of only using the git repository as source of
> information is that it is immutable, reproducible, and cannot be
> changed after commits have been pushed.
> The git repository data is also available for working on packages
> *offline*, in contrast to having to ask koji for the number of builds
> since X ...

The way I see it is this:
With the number of commits+number of build idea, you get the same results
locally and in bodhi.
Locally fedpkg build or rpmbuild -ba will override the existing RPM
In koji, it will simply append a .1 to the release to avoid overriding the
existing RPM.
But the content and release, except for two characters, will be the same.

That being said, there seems to be a consensus forming about wanting to rely
only on number of commits (though, we still have the upgrade path issue to sort
out).


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote:
> 
> Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> > Good Morning Everyone,
> >
> > This topic has already been discussed a few times over the past month, but 
> > Adam
> > Saleh, Nils Philippsen and myself have had the opportunity to invest some 
> > time
> > on it with the hope of making the packager's life simpler as well as making 
> > it
> > easier to build automation around our package maintenance.
> >
> > We have investigated a few ideas, the full list with their pros and cons 
> > can be
> > found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
> > If you have any questions about some of these, please ask them, we'll be 
> > happy
> > to answer them and potentially complete this document.
> >
> >
> > For both the release and the changelog fields we believe using RPM macros 
> > would
> > satisfy the requirements we have for opting-in/out:
> >   - You can easily opt-in by using the macros
> >   - You can easily opt-out by removing the macros from your spec file
> >
> >
> > For the changelog, we believe we have a potential good solution:
> > - The changelog will be automatically generated using an external 
> > `changelog`
> >   file as well as the commit history
> >   - When you opt-in, you will simply move the existing changelog to an 
> > external
> > file `changelog`, which is placed in the dist-git repo and add the
> > appropriate macro.
> 
> 
> I assume you are aware about my PR:
> 
> 
> https://pagure.io/packaging-committee/pull-request/942
> 
> 
> >   - Upon building, the macro will generate the changelog using all the 
> > commits
> > of the repo up to the last commit touching the `changelog` file.
> 
> 
> I proposed, that the changelog file is either included in the repository
> or it is not included (probably listed in .gitignore). So it is either
> used as it is or if later, then it is generated.
> 
> You propose mixture if I understand it correctly. I.e. the changelog
> file is always present in the dist-git and it is always is used. But if
> there are more recent commits without changelog modifications, they are
> prepended to the changelog, but the changelog file itself stays
> untouched. E.g. if my latest commit modifies the changelog, the
> changelog as it is present in the repo will be used without any
> modifications.
> 
> I like it. It is opt-in, because I have to place some macro into .spec
> file and it is even more or less bacward compatible, because the
> automation kicks in only if I don't maintain the changelog manually.
 
That is correct.
I was aware of the PR to the FPC which actually contributed to this idea
(figuring out the last commit that changed the `changelog` file is way easier
than the last commit that changed %changelog in the spec file).
So thanks for this!
 

[About the release field]

> I am not really sure about this. How do you envision this is going to be
> implemented? Is there going to be "release" file, similarly to
> changelog, which would help me to override this? Because, currently, it
> seems that both methods are going to need a lot of information from the
> build system. 

The first method using number of commits and number of builds, pull limited
information from the build system (just: how many builds succeed before this one
with this version and release?).
The second method does rely heavily on the build system.

> They will need to parse .spec file etc. I don't see this
> to be able to handle even a bit more complex stuff like e.g.
> https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_26

We've been trying to find something that fit the majority of the packages but we
are well aware that there are and will always be some special snowflakes that
will not be able to adhere to this.
I'd be happy if this works makes life/packaging easier for 50% of our packages
(I'd even probably be happy if it's 20%).
Once we have the simple case out and we can test it, see how it behaves, what
its limits are, we can start building on more complex cases, but I don't really
believe on building the perfect solution in one go.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Fabio Valentini]

On Tue, Feb 25, 2020 at 2:47 PM Remi Collet  wrote:
>
> Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
>
> >   - You can easily opt-in by using the macros
>
> Please keep opt-in as a mandatory need for such a change.
>
>
> To be clear, I will be (perhaps the only) one to not use it.
>
>
> For now spec file are self-contained, which is nice.
>
> I don't like the idea of generated / external stuff related
> to "storage" or "build system"
>
>
> Sorry, to be again the old bad guy which don't like changes.
>
> Remi

FWIW, I agree. Maybe I'm getting old as well >:-D

I don't think it's a good idea to use any information from outside the
dist-git repository as a source of truth for anything.
The big benefit of only using the git repository as source of
information is that it is immutable, reproducible, and cannot be
changed after commits have been pushed.
The git repository data is also available for working on packages
*offline*, in contrast to having to ask koji for the number of builds
since X ...

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

Re: Adopting fedora-jam-kde-theme and fedora-jam-backgrounds

[Ankur Sinha]

On Sat, Feb 22, 2020 07:03:16 -0800, Erich Eickmeyer wrote:
> 
> 
> I have had a few people looking at my reviews. After I made corrections and 
> posted that info, I have had zero responses on my bugs:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1801352
> https://bugzilla.redhat.com/show_bug.cgi?id=1803945
> https://bugzilla.redhat.com/show_bug.cgi?id=1804307

I just had a look. People are working on all three, and @salimma has
agreed to sponsor you there also. So it should all be done soon.

If there's anything else the community can help with, please let us
know.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Modularity branch name

[Remi Collet]

Hi,


After some test, is looks like the stream name of a module have to
match the branch name.

I think this constraint doesn't make sense.

We can want different content (.yaml file) for different
distributions (Fedora vs EPEL) or different Version

Reported as https://pagure.io/fedora-infrastructure/issue/8687
(but probably not the right place)


Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Remi Collet]

Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :

>   - You can easily opt-in by using the macros

Please keep opt-in as a mandatory need for such a change.


To be clear, I will be (perhaps the only) one to not use it.


For now spec file are self-contained, which is nice.

I don't like the idea of generated / external stuff related
to "storage" or "build system"


Sorry, to be again the old bad guy which don't like changes.



Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

I have given the project to mhjacks.

On Mon, 24 Feb 2020 at 18:19, Martin Jackson  wrote:
>
> I will take them - mhjacks in FAS.
>
> Any other potential comaintainers would also be welcome but I am a fan of the 
> stack and would hate to see it disappear from the Fedora ecosystem.
>
> Thanks!
>
> > On Feb 24, 2020, at 4:21 PM, Stephen John Smoogen  wrote:
> >
> > I have been maintaining nagios, nagios-plugins, and nrpe for a couple
> > of years but currently I do not have much time to put towards the
> > packages and won't until 2021 at my current rate.
> >
> > Last week, I emailed various people who have co-maintainer rights on
> > the package, but haven't had anyone reply. So I am asking on these
> > lists to see if another packager has time to maintain them and if not
> > I plan to orphan the packages in 2 weeks.
> >
> > --
> > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Vít Ondruch]

Dne 25. 02. 20 v 9:55 Pierre-Yves Chibon napsal(a):
> On Mon, Feb 24, 2020 at 10:05:31PM +0100, Miroslav Suchý wrote:
>> Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
>>> Can we please have a "git is the only source of truth" version of this? 
>>> I.e. "Compute the release field from the number
>>> of commits since the last version change" in the document. It seem to only 
>>> have one con (breaks if two builds are
>>> triggered from the same commit) which is the status quo.
>>>
>> +1
>>
>> Or the combination of:
>>   Get the release field from the annotation of the git tag
>> and
>>   Get the release field using the number of tags since the last version 
>> change
>> If the regexp does not match, just count the tags (or the commits).
> We addressed git tags in the hackmd doc and we were not very thrilled with the
> idea. It seems fragile (parsing/regex) and if the changelog is included in the
> git tag, packagers still have to maintain 3 different changelogs.


We should keep git tags for Bodhi updates O:-)


Vít


>
>> And BTW I like the changelog proposal.
> Thanks :)
> It's a bit of a tricky situation since we tend to consider both release and
> changelog separately but they are also very much related since the release
> appears in the changelog.
> So if we want to keep the current changelog format, we need to consider them
> together (of we accept to change the structure of the changelog)
>
>
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Vít Ondruch]

Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> Good Morning Everyone,
>
> This topic has already been discussed a few times over the past month, but 
> Adam
> Saleh, Nils Philippsen and myself have had the opportunity to invest some time
> on it with the hope of making the packager's life simpler as well as making it
> easier to build automation around our package maintenance.
>
> We have investigated a few ideas, the full list with their pros and cons can 
> be
> found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
> If you have any questions about some of these, please ask them, we'll be happy
> to answer them and potentially complete this document.
>
>
> For both the release and the changelog fields we believe using RPM macros 
> would
> satisfy the requirements we have for opting-in/out:
>   - You can easily opt-in by using the macros
>   - You can easily opt-out by removing the macros from your spec file
>
>
> For the changelog, we believe we have a potential good solution:
> - The changelog will be automatically generated using an external `changelog`
>   file as well as the commit history
>   - When you opt-in, you will simply move the existing changelog to an 
> external
> file `changelog`, which is placed in the dist-git repo and add the
> appropriate macro.


I assume you are aware about my PR:


https://pagure.io/packaging-committee/pull-request/942


>   - Upon building, the macro will generate the changelog using all the commits
> of the repo up to the last commit touching the `changelog` file.


I proposed, that the changelog file is either included in the repository
or it is not included (probably listed in .gitignore). So it is either
used as it is or if later, then it is generated.

You propose mixture if I understand it correctly. I.e. the changelog
file is always present in the dist-git and it is always is used. But if
there are more recent commits without changelog modifications, they are
prepended to the changelog, but the changelog file itself stays
untouched. E.g. if my latest commit modifies the changelog, the
changelog as it is present in the repo will be used without any
modifications.

I like it. It is opt-in, because I have to place some macro into .spec
file and it is even more or less bacward compatible, because the
automation kicks in only if I don't maintain the changelog manually.


> Of all
> these commits it will only consider the commits following these rules:
> - There are generally two approaches regarding what to include by default:
>   1. commits touching only the `sources`, `.gitignore`, `dead.package`
>  files, `tests` folder will be ignored by default, i.e. a blacklist
>   2. only commits touching the spec file or patches will be included by
>  default, i.e. a whitelist
>   ==> Which approach do you think is better/will work in most cases?
> - empty commits (not touching any files) will be included on the 
> assumption
>   that this is their purpose
> - commits containing "magic keyword" (#changelog_exclude,
>   #changelog_include?) will be ignored or included as the case may be
>   - Finally the content of the changelog file specified will be appended to 
> the
> changelog generated from the git history
>
>
> If you wanted to edit the changelog, you would:
> - Generate the changelog locally via a command like: 
>   `fedpkg generate-changelog > changelog`


This also helps to completely modify the changelog and possible fix some
past errors in git changelog or what not.


> - Edit `changelog` as desired
> - Commit and push the changes
>
> Since the macro will only consider the commits up to the first commit touching
> `changelog` (in other words, the macro will only consider the commits after 
> this
> one) and include `changelog` file as is, your edits will appear in the RPM
> changelog as you want.
>
> One thing to note is that rebuilds from the same commit will have the same
> %changelog, they will not get a new entry. If you want a new changelog entry,
> you have to create a new commit with the desired changelog entry as commit
> message (the commit itself can be empty).
>
>
>
> However, for the release field, we are struggling a little bit more, two 
> options
> are more appealing to us:
>
> A) The release field is automatically generated using two elements:
>   - the number of commits at this version
>   - the number of builds at this commit
>   - the dist-tag being added after them
>   The release field would thus look like:
> ``.%{dist}``
>
> So we could have:  (A, B, C and D being different commits)
>  A -- version: 0.9 -- release: ?
>  |
>  B -- version: 1.0 -- release: 1.0
>  |
>  C -- version: 1.0 -- release: 2.0
>  |
>  D -- version: 1.1 -- release: 1.0
>
> A rebuild of the commit D, would lead to a release 1.1 (assuming the first one
> succeeded)/
>
> Pros:
>  - Easy to replicate locally
>  - Every changelog entry can be mapped to a `version-release` (No

Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Tue, 25 Feb 2020 at 12:47, clime  wrote:
>
> Hey pingou!
>
> On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon  wrote:
> >
> > On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> > > Hello!
> > >
> > > What is the point of including number of builds into release? I think
> > > the Miro's approach solves it.
> > > Or is there any other problem except soname bumps?
> >
> > It makes it easier to do rebuilds which means it makes it easier and 
> > simpler to
> > do mass-rebuilds.
> >
> > > Ad. document - annotated git tags:
> > > (-) Editing the changelog would mean allowing to remove the git tags,
> > > thus leading to potential issue in build reproducibility
> > >
> > > That doesn't need to be the case. In rpkg-util, this was resolved by
> > > introducing arguments since_tag and until_tag
> > > for git_changelog macro
> > > (https://docs.pagure.org/rpkg-util/macro_reference.html#git-macros).
> > > That's
> > > how it can be prevented for some annotated tag to contribute to changelog.
> > >
> > > Example:
> > >
> > > {{{ git_changelog since_tag=name-1.3-1 }}}
> > >
> > > * Mon Feb 24 2020 clime  1.2-1
> > > - manual changelog entry that is used instead of a tag annotation
> > >
> > > {{{ git_changelog until_tag=name-1.1-1 }}}
> >
> > Interesting idea.
> >
> > > Removing already pushed git tags is probably not a good idea anyway:
> > > https://git-scm.com/docs/git-tag#_on_re_tagging
> >
> > We very much agree that removing git tags is not a good idea, that's why we
> > listed it as a con :)
> >
> > > Ad. the following approach for calculating release:
> > > - Compute the release field from the number of commits since the last
> > > version change: -%{dist}
> > >
> > > I think it is a good idea. In rpkg-util, it is done similarly, except
> > > the release part has more subparts than just
> > > two (including %{dist}).
> >
> > If you make the build system provide the ${dirty_appendix} and drop the 
> > ${pivot}
> > (because we want to generate the release, so there is no input specified), 
> > you
> > get very close to what we described.
>
> ${dirty_appendix} is a part intended for development purposes, i.e. to be able
> to have versioned working tree when working locally without committing. It
> will be empty if working tree is clean, which should always be the
> case in a build system
> (there is more info here
> https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_9
> on this).
>
> I am guessing you think about number-of-builds as the
> ${dirty_appendix} ? That would
> need to be a normal rpm macro provided by a build system (similarly to
> %dist). Anyway,
> if the number-of-builds part is just to optimize mass rebuild process,
> I would try to look
> if we can tweak the build system to be able to do the mass rebuilds
> without making
> new commits back to dist-git and even without that %number-of-builds macro. In
> my opinion, it should be possible. There is already BUILDTIME in rpm headers
> that can be used to differentiate between newer and older rpm with otherwise 
> the
> same nevr.
>
> In rpkg-util, ${pivot} (the main release number) is generated
> automatically (when the git_release
> macro is employed) but packager can also hard-set it at any time to
> any value. I think with
> the pivot number, the upgrade-path problem would be solved cause the
> commit-count appendix
> is only used as delta since the last pivot change, which is marked by
> an annotated tag in the git
> tree. So the commit (having an annotated tag on it) in older and newer
> Fedora release (branch)
> would generate an rpm with the same NVR and just the %dist decides
> then (there can
> also be two separate tags if %dist is used in the Release string and
> if it is configured
> not to be empty as i do it now rpkg-util :) but this is another discussion).
>
> The pivot is also useful for post/pre-releases and other cases described here:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning
>
> It is then useful to have something that can be configured by hand.
>
> >
> > > The full description is here:
> > > https://pagure.io/rpkg-util/blob/master/f/man/rpkg_man_page.py#_262
> > > but the main difference is that it counts commits from the latest
> > > annotated tag which contains (in its name)
> > > the current version and the current release number which are extracted
> > > from the spec file when
> > > creating the tag unless they are specified manually on command line.
> > > Commit count is only appended
> > > to it if we build from commit which is on top of some annotated tag
> > > (i.e. it is itself untagged).
> > >
> > > Going by just a textual version change in a spec file might be slightly 
> > > tricky.
> > > You would need to go through all the past commits that touched that spec 
> > > file,
> > > keep checking these out and look if the version is changed when compared 
> > > to the
> > > one parsed from the head commit. Possible though.
> >
> > This is basicall

Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

Hey pingou!

On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon  wrote:
>
> On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> > Hello!
> >
> > What is the point of including number of builds into release? I think
> > the Miro's approach solves it.
> > Or is there any other problem except soname bumps?
>
> It makes it easier to do rebuilds which means it makes it easier and simpler 
> to
> do mass-rebuilds.
>
> > Ad. document - annotated git tags:
> > (-) Editing the changelog would mean allowing to remove the git tags,
> > thus leading to potential issue in build reproducibility
> >
> > That doesn't need to be the case. In rpkg-util, this was resolved by
> > introducing arguments since_tag and until_tag
> > for git_changelog macro
> > (https://docs.pagure.org/rpkg-util/macro_reference.html#git-macros).
> > That's
> > how it can be prevented for some annotated tag to contribute to changelog.
> >
> > Example:
> >
> > {{{ git_changelog since_tag=name-1.3-1 }}}
> >
> > * Mon Feb 24 2020 clime  1.2-1
> > - manual changelog entry that is used instead of a tag annotation
> >
> > {{{ git_changelog until_tag=name-1.1-1 }}}
>
> Interesting idea.
>
> > Removing already pushed git tags is probably not a good idea anyway:
> > https://git-scm.com/docs/git-tag#_on_re_tagging
>
> We very much agree that removing git tags is not a good idea, that's why we
> listed it as a con :)
>
> > Ad. the following approach for calculating release:
> > - Compute the release field from the number of commits since the last
> > version change: -%{dist}
> >
> > I think it is a good idea. In rpkg-util, it is done similarly, except
> > the release part has more subparts than just
> > two (including %{dist}).
>
> If you make the build system provide the ${dirty_appendix} and drop the 
> ${pivot}
> (because we want to generate the release, so there is no input specified), you
> get very close to what we described.

${dirty_appendix} is a part intended for development purposes, i.e. to be able
to have versioned working tree when working locally without committing. It
will be empty if working tree is clean, which should always be the
case in a build system
(there is more info here
https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_9
on this).

I am guessing you think about number-of-builds as the
${dirty_appendix} ? That would
need to be a normal rpm macro provided by a build system (similarly to
%dist). Anyway,
if the number-of-builds part is just to optimize mass rebuild process,
I would try to look
if we can tweak the build system to be able to do the mass rebuilds
without making
new commits back to dist-git and even without that %number-of-builds macro. In
my opinion, it should be possible. There is already BUILDTIME in rpm headers
that can be used to differentiate between newer and older rpm with otherwise the
same nevr.

In rpkg-util, ${pivot} (the main release number) is generated
automatically (when the git_release
macro is employed) but packager can also hard-set it at any time to
any value. I think with
the pivot number, the upgrade-path problem would be solved cause the
commit-count appendix
is only used as delta since the last pivot change, which is marked by
an annotated tag in the git
tree. So the commit (having an annotated tag on it) in older and newer
Fedora release (branch)
would generate an rpm with the same NVR and just the %dist decides
then (there can
also be two separate tags if %dist is used in the Release string and
if it is configured
not to be empty as i do it now rpkg-util :) but this is another discussion).

The pivot is also useful for post/pre-releases and other cases described here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning

It is then useful to have something that can be configured by hand.

>
> > The full description is here:
> > https://pagure.io/rpkg-util/blob/master/f/man/rpkg_man_page.py#_262
> > but the main difference is that it counts commits from the latest
> > annotated tag which contains (in its name)
> > the current version and the current release number which are extracted
> > from the spec file when
> > creating the tag unless they are specified manually on command line.
> > Commit count is only appended
> > to it if we build from commit which is on top of some annotated tag
> > (i.e. it is itself untagged).
> >
> > Going by just a textual version change in a spec file might be slightly 
> > tricky.
> > You would need to go through all the past commits that touched that spec 
> > file,
> > keep checking these out and look if the version is changed when compared to 
> > the
> > one parsed from the head commit. Possible though.
>
> This is basically what I had in mind.

Yes, it takes slightly more computational time than being navigated by tags
themselves that can be used for version bumps as well as release bumps.

>
> > To go back to your original post:
> > > For both the release and the changelog fields we believe using RPM 

LWT 5.1.2? (was: Re: OCaml 4.10.0 build in Fedora 32 and 33)

[Richard W.M. Jones]

In the previous mass build LWT FTBFS because the tests failed on POWER
and s/390 (https://bugzilla.redhat.com/1792780).  There is also a new
version of LWT (https://bugzilla.redhat.com/1755859).  The new version
is noted as an API break, although I don't know how that will affect
other packages.

Anyway I did manage to update LWT to 5.1.2, fix a few things, and do a
scratch build.  The tests even pass on all arches:

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

I didn't push this of course.  What do you think about updating this
package?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Spam on closed bugzilla reports

[Richard W.M. Jones]

On Mon, Feb 24, 2020 at 10:07:15PM -0800, Luya Tshimbalanga wrote:
> Hello team,
> 
> It looks like spammers use closed bug report for their ads as seen
> in this one:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1644013
> 
> Can someone maintaining bugzilla investigate the issue?

There's a self-service way to fix this (I see it's already been done
in this case, but here it is for the record):

(1) On the comment click on the little label icon ("Tags").

(2) Type "spam" into the field and press enter.

This will hide the comment as spam.

These spam comment reports are aggregated by the BZ maintainers and
they will block the spammers' accounts eventually.

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: OCaml 4.10.0 build in Fedora 32 and 33

[Richard W.M. Jones]

On Mon, Feb 24, 2020 at 01:53:37PM -0700, Jerry James wrote:
> On Mon, Feb 24, 2020 at 1:57 AM Richard W.M. Jones  wrote:
> > * z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740
> 
> Actually, z3 should build.  I checked in a workaround.  The bug is
> still open to remind me to figure out and fix the real problem.

Got it, thanks.

> > coq and friends failed last time, but I believe they should work now.
> > Latest status is in this thread:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6I2CB4KNAZXH6TKX5WQZJ3ZQGBIOCNJK/
> 
> I'm still 3 package reviews away from being able to update the coq
> stack.  Real soon now

I guess I could help here.  Do you have a link to any unassigned reviews?

> I may have caused you a problem with the ocaml-ounit update I
> requested.  Now we have ocaml-ounit requiring ocaml-dune to build, and
> ocaml-dune requiring ocaml-ounit to run its tests.  I guess ocaml-dune
> will need a bootstrap mode where it does not run its tests.
>
> That's not going to be the end, either.  There is a new upstream
> release of menhir, and it has switched to using dune to build.  That
> means that we will have menhir requiring dune to build, and dune
> requiring menhir to run its tests.
> 
> And then coq is in the process of switching over to using dune to
> build.  It can still be built the old way, but some day that will not
> be possible.  Then coq will need dune to build, menhir will need coq
> to build, and dune will need menhir to run its tests.

It's actually not so much of a problem with binaries (unlike OCaml
libraries).  Packages that build self-contained binaries (menhir,
dune) don't have to be built in the normal build-dependency order
since the old binaries will presumably still work to build the parser
(menhir) or run the build (dune).  The only problem would be if the
older binary has a bug or lacks a feature which is required to build
the newer package, but I suppose that is not likely.  I guess I'll
find out shortly if this theory is true or not.

The bigger issue is going to be goals itself which, unlike make, will
not arbitrarily break dependency cycles.  However I should still be
able to break those manually in the Goalfile, or failing that
temporarily in the spec file.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-31-20200225.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OCaml 4.10.0 build in Fedora 32 and 33

[Richard W.M. Jones]

On Mon, Feb 24, 2020 at 10:36:41AM -0800, Kevin Fenzi wrote:
> On Mon, Feb 24, 2020 at 10:27:44AM +0100, Fabio Valentini wrote:
> > On Mon, Feb 24, 2020 at 9:57 AM Richard W.M. Jones  
> > wrote:
> > >
> > > OCaml 4.10.0 was released over the weekend.
> > >
> > > We currently have OCaml 4.10.0 beta 1 in Rawhide.  It's not that far
> > > away from 4.10.0.  Unfortunately since building beta 1, Fedora 32 was
> > > forked from Rawhide so we now have the beta 1 build in Fedora 32 as
> > > well.
> > >
> > > Hopefully the plan is as follows:
> > >
> > > (1) Rebuild OCaml 4.10.0 in a side tag then move it to Rawhide.  I
> > > don't expect any difficulties here since all the hard work was already
> > > done when I built beta 1.
> > >
> > > (2) Merge all those changes into the f32 branches of the ocaml*
> > > packages.
> > >
> > > (3) (This is where it gets more speculative because my mass rebuild
> > > script has only ever been run against Rawhide ...)  Rebuild in a side
> > > tag of Fedora 32, and if that goes well then merge the side tag in
> > > F32.
> > >
> > > This should start happening this afternoon / tomorrow.
> > 
> > This is probably bad timing, since the updates-testing activation for
> > f32 is planned for tomorrow, followed by the beta freeze :/
> > See point 12 here:
> > https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
> 
> Yeah, if you start this/it's still running at 14UTC, please check with
> releng. (#fedora-releng irc or I guess email to the releng list). 
> 
> If the f32 bits aren't done, you should be able to submit them as a
> update after we enable bodhi. If they are, we can make sure they get
> landed in the f32 base tag. 

I can start the Rawhide build now, and will wait on the above before
doing the F32 build.  They are sort of separate tasks anyway.

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

Re: Want to claim vault

[Tomasz Torcz]

On Mon, Feb 24, 2020 at 10:12:41PM +, Dave Dykstra wrote:
> I made a ticket (bug #1806737) for the maintainer of the existing vault
> package in Fedora to see if he'd be willing to give it up so it can be
> used for Hashicorp vault (https://vaultproject.io) and he decided to
> mark it EOL so I could claim it.

  We already have some HashiCorp software packages (dnf search hashicorp),
maybe you can reuse some ideas.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Nicolas Mailhot via devel]

Le 2020-02-25 10:24, Pierre-Yves Chibon a écrit :

If you make the build system provide the ${dirty_appendix} and drop the 
${pivot}
(because we want to generate the release, so there is no input 
specified), you

get very close to what we described.


BTW, regardless of how things up, we have existing logic that computes 
dist prefixes (unpstream git commit numbers…) and appendixes 
(bootstrap…).


The easy way to do things is to let things as they stand today and limit 
the automation to the main release number, but that still requires 
adding those things to changelog entries (if we want to trace them in 
changelogs; we probably want because a project that does not releases 
will be stuck at version 0 forever, only the distprefix disambiguates 
what version 0 means)


OTOH, if people feel ambitious, and want to reexamine all the dist 
prefix/appendix logic, there is quite a lot of work to audit the 
hundreds of packages that use them today and define a migration plan and 
logic. Because this amount of spec logic is not going to rewrite itself, 
and expecting someone else (packagers) to do it will throw a non trivial 
part of the distro under the bus.


(The correct way to do things would be to evolve rpm to have dedicated 
fields for all the things we crammed into Release in the past. That’s a 
non trivial endeavour.)


Regards,

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> Hello!
> 
> What is the point of including number of builds into release? I think
> the Miro's approach solves it.
> Or is there any other problem except soname bumps?

It makes it easier to do rebuilds which means it makes it easier and simpler to
do mass-rebuilds.

> Ad. document - annotated git tags:
> (-) Editing the changelog would mean allowing to remove the git tags,
> thus leading to potential issue in build reproducibility
> 
> That doesn't need to be the case. In rpkg-util, this was resolved by
> introducing arguments since_tag and until_tag
> for git_changelog macro
> (https://docs.pagure.org/rpkg-util/macro_reference.html#git-macros).
> That's
> how it can be prevented for some annotated tag to contribute to changelog.
> 
> Example:
> 
> {{{ git_changelog since_tag=name-1.3-1 }}}
> 
> * Mon Feb 24 2020 clime  1.2-1
> - manual changelog entry that is used instead of a tag annotation
> 
> {{{ git_changelog until_tag=name-1.1-1 }}}

Interesting idea.

> Removing already pushed git tags is probably not a good idea anyway:
> https://git-scm.com/docs/git-tag#_on_re_tagging

We very much agree that removing git tags is not a good idea, that's why we
listed it as a con :)

> Ad. the following approach for calculating release:
> - Compute the release field from the number of commits since the last
> version change: -%{dist}
> 
> I think it is a good idea. In rpkg-util, it is done similarly, except
> the release part has more subparts than just
> two (including %{dist}).

If you make the build system provide the ${dirty_appendix} and drop the ${pivot}
(because we want to generate the release, so there is no input specified), you
get very close to what we described.

> The full description is here:
> https://pagure.io/rpkg-util/blob/master/f/man/rpkg_man_page.py#_262
> but the main difference is that it counts commits from the latest
> annotated tag which contains (in its name)
> the current version and the current release number which are extracted
> from the spec file when
> creating the tag unless they are specified manually on command line.
> Commit count is only appended
> to it if we build from commit which is on top of some annotated tag
> (i.e. it is itself untagged).
> 
> Going by just a textual version change in a spec file might be slightly 
> tricky.
> You would need to go through all the past commits that touched that spec file,
> keep checking these out and look if the version is changed when compared to 
> the
> one parsed from the head commit. Possible though.

This is basically what I had in mind.

> To go back to your original post:
> > For both the release and the changelog fields we believe using RPM macros 
> > would
> > satisfy the requirements we have for opting-in/out:
> 
> By using such RPM macros, you would lose ability to rebuild srpms
> because it will
> be only possible to build them when the git context is present but not when 
> they
> become a standalone thing. I.e. things like this will not work:
> 
> https://github.com/rpm-software-management/mock/blob/cfe34c8a57/mock/py/mockbuild/backend.py#L270
> 
> That's why I think that such macros should be of a different kind:
> macros that are computed
> once when srpm is created and result of which is put _verbatim_ into
> the spec file so that
> there is no (re)computation later when srpm is being built and when
> the git context is already
> missing.
 
We had a discussion with Neal about this topic on #fedora-apps yesterday and I
believe one of the outcome of this discussion was that we should indeed use this
approach, for the reasons you're mentioning.


Thanks for your feedbacks and thoughts (and links!)

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Want to claim vault

[Mattia Verga via devel]

Il 24/02/20 23:12, Dave Dykstra ha scritto:
> I made a ticket (bug #1806737) for the maintainer of the existing vault
> package in Fedora to see if he'd be willing to give it up so it can be
> used for Hashicorp vault (https://vaultproject.io) and he decided to
> mark it EOL so I could claim it.
>
> Dave
> ___

I don't think it is allowed to reuse the git repo (and the name) of a 
retired package for a completely different one, even if their name it's 
the same...

In my opinion you should file a review ticket for the new package with a 
name which avoid present and future conflicts, the name 'vault' is just 
too generic: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_conflicting_package_names

Maybe someone with more knowledge here can tell you the right procedure 
for this case.

Mattia

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Tue, Feb 25, 2020 at 09:06:35AM +0100, Petr Pisar wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > - commits containing "magic keyword" (#changelog_exclude,
> >   #changelog_include?) will be ignored or included as the case may be
> 
> Could we please use the usual git commit keyword syntax? I.e. the e-mail
> header format (Signed-off-by:). E.g.:
> 
> RPM-Changelog: include
> RPM-Changelog: exclude
> 
> > If you wanted to edit the changelog, you would:
> > - Generate the changelog locally via a command like: 
> >   `fedpkg generate-changelog > changelog`
> > - Edit `changelog` as desired
> > - Commit and push the changes
> >
> If the changelog file name is hard-coded, I recommend "fedpkg
> generate-changelog" command to write directly into the "changelog" file.

Two good ideas, thanks :)


Pierre


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: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Mon, Feb 24, 2020 at 10:05:31PM +0100, Miroslav Suchý wrote:
> Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
> > Can we please have a "git is the only source of truth" version of this? 
> > I.e. "Compute the release field from the number
> > of commits since the last version change" in the document. It seem to only 
> > have one con (breaks if two builds are
> > triggered from the same commit) which is the status quo.
> > 
> 
> +1
> 
> Or the combination of:
>   Get the release field from the annotation of the git tag
> and
>   Get the release field using the number of tags since the last version change
> If the regexp does not match, just count the tags (or the commits).

We addressed git tags in the hackmd doc and we were not very thrilled with the
idea. It seems fragile (parsing/regex) and if the changelog is included in the
git tag, packagers still have to maintain 3 different changelogs.

> And BTW I like the changelog proposal.
Thanks :)
It's a bit of a tricky situation since we tend to consider both release and
changelog separately but they are also very much related since the release
appears in the changelog.
So if we want to keep the current changelog format, we need to consider them
together (of we accept to change the structure of the changelog)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Mon, Feb 24, 2020 at 07:30:15PM +0100, Nicolas Mailhot via devel wrote:
> Le lundi 24 février 2020 à 18:13 +0100, Miro Hrončok a écrit :
> > On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > > However, for the release field, we are struggling a little bit
> > > more, two options
> > > are more appealing to us:
> > 
> > Can we please have a "git is the only source of truth" version of
> > this? 
> 
> Packages have a life in review before they get a Fedora git (sometimes
> the life can be years in copr, OBS or elsewhere as our review process
> is none too fast)

I guess this means the first version that lands in Fedora will not have a -1
release, is that a real problem?
Don't we already have this anyway since often we bump the release and changelog
during the review process to address the reviewer's comments?


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1806724] perl-HTTP-Message-6.22 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-465920564b has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-465920564b

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

perl-HTTP-Message license correction

[Petr Pisar]

I corrected a license tag for perl-HTTP-Message package from
"GPL+ or Artistic" to "(GPL+ or Artistic) and CC0". It should not affect other
packages because the CC0 license is only used for a documentation file.

-- 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: Subject: Self Introduction: Francis Gesora

[Francis Gesora]

Jambo Benson,

Glad to be here.

Thanks!

On Tue, Feb 25, 2020 at 11:33 AM Benson Muite 
wrote:

>
>
>
>
> On Tue, Feb 25, 2020, at 11:17 AM, Francis Gesora wrote:
>
> Hi All,
>
> I am Francis, based in Nairobi, Kenya.
>
> I am joining as a package maintainer to assist Ankur manage xmedcon and
> deps as i get up to speed with package maintenance.
>
> Hello/Hujambo Gesora,
>
> Awesome to have you here.
>
> Regards,
> Benson
>
>
> Thanks!
>
> --
> Regards,
> Gesora.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
Regards,
Gesora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Pierre-Yves Chibon]

On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two 
> > options
> > are more appealing to us:
> 
> Can we please have a "git is the only source of truth" version of this? I.e.
> "Compute the release field from the number of commits since the last version
> change" in the document. It seem to only have one con (breaks if two builds
> are triggered from the same commit) which is the status quo.

It has another con which is indeed not mentioned in this section but in the next
one (n_commits+n_build) (I've fixed that).
Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).

> If you need to rebuild for a libpingouisawesome soname bump, you just do an
> empty commit with the explanation.
> 
> If you merge that empty commit to a branch that did not need it, it would
> have a bogus changelog entry (status quo). If you care, you would not merge
> but cherry-pick anything thta comes next (which is now much easier given the
> benefit of not having the %changelog and release).
> 
> With the proposed solution that includes "successful build count" you always
> bump and build even if it is not needed and also you make the release number
> depend on a specific build system, which I think is kinda wrong.

One of the benefit of the approach using number of commits + number of builds
(when it's > 1) is that mass-rebuild could be made even simpler and faster.
Instead of doing git commit + koji build, you would simply do koji build.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Tue, 25 Feb 2020 at 09:31, clime  wrote:
>
> Hello Adam!
>
> On Tue, 25 Feb 2020 at 08:58, Adam Saleh  wrote:
> >
> > Nice, I have been trying to fight through the 'git context already missing' 
> > with pure lua rpm macros,
> > and so far was hitting walls left and right :-)
> >
> > Will look at https://pagure.io/rpkg-util, might have more questions :-)
>
> You have probably already noticed...the docs at
> https://docs.pagure.org/rpkg-util/index.html
> are for rpkg-util version that is currently in Fedora but it contains
> some nice introduction, nevertheless.
>
> The (newer) git version from the pagure repository has some features
> (e.g. git_release macro),
> which are not yet documented there.
>
> man page of the git version ($ man rpkg) is up to date, however.
>
> Thank you for looking at it.
> clime

...in case of any questions i am on this email or on #fedora-apps. Again,
thanks for looking at it. Cheers.

>
> >
> > Adam
> >
> > On Tue, Feb 25, 2020 at 12:20 AM clime  wrote:
> >>
> >> Hello!
> >>
> >> On Mon, 24 Feb 2020 at 17:50, Pierre-Yves Chibon  
> >> wrote:
> >> >
> >> > Good Morning Everyone,
> >> >
> >> > This topic has already been discussed a few times over the past month, 
> >> > but Adam
> >> > Saleh, Nils Philippsen and myself have had the opportunity to invest 
> >> > some time
> >> > on it with the hope of making the packager's life simpler as well as 
> >> > making it
> >> > easier to build automation around our package maintenance.
> >> >
> >> > We have investigated a few ideas, the full list with their pros and cons 
> >> > can be
> >> > found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
> >> > If you have any questions about some of these, please ask them, we'll be 
> >> > happy
> >> > to answer them and potentially complete this document.
> >> >
> >> >
> >> > For both the release and the changelog fields we believe using RPM 
> >> > macros would
> >> > satisfy the requirements we have for opting-in/out:
> >> >   - You can easily opt-in by using the macros
> >> >   - You can easily opt-out by removing the macros from your spec file
> >> >
> >> >
> >> > For the changelog, we believe we have a potential good solution:
> >> > - The changelog will be automatically generated using an external 
> >> > `changelog`
> >> >   file as well as the commit history
> >> >   - When you opt-in, you will simply move the existing changelog to an 
> >> > external
> >> > file `changelog`, which is placed in the dist-git repo and add the
> >> > appropriate macro.
> >> >   - Upon building, the macro will generate the changelog using all the 
> >> > commits
> >> > of the repo up to the last commit touching the `changelog` file. Of 
> >> > all
> >> > these commits it will only consider the commits following these 
> >> > rules:
> >> > - There are generally two approaches regarding what to include by 
> >> > default:
> >> >   1. commits touching only the `sources`, `.gitignore`, 
> >> > `dead.package`
> >> >  files, `tests` folder will be ignored by default, i.e. a 
> >> > blacklist
> >> >   2. only commits touching the spec file or patches will be included 
> >> > by
> >> >  default, i.e. a whitelist
> >> >   ==> Which approach do you think is better/will work in most cases?
> >> > - empty commits (not touching any files) will be included on the 
> >> > assumption
> >> >   that this is their purpose
> >> > - commits containing "magic keyword" (#changelog_exclude,
> >> >   #changelog_include?) will be ignored or included as the case may be
> >> >   - Finally the content of the changelog file specified will be appended 
> >> > to the
> >> > changelog generated from the git history
> >> >
> >> >
> >> > If you wanted to edit the changelog, you would:
> >> > - Generate the changelog locally via a command like:
> >> >   `fedpkg generate-changelog > changelog`
> >> > - Edit `changelog` as desired
> >> > - Commit and push the changes
> >> >
> >> > Since the macro will only consider the commits up to the first commit 
> >> > touching
> >> > `changelog` (in other words, the macro will only consider the commits 
> >> > after this
> >> > one) and include `changelog` file as is, your edits will appear in the 
> >> > RPM
> >> > changelog as you want.
> >> >
> >> > One thing to note is that rebuilds from the same commit will have the 
> >> > same
> >> > %changelog, they will not get a new entry. If you want a new changelog 
> >> > entry,
> >> > you have to create a new commit with the desired changelog entry as 
> >> > commit
> >> > message (the commit itself can be empty).
> >> >
> >> >
> >> >
> >> > However, for the release field, we are struggling a little bit more, two 
> >> > options
> >> > are more appealing to us:
> >> >
> >> > A) The release field is automatically generated using two elements:
> >> >   - the number of commits at this version
> >> >   - the number of builds at this commit
> >> >   - the dist-tag being added 

Re: Subject: Self Introduction: Francis Gesora

[Benson Muite]

On Tue, Feb 25, 2020, at 11:17 AM, Francis Gesora wrote:
> Hi All,
> 
> I am Francis, based in Nairobi, Kenya.
> 
> I am joining as a package maintainer to assist Ankur manage xmedcon and deps 
> as i get up to speed with package maintenance.
Hello/Hujambo Gesora,

Awesome to have you here.

Regards,
Benson
> 
> Thanks!
> 
> -- 
> Regards,
> Gesora.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[clime]

Hello Adam!

On Tue, 25 Feb 2020 at 08:58, Adam Saleh  wrote:
>
> Nice, I have been trying to fight through the 'git context already missing' 
> with pure lua rpm macros,
> and so far was hitting walls left and right :-)
>
> Will look at https://pagure.io/rpkg-util, might have more questions :-)

You have probably already noticed...the docs at
https://docs.pagure.org/rpkg-util/index.html
are for rpkg-util version that is currently in Fedora but it contains
some nice introduction, nevertheless.

The (newer) git version from the pagure repository has some features
(e.g. git_release macro),
which are not yet documented there.

man page of the git version ($ man rpkg) is up to date, however.

Thank you for looking at it.
clime

>
> Adam
>
> On Tue, Feb 25, 2020 at 12:20 AM clime  wrote:
>>
>> Hello!
>>
>> On Mon, 24 Feb 2020 at 17:50, Pierre-Yves Chibon  wrote:
>> >
>> > Good Morning Everyone,
>> >
>> > This topic has already been discussed a few times over the past month, but 
>> > Adam
>> > Saleh, Nils Philippsen and myself have had the opportunity to invest some 
>> > time
>> > on it with the hope of making the packager's life simpler as well as 
>> > making it
>> > easier to build automation around our package maintenance.
>> >
>> > We have investigated a few ideas, the full list with their pros and cons 
>> > can be
>> > found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
>> > If you have any questions about some of these, please ask them, we'll be 
>> > happy
>> > to answer them and potentially complete this document.
>> >
>> >
>> > For both the release and the changelog fields we believe using RPM macros 
>> > would
>> > satisfy the requirements we have for opting-in/out:
>> >   - You can easily opt-in by using the macros
>> >   - You can easily opt-out by removing the macros from your spec file
>> >
>> >
>> > For the changelog, we believe we have a potential good solution:
>> > - The changelog will be automatically generated using an external 
>> > `changelog`
>> >   file as well as the commit history
>> >   - When you opt-in, you will simply move the existing changelog to an 
>> > external
>> > file `changelog`, which is placed in the dist-git repo and add the
>> > appropriate macro.
>> >   - Upon building, the macro will generate the changelog using all the 
>> > commits
>> > of the repo up to the last commit touching the `changelog` file. Of all
>> > these commits it will only consider the commits following these rules:
>> > - There are generally two approaches regarding what to include by 
>> > default:
>> >   1. commits touching only the `sources`, `.gitignore`, `dead.package`
>> >  files, `tests` folder will be ignored by default, i.e. a blacklist
>> >   2. only commits touching the spec file or patches will be included by
>> >  default, i.e. a whitelist
>> >   ==> Which approach do you think is better/will work in most cases?
>> > - empty commits (not touching any files) will be included on the 
>> > assumption
>> >   that this is their purpose
>> > - commits containing "magic keyword" (#changelog_exclude,
>> >   #changelog_include?) will be ignored or included as the case may be
>> >   - Finally the content of the changelog file specified will be appended 
>> > to the
>> > changelog generated from the git history
>> >
>> >
>> > If you wanted to edit the changelog, you would:
>> > - Generate the changelog locally via a command like:
>> >   `fedpkg generate-changelog > changelog`
>> > - Edit `changelog` as desired
>> > - Commit and push the changes
>> >
>> > Since the macro will only consider the commits up to the first commit 
>> > touching
>> > `changelog` (in other words, the macro will only consider the commits 
>> > after this
>> > one) and include `changelog` file as is, your edits will appear in the RPM
>> > changelog as you want.
>> >
>> > One thing to note is that rebuilds from the same commit will have the same
>> > %changelog, they will not get a new entry. If you want a new changelog 
>> > entry,
>> > you have to create a new commit with the desired changelog entry as commit
>> > message (the commit itself can be empty).
>> >
>> >
>> >
>> > However, for the release field, we are struggling a little bit more, two 
>> > options
>> > are more appealing to us:
>> >
>> > A) The release field is automatically generated using two elements:
>> >   - the number of commits at this version
>> >   - the number of builds at this commit
>> >   - the dist-tag being added after them
>> >   The release field would thus look like:
>> > ``.%{dist}``
>> >
>> > So we could have:  (A, B, C and D being different commits)
>> >  A -- version: 0.9 -- release: ?
>> >  |
>> >  B -- version: 1.0 -- release: 1.0
>> >  |
>> >  C -- version: 1.0 -- release: 2.0
>> >  |
>> >  D -- version: 1.1 -- release: 1.0
>> >
>> > A rebuild of the commit D, would lead to a release 1.1 (assuming the first 
>> > one
>> > succeeded)/
>> >
>> >

Fedora-Cloud-30-20200225.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Subject: Self Introduction: Francis Gesora

[Francis Gesora]

Hi All,

I am Francis, based in Nairobi, Kenya.

I am joining as a package maintainer to assist Ankur manage xmedcon and
deps as i get up to speed with package maintenance.

Thanks!

-- 
Regards,
Gesora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Petr Pisar]

On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> - commits containing "magic keyword" (#changelog_exclude,
>   #changelog_include?) will be ignored or included as the case may be

Could we please use the usual git commit keyword syntax? I.e. the e-mail
header format (Signed-off-by:). E.g.:

RPM-Changelog: include
RPM-Changelog: exclude

> If you wanted to edit the changelog, you would:
> - Generate the changelog locally via a command like: 
>   `fedpkg generate-changelog > changelog`
> - Edit `changelog` as desired
> - Commit and push the changes
>
If the changelog file name is hard-coded, I recommend "fedpkg
generate-changelog" command to write directly into the "changelog" file.

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