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

[Adam Saleh]

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

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)/
> >
> > Pros:
> >  - Easy to replicate locally
> >  - Every changelog entry can be mapped to a `version-release` (No
> changes to the
> >packaging guidelines)
> >  - Allows triggering two builds from the same commit without any manual
> change
> >(simplifies mass-rebuilds)
> >  - Easy to link a certain build with a specific commit
> >  - Easy to “guess” the next release value before triggering the build
> >
> > Cons:
> >   - Old packages which are no longer receiving upstream releases may need
> > special care (for example if they are at the release -48 but only
> had 45
> > commits leading to this)
> >   -  Relies on information from the 

Re: Non-responsive maintainer: pocock

[Artur Iwicki]

On FSF Europe's mailing lists, DP's using the "daniel at pocock dot pro" 
address. I guess you could try messaging him using that address.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Minimize systemd for kdump's initramfs

[Kairui Song]

On Tue, Feb 25, 2020 at 3:07 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote:
> > On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > > > On 01/03/20 at 11:45am, Dave Young wrote:
> > > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > > > Some component, like Systemd, have grown by a lot, here is a list 
> > > > > > > of
> > > > > > > the size of part of binaries along with the binaries they 
> > > > > > > required in
> > > > > > > F31:
> > > > > > > /root/image/bin/systemctl
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemctl
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-cgls
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-escape
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-run
> > > > > > > 20M .
> > > > > > > ...
> > > > > > >
> > > > > > > There are overlays between the libraries they used so when 
> > > > > > > installed
> > > > > > > into the initramfs, the total size didn't go too big yet. But we 
> > > > > > > can
> > > > > > > see the size of systemd binary and libraries it used is much 
> > > > > > > bigger
> > > > > > > than others.
> > > > > >
> > > > > > All systemd binaries will mostly link to the same libraries (because
> > > > > > they link to a private shared library, which links to various other
> > > > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > > > it's the same dependencies.
> > > > > >
> > > > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > > > not that much...
> > > > > >
> > > > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > > > dependency increased a lot:
> > > > > > > (v219 is 5M in total, v243 is 20M in total)
> > > > > >
> > > > > > This is slightly misleading. Code was moved from individual binaries
> > > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a 
> > > > > > single
> > > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so 
> > > > > > has
> > > > > > more deps). But the total number of deps when summed over all 
> > > > > > binaries
> > > > > > grew much less. A more useful measure would be the size with deps 
> > > > > > summed
> > > > > > over all systemd binaries that are installed into your image in 
> > > > > > v219 and
> > > > > > v243.
> > > > > >
> > > > >
> > > > > I vaguely remember the size increased before due to linking with 
> > > > > libidn2
> > > > > previously, so those libraries contribute a lot.
> > > > >
> > > > > Does every systemd binary depend on all libraries? Or each of the
> > > > > systemd binary only depends on those libs when really needed?
> > > >
> > > > For example if I do not need journalctl, then I can drop journalctl and
> > > > those libraries specific for journalctl?
> > >
> > > It's using standard shared object linking, so yeah, for anything which
> > > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> > > all libraries", in the sense that the runtime linker will fail to start
> > > the executable if any of the libraries are missing.
> > >
> >
> > Hi, it has been a while since last discuss update, but a second
> > thought about the libsystemd-shared-nnn.so problem:
> >
> > Now each systemd executable depends on libsystemd-shared-nnn.so, which
> > then depend on a lot of things. In older version (eg. version 219),
> > each individual systemd executable have it's own dependency, that make
> > thing much cleaner for special usages like kdump.
> >
> > I'm not sure what is the purpose of this change, could there be any
> > work be done to minimize the lib dependency of each systemd binary?
>
> libsystemd-shared-nnn.so holds code used in multiple executables. This
> means that if the full suite is installed, shared code is present in
> just one copy, and the total footprint of the installation is minimized
> (disk, loading time, rss). OTOH, the footprint of installing just a
> single executable is unfortunately increased. Our thinking was that
> installing many executables is much more common (pretty even a minimal
> system with systemd has at least ~30 systemd binaries), so it makes
> sense to prioritize that.

Yes, that's very true, this kind of usage (single binary intallation)
is quite rare.

>
> See https://github.com/systemd/systemd/pull/3516 for the discussion
> of the space savings back when this was originally done. Now we have
> many more binaries (and even more shared code since integration of
> various components is increasing...), so I expect the savings to
> be even bigger.
>
> Zbyszek
>

Thanks for the info, the PR reference is very useful. Will check it
for more background knowledge.

-- 
Best Regards,
Kairui Song

Re: Minimize systemd for kdump's initramfs

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote:
> On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > > On 01/03/20 at 11:45am, Dave Young wrote:
> > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > > > the size of part of binaries along with the binaries they required 
> > > > > > in
> > > > > > F31:
> > > > > > /root/image/bin/systemctl
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemctl
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-cgls
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-escape
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-run
> > > > > > 20M .
> > > > > > ...
> > > > > >
> > > > > > There are overlays between the libraries they used so when installed
> > > > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > > > see the size of systemd binary and libraries it used is much bigger
> > > > > > than others.
> > > > >
> > > > > All systemd binaries will mostly link to the same libraries (because
> > > > > they link to a private shared library, which links to various other
> > > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > > it's the same dependencies.
> > > > >
> > > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > > not that much...
> > > > >
> > > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > > dependency increased a lot:
> > > > > > (v219 is 5M in total, v243 is 20M in total)
> > > > >
> > > > > This is slightly misleading. Code was moved from individual binaries
> > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a 
> > > > > single
> > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so 
> > > > > has
> > > > > more deps). But the total number of deps when summed over all binaries
> > > > > grew much less. A more useful measure would be the size with deps 
> > > > > summed
> > > > > over all systemd binaries that are installed into your image in v219 
> > > > > and
> > > > > v243.
> > > > >
> > > >
> > > > I vaguely remember the size increased before due to linking with libidn2
> > > > previously, so those libraries contribute a lot.
> > > >
> > > > Does every systemd binary depend on all libraries? Or each of the
> > > > systemd binary only depends on those libs when really needed?
> > >
> > > For example if I do not need journalctl, then I can drop journalctl and
> > > those libraries specific for journalctl?
> >
> > It's using standard shared object linking, so yeah, for anything which
> > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> > all libraries", in the sense that the runtime linker will fail to start
> > the executable if any of the libraries are missing.
> >
> 
> Hi, it has been a while since last discuss update, but a second
> thought about the libsystemd-shared-nnn.so problem:
> 
> Now each systemd executable depends on libsystemd-shared-nnn.so, which
> then depend on a lot of things. In older version (eg. version 219),
> each individual systemd executable have it's own dependency, that make
> thing much cleaner for special usages like kdump.
> 
> I'm not sure what is the purpose of this change, could there be any
> work be done to minimize the lib dependency of each systemd binary?

libsystemd-shared-nnn.so holds code used in multiple executables. This
means that if the full suite is installed, shared code is present in
just one copy, and the total footprint of the installation is minimized
(disk, loading time, rss). OTOH, the footprint of installing just a
single executable is unfortunately increased. Our thinking was that
installing many executables is much more common (pretty even a minimal
system with systemd has at least ~30 systemd binaries), so it makes
sense to prioritize that.

See https://github.com/systemd/systemd/pull/3516 for the discussion
of the space savings back when this was originally done. Now we have
many more binaries (and even more shared code since integration of
various components is increasing...), so I expect the savings to
be even bigger.

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

Spam on closed bugzilla reports

[Luya Tshimbalanga]

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?

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Minimize systemd for kdump's initramfs

[Kairui Song]

On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > On 01/03/20 at 11:45am, Dave Young wrote:
> > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > > the size of part of binaries along with the binaries they required in
> > > > > F31:
> > > > > /root/image/bin/systemctl
> > > > > 20M .
> > > > > /root/image/usr/bin/systemctl
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-cgls
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-escape
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-run
> > > > > 20M .
> > > > > ...
> > > > >
> > > > > There are overlays between the libraries they used so when installed
> > > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > > see the size of systemd binary and libraries it used is much bigger
> > > > > than others.
> > > >
> > > > All systemd binaries will mostly link to the same libraries (because
> > > > they link to a private shared library, which links to various other
> > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > it's the same dependencies.
> > > >
> > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > not that much...
> > > >
> > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > dependency increased a lot:
> > > > > (v219 is 5M in total, v243 is 20M in total)
> > > >
> > > > This is slightly misleading. Code was moved from individual binaries
> > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> > > > more deps). But the total number of deps when summed over all binaries
> > > > grew much less. A more useful measure would be the size with deps summed
> > > > over all systemd binaries that are installed into your image in v219 and
> > > > v243.
> > > >
> > >
> > > I vaguely remember the size increased before due to linking with libidn2
> > > previously, so those libraries contribute a lot.
> > >
> > > Does every systemd binary depend on all libraries? Or each of the
> > > systemd binary only depends on those libs when really needed?
> >
> > For example if I do not need journalctl, then I can drop journalctl and
> > those libraries specific for journalctl?
>
> It's using standard shared object linking, so yeah, for anything which
> libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> all libraries", in the sense that the runtime linker will fail to start
> the executable if any of the libraries are missing.
>

Hi, it has been a while since last discuss update, but a second
thought about the libsystemd-shared-nnn.so problem:

Now each systemd executable depends on libsystemd-shared-nnn.so, which
then depend on a lot of things. In older version (eg. version 219),
each individual systemd executable have it's own dependency, that make
thing much cleaner for special usages like kdump.

I'm not sure what is the purpose of this change, could there be any
work be done to minimize the lib dependency of each systemd binary?


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

[389-devel] 389 DS nightly 2020-02-25 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/25/report-389-ds-base-1.4.3.3-20200225git3963b02.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1781745] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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

Orion Poplawski  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-25 03:59:48



--- Comment #2 from Orion Poplawski  ---
Done.  Sorry this got missed for so long.

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

Re: Fedora 32 Wifi Loss

[Mark Bidewell]

On Mon, Feb 24, 2020 at 8:59 PM Samuel Sieb  wrote:

