Re: dnf versus yum
Il 05/01/2014 00:13, Adam Williamson ha scritto: On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote: On 2014-01-04 21:31, Lars E. Pettersson wrote: On 01/04/2014 08:56 PM, Rahul Sundaram wrote: * yum remove kernel vs dnf remove kernel difference (unfiled? ) I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion. https://bugzilla.redhat.com/show_bug.cgi?id=976704 Lars Hej... Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread It's a bit hard to tell, but from the comment it looks like it was really closed as 'notabug' rather than 'upstream'. They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel -- 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 versus yum
Am 05.01.2014 09:23, schrieb Mattia Verga: Il 05/01/2014 00:13, Adam Williamson ha scritto: On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote: On 2014-01-04 21:31, Lars E. Pettersson wrote: On 01/04/2014 08:56 PM, Rahul Sundaram wrote: * yum remove kernel vs dnf remove kernel difference (unfiled? ) I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion. https://bugzilla.redhat.com/show_bug.cgi?id=976704 Lars Hej... Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread It's a bit hard to tell, but from the comment it looks like it was really closed as 'notabug' rather than 'upstream'. They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel and that is clearly a regression how likely is that somebody want to delete all kernels include the running one? the user can always specify concrete versions on the command line - yes, at the same time the user can rpm -e --nodeps if he really knwos what he is doing the same for: protected_packages is ignored DNF drops Yum’s protected_packages configuration option. Generally, DNF lets the user do what she specified, even have DNF itself removed. Similar functionality can be implemented by a plugin DNF lets the user do what she specified is nonsense, the system must not destroy itself without *explicitly* specified this action via a *non-default* switch 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 versus yum
Am 05.01.2014 09:40, schrieb Reindl Harald:
They really want to make dnf work this way.
This is explained here:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel
and that is clearly a regression
how likely is that somebody want to delete all kernels include the running
one?
the user can always specify concrete versions on the command line - yes, at
the same time the user can rpm -e --nodeps if he really knwos what he is
doing
the same for:
protected_packages is ignored
DNF drops Yum’s protected_packages configuration option. Generally, DNF lets
the user
do what she specified, even have DNF itself removed. Similar functionality
can be
implemented by a plugin
DNF lets the user do what she specified is nonsense, the system must not
destroy itself
without *explicitly* specified this action via a *non-default* switch
the following paragraph would only be true if the UsrMove would have
been finished which is not the case, otherwise i would not be forced
to carry a meta-apckage with Provides: %{_sbindir}/ldconfig even
in F20 because all my self-maintained packages have done UsrMove
i had this fun recently by upgrade to F20 with yum because for
dependency solving the metapackage was temporarly removed and
there are still issues if glibc and other packages are updated
at the same time
so for me there are two choices:
* finish UsrMove and stop refer to /bin and /sbin anywhere in the distribution
* let DNF not assume a finished UsrMove
__
dnf provides /bin/file does not find any packages on Fedora
After UsrMove there’s no directory /bin on Fedora systems and no files get
installed there, /bin is only a symlink
created by the filesystem package to point to /usr/bin. Resolving the symlinks
to their real path would only give
the user false sense that this works while in fact provides requests using
globs such as
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 versus yum
On 01/05/2014 09:23 AM, Mattia Verga wrote: They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Yes, I have read that, but (strongly) disagree. The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), a better solution would be to safe guard the running kernel, only removing it if you explicitly ask for it: $ uname -a Linux tux 3.12.6-300.fc20.x86_64 #1 SMP Mon Dec 23 16:44:31 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ dnf erase kernel-3.12.6-300.fc20.x86_64 The same thing could be said about other packages now protected in yum. Please protect them in the same way in dnf. Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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 versus yum
Il 05/01/2014 10:27, Lars E. Pettersson ha scritto: Yes, I have read that, but (strongly) disagree. I agree in your disagreement! ;-) -- 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 versus yum
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson l...@homer.se wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
why did they change remove into erase?
Yum actually offers both erase and remove for the same purpose. I
don't know which is an alias of the other, but rpm uses erase.
From the man page: rpm {-e|--erase}
Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
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: dnf versus yum
On 01/05/2014 12:02 PM, Dridi Boukelmoune wrote:
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson l...@homer.se wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
why did they change remove into erase?
Yum actually offers both erase and remove for the same purpose. I
don't know which is an alias of the other, but rpm uses erase.
From the man page: rpm {-e|--erase}
Ah, did not know that, if you try to auto complete yum only remove shows
up, but erase also works. So perhaps erase was an afterthought, to mimic
the rpm behavior. If rpm has erase, and yum also can use erase, perhaps
erase is the way to go, perhaps...? :)
Lars
--
Lars E. Pettersson l...@homer.se
http://www.sm6rpz.se/
--
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 versus yum
On Sun, 05 Jan 2014 12:16:36 +0100 Lars E. Pettersson l...@homer.se wrote: Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :) Lars Maybe remove was for @debian people used to apt-get remove? ___ Regards, Frank www.frankly3d.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: dnf versus yum
Am 05.01.2014 12:21, schrieb Frank Murphy: On Sun, 05 Jan 2014 12:16:36 +0100 Lars E. Pettersson l...@homer.se wrote: Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :) Maybe remove was for @debian people used to apt-get remove? and if developers would be more pragmatic and user-friendly this wouöd not be discussed a single second and both supported the time which was used to explain why could have been used for implement the alias why? why not? should be the real question both are clear words and if both are supported it would not matter if erase is logical for user A or remove for user B 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: enlightenment 0.18.1 etc...
On Sat, Jan 4, 2014 at 9:27 PM, Bob Richmond b...@lorez.org wrote: No, the EFL is distributed as one big tarball now. All the old releases could be found here: http://download.enlightenment.org/releases/ Starting with 1.8.0, they're distributed in: http://download.enlightenment.org/rel/libs/efl/ ... as a single tarball. The spec file in my efl source RPM creates individual subpackages that resemble the existing efl packages out of a single source RPM. HI, Yes, I've been working on packaging up the new efl and submitting it for a review. If you would like to help maintain it you are more than welcome to. Dan -- 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: 20140105 changes
Compose started at Sun Jan 5 05:15:02 UTC 2014 Broken deps for i386 -- [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [OpenEXR_Viewers] OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libImath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmThread-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmImf-Imf_2_0.so.20 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIexMath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIex-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libHalf.so.10 [R-maanova] R-maanova-1.30.0-2.fc20.i686 requires libRlapack.so R-maanova-1.30.0-2.fc20.i686 requires libRblas.so [aime] aime-7.20131209-1.fc21.i686 requires /usr/sbin/install-info aime-7.20131209-1.fc21.i686 requires /usr/sbin/install-info [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [dmapd] dmapd-0.0.55-5.fc21.i686 requires libwebp.so.4 dmapd-0.0.55-5.fc21.i686 requires libImath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmThread-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmImf-Imf_2_0.so.20 dmapd-0.0.55-5.fc21.i686 requires libIexMath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIex-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libHalf.so.10 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [evolution-rss] 1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46 [gpsdrive] gpsdrive-2.11-20.fc20.i686 requires libgps.so.20 [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [mojomojo] mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libitksys-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkopenjpeg-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkdouble-conversion-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkNetlibSlatec-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmMSFF.so.2.2 nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmDICT.so.2.2
Re: enlightenment 0.18.1 etc...
On Sun, Jan 5, 2014 at 3:43 AM, Dan Mashal dan.mas...@gmail.com wrote: On Sat, Jan 4, 2014 at 9:27 PM, Bob Richmond b...@lorez.org wrote: No, the EFL is distributed as one big tarball now. All the old releases could be found here: http://download.enlightenment.org/releases/ Starting with 1.8.0, they're distributed in: http://download.enlightenment.org/rel/libs/efl/ ... as a single tarball. The spec file in my efl source RPM creates individual subpackages that resemble the existing efl packages out of a single source RPM. HI, Yes, I've been working on packaging up the new efl and submitting it for a review. If you would like to help maintain it you are more than welcome to. Hi, Obviously fully didn't read the original post. Just wanted to say thanks for this. Majorly reduces the time I have to spend on this. I'll go through these and submit them for review ASAP. Also, thanks for the patches. Just an FYI, autogen.sh doesn't need to be run on these packages as they already include a configure script. However, in tarballs that don't contain a configure script and just autogen.sh, you usually would want to run NOCONFIGURE=1 ./autogen.sh. Thanks again. Dan -- 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: Grub installation. First potential Fedora killer
On 01/02/2014 05:32 PM, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. In addition it didn't detect my other Linux installation so at first boot I was only able to choose between Fedora 20 and Fedora 20. Fortunately running grub-install fixed it (ie this time my other installations were detected). Sort of. First of all because Fedora 20, ie a ditribution I was _testing_ was now the default and second of all because every time I upgrade the kernel of my _main_ distribution I am supposed to reboot on F20 and run grub-install. Great. Nothing I can't fix but your average Ubuntu or Suse user will just cancel installation as soon he notices F20 is going to force itself on his MBR. And if the road is a one way one between Fedora and Ubintu then it is doomed. If your system has multiple disk drives, there is a way to do what you want to do. That is, have you current (production) installation and then install Fedora 20 for testing without disturbing your current boot. Assuming that you current system has grub2-install /dev/sda, when you install Fedora 20, tell the install to put the MBR on another disk such as sdb. Everything will be installed and configured except that the MBR on /dev/sda will not be touched. When you reboot into you current/production system, you need to either enable (not disable) os-prober or add a definition to /etc/grub.d/40_custom which will chainload the grub.cfg file on your new/test system. This works; I use it. Gene -- 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: enlightenment 0.18.1 etc...
On 05.01.2014 04:29, Bob Richmond wrote: I have no desire to become a package maintainer for Enlightenment, but I Even in this case, after the hard work already done by you, now it is possible binaries be delivered to the end users - Are you aware of the new COPR [1] service? After repo creating, your further rebuilds will be easy as: copr-cli build efl18 http://www.lorez.org/enlightenment/efl-1.8.3-1.fc20.src.rpm resulting in ready for use yum.repo in something like: http://copr.fedoraproject.org/coprs/bob/efl18/repo/fedora-20-x86_64/ (assuming copr-cli create efl18 setup step) Kind Regards, Alek [1] http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/index.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: enlightenment 0.18.1 etc...
The autogen thing was because I patched configure.ac to look for the pkg-config name for tslib as tslib-0.0 (as shipped in Fedora). Which means configure needed to be regenerated. I guess an alternative would be to patch configure directly, but eh... :) On 01/05/2014 04:02 AM, Dan Mashal wrote: On Sun, Jan 5, 2014 at 3:43 AM, Dan Mashal dan.mas...@gmail.com wrote: On Sat, Jan 4, 2014 at 9:27 PM, Bob Richmond b...@lorez.org wrote: No, the EFL is distributed as one big tarball now. All the old releases could be found here: http://download.enlightenment.org/releases/ Starting with 1.8.0, they're distributed in: http://download.enlightenment.org/rel/libs/efl/ ... as a single tarball. The spec file in my efl source RPM creates individual subpackages that resemble the existing efl packages out of a single source RPM. HI, Yes, I've been working on packaging up the new efl and submitting it for a review. If you would like to help maintain it you are more than welcome to. Hi, Obviously fully didn't read the original post. Just wanted to say thanks for this. Majorly reduces the time I have to spend on this. I'll go through these and submit them for review ASAP. Also, thanks for the patches. Just an FYI, autogen.sh doesn't need to be run on these packages as they already include a configure script. However, in tarballs that don't contain a configure script and just autogen.sh, you usually would want to run NOCONFIGURE=1 ./autogen.sh. Thanks again. Dan -- 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 versus yum
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote: On 01/05/2014 09:23 AM, Mattia Verga wrote: They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Yes, I have read that, but (strongly) disagree. The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), They didn't. Both work on both. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 versus yum
On Sun, 2014-01-05 at 12:34 +0100, Reindl Harald wrote: Am 05.01.2014 12:21, schrieb Frank Murphy: On Sun, 05 Jan 2014 12:16:36 +0100 Lars E. Pettersson l...@homer.se wrote: Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :) Maybe remove was for @debian people used to apt-get remove? and if developers would be more pragmatic and user-friendly this wouöd not be discussed a single second and both supported You're losing track of the discussion. This has devolved into a sub-thread about the commands 'remove' and 'erase', it now has little to do with the call about what '[yum/dnf] [remove/erase] kernel' should do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 versus yum
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote: On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote: On 01/05/2014 09:23 AM, Mattia Verga wrote: They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Yes, I have read that, but (strongly) disagree. The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), They didn't. Both work on both. It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 versus yum
Am 05.01.2014 19:07, schrieb Adam Williamson: On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote: On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote: On 01/05/2014 09:23 AM, Mattia Verga wrote: They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Yes, I have read that, but (strongly) disagree. The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), They didn't. Both work on both. It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel *that* and other things missing are example why this thread is not terrible or useless and as you have seen the cache is coming back which was declared as useless by DNF developers before this discussion honestly i am *not* testing DNF *because currently* it lacks obviously features which makes it a no-go replacement for my envirnonments and *the main reason* for this thread was push it in a direction where it makes sense for me to have it on my testserver, even risk a dist-upgrade on a VM and give feeback/karma for updates - as said - ASAP and not too late to get things fine before it really claims to replace YUM 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 versus yum
On 01/05/2014 07:07 PM, Adam Williamson wrote: On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote: On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote: ... The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), They didn't. Both work on both. It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs. As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too. As a side not 'dnf --help' shows: '--version show Yum version and exit' which probably also is wrong. This is by no mean any excoriation of the dnf devs on my part. Three documentation bugs out of a side track of a thread is not a terrible thread, in my opinion... Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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 versus yum
On 01/05/2014 07:24 PM, Lars E. Pettersson wrote: As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. Pressed send a bit too early. Should of course be 'erase' here, not 'remove'... :) Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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 versus yum
A solution may be for someone to write a plugin that restores the protected packages feature. Fedora users are clearly used to such a feature and expect it while upstream doesnt want to add hand holding features, but provide a method to do the same. On 5 January 2014 18:32, Lars E. Pettersson l...@homer.se wrote: On 01/05/2014 07:24 PM, Lars E. Pettersson wrote: As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. Pressed send a bit too early. Should of course be 'erase' here, not 'remove'... :) Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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: Updating hdf5 to 1.8.12
Orion, is it possible that you missed h5py? We are getting this 1. Warning! ***HDF5 library version mismatched error*** 2. The HDF5 header files used to compile this application do not match 3. the version used by the HDF5 library to which this application is linked. 4. Data corruption or segmentation faults may occur if the application continues. 5. This can happen when an application was compiled by one version of HDF5 but 6. linked with a different version of static or shared HDF5 library. 7. You should recompile the application or check your shared library related 8. settings such as 'LD_LIBRARY_PATH'. 9. You can, at your own risk, disable this warning by setting the environment 10. variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'. 11. Setting it to 2 or higher will suppress the warning messages totally. 12. Headers are 1.8.11, library is 1.8.12 when building astropy in its review (details here https://bugzilla.redhat.com/show_bug.cgi?id=1014738#c28 ) and I think that is happens because h5py was not rebuilt. Regards, Sergio 2013/12/27 Orion Poplawski or...@cora.nwra.com I will be updating hdf5 to 1.8.12 shortly in rawhide and rebuilding dependent packages: Field3D-1.3.2-14.fc21.src.rpm R-hdf5-1.6.9-22.fc20.src.rpm ViTables-2.1-7.fc21.src.rpm cgnslib-3.2-3.fc20.src.rpm gdl-0.9.4-1.fc21.src.rpm hdf5-1.8.11-6.fc21.src.rpm jhdf5-2.9-3.fc20.src.rpm matio-1.5.1-4.fc21.src.rpm netcdf-4.3.0-7.fc21.src.rpm octave-3.6.4-9.fc21.src.rpm paraview-4.0.1-3.fc21.src.rpm scilab-5.5.0-0.2.beta1.fc21.1.src.rpm vtk-6.0.0-9.fc21.src.rpm -- 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 -- 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 versus yum
Am 05.01.2014 20:06, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Frankly, that's a dumb feature to have the package manager know magic things about some names. Why is it dumb? Because some people then depend on magic features. Is this feature even documented anywhere? I don't see it in the yum man page for example. I never knew that yum erase kernel wouldn't actually remove all packages named kernel, because I would never say erase the kernel and expect something to not erase the kernel. others did because the tried what things are doing This is Unix; system programs are expected to do what I say. Don't try to code do what I mean into it (because what you mean is probably different from what I mean) i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is we are not Unix, we are Linux so somewhere in time Fedora should decide if it follows the unix-way or not, there are many decisions helping endusers where i would say a technican don't do that and nobody cares so in case of destory the system *yes* protect from happen it and allow to do with force flags but not by accident _ following your argumentation this should be removed too? [root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe 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
Self Introduction
Hi all I'm an IT university student. With Fedora I have a total experience about half a year, my primary distribution is Archlinux (about four or five years experience). Currently, I'm preparing a Fedora package as part of my bachelor thesis: A library for RdRand (the instruction used in Ivy Bridge and newer Intel CPUs for generating random numbers). Regards 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 versus yum
On 01/04/2014 03:09 PM, Adam Williamson wrote: On Sat, 2014-01-04 at 10:50 +0100, Mattia Verga wrote: This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum? Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum? Because yum's code is a mess. The primary point of the dnf rewrite is not to alter the user interface, but to clean up the code itself. That is great but it should support everything yum supported. Even Linux keeps old interfaces around, if they are going to change there is at least a period where they are marked as deprecated and with a caution they may be removed in the future! -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.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: Self Introduction
Welcome in Fedora :) Out of curiosity, are you only packaging it or also developing it ? Anyway, it will be a useful library (no trolling about the rdrand instruction ;)) Best regards, H. Le 5 janv. 2014 21:14, Jan Tulak jtu...@redhat.com a écrit : Hi all I'm an IT university student. With Fedora I have a total experience about half a year, my primary distribution is Archlinux (about four or five years experience). Currently, I'm preparing a Fedora package as part of my bachelor thesis: A library for RdRand (the instruction used in Ivy Bridge and newer Intel CPUs for generating random numbers). Regards 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 -- 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: enlightenment 0.18.1 etc...
I uploaded a new version of the efl srpm that patches configure directly to look for the correct tslib pkg-config and removes the call to autogen. Also corrects a cut paste error I made that erroneously included libemotion in the ephysics package. http://www.lorez.org/enlightenment/efl-1.8.3-1.fc20.src.rpm On 01/05/2014 09:01 AM, Bob Richmond wrote: The autogen thing was because I patched configure.ac to look for the pkg-config name for tslib as tslib-0.0 (as shipped in Fedora). Which means configure needed to be regenerated. I guess an alternative would be to patch configure directly, but eh... :) On 01/05/2014 04:02 AM, Dan Mashal wrote: On Sun, Jan 5, 2014 at 3:43 AM, Dan Mashal dan.mas...@gmail.com wrote: On Sat, Jan 4, 2014 at 9:27 PM, Bob Richmond b...@lorez.org wrote: No, the EFL is distributed as one big tarball now. All the old releases could be found here: http://download.enlightenment.org/releases/ Starting with 1.8.0, they're distributed in: http://download.enlightenment.org/rel/libs/efl/ ... as a single tarball. The spec file in my efl source RPM creates individual subpackages that resemble the existing efl packages out of a single source RPM. HI, Yes, I've been working on packaging up the new efl and submitting it for a review. If you would like to help maintain it you are more than welcome to. Hi, Obviously fully didn't read the original post. Just wanted to say thanks for this. Majorly reduces the time I have to spend on this. I'll go through these and submit them for review ASAP. Also, thanks for the patches. Just an FYI, autogen.sh doesn't need to be run on these packages as they already include a configure script. However, in tarballs that don't contain a configure script and just autogen.sh, you usually would want to run NOCONFIGURE=1 ./autogen.sh. Thanks again. Dan -- 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: Self Introduction
Thank you :-) I'm also developing it (https://github.com/BroukPytlik/RdRand). ReadMe still needs to be filled with reasonable texts, I have to copy it from man pages (why write the same things twice). :-) About the security concerns... I have done some statistical testing of it (PractRand, TestU01) and even after many terabytes on four machines it didn't found anything suspicious. So I would not used it directly for something important (closed things are closed things, and with NSA paying to RSA for backdoors...), but for casual usage or as one of more entropy sources (or as a seed for a CSPRNG) it can work pretty well. My package is including the C library and also a simple application usable by users directly (i.e. usable in shell scripts) if they do not want to pull data from /dev/[u]random. Best regards Jan On Sunday 05 of January 2014 21:21:32 H. Guémar wrote: Welcome in Fedora :) Out of curiosity, are you only packaging it or also developing it ? Anyway, it will be a useful library (no trolling about the rdrand instruction ;)) Best regards, H. -- 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 versus yum
On Sun, Jan 05, 2014 at 01:06:16PM -0600, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel Frankly, that's a dumb feature to have the package manager know magic things about some names. Why is it dumb? Because some people then depend on magic features. Is this feature even documented anywhere? I don't see it in the yum man page for example. [...] This is Unix; system programs are expected to do what I say. Don't try to code do what I mean into it (because what you mean is probably different from what I mean). We've had kernel variant packages in the past, like kernel-smp and kernel-PAE; are all variants supposed to be handled magically? What if there's a new variant? Would not handling it in the package manager magic be a release-blocker bug? Kernel packages are special with yum, because multiple packages are installed by default. With your argumentation 'dnf update kernel' should remove the current kernel when a new kernel is installed. Is this really what you expect and what dnf should do? Currently it installs a new kernel without removing the old one as I know it from yum. Regards Till -- 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 versus yum
Once upon a time, Reindl Harald h.rei...@thelounge.net said: i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is we are not Unix, we are Linux Yeah, I dislike that as well. If I want paged output, I'll page it; if I want cut output, I'll cut it. The helpful options added to the $PAGER variable are really stupid as well; I have to set $SYSTEMD_PAGER as well as $PAGER, just to override systemd's help. following your argumentation this should be removed too? [root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe I didn't know that was there (not in the habit of running rm -rf / just to see what happens). I really can't think of a situation where rm -rf / would be useful, so I don't really care one way or the other about that one. -- Chris Adams li...@cmadams.net -- 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 versus yum
Am 05.01.2014 23:33, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is we are not Unix, we are Linux Yeah, I dislike that as well. If I want paged output, I'll page it; if I want cut output, I'll cut it. The helpful options added to the $PAGER variable are really stupid as well; I have to set $SYSTEMD_PAGER as well as $PAGER, just to override systemd's help. agreed but realize the lernel is a very special package following your argumentation it would be handeled as any other apckage and you would have not way to boot the old one if boot fails after a update following your argumentation this should be removed too? [root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe I didn't know that was there (not in the habit of running rm -rf / just to see what happens). I really can't think of a situation where rm -rf / would be useful, so I don't really care one way or the other about that one where it would be useful? nowhere - press enter by accident while typing a command where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state? 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 versus yum
Once upon a time, Reindl Harald h.rei...@thelounge.net said: where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state? I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list): when you have a system that doesn't load a kernel from the filesystem, such as a VM environment where the boot process is external. Another is if you need to re-install the kernel RPM because files have been removed, overwritten, etc.; yum reinstall is documented (unlike this magic feature) to not handle multi-install packages like the kernel. The only way is going to be to yum erase and yum install. Also, even removing every kernel RPM will not render your system non-recoverable. You can always use a boot CD, and in modern Fedora systems, the rescue kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that. -- Chris Adams li...@cmadams.net -- 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 versus yum
Am 05.01.2014 23:53, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state? I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list): when you have a system that doesn't load a kernel from the filesystem, such as a VM environment where the boot process is external. border cases where you can use --nodeps Another is if you need to re-install the kernel RPM because files have been removed, overwritten, etc.; yum reinstall is documented (unlike this magic feature) to not handle multi-install packages like the kernel. The only way is going to be to yum erase and yum install. this is *really* a border case where download and rpm -Uvh --force is the way to go Also, even removing every kernel RPM will not render your system non-recoverable. You can always use a boot CD, and in modern Fedora systems, the rescue kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that you can do that, i can do that the ordianry user - i doubt 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 versus yum
On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote: On 01/05/2014 07:07 PM, Adam Williamson wrote: On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote: On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote: ... The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), They didn't. Both work on both. It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs. As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too. As a side not 'dnf --help' shows: '--version show Yum version and exit' which probably also is wrong. This is by no mean any excoriation of the dnf devs on my part. Three documentation bugs out of a side track of a thread is not a terrible thread, in my opinion... If it exists for backward compatibility, it doesn't necessarily need to be documented. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction
Hi, I am Tom Hodder, long time fedora user, ex-RHCE, and tolland on IRC. I noticed that ghemical was listed as an orphaned package, and I had an email chat with the previous maintainer, and he suggested that there are some updates pending in upstream. However he was too busy to continue as maintainer and pull those in. So I'd like to take over maintaining the following packages; ghemical libghemical liboglappth mopac7 mpqc Cheers, 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
Re: dnf versus yum
Once upon a time, Reindl Harald h.rei...@thelounge.net said: border cases where you can use --nodeps What does --nodeps have to do with this? this is *really* a border case where download and rpm -Uvh --force is the way to go No, you should do it correctly. First, AFAIK rpm doesn't have the magic kernel behavior, so your -U will upgrade, not install, and you can't upgrade to the same package version (I don't think --force overrides that, but I haven't tried it myself). Second, --force should be banned from any recommended rpm usage; there is virtually never a good reason to do that (I haven't used it in many many years). Also, even removing every kernel RPM will not render your system non-recoverable. You can always use a boot CD, and in modern Fedora systems, the rescue kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that you can do that, i can do that the ordianry user - i doubt The ordinary user won't do yum erase kernel either, so that's moot. The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default). In any case, this is still a very minor side issue, and should not derail practical dnf discussions. -- Chris Adams li...@cmadams.net -- 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 versus yum
Am 06.01.2014 02:12, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: border cases where you can use --nodeps What does --nodeps have to do with this? border cases are not usual behavior? this is *really* a border case where download and rpm -Uvh --force is the way to go No, you should do it correctly. First, AFAIK rpm doesn't have the magic kernel behavior, so your -U will upgrade, not install ah and that is why yum/dnf should not have it too? Also, even removing every kernel RPM will not render your system non-recoverable. You can always use a boot CD, and in modern Fedora systems, the rescue kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that you can do that, i can do that the ordianry user - i doubt The ordinary user won't do yum erase kernel either, so that's moot and *why* does it help *you* no longer support the long years existing behavior? only because you did not know that it works instead put all kernels to uninstall explicit in the command line? have fun if you maintain more than 20 machines mixed of testing and production and after a few days you want them all at the same package level - currently it is one single command with zero danger The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default). In any case, this is still a very minor side issue, and should not derail practical dnf discussions your practices? my practices? yum remove kernel is a clean and sane way to remove all but not the running kernels distribute-command.sh 'yum -y remove kernel' is used here for years on a ton of machines why do you think that a *replacement* should come up not support this? why do you think we do not care and even allow remove dnf is sane behavior? hence that is why whatever calls itself a replacement for yum should *not* support destroy the running system without whatever *force switch* 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: Updating hdf5 to 1.8.12
On 01/05/2014 11:54 AM, Sergio Pascual wrote: Orion, is it possible that you missed h5py? We are getting this 1. Warning! ***HDF5 library version mismatched error*** 2. The HDF5 header files used to compile this application do not match 3. the version used by the HDF5 library to which this application is linked. 4. Data corruption or segmentation faults may occur if the application continues. 5. This can happen when an application was compiled by one version of HDF5 but 6. linked with a different version of static or shared HDF5 library. 7. You should recompile the application or check your shared library related 8. settings such as 'LD_LIBRARY_PATH'. 9. You can, at your own risk, disable this warning by setting the environment 10. variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'. 11. Setting it to 2 or higher will suppress the warning messages totally. 12. Headers are 1.8.11, library is 1.8.12 when building astropy in its review (details here https://bugzilla.redhat.com/show_bug.cgi?id=1014738#c28 ) and I think that is happens because h5py was not rebuilt. Yup - it was missing the specific hdf5 requires. I've rebuilt it now. Thanks. I've really got to get upstream to drop this, pinging them again about it. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.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: [pkgdb] python-boto ownership changed
On 2014-01-02 16:38, Andrew Lutomirski wrote: [Third try to send this email. The Gmail Android app has a lovely UI to select the sender address, but it doesn't do anything :(.] On Fri, Jan 3, 2014 at 5:31 AM, Garrett Holmstrom gho...@fedoraproject.org wrote: On Fri, Dec 27, 2013 at 10:32 PM, Orion Poplawski or...@cora.nwra.com wrote: On 12/27/2013 05:24 PM, Andrew Lutomirski wrote: On Fri, Dec 27, 2013 at 9:42 AM, Orion Poplawski or...@cora.nwra.com wrote: Is anyone interested in taking on python-boto, please? I can, although I won't be able to do anything beyond clicking the button for a couple weeks. --Andy Thanks! I can push new releases at times, but I really can't take on any more packages as primary maintainer. I can take it. I had actually discussed this with the previous maintainer before, but it seems that he orphaned it while I was on vacation out of town. Sorry about the delay. :-\ Go for it. Do I need to re-orphan it? I believe so. -- Garrett Holmstrom -- 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: Grub installation. First potential Fedora killer
This is not the problem. THe problem is: a user of another distribution will not want to touch Fedora with a ten foot pole pnce he discovers Fedora messe up with his booter setup. And the parttitionner is equally bad. These are two areas a distribution not only in the area of bugs but in the are of design. And Fedora hasn't. On Sun, 05 Jan 2014 07:05:50 -0500 Gene Czarcinski gczarcin...@gmail.com wrote: On 01/02/2014 05:32 PM, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. In addition it didn't detect my other Linux installation so at first boot I was only able to choose between Fedora 20 and Fedora 20. Fortunately running grub-install fixed it (ie this time my other installations were detected). Sort of. First of all because Fedora 20, ie a ditribution I was _testing_ was now the default and second of all because every time I upgrade the kernel of my _main_ distribution I am supposed to reboot on F20 and run grub-install. Great. Nothing I can't fix but your average Ubuntu or Suse user will just cancel installation as soon he notices F20 is going to force itself on his MBR. And if the road is a one way one between Fedora and Ubintu then it is doomed. If your system has multiple disk drives, there is a way to do what you want to do. That is, have you current (production) installation and then install Fedora 20 for testing without disturbing your current boot. Assuming that you current system has grub2-install /dev/sda, when you install Fedora 20, tell the install to put the MBR on another disk such as sdb. Everything will be installed and configured except that the MBR on /dev/sda will not be touched. When you reboot into you current/production system, you need to either enable (not disable) os-prober or add a definition to /etc/grub.d/40_custom which will chainload the grub.cfg file on your new/test system. This works; I use it. Gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Jean François Martinez jfm...@free.fr -- 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 versus yum
On Mon, 2014-01-06 at 02:33 +0100, Reindl Harald wrote: Am 06.01.2014 02:12, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: border cases where you can use --nodeps What does --nodeps have to do with this? border cases are not usual behavior? His point was that there is nothing involving dependencies here. nodeps would not make any difference. yum remove kernel is a clean and sane way to remove all but not the running kernels distribute-command.sh 'yum -y remove kernel' is used here for years on a ton of machines https://xkcd.com/1172/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Grub installation. First potential Fedora killer
On Thu, 2014-01-02 at 23:32 +0100, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. Why? Not at all is precisely the correct action for a grub2-based distribution in this case. I think we should do grub2-mkconfig for such installs, though it's a bit tricky to refactor anaconda's bootloader install code to do so. I might have a shot at it if I get a spare minute, though. But yes, aside from not generating a grub2.cfg for you, this is precisely the right thing to do. If you don't want Fedora to own the MBR, then you should not install a bootloader during installation. You should install no bootloader, and then use grub2 configfile inclusion to boot Fedora. See https://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html . In addition it didn't detect my other Linux installation so at first boot I was only able to choose between Fedora 20 and Fedora 20. What is your 'other Linux installation'? It's not like we can do anything if you don't even say that. (But we don't really do anything special for multi-boot configuration; we let grub do it, via os-prober. If it didn't find your other installers, it sounds like there's a bug in grub.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 versus yum
On 01/05/2014 11:53 PM, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state? I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list): When will it be useful and correct to remove the *running* kernel (that is what yum protects you from doing)? Yum also protects you from removing yum, 'Error: Trying to remove yum, which is protected'. Is that bad also? As long as you have rpm installed you can download the yum rpm, and re-install yum, so why protects it? Could it be because yum has a user perspective, making it a tad harder for the non technically oriented user to do bad things to the system? Leaving the bad things to the more technically oriented user? Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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 versus yum
On 01/06/2014 12:46 AM, Adam Williamson wrote: On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote: ... As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too. As a side not 'dnf --help' shows: '--version show Yum version and exit' which probably also is wrong. This is by no mean any excoriation of the dnf devs on my part. Three documentation bugs out of a side track of a thread is not a terrible thread, in my opinion... If it exists for backward compatibility, it doesn't necessarily need to be documented. Ehh? Why? Could you elaborate? Lars -- Lars E. Pettersson l...@homer.se http://www.sm6rpz.se/ -- 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: Grub installation. First potential Fedora killer
On Sun, 2014-01-05 at 22:52 -0800, Adam Williamson wrote: On Thu, 2014-01-02 at 23:32 +0100, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. Why? Not at all is precisely the correct action for a grub2-based distribution in this case. I think we should do grub2-mkconfig for such installs, though it's a bit tricky to refactor anaconda's bootloader install code to do so. I might have a shot at it if I get a spare minute, though. Well, hum, it doesn't look hard at all, in fact, at least a simple version. See attached patch (untested, but what could possibly go wrong?!). I'm not subscribed to anaconda-patches-list ATM, but CCing anaconda-devel-list to see what the anaconda devs think. I think it's reasonable to install a config file and device.map when 'skipping' grub2-bios bootloader install, especially given our standing advice to people who want to do chainload-style multi boot is skip bootloader installation then setup configfile booting after install. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net From 88d4843eda3a00b0474ecb26242c52e4f378add7 Mon Sep 17 00:00:00 2001 From: Adam Williamson awill...@redhat.com Date: Sun, 5 Jan 2014 22:57:51 -0800 Subject: [PATCH] write a device.map and bootloader config when 'skipping' grub2 install The usual reason for skipping bootloader installation is if you want to do a multi-boot configuration other than one where Fedora 'takes over' boot. People who do this are usually going to have a much easier time if they have a config file - our 'official' recommendation instead of chainloading is to use grub2's configfile functionality, and that obviously requires the OS to have a config file. --- pyanaconda/bootloader.py | 6 ++ 1 file changed, 6 insertions(+) diff --git a/pyanaconda/bootloader.py b/pyanaconda/bootloader.py index fe62b3a..741169d 100644 --- a/pyanaconda/bootloader.py +++ b/pyanaconda/bootloader.py @@ -1566,6 +1566,12 @@ class GRUB2(GRUB): def write(self): Write the bootloader configuration and install the bootloader. if self.skip_bootloader: + We should write a config file at least, as the normal +reason for skipping bootloader installation is to do advanced +multi-boot, and it's useful to have a config file. +self.write_device_map() +sync() +self.write_config() return if self.update_only: -- 1.8.5.2 -- 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 versus yum
On Mon, 2014-01-06 at 08:01 +0100, Lars E. Pettersson wrote: On 01/06/2014 12:46 AM, Adam Williamson wrote: On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote: ... As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one. dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too. As a side not 'dnf --help' shows: '--version show Yum version and exit' which probably also is wrong. This is by no mean any excoriation of the dnf devs on my part. Three documentation bugs out of a side track of a thread is not a terrible thread, in my opinion... If it exists for backward compatibility, it doesn't necessarily need to be documented. Ehh? Why? Could you elaborate? I don't see what needs elaborating. I'm not aware that the 11th commandment is Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem. If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 versus yum
On Sun, 2014-01-05 at 23:13 -0800, Adam Williamson wrote: I don't see what needs elaborating. I'm not aware that the 11th commandment is Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem. If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble? One thing I find a bit inconsistent, though, is that the manpage documents dnf erase, but dnf group remove. :) Picking one verb or the other and sticking with it seems advised. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-01-06 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-01-06 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again soon! Still not an awful lot on the agenda that I can see, to be honest, I think we're sort of sitting around waiting for FESCo at this point. But it's the New Year, so we may as well get together and chat a bit, and we can look at Mike and Dan's revision to the Join page (thanks, guys!) This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20140106 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. QA/Join page revision 3. Open floor -- 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: Grub installation. First potential Fedora killer
On Jan 5, 2014, at 11:27 PM, Jean François Martinez jfm...@free.fr wrote: This is not the problem. THe problem is: a user of another distribution will not want to touch Fedora with a ten foot pole pnce he discovers Fedora messe up with his booter setup. And the parttitionner is equally bad. These are two areas a distribution not only in the area of bugs but in the are of design. And Fedora hasn't. Yes. Well, the unfriendliness of linux distributions toward other linux distributions in multiboot context is not unique to Fedora. By default they all pretty much will try to eat each other for lunch. It's distinctly unfriendly compared to the default behavior of installing two copies of Windows, or two copies of OS X on the same drive. It annoys me, but also there's a kind of irony so I'm also amused. Anyway, some distros try to get around the problem, while it's still not at all friendly, by forcing the installation of boot.img and block list into the first two sectors of the /boot partition. Literally it requires grub-install --force, otherwise it fails. The Fedora installer since F18 doesn't support --force anymore. Other distros take the ensuing risk. You can do one of three things post install, starting with do not install a boot loader when installing Fedora: 1. grub2-install --force /dev/sdXY and then grub2-mkconfig -o /boot/grub2/grub.cfg. Does not require --force for Btrfs. Does not work in any case with XFS. Unfortunately when the bootloader isn't installed by anaconda, it also doesn't create /etc/default/grub which could be a drag to create manually but that's the deal. There has been an RFE on this for two releases or so, no progress or patches to help the progress. This is a bit clunky but can be chainloaded from grub legacy or other non-grub2 bootloaders, and it's probably what you're used to even though it's really inelegant. 2. grub2-install --grub-setup=/bin/true /dev/sda will do everything except obliterate the MBR gap boot loader code, leaving the existing boot loader working. Also run grub2-mkconfig as above. No code goes in the /boot partition VBR in this case, so you need to have your non-grub2 main bootloader directly load the grub2 core.img; or if it is grub2 then you should edit the main distro /etc/grub.d/40_custom with an entry using configfile pointed to the Fedora grub.cfg and update its grub.cfg. Still lacks /etc/default/grub. 3. Use extlinux as a boot parameter for the install media. This will use extlinux which by design installs to rootfs for unified layouts, or /boot if separate. Currently boot code already in the MBR is not replaced. (On blank disks, parted writes some basic jump code in the MBR so new installs do boot with no extra work.) There's an RFE asking for extlinux installs to overwrite the MBR, FYI, so this behavior could change. In this case there's boot code in the Fedora boot partition VBR, so you just have the main bootloader chainload extlinux by pointing it to the boot partition. Anaconda creates a extlinux.conf for you. So I think this is the best option. Chris Murphy -- 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: Grub installation. First potential Fedora killer
On Jan 6, 2014, at 12:04 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2014-01-05 at 22:52 -0800, Adam Williamson wrote: On Thu, 2014-01-02 at 23:32 +0100, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. Why? Not at all is precisely the correct action for a grub2-based distribution in this case. I think we should do grub2-mkconfig for such installs, though it's a bit tricky to refactor anaconda's bootloader install code to do so. I might have a shot at it if I get a spare minute, though. Well, hum, it doesn't look hard at all, in fact, at least a simple version. See attached patch (untested, but what could possibly go wrong?!). I'm not subscribed to anaconda-patches-list ATM, but CCing anaconda-devel-list to see what the anaconda devs think. I think it's reasonable to install a config file and device.map when 'skipping' grub2-bios bootloader install, especially given our standing advice to people who want to do chainload-style multi boot is skip bootloader installation then setup configfile booting after install. There's an RFE bug floating around for this. I asked a while ago on grub-devel@ whether grub-mkconfig depended on grub-install being done first, and I got a kinda yesish answer that wasn't all that convincing. But the suggestion was to use 'grub2-install --grub-setup=/bin/true /dev/sdX' before grub2-mkconfig. This causes all the parts of grub to be installed except the singular thing people object to, and is the sole reason why they say they don't want a bootloader installed - which is boot.img being written into the MBR. I've tested that combination and it's safe. So if the code were changed just that no bootloader simply means *adding* --grub-setup=/bin/true and doing everything else we already do, that'd be the easiest fix that helps the most people IMO. BTW I think device.map is deprecated (?). Chris Murphy -- 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: Grub installation. First potential Fedora killer
On Mon, 2014-01-06 at 00:43 -0700, Chris Murphy wrote: On Jan 6, 2014, at 12:04 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2014-01-05 at 22:52 -0800, Adam Williamson wrote: On Thu, 2014-01-02 at 23:32 +0100, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. Why? Not at all is precisely the correct action for a grub2-based distribution in this case. I think we should do grub2-mkconfig for such installs, though it's a bit tricky to refactor anaconda's bootloader install code to do so. I might have a shot at it if I get a spare minute, though. Well, hum, it doesn't look hard at all, in fact, at least a simple version. See attached patch (untested, but what could possibly go wrong?!). I'm not subscribed to anaconda-patches-list ATM, but CCing anaconda-devel-list to see what the anaconda devs think. I think it's reasonable to install a config file and device.map when 'skipping' grub2-bios bootloader install, especially given our standing advice to people who want to do chainload-style multi boot is skip bootloader installation then setup configfile booting after install. There's an RFE bug floating around for this. I asked a while ago on grub-devel@ whether grub-mkconfig depended on grub-install being done first, and I got a kinda yesish answer that wasn't all that convincing. But the suggestion was to use 'grub2-install --grub-setup=/bin/true /dev/sdX' before grub2-mkconfig. This causes all the parts of grub to be installed except the singular thing people object to, and is the sole reason why they say they don't want a bootloader installed - which is boot.img being written into the MBR. I've tested that combination and it's safe. So if the code were changed just that no bootloader simply means *adding* --grub-setup=/bin/true and doing everything else we already do, that'd be the easiest fix that helps the most people IMO. BTW I think device.map is deprecated (?). I dunno, it's in there for the regular grub2 install so I kept it for the 'non-install-install' I'm suggesting. bootloader.py is really falling-off-a-log-simple code, it wouldn't be at all difficult to implement just about any approach to this, AFAICS. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Mojolicious-4.66.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: 427987a3d564958d174f8229905b294b Mojolicious-4.66.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mojolicious] Update to 4.66
commit e0f1a688c9075b27c5277be78ee90a6499544aab
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Jan 5 11:17:51 2014 +0100
Update to 4.66
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7f08c1a..00d5f24 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,3 +111,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-4.58.tar.gz
/Mojolicious-4.59.tar.gz
/Mojolicious-4.63.tar.gz
+/Mojolicious-4.66.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 8b79672..9b53eda 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:4.63
+Version:4.66
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Jan 05 2014 Emmanuel Seyman emman...@seyman.fr - 4.66-1
+- Update to 4.66
+
* Sun Dec 22 2013 Emmanuel Seyman emman...@seyman.fr - 4.63-1
- Update to 4.63
diff --git a/sources b/sources
index 4eda521..729ed4f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-37723246e7361e7066efc7a07694e048 Mojolicious-4.63.tar.gz
+427987a3d564958d174f8229905b294b Mojolicious-4.66.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Data-Random-0.11.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Data-Random: 9604ddc45eff8fc95803f34a7553c93b Data-Random-0.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-Random] Update to 0.11
commit d086921ef084daef9615ecf92c3d965154430306
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Jan 5 11:36:12 2014 +0100
Update to 0.11
.gitignore|1 +
perl-Data-Random.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 117cd29..9bc9179 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Data-Random-0.05.tar.gz
/Data-Random-0.08.tar.gz
/Data-Random-0.09.tar.gz
/Data-Random-0.10.tar.gz
+/Data-Random-0.11.tar.gz
diff --git a/perl-Data-Random.spec b/perl-Data-Random.spec
index 2c1faa2..83b4cc7 100644
--- a/perl-Data-Random.spec
+++ b/perl-Data-Random.spec
@@ -1,5 +1,5 @@
Name: perl-Data-Random
-Version:0.10
+Version:0.11
Release:1%{?dist}
Summary:Perl module to generate random data
License:GPL+ or Artistic
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Jan 05 2014 Emmanuel Seyman emman...@seyman.fr - 0.11-1
+- Update to 0.11
+
* Sun Nov 03 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-1
- Update to 0.10
diff --git a/sources b/sources
index bd7105d..e283130 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-201ae1ba6b7888b9eaf0ea20fd06d60d Data-Random-0.10.tar.gz
+9604ddc45eff8fc95803f34a7553c93b Data-Random-0.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1047282] SELinux is preventing /usr/bin/perl from 'append' accesses on the file .
https://bugzilla.redhat.com/show_bug.cgi?id=1047282 Kevin Fenzi ke...@scrye.com changed: What|Removed |Added CC||perl-devel@lists.fedoraproj ||ect.org, ||redhat-bugzilla@linuxnetz.d ||e Component|spamassassin|perl-Razor-Agent Assignee|wtog...@gmail.com |redhat-bugzilla@linuxnetz.d ||e --- Comment #6 from Kevin Fenzi ke...@scrye.com --- Well, looking at the razor package it looks like it always looks for HOME... ;( Moving to that component for comment. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PdlJ6oFs9ua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-FormFu-Model-DBIC] Update to 1.00
commit 3bd91e3c579c426739f09993dcbc5098dbaea628
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Jan 5 18:02:21 2014 +0100
Update to 1.00
.gitignore |1 +
perl-HTML-FormFu-Model-DBIC.spec | 14 +-
sources |2 +-
3 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e791e98..ba6bc55 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ HTML-FormFu-Model-DBIC-0.06000.tar.gz
/HTML-FormFu-Model-DBIC-0.09000.tar.gz
/HTML-FormFu-Model-DBIC-0.09002.tar.gz
/HTML-FormFu-Model-DBIC-0.09010.tar.gz
+/HTML-FormFu-Model-DBIC-1.00.tar.gz
diff --git a/perl-HTML-FormFu-Model-DBIC.spec b/perl-HTML-FormFu-Model-DBIC.spec
index a430bec..9ccd137 100644
--- a/perl-HTML-FormFu-Model-DBIC.spec
+++ b/perl-HTML-FormFu-Model-DBIC.spec
@@ -1,7 +1,7 @@
Name: perl-HTML-FormFu-Model-DBIC
Summary:Integrate HTML::FormFu with DBIx::Class
-Version:0.09010
-Release:3%{?dist}
+Version:1.00
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/C/CF/CFRANKS/HTML-FormFu-Model-DBIC-%{version}.tar.gz
@@ -9,20 +9,22 @@ URL:
http://search.cpan.org/dist/HTML-FormFu-Model-DBIC
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
+BuildRequires: perl(Crypt::CBC)
BuildRequires: perl(DateTime::Format::SQLite)
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBIx::Class) = 0.08108
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(HTML::FormFu) = 0.09010
+BuildRequires: perl(HTML::FormFu) = 1.00
BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(SQL::Translator)
BuildRequires: perl(Task::Weaken)
+BuildRequires: perl(Test::Aggregate::Nested)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More)
BuildRequires: perl(YAML::Syck)
Requires: perl(DBIx::Class) = 0.08108
-Requires: perl(HTML::FormFu) = 0.09010
+Requires: perl(HTML::FormFu) = 1.00
%{?perl_default_filter}
@@ -34,7 +36,6 @@ Integrate your HTML::FormFu forms with a DBIx::Class model.
%prep
%setup -q -n HTML-FormFu-Model-DBIC-%{version}
-sed -i -e 's/\r//' t/update/null_if_empty.t
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -56,6 +57,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Sun Jan 05 2014 Emmanuel Seyman emman...@seyman.fr - 1.00
+- Update to 1.00
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.09010-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 1a95caa..b92a945 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8bc54938c45c965294fad04546315473 HTML-FormFu-Model-DBIC-0.09010.tar.gz
+e59f7edcf9f7b96ac84be62e9c6c3a09 HTML-FormFu-Model-DBIC-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 914265] perl-DBD-AnyData: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=914265 Christopher Meng cicku...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED CC||cicku...@gmail.com Resolution|--- |CANTFIX Last Closed||2014-01-05 12:42:43 --- Comment #3 from Christopher Meng cicku...@gmail.com --- Upstream hasn't fixed up the code and this package got retired. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=L005TiJ7ORa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 820663] update of Finance::Quote
https://bugzilla.redhat.com/show_bug.cgi?id=820663 --- Comment #15 from Peter Lawler redhat-bugzi...@bleeter.id.au --- Oh hey, I had forgotten about this bug until I updated to F20 and GnuCash was on the 'featured' list of the in-distro Software Installer. Did Bill and Marcela sort out the comaint as referenced in #comment8? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5FlmRtX5Dza=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1048134] decode_utf8() returns gibberish on non-string value
https://bugzilla.redhat.com/show_bug.cgi?id=1048134 lnie l...@redhat.com changed: What|Removed |Added CC||l...@redhat.com --- Comment #3 from lnie l...@redhat.com --- 2.54-2.fc20 works fine -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Dzi1yuK8B7a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Module-Pluggable-5.0.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Pluggable: 15a539c8d0b5e61d8a475949127fc682 Module-Pluggable-5.0.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Pluggable] 5.0 bump
commit af2df40337baf1b3ff3d3d1d2a79e738abd0e96c
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 6 08:10:58 2014 +0100
5.0 bump
.gitignore |1 +
perl-Module-Pluggable.spec |8 +---
sources|2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f098636..91f1a4e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/Module-Pluggable-4.6.tar.gz
/Module-Pluggable-4.7.tar.gz
/Module-Pluggable-4.8.tar.gz
+/Module-Pluggable-5.0.tar.gz
diff --git a/perl-Module-Pluggable.spec b/perl-Module-Pluggable.spec
index c623b95..e6f8aa3 100644
--- a/perl-Module-Pluggable.spec
+++ b/perl-Module-Pluggable.spec
@@ -1,10 +1,10 @@
-%global cpan_version 4.8
+%global cpan_version 5.0
Name: perl-Module-Pluggable
# Epoch to compete with perl.spec
Epoch: 1
# Keep two digit decimal part
Version:%{cpan_version}0
-Release:291%{?dist}
+Release:1%{?dist}
Summary:Automatically give your module the ability to have plugins
License:GPL+ or Artistic
Group: Development/Libraries
@@ -32,7 +32,6 @@ BuildRequires: perl(Data::Dumper)
BuildRequires: perl(lib)
BuildRequires: perl(Test::More) = 0.62
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(File::Basename)
Requires: perl(File::Spec::Functions) = 3.00
%if 0%(perl -e 'print $] 5.017')
Requires: perl(deprecate)
@@ -68,6 +67,9 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Mon Jan 06 2014 Petr Pisar ppi...@redhat.com - 1:5.00-1
+- 5.0 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:4.80-291
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 09cb7b2..5feaff0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-28806a26002ef887db8430f14ba3f5cd Module-Pluggable-4.8.tar.gz
+15a539c8d0b5e61d8a475949127fc682 Module-Pluggable-5.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1048455] perl-Module-Pluggable-5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1048455 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Module-Pluggable-5.00- ||1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-06 02:51:02 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mBaQVFLoDja=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
