Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
* Adam Williamson [10/11/2012 08:36] : BTW, for the factual record, only the very first generation of the very first netbook ever created - the Eee 700-701 - had 512MB of RAM. Not even that. I have an Eee701 and I replaced the 512MB stick of RAM with a 2GB one a while ago. Emmanuel -- 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 09:33:08AM -0500, Matthew Miller wrote: - 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 - depends on Python stack Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller 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? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
monitoring the memory usage of a build process
Hi, I was wondering if it was possible to monitor the maximum and/or average memory usage of a mock build process. I am trying to investigate why a package takes less 2 hours to build on F16/F17, 24 hours on F18 and 7 hours on rawhide: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2554 Regards, Julian -- 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:08 PM, Jesse Keating wrote: 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. Hmm, not sure how meaningful the 'free' output is for memory use (process RSS is what I look at), but that is just way, way, way off. The depsolve + install stage obviously does need a very non-trivial amount of memory that anaconda wouldn't have required up to that point, but we should be talking about a *couple* of hundred megs at most for normal Fedora install/upgrade cases. The one testcase I have at hand is a 3103 package install of F16 x86_64 DVD contents into an empty chroot. That's roughly the double the size of an avegare/default installation, and the memory peak for that set when installing with rpm is circa 100M resident size (RSS). Yum does add a fair share of overhead but even if it doubled or tripled the memory use (its been a while since I last looked and dont remember offhand), its still nowhere near a gigabyte of additional memory. Probably the biggest anaconda memory requirement jump I recall around Fedora 15 had to do with the overall layout changes (moving to one big initrd or something like that), not the actual anaconda process memory requirements. That's when I last looked at this and provided patches to save memory in the package installation area... but perhaps I should look at it again. - 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 09:30:14AM -0500, David Cantrell wrote: 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. You're very wrong here. Memory is *the* key limiting resource for VMs, particularly when people want to pack as many VMs into a system as possible. If the minimum required for an OS goes from 256 - 512MB, then the number of VMs that can be run per host (more than) halves. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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 Sat, Nov 10, 2012 at 11:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote: 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. You're very wrong here. Memory is *the* key limiting resource for VMs, particularly when people want to pack as many VMs into a system as possible. If the minimum required for an OS goes from 256 - 512MB, then the number of VMs that can be run per host (more than) halves. Yeah but the amount of memory needed for installation is hardly relevant here .. you install once (with a higher memory allocation) and scale down afterwards. And once you have a working image you can reuse it for other installations. So the VMs are not really much of an issue here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121110 changes
Compose started at Sat Nov 10 09:15:51 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-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 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl
livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote: I think appliance-creator is pretty much unsupported at this point, isn't it? Yes, so moving to ami-creator might be a good choice. livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package. I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us. We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? On another note, Boxgrinder also is based around appliance creator, and it'd be nice to play nicely with those people too. -- 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 06:23 PM, Kevin Kofler wrote: But they wouldn't be able to claim a misunderstanding as now and FESCo would have a standing for requesting a reversion. Plus, in this case, Anaconda isn't an upstream project in the first place, we are upstream. Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. -- 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 2012-11-09 18:27, Matthew Miller wrote: The js package is 6.5MB. BTW I suppose that could be significantly reduced by linking /usr/bin/js with the dynamic libmozjs instead of the static one generated during the build. It seems to take something more than just the attached patch though. diff -up js-1.8.5/js/src/shell/Makefile.in~ js-1.8.5/js/src/shell/Makefile.in --- js-1.8.5/js/src/shell/Makefile.in~ 2011-03-31 22:08:36.0 +0300 +++ js-1.8.5/js/src/shell/Makefile.in 2012-11-10 18:22:13.647935875 +0200 @@ -52,7 +52,7 @@ CPPSRCS = \ DEFINES += -DEXPORT_JS_API -LIBS = $(NSPR_LIBS) $(EDITLINE_LIBS) $(DEPTH)/$(LIB_PREFIX)js_static.$(LIB_SUFFIX) +LIBS = $(NSPR_LIBS) $(EDITLINE_LIBS) -L$(DEPTH) -lmozjs185 LOCAL_INCLUDES += -I$(topsrcdir) -I.. -- 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:43 AM, 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 still don't get it. If just depsolving requires so much memory, then it's maybe an option, to add an 'express lane' to anaconda, to install all files listed in an explicit file list and also to skip dependency checking. That file list could be included for the three/four/ten typical usage scenarios. I assume, this is just one scenario minimum install. Does rpm -i --nodeps really take so much memory? (Yes, there's a risk to install a system with unsolved dependencies, and I currently ignore this fact) Or does anaconda require much memory when running headless (e.g. when working on a kickstart file?) If not, we may want to put some energy into kickstart-creator? -- Matthias Runge mru...@matthias-runge.de mru...@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
Am 10.11.2012 11:57, schrieb drago01: Yeah but the amount of memory needed for installation is hardly relevant here .. you install once (with a higher memory allocation) and scale down afterwards. yeah this works for you and me me the average user will say WTF, throw away this crap and take ubuntu that is the real life which happens if previous working things are replaced without care but hey, some mistakes in F15/F16/F17 may lead that Fedora loses the noob users and after that it could be considered satisfy power users more again and reduce the do it the windows way signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote: We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap a supermin appliance might be an option for you too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On 9 November 2012 18:46, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-11-09 at 20:39 -0500, Matthew Miller wrote: On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote: it maybe doesn't actually need to be). So perhaps we should change firewalld to default to opening port 22. +1, even having read the rest of this message. Same with iptables if firewalld is not installed by default. Somehow it took me 45 minutes to notice the giant logic fail in my thinking: if what we're trying to achieve is 'don't install firewalld in a minimal install', obviously firewalld's default firewall configuration is entirely irrelevant. To achieve the above, we don't need to make sure that the default configuration leaves port 22 open when firewalld is installed, but that the default configuration leaves port 22 open when firewalld is *not* installed. D'oh. Well with firewalld not installed and no iptables configs.. I would believe that the default would be everything open... unless some other program is there to set some defaults. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- 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
Adam Williamson wrote: On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote: Adam Williamson wrote: You're being pretty absurd comparing 2003 requirements to 2012 requirements without allowing at all for hardware inflation. People thinking like you are the reason why entire villages in China and Africa are huge heavily-polluted landfills of electronic scrap material. That's so stupid it barely merits a response. But I'll humour you. How's it stupid? A computer can easily last a decade or more. The computer I'm typing this message on is from 2003. Why should we have to replace our hardware every few months? And I didn't invent or exaggerate the story about the villages in China and Africa either. I've seen several documentaries about it on TV. Just use a search engine and I'm sure you'll find articles on the Internet about the problem. We improve the ability of our hardware so we can improve the ability of our software. When designing modern software it does not make sense to design to the capabilities of a Commodore PET. A PC from nine years ago really is not a terribly different case. You need to care about older hardware if you want to reduce the pollution of our environment and the plundering of our planet's resources (copper, aluminium, gold, rare metals etc.). This is last year's hardware, just throw it away just doesn't cut it. We are not designing an OS to be used to extend the life of ancient hardware for re-use in the developing world. That is a fine goal, but it is not really Fedora's goal. Our goal includes Features and First - i.e. we are pushing the envelope of what is possible. This is not only about the developing world! Most of the scrap in those landfill villages in China and Africa originates from the so-called developed world, i.e. Europe and North America! WE need to stop replacing our hardware for no reason every couple years! In doing this it is clearly appropriate to target the capabilities of contemporary hardware, not hardware built before George W. Bush's second term in office began. And I respectfully disagree, for both ecologic and economic reasons. Modern software does not use more resources than old software because it's 'bloated' or because modern coders are lazy. It just uses the greater resources available to do better stuff. This is why hardware engineers work to make more resources available in the _first_ place. We could now list all the capabilities of modern code that code from 2003 didn't have, but I really, really don't see the point. I fail to see those capabilities in the case of Anaconda, or more precisely, I don't see it having anywhere near 10 times the features it had in 2003! Kevin Kofler -- 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
Jóhann B. Guðmundsson wrote: Kevin manufactures today don't built hardware to last more then 3 years tops and actually the industry is moving towards to make them unfixable as well ( cheaper to jus throw it away and give you a new one ) I think Germany is actually the only country that holds high standards in that regards ( as in requiring manufactures to build appliance that lasts ) My main computer is from 2003 and still works fine. My notebook from 2008 obviously also still works (and I intend to use it until at least 2018 if it keeps working), and in fact even my old laptop from 1998 still technically works, too, I just stopped using it, and the evergrowing memory requirements of software have a lot to do with that (as does the lack of care given to drivers like s3virge). Kevin Kofler -- 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
Adam Williamson wrote: Oh, god, I'm pulling a Kevin with this list spamming, but this is just too glorious not to post. I couldn't resist taking a trip in the wayback machine. Here we are in Fedoraland, 2003: https://lists.fedoraproject.org/pipermail/devel/2003-December . What do we find? This just proves my point: Creeping biggerism has been a problem for many years, and by its cumulative nature, the longer it goes on, the worse a problem it is! Kevin Kofler -- 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 Sat, 10 Nov 2012 19:59:22 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: Oh, god, I'm pulling a Kevin with this list spamming, but this is just too glorious not to post. I couldn't resist taking a trip in the wayback machine. Here we are in Fedoraland, 2003: https://lists.fedoraproject.org/pipermail/devel/2003-December . What do we find? This just proves my point: Creeping biggerism has been a problem for many years, and by its cumulative nature, the longer it goes on, the worse a problem it is! I think most folks eyes have glazed over at this point. Can we drop this thread now? If you have a concrete proposal to put forward, write it up. If you have actual measurements for memory use or concrete ways to reduce it, please let us know. (this is the general you or all of yall (if in texas) not just Kevin). kevin signature.asc 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
Adam Williamson wrote: Or are you seriously suggesting that a sensible direction for Fedora is to consider the requirements of nine year old hardware and attempt to adjust our software to match? Why not? High-end hardware should have a lifespan of at least a decade. It obviously won't be high-end anymore by then, but it does the job. Kevin Kofler -- 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
Adam Williamson wrote: Same outfit here, and they also use Ubuntu, but it's nothing to do with system requirements, just broader hardware support through non-free drivers and the simple fact that it's the most popular desktop general-user distro. Ubuntu 12.04 cites 384MB minimum for a 32-bit install and 512MB minimum for a 64-bit install: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_requirements so they're very close to us. The fact that even *Ubuntu*, of all distros, requires less RAM than we do should ring a HUGE alarm bell! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
leechcraft package co-maintaining
Hello, maintainers! I'm looking for a co-maintainer for the leechcraft package ( http://pkgs.fedoraproject.org/cgit/leechcraft.git ). I cannot support its huge spec file duly because of some reasons in the real life. So if you want to help me, you are welcome :). Regards, Minh Ngo Fedora Project -- 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
Jesse Keating wrote: Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. If you want to be truly independent of Fedora, you need to do your development elsewhere and only import finished and fully working upstream releases into Rawhide (which need to be testable by Alpha and 100% complete by Beta), as for any other upstream project in the critical path. As long as you (ab)use Rawhide to do upstream development and alpha-testing in, Fedora WILL dictate how you do development. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Sat, Nov 10, 2012 at 05:35:16PM +, Richard W.M. Jones wrote: On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote: We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap a supermin appliance might be an option for you too. Doesn't Oz have the same issue with needing to launch a virtual machine? I don't think we want to run the install under QEMU. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Sat, Nov 10, 2012 at 11:15:31AM -0700, Stephen John Smoogen wrote: is entirely irrelevant. To achieve the above, we don't need to make sure that the default configuration leaves port 22 open when firewalld is installed, but that the default configuration leaves port 22 open when firewalld is *not* installed. D'oh. Well with firewalld not installed and no iptables configs.. I would believe that the default would be everything open... unless some other This is indeed the case. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
*IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. As per the Fedora 18 schedule [1], Fedora 18 Beta Test Compose 8 (TC8) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5349#comment:26 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Beta Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 18 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5349 Current Blocker and NTH bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Sat, Nov 10, 2012 at 02:40:02PM -0500, Matthew Miller wrote: On Sat, Nov 10, 2012 at 05:35:16PM +, Richard W.M. Jones wrote: On Sat, Nov 10, 2012 at 11:12:20AM -0500, Matthew Miller wrote: We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? I'd strongly recommend oz-install ... https://github.com/clalancette/oz Depending on what exactly this appliance is going to be used for, then febootstrap a supermin appliance might be an option for you too. Doesn't Oz have the same issue with needing to launch a virtual machine? I don't think we want to run the install under QEMU. It does, but this isn't a huge problem because installation is so entirely I/O-bound. Or do you mean it's a problem to run qemu at all? qemu certainly runs inside Koji just fine -- we run that all the time. febootstrap works off the RPMs directly, but has other limitations. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- 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 Sam 10 novembre 2012 11:57, drago01 a écrit : Yeah but the amount of memory needed for installation is hardly relevant here .. you install once (with a higher memory allocation) and scale down afterwards. Does not work with organisations that charge projects their top vm resource use (yes they exist) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Richard W.M. Jones wrote: - depends on Python stack +1, we really need to get Python out of the minimal installation. The focus should be on replacing the existing Python-based packages in the minimum set (e.g. yum) by native replacements (e.g. zif). Adding more Python stuff with additional Python dependencies is a step backwards. I really don't understand why a core system component such as firewalld is implemented in Python! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
I'm more concerned with getting sizes down to fix a cheap 4 GB USB drive than a 4.7 GB DVD. I don't think making install media over 4 GB is a viable option. I will test with the default desktop and the net installer before I'll erase one of my expensive 8 GB USB sticks! On Sat, Nov 10, 2012 at 1:41 PM, Kevin Kofler kevin.kof...@chello.at wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Am 10.11.2012 22:41, schrieb Kevin Kofler: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! +1 generally only few people need any debug-infos if they need - they can install package-debug do NOT BLOAT the whole distribution for more or less nothing 5-10% bigger - one may say these days hard-disks are cheap this is bullshit. in virtual environments with 50,100,500 instances on expensive SAN-storages NOTHING is cheap and you havve to add backups to the install size, mostly mutiplied signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- 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-10, 19:03 GMT, Kevin Kofler wrote: The fact that even *Ubuntu*, of all distros, requires less RAM than we do should ring a HUGE alarm bell! That’s unfortunate side-effect of rpm having file dependencies ... the matrix of possible dependencies apt-get has to resolve is by the order of magnitude smaller. And IIRC need for RAM required for depsolving is exponentially dependent on the number of dependencies. OTOH, file dependencies make some thinks incredibly more simple. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Tomasz Torcz wrote: On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. SARCASMYeah right, because the OBVIOUS solution to bloat added by a useless feature is to remove a useful feature to compensate./SARCASM Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sat, Nov 10, 2012 at 1:56 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Sat, Nov 10, 2012 at 10:41:16PM +0100, Kevin Kofler wrote: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! Let's drop KDE then. Fine with me - I use GNOME. ;-) But seriously, I have a huge collection of 4 GB USB sticks and will never buy a CD or DVD blank again. I simply won't test anything that won't fit on a 4 GB drive. openSUSE crossed that bridge already, and I suppose the 700 MB CD is a dead duck in all the distros now. But really, if you've got more than 4 GB on your full install media, you're not managing your distro effectively. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- 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 Sat, Nov 10, 2012 at 2:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: [snip] You're very wrong here. Memory is *the* key limiting resource for VMs, particularly when people want to pack as many VMs into a system as possible. If the minimum required for an OS goes from 256 - 512MB, then the number of VMs that can be run per host (more than) halves. Rich. It's worse than that - you generally only have *half* of your host's RAM to give to all the guests. Any more and all kinds of Heck breaks loose on a desktop. -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Sat, Nov 10, 2012 at 05:35:16PM +, Richard W.M. Jones wrote: I'd strongly recommend oz-install ... https://github.com/clalancette/oz Okay, so, sell me on this. I know Oz is popular, especially in the OpenStack world, so we definitely want to make sure it works with Fedora. But what's the advantage over livemedia-creator, if we were to rework the koji appliance build for either one? -- 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 Nov 10, 2012, at 11:21 AM, Kevin Kofler wrote: Jesse Keating wrote: Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. If you want to be truly independent of Fedora, you need to do your development elsewhere and only import finished and fully working upstream releases into Rawhide (which need to be testable by Alpha and 100% complete by Beta), as for any other upstream project in the critical path. As long as you (ab)use Rawhide to do upstream development and alpha-testing in, Fedora WILL dictate how you do development. Sorry, that's not a hard requirement of any other upstream, and KDE/Gnome have frequently used snapshots in rawhide/branched. But nice try. --jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi, I'm trying to get sponsored as a package maintainer and would like to introduce myself. I've been doing some level of build/deployment automation for different companies over the last few years, and one thing that makes life harder than it should is lack of native packages for any given dependency. As such, I've decided to try and contribute packages where I find one is missing. For starters this will be perl modules, but I can think of a couple libraries which I'd like to add later on once I understand the process a bit better. My initial package submission is: https://bugzilla.redhat.com/show_bug.cgi?id=875406 ( sponsors welcome ! ) Regards, João -- http://zonalivre.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the F-18 tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
