Re: Ubuntu 10.10's installer looks rather nice
Matthias Clasen (mcla...@redhat.com) said: That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users. Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Chris Lumens (clum...@redhat.com) said: - downloads updates in parallel too Package updates? 1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that package selection is the final task in the current workflow, it would require reordering the workflow to be beneficial. (Which becomes a memory usage tradeoff.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
'milkymist' group in comps?
1) When you added this to F14/F15/EL6, you added a typo; this broke the F-14 branched compose and the EPEL updates push. *Please* verify your changes before pushing. 2) Aside from that... how does this merit a separate group? - We already have the electronic lab group - If we add a group each for developing for any embedded/custom board, we're going to run into group explosion really quickly Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'milkymist' group in comps?
Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: Milkymist community builds and enhance their own toolchain (currently not fully supported by Fedora). They have contributors who contribute for tools such as gcc, qemu, other libraries (too software for FEL goals). They have many patches that need to push to upstream. Milkymist founder and I believe that we can collaborate as the milkmist community is situated between FEL and Fedora, in terms of tools and upstream patch-push. It is a win-win situation for everyone. OK, that's clear. But I am worried that if we go down this road, we'll eventually have 20 or 30 groups for different SoCs for embedded use, and that seems like it will eventually be problematic. Is there some generic moniker that could be used for this usage? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
Ankur Sinha (sanjay.an...@gmail.com) said: Since the design team is using a design suite, would it be possible to please create a group in comps for the purpose? It would make installation of the design suite much easier for end users. The alternative is to create a meta package which isn't welcomed. This[1] is the tentative list of packages. [1]http://fedoraproject.org/wiki/Design_Suite_Planning#Included There appears to be a lot of overlap here with the graphics group (and some with other groups). Perhaps it's best to just expand that group into a more full-fledged design suite? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'milkymist' group in comps?
Chitlesh GOORAH (chitlesh.goo...@gmail.com) said: OK, that's clear. But I am worried that if we go down this road, we'll eventually have 20 or 30 groups for different SoCs for embedded use, and that seems like it will eventually be problematic. Is there some generic moniker that could be used for this usage? To be honest that would be a great idea. But I don't know any other active and vibrant community like milkymist and openmoko alike. I suggest that, let it be like this. If it gets momentum and other HW communities pop in, we can rename it, I won't object. Works for me. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'milkymist' group in comps?
James Laska (jla...@redhat.com) said: 1) When you added this to F14/F15/EL6, you added a typo; this broke the F-14 branched compose and the EPEL updates push. *Please* verify your changes before pushing. How did the compose break? The comps file in git failed to parse, such that the with-translations comps file could not be made. Is this something that the autoqa rats_sanity test [sh|c]ould have caught? No, this is well before the tree gets to that state. It would need to be implemented as a check on git push. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'milkymist' group in comps?
James Laska (jla...@redhat.com) said: No, this is well before the tree gets to that state. It would need to be implemented as a check on git push. We attempt to validate comps in this test using the comps.rng in git (see results logs posted earlier). I'm not tremendously familiar with that part of the test, but I believe it should catch that? You're validating it after the repo has already been made. In this case, it was broken such that the repo couldn't even be made. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
Nicu Buculei (nicu_fed...@nicubunu.ro) said: There appears to be a lot of overlap here with the graphics group (and some with other groups). Perhaps it's best to just expand that group into a more full-fledged design suite? They are different things: the graphics group is the sum of all packages about graphics, a design suite group would be a way for people to install the Design Suite Spin (a collection of best of breed apps) if they already have Fedora installed. Right, but I'm saying that the Design Suite group might be more appropriate in all cases. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Matthew Miller (mat...@mattdm.org) said: On Tue, Oct 12, 2010 at 07:06:50PM -0500, Chris Adams wrote: It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: Still the case in RHEL5, FWIW. I'm assuming you mean RHEL 6; it just seemed too big of a change to debut in RHEL at the time we branched. However, it has worked pretty well in Fedora so far to just rely on the carrier attribute in sysfs. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Matthew Miller (mat...@mattdm.org) said: On Wed, Oct 13, 2010 at 11:54:43AM -0400, Bill Nottingham wrote: It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: Still the case in RHEL5, FWIW. I'm assuming you mean RHEL 6; it just seemed too big of a change to debut in RHEL at the time we branched. However, it has worked pretty well in Fedora so far to just rely on the carrier attribute in sysfs. No, I mean in current RHEL5, ethtool is required by initscripts. Maybe that happened somewhere in one of the point releases? The change to drop the required ethtool use in initscripts was in F-13... it's not something that would be backported to RHEL 5 ever (and almost certainly won't be backported to RHEL 6.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
Nicu Buculei (nicu_fed...@nicubunu.ro) said: Do you mean getting rid of the Graphics group and creating a new Design Suite group? Is there a procedure for this? I mean like filing a ticket some place? I'm confused about the whole conversation. What exactly are you talking about Bill when you refer to creating a new comps group? When you run any other spin than the Design Suite the ability to run yum groupinstall design-suite and automatically get *all* the goodies provided by that spin. Right, it would be (for Fedora 15, *not* 14) renaming the graphics grop to the 'design suite' group, and adjusting the package list appropriately. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Peter Jones (pjo...@redhat.com) said: Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration. Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Cleaver, Japheth (jclea...@soe.sony.com) said: A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside? Given that it involves bind-mounting *files* in some cases (which imparts some truly odd semantics that confuse programs), it's not quite enough for generalizing to any use. It certainly can be made to work, though. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
experimental systemd + initscripts repo
I've set up a repo on r.fp.org: http://repos.fedorapeople.org/repos/notting/initscripts-systemd/ This repo includes updated initscripts and associated packages that test the conversion of various boot-time actions to systemd services. (Essentially, rc.sysinit is dead.) Before putting this in rawhide, we want to make sure it's not too horribly broken. Feedback welcome in bugzilla (against initscripts) or on the list. There may be additional changes pushed to the repo as more things are moved to native systemd services. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: experimental systemd + initscripts repo
Yanko Kaneti (yan...@declera.com) said: On Thu, 2010-10-21 at 10:43 -0400, Bill Nottingham wrote: I've set up a repo on r.fp.org: http://repos.fedorapeople.org/repos/notting/initscripts-systemd/ Didn't automount anything from fstab other than /, not even /home. Even when I logged in on the console with a user that has a home directory there. Manually starting the corresponding *.mount units worked. It's not supposed to do that through systemd mount units... yet. There's a separate service for that. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: experimental systemd + initscripts repo
Bill Nottingham (nott...@redhat.com) said: Yanko Kaneti (yan...@declera.com) said: On Thu, 2010-10-21 at 10:43 -0400, Bill Nottingham wrote: I've set up a repo on r.fp.org: http://repos.fedorapeople.org/repos/notting/initscripts-systemd/ Didn't automount anything from fstab other than /, not even /home. Even when I logged in on the console with a user that has a home directory there. Manually starting the corresponding *.mount units worked. It's not supposed to do that through systemd mount units... yet. There's a separate service for that. To elaborate more... what does 'systemctl status fedora-mountall.service' say? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: experimental systemd + initscripts repo
Yanko Kaneti (yan...@declera.com) said: Which seems to be caused by a missing /etc/crypttab I've never had this file apparently. # touch /etc/crypttab and the systems seem to boot as exected Fixed in git, thanks for the report. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
Peter Robinson (pbrobin...@gmail.com) said: Nokia managed to upgrade Qt to 4.7 in their Maemo distribution and it got pushed to all devices without causing any problems so far. Their standards for avoiding churn are pretty high and their update scheme is extremely conservative for stable releases. Nevertheless they updated Qt. But they have a pretty good reason for doing that (aligning with future versions of MeeGo and Symbian). So what does a F13 user gain from an upgrade? Is it worth the risks? QT isn't the default toolkit in Maemo and it was only introduced at all in the PR1.2 release which only came out around 3-4 months ago so its not a core part of their UI experience on maemo. So that's not really a good argument for upgrading it in F-13. Also, I'd assume that Maemo explictily ships/supports a much smaller set of software than Fedora, so they can explicitly list all their dependencies that may need fixed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: experimental systemd + initscripts repo
Lennart Poettering (mzerq...@0pointer.de) said: Fixed in git, thanks for the report. BTW: A nice way to make activation of services conditional based on existance of a file is the relatively new ConditionPathExists= setting in [Unit]. If the file listed there doesn't exist, then the unit will not actualy be started, however, it is still useful for all synchronization purposes, and hence not disrupt startup in any way. You can even specify more than one file in which case the unit will be run when at least one of those files exists. http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=12cabd751919122551b6eb73850b35fbe565c679 Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [libxml2] Release of libxml2-2.7.8
Peter Robinson (pbrobin...@gmail.com) said: 2010/11/5 Marcela Mašláňová mmasl...@redhat.com: On 11/04/2010 08:32 PM, Michael Schwendt wrote: On Thu, 4 Nov 2010 17:41:34 + (UTC), Daniel wrote: Release of libxml2-2.7.8 libxml2.spec | 10 -- Seems to break the koji build root due to ABI incompatibility. Dependent packages should be rebuild. There should have been a heads up for this. It affects 100s of packages. It's being fixed; no rebuilds needed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers
Jon Ciesla (limburg...@gmail.com) said: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis. If you're looking for comaintainers: Package NetworkManager-pptp comaintained by: dcbw Package apache-ivy comaintained by: orion Package astronomy-menus comaintained by: mmahut Package bam comaintained by: lkundrak Package centerim comaintained by: awjb Package cloudy comaintained by: mmahut Package collectd comaintained by: apevec fab Package cpl comaintained by: mmahut Package erlang-meck comaintained by: peter Package extrema comaintained by: mmahut Package fop comaintained by: sparks Package fusecompress comaintained by: lmacken comaintained by: akurtakov Package groovy comaintained by: madsa hannes Package http-parser comaintained by: mcepl Package isync comaintained by: s4504kr Package jfreechart comaintained by: jerboaa Package jgraphx comaintained by: davidcl Package justmoon comaintained by: mmahut Package kBuild comaintained by: laxathom Package kdeedu comaintained by: ltinkl rdieter kkofler jreznik Package libclaw comaintained by: xavierb Package libsamplerate comaintained by: jwrdegoede lkundrak Package links comaintained by: ovasik Package loudmouth comaintained by: tjikkun otaylor Package maatkit comaintained by: slankes Package mars-sim comaintained by: mmahut Package meld comaintained by: cwickert Package mon comaintained by: lucilanga Package orsa comaintained by: rakesh Package perl-CSS-Tiny comaintained by: mmaslano Package perl-Class-C3-XS comaintained by: mmaslano Package perl-Class-Factory-Util comaintained by: psabata mmaslano Package perl-Compress-Raw-Bzip2 comaintained by: mmaslano Package perl-Contextual-Return comaintained by: mmaslano Package perl-DateTime-Format-Builder comaintained by: psabata mmaslano Package perl-DateTime-Format-HTTP comaintained by: mmaslano Package perl-DateTime-Format-IBeat comaintained by: mmaslano Package perl-DateTime-Format-MySQL comaintained by: psabata mmaslano Package perl-Declare-Constraints-Simple comaintained by: mmaslano comaintained by: mmaslano Package perl-File-Slurp comaintained by: laxathom Package perl-JSON-XS comaintained by: psabata mmaslano Package perl-MRO-Compat comaintained by: ppisar psabata mmaslano Package perl-Module-Refresh comaintained by: laxathom Package perl-Moose comaintained by: mmaslano Package perl-String-Random comaintained by: steve Package perl-Test-LongString comaintained by: laxathom Package perl-aliased comaintained by: mmaslano Package perl-common-sense comaintained by: mmaslano Package printer-filters comaintained by: jpopelka Package ptouch-driver comaintained by: jpopelka Package pulseaudio comaintained by: lkundrak Package pure-ftpd comaintained by: jcapik ksyz Package qemu comaintained by: dwmw2 berrange Package rubygem-configuration comaintained by: stahnma Package rubygem-cucumber comaintained by: kanarip stahnma mmorsi Package rubygem-launchy comaintained by: mfojtik Package rubygem-polyglot comaintained by: kanarip stahnma vondruch Package rubygem-rubigen comaintained by: mmorsi Package rubygem-shotgun comaintained by: mfojtik stahnma Package rubygem-sinatra comaintained by: bkabrda mfojtik Package rubygem-test-spec comaintained by: stahnma Package s3cmd Package saoimage comaintained by: mmahut Package skychart comaintained by: mmahut Package starplot comaintained by: mmahut Package swarp comaintained by: mmahut Package system-config-keyboard comaintained by: twoerner itamarjp Package system-config-rootpassword comaintained by: rnovacek Package v8 comaintained by: tomspur Package xom comaintained by: dbhole Package xpp3 comaintained by: dbhole Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Questions about the new comps
Christoph Wickert (christoph.wick...@gmail.com) said:
In order to reduce the size of the F18 Xfce spin, I wanted to edit comps
- but decided to not do so until I fully understand what is going on. I
seem to have missed a lot since since last our discussion at Blacksburg,
so have a lot of questions.
Here we go:
1. How can a package maintainer define a default, but not mandatory
package? Example: The Xfce SIG decided to no longer install
xfce4-icon-theme by default. It just takes space and we don't
use it. Nevertheless we want to enable users to install it
easily. How would we do that? Define an extra group with only
xfce4-icon-theme and make it an option of the Xfce environment?
That's the simplest way, yes. Under what circumstances would you expect
that a user would want to install it? If it's something where they would
only ever install it if they already know what the package name is, having
it categorized via a group seems like overkill.
2. Even if I cannot do it in anacoda any longer, how would I do it
in PackageKit? How can I make something show up in a group there
without making it mandatory?
3. How do the new groups translate into PackageKit groups? Will all
options be listed in the side pane of gpk-applications? Will
they dynamically change? Will all packages of a group be
selected?
Tackling these together:
This is sort of a two-part question - what is the available data, and what
do the tools do with it?
= The data =
Right now, nearly all 'building block' groups (part of environments, or
add-ons to those environments) are marked with:
uservisiblefalse/uservisible
to prevent them showing up in the installer UI where they shouldn't. We
could add some code to change this, but this is how it's currently done.
We have the environment sections in comps that define the installation
choices, and the options to them.
We have the category section in comps as well, which is a little
less defined.
= The tools =
1. anaconda
anaconda uses the 'environment' sections to determine what to offer.
The left pane is populated with the list of environments. After selecting
one, the right pane is populated with:
- all add-ons for that environment
- any groups that both:
1. are marked uservisibletrue/uservisible
2. have default/mandatory packages
This is for compatibility for add-on/third-party repos - if you add on, say,
a Chromium repo that has a group there, it will show up as an option for
whatever you decide to install.
anaconda ignores optional packages, unless you pass --optional in a
kickstart file.
anaconda no longer uses the category section.
2. apper
apper organizes groups via the category section. It appears to show them
whether or not the group is marked as user-visible. You can individually
select packages in these groups, but do not appear to be able to (easily)
select the group to get its default offerings. apper does not specifically
denote a package's status (mandatory/default/optional) in the UI, AFAICT.
apper does not read environments.
3. yumex
yumex organizes groups via the category section. It also appears to show
them whether or not the group is marked as user-visible. You can
individually select packages in these groups, or select the group to get
its default offerings. yumex does not specifically denote a package's status
(mandatory/default/optional) in the UI, AFAICT.
yumex does not read environments.
yumex has a 'categories' option that appears to have nothing to do with
comps categories, as well.
4. gnome-packagekit
gpk-application offers groups via two mechanisms:
- An uncategorized list of groups ('package collections')
This shows all groups listed in the category sections, in a flat list
instead of a tree. While you can select a group in this interface to get
its default offerings, you can not individually select packages from them
(as far as I can easily tell.)
- A filtered list of groups
PackageKit has its own concept of featured groups that it lists as separate
items. This list is assembled from comps groups via a mapping in
PacakgeKit's yum backend. You can individuallly select packages in groups
offered in this manner, but you can not select a group to get its default
offerings.
I did not check synaptic - people using that, frankly, are beyond my
immediate concern, but I'll answer questions on the data if they have them.
...
So, taking this into account, I think the simplest fix that ensures a
semi-coherent interface in post-install package tools while we work towards
something better would be to edit the category definitions in the comps file
so that there are categories for each installation option that lists the
add-ons for that option.
This would have the benefit of giving easy access to the options presented
in the anaconda interface in a post-install environment without having to
modify the code in those tools, at the
Re: Questions about the new comps
Christoph Wickert (christoph.wick...@gmail.com) said: one more question: How can one install something that is neither an 'environment' nor a minimal install install? Say I want openbox as window manager, how would I do that? openbox is in the group 'window-managers', but that group is not shown in anaconda. I guess we need to creae a group for each and every window manager and then make these groups options of either 'window-managers' or 'basic-x-windows' (the latter is shown in anaconda). If you really want every window manager to be an installation option for network installs, yes, you'd create groups and make them options of the basic-x-windows environment. Go nuts - Jens has already done so for xmonad. Note that in this scenario you either add the appropriate ancillary bits (display manager, firstboot, any additional applets, what have you) either into your window-manager option, or in another group that users would have to select as well. It's not really the target audience of the anaconda installation at the moment - the idea is to provide a meaningful list of vetted and tested installation options. (It's why they mirror the spins + a couple of server options). Supporting an X by Y by Z matrix of window managers, display managers, and input methods/font groups/pick-your-poison doesn't fit into that. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Miloslav Trmač (m...@volny.cz) said: is any current data available about how our minimal footprint got worse/better over time in both terms of packages and disk space, and which packages are to blame for it? If the libmicrohttpd dep really is problematic I am happy to split it off, but I'd really like some hard data first whether doing this would help more than a trivial bit to achieve a smaller minimal installation set. One more network-listening service, let alone an unauthenticated one, is way more than a trivial bit IMHO. Well, it *is* off by default. Checking the minimal install of the moment: Install 38 Packages (+160 Dependent packages) Total download size: 129 M Installed size: 505 M In that minimal install, the following disabled services exist: NetworkManager-wait-online.service autovt@.service console-getty.service console-shell.service debug-shell.service dnsmasq.service ip6tables.service iptables.service rdisc.service saslauthd.service wpa_supplicant.service systemd-journal-gatewayd.socket The follwing 'traditional' services are enabled: auditd.service sshd.service sm-client.service sendmail.service NetworkManager.service crond.service rsyslog.service Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Seth Vidal (skvi...@fedoraproject.org) said: Maybe the definition of the fedora base set needs a bit of updating, given that it considers rdisc, saslauthd, audit, dnsmasq, syslog, wpa supplicant and sendmail basic. For container setups I need nothing of that... (heck! for my non-containerized server I don't need that either...) For minimal installs you also need a tool that can do automatic installation of dependencies. Otherwise the first thing every admin who installs minimal will have to do is to fetch down yum, python, etc to get themselves rolling. Maybe in the eventual future dnf, libzypp etc will be fetched down - but in either case minimal requires such a tool as part of it. To describe them all: - wpa dnsmasq are brought in by NM - rdisc is in the iputils package (basic networking) - saslauthd is brought in by our lovely default MTA - audit, sendmail, rsyslog are explicit. (The latter two being explicit help with depsolving fun, as we do want consistency there, rather than getting whatever MTA log daemon the depsolver spits out.) rsylog would get pulled in by deps anyway; sendmail audit wouldn't. We can certainly have a smaller image base that consists of something like: - systemd - util-linux - bash - passwd - initscripts But, as Seth said, unless you want to preclue people modifiying it from inside the chroot/image/installation by *not* including package management tools, it grows pretty quickly. (Also, it's not that much smaller now, due to things pulling in python, but bugs have been filed.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Lennart Poettering (mzerq...@0pointer.de) said: From the list of packages this minimal set still installs, that I'd really like to see gone: chkconfig Mostly obsolete requirements not removed in systemd migration; probably could stand to have some bugs filed. gamin glib2. info Already covered. systemd-sysv iptables... bug already filed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Toshio Kuratomi (a.bad...@gmail.com) said: in the past, anaconda's language settings were more about default localization, not about what locales should be installed. The package selection interface had separate packages for supporting some languages. So somewhere close to that screen might be more appropriate. rpm and yum should work with that setting.. I used to run with _install_langs set to three or less languages back in the early Fedora Core days. One issue is that there's not really a way for the sysadmin to change this on the fly. ie: if anaconda installs with only one locale, the only way to then get the other locales is to change _install_langs and then reinstall the packages. Also: -rw-r--r--1 rootroot104783632 Sep 21 15:00 -/usr/lib/locale/locale-archive.tmpl It's not as if _install_langs helps with that. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
Konstantin Ryabitsev (i...@fedoraproject.org) said: Not sure I can parse this, but IIUC you are wondering whether logwatch is compatible with the journal. Not to my knowledge, no. But adding this should be fairly easy as the output of journalctl is a pixel-perfect copy of the original format, so where it works on /var/log/messages it should simply work on the output of journalctl and all should be good. Note however that with the capabilities of the journal it might be interesting to add journal support to logwatch that goes beyond mere compatibility. For example, tests such as look for messages which are claimed to come from PID xyz but actually came from uvw and suchlike would be really interesting to have. That information is not available in the /var/log/messages format however... So, in other words, all our existing log analysis tools have to be modified if they are to be of any use in Fedora 18? Right, you'll have to port them to understand CEE from updated rsyslog. HTH, HAND. - note: THIS IS A JOKE. MORE SERIOUSLY There are a lot of usage cases that people want from their logging. 1) Administrators want their plain-text logs that they know and love (or at least know and have gotten accustomed to) that they can use their normal unix tools and their homegrown custom shell/awk/perl/python/whatever scripts for parsing. (For the purposes of this discussion, consider logwatch one of those homegrown things, as it basically is that writ large.) 2) System management authors would love to have a mechanism where they can subscribe to particular alerts as they come in, without having to subscribe to all messages, or try and parse the unstructured text of syslog 3) Application developers might want to be able to express stuff they log in a more structured fashion rather than just: (function:line) bad juju happened here in frobnitz 4) Administrators want to be able to do things like 'show me everything sshd did/logged about', or 'show me what happened last Thursday, because I can never get the hang of them.' 5) Standards People want to have messages in the new CEE format, so they can use their new CEE tools on them and merge some of their homegrown tools. 6) Meanwhile, you've got the poor audit logger over there on the side doing its own thing, and there are users who Really Like those audit logs. And we've got a lot of technology going around. journald - that's technology. rsyslog - that's technology. libumberlog ceelog - that's technology. What we've got to do is take the usage cases we have, and the technology we have, and get a coherent solution that covers them. And it's certainly not clear at this point what that solution would be. If people want CEE format logs, or plain text logs, maybe journald should grow those as output formats. Or maybe rsyslog should produce those formats. Maybe rsyslog should grow a journald plugin, so instead of duplicating some of journald's code for associating entries with pid/exec/etc., it can read the already annotated journal stream and add its own metadata spit out whatever formats it wants. (Maybe it already does this!) Maybe rsyslog or journald should take over audit logging in some way. But the point is, there's a lot of work in this space going on on all sides (take ceelog, liumberlog, and journald - all relatively new bits of technology touching portions of this space). And at this point I'd say it's way too early to say that Fedora Shall Be XYZ, or to conversly say that Fedora Shall Not Be XYZ. A full plan for hitting all the usage cases we might want just isn't known. (Although it would be a lot easier to get there if y'all would stop shouting AT PAST each other.) So no, you don't need to change anything for Fedora 18. rsyslog is there by default, journald is there too if you want to look at that. And until we actually have a Plan, rather than just Technology, I'm not sure why you'd say that Fedora will do XYZ in F-19 either. Well, you can probably say that Fedora 19 won't ship with sysklogd by default; that should be safe. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Jesse Keating (jkeat...@j2solutions.net) said: Well, we do currently have the minimal environment, which boils down to @core + the couple things anaconda forces (authconfig, system-config-firewall-base, kernel, bootloader). You can get to that via kickstart with just: %packages @core %end But it's not close to what some of these people want out of a minimal install. For reference: @core + kernel: Install 38 Packages (+157 Dependent packages) Total download size: 128 M Installed size: 506 M But hey, I just want something smaller! systemd + util-linux + bash + initscripts + passwd + yum: Install 7 Packages (+132 Dependent packages) Total download size: 106 M Installed size: 446 M But hey, I don't need to install packages or want python! systemd+ util-linux + bash + initscripts + passwd: Install 6 Packages (+108 Dependent packages) Total download size: 94 M Installed size: 401 M Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Matthew Miller (mat...@fedoraproject.org) said: On Mon, Oct 15, 2012 at 02:19:03PM -0400, Bill Nottingham wrote: But hey, I don't need to install packages or want python! systemd+ util-linux + bash + initscripts + passwd: Install 6 Packages (+108 Dependent packages) Total download size: 94 M Installed size: 401 M Of which one quarter is the kernel and the other quarter is glibc locale support, right? Or more: 122659574 kernel 117821428 glibc-common 35623360linux-firmware 14233540coreutils 13845828glibc ... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Kevin Fenzi (ke...@scrye.com) said: 122659574 kernel 117821428 glibc-common 35623360linux-firmware 14233540coreutils 13845828glibc I wonder... could we make linux-firmware optional? I would expect many virt env's don't need any firmware to work... (but of course I could be wrong). It depends. It includes firmware for wired NICs as well as other things, so it depends on what hardware your virtual environment is deciding to emulate. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Peter Robinson (pbrobin...@gmail.com) said: I wonder... could we make linux-firmware optional? I would expect many virt env's don't need any firmware to work... (but of course I could be wrong). It use to be optional, I know on the olpc xo-1 it use to be optional and there should be no firmware needed for an average VM. I'd also love to see it broken down for various profiles because most desktops don't need enterprise storage controllers, most servers don't need wifi and most ARM platforms don't need most of the stuff in there but do need a few ARM only firmware packages. However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. (Unless you're relying on packagekit to install your firmware, which if you're going that minimal seems to have missed the forest for the trees somewhere.) I wouldn't be against that, but I also don't have the time to look at that right now. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Josh Boyer (jwbo...@gmail.com) said: However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. (Unless you're relying on packagekit to install your firmware, which if you're going that minimal seems to have missed the forest for the trees somewhere.) I'm not understanding what you're proposing. Are you suggesting: 1) We have further split up module sub-packages that carry their own firmware requires (e.g. kernel-module-iwlwifi requires iwlwifi-firmware) or 2) Even more firmware subpackages split out of linux-firmware. If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. If you're suggesting 2, I don't see the point. The kernel will install and even with per-module dependencies generated (somehow), it'll still install all of the various -firmware packages because the modules will be getting installed. Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver - firmware package dependency mapping. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Lennart Poettering (mzerq...@0pointer.de) said: To end this bit of the discussion too, I have now added a README that is installed to /var/log/README and one that ends up in /etc/rc.d/init.d/README, and should help the user to find the new tool set. Should hit F18 soon. Given we default to rsyslog in F18, please don't put a /var/log/README there - that would just confuse things. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Josh Boyer (jwbo...@gmail.com) said: You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. That also works with the normal paradigm where all the variants provide 'kernel' for RPM dependency purposes; if you try to have a kernel-minimal that provides 'kernel' while also having a 'kernel' package that requires 'kernel-minimal', things get a bit more strange. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
Adam Tkac (at...@redhat.com) said: I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19. All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers. If there are no objections against this approach, I will start with this task next week. Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
Adam Tkac (at...@redhat.com) said: On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote: Adam Tkac (at...@redhat.com) said: I've just created https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page which contains plan how to successfully move from current jpeg6 API/ABI to more recent jpeg8 API/ABI for Fedora 19. All packages which depends on libjpeg.so will have to be rebuilt. Since I have provenpackager privileges, I will cook some script which will rebuild all pkgs automatically so no action will be required from maintainers. If there are no objections against this approach, I will start with this task next week. Ouch. I can see a need for a compat library for some period of time here - the jpeg6 API has certainly been around for quite a long while. Hm, you are probably right. Since libjpeg is widely used, there might be some proprietary apps which require it. In my opinion we can just ship compat libjpeg.so.* without development files for some time. Or do we need devel files as well? Just the .so should be fine. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps for Fedora Security Lab
Fabian Affolter (f...@fedoraproject.org) said: The Fedora Security Lab is an official spin since Fedora 13. So far all packages are handled direct in the kickstart file which is not very handy if you want to install the packages from a running Fedora installation. I would like to include the Security Lab tools into comps for F19. This way the FSL can stand shoulder-to-shoulder with the Fedora Electronic Lab, the Robotics Spin, and others. What are you envisioning? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
Adam Williamson (awill...@redhat.com) said: Well, I don't mind doing that, but I'd like to be sure there's a broad consensus that this is the way to go first. I don't think 'duelling drafts' is the best way to decide on what direction to go; I'd rather make sure we agree on the direction first, and use the drafting process simply to refine how we express that direction. It causes problems for people who build things outside of chroots with straight rpmbuild, though, if they need to ever build different things with different buildreqs (even as test builds). Admittedly, we like to encourage people to use mock, but people will still hit this. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: change of names of configuration files
Adam Williamson (awill...@redhat.com) said: anaconda has been writing to vconsole.conf for some time now - at least Oct 4th: commit 4b98eab34f310c2704ec24b417bdf919c413fa1d Author: Vratislav Podzimek vpodz...@redhat.com Date: Thu Oct 4 12:37:24 2012 +0200 Work with VConsole keymap and X layouts separately ... Resolves: rhbz#853877 Resolves: rhbz#856362 Resolves: rhbz#859867 In fact we've always had problems with X and console keymaps; there's a longstanding bug about the encrypted partition case: https://bugzilla.redhat.com/show_bug.cgi?id=743281 It's a rather complex area. I don't have a 100% grasp on it, but I _think_ F18 actually behaves rather _better_ than previous releases at this point. I think Marcela's mail is slightly misleading. The 'new' locations for these files have existed and systemd has been using them for some time. The commit Marcela linked provided RPM scripts that automatically migrate to the new locations; it doesn't actually introduce the new locations. Right. Since F16 when systemd took over the basic startup of the system, it's had to set things like: - keymap - font - locale - hostname etc. It's always had the policy where it reads a heirarchy of locations for these settings: 1. the kernel commandline 2. a cross-distro default location 3. a distro specific location (for example, /etc/sysconfig/i18n on Fedora-alike, /etc/sysconfig/language on SuSe, /etc/rc.conf on Arch... it's a large pile of #ifdefs, and it's why there is a cross-distro default location suggested) In each case, the later location overrides the former. (Except for hostname ... I'll go file that one.) Options would be: 1. ignore the cross-distro locations, never use them, patch them out where they occur 2. ignore the distro-specific locations, never use them, patch them out where they occur (hooray, flag day!) 3. Accept both. Deal with confusion if people have both files present. 4. Attempt to patch everything to only support one variant, but allow for the other where available. Fedora's done #3, and has done so since F-16. We get the occasional bug from this, usually when someone's used one tool that writes a config to one file location, and another that assumes another. That's not a good long term solution, so discussion was to take what format anaconda is writing for new installs, and convert old installs to that format, so that upgraded systems match (all the while while the old location still works for those that modify their configs by hand, or with old tools.) Of course, in checking the code, anaconda for the moment is writing *both* files with identical data. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Björn Persson (bjorn@rombobjörn.se) said: Emmanuel Seyman wrote: From bug #871503 (and I apologize if I'm reading this wrong), it appears that the dependency on /bin/perl is being caused by the hardcoded $PATH in openssh. To fix the problem, I think we would not only need to provide /bin/perl but a /bin equivalent to everything in /usr/bin (/bin/perl is the only usecase which Harald has hit so far). That still wouldn't solve all cases. I've seen code that does the equivalent of which some-program, finds /bin/some-program, concludes that the installation prefix is /, and proceeds to look for files in /share, which doesn't exist and never has. We really need to get /bin and /sbin removed from PATH, or at least moved behind /usr/bin and /usr/sbin. Björn Persson -- 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: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Michał Piotrowski (mkkp...@gmail.com) said: Do current anaconda problems will have an impact on preupgrade? preupgrade is not the current supported upgrade tool to upgrade to Fedora 18. So the simple answer to your question is 'yes', although not exactly for the reasons you expect. https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
Colin Walters (walt...@verbum.org) said: On Fri, 2012-11-02 at 16:04 -0400, Adam Jackson wrote: It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. Or just apply the patch from here: http://lists.fedoraproject.org/pipermail/devel/2012-April/165871.html And skip tons of pain for all the libffi consumers at the tiny cost of a stub symbol. Hm, no links to the patch in the archives. Well, I'll attach it again, since I still have it sitting around in my libffi git checkout. And note that whatever you do, F-19 is open for doing it now - you don't need to wait until F-18 ships... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote: long story short, it's firewalld. Its deps are pretty heavy for something that's supposed to be in minimal. I'm sure twoerner would welcome help in pruning the deps if it's possible. it should at least be possible for it not to depend on both pygobject2 and pygobject3, one would think :) Maybe we could have a release criterion which states that the minimal install doesn't have anything which pulls in the X libraries (or Wayland)? That's not a _completely_ arbitrary line in the sand. Probably the issue here is just a matter of what goes in what subpackage. Nod, this is more due to how pygobject3 is packaged rather than firewalld itself. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
Adam Williamson (awill...@redhat.com) said: In case anyone noticed minimal install got rather bigger between Alpha and Beta - I did too. And I finally got around to figuring out why and filing a bug: https://bugzilla.redhat.com/show_bug.cgi?id=874378 long story short, it's firewalld. Its deps are pretty heavy for something that's supposed to be in minimal. I'm sure twoerner would welcome help in pruning the deps if it's possible. it should at least be possible for it not to depend on both pygobject2 and pygobject3, one would think :) FYI, re: firewalld minimal install. firewalld isn't in the minimal comps groups. However, it's pulled in by anaconda, see pyanaconda/install.py: # anaconda requires storage packages in order to make sure the target # system is bootable and configurable, and some other packages in order # to finish setting up the system. packages = storage.packages + [authconfig, firewalld] Bill -- 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
Matthew Garrett (mj...@srcf.ucam.org) said: Patches that cleanly decouple Anaconda from the entire software stack that it runs on top of would probably be received with open arms, but nobody who works on it has any idea how to implement them. In fact, this is what has been done in anaconda over the past couple of releases - Anaconda migrated from having its own boot and init infrastructure to using system-provided items such as dracut and systemd. But that's complicated work, and while you're doing that migration, you're doing a lot of arbitration as to what bits are in generic dracut, what bits are in generic systemd, and what bits remain in anaconda. And during that process, you are *very* tied to the version of the underlying system, until the work is fully complete and there is a defined separation of features into each layer. This, incidentally, also is why running the F17 installer on F19 isn't practical. Bill -- 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
Dan Horák (d...@danny.cz) said: 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? I would love it if someone showed love to things like the web-server group, or similar things. Historically... people don't seem to care too much. (See the sad, sad, web-development group in F17 and earlier.) A lot of it likely is that server users don't use the groups, and just do the packages by hand. To fix that, we'd need to set up something better that actually helps them (canned configs, integration, etc.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention, dependency fighters
Jóhann B. Guðmundsson (johan...@gmail.com) said: The storage packages are going to be needed for the system to boot. Anaconda could probably add some smarts to remove authconfig if it wasn't pulled in by anything in the selected comps, but I'm not sure it'd be worth the special logic -- we might as well just put it in @core (even though it's not super-tiny). Firwealld I don't know about, though. If anaconda sets up the firewall using firewalld but then doesn't install it, will the old iptables scripts load the configuration? It'd be nice if it could, because firewalld is *another* big change that it'd be nice to have a reasonable back-out plan for. The point here is that both authconfig and firewalld are used by anaconda to configure the installed system, via either the old code (pre-F18) or the kickstart code (older releases, and F18+). anaconda would need to grow more complicated checks to ensure that certain things weren't set in the install before laying them down. You might want to remove plymouth from the minimal install since it does not make sense having it there anyway You filed a bug about that, actually... I'll respond here and paste there. plymouth was added to the minimal install as a consistent method for handling encrypted passphrases and boot-time logs at the time. Since this has moved out into other components since then, it can be reconsidered. There's something to be said for having a consistent boot-time interface though, rather than one that changes whether or not plymouth is installed. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote: That's not correct. You can modify the firewall just fine without restarting it. This is related to system-config-firewall/lokkit. You are right, if you are using iptables directly then you do not have this limitation. firewalld is a replacement for s-c-fw/lokkit. This is not what it says in the feature page at https://fedoraproject.org/wiki/Features/firewalld-default#Detailed_Description That says: The services iptables, iptables-ipv6 and ebtables will be replaced by firewalld. system-config-firewall in it's [sic] current form will also be replaced. Replaced in the default configuration - you obviously shouldn't be running firewalld and the static firewall scripts at the same time, so enabling them in combination would be a bad idea. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Miloslav Trmač (m...@volny.cz) said: A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in Hm, I don't like that much. Having two completely separate authorization code paths in many software components makes it very likely that the less frequently used code path will be buggy at least in some components. Applications are already supposed to be able to cope with polkitd not being present; it's not really an authorization code path as much as it is just good defensive coding. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Steve Grubb (sgr...@redhat.com) said: So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: 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. So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager - Connect to remote systems curl openssh-clients - Allow remote systems to connect to us openssh-server - Store forward logs audit rsyslog - Install other software rpm yum - SELinux policycoreutils selinux-policy-targeted - Add/remove/configure local users, and allow them to admin if necessary passwd shadow-utils sudo - Minimal tools for admins less man-db procps-ng vim-minimal - Scheduled tasks cronie - Get mail off the box (and define a default for doing so) sendmail - Support a local console kbd ncurses - Configure additional partitions for the simple case e2fsprogs parted - Probably legacy and can be dropped from explicit listing iprutils ppc64-utils Bill -- 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!
Kevin Kofler (kevin.kof...@chello.at) said: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Not to let silly things like facts get in the way of a good rant, but the images went over size because MATE texlive are now getting pulled in via deps when they weren't before, not because of incremental minidebuginfo changes. Carry on... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). Seems like a possible candidate to have default but not mandatory in core. Nothing pulls it in. It's in standard, not core. - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. Automatically added by anaconda when the system has LVM. If we want to rely on anaconda to add the filesystem tools for whatever FS you install, we could drop e2fsprogs. But we'd still want parted. (And I think leaving e2fsprogs in the minimal install likely makes sense anyway.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
Richard Hughes (hughsi...@gmail.com) said: In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. If you're using the yum backend, it already has support for this via a plugin. (Haven't tested it recently, but it's been there for a few releases.) snapper's just a wrapper around the other commandline tools, right? We do have 'system-storage-manager' now; see the 'ssm snapshot' command it provides. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Nov 14, 2012 at 10:03:36PM -0800, Adam Williamson wrote: Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. I think Bill Nottingham mentioned something similar too, although I don't want to put words into his mouth. What I had suggested at one point was we have an 'image-base' group that is *really* tiny, that is intended to be used as a basis for creating images, chroot, and other things where you're not necessarily doing package management *on the running system*. So it would be: kernel systemd initscripts util-linux bash and their dependencies. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. That would be weird. But fortunately, it's @core, not @minimal. So we could easily have @minimal, @core, and @standard, each with different targets. @core is what's shown as the minimal install in anacona. We could do some renaming, but having @minimal, and having it *not* be the minimal install in anaconda, sounds like a really bad idea. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. Well, anaconda could change such that the interactive person explicitly specifies @core in kickstart, and we could then change anaconda's default to not always include it. Would require very large release notes, though. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta Go/No-Go Meeting, Thursday, November 22 @ 20:00 UTC (3pm Eastern, 12pm Pacific)
Kaleb Keithley (kkeit...@redhat.com) said: Friday is a normal work day for most people (although some people will take it off to get a longer weekend :)) You know it's a Red Hat paid holiday, right? Sure, but even among those who may have the day off, I suspect they're more likely be able to make a short meeting on Friday than Thursday. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo meeting (2012-12-05)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #896 Refine Feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896 #topic #960 F18 schedule + the holidays .fesco 960 https://fedorahosted.org/fesco/ticket/960 = New business = - none - = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
=== #fedora-meeting: FESCO (2012-12-05) === Meeting started by notting at 18:07:27 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-12-05/fesco.2012-12-05-18.07.log.html . Meeting summary --- * 896 - Refine Feature Process (notting, 18:07:50) * AGREED: Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) (notting, 18:34:51) * AGREED: FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) (notting, 18:46:03) * AGREED: mitr (and others) will continue to discuss specific improvements (notting, 18:49:18) * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Allow deferment of fedup gui until F19 (+:8, -:0, 0:0) (notting, 19:05:56) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) * AGREED: (960) Final change deadline moved from 12/18 to 12/11. Release date remains 01/08. (+:6, -:3 0:0) (notting, 19:50:11) * 940 - The /tmp-on-tmpfs feature should be disabled by default (notting, 19:51:03) * AGREED: #940 (The tmp-on-tmpfs feature should be disabled by default) does not pass. (+:4, -:4, 0:1) (notting, 20:06:37) * Open Floor (notting, 20:07:42) * Elections going on now - please vote. (notting, 20:07:52) * Next week's chair is jwb (notting, 20:08:09) Meeting ended at 20:11:34 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * notting (106) * jreznik (94) * nirik (84) * mjg59 (75) * jwb (70) * pjones (66) * t8m (62) * mitr (48) * adamw (32) * tflink (23) * mmaslano (20) * limburgher (20) * rbergeron (11) * zodbot (9) * Viking-Ice (3) * mattdm (3) * BobJensen (1) * cwickert (1) * gholms (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Matthew Miller (mat...@fedoraproject.org) said: Three things: 1) Fedora is big enough that we have concrete situations where one size doesn't fit all. Puppet being broken on F17 (and probably F18 as well) is a fine example of something within the distro itself. And, as a platform for development, offering more version choices to our users would be a strength. heretical Well, then maybe Fedora's too big, and we should move to a model where Fedora is much smaller, and the grand Fedora universe contains things that are packaged *for* one or multiple Fedoras. /heretical Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Marcela Mašláňová (mmasl...@redhat.com) said: You're using a Mac now, so good luck. But I'm pretty sure that software collections would not have helped you to upgrade Libreoffice. Which, by the way, is possible without upgrading everything: just compile the later SRPMs. In other words, create your own backports repository, and find a group of people who have the same problem to share the security and maintenance burden around. Rich. In that case he might use gentoo ;-) On the other hand create a collection for LibreOffice and support it would be a lot of work. I would suspect, actually, that upgrading to a later LibreOffice is fairly simple on a 'stable' release, if it was built for that release. The problem comes when the only newer LibreOffice is built for the next Fedora release, so it's linked against newer libicu/boost/clucene/etc/etc that's only available in that later Fedora release, even though it doesn't specifically *require* those newer library versions. Of course, just doing an update for an older release breaks those who want the older release to maintain stability at all costs. So the LibreOffice case could be fixed by merely defining what's inside the always-stable set vs. what's outside it and can be updated more frequently (and convincing the maintainer to do so with LibreOffice.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
Nicolas Mailhot (nicolas.mail...@laposte.net) said: If you really want to support console keyboard layouts in systemd, you need to start generating console layouts from xkb-config, not adopt the old anaconda mapping bandaid There's already a bug for this, but the runtime perl dependencies it introduced were deemed too much, as I recall. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering (mzerq...@0pointer.de) said:
it is simply wrong to place internal binaries in %{_libdir}. internal
binaries should not be subject to multlib'ed dirs, the same way as
binaries in bin/ are not...
I would note I have seen cases where helper binaries actually needed to be
arch-specific and in $prefix/$libdir. I think it was bonobo?
In any case, I agree - my proposal was that packages that use
non-multilibbed helper binaries should be free to put them in *one of*
$prefix/lib or $prefix/libexec, as long as they remain consistent.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20121226 changes
Bruno Wolff III (br...@wolff.to) said: On Wed, Jan 02, 2013 at 12:08:31 +0100, Vít Ondruch vondr...@redhat.com wrote: Hm, wondering why there are not automatically filled bugs about broken dependencies. Wouldn't it be easier for tracking such issues? The owners get warning messages every compose. That helps with notification. Right, sending mail from a script requires no credentials. Filing bugs requires credentials embedded/pulled by the script. While we could do so, we haven't done that work yet. (Also, having duplicate/continued warning in e-mails for long-standing issues is lower overhead than if duplicate bugs start getting filed.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Adam Williamson (awill...@redhat.com) said: In addition to those bugs, we have fairly significant regressions in the completeness of anaconda translations between Fedora 16 and Fedora 18 (the numbers for F17 for some languages are weird - a lot of languages show 55% completion for F17 but 90-100% for F16, which seems bogus, as I'm sure things didn't change that much between F16 and F17, so I'm just using the F16 numbers. I assume there's some weirdness that explains the odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): Language F16 F18 Finnish 93% 75% Indonesian100%33% Kannada 94% 33% Oriya 94% 27% Telugu94% 32% Bengali (India) 93% 33% Portuguese100%36% Persian 95% 27% Malayalam 78% 20% NorwegianBokmal 92% 55% Bengali 93% 33% Sinhala 93% 27% Serbian 81% 23% Serbian(Latin)81% 23% Hebrew83% 22% Catalan 68% (98% F17) 25% Latvian 88% 20% Greek 68% 21% Turkish 79% 21% Maithili 67% 18% Asturian 85% 24% (from https://fedora.transifex.com/projects/p/anaconda/ ) When we approved the anaconda bits in FESCo, full translation was marked as an item that was scheduled for F19. We can go back on that now, but the knowledge that things were not fully translated (and weren't going to be) was something that was known at the time. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
Seth Vidal (skvi...@fedoraproject.org) said: One of the big questions to answer is distribution. I can see good arguments on the one hand distributing formulas via RPM and on the other having an official Git repository for them. Yep. I am torn here too. rpms get us a lot, but are also inflexable in other ways. :) Let me make an argument against rpms here. Ansible doesn't require anything on the local system to run a playbook. That's one of its virtues. For a user if we just use a git repo then the user doesn't have to modify their system in order to use the tools to change their system. There is a certain amount of elegance in that not to mention just not being annoying. Well, if we're allowing this to be for end-users as opposed to just managed infrastructure, it would require *something* to be on the local end-user's system, depending on how the playbook is written. (For example, if it uses the 'command' or 'shell' features) That can be mitigated by having requirements on the playbooks that we accept into this repository, of course. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Lennart Poettering (mzerq...@0pointer.de) said: On Thu, 10.01.13 09:55, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. pinfo is the (IMHO) best console info page reader, and until we stop having man pages that say see the info page for real documentation and/or packages that only ship info pages, pinfo should stay (and should be at the same default install level as man). My mail wasn't really about the specifics what to remove but how to get themn removed. But I'll bite anyway: we hardly need two info readers installed by default, do we? Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Lennart Poettering (mzerq...@0pointer.de) said: Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. How shall I proceed with this? file a feature for fesco? file a bug? A bug should be fine, although I was going to start poking at a patch later today now that it's been brought up. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Seth Vidal (skvi...@fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... In any case, attached is the initial diff I have. Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... bind-utils in core? mailcap can probably be dropped and only brought in via requirements, unless people know of lots of users of it that don't require it. bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. iptstate is left in for now. Perhaps this should move to firewalld? Much like pinfo/info, there is mtr and traceroute. As a philosophy, should we by default be including 'better' versions of ancient unix tools instead of the standard ones? We should probably split off network auth, network filesystem tools, and smart card auth, into their own separate groups. btrfs-progs is dropped from @standard, but will get added to @core if/when it becomes the default FS. (Anaconda will still add it if you use it.) numactl... I'd wait until autonuma lands upstream, but we could potentially remove it. prelink. Ugh. smartmontools... could be dropped, if people don't use it much. All it does out of the box is e-mail root (and throw messages at the tty.) setuptool should probably be cleaned up or removed. Bill diff --git a/comps-f19.xml.in b/comps-f19.xml.in index 4be1207..1953f85 100644 --- a/comps-f19.xml.in +++ b/comps-f19.xml.in @@ -1195,52 +1195,35 @@ packagereqat/packagereq packagereqattr/packagereq packagereqauthconfig/packagereq - packagereqbc/packagereq packagereqbind-utils/packagereq packagereqbzip2/packagereq packagereqcpio/packagereq packagereqcrontabs/packagereq - packagereqcyrus-sasl-plain/packagereq - packagereqdbus/packagereq - packagereqed/packagereq packagereqfile/packagereq packagereqfirewalld/packagereq - packagereqlogrotate/packagereq packagereqlsof/packagereq packagereqmailcap/packagereq - packagereqntsysv/packagereq packagereqpciutils/packagereq packagereqpsacct/packagereq packagereqquota/packagereq - packagereqtmpwatch/packagereq packagereqtraceroute/packagereq packagereq type=conditional requires=system-config-datechrony/packagereq packagereqbash-completion/packagereq packagereqbridge-utils/packagereq - packagereqbtrfs-progs/packagereq packagereqcifs-utils/packagereq - packagereqcoolkey/packagereq packagereqcryptsetup/packagereq - packagereqdmraid/packagereq packagereqdos2unix/packagereq packagereqdosfstools/packagereq - packagereqdump/packagereq packagereqethtool/packagereq packagereqfedora-release-notes/packagereq - packagereqfinger/packagereq - packagereqfprintd-pam/packagereq - packagereqftp/packagereq packagereqgnupg2/packagereq packagereqhunspell/packagereq packagereqiptstate/packagereq - packagereqirda-utils/packagereq packagereqirqbalance/packagereq packagereqjwhois/packagereq packagereqkrb5-workstation/packagereq - packagereqlftp/packagereq packagereqman-pages/packagereq packagereqmcelog/packagereq - packagereqmdadm/packagereq packagereqmicrocode_ctl/packagereq packagereqmlocate/packagereq packagereqmtr/packagereq @@ -1253,42 +1236,26 @@ packagereqnumactl/packagereq packagereqPackageKit-yum-plugin/packagereq packagereqpam_krb5/packagereq - packagereqpam_pkcs11/packagereq - packagereqpasswdqc/packagereq - packagereqpcmciautils/packagereq packagereqpinfo/packagereq packagereqplymouth/packagereq - packagereqpm-utils/packagereq packagereqprelink/packagereq - packagereqrdate/packagereq - packagereqrdist/packagereq packagereqrealmd/packagereq packagereqrng-tools/packagereq - packagereqrsh/packagereq packagereqrsync/packagereq packagereqsendmail/packagereq packagereqsetuptool/packagereq packagereqsmartmontools/packagereq packagereqsos/packagereq packagereqsssd/packagereq - packagereqstunnel/packagereq packagereqsudo/packagereq packagereqsymlinks/packagereq - packagereqtalk/packagereq packagereqtar/packagereq packagereqtcpdump/packagereq packagereqtcp_wrappers/packagereq - packagereqtelnet/packagereq - packagereqtime/packagereq - packagereqtree/packagereq packagerequnzip/packagereq packagerequsbutils/packagereq - packagereqvconfig/packagereq - packagereqwget/packagereq packagereqwhich/packagereq - packagereqwireless-tools/packagereq packagereqwords/packagereq -
Re: comps' standard group spring cleaning?
Tomasz Torcz (to...@pipebreaker.pl) said: On Thu, Jan 10, 2013 at 03:08:21PM -0500, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. Your patch (https://lwn.net/Articles/289040/ ) should rectify this. Wasn't the patch merged? No, upstream maintainers would rather people use netlink. (Unless something has changed since then.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Chris Adams (cmad...@hiwaay.net) said: Once upon a time, Bill Nottingham nott...@redhat.com said: Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... Okay, that's a starting point. However, what is the reasoning behind this? There are a number of things in your list of removed things that are still quite useful and not redundant. Before this really goes anywhere, what is the justification for what goes (and what stays in for that matter)? Sure, going through the diff: - packagereqbc/packagereq - packagereqdump/packagereq - packagereqed/packagereq - packagereqfinger/packagereq - packagereqftp/packagereq - packagereqrdate/packagereq - packagereqrsh/packagereq - packagereqtalk/packagereq - packagereqtelnet/packagereq - packagereqypbind/packagereq Moved to legacy-unix. - packagereqcyrus-sasl-plain/packagereq Should be Required: by apps that need it. - packagereqdbus/packagereq Pulled in implicitly by @core, moved there to be explicit. - packagereqlogrotate/packagereq Required: by rsyslog. Not used if you're not using rsyslog. - packagereqntsysv/packagereq Doesn't do much useful these days with systemd migration. (chkconfig has redirects; this does not.) - packagereqtmpwatch/packagereq Out of the box, conflicts with systemd's own tmp reaper. For apps that ship additional tmpwatch dirs (cups, etc.) they require it. - packagereqbtrfs-progs/packagereq Will be installed by anaconda if you install on btrfs; can move to @core if it becomes the default FS. - packagereqcoolkey/packagereq - packagereqpam_pkcs11/packagereq Will move to a smart-card-auth group shortly. - packagereqdmraid/packagereq Will be installed by anaconda if you need it. - packagereqfprintd-pam/packagereq Pulled in the GNOME desktop environment; doesn't need to be in the smaller server installs. - packagereqirda-utils/packagereq Ancient cruft. - packagereqlftp/packagereq Removed; ftp is in legacy-unix. - packagereqmdadm/packagereq Will be installed by anaconda if you need it (and pulled in by udisks2 if you install that.) - packagereqpasswdqc/packagereq Not used in the default config any more (libpwquality is used.) - packagereqpcmciautils/packagereq Ancient cruft (for old 16-bit only slots.) - packagereqpm-utils/packagereq See Lennart's reasoning on this. I could be swayed, or convinced that we should provide compat 'pm-suspend/pm-hibernate' binaries that just link to systemctl. - packagereqrdist/packagereq Doesn't belong in @standard; possibly should be in legacy-unix, or some other 'random administration utilities' section. - packagereqstunnel/packagereq - packagereqtree/packagereq Not functionality needed by everyone out of the box. - packagereqtime/packagereq bash has this builtin; don't think the additional features warrant this on every non-minimal install. - packagereqvconfig/packagereq Functionality subsumed by /sbin/ip. - packagereqwget/packagereq curl is already in the minimal install. (This will get pulled in by a bunch of other packages in Fedora anyway.) - packagereqwireless-tools/packagereq Functionality subsumed by iw. Although this is perhaps premature until initscripts gets ported to it. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
(mashing together a few replies. Sorry about the delay.) Michael Scherer (m...@zarb.org) said: Le vendredi 11 janvier 2013 à 08:05 -0600, Chris Adams a écrit : Once upon a time, Bill Nottingham nott...@redhat.com said: - packagereqed/packagereq I don't know how widely it is used, but ed is also part of POSIX/SUS. based on my understanding, POSIX do not mandate them to be there by default, just to support them : http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html so not installing them by default will not change much, given that we already do not support several command : http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html ... A separate group would be better because : - this is easier to audit ( especially if the norm is updated ) - this doesn't force to install a compiler by default ( fort77 ) Things like ed bc are required by redhat-lsb-core. (You can repoquery it for its full list). Would it be worth it to just list that, and not worry about the smaller things? Biggest size downfall to this is that it drags cups into the system. :/ Chris Adams (cmad...@hiwaay.net) said: - packagereqftp/packagereq Either ftp or lftp should still be in the standard install (command line FTP is sometimes essential, especially when trying to add to a minimal install). lftp is bigger than ftp (because lftp does more, such as sftp and http). If you're adding to an install, and you already have curl, rsync, and sftp, how much do you need an interactive ftp client itself? - packagereqbtrfs-progs/packagereq Will be installed by anaconda if you install on btrfs; can move to @core if it becomes the default FS. There are several common things that you list as installed by anaconda if needed; that can give you problems if you install in one system or setup and then move the drive, add other drives, etc. Sure, but I would assume that if you're doing that, you know what you're doing. - packagereqlftp/packagereq Removed; ftp is in legacy-unix. If legacy-unix is not part of standard install, that is a poor justification (we removed one FTP client, so better remove the other as well). The idea is that if the functionality is provided elsewhere, all uses of it should go there; splitting the functionality between groups doesn't make much sense. I guess my comments get back to: is there a defined goal, other than remove things Bill doesn't use (not trying to pick on you Bill, but you did make this list)? Are we trying to shrink the installed disk footprint (none of the these are very big)? Does removing these reduce install time significantly? This came up in the bugzilla ticket as well, and it's probably a better place to start. So, first principles of the group, IMO: 'Standard' would be 'tools and utilities you expect to be on a standard Linux install, but that aren't needed in a minimal install'. It's included in every non-minimal install. (In general, that means all the desktops; people who install servers usually start at minimal and work their way up.) This then brings up the following discussion points: * bc, ed, talk, etc. Should we just list redhat-lsb-core? * ftp vs lftp, info vs pinfo, traceroute vs mtr If we're talking about a 'standard' group of things that people would expect to be there, then perhaps we drop all the newer, better version of things. Sure, people still can install and use pinfo or mtr. But is that the standard that people expect to be there every time? * ftp, finger, etc. Are these things that are still expected in a 'standard' Linux install? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
Josh Boyer (jwbo...@gmail.com) said: On Wed, Jan 16, 2013 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Ruby 2.0.0 - the latest stable version of Ruby, with major increases in speed and reliability
Jaroslav Reznik (jrez...@redhat.com) said: Yet, it is source level backward compatible with Ruby 1.9.3, so your software will continue to work. The updated Ruby also provides better integration with Fedora, especially JRuby. But not only JRuby, it is also one step closer to be prepared for other interpreters, such as Rubinius. Provided custom Ruby loader with working name rubypick [1] will allow to easily switch interpreters executing your script, provides fallback to whatever Ruby interpreter is available on you system, yet still keeps backward compatibility with all your Ruby scripts. Reading this, it's source compatible, but not binary compatible, so everything gets a rebuild? (IOW, akin to many python version updates). Do you need a side tag for it? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
Jaroslav Reznik (jrez...@redhat.com) said: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Jaroslav Reznik (jrez...@redhat.com) said: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/ReplaceMySQLwithMariaDB = https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB * Detailed description: MariaDB is a fork of the MySQL database project that provides a drop-in replacement for MySQL. It preserves API/ABI compatibility with MySQL and adds some new features. The original company behind MySQL, MySQL AB, were bought out by Sun which was then bought by Oracle. Recent changes made by Oracle indicate they are moving the MySQL project to be more closed. They are no longer publishing any useful information about security issues (CVEs), and they are not providing complete regression tests any more, and a very large fraction of the mysql bug database is now not public. MariaDB, which was founded by some of the original MySQL developers, has a more open-source attitude and an active community. We have found them to be much easier to work with, especially in regards to security matters. We would like to replace MySQL with MariaDB in early development cycle for Fedora 19. MySQL will continue to be available for at least one release, but MariaDB will become the default. Also, we do not intend to support concurrent installation of both packages on the same machine; pick one or the other. What does it mean to replace it as the default if neither is ever installed in a default 'next - next - next' installation? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Tom Lane (t...@redhat.com) said: Yes, that's the general idea --- any dependencies on mysql should result in installing mariadb, unless the user takes specific action to get mysql instead. Ideally we'd just do the standard Provides/Obsoletes dance for replacing one package with another, but I'm not quite sure how that should work if we still want original mysql to be installable. Any thoughts from RPM experts would be welcome. (If the compatibility testing goes *really* smoothly, maybe we could just drop the requirement for original mysql to still be available, in which case it reduces to the standard package-replacement problem. But I'm not prepared to bet on that quite yet.) Honestly, I'd be curious as to whether we could get all the compatibility testing done early enough, and packages changed, such that we could consider dropping MySQL. It's just... cleaner. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2013-01-23)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #896 Refine Feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896 = New business = #986F19 Feature: Fix Network Name Resolution - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution .fesco 986 https://fedorahosted.org/fesco/ticket/986 #996F19 Feature: BIND10 - https://fedoraproject.org/wiki/Features/BIND10 .fesco 996 https://fedorahosted.org/fesco/ticket/996 #997F19 Feature: Enlightement - https://fedoraproject.org/wiki/Features/Enlightenment .fesco 997 https://fedorahosted.org/fesco/ticket/997 #998F19 Feature: Erlyvideo -https://fedoraproject.org/wiki/Features/Erlyvideo .fesco 998 https://fedorahosted.org/fesco/ticket/998 #999F19 Feature: Fedora 19 Boost 1.53 Uplift - https://fedoraproject.org/wiki/Features/F19Boost153 .fesco 999 https://fedorahosted.org/fesco/ticket/999 #1000 F19 Feature: GCC 4.8.x - https://fedoraproject.org/wiki/Features/GCC48 .fesco 1000 https://fedorahosted.org/fesco/ticket/1000 #1001 F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7 .fesco 1001 https://fedorahosted.org/fesco/ticket/1001 #1002 F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0 .fesco 1002 https://fedorahosted.org/fesco/ticket/1002 #1003 F19 Feature: RemovePyXML - https://fedoraproject.org/wiki/Features/RemovePyXML .fesco 1003 https://fedorahosted.org/fesco/ticket/1003 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Peter Robinson (pbrobin...@gmail.com) said: Default might not be the exactly correct word here. The main thing I'm expecting would be that the mysql database package group would actually give you mariadb, as would the anaconda checkbox. Will it be designed to work with the alternatives infrastructure so that those that actually want mysql can swap it in/out? Alternatives isn't really what you want for swapping between sets of client libraries. However, given that the mysql client libraries use specific paths in ld.so.conf.d, the files don't actually conflict. (But then you're relying on glibc's interpretation order of ld.so.conf.d if you have both installed.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for Wednesday's FESCo Meeting (2013-01-23)
=== #fedora-meeting: FESCO (2013-01-23) === Meeting started by notting at 18:01:20 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-01-23/fesco.2013-01-23-18.01.log.html . Meeting summary --- * init process (notting, 18:01:28) * #896 Refine Feature process (notting, 18:03:58) * AGREED: F19 Feature: Boost 1.53 Uplift is approved (+:9, -:0) (notting, 18:10:44) * AGREED: F19 Feature: RemovePyXML is approved (+:9, -:0) (notting, 18:10:56) * #986 F19 Feature: Fix Network Name Resolution - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution (notting, 18:12:15) * AGREED: F19 Feature: Fix Network Name Resolution is approved (+:9, -:0) (notting, 18:13:50) * #996F19 Feature: BIND10 - https://fedoraproject.org/wiki/Features/BIND10 (notting, 18:14:13) * AGREED: F19 Feature: BIND10 is approved (+:9, -:0) (notting, 18:16:24) * #997F19 Feature: Enlightement - https://fedoraproject.org/wiki/Features/Enlightenment (notting, 18:16:35) * AGREED: F19 Feature: Enlightenment is approved (+:9, -:0) (notting, 18:18:47) * #998F19 Feature: Erlyvideo -https://fedoraproject.org/wiki/Features/Erlyvideo (notting, 18:19:01) * AGREED: F19 Feature: Erlyvideo is approved (+:9, -:0) (notting, 18:20:55) * sgallagh to check that it works with acceptable free in-Fedora codecs before release (notting, 18:21:10) * #1000 F19 Feature: GCC 4.8.x - https://fedoraproject.org/wiki/Features/GCC48 (notting, 18:21:42) * AGREED: F19 Feature: GCC 4.8.x approved (+:7, -:0) (notting, 18:28:25) * AGREED: Feb 1 tentatively scheduled for start of mass rebuild. Will confirm at 2013-01-30 FESCo meeting (notting, 18:28:46) * #1001 F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7 (notting, 18:29:22) * postponed to next week while devel@ and packaging@ discussion continues (notting, 18:36:35) * #1002 F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0 (notting, 18:36:58) * postponed to next week while devel@ and packaging@ discussion continues (notting, 18:49:55) * Next week's chair (notting, 18:50:54) * mmaslano will chair next week's meeting (notting, 18:51:16) * Open Floor (notting, 18:51:30) * FESCo intends to do block approval of features next week based on whther or not further discussion on them is warranted (notting, 18:59:47) Meeting ended at 19:03:02 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * notting (82) * sgallagh (45) * mmaslano (42) * nirik (34) * abadger1999 (31) * mitr (30) * pjones (25) * t8m (24) * jwb (17) * zodbot (14) * dgilmore (10) * jlaw (9) * jreznik (8) * gregdek (3) * mattn__ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 18:01:20 notting #startmeeting FESCO (2013-01-23) 18:01:20 zodbot Meeting started Wed Jan 23 18:01:20 2013 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:20 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:28 notting #meetingname fesco 18:01:28 zodbot The meeting name has been set to 'fesco' 18:01:28 notting #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:01:28 notting #topic init process 18:01:28 zodbot Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:01:33 pjones hello. 18:01:34 mitr Hello 18:01:38 mmaslano hi 18:01:39 jwb here 18:01:40 * sgallagh waves 18:01:43 * abadger1999 here 18:01:44 nirik morning everyone 18:01:51 sgallagh Happy Post-FUDCon FESCo meeting :) 18:01:53 pjones good to see everybody made it back from fudcon alive 18:01:58 t8m good evening everyone 18:02:08 * gregdek lurks4fun 18:02:19 sgallagh pjones: Except apparently spot. Poor guy. 18:02:30 pjones Oh? 18:02:35 gregdek kidney stones. 18:02:38 pjones yikes. 18:02:40 nirik :( 18:02:45 jlaw :( 18:02:46 t8m ouch 18:02:49 notting yeah, those are Not Fun 18:02:52 pjones dcantrell also wound up in the hospital with bronchitis, apparently. 18:02:53 gregdek he has drugs, though, so he'll make it. 18:03:03 abadger1999 :-( 18:03:03 pjones but he's out now and recovering. 18:03:24 notting but hey, everyone's here. so... 18:03:24 jlaw had my first this summer while on vacation... not good 18:03:38 notting jlaw: we're all getting old 18:03:51 jlaw yea, i realize that from time to time 18:03:58 notting #topic #896 Refine Feature process 18:03:59 notting .fesco 896 18:04:01 zodbot notting: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:04:35 nirik jreznik asked us to delay a week on this... 18:04:40 notting there was discussion of this at FUDCon. in a not-shocking surprise, it also morphed
Re: Proposed F19 Feature: Guile2
Jaroslav Reznik (jrez...@redhat.com) said: = Features/Guile2 = https://fedoraproject.org/wiki/Features/Guile2 Feature owner(s): Jan Synacek jsyna...@redhat.com Update GNU Guile to version 2.0.x in Fedora 19. == Detailed description == Current guile package will be upgraded to 2.0.x. compat-guile18 package will provide additional time for the packages to be ported to guile-2.0.x. Will compat-guile1.8 provide guile = 1.8 (and similarly for compat-guile1.8-devel? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Shared System Certificates
Jaroslav Reznik (jrez...@redhat.com) said: OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the PKCS#11 trust module. These extracted certificates will be placed in a location so that they can be consumed by OpenSSL by default. The aim is that neither OpenSSL nor OpenSSL applications will have to be changed for this to work. the aim... GnuTLS: The p11-kit tool tool will extract a CA bundle to be used by GnuTLS from the PKCS#11 trust module. This CA bundle would be placed in the location where most GnuTLS applications today are configured to use it. most... Obviously applications can continue to use their own CA list as appropriate, for example in servers such as httpd or postfix. Essentially, how will we know whether apps work transparently with the library changes, and/or if there are apps that are hardcoding old locations/methods somewhere? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: KScreen - KDE screen management
Jaroslav Reznik (jrez...@redhat.com) said: = Features/KScreen = https://fedoraproject.org/wiki/Features/KScreen Feature owner(s): Dan Vrátil dvra...@redhat.com Replace current KDE screen management software by KScreen. == Detailed description == KScreen is a KDE screen management software that massively improves user experience when working with multiple monitors in KDE. It provides modern user interface and can automatically save and restore screen configuration profiles. It obsoletes the current screen management software. If this is an upstream KDE project, wouldn't it just be rolled into the main KDE feature? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: First-Class Cloud Images
Jaroslav Reznik (jrez...@redhat.com) said: == Detailed description == * New images that can be used in other cloud deployments (such as OpenStack, CloudStack, or Eucalyptus) will be produced. They will be in a qcow2 format and lack the EC2-specific customization. Images for this feature would ideally work for all cloud deployments and there will be i686 and x86_64 versions of both image types. In total and image drop will have 4 images: 2 arches for 2 different types (EC2, not-EC2). Will these images also be usable directly as virt image templates in local virtualization tools such as virt-manager Boxes? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: OpenStack Grizzly
Michael Scherer (m...@zarb.org) said: While it may be harder to predict the feature that will land in Openstack at this point, would it be possible to have at least a idea of the new features and changes that such upgrade will bring ? It is hard to say if this is a good idea or not without it, and hard to write a good marketing pitch based on this. The desktop features usually do some of this, where they mention not just the new version, but the major improvements in that new version. Also, I note: Upgrades from Folsom to Grizzly may need significant upstream work to achieve. Do we know what sort of work this may imply? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. [...] This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed. This seems to invent yet another new naming scheme. We just went through this pain, and the biosdevname scheme went through several iterations in the field and represents real-world lessons learned. Is there a compelling reason to make the systemd/udev policy for Fedora not just follow the existing solution to the same problem embodied in biosdevname? (Then, we could just phase out biosdevname.) biosdevname naming isn't apparently consistent across versions. https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 The problems are roughly this: - biosdevname only provides predictable naming for machines with SMBIOS type 9 type 41 records - For other machines, it does 'best effort' based off of heuristics and attempting to enumerate all the devices... which gives weird/unpredictable results. This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
Bohuslav Kabrda (bkab...@redhat.com) said:
JRuby and Ruby won't share extensions. Extensions for Ruby will live in
%{_libdir}/gems/ruby, while extensions for JRuby will in
%{_datadir}/gems/jruby (although we decided not to actually ship any JRuby
extension Gems for F19 as we want to take more time to figure out the
guidelines specifics around it).
JRuby is pretty incompatible with C extensions. In fact, guys from upstream
told me that they may even completely drop support for C extensions, as its
very hard to maintain and doesn't really bring significant benefits. That's
why we don't want to do it in Fedora.
So, thinking of this in terms of python (sorry, that's my experience), this
is the equivalent of an alternate python interpreter that can only use
.noarch python extensions/modules that don't depend on any archful python
modules?
How is an application author supposed to know which interpreter they can
use - do they have to recursively traverse their dependency stack first
before making a decision?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: First-Class Cloud Images
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Jan 23, 2013 at 04:38:13PM -0500, Bill Nottingham wrote: == Detailed description == * New images that can be used in other cloud deployments (such as OpenStack, CloudStack, or Eucalyptus) will be produced. They will be in a qcow2 format and lack the EC2-specific customization. Images for this feature would ideally work for all cloud deployments and there will be i686 and x86_64 versions of both image types. In total and image drop will have 4 images: 2 arches for 2 different types (EC2, not-EC2). Will these images also be usable directly as virt image templates in local virtualization tools such as virt-manager Boxes? Yes. They have cloud-init enabled, which will look for a metadata service and (probably) not find one and then eventually time out and get you to a login prompt. To avoid that, you can boot with ds=nocloud' (Apparently there's a RHEVm and vSphere datasource too but I haven't tested that.) Have the boxes and libvirt people investigated writing a minimal cloud-init compatibile data-source? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Miroslav Suchý (msu...@redhat.com) said: On 01/23/2013 07:50 PM, Lennart Poettering wrote: The thing is that doing on-line updates only works for stuff you can restart, and that doesn't mind that things are not atomically updated. However, much (most?) of our code isn't like that. Anybody who What could not be restarted? And what we can do to fix that? If this work for Debian/Ubuntu, why it could not work for Fedora? Essentially, the idea of a major release is to do the sorts of upgrades that don't work cleanly on a running system. Examples would be: - mysql database version upgrade (or similar upgrades that require a format conversion) - switching out the system python interpreter version - switching from a static /dev to udev - switching init systems - switching a script from being sysv to being a systemd service - refactoring of a systemd service if necessary - /usr move - introduction of changes that require a new kernel subsystem mount point, or the move of one (/selinux to /sys/fs/selinux, for example) None of these things are things that will work perfectly reliably in an on-line upgrade mechanism. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Start of systemd timers after install/update of a package
Tomas Mraz (tm...@redhat.com) said: On Thu, 2013-01-24 at 16:03 +0100, Jochen Schmitt wrote: Hello, I have tried to migrating the cron jobs of the inn package to systemd timers. Unfortunately, I have got the following problem. After a install/update of the package the timer will only start the service unit only once time. The service was not started after the configure period was expired. But when I have restart the system, it's works as expected. So I would to ask, what I have to concern when I want to migrate to systemd timers. I think that massive migration of services from cron to systemd timers is very premature and should be actively at least discouraged by packaging directives. I'm somewhat skeptical of the benefit of migration in general. I'm really skeptical that the place you start reducing the dependency load is inn. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
Jaroslav Reznik (jrez...@redhat.com) said: = Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Orion Poplawski (or...@cora.nwra.com) said: I'm not trying to disparage this work, it seems reasonable (although I've been bitten by a lot of crappy software assuming network devices are named eth#, but it's able to be turned off, so meh). We went through most of the things we shipped back when biosdevname was first introduced and filed a *lot* of bugs to get all those cases fixed, so we *should* be much better there. (Can't speak to third-party software, obviously). If any of those fixes involved merely adding the biosdevname namespaces to whitelists instead of properly getting device names, well, I'm not *supposed* to promote an attitude of violence, but... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
Chris Adams (cmad...@hiwaay.net) said: Once upon a time, Bill Nottingham nott...@redhat.com said: Jaroslav Reznik (jrez...@redhat.com) said: The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? I would guess that the backtrace code which is not thread safe would mean you couldn't safely do it system-wide. Well, it's already killing the process at that point - I assumed he meant that the backtrace would be unreliable in the presence of threads. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. The simplest way to do that would be: - change biosdevname to not be installed by default - enable these rules only on install, not on upgrade both of which are pretty easily doable. To quote the documentation, of the device name formats: * Two character prefixes based on the type of interface: * en -- ethernet * wl -- wlan * ww -- wwan * * Type of names: * oindex -- on-board device index number * sslot[ffunction][ddev_id] -- hotplug slot index number * xMAC-- MAC address * pbussslot[ffunction][ddev_id] -- PCI geographical location * pbussslot[ffunction][uport][..][cconfig][iinterface] * -- USB port number chain What concerns would people have with this naming? Off the top of my head: - wwan devices aren't always discoverable (they can show up as ethernet) - devices that biosdevname considers emX via enumeration/guessing would now have enpXsY, which could be considered 'uglier' Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Miloslav Trmač (m...@volny.cz) said: On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdPredictableNetworkInterfaceNames = https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. 71-biosdevname.rules only handles KERNEL==eth*; so am I correct that it doesn't affect wlan* names at all? If wlan* is not controlled by biosdevname, what happens to them in this proposal in the default installation? Will they remain unchanged because biosdevname is installed, or will they be changed because biosdevname doesn't assign them a name? The latter. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
