Reliability test for hard drives and SSD

Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The

Re: Kernel marking files in /boot as %ghost

> What is the result you expect from this email? You filed a bug, it was closed because the packaging was done intentionally and there is no other solution when considering the original reasons for the change. I'm not sure if you want the original change reverted entirely or what you would like

Re: News in opencv package

On Sat, 2018-03-03 at 00:58 +0100, Till Hofmann wrote: > > On 03/02/2018 08:31 PM, Sérgio Basto wrote: > > On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: > > > On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > > > > > > > player will fail due a glibc problem > > > > > > Can

[Bug 1551174] New: perl-Test2-Suite-0.000102 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1551174 Bug ID: 1551174 Summary: perl-Test2-Suite-0.000102 is available Product: Fedora Version: rawhide Component: perl-Test2-Suite Keywords: FutureFeature, Triaged Assignee:

Re: News in opencv package

On 03/02/2018 08:31 PM, Sérgio Basto wrote: > On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: >> On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: >>> >>> player will fail due a glibc problem >> >> Can you elaborate? You've tried a build and it blew up? >> >> I am starting to get

Fedora 28-20180302.n.0 compose check report

Missing expected images: Atomic qcow2 x86_64 Atomic raw-xz x86_64 Failed openQA tests: 16/127 (x86_64), 7/24 (i386), 1/2 (arm) ID: 196778 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/196778 ID: 196791 Test: x86_64

Re: why do I keep getting Broken dependencies: nfs-ganesha emails

On 03/02/2018 12:48 PM, Kaleb S. KEITHLEY wrote: > > E.g.: > ... > On x86_64: > nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires > libntirpc.so.1.6(NTIRPC_1.6.0)(64bit) > ... > > > I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and > even nfs-ganesha-2.6.0-2 because I

Re: Re: Frequently broken Rawhide/Branched composes

On 03/02/2018 08:42 AM, Nicolas Mailhot wrote: > Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit : ...snip... >> That'd actually give us the opportunity to clean up more our repos no? >> :) > > Explain that to someone who had several hours/days of builds rejected > because of

Re: Why size of repositories metadata is too high in Fedora?

On Fri, Mar 2, 2018, at 3:29 PM, Andrew Lutomirski wrote: > I feel like that discussion is ignoring a third option: keep file deps > built preprocess the repo metadata to turn each file dep that is > uniquely satisfied by a single package into a direct dependency on > that package. This

why do I keep getting Broken dependencies: nfs-ganesha emails

E.g.: ... On x86_64: nfs-ganesha-2.6.0-0.4rc5.fc28.x86_64 requires libntirpc.so.1.6(NTIRPC_1.6.0)(64bit) ... I have long since built the GA packages: nfs-ganesha-2.6.0-1 in f28 and even nfs-ganesha-2.6.0-2 because I didn't notice that this was whining about -0.4rc5. Is something stuck

Re: BuildError: package PKGNAME not in list for tag f29-pending

On 03/02/2018 01:22 AM, Jan Chaloupka wrote: > Hi, > > anyone knows cause of the build error message? Getting the message for > 70 Go packages when building for rawhide. FYI, this was due to the new go macros treating everything as lower space, when these 70 packages had upper case in the name.

Re: Why size of repositories metadata is too high in Fedora?

> On Mar 2, 2018, at 6:42 AM, Matthew Miller wrote: > >> On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote: >> I don't know, I just ran "dnf upgrade" and it took metadata in >> mentioned size, Fedora developers should answer to these questions. > > A

Re: Frequently broken Rawhide/Branched composes

On 03/01/2018 07:40 PM, Kevin Kofler wrote: > And how do you propose doing that? The only reliable way to hold packages > that break the compose would be to actually try to run the whole compose > process after every package build. That just does not scale. The composes > are only daily for a

Re: News in opencv package

On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > > > player will fail due a glibc problem > > Can you elaborate? You've tried a build and it blew up? > > I am starting to get rather worried about this new glibc that landed >

Re: Why size of repositories metadata is too high in Fedora?

On Thu, 2018-03-01 at 18:44 -0700, stan wrote: > On Thu, 01 Mar 2018 14:29:45 - > "Farhad Mohammadi Majd" wrote: > > > Hello, in Debian (9, stable), size of all the official repositories > > metadata is maximum 10MB, while in Fedora, today I ran "dnf update" > > for

Re: News in opencv package

On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote: > > player will fail due a glibc problem Can you elaborate? You've tried a build and it blew up? I am starting to get rather worried about this new glibc that landed yesterday. I think it might be breaking several things. -- Adam

Re: Appstream metadata compose failures

On Fri, 2018-03-02 at 11:28 +0100, Kalev Lember wrote: > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if maintainers could have a look and see if they can > make their packages pass! Hi, even not a maintainer, why is evolution-rss in the list,

Re: News in opencv package

On Fri, 2018-03-02 at 10:29 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote: > > On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > > > > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > > > Hi folks, > > > > > > > > I would like to inform you,

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

The following Fedora EPEL 6 Security updates need testing: Age URL 962 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 852 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 823

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

The following Fedora EPEL 7 Security updates need testing: Age URL 1089 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 852 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 434

Re: News in opencv package

On Fri, 2018-03-02 at 10:05 -0800, Adam Williamson wrote: > On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > > Hi folks, > > > > > > I would like to inform you, that new version of opencv package (3.4.1) > > > will be available in

Re: News in opencv package

On Fri, 2018-03-02 at 16:51 +0100, Till Hofmann wrote: > > On 03/02/2018 12:24 PM, Josef Ridky wrote: > > Hi folks, > > > > I would like to inform you, that new version of opencv package (3.4.1) will > > be available in rawhide and Fedora 28. > > All packages, that requires opencv should be

Re: Why size of repositories metadata is too high in Fedora?

On Fri, Mar 2, 2018 at 12:40 PM, Neal Gompa wrote: > On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia wrote: >> On Thu, Mar 1, 2018 at 9:46 AM, chicago wrote: >>> Good question. What is in this 20+58MB? Is it all text? Does most of it

Re: Why size of repositories metadata is too high in Fedora?

On Fri, Mar 2, 2018 at 12:35 PM, Nico Kadel-Garcia wrote: > On Thu, Mar 1, 2018 at 9:46 AM, chicago wrote: >> Good question. What is in this 20+58MB? Is it all text? Does most of it it >> change infrequently?/Maybe we can diff it? > > Most of it is pretty

Re: Why size of repositories metadata is too high in Fedora?

On Thu, Mar 1, 2018 at 9:46 AM, chicago wrote: > Good question. What is in this 20+58MB? Is it all text? Does most of it it > change infrequently?/Maybe we can diff it? Most of it is pretty stable. But it's database-stored, and it's compressed. Both cause the overall files

[Bug 1550752] perl-Locale-Codes-3.56 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550752 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA

Re: Draft: Macros to tell what Python versions to package for

> "MH" == Miro Hrončok writes: MH> I expect it to be called for both 2 and 3 unconditionally. Hiding MH> the condition in the maro makes things too magical for me. I don't think that stance holds up well as we increasingly hide things in macros and will continue to hide

Summary/Minutes from today's FESCo Meeting (2018-03-02)

Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2018-03-02/fesco.2018-03-02-15.00.txt Log:

Re: Draft: Macros to tell what Python versions to package for

> "PV" == Petr Viktorin writes: PV> %install PV> %install PV> %if %{with python2} PV> %py2_install PV> %endif PV> %if %{with python3} PV> %py3_install PV> %endif So... why not just make %py2_install and %py3_install just do the %{with python*} internally, so the

Re: Re: Frequently broken Rawhide/Branched composes

Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit : > On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote: > > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > > > > > I disagree entirely with the above. I think the solution is to > > > gate > > >

Re: News in opencv package

On 03/02/2018 12:24 PM, Josef Ridky wrote: > Hi folks, > > I would like to inform you, that new version of opencv package (3.4.1) will > be available in rawhide and Fedora 28. > All packages, that requires opencv should be rebuild. > It would be nice if the announcement would have been made

Re: Why size of repositories metadata is too high in Fedora?

On Thu, 2018-03-01 at 14:46 +, chicago wrote: > Good question. What is in this 20+58MB? Is it all text? Does most of > it it change infrequently?/Maybe we can diff it? I don't know, I just ran "dnf upgrade" and it took metadata in mentioned size, Fedora developers should answer to these

Re: Draft: Macros to tell what Python versions to package for

On 2.3.2018 16:23, Richard W.M. Jones wrote: On Fri, Mar 02, 2018 at 10:36:36AM +0100, Miro Hrončok wrote: Hello Pythonistas, I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to

Re: Appstream metadata compose failures

On Fri, Mar 2, 2018 at 8:10 AM, Kalev Lember wrote: > On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > > qdirstat.desktop > > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/ > 32x32/ > > apps/qdirstat.png, Has no Icon > > > > Well, what if

Re: Appstream metadata compose failures

On 03/02/2018 03:59 PM, Dennis Gilmore wrote: > El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió: >> Hi, >> >> hughsie just did a new appstream-data compose for F29 and I noticed >> there's quite a large number of packages failing in the logs: >> >>

Re: Appstream metadata compose failures

Richard Hughes wrote: > 64x64 is a very low bar indeed, compared to all of the other > platforms, e.g. Windows Store or the Apple AppStore. All that's going to happen with such a requirement is that specfiles are going to run the icon through scale2x or hq2x if you're lucky, through a dumb

Re: Appstream metadata compose failures

El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió: > Hi, > > hughsie just did a new appstream-data compose for F29 and I noticed > there's quite a large number of packages failing in the logs: > > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if

[HEAD UP] soname bump Re: News in opencv package

Hi, Josef thanks for your work. As request we inform that is a soname bump , hopefully shouldn't change much since version 3.3.1 and bring a lot of security fixes Thanks, On Fri, 2018-03-02 at 06:24 -0500, Josef Ridky wrote: > Hi folks, > > I would like to inform you, that new version of

Re: Appstream metadata compose failures

On 2 March 2018 at 14:10, Kalev Lember wrote: > I believe the answer is to work with upstream to provide updated icons. Right, or patch them in the srpm. Working upstream is obviously better than all the distros having to do the same thing... > I would personally be a bit

Re: Appstream metadata compose failures

On 2 March 2018 at 14:44, Robert-André Mauchin wrote: > Also, with what command can I check if my package is now ok? From memory, I think you can do "appstream-builder name-of-the-file.rpm" and if it makes it into the example.xml.gz file then it passed all the checks.

Re: Appstream metadata compose failures

On vendredi 2 mars 2018 15:10:59 CET Kalev Lember wrote: > On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > > > qdirstat.desktop > > Failed to load icon: icon was too small 32x32: > > /usr/share/icons/hicolor/32x32/ apps/qdirstat.png, Has no Icon > > > > Well, what if upstream doesn't

Re: Why size of repositories metadata is too high in Fedora?

On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote: > I don't know, I just ran "dnf upgrade" and it took metadata in > mentioned size, Fedora developers should answer to these questions. A very large chunk of it is this: https://pagure.io/packaging-committee/issue/714 --

Re: Call for users of darkserver

On Thu, 01 Mar 2018 19:30:28 +0100, Pierre-Yves Chibon wrote: > On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote: > > On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote: > > It seems to me interactive crash core file analysis is just not a goal of > > ABRT > > (which is

Re: Kernel marking files in /boot as %ghost

On Fri, Mar 2, 2018 at 1:11 AM, Samuel Rakitničan wrote: > Dear list, > > I've stumbled upon a serious issue that has not been discussed before. > Somewhere around May 2015 kernel files was moved to > /usr/lib/modules/, which are then copied to /boot in post >

Re: Appstream metadata compose failures

On 03/02/2018 02:56 PM, Robert-André Mauchin wrote: > qdirstat.desktop > Failed to load icon: icon was too small 32x32: /usr/share/icons/hicolor/32x32/ > apps/qdirstat.png, Has no Icon > > Well, what if upstream doesn't provide bigger icons? I believe the answer is to work with upstream to

Re: Appstream metadata compose failures

On vendredi 2 mars 2018 11:28:40 CET Kalev Lember wrote: > Hi, > > hughsie just did a new appstream-data compose for F29 and I noticed > there's quite a large number of packages failing in the logs: > > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

https://bugzilla.redhat.com/show_bug.cgi?id=1547165 Petr Pisar changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment

Re: 389-ds-base and freeipa on 32 bit arches

On Fri, Feb 23, 2018 at 6:39 PM, Jared K. Smith wrote: > Can you give any more details on 32-bit ARM in particular -- is it just > i686 that is experiencing issues, or have you seen similar memory > corruption issues on 32-bit ARM as well? > Just another gentle ping --

[389-devel] Please review: Issue 49572 - ns_job_wait race on condvar

Hi team, please, review a small fix for nunc-stance tests: https://pagure.io/389-ds-base/issue/49572 https://pagure.io/389-ds-base/pull-request/49592 Thanks, Simon ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an

Re: Why size of repositories metadata is too high in Fedora?

On Thu, 2018-03-01 at 14:46 +, chicago wrote: > Good question. What is in this 20+58MB? Is it all text? Does most of > it it change infrequently?/Maybe we can diff it? I don't know, I just ran "dnf upgrade" and it took metadata in mentioned size, Fedora developers should answer to these

Re: Need assistance to build openvdb for both Blender and LuxRender

On 03/02/2018 01:04 PM, Mamoru TASAKA wrote: /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In function 'void exportFloatGrid()': /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: error: 'py::numeric' has not been declared

[Bug 1550959] New: perl-CGI-Application-4.61 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550959 Bug ID: 1550959 Summary: perl-CGI-Application-4.61 is available Product: Fedora Version: rawhide Component: perl-CGI-Application Keywords: FutureFeature, Triaged Assignee:

Re: Need assistance to build openvdb for both Blender and LuxRender

Luya Tshimbalanga wrote on 03/02/2018 03:00 PM: Hello team, openvdb currently failed for some odd reasons (https://koji.fedoraproject.org/koji/taskinfo?taskID=25408808) on both Rawhide and F28 in order to rebuild for boost 1.66. Looking for tail result from build.log, it seems the mockbuild

[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Petr Pisar changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In

Re: Why size of repositories metadata is too high in Fedora?

On Fri, Mar 2, 2018 at 5:05 AM, Pavel Raiskup wrote: > On Friday, March 2, 2018 2:44:19 AM CET stan wrote: >> On Thu, 01 Mar 2018 14:29:45 - >> "Farhad Mohammadi Majd" wrote: >> >> > Hello, in Debian (9, stable), size of all the official

News in opencv package

Hi folks, I would like to inform you, that new version of opencv package (3.4.1) will be available in rawhide and Fedora 28. All packages, that requires opencv should be rebuild. Regards Josef Ridky Associate Software Engineer Core Services Team Red Hat Czech, s.r.o.

[Bug 1550943] perl-Net-CardDAVTalk-0.09 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

Re: Draft: Macros to tell what Python versions to package for

On 2.3.2018 11:54, Petr Viktorin wrote: I like to use bconds, i.e. "%if %{with python2}". They're easy to override for local builds, allowing easy experimentation with, for example, dropping Python 2. I'd be happy if our official recommendation used bconds. If we want people to copy-paste

Re: Draft: Macros to tell what Python versions to package for

On 2.3.2018 11:50, Pavel Raiskup wrote: On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote: On 2.3.2018 11:25, Pavel Raiskup wrote: On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote: I've prepared a draft for Python packaging that introduces some new macros that should ease

Re: Draft: Macros to tell what Python versions to package for

I like to use bconds, i.e. "%if %{with python2}". They're easy to override for local builds, allowing easy experimentation with, for example, dropping Python 2. I'd be happy if our official recommendation used bconds. If we want people to copy-paste something, let's make it good. Also,

[Bug 1550943] New: perl-Net-CardDAVTalk-0.09 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550943 Bug ID: 1550943 Summary: perl-Net-CardDAVTalk-0.09 is available Product: Fedora Version: rawhide Component: perl-Net-CardDAVTalk Keywords: FutureFeature, Triaged Assignee:

[Bug 1550942] New: Upgrade perl-Lucy to 0.6.2

https://bugzilla.redhat.com/show_bug.cgi?id=1550942 Bug ID: 1550942 Summary: Upgrade perl-Lucy to 0.6.2 Product: Fedora Version: rawhide Component: perl-Lucy Assignee: lkund...@v3.sk Reporter: jples...@redhat.com QA

[Bug 1550940] New: Upgrade perl-CGI-Simple to 1.13

https://bugzilla.redhat.com/show_bug.cgi?id=1550940 Bug ID: 1550940 Summary: Upgrade perl-CGI-Simple to 1.13 Product: Fedora Version: rawhide Component: perl-CGI-Simple Assignee: tcall...@redhat.com Reporter:

Re: Draft: Macros to tell what Python versions to package for

On 2.3.2018 11:25, Pavel Raiskup wrote: On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote: I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do

Appstream metadata compose failures

Hi, hughsie just did a new appstream-data compose for F29 and I noticed there's quite a large number of packages failing in the logs: https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html Would be awesome if maintainers could have a look and see if they can make their packages pass!

[Bug 1550755] perl-Mozilla-CA-20180117 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550755 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In

Re: Why size of repositories metadata is too high in Fedora?

Good question. What is in this 20+58MB? Is it all text? Does most of it it change infrequently?/Maybe we can diff it? signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Why size of repositories metadata is too high in Fedora?

On Friday, March 2, 2018 2:44:19 AM CET stan wrote: > On Thu, 01 Mar 2018 14:29:45 - > "Farhad Mohammadi Majd" wrote: > > > Hello, in Debian (9, stable), size of all the official repositories > > metadata is maximum 10MB, while in Fedora, today I ran "dnf update" >

[Bug 1550752] perl-Locale-Codes-3.56 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550752 --- Comment #2 from Fedora Update System --- perl-Locale-Codes-3.56-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-437212397f -- You are receiving this

[Bug 1550752] perl-Locale-Codes-3.56 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1550752 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In

Re: Re: Frequently broken Rawhide/Branched composes

On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote: > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > > > I disagree entirely with the above. I think the solution is to gate > > packages coming into rawhide and hold or reject those that break the > > compose until they

Draft: Macros to tell what Python versions to package for

Hello Pythonistas, I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks. I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't

BuildError: package PKGNAME not in list for tag f29-pending

Hi, anyone knows cause of the build error message? Getting the message for 70 Go packages when building for rawhide. Regards Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

[Bug 1544589] perl-SNMP-Info-3.47 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1544589 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED

Re: Re: Frequently broken Rawhide/Branched composes

Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit : > > I disagree entirely with the above. I think the solution is to gate > packages coming into rawhide and hold or reject those that break the > compose until they are fixed. While I don't disagree with the sentiment there needs to be a

[Bug 1549346] perl-Plack-Middleware-RemoveRedundantBody-0.07 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1549346 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

On Fri, Mar 02, 2018 at 06:10:16AM +0100, Ralf Corsepius wrote: > On 02/28/2018 05:43 PM, Adam Williamson wrote: > > On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote: > > > On 02/27/2018 07:27 PM, Richard Shaw wrote: > > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson > > > >

Re: Frequently broken Rawhide/Branched composes

On Fri, Mar 02, 2018 at 04:40:03AM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > >> Something needs to be done to make the compose process more robust, e.g.: > >> * running createrepo on a stable release, so that we do not have to be > >> able > >> to init a chroot of the target system to

Re: [RFC] Packages which are not installable (obsoleted by other pacakges)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-03-01 at 12:56 -0800, Kevin Fenzi wrote: > On 03/01/2018 08:46 AM, Igor Gnatenko wrote: > > I ran some check on latest compose and found that quite a few > > packages > > in repo can't be installed due to being obsoleted. What do we do