Re: Making Fedora secure - Package exit policy for security

[Huzaifa Sidhpurwala]

On 07/31/2018 05:05 PM, Ondřej Lysoněk wrote:
> On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote:
>> I would like to propose the following:
>>
>>
>> 1. If a CRITICAL or IMPORTANT security issue is open against a package
>> in Fedora-X and by the time X is EOL and the issue is not addressed,
>> proactively remove the package from X+1
>> 2. If a MODERATE or LOW security issue is open against a package in
>> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
>> it from X+2
>>
>> Note:
>> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro
>> 2. X/X+1 is the best boundary to remove the insecure packages imo, since
>> inbetween removals are not possible due to the way mirrors work.
>> 3. Maintain a list somewhere (automated maybe) of the list of packages
>> removed and why.
>> 4. Have a list of critical pkg, which cannot be removed which will break
>> the distro.
> Please make sure the process takes into account the fact that packages
> may be affected by CVEs in certain Fedora releases only. For example an
> older version of a package in F27 is affected by a CVE, but a new
> (rewritten) version in F28 is not. It seems the summary of CVE bugs
> accordingly contains either the string "[fedora-all]", or "[fedora-27]",
> "[fedora-28]" etc. Hopefully that is a reliable source of information.
>

In this case, the CVE tracker should be fixed as CLOSED:WONTFIX,
Automation will only look at open bugs!



-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y3PSYRIVOMETQ67AGMQOBYHEKF73GHPR/

Re: Making Fedora secure - Package exit policy for security

[Huzaifa Sidhpurwala]

On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote:

> 
> Do we have any analysis showing what would be the fallout if we applied
> these purge rules today ? ie what packages would be dropped today due
> to unaddressed CVEs.
> 
See reply to my previous email. Also i have attached the list here. I
did some random analysis and came up with the following conclusion:

https://bugzilla.redhat.com/show_bug.cgi?id=1493497
This one is ftbs on ppc

https://bugzilla.redhat.com/show_bug.cgi?id=1488785
This one was actually fixed, but the bug did not close

https://bugzilla.redhat.com/show_bug.cgi?id=1487715
This is iamgemagick so one of many cves which are open against it.

https://bugzilla.redhat.com/show_bug.cgi?id=1484840
Not sure.


> Then, from that list of packages, do we have idea of reasons why
> their CVEs are not getting fixed in Fedora. This could perhaps identify
> changes to help with the problem(s), rather than jumping straight to
> the big stick of dropping packages.
> 
I definitely want to address the core problem here, but i dont want to
go through tens and even sometimes hundreds of bugs to figure out why
they have not been fixed. Shouldnt the package maintainer be doing it in
the first place?


> 
> Regards,
> Daniel
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
apt-cacher-ng
asterisk
async-http-client
binutils
bzr
chromium
connman
docker-distribution
docker-latest
emacs
freerdp1.2
glpi
hive
ImageMagick
itext
jenkins-script-security-plugin
ledger
libmspack
libsndfile
lrzip
mantis
mercurial
mesos
mingw-binutils
mingw-curl
mingw-icu
mingw-libgcrypt
mingw-openjpeg2
mingw-openssl
mingw-SDL2_image
mongoose
newsbeuter
nodejs-debug
nodejs-fresh
nodejs-hawk
nodejs-method-override
nodejs-mime
nodejs-st
opencv
openjpeg
openjpeg2
opennlp
passenger
php
php-Kohana
python-scrapy
resiprocate
rtpproxy
rubygem-ox
rubygems
sleuthkit
springframework-amqp
spring-ldap
tcmu-runner
tidy
undertow
xorg-x11-server
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L62W4VXEJKI6RLUP6WPX5EPCT6Q7EE6H/

Re: Making Fedora secure - Package exit policy for security

[Huzaifa Sidhpurwala]

On 07/31/2018 08:33 PM, Rex Dieter wrote:

>> 1. If a CRITICAL or IMPORTANT security issue is open against a package
>> in Fedora-X and by the time X is EOL and the issue is not addressed,
>> proactively remove the package from X+1
>> 2. If a MODERATE or LOW security issue is open against a package in
>> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
>> it from X+2
> 
> I don't think this is practical, we'll lose half the distro (are at least 
> large chunks).
> 
> Initially, such a proposal may be possible if generally limited to leaf 
> packages.
> 

So, i did some analysis of the number of packages which would be
actually removed if we allowed this policy. I generated a list of open
CVE bugs against X-2 which in this case is Fedora-26 and i got the
following list:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26

If you extract the list of components ,it yields 57 unique components.
out of that components like xorg-server etc would probably be in the
critical list.

So overall, i dont think its a big problem imo. Theoretically if there
is an FTBS, the maintainer would definitely want to do something to fix
this. Maybe a lot of these bugs are not really applicable or a rebase
already fixed them, so all that is required is to close the bug with an
approproate explanation.




-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7X4LIFJD7NTJN4A4Z3JYJPI43SBL7RGA/

Re: Updates to mathematical software

[Jerry James]

Paul,

On Tue, May 29, 2018 at 4:36 AM Paul Howarth  wrote:
> On Mon, 28 May 2018 21:03:34 -0600
> Jerry James  wrote:
> > It looks like the giac, Macaulay2, and sagemath stacks are the only
> > pari consumers.  There is also a pending update to clisp that will
> > bring its pari integration back; that has been missing for a few
> > years.  And sure enough, I've got my fingers in all of those
> > pies. :-)  I'm happy to take pari off of your hands if you want to
> > hand it over.
>
> OK, done. Have fun!

Are you also the maintainer of the pari-elldata, pari-galdata,
pari-galpol, and pari-seadata packages?  If so, I might as well take
those, too.  An update to pari-galpol is needed for the latest version
of pari.

Regards,
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LGW7FK4QCI4LVKVAB45QQ5S7ME22CFUE/

Re: Orphaning winswitch

[Jonathan Underwood]

On 29 July 2018 at 19:14, Jonathan Underwood
 wrote:
> Dear All,
>
> I haven't used winswitch for a few years now, and haven't really got
> the bandwidth to maintain the package, and so I plan to orphan it in
> the coming week. Winswitch is developed by the same person as Xpra and
> provides a front end to Xpra as well as other remote desktop
> applications. I've cc'd the Xpra package owner in case he wants to
> pick it up.

I have now orphaned this package (and also removed admin rights from
cicku/Christopher Meng who stopped contributing to the project a long
time ago).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PGILMRAX6XZNNLT7QUEN77S66GBCDOB3/

Re: Please help me test Workstation 28 -> 29 upgrade

[Adam Williamson]

On Wed, 2018-08-01 at 00:13 +0200, Miro Hrončok wrote:
> Hi,
> 
> could somebody please test upgrade from fully upgraded Workstation 28 to 
> 29? I have a suspicion that it will be blocked by [0], yet I lack disk 
> space to try it.
> 
> Thanks.
> 
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1605613

openQA does this on every compose.

Upgrading with dnf without '--allowerasing' does indeed fail on this
problem, but with '--allowerasing' it works (the openQA test first
tries the former, if it fails, it registers a 'soft fail' and tries the
latter instead). GNOME Software, IIRC, does the equivalent of '--best
--allowerasing' by default, so upgrading graphically would probably
work.

https://openqa.fedoraproject.org/tests/261810

(Note today's test failed due to
https://bugzilla.redhat.com/show_bug.cgi?id=1610562 ).

Also note this should probably have gone to test@ or devel@...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/message/O5QP2FBWPDXOKQCFTZRCUZZIYOQ3RCMN/

Review swap, Perl flavored

[Robert-André Mauchin]

Hello,


Today is my first year anniversary of contributing to Fedora, yay us!

I've just proposed a Perl program to review:

Bug 1610554 - (perl-Crypt-HSXKPasswd) Review Request: hsxkpasswd - Secure 
memorable password generator
https://bugzilla.redhat.com/show_bug.cgi?id=1610554

Description:
A secure memorable password generator inspired by the wonderful XKCD
webcomic at http://www.xkcd.com/ and Steve Gibson's Password Haystacks page
at https://www.grc.com/haystack.htm. This is the Perl module that powers
https://www.xkpasswd.net.

I'll review any package(s) in exchange, even a forgotten old one.

Best regards,

Robert-André

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

Please help me test Workstation 28 -> 29 upgrade

[Miro Hrončok]

Hi,

could somebody please test upgrade from fully upgraded Workstation 28 to 
29? I have a suspicion that it will be blocked by [0], yet I lack disk 
space to try it.


Thanks.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1605613
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/message/225JZC37I7BKP4N7XSAPPJSNEEJN2GD7/

Fedora Rawhide-20180731.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 60/138 (x86_64), 23/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180730.n.0):