> On 2/24/20 5:51 PM, Mark Bidewell wrote:
> > Looks like an issue with firmware:
> >
> > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: no
> > suitable firmware found!
> > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: minimum
> > version required: (null)0
> > Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: maximum
> > version supported: (null)39
>
> Definitely looks like a driver bug.  You could file a report on the
> kernel bugzilla.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

Thanks!  I created:
https://bugzilla.kernel.org/show_bug.cgi?id=206661

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

Re: Fedora 32 Wifi Loss

[Samuel Sieb]

On 2/24/20 5:51 PM, Mark Bidewell wrote:

Looks like an issue with firmware:

Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: no 
suitable firmware found!
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: minimum 
version required: (null)0
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: maximum 
version supported: (null)39


Definitely looks like a driver bug.  You could file a report on the 
kernel bugzilla.

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

Re: Fedora 32 Wifi Loss

[Mark Bidewell]

On Mon, Feb 24, 2020 at 4:27 PM Samuel Sieb  wrote:

> On 2/24/20 1:02 PM, Mark Bidewell wrote:
> > Sorry if this is the wrong list for this, but since this refers to
> > Fedora 32 I figured I would start here. I updated to the Fedora 32
> > Branched release and my Wifi no longer enables on the 5.6 RC kernel.
> > lspci still shows the wireless card by the is no wifi section in Gnome
> > settings and ip addr show does not show the card.  Leftover kernels from
> > F31 still work fine with Wifi.  My card is an Intel Wireless AC 9260
> >
> > Any suggestions on how to debug?
>
> Check the journal for messages about it.  Run "sudo journalctl -b" to
> see the logs from the current boot.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

Looks like an issue with firmware:

Feb 24 20:32:51 precision7530-lan kernel: Intel(R) Wireless WiFi driver for
Linux
Feb 24 20:32:51 precision7530-lan kernel: Copyright(c) 2003- 2015 Intel
Corporation
Feb 24 20:32:51 precision7530-lan kernel: mc: Linux media interface: v0.10
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: enabling
device ( -> 0002)
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)39.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)38.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)37.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)36.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)35.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)34.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)33.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)32.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)31.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)30.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)29.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)28.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)27.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)26.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)25.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)24.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)23.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)22.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)21.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)20.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)19.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)18.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)17.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)16.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)15.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)14.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)13.ucode failed with error -2
Feb 24 20:32:51 precision7530-lan kernel: iwlwifi :6e:00.0: Direct
firmware load for (null)12.ucode failed with error -2

Re: Fedora 32 Wifi Loss

[Chris Murphy]

On Mon, Feb 24, 2020, 2:03 PM Mark Bidewell  wrote:

> Sorry if this is the wrong list for this, but since this refers to Fedora
> 32 I figured I would start here. I updated to the Fedora 32 Branched
> release and my Wifi no longer enables on the 5.6 RC kernel.  lspci still
> shows the wireless card by the is no wifi section in Gnome settings and ip
> addr show does not show the card.  Leftover kernels from F31 still work
> fine with Wifi.  My card is an Intel Wireless AC 9260
>
> Any suggestions on how to debug?
>

Check bugzilla.kernel.org or a Google searxh with quotes:
"iwlwifi" "9260"
And set time in the last month.

Could be related to

https://bugzilla.kernel.org/show_bug.cgi?id=206329


> --
> Mark Bidewell
> http://www.linkedin.com/in/markbidewell
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

[EPEL-devel] Re: Looking for new maintainer: nagios, nagios-plugins, nrpe

[Eduardo Kienetz]

It would be my first time maintaining an EPEL package, but if nobody else
already experienced is willing, I could probably do it with minimal
supervision/hints to get started :)
What has been the typical work? If they have git repos I can probably get a
good understanding from the commits.

Thanks,
Eduardo Kienetz
eduardok @ freenode

On Mon, 24 Feb 2020 at 17:21, 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.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[clime]

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)/
>
> Pros:
>  - Easy to replicate locally
>  - Every changelog entry can be mapped to a `version-release` (No changes to 
> the
>packaging guidelines)
>  - Allows triggering two builds from the same commit without any manual change
>(simplifies mass-rebuilds)
>  - Easy to link a certain build with a specific commit
>  - Easy to “guess” the next release value before triggering the build
>
> Cons:
>   - Old packages which are no longer receiving upstream releases may need
> special care (for example if they are at the release -48 but only had 45
> commits leading to this)
>   -  Relies on information from the build system for the build number (but can
>  be closely simulated locally since the  info is only used for
>  rebuilds)
>   -  Upgrade path may be problematic if Fn is upgraded to version X with one
>  commit while Fn-1 is upgrade to version X with 2 commits (or more)
>
>
> B) The release field is automatically generated taking existing builds in all
> current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This means 
> for
> builds of the same epoch:version, find a new release 

Re: Looking for new maintainer: nagios, nagios-plugins, nrpe

[Martin Jackson]

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

Re: Cross-arch dependencies for plugins (NSS and others)

[James Cassell]

On Mon, Feb 24, 2020, at 4:51 PM, Florian Weimer wrote:
> * James Cassell:
> 
> > On Mon, Feb 24, 2020, at 1:11 PM, Florian Weimer wrote:
> >> Sometimes, users run into problems because they install nss_nis on
> >> x86_64 and want to use 32-bit applications, but those do not work
> >> correctly because nss_nis.i686 is not installed.  I think we have an
> >> opportunity here to improve the system administrator experience with
> >> reasonable effort.
> >> 
> >> If we add this to nss_nis.spec:
> >> 
> >> %ifarch x86_64
> >> Recommends: (nss_nis(x86-32) if glibc(x86-32))
> >> %endif
> >
> > What about also adding
> >
> > %ifarch i686
> > Supplements: (glibc(x86-32) if (nss_nis(x86-64))
> > %endif
> >
> > (Untested)
> 
> Does this have the same non-ideal behavior regarding late installation
> of glibc.i686?
> 

I believe the combo of the two will avoid the late install issue, and also 
avoid modifying any other SPEC. Again, not tested.

> > I'd greatly prefer to avoid hard deps where they aren't absolutely
> > necessary.
> 
> Recommends: isn't a hard dependency?
> 

Recommends is weak. I was referring to another message in the thread that 
suggested using Depends:

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

[Fabio Valentini]

On Mon, Feb 24, 2020 at 11:23 PM Iñaki Ucar  wrote:
>
> On Mon, 24 Feb 2020 at 23:13, Ben Cotton  wrote:
> >
> > 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.
> >
> > 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?
>
> Similar to other procedures for non-responsive people I guess: after a
> timeout, set a flag and post a comment there, and if nobody steps up
> to take it, close it.
>
> > 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.
>
> Sounds reasonable.
>
> Iñaki

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

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?

[Iñaki Ucar]

On Mon, 24 Feb 2020 at 23:13, Ben Cotton  wrote:
>
> 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.
>
> 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?

Similar to other procedures for non-responsive people I guess: after a
timeout, set a flag and post a comment there, and if nobody steps up
to take it, close it.

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

Sounds reasonable.

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

[EPEL-devel] Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

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

Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

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

Want to claim vault

[Dave Dykstra]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Cross-arch dependencies for plugins (NSS and others)

[Nicolas Mailhot via devel]

Le lundi 24 février 2020 à 22:51 +0100, Florian Weimer a écrit :
> 
> Recommends: isn't a hard dependency?

It’s a weak but not weak weak dependency :)

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

Autoclosure of review requests?

[Ben Cotton]

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.

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.

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

Re: Cross-arch dependencies for plugins (NSS and others)

[Florian Weimer]

* James Cassell:

> On Mon, Feb 24, 2020, at 1:11 PM, Florian Weimer wrote:
>> Sometimes, users run into problems because they install nss_nis on
>> x86_64 and want to use 32-bit applications, but those do not work
>> correctly because nss_nis.i686 is not installed.  I think we have an
>> opportunity here to improve the system administrator experience with
>> reasonable effort.
>> 
>> If we add this to nss_nis.spec:
>> 
>> %ifarch x86_64
>> Recommends: (nss_nis(x86-32) if glibc(x86-32))
>> %endif
>
> What about also adding
>
> %ifarch i686
> Supplements: (glibc(x86-32) if (nss_nis(x86-64))
> %endif
>
> (Untested)

Does this have the same non-ideal behavior regarding late installation
of glibc.i686?

> I'd greatly prefer to avoid hard deps where they aren't absolutely
> necessary.

Recommends: isn't a hard dependency?

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

Re: Cross-arch dependencies for plugins (NSS and others)

[James Cassell]

On Mon, Feb 24, 2020, at 1:11 PM, Florian Weimer wrote:
> Sometimes, users run into problems because they install nss_nis on
> x86_64 and want to use 32-bit applications, but those do not work
> correctly because nss_nis.i686 is not installed.  I think we have an
> opportunity here to improve the system administrator experience with
> reasonable effort.
> 
> If we add this to nss_nis.spec:
> 
> %ifarch x86_64
> Recommends: (nss_nis(x86-32) if glibc(x86-32))
> %endif

What about also adding

%ifarch i686
Supplements: (glibc(x86-32) if (nss_nis(x86-64))
%endif

(Untested)

I'd greatly prefer to avoid hard deps where they aren't absolutely necessary.

V/r,
James Cassell


> 
> then when the user installs nss_nis after glibc.i686, they will get both
> packages, as expected.
> 
> Unfortunately, it does not work if nss_nis.x86_64 is installed first.
> Is there a way to fix this aspect?
> 
> What would be a good way to abstract this into some RPM macro, so that
> we can apply this to other plugins 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

Re: Fedora 32 Wifi Loss

[Samuel Sieb]

On 2/24/20 1:02 PM, Mark Bidewell wrote:
Sorry if this is the wrong list for this, but since this refers to 
Fedora 32 I figured I would start here. I updated to the Fedora 32 
Branched release and my Wifi no longer enables on the 5.6 RC kernel.  
lspci still shows the wireless card by the is no wifi section in Gnome 
settings and ip addr show does not show the card.  Leftover kernels from 
F31 still work fine with Wifi.  My card is an Intel Wireless AC 9260


Any suggestions on how to debug?


Check the journal for messages about it.  Run "sudo journalctl -b" to 
see the logs from the current boot.

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

[Miroslav Suchý]

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


And BTW I like the changelog proposal.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Wifi Loss

[Mark Bidewell]

Sorry if this is the wrong list for this, but since this refers to Fedora
32 I figured I would start here. I updated to the Fedora 32 Branched
release and my Wifi no longer enables on the 5.6 RC kernel.  lspci still
shows the wireless card by the is no wifi section in Gnome settings and ip
addr show does not show the card.  Leftover kernels from F31 still work
fine with Wifi.  My card is an Intel Wireless AC 9260

Any suggestions on how to debug?

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 nimbus-jose-jwt

[Sandro Bonazzola]

Hi,
nimbus-jose-jwt was previously used by oVirt project and this dependency is
no longer needed there in supported ovirt versions.
The package has open CVEs (*Bug 1764792*
 - CVE-2019-17195
 nimbus-jose-jwt:
Uncaught exceptions while parsing a JWT [fedora-all])
Given the limited capacity and the reduced interest for this package, I
orphaned it.


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Jerry James]

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.

> 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 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.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] please review: Issue 50909 - nsDS5ReplicaId cant be set to the old value it had before

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50910

