Fedora-Cloud-33-20201225.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

ID: 746419  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/746419
ID: 746426  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/746426

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
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

[389-devel] 389 DS nightly 2020-12-25 - 93% PASS

[vashirov]

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

[Bug 1905896] perl-libnet-3.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-libnet-3.12-1.fc34 |perl-libnet-3.12-1.fc34
   |perl-libnet-3.12-1.fc33 |perl-libnet-3.12-1.fc33
   ||perl-libnet-3.12-1.fc32



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


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

[Bug 1909426] perl-Graph-0.9714 is available

[bugzilla]

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



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


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

[Bug 1909426] perl-Graph-0.9714 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Graph-0.9713 is|perl-Graph-0.9714 is
   |available   |available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.9714
Current version/release in rawhide: 0.97.12-1.fc34
URL: http://search.cpan.org/dist/Graph/

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


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


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


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


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

package review request - python-textdistance

[Mukundan Ragavan]

Hi,

Can someone please review this package?

python-textdistance:
https://bugzilla.redhat.com/show_bug.cgi?id=1910822

This should be the last package I need to update spyder to version 4.2.1 
(along with other dependencies). I can update spyder once this is approved.


Thank you,
Mukundan.



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

Re: Fedora 34 Change: Enable systemd-oomd by default for all variants(System-Wide Change)

[James Cassell]

On Tue, Dec 22, 2020, at 10:45 AM, Michael Catanzaro wrote:
> Each gnome-terminal tab runs in its own cgroup:
> 
> │ │ │ ├─app-org.gnome.Terminal.slice
> │ │ │ │ 
> ├─vte-spawn-1d1d5519-71d2-4035-929a-8a9ae5bc3822.scope
> │ │ │ │ │ ├─7848 bash
> │ │ │ │ │ └─7889 less /etc/hosts
> │ │ │ │ 
> ├─vte-spawn-03fe4cc9-0400-4723-ac9b-e929b850ca02.scope
> │ │ │ │ │ ├─7892 bash
> │ │ │ │ │ ├─7927 systemd-cgls
> │ │ │ │ │ └─7928 less
> │ │ │ │ └─gnome-terminal-server.service
> │ │ │ │ └─7843 /usr/libexec/gnome-terminal-server
> 
> Firefox does this too. WebKit doesn't, but it won't be hard to fix. Not 
> sure about Chrome. Point is, apps have all the tools they need to use 
> cgroups to ensure out-of-control subprocesses don't cause the main 
> process to be killed, and our important default apps (Firefox and 
> gnome-terminal) actually do this.
> 

It's there a way to make bash launch each command in a separate cgroup? I've 
usually got my various terminal apps in the background of a single bash 
session. It sounds like if any of them gets killed by oomd, they all would be 
killed.

Glad to hear gnome-terminal separates tabs. Any idea if tilix does the same?

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: Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

[Matthew Almond via devel]

On Wed, 2020-12-23 at 19:23 -0500, James Cassell wrote:
> # Resolve packaging request into a list of packages and operations
> > # Download and '''decompress''' packages into a '''locally
> > optimized''' rpm file
> 
> Please verify the signature on the downloaded RPM before
> decompressing it.  (Do we do this already?)
> 

We have an opportunity to do the verification during download, but I'm
not keen on it for two major reasons:

1. the transcoder would need to open the rpmdb to perform the 
   verification, adding a fair amount of complexity.
2. (more crucially) I observe that dnf downloads packages and
   signatures before asking whether to trust them. The order of events
   means we can't be confident that all signatures are in the rpmdb
   yet.

My proposal is for enabling CoW with dnf. The code change to do
transcoding is in librepo as part of the generic file download
mechanism. librepo does verify downloads relative to the repo's
recorded digest.

The transcoder produces a different series of bits to be written to
disk, so how could that verification work? Turns out the answer is
easy: we see the original bits on the input to the transcoder, so we
calculate the digest of the bits received from the yum server and
record this in the footer of the transcoded rpm. I've
modified lr_checksum_fd() in librepo to look for this before using the
xattr cache or reading the whole file again. You can only locate that
whole file digest if the footer itself is complete.

The digest is actually a list of digests. The default value in
createrepo_c is SHA256 (irrespective of what digest algorithm is used
to identify/verify files in each rpm) and for now the dnf plugin passes
"SHA256" to the transcoder statically. This is ultimately repo
specific. I hope to eliminate the hard coding later if there's signal
within librepo to choose the right digest algo for the specific repo. 

The job of actually verifying the signature falls through to rpm as it
did before. As stated in the proposal: the headers (lead, signature,
main header) are completely untouched, so the gpg based signature is
still verified as before, and at the same point in time.


> > # Install and/or upgrade packages sequentially using RPM files,
> > using
> > '''reference linking''' (reflinking) to reuse data already on disk.
> 
> Sounds like a great improvement!  Any real-world data on how much
> time it saves, how much it changes disk usage, or how much SSD writes
> it saves?
> 

Forthcoming! I've got some numbers I've used internally at Facebook to
talk about this. To do this I had to write another rpm plugin to
measure how much time was spent on decompressing and writing data. I'm
planning on improving this and open sourcing that too. The goal here is
to produce some publicly reproducible numbers.


> > The outcome is intended to be the same, but the order of operations
> > is
> > different.
> > 
> > # Decompression happens inline with download. This has a positive
> > effect on resource usage: downloads are typically limited by
> > bandwidth. Decompression and writing the full data into a single
> > file
> > per rpm is essentially free. Additionally: if there is more than
> > one
> > download at a time, a multi-CPU system can be better utilized. All
> > compression types supported in RPM work because this uses the rpm
> > I/O
> > functions.
> 
> I referenced above, I think each chunk should also be verified before
> decompressing.
> 

This is certainly possible, but not implemented. My thinking here is
that the full rpm file digest enforced for files downloaded with
dnf/librepo also covers this. The only optimization possible here is
for a damaged rpm to fail faster during transcode. I consider this a
pretty minor optimization.


> > # RPMs are cached on local storage between downloading and
> > installation time as normal. This allows DNF to defer actual RPM
> > installation to when all the RPM are available. This is unchanged.
> > # The file format for RPMs is different with Copy on Write. The
> > headers are identical, but the payload is different. There is also
> > a
> > footer.
> > ## Files are converted (“transcoded”) locally during download using
> > /usr/bin/rpm2extents (part of rpm codebase). The
> > format
> > is not intended to be “portable” - i.e. copying the files from the
> > cache is not supported.
> 
> I think these should be made to be portable.  How many variants of
> these are there?  Would it be difficult to make the transcoder also
> understand RPMs transcoded for a different
> platform/setup?  Eventually, I'd like to see additional signatures
> added to the RPM for each of the variants so RPM itself can do the
> verification at install time, avoiding a transcode to the "canonical"
> format.  (I suppose this might require a build-time or sign-time
> transcode to each of the other variants.)  Until then, I'd like to
> ensure that the package signatures are being verified in a secure
> manner, which would be necessary for the 

[Bug 1910811] New: perl-Dist-Zilla-Plugin-Git-Contributors-0.036 is available

[bugzilla]

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

Bug ID: 1910811
   Summary: perl-Dist-Zilla-Plugin-Git-Contributors-0.036 is
available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dist-Zilla-Plugin-Git-Contributors
  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: 0.036
Current version/release in rawhide: 0.035-7.fc33
URL: http://search.cpan.org/dist/Dist-Zilla-Plugin-Git-Contributors/

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


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


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


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


-- 
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 1910797] perl-Text-CSV_XS-1.45 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Text-CSV_XS-1.45-1.fc3
   ||4
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-12-24 19:42:06



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=58210953


-- 
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 1910797] New: perl-Text-CSV_XS-1.45 is available

[bugzilla]

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

Bug ID: 1910797
   Summary: perl-Text-CSV_XS-1.45 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-CSV_XS
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jose.p.oliveira@gmail.com,
ka...@ucw.cz, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.45
Current version/release in rawhide: 1.44-2.fc33
URL: http://search.cpan.org/dist/Text-CSV_XS/

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


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


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


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


-- 
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: gcc11/kconfig_compiler (was: weird build failure on i686)

[Rex Dieter]

Jeff Law wrote:

> 
> 
> On 12/19/20 9:40 PM, Rex Dieter wrote:
>> Mattia Verga via devel wrote:
>>
>>> While trying to build a new kde-partitionmanager release, I get a
>>> strange build failure which seems related to character encoding:
>>>
>>> https://kojipkgs.fedoraproject.org//work/tasks/8985/57428985/build.log
>>>
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>>48 | 挀漀渀猀琀 挀栀愀爀⨀ 挀漀渀猀琀 Config::EnumFileSystem::enumToString[] = {
>>>"Unknown", "Extended", "Ext2", "Ext3", "Ext4", "LinuxSwap", "Fat16",
>>>"Fat32", "Ntfs", "ReiserFS", "Reiser4", "Xfs", "Jfs", "Hfs",
>>>"HfsPlus", "Ufs", "Unformatted", "Btrfs", "Hpfs", "Luks", "Ocfs2",
>>>"Zfs", "Exfat", "Nilfs2", "Lvm2_PV", "F2fs", "Udf", "Iso9660",
>>>"Luks2", "Fat12", "LinuxRaidMember", "BitLocker", "Apfs", "Minix" };
>>>   | ^
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character ⨀ is not valid in an identifier
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>> /builddir/build/BUILD/partitionmanager-20.12.0/i686-redhat-linux-
>> gnu/src/config.cpp:48:1:
>>> error: extended character   is not valid in an identifier
>>>
>>> This seems to happen only on i686 arch, so I don't think sources are
>>> corrupted in some way. Also, there seems to be no relevant changes
>>> between the latest built release and this one that could justify the
>>> failure:
>>>
>>> https://github.com/KDE/kpmcore/compare/v20.11.90...v20.12.0
>>>
>>> Any idea what's going on?
>> Wierd issue with kconfig_compiler on i686 when built with gcc-11, see bug
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1907799
> I wouldn't be surprised if this turns out to be a gcc bug.  In fact,
> I've got my eye on upstream gcc bug 98366.
> 
> While I'm on PTO for the next two weeks, I'll probably be checking-in on
> a few things.  If there's a good way to test this I expect I'll have a
> compiler with the 98366 fix handy today/tomorrow.

Tentatively, looks like this gcc issue is fixed using gcc-11.0.0-0.11.fc34, 
thanks!

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2020-12-25 from 17:00:00 to 18:00:00 US/Eastern
   At fedora-meet...@irc.freenode.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9854/

___
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

i-nex: MDecode_dimms._inits.47: #45: File or directory does not exist

[Martin Gansser]

Hi,

when launch i-nex-7.6.1 [1] i get this warning

[martin@fc33 $ env QT_QPA_PLATFORM=xcb /usr/bin/i-nex.gambas
[12/24/2020 16:26:37.889] [INFO] [MStart.Main.23] Starting log
[12/24/2020 16:26:37.901] [INFO] [MStart.Main.24] Checking if eeprom module is 
loaded
MDecode_dimms._inits.47: #45: File or directory does not exist
MDecode_dimms._inits.47 Finfosys.ComboBox10_Click.1108 
MDecode_dimms.List_EEPROM.30 MStart.Main.26 

how can i fix this ?

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1661729

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

[Roberto Ragusa]

On 12/23/20 1:56 PM, Oron Peled wrote:


More problematic, but possible.

The key is using "--pinentry-mode=loopback" (I don't have my scripts in front 
of me for further details)

There are simple use cases that are very problematic.
Consider this:

[me@localhost tmp]$ date >date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt   ### this asks 
for a passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me  32 Dec 24 16:59 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
[me@localhost tmp]$ rm date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg   ### this does 
not ask!
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me  32 Dec 24 17:00 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg

that would be a very simple tutorial about symmetric encryption and it is
absolutely surprising, since decryption happens without any need to supply
the passphrase.
Because an agent was forked and it remembers the symmetric
passphrase I've used! Crazy.

So let's see if we can use --batch: using it on encryption conflicts with 
pineentry,
using it on decryption doesn't disable the gpg-agent usage.

We should try to avoid the agent, let's see in the man page:
   --use-agent
   --no-use-agent
  This is dummy option. gpg always requires the agent.
Wow, the option you want, but with a dummy implementation.

There is a --no-autostart, let's try it: more wasted time.

The use case I care about is for a script that reads some data
from an encrypted file, asking me the passphrase when necessary.
Something like:

token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)"
# use $token

The passphrase should not be hardcoded in the script or remembered by
a magic gpg-agent forked behind my back.

My only solution has been:
  dnf install gnupg1

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20201224.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 8/180 (x86_64), 9/122 (aarch64)

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

ID: 746015  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/746015
ID: 746030  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/746030
ID: 746058  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/746058
ID: 746070  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/746070
ID: 746089  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/746089
ID: 746092  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/746092
ID: 746113  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/746113
ID: 746269  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/746269

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

ID: 746037  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/746037
ID: 746047  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/746047
ID: 746056  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/746056
ID: 746135  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/746135
ID: 746210  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/746210
ID: 746237  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/746237
ID: 746248  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/746248
ID: 746264  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/746264
ID: 746273  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/746273

Soft failed openQA tests: 19/180 (x86_64), 14/122 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 746035  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/746035
ID: 746155  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/746155
ID: 746270  Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/746270

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

ID: 745976  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/745976
ID: 745977  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/745977
ID: 745984  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/745984
ID: 745988  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/745988
ID: 745992  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/745992
ID: 745993  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/745993
ID: 746006  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/746006
ID: 746078  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/746078
ID: 746087  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/746087
ID: 746088  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/746088
ID: 746096  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/746096
ID: 746107  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/746107
ID: 746127  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/746127
ID: 746131  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/746131
ID: 746154  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/746154
ID: 746170  Test: x86_64 universal 

Fedora-IoT-34-20201224.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 1/16 (x86_64), 5/15 (aarch64)

ID: 746286  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/746286
ID: 746295  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/746295
ID: 746297  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/746297
ID: 746298  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/746298
ID: 746300  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/746300
ID: 746304  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/746304

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

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

Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64)
-- 
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

[Bug 1910780] New: perl-ExtUtils-HasCompiler-0.023 is available

[bugzilla]

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

Bug ID: 1910780
   Summary: perl-ExtUtils-HasCompiler-0.023 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-ExtUtils-HasCompiler
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.023
Current version/release in rawhide: 0.022-2.fc33
URL: http://search.cpan.org/dist/ExtUtils-HasCompiler/

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


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


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


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


-- 
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: bundled libraries

[Antonio T. sagitter]

On 24/12/20 15:24, Didier Fabert wrote:

Hi,

It's for netdata package and specifically for the cloud registration 
feature. So netdata is working fine without this feature but a lot of 
users claim this feature.


All bundled libs are static, so there is no additional .so file 
installed (neither fedora nor epel repos).


We're talking about libwebsockets (min 3.2.2 and epel provides 3.0.1) 
and a "patched" version of mosquitto


For fedora package, it's working with libwebsockets from system, but not 
mosquitto.


For epel, I have to use bundled libs (for both) otherwise, it's not 
working.


Best Regards,

Didier FABERT.

In my opinion, using bundled libraries in a private directory is the 
best choice now, both in Fedora and EPEL. Different patched/bundled 
libraries could be frequently used.


--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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

Re: bundled libraries

[Didier Fabert]

Hi,

It's for netdata package and specifically for the cloud registration 
feature. So netdata is working fine without this feature but a lot of 
users claim this feature.


All bundled libs are static, so there is no additional .so file 
installed (neither fedora nor epel repos).


We're talking about libwebsockets (min 3.2.2 and epel provides 3.0.1) 
and a "patched" version of mosquitto


For fedora package, it's working with libwebsockets from system, but not 
mosquitto.


For epel, I have to use bundled libs (for both) otherwise, it's not working.

Best Regards,

Didier FABERT.

Le 24/12/2020 à 15:01, Antonio T. sagitter a écrit :
Bundled libraries are permitted as long as they do not conflict with 
system libraries.
In your case, it does not happen in Fedora but in EPEL it does; so i 
would advice you to use a private lib directory in EPEL where

bundled .so libraries (generally unversioned libraries) will be installed.

See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath


Of which libraries are we talking about?

On 24/12/20 14:17, Richard Shaw wrote:
On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert > wrote:


    Hi,

    Yes the guidelines are clear for fedora. I miss tell that the
    package is
    present in fedora and epel repos and my question is more like this:

    Is it possible to mix bundled/system libs ? like using system libs 
(the

    must part in guidelines) for fedora packages and use bundled one for
    epel packages (because libs are too old)


That's a much more interesting question :)

The first line of the main EPEL guidelines[1] says that you must 
follow the Fedora packaging guidelines and that the EPEL links are for 
the exceptions for EPEL.


So if the library is not available in EPEL, then I would say the 
answer is yes, you can use the bundled library (even if you're not on 
Fedora).


For the 2nd question, can you use them if the ones in EPEL/RHEL are 
too old, I'd like to see more feedback from others. Theoretically 
dependencies in EPEL could be updated, but it has to be done very 
carefully. For RHEL packages, I tried filling a bug about 6 years ago 
and as far as I know it's still open, with little to no feedback from RH.






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

[David Kaufmann]

On Thu, Dec 24, 2020 at 11:35:03AM +, Peter Robinson wrote:
> On Thu, Dec 24, 2020 at 10:43 AM Leigh Scott  wrote:
> >
> > > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel
> > >  > >
> > >
> > > It does support it, but AFAIK does not require it.
> > >
> > > Arguably those with elevated access (provenpackagers(*))
> > > should be required to use a hardware token such
> > > as a FIDO2 authenticators with biometrics and/or
> > > PIN required (some phones with biometrics are
> > > are equivalent to external tokens) where passwords
> > > themselves can away.  That may be a bridge too
> > > far at this point, but I would like to see that as a goal
> > > to work towards (2021 should be the year passwords
> > > die according to Microsoft).
> >
> > Are fedora going to provide us with the FIDO2 authenticators with 
> > biometrics hardware?
> > My current FIDO U2F key just has a button to press.
> 
> There's apps too

Ad biometrics:
There currently exists no biometrics authentication option, which has
not already been broken, sometimes even before release. This only adds a
false sense of security. (Fingerprints can't be just reset/renewed too)

Apps are *never* equivalent to physical tokens, as phones do have a
direct network connection with exposed services or network submitted
code run on the device almost always.

Requiring a higher security level for some things is fine, as long as it
is not too tedious - otherwise people will write workarounds for it.
FIDO2 itself seems to be current thing, but the biometrics option
doesn't add anything useful.

Ad expiration of pp accounts:
Confirmation e.g. once a year by the same person is fine (with
appropriate reminder emails/notifications), but as soon as you add more
requirements from other persons it makes it more political.

All the best,
Astra


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

[EPEL-devel] Re: bundled libraries

[Antonio T. sagitter]

Bundled libraries are permitted as long as they do not conflict with 
system libraries.
In your case, it does not happen in Fedora but in EPEL it does; so i 
would advice you to use a private lib directory in EPEL where

bundled .so libraries (generally unversioned libraries) will be installed.

See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath


Of which libraries are we talking about?

On 24/12/20 14:17, Richard Shaw wrote:
On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert > wrote:


Hi,

Yes the guidelines are clear for fedora. I miss tell that the
package is
present in fedora and epel repos and my question is more like this:

Is it possible to mix bundled/system libs ? like using system libs (the
must part in guidelines) for fedora packages and use bundled one for
epel packages (because libs are too old)


That's a much more interesting question :)

The first line of the main EPEL guidelines[1] says that you must follow 
the Fedora packaging guidelines and that the EPEL links are for the 
exceptions for EPEL.


So if the library is not available in EPEL, then I would say the answer 
is yes, you can use the bundled library (even if you're not on Fedora).


For the 2nd question, can you use them if the ones in EPEL/RHEL are too 
old, I'd like to see more feedback from others. Theoretically 
dependencies in EPEL could be updated, but it has to be done very 
carefully. For RHEL packages, I tried filling a bug about 6 years ago 
and as far as I know it's still open, with little to no feedback from RH.





--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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: bundled libraries

[Antonio T. sagitter]

Bundled libraries are permitted as long as they do not conflict with 
system libraries.
In your case, it does not happen in Fedora but in EPEL it does; so i 
would advice you to use a private lib directory in EPEL where

bundled .so libraries (generally unversioned libraries) will be installed.

See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath


Of which libraries are we talking about?

On 24/12/20 14:17, Richard Shaw wrote:
On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert > wrote:


Hi,

Yes the guidelines are clear for fedora. I miss tell that the
package is
present in fedora and epel repos and my question is more like this:

Is it possible to mix bundled/system libs ? like using system libs (the
must part in guidelines) for fedora packages and use bundled one for
epel packages (because libs are too old)


That's a much more interesting question :)

The first line of the main EPEL guidelines[1] says that you must follow 
the Fedora packaging guidelines and that the EPEL links are for the 
exceptions for EPEL.


So if the library is not available in EPEL, then I would say the answer 
is yes, you can use the bundled library (even if you're not on Fedora).


For the 2nd question, can you use them if the ones in EPEL/RHEL are too 
old, I'd like to see more feedback from others. Theoretically 
dependencies in EPEL could be updated, but it has to be done very 
carefully. For RHEL packages, I tried filling a bug about 6 years ago 
and as far as I know it's still open, with little to no feedback from RH.





--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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

Re: bundled libraries

[Neal Gompa]

On Thu, Dec 24, 2020 at 8:18 AM Richard Shaw  wrote:
>
> On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert  wrote:
>>
>> Hi,
>>
>> Yes the guidelines are clear for fedora. I miss tell that the package is
>> present in fedora and epel repos and my question is more like this:
>>
>> Is it possible to mix bundled/system libs ? like using system libs (the
>> must part in guidelines) for fedora packages and use bundled one for
>> epel packages (because libs are too old)
>
>
> That's a much more interesting question :)
>
> The first line of the main EPEL guidelines[1] says that you must follow the 
> Fedora packaging guidelines and that the EPEL links are for the exceptions 
> for EPEL.
>
> So if the library is not available in EPEL, then I would say the answer is 
> yes, you can use the bundled library (even if you're not on Fedora).
>
> For the 2nd question, can you use them if the ones in EPEL/RHEL are too old, 
> I'd like to see more feedback from others. Theoretically dependencies in EPEL 
> could be updated, but it has to be done very carefully. For RHEL packages, I 
> tried filling a bug about 6 years ago and as far as I know it's still open, 
> with little to no feedback from RH.
>

If the library is in RHEL, file a bug asking for it to be updated,
mark the library as bundled with a comment about why with a link to
the BZ. If the library is in EPEL, talk to the maintainer about
updating it. If it's not feasible, then do the same as you would for
RHEL stuff.

That's the way I've handled it so far.



-- 
真実はいつも一つ！/ 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 rawhide compose report: 20201224.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201221.n.0
NEW: Fedora-Rawhide-20201224.n.0

= SUMMARY =
Added images:0
Dropped images:  66
Added packages:  8
Dropped packages:3
Upgraded packages:   247
Downgraded packages: 0

Size of added packages:  24.67 MiB
Size of dropped packages:5.09 MiB
Size of upgraded packages:   15.74 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Server boot aarch64
Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20201221.n.0.iso
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-Rawhide-20201221.n.0.armhfp.raw.xz
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-Rawhide-20201221.n.0.armhfp.raw.xz
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20201221.n.0.iso
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20201221.n.0.iso
Image: Cloud_Base raw-xz x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20201221.n.0.x86_64.raw.xz
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Container_Minimal_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Minimal-Base-Rawhide-20201221.n.0.armhfp.tar.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20201221.n.0.iso
Image: KDE live x86_64
Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Cloud_Base raw-xz aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201221.n.0.aarch64.raw.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20201221.n.0.iso
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20201221.n.0.armhfp.tar.xz
Image: Minimal raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Minimal-Rawhide-20201221.n.0.armhfp.raw.xz
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201221.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20201221.n.0.iso
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20201221.n.0.aarch64.raw.xz
Image: Server dvd armhfp
Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20201221.n.0.iso
Image: Everything boot x86_64
Path: 
Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20201221.n.0.iso
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20201221.n.0.aarch64.raw.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20201221.n.0-sda.raw.xz
Image: Minimal_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Minimal-armhfp-Rawhide-20201221.n.0-sda.raw.xz
Image: Cloud_Base vagrant-libvirt x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201221.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201221.n.0.x86_64.vagrant-libvirt.box
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20201221.n.0.x86_64.tar.xz
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20201221.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20201221.n.0.iso
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20201221.n.0.x86_64.tar.xz
Image: Cloud_Base qcow2 aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201221.n.0.aarch64.qcow2
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20201221.n.0.aarch64.tar.xz
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20201221.n.0.iso
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201221.n.0.x86_64.vagrant

Re: bundled libraries

[Didier Fabert]

Hi,

Thank you very much Richard.

Best Regards,

Didier FABERT.

Le 24/12/2020 à 14:17, Richard Shaw a écrit :
On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert > wrote:


Hi,

Yes the guidelines are clear for fedora. I miss tell that the
package is
present in fedora and epel repos and my question is more like this:

Is it possible to mix bundled/system libs ? like using system libs (the
must part in guidelines) for fedora packages and use bundled one for
epel packages (because libs are too old)


That's a much more interesting question :)

The first line of the main EPEL guidelines[1] says that you must follow 
the Fedora packaging guidelines and that the EPEL links are for the 
exceptions for EPEL.


So if the library is not available in EPEL, then I would say the answer 
is yes, you can use the bundled library (even if you're not on Fedora).


For the 2nd question, can you use them if the ones in EPEL/RHEL are too 
old, I'd like to see more feedback from others. Theoretically 
dependencies in EPEL could be updated, but it has to be done very 
carefully. For RHEL packages, I tried filling a bug about 6 years ago 
and as far as I know it's still open, with little to no feedback from RH.


Thanks,
Richard

[1] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies 



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

[Richard Shaw]

On Thu, Dec 24, 2020 at 1:45 AM Didier Fabert 
wrote:

> Hi,
>
> Yes the guidelines are clear for fedora. I miss tell that the package is
> present in fedora and epel repos and my question is more like this:
>
> Is it possible to mix bundled/system libs ? like using system libs (the
> must part in guidelines) for fedora packages and use bundled one for
> epel packages (because libs are too old)
>

That's a much more interesting question :)

The first line of the main EPEL guidelines[1] says that you must follow the
Fedora packaging guidelines and that the EPEL links are for the exceptions
for EPEL.

So if the library is not available in EPEL, then I would say the answer is
yes, you can use the bundled library (even if you're not on Fedora).

For the 2nd question, can you use them if the ones in EPEL/RHEL are too
old, I'd like to see more feedback from others. Theoretically dependencies
in EPEL could be updated, but it has to be done very carefully. For RHEL
packages, I tried filling a bug about 6 years ago and as far as I know it's
still open, with little to no feedback from RH.

Thanks,
Richard

[1] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Stale proven packagers

[Peter Robinson]

On Thu, Dec 24, 2020 at 10:43 AM Leigh Scott  wrote:
>
> > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel
> >  >
> >
> > It does support it, but AFAIK does not require it.
> >
> > Arguably those with elevated access (provenpackagers(*))
> > should be required to use a hardware token such
> > as a FIDO2 authenticators with biometrics and/or
> > PIN required (some phones with biometrics are
> > are equivalent to external tokens) where passwords
> > themselves can away.  That may be a bridge too
> > far at this point, but I would like to see that as a goal
> > to work towards (2021 should be the year passwords
> > die according to Microsoft).
>
> Are fedora going to provide us with the FIDO2 authenticators with biometrics 
> hardware?
> My current FIDO U2F key just has a button to press.

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

[Leigh Scott]

> On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel
>  
> 
> It does support it, but AFAIK does not require it.
> 
> Arguably those with elevated access (provenpackagers(*))
> should be required to use a hardware token such
> as a FIDO2 authenticators with biometrics and/or
> PIN required (some phones with biometrics are
> are equivalent to external tokens) where passwords
> themselves can away.  That may be a bridge too
> far at this point, but I would like to see that as a goal
> to work towards (2021 should be the year passwords
> die according to Microsoft).

Are fedora going to provide us with the FIDO2 authenticators with biometrics 
hardware?
My current FIDO U2F key just has a button to press.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20201224.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

ID: 745915  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/745915
ID: 745922  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/745922

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
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