Re: Roadmap for Mono packages in Fedora ?
On Thu, Apr 9, 2015 at 10:36 PM Gabriel L. Somlo wrote: > I've been given a (.net4.5/c# + vmware) project to port to > Fedora/RHEL (mono + kvm), so I suddenly find myself interested > in gaining access to late-model official Fedora packages for > mono (4.0.0 alpha is just out) and monodevelop (currently at 5.7.0). > > The current F21 versions are 2.10.8 and 2.8.8, respectively, and > I see those versions are still the same in rawhide. > > Are there any plans to package the more recent versions in F22 or F23 ? > > There are. Gabriel (fas: elsupergomez) has some build around here: https://copr.fedoraproject.org/coprs/elsupergomez/mono-4/ Lately, Moez (fas: moezroy) started to look at it closely with some scratch builds here: http://koji.fedoraproject.org/scratch/moezroy/task_9392781/ . They will have more input to give you on the status. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Roadmap for Mono packages in Fedora ?
I've been given a (.net4.5/c# + vmware) project to port to Fedora/RHEL (mono + kvm), so I suddenly find myself interested in gaining access to late-model official Fedora packages for mono (4.0.0 alpha is just out) and monodevelop (currently at 5.7.0). The current F21 versions are 2.10.8 and 2.8.8, respectively, and I see those versions are still the same in rawhide. Are there any plans to package the more recent versions in F22 or F23 ? Thanks much, --Gabriel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Beta to slip by one week
Today at Go/No-Go meeting it was decided to slip Fedora 22 Beta release by one week due to unresolved blocker bug [1]. More details in meeting minutes [2]. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week [3]. The next Go/No-Go meeting is on Thursday, Apr 16, 17:00 UTC at #fedora-meeting-2 channel on FreeNode. Jaroslav [1] http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist [2] http://bit.ly/1NX92nq [3] https://fedoraproject.org/wiki/Releases/22/Schedule ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Moving Docker image under Cloud edition?
On Thursday, April 09, 2015 12:07:55 PM Joe Brockmeier wrote: > On 04/08/2015 06:41 PM, Dennis Gilmore wrote: > > the docker base image is part of the Base WG. so it seems wrong to put it > > on the Cloud page, but we should do something to advertise it more. > > But there's no Base WG page or anything... I know it's sitting there > now, but I don't think end users care about which working group does it. > > Conceptually, it seems to me to fit with Cloud. Other suggestions welcome. > > I'm also curious whether there should be some closer collaboration > between base wg and cloud on the container image(s)? there probably should be closer collaboration, it started under the cloud WG and was moved to the Base WG. I do not really mind where it sits, but it should not go flip flopping. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
- Original Message - > From: "Przemek Klosowski" > To: devel@lists.fedoraproject.org > Sent: Thursday, April 9, 2015 5:01:19 PM > Subject: Re: dnf replacing yum and dnf-yum > On 04/08/2015 02:32 AM, Jan Zelený wrote > > I'm afraid not. From the very beginning, we were sending a clear message > > that > > > we will be as compatible as possible in terms of CLI but we never wanted to > > > have just another yum. If that was the case, we wouldn't call the project > > > differently. > > I am concerned that the yum-to-dnf transition is confusing, because of this > mixed message. On one hand, they are just two package management tools: on a > high level, they do a simple, well defined job of updating your system to > the latest version of available packages. In an ideal world it just wouldn't > matter which one you use, and from that point of view the name change is > superfluous: all you need to do is 'yum update', and calling it 'dnf update' > is just a tiny annoyance that is not bothersome enough to be worth bothering > about. > We are not living in an ideal world, however, and the updating problem is > complex enough so that yum ecosystem is not handling it well. You are making > an argument that dnf reimplemented this ecosystem in a qualitatively > different, more correct way, that is so different that it merits a clean > break, justifying the project name change. I am fine with that, but this > leads to confusion when there are observable changes in behavior. The > implication is that dnf is better and more correct, but on the other hand > it's clear that dnf is still in development and exhibits faults. So, now we > have a problem: if dnf behaves differently from yum, is it an improvement or > a regression? We don't know, and it's not clear to me how to tell; every > divergence is a potential bug in dnf, and therefore should be reported as > such. > I would venture a comment that it was a mistake to declare dnf a separate > project, because it leads to a different approach to such differences. If it > was an evolutionary change in yum, it would be natural to expect it to > behave in a compatible way, and consequently detect and explain in more > detail the divergent behavior. By declaring a clean break, you are basically > saying that there is no need to explain the diffs, but the flip side of it > is that unless I can clearly understand why the difference is for the > better, I must suspect this to be a regression and report it. > As a result, dnf will have a huge bug load that is hard to work with because > it depends on a specific state of the repositories at that specific moment > in time. Do you have a capability to investigate such problems? Yes, we have. "dnf --debugsolver" helps us a lot. > Here's a specific one, a firefox update from this morning that shows up in > yum but not in dnf. I will submit it to bugzilla, just to see where we go > with that. > # dnf update firefox > Using metadata from Fri Apr 3 03:24:08 2015 > Dependencies resolved. > Nothing to do. > # yum update firefox > Loaded plugins: auto-update-debuginfo, langpacks > Resolving Dependencies > --> Running transaction check > ---> Package firefox.x86_64 0:37.0-2.fc21 will be updated > ---> Package firefox.x86_64 0:37.0.1-1.fc21 will be an update > --> Finished Dependency Resolution > # dnf info firefox > Using metadata from Fri Apr 3 03:24:08 2015 > Installed Packages > Name : firefox > Arch : x86_64 > Epoch : 0 > Version : 37.0 > Release : 2.fc21 > ... > # yum info firefox > Loaded plugins: auto-update-debuginfo, langpacks > Installed Packages > Name : firefox > Arch : x86_64 > Version : 37.0 > Release : 2.fc21 > ... > Available Packages > Name : firefox > Arch : x86_64 > Version : 37.0.1 > Release : 1.fc21 > Size : 69 M > Repo : updates/21/x86_64 > ... > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
- Original Message - > From: "Przemek Klosowski" > To: devel@lists.fedoraproject.org > Sent: Thursday, April 9, 2015 5:13:49 PM > Subject: Re: dnf replacing yum and dnf-yum > On 04/09/2015 11:05 AM, Michal Luscon wrote: > > On 04/09/2015 05:01 PM, Przemek Klosowski wrote: > > > > Using metadata from Fri Apr 3 03:24:08 2015 > > > > > ^^^ the key part of DNF output > > Well, OK, but when I just re-run 'dnf update' it updates firefox now: > > Using metadata from Fri Apr 3 03:24:08 2015 > > > ^^^ same timestamp as before, but different result > > > ... > > > Dependencies resolved. > > > ... > > > firefox x86_64 37.0.1-1.fc21 updates 69 M > > This is a definition of craziness: you do the same thing twice and expect a > different return. In the end, I can't say that it doesn't work but I have an > uneasy feeling that I do not understand how an essential part of my system > works. The reason is that even if metadata of the "updates" repository have been refreshed, there is probably another repository with matadata from Fri Apr 3 03:24:08 2015 (it has probably longer expiration period). So, yes, I agree that this is confusing. Do you have a better idea than printing the timestamp for each repository? -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Another C++ ABI change?
With gcc 5.0.0-0.22.fc23 I'm getting new build failures: http://koschei.cloud.fedoraproject.org/package/gdl CMakeFiles/gdl.dir/CFMTLexer.cpp.o: In function `antlr::TokenStreamRecognitionException::toString[abi:cxx11]() const': /usr/include/antlr/TokenStreamRecognitionException.hpp:34: undefined reference to `antlr::RecognitionException::getFileLineColumnString[abi:cxx11]() const' CMakeFiles/gdl.dir/FMTIn.cpp.o:(.data.rel.ro._ZTVN5antlr7BaseASTE[_ZTVN5antlr7BaseASTE]+0xd8): undefined reference to `antlr::BaseAST::toStringList[abi:cxx11]() const' CMakeFiles/gdl.dir/FMTIn.cpp.o:(.data.rel.ro._ZTVN5antlr7BaseASTE[_ZTVN5antlr7BaseASTE]+0xe0): undefined reference to `antlr::BaseAST::toStringTree[abi:cxx11]() const' CMakeFiles/gdl.dir/GDLLexer.cpp.o:(.data.rel.ro._ZTVN5antlr17SemanticExceptionE[_ZTVN5antlr17SemanticExceptionE]+0x20): undefined reference to `antlr::RecognitionException::toString[abi:cxx11]() const' CMakeFiles/gdl.dir/GDLLexer.cpp.o:(.data.rel.ro._ZTVN5antlr17SemanticExceptionE[_ZTVN5antlr17SemanticExceptionE]+0x48): undefined reference to `antlr::RecognitionException::getFileLineColumnString[abi:cxx11]() const' CMakeFiles/gdl.dir/dnode.cpp.o:(.data.rel.ro._ZTVN5antlr9CommonASTE[_ZTVN5antlr9CommonASTE]+0xd8): undefined reference to `antlr::BaseAST::toStringList[abi:cxx11]() const' CMakeFiles/gdl.dir/dnode.cpp.o:(.data.rel.ro._ZTVN5antlr9CommonASTE[_ZTVN5antlr9CommonASTE]+0xe0): undefined reference to `antlr::BaseAST::toStringTree[abi:cxx11]() const' CMakeFiles/gdl.dir/dnode.cpp.o:(.data.rel.ro._ZTV5DNode[_ZTV5DNode]+0xd8): undefined reference to `antlr::BaseAST::toStringList[abi:cxx11]() const' CMakeFiles/gdl.dir/dnode.cpp.o:(.data.rel.ro._ZTV5DNode[_ZTV5DNode]+0xe0): undefined reference to `antlr::BaseAST::toStringTree[abi:cxx11]() const' CMakeFiles/gdl.dir/fmtnode.cpp.o:(.data.rel.ro._ZTV7FMTNode[_ZTV7FMTNode]+0xd8): undefined reference to `antlr::BaseAST::toStringList[abi:cxx11]() const' CMakeFiles/gdl.dir/fmtnode.cpp.o:(.data.rel.ro._ZTV7FMTNode[_ZTV7FMTNode]+0xe0): undefined reference to `antlr::BaseAST::toStringTree[abi:cxx11]() const' CMakeFiles/gdl.dir/magick_cl.cpp.o: In function `lib::magick_magick(EnvT*)': /builddir/build/BUILD/gdl-0.9.5/src/magick_cl.cpp:767: undefined reference to `Magick::Image::magick[abi:cxx11]() const' CMakeFiles/gdl.dir/magick_cl.cpp.o: In function `lib::magick_ping(EnvT*)': /builddir/build/BUILD/gdl-0.9.5/src/magick_cl.cpp:231: undefined reference to `Magick::Image::magick[abi:cxx11]() const' /builddir/build/BUILD/gdl-0.9.5/src/magick_cl.cpp:232: undefined reference to `Magick::Image::magick[abi:cxx11]() const' /builddir/build/BUILD/gdl-0.9.5/src/magick_cl.cpp:231: undefined reference to `Magick::Image::magick[abi:cxx11]() const' /builddir/build/BUILD/gdl-0.9.5/src/magick_cl.cpp:175: undefined reference to `Magick::Image::magick[abi:cxx11]() const' Did we just get another set of C++ ABI changes? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
review swap : yumex-dnf
Hi. I have submitted yumex-dnf for inclusion into fedora https://bugzilla.redhat.com/show_bug.cgi?id=1210430 yumex-dnf is a rewritten version of yumex, based on dnf instead of yum you can check it out here https://copr.fedoraproject.org/coprs/timlau/yumex-dnf If you want to review it, then please grab it and let me know want to review Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
Fixed in rawhide now.
Thanks,
On Thu, Apr 09, 2015 at 10:36:50AM +0200, poma wrote:
> On 01.04.2015 10:29, Jaroslav Skarvada wrote:
> >>> pm-hibernate is obsolete as others already mentioned.
> >>
> >> Do the pm-utils maintainers/upstream know this?
> >>
> >
> > Hi,
> >
> > I am pm-utils maintainer. I own some other "legacy" packages and
> > I am retiring them only if there are good reasons for it
> > (e.g. unfixed security bugs, breakage, etc.), because there may
> > be still users using such packages / depending on their functionality.
> >
> > Regarding pm-utils, most of the functionality is currently handled
> > by systemd. If there is anybody still using it, I think it shouldn't be
> > hard to migrate. Also I think this package may be quite confusing
> > for newcomers. Upstream said it's dead, so there are probably
> > good reasons to retire. But currently there are the following
> > packages in rawhide depending on pm-utils:
> >
> > cdm
> > kdebase3
> > wicd
> >
>
> http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/view/head:/INSTALL#L13
> 8. pm-utils (optional for suspend/resume integration)
>
> http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/view/head:/setup.py#L130
> ('no-install-pmutils', None, 'do not install the pm-utils hooks'),
>
>
> diff --git a/wicd.spec b/wicd.spec
> index a5dcaf0..bc7afe6 100644
> --- a/wicd.spec
> +++ b/wicd.spec
> @@ -36,7 +36,6 @@ BuildRequires: desktop-file-utils
> BuildRequires: pkgconfig
> BuildRequires: systemd-units
>
> -Requires:pm-utils >= 1.2.4
> Requires:%{name}-common = %{version}-%{release}
>
> %description
> @@ -140,10 +139,10 @@ rm -f po/ast.po
> --share %{_datadir}/wicd \
> --etc %{_sysconfdir}/wicd \
> --bin %{_bindir} \
> ---pmutils %{_libdir}/pm-utils/sleep.d \
> --log %{_localstatedir}/log \
> --systemd %{_systemd_unitdir} \
> ---no-install-init
> +--no-install-init \
> +--no-install-pmutils
> %{__python} setup.py build
> %{__python} setup.py compile_translations
>
> @@ -214,7 +213,7 @@ gtk-update-icon-cache %{_datadir}/icons/hicolor
> &>/dev/null || :
>
> %files
> %defattr(-,root,root,-)
> -%{_libdir}/pm-utils/sleep.d/55wicd
> +%{_datadir}/autostart/wicd-tray.desktop
>
> %files common -f %{name}.lang
> %defattr(-,root,root,-)
>
>
> > I will drop pm-utils when resolved
> >
> > regards
> >
> > Jaroslav
> >
>
--
David Cantrell
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 147 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3989/cross-binutils-2.23.88.0.1-2.el7.1 41 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0862/nodejs-0.10.36-3.el7,libuv-0.10.34-1.el7,v8-3.14.5.10-17.el7 31 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1087/dokuwiki-0-0.24.20140929c.el7 31 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0952/qpid-qmf-0.28-27.el7,qpid-cpp-0.30-12.el7 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1407/glpi-0.84.8-4.el7 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1390/owncloud-7.0.5-2.el7 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1421/quassel-0.11.0-2.el7 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1458/mongodb-2.6.9-1.el7 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1476/tor-0.2.5.11-1.el7 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1545/strongswan-5.3.0-1.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1596/postgis-2.0.7-1.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1604/perl-DBD-Firebird-1.19-1.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1606/arj-3.10.22-22.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1611/php-symfony-2.5.11-1.el7 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5703/php-pecl-zendopcache-7.0.4-2.el7 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5698/knot-1.6.3-1.el7 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5699/zarafa-7.1.12-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing collectl-4.0.0-1.el7 perl-MCE-1.606-1.el7 python-bugzilla-1.2.0-1.el7 qpid-proton-0.9-3.el7 qt5-qtconfiguration-0.3.0-2.el7 sx-2.17-2.el7 vertica-python-0.3.5-1.el7 wiredtiger-2.5.2-1.el7 Details about builds: collectl-4.0.0-1.el7 (FEDORA-EPEL-2015-5725) A utility to collect various Linux performance data Update Information: - update to upstream version 4.0.0 - upstream changelog at http://collectl.sourceforge.net/Releases.html ChangeLog: * Thu Apr 9 2015 Dan Horák - 4.0.0-1 - upgrade to upstream version 4.0.0 (#1201069) References: [ 1 ] Bug #1201069 - collectl-4.0.0.src is available https://bugzilla.redhat.com/show_bug.cgi?id=1201069 perl-MCE-1.606-1.el7 (FEDORA-EPEL-2015-5732) Many-core Engine for Perl providing parallel processing capabilities Update Information: A new version of MCE is available. See http://search.cpan.org/src/MARIOROY/MCE-1.606/CHANGES for details on changes in this release. A new version of MCE is available. See http://cpansearch.perl.org/src/MARIOROY/MCE-1.605/CHANGES for details on changes in this release. A new version of MCE is available. See http://cpansearch.perl.org/src/MARIOROY/MCE-1.604/CHANGES for summary of changes for this release. ChangeLog: * Thu Apr 9 2015 Petr Šabata - 1.606-1 - 1.606 bump * Wed Apr 8 2015 Petr Šabata - 1.605-1 - 1.605 bump * Mon Mar 23 2015 Petr Šabata - 1.604-1 - 1.604 bump * Wed Feb 11 2015 Petr Pisar - 1.600-3 - Move mce_grep tool into a separate sub-package * Tue Feb 10 2015 Petr Pisar - 1.600-2 - Correct dependencies References: [ 1 ] Bug #1210119 - perl-MCE-1.606 is available https://bugzilla.redhat.com/show_bug.cgi?id=1210119 [ 2 ] Bug #1209148 - perl-MCE-1.605 is available https://bugzilla.redhat.com/show_bug.cgi?id=1209148 [ 3 ] Bug #1204474 - perl-MCE-1.604 is available https://bugzilla.redhat.com/show_bug.cgi?id=1204474 python-bugzilla-1.2.0-1.el7 (FEDORA-EPEL-2015-5731) A python library and tool for interacting with Bugzilla Update Information: * Rebased to version 1.2.0 * Add bugzilla new/query/modify --field flag (Arun Babu Neelicattu) * API support for ExternalBugs (Arun Babu Neelicattu, Brian Bouterse) * Add new/modify --alias support (Adam
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 1082 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 147 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4008/cross-binutils-2.23.51.0.3-1.el6.1 135 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4242/facter-1.6.18-8.el6 41 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0864/nodejs-0.10.36-3.el6,libuv-0.10.34-1.el6,v8-3.14.5.10-17.el6 20 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1317/mongodb-2.4.13-1.el6 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1346/drupal6-6.35-1.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1404/tor-0.2.5.11-1.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1376/owncloud-7.0.5-2.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1501/strongswan-5.3.0-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1530/drupal7-webform-4.7-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1552/mediawiki119-1.19.24-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1592/arj-3.10.22-22.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1599/perl-DBD-Firebird-1.19-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5739/perl-Test-Signature-1.11-1.el6,perl-Module-Signature-0.78-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5707/chrony-1.31.1-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5720/zarafa-7.1.12-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5702/torque-4.2.10-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5690/php-pecl-zendopcache-7.0.4-2.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5684/knot-1.6.3-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing collectl-4.0.0-1.el6 perl-MCE-1.606-1.el6 perl-Module-Signature-0.78-1.el6 perl-Test-Signature-1.11-1.el6 python-bugzilla-1.2.0-1.el6 qpid-proton-0.9-3.el6 rubygem-qpid_proton-0.9.0-1.el6 vertica-python-0.3.5-1.el6 Details about builds: collectl-4.0.0-1.el6 (FEDORA-EPEL-2015-5730) A utility to collect various Linux performance data Update Information: - update to upstream version 4.0.0 - upstream changelog at http://collectl.sourceforge.net/Releases.html ChangeLog: * Thu Apr 9 2015 Dan Horák - 4.0.0-1 - upgrade to upstream version 4.0.0 (#1201069) References: [ 1 ] Bug #1201069 - collectl-4.0.0.src is available https://bugzilla.redhat.com/show_bug.cgi?id=1201069 perl-MCE-1.606-1.el6 (FEDORA-EPEL-2015-5727) Many-core Engine for Perl providing parallel processing capabilities Update Information: A new version of MCE is available. See http://search.cpan.org/src/MARIOROY/MCE-1.606/CHANGES for details on changes in this release. A new version of MCE is available. See http://cpansearch.perl.org/src/MARIOROY/MCE-1.605/CHANGES for details on changes in this release. A new version of MCE is available. See http://cpansearch.perl.org/src/MARIOROY/MCE-1.604/CHANGES for summary of changes for this release. ChangeLog: * Thu Apr 9 2015 Petr Šabata - 1.606-1 - 1.606 bump * Wed Apr 8 2015 Petr Šabata - 1.605-1 - 1.605 bump * Mon Mar 23 2015 Petr Šabata - 1.604-1 - 1.604 bump * Wed Feb 11 2015 Petr Pisar - 1.600-3 - Move mce_grep tool into a separate sub-package * Tue Feb 10 2015 Petr Pisar - 1.600-2 - Correct dependencies References: [ 1 ] Bug #1210119 - perl-MCE-1.606 is available https://bugzilla.redhat.com/show_bug.cgi?id=1210119 [ 2 ] Bug #1209148 - perl-MCE-1.605 is available https://bugzilla.redhat.com/show_bug.cgi?id=1209148 [ 3 ] Bug #1204474 - perl-MCE-1.604 is available https://bugzilla.redhat.com/show_bug.cgi?id=1204474 perl-Module-Signature-0.78-1.el6 (FEDORA-EPEL-2015-5739) CPAN signature management utilities and modules ---
[EPEL-devel] Fedora EPEL 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing:
Age URL
1082
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
536
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5
301
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5
151
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3849/sblim-sfcb-1.3.8-2.el5
19
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1344/drupal6-6.35-1.el5
14
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1374/tor-0.2.4.26-1.el5
3
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1588/arj-3.10.22-22.el5
1
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1636/mantis-1.2.19-1.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5740/perl-Test-Signature-1.11-1.el5,perl-Module-Signature-0.78-1.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5724/torque-4.2.10-1.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5677/chrony-1.31.1-1.el5
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5694/zarafa-7.1.12-1.el5
The following builds have been pushed to Fedora EPEL 5 updates-testing
collectl-4.0.0-1.el5
perl-Module-Signature-0.78-1.el5
perl-Test-Signature-1.11-1.el5
Details about builds:
collectl-4.0.0-1.el5 (FEDORA-EPEL-2015-5729)
A utility to collect various Linux performance data
Update Information:
- update to upstream version 4.0.0
- upstream changelog at http://collectl.sourceforge.net/Releases.html
ChangeLog:
* Thu Apr 9 2015 Dan Horák - 4.0.0-1
- upgrade to upstream version 4.0.0 (#1201069)
References:
[ 1 ] Bug #1201069 - collectl-4.0.0.src is available
https://bugzilla.redhat.com/show_bug.cgi?id=1201069
perl-Module-Signature-0.78-1.el5 (FEDORA-EPEL-2015-5740)
CPAN signature management utilities and modules
Update Information:
This update addresses various security issues in perl-Module-Signature as
described below. The default behavior is also changed so as to ignore any
MANIFEST.SKIP files unless a "skip" parameter is specified. An updated version
of perl-Test-Signature that accounts for the changed default behavior is
included in this update.
Security issues:
* Module::Signature before version 0.75 could be tricked into interpreting the
unsigned portion of a SIGNATURE file as the signed portion due to faulty
parsing of the PGP signature boundaries.
* When verifying the contents of a CPAN module, Module::Signature before
version 0.75 ignored some files in the extracted tarball that were not listed
in the signature file. This included some files in the t/ directory that would
execute
automatically during "make test".
* Module::Signature before version 0.75 used two argument open() calls to read
the files when generating checksums from the signed manifest. This allowed
embedding arbitrary shell commands into the SIGNATURE file that would execute
during the signature verification process.
* Module::Signature before version 0.75 has been loading several modules at
runtime inside the extracted module directory. Modules like Text::Diff are not
guaranteed to be available on all platforms and could be added to a malicious
module so that they would load from the '.' path in @INC.
ChangeLog:
* Thu Apr 9 2015 Paul Howarth - 0.78-1
- Update to 0.78
- Fix verify() use from cpanm and CPAN.pm
* Wed Apr 8 2015 Paul Howarth - 0.77-1
- Update to 0.77
- Include the latest public keys of PAUSE, ANDK and AUDREYT
- Clarify scripts/cpansign copyright to CC0 (#965126, CPAN RT#85466)
* Wed Apr 8 2015 Paul Howarth - 0.76-1
- Update to 0.76
- Fix signature tests by defaulting to verify(skip=>1) when
$ENV{TEST_SIGNATURE} is true
* Tue Apr 7 2015 Paul Howarth - 0.75-1
- Update to 0.75
- Fix GPG signature parsing logic
- MANIFEST.SKIP is no longer consulted unless --skip is given
- Properly use open() modes to avoid injection attacks
- More protection of @INC from relative paths
- Don't try to run the signature test, which needs the network
References:
[ 1 ] Bug #1209911 - perl-Module-Signature: unsigned files interpreted as
signed in some circumstances
Re: dnf replacing yum and dnf-yum
Am 09.04.2015 um 17:01 schrieb Przemek Klosowski: On 04/08/2015 02:32 AM, Jan Zelený wrote I'm afraid not. From the very beginning, we were sending a clear message that we will be as compatible as possible in terms of CLI but we never wanted to have just another yum. If that was the case, we wouldn't call the project differently. I am concerned that the yum-to-dnf transition is confusing, because of this mixed message. On one hand, they are just two package management tools: on a high level, they do a simple, well defined job of updating your system to the latest version of available packages. In an ideal world it just wouldn't matter which one you use, and from that point of view the name change is superfluous: all you need to do is 'yum update', and calling it 'dnf update' is just a tiny annoyance that is not bothersome enough to be worth bothering about nobody cares about the annoyance while the original promise was "dnf will be a fork of current yum and later renamed back to yum" this no longer bothers anybody and it was decided that user confusion is no problem as long as developer egos are fine signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Moving Docker image under Cloud edition?
On 04/08/2015 06:41 PM, Dennis Gilmore wrote: > the docker base image is part of the Base WG. so it seems wrong to put it on > the Cloud page, but we should do something to advertise it more. But there's no Base WG page or anything... I know it's sitting there now, but I don't think end users care about which working group does it. Conceptually, it seems to me to fit with Cloud. Other suggestions welcome. I'm also curious whether there should be some closer collaboration between base wg and cloud on the container image(s)? Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RE: remedy for depcheck inferior architecture issue
> Date: Thu, 9 Apr 2015 04:39:59 -0400 > From: kpa...@redhat.com > To: qa-de...@lists.fedoraproject.org > Subject: remedy for depcheck inferior architecture issue > > I see people asking on #fedora-devel or #fedora-admin about depcheck inferior > architecture issue [1] quite often. Most of them are very confused. Last time > I saw someone asking about this was tonight [2]. > > We're not able fix this easily, but I think we should finally at least put > some temporary measures to "work around" this issue and stop confusing people > that much, or least start explaining better what this is and what it means. I > have the following ideas: > > 1. In depcheck, detect if the output has "inferior architecture" substring > and add an explanatory note, like this: > > not ok - depcheck for Bodhi update xforms-1.2.4-2.fc22 # FAIL > --- > arch: x86_64 > details: > output: |- > Build xforms-1.2.4-2.fc22 failed depcheck > package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = > 1.2.4-2.fc22, but none of the providers can be installed > xforms-1.2.4-2.fc22.i686 has inferior architecture > xforms-1.2.4-2.fc22.i686 has inferior architecture > package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = > 1.2.4-2.fc22, but none of the providers can be installed > xforms-1.2.4-2.fc22.i686 has inferior architecture > xforms-1.2.4-2.fc22.i686 has inferior architecture > PLEASE NOTE : This failure is most probably invalid, caused by a bug > we weren't able to fix yet: https://phab.qadevel.cloud.fedoraproject.org/T366 > . Please test you package dependencies manually and if everything looks > correct, ignore this error. We're sorry for this inconvenience. > item: xforms-1.2.4-2.fc22 > outcome: FAILED > summary: xforms-1.2.4-2.fc22 into F22 testing > type: bodhi_update > ... > > > 2. Do not submit this result (I'm mostly concerned about Bodhi, but there's > no easy way to disconnect ResultsDB reporting from Bodhi reporting, so it > would affect both systems). That can be done by filtering out "inferior > architecture" CheckDetails at the end of the depcheck run, before the final > TAP is generated. We would print these CheckDetails to stdout instead, so > that the results would still be visible in the log. > > > 3. Alternatively to 2), Josef proposed setting these results to ABORTED > instead of FAILED. They would still show up in ResultsDB, and they would be > easy to search for (we'll need to fix T458, but we'll need to fix that > anyway). I've went through bodhi_comment_directive, and I believe it will > report the ABORTED outcome to Bodhi the same way as any other outcome. I'd > prefer either not to report ABORTED at all, or least not send emails for > them. But either way, saying ABORTED is a bit less confusing than FAILED. And > if we add the explanatory note as suggested in 1), it could be a substantial > improvement. I think I prefer this to 2). > > > What do you think? Any better suggestions? I'm with 3 plus the note from 1. John. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: dnf replacing yum and dnf-yum
On 04/09/2015 11:05 AM, Michal Luscon wrote: On 04/09/2015 05:01 PM, Przemek Klosowski wrote: Using metadata from Fri Apr 3 03:24:08 2015 ^^^ the key part of DNF output Well, OK, but when I just re-run 'dnf update' it updates firefox now: Using metadata from Fri Apr 3 03:24:08 2015 ^^^ same timestamp as before, but different result ... Dependencies resolved. ... firefox x86_64 37.0.1-1.fc21 updates69 M This is a definition of craziness: you do the same thing twice and expect a different return. In the end, I can't say that it doesn't work but I have an uneasy feeling that I do not understand how an essential part of my system works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 04/09/2015 05:01 PM, Przemek Klosowski wrote: Using metadata from Fri Apr 3 03:24:08 2015 ^^^ the key part of DNF output -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 04/08/2015 02:32 AM, Jan Zelený wrote I'm afraid not. From the very beginning, we were sending a clear message that we will be as compatible as possible in terms of CLI but we never wanted to have just another yum. If that was the case, we wouldn't call the project differently. I am concerned that the yum-to-dnf transition is confusing, because of this mixed message. On one hand, they are just two package management tools: on a high level, they do a simple, well defined job of updating your system to the latest version of available packages. In an ideal world it just wouldn't matter which one you use, and from that point of view the name change is superfluous: all you need to do is 'yum update', and calling it 'dnf update' is just a tiny annoyance that is not bothersome enough to be worth bothering about. We are not living in an ideal world, however, and the updating problem is complex enough so that yum ecosystem is not handling it well. You are making an argument that dnf reimplemented this ecosystem in a qualitatively different, more correct way, that is so different that it merits a clean break, justifying the project name change. I am fine with that, but this leads to confusion when there are observable changes in behavior. The implication is that dnf is better and more correct, but on the other hand it's clear that dnf is still in development and exhibits faults. So, now we have a problem: if dnf behaves differently from yum, is it an improvement or a regression? We don't know, and it's not clear to me how to tell; every divergence is a potential bug in dnf, and therefore should be reported as such. I would venture a comment that it was a mistake to declare dnf a separate project, because it leads to a different approach to such differences. If it was an evolutionary change in yum, it would be natural to expect it to behave in a compatible way, and consequently detect and explain in more detail the divergent behavior. By declaring a clean break, you are basically saying that there is no need to explain the diffs, but the flip side of it is that unless I can clearly understand why the difference is for the better, I must suspect this to be a regression and report it. As a result, dnf will have a huge bug load that is hard to work with because it depends on a specific state of the repositories at that specific moment in time. Do you have a capability to investigate such problems? Here's a specific one, a firefox update from this morning that shows up in yum but not in dnf. I will submit it to bugzilla, just to see where we go with that. # dnf update firefox Using metadata from Fri Apr 3 03:24:08 2015 Dependencies resolved. Nothing to do. # yum update firefox Loaded plugins: auto-update-debuginfo, langpacks Resolving Dependencies --> Running transaction check ---> Package firefox.x86_64 0:37.0-2.fc21 will be updated ---> Package firefox.x86_64 0:37.0.1-1.fc21 will be an update --> Finished Dependency Resolution # dnf info firefox Using metadata from Fri Apr 3 03:24:08 2015 Installed Packages Name: firefox Arch: x86_64 Epoch : 0 Version : 37.0 Release : 2.fc21 ... # yum info firefox Loaded plugins: auto-update-debuginfo, langpacks Installed Packages Name: firefox Arch: x86_64 Version : 37.0 Release : 2.fc21 ... Available Packages Name: firefox Arch: x86_64 Version : 37.0.1 Release : 1.fc21 Size: 69 M Repo: updates/21/x86_64 ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
Jan Zelený wrote: > On 7. 4. 2015 at 18:34:49, Ralf Corsepius wrote: > > Pardon, folks - But haven't we been told dnf was supposed to be yum > > compatible? > > I'm afraid not. From the very beginning, we were sending a clear message that > we will be as compatible as possible in terms of CLI but we never wanted to > have just another yum. If that was the case, we wouldn't call the project > differently. Your definition of "possible" seems to be different from mine. To me "possible" means that it doesn't require doing something impossible such as solving the halting problem. As I don't know what you consider possible I can't tell how compatible Yum and DNF are really supposed to be. If you mean that DNF will duplicate those parts of Yum's CLI that are reasonably straightforward to implement on top of DNF's internal architecture, then it would be better to say that. If you mean that DNF will duplicate the most commonly used of Yum's features, then please say that. If you mean that whenever DNF happens to have a feature that works similarly to one of Yum's features it will have the same name so that users will recognize it, then please say that. Björn Persson pgpx9cyFBwOK0.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Minutes from Env-and-Stacks WG meeting (2015-04-09)
== #fedora-meeting-2: Env and Stacks (2015-04-09) == Meeting started by hhorak at 12:09:52 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2015-04-09/env-and-stacks.2015-04-09-12.09.log.html . Meeting summary --- * init process (hhorak, 12:10:07) * Dockerfile lint (hhorak, 12:12:28) * LINK: http://docker-phracek.rhcloud.com/ (hhorak, 12:19:27) * web app for dockerfile_lint is not part of the dockerfile_lint project, but it may be just tiny web app (hhorak, 12:20:42) * ACTION: phracek to check plans about UI with dockerfile_lint authors (hhorak, 12:22:43) * dockerfile_lint moved under project atomic (hhorak, 12:28:26) * LINK: https://github.com/projectatomic/dockerfile_lint/ (hhorak, 12:28:27) * IDEA: to rewrite dockerfile_lint into python, but not sure if the effort is worth since we should also concentrate on writing rules (hhorak, 13:05:26) * IDEA: dockerfiles should live in upstream rather than downstream distro (hhorak, 13:05:33) * IDEA: we need to aggregate dockerfiles in fedora (primarily for marketing reasons), the question is how (wiki considered not ideal, since it never gets updated) (hhorak, 13:06:21) * docker.fp.o or containers.fp.o may be a good place to keep the aggregation of dockerfiles, the content may be generated from git, similar to https://github.com/yeoman/yeoman.io (hhorak, 13:22:39) Meeting ended at 13:25:57 UTC. Action Items * phracek to check plans about UI with dockerfile_lint authors Action Items, by person --- * phracek * phracek to check plans about UI with dockerfile_lint authors * **UNASSIGNED** * (none) People Present (lines said) --- * phracek (53) * hhorak (51) * langdon (42) * ttomecek (22) * vpavlin (19) * zodbot (7) * vpavlin1 (2) * ttomecek1 (1) * bkabrda (0) * sicampbell (0) * juhp (0) * ncoghlan (0) * walters (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Should a failed arch cancel other arch builds in koji?
On 2015-04-09 01:51, Sérgio Basto wrote: On Qua, 2015-04-08 at 12:20 -0600, Orion Poplawski wrote: Should a failed arch cancel other arch builds in koji? I can understand the resource saving argument, but I'm finding it increasingly useful to know if a build failure is arch specific or not and this makes it impossible to tell. Sorry hijack this thread, a different question , can we force a noarch package be build in an specific arch ? When submitting a scratch build you can use arch-override. But not for non-scratch builds. We got this problem [1] with debhelper.noach fails to build on arm builders and I'm getting notifications time to time like this : debhelper's builds started to fail in f23 http://koschei.cloud.fedoraproject.org/package/debhelper For koschei, you can set the arch-override in the package detail (the link you have in the notification). You need to be logged in. Michael Simacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Replace Bacula with Bareos
On 13 Dec 2013 13:31, "Vitaly Kuznetsov" wrote: > > Kevin Kofler writes: > > > Simone Caronni wrote: > >> http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg57308.html > > > > Hmmm, that guy is painting a somewhat different picture of the situation of > > the 2 projects than your Change page. In particular, he claims the community > > version is not dead. (Is that credible?) (He does admit that Bacula is using > > the crippleware business model though.) > > > > His vague allegations of copyright infringement in Bareos lack any kind of > > details required to verify them though. > > > > Kern wrote new letter to the community explaining his point of view, it > is available here: http://www.bacula.org/en/?page=news > > -- They settled their differences and Spot recently removed bareos from the forbidden items page if there is interest in picking this up again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 2015-04-08 11:17, Marcin Juszkiewicz wrote: W dniu 08.04.2015 o 11:05, drago01 pisze: We do have dep solvers otherwise no one would notice that a dep is broken ever. (like libsolv + hawkey). So what bodhi should do is to ask "has this package all dependencies satisfied with base + updates + other packages in this push" for every package in the push. If the answer is "no" for a package cancel the push; remove it; restart and only push the once that has satisfied deps. Report the failed once to the maintainers so that they can fix it. When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks and one of them in my setup was "once built, install all resulting packages". This way as a developer I could check are results usable. Not found something like that in mock. Curent mock has such option: --postinstall Try to install built packages in the same buildroot right after build. Michael Simacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-22 Branched report: 20150409 changes
Compose started at Thu Apr 9 07:15:02 UTC 2015 Broken deps for armhfp -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmdata.so.3.6 [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bro] broccoli-2.3-1.fc22.armv7hl requires bro-2.3 python-broccoli-2.3-1.fc22.armv7hl requires bro-2.3 [crystal] crystal-2.2.1-2.fc22.armv7hl requires libkdecorations.so.4 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 [kde-style-skulpture] kde-style-skulpture-0.2.4-9.fc22.armv7hl requires libkdecorations.so.4 [kfilefactory] kfilefactory-0.1.1-8.fc21.noarch requires kdebase-workspace [leksah] ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(utf8-string-0.3.7-013ef9ad8ac70ebb11df31f487b74f26) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(unix-2.6.0.1-7550b9ae9dbc74e4d6570cc239a29030) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(transformers-0.3.0.0-23508e0b4a1c1bc1cf2c2de3bb13e90c) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(time-1.4.0.1-970760bdd865d8b6cafac382276795a2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(text-0.11.3.1-17cae9ba49c3f3d533bf78a6e387f543) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(strict-0.3.2-04f0cc1e99eff2196c0a7cd16d748b37) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-tdfa-1.1.8-0b03687c4e38c00ef92e9445170081e2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-base-0.93.2-6a541a53412d1d7d310fa69bca50c85f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(pretty-1.1.1.0-2de27f83b2c1c65d629a564e9e01b27d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(parsec-3.1.3-a8bebef411959de671abb0f1f7da556f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(old-time-1.1.0.1-29c02e2b3bbdfd9a5756f0c46f4d6071) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(network-2.4.1.2-82f6bcf79fe0252b3ab387e8dcb82e71) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(mtl-2.1.2-2f2cd438035824ec2bed4811930bc232) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ltk-0.12.1.0-2fbb10498719be9dbdbb3d9f8adedbec) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(leksah-server-0.12.1.2-7dbd70c9f5e4dd8b3b5efcb6597b3bfd) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(hslogger-1.2.1-43834164508859009a3cc8aef7fd1e84) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtksourceview2-0.12.5.0-588b179d0562576f9afa46559cebf79f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtk-0.12.5.0-2342a114ec8897cecfdda15ac92aed08) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(glib-0.12.5.0-1b94df160e141377711a221615168695) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gio-0.12.5.0-b012293268f349d8f05c73d053798c7b) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ghc-7.6.3-18fc786f8ad3478b9bb568d865b0e48d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(filepath-1.3.0.1-62570c67b40fb99e7078c0d179220531) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(enumerator-0.4.19-a164f71ed1088e349dd8bc4cdee8e449) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(directory-1.2.0.1-504c99535d64699e20e001d81b577d06) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(deepseq-1.3.0.1-aa1be128186a233c7290faf88620ffe5) ghc-leksah-devel-0.12.1.3-16.fc22.
Re: Continuous integration for Fedora
Le 09/04/2015 12:41, Mikolaj Izdebski a écrit : > Koschei [1] can be used to rebuild package after dependency change or > time elapse. Koschei runs tests enabled during package build. Among other thing, Koschei is already used to monitor changes in the PHP stack http://koschei.cloud.fedoraproject.org/groups/php?order_by=state%2C-started%2Cname Very useful tool which already allow us to detect and fix some regression. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Continuous integration for Fedora
On 04/09/2015 12:32 PM, Sergio Pascual wrote: > I have recently heard of Debian Continuous Integration, i.e, automated self > tests are run for packages whenever its dependencies are updated. > > http://ci.debian.net/ > > Are there any plans to have something similar for Fedora? Koschei [1] can be used to rebuild package after dependency change or time elapse. Koschei runs tests enabled during package build. Taskotron [2] can be used to run other automated test cases (this is not yet possible in production instance AFAIK). [1] http://koschei.cloud.fedoraproject.org/ [2] http://taskotron.fedoraproject.org/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Continuous integration for Fedora
Hello, I have recently heard of Debian Continuous Integration, i.e, automated self tests are run for packages whenever its dependencies are updated. http://ci.debian.net/ Are there any plans to have something similar for Fedora? Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 09/04/15 11:10, Tom Hughes wrote: On 09/04/15 10:30, Radek Holy wrote: On Wed, Apr 08, 2015 at 08:22:53 -0400, Radek Holy wrote: AFAIK, YUM's --skip-broken does two things: 1) it selects another version of the requested package if the most suitable cannot be installed 2) it skips the requested package if none of its versions can be installed (2) was intentionally not supported in DNF so far but we have been repeatedly receiving bug reports complaining that this "feature" is missing. We have finally received a use case for it and thus we are considering an implementation as a plugin. Doesn't 2 apply if no package list is given for dnf update? Hm, well, in case of upgrade some version of the given package is already installed so literally no (because the already installed version can be installed :-) ). But let's say that we both are correct because upgrade is kind of special in this case. We can think about changing the upgrade command to be consistent with the install command if there is a demand to do that but so far I'm fine with the current situation. I think that in case of upgrade, it's more common to ask to upgrade as much as you can while in case of install, users/scripts prefer to install everything or fail otherwise. Moreover I think that the change could annoy a lot of users. Sounds reasonable, but include distro-sync in the upgrade case please... That was one of the issues I ran into the other day, where I did something like "dnf distro-sync b*" and if failed because one of the installed packages which matched the wildcard didn't exist in any repo. Hmm. Think I misread a bit what you were talking about, but my request still stands ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 09/04/15 10:30, Radek Holy wrote: On Wed, Apr 08, 2015 at 08:22:53 -0400, Radek Holy wrote: AFAIK, YUM's --skip-broken does two things: 1) it selects another version of the requested package if the most suitable cannot be installed 2) it skips the requested package if none of its versions can be installed (2) was intentionally not supported in DNF so far but we have been repeatedly receiving bug reports complaining that this "feature" is missing. We have finally received a use case for it and thus we are considering an implementation as a plugin. Doesn't 2 apply if no package list is given for dnf update? Hm, well, in case of upgrade some version of the given package is already installed so literally no (because the already installed version can be installed :-) ). But let's say that we both are correct because upgrade is kind of special in this case. We can think about changing the upgrade command to be consistent with the install command if there is a demand to do that but so far I'm fine with the current situation. I think that in case of upgrade, it's more common to ask to upgrade as much as you can while in case of install, users/scripts prefer to install everything or fail otherwise. Moreover I think that the change could annoy a lot of users. Sounds reasonable, but include distro-sync in the upgrade case please... That was one of the issues I ran into the other day, where I did something like "dnf distro-sync b*" and if failed because one of the installed packages which matched the wildcard didn't exist in any repo. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
On 9. 4. 2015 at 10:31:20, Reindl Harald wrote: > Am 09.04.2015 um 10:28 schrieb Jan Zelený: > > On 9. 4. 2015 at 03:19:02, kendell clark wrote: > >> hi > >> I'll add my two cents in. I've had few problems with dnf. That being > >> said, I usually get an error after every install/update that goes > >> something like, snapper. Could not create snapshot error.unknown > >> config: /org.freedesktop.dbus.error. This is not exact, I can get > >> exact if needed. I'm assuming the snapshot plugin might be broken, or > >> still be in development. I sometimes get a much more serious error > >> that I solved once, but now can't remember how. Sometimes when I go to > >> do anything with dnf, I get an error of, error. Repository "local" is > >> listed more than once in the configuration." And dnf immediately > >> returns me to my prompt. This not only affects dnf when run from the > >> command line, but also appears to affect gnome software, which > >> presumably uses it. I hope to be able to help fix these issues by > >> f22's release. I'll gladly provide any needed info. > >> Thanks > >> Kendell clark > >> Sent from Fedora GNU/Linux > > > > Please review the entire thread, I believe you are hitting the very same > > issue that was thoroughly analyzed and solved here. Once again, dnf is > > not to be blamed here, the issues are in the individual plugins you have > > installed > not really > > snapper could simply realize that it can't work as example on ext4 and > just be a NOP operatin doing nothing in that case My point was that it's still an issue of one specific plugin, not the entire dnf. That plugin (may it be snapper or local) can be disabled or uninstalled until the bug is fixed. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
- Original Message - > From: "Bruno Wolff III" > To: "Radek Holy" > Cc: "Development discussions related to Fedora" > > Sent: Wednesday, April 8, 2015 5:03:46 PM > Subject: Re: dnf replacing yum and dnf-yum > > On Wed, Apr 08, 2015 at 08:22:53 -0400, > Radek Holy wrote: > > > >AFAIK, YUM's --skip-broken does two things: > >1) it selects another version of the requested package if the most suitable > >cannot be installed > >2) it skips the requested package if none of its versions can be installed > > > >(2) was intentionally not supported in DNF so far but we have been > >repeatedly receiving bug reports complaining that this "feature" is > >missing. We have finally received a use case for it and thus we are > >considering an implementation as a plugin. > > Doesn't 2 apply if no package list is given for dnf update? > Hm, well, in case of upgrade some version of the given package is already installed so literally no (because the already installed version can be installed :-) ). But let's say that we both are correct because upgrade is kind of special in this case. We can think about changing the upgrade command to be consistent with the install command if there is a demand to do that but so far I'm fine with the current situation. I think that in case of upgrade, it's more common to ask to upgrade as much as you can while in case of install, users/scripts prefer to install everything or fail otherwise. Moreover I think that the change could annoy a lot of users. So, let's say that (1) applies in both cases, (2) doesn't apply in case of install and both does and doesn't (depending on the point of view) apply in case of upgrade :-) -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
remedy for depcheck inferior architecture issue
I see people asking on #fedora-devel or #fedora-admin about depcheck inferior architecture issue [1] quite often. Most of them are very confused. Last time I saw someone asking about this was tonight [2]. We're not able fix this easily, but I think we should finally at least put some temporary measures to "work around" this issue and stop confusing people that much, or least start explaining better what this is and what it means. I have the following ideas: 1. In depcheck, detect if the output has "inferior architecture" substring and add an explanatory note, like this: not ok - depcheck for Bodhi update xforms-1.2.4-2.fc22 # FAIL --- arch: x86_64 details: output: |- Build xforms-1.2.4-2.fc22 failed depcheck package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = 1.2.4-2.fc22, but none of the providers can be installed xforms-1.2.4-2.fc22.i686 has inferior architecture xforms-1.2.4-2.fc22.i686 has inferior architecture package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = 1.2.4-2.fc22, but none of the providers can be installed xforms-1.2.4-2.fc22.i686 has inferior architecture xforms-1.2.4-2.fc22.i686 has inferior architecture PLEASE NOTE : This failure is most probably invalid, caused by a bug we weren't able to fix yet: https://phab.qadevel.cloud.fedoraproject.org/T366 . Please test you package dependencies manually and if everything looks correct, ignore this error. We're sorry for this inconvenience. item: xforms-1.2.4-2.fc22 outcome: FAILED summary: xforms-1.2.4-2.fc22 into F22 testing type: bodhi_update ... 2. Do not submit this result (I'm mostly concerned about Bodhi, but there's no easy way to disconnect ResultsDB reporting from Bodhi reporting, so it would affect both systems). That can be done by filtering out "inferior architecture" CheckDetails at the end of the depcheck run, before the final TAP is generated. We would print these CheckDetails to stdout instead, so that the results would still be visible in the log. 3. Alternatively to 2), Josef proposed setting these results to ABORTED instead of FAILED. They would still show up in ResultsDB, and they would be easy to search for (we'll need to fix T458, but we'll need to fix that anyway). I've went through bodhi_comment_directive, and I believe it will report the ABORTED outcome to Bodhi the same way as any other outcome. I'd prefer either not to report ABORTED at all, or least not send emails for them. But either way, saying ABORTED is a bit less confusing than FAILED. And if we add the explanatory note as suggested in 1), it could be a substantial improvement. I think I prefer this to 2). What do you think? Any better suggestions? [1] https://phab.qadevel.cloud.fedoraproject.org/T366 [2] https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/56193/steps/runtask/logs/stdio ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: An everyday tale of dnf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 hi Yup, will do. Yeah, I figured it was the plugins, not dnf itself. I may need to remove the offending plugins, if I can figure out which ones cause the error. As for reviewing the thread, all I can do is read the emails. If the history isn't there, I'm not sure how else to do it. Thanks Kendell clark Sent from Fedora GNU/Linux Jan Zelený wrote: > On 9. 4. 2015 at 03:19:02, kendell clark wrote: >> hi I'll add my two cents in. I've had few problems with dnf. That >> being said, I usually get an error after every install/update >> that goes something like, snapper. Could not create snapshot >> error.unknown config: /org.freedesktop.dbus.error. This is not >> exact, I can get exact if needed. I'm assuming the snapshot >> plugin might be broken, or still be in development. I sometimes >> get a much more serious error that I solved once, but now can't >> remember how. Sometimes when I go to do anything with dnf, I get >> an error of, error. Repository "local" is listed more than once >> in the configuration." And dnf immediately returns me to my >> prompt. This not only affects dnf when run from the command line, >> but also appears to affect gnome software, which presumably uses >> it. I hope to be able to help fix these issues by f22's release. >> I'll gladly provide any needed info. Thanks Kendell clark Sent >> from Fedora GNU/Linux > > Please review the entire thread, I believe you are hitting the very > same issue that was thoroughly analyzed and solved here. Once > again, dnf is not to be blamed here, the issues are in the > individual plugins you have installed. > > Thanks Jan > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVJjnlAAoJEGYgJ5/kqBTdo8kP/3fBP24GqmALIXWiKc59cVV/ dS+AufjzQ2hGza8VBUG0ZxZrt+Hk8fUgRiXHvYrgVKfrcLtCnFom9kS4E9WLiq06 D7drf1gJ/y4BMYTA2hOpJ70+/PLuDdvZFcD7at2aEwEssPM7Whyz9jaK4yNmQjJP 05ltuTNhCZaanv42oQKHyvok8qTlo0UjmPxlk63IwnIDo4U5zzuAo+IS8vMj70ly NyZELthWaZw4Not/mivENu7SgLi1cd0er6n1cAs3UhHrQOkkyIboNU2SYe7wsdd4 P8Mo3wQY2pPevWgJYaWZT7cLICRMCmHoKOCF8ga9hJkinA1A4glTG6vCH7wtZzAL gakGvgB9SYjBmfRo8X4oxrrAj46hJuENpIzixbmwxR5GrxWpHoL/EcaXwsEA5k2M JN53tHteDWEfjFyf47Soy7Cwe6+xucGJaioC8VnI0+zHts51eyo6DCOikUmOzoXF YTlDYxFExKMbSpvfaZ9i1Ne28jHBSq7gCjCDzFY9tGZeAyAWJBxkq0DumqWVdm+Y e10TX6EFqntRXvWBo7M+kmGjAnc8DY/IoJbpeDyv0jBSibg30ToebUnx1fMXeoaD RA/+nH4AzpY4RT9f/oEtScKUM1gKQjtvWrJW8jGbr4m0YbyQmzObJrP6CvNtO+h1 End9UUgIrMW1iu8L+Jkc =uodP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
Am 09.04.2015 um 10:28 schrieb Jan Zelený: On 9. 4. 2015 at 03:19:02, kendell clark wrote: hi I'll add my two cents in. I've had few problems with dnf. That being said, I usually get an error after every install/update that goes something like, snapper. Could not create snapshot error.unknown config: /org.freedesktop.dbus.error. This is not exact, I can get exact if needed. I'm assuming the snapshot plugin might be broken, or still be in development. I sometimes get a much more serious error that I solved once, but now can't remember how. Sometimes when I go to do anything with dnf, I get an error of, error. Repository "local" is listed more than once in the configuration." And dnf immediately returns me to my prompt. This not only affects dnf when run from the command line, but also appears to affect gnome software, which presumably uses it. I hope to be able to help fix these issues by f22's release. I'll gladly provide any needed info. Thanks Kendell clark Sent from Fedora GNU/Linux Please review the entire thread, I believe you are hitting the very same issue that was thoroughly analyzed and solved here. Once again, dnf is not to be blamed here, the issues are in the individual plugins you have installed not really snapper could simply realize that it can't work as example on ext4 and just be a NOP operatin doing nothing in that case signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
On 9. 4. 2015 at 03:19:02, kendell clark wrote: > hi > I'll add my two cents in. I've had few problems with dnf. That being > said, I usually get an error after every install/update that goes > something like, snapper. Could not create snapshot error.unknown > config: /org.freedesktop.dbus.error. This is not exact, I can get > exact if needed. I'm assuming the snapshot plugin might be broken, or > still be in development. I sometimes get a much more serious error > that I solved once, but now can't remember how. Sometimes when I go to > do anything with dnf, I get an error of, error. Repository "local" is > listed more than once in the configuration." And dnf immediately > returns me to my prompt. This not only affects dnf when run from the > command line, but also appears to affect gnome software, which > presumably uses it. I hope to be able to help fix these issues by > f22's release. I'll gladly provide any needed info. > Thanks > Kendell clark > Sent from Fedora GNU/Linux Please review the entire thread, I believe you are hitting the very same issue that was thoroughly analyzed and solved here. Once again, dnf is not to be blamed here, the issues are in the individual plugins you have installed. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 hi I'll add my two cents in. I've had few problems with dnf. That being said, I usually get an error after every install/update that goes something like, snapper. Could not create snapshot error.unknown config: /org.freedesktop.dbus.error. This is not exact, I can get exact if needed. I'm assuming the snapshot plugin might be broken, or still be in development. I sometimes get a much more serious error that I solved once, but now can't remember how. Sometimes when I go to do anything with dnf, I get an error of, error. Repository "local" is listed more than once in the configuration." And dnf immediately returns me to my prompt. This not only affects dnf when run from the command line, but also appears to affect gnome software, which presumably uses it. I hope to be able to help fix these issues by f22's release. I'll gladly provide any needed info. Thanks Kendell clark Sent from Fedora GNU/Linux Igor Gnatenko wrote: > probably you are right. I will take a care tomorrow > > On Thu, Apr 9, 2015 at 9:49 AM, Jan Zelený > wrote: >> FYI dnf-plugins-extras is a package that aggregates all plugins >> that the community produces. Bottom line, please don't blame >> dnf, blame the individual plugins. >> >> Reading your problem and couple other just like it I think it >> might make sense not to have the dnf-plugins-extras metapackage >> that installs all the plugins automatically. It seems to be only >> upsetting people when one (often not the desired one) plugin >> breaks everything else. I'm CCing Igor to consider this >> proposal. >> >> Thanks Jan >> >> On 8. 4. 2015 at 12:14:17, Tom Hughes wrote: >>> So this morning I cloned an up to date rawhide VM and >>> attempted to convert it to F22 by using "dnf distro-sync" on >>> it. Obviously that is a fairly advanced use case but I think >>> one tale of what happened at the end of that process will >>> highlight why I often find myself shouting WTF at dnf when >>> going beyond basic install/update of packages. There were other >>> issues along the way before I got to this point... >>> >>> Having eventually completed the distro-sync I wanted to check >>> for any orphans that needed sorting out. Google told me >>> dnf-plugins-extras was that I needed to replace >>> package-cleanup, so I installed it, only to find that every >>> use of dnf now reported: >>> >>> fedora22 [~] % sudo dnf upgrade Failed to synchronize cache >>> for repo '_local' from 'file:///var/lib/dnf/plugins/local': >>> Cannot download repomd.xml: Cannot download >>> repodata/repomd.xml: All mirrors were tried, disabling. >>> >>> After shouting WTF yet again I determined that >>> dnf-plugins-extras includes python-dnf-plugins-extras-local >>> which apparently tries to use a non-existent local directory >>> as a hidden extra repo. >>> >>> Fine whatever, we don't need that, so lets remove it: >>> >>> fedora22 [~] % sudo dnf erase python-dnf-plugins-extras-local >>> Dependencies resolved. >>> >> = === >>> >> >> PackageArchVersion >>> Repository Size >>> >> = == >>> >> >> = Removing: >>> dnf-plugins-extras noarch 0.0.6-2.fc22 >>> @System 0 python-beautifulsoup4 noarch >>> 4.3.2-3.fc21 @System 605 k python-dnf-plugins-extras noarch >>> 0.0.6-2.fc22 @System0 python-dnf-plugins-extras-debug >>> noarch 0.0.6-2.fc22 @System 26 k >>> python-dnf-plugins-extras-localnoarch 0.0.6-2.fc22 >>> @System 11 k python-dnf-plugins-extras-orphans noarch >>> 0.0.6-2.fc22 @System 9.3 k >>> python-dnf-plugins-extras-repoclosure noarch 0.0.6-2.fc22 >>> @System 9.4 k python-dnf-plugins-extras-repograph noarch >>> 0.0.6-2.fc22 @System 9.5 k >>> python-dnf-plugins-extras-repomanage noarch 0.0.6-2.fc22 >>> @System 12 k python-dnf-plugins-extras-snapper noarch >>> 0.0.6-2.fc22 @System 4.4 k python-dnf-plugins-extras-tracer >>> noarch 0.0.6-2.fc22 @System 7.7 k python-html5lib noarch >>> 1:0.999-5.fc21 @System 1.2 M python-psutil x86_64 >>> 2.1.3-1.fc22 @System 518 k snapper x86_64 0.2.5-2.fc22 >>> @System 1.0 M snapper-libs x86_64 0.2.5-2.fc22 @System >>> 846 k tracer noarch 0.5.8-1.fc22 @System 272 k >>> >>> Transaction Summary >>> >> = === >>> >> >> Remove 16 Packages >>> >>> Installed size: 4.5 M Is this ok [y/N]: y >>> >>> WTF! Oh, of course, removing that removes dnf-plugins-extras >>> and then everything else counts as auto installed and gets >>> removed. After ceasing banging my head on the desk I let it go >>> ahead and then add back python-dnf-plugins-extras-orphans to >>> get the plugin I actually wanted. >>> >>> So now I run "dnf orphans" at last and am a little sur
Re: An everyday tale of dnf
probably you are right. I will take a care tomorrow On Thu, Apr 9, 2015 at 9:49 AM, Jan Zelený wrote: > FYI dnf-plugins-extras is a package that aggregates all plugins that the > community produces. Bottom line, please don't blame dnf, blame the individual > plugins. > > Reading your problem and couple other just like it I think it might make sense > not to have the dnf-plugins-extras metapackage that installs all the plugins > automatically. It seems to be only upsetting people when one (often not the > desired one) plugin breaks everything else. I'm CCing Igor to consider this > proposal. > > Thanks > Jan > > On 8. 4. 2015 at 12:14:17, Tom Hughes wrote: >> So this morning I cloned an up to date rawhide VM and attempted to convert >> it to F22 by using "dnf distro-sync" on it. Obviously that is a fairly >> advanced use case but I think one tale of what happened at the end of that >> process will highlight why I often find myself shouting WTF at dnf when >> going beyond basic install/update of packages. There were other issues >> along the way before I got to this point... >> >> Having eventually completed the distro-sync I wanted to check for any >> orphans that needed sorting out. Google told me dnf-plugins-extras was that >> I needed to replace package-cleanup, so I installed it, only to find that >> every use of dnf now reported: >> >> fedora22 [~] % sudo dnf upgrade >> Failed to synchronize cache for repo '_local' from >> 'file:///var/lib/dnf/plugins/local': Cannot download repomd.xml: Cannot >> download repodata/repomd.xml: All mirrors were tried, disabling. >> >> After shouting WTF yet again I determined that dnf-plugins-extras includes >> python-dnf-plugins-extras-local which apparently tries to use a non-existent >> local directory as a hidden extra repo. >> >> Fine whatever, we don't need that, so lets remove it: >> >> fedora22 [~] % sudo dnf erase python-dnf-plugins-extras-local >> Dependencies resolved. >> > >> PackageArchVersion >> Repository Size >> > === >> = Removing: >> dnf-plugins-extras noarch 0.0.6-2.fc22 @System >> 0 python-beautifulsoup4 noarch 4.3.2-3.fc21 @System >> 605 k python-dnf-plugins-extras noarch 0.0.6-2.fc22 >> @System0 python-dnf-plugins-extras-debugnoarch 0.0.6-2.fc22 >> @System 26 k python-dnf-plugins-extras-localnoarch 0.0.6-2.fc22 >> @System 11 k python-dnf-plugins-extras-orphans noarch >> 0.0.6-2.fc22 @System 9.3 k python-dnf-plugins-extras-repoclosure >> noarch 0.0.6-2.fc22 @System 9.4 k python-dnf-plugins-extras-repograph >>noarch 0.0.6-2.fc22 @System 9.5 k >> python-dnf-plugins-extras-repomanage noarch 0.0.6-2.fc22 @System >> 12 k python-dnf-plugins-extras-snapper noarch 0.0.6-2.fc22 >> @System 4.4 k python-dnf-plugins-extras-tracer noarch 0.0.6-2.fc22 >>@System 7.7 k python-html5libnoarch >> 1:0.999-5.fc21 @System 1.2 M python-psutil >> x86_64 2.1.3-1.fc22 @System 518 k snapper >>x86_64 0.2.5-2.fc22 @System 1.0 M snapper-libs >> x86_64 0.2.5-2.fc22 @System 846 k tracer >> noarch 0.5.8-1.fc22 @System 272 k >> >> Transaction Summary >> > >> Remove 16 Packages >> >> Installed size: 4.5 M >> Is this ok [y/N]: y >> >> WTF! Oh, of course, removing that removes dnf-plugins-extras and then >> everything else counts as auto installed and gets removed. After ceasing >> banging my head on the desk I let it go ahead and then add back >> python-dnf-plugins-extras-orphans to get the plugin I actually wanted. >> >> So now I run "dnf orphans" at last and am a little surprised to get 589 >> lines of output: >> >> fedora22 [~] % sudo dnf orphans >> CharLS-devel-1.0-8.fc22.x86_64 >> ... >> zsh-5.0.7-6.fc22.x86_64 >> >> But those are F22 packages I hear you say! Indeed they are, and list >> confirms that they do exist in configured repositories: >> >> fedora22 [~] % sudo dnf list --showduplicates zsh >> Using metadata from Wed Apr 8 11:02:28 2015 (0:53:45 hours old) >> Installed Packages >> zsh.x86_64 5.0.7-6.fc22@System >> Available Packages >> zsh.x86_64 5.0.7-6.fc22@System >> zsh.x86_64 5.0.7-6.fc22 >> fedora-base >> >> WTF! >> >> Tom -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Moving Docker image under Cloud edition?
2015-04-09 0:41 GMT+02:00 Dennis Gilmore : > On Wednesday, April 08, 2015 01:36:11 PM Joe Brockmeier wrote: > > Hey all, > > > > Currently the Docker image is located on the Spins page, on the sidebar. > > I know we also put the images in Docker Hub, but I'd like to pull this > > under the Cloud pages and start rolling up promotion of the Docker image > > with the Cloud edition. > > > > Thoughts, comments, flames? > > the docker base image is part of the Base WG. so it seems wrong to put it > on > the Cloud page, but we should do something to advertise it more. > > Dennis > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > I substantially agree with Dennis, Docker is not a product and can be used for many purposes, so getfedora.org is not really an option. We (websites) put Docker (but also ARM) temporary on spins.fpo because we hadn't any better place to promote it. We are already working on redesigning spins.fedoraproject.org and to give ARM and Docker a better place where to live. You can look at the webticket #315 to know more. [1] https://fedorahosted.org/fedora-websites/ticket/315 -- Robert Mayr (robyduck) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2015-04-09)
WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Follow-ups Dockah * Dockerfiles recommended tips * Dockerfile lint * Dockerfiles revisiting * Open Floor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