--

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

[Bug 1806724] New: perl-HTTP-Message-6.22 is available

[bugzilla]

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

Bug ID: 1806724
   Summary: perl-HTTP-Message-6.22 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-HTTP-Message
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.22
Current version/release in rawhide: 6.18-7.fc32
URL: http://search.cpan.org/dist/HTTP-Message/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

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

Re: Cross-arch dependencies for plugins (NSS and others)

[Nicolas Chauvet]

Le lun. 24 févr. 2020 à 19:12, Florian Weimer  a écrit :
>
> Sometimes, users run into problems because they install nss_nis on
> x86_64 and want to use 32-bit applications, but those do not work
> correctly because nss_nis.i686 is not installed.  I think we have an
> opportunity here to improve the system administrator experience with
> reasonable effort.
>
> If we add this to nss_nis.spec:
>
> %ifarch x86_64
> Recommends: (nss_nis(x86-32) if glibc(x86-32))
> %endif

I'm using a similar boolean dependency for a 3rd part provided binary
driver and the libGL.i686 counterpart.
Althought I've experienced better success with Requires instead of
Recommends because the former is more deterministic.

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 24. 02. 20 19:30, 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)


Yet even if we count builds, the package needs to be in git first.

--
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-responsive maintainer: pocock

[Dakota Williams via devel]

Does anyone know how to contact maintainer pocock?

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

Thanks,
Dakota
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Cross-arch dependencies for plugins (NSS and others)

[Florian Weimer]

* Josh Stone:

> On 2/24/20 10:11 AM, Florian Weimer wrote:
>> If we add this to nss_nis.spec:
>> 
>> %ifarch x86_64
>> Recommends: (nss_nis(x86-32) if glibc(x86-32))
>> %endif
>> 
>> then when the user installs nss_nis after glibc.i686, they will get both
>> packages, as expected.
>> 
>> Unfortunately, it does not work if nss_nis.x86_64 is installed first.
>> Is there a way to fix this aspect?
>
> Would you be willing to add a similar rule in glibc.spec?
>
> %ifarch %{ix86}
> Recommends: (nss_nis(x86-32) if nss_nis(x86-64))
> %endif

Hmm.  We'd have to do this for all NSS modules and PAM modules, which is
an open-ended list.  I'm not sure the limitation (regarding late
installation of glibc.i686) is worth it.

DNF seems to do the right thing if glibc.i686 and nss_nis are installed
in the same transaction, so presumably kickstart files would work as
expected.

(nss_nis is no longer built from the glibc sources, sorry if this caused
confusion.)

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

Re: Cross-arch dependencies for plugins (NSS and others)

[Josh Stone]

On 2/24/20 10:11 AM, Florian Weimer wrote:
> If we add this to nss_nis.spec:
> 
> %ifarch x86_64
> Recommends: (nss_nis(x86-32) if glibc(x86-32))
> %endif
> 
> then when the user installs nss_nis after glibc.i686, they will get both
> packages, as expected.
> 
> Unfortunately, it does not work if nss_nis.x86_64 is installed first.
> Is there a way to fix this aspect?

Would you be willing to add a similar rule in glibc.spec?

%ifarch %{ix86}
Recommends: (nss_nis(x86-32) if nss_nis(x86-64))
%endif
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Temporary package rollback by using Version: +really.

[Kevin Fenzi]

On Mon, Feb 24, 2020 at 03:26:57PM +0100, Sandro Mani wrote:
> 
> On 24.02.20 14:30, Sandro Mani wrote:
> > 
> > On 24.02.20 14:21, Neal Gompa wrote:
> > > But removing the dependency just restores it to the level of accuracy
> > > it had before the introduction of that dependency.
> > That's a good point, I've asked upstream if that is actually the case or
> > whether the dependency replaced previous logic which would also need to
> > be restored to get the same level of accuracy.
> 
> Upstream reply wasn't exactly helpful. Dunno, I suppose I'll go for the
> patch after all so that I'm not stuck with old version.

Well, I am sure you will not want to, but Epoch is for just this sort of
thing isn't it? Sure, you will have to use it forever after, but... such
is life. 

kevin


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

Re: Include non-RPM content in buildroot

[Kevin Fenzi]

On Mon, Feb 24, 2020 at 02:46:02PM +0100, Vitaly Zaitsev via devel wrote:
> On 24.02.2020 13:41, Miroslav Suchý wrote:
> > Yes. But it is only rpm-build what cannot access network. Mock itself can 
> > access network.
> 
> Mock is using Internet connection only for downloading metadata and
> packages from repositories. Then it use systemd-nspawn to create a
> protected isolated container and run rpmbuild there with no Internet access.

To further clarify here... yes, mock can access the internet.

However, Fedora builders also have a restrictive firewall set, allowing
them to only access a few specific sites. They can reach koji/kojipkgs,
they can reach the master mirrors, they can reach pagure.io (for things
like kickstarts and comps), they can reach src.fedoraproject.org (for
things like spec files/sources files), they can reach the fedora
regestry. Thats about it. Everything else is just denied. 

kevin


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

Re: OCaml 4.10.0 build in Fedora 32 and 33

[Kevin Fenzi]

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. 

kevin


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

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

[Nicolas Mailhot via devel]

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)

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

Cross-arch dependencies for plugins (NSS and others)

[Florian Weimer]

Sometimes, users run into problems because they install nss_nis on
x86_64 and want to use 32-bit applications, but those do not work
correctly because nss_nis.i686 is not installed.  I think we have an
opportunity here to improve the system administrator experience with
reasonable effort.

If we add this to nss_nis.spec:

%ifarch x86_64
Recommends: (nss_nis(x86-32) if glibc(x86-32))
%endif

then when the user installs nss_nis after glibc.i686, they will get both
packages, as expected.

Unfortunately, it does not work if nss_nis.x86_64 is installed first.
Is there a way to fix this aspect?

What would be a good way to abstract this into some RPM macro, so that
we can apply this to other plugins 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

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

[Igor Gnatenko]

On Mon, Feb 24, 2020, 18:38 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.
>
> 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.
>
> i.e. if you do two "fedpkg build" in a row without a commit, I think that
> the
> second one should still fail with "already been build" kind of message.
>

What if build environment has changed?


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


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.


i.e. if you do two "fedpkg build" in a row without a commit, I think that the 
second one should still fail with "already been build" kind of message.


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

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 79/171 (x86_64), 1/2 (arm)

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

ID: 526398  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/526398
ID: 526453  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/526453

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

ID: 526395  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/526395
ID: 526396  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526396
ID: 526397  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/526397
ID: 526400  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526400
ID: 526401  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/526401
ID: 526402  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/526402
ID: 526403  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/526403
ID: 526410  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/526410
ID: 526418  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/526418
ID: 526419  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/526419
ID: 526426  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/526426
ID: 526431  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/526431
ID: 526437  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526437
ID: 526438  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/526438
ID: 526440  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526440
ID: 526450  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/526450
ID: 526458  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526458
ID: 526467  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/526467
ID: 526474  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/526474
ID: 526483  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/526483
ID: 526488  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/526488
ID: 526489  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/526489
ID: 526490  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/526490
ID: 526492  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/526492
ID: 526493  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/526493
ID: 526495  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/526495
ID: 526496  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/526496
ID: 526497  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/526497
ID: 526498  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/526498
ID: 526499  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/526499
ID: 526500  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/526500
ID: 526501  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/526501
ID: 526502  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/526502
ID: 526503  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/526503
ID: 526504  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/526504
ID: 526507  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/526507
ID: 526508  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/526508
ID: 526509  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/526509
ID: 526510  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/526510
ID: 526511  

Summary/Minutes from today's FESCo Meeting (2020-02-24)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2020-02-24)
=


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

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

* #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes proposal to
  ban default modular streams)  (contyk, 15:01:53)
  * LINK: https://pagure.io/fesco/issue/2341#comment-627466   (nirik,
15:03:42)
  * AGREED: For Fedora 32 and onward, all default modular streams are
banned. Existing defaults are removed. (+8, 0, -0)  (contyk,
15:25:24)

* #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE
  (32bit), Add Workstation(64bit)  (contyk, 15:26:14)
  * No change in last week's FESCo decision, the ticket can be closed.
(contyk, 15:27:52)

* #2328 F32 Self-Contained Change: Additional buildroot to test x86-64
  micro-architecture update  (contyk, 15:28:11)
  * AGREED: Provided releng agrees, the change proposal is approved.
(+7, 0, -0)  (contyk, 15:52:12)

* #2342 F32 incomplete Changes  (contyk, 15:52:40)
  * LINK: https://pagure.io/fedora-infrastructure/issue/7677   (nirik,
16:01:43)
  * DNF Better Counting: Non-blocking, client-side done, let's give the
server-side part more time.  (contyk, 16:02:59)
  * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1469799
(mhroncok, 16:05:02)
  * Free Pascal Compiler 3.20: Appears to be done, bug status should be
updated.  (contyk, 16:05:03)
  * LLVM 10: Appears to be done, bug status should be updated.  (contyk,
16:06:02)
  * LINK:
https://src.fedoraproject.org/rpms/clang/blob/master/f/clang.spec
has -DBUILD_SHARED_LIBS=OFF, not yet sure if built or just committed
(mhroncok, 16:07:45)
  * Restart services at end of rpm transaction: Status unclear; if no
