[Test-Announce] Fedora 22 Release Candidate 1 (RC1) Available Now!
As per the Fedora 22 schedule [1], Fedora 22 Beta Release Candidate 1 (RC1) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6132#comment:15.Please see the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. For the Fedora 22 cycle we are also trying to run the Final tests at this time, to try and identify later release blocker bugs as early as possible. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 22 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6132 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: How to build one TeXLive subpackage for EPEL-7?
On 2015-04-08, 01:06 GMT, Jason L Tibbitts III wrote: > Just package it separately. They should all have proper upstream > tarballs, and there's no reason not to just make individual packages if > that's what you need. And, hey, while you're at it, stick them in > rawhide and make the texlive package not generate them at all. Anything > that gets split out of texlive into proper packages is a win. Cutting up texlive monster piece by piece seems like rather lousy idea to me. After all that long thread about texlive which just happened here I am afraid dealing with the monster must be done in some more sensible and organized matter. Anyway, I'll try to make a special EPEL package for it. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Don't anthropomorphize computers. They don't like it. -- 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 debug-info-install
Dne 7.4.2015 v 15:39 Jan Kratochvil napsal(a): > On Tue, 07 Apr 2015 14:51:49 +0200, Vít Ondruch wrote: >> Dne 7.4.2015 v 14:25 Michael Catanzaro napsal(a): >>> On Tue, 2015-04-07 at 14:15 +0200, Vít Ondruch wrote: Dne 7.4.2015 v 14:09 Michael Catanzaro napsal(a): > I want 'dnf debug-info-install' to be available by default on > Workstation. Sorry for my ignorance, but why it should be installed by default? >>> Because gdb recommends you use it whenever it detects that debuginfo >>> is missing. :-) >> Then I have the same question with regards to GDB. Although I consider >> my computer to be development computer and I probably have GDB >> installed, I'd be much happier if it is not the case. > Not to suggest how to fix missing crashed source line + context > backtrace/parameters after a system library crashes due to wrong parameters > passed from application under development? This has always been a FAQ for GDB > so the suggestion has been added and now only non-Fedora GDB users ask about > it. > > > Jan 1) As a Ruby developer, I typically don't care much about GDB 2) In days of virtualization, containers, vagrant, etc your runtime environment is not necessary directly your development machine. I can assure you that for example, I don't have gcc installed directly on my system and it is just fine (although it might sound strange to some parties). Vít -- 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: How to build one TeXLive subpackage for EPEL-7?
On Wed, Apr 8, 2015 at 12:30 AM, Matěj Cepl wrote: > On 2015-04-08, 01:06 GMT, Jason L Tibbitts III wrote: >> Just package it separately. They should all have proper upstream >> tarballs, and there's no reason not to just make individual packages if >> that's what you need. And, hey, while you're at it, stick them in >> rawhide and make the texlive package not generate them at all. Anything >> that gets split out of texlive into proper packages is a win. > > Cutting up texlive monster piece by piece seems like rather > lousy idea to me. After all that long thread about texlive which > just happened here I am afraid dealing with the monster must be > done in some more sensible and organized matter. > > Anyway, I'll try to make a special EPEL package for it. > > Matěj > -- > http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz > GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC > > Don't anthropomorphize computers. They don't like it. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct One reason I'm building my OSJourno Docker images on Fedora and not the more popular and theoretically more stable CentOS is that EPEL doesn't have a few LaTeX packages I need. Sometime when I run out of more pressing things to fix, I'm going to try texlive-texliveonfly to see if it can find and install missing LaTeX packages. Seriously, texlive is huge - if you install *everything* IIRC you have something like 4 GB just for texlive! So there's every reason to want to install a minimal texlive and install packages on an as-needed basis. And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint. -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- 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: appdata validation and too long
On 7 April 2015 at 23:23, Bruno Wolff III wrote: > The hedgewars appdata file from upstream is getting flagged as invalid by > rpmlint. I checked with appdata-validate and get the following: > appdata-validate -v /usr/share/appdata/hedgewars.appdata.xml > /usr/share/appdata/hedgewars.appdata.xml 1 problems detected: > • style-invalid : is too long > > What is the limit on the size of list elements? For normal validation, it's 20 Does this really break anything or can I just leave it? A style warning is just that; it's going to look a little different to most other apps but with no real harm. If you use: appstream-util validate-relax usr/share/appdata/hedgewars.appdata.xml ...then the style warnings go away, and this is probably what you want to use if you're using it in a .spec file. I hope that helps, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150408 changes
Compose started at Wed Apr 8 05:15:03 UTC 2015 Broken deps for i386 -- [Agda-stdlib] ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires libHSinteger-gmp-0.5.0.0-ghc7.6.3.so ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires libHSghc-prim-0.3.0.0-ghc7.6.3.so ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires libHSbase-4.6.0.1-ghc7.6.3.so ghc-agda-lib-ffi-0.0.2-5.fc22.i686 requires ghc(base-4.6.0.1-ced5f3d8c90960e9f372129163296e44) ghc-agda-lib-ffi-devel-0.0.2-5.fc22.i686 requires ghc-devel(base-4.6.0.1-ced5f3d8c90960e9f372129163296e44) ghc-agda-lib-ffi-devel-0.0.2-5.fc22.i686 requires ghc-compiler = 0:7.6.3 ghc-agda-lib-ffi-devel-0.0.2-5.fc22.i686 requires ghc-compiler = 0:7.6.3 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [aunit] aunit-2013-7.fc22.i686 requires libgnat-4.9.so [aws] aws-3.1.0-12.fc22.i686 requires libgnat-4.9.so aws-3.1.0-12.fc22.i686 requires libgnarl-4.9.so aws-devel-3.1.0-12.fc22.i686 requires libgnat-4.9.so aws-devel-3.1.0-12.fc22.i686 requires libgnarl-4.9.so [bro] broccoli-2.3-1.fc22.i686 requires bro-2.3 python-broccoli-2.3-1.fc22.i686 requires bro-2.3 [bustle] bustle-0.4.8-1.fc23.i686 requires libHSdbus-0.10.8-ghc7.8.4.so bustle-0.4.8-1.fc23.i686 requires ghc(dbus-0.10.8-ca372b3d5372ab2e67a5ef78d0f32f75) [crystal] crystal-2.2.1-2.fc22.i686 requires libkdecorations.so.4 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dsqlite] dsqlite-1.1.1-5.fc22.i686 requires libphobos-ldc.so.64 [elk] elk-mpich-2.3.22-10.fc22.i686 requires libopa.so.1 elk-mpich-2.3.22-10.fc22.i686 requires libmpl.so.1 elk-mpich-2.3.22-10.fc22.i686 requires libmpichf90.so.12 elk-mpich-2.3.22-10.fc22.i686 requires libmpich.so.12 [fawkes] fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_thread.so.1.55.0 fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_system.so.1.55.0 fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_signals.so.1.55.0 [florist] florist-2011-16.fc22.i686 requires libgnat-4.9.so florist-2011-16.fc22.i686 requires libgnarl-4.9.so [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [git-annex] git-annex-5.20140717-5.fc23.i686 requires libHSdbus-0.10.8-ghc7.8.4.so git-annex-5.20140717-5.fc23.i686 requires libHSQuickCheck-2.6-ghc7.8.4.so git-annex-5.20140717-5.fc23.i686 requires ghc(dbus-0.10.8-ca372b3d5372ab2e67a5ef78d0f32f75) git-annex-5.20140717-5.fc23.i686 requires ghc(QuickCheck-2.6-8a12668f63418b314ed544171a63db12) [gl3n] gl3n-0.20140505-13.fc22.i686 requires libphobos-ldc.so.64 [gnatcoll] gnatcoll-2013-9.fc22.i686 requires libgnat-4.9.so gnatcoll-2013-9.fc22.i686 requires libgnarl-4.9.so [gnome-chemistry-utils] gnome-chemistry-utils-gnumeric-0.14.10-5.fc23.i686 requires libspreadsheet-1.12.20.so [gpaw] gpaw-mpich-0.10.0.11364-9.fc22.i686 requires libopa.so.1 gpaw-mpich-0.10.0.11364-9.fc22.i686 requires libmpl.so.1 gpaw-mpich-0.10.0.11364-9.fc22.i686 requires libmpich.so.12 [gromacs] gromacs-mpich-4.6.5-5.fc22.i686 requires libopa.so.1 gromacs-mpich-4.6.5-5.fc22.i686 requires libmpl.so.1 gromacs-mpich-4.6.5-5.fc22.i686 requires libmpich.so.12 gromacs-mpich-libs-4.6.5-5.fc22.i686 requires libopa.so.1 gromacs-mpich-libs-4.6.5-5.fc22.i686 requires libmpl.so.1 gromacs-mpich-libs-4.6.5-5.fc22.i686 requires libmpich.so.12 [hadoop] hadoop-common-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hadoop-hdfs-2.4.1-6.fc22.noarch requires mvn(org.jboss.netty:netty:3.6.6.Final) hadoop-hdfs-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hadoop-
Re: dnf replacing yum and dnf-yum
Dne 8.4.2015 v 08:41 Jan Zelený napsal(a): > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote: >>> On Tue, 7 Apr 2015 08:38:57 -0500 >>> >>> Bruno Wolff III wrote: On Tue, Apr 07, 2015 at 10:22:25 -0300, Paulo César Pereira de Andrade wrote: > I had also switched back to yum in rawhide due to --skip-broken, > > and > in a few updates not even needing it (I would first see what is > broken, and if not something "vital", use --skip-broken), while dnf > would just fail with cryptic messages. I can keep up if kde or gnome > is broken, or some other stuff that does not prevent boot and a > functional system. dnf really does need --skip-broken like support if it is to replace yum. yum can be a lot faster than the needed work around to get dnf to work equivalently. I am considering going back to yum in rawhide rather than continuig to test dnf in rawhide because of this issue. >>> dnf's default behavior is like yum with --skip-broken already. >> WHAT? >> >> --skip-broken is a band-aid to work around packaging mistakes and bugs >> and NOT be the default. >> >> IMO, this kind of behavior is not helpful and therefore should be reverted. > This behavior is actually helpful, as it doesn't bother users with a bunch of > broken deps messages they usually don't fully understand (check out how many > of these bugs were filed against yum over the years). > > Putting the opinion of myself and the dnf team aside, I'd like to point out > that the information you want is still available - dnf check-update will show > you all the updates, even those that have broken deps. Running this command > right after dnf upgrade will list you those that could not be installed. > > Thanks > Jan Is there chance to have --skip-broken enabled/disabled for certain repositories? For example, you probably want to use --skip-broken for "updates", while you don't want to use it for "updates-testing" or "rawhide", since in there repositories, the bugs should be caught and removed. Vít -- 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
Am 08.04.2015 um 08:41 schrieb Jan Zelený: On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: On 04/07/2015 05:07 PM, Kevin Fenzi wrote: On Tue, 7 Apr 2015 08:38:57 -0500 Bruno Wolff III wrote: On Tue, Apr 07, 2015 at 10:22:25 -0300, Paulo César Pereira de Andrade wrote: I had also switched back to yum in rawhide due to --skip-broken, and in a few updates not even needing it (I would first see what is broken, and if not something "vital", use --skip-broken), while dnf would just fail with cryptic messages. I can keep up if kde or gnome is broken, or some other stuff that does not prevent boot and a functional system. dnf really does need --skip-broken like support if it is to replace yum. yum can be a lot faster than the needed work around to get dnf to work equivalently. I am considering going back to yum in rawhide rather than continuig to test dnf in rawhide because of this issue. dnf's default behavior is like yum with --skip-broken already. WHAT? --skip-broken is a band-aid to work around packaging mistakes and bugs and NOT be the default. IMO, this kind of behavior is not helpful and therefore should be reverted. This behavior is actually helpful, as it doesn't bother users with a bunch of broken deps messages they usually don't fully understand (check out how many of these bugs were filed against yum over the years). well, check out how many bugs where filed for the correct component that default don't solve any problem, it's just put the head in the sand and burry it Putting the opinion of myself and the dnf team aside, I'd like to point out that the information you want is still available - dnf check-update will show you all the updates, even those that have broken deps. Running this command right after dnf upgrade will list you those that could not be installed the world don't work that way *nobody* even not myself would call "dnf check-update" after "dnf upgrade" installed updates and did not complain about anything 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: dnf debug-info-install
On Wed, 08 Apr 2015 09:52:46 +0200, Vít Ondruch wrote: > 2) In days of virtualization, containers, vagrant, etc your runtime > environment is not necessary directly your development machine. Yes, Gary Benson is working on integrating gdbserver and GDB for these scenarios. Although I am not sure how the debuginfos for target system should become available on the development (host) machine. ABRT does so with chroots. 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
On 7 April 2015 at 17:37, Adam Williamson wrote: > This is easier said than done. We don't have a perfect dependency > checker and it's not at all easy to write one. From someone that's actually written a yum-compatible dependency checker in C several years ago[1] I can attest that the --skip-broken flag is really only a work around for repositories being pushed while broken, or the depsolver being broken by design. We tried using --skip-broken by default in PackageKit a few years ago and it was basically a disaster. A "simple" iterative depsolver like yum has needs so many special cases that it becomes a maze of code making pretty random decisions, requiring spurious manual deps added to packages when upgrade issues were found. Ten years ago cleverer people than me decided that SAT-based solvers were the only thing that made logical sense, which is what hawkey uses via the libsolv library. PackageKit in F22 uses hawkey, and the code is predictable and stable, which is a long way from what we had with the yum depsolver. To those mis-remembering how awesome the yum depsolver was: it really wasn't. Richard [1] https://github.com/hughsie/zif -- 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 Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson wrote: > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote: >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald > > wrote: >> > >> > >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius: >> > > >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote: >> > > > >> > > > dnf's default behavior is like yum with --skip-broken already. >> > > >> > > >> > > WHAT? >> > > >> > > --skip-broken is a band-aid to work around packaging mistakes >> > > and bugs >> > > and NOT be the default. >> > > >> > > IMO, this kind of behavior is not helpful and therefore should >> > > be reverted >> > >> > >> > +1 >> > >> > that's unacceptable and leads in burry *real* problems resulting >> > in sonner >> > or later security updates are broken and nobody take snotice soon >> > enough >> >> The bug is elsewhere though ... i.e. that is even possible to push >> updates with broken deps. >> Rawhide is a different story but everything that goes through bodhi >> (stable releases and branched) should simply refuse pushes with >> broken >> deps. > > This is easier said than done. We don't have a perfect dependency > checker and it's not at all easy to write one. tflink and John Dulaney > have more details if you're interested, but yes, this is not a trivial > thing we can just wave a wand and make happen. 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. -- 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
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. -- 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: How to build one TeXLive subpackage for EPEL-7?
On 2015-04-08, 08:12 GMT, M. Edward (Ed) Borasky wrote: > And I'm curious why there are texlive packages in Fedora that > aren't in EPEL - I assume it's a human or machine resource constraint. Not in EPEL, but in the RHEL-7. Obviously Red Hat delivers only a subset of whole TeXLive. Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC "Push to test." (click) "Release to detonate..." -- from a bugzilla quip list -- 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 Wed, 8 Apr 2015 at 11:05 drago01 wrote: > On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson > wrote: > > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote: > >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald >> > wrote: > >> > > >> > > >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius: > >> > > > >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote: > >> > > > > >> > > > dnf's default behavior is like yum with --skip-broken already. > >> > > > >> > > > >> > > WHAT? > >> > > > >> > > --skip-broken is a band-aid to work around packaging mistakes > >> > > and bugs > >> > > and NOT be the default. > >> > > > >> > > IMO, this kind of behavior is not helpful and therefore should > >> > > be reverted > >> > > >> > > >> > +1 > >> > > >> > that's unacceptable and leads in burry *real* problems resulting > >> > in sonner > >> > or later security updates are broken and nobody take snotice soon > >> > enough > >> > >> The bug is elsewhere though ... i.e. that is even possible to push > >> updates with broken deps. > >> Rawhide is a different story but everything that goes through bodhi > >> (stable releases and branched) should simply refuse pushes with > >> broken > >> deps. > > > > This is easier said than done. We don't have a perfect dependency > > checker and it's not at all easy to write one. tflink and John Dulaney > > have more details if you're interested, but yes, this is not a trivial > > thing we can just wave a wand and make happen. > > 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. > > It is not so simple, you have to test all combinations for packages requiring an updated package and all the packages there requires someting provided by previous version of the package, with thousend of packages and multiple packages providing the same stuff, it is an almost impossible task. 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
An everyday tale of dnf
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 @System0 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-repographnoarch 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 snapperx86_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.fc22fedora-base WTF! 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
F-22 Branched report: 20150408 changes
Compose started at Wed Apr 8 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: An everyday tale of dnf
Haha, sounds like a fun experience. I've not used dnf for many complex tasks, but it sounds interesting. On Wed, Apr 8, 2015, 7:14 AM 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 @System > 0 > 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-repographnoarch 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 > snapperx86_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 > > -- > 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 -- 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: How to build one TeXLive subpackage for EPEL-7?
On 04/08/2015 03:06 AM, Jason L Tibbitts III wrote: "MC" == Matěj Cepl writes: MC> Now, the question is how to build just one subpackage (or any MC> required other subpackages) from the monstrosity which the current MC> texlive? Anybody any suggestions? Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win. +1 That's similar to the way we had split perl into pieces years ago. Ralf -- 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: devel@lists.fedoraproject.org > Sent: Tuesday, April 7, 2015 5:51:41 PM > Subject: Re: dnf replacing yum and dnf-yum > > On Tue, Apr 07, 2015 at 09:07:08 -0600, > Kevin Fenzi wrote: > > > >dnf's default behavior is like yum with --skip-broken already. This recurrent half-truth causes so much confusion. I'd like to ask everyone not to repeat it. Or at least also point to http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#no-skip-broken please. > Not when installing packages. 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 DNF does only (1) by default (and it can be disabled by --best). And it does it during both upgrades and installations. But only if the requested "pkg-spec" matches multiple packages. If the given "pkg-spec" is unique (e.g. foo-1-0.fc21.noarch) and the matching package cannot be installed, DNF fails. (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. > > > >If thats not working and you need to find out more, add '--best' to see > >things without 'skip-broken'. > > My understanding is that --best can erase stuff (outside of obsoletes) > and I don't want to do that in scripts. > > >If that still doesn't work, please file a bug. ;) > > I have already filed some bugs and RFEs since dnf replaced yum in rawhide, > including about needing --skip-broken like functionallity for installs. -- 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
On 8. 4. 2015 at 11:05:20, drago01 wrote: > On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson > > wrote: > > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote: > >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald >> > >> > wrote: > >> > > >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius: > >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote: > >> > > > dnf's default behavior is like yum with --skip-broken already. > >> > > > >> > > WHAT? > >> > > > >> > > --skip-broken is a band-aid to work around packaging mistakes > >> > > and bugs > >> > > and NOT be the default. > >> > > > >> > > IMO, this kind of behavior is not helpful and therefore should > >> > > be reverted > >> > > >> > +1 > >> > > >> > that's unacceptable and leads in burry *real* problems resulting > >> > in sonner > >> > or later security updates are broken and nobody take snotice soon > >> > enough > >> > >> The bug is elsewhere though ... i.e. that is even possible to push > >> updates with broken deps. > >> Rawhide is a different story but everything that goes through bodhi > >> (stable releases and branched) should simply refuse pushes with > >> broken > >> deps. > > > > This is easier said than done. We don't have a perfect dependency > > checker and it's not at all easy to write one. tflink and John Dulaney > > have more details if you're interested, but yes, this is not a trivial > > thing we can just wave a wand and make happen. > > 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. For the record, we are in touch with Fedora QA team about this and we will be helping them with improving the dependency checks. 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
On 8. 4. 2015 at 10:26:51, Reindl Harald wrote: > Am 08.04.2015 um 08:41 schrieb Jan Zelený: > > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: > >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote: > >>> On Tue, 7 Apr 2015 08:38:57 -0500 > >>> > >>> Bruno Wolff III wrote: > On Tue, Apr 07, 2015 at 10:22:25 -0300, > > Paulo César Pereira de Andrade > > wrote: > >I had also switched back to yum in rawhide due to --skip-broken, > > > > and > > in a few updates not even needing it (I would first see what is > > broken, and if not something "vital", use --skip-broken), while dnf > > would just fail with cryptic messages. I can keep up if kde or gnome > > is broken, or some other stuff that does not prevent boot and a > > functional system. > > dnf really does need --skip-broken like support if it is to replace > yum. yum can be a lot faster than the needed work around to get dnf > to work equivalently. I am considering going back to yum in rawhide > rather than continuig to test dnf in rawhide because of this issue. > >>> > >>> dnf's default behavior is like yum with --skip-broken already. > >> > >> WHAT? > >> > >> --skip-broken is a band-aid to work around packaging mistakes and bugs > >> and NOT be the default. > >> > >> IMO, this kind of behavior is not helpful and therefore should be > >> reverted. > > > > This behavior is actually helpful, as it doesn't bother users with a bunch > > of broken deps messages they usually don't fully understand (check out > > how many of these bugs were filed against yum over the years). > > well, check out how many bugs where filed for the correct component > > that default don't solve any problem, it's just put the head in the sand > and burry it > > > Putting the opinion of myself and the dnf team aside, I'd like to point > > out > > that the information you want is still available - dnf check-update will > > show you all the updates, even those that have broken deps. Running this > > command right after dnf upgrade will list you those that could not be > > installed > the world don't work that way > > *nobody* even not myself would call "dnf check-update" after "dnf > upgrade" installed updates and did not complain about anything You are right, people use it the other way - we have had reports stating that dnf check-update shows packages that dnf upgrade doesn't select. In other words, the information about broken updates is still available to the user. 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
On 04/08/2015 08:41 AM, Jan Zelený wrote: > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote: >>> dnf's default behavior is like yum with --skip-broken already. >> >> WHAT? >> >> --skip-broken is a band-aid to work around packaging mistakes and bugs >> and NOT be the default. >> >> IMO, this kind of behavior is not helpful and therefore should be reverted. > > This behavior is actually helpful, as it doesn't bother users with a bunch of > broken deps messages they usually don't fully understand (check out how many > of these bugs were filed against yum over the years). > > Putting the opinion of myself and the dnf team aside, I'd like to point out > that the information you want is still available - dnf check-update will show > you all the updates, even those that have broken deps. Running this command > right after dnf upgrade will list you those that could not be installed. Would it please be possible for "dnf update" to print this information automatically? E.g. apt-get can say "The following packages have been kept back: ..." dnf could report it like in this mockup: ... Dependencies resolved. PackageArch VersionRepository Size Upgrading: emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M emacs-common x86_64 1:24.4-6.fc21 updates-testing37 M emacs-filesystem noarch 1:24.4-6.fc21 updates-testing64 k Skipping for dependency reasons: firefoxx86_64 37.0.1-1.fc21 updates-testing69 M Transaction Summary Upgrade 3 Packages Skip 1 Package Total download size: ... Is this ok [y/N]: Thanks, Michal -- 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
Am 08.04.2015 um 14:39 schrieb Jan Zelený: On 8. 4. 2015 at 10:26:51, Reindl Harald wrote: Am 08.04.2015 um 08:41 schrieb Jan Zelený: Putting the opinion of myself and the dnf team aside, I'd like to point out that the information you want is still available - dnf check-update will show you all the updates, even those that have broken deps. Running this command right after dnf upgrade will list you those that could not be installed the world don't work that way *nobody* even not myself would call "dnf check-update" after "dnf upgrade" installed updates and did not complain about anything You are right, people use it the other way - we have had reports stating that dnf check-update shows packages that dnf upgrade doesn't select. In other words, the information about broken updates is still available to the user your repsonse is completly unclear "you are right", "people use it the other way", "updates is still available to the user" in combination makes no sense at all to make it clear: a in theory available option is worhless and just because you had reports of people using "dnf check-update" don't mean "people in general use it that way" i am pretty sure most people just use "yum upgrade" and that's it and i can't imagine why i should type "dnf check-update" at all when "yum upgrade" is supposed to give the same answer and finally needs just "y" for install them if available 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: dnf replacing yum and dnf-yum
On Wed, Apr 8, 2015 at 12:11 PM, Tim Lauridsen wrote: > > > On Wed, 8 Apr 2015 at 11:05 drago01 wrote: >> >> On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson >> wrote: >> > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote: >> >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald > >> > wrote: >> >> > >> >> > >> >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius: >> >> > > >> >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote: >> >> > > > >> >> > > > dnf's default behavior is like yum with --skip-broken already. >> >> > > >> >> > > >> >> > > WHAT? >> >> > > >> >> > > --skip-broken is a band-aid to work around packaging mistakes >> >> > > and bugs >> >> > > and NOT be the default. >> >> > > >> >> > > IMO, this kind of behavior is not helpful and therefore should >> >> > > be reverted >> >> > >> >> > >> >> > +1 >> >> > >> >> > that's unacceptable and leads in burry *real* problems resulting >> >> > in sonner >> >> > or later security updates are broken and nobody take snotice soon >> >> > enough >> >> >> >> The bug is elsewhere though ... i.e. that is even possible to push >> >> updates with broken deps. >> >> Rawhide is a different story but everything that goes through bodhi >> >> (stable releases and branched) should simply refuse pushes with >> >> broken >> >> deps. >> > >> > This is easier said than done. We don't have a perfect dependency >> > checker and it's not at all easy to write one. tflink and John Dulaney >> > have more details if you're interested, but yes, this is not a trivial >> > thing we can just wave a wand and make happen. >> >> 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. >> > > It is not so simple, you have to test all combinations for packages > requiring an updated package and all the packages there requires someting > provided by previous version of the package, with thousend of packages and > multiple packages providing the same stuff, it is an almost impossible task. Did you even read what I wrote? -- 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: Quick C++ question for C++ experts :)
On 02/04/15 10:34 +0100, Ian Malone wrote: Thanks. Hadn't occurred to me the + operator here was a template as I'd never had to deal with basic_string. Still a bit puzzled as cplusplus.com says string is an instantiation of basic_string while cppreference.com says it's a typedef (which I guess doesn't count as explicit instantiation). cplusplus.com is notoriously inaccurate. It probably means string is a specialization of basic_string. This is going very off-topic for this list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1209148] perl-MCE-1.605 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1209148 --- Comment #4 from Fedora Update System --- perl-MCE-1.605-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-MCE-1.605-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: dnf replacing yum and dnf-yum
On 8. 4. 2015 at 14:44:25, Michal Schmidt wrote: > On 04/08/2015 08:41 AM, Jan Zelený wrote: > > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: > >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote: > >>> dnf's default behavior is like yum with --skip-broken already. > >> > >> WHAT? > >> > >> --skip-broken is a band-aid to work around packaging mistakes and bugs > >> and NOT be the default. > >> > >> IMO, this kind of behavior is not helpful and therefore should be > >> reverted. > > > > This behavior is actually helpful, as it doesn't bother users with a bunch > > of broken deps messages they usually don't fully understand (check out > > how many of these bugs were filed against yum over the years). > > > > Putting the opinion of myself and the dnf team aside, I'd like to point > > out > > that the information you want is still available - dnf check-update will > > show you all the updates, even those that have broken deps. Running this > > command right after dnf upgrade will list you those that could not be > > installed. > Would it please be possible for "dnf update" to print this information > automatically? > E.g. apt-get can say "The following packages have been kept back: ..." > > dnf could report it like in this mockup: > ... > Dependencies resolved. > > PackageArch VersionRepository Size > > Upgrading: > emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M > emacs-common x86_64 1:24.4-6.fc21 updates-testing37 M > emacs-filesystem noarch 1:24.4-6.fc21 updates-testing64 k > Skipping for dependency reasons: > firefoxx86_64 37.0.1-1.fc21 updates-testing69 M > > Transaction Summary > > Upgrade 3 Packages > Skip 1 Package > > Total download size: ... > Is this ok [y/N]: > > Thanks, > Michal Please open an RFE, the dnf devel team is tracking everything in bugzilla, including priorities. Don't forget to describe the use case ... 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
Hi Tom, On Wed, 2015-04-08 at 12:14 +0100, Tom Hughes wrote: > WTF! https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
On 08/04/15 15:26, Lubomir Rintel wrote: Hi Tom, On Wed, 2015-04-08 at 12:14 +0100, Tom Hughes wrote: WTF! Err, I already did report them: https://bugzilla.redhat.com/show_bug.cgi?id=1209862 https://bugzilla.redhat.com/show_bug.cgi?id=1209864 I was simply trying to provide input to the ongoing discussion about how surprising it can often be to users used to yum. It was also born of a certain amount of frustration at the end of a long morning doing battle with dnf where many of the things that I had to workaround are things which I know have already been stated to be deliberate design choices and which I therefore didn't feel were worth reporting. 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: appdata validation and too long
On Wed, Apr 08, 2015 at 09:16:12 +0100, Richard Hughes wrote: A style warning is just that; it's going to look a little different to most other apps but with no real harm. If you use: appstream-util validate-relax usr/share/appdata/hedgewars.appdata.xml ...then the style warnings go away, and this is probably what you want to use if you're using it in a .spec file. I hope that helps, I did change the licence to to metadata-license since licence is deprecated, but otherwise since the list item was only a little over sized, I'd rather leave things as upstream wrote them. Thanks. -- 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: system-config-users and IPA
Apropos of ldap, the following message states that it is not recommended to write something the directory directly though ldap. http://www.redhat.com/archives/freeipa-users/2014-September/msg00228.html -- 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 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? -- 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 Wed, Apr 08, 2015 at 12:14:17 +0100, Tom Hughes wrote: 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. You can disable that plugin, though there was a bug related to that that I reported and got fixed. 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 I mentioned this effect in my bug about the snapper plugin suggesting it not be on by default because it can use significant resources and that it should be controlled by a config file, since in the default configuration, removing that plugin is going to remove a bunch of others. It sounds like you might be happier setting clean_requirements_on_remove to false in dnf.conf . -- 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 Release Readiness Meeting :: Thursday, April 09, 19:00 UTC
Fedora 22 Beta Release Readiness Meeting. date: 2015-04-09 place: irc.freenode.net in #fedora-meeting-2 time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST) This Thursday, April 09, we will meet to make sure we are coordinated and ready for the Beta release of Fedora 22 on Tuesday, April 14, 2015. Please note that this meeting will occur on April 09 even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but I was asked to open this meeting to the teams and I'll also hope this will raise awareness and more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. We also have a badge! Jaroslav ___ 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: An everyday tale of dnf
On 8 April 2015 at 16:21, Bruno Wolff III wrote: > It sounds like you might be happier setting clean_requirements_on_remove to > false in dnf.conf . I often find myself wanting to do this temporarily, but have yet to find a command line flag to do it - is there such a thing? If not, I'll file an RFE. -- 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 08:39 AM, Jan Zelený wrote: On 8. 4. 2015 at 10:26:51, Reindl Harald wrote: Am 08.04.2015 um 08:41 schrieb Jan Zelený: Putting the opinion of myself and the dnf team aside, I'd like to point out that the information you want is still available - dnf check-update will show you all the updates, even those that have broken deps. Running this command right after dnf upgrade will list you those that could not be installed the world don't work that way *nobody* even not myself would call "dnf check-update" after "dnf upgrade" installed updates and did not complain about anything You are right, people use it the other way - we have had reports stating that dnf check-update shows packages that dnf upgrade doesn't select. In other words, the information about broken updates is still available to the user. Perhaps dnf should keep track whether it had to 'skip-broken' , and report packages that were skipped during the update? I agree with Harald that invoking it quietly is the wrong thing to do. I have an extensive set of repositories (Fedora, Fusion, local, src/debug) and I had to "yum --skip-broken" disturbingly often. -- 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 Wed, Apr 08, 2015 at 16:47:17 +0100, Jonathan Underwood wrote: On 8 April 2015 at 16:21, Bruno Wolff III wrote: It sounds like you might be happier setting clean_requirements_on_remove to false in dnf.conf . I often find myself wanting to do this temporarily, but have yet to find a command line flag to do it - is there such a thing? If not, I'll file an RFE. It looks like you can do it with --setopt, but I am not sure of the exact syntax. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Moving Docker image under Cloud edition?
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? 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: dnf replacing yum and dnf-yum
> "MJ" == Marcin Juszkiewicz writes:
MJ> When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks
MJ> and one of them in my setup was "once built, install all resulting
MJ> packages".
MJ> This way as a developer I could check are results usable. Not found
MJ> something like that in mock.
For every local mock build, my script installs the built package and
runs rpmlint on them (which catches more things than just running
rpmlint on the rpms). That's one of the things I've really missed about
fedora-review.
To install the built packages, you just have to run
mock --install $MOCKDIR/result/*{i686,x86_64,noarch}.rpm
adjusting $MOCKDIR appropriately, of course. Probably trivial to do
with a mock plugin. For testing of "easy" things, you can even do a
mock shell and run the code out of the chroot.
- J<
--
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: How to build one TeXLive subpackage for EPEL-7?
> "MC" == Matěj Cepl writes: MC> Cutting up texlive monster piece by piece seems like rather lousy MC> idea to me. I honestly don't see why. Surely fixing some of it is better than fixing none of it. And fixing some of it shows us how to fix the rest of it. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Should a failed arch cancel other arch builds in koji?
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. -- 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
Re: Should a failed arch cancel other arch builds in koji?
W dniu 08.04.2015 o 20:20, Orion Poplawski pisze: > 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. "koji build --scratch --arch-override=justonearch" maybe? -- 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: How to build one TeXLive subpackage for EPEL-7?
Once upon a time, Jason L Tibbitts III said: > > "MC" == Matěj Cepl writes: > MC> Cutting up texlive monster piece by piece seems like rather lousy > MC> idea to me. > > I honestly don't see why. Surely fixing some of it is better than > fixing none of it. And fixing some of it shows us how to fix the rest > of it. Each time a small piece is sliced out of the giant package, the giant package must also be rebuilt to exclude that piece. That's a lot of churn on a giant package with a massive number of subpackages; it would be better to batch up pulling out lots of pieces at once. -- Chris Adams -- 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: How to build one TeXLive subpackage for EPEL-7?
On 8 April 2015 at 12:04, Jason L Tibbitts III wrote: > > "MC" == Matěj Cepl writes: > > MC> Cutting up texlive monster piece by piece seems like rather lousy > MC> idea to me. > > I honestly don't see why. Surely fixing some of it is better than > fixing none of it. And fixing some of it shows us how to fix the rest > of it. > I think the problem is that no one has figured out how to 'fix' a part of it. The best anyone has come up with was a machine generated 16MB spec file. We all keep looking at it, scratching our heads and then saying "Someone should fix that." knowing we can't. -- Stephen J Smoogen. -- 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: How to build one TeXLive subpackage for EPEL-7?
On 8 April 2015 at 19:40, Stephen John Smoogen wrote: > > > On 8 April 2015 at 12:04, Jason L Tibbitts III wrote: >> >> > "MC" == Matěj Cepl writes: >> >> MC> Cutting up texlive monster piece by piece seems like rather lousy >> MC> idea to me. >> >> I honestly don't see why. Surely fixing some of it is better than >> fixing none of it. And fixing some of it shows us how to fix the rest >> of it. > > > I think the problem is that no one has figured out how to 'fix' a part of > it. The best anyone has come up with was a machine generated 16MB spec file. > We all keep looking at it, scratching our heads and then saying "Someone > should fix that." knowing we can't. I look at tl2pm and think "it would be fairly easy to patch that to spit out 4000 and something spec files rather than one 16 MB one". The unresolved issues are whether doing that would invalidate the previous license audit (it shouldn't really), and whether FESCO would grant a package review exception for those packages. -- 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 Wed, Apr 8, 2015, at 01:36 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. Makes sense to me. -- 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: [EPEL-devel] Request to add glibc-static for rhel 7 ppc64 and ppc64le to EPEL
On Tue, Apr 7, 2015 at 9:40 PM, Kaustubh Deorukhkar wrote: > Hello, > > > I am looking for glibc-static packages for RHEL 7 (ppc64 and ppc64le) but > these are not available in EPEL repo. Is it possible to get these in epel > repo please? > They are available as part of the base OS. The output of "yum info glibc-static" is the following on my machine: ... Available Packages Name: glibc-static Arch: i686 Version : 2.12 Release : 1.149.el6_6.5 Size: 1.1 M Repo: updates Summary : C library static libraries for -static linking. URL : http://sources.redhat.com/glibc/ License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ Description : The glibc-static package contains the C library static libraries : for -static linking. You don't need these, unless you link statically, : which is highly discouraged. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Moving Docker image under Cloud edition?
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
Breathe for phython-sphinx?
Is Breathe for python-sphinx ( https://github.com/michaeljones/breathe ) available for Fedora? My searching with yum and such seems to indicate no, but I just wanted to ask on here in case it was packaged in a way that I didn't expect. Thanks, Dave -- 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 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 ? 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 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134914 Thanks, -- Sérgio M. B. -- 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 8. 4. 2015 at 16:47:17, Jonathan Underwood wrote: > On 8 April 2015 at 16:21, Bruno Wolff III wrote: > > It sounds like you might be happier setting clean_requirements_on_remove > > to > > false in dnf.conf . > > I often find myself wanting to do this temporarily, but have yet to > find a command line flag to do it - is there such a thing? If not, > I'll file an RFE. To be perfectly honest, I'm not sure that's going to be useful feature - if you disable this functionality by a switch in one run, the next run will do the cleanup anyway. 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
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
