Re: remove polkit from core?
On 11/10/2012 05:26 PM, Ville Skyttä wrote: 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. Most interpreters deliberately do this because non-PIC code is significantly faster than PIC code, especially on architectures without IP-relative addressing. These days, it may be possible to recover some of the lost performance by tweaking ELF symbol visibility or amalgamation builds (that is, stuffing everything in a single C file; -flto could perhaps provide an equivalent). -- Florian Weimer / Red Hat Product Security Team -- 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 07:45 PM, Reindl Harald wrote: 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 I meant: Add a requirement for iptables-services to system-config-firewall-base, this is currently not there. 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 Yes, full ack. You will be able to use it after switching off firewalld.service and enabling iptables.service and ip6tables.service. I will add a script for switching from and to dynamic/static mode: switch-firewall -- 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
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. Thanks for info. I reported a bug in anaconda to update the kickstart documentation: https://bugzilla.redhat.com/show_bug.cgi?id=875650 That means that Minimal Core SIG or Core SIG now makes even more sense :-) -- 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
- Original Message - Matthew Miller píše v Čt 08. 11. 2012 v 15:15 -0500: 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 Please comment and join if you're interested. This is intended to be a request for comments and input rather than a finish document. Note that Minimal Core isn't meant to necessarily imply minimal possible distribution. I would have just called it Fedora Core, if we didn't already have a lot of baggage around that name. It means minimal for us, and the group's mission is defining exactly what that means, and estabilishing sensible standards around that. Basically, we have the various desktop SIGs which decide what goes into those package sets, and it's reasonable to have one for core as well. Maybe such groups could exist for all top-level groups in comps? And yes, I'm interested in this SIG. How will be Core SIG related to Server SIG? As a basis for Server SIG work? As far as I can see what you wanted to achieve with this SIG is now covered partially in Core SIG. Jaroslav Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/12/2012 07:28 AM, Seth Vidal wrote: On Sat, 10 Nov 2012, Kevin Kofler wrote: 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! Yum will likely be replaced with dnf afaik. I don't think zif is under consideration at all. -sv DNF is going to be a replacement for Yum, but the underlying libraries are C and I can imagine a simple, fairly straightforward tool on top of them that does the job for minimal install, all in C. Ales -- 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 Sun, Nov 11, 2012 at 06:35:50PM -0500, Matthew Miller wrote: On Sun, Nov 11, 2012 at 04:02:27PM +, Richard W.M. Jones wrote: So .. they're different things. I'm still unclear what sort of appliances you're trying to build and what for, and that will affect what tool you decide to use. This is the official image produced by Fedora for use in EC2 and for download to run in your own private cloud. I can see the appeal of using livemedia-creator, presuming we can get it to work with the build system, but what extra would Oz get us for this case? Since it appears that you want a Fedora build only, not much. BUT for some reason live CD builds have been added as this kind of sideways after-thought to Koji. I guess that's because livecd-creator had to run as root and had to do all sorts of strange stuff with device nodes. None of that is necessary once you've got virtualization, and indeed libguestfs proves we can build and run a complete VM during an ordinary Koji build, with no special permissions required. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121112 changes
Compose started at Mon Nov 12 09:15:40 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
Re: akonadi-googledata retire
Il giorno dom, 11/11/2012 alle 11.04 +0100, Mario Santagiuliana ha scritto: I follow the step to retire akonadi-googledata package. The upstream project is no longer maintain and in kdepim-runtime there is already a new akonadi resource for google services. On fedora git web interface I don't see my the last commit with dead.package file... http://pkgs.fedoraproject.org/cgit/akonadi-googledata.git/ Is it correct? Maybe I do something wrong? Ciao Mario, did you follow the steps of https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life in the right order? If you completed step 5) before step 2) and 3), then you need the help of a provenpackager to fix that. Nicola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how do I allow a service on an arbitrary local interface the firewalld way?
On 11/09/2012 05:21 AM, Matthew Miller wrote: I'm making a crude fake EC2 environment on my test machine, and as part of that, I need a web server listening on 169.254.169.254. I've bound this address to lo:0. How do I use firewall-cmd to allow http through? It's blocked by default. I thought I could do it with the interface=lo:0 argument, but that gives me Warning: ALREADY_ENABLED. And firewall-cmd --list-interfaces returns only 'wlan0' Add the interface to the default zone or to trusted, if you want to have full access: To add the interface to the default zone: firewall-cmd --add-interface=lo:0 To add the interface to the trusted zone: firewall-cmd --add-interface=lo:0 --zone=trusted As : was not allowed in interface names up to now, this is only possible with the GIT version and also soon with an updated firewalld package in Fedora. There doesn't appear to be any real documentation for firewall-cmd. The web page is just development plans, the help is a maze of BNF, and the man page is full of less-than-helpful stuff like: interface=interface Use an interface name. Man pages with more information and also examples are in the works. Where should I look to find out more? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20121112 changes
Compose started at Mon Nov 12 08:15:06 UTC 2012 Broken deps for x86_64 -- [LabPlot] LabPlot-1.6.0.2-12.fc18.i686 requires libaudiofile.so.0 LabPlot-1.6.0.2-12.fc18.x86_64 requires libaudiofile.so.0()(64bit) [autotest-framework] autotest-framework-server-0.14.3-1.fc17.noarch requires mod_python [blacs] blacs-mpich2-1.1-46.fc18.i686 requires libmpich.so.3 blacs-mpich2-1.1-46.fc18.x86_64 requires libmpich.so.3()(64bit) [cduce] cduce-0.5.5-2.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0 cduce-0.5.5-2.fc18.x86_64 requires ocaml(Pcre) = 0:fedf84da3d313aea51e03bb7d7c99a3b [coccinelle] coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(runtime) = 0:4.00.0 coccinelle-1.0.0-0.rc14.5.fc18.x86_64 requires ocaml(Pcre) = 0:fedf84da3d313aea51e03bb7d7c99a3b [cp2k] cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpichf90.so.3()(64bit) cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpich.so.3()(64bit) [dmlite-plugins-memcache] dmlite-plugins-memcache-0.4.0-1.fc18.x86_64 requires libmemcached.so.10()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-selinux = 0:10.0.0 [e16] e16-1.0.10-3.fc18.x86_64 requires libaudiofile.so.0()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [espresso] espresso-mpich2-3.0.2-4.fc18.x86_64 requires libmpich.so.3()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-6.fc19.x86_64 requires gcc = 0:4.7.2-6.fc19 gcc-python2-plugin-0.9-6.fc19.x86_64 requires gcc = 0:4.7.2-6.fc19 gcc-python3-debug-plugin-0.9-6.fc19.x86_64 requires gcc = 0:4.7.2-6.fc19 gcc-python3-plugin-0.9-6.fc19.x86_64 requires gcc = 0:4.7.2-6.fc19 [gcstar] gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox) [ghc-MemoTrie] ghc-MemoTrie-0.5-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-blaze-builder-conduit] ghc-blaze-builder-conduit-0.4.0.2-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-conduit] ghc-conduit-0.4.2-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-ghc-mtl] ghc-ghc-mtl-1.0.1.1-2.fc19.x86_64 requires ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) ghc-ghc-mtl-devel-1.0.1.1-2.fc19.x86_64 requires ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) [ghc-hakyll] ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires libHSpandoc-1.9.4.2-ghc7.4.1.so()(64bit) ghc-hakyll-3.2.7.2-6.fc18.x86_64 requires ghc(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244) ghc-hakyll-devel-3.2.7.2-6.fc18.x86_64 requires ghc-devel(pandoc-1.9.4.2-a2700c5fb49c2879e0846ae80f139244) [ghc-ltk] ghc-ltk-0.12.1.0-6.fc19.x86_64 requires ghc(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) ghc-ltk-devel-0.12.1.0-6.fc19.x86_64 requires ghc-devel(ghc-7.4.1-2e8223f1ab945abe712c4fc4010c270e) [ghc-network-conduit] ghc-network-conduit-0.4.0.1-3.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-snap-core] ghc-snap-core-0.9.0-4.fc18.x86_64 requires libHSunix-compat-0.3.0.1-ghc7.4.1.so()(64bit) ghc-snap-core-0.9.0-4.fc18.x86_64 requires libHSmwc-random-0.12.0.0-ghc7.4.1.so()(64bit) ghc-snap-core-0.9.0-4.fc18.x86_64 requires ghc(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) ghc-snap-core-0.9.0-4.fc18.x86_64 requires ghc(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97) ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires ghc-devel(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b) ghc-snap-core-devel-0.9.0-4.fc18.x86_64 requires ghc-devel(mwc-random-0.12.0.0-9ca879896db2ffb2250b04f25bb8cb97) [ghc-vector-space] ghc-vector-space-0.8.2-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-void] ghc-void-0.5.6-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-void-0.5.6-1.fc18.x86_64 requires ghc(semigroups-0.8.3.2-608a60352745868d7816fbfb76870ddf) ghc-void-devel-0.5.6-1.fc18.x86_64 requires ghc-devel(semigroups-0.8.3.2-608a60352745868d7816fbfb76870ddf) [ghc-wai] ghc-wai-1.2.0.3-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) [ghc-warp] ghc-warp-1.2.2-1.fc18.x86_64 requires libHSunix-compat-0.3.0.1-ghc7.4.1.so()(64bit) ghc-warp-1.2.2-1.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-warp-1.2.2-1.fc18.x86_64 requires ghc(unix-compat-0.3.0.1-5c60739e7246890d88ea5d633793062b)
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Mon, Nov 12, 2012 at 11:13:15AM +, Richard W.M. Jones wrote: BUT for some reason live CD builds have been added as this kind of sideways after-thought to Koji. I guess that's because livecd-creator had to run as root and had to do all sorts of strange stuff with device nodes. None of that is necessary once you've got virtualization, and indeed libguestfs proves we can build and run a complete VM during an ordinary Koji build, with no special permissions required. Many of the Koji builders are actually virtualized themselves now, so if the build process is planning to spin up a new VM, it needs to either be forced to run on a hardware builder (because I really can't believe that the install under full emulation will be a reasonable use of resources) or grow a new ability to spin up a remote cloud instance. This discussion should probably be taken over to the Fedora Infrastructure list. I'll start a new thread (because probably many people here aren't subscribed to that list). -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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 Mon, Nov 12, 2012 at 09:17:53AM -0500, Matthew Miller wrote: Many of the Koji builders are actually virtualized themselves now, so if the build process is planning to spin up a new VM, it needs to either be forced to run on a hardware builder (because I really can't believe that the install under full emulation will be a reasonable use of resources) or grow a new ability to spin up a remote cloud instance. This just makes things a lot more complex. I would measure the resources needed before taking any steps like that, because as I said before installers are I/O bound so as long as you use virtio you should be fine. Maybe one day we'll have good nested virt though ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- 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
Jaroslav Reznik píše v Po 12. 11. 2012 v 04:52 -0500: - Original Message - Matthew Miller píše v Čt 08. 11. 2012 v 15:15 -0500: 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 Please comment and join if you're interested. This is intended to be a request for comments and input rather than a finish document. Note that Minimal Core isn't meant to necessarily imply minimal possible distribution. I would have just called it Fedora Core, if we didn't already have a lot of baggage around that name. It means minimal for us, and the group's mission is defining exactly what that means, and estabilishing sensible standards around that. Basically, we have the various desktop SIGs which decide what goes into those package sets, and it's reasonable to have one for core as well. Maybe such groups could exist for all top-level groups in comps? And yes, I'm interested in this SIG. How will be Core SIG related to Server SIG? As a basis for Server SIG work? As far as I can see what you wanted to achieve with this SIG is now covered partially in Core SIG. it's correct there is an overlap, but it will allow the Server SIG (when alive again) to concentrate on the higher level stuff (like organizing the servers in comps to be easier accessible) while the Core SIG will care of the common lowest denominator. And is also answers the question where the Server begins = on top of Core. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Saturday, November 10, 2012 09:26:26 AM Richard W.M. Jones wrote: 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). Another problem is how would we do SCAP configuration checks when the language will allow 20 different ways to do the same thing? We might be able to do a SHA256 has of the js. Which means you've completely lost any ability to modify the behaviour. In an ini file, we could pick out the lines that were important and check them only allowing other settings we don't care about to change. Additionally, access control decisions should be audited. There are no libaudit bindings for javascript. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: akonadi-googledata retire
In data lunedì 12 novembre 2012 14:41:43, Nicola Soranzo ha scritto: Ciao Mario, did you follow the steps of https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life in the right order? If you completed step 5) before step 2) and 3), then you need the help of a provenpackager to fix that. Yes I done it, but I had must to do a git push error and I didn't read correctly the output and I'm gone ahead with the various steps... I wrote to fedora-kde mailing list, I hope Rex Dieter, or another provepackager can fix my stupid error... This is my first package retire and obviously I do something wrong... :( Thank you! -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: akonadi-googledata retire
On Mon, 12 Nov 2012 16:57:06 +0100 Mario Santagiuliana fed...@marionline.it wrote: In data lunedì 12 novembre 2012 14:41:43, Nicola Soranzo ha scritto: Ciao Mario, did you follow the steps of https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life in the right order? If you completed step 5) before step 2) and 3), then you need the help of a provenpackager to fix that. Yes I done it, but I had must to do a git push error and I didn't read correctly the output and I'm gone ahead with the various steps... I wrote to fedora-kde mailing list, I hope Rex Dieter, or another provepackager can fix my stupid error... This is my first package retire and obviously I do something wrong... :( It happens. I've pushed the commits to mark it dead.package now. Please let me know if you still see anything amiss and I will help you fix it up. 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
On 11/11/2012 10:01 PM, Seth Vidal wrote: Jesse, To be fair - gnome/kde importing something into rawhide/branched that's not finished doesn't shut down everyone else's ability to test the distro I think it is disingenuous to talk about another distro using anaconda - b/c the only other one that does, directly, is rhel - and they're downstream of fedora, too. That doesn't mean things can be dictated - but it does mean that breaking/delaying fedora is not something that should be done lightly. I think holding anaconda to higher standards is not a ridiculous concept. For years the requirement for yum and rpm (even in rawhide) has been 'never commit something so broken it cannot be used to revert itself'. but I'm positive that this conversation is long past the point of productivity so... I can't disagree with this message. I'll also point out that we didn't have a lot of choices for F18. We could either leave the existing anaconda package there (which was completely broken) or import the partially functional newUI code base. We went with the option that would provide the most functionality, which was the newUI code base. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[@core] working definition for the minimal package set
Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Mon, Nov 12, 2012 at 10:37:54AM -0500, Steve Grubb wrote: 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! Another problem is how would we do SCAP configuration checks when the language will allow 20 different ways to do the same thing? We might be able to do a SHA256 has of the js. Which means you've completely lost any ability to modify the behaviour. In an ini file, we could pick out the lines that were important and check them only allowing other settings we don't care about to change. Additionally, access control decisions should be audited. There are no libaudit bindings for javascript. I'm very sympathetic to these concerns, but this is the way the upstream package has gone. How do we reconcile that? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: itext 5.x
On Fri, Nov 9, 2012 at 11:26 PM, Orcan Ogetbil oget.fed...@gmail.comwrote: Yeah, we can't have itext-5 in Fedora. Please see [1] and the references therein. We could not update bouncycastle either, lately, due to its incompatibility with itext-2. I have some patches that give partial success with building itext-2 against the latest bouncycastle API, but the build fails during the AOT bits compilation step. I am not a java programmer and I eventually gave up working on it. Meanwhile, I dropped the maintainership for both bouncycastle and itext-2 a couple months ago. To my knowledge, these packages are still up for grabs. Best, Orcan [1] http://lists.fedoraproject.org/pipermail/legal/2011-June/001653.html Thanks for the information, Orcan. Well, drat. I guess I'll have to see if I can either downgrade the itext usage in the app I'm looking at, or excise it altogether. Can you send me your itext-2 patches? I can't promise anything, but I'll see if I can get it working with the latest bouncycastle. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ ditto w/rsync. -sv -- 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 2012-11-11 23:43, Panu Matilainen wrote: On 11/12/2012 08:56 AM, Adam Williamson wrote: On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. Meh. Of course not. But unlike yum, pungi deals with space-constrained images and if it ends up pulling useless cruft in those images then it's not doing the best job it can for the very specific task it has. Well, it's one of those things where you have two imperatives and you can't possibly satisfy both: be space efficient but also ensure that any installation done from the images will be complete and sensible. I think pungi makes the choice to prioritize the latter. Any kind of 'space efficiency' code is going to come with a non-zero danger of resulting in dependency problems or odd dependency resolutions, I guess. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. No disagreement there. But quite obviously nothing is currently finding those packaging errors, much of the suspect items list I posted has been there for years already. Just haven't gotten around to mention it anywhere. I'll shut up now and go see if I can actually do something about it. I recommend it - it's not hard to probe out why these things happen (usually), and it can be quite fun. BTW, QA does have a test which looks for non-explicit conflicts or incomplete dependencies on the images and we hit those every so often, so we're pretty used to poking through things like this. It often tracks out to something which was a packaging problem in the first place and needed to be fixed. If you wind up getting stuck, poke dgilmore in #fedora-releng, as he should have the logs of the compose to look through which can help identifying some of the issues. -- 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 Mon, Nov 12, 2012 at 5:16 PM, Jesse Keating jkeat...@redhat.com wrote: On 11/11/2012 10:01 PM, Seth Vidal wrote: Jesse, To be fair - gnome/kde importing something into rawhide/branched that's not finished doesn't shut down everyone else's ability to test the distro I think it is disingenuous to talk about another distro using anaconda - b/c the only other one that does, directly, is rhel - and they're downstream of fedora, too. That doesn't mean things can be dictated - but it does mean that breaking/delaying fedora is not something that should be done lightly. I think holding anaconda to higher standards is not a ridiculous concept. For years the requirement for yum and rpm (even in rawhide) has been 'never commit something so broken it cannot be used to revert itself'. but I'm positive that this conversation is long past the point of productivity so... I can't disagree with this message. I'll also point out that we didn't have a lot of choices for F18. We could either leave the existing anaconda package there (which was completely broken) or import the partially functional newUI code base. We went with the option that would provide the most functionality, which was the newUI code base. And there was a third option ... port over the old anaconda to the F18 changes. (so you'd have less changes). -- 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/12/2012 08:45 AM, drago01 wrote: And there was a third option ... port over the old anaconda to the F18 changes. (so you'd have less changes). Which would have taken just about as long to get working, and would delay the newui move further. But that's OK, you can keep banging that drum. -- 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 Mon, Nov 12, 2012 at 5:49 PM, Jesse Keating jkeat...@redhat.com wrote: On 11/12/2012 08:45 AM, drago01 wrote: And there was a third option ... port over the old anaconda to the F18 changes. (so you'd have less changes). Which would have taken just about as long to get working, and would delay the newui move further. How so? You'd have to just port over the other layers to work with the new stuff and in F19 focus on the UI. Now you had to do both at the same time with the same amount of man power. But that's OK, you can keep banging that drum. Yeah I know that something like that would be coming back but well ... we can't change what happened and unfortunately can't even learn from the mistakes made because the everything else is impossible attitude. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. -sv -- 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/12/2012 08:58 AM, drago01 wrote: How so? You'd have to just port over the other layers to work with the new stuff and in F19 focus on the UI. Now you had to do both at the same time with the same amount of man power. Changes in the dracut environment broke assumptions in the runtime environment. Code in newUI is different from old code in some of the same areas, which means doing the work twice instead of once. Not to mention porting forward all the other bits of F17's anaconda that doesn't work with F18's userland tools/apis. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote: On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. i think you misunderstand. if I am attempting to connect to a server running sshd: I can run ssh servername and that works I can run sftp servername and THAT works I cannot run scp servername I have to have a local scp client installed on the server for scp to work as a service. -sv -- 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 Mon, Nov 12, 2012 at 05:58:01PM +0100, drago01 wrote: How so? You'd have to just port over the other layers to work with the new stuff and in F19 focus on the UI. Now you had to do both at the same time with the same amount of man power. I haven't looked at the new code, but I've spent a _lot_ of time with the old. I don't think the new UI is just a re-skinning, but is a redesign of the program's more fundamental architecture. It now supports a hub and spoke model for option selection followed by a second stage where choices are applied, where as the old model was based around linear steps. That makes it harder to separate the changes, and I think it very reasonable to assume that a lot of the backend work would have to have been done twice. Now, having gone through this, the program is more ready for future adaptation. Maybe in another decade we'll need another big redesign, but until then, the current work will make it *more* possible to develop future Anaconda improvements in Rawhide in parallel with a stable maintenance branch. At least, that's my interested-outsider view here. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:10 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote: On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. i think you misunderstand. if I am attempting to connect to a server running sshd: I can run ssh servername and that works I can run sftp servername and THAT works I cannot run scp servername I have to have a local scp client installed on the server for scp to work as a service. scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. Petr -- Petr Lautrbach, Red Hat, Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. -sv -- 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 Seg, 2012-11-12 at 08:49 -0800, Jesse Keating wrote: On 11/12/2012 08:45 AM, drago01 wrote: And there was a third option ... port over the old anaconda to the F18 changes. (so you'd have less changes). Which would have taken just about as long to get working, and would delay the newui move further. But that's OK, you can keep banging that drum. and 2 weeks are enough ? or you will need more time ? I don't mind postpone a release , but I prefer one postpone of 4 weeks than 4 of one week ... Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 875784] New: perl-CGI-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875784 Bug ID: 875784 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org Assignee: mmasl...@redhat.com Summary: perl-CGI-3.62 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-CGI Product: Fedora Latest upstream release: 3.62 Current version in Fedora Rawhide: 3.61 URL: http://search.cpan.org/dist/CGI/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: remove polkit from core?
On Mon, Nov 12, 2012 at 09:41:22AM +0100, Florian Weimer wrote: On 11/10/2012 05:26 PM, Ville Skyttä wrote: 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. Most interpreters deliberately do this because non-PIC code is significantly faster than PIC code, especially on architectures without IP-relative addressing. Two notes: tis might be the default case upstream but it's not normal behaviour in what we package for Fedora: $ ldd `which perl`|grep libperl libperl.so = /usr/lib64/perl5/CORE/libperl.so (0x0034d1e0) $ ldd `which python`|grep libpython libpython2.7.so.1.0 = /lib64/libpython2.7.so.1.0 (0x0034da00) $ ldd `which ruby`|grep libruby libruby.so.1.9 = /lib64/libruby.so.1.9 (0x0034bca0) ajax (IIRC) analyzed the speed increase of non-PIC code when he worked on this: https://fedoraproject.org/wiki/User:Tibbs/Text_Relocation_Guidelines?rd=User:Tibbs/Static_Library_PICness_Guidelines#Rationale He found a small performance benefit, not significantly faster performance. He also made the case that non-PIC code has negative performance characteristics that are weighed against the gains. -Toshio pgpkVFxQ5J5RR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 875787] New: perl-IO-Compress-2.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875787 Bug ID: 875787 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, p...@city-fan.org, perl-de...@lists.fedoraproject.org Assignee: mmasl...@redhat.com Summary: perl-IO-Compress-2.057 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-IO-Compress Product: Fedora Latest upstream release: 2.057 Current version in Fedora Rawhide: 2.055 URL: http://search.cpan.org/dist/IO-Compress/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 875789] New: perl-Net-HTTP-6.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875789 Bug ID: 875789 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: perl-Net-HTTP-6.05 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Net-HTTP Product: Fedora Latest upstream release: 6.05 Current version in Fedora Rawhide: 6.04 URL: http://search.cpan.org/dist/Net-HTTP/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: remove polkit from core?
On Sat, 2012-11-10 at 02:33 +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! So that more complex rules-parsing can be done instead of hardcoded rules. For example, when creating a new WiFi network, NetworkManager could pass along the security options, network details, even the user that requested creating it. Administrator-written rules can factor all those details into the decision whether to allow/deny, which the existing static rules simply cannot do. Whether or not JS should be a *hard* dependency of PolicyKit, I don't know. But the feature is valuable, so don't dismiss it out-of-hand. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:44 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Petr Lautrbach wrote: scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. A thin client would probably not want to install openssh-server. Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network interface renaming, where does INTERFACE_NAME get applied?
On Sat, 2012-11-10 at 00:45 +0100, Lennart Poettering wrote:
On Fri, 09.11.12 11:42, Daniel Drake (d...@laptop.org) wrote:
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
IIRC support INTERFACE_NAME is gone for quite a while since udev stopped
to provide implicit permenanet naming since it was a trainwreck. People
should use biosdevname instead.
Which doesn't work for USB devices, in which case you have to write
manual rules to do the rename. And when you do, please make sure you
rename the interface somewhere *not* in the kernel namespace, which
means don't use ethX, usbX, wwanX, wlanX, etc. Otherwise you'll
race with the kernel when discovering network devices, and the rename
will fail.
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote: A thin client would probably not want to install openssh-server. Bringing us back around to the point of this thread. :) Thin client is one use case. Server base is another. JEOS cloud image is another. We don't necessarily have to define @core such that it means only the bare minimum (although I think that's on the table, at least). It's useful to consider packages which might fit a broad reading of the use cases within the scope of this SIG. For example, if SSH suddenly grew a dependency on (picking on something at random) Django, I think we'd want to talk about it. That's one of the reasons I think it's useful to have a broader target. -- 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
Seth Vidal wrote: Yum will likely be replaced with dnf afaik. I don't think zif is under consideration at all. That's exactly what I'm complaining about. Dnf is no improvement over yum at all, zif would bring real advantages through the simple fact that it's native code, not Python. Native C code is faster, requires less memory and is less likely to break when the system is broken (and thus more likely to be usable to repair it). Zif also interoperates much better with PackageKit (on which our package management UIs, gnome-packagekit and Apper, are based), being implemented in the same language by the same primary developer and designed with PackageKit in mind (whereas yum happily breaks APIs used by PackageKit, see e.g. the repo.str() case; apparently, you don't even test your changes with PackageKit!). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Jan Zelený wrote: Yes, that's the plan. But dnf is still Python. So if we really want to get Python out of minimal install, there is a room for possible alternatives I guess. Right. We need to stop writing core system components in scripting languages! But none of this is certainly happening for at least a year or two, we don't want to break things by rushing. But that doesn't justify adding MORE Python stuff to the minimal install. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote: On Sat, 2012-11-10 at 02:33 +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! So that more complex rules-parsing can be done instead of hardcoded rules. For example, when creating a new WiFi network, NetworkManager could pass along the security options, network details, even the user that requested creating it. Administrator-written rules can factor all those details into the decision whether to allow/deny, which the existing static rules simply cannot do. except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. IOW, anyone running any sizeable operation just lost any flexibility. Whether or not JS should be a *hard* dependency of PolicyKit, I don't know. But the feature is valuable, so don't dismiss it out-of-hand. I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jan Zelený wrote: Yes, that's the plan. But dnf is still Python. So if we really want to get Python out of minimal install, there is a room for possible alternatives I guess. Right. We need to stop writing core system components in scripting languages! Well, there _are_ significant advantages to using a higer-level language than C.[1] Using one of the higher-level languages as a primary development language on par with C often increases the quality of the software and the time to develop it, in return for an acceptable loss of speed. If firewalld were an on-demand, automatically-terminating D-Bus service, I can't really see any reason to object to a using higher-level language. Unfortunately, there's seems to be something significantly wrong/disliked about every candidate higher-level language. For better or worse, the Fedora world is mostly standardized on using Python in such situations. Is it perfect? No. Is it better than nothing? I think so. Mirek [1] At least two to mention: - Automatic memory management, with all associated lack of bugs and simplified code - Much easier access to higher-level (and more efficient!) data structures. C programs frequently use linked lists instead of e.g. hash tables simply because maintaining hash tables and the associated memory allocation is just too complex. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Once upon a time, Miloslav Trmač m...@volny.cz said: - Much easier access to higher-level (and more efficient!) data structures. C programs frequently use linked lists instead of e.g. hash tables simply because maintaining hash tables and the associated memory allocation is just too complex. Hash table management was a part of my computer science core curriculum; it isn't _that_ hard. Also, for C programmers, there's standard library hash management functions that are easy to use (never try to re-invent the wheel!). See man hcreate_r (although it is unfortunately just a GNU extension to have multiple hash tables). Now, given that, I still write most of my system admin stuff in perl. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Monday, November 12, 2012 08:15:48 PM Miloslav Trmač wrote: On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jan Zelený wrote: Yes, that's the plan. But dnf is still Python. So if we really want to get Python out of minimal install, there is a room for possible alternatives I guess. Right. We need to stop writing core system components in scripting languages! Well, there are significant advantages to using a higer-level language than C.[1] But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Mon, Nov 12, 2012 at 8:25 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Miloslav Trmač m...@volny.cz said: - Much easier access to higher-level (and more efficient!) data structures. C programs frequently use linked lists instead of e.g. hash tables simply because maintaining hash tables and the associated memory allocation is just too complex. Hash table management was a part of my computer science core curriculum; it isn't _that_ hard. Sure. Now create a hash table indexed by a tuple, or for more challenge by an unordered set of strings. Or have all items of the same type hashed by three different fields for fast lookups. Can it be done? Absolutely. Will it be bug-free? Probably not on the first try. Do C programmers actually write such code? So far as I have seen, usually not; if something simpler and less efficient works for version 1, it stays that way until it is becomes a very noticeable bottleneck. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Once upon a time, Miloslav Trmač m...@volny.cz said: Sure. Now create a hash table indexed by a tuple, or for more challenge by an unordered set of strings. Or have all items of the same type hashed by three different fields for fast lookups. If I were trying to do all that, I'd probably just go with an in-memory SQLite table. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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 11/12/2012 09:43 AM, Panu Matilainen wrote: On 11/12/2012 08:56 AM, Adam Williamson wrote: On 2012-11-11 22:02, Panu Matilainen wrote: Based on a quick grep, it doesn't seem to consider obsoletion at all, which explains what I see on the DVD and perhaps deserves looking at. I think the basic idea is that pungi isn't supposed to painfully re-implement yum. Meh. Of course not. But unlike yum, pungi deals with space-constrained images and if it ends up pulling useless cruft in those images then it's not doing the best job it can for the very specific task it has. If packages are obsoleted, they're supposed to be retired. If something's obsoleted but not retired, that's a packaging error. No disagreement there. But quite obviously nothing is currently finding those packaging errors, much of the suspect items list I posted has been there for years already. Just haven't gotten around to mention it anywhere. I'll shut up now and go see if I can actually do something about it. FWIW, this is what I get with F18 pungi compose: -rw-r--r--. 1 root root240 Nov 12 21:10 Fedora-18-x86_64-CHECKSUM -rw-r--r--. 1 root root 4687134720 Nov 12 21:10 Fedora-18-x86_64-DVD.iso -rw-r--r--. 2 root root 268435456 Nov 12 19:22 Fedora-18-x86_64-netinst.iso And this is with a patched pungi to filter out obsoleted packages: -rw-r--r--. 1 root root240 Nov 12 21:02 Fedora-18-x86_64-CHECKSUM -rw-r--r--. 1 root root 4550819840 Nov 12 21:01 Fedora-18-x86_64-DVD.iso -rw-r--r--. 2 root root 268435456 Nov 12 19:22 Fedora-18-x86_64-netinst.iso It might not save the whales or even the day, but the difference is simply dead weight of obsoleted packages, and the list of packages excluded this way shockingly matches what the install-everything rpm test found. Here's the diff to pungi in case somebody is interested: [root@turre pypungi]# diff -u __init__.py.orig __init__.py --- __init__.py.orig2012-11-12 19:12:12.592544072 +0200 +++ __init__.py 2012-11-12 21:12:14.139970112 +0200 @@ -336,6 +336,14 @@ pkg_sack.remove(pkg) break +# weed out obsoleted packages +obsoleters = pkg.obsoletedBy(self.ayum.pkgSack.searchObsoletes(pkg.name), limit=1) +if obsoleters: +obs = obsoleters[0] +self.logger.info(Excluding %s.%s (obsoleted by %s.%s) % (pkg.name, pkg.arch, obs.name, obs.arch)) +self.excluded_pkgs[pkg.nvra] = pkg +pkg_sack.remove(pkg) + return pkg_sack def getPackageDeps(self, po): - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. A thin client would probably not want to install openssh-server. fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:21:43PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? Historically the @core group did not have anything other than mandatory packages as there was no UI to deselect them (because core was not a visible group). Core is still not a visible group, but there appears to be a few default packages in there now, But there was a non-UI way. Does that no longer work? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Jesse Keating wrote: On 11/12/2012 12:17 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? Historically the @core group did not have anything other than mandatory packages as there was no UI to deselect them (because core was not a visible group). Core is still not a visible group, but there appears to be a few default packages in there now, NetworkManager, ppc64-utils, and sendmail. I'm not sure of the backstory on this, but now you can - those packages (provided nothing else requires them). More of @core could be made this way, if that was desired for the kickstarters. sendmail is in there so we didn't need a special case to make sendmail 'win' for the options for MTA. ppc64-utils is b/c I do not think we had another way to get it in for the ppc boxes. -sv -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 9 Nov 2012 17:33:05 +0100 Matej Cepl mc...@redhat.com escribió: 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)? My email client uses around 2gb of ram firefox usually is using between 512Mb and 1Gb your statement for me is false. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlChXKcACgkQkSxm47BaWfegdwCgvRcXX2yvWVjcX7Ih7dm5lub/ MUAAn26pii5vJ6UVeR19YPt86BKCwQv6 =IOdA -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Seth Vidal skvi...@fedoraproject.org writes: fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Benny Amorsen wrote: Seth Vidal skvi...@fedoraproject.org writes: fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. why is rpm -e in %post in the kickstart not okay? the system isn't 'up'. what harm is it in cleaning up crap? If you're doing enough installs that the bandwidth is an issue in installing these additional packages then you should make a local mirror, I'd think. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Mon, Nov 12, 2012 at 02:53:01PM -0500, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. Eh 2to3 is used in code besides the 2to3 command line tool. idlelib I aven't seen being used but... These are libraries provided by the main python distribution whether or not they're frequently used. If this is something we want to pursuse, perhaps we really want to look at all of the python stdlib and decide if there's other things that are not popular and we'd wish to make into subpackages. This is not a one-time piece of work, however -- there'd be ongoing maintainance -- for instance, if we broke the 2to3 module into its own subpackage and then a different python-stdlib module started importing it we'd have to spot that new inter-dependency and move 2to3 back into the stdlib. -Toshio pgp3rKodX0r25.pgp Description: PGP 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 ...]
Richard W.M. Jones wrote: Maybe one day we'll have good nested virt though ... Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction. 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
Once upon a time, Dennis Gilmore den...@ausil.us said: El Fri, 9 Nov 2012 17:33:05 +0100 Matej Cepl mc...@redhat.com escribió: 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)? My email client uses around 2gb of ram firefox usually is using between 512Mb and 1Gb your statement for me is false. Read the message, especially SOHO server. Most people are not running email clients and Firefox on servers. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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!
Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! 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 11/12/2012 09:05 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... JBG -- 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!
Adam Williamson wrote: They already aren't. Half the point of going to 1GB would be to include them. There's no way LibreOffice is going to fit on the KDE spin with a 1 GiB target limit. We're already almost there no thanks to MiniDebugInfo. We'd need an even higher target size to fit LibreOffice. Look, Johann already pointed out, the relevant SIG for each spin owns the spin size. It's not a topic for devel@ kibbitzing and voting. I can't stop you posting +1s, but you're wasting your time if you're not a member of the relevant spin SIG. As seems to need pointing out so often, this isn't a democracy, it's a do-ocracy. You don't get anything done by posting indignant messages on mailing lists. I *AM* a member of the KDE SIG and have de-facto maintained the KDE spin kickstart ever since Sebastian Vahl (the official maintainer) has stopped taking care of it. FESCo has clearly said that they don't care about our size target and that we must target a larger size if MiniDebugInfo blows the current target. This is not a do-ocracy at all. It's design by committee. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: akonadi-googledata retire
In data lunedì 12 novembre 2012 08:53:19, Kevin Fenzi ha scritto: It happens. I've pushed the commits to mark it dead.package now. Please let me know if you still see anything amiss and I will help you fix it up. Thank you very much Kevin! Everything should be ok now! Thanks to Nicola and also to Rex for their support. :) -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- 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!
Jóhann B. Guðmundsson wrote: Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... Their reasoning was simply that nobody uses CDs anymore anyway. :-/ And unfortunately we can only directly decide what goes into the spin at the package level, stuff which bloats every package from the inside like MiniDebugInfo cannot reasonably be opted out per spin. So FESCo should listen to spin maintainers there. Sadly, it didn't. Even when OLPC pointed out that this feature also made THEIR spin oversized and they cannot simply bump the size target without actually desupporting a large subset of their hardware, FESCo ignored the objection. Even just one spin maintainer/SIG vetoing a feature should block it, it's just plain unacceptable that it gets approved over the objections of TWO spins. 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 Mon, 12 Nov 2012 21:09:42 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/12/2012 09:05 PM, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Last time I checked the SIG's surrounding each of those spins they themselves where responsible for their own spins sizes so if they pass that they might just as well be doing so deliberately to deliver better out of the box experience for their target user base... I'm in the KDE SIG. We were basically forced to give up CD size because MiniDebugInfo was approved by FESCo over our objection. (We objected because of this very size issue.) FESCo explicitly told us Make your image larger then, we don't care. SIGs setting their own size targets only works if the size targets are actually enforced against the features which break them! Fesco needs to provide the reasoning behind that decision to me it makes no sense since the community surrounding their spins are the once that actually decide what goes on them since they are the once doing their own leg work... Please read all the logs from the fesco meetings where this feature was approved. FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I don't recall anyone saying Make your image larger then, we don't care. Your possible options are: a) target a larger size (which is what you have done?) b) ask FESCo to reconsider, but you probibly want some kind of NEW data for that, because without that it's just likely to end the same way. c) Drop some more stuff from the live to get it back under 700mb. kevin signature.asc Description: PGP 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 Mon, 12 Nov 2012 22:12:21 +0100 Kevin Kofler kevin.kof...@chello.at wrote: I *AM* a member of the KDE SIG and have de-facto maintained the KDE spin kickstart ever since Sebastian Vahl (the official maintainer) has stopped taking care of it. FESCo has clearly said that they don't care about our size target and that we must target a larger size if MiniDebugInfo blows the current target. This is not a do-ocracy at all. It's design by committee. It's a community. Sometimes things aren't ideal for one group in favor of another. Anyhow, I don't think this thread is productive anymore, so can we move on? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
If dnf is no improvement, then I'd rather we stick with yum; messing with something new just means spending time that I don't have trying to learn that new command. This is incredibly cumbersome. If at all possible, please stay with yum. On Nov 12, 2012 10:53 AM, Kevin Kofler kevin.kof...@chello.at wrote: Seth Vidal wrote: Yum will likely be replaced with dnf afaik. I don't think zif is under consideration at all. That's exactly what I'm complaining about. Dnf is no improvement over yum at all, zif would bring real advantages through the simple fact that it's native code, not Python. Native C code is faster, requires less memory and is less likely to break when the system is broken (and thus more likely to be usable to repair it). Zif also interoperates much better with PackageKit (on which our package management UIs, gnome-packagekit and Apper, are based), being implemented in the same language by the same primary developer and designed with PackageKit in mind (whereas yum happily breaks APIs used by PackageKit, see e.g. the repo.str() case; apparently, you don't even test your changes with PackageKit!). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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 11/12/2012 09:36 PM, Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I see done to making abrt atleast somewhat usable JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Once upon a time, Richard Vickery richard.vicker...@gmail.com said: If dnf is no improvement, then I'd rather we stick with yum; messing with something new just means spending time that I don't have trying to learn that new command. This is incredibly cumbersome. If at all possible, please stay with yum. You should learn about something before you criticize it: https://fedoraproject.org/wiki/Features/DNF dnf is currently implementing a (subset of) existing yum commands. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- 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 Mon, Nov 12, 2012 at 09:49:58PM +0100, Kevin Kofler wrote: Richard W.M. Jones wrote: Maybe one day we'll have good nested virt though ... Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction. We talked about this at the KVM Forum. Apparently Intel nested virt is *hard* .. the code is larger than the rest of KVM combined. AMD nested virt was much easier, because AMD choose a completely different and much less hairy way to implement virt in the first place. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 01:42:02PM -0500, Matthew Miller wrote: On Mon, Nov 12, 2012 at 07:10:21PM +0100, Petr Lautrbach wrote: A thin client would probably not want to install openssh-server. Bringing us back around to the point of this thread. :) Thin client is one use case. Server base is another. JEOS cloud image is another. oVirt Node is another ... It's not really like any of the things discussed before: (a) It's sealed. You can't use yum to install packages, by design. (b) It's minimized. In order to fit it on very tiny flash disks, large parts such as docs and locales are 'rm -rf'd. 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
macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
See also, https://bugzilla.redhat.com/show_bug.cgi?id=875954 orionp and I were discussing on irc today, the idea to add -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo to %cmake by default in /etc/rpm/macros.cmake , while making it easy to set/override manually, similar to how %_cmake_lib_suffix64 is currently handled. the idea being that many cmake projects default to Release (or not, sometimes goofy things like Debug) The idea being that many projects default to CMAKE_BUILD_TYPE=Release and end up pulling in -O3 (and -DNDEBUG). There's 2 issues we'd like some wider input. What disadvantages or side- effects are there to: 1. setting a default CMAKE_BUILD_TYPE? 2. building with -DNDEBUG by default? Personally, 1. Re: CMAKE_BUILD_TYPE: I feel anything that breaks due to this is probably already broken in some regard, and is worth fixing anyway. After all, we did make this easy to set/override manually. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Change still frightens people to varying degree s., and many busy end-users may not have time to read pages in order to learn a new command On Nov 12, 2012 1:46 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Richard Vickery richard.vicker...@gmail.com said: If dnf is no improvement, then I'd rather we stick with yum; messing with something new just means spending time that I don't have trying to learn that new command. This is incredibly cumbersome. If at all possible, please stay with yum. You should learn about something before you criticize it: https://fedoraproject.org/wiki/Features/DNF dnf is currently implementing a (subset of) existing yum commands. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[X-post] Reminder: FESCo, FAmSCo, Board election nomination period and questionnaire collection ends today!
Attention all fedorians! This is an urgent but gentle reminder that the nomination period for the elections ends today (November 13 at 2359 UTC). Please update the wiki page with your nominations before the nominations period ends later today if you'd like to be considered and voted for! All the best! Fedora Project Board (two seats) FESCo (Engineering) (four seats) FAmSCo (Ambassadors) (three seats) I'd also like to remind you that that the questionnaire will close today as well: https://fedoraproject.org/wiki/F19_elections_questionnaire Please regard this as critical: - We currently have ONE nomination for FAmSCo (to fill 3 seats?), THREE for FESCo (to fill 4 seats?) and *NONE* for the Fedora Board (to fill 2 seats!). - We have no questions in the questionnaire at all. :( -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- 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 ...]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 10 Nov 2012 11:12:20 -0500 Matthew Miller mat...@fedoraproject.org escribió: 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. Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening. 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. Boxgrinder is not a viable option at all. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlChirkACgkQkSxm47BaWfeGXACfe5LNCOZUvVcscAqY+xg/wA4M qnwAn1DJ27kAIXgZ8zEAupOKDazyms40 =lKhO -END PGP 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 ...]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 10 Nov 2012 14:40:02 -0500 Matthew Miller mat...@fedoraproject.org escribió: 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. the issue is entirely launching vms inside of chroots nothing else. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlChi5AACgkQkSxm47BaWffzSwCghvdNpfP+LVqAs6DSA8fCjB9d dcAAnibZe7ewAfzk+eICo3O4egkbW2uB =Yef2 -END PGP 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 Mon, 12 Nov 2012, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 10 Nov 2012 11:12:20 -0500 Matthew Miller mat...@fedoraproject.org escribió: 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. Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening. 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. Boxgrinder is not a viable option at all. agreed - if for any reason than too many moving parts and a giant software stack behind it. Dennis, ami-creator is what I've been using to make imgs for euca and I know it will work for ec2 imgs (provided you have a kernel/ramdisk which works with xen) And ami-creator only requires a dead-standard stock kickstart file. (well you have to do various things in %post to make the img work when it is spun up in an instance but that's nothing different than normal kickstarty-ness. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Once upon a time, Richard Vickery richard.vicker...@gmail.com said: Change still frightens people to varying degree s., and many busy end-users may not have time to read pages in order to learn a new command It is in _development_ and is just in F18 as a preview. If/when it is ready to replace yum, it may get a symlink from /usr/bin/yum. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote: But there was a non-UI way. Does that no longer work? The non-UI way was kickstart. But you can't deselect (-) mandatory packages in a group. @core is primarily made up of mandatory packages. Huh. I could swear I've done that before and it worked. In any case, it is _certainly_ working with appliance-creator right now. :) This actually opens up another axis, here, so we could have one standard for mandatory packages (kernel+init, or up-to-yum+net) and a second level for default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the distinction between mandatory and deselectable is huge for kickstart, which I think is common for _most_ of our use cases. -- 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
I just found this. https://kb.askmonty.org/en/mariadb-1000-changelog -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
I think a minimal image is just like centos minimal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 10:13:54AM +0800, Christopher Meng wrote: I think a minimal image is just like centos minimal. Care to share what that means? -- 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
On Mon, Nov 12, 2012 at 8:06 PM, Christopher Meng cicku...@gmail.com wrote: I just found this. https://kb.askmonty.org/en/mariadb-1000-changelog Nice find. Are you suggesting anything? -- 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: [@core] working definition for the minimal package set
I don't know Fedora minimal looks like...FOR SERVER USE the Minimal includes: Network support; BASH; Maybe some development tools also. Nothing else. BUT FOR DESKTOP USE,I think it should also have a desktop based on server version...That's what is troubling me...If it has a built-in desktop,I don't know if we can still treat it as minimal.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
So IMO I think now that we can accept different database tools into repo,it's available for us to include mariadb.Official says they will try to become a independent software but not a mod based on MySQL... Maybe easy for review? I don't know exactly... -- 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: 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? livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpxTrepAWG4W.pgp Description: PGP 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 Mon, Nov 12, 2012 at 07:04:29PM -0800, Brian C. Lane wrote: adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17. Huh. I guess the question is: *will* it work for F18 or beyond? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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 Mon, Nov 12, 2012 at 05:48:05PM -0600, Dennis Gilmore wrote: Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening. Actually it was. That's one of the reasons why the --no-virt mode was added. The primary goal for livemedia-creator was to use the same codepath for creating installed systems and livemedia, not to duplicate how livecd-creator works (basically a chrooted yum install). -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpdhpxOEKn3E.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 2012-11-12 12:59, Chris Adams wrote: Once upon a time, Dennis Gilmore den...@ausil.us said: El Fri, 9 Nov 2012 17:33:05 +0100 Matej Cepl mc...@redhat.com escribió: 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)? My email client uses around 2gb of ram firefox usually is using between 512Mb and 1Gb your statement for me is false. Read the message, especially SOHO server. Most people are not running email clients and Firefox on servers. That doesn't make it a sensible argument or target. My IRC proxy VM sits there using about 20MB of RAM. That's a perfectly useful installation of Fedora. So should our target be to fit our sophisticated graphical installer in 20MB of RAM, something it hasn't managed for at least a decade? Really? This thread continues to get more absurd. Everyone agrees it would be good to make the installer as efficient as possible. It is open source code. Check it out from git and go to work. Patches to anaconda-devel-list. The anaconda team is aware that memory usage could be optimized; however, you may have noticed they're a _tad_ busy with other things too. Is there anything more to say in this thread? Given that no silly usage / historical comparisons anyone can make are going to magically result in a halving of the RAM use of the installer? -- 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: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Mon, Nov 12, 2012 at 10:05:50PM -0500, Matthew Miller wrote: On Mon, Nov 12, 2012 at 07:04:29PM -0800, Brian C. Lane wrote: adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? livemedia-creator has a --no-vitr mode which uses anaconda's --image install mode. It doesn't currently work for F18, but does work for F17. Huh. I guess the question is: *will* it work for F18 or beyond? Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final. More testing would be appreciated though, especially the EC2 code that I added blind. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpF1X4Xm7Cg9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
iprutils -- should this be pulled in by anaconda instead of in core?
The iprutils package provides utilities for IBM Power Linux RAID adapters. Up until current rawhide, this was exclusive to that architecture. However, now it's built on all archs (because these devices _may_ be found there). I know anaconda currently does some magic to install storage-related packages; should this be included there rather than on the minimal list? It's not a big package, but unless it's necessary I don't think we want to force it on every system everywhere, do we? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- 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 ...]
Am 12.11.2012 21:49, schrieb Kevin Kofler: Richard W.M. Jones wrote: Maybe one day we'll have good nested virt though ... Nested virt would really be the right solution, if we can make it work with today's hardware. It feels quite wrong that virtualization can do everything except virtualizing, it kinda breaks the abstraction i think this will be possible in the future VMware workstation supports ESXi with 64bit guests as long your CPU supports http://en.wikipedia.org/wiki/Extended_Page_Table or the AMD equivalent not having in mind currently so it is much liekly to have it supported in KVM too over the long if it does not already exist and can only not be used by hardware lacking the cpu-features signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On Mon, Nov 12, 2012 at 4:46 PM, Rex Dieter rdie...@math.unl.edu wrote: See also, https://bugzilla.redhat.com/show_bug.cgi?id=875954 orionp and I were discussing on irc today, the idea to add -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo to %cmake by default in /etc/rpm/macros.cmake , while making it easy to set/override manually, similar to how %_cmake_lib_suffix64 is currently handled. the idea being that many cmake projects default to Release (or not, sometimes goofy things like Debug) The idea being that many projects default to CMAKE_BUILD_TYPE=Release and end up pulling in -O3 (and -DNDEBUG). There's 2 issues we'd like some wider input. What disadvantages or side- effects are there to: 1. setting a default CMAKE_BUILD_TYPE? 2. building with -DNDEBUG by default? I own several packages that use cmake and I've taken to setting the release type to RelWithDebugInfo like you suggest. One question I've had but never gotten around to asking is: Regardless of whether you use Release or RelWithDebugInfo, should we be building with -O3? It seems odd that the rpm macro defaults to doing something that is explicitly against the packaging guidelines. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 05:25 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote: But there was a non-UI way. Does that no longer work? The non-UI way was kickstart. But you can't deselect (-) mandatory packages in a group. @core is primarily made up of mandatory packages. Huh. I could swear I've done that before and it worked. In any case, it is _certainly_ working with appliance-creator right now. :) appliance-creator may not force @core. The force of @core is an anaconda thing. This actually opens up another axis, here, so we could have one standard for mandatory packages (kernel+init, or up-to-yum+net) and a second level for default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the distinction between mandatory and deselectable is huge for kickstart, which I think is common for _most_ of our use cases. Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