action is taken before the deadline, let's move this to F33.
(contyk, 16:16:40)
  * Stop shipping individual component libraries in clang-libs package:
Appears to be done, bug status should be updated.  (contyk,
16:18:28)
  * Use update-alternatives for /usr/bin/cc and /usr/bin/c++: Moved to
F33, any changes should be reverted.  (contyk, 16:20:28)
  * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b0652e4f4b
(2 hours ago ;)  (nirik, 16:22:08)
  * Haskell package to Stackage LTS 14: Done.  (contyk, 16:22:12)
  * Ship BerkeleyDB backend as a module: Moved to F33.  (contyk,
16:23:03)
  * Limit scriptlet usage of core packages: An ongoing change, status
unknown. No action needed.  (contyk, 16:25:18)

* #2343 Proposal: Block (stable release) bodhi updates when they fail
  dist.rpmdeplint  (contyk, 16:25:36)
  * AGREED: Close for now; as soon as something is ready to enable, ask
us again about that specific thing (+6, 0, -0)  (contyk, 16:42:31)

* #2340 Get a process established to remove branches  (contyk, 16:42:44)
  * LINK: https://pagure.io/fedora-infrastructure/issue/8390   (nirik,
16:47:40)
  * AGREED: Branches reachable from any other branch that are not used
for building anything can be removed (+6, 0, -0)  (contyk, 16:51:52)

* #2344 Enable new fonts packaging guidelines in F31  (contyk, 16:52:19)
  * FPC approval is sufficient in this case.  (contyk, 16:54:25)
  * No explicit approval needed for backwards compatible changes Close
the ticket.  (contyk, 16:59:56)

* Next week's chair  (contyk, 17:00:08)
  * ACTION: mhroncok will chair the next meeting.  (contyk, 17:01:29)

* Open Floor  (contyk, 17:01:33)
  * beta freeze/bodhi enablement is at 14UTC on tuesday (2020-02-25). We
moved it from 00:00, so 14 extra hours...  (contyk, 17:02:42)

Meeting ended at 17:03:13 UTC.


Action Items

* mhroncok will chair the next meeting.


Action Items, by person
---
* mhroncok
  * mhroncok will chair the next meeting.


People Present (lines said)
---
* contyk (145)
* mhroncok (92)
* nirik (71)
* sgallagh (58)
* decathorpe (39)
* dcantrell (28)
* zodbot (24)
* bookwar (15)
* nim-nim (8)
* ignatenkobrain (5)
* tflink (4)
* smooge (3)
* zbyszek (0)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Pierre-Yves Chibon]

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

Pros:
 - Easy to replicate locally
 - Every changelog entry can be mapped to a `version-release` (No changes to the
   packaging guidelines)
 - Allows triggering two builds from the same commit without any manual change
   (simplifies mass-rebuilds)
 - Easy to link a certain build with a specific commit
 - Easy to “guess” the next release value before triggering the build

Cons:
  - Old packages which are no longer receiving upstream releases may need
special care (for example if they are at the release -48 but only had 45
commits leading to this)
  -  Relies on information from the build system for the build number (but can
 be closely simulated locally since the  info is only used for
 rebuilds)
  -  Upgrade path may be problematic if Fn is upgraded to version X with one
 commit while Fn-1 is upgrade to version X with 2 commits (or more)


B) The release field is automatically generated taking existing builds in all
current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This means for
builds of the same epoch:version, find a new release that (if at all possible)
ensures upgradability from older Fedora versions to newer ones, adhering to the
structure of a release tag documented in the Versioning Guidelines[1]. Going
from the (RPM-wise) "latest build" that the new one should surpass, this can
mean bumping in the front 

Review request: starlark

[Alejandro Saez Morollon]

Hi everyone

Starlark is a Python dialect for configuration purposes written in Go
that can be used as a library.

In fact, Delve has it as dependency, which by the way I want to
upgrade to the latest version.

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

Thanks!

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

[Björn Persson]

Neal Gompa wrote:
>We may want to replace it with a simple Web Key Directory server:

For anyone who is interested, this possibility is being explored here:
https://github.com/fedora-infra/securitas/issues/118

Björn Persson


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

REMINDER: Fedora 32 Code complete (100% complete) deadline tomorrow

[Ben Cotton]

According to the Fedora 32 schedule[]1, the deadline for Changes to be
in a code complete (100% complete) state is *tomorrow* 25 February. At
this time, all Changes should be fully implemented and tracker bugs
set to the ON_QA state.

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html

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

Fedora-IoT-32-20200224.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 2/8 (x86_64)

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

ID: 526568  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/526568
ID: 526569  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526569

Skipped non-gating openQA tests: 6 of 8
-- 
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

REMINDER: Fedora 32 Code complete (100% complete) deadline tomorrow

[Ben Cotton]

According to the Fedora 32 schedule[]1, the deadline for Changes to be
in a code complete (100% complete) state is *tomorrow* 25 February. At
this time, all Changes should be fully implemented and tracker bugs
set to the ON_QA state.

[1] https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html

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

Fedora 32 compose report: 20200224.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200223.n.0
NEW: Fedora-32-20200224.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:4
Upgraded packages:   32
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:1.76 MiB
Size of upgraded packages:   685.24 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -7.96 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-32-20200224.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: php-guzzle-Guzzle-3.9.3-21.fc32
Summary: PHP HTTP client library and framework for building RESTful web service 
clients
RPMs:php-guzzle-Guzzle
Size:187.33 KiB

Package: php-lessphp-0.5.0-10.fc31
Summary: A compiler for LESS written in PHP
RPMs:php-lessphp
Size:55.49 KiB

Package: php-opencloud-1.16.0-9.fc31
Summary: PHP SDK for OpenStack/Rackspace APIs
RPMs:php-opencloud php-opencloud-doc
Size:226.23 KiB

Package: php-phpoffice-phpexcel-1.8.1-9.fc31
Summary: A pure PHP library for reading and writing spreadsheet files
RPMs:php-phpoffice-phpexcel
Size:1.30 MiB


= UPGRADED PACKAGES =
Package:  LabPlot-2.7.0-1.fc32
Old package:  LabPlot-2.5.0-7.fc32
Summary:  Data Analysis and Visualization
RPMs: LabPlot
Size: 31.18 MiB
Size change:  1.52 MiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.5.0-8
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Sun Feb 23 2020 Christian Dersch  - 2.5.0-9
  - Rebuilt for cantor soname-bump

  * Sun Feb 23 2020 Christian Dersch  - 2.7.0-1
  - new version


Package:  Random123-1.13.2-1.fc32
Old package:  Random123-1.09-10.fc32
Summary:  Library of random number generators
RPMs: Random123-devel Random123-doc
Size: 325.65 KiB
Size change:  -453.05 KiB
Changelog:
  * Sun Feb 23 2020 Ankur Sinha  - 1.13.2-1
  - Update to latest release
  - Run new tests
  - Update arches supported
  - Drop unneeded patch


Package:  armadillo-9.850.1-1.fc32
Old package:  armadillo-9.800.3-2.fc32
Summary:  Fast C++ matrix library with syntax similar to MATLAB and Octave
RPMs: armadillo armadillo-devel
Size: 10.89 MiB
Size change:  2.38 MiB
Changelog:
  * Sun Feb 23 2020 Jos?? Matos  - 9.850.1-1
  - update to 9.850.1
  - update list of document files


Package:  asv-0.4.1-7.fc32
Old package:  asv-0.4.1-5.fc32
Summary:  Airspeed Velocity: A simple Python history benchmarking tool
RPMs: asv asv-doc
Size: 5.25 MiB
Size change:  112.30 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
0.4.1-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Sun Feb 23 2020 Elliott Sales de Andrade  - 
0.4.1-7
  - Re-bundle flot
  - Small cleanups to spec


Package:  clamav-unofficial-sigs-7.0.1-5.fc32
Old package:  clamav-unofficial-sigs-7.0.1-4.fc32
Summary:  Scripts to download unofficial clamav signatures
RPMs: clamav-unofficial-sigs
Size: 55.63 KiB
Size change:  159 B
Changelog:
  * Sun Feb 23 2020 J??n ONDREJ (SAL)  - 7.0.1-5
  - Remove delay from cron script, doesn't work as expected.


Package:  claws-mail-3.17.5-1.fc32
Old package:  claws-mail-3.17.4-7.fc32
Summary:  Email client and news reader based on GTK+
RPMs: claws-mail claws-mail-devel claws-mail-plugins 
claws-mail-plugins-acpi-notifier claws-mail-plugins-address-keeper 
claws-mail-plugins-archive claws-mail-plugins-att-remover 
claws-mail-plugins-attachwarner claws-mail-plugins-bogofilter 
claws-mail-plugins-bsfilter claws-mail-plugins-clamd claws-mail-plugins-dillo 
claws-mail-plugins-fetchinfo claws-mail-plugins-gdata 
claws-mail-plugins-libravatar claws-mail-plugins-litehtml-viewer 
claws-mail-plugins-mailmbox claws-mail-plugins-managesieve 
claws-mail-plugins-newmail claws-mail-plugins-notification 
claws-mail-plugins-pdf-viewer claws-mail-plugins-perl claws-mail-plugins-pgp 
claws-mail-plugins-rssyl claws-mail-plugins-smime 
claws-mail-plugins-spam-report claws-mail-plugins-spamassassin 
claws-mail-plugins-tnef claws-mail-plugins-vcalendar
Size: 28.36 MiB
Size change:  1.38 KiB
Changelog:
  * Sun Feb 23 2020 Michael Schwendt  - 3.17.5-0.1
  - Update to 3.17.5.


Package:  evince-3.35.92-1.fc32
Old package:  evince-3.35.1-4.fc32
Summary:  Document viewer
RPMs: evince evince-devel evince-djvu evince-dvi evince-libs 
evince-nautilus
Size: 11.40 MiB
Size change:  -38.00 KiB
Changelog:
  * Sun Feb 23 2020 Kalev Lember  - 3.35.92-1
  - Update to 3.35.92


Package:  ghostwriter-1.8.1-1.fc32
Old package:  ghostwriter-1.8.0-3.fc32
Summary:  Cross-platform, aesthetic, distraction-free Markdown editor
RPMs: ghostwriter
Size: 1.31 MiB
Size change:  34.29 KiB
Changelog:
  * Sun Feb 23

Non-responsive maintainer: normunds

[Scott Talbert]

Does anyone know how to contact maintainer normunds?

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

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

[Bug 1806619] New: Non-responsive maintainer check for normunds

[bugzilla]

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

Bug ID: 1806619
   Summary: Non-responsive maintainer check for normunds
   Product: Fedora
   Version: rawhide
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Data-Validate-IP
  Severity: medium
  Priority: medium
  Assignee: fedora...@rule.lv
  Reporter: s...@techie.net
QA Contact: extras...@fedoraproject.org
CC: fedora...@rule.lv, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



This bug is part of the non-responsive maintainer procedure for normunds,
following
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/.

Please respond if you are still active in Fedora and want to maintain
perl-Data-Validate-IP.

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

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

[Bug 1797039] Please build perl-Data-Validate-IP for EPEL8

[bugzilla]

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



--- Comment #4 from Jitka Plesnikova  ---
The requests were invalidated because I am not a maintainer. I can only make
changes to current branches. 

You can start non-responsive maintainer process because normunds last login in
FAS was 2013-10-02

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

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

Re: Help needed to fix FTBFS (gcc-10 caused failures)

[Robin Lee]

On Sun, Feb 23, 2020 at 11:50 PM Mukundan Ragavan  wrote:
>
> Hi all,
>
> I have two packages that fail to build from source. As far as I can tell
> from the build logs, they are gcc-10 failures. The typical "extern"
> solution does not work me (or, I am not adding 'extern' at the correct
> places).
>
> Can someone give me pointers for fixing this FTBFS? Here are the links
> containing the build logs -
>
> xfce4-panel:
> https://bugzilla.redhat.com/show_bug.cgi?id=1800267
>
> xfce4-sensors-plugin:
> https://bugzilla.redhat.com/show_bug.cgi?id=1800268
I have figured out patches for both issues. Let's talk in bugzilla and upstream.

-robin
>
> Direct koji links no longer show the build logs and hence
>
> Thanks!
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Help needed to fix FTBFS (gcc-10 caused failures)

[Dridi Boukelmoune]

> Having -Wall and -Wextra with -Werror is the perfect footgun, since
> you’re at the mercy of whatever compiler is being used. Get yourself a
> manageable set of warnings and make those fatal instead.

That's what we do at $DAYJOB and we are happy whenever a new gcc or
clang release finds new issues.

But as I suggested this should be a development/CI thing, not enabled
by default for redistribution.

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

[EPEL-devel] Re: Missing httpd-itk for CentOS 8

[Troy Dawson]

I can see you've already found at least part of the answer, but I'm
going to answer anyway so other can see.

Packages in the EPEL-8 repository are volunteered by Fedora packagers
via requests by interested users. If a package you are looking for is
not there, please look at https://bugzilla.redhat.com and see if a
request has been opened for your package to be built in EPEL-8. If it
hasn't please open a new ticket. Some packages may not be able to
built in EPEL-8 due to missing deps which need to be added.

That being said, a bugzilla already has been open for this package
https://bugzilla.redhat.com/show_bug.cgi?id=1741758
Looking at the package in Fedora, it hasn't been touched in over two
years, other than mass rebuilds.

On Sat, Feb 22, 2020 at 11:18 AM Marko Bevc  wrote:
>
>  Hi.
>
> qq, is there a reason httpd-itk package is missing in EPEL-8?
>
> Thanks,
> Marko
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Fedora-Rawhide-20200224.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 74/171 (x86_64), 1/2 (arm)

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

ID: 526214  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/526214
ID: 526215  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/526215
ID: 526216  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/526216
ID: 526219  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/526219
ID: 526220  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/526220
ID: 526221  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/526221
ID: 526222  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/526222
ID: 526229  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/526229
ID: 526237  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/526237
ID: 526238  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/526238
ID: 526245  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/526245
ID: 526250  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/526250
ID: 526256  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/526256
ID: 526257  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/526257
ID: 526259  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/526259
ID: 526277  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/526277
ID: 526293  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/526293
ID: 526307  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/526307
ID: 526308  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/526308
ID: 526309  Test: x86_64 universal install_sata **GATING**
URL: https://openqa.fedoraproject.org/tests/526309
ID: 526311  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/526311
ID: 526312  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/526312
ID: 526314  Test: x86_64 universal install_scsi_updates_img **GATING**
URL: https://openqa.fedoraproject.org/tests/526314
ID: 526315  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/526315
ID: 526316  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/526316
ID: 526317  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/526317
ID: 526318  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/526318
ID: 526319  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/526319
ID: 526320  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/526320
ID: 526321  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/526321
ID: 526322  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/526322
ID: 526323  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/526323
ID: 526326  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/526326
ID: 526327  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/526327
ID: 526328  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/526328
ID: 526329  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/526329
ID: 526330  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/526330
ID: 526331  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/526331
ID: 526332  Test: x86_64 universal install_software_raid@uefi
URL: 

Re: New Release Freeze Times

[Mohan Boddu]

We didn't pick the time at random, 14:00 UTC is the time when Fedora
release gets out. We thought if we are changing the time, we should
align it with the only other time constrained task, that is, Fedora
release.

00:00 UTC is definitely confusing for some people as they complained
about it, but 14:00 UTC should not make it anymore confusing.

Also, as a side note, people will get 14 more hours to get their stuff
into the release before the freeze starts, that should help the
maintainers as well.

On Sat, Feb 22, 2020 at 10:51 AM Neal Gompa  wrote:
>
> On Sat, Feb 22, 2020 at 7:58 AM Kevin Kofler  wrote:
> >
> > Neal Gompa wrote:
> > > 14:00 UTC is 9:00 EST, so it basically means to everyone: do
> > > everything the day before.
> >
> > "Do everything the day before" is exactly what was confusing about the 00:00
> > UTC deadline, so I do not see how the change to 14:00 UTC fixes the issue.
> > It is customary to give inclusive deadlines, i.e., a deadline of day X means
> > I have up to AND INCLUDING day X to do the work.
> >
> > I do not see why the deadlines were not changed to 23:59 UTC deadlines
> > instead, which would also not have meant any actual change in process
> > (unlike this 14:00 UTC change), just a change of how the deadlines are
> > announced (subtract 1 day from all the posted deadlines).
> >
>
> The folks that actually are doing this work are also based on US
> Eastern Time, specifically out in the Boston, MA area. It is much
> easier for them to pull this off by saying "welp, it's the start of
> the day for me and this is the day we push the button, so let's push
> it!". Previously they had to do it technically *after* the end of *the
> previous day* their time, which made things confusing.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Schedule for Mondays's FESCo Meeting (2020-02-24)

[Petr Šabata]

Sure.

On Mon, Feb 24, 2020 at 2:01 PM Nicolas Mailhot
 wrote:
>
> Le 2020-02-24 13:37, Petr Šabata a écrit :
> > Following is the list of topics that will be discussed in the
> > FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> > irc.freenode.net.
>
> Hi,
>
> Can you please add
> https://pagure.io/fesco/issue/2344
>
> to the list since FESCO arbitration was requested within the project?
> 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

Fedora rawhide compose report: 20200224.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200223.n.0
NEW: Fedora-Rawhide-20200224.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  3
Dropped packages:4
Upgraded packages:   63
Downgraded packages: 0

Size of added packages:  30.58 MiB
Size of dropped packages:1.80 MiB
Size of upgraded packages:   893.11 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -2.74 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200224.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: aeskeyfind-1.0-7.fc33
Summary: Locate 128-bit and 256-bit AES keys in a captured memory image
RPMs:aeskeyfind
Size:92.19 KiB

Package: arbor-0.2.2-5.20200223gitf12f934f365d9e68f01bfd857982be80da2ddd10.fc33
Summary: Multi-compartment neural network simulation library
RPMs:arbor arbor-devel arbor-doc arbor-mpich arbor-mpich-devel 
arbor-openmpi arbor-openmpi-devel
Size:30.47 MiB

Package: rust-maybe-uninit-2.0.0-1.fc33
Summary: MaybeUninit for friends of backwards compatibility
RPMs:rust-maybe-uninit+default-devel rust-maybe-uninit-devel
Size:26.85 KiB


= DROPPED PACKAGES =
Package: php-guzzle-Guzzle-3.9.3-21.fc32
Summary: PHP HTTP client library and framework for building RESTful web service 
clients
RPMs:php-guzzle-Guzzle
Size:187.33 KiB

Package: php-opencloud-1.16.0-9.fc31
Summary: PHP SDK for OpenStack/Rackspace APIs
RPMs:php-opencloud php-opencloud-doc
Size:226.23 KiB

Package: php-phpoffice-phpexcel-1.8.1-9.fc31
Summary: A pure PHP library for reading and writing spreadsheet files
RPMs:php-phpoffice-phpexcel
Size:1.30 MiB

Package: php-simplesamlphp-saml2_1-1.10.6-6.fc32
Summary: SAML2 PHP library from SimpleSAMLphp (version 1)
RPMs:php-simplesamlphp-saml2_1
Size:96.00 KiB


= UPGRADED PACKAGES =
Package:  LabPlot-2.7.0-1.fc33
Old package:  LabPlot-2.5.0-7.fc32
Summary:  Data Analysis and Visualization
RPMs: LabPlot
Size: 31.18 MiB
Size change:  1.52 MiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.5.0-8
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Sun Feb 23 2020 Christian Dersch  - 2.5.0-9
  - Rebuilt for cantor soname-bump

  * Sun Feb 23 2020 Christian Dersch  - 2.7.0-1
  - new version


Package:  R-ape-5.3-6.fc33~bootstrap
Old package:  R-ape-5.3-4.fc32
Summary:  Analyses of Phylogenetics and Evolution
RPMs: R-ape
Size: 11.25 MiB
Size change:  1.31 KiB
Changelog:
  * Tue Feb 18 2020 Tom Callaway  - 5.3-5
  - rebuild against R without libRlapack.so

  * Sun Feb 23 2020 Elliott Sales de Andrade  - 5.3-6
  - Add bootstrap setup to build without igraph


Package:  Random123-1.13.2-1.fc33
Old package:  Random123-1.09-10.fc32
Summary:  Library of random number generators
RPMs: Random123-devel Random123-doc
Size: 325.64 KiB
Size change:  -453.05 KiB
Changelog:
  * Sun Feb 23 2020 Ankur Sinha  - 1.13.2-1
  - Update to latest release
  - Run new tests
  - Update arches supported
  - Drop unneeded patch


Package:  armadillo-9.850.1-1.fc33
Old package:  armadillo-9.800.3-2.fc32
Summary:  Fast C++ matrix library with syntax similar to MATLAB and Octave
RPMs: armadillo armadillo-devel
Size: 10.89 MiB
Size change:  2.38 MiB
Changelog:
  * Sun Feb 23 2020 Jos?? Matos  - 9.850.1-1
  - update to 9.850.1
  - update list of document files


Package:  asv-0.4.1-7.fc33
Old package:  asv-0.4.1-5.fc32
Summary:  Airspeed Velocity: A simple Python history benchmarking tool
RPMs: asv asv-doc
Size: 5.25 MiB
Size change:  112.37 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
0.4.1-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Sun Feb 23 2020 Elliott Sales de Andrade  - 
0.4.1-7
  - Re-bundle flot
  - Small cleanups to spec


Package:  blender-1:2.82-2.fc33
Old package:  blender-1:2.82-1.fc33
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-fonts blender-rpm-macros
Size: 172.03 MiB
Size change:  60.69 KiB
Changelog:
  * Sun Feb 23 2020 Luya Tshimbalanga  - 1:2.82-2
  - Patch for upstream invalid appdata causing segmentation fault


Package:  cantor-19.12.2-3.fc33
Old package:  cantor-19.12.2-2.fc33
Summary:  KDE Frontend to Mathematical Software
RPMs: cantor cantor-devel cantor-libs python3-cantor
Size: 11.54 MiB
Size change:  2.02 KiB
Changelog:
  * Sun Feb 23 2020 Rex Dieter  - 19.12.2-3
  - track library soname


Package:  certbot-1.2.0-2.fc33
Old package:  certbot-1.2.0-1.fc32
Summary:  A free, automated certificate authority client
RPMs: certbot python3-certbot
Size: 372.20 KiB
Size change:  -55 B
Changelog:
  * Sun Feb 23 2020 Felix Schwarz  - 1.2.0-2
  - re-added

Re: Temporary package rollback by using Version: +really.

[Sandro Mani]

On 24.02.20 14:30, Sandro Mani wrote:


On 24.02.20 14:21, Neal Gompa wrote:

But removing the dependency just restores it to the level of accuracy
it had before the introduction of that dependency.
That's a good point, I've asked upstream if that is actually the case 
or whether the dependency replaced previous logic which would also 
need to be restored to get the same level of accuracy.


Upstream reply wasn't exactly helpful. Dunno, I suppose I'll go for the 
patch after all so that I'm not stuck with old version.


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

Re: Non-responsive maintainer check for libffi maintainer

[Jeff Law]

On Mon, 2020-02-24 at 13:02 +, devel-
requ...@lists.fedoraproject.org wrote:
> 
> Date: Mon, 24 Feb 2020 12:10:49 +0100
> From: Miro Hrončok 
> Subject: Re: Non-responsive maintainer check for libffi maintainer
> To: Anthony Green 
> Cc: Development discussions related to Fedora
>   
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 24. 02. 20 1:46, Anthony Green wrote:
> >I would be very happy if somebody could pick up the libffi packaging
> > responsibility from me.
> 
> Suggestion: Try announcing on devel list that you are seeking co-maintainers 
> (from a separate thread). If that doesn't help, orphan the package and see 
> who 
> cares enough to take it.
> 
> I've also CC'ed the RHEL Bugzilla default assignee, DJ Delorie.
> 
> There are plenty of components that need libffi including various Python 
> versions and Ruby.
At this point it probably makes sense to hand libffi off to DJ (who
took it over in RHEL fairly recently).  I can give DJ a heads-up.

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: Help needed to fix FTBFS (gcc-10 caused failures)

[Ernestas Kulik]

On Sun, 2020-02-23 at 20:04 +, Dridi Boukelmoune wrote:
> On Sun, Feb 23, 2020 at 3:49 PM Mukundan Ragavan <
> nonamed...@gmail.com> wrote:
> > Hi all,
> > 
> > I have two packages that fail to build from source. As far as I can
> > tell
> > from the build logs, they are gcc-10 failures. The typical "extern"
> > solution does not work me (or, I am not adding 'extern' at the
> > correct
> > places).
> > 
> > Can someone give me pointers for fixing this FTBFS? Here are the
> > links
> > containing the build logs -
> > 
> > xfce4-panel:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1800267
> 
> I looked briefly at xfce4-panel and I mostly saw warnings for
> deprecated declarations on Gtk2 symbols, something I'd be willing to
> disregard until that component is migrated to Gtk+3.
> 
> I performed a mock build with -Wall and -Werror and broke it down
> like this:
> 
> grep -F '[-Werror=' results_xfce4-panel/4.14.3/2.fc33/build.log |
> awk '{print $NF}' |
> sort |
> uniq -c |
> sort -rn
> 480 [-Werror=unused-parameter]
>  44 [-Werror=deprecated-declarations]
>  24 [-Werror=missing-field-initializers]
>   6 [-Werror=cast-function-type]
>   2 [-Werror=unused-but-set-variable]
>   2 [-Werror=enum-conversion]
> 
> To get all the warnings I added -k to %make_build.
> 
> The first two can be disabled safely at %configure time, but the rest
> probably need to be fixed (I would personally fix everything).
> 
> It would be nice if the xfce4-panel developers had -Wall and -Wextra
> turned into errors in their continuous integration or development
> process. But with so many warnings, probably trivial to silence
> properly, I don't have time to help produce patches.
> 
> > xfce4-sensors-plugin:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1800268
> 
> I didn't try to produce a comprehensive build.log locally for this
> one, but the fgets warning visible in bugzilla is super legit and
> should be fixed, but the manual doesn't say precisely how errors are
> handled and if the null character is always added then ignoring the
> return value is harmless.

Having -Wall and -Wextra with -Werror is the perfect footgun, since
you’re at the mercy of whatever compiler is being used. Get yourself a
manageable set of warnings and make those fatal instead.

-- 
Ernestas Kulik
Associate Software Engineer - Base Operating Systems (Core
Services/ABRT)
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-responsive maintainer check for libffi maintainer

[Christopher Engelhard]

On 2/24/2020 1:46 AM, Anthony Green wrote:
>I would be very happy if somebody could pick up the libffi packaging
> responsibility from me.

I'd be happy to adopt libffi, but given that I am a VERY new packager 
and this is a pretty core package, I think it would be best if someone 
with a bit more experience would offer to co-maintain.

Alternatively, you can just add me (lcts) as a co-maintainer.

Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Temporary package rollback by using Version: +really.

[Vitaly Zaitsev via devel]

On 24.02.2020 14:30, Sandro Mani wrote:
> That's a good point, I've asked upstream if that is actually the case or
> whether the dependency replaced previous logic which would also need to
> be restored to get the same level of accuracy.

You can just revert some upstream commits by downstream patches.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Include non-RPM content in buildroot

[Vitaly Zaitsev via devel]

On 24.02.2020 13:41, Miroslav Suchý wrote:
> Yes. But it is only rpm-build what cannot access network. Mock itself can 
> access network.

Mock is using Internet connection only for downloading metadata and
packages from repositories. Then it use systemd-nspawn to create a
protected isolated container and run rpmbuild there with no Internet access.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Temporary package rollback by using Version: +really.

[Sandro Mani]

On 24.02.20 14:21, Neal Gompa wrote:

But removing the dependency just restores it to the level of accuracy
it had before the introduction of that dependency.
That's a good point, I've asked upstream if that is actually the case or 
whether the dependency replaced previous logic which would also need to 
be restored to get the same level of accuracy.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Temporary package rollback by using Version: +really.

[Neal Gompa]

On Mon, Feb 24, 2020 at 8:21 AM Sandro Mani  wrote:
>
>
> On 24.02.20 14:14, Neal Gompa wrote:
> > You can do that trick, it'll even kind of work. But we don't typically
> > do this. That said, why not just patch it to remove the non-free
> > dependency, even if it weakens the functionality a bit?
> I suppose licensecheck is mostly used for package reviews, so it might
> be a bit delicate to have it misreport licenses.

But removing the dependency just restores it to the level of accuracy
it had before the introduction of that dependency.



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

Fedora-IoT-33-20200224.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 2/8 (x86_64)

Old failures (same test failed in Fedora-IoT-33-20200221.0):

ID: 526387  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/526387
ID: 526388  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/526388

Skipped non-gating openQA tests: 6 of 8
-- 
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: Temporary package rollback by using Version: +really.

[Sandro Mani]

On 24.02.20 14:14, Neal Gompa wrote:

You can do that trick, it'll even kind of work. But we don't typically
do this. That said, why not just patch it to remove the non-free
dependency, even if it weakens the functionality a bit?
I suppose licensecheck is mostly used for package reviews, so it might 
be a bit delicate to have it misreport licenses.

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

Open NeuroFedora Meeting: 1600 UTC on Tuesday, 25th February

[Aniket Pradhan]

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=20200225T16=%3A=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=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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Temporary package rollback by using Version: +really.

[Neal Gompa]

On Mon, Feb 24, 2020 at 8:11 AM Sandro Mani  wrote:
>
> Hi
>
> Get ship a working licensecheck again in rawhide (stuck at v3.0.39 due to 
> later versions requiring a non-free library), I need to temporarily downgrade 
> perl-Regexp-Pattern-License, which was since updated to a version which isn't 
> compatible with licensecheck-3.0.39 anymore. This is a temporary thing, as 
> upstream will look at removing the non-free dependency in future versions [1].
>
> As the upstream maintainer mentioned in [1], in debian they do temporary 
> rollbacks by specifying
>
> Version: +really.
>
> in my case of perl-Regexp-Pattern-License, that would mean
>
> %global realversion 3.1.99
> Version:3.2.0+really.%{realversion}
> Release:1%{?dist}
>
> i.e. perl-Regexp-Pattern-License-3.2.0+really.3.1.99-1 [2]. Is this approach 
> permissible? (Obvious alternative would be an Epoch bump, which I'd rather 
> avoid, or patching licensecheck to remove the non-free dependency, which 
> however results in some deficiencies, see [1]).
>