ID: 262052  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262052
ID: 262054  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262054
ID: 262065  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/262065
ID: 262066  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/262066
ID: 262073  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/262073
ID: 262077  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262077
ID: 262080  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262080
ID: 262090  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/262090
ID: 262092  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262092
ID: 262093  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/262093
ID: 262099  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262099
ID: 262101  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/262101
ID: 262110  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/262110
ID: 262115  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/262115
ID: 262126  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/262126
ID: 262127  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/262127
ID: 262128  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/262128
ID: 262129  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/262129
ID: 262132  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/262132
ID: 262133  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/262133
ID: 262134  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/262134
ID: 262135  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/262135
ID: 262136  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/262136
ID: 262137  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/262137
ID: 262138  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/262138
ID: 262139  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/262139
ID: 262140  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/262140
ID: 262143  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/262143
ID: 262144  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/262144
ID: 262145  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/262145
ID: 262146  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/262146
ID: 262148  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/262148
ID: 262149  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/262149
ID: 262151  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/262151
ID: 262152  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/262152
ID: 262164  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/262164
ID: 262165  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/262165
ID: 262166  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/262166
ID: 262169  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/262169
ID: 262170  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/262170
ID: 262177  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/262177
ID: 262178  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/262178
ID: 262180  

Re: Intent to retire python-svgwrite

[Miro Hrončok]

On 31.7.2018 21:25, Robert Brown wrote:
> On Tue, Jul 31, 2018, 3:18 PM Miro Hrončok  > wrote:
>
> On 31.7.2018 21:06, Robert Brown wrote:
>  > I have an account and was recently sponsored.
>  >
>  > Still waiting on joining packagers group. Are you able to add me?
> sponsoring = adding to the group

Got it. Thanks. I'm not sure what to do at this point.


Contact your sponsor?

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EQGTJA4ACAEYL6KG4GC4YQQZR6BXFLRP/

Re: Intent to retire python-svgwrite

[Robert Brown]

Got it. Thanks. I'm not sure what to do at this point.

On Tue, Jul 31, 2018, 3:18 PM Miro Hrončok  wrote:

> On 31.7.2018 21:06, Robert Brown wrote:
> > I have an account and was recently sponsored.
> >
> > Still waiting on joining packagers group. Are you able to add me?
> sponsoring = adding to the group
>
> --
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JWAZM5H7NWGVYMWAYLN6U3GU7WQDSKA6/

Re: Intent to retire python-svgwrite

[Miro Hrončok]

On 31.7.2018 21:06, Robert Brown wrote:

I have an account and was recently sponsored.

Still waiting on joining packagers group. Are you able to add me?

sponsoring = adding to the group

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VKD2NMIK4T6EMID5W5WK4YDHQDZB6MMX/

Fedora rawhide compose report: 20180731.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180730.n.0
NEW: Fedora-Rawhide-20180731.n.0

= SUMMARY =
Added images:4
Dropped images:  3
Added packages:  12
Dropped packages:1
Upgraded packages:   134
Downgraded packages: 2

Size of added packages:  13.06 MiB
Size of dropped packages:49.54 KiB
Size of upgraded packages:   5.89 GiB
Size of downgraded packages: 4.94 GiB

Size change of upgraded packages:   34.65 MiB
Size change of downgraded packages: -116.41 KiB

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180731.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180731.n.0.s390x.raw.xz
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20180731.n.0.iso
Image: Jam_KDE live i386
Path: Labs/i386/iso/Fedora-Jam_KDE-Live-i386-Rawhide-20180731.n.0.iso

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180730.n.0.s390x.tar.xz
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20180730.n.0.s390x.tar.xz
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20180730.n.0.iso

= ADDED PACKAGES =
Package: chafa-0.9.0-1.fc29
Summary: Image-to-text converter for terminal
RPMs:chafa chafa-devel chafa-doc chafa-libs chafa-static
Size:868.53 KiB

Package: fuse-overlayfs-0.1-4.dev.git79c70fd.fc29
Summary: FUSE overlay+shiftfs implementation for rootless containers
RPMs:fuse-overlayfs
Size:308.83 KiB

Package: libmobi-0.4-1.fc29
Summary: Library for handling Kindle (MOBI) formats of ebook documents
RPMs:libmobi libmobi-devel libmobi-tools
Size:954.98 KiB

Package: mingw-python-enum34-1.1.6-1.fc29
Summary: MinGW Windows Python enum34
RPMs:mingw32-python2-enum34 mingw64-python2-enum34
Size:95.41 KiB

Package: python-arpeggio-1.9.0-1.fc29
Summary: Packrat parser interpreter
RPMs:python3-arpeggio
Size:50.39 KiB

Package: python-flaky-3.4.0-1.fc29
Summary: Plugin for nose or py.test that automatically reruns flaky tests
RPMs:python3-flaky
Size:38.11 KiB

Package: python-genty-1.3.2-1.fc29
Summary: Allows you to run a test with multiple data sets
RPMs:python3-genty
Size:29.21 KiB

Package: python-parver-0.1.1-1.fc29
Summary: Parse and manipulate version numbers
RPMs:python3-parver
Size:29.47 KiB

Package: rust-cargo-0.28.0-1.fc29
Summary: Cargo, a package manager for Rust
RPMs:rust-cargo-devel
Size:725.59 KiB

Package: rust-encoding_rs_io-0.1.1-1.fc29
Summary: Streaming transcoding for encoding_rs
RPMs:rust-encoding_rs_io-devel
Size:23.82 KiB

Package: rust-gcsf-0.1.16-1.module_1960+94e1e224
Summary: Filesystem based on Google Drive
RPMs:gcsf rust-gcsf-devel
Size:9.71 MiB

Package: slirp4netns-0.1-1.dev.gitc4e1bc5.fc29
Summary: slirp for network namespaces
RPMs:slirp4netns
Size:313.03 KiB


= DROPPED PACKAGES =
Package: python-toro-1.0.1-5.fc28
Summary: Synchronization primitives for Tornado coroutines
RPMs:python2-toro python3-toro
Size:49.54 KiB


= UPGRADED PACKAGES =
Package:  CuraEngine-lulzbot-1:3.2.23-2.fc29
Old package:  CuraEngine-lulzbot-1:3.2.21-2.fc29
Summary:  Engine for processing 3D models into G-code instructions for 3D 
printers
RPMs: CuraEngine-lulzbot
Size: 4.36 MiB
Size change:  -54.19 KiB
Changelog:
  * Mon Jul 30 2018 Tom Callaway  - 1:3.2.23-1
  - update to 3.2.23

  * Mon Jul 30 2018 Tom Callaway  - 1:3.2.23-2
  - do not copy the resources directory to itself (no-op)


Package:  PackageKit-1.1.10-4.fc29
Old package:  PackageKit-1.1.10-3.fc29
Summary:  Package management service
RPMs: PackageKit PackageKit-command-not-found PackageKit-cron 
PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin 
PackageKit-gtk3-module
Size: 8.37 MiB
Size change:  -167.80 KiB
Changelog:
  * Tue Jul 24 2018 Stephen Gallagher  - 1.1.10-4
  - Add patch to support modularity


Package:  PyGreSQL-5.0.6-1.fc29
Old package:  PyGreSQL-5.0.5-3.fc29
Summary:  Python client library for PostgreSQL
RPMs: python2-pygresql python3-pygresql
Size: 1.46 MiB
Size change:  -29.18 KiB
Changelog:
  * Mon Jul 30 2018 Pavel Raiskup  - 5.0.6-1
  - rebase to the latest upstream version, per release notes:
http://www.pygresql.org/contents/changelog.html


Package:  R-Rmpfr-0.7.1-1.fc29
Old package:  R-Rmpfr-0.7.0-3.fc29
Summary:  R MPFR - Multiple Precision Floating-Point Reliable
RPMs: R-Rmpfr
Size: 7.60 MiB
Size change:  50.43 KiB
Changelog:
  * Tue Jul 31 2018 Elliott Sales de Andrade  - 
0.7.1-1
  - Update to latest version


Package:  R-diffobj-0.1.11-1.fc29
Old package:  R-diffobj-0.1.10-1.fc29
Summary:  Diffs for R Objects
RPMs: R-diffobj
Size: 6.42 MiB
Size change

Re: Intent to retire python-svgwrite

[Robert Brown]

I have an account and was recently sponsored.

Still waiting on joining packagers group. Are you able to add me?

On Tue, Jul 31, 2018, 12:26 PM Julien Enselme  wrote:

