No builds of v8-314 for f30 and f31
by Samuel Rakitničan
Hello,
I am wondering what is the status of v8-314. In koji there are some failed builds for f30. New builds are required because readline was updated to a new version, thus Fedora 29 version is not able to install.
Error: nothing provides libreadline.so.7()(64bit) needed by v8-314-3.14.5.10-13.fc29.x86_64.
5 years, 2 months
Open Source Conference Albania - CFP is open
by Silva Arapi
Hello,
This is Silva, one of the organizers of Open Source Conference Albania. As we were very happy to have Fedora as a supporter of the conference, we would also like to invite Fedora contributors to host a talk and/or workshop at OSCAL.
About:
OSCAL (Open Source Conference Albania) is the first annual conference in Albania organized to promote software freedom, open source software, free culture and open knowledge. The Conference will gather free libre open source technology users, developers, academics, governmental agencies and people who share the idea that software should be free and open for the local community and governments to develop and customize to its needs; that knowledge is a communal property and free and open to everyone.
The 6th edition of Open Source Conference Albania (OSCAL) is taking place in Tirana city on 18th & 19th of May 2019.
For the Fedora contributors who would like to attend OSCAL, we have prepared a list of topics which we would love to have at our conference. We always value Fedora presence at OSCAL. This is a list of topics we are interested to have, but for those who might have another topic you want to talk about, do not feel limited to apply.
Specific topics:
- How to be part of the Fedora community.
- Openness in a culturally diverse world
- Contributing to open source
- Importance of communication in open source communities/case study Fedora
- Open source software security testing
- Fedora CI: Testing an Operating System
- Quality Assurance
- Automated test, tools to help you get started
- How to optimize testing time
- Quality Engineer - role in a cross functional team.
- Getting started with DevOps
- Linux distributions, lifecycles, and containers (Fedora )
- Introduction to Machine Learning
- Introduction to OpenShift
- Software Documentation Types and Best Practices/Importance of documentation
- Agile documentation
- Open source project management tools for agile teams
- How to choose a kernel
- Being a mentor to junior devs — what’s to learn for everyone
- Organizing successful tech meetups- tips and tricks
- Online Privacy, tools, tips and tricks.
- Cyber Security - exposing Privacy Leaks
Thanks and looking forward to seeing many of you present at OSCAL :)
5 years, 2 months
Tracking translation status of a package built in koji
by Sundeep Anand
Hi Everyone,
At times this could be a requirement to track or know translation status of a package which has (just) built in koji.
Transtats could be used for this purpose. We just need to run a job.
Steps:
1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based
2. Select 'Sync Package Build System' job template and proceed.
3. You may read and continue with the tasks defined in YML.
4. Select or enter package name. For example: anaconda.
Select Build System and Tag. For example: koji and rawhide
Click 'Next'
5. And run the job. Upon successful completion an unique URL will be created.
This could really be helpful. We are working on creating alerts or warnings.
Feel free to share comments on this here: http://feedback.transtats.xyz
thanks,
sundeep
5 years, 2 months
Building modules take forever
by Igor Gnatenko
Hello,
I'm building modules with Rust apps (because this is only way to get them
in f28/f29/f30) and I noticed that building them takes ages (more
specifically, more than 12 hours(!)). I can build all those packages on my
laptop under 1 hour. Even composes take less time.
It seems that MBS has limit of 20 builds in parallel. Is there any reason
for it? Why can't we just build all packages in parallel?
5 years, 2 months
On not bumping the epoch in ceph-14, f30 and f31/rawhide
by Kaleb Keithley
The epoch was inadvertently bumped (not by me) when ceph was rebased to
14.x in f30/rawhide.
I reset it to 1 in subsequent builds. Now adamwill is running builds with
it bumped to 2 again.
I would prefer that it not be bumped. Ceph has their own builds (for Fedora
even I think) where they have epoch=2. I see this as a feature that lets
someone install Ceph's epoch=2 packages on a system and not risk
inadvertently updating with the Fedora Ceph packages.
Is there really no other way to get rid of the one or two "bad builds"
where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds
perhaps?
Thanks,
--
Kaleb
5 years, 2 months
EPEL: Python34 moving to Python36
by Stephen John Smoogen
Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7. They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.
The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
Please heavily test them by doing the following:
Stage 1 Testing
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
Install various packages you would normally use
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 2 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python34
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 3 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python36
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
This should cover the three most common scenarios. Other scenarios
exist and will require some sort of intervention to work around. We
will outline them as they come up.
Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
python team who made a copr and did many of the initial patches to
make this possible.
--
Stephen J Smoogen.
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)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.fedora...
5 years, 2 months
Chromium C++ help needed
by Tom Callaway
Hi folks,
I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Here's a sample of the error (it happens in a few places), from Fedora 30:
In file included from
../../base/trace_event/trace_event_system_stats_monitor.h:15,
from ../../base/trace_event/trace_event.h:26,
from ../../base/threading/scoped_blocking_call.cc:11:
../../base/trace_event/trace_log.h: In constructor
'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
expansion of
'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
char*)"base"))'
../../base/trace_event/trace_log.h:215:25: error: '((&
base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
constant expression
215 | if (builtin_category)
| ^
Now, chromium isn't the easiest code base to work with, but what seems to
be happening is that this code calls one of the TRACE_EVENT macros, like
this from base/threading/scoped_blocking_call.cc:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast<int>(blocking_type));
Those macros are defined in base/trace_event/common/trace_event_common.h:
#define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
/ Implementation detail: internal macro to create static category and add
// event if the category is enabled.
#define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...) \
do { \
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group); \
if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) { \
trace_event_internal::AddTraceEvent( \
phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name, \
trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
flags, trace_event_internal::kNoId, ##__VA_ARGS__); \
} \
} while (0)
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
base/trace_event/trace_event.h:
#define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
\
static_assert(
\
base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
"Unknown tracing category is used. Please register your "
\
"category in base/trace_event/builtin_categories.h");
\
constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
\
k_category_group_enabled) =
\
base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
\
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
\
category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
\
INTERNAL_TRACE_EVENT_UID(category_group_enabled));
Finally, inside here, it
calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
defined in base/trace_event/trace_log.h:
// Called by TRACE_EVENT* macros, don't call this directly.
// The name parameter is a category group for example:
// TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
static const unsigned char* GetCategoryGroupEnabled(const char* name);
static const char* GetCategoryGroupName(
const unsigned char* category_group_enabled);
static constexpr const unsigned char* GetBuiltinCategoryEnabled(
const char* name) {
TraceCategory* builtin_category =
CategoryRegistry::GetBuiltinCategoryByName(name);
if (builtin_category)
return builtin_category->state_ptr();
return nullptr;
}
Okay, so what seems like is happening here, is that the calls like this:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast<int>(blocking_type));
Are passing "base" (that first var) all the way into
GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
in base/trace_event/category_registry.h, checking against the list in
INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
from base/trace_event/builtin_categories.h, finding it, then returning this
as builtin_category:
(& base::trace_event::CategoryRegistry::categories_[7])
When if(builtin_category) is run (trying to check to see if we got a
buillt-in category or a nullptr, I think), thats when GCC says:
error: '((& base::trace_event::CategoryRegistry::categories_[7]) != 0)' is
not a constant expression
*****
None of the other distros that build Chromium seem to have hit this issue,
nor does it appear in any bugs I could find with upstream (but they use a
fork of clang to build, and we use gcc). I have hit the limit of my C++
knowledge here, so I'm not sure how to fix this. If you can help me, it
would be greatly appreciated. My work in progress is checked into the
master chromium branch in git.
There are quite a few security issues that this new version fixes,
including some that are being actively exploited, so timely help here is
appreciated.
Thanks,
~tom
5 years, 2 months
Downgrading glibc from Rawhide removed /bin/sh (!)
by Richard W.M. Jones
$ sudo dnf install glibc-headers.i686
Last metadata expiration check: 0:53:05 ago on Thu 07 Mar 2019 09:42:26 GMT.
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
glibc-headers i686 2.29-7.fc30 rawhide 475 k
Downgrading:
glibc i686 2.29-7.fc30 rawhide 3.7 M
glibc x86_64 2.29-7.fc30 rawhide 3.9 M
glibc-all-langpacks x86_64 2.29-7.fc30 rawhide 25 M
glibc-common x86_64 2.29-7.fc30 rawhide 822 k
glibc-devel i686 2.29-7.fc30 rawhide 1.0 M
glibc-devel x86_64 2.29-7.fc30 rawhide 1.0 M
glibc-headers x86_64 2.29-7.fc30 rawhide 474 k
glibc-langpack-en x86_64 2.29-7.fc30 rawhide 820 k
glibc-static x86_64 2.29-7.fc30 rawhide 1.9 M
Transaction Summary
================================================================================
Install 1 Package
Downgrade 9 Packages
Total download size: 39 M
Is this ok [y/N]: y
Downloading Packages:
(1/10): glibc-2.29-7.fc30.x86_64.rpm 661 kB/s | 3.9 MB 00:06
(2/10): glibc-2.29-7.fc30.i686.rpm 610 kB/s | 3.7 MB 00:06
(3/10): glibc-common-2.29-7.fc30.x86_64.rpm 737 kB/s | 822 kB 00:01
(4/10): glibc-devel-2.29-7.fc30.i686.rpm 675 kB/s | 1.0 MB 00:01
(5/10): glibc-devel-2.29-7.fc30.x86_64.rpm 926 kB/s | 1.0 MB 00:01
(6/10): glibc-headers-2.29-7.fc30.x86_64.rpm 609 kB/s | 474 kB 00:00
(7/10): glibc-langpack-en-2.29-7.fc30.x86_64.rp 968 kB/s | 820 kB 00:00
(8/10): glibc-headers-2.29-7.fc30.i686.rpm 934 kB/s | 475 kB 00:00
(9/10): glibc-static-2.29-7.fc30.x86_64.rpm 882 kB/s | 1.9 MB 00:02
(10/10): glibc-all-langpacks-2.29-7.fc30.x86_64 1.3 MB/s | 25 MB 00:18
--------------------------------------------------------------------------------
Total 2.0 MB/s | 39 MB 00:20
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Downgrading : glibc-all-langpacks-2.29-7.fc30.x86_64 1/19
Downgrading : glibc-common-2.29-7.fc30.x86_64 2/19
Downgrading : glibc-langpack-en-2.29-7.fc30.x86_64 3/19
Running scriptlet: glibc-2.29-7.fc30.x86_64 4/19
Downgrading : glibc-2.29-7.fc30.x86_64 4/19
Running scriptlet: glibc-2.29-7.fc30.x86_64 4/19
Running scriptlet: glibc-headers-2.29-7.fc30.x86_64 5/19
Downgrading : glibc-headers-2.29-7.fc30.x86_64 5/19
Downgrading : glibc-devel-2.29-7.fc30.x86_64 6/19
Running scriptlet: glibc-headers-2.29-7.fc30.i686 7/19
Installing : glibc-headers-2.29-7.fc30.i686 7/19
Running scriptlet: glibc-2.29-7.fc30.i686 8/19
Downgrading : glibc-2.29-7.fc30.i686 8/19
Running scriptlet: glibc-2.29-7.fc30.i686 8/19
Downgrading : glibc-devel-2.29-7.fc30.i686 9/19
Downgrading : glibc-static-2.29-7.fc30.x86_64 10/19
Cleanup : glibc-devel-2.29.9000-4.fc31.i686 11/19
Cleanup : glibc-2.29.9000-4.fc31.i686 12/19
Cleanup : glibc-static-2.29.9000-4.fc31.x86_64 13/19
Cleanup : glibc-devel-2.29.9000-4.fc31.x86_64 14/19
Cleanup : glibc-headers-2.29.9000-4.fc31.x86_64 15/19
Cleanup : glibc-langpack-en-2.29.9000-4.fc31.x86_64 16/19
Cleanup : glibc-2.29.9000-4.fc31.x86_64 17/19
Cleanup : glibc-all-langpacks-2.29.9000-4.fc31.x86_64 18/19
Running scriptlet: glibc-all-langpacks-2.29.9000-4.fc31.x86_64 18/19
Cleanup : glibc-common-2.29.9000-4.fc31.x86_64 19/19
Running scriptlet: glibc-all-langpacks-2.29-7.fc30.x86_64 19/19
Running scriptlet: glibc-common-2.29.9000-4.fc31.x86_64 19/19
error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
warning: %triggerin(info-6.5-12.fc30.x86_64) scriptlet failed, exit status 127
Error in <unknown> scriptlet in rpm package glibc-common
error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
warning: %triggerpostun(glibc-common-2.29-7.fc30.x86_64) scriptlet failed, exit status 127
Error in <unknown> scriptlet in rpm package glibc-common
error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
warning: %triggerpostun(info-6.5-12.fc30.x86_64) scriptlet failed, exit status 127
Error in <unknown> scriptlet in rpm package glibc-common
Running scriptlet: glibc-common-2.29-7.fc30.x86_64 19/19
error: failed to exec scriptlet interpreter /bin/sh: No such file or directory
warning: %triggerin(glibc-common-2.29-7.fc30.x86_64) scriptlet failed, exit status 127
Error in <unknown> scriptlet in rpm package glibc-common
Verifying : glibc-2.29-7.fc30.i686 1/19
Verifying : glibc-2.29.9000-4.fc31.i686 2/19
Verifying : glibc-2.29-7.fc30.x86_64 3/19
Verifying : glibc-2.29.9000-4.fc31.x86_64 4/19
Verifying : glibc-all-langpacks-2.29-7.fc30.x86_64 5/19
Verifying : glibc-all-langpacks-2.29.9000-4.fc31.x86_64 6/19
Verifying : glibc-common-2.29-7.fc30.x86_64 7/19
Verifying : glibc-common-2.29.9000-4.fc31.x86_64 8/19
Verifying : glibc-devel-2.29-7.fc30.i686 9/19
Verifying : glibc-devel-2.29.9000-4.fc31.i686 10/19
Verifying : glibc-devel-2.29-7.fc30.x86_64 11/19
Verifying : glibc-devel-2.29.9000-4.fc31.x86_64 12/19
Verifying : glibc-headers-2.29-7.fc30.x86_64 13/19
Verifying : glibc-headers-2.29.9000-4.fc31.x86_64 14/19
Verifying : glibc-langpack-en-2.29-7.fc30.x86_64 15/19
Verifying : glibc-langpack-en-2.29.9000-4.fc31.x86_64 16/19
Verifying : glibc-static-2.29-7.fc30.x86_64 17/19
Verifying : glibc-static-2.29.9000-4.fc31.x86_64 18/19
Verifying : glibc-headers-2.29-7.fc30.i686 19/19
Downgraded:
glibc-2.29-7.fc30.i686 glibc-2.29-7.fc30.x86_64
glibc-all-langpacks-2.29-7.fc30.x86_64 glibc-common-2.29-7.fc30.x86_64
glibc-devel-2.29-7.fc30.i686 glibc-devel-2.29-7.fc30.x86_64
glibc-headers-2.29-7.fc30.x86_64 glibc-langpack-en-2.29-7.fc30.x86_64
glibc-static-2.29-7.fc30.x86_64
Installed:
glibc-headers-2.29-7.fc30.i686
Complete!
$ ll /bin/sh
-bash: /usr/bin/ls: No such file or directory
$ sudo dnf install /bin/sh
-bash: /usr/bin/sudo: No such file or directory
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
5 years, 2 months
Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30
by Robert-André Mauchin
Hello,
I have an issue with the update of papirus-icon-theme: in the new version, symlinks
have replaced what was previously folders and dnf errors out on this:
For example, on the current version:
$ ll /usr/share/icons/Papirus-Light/16x16
total 24K
drwxr-xr-x. 1 root root 73K nov. 6 16:36 actions/
lrwxrwxrwx. 1 root root 24 oct. 22 16:33 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root 30 oct. 22 16:33 categories -> ../../Papirus/16x16/categories/
drwxr-xr-x. 1 root root 6,9K nov. 6 16:36 devices/
lrwxrwxrwx. 1 root root 27 oct. 22 16:33 emblems -> ../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root 27 oct. 22 16:33 emotes -> ../../Papirus/16x16/emotes//
lrwxrwxrwx. 1 root root 29 oct. 22 16:33 mimetypes -> ../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root 59K nov. 6 16:36 panel/
drwxr-xr-x. 1 root root 4,5K nov. 6 16:36 places/
lrwxrwxrwx. 1 root root 26 oct. 22 16:33 status -> ../../Papirus/16x16/status/
On the new version:
$ ll /usr/share/icons/Papirus-Light/16x16
total 36K
lrwxrwxrwx. 1 root root 27 mars 11 16:16 actions -> ../../Papirus/16x16/actions/
lrwxrwxrwx. 1 root root 24 mars 11 16:16 apps -> ../../Papirus/16x16/apps/
lrwxrwxrwx. 1 root root 4 mars 11 16:16 categories -> apps/
lrwxrwxrwx. 1 root root 27 mars 11 16:16 devices -> ../../Papirus/16x16/devices/
lrwxrwxrwx. 1 root root 27 mars 11 16:16 emblems -> ../../Papirus/16x16/emblems/
lrwxrwxrwx. 1 root root 26 mars 11 16:16 emotes -> ../../Papirus/16x16/emotes/
lrwxrwxrwx. 1 root root 29 mars 11 16:16 mimetypes -> ../../Papirus/16x16/mimetypes/
drwxr-xr-x. 1 root root 60K mars 12 04:52 panel/
lrwxrwxrwx. 1 root root 26 mars 11 16:16 places -> ../../Papirus/16x16/places/
lrwxrwxrwx. 1 root root 26 mars 11 16:16 status -> ../../Papirus/16x16/status/
Why doesn't dnf simply remove the previous folders and replace them with symlinks?
How can I solve this?
On mardi 12 mars 2019 00:28:04 CET you wrote:
> The following comment has been added to the
> papirus-icon-theme-20190302-1.fc30 update:
>
> bluepencil - 2019-03-11 23:28:03.749975 (karma: 0)
> Transaction check error:
> file /usr/share/icons/Papirus-Light/16x16/devices from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/16x16/places from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/22x22/actions from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/24x24/actions from install of
> papirus-icon-theme-20190302-1.fc30.noarch conflicts with file from package
> papirus-icon-theme-20181007-2.fc30.noarch
>
> To reply to this comment, please visit the URL at the bottom of this mail
>
> ============================================================================
> ==== papirus-icon-theme-20190302-1.fc30
> ============================================================================
> ==== Update ID: FEDORA-2019-0b6e471142
> Release: Fedora 30
> Status: pending
> Type: enhancement
> Severity: unspecified
> Karma: 0
> Request: testing
> Bugs: 1687463 - papirus-icon-theme-20190302 is available
> Notes: Release 20190302 (#1687463)
> Submitter: eclipseo
> Submitted: 2019-03-11 15:12:44.615650
> Comments: bluepencil - 2019-03-11 23:28:03.749975 (karma 0)
> Transaction check error: file
> /usr/share/icons/Papirus-Light/16x16/devices from
> install of papirus-icon-theme-20190302-1.fc30.noarch
> conflicts with file from package papirus-icon-
> theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/16x16/places from
> install of papirus-icon-theme-20190302-1.fc30.noarch
> conflicts with file from package papirus-icon-
> theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/22x22/actions from
> install of papirus-icon-theme-20190302-1.fc30.noarch
> conflicts with file from package papirus-icon-
> theme-20181007-2.fc30.noarch file
> /usr/share/icons/Papirus-Light/24x24/actions from
> install of papirus-icon-theme-20190302-1.fc30.noarch
> conflicts with file from package papirus-icon-
> theme-20181007-2.fc30.noarch
> bluepencil - 2019-03-11 15:48:11.297750 (karma 0)
> Error upgrading: unpacking of archive failed on
> file /usr/share/icons/Papirus-Light/16x16/actions:
> cpio: File from package already exists as a directory
> in system
> bodhi - 2019-03-11 15:12:44.648211 (karma 0)
> This update has been submitted for testing by
> eclipseo.
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-0b6e471142
5 years, 2 months