You can do that trick, it'll even kind of work. But we don't typically
do this. That said, why not just patch it to remove the non-free
dependency, even if it weakens the functionality a bit?



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

Re: Include non-RPM content in buildroot

[Jakub Cajka]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, February 21, 2020 4:46:52 PM
> Subject: Re: Include non-RPM content in buildroot
> 
> On Fri, Feb 21, 2020 at 3:58 PM Martin Sehnoutka  wrote:
> >
> > Hi,
> 
> Hi!
> 
> I think several of your assumptions are not necessarily correct, which
> might lead to wrong conclusions.
> My responses are inline below.

I second that ;).

> 
> > before I write the proposal itself I just want to stress the fact that
> > it isn’t my intention to change the current packaging workflow and
> > definitely not the user experience. Also if you have C or Python
> > packages it would not affect your work at all (I’m not familiar with all
> > interpreted languages in Fedora, but I guess it is similar to Python and
> > therefore it is not affected by the problems I am going to describe).
> 
> (snip)
> 
> > First of all, let me describe the problem I see in our Fedora ecosystem
> > with relation to Go and Rust language ecosystems. More specifically in
> > the relation between RPM buildroot and packages in these ecosystems.
> > Both of these languages follow the idea that packages should be small
> > and only have a limited set of features. Developers then use a lot of
> > these packages to write the final executable that is meant for end-users
> > [1]. Also both of these languages use static linking of the final
> > binaries meaning that Fedora users don’t install RPM packages of these
> > libraries as they are already baked inside of the binary [2].
> 
> One big difference between Go and Rust is that Go only namespaces
> libraries by their import path (with some exceptions, like gopkg.in),
> whereas Rust/cargo namespaces everything by name *and* version, which
> makes some things a lot easier. Then there's also the fact that a lot
> of Go libraries don't even *have* versions, and most only reference
> dependencies by "this git repository". There's some effort to make
> this better, but Go modules are not ready yet.

With Go modules("upstream ones") you are getting that name + version/tag(and 
rules what to use). Definitively many packages will not move to the 
modules/best practices, if that happen, we should try to move them to 
modules/best practices or move depending package to different package that is 
still maintained or in worst case scenario take over the maintenance -> fork.

> 
> > The 1st problem is that if we want to build RPMs of the final
> > executables the way we do now, we need to package all these small
> > libraries into RPM even though they are just build dependencies and
> > users never install RPMs of these libraries. Many of these RPMs are
> > automatically generated from the upstream packages meaning that we don’t
> > do anything except for unpacking the upstream package (e.g. plain
> > tarball in case of crates.io)  and then we package the same into RPM.
> > This process is unfortunately not fully automated and therefore requires
> > a certain amount of human effort.
> >
> >
> > To sum up the previous paragraph, I don’t think it is necessary to
> > repackage upstream tarball into a downstream RPM.
> 
> Of course this requires a certain amount of human effort - because
> that's where the packager does their work. This includes:
> 
> - verifying that the specified license is correct and suitable for
> (re)distribution in fedora
> - verify that the package builds and doesn't do crazy things
> - fix upstream and integration issues with patches
> 
> And none of these three things is 100% automatable.

Seconding that.

> 
> > The 2nd problem is present only in the Rust ecosystem (as far as my
> > knowledge goes). Cargo, the official package manager for Rust, can
> > handle the scenario where an executable depends on a single library in
> > two different versions [3]. Dnf, on the other hand, will not install two
> > versions of the same RPM package. What we do now is, that we patch the
> > affected executables and libraries to only use the newest versions
> > everywhere. This is again an additional maintenance cost and we create
> > differences from upstream, because these patches are not necessarily
> > merged. See this as an example:
> > https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17
> > https://github.com/BurntSushi/bstr/pull/23

 (snip)

> 
> > It is fair to say, that my first motivation was the current state of
> > packaging in RHEL but I’d prefer to discuss this in Fedora first.
> >
> >
> > The proposal itself is fairly simple: Let’s stop packaging all Go and
> > Rust libraries into RPM and install them to the buildroot in the
> > upstream format instead.
> 
> As I said (and others have pointed out as well), this is not possible
> right now, primarily because automation cannot verify licensing and
> write and apply necessary patches without human intervention. And when
> you start curating your own Cargo registry, you might as well just
> package them 

Temporary package rollback by using Version: +really.

[Sandro Mani]

Hi

Get ship a working licensecheck again in rawhide (stuck at v3.0.39 due 
to later versions requiring a non-free library), I need to temporarily 
downgrade perl-Regexp-Pattern-License, which was since updated to a 
version which isn't compatible with licensecheck-3.0.39 anymore. This is 
a temporary thing, as upstream will look at removing the non-free 
dependency in future versions [1].


As the upstream maintainer mentioned in [1], in debian they do temporary 
rollbacks by specifying


Version: +really.

in my case of perl-Regexp-Pattern-License, that would mean

%global realversion 3.1.99
Version:    3.2.0+really.%{realversion}
Release:    1%{?dist}

i.e. perl-Regexp-Pattern-License-3.2.0+really.3.1.99-1 [2]. Is this 
approach permissible? (Obvious alternative would be an Epoch bump, which 
I'd rather avoid, or patching licensecheck to remove the non-free 
dependency, which however results in some deficiencies, see [1]).


Thanks
Sandro

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951186
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=41840764


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Schedule for Mondays's FESCo Meeting (2020-02-24)

[Nicolas Mailhot via devel]

Le 2020-02-24 13:37, Petr Šabata a écrit :

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


Hi,

Can you please add
https://pagure.io/fesco/issue/2344

to the list since FESCO arbitration was requested within the project?
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: Include non-RPM content in buildroot

[Miroslav Suchý]

Dne 24. 02. 20 v 11:17 Vitaly Zaitsev via devel napsal(a):
> All packages must be build with disabled network access to ensure, that
> it use packaged dependencies and not downloaded from outside.

Yes. But it is only rpm-build what cannot access network. Mock itself can 
access network.

In other words. (see comments inline of output)

## internet access here 
Mock Version: 2.0
INFO: Mock Version: 2.0
Start: dnf install
No matches found for the following disable plugin patterns: local, spacewalk
fedora  
  16 MB/s |  71 MB 00:04
updates 
  14 MB/s |  21 MB 00:01

Complete!
Finish: dnf install
Start: creating root cache
Finish: creating root cache
Finish: chroot init
INFO: Installed packages:
Start: build phase for mock-core-configs-32.1-1.fc31.src.rpm
Start: build setup for mock-core-configs-32.1-1.fc31.src.rpm
### No internet from here - Mock executing rpm-build #
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=158112
Wrote: /builddir/build/SRPMS/mock-core-configs-32.1-1.fc31.src.rpm
### Internet enabled again #
No matches found for the following disable plugin patterns: local, spacewalk
fedora  
  42 kB/s |  24 kB 00:00
updates 
  45 kB/s |  21 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
Finish: build setup for mock-core-configs-32.1-1.fc31.src.rpm
Start: Outputting list of installed packages
Finish: Outputting list of installed packages
Start: rpmbuild mock-core-configs-32.1-1.fc31.src.rpm
### No internet from here - Mock executing rpm-build #
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=158112
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.iN2SBw


Finish: rpmbuild mock-core-configs-32.1-1.fc31.src.rpm
Finish: build phase for mock-core-configs-32.1-1.fc31.src.rpm
### Internet enabled again #
INFO: Done(/tmp/tito/mock-core-configs-32.1-1.fc31.src.rpm) Config(default) 3 
minutes 28 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-31-x86_64/result
Finish: run


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2020-02-24)

[Petr Šabata]

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

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

or run:
  date -d '2020-02-24 15:00 UTC'


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

= Followups =

#topic #2341 maven and ant: sfl4j-jdk14 filtered (ticket includes
proposal to ban default modular streams)
https://pagure.io/fesco/issue/2341

#topic #2339 Proposal to change ARM Release Blocking Criteria - Drop
XFCE (32bit), Add Workstation(64bit)
https://pagure.io/fesco/issue/2339

#topic #2328 F32 Self-Contained Change: Additional buildroot to test
x86-64 micro-architecture update
https://pagure.io/fesco/issue/2328

= New business =

#topic #2342 F32 incomplete Changes
https://pagure.io/fesco/issue/2342

#topic #2343 Proposal: Block (stable release) bodhi updates when they
fail dist.rpmdeplint
https://pagure.io/fesco/issue/2343

#topic #2340 Get a process established to remove branches
https://pagure.io/fesco/issue/2340

= Open Floor =

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1806302] perl-Promises-1.04 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Promises-1.04-1.fc33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-24 11:38:21



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

[Bug 1806215] perl-experimental-0.021 is available

[bugzilla]

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



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

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

[Bug 1806215] perl-experimental-0.021 is available

[bugzilla]

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



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

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

[Bug 1806215] perl-experimental-0.021 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-experimental-0.021-1.f |perl-experimental-0.021-1.f
   |c33 |c32



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

[Bug 1806215] perl-experimental-0.021 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|ppi...@redhat.com   |
   Fixed In Version||perl-experimental-0.021-1.f
   ||c33
   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

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

Re: Non-responsive maintainer check for libffi maintainer

[Miro Hrončok]

On 24. 02. 20 1:46, Anthony Green wrote:

   I would be very happy if somebody could pick up the libffi packaging
responsibility from me.


Suggestion: Try announcing on devel list that you are seeking co-maintainers 
(from a separate thread). If that doesn't help, orphan the package and see who 
cares enough to take it.


I've also CC'ed the RHEL Bugzilla default assignee, DJ Delorie.

There are plenty of components that need libffi including various Python 
versions and Ruby.


--
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: Include non-RPM content in buildroot

[Ankur Sinha]

On Fri, Feb 21, 2020 10:11:47 -0500, Randy Barlow wrote:
> On 2/21/20 9:57 AM, Martin Sehnoutka wrote:
> > Every time there is a new release it would automatically synchronize our
> > own Fedora-specific registry, which would in turn be accessible in
> > buildroot.
> 
> 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.

-- 
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: epel8: BuildrootError: could not init mock buildroot

[Mattias Ellert]

tor 2020-01-30 klockan 17:42 -0800 skrev Kevin Fenzi:
> On Thu, Jan 30, 2020 at 07:57:22AM -0500, Stephen John Smoogen wrote:
> > On Thu, 30 Jan 2020 at 06:06, Jiri Kucera  wrote:
> > > Hello,
> > > 
> > > when doing `fedpkg scratch-build --target epel8-candidate --srpm
> > > sox-14.4.2.0-29.el8.src.rpm`, I get:
> > > 
> > 
> > So there seems to be something off in koji and the repo is not getting
> > properly regenerated after the repo gets updated. These errors seem to
> > have occurred after we updated koji to the latest release so this may
> > be a change in what koji does.
> 
> I fear it's just bad timing + the external rhel8 repo we have only keeps
> the newest packages (epel7 repos keep the old packages around too). 
> 
> koji has no way to know that an external repo updated and needs
> regeneration, so it just regenerates it when the buildroots that depend
> on it change, ie, for epel8 that means when a stable updates push goes
> out. Since updates pushes have been broken, no regen has happened
> recently. ;( For epel7, it's fine just using the older package, but in
> epel8 it's gone and you see the 404 for it. 
> 
> Updates pushes should be going again so that should help. 
> 
> After that I guess we could try and just do a regen every day no matter
> what? Or add something to the script that updates the repo to fire one
> after anything updates?
> 
> kevin

There is a work-around for this. Since the buildroot is regenerated
when a buildroot override is added, you can repair the buildroot by
adding an override for some random package you don't really need an
override for, see e.g.:

https://bodhi.fedoraproject.org/overrides/castxml-0.2.0-1.el8

It would of course be better if changes to the external repo would be
automatically detected, but until that happens you can work around it.

Mattias



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

Re: Non-responsive maintainer: devrim (gdal, proj, geos)

[Sandro Mani]

On 12.02.20 10:23, Sandro Mani wrote:

Hi Devrim

Please keep me as co-maintainer. I'm already maintaining these 
packages in the
upstream repository (https://yum.PostgreSQL.org) with more options 
there, and

I'd like to keep things in sync as much as possible.


Thanks for your reply. I read this as you being ok if I proceed with 
the updates? In this case, can you please add me to the packages (FAS: 
smani), namely to gdal, proj and geos, and postgis?


Since over a week has passed with no reply, and also other people are 
waiting for the Fedora GIS stack to get updated [1], I've gone ahead and 
filed a FESCO ticket [2]. I'd then like to do a mass 
proj/gdal/geos/postgis update to rawhide and possibly F32.


Sandro

[1] https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051716.html
[2] https://pagure.io/fesco/issue/2345
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Vitaly Zaitsev via devel]

On 24.02.2020 10:55, Miroslav Suchý wrote:
> Additionally, even when the build in Koji (or Mock in general) is offline, 
> the dependencies are installed with internet
> enabled. If you teach Mock how to call native crate/rubygem/.. before the 
> actual build start, you will have most of the
> work done.

All packages must be build with disabled network access to ensure, that
it use packaged dependencies and not downloaded from outside.

Remember about malwares/breakages in npm.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Include non-RPM content in buildroot

[Miroslav Suchý]

Dne 21. 02. 20 v 15:57 Martin Sehnoutka napsal(a):
> This process is unfortunately not fully automated and therefore requires a 
> certain amount of human effort.

This is an important sentence. Let's save it for later as [1]

> The proposal itself is fairly simple: Let’s stop packaging all Go and Rust 
> libraries into RPM and install them to the
> buildroot in the upstream format instead.
...
> 
>  * We want to know what exactly was used to build the RPM to ensure 
> integrity. This is possible with upstream tarballs
> as well as with RPMs. Just store a hash of the tarball.
>  * There should be no maintenance cost. If we would avoid modifying the 
> upstream package it would be the ideal case.
>  * It should be possible to patch the library in case of severe issues like 
> CVEs. This is a contradiction to the
> previous point, but it could be solved by unpacking the upstream package into 
> a git repository and creating a new,
> modified package in upstream format from it.
>  * It should be possible to run the build locally in exactly the same way 
> Koji does it. This is just about exposing our
> “registry” of packages to the public Internet.

Whoa. That is a lots of requirements. You can easily get lost in them. And very 
likely unable to reach your goal.

> Finally, the implementation could be something like this:
> A service like release-monitoring could monitor the upstream projects for new 
> releases (e.g. NPM has a RSS feed). Every
> time there is a new release it would automatically synchronize our own 
> Fedora-specific registry, which would in turn be
> accessible in buildroot. 

So bits in wild internet suddenly become clean when we duplicate them into our 
infrastructure?
And this is a lot of bits. The storage has a price :(
Additionally, even when the build in Koji (or Mock in general) is offline, the 
dependencies are installed with internet
enabled. If you teach Mock how to call native crate/rubygem/.. before the 
actual build start, you will have most of the
work done.


Many people tried to achieve this (non-RPM content in rpm). It may sound 
simple, but this is a **huge** task. And for
example: 1) making this technically possible and 2) allow this in Fedora are 
completely different task with different
ETA and different chances for success.

Why are you trying to come with this proposal? Do you think it will be much 
easier than automating the packaging? (see
[1] above). I, personally, think automating the packaging is a better way to 
go. Still huge, though.

What I would recommend is either:

1) Focus on the automation. Especially automation of license check. There has 
been several mentiond on this list in past
few months. We can learn a lot from OpenSuse regarding this.

2) Improve the automation of packaging.
See https://copr.fedorainfracloud.org/coprs/iucar/cran/ or our previous 
attempts to rebuild PYPI and Rubygems where we
imporoved spec generators a lot.

3) If you really want to focus on non-RPM content - you may add something like 
this to SPEC files:
  BuildRequires: native::crate(foo)

with the semantics that rpm-build:
  1) will ignore anything with native:: prefix
  2) or check if foo is present on system using crate (and not as rpm)

This has a benefit that you need to modify only rpm-build, but not rpm itself.
When you choose the first option, then you can levarage
  https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
and emit this dependency and it can be catched by Mock and installed before the 
rpm-build is called.

Focus on making this technically possible. And only then start discussion if we 
want to have this enabled in Fedora.
This will give you a grace period where this feature can mature.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1806473] New: perl-Gtk3-0.036-2.fc33 FTBFS: Can't find information for method TreeModel::sort_new_with_model at t/overrides.t line 466.

[bugzilla]

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

Bug ID: 1806473
   Summary: perl-Gtk3-0.036-2.fc33 FTBFS: Can't find information
for method TreeModel::sort_new_with_model at
t/overrides.t line 466.
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/build/7982091
Status: NEW
 Component: perl-Gtk3
  Assignee: berra...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, dd...@cpan.org,
perl-devel@lists.fedoraproject.org, ser...@serjux.com
  Target Milestone: ---
   Link ID: CPAN 131871
Classification: Fedora



perl-Gtk3-0.036-2.fc33 fails to build in Fedora 33 because a test fails:

t/floating-refs.t .. ok
Can't find information for method TreeModel::sort_new_with_model at
t/overrides.t line 466.
# Looks like your test exited with 255 just after 112.
t/overrides.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 121/233 subtests 

This is triggered by upgrading gtk3 from 3.24.13 to 3.24.14.

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

Re: OCaml 4.10.0 build in Fedora 32 and 33

[Fabio Valentini]

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

Fabio

> There are some packages which are still failing to build:
>
> * coccinelle - Uses -unsafe-string, still waiting resolution upstream.
> * nbdkit - Caused a crash in goals, all my code so I will try to
>   debug it this time
> * plplot - FTBFS for unrelated reasons last time
> * z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740
>
> 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/
>
> opam should be fixed now (was
> https://bugzilla.redhat.com/show_bug.cgi?id=1792770)
>
> Mass rebuild script:
> http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary
>
> Talk about mass rebuilding technique:
> https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1797333] perl-Scalar-List-Utils-1.54 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-24 09:19:27



--- Comment #3 from Jan Pazdziora  ---
perl-Scalar-List-Utils-1.54-440.fc32.x86 is in Fedora rawhide.

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

Looking for co-maintainer for xmedcon and deps: will help learn packaging and sponsor

[Ankur Sinha]

Hi,

I'm looking for a co-maintainer to help me maintain (and keep) xmedcon
in Fedora. It is a commonly used open source medical image conversion
toolkit:

https://xmedcon.sourceforge.io/

I will help you learn packaging and will also help you get sponsored to
the packager group. The idea is that over time, you will become the main
maintainer for xmedcon in Fedora and use your skills to help maintain
other packages in Fedora also.

- time requirements: you will need to commit at least 2-3 hours a week
  to Fedora tasks,
- skills required: none, you can learn "on the job".

Packages that you will be looking after to start with:

- xmedcon: https://src.fedoraproject.org/rpms/xmedcon

and its dependencies. Currently, we need to package tpclib to replace
two of its components (and update them to latest upstream versions)

- https://gitlab.utu.fi/vesoik/tpcclib
- https://src.fedoraproject.org/rpms/libtpcimgio
- https://src.fedoraproject.org/rpms/libtpcmisc

For more information on what package maintainers do, please look at:
- https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Please read the provided links, and e-mail me off-list if you are
interested.

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

[Bug 1805790] perl-Alien-pkgconf-0.16 is available

[bugzilla]

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



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

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

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

[Bug 1805790] perl-Alien-pkgconf-0.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Alien-pkgconf-0.16-1.f
   ||c33



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

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

OCaml 4.10.0 build in Fedora 32 and 33

[Richard W.M. Jones]

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.

There are some packages which are still failing to build:

* coccinelle - Uses -unsafe-string, still waiting resolution upstream.
* nbdkit - Caused a crash in goals, all my code so I will try to
  debug it this time
* plplot - FTBFS for unrelated reasons last time
* z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740

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/

opam should be fixed now (was
https://bugzilla.redhat.com/show_bug.cgi?id=1792770)

Mass rebuild script:
http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary

Talk about mass rebuilding technique:
https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/

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

[Bug 1805790] perl-Alien-pkgconf-0.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value



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

Fedora-Cloud-31-20200224.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