> It seems I cannot find you on
> https://src.fedoraproject.org/rpms/python-svgwrite/settings
>
> Do you have an account and are you a packager?
> --
> Julien Enselme
> http://www.jujens.eu/
>
> On Tue, 2018-07-31 at 10:30 -0400, Robert Brown wrote:
> > Thanks! It gives me something productive to do.
> >
> > Fedora username is brown2rl
> >
> > On Tue, Jul 31, 2018, 4:04 AM Julien Enselme 
> > wrote:
> > > I'll gladly give you access. What is your fedora username?
> > >
> > > The repo: https://src.fedoraproject.org/rpms/python-svgwrite/
> > > The bugs on bugzilla:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1605936
> > >
> > > PS: I made a mistake in the package name. The name is python-
> > > svgwrite,
> > > not just python-svg. Sorry about that.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3W4POTBGGQQPWX6CLD7J73Q4UDEWOGG/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YM624HFTIS7LKKMCDEAEQT66FV5YOQXE/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ANR3PIHTAPXLWIQA4CYBXHD7PSHHEYAR/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-HTTP-Tiny-0.074-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-25a251c107

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/LA2MOJVM6BCWOVP5TFRUB5PPN7BQ2X7N/

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  51  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d801e05f92   
uwsgi-2.0.17.1-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aeb81e4fba   
libpng10-1.0.69-5.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a83d5ad82b   
redis-3.2.12-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b4f8d828cd   
perl-Parallel-ForkManager-1.20-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-68e2f541df   
pam_yubico-2.26-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4186e02757   
seamonkey-2.49.4-2.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

R-inline-0.3.15-1.el6
pythia8-8.2.35-4.el6

Details about builds:



 R-inline-0.3.15-1.el6 (FEDORA-EPEL-2018-e5a6948727)
 Functions to Inline C, C++, Fortran Function Calls from R

Update Information:

Update to version 0.3.15

ChangeLog:





 pythia8-8.2.35-4.el6 (FEDORA-EPEL-2018-698e2b484e)
 Pythia Event Generator for High Energy Physics

Update Information:

Don't own toplevel __pycache__ directory

ChangeLog:

* Tue Jul 31 2018 Mattias Ellert  - 8.2.35-4
- Don't own toplevel __pycache__ directory
* Fri Jul 13 2018 Fedora Release Engineering  - 
8.2.35-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ZLR53TAHZC5WSMWGX3SPWWA7QU5K4JGG/

License update for nodejs-qunitjs package

[Jared K. Smith]

I updated the version of nodejs-qunitjs in Rawhide today, and it's license
has changed from "MIT and ASL 2.0" to "MIT".  Previously, the entire
package was under the MIT license, with the exception of the src/diff.js
file, which was under the ASL 2.0 license.  That file has since been
removed, and the entire package is now under the MIT license.

--
Jared Smith
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PCDH4LG2D75UEMVQNJFXEILTFJ7OBLXJ/

Fedora testing-20180731.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XM5LVYU6Y4JXTB5J57CCF7AUVY2MZESC/

Fedora updates-20180731.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default: 
Filesystem for mount /sysroot changed from 
/dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root to 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root
Previous test data: https://openqa.fedoraproject.org/tests/261885#downloads
Current test data: https://openqa.fedoraproject.org/tests/262260#downloads

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default@uefi: 
Filesystem for mount /sysroot changed from 
/dev/mapper/fedora--atomic_ibm--p8--kvm--03--guest--02-root to 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root
System load changed from 0.21 to 0.61
Previous test data: https://openqa.fedoraproject.org/tests/261886#downloads
Current test data: https://openqa.fedoraproject.org/tests/262261#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6VPQ7IOQBWZDW646LT5SFUKBEB6J42MT/

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  51  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-15b7dc35af   
pass-1.7.2-1.el7
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ccbe8e3c4d   
knot-resolver-2.4.0-1.el7
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d2e0971e9b   
uwsgi-2.0.17.1-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f07844689   
znc-1.7.1-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d8d62b4f6c   
suricata-4.0.5-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8de40d24ca   
redis-3.2.12-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f19460105c   
pam_yubico-2.26-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5b5c4b0050   
rust-1.27.2-3.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e9a8615099   
mbedtls-2.7.5-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-52b5b56d0a   
seamonkey-2.49.4-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5346e2123a   
dpkg-1.18.25-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

R-inline-0.3.15-1.el7
RBTools-1.0.1-1.el7
golang-gopkg-data-dog-sqlmock-1-1.3.0-1.el7
moodle-3.1.13-1.el7
odcs-0.2.10-1.el7
pythia8-8.2.35-4.el7

Details about builds:



 R-inline-0.3.15-1.el7 (FEDORA-EPEL-2018-e44cdd0af6)
 Functions to Inline C, C++, Fortran Function Calls from R

Update Information:

Update to version 0.3.15

ChangeLog:





 RBTools-1.0.1-1.el7 (FEDORA-EPEL-2018-f0f5e2510a)
 Tools for use with ReviewBoard

Update Information:

Update to 1.0.1 * Fixed tracking branch detection with Git

ChangeLog:

* Mon Jul 30 2018 Stephen Gallagher  - 1.0.1-1
- Update to RBTools 1.0.1
- Fixed tracking branch detection with Git




 golang-gopkg-data-dog-sqlmock-1-1.3.0-1.el7 (FEDORA-EPEL-2018-82e93f81c0)
 SQL mock driver for golang to test database interactions

Update Information:

Initial epel7 release.

References:

  [ 1 ] Bug #1561369 - fzf would be nice to have in EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=1561369




 moodle-3.1.13-1.el7 (FEDORA-EPEL-2018-4f0963b857)
 A Course Management System

Update Information:

Multiple CVE fixes.

ChangeLog:

* Mon Jul 30 2018 Gwyn Ciesla  - 3.1.13-1
- 3.1.13.

References:

  [ 1 ] Bug #1599817 - CVE-2018-10891 moodle: Quiz question bank import preview 
could execute JavaScript [epel-7]
https://bugzilla.redhat.com/show_bug.cgi?id=1599817
  [ 2 ] Bug #1599807 - CVE-2018-10890 moodle: Web service 
core_course_get_categories may return invisible categories [epel-7]
https://bugzilla.redhat.com/show_bug.cgi?id=1599807
  [ 3 ] Bug #1599816 - CVE-2018-10891 moodle: Quiz question bank import preview 
could execute JavaScript [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1599816
  [ 4 ] Bug #1599806 - CVE-2018-10890 moodle: Web service 
core_course_get_categories may return invisible categories [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1599806
  [ 5 ] Bug #1599800 - CVE-2018-10889 moodle: Privacy data exports include log 
data [fedora-27]
https://bugzilla.redhat.com/show_bug.cgi?id=1599800




 odcs-0.2.10-1.el7 

[Bug 1604727] ctstream-28 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
ctstream-28-1.fc28 has been pushed to the Fedora 28 stable repository. If
problems still persist, 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/SDJK75WBONMAJAYOZPFEROAH64EMCTBC/

Fedora 29 Software String Freeze

[Ben Cotton]

Today (2018-07-31) we have reached the "Software String Freeze"
deadline. Beyond this deadline there should not be any changes in
strings.

If you want to help with translations, please check the packages that
follow Fedora release cycle (Main projects):
https://fedora.zanata.org/version-group/view/main

The deadline for translations is 2018-08-28 (Software Translation
Deadline). See the translation schedule[1] for more detail.

[1] https://fedorapeople.org/groups/schedule/f-29/f-29-trans-tasks.html

-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SU4LNPDA3JHZKYWBDMBCSB6CNEYDB6DC/

[Bug 1604727] ctstream-28 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
ctstream-28-1.fc27 has been pushed to the Fedora 27 stable repository. If
problems still persist, 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/C4VVR6Y7EGQYOCTM6IO7B74OOMAXYEWC/

Re: python-pip license changed (and clarified)

[Miro Hrončok]

On 31.7.2018 18:15, Jun Aruga wrote:

9.0.x -> 10.0.x then 18.0?


https://github.com/pypa/pip/blob/master/NEWS.rst
Switch to a Calendar based versioning scheme.


Oh they changed the versioning rule.


See also 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/S7FE45Y76MBIXU7QE75FTZSPEPLIIWOH/


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FRNJ7THFVYONYLU2KL3EY2JEYJFTDSY7/

Re: python-pip license changed (and clarified)

[Jun Aruga]

9.0.x -> 10.0.x then 18.0?

> https://github.com/pypa/pip/blob/master/NEWS.rst
> Switch to a Calendar based versioning scheme.

Oh they changed the versioning rule.

Jun


On Tue, Jul 31, 2018 at 3:48 PM, Miro Hrončok  wrote:
> python-pip 9.0.x had MIT as License (bundled deps were not mentioned)
>
> python-pip 18.0 now has more enjoyable:
>
> MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and (ASL
> 2.0 or BSD)
>
> License breakdown is in the specfile.
>
> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQWC4L7UKBVWSCSL33WM5P5QN6HTZB2U/



-- 
Jun Aruga jar...@redhat.com
IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno,
Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ONCVQOWEI7CMHT4CHMCCZXZGADM3HWMW/

Re: Intent to retire python-svgwrite

[Julien Enselme]

It seems I cannot find you on 
https://src.fedoraproject.org/rpms/python-svgwrite/settings

Do you have an account and are you a packager?
-- 
Julien Enselme
http://www.jujens.eu/

On Tue, 2018-07-31 at 10:30 -0400, Robert Brown wrote:
> Thanks! It gives me something productive to do.
> 
> Fedora username is brown2rl
> 
> On Tue, Jul 31, 2018, 4:04 AM Julien Enselme 
> wrote:
> > I'll gladly give you access. What is your fedora username?
> > 
> > The repo: https://src.fedoraproject.org/rpms/python-svgwrite/
> > The bugs on bugzilla: 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1605936
> > 
> > PS: I made a mistake in the package name. The name is python-
> > svgwrite,
> > not just python-svg. Sorry about that.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3W4POTBGGQQPWX6CLD7J73Q4UDEWOGG/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YM624HFTIS7LKKMCDEAEQT66FV5YOQXE/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-HTTP-Tiny-0.074-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-58a4436322

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CVXFMOAB3GYXRXGUVBYK2SQFTRE4ZP72/

Re: Making Fedora secure - Package exit policy for security

[Daniel P . Berrangé]

On Tue, Jul 31, 2018 at 10:03:16AM -0500, Rex Dieter wrote:
> Huzaifa Sidhpurwala wrote:
> 
> > Hi All,
> > 
> > I was asked to bring this issue[1] to the developer community before
> > FESCO makes a decision.
> > 
> > In several instances[2] there exists packages in Fedora, in which
> > package-maintainers did not patch security issues, for multiple reasons
> > including 1. non-responsive maintainer 2. issue hard to patch 3. no one
> > cares?
> > 
> > This is a risk for the distribution, our users and community as a whole
> > and not to mentioned bad PR :)
> > 
> > I would like to propose the following:
> > 
> > 
> > 1. If a CRITICAL or IMPORTANT security issue is open against a package
> > in Fedora-X and by the time X is EOL and the issue is not addressed,
> > proactively remove the package from X+1
> > 2. If a MODERATE or LOW security issue is open against a package in
> > Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> > it from X+2
> 
> I don't think this is practical, we'll lose half the distro (are at least 
> large chunks).

Do we have any analysis showing what would be the fallout if we applied
these purge rules today ? ie what packages would be dropped today due
to unaddressed CVEs.

Then, from that list of packages, do we have idea of reasons why
their CVEs are not getting fixed in Fedora. This could perhaps identify
changes to help with the problem(s), rather than jumping straight to
the big stick of dropping packages.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z2R2ZXJK3QHOIPAM3KMRFJLR4AK34J6T/

Re: orphaning/retiring some packages

[Miro Hrončok]

On 31.7.2018 16:41, Matthias Runge wrote:

Hello,

I'm intending to either orphan or better retire the following
packages.

python-wordpress-xmlrpc
python-mozbase
pymunin
feedstail



If you retire some that run on Python 3, please make a note at 
https://bugzilla.redhat.com/show_bug.cgi?id=1610422


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5REMZBP67IMBDBNZGEHLHT6REDGZ6E5W/

Re: Making Fedora secure - Package exit policy for security

[Rex Dieter]

Huzaifa Sidhpurwala wrote:

> Hi All,
> 
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
> 
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no one
> cares?
> 
> This is a risk for the distribution, our users and community as a whole
> and not to mentioned bad PR :)
> 
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> it from X+2

I don't think this is practical, we'll lose half the distro (are at least 
large chunks).

Initially, such a proposal may be possible if generally limited to leaf 
packages.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2PXSOOOPRNXIBHFUC2RHJFMVGDC6INZI/

Re: [CoreOS] Re: [atomic-devel] Re: Starting a Container SIG

[Sanja Bonic]

The Containers SIG is fairly broad. People who want to talk about
application containers and also work on development with us might find it
easier to discuss on Discourse and then be asked to file an issue on Pagure
rather than having to go full on IRC/ML/Pagure. Pagure is already a
learning curve since it's unfamiliar to everyone who isn't familiar with
Fedora.

This SIG isn't heavy on kernel and OS development and therefore might be a
good entry point for beginners as well. Asking people to go to mailing
lists and IRC might not be the best way to have some fresh breeze community
engagement. A Containers SIG is a great way to gather developers' interest
outside of the usual Fedora world which hopefully leads to some interest in
Fedora as well, especially since they'd already be on the forums and be
able to explore other stuff they might be interested in.

On Tue, Jul 31, 2018 at 2:23 PM, Dusty Mabe  wrote:

>
>
> On 07/31/2018 08:29 AM, Clement Verna wrote:
> > On Tue, 31 Jul 2018 at 13:38, Sanja Bonic  wrote:
> >>
> >> For search and threaded visibility, it would be useful to have these
> discussions happen on the forums (created a category, let's see if we use
> it: https://discussion.fedoraproject.org/c/containers) and then be put
> into the issue tracker on Pagure where applicable.
> >>
> >> Since both Pagure and Discourse work with FAS, noone needs to create
> any extra accounts. I'm up for it, let's see what we end up using. If we do
> want some engagement within Fedora from outside the world of people who
> know how to handle mailing lists, this is a good way to start. I have to
> just remind everyone here that there are plenty of smart people willing to
> get started with open source who have no experience with mailing lists and
> IRC, where a forum with usability and structure really provides some
> initial help that shouldn't be underestimated.
> >>
> >
> >  I added https://discussion.fedoraproject.org/c/containers to the wiki
> > page. I am happy to use it instead of the mailing list :)
> >
> >
> >> On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller <
> mat...@fedoraproject.org> wrote:
> >>>
> >>> On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
>  Container story great in Fedora. If there is a good response, I will
>  create a Container SIG wiki page, and I guess we can ask for
>  container-devel mailing list for SIG discussions.
> >>>
> >>> What about trying https://discussion.fedoraproject.org/ for
> discussions
> >>> instead of a new mailing list?
>
> My personal opinion: mailing list/pagure tracker would be more for
> development
> discussions and announcements and discourse would be more for user
> questions.
>
> Dusty
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HEIQSLS665IK3EG5PL2PEJSEGHFVWQPP/

Re: dnf history - change in how rpmdb checksum is computed

[Tomasz Torcz]

On Tue, Jul 31, 2018 at 09:06:13AM +0200, Michael Mraka wrote:
> > 
> > Is there a reason why we can't change YUM to match the DNF behavior?
> > IMO, the YUM behavior is nonsense and isn't even a valid package
> > identifier.
> 
> Actually E:N-V-R.A is yum-ism no one else understand
> while N-E:V-R.A is correct rpm format.
> 
> So if you want make world a better place stick with current dnf format.

  I think this, with the combination of earlier suggestion, is the
best solution for Fedora. So:
1) make yum calculate checksum primarly with DNF format
2) when there's a discrepancy, let yum calculate csum in legacy yum format

 This way:
 - dnf is not bothered
 - users of yum have continuous history
 - new yum users have checksum calculated in better way

 Win-win!

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TT3ZVQBBJGQGQYIVOWBC7L6Y2D5WCF4J/

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

On Tue, Jul 31, 2018 at 3:40 PM Michal Novotny  wrote:

> On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson  wrote:
>
>> This simply is not true.
>>
>> Whatever "rpm format" means, historically RPM itself has always gone to
>> some lengths not to expose E: to users to simplify the endless fog of
>> dependency hell clutter.
>>
>
> Yeah, something which is eluding my understanding.
>
> This will be all off-topic by me again but I think it might be worth to be
> mentioned at least...
>
> Given that epoch plays an important role in version comparison (therefore
> during package upgrades), it should be visible in rpm names.
>
> E.g.
>
> $ rpm -q bind-libs
>
> should return:
>
> bind-libs-32:9.11.3-6.fc28.x86_64
>
> on my system.
>
> It should be clear directly from package name why e.g.:
>
> bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64
>
> Hiding the epoch does not serve any purpose here (or anywhere). Epoch
> number is something that should be explicitly present in package name so
> that
> users know what's going on when they can't update a package.
>
> Of course, ideally epoch should stay zero if possible and only be used as
> a "safety mechanism" when upstream does something unexpected but even if
> epoch is zero,
> it should still be put into rpm name.
>
> This is very remotely related to:
> https://github.com/rpm-software-management/rpm/issues/450
>
> clime
>
> P.S.: note that if Epoch: tag is missing in a spec file, it should be
> assumed epoch = 0. I think the behavior I am describing is quite natural,
> that's why I am using the word "should".
>

Sorry for the tone in this sentence. I just think rpm is a bit needlessly
"bent" in these areas.

clime


>
> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E2IUSM4JGEEE7ZJ34B3FBCOT5PHRUQ2P/

orphaning/retiring some packages

[Matthias Runge]

Hello,

I'm intending to either orphan or better retire the following
packages.

python-wordpress-xmlrpc
python-mozbase
pymunin
feedstail

All of them can be considered dead upstream, and haven't seen
a release for loong time.

Takers? Otherwise I'll retire them in a week.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PYXX52VQLHJFFJKQNQ4KQNYUDX2OKLZA/

Re: Intent to retire python-svgwrite

[Robert Brown]

Thanks! It gives me something productive to do.

Fedora username is brown2rl

On Tue, Jul 31, 2018, 4:04 AM Julien Enselme  wrote:

> I'll gladly give you access. What is your fedora username?
>
> The repo: https://src.fedoraproject.org/rpms/python-svgwrite/
> The bugs on bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1605936
>
> PS: I made a mistake in the package name. The name is python-svgwrite,
> not just python-svg. Sorry about that.
> --
> Julien Enselme
> http://www.jujens.eu/
>
> On Mon, 2018-07-30 at 19:45 -0400, Robert Brown wrote:
> > Julien,
> >
> > I'd be happy to take some ownership.  Any info?
> >
> > Thanks
> >
> > On Mon, Jul 30, 2018, 4:15 PM Julien Enselme 
> > wrote:
> > > Hi all,
> > >
> > > I intend to retire python-svg. Tests are failing on Python 3.7 for
> > > a
> > > reason I cannot figure, there was no commit during the last year
> > > and
> > > according to `repoquery --whatrequires python2-svgwrite` and
> > > `repoquery
> > > --whatrequires python3-svgwrite` nothing uses it anymore.
> > >
> > > If you want to maintain it, please step up.
> > >
> > > Regards,
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TBHUZPFPGTYIDE3U6JPNSWZUXR7KRU3H/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O6LPAI2IW5LB2NPBWD5KNQJZX3AZXBQU/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3W4POTBGGQQPWX6CLD7J73Q4UDEWOGG/

plexus-containers license correction

[Michael Šimáček]

plexus-containers package license tag has been corrected from:
ASL 2.0 and MIT
to:
ASL 2.0 and MIT and xpp

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F77RD2C5RB3MUFQVPEAFCCRQ65M22S4G/

python-pip license changed (and clarified)

[Miro Hrončok]

python-pip 9.0.x had MIT as License (bundled deps were not mentioned)

python-pip 18.0 now has more enjoyable:

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


License breakdown is in the specfile.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQWC4L7UKBVWSCSL33WM5P5QN6HTZB2U/

HEADS UP: pip upgraded from 9 to 18 (rawhide only)

[Miro Hrončok]

I've just built python-pip-18.0-1.fc29.

It has a lot of breaking changes, so please file bugs if you have 
problems. We do not plan to upgrade pip in stable Fedora releases.


Release notes: https://pip.pypa.io/en/stable/news/

See notes for 18 and 10, as we skipped 10.

Note that upstream changed version scheme, nothing existed between 10 
and 18.


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/S7FE45Y76MBIXU7QE75FTZSPEPLIIWOH/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S7FE45Y76MBIXU7QE75FTZSPEPLIIWOH/

HEADS UP: pip upgraded from 9 to 18 (rawhide only)

[Miro Hrončok]

I've just built python-pip-18.0-1.fc29.

It has a lot of breaking changes, so please file bugs if you have 
problems. We do not plan to upgrade pip in stable Fedora releases.


Release notes: https://pip.pypa.io/en/stable/news/

See notes for 18 and 10, as we skipped 10.

Note that upstream changed version scheme, nothing existed between 10 
and 18.


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/S7FE45Y76MBIXU7QE75FTZSPEPLIIWOH/

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson  wrote:

> This simply is not true.
>
> Whatever "rpm format" means, historically RPM itself has always gone to
> some lengths not to expose E: to users to simplify the endless fog of
> dependency hell clutter.
>

Yeah, something which is eluding my understanding.

This will be all off-topic by me again but I think it might be worth to be
mentioned at least...

Given that epoch plays an important role in version comparison (therefore
during package upgrades), it should be visible in rpm names.

E.g.

$ rpm -q bind-libs

should return:

bind-libs-32:9.11.3-6.fc28.x86_64

on my system.

It should be clear directly from package name why e.g.:

bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64

Hiding the epoch does not serve any purpose here (or anywhere). Epoch
number is something that should be explicitly present in package name so
that
users know what's going on when they can't update a package.

Of course, ideally epoch should stay zero if possible and only be used as a
"safety mechanism" when upstream does something unexpected but even if
epoch is zero,
it should still be put into rpm name.

This is very remotely related to:
https://github.com/rpm-software-management/rpm/issues/450

clime

P.S.: note that if Epoch: tag is missing in a spec file, it should be
assumed epoch = 0. I think the behavior I am describing is quite natural,
that's why I am using the word "should".

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZTTRZEKH6KXH324OHN5Y44AUZU5RSHA/

Re: [CoreOS] Re: [atomic-devel] Re: Starting a Container SIG

[Dusty Mabe]

On 07/31/2018 08:29 AM, Clement Verna wrote:
> On Tue, 31 Jul 2018 at 13:38, Sanja Bonic  wrote:
>>
>> For search and threaded visibility, it would be useful to have these 
>> discussions happen on the forums (created a category, let's see if we use 
>> it: https://discussion.fedoraproject.org/c/containers) and then be put into 
>> the issue tracker on Pagure where applicable.
>>
>> Since both Pagure and Discourse work with FAS, noone needs to create any 
>> extra accounts. I'm up for it, let's see what we end up using. If we do want 
>> some engagement within Fedora from outside the world of people who know how 
>> to handle mailing lists, this is a good way to start. I have to just remind 
>> everyone here that there are plenty of smart people willing to get started 
>> with open source who have no experience with mailing lists and IRC, where a 
>> forum with usability and structure really provides some initial help that 
>> shouldn't be underestimated.
>>
> 
>  I added https://discussion.fedoraproject.org/c/containers to the wiki
> page. I am happy to use it instead of the mailing list :)
> 
> 
>> On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller  
>> wrote:
>>>
>>> On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
 Container story great in Fedora. If there is a good response, I will
 create a Container SIG wiki page, and I guess we can ask for
 container-devel mailing list for SIG discussions.
>>>
>>> What about trying https://discussion.fedoraproject.org/ for discussions
>>> instead of a new mailing list?

My personal opinion: mailing list/pagure tracker would be more for development
discussions and announcements and discourse would be more for user questions.

Dusty

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7SKJCNTLZ7M5L7WYVEKTW2YV7ZOXHKGO/

RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

Hello devel list,

this is a request for comments for a recent proposal I filed at releng
tracker:
https://pagure.io/releng/issue/7445

In short, package managers on Rawhide would no longer replace $releasever
variable with a numerical value (like '29' at this moment, soon '30'), but
with 'rawhide' string instead. I hope this change will make life a bit
easier for third-party repos maintainers, for users, for developers and
sysadmins, and for release engineering. The technical implementation can be
seen in the ticket (it's the 'Proposed solution 1'), together with a long
discussion.

To provide a longer explanation of the improvements I expect this to bring:
* Third-party repo maintainers will no longer need to provide two different
repo files, one for stable Fedora releases using $releasever in URLs, and
one for Rawhide hardcoding 'rawhide/' in URL and avoiding $releasever in
URL. (Technically, two repo files are not needed if you always use a
numbered dir even for Rawhide, but that's maintenance-heavy, because you
need to change the directory number precisely at Branching time). This
involves COPR as well.
* Users will be able to run commands like "dnf ... --releasever=28" even on
Rawhide. That doesn't work at the moment, because most repo files don't use
$releasever and instead have 'rawhide/' hardcoded.
* Developers and sysadmins will be able to use the same approach regarding
repositories for stable Fedora releases and Rawhide. Rawhide will no longer
be different, requiring special treatment. For example, the same repo URL
can be used to install a system, or the same URL can be used to add an
additional repository to an existing system. As an engineer working on
automation, I was always annoyed how I need to special-case Rawhide
everywhere (and of course, maintain a config file that states which release
number Rawhide currently maps to). That will hopefully be no longer
necessary, or very much reduced.
* Fedora release engineers should be able to get rid of
fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the
standard repo files instead (making use of $releasever).

There might be other advantages, which I haven't tested or though of.

There are also disadvantages. The only one I know of at this moment, is
that PackageKit is currently incompatible with this change (it uses custom
logic for populating $releasever, different from dnf logic) and will need
adjustments.

Fedora releng has pre-approved this change in the ticket, and the point of
this email is to ask for more feedback from all of you. I'd appreciate if
you could help us identify edge cases we haven't thought of, or point out
which tools would be incompatible with this change, so that we can track
them and discuss it with their developers.

Thanks,
Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/

Re: [atomic-devel] [CoreOS] Re: Starting a Container SIG

[Clement Verna]

On Tue, 31 Jul 2018 at 13:38, Sanja Bonic  wrote:
>
> For search and threaded visibility, it would be useful to have these 
> discussions happen on the forums (created a category, let's see if we use it: 
> https://discussion.fedoraproject.org/c/containers) and then be put into the 
> issue tracker on Pagure where applicable.
>
> Since both Pagure and Discourse work with FAS, noone needs to create any 
> extra accounts. I'm up for it, let's see what we end up using. If we do want 
> some engagement within Fedora from outside the world of people who know how 
> to handle mailing lists, this is a good way to start. I have to just remind 
> everyone here that there are plenty of smart people willing to get started 
> with open source who have no experience with mailing lists and IRC, where a 
> forum with usability and structure really provides some initial help that 
> shouldn't be underestimated.
>

 I added https://discussion.fedoraproject.org/c/containers to the wiki
page. I am happy to use it instead of the mailing list :)


> On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller  
> wrote:
>>
>> On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
>> > Container story great in Fedora. If there is a good response, I will
>> > create a Container SIG wiki page, and I guess we can ask for
>> > container-devel mailing list for SIG discussions.
>>
>> What about trying https://discussion.fedoraproject.org/ for discussions
>> instead of a new mailing list?
>>
>> --
>> Matthew Miller
>> 
>> Fedora Project Leader
>> ___
>> CoreOS mailing list -- cor...@lists.fedoraproject.org
>> To unsubscribe send an email to coreos-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/message/5Y3YRMQMXV7CRSOWGADCJWNUJ3G26GTB/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7WIP3FLUVADHITCCDKKIPFFT5PVJ77H2/

scala license correction

[Michael Šimáček]

scala package license tag has been corrected from:
BSD
to:
BSD and CC0 and Public Domain

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5GZUFNEBJAJZOEULCK5KLUUUGN7DWDTA/

Re: [CoreOS] Re: Starting a Container SIG

[Chuck Anderson]

Doesn't HyperKitty provide the forum experience integrated with the traditional 
mailing list?

On Tue, Jul 31, 2018 at 12:37:50PM +0100, Sanja Bonic wrote:
> For search and threaded visibility, it would be useful to have these
> discussions happen on the forums (created a category, let's see if we use
> it: https://discussion.fedoraproject.org/c/containers) and then be put into
> the issue tracker on Pagure where applicable.
> 
> Since both Pagure and Discourse work with FAS, noone needs to create any
> extra accounts. I'm up for it, let's see what we end up using. If we do
> want some engagement within Fedora from outside the world of people who
> know how to handle mailing lists, this is a good way to start. I have to
> just remind everyone here that there are plenty of smart people willing to
> get started with open source who have no experience with mailing lists and
> IRC, where a forum with usability and structure really provides some
> initial help that shouldn't be underestimated.
> 
> On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller 
> wrote:
> 
> > On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
> > > Container story great in Fedora. If there is a good response, I will
> > > create a Container SIG wiki page, and I guess we can ask for
> > > container-devel mailing list for SIG discussions.
> >
> > What about trying https://discussion.fedoraproject.org/ for discussions
> > instead of a new mailing list?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HAFFCI74D2LMC2HI5YBNHLKKJII5FVA5/

Re: Making Fedora secure - Package exit policy for security

[Daniel P . Berrangé]

On Tue, Jul 31, 2018 at 09:09:58AM +0530, Huzaifa Sidhpurwala wrote:
> Hi All,
> 
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
> 
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no one
> cares?
> 
> This is a risk for the distribution, our users and community as a whole
> and not to mentioned bad PR :)
> 
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> it from X+2

What do you mean by 'issue is not addressed' here ?  Hopefully it is still
valid to simply close the issues as WONTFIX or NOTABUG. IMHO for some low
or even moderate severity issues it is often wiser to simply wait till next
major Fedora release to pick up a rebased upstream release, rather than do
a hairy backport which can risk creating as many problems as it solves.
This would imply closing Fedora X as WONTFIX, while Fedora X+2 gets a fix
still due to rebased version.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3KJEWYZT2KSRCNTM2XHVZRS3XOMDIGCH/

Re: dnf history - change in how rpmdb checksum is computed

[Michael Mraka]

Jeff Johnson:
> This simply is not true.

What is not true? Could you please include sentence you are referring to?

> Whatever "rpm format" means, historically RPM itself has always gone to some 
> lengths not to expose E: to users to simplify the endless fog of dependency 
> hell clutter.

Rpm does not print epoch in in standard --query output only in --info mode.

  $ rpm -q bind-libs
  bind-libs-9.9.4-61.el7.x86_64
  $ rpm -qi bind-libs
  Name: bind-libs
  Epoch   : 32
  Version : 9.9.4
  Release : 61.el7
  Architecture: x86_64
  ...

It understands N-V-R.A or N-E:V-R.A as an argument but not E:N-V-R.A.

  $ rpm -q bind-libs-9.9.4-61.el7.x86_64 bind-libs-32:9.9.4-61.el7.x86_64 
32:bind-libs-9.9.4-61.el7.x86_64
  bind-libs-9.9.4-61.el7.x86_64
  bind-libs-9.9.4-61.el7.x86_64
  package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed


--
Michael Mráka
System Management Engineering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4LNMWBXTPGWDYQCE2LJIVG6QCPDUH6FL/

Re: [CoreOS] Re: Starting a Container SIG

[Sanja Bonic]

For search and threaded visibility, it would be useful to have these
discussions happen on the forums (created a category, let's see if we use
it: https://discussion.fedoraproject.org/c/containers) and then be put into
the issue tracker on Pagure where applicable.

Since both Pagure and Discourse work with FAS, noone needs to create any
extra accounts. I'm up for it, let's see what we end up using. If we do
want some engagement within Fedora from outside the world of people who
know how to handle mailing lists, this is a good way to start. I have to
just remind everyone here that there are plenty of smart people willing to
get started with open source who have no experience with mailing lists and
IRC, where a forum with usability and structure really provides some
initial help that shouldn't be underestimated.

On Tue, Jul 31, 2018 at 10:59 AM, Matthew Miller 
wrote:

> On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
> > Container story great in Fedora. If there is a good response, I will
> > create a Container SIG wiki page, and I guess we can ask for
> > container-devel mailing list for SIG discussions.
>
> What about trying https://discussion.fedoraproject.org/ for discussions
> instead of a new mailing list?
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> CoreOS mailing list -- cor...@lists.fedoraproject.org
> To unsubscribe send an email to coreos-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/coreos@
> lists.fedoraproject.org/message/5Y3YRMQMXV7CRSOWGADCJWNUJ3G26GTB/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YWWPNYECHHOMZWQ2BEP5W6ZBEJNDLWS6/

Re: Making Fedora secure - Package exit policy for security

[Ondřej Lysoněk]

On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote:
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> it from X+2
> 
> Note:
> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro
> 2. X/X+1 is the best boundary to remove the insecure packages imo, since
> inbetween removals are not possible due to the way mirrors work.
> 3. Maintain a list somewhere (automated maybe) of the list of packages
> removed and why.
> 4. Have a list of critical pkg, which cannot be removed which will break
> the distro.
Please make sure the process takes into account the fact that packages
may be affected by CVEs in certain Fedora releases only. For example an
older version of a package in F27 is affected by a CVE, but a new
(rewritten) version in F28 is not. It seems the summary of CVE bugs
accordingly contains either the string "[fedora-all]", or "[fedora-27]",
"[fedora-28]" etc. Hopefully that is a reliable source of information.

Best regards
Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JXQVT55SMOKIMYT6T5BX3CDAXORNQLLG/

Re: dnf history - change in how rpmdb checksum is computed

[Jeff Johnson]

This simply is not true.

Whatever "rpm format" means, historically RPM itself has always gone to some 
lengths not to expose E: to users to simplify the endless fog of dependency 
hell clutter.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/

Re: Making Fedora secure - Package exit policy for security

[Jeff Johnson]

Don't rely on MODERATE or LOW distinctions to drop a package in FX+2.

Just drop all unfixed packages with the same policy.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EOQ3DJKOMBGUHDQ66XTL43RZCSV4MAFN/

Re: Making Fedora secure - Package exit policy for security

[Pavel Zhukov]

Huzaifa Sidhpurwala  writes:

> Hi All,
>
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
>
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no one
> cares?
>
> This is a risk for the distribution, our users and community as a whole
> and not to mentioned bad PR :)
>
> I would like to propose the following:
>
>
> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
By the time FX is EOL'ed it's too late even for FX+2 to drop the
package. Besides of that CVE could be fixed in FX+2 but not fixed in FX
so the logic should be a way more complex.
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> it from X+2
Same here. 
>
> Note:
> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro
> 2. X/X+1 is the best boundary to remove the insecure packages imo, since
> inbetween removals are not possible due to the way mirrors work.
> 3. Maintain a list somewhere (automated maybe) of the list of packages
> removed and why.
> 4. Have a list of critical pkg, which cannot be removed which will break
> the distro.
>
> The above is not set in stone, but is open for discussion. Let me know
> what you guys think!
>
> In the end, i would like you leave you all with this parting link:
> https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/
>
> [1] https://pagure.io/fesco/issue/1935
> [2]
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UPOUU56BRMLWIIUJB3V5WHV6FZKUP2YW/

Re: binutils 2.31.1-4.fc29 - 2.31.1-7.fc29 produces broken ELF binaries

[Florian Weimer]

On 07/31/2018 10:41 AM, Hans de Goede wrote:

Hi All,

This is a heads up about a bug which I hit Sunday, if you're
seeing any weird crashes with recently build packages then
this may very well be the cause.

I've filed a ticket with rel-eng to get affected packages
automatically rebuild:

https://pagure.io/releng/issue/7670


I'm attaching a list of affected packages in the Fedora rawhide 
buildroot, as of 2018-07-31 10:00.  This is based on ELF files which 
have a .gnu.build.attributes section (which is not allocated) between 
two allocated sections.  (The rawhide compose lags behind and has a 
different set of affected packages.)  Some of the affected packages are 
being rebuild, and I will schedule builds for the remaining ones.


This phenomenon is actually much older and may also have affected 
packages in the libqb/pacemaker context, but the impact there seems to 
have been limited.


Thanks,
Florian
booth-1.0-3.f2d38ce.git.fc29
c++-gtk-utils-2.0.16-13.fc29
coin-or-Bcps-0.94.4-7.fc29
coin-or-Blis-0.94.4-7.fc29
coin-or-Cbc-2.9.8-8.fc29
coin-or-Cgl-0.59.9-7.fc29
coin-or-CoinMP-1.8.3-6.fc29
coin-or-Dip-0.92.2-7.fc29
coin-or-DyLP-1.10.3-6.fc29
coin-or-Osi-0.107.8-7.fc29
coin-or-SYMPHONY-5.6.14-7.fc29
coin-or-Vol-1.5.3-7.fc29
cone-0.96.2-4.fc29
corosync-2.99.3-2.fc29
corosync-qdevice-2.91.0-2.fc29
crack-attack-1.1.14-38.fc29
cronolog-1.6.2-25.fc29
cube-4.4-3.fc29
dd2-0.2.2-21.fc29
ddd-3.3.12-29.fc29
deepin-api-3.1.20-2.fc29
deepin-gir-generator-1.0.2-3.fc29
dep-0.4.1-3.fc29
devtodo-0.1.20-23.fc29
dhcpcd-6.11.3-6.fc29
douceur-0.2.0-4.fc29
dreamchess-0.3.0-0.2.20180601git.fc29
dreamchess-tools-0-0.7.20141101gitf8f32aa.fc29
dtkcore-2.0.9-2.fc29
dumb-0.9.3-27.fc29
ecryptfs-utils-111-13.fc29
ember-0.7.2-24.fc29
entangle-1.0-6.fc29
eris-1.3.23-13.fc29
erlang-20.3.8.3-1.fc29
erlang-cache_tab-1.0.14-1.fc29
erlang-eimp-1.0.6-1.fc29
erlang-esip-1.0.24-1.fc29
erlang-fast_tls-1.0.23-1.fc29
erlang-fast_xml-1.1.32-1.fc29
erlang-fast_yaml-1.0.15-1.fc29
erlang-iconv-1.0.8-1.fc29
erlang-stringprep-1.0.12-1.fc29
erlang-xmpp-1.2.2-1.fc29
espresso-ab-1.0-16.fc29
festival-1.96-38.fc29
file-roller-3.28.1-1.fc29
firewalk-5.0-20.fc29
flannel-0.9.0-3.fc29
flatpak-builder-0.99.3-2.fc29
fluxbox-1.3.7-5.fc29
folks-0.11.4-7.fc29
foo2zjs-0.20170412-8.fc29
freenx-server-0.7.3-43.fc29
frepple-3.1-10.fc29
frogr-1.4-2.fc29
funguloids-1.06-30.fc29
gdl-0.9.8-4.fc29.20180723gitf3b6e01
gimp-focusblur-plugin-3.2.6-6.fc29
git-lfs-2.4.1-2.fc29
glaxium-0.5-29.fc29
glib-networking-2.56.1-2.fc29
glide-0.13.1-2.fc29
gnome-builder-3.28.4-1.fc29
gnome-disk-utility-3.28.3-2.fc29
gnome-font-viewer-3.28.0-2.fc29
gnome-settings-daemon-3.28.1-2.fc29
go-bindata-3.0.7-13.gita0ff256.fc29
go-i18n-1.10.0-4.fc29
godotenv-1.2.0-2.fc29
gofed-1.0.0-0.20.rc1.fc29
golang-github-cpuguy83-go-md2man-1.0.7-7.20180307git1d903dc.fc29
golang-github-mholt-archiver-2.0-2.fc29
golang-github-ulikunitz-xz-0.5.4-2.fc29
golang-googlecode-gogoprotobuf-0.4-0.7.20180307git100ba4e.fc29
golang-googlecode-gomock-0-0.14.20180326git58cd061.fc29
golint-0-0.8.gitc7bacac.fc29
gotun-0-0.5.gita9dbe4d.fc29
grilo-plugins-0.3.7-3.fc29
grive2-0.5.0-16.20171122git84c57c1.fc29
gsignond-1.1.0-2.fc29
gst-entrans-1.2.2-1.fc29
heketi-7.0.0-2.fc29
ibus-hangul-1.5.1-1.fc29
imake-1.0.7-14.fc29
indi-aagcloudwatcher-1.7.4-1.fc29
indi-apogee-1.7.4-1.fc29
indi-eqmod-1.7.4-1.fc29
indi-gphoto-1.7.4-1.fc29
indi-sx-1.7.4-1.fc29
kf5-modemmanager-qt-5.48.0-3.fc29
kismet-0.0.2016.07.R1-7.fc29
kstars-2.9.7-1.fc29
lcms-1.19-24.fc29
lhapdf-6.2.1-3.fc29
libdazzle-3.28.5-1.fc29
libgsystem-2015.2-7.fc29
libhid-0.2.17-32.fc29
libijs-0.35-7.fc29
libindi-1.7.4-1.fc29
libkcapi-1.1.1-9.fc29
libkolabxml-1.1.6-5.fc29
liblouis-3.6.0-3.fc29
libmobi-0.4-1.fc29
libpwquality-1.4.0-9.fc29
libqb-1.0.3-5.fc29
libreoffice-6.0.6.1-6.fc29
librtfcomp-1.1-25.fc29
libunistring-0.9.10-3.fc29
libwfut-0.2.3-15.fc29
libxkbcommon-0.8.0-5.fc29
lilv-0.24.4-1.fc29
lsyncd-2.2.2-5.fc29
luminance-hdr-2.5.1-14.fc29
mame-0.200-2.fc29
matrix-structs-0.1.0-6.20180714git8de04af.fc29
mtxclient-0.1.0-7.20180726gitca66424.fc29
nheko-0.5.2-1.fc29
nm-tray-0.4.1-4.fc29
ocitools-0-0.7.git506e7db.fc29
octave-netcdf-1.0.12-1.fc29
octave-signal-1.4.0-3.fc29
pacemaker-2.0.0-1.fc29.1
petsc-3.9.3-1.fc29
petsc4py-3.9.1-1.fc29
picard-1.4.2-4.fc29
pinfo-0.6.10-19.fc29
pkgconf-1.5.3-1.fc29
pseudo-1.9.0-5.fc29
purple-mattermost-1.2-2.fc29
pygoocanvas-0.14.1-23.fc29
pyparted-3.11.0-16.fc29
python-PyMuPDF-1.13.15-1.fc29
python-blist-1.3.6-17.fc29
python-evdev-1.0.0-1.fc29
python-gtkextra-1.1.0-34.fc29
python-pivy-0.5.0-20.hg609.fc29
python-pymongo-3.7.1-1.fc29
python-pyopencl-2018.1.1-1.fc29
python-pysctp-0.6-17.fc29
python-pyside-1.2.4-6.fc29
python-rasterio-1.0.2-1.fc29
python-thriftpy-0.3.9-7.fc29
recoll-1.23.7-6.fc29
restic-0.9.1-2.fc29
ruby-2.5.1-95.fc29
rubygem-rugged-0.26.0-8.fc29
rust-gcsf-0.1.16-1.fc29
rust-ripgrep-0.8.1-9.fc29
rust-varlink-cli-2.0.0-1.fc29
sbd-1.2.1-4.fc28.1
seamonkey-2.49.4-1.fc29
sirikali-1.3.4-2.fc29

Re: Starting a Container SIG

[Matthew Miller]

On Wed, Jul 25, 2018 at 07:09:39PM +0200, Clement Verna wrote:
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.

What about trying https://discussion.fedoraproject.org/ for discussions
instead of a new mailing list?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5Y3YRMQMXV7CRSOWGADCJWNUJ3G26GTB/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-HTTP-Tiny-0.074-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-58a4436322

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/63OFZTU2S4BRYSBFK5X437YBZUJ6KQKU/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-HTTP-Tiny-0.074-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-25a251c107

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/XRZ7EE3YNEDWOZVK67XS47S5IZHQAFEK/

[Bug 1610065] perl-HTTP-Tiny-0.074 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-HTTP-Tiny-0.074-1.fc29



--- Comment #1 from Petr Pisar  ---
An enhancement 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BMBZZZVFRFTWTDUVE67F4AXG36UNFY3J/

binutils 2.31.1-4.fc29 - 2.31.1-7.fc29 produces broken ELF binaries

[Hans de Goede]

Hi All,

This is a heads up about a bug which I hit Sunday, if you're
seeing any weird crashes with recently build packages then
this may very well be the cause.

I've filed a ticket with rel-eng to get affected packages
automatically rebuild:

https://pagure.io/releng/issue/7670

Here is the text of the ticket for those of you looking for
more details:

"As discovered last Sunday and discussed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1609577

A bug was introduced in binutils starting with version binutils-2.31.1-4.fc29 
which causes it to put the sections in ELF binaries it produces in non 
incrementing order. This causes eu-strip to mangle the binary into a broken 
binary when eu-strip is ran on the ELF binary generated by 
binutils-2.31.1-4.fc29 or newer. This is a big problem since 
/usr/lib/rpm/find-debuginfo.sh runs eu-strip on all binaries.

The binutils bug causing this was fixed in binutils-2.31.1-8.fc29 which was 
build yesterday.

Since any binaries produced by binutils >= 2.31.1-4.fc29 && binutils < 2.31.1-8.fc29 
and then processed by eu-strip are (potentially) broken this means that all builds done with a 
binutils version of 2.31.1-4.fc29 - 2.31.1-7.fc29 need to be rebuild."

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5STOG6CETD5UVN5INQPL5XXC3MYKMW3W/

License tags of i2c-tools corrected

[Ondřej Lysoněk]

I reviewed the licensing of i2c-tools and found the License tags to be
inaccurate. I changed the tags as follows.

i2c-tools-eepromer subpackage:
License tag changed from
GPLv2+
to
GPLv2+ and Public Domain

python3-i2c-tools subpackage:
License tag changed from
GPLv2+
to
GPLv2

Best regards
Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DJBOQODKASLQMKN5SFPCOEADBM52AGFX/

Re: Making Fedora secure - Package exit policy for security

[Matthias Runge]

On Tue, Jul 31, 2018 at 09:09:58AM +0530, Huzaifa Sidhpurwala wrote:
> Hi All,
> 
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
> 
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no one
> cares?
> 
> This is a risk for the distribution, our users and community as a whole
> and not to mentioned bad PR :)
> 
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> it from X+2
> 
> Note:
> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro
> 2. X/X+1 is the best boundary to remove the insecure packages imo, since
> inbetween removals are not possible due to the way mirrors work.
> 3. Maintain a list somewhere (automated maybe) of the list of packages
> removed and why.
> 4. Have a list of critical pkg, which cannot be removed which will break
> the distro.
> 
> The above is not set in stone, but is open for discussion. Let me know
> what you guys think!

Hello,

first of all, I really like a more formal approach. However:

what about an old version of package p in Fedora release X-1 with a CVE;
if upstream does not fix it, you'd be expecting to fix this by the
package maintainer; that'd require either backporting to an older
branch, or upgrading the package to a newer version, possibly breaking
packages being dependencies of pkg in an old (or at least released)
Fedora version. Not ideal :-/

> 
> In the end, i would like you leave you all with this parting link:
> https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/

This is a different issue. While we can not be sure this won't happen in
Fedora, I'd like to focus on one question/issue per thread.

Matthias

-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6CGHEU3PI4BW3Q46PHJNZNKCRPZ7H7A2/

Re: Intent to retire python-svgwrite

[Julien Enselme]

I'll gladly give you access. What is your fedora username?

The repo: https://src.fedoraproject.org/rpms/python-svgwrite/
The bugs on bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1605936

PS: I made a mistake in the package name. The name is python-svgwrite,
not just python-svg. Sorry about that.
-- 
Julien Enselme
http://www.jujens.eu/

On Mon, 2018-07-30 at 19:45 -0400, Robert Brown wrote:
> Julien,
> 
> I'd be happy to take some ownership.  Any info?
> 
> Thanks
> 
> On Mon, Jul 30, 2018, 4:15 PM Julien Enselme 
> wrote:
> > Hi all,
> > 
> > I intend to retire python-svg. Tests are failing on Python 3.7 for
> > a
> > reason I cannot figure, there was no commit during the last year
> > and
> > according to `repoquery --whatrequires python2-svgwrite` and
> > `repoquery
> > --whatrequires python3-svgwrite` nothing uses it anymore.
> > 
> > If you want to maintain it, please step up.
> > 
> > Regards,
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TBHUZPFPGTYIDE3U6JPNSWZUXR7KRU3H/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O6LPAI2IW5LB2NPBWD5KNQJZX3AZXBQU/

Re: dnf history - change in how rpmdb checksum is computed

[Michael Mraka]

Neal Gompa:
> > Regarding these two questions:
> >
> >>> Are there any concerns about such change?
> >>> I believe that >90% users wouldn't notice anything as it's related to the 
> >>> history database only.
> >
> >> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko 
> >>  wrote:
> >> Since we've changed the database entirely, what's the point of keeping 
> >> same algorithm for calculating checksum?
> >
> >> On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé  
> >> wrote:
> >> What's the benefit in changing to be compatible with YUM as opposed
> >> to stickin with current alogorithm ?
> >>
> >> Surely if we don't change it, even fewer users will notice that DNF's
> >> behaviour is different from YUM's, since DNF has been the default for
> >> many releases now.
> >>
> >> I could understand the motiviation to stay compatible with YUM if we
> >> were only just about to switch Fedora from YUM to DNF, but time is
> >> way in the past now. Shouldn't we optimize for the fact that DNF is
> >> the more widely deployed & used tool, and thus not worry about
> >> YUM compatibility in respect of the history DB ?
> >
> > It is true that going forward in the Fedora world it matters less.  It is 
> > more of an impact for yum-3 compatibility as yum4/dnf is being considered 
> > in the RHEL7/CentOS7 userspace environments as described at 
> > https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/
> >
> > Currently yum version 3 and what the proof-of-concept project is calling 
> > yum4 work very well together side by side.  Users can safely switch back 
> > and forth.  The major problem is yum/dnf histories being different and the 
> > rpmdb checksum difference is a blocker for resolving the history 
> > compatibility.
> >
> > So think of this as an effort to bring package management parity between 
> > Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead 
> > of them.
> >
> 
> Is there a reason why we can't change YUM to match the DNF behavior?
> IMO, the YUM behavior is nonsense and isn't even a valid package
> identifier.

Actually E:N-V-R.A is yum-ism no one else understand
while N-E:V-R.A is correct rpm format.

  $ rpm -q bind-libs
  bind-libs-9.9.4-61.el7.x86_64
  $ rpm -q 32:bind-libs-9.9.4-61.el7.x86_64
  package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed
  $ rpm -q bind-libs-32:9.9.4-61.el7.x86_64
  bind-libs-9.9.4-61.el7.x86_64

So if you want make world a better place stick with current dnf format.


--
Michael Mráka
System Management Engineering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXLUGD7446XWI4TS2ITKQ2JPUAGHEF5S/

Re: dokuwiki packagers unresponsive

[Matthias Runge]

On Mon, Jul 30, 2018 at 11:07:21PM +0200, Peter 'Pessoft' Kolínek wrote:
> I've already submitted a pull request for dokuwiki circa a month ago:
> https://src.fedoraproject.org/rpms/dokuwiki/pull-request/2
> Also for topdog's other package ike 10 days ago:
> https://src.fedoraproject.org/rpms/ike/pull-request/1
> 
> @Matthias, Sérgio: Do you know at which month approximately you had a
> response from topdog?
> On fedmsg I can see last entries invoked by topdog 11 months ago.

Ok, great!

Unfortunately, I don't remember anymore the time of contact. It has
probably been more than 12 months.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HNVZEANLZI5OHMS4VK3YYJCIZXL5UMW5/