Re: No preupgrade for F17-F18?, [Bug 872876] WONTFIX
On Thu, Nov 8, 2012 at 11:13 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-11-08 at 10:01 +, Camilo Mesias wrote: List, cc Chris, I reported a bug after trying to use F17 to preupgrade to F18. It didn't work using Anaconda (I am aware Anaconda is a WIP) but I was surprised at the response. If preupgrade is being canned then presumably it needs fixing to no longer offer the non-working and WONTFIX option to upgrade to F18. Also if a 'completely separate process that does not involve anaconda' is mooted then... could preupgrade call that, or refer to it if it's a manual process? The new tool has more or less the same shape as preupgrade. It's a two-stage process launched from the running system you want to upgrade, just like preupgrade, but it's all new code. The second stage goes through dracut, rather than anaconda. Details on how to test the new system are at https://fedoraproject.org/wiki/QA:Fedora_18_Upgrade_Testing , give it a shot. Yes, we should suppress preupgrade from offering upgrades from F17 somehow. The obvious thing would be to mark it as preupgrade-ok=False in https://mirrors.fedoraproject.org/releases.txt . I'll ask releng. Dunno why I didn't think of that before, thanks for the nudge. We should make fedup obsolete preupgrade. But we should have a gui first . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 11/08/2012 03:10 PM, Roberto Ragusa wrote: Hmm, I now see there is a set -e at the beginning. Still a little scary.:-) Scary is only the idea. And only because we are not used to do rolling upgrades. Ask somebody from Debian experiance if this is scary ;) And honestly, if the upgrade fails, let it be rather on command line in open console, rather then inside of systemd service or inside dracut, where I will have hard time fixing the issue. -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý msu...@redhat.com wrote: On 11/08/2012 03:10 PM, Roberto Ragusa wrote: Hmm, I now see there is a set -e at the beginning. Still a little scary.:-) Scary is only the idea. And only because we are not used to do rolling upgrades. Ask somebody from Debian experiance if this is scary ;) There are some upgrade tasks that you simply cannot do from within a running system (ex: usermove). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 02:15 AM, Adam Williamson wrote: I'd put things more strongly than Bill: what's been happening in anaconda lately is the precise opposite of what Johann suggests, and that's exactly the right direction. I question if that's the right direction since I cant for the love of me figure out how they are going to be able to revert the installer if it becomes necessary in the future which this release cycle has proven that it *has* to be able to do that. So care to explain to me since you are such an Anaconda expert how they are going to do that since none of the Anaconda developers have been able so far or even outline to me how they *plan* to support that in the near future ... Not maintaining the installer on three branches also takes away the ability to release updated GA release with updated Anaconda which people from the community have wanted and been doing themselves on their own and there is a demand for it as well ( less demand after the Anaconda developers introduced the ability to install updates directly if you have network connection but demand never the less ) And as Tom has pointed out them floating on an cloud like some golden child through our process where the rules that *every* other maintainer and component have to follow is not fair now is it. If we would have been given the ability to tell them to come back in F19 when the installer was more complete we would have but you know as well as I do that they gave us no option to do so... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 07:43 GMT, Adam Williamson wrote: It hasn't really 'skyrocketed'. We cited 512MB for several releases, bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for F17, and it's back up to 768MB or 1GB for F18 atm because everyone has more important stuff to do than optimize the RAM usage right now. But it's not been rising crazily or anything. I think the last time someone took a deep look at RAM use during install - during F17 cycle when we got it back down to 512MB - it turned out a lot of the usage happened during package install and wasn't really to do with anaconda at all. I understand and accept that now everybody in the anaconda-land is busy with something else, but let it not slip our attention how absolutely crazy it is when the installation program requires twice as much (or more) of the resources than all programs running on the computer combined. I have here a server with RHEL-6 which I had to upgrade to 512MB just to be able to install a system on it. Now it has plenty of free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted. With the spread of virtual machines, it seems to be even more obvious. Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 10:21 AM, Jaroslav Reznik jrez...@redhat.com wrote: As someone pointed out in yesterday meeting - Fedora is becoming more a combo of time/feature based distribution. I don't think that's really the case. The important thing about a time-based schedule is that at some point you _stop accepting new features_ (and we do have that), not that there is a 100% reliable time when the GA release happens (which we don't have). The only way to have a 100% reliable GA release date would be to have a development process that guarantees no regressions, so that no surprises ever happen. (Some projects do have that - full test coverage and continuous integration running the tests after every commit - but we obviously don't, and probably never will.) Mirek (The problem with feature-based schedules is that if you plan features A, B, C, and to release when all of them are done, and A becomes significantly delayed, causing a slip in the schedule. In the meantine, somebody else starts working on D, adds it to the release... and when A is done, D is delayed, causing a next slip. IIRC emacs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 5:07 PM, David Cantrell dcantr...@redhat.com wrote: On Thu, Nov 08, 2012 at 05:44:41AM -0500, Jaroslav Reznik wrote: We have bigger issue with features that are OUT OF the process, not communicated at all. If you take a look on New Installer UI, it fits current design, it was a late as the scope was bigger than Anaconda team thought but it's there. The scope was not a surprise to us, we knew from the beginning when we started this that the delivery of all newui work would have to be staged across multiple Fedora releases. It _was_ probably a surprise to some of us in FESCo. If you look at the NewInstallerUI feature, there's very little indication that there is a plan to stage things across releases - there is only a single mention of F19 related to a feature that is really not that important for the average Fedora user. I suppose what happened here was, that the Anaconda team knew that they want to do a multi-release transition, it was obvious, so it wasn't really emphasized anywhere - and anyone reading the feature page didn't find anything wrong about it. OTOH FESCo started with the assumption that F18 needs to ship with the expected functionality, and seeing the feature, it was obvious that the Anaconda team was proposing the feature within these constraints. So nobody even noticed the difference basically until the predecessor of the detailed https://fedoraproject.org/wiki/Anaconda/Work_List page was created. However, I'm not sure that we can solve this kind of disconnect by a process change. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 4:58 PM, David Cantrell dcantr...@redhat.com wrote: 2) Just stop everything, move newui to F-19, and ship the F-17 installer. This just delays what we are going through right now until the F-19 cycle. We need to identify the failings at some point and work to improve/change them. (Completely hypothetical at this point) Yes, from the point of view of the Anaconda team - but from the point of view of the other teams, it would have allowed to ship _their_ features to users. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 5:32 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/08/2012 03:58 PM, David Cantrell wrote: Not true. As with our other major changes, we new it would be absolutely impossible to deliver all functionality in a single release. What exactly prevented the Anaconda from implementing Anaconda 2.0 in a F19 or later when it was fully complete? Or if I rephrase why could not the community continue to use Anaconda in it's form that it existed in F17 until the new installer was *completly* done? Well, FESCo _did_ approve the plan to move to F18 with no contingency plan. The blame here is on FESCo, not on Anaconda. Yes, it was a major error; we could have at that point insisted on keeping the F17 implementation working, and it probably would have been easier at that point to maintain two branches than to backport nobody-knows-what now. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 8, 2012 at 9:40 PM, David Lehman dleh...@redhat.com wrote: On Thu, 2012-11-08 at 17:20 +, Jóhann B. Guðmundsson wrote: On 11/08/2012 05:14 PM, Stephen John Smoogen wrote: On 8 November 2012 10:06, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/08/2012 04:37 PM, Matthew Garrett wrote: On Thu, Nov 08, 2012 at 04:32:29PM +, Jóhann B. Guðmundsson wrote: Or if I rephrase why could not the community continue to use Anaconda in it's form that it existed in F17 until the new installer was *completly* done? Because nobody in the community did the work to make the F17 Anaconda work in F18? This also touches on Who's responsible for an feature Just recently FESCO decided *for* Kay that he was responsible to ensure the migration related docs and what not kept working for the name change of configuration files that takes place in systemd ( which was not even a feature ) Applying the same logic here the Anaconda developers themselves would have been responsible keeping the old code working until the new one was ready to completely replace it. Your problem is that you are assuming a lot of things without actually doing any legwork to find out what anaconda does. Anaconda does a lot of probing of hardware which changes when kernels change. Anaconda requires changes when dracut changes APIs. Every release requires changes in what is blacklisted and what is not blacklisted. It requires dealing with the usual multiple changes in python apis and such. It has other changes due to EFI or secure boot or other features. None of them are trivial and doing them in parallel is usually not possible. Not that your response is relate to who's responsible for making those changes, but is that not a fundamental flaw in the installer and it's design? No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning LibRaw and gource
Hi, I don't have enough bandwidth to do anything useful with them any more, so I'm orphaning them. LibRaw is a dependency for shotwell and gource is, well, pretty neat. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote: On Thu, Nov 8, 2012 at 9:40 PM, David Lehman dleh...@redhat.com wrote: On Thu, 2012-11-08 at 17:20 +, Jóhann B. Guðmundsson wrote: On 11/08/2012 05:14 PM, Stephen John Smoogen wrote: On 8 November 2012 10:06, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/08/2012 04:37 PM, Matthew Garrett wrote: On Thu, Nov 08, 2012 at 04:32:29PM +, Jóhann B. Guðmundsson wrote: Or if I rephrase why could not the community continue to use Anaconda in it's form that it existed in F17 until the new installer was *completly* done? Because nobody in the community did the work to make the F17 Anaconda work in F18? This also touches on Who's responsible for an feature Just recently FESCO decided *for* Kay that he was responsible to ensure the migration related docs and what not kept working for the name change of configuration files that takes place in systemd ( which was not even a feature ) Applying the same logic here the Anaconda developers themselves would have been responsible keeping the old code working until the new one was ready to completely replace it. Your problem is that you are assuming a lot of things without actually doing any legwork to find out what anaconda does. Anaconda does a lot of probing of hardware which changes when kernels change. Anaconda requires changes when dracut changes APIs. Every release requires changes in what is blacklisted and what is not blacklisted. It requires dealing with the usual multiple changes in python apis and such. It has other changes due to EFI or secure boot or other features. None of them are trivial and doing them in parallel is usually not possible. Not that your response is relate to who's responsible for making those changes, but is that not a fundamental flaw in the installer and it's design? No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. I'm afraid anaconda _is that_ special. AFAICT there is no other piece of code that directly interacts with dracut, systemd, Network Manager, gtk3 (and GObject introspection) and many other components that change quite often. If there is such code, I'd be happy to look at how its developers handle such changes and take a lecture from them. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning LibRaw and gource
On Fri, Nov 9, 2012 at 5:41 AM, Siddhesh Poyarekar spoya...@redhat.comwrote: Hi, I don't have enough bandwidth to do anything useful with them any more, so I'm orphaning them. LibRaw is a dependency for shotwell and gource is, well, pretty neat. Taken, thanks for your work! -J Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote: FYI, re: firewalld minimal install. firewalld isn't in the minimal comps groups. However, it's pulled in by anaconda, see pyanaconda/install.py: # anaconda requires storage packages in order to make sure the target # system is bootable and configurable, and some other packages in order # to finish setting up the system. packages = storage.packages + [authconfig, firewalld] Why do anaconda dependencies end up in the minimal install ? That shouldn't really be necessary, right ? It has always bugged me the we end up with anaconda on the installed system when installing from a live cd. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121109 changes
Compose started at Fri Nov 9 09:15:42 UTC 2012 Broken deps for x86_64 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dvipdfm] dvipdfm-0.13.2d-44.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvipdfmx] dvipdfmx-0-0.35.20090708cvs.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvipng] dvipng-1.14-4.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvisvgm] dvisvgm-1.0.12-1.fc18.x86_64 requires libkpathsea.so.4()(64bit) [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [mftrace] mftrace-1.2.15-8.fc18.x86_64 requires texlive-fonts [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [perl-Hardware-Verilog-Parser] perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires perl(:MODULE_COMPAT_5.14.2) [perl-OpenOffice-UNO] perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [pyfuzzy] pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python [python-flask] 1:python-flask-doc-0.9-1.fc18.noarch requires python-flask = 0:0.9-1.fc18 [reciteword] reciteword-0.8.4-10.fc18.x86_64 requires esound [resource-agents] resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit) resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit) [ruby-revolution] ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libedataserver-1.2.so.16()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libecal-1.2.so.12()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libebook-1.2.so.13()(64bit) [rubygem-calendar_date_select] rubygem-calendar_date_select-1.15-6.fc17.noarch requires ruby(abi) = 0:1.8 [rubygem-linecache] rubygem-linecache-0.43-5.fc17.x86_64 requires ruby(abi) = 0:1.8 rubygem-linecache-0.43-5.fc17.x86_64 requires libruby.so.1.8()(64bit) [rubygem-ruby-debug] rubygem-ruby-debug-0.10.5-0.3.rc1.fc17.1.noarch requires ruby(abi) = 0:1.8 [rubygem-ruby-debug-base] rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires ruby(abi) = 0:1.8 rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires libruby.so.1.8()(64bit) [tetex-tex4ht] tetex-tex4ht-1.0.2008_09_16_1413-10.fc18.x86_64 requires libkpathsea.so.4()(64bit) [xdvik] xdvik-22.84.14-12.fc18.x86_64 requires libkpathsea.so.4()(64bit) [xdvipdfmx] xdvipdfmx-0.4-9.fc18.x86_64 requires libkpathsea.so.4()(64bit) [znc-infobot] znc-infobot-0.206-2.fc18.x86_64 requires znc = 0:0.206 Broken deps for i386
PHP embedded library soname change
Hi, In previous version libphp5.so used php version as soname (so, libphp5-5.4.8.so) For new version it will only use php major version (so, libphp5-5.4.so) Already available for Fedora 18 (php-5.4.8-6 in testing). Dependent package owner (maniadrive and uwsgi) are aware of this change. Of course, for each new version, I will run an ABI/API check (as upstream doesn't care of it for this experimental library) before pushing the update to our repository. Regards, Remi. P.S. : yes, this will make my life easier (no need for buildoverride) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Template-Toolkit/f17] Remove executable bit from documentation
commit f245e6728b67533451d5f078f7b3c4674af42b50
Author: Petr Písař ppi...@redhat.com
Date: Fri Nov 9 14:25:38 2012 +0100
Remove executable bit from documentation
perl-Template-Toolkit.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Template-Toolkit.spec b/perl-Template-Toolkit.spec
index 753be83..8ed0338 100644
--- a/perl-Template-Toolkit.spec
+++ b/perl-Template-Toolkit.spec
@@ -1,6 +1,6 @@
Name: perl-Template-Toolkit
Version:2.24
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Template processing system
Group: Development/Libraries
License:GPL+ or Artistic
@@ -9,7 +9,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABW/Template-Toolkit
Source1:http://tt2.org/download/TT_v224_html_docs.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: perl(AppConfig)
+BuildRequires: perl(AppConfig)
BuildRequires: perl(Cwd)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec::Functions)
@@ -59,6 +59,7 @@ LaTeX, and so on.
%setup -q -n Template-Toolkit-%{version} -a 1
find lib -type f | xargs chmod -c -x
find TT_v*_html_docs -depth -name .svn -type d -exec rm -rf {} \;
+find TT_v*_html_docs -type f -exec chmod -x {} +;
# Convert file to UTF-8
iconv -f iso-8859-1 -t utf-8 -o Changes{.utf8,}
@@ -102,6 +103,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri Nov 09 2012 Petr Pisar ppi...@redhat.com - 2.24-2
+- Remove executable bit from documentation
+
* Thu Aug 23 2012 Tom Callaway s...@fedoraproject.org - 2.24-1
- update to 2.24
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Attention, dependency fighters
On Fri, Nov 09, 2012 at 07:12:50AM -0500, Matthias Clasen wrote: firewalld isn't in the minimal comps groups. However, it's pulled in by anaconda, see pyanaconda/install.py: # anaconda requires storage packages in order to make sure the target # system is bootable and configurable, and some other packages in order # to finish setting up the system. packages = storage.packages + [authconfig, firewalld] Why do anaconda dependencies end up in the minimal install ? That shouldn't really be necessary, right ? It has always bugged me the we end up with anaconda on the installed system when installing from a live cd. The storage packages are going to be needed for the system to boot. Anaconda could probably add some smarts to remove authconfig if it wasn't pulled in by anything in the selected comps, but I'm not sure it'd be worth the special logic -- we might as well just put it in @core (even though it's not super-tiny). Firwealld I don't know about, though. If anaconda sets up the firewall using firewalld but then doesn't install it, will the old iptables scripts load the configuration? It'd be nice if it could, because firewalld is *another* big change that it'd be nice to have a reasonable back-out plan for. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
On 11/09/2012 01:34 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 07:12:50AM -0500, Matthias Clasen wrote: firewalld isn't in the minimal comps groups. However, it's pulled in by anaconda, see pyanaconda/install.py: # anaconda requires storage packages in order to make sure the target # system is bootable and configurable, and some other packages in order # to finish setting up the system. packages = storage.packages + [authconfig, firewalld] Why do anaconda dependencies end up in the minimal install ? That shouldn't really be necessary, right ? It has always bugged me the we end up with anaconda on the installed system when installing from a live cd. The storage packages are going to be needed for the system to boot. Anaconda could probably add some smarts to remove authconfig if it wasn't pulled in by anything in the selected comps, but I'm not sure it'd be worth the special logic -- we might as well just put it in @core (even though it's not super-tiny). Firwealld I don't know about, though. If anaconda sets up the firewall using firewalld but then doesn't install it, will the old iptables scripts load the configuration? It'd be nice if it could, because firewalld is *another* big change that it'd be nice to have a reasonable back-out plan for. You might want to remove plymouth from the minimal install since it does not make sense having it there anyway JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 18:15 -0800, Adam Williamson wrote: Again, this isn't an accident, it's a very deliberate plan. One of the whole points of the Fedora philosophy is that we're supposed to share and reuse work and code as much as possible. We're not supposed to write five independent versions of everything at all. The fact that anaconda team had to maintain their own loader (which did pretty much what dracut does), their own partition code (which did pretty much what parted does) and their own network code (which did pretty much what NetworkManager does, only not as well) was a problem, not an advantage. It meant we were duplicating a whole bunch of effort to get inconsistent results. anaconda team was wasting time maintaining a bunch of network code that wasn't as good as NetworkManager in the first place (ditto for the other two examples). The overall strategy of the anaconda team has been to try and reduce their maintenance burden; they'd reached a point where they were almost running full tilt just to stand still - they had so much unique code to maintain that it took almost all their resources just to keep it working and up to date. They couldn't work on actually improving anaconda, it was the best they could do just to keep it at the level it was at. So they deliberately went out and aimed to reduce that burden, and using existing code like dracut, NM and parted was just a part of that plan. newUI is another part of that plan - it's a lot of work now, but the aim is that it's less of a maintenance burden than the old UI code when it's done. The ultimate goal is that an anaconda team with the same resources will be able to devote much less time to just keeping a giant codebase working, and more time to enhancing a smaller codebase. So no, our installer absolutely is not independent from the rest of the distro, it's not intended to be and it shouldn't be. It's deliberately designed to reuse components of the distribution as much as possible, and the goal is if anything to increase this over time, not decrease it. The maintenance burden of adjusting to changes in those components it depends on is non-zero - which is where we came into this side track - but that's not a problem. It's non-zero, but it's much lower than duplicating all those components from scratch, only worse. I agree 100% that it is right for the installer to use the system infrastructure for the things it needs to do. That is a much needed and very welcome change. I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Maybe that is a design discussion for a different installer, anaconda has always been a 'fat' installer, and it doesn't look like that is going change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, Nov 09, 2012 at 01:41:08PM +, Jóhann B. Guðmundsson wrote: You might want to remove plymouth from the minimal install since it does not make sense having it there anyway Yes probably. Anyone know why it's there? I'm starting to think that a dedicated list for the minimal core sig makes sense after all. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:15:55PM -0800, Adam Williamson wrote: On Thu, 2012-11-08 at 15:19 -0500, Bill Nottingham wrote: Matthew Garrett (mj...@srcf.ucam.org) said: Patches that cleanly decouple Anaconda from the entire software stack that it runs on top of would probably be received with open arms, but nobody who works on it has any idea how to implement them. In fact, this is what has been done in anaconda over the past couple of releases - Anaconda migrated from having its own boot and init infrastructure to using system-provided items such as dracut and systemd. But that's complicated work, and while you're doing that migration, you're doing a lot of arbitration as to what bits are in generic dracut, what bits are in generic systemd, and what bits remain in anaconda. And during that process, you are *very* tied to the version of the underlying system, until the work is fully complete and there is a defined separation of features into each layer. This, incidentally, also is why running the F17 installer on F19 isn't practical. I think this whole subthread took a crazy left turn a ways back and is _way_ into the weeds by now. I'd put things more strongly than Bill: what's been happening in anaconda lately is the precise opposite of what Johann suggests, and that's exactly the right direction. We don't want to have an installer stack that's completely independent of the rest of the distro. I don't think anyone would take patches to do that, really. We've been trying to do exactly the opposite. Let's look at the practical examples. anaconda used to have its own partition inspection code, its own loader stage, and its own network management code and UI. Over the last few years, all of those have very deliberately been killed and replaced with bits of the main distro. The partition stuff was replaced by libparted; the loader was replaced by dracut; and the network code was replaced by NetworkManager. Again, this isn't an accident, it's a very deliberate plan. One of the whole points of the Fedora philosophy is that we're supposed to share and reuse work and code as much as possible. We're not supposed to write five independent versions of everything at all. The fact that anaconda team had to maintain their own loader (which did pretty much what dracut does), their own partition code (which did pretty much what parted does) and their own network code (which did pretty much what NetworkManager does, only not as well) was a problem, not an advantage. It meant we were duplicating a whole bunch of effort to get inconsistent results. anaconda team was wasting time maintaining a bunch of network code that wasn't as good as NetworkManager in the first place (ditto for the other two examples). Just as a clarification here anaconda has used libparted for a very long time. It is one piece of the larger storage backend code. The libparted changes that came with our storage backend rewrite a number of years ago was that we began relying on libparted to do more for us. I'll also point out that we both own the parted component in Fedora and are upstream contributors and co-maintainers. The overall strategy of the anaconda team has been to try and reduce their maintenance burden; they'd reached a point where they were almost running full tilt just to stand still - they had so much unique code to maintain that it took almost all their resources just to keep it working and up to date. They couldn't work on actually improving anaconda, it was the best they could do just to keep it at the level it was at. So they deliberately went out and aimed to reduce that burden, and using existing code like dracut, NM and parted was just a part of that plan. newUI is another part of that plan - it's a lot of work now, but the aim is that it's less of a maintenance burden than the old UI code when it's done. The ultimate goal is that an anaconda team with the same resources will be able to devote much less time to just keeping a giant codebase working, and more time to enhancing a smaller codebase. So no, our installer absolutely is not independent from the rest of the distro, it's not intended to be and it shouldn't be. It's deliberately designed to reuse components of the distribution as much as possible, and the goal is if anything to increase this over time, not decrease it. The maintenance burden of adjusting to changes in those components it depends on is non-zero - which is where we came into this side track - but that's not a problem. It's non-zero, but it's much lower than duplicating all those components from scratch, only worse. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
raising warning flag on firewalld-default feature
https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. The old scripts are primitive and can't handle dynamic environments very well, so having something new and modern is admirable. The lokkit family of GUI config tools is primative enough to be considered dangerous. And a lot of integration work has been done in NetworkManager, libvirt, and a bunch of other places. But, I think we should strongly consider pushing this to F19, because: - this turns out to be a big change! - there's little to no documentation - the UI is very confusing, with a large number of zones and no apparent way to configure those zones - toolset is not yet robust -- has funny things like `firewall-cmd --enable` enables *panic mode*. - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources The alternative is to enable it by default in some cases but not in others, but I think that's just confusing. We should wait until it's ready and then turn it on everywhere. I think this bug is illustrative of the problems we're going to see if we ship as-is: https://bugzilla.redhat.com/show_bug.cgi?id=869625. Stef isn't trying to anything crazy, but is both foiled by the lack of options and confused by the choices that are there. We're going to get a lot more bugs like this, and worse, unhappy users. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Minimal Core SIG -- please join if you're interested
So, here's a proposal for a semi-informal group linking different stakeholders interested in curating the @core package selection: https://fedoraproject.org/wiki/SIGs/Minimal_Core I wonder whether Core is a good word for Fedora Minimal installation SIG. Because currently the minimal installation uses @base yum group. @core group is included always, whether you want it or not. If you really want to have a _core_ system, you must use kickstart like this: %packages --nobase %end That is even smaller than default minimal installation. But I understand this initiative is related to the default minimal installation as displayed in anaconda. So maybe Fedora Base SIG, or Fedora Minimal SIG? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote: Aside from that - I can understand your frustration that you think people are chinwagging and not helping, but my point is kind of that you (anaconda team) have brought that on yourselves. I'm not on the Anaconda team. That's my point. When bugs threaten the release of the distribution then *everyone* involved in the distribution should be willing to work on them, not just insist that it's up to the developers currently working on it. I've just spent two days of vacation working on this because it's clear that more developer contribution would be useful and because I actually want us to release Fedora 18. We're not obliged to sit here pointing at a sinking ship when we could do something to avoid that ship from sinking. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Le Ven 9 novembre 2012 14:48, Matthias Clasen a écrit : I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Only if you forget about all the automated mass installation processes where you do absolutely want to feed a kickstart to the installer and have it configure everything in one go. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 09 Nov 2012, Nicolas Mailhot wrote: Le Ven 9 novembre 2012 14:48, Matthias Clasen a écrit : I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Only if you forget about all the automated mass installation processes where you do absolutely want to feed a kickstart to the installer and have it configure everything in one go. The simple fact that you are feeding kickstart file to a single entity does not mean this entity cannot outsource actual tasks to others and run them later, be it post-install phase in the actual installer's session or after (a simulated) reboot. Input interface change is not needed for backend changes. If all you are interested is 'one go' installer from perspective of the feeding kickstart files, it would still be the same. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Minimal Core SIG -- please join if you're interested
On Fri, Nov 09, 2012 at 09:45:56AM -0500, Kamil Paral wrote: I wonder whether Core is a good word for Fedora Minimal installation SIG. Because currently the minimal installation uses @base yum group. @core group is included always, whether you want it or not. If you really want to have a _core_ system, you must use kickstart like this: There is no more @base group -- it's @standard now. Can't find the message about it right now. But yeah, your point still stands. That is even smaller than default minimal installation. But I understand this initiative is related to the default minimal installation as displayed in anaconda. I was actually more focused on the actual core group, in line with http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#Core But, I think that it's reasonable for this group to be concerned with both; the definition should probably be expanded. The reason I didn't want just Fedora Minimal is that sounds too much like an ideological effort to make Fedora into an ultra-tiny distro. But the exact name isn't important to me and if others think it'd be better to just be Minimal I'm totally okay with that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 11:21:07AM +0100, Matej Cepl wrote: On 2012-11-09, 07:43 GMT, Adam Williamson wrote: It hasn't really 'skyrocketed'. We cited 512MB for several releases, bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for F17, and it's back up to 768MB or 1GB for F18 atm because everyone has more important stuff to do than optimize the RAM usage right now. But it's not been rising crazily or anything. I think the last time someone took a deep look at RAM use during install - during F17 cycle when we got it back down to 512MB - it turned out a lot of the usage happened during package install and wasn't really to do with anaconda at all. I understand and accept that now everybody in the anaconda-land is busy with something else, but let it not slip our attention how absolutely crazy it is when the installation program requires twice as much (or more) of the resources than all programs running on the computer combined. I have here a server with RHEL-6 which I had to upgrade to 512MB just to be able to install a system on it. Now it has plenty of free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted. With the spread of virtual machines, it seems to be even more obvious. Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? Yes, that is an advantage, but that shouldn't be slicing up one computer in to multiple very underpowered smaller computers. Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote: Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? Yes, that is an advantage, but that shouldn't be slicing up one computer in to multiple very underpowered smaller computers. Why not? That's incredibly useful. Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. What about my host system for 500 VMs? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No preupgrade for F17-F18?, [Bug 872876] WONTFIX
On Thu, 08 Nov 2012 23:38:21 -0800 Adam Williamson awill...@redhat.com wrote: On Fri, 2012-11-09 at 08:07 +0100, Kevin Kofler wrote: Jaroslav Reznik wrote: Prepupgrade should be probably taken out from F17 (as there's no newer Fedora that supports preupgrade). We can't really take it out from the shipped release, fedup will have to Obsolete it when it's ready. Until then, marking F18 as preupgrade-ok=False should fix the immediate problem. I already filed a bug on the former and asked releng to do the latter. I did set preupgrade-ok=False yesterday for f18. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Minimal Core SIG -- please join if you're interested
On 11/09/2012 06:45 AM, Kamil Paral wrote: I wonder whether Core is a good word for Fedora Minimal installation SIG. Because currently the minimal installation uses @base yum group. @core group is included always, whether you want it or not. If you really want to have a_core_ system, you must use kickstart like this: %packages --nobase %end This isn't true anymore. --nobase doesn't do anything because there is no @base. It was renamed to @standard, and it's no longer selected by default in kickstart. Also, the minimal install (GUI or TUI) does %packages \n %end as well, only @core gets installed. So the result is the same as doing the kickstart. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 9 Nov 2012 08:53:19 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Fri, Nov 09, 2012 at 01:41:08PM +, Jóhann B. Guðmundsson wrote: You might want to remove plymouth from the minimal install since it does not make sense having it there anyway Yes probably. Anyone know why it's there? IIRC, even if you 'disable' it, plymouth is still the thing handing the text mode output. Perhaps some plymouth folks would chime in here... I'm starting to think that a dedicated list for the minimal core sig makes sense after all. I'm thinking the opposite. ;) For example, as above plymouth folks read the devel list, you would have to find and invite them to a new list. ;) Can't we just use this list and try and add more signal to it for those that killed off the long threads? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Minimal Core SIG -- please join if you're interested
On Fri, Nov 09, 2012 at 08:11:17AM -0800, Jesse Keating wrote: Also, the minimal install (GUI or TUI) does %packages \n %end as well, only @core gets installed. So the result is the same as doing the kickstart. Okay, cool -- I didn't know that was changed too. Good! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote: Yes probably. Anyone know why it's there? IIRC, even if you 'disable' it, plymouth is still the thing handing the text mode output. Perhaps some plymouth folks would chime in here... I removed it from my test vm with no apparent ill effects I'm starting to think that a dedicated list for the minimal core sig makes sense after all. I'm thinking the opposite. ;) For example, as above plymouth folks read the devel list, you would have to find and invite them to a new list. ;) Eh, I'm willing to try either way. Can't we just use this list and try and add more signal to it for those that killed off the long threads? Mailman needs a feature where it automatically redirects super-long threads to a separate mailing list. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. This replaces iptables and ip6tables? Perhaps I have had my head in the sand (I certainly haven't been looking around) but this is the first I've heard of a replacement for iptables. Has firewalld been tested as well as iptables has (which seems to be a fairly bullet-proof solution)? But, I think we should strongly consider pushing this to F19, because: ... - there's little to no documentation I'd happily help document it in the Fedora Security Guide if I could get the proper content or access to the developers. Heck, I'll even help write stand-alone documentation for this project if needed. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) +1 - -Eric Sparks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQnS4+AAoJEIB2q94CS7PRdGcP/1z5O5kgvHDX04E/6t3xhdWv w2JtwDC3zYc0KlASa+XFPlqFmvQUBngI7Esy3kJ8+mas+bFwVOftTRQhZz13mmfg C+eKe/rHtL2hEF/EDkWe23FSASrHdK6FNyotK7xxdfh3QYPGmavmFSvlETg6qUdS kkWRrTCtkro4EirO7KGbW7DDeuzcxqK6IHy6JStdevouwaTqJ/TtdCI2vYJKDTyg GkxQQwk00GCk7xox5dJq1jdpniVfpQ/pKAVb9BTuQYCaMCuqdv64xg6ggbkXi28T cIFkdKxNCBw0L5Ecwg3/d4y2OlTAJmBULsAQZ7piFKXFbHPb9CofxCypGSTn5cMw F9wnr/0geTw3UOxfi0OGNm2Wf0x2B9n7iyYZODxvihdoeg8OGbusPJr9viRYI7tA 47+/95ywXBTcAPxLwSCb3vXG2FImgnzwnaG/9xpKZk4dKAZcxQBxqlgDtBbilv8X zvr9ArmCG9hdEAojD66AKM5Qmzse+tPaAiDFecGBvlSN3/J2AOrTF9U64Akbkzg9 +uXkV3rk/DhP0JTLXvb8Aizbb9Y51PGO/G7KZH3tCYieaCQbkNdddNbIg3WI4kV1 AEGvDd30vDdAkl17UcguV6iwPwCP0tFs9GNcJRCEninL+/bQmVs2PcpYJ5+oPBsi vUc791SABXCttPkm1X/A =E0LH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
remove polkit from core?
Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
https://bugzilla.redhat.com/show_bug.cgi?id=875150 Spec URL: http://renich.fedorapeople.org/SPECS/mariadb.spec SRPM URL: http://renich.fedorapeople.org/SRPMS/ -- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric http://www.woralelandia.com/ http://www.introbella.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/09/2012 03:33 PM, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. The old scripts are primitive and can't handle dynamic environments very well, so having something new and modern is admirable. The lokkit family of GUI config tools is primative enough to be considered dangerous. And a lot of integration work has been done in NetworkManager, libvirt, and a bunch of other places. But, I think we should strongly consider pushing this to F19, because: - this turns out to be a big change! - there's little to no documentation Have you had a look at the man pages? - the UI is very confusing, with a large number of zones and no apparent way to configure those zones Go to the persistent view and you can configure zones, services and icmptypes. - toolset is not yet robust -- has funny things like `firewall-cmd --enable` enables *panic mode*. Nice find. You are the first to get this. Will work on it. - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Firewalld is using about 12M of memory (RES), produces only a small amount of wakeups ( 0.1) if idle. Where is the non-trivial use of system resources. The alternative is to enable it by default in some cases but not in others, but I think that's just confusing. We should wait until it's ready and then turn it on everywhere. I think this bug is illustrative of the problems we're going to see if we ship as-is: https://bugzilla.redhat.com/show_bug.cgi?id=869625. Stef isn't trying to anything crazy, but is both foiled by the lack of options and confused by the choices that are there. We're going to get a lot more bugs like this, and worse, unhappy users. libvirt is creating the firewall rules for guests - it is doing this with the old static model, where you loose these rules in case of other firewall changes, or with firewalld, but here changes are dynamic. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 08:48 AM, Jóhann B. Guðmundsson wrote: No I assume everyone expected the Anaconda developers to handle that if not they would have asked for assistance in that regard and outlined the steps necessary to do so which I assume would have been minimal if necessary et all since I expect the installer to be able to work on packages in F16 or F17 or F18 for that matter hence the installer would be unchanged while the package set he is installing would only change. Is my assumption wrong in that regard as in the installer in F17 could not have been used and if so why? A significant amount of work had to be done to the newui code base (which was largely developed and tested on F17) to get it to work in an F18 environment. To get the F17 code base to work in an F18 environment would have taken even more work, and that would would have had to be done twice. Once for the F17 code base, once for the F18 code base. We just don't have that many developers, so newui would be delayed again, and we'd have to do the same thing again for F19. Meanwhile any feature that requires installer interaction would have to either be punted, or coded twice, and noted in a growing list of things to re-check after the newui cut over to ensure it didn't break the new feature. Anaconda is increasingly dependent upon the environment around it, which has a tendency to change in unexpected and weird ways between releases. Much of anaconda development work is reacting to subtle bugs that arise in previously working code, being detective to figure out what has changed in the environment and why and what the new rules on the ground are so that we can make things work again. We operate in a space that people don't think about, and that doesn't get any real attention on a running system. When people make changes to the pre-root environment they think it's fairly isolated and that changes can happen with impunity, because runtime will be fine. Runtime people make changes but think it's fine if their own stack continues to work with the change or their stack is updated to work with the change, but Anaconda is left broken. We are not plug-n-play. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 9 Nov 2012 11:20:08 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote: Yes probably. Anyone know why it's there? IIRC, even if you 'disable' it, plymouth is still the thing handing the text mode output. Perhaps some plymouth folks would chime in here... I removed it from my test vm with no apparent ill effects Does a kernel upgrade work as expected? (dracut might want plymouth to put in the initramfs?) I'm starting to think that a dedicated list for the minimal core sig makes sense after all. I'm thinking the opposite. ;) For example, as above plymouth folks read the devel list, you would have to find and invite them to a new list. ;) Eh, I'm willing to try either way. :) Can't we just use this list and try and add more signal to it for those that killed off the long threads? Mailman needs a feature where it automatically redirects super-long threads to a separate mailing list. Yeah, although you could also just not pay attention to it at the client end. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
Le Ven 9 novembre 2012 17:35, Kevin Fenzi a écrit : On Fri, 9 Nov 2012 11:20:08 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote: Yes probably. Anyone know why it's there? IIRC, even if you 'disable' it, plymouth is still the thing handing the text mode output. Perhaps some plymouth folks would chime in here... I removed it from my test vm with no apparent ill effects Does a kernel upgrade work as expected? (dracut might want plymouth to put in the initramfs?) It works fine. The only thing that used to peg plymouth were some package deps, and they've been removed lately Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, 09.11.12 11:27, Matthew Miller (mat...@fedoraproject.org) wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? We can work towards that but it requires a bit of changes in systemd. A number of systemd services check with PK for authorization if an unprivileged user tries to execute a privileged operation. Since we never really tested this on systems that lack PK the fallback code that bypasses PK if it is not around didn't really get the testing it deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. So, I think it makes sense to make PK truly optional, but this needs a bit of love in some layers of our stack, not just systemd but others as well, I presume. If somebody wants to work on it, please do, and file bugs whenever you notice that you get a PK related error message where a fallback to classic Unix UID-based security doesn't work as it should. David actually documented explicitly that daemons should fall back to classic Unix-style uid-based authoization if PK is found not to be around. It's clearly systemd's fault that we so far didn't follow this fully. Of course, it should be clear that making PK optional if a desktop is installed is not desirable, but other than that I think for head-less systems such as servers or embedded making PK optional would be desirable goal and worthwile to spend a bit of work on. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 11:40 AM, Jóhann B. Guðmundsson wrote: Pointing out how the installer currently works does not change my opinion on the fact that if an installer ( any installer ) cannot run on his own bits isolated from the package set he is about install is a design flaw and is something that should be corrected ( from my pov ). I think you're talking about booting an F17 kernel, using an F17 content initrd and stage2 (F17 version dracut, systemd, udev, polkit, dbus, parted, lvm, ext/btrfs/xfs tools, glibc, yum, rpm, selinux, grub, etc...) and just point it at a newer repository of packages. While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. So no, it's not really possible to isolate the installer environment such that you can plug and play with different package sets and expect things to work. If you think this is some kind of design flaw, then knock yourself out redesigning it. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/09/2012 05:24 PM, Eric H. Christensen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. This replaces iptables and ip6tables? Perhaps I have had my head in the sand (I certainly haven't been looking around) but this is the first I've heard of a replacement for iptables. Has firewalld been tested as well as iptables has (which seems to be a fairly bullet-proof solution)? Please have a look at the feature list for F-18. firewalld replaces system-config-firewall/lokkit, and the iptables and ip6tables services, not the iptables package and command. The ip*tables services and also system-config-firewall/lokkit are still available and also usable after deactivation of the firewalld serice. With the latest request to move the services of iptables and ip6tables in a sub package, I will add a requirement to system-config-firewall for this. But, I think we should strongly consider pushing this to F19, because: ... - there's little to no documentation I'd happily help document it in the Fedora Security Guide if I could get the proper content or access to the developers. Heck, I'll even help write stand-alone documentation for this project if needed. I will provide content/help for this. The lack of documentation is really the showstopper here. If we had really good 1) hand-holding documentation and 2) technical documentation for admins, I'd be more willing to take the risk. (In an even more ideal world, the UI would be so well designed that the hand-holding documentation wouldn't be necessary.) +1 - -Eric Sparks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQnS4+AAoJEIB2q94CS7PRdGcP/1z5O5kgvHDX04E/6t3xhdWv w2JtwDC3zYc0KlASa+XFPlqFmvQUBngI7Esy3kJ8+mas+bFwVOftTRQhZz13mmfg C+eKe/rHtL2hEF/EDkWe23FSASrHdK6FNyotK7xxdfh3QYPGmavmFSvlETg6qUdS kkWRrTCtkro4EirO7KGbW7DDeuzcxqK6IHy6JStdevouwaTqJ/TtdCI2vYJKDTyg GkxQQwk00GCk7xox5dJq1jdpniVfpQ/pKAVb9BTuQYCaMCuqdv64xg6ggbkXi28T cIFkdKxNCBw0L5Ecwg3/d4y2OlTAJmBULsAQZ7piFKXFbHPb9CofxCypGSTn5cMw F9wnr/0geTw3UOxfi0OGNm2Wf0x2B9n7iyYZODxvihdoeg8OGbusPJr9viRYI7tA 47+/95ywXBTcAPxLwSCb3vXG2FImgnzwnaG/9xpKZk4dKAZcxQBxqlgDtBbilv8X zvr9ArmCG9hdEAojD66AKM5Qmzse+tPaAiDFecGBvlSN3/J2AOrTF9U64Akbkzg9 +uXkV3rk/DhP0JTLXvb8Aizbb9Y51PGO/G7KZH3tCYieaCQbkNdddNbIg3WI4kV1 AEGvDd30vDdAkl17UcguV6iwPwCP0tFs9GNcJRCEninL+/bQmVs2PcpYJ5+oPBsi vUc791SABXCttPkm1X/A =E0LH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:19 PM, Bill Nottingham wrote: Matthew Garrett (mj...@srcf.ucam.org) said: Patches that cleanly decouple Anaconda from the entire software stack that it runs on top of would probably be received with open arms, but nobody who works on it has any idea how to implement them. In fact, this is what has been done in anaconda over the past couple of releases - Anaconda migrated from having its own boot and init infrastructure to using system-provided items such as dracut and systemd. But that's complicated work, and while you're doing that migration, you're doing a lot of arbitration as to what bits are in generic dracut, what bits are in generic systemd, and what bits remain in anaconda. And during that process, you are *very* tied to the version of the underlying system, until the work is fully complete and there is a defined separation of features into each layer. This, incidentally, also is why running the F17 installer on F19 isn't practical. Bill Not to mention that while making this migration and after, when system tools /change their api/ or /change their command line arguments/ it means that the installer is suddenly broken again. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 05:45:23PM +0100, Thomas Woerner wrote: I'd happily help document it in the Fedora Security Guide if I could get the proper content or access to the developers. Heck, I'll even help write stand-alone documentation for this project if needed. I will provide content/help for this. Awesome, thanks! Hit me up on IRC (Sparks on freenode) or email when you get some time. - -Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQnTToAAoJEIB2q94CS7PRQikQAKC2GXhzR7U3w515iqm0Rtb7 brVvZkaUC5fMdz3tZ/gB8MzzedZvGkPrs08O+iu1vcGd9smI8fBV4juhfdV2qCpv cSK05y+AYKzX9tB9SVqpG7PybneD+V3WHluZED5of4CQEra6GOS2gxhNCw4fixSf CO4UWM9WW3PKaj2W/UbADwi+V/isrErQRYrkJBgraoXAqCzuiHMvJoK8gxCfvOk6 FnxlslXFfOoc1BKyhZPXDkxhMaW9ttko8KMGCu2vUG6TXmU9YIWUd0vD0Wxy0mb7 4kBhuGn5CRljRxl4ueu7J7HgwcXKGVSV5A8EnsG6LRVswEEoQWpDL/EjO567hJ0A YpynXklF/A5qc8hQdc36VXd/I1ipv7ViRjesazshF1Ub7AmcslJWO0ewF+HpR4Ai LzIT3xgmh3+7y1An42X0Tm1j8mqxbsQ7tEda1pNCS7m2GCn1T/Ps2rII05R8LAUL dtnuJO1T4GQUg5/Q2775VDvr3Jo1LFFw/64bIp9M3ij6FtiWROJB/R98fh5xfx6h mgg5RPsnzfzv3rYRzYsvXNPWoOtd6rxb7K7uGvSzUHxtbSI+WwndRHH1N7MAvUAB q+wWPOOYEpItvqDj0YrUbyJOOWMns/ffCXsjUFdyJv8NgYOK7nOi8gi4Rq3vvhNe +HDERDXMxMu6oXpz1mBS =XStG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 AM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote: Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? Yes, that is an advantage, but that shouldn't be slicing up one computer in to multiple very underpowered smaller computers. Why not? That's incredibly useful. Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. What about my host system for 500 VMs? Use elastic allocation. It takes a lot of ram to say please depsolve these 40 packages which turns into install these 250 (minimal) packages. So in order to handle that kind of task (once), allocate a large amount of ram. Once that task is complete, the actual work the image will be doing may require a lot less ram, so you can scale down what you allocate to that guest. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Fri, Nov 09, 2012 at 05:32:14PM +0100, Thomas Woerner wrote: - this turns out to be a big change! - there's little to no documentation Have you had a look at the man pages? I missed the top-level man page and was looking at firewall-cmd, which is not very helpful on its own. Starting from firewalld is much more helpful. (Thanks!) The Zone man page dumps me right into reading XML. :) This is the technical documentation I was referring to, and I'm glad to see it _is_ there -- sorry I missed it. I'm still not clear on some concepts, though -- particularly, a zone is described as defining the trust level of the interface used for a connection, but in the man page for zones, trust isn't mentioned at all -- instead, they appear to be the config files for firewall chains. But I can get into my specific confusion in a separate thread. For the point of view of the feature, we need to get some of this into web pages and maybe online help for the GUI applet. - the UI is very confusing, with a large number of zones and no apparent way to configure those zones Go to the persistent view and you can configure zones, services and icmptypes. I can certainly check and uncheck services and other things within zones, but the GUI gives me no idea about what the zones mean and neither a way to learn that nor a way to tell it -- I'd expect at least _one_ of those. I see there's a work zone -- how does firewalld know I'm on the work network and not at home or at a coffee shop? - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. Firewalld is using about 12M of memory (RES), produces only a small amount of wakeups ( 0.1) if idle. Where is the non-trivial use of system resources. That. That right there. When the net result of that is _no work done ever_, multipled by a thousand of million, it's really not a good use of the world's resources. Even on a dynamic system, it's going to be idle most of the time, right? Couldn't this be entirely D-BUS activated and exit after making changes? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 04:43 PM, Jesse Keating wrote: While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., It's not like it always works in that area anyway there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. Last time I checked the configuration of those files have remained the same for years if we put that aside how is Anaconda supposed to be reverted in the future what's the plan you guys have here, which direction are you guys taking in regards to that? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:48 AM, Matthias Clasen wrote: I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Because when you are only installing the minimal package set (which means no x) then the post-install configuration tools don't really exist to do those necessary steps, nor do people want to have an automated install, which then halts at first boot to prompt a user to configure a bunch of stuff necessary to make the machine work right. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 14:30 GMT, David Cantrell wrote: Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. Does it really irritate you? Those are strong words ... anyway. I will risk your irritation, anger, maybe even rage (after all, their impact is limited over IRC) and let me ask: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? b) What awesome and breathtaking functionality I've got in anaconda since EL-5 that I have to pay for it with this increase of hardware requirements? (and let me remind you again about those 500 VMs) I don't think these question are in any way inappropriate or too offensive, are they? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:33 AM, Matej Cepl wrote: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. b) What awesome and breathtaking functionality I've got in anaconda since EL-5 that I have to pay for it with this increase of hardware requirements? (and let me remind you again about those 500 VMs) I don't think these question are in any way inappropriate or too offensive, are they? Hey it's free software. Feel free to take EL5's anaconda code base and make it work for F19. If it's good enough, maybe you can convince FESCo to replace anaconda with your project as the official installer for Fedora. I wish you luck! -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 06:56 AM, Alexander Bokovoy wrote: The simple fact that you are feeding kickstart file to a single entity does not mean this entity cannot outsource actual tasks to others and run them later, be it post-install phase in the actual installer's session or after (a simulated) reboot. Input interface change is not needed for backend changes. If all you are interested is 'one go' installer from perspective of the feeding kickstart files, it would still be the same. What anaconda is doing is taking that kickstart input and feed it into run-time tools in a way that those tools can do what we want them to do. Except those tools change over time, and their inputs change over time, so anaconda breaks over time just in trying to take data in one place and feed it into another. Isn't software fun? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 12:03:23PM +0100, Miloslav Trmač wrote: On Thu, Nov 8, 2012 at 10:21 AM, Jaroslav Reznik jrez...@redhat.com wrote: As someone pointed out in yesterday meeting - Fedora is becoming more a combo of time/feature based distribution. I don't think that's really the case. The important thing about a time-based schedule is that at some point you _stop accepting new features_ (and we do have that), not that there is a 100% reliable time when the GA release happens (which we don't have). It might all be definitions but that still sounds like a description of a feature-based release model. F19 will have Feature X, Y, and Z. If feature X isn't ready yet, we slip our release date until it's ready. A time-based release would say we're releasing on -MM-DD. If feature X isn't ready to go into the release that's being shipped on that date, the feature is removed. In the time-based release model, you still have schedule slips as you either fix things at the last minute or you invoke plans to revert an incomplete feature and those plans end up running longer than you thought. But in either scheduling case, you are intending to hit as close to your scheduled release date as possible and choices like plough ahead with X or revert X are evaluated on which is likely to slip the release date the least. -Toshio pgpBWG3oStbhC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:57 AM, Jóhann B. Guðmundsson wrote: On 11/09/2012 04:43 PM, Jesse Keating wrote: While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., It's not like it always works in that area anyway Right, computers don't always work, so lets give up, and go shopping right? there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. Last time I checked the configuration of those files have remained the same for years if we put that aside how is Anaconda supposed to be reverted in the future what's the plan you guys have here, which direction are you guys taking in regards to that? JBG The inputs to the tools doing the configuration of those tools has changed over time. We don't want to duplicate code by having our own pile of config parsers and writers, we want to rely on the same tools that userlands are using. As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:01 PM, Jesse Keating wrote: On 11/09/2012 05:48 AM, Matthias Clasen wrote: I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Because when you are only installing the minimal package set (which means no x) then the post-install configuration tools don't really exist to do those necessary steps, nor do people want to have an automated install, which then halts at first boot to prompt a user to configure a bunch of stuff necessary to make the machine work right. Well the argue can be made that If you are doing a minimal install it kinda indicates you actually know what you are doing ( which means you will probably change whatever was set afterwards ) so the system should just default to use sane working defaults which should come with the relevant package when it's installed even set some default password. But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: Of course, it should be clear that making PK optional if a desktop is installed is not desirable, but other than that I think for head-less systems such as servers or embedded making PK optional would be desirable goal and worthwile to spend a bit of work on. Cool, thanks for the input. There's little risk of it becoming optional on the desktop, because a large number of desktop packages sensibly have it as a requirement -- including gnome-shell and kde-runtime. (Xfce doesn't seem to have anything that directly requires it except for xfce4-power-manager, but other collatoral deps lead back to xfce-session.) I'm going to build some images without it and can start filing bugs on anything that comes up. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote: On 2012-11-09, 14:30 GMT, David Cantrell wrote: Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. Does it really irritate you? Those are strong words ... anyway. I will risk your irritation, anger, maybe even rage (after all, their impact is limited over IRC) and let me ask: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? The installer's memory footprint is largely bound by the size of the package set. So, for example, a yum upgrade will take more ram - because there are effectively twice as many packages involved. There may be ways to reduce how much of that needs to be kept in ram at a time, but those are things for yum/rpmlib - they're not anaconda changes. b) What awesome and breathtaking functionality I've got in anaconda since EL-5 that I have to pay for it with this increase of hardware requirements? (and let me remind you again about those 500 VMs) Most of the increase of hardware requirements has been related to the package set, rather than by anaconda getting significantly bigger. There are some cases where we've grown the install images, and despite your implication they tend to be directly related to additional functionality. As a matter of fact, recently we've worked hard to make the install image and working set of the installer *smaller*. As for what functionality you've gotten since, say, the last time we had a major UI change, here's a small sample just off the top of my head: - BIOS-RAID boot - encrypted boot - uefi support on x86 - iscsi boot support - multipath support - using NetworkManager - wireless networking support - ssh support in the installer - kickstart generation mode - jlk's new improved non-graphical mode - 3TB disk support There's a full(er) list of what our team has been doing here: http://fedoraproject.org/wiki/Anaconda/Features I don't think these question are in any way inappropriate or too offensive, are they? Actually, yeah, when you question our competence and the utility of what we're doing, that is a bit offensive. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:13 PM, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. It never was up to this point you know the usual attitude of let's cross that bridge when we get there and this release cycle has proven that it's necessary JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:47 PM, Jóhann B. Guðmundsson wrote: On 11/08/2012 08:40 PM, David Lehman wrote: No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? I'm all for magic but I would expect specific configuration package(s) and or a configuration template tailored for the component being install which the installer might use or the package himself would simply do it post install. Are there any specific use case where that would not suffice? JBG You're focused on packages. How about filesystems? That stuff changes way more often than one would like. LVM? How often do we have to update the command line arguments we pass to do things? --force --force --noIreallymeanit BTRFS? That's all still in development so the tools are changing rapidly. What about actually getting packages into the filesystem. yum api changes with time, and our use of yum means we have to change our code to work with the API as well. Boot loaders? yeah, go ahead and install the grub package, see what it does in the %post scripts. Oh, you actually want to /configure/ the machine to boot? Well that takes work, work that has to change because /grub/ changes. I can keep going, but is it really necessary? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
Jóhann B. Guðmundsson (johan...@gmail.com) said: The storage packages are going to be needed for the system to boot. Anaconda could probably add some smarts to remove authconfig if it wasn't pulled in by anything in the selected comps, but I'm not sure it'd be worth the special logic -- we might as well just put it in @core (even though it's not super-tiny). Firwealld I don't know about, though. If anaconda sets up the firewall using firewalld but then doesn't install it, will the old iptables scripts load the configuration? It'd be nice if it could, because firewalld is *another* big change that it'd be nice to have a reasonable back-out plan for. The point here is that both authconfig and firewalld are used by anaconda to configure the installed system, via either the old code (pre-F18) or the kickstart code (older releases, and F18+). anaconda would need to grow more complicated checks to ensure that certain things weren't set in the install before laying them down. You might want to remove plymouth from the minimal install since it does not make sense having it there anyway You filed a bug about that, actually... I'll respond here and paste there. plymouth was added to the minimal install as a consistent method for handling encrypted passphrases and boot-time logs at the time. Since this has moved out into other components since then, it can be reconsidered. There's something to be said for having a consistent boot-time interface though, rather than one that changes whether or not plymouth is installed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote: deserved. Just today I made a minor fix to systemd git to deal nicely with PK-less systems. Right now, I get: $ reboot Failed to issue method call: The name org.freedesktop.PolicyKit1 was not provided by any .service files Must be root. Which is fine except that I don't want to see the message. :) Does your fix handle this or should I bug report? Yes, that's the one that should be fixed with this: http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e000255d07f6b3cc777f15b Would probably make sense to test things with this applied as it should solve most (but probably not all) issues related to PK-less systems. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 03:27 AM, Miloslav Trmač wrote: Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. You won't find much disagreement in the installer team. Fedora changes, and it changes fast, and it changes without a lot of notice, cooperation, or coordination. Anaconda suffers a lot because of this, and Fedora users/testers suffer a lot because Anaconda breaks a lot. We are often the advanced scout who first encounters a major change. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:17 PM, Jesse Keating wrote: I can keep going, but is it really necessary? I argue yes maybe not here but having a wikipage under the anaconda name space which mention all the package and configuration files change that can directly affect the installer and how would be necessary for Feature wranglers/Fesco/QA to look at. Having a page like that might have prevented fesco from approving [1] which I'm pretty sure put added a bit of load on top of your guys work 1.http://fedoraproject.org/wiki/Features/ReworkPackageGroups -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 11:21 +0100, Matej Cepl wrote: On 2012-11-09, 07:43 GMT, Adam Williamson wrote: It hasn't really 'skyrocketed'. We cited 512MB for several releases, bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for F17, and it's back up to 768MB or 1GB for F18 atm because everyone has more important stuff to do than optimize the RAM usage right now. But it's not been rising crazily or anything. I think the last time someone took a deep look at RAM use during install - during F17 cycle when we got it back down to 512MB - it turned out a lot of the usage happened during package install and wasn't really to do with anaconda at all. I understand and accept that now everybody in the anaconda-land is busy with something else, but let it not slip our attention how absolutely crazy it is when the installation program requires twice as much (or more) of the resources than all programs running on the computer combined. I have here a server with RHEL-6 which I had to upgrade to 512MB just to be able to install a system on it. Now it has plenty of free RAM even with some bulky PHP apps (e.g., Zarafa) which is wasted. With the spread of virtual machines, it seems to be even more obvious. Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? If you're doing that, it's pretty trivial to use pre-built images. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 08.11.2012 15:10, Miroslav Suchý wrote: [1] https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Nice start, Thank you! I like the scripting (ifs) or even better a rule based (make-like) approach. I will test your script on few instances. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the time-based release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding have a longer release cycle to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) pgpnpzwv48BiP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 09.11.12 08:53, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Nov 09, 2012 at 01:41:08PM +, Jóhann B. Guðmundsson wrote: You might want to remove plymouth from the minimal install since it does not make sense having it there anyway Yes probably. Anyone know why it's there? In rc.sysinit-times ply was the only way how LUKS passwords and suchlike could be prompted during boot. Hence rc.sysinit in a way relied on plymouth to be around to fully function. In systemd we have a non-ply fallback in place however, so prompting passwords on the text console without ply around should work fine nowadays. We regularly test systemd upstream with and without plymouth, to make sure both ways to boot is well supported. Dropping plymouth from the minimal install set should hence be unproblematic and well supported. Note that even on systemd without a display plymouth used to be highly useful since it collected the boot status output from the console and stored it away in log files. With systemd we now connect all boot services (that means stdout/stderr and syslog() of all services in the initrd and early boot) to the journal anyway, so this really useful functionality of plymouth is not necessary anymore. (In case you wonder, to get these boot outputs just run journalctl -b). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Network interface renaming, where does INTERFACE_NAME get applied?
Hi Bill
I see that initscripts in F18 ships this udev rule:
ACTION==add, SUBSYSTEM==net, PROGRAM=/lib/udev/rename_device,
RESULT==?*, ENV{INTERFACE_NAME}=$result
I'm trying to tackle some problems related to interface renaming, and
understanding how this works would be useful.
But I can't find which software component *applies* the INTERFACE_NAME
variable set by the above rule, actually performing the interface
rename. Can you explain?
FYI, I would imagine this area will also be susceptible to a current
udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
Thanks
Daniel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 12:55:30PM +0100, Vratislav Podzimek wrote: On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote: I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. I'm afraid anaconda _is that_ special. AFAICT there is no other piece of code that directly interacts with dracut, systemd, Network Manager, gtk3 (and GObject introspection) and many other components that change quite often. If there is such code, I'd be happy to look at how its developers handle such changes and take a lecture from them. Other projects would handle something like this by having a subset of people working on a branch that kept the existing UI but was updating to fix issues with dependencies. The NewUI feature work would be done by a different subset of people on a separate branch and be merged in only when it was ready. David Cantrell has mentioned the reasons that he doesn't think that would work for anaconda -- I'll list them here so no one reads my message without that information as well: * Doing it this way would slow down anaconda development * Anaconda lacks the manpower to maintain two separate development heads -Toshio pgpqxuuszzi2x.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:11 AM, Jóhann B. Guðmundsson wrote: Well the argue can be made that If you are doing a minimal install it kinda indicates you actually know what you are doing ( which means you will probably change whatever was set afterwards ) so the system should just default to use sane working defaults which should come with the relevant package when it's installed even set some default password. Pretty sure having a default root password in some package in Fedora is a non-starter. The point of doing an (automated) install (which can be minimal, or at least start with minimal and build upon that with only exactly the needed functionality) is so that you can do the install unattended, reboot the machine and put it into production, unattended. But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? root auth and firewall config are the main ones. Note that we don't have any UI for firewall config either, so not really a lot of code duplication. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the time-based release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding have a longer release cycle to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) In that context the plan would have had to be do all the bring the code base forward into the next Fedora environment work twice. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:49:00AM -0800, Jesse Keating wrote: On 11/09/2012 09:35 AM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the time-based release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding have a longer release cycle to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) In that context the plan would have had to be do all the bring the code base forward into the next Fedora environment work twice. Correct. But while this is a problem for the anaconda team, it may be the least-bad for Fedora overall. Then again, there might be an alternative that is even better. -Toshio pgptwVnwzfGBC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 PM, Peter Jones wrote: On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote: On 2012-11-09, 14:30 GMT, David Cantrell wrote: Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. Does it really irritate you? Those are strong words ... anyway. I will risk your irritation, anger, maybe even rage (after all, their impact is limited over IRC) and let me ask: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? The installer's memory footprint is largely bound by the size of the package set. So, for example, a yum upgrade will take more ram - because there are effectively twice as many packages involved. There may be ways to reduce how much of that needs to be kept in ram at a time, but those are things for yum/rpmlib - they're not anaconda changes. Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 08:57:05AM -0800, Jesse Keating wrote: Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. What about my host system for 500 VMs? Use elastic allocation. It takes a lot of ram to say please depsolve these 40 packages which turns into install these 250 (minimal) packages. So in order to handle that kind of task (once), allocate a large amount of ram. Once that task is complete, the actual work the image will be doing may require a lot less ram, so you can scale down what you allocate to that guest. Which is of course what everyone is doing. I was replying to the broader theme (small VMs are useless) out of context, probably because it was early in the morning. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:57 AM, Panu Matilainen wrote: Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. While that may be true, the amount of ram (free -m) used during an install *triples* when we get to the desolve and package install phase. In my most recent test the used number went from roughly 550m just before the packages step to 1645 during. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
itext 5.x
Does anybody know if there are licensing issues with itext 5.x? I'd like to package some software that needs a fairly recent version of itext, but I know we've had license issues with that package in the past. Also, FWIW, bouncycastle hasn't been updated because of itext ( https://bugzilla.redhat.com/show_bug.cgi?id=806262), but the most recent version of itext, at least, requires the newest bouncycastle. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
appliance-creator: how can I shorten the grub timeout in kickstart?
This perplexing to me. In my %post section, I tried both writing GRUB_TIMEOUT=0 to /etc/default/grub and using sed to replace set timeout=5 in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: This perplexing to me. In my %post section, I tried both writing GRUB_TIMEOUT=0 to /etc/default/grub and using sed to replace set timeout=5 in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. in your kickstart can you do: bootloader --timeout=1 -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: plymouth in @core? [was Re: Attention, dependency fighters]
Am 09.11.2012 17:35, schrieb Kevin Fenzi: On Fri, 9 Nov 2012 11:20:08 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote: Yes probably. Anyone know why it's there? IIRC, even if you 'disable' it, plymouth is still the thing handing the text mode output. Perhaps some plymouth folks would chime in here... I removed it from my test vm with no apparent ill effects Does a kernel upgrade work as expected? (dracut might want plymouth to put in the initramfs?) kernel-line: rd.plymouth=0 plymouth.enable=0 [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote: Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator I've got https://github.com/katzj/ami-creator :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Am 09.11.2012 17:45, schrieb Thomas Woerner: On 11/09/2012 05:24 PM, Eric H. Christensen wrote: Please have a look at the feature list for F-18. firewalld replaces system-config-firewall/lokkit, and the iptables and ip6tables services, not the iptables package and command. The ip*tables services and also system-config-firewall/lokkit are still available and also usable after deactivation of the firewalld serice. With the latest request to move the services of iptables and ip6tables in a sub package, I will add a requirement to system-config-firewall for this PLEASE do not Require: system-config-firewall this would pull useless dependencies what we (users) really need is iptables.service as it was and working /sbin/iptables-save /etc/sysconfig/iptables to lod the with whatever shell script generated /etc/sysconfig/iptables so satisfy over many years perfect working setups for (the same for iptables6.service) * firewalls * NAT * routing as example i have a large shellscript with the following start $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -F $IPTABLES -X CHAINS=`cat /proc/net/ip_tables_names 2/dev/null` for i in $CHAINS; do $IPTABLES -t $i -F; done echo Flush OK || echo Flush FAILED for i in $CHAINS; do $IPTABLES -t $i -X; done echo Clear OK || echo Clear FAILED for i in $CHAINS; do $IPTABLES -t $i -Z; done and ending with /sbin/iptables-save /etc/sysconfig/iptables after that any needed rules are added with iptables-command this script is distributed to a LOT of machines of any type at the begin it has basic rules for any machine (accept, block, reject) followed by a lot of if [ $HOSTNAME == hostname ]; then specific rules fi this is maintained on a staging server, distributed to any amchine and called with ssh root@host '/scirpts/iptables.sh for other networks / routers / nat-gateways outside the main network a fork of this thing exists, using over years grown knowledge and adds specific rules, mostly controlled by a lot of variables at the begin call this script does NOt interrupt connections it handles really a lot of specific filters it works like a charme these setups does not need firewalld at all nor do they need any dependency of GUI/TUI tools signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote: Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator I've got https://github.com/katzj/ami-creator :) Jeremy's is older last time I checked - the one from euca is modified by andy grimm and, well, works and stuff. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 11/09/2012 10:19 AM, drago01 wrote: On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý msu...@redhat.com wrote: On 11/08/2012 03:10 PM, Roberto Ragusa wrote: Hmm, I now see there is a set -e at the beginning. Still a little scary.:-) Scary is only the idea. And only because we are not used to do rolling upgrades. Ask somebody from Debian experiance if this is scary ;) There are some upgrade tasks that you simply cannot do from within a running system (ex: usermove). Serious question: why usrmove is not doable? If you have all the dirs in your path, and move executable files from one place to another, why should this fail? I managed to do a 32 bit - 64 bit transition (you know, the absolutely unsupported upgrade) on a system which was running an entire KDE session. My upgrade commands (rpm, yum, bash, everything else) started 32 bit, then were mixed, then ended to be 64 bit. Usrmove appears simpler. Am I missing something? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
Am 09.11.2012 19:08, schrieb Jesse Keating: On 11/09/2012 09:57 AM, Panu Matilainen wrote: Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. While that may be true, the amount of ram (free -m) used during an install *triples* when we get to the desolve and package install phase. In my most recent test the used number went from roughly 550m just before the packages step to 1645 during NO i did a lot of yum-upgrades F16-F17 in the last weeks on a lot of VM's with exactly 512 MB RAM without any single problem so no, there is no reason anaconda needs more ressources because all of this machines was full operating while the upgrade was running (httpd, mysqld, asterisk, hlyfax) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:06 GMT, Jesse Keating wrote: Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. Right, that looks possible. I still wonder why installer needs MORE memory than running server with couple of servers, Apache, MySQL, and some application servers (Zarafa, Status.net, dspam, wordpress)? But following in this argument would probably require more detailed analysis than I am willing and able to provide, so let me close this argument here. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 2012-11-09, 17:15 GMT, Peter Jones wrote: The installer's memory footprint is largely bound by the size of the package set. So, for example, a yum upgrade will take more ram - because there are effectively twice as many packages involved. I see that. Couldn’t be there a way how to somehow overcome this problem? Just a bit of brainstorming, don’t shoot me too much for being silly. a) it could be that anaconda could just provide some kind of profiles instead of exact selection of individual packages and the lists of required packages for such profiles could be then precompiled in advance and provided on the installation medium (and for kickstart you could precompile it on a separate machine)? b) installation could be done just from a limited set of packages (something similar to what we used to have in Fedora Core, for example) and the final installation of packages would be done post-installation from the full set? We do that effectively with LiveCD installations anyway, don’t we? Well, at least mostly ... certainly people can download additional packages from Internet. Do users do that or do they typically install just what’s on CD/USB? Do people typically do detailed selection of packages (including obscure ones) in anaconda, or do they do (what I do, so I am biased) detailed final selection of packages on the already installed system? Actually, yeah, when you question our competence and the utility of what we're doing, that is a bit offensive. Did I say a word about your competence? I really didn’t mean to do that. For one, I am quite sure that you are way better programmers than I am, so I have not much to say about anybody’s competence. I just wondered (and I still wonder a little, see above) about the necessity of using 2-4 times more RAM for what me (yes, that could be part of the problem, I don’t need/use most of the advanced/enterprise functionality in anaconda) seems like doing exactly the same as before. From the user’s point of view, it is just cost/benefit ratio ... what I've got for the cost of increased hardware requirements. But yes, it could be because I just don’t need advanced functionality. So I was just trying to get to the bottom of it. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 11:32 AM, Matej Cepl wrote: On 2012-11-09, 17:06 GMT, Jesse Keating wrote: Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. Right, that looks possible. I still wonder why installer needs MORE memory than running server with couple of servers, Apache, MySQL, and some application servers (Zarafa, Status.net, dspam, wordpress)? But following in this argument would probably require more detailed analysis than I am willing and able to provide, so let me close this argument here. Matěj I don't think I'm necessarily disagreeing with you. I don't think anybody on the Anaconda team is happy with the current memory usage. That said, we've had very very very little time to pursue fixing this particular issue. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote: On 11/08/2012 11:31 AM, Adam Williamson wrote: Yes. This is_absolutely_ a feature. A complete rewrite of a core and non-optional component cannot be done ad hoc without planning. One blindingly obvious reason for this in the current situation is that we're still thrashing around trying to figure out how to build and ship the initramfs that fedup needs. This is exactly the kind of thing that needs to go through the feature process so that the relevant groups - releng, infra - know about it. I don't believe they even knew about the problem until about two weeks ago. I think the unfortunate thing here is that we're trying to use Feature to handle cross team coordination. Why unfortunate? That is one of the two issues the Feature Process was created to address. If it's unfortunate because the two issues the feature process attempts to solve don't really have as much in common as once thought, that's cool and probably the number one thing that everyone would like to fix -- I'm just checking that you don't have some other idea in mind. -Toshio pgpddXPKmjxMr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 14:47 +, Matthew Garrett wrote: On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote: Aside from that - I can understand your frustration that you think people are chinwagging and not helping, but my point is kind of that you (anaconda team) have brought that on yourselves. I'm not on the Anaconda team. That's my point. When bugs threaten the release of the distribution then *everyone* involved in the distribution should be willing to work on them, not just insist that it's up to the developers currently working on it. I've just spent two days of vacation working on this because it's clear that more developer contribution would be useful and because I actually want us to release Fedora 18. We're not obliged to sit here pointing at a sinking ship when we could do something to avoid that ship from sinking. Correction accepted - I tend to think of you as an honorary member because you always pop up in #anaconda :) But my point stands too: there would have been much more co-operation and contribution if fedup had gone through the feature process correctly, as that is one thing the feature process achieves. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:35 -0800, Jesse Keating wrote: On 11/08/2012 11:31 AM, Adam Williamson wrote: Yes. This is_absolutely_ a feature. A complete rewrite of a core and non-optional component cannot be done ad hoc without planning. One blindingly obvious reason for this in the current situation is that we're still thrashing around trying to figure out how to build and ship the initramfs that fedup needs. This is exactly the kind of thing that needs to go through the feature process so that the relevant groups - releng, infra - know about it. I don't believe they even knew about the problem until about two weeks ago. I think the unfortunate thing here is that we're trying to use Feature to handle cross team coordination. It may not be the best possible system, but I'm fairly confident it would have worked better than what we actually did. Which, for fedup, appears to have been 'nothing'. Until Tim started trying to actually test fedup, I believe there had no attempt by any party to consider what work other parties might have to do to make fedup fly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote: But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? root auth and firewall config are the main ones. Note that we don't have any UI for firewall config either, so not really a lot of code duplication. Also bootloader configuration and network configuration, no? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 12:05 PM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote: On 11/08/2012 11:31 AM, Adam Williamson wrote: Yes. This is_absolutely_ a feature. A complete rewrite of a core and non-optional component cannot be done ad hoc without planning. One blindingly obvious reason for this in the current situation is that we're still thrashing around trying to figure out how to build and ship the initramfs that fedup needs. This is exactly the kind of thing that needs to go through the feature process so that the relevant groups - releng, infra - know about it. I don't believe they even knew about the problem until about two weeks ago. I think the unfortunate thing here is that we're trying to use Feature to handle cross team coordination. Why unfortunate? That is one of the two issues the Feature Process was created to address. If it's unfortunate because the two issues the feature process attempts to solve don't really have as much in common as once thought, that's cool and probably the number one thing that everyone would like to fix -- I'm just checking that you don't have some other idea in mind. Don't have anything else in mind. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
I can't comment on UsrMove because I'm quite unfamiliar with it, but I did manage to upgrade from f17 to f18 using the totally unsupported yum update --releasever --enablerepo=*testing --nogpgcheck method. Computer booted and everything's exactly as it used to (Though I did have to remove some packages like Calibre because of file conflicts, no big deal). I did it on a live system, too. The only thing that failed during that time was postgres (Which managed to stay borked after it was done and f18 booted, the pg_upgrade method didn't work properly) but other than that and a much more responsive KDE, I can't see any side effects to this method. YMMV, -Nushio On Fri, Nov 9, 2012 at 1:16 PM, Roberto Ragusa m...@robertoragusa.itwrote: On 11/09/2012 10:19 AM, drago01 wrote: On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý msu...@redhat.com wrote: On 11/08/2012 03:10 PM, Roberto Ragusa wrote: Hmm, I now see there is a set -e at the beginning. Still a little scary.:-) Scary is only the idea. And only because we are not used to do rolling upgrades. Ask somebody from Debian experiance if this is scary ;) There are some upgrade tasks that you simply cannot do from within a running system (ex: usermove). Serious question: why usrmove is not doable? If you have all the dirs in your path, and move executable files from one place to another, why should this fail? I managed to do a 32 bit - 64 bit transition (you know, the absolutely unsupported upgrade) on a system which was running an entire KDE session. My upgrade commands (rpm, yum, bash, everything else) started 32 bit, then were mixed, then ended to be 64 bit. Usrmove appears simpler. Am I missing something? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
