Re: Goals for F13?
Mike McGrath (mmcgr...@redhat.com) said: What does everyone else have? 1) no frozen rawhide which requires faster composes 2) dist-git 3) A functioning message bus with services passing messages I think I know what you'd want from us on 2 and 3, can you think of anything off hand you'd need help with for 1? By faster composes are you thinking composing more often? Does that include distribution? NFR essentially requires two rawhides per day, once we branch for release. Given that we'd also be pushing updates, that's a lot of mashing and load on /mnt/koji. Possible help points for that: - using multiple releng boxes for composition - faster storage Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: FESCo election results December 2009
Matthew Garrett (m...@redhat.com) said: On Fri, Dec 18, 2009 at 12:19:47PM -0500, Paul W. Frields wrote: Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 I think there's a discrepency here :) With seven candidates, the actual maximum number is 1512 (7*216). Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: autofs not installed by default
Todd Volkert (tvolk...@gmail.com) said: The past few Fedora installs, I've specified a NIS server during the Anaconda installation so I don't have to create any local user accounts. However, once installation is complete, I can't log into any NIS accounts because autofs insn't installed, causing the user accounts' home folders to not be mounted. I have to sign in as root, install autofs, then all is well. How have you set up a NIS server as part of the install? It's not part of the anaconda configuration screens. My question is: shouldn't autofs be installed by default, as part of the base installation? For many use cases in Fedora, it's not needed; we're trying to keep the core/base groups reasonably small. If you use kickstart, you can both set up NIS and install autofs with directives in your kickstart file. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10
Matthew Miller (mat...@mattdm.org) said: One notable change that was made is that we were able to simplify the jobs to the point where the number of login consoles is now configurable, without editing or removing upstart job definitions. This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; the default value is /dev/tty/[1-6], which means that mingetty will be started on ttys 1 through 6. Shell globs are accepted. How hard would it be to make this be different in runlevels 3 and 5? I like to have lots in runlevel 3, and few if X is available. Given how it's implemented, you could do something truly disgusting like ACTIVE_CONSOLES=$([ $RUNLEVEL = 3 ] echo '/dev/tty[1-6]' || echo '/dev/tty2') I'm not sure I really want to *support* people doing that, though. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10
Matthew Miller (mat...@mattdm.org) said: Given how it's implemented, you could do something truly disgusting like ACTIVE_CONSOLES=$([ $RUNLEVEL = 3 ] echo '/dev/tty[1-6]' || echo '/dev/tty2') I'm not sure I really want to *support* people doing that, though. You mean, you don't like the idea of having different numbers of consoles running in different runlevels, or you don't like the abusing-shell-script-as-config-file thing? The latter. :) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
Nathanael D. Noblet (nathan...@gnat.ca) said: I'm also curious why gdm is still running once I've logged in. When you start a display manager, you start an X server; the display manager then draws on this. Then, when you log in, you have to stat an user session, as the authenticated user (which has a connection to the X server, so it can know when it goes away.) You also have to tell the init daemon which process it's supposed to be tracking, so it can respawn it when it exits. Having that process be the gdm daemon (which forks and execs both the X server and the user session) is arguably a lot simpler than trying to architect it such that the daemon goes away entirely and init then ends up tracking either the X serve or the user session. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
James Antill (ja...@fedoraproject.org) said: Hmm, looking at the traceback at the end of http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log Note that while I fixed the bug which caused the traceback, the traceback is in a code path that means clamav-scanner-upstart has a file dep. that can't be satisfied ... so I'm not sure if that means the compose will fail anyway? Broken deps will only fail the compose if they're critical enough to prevent composing the chroot that rawhide composes in (essentially, dependnecies of mash - yum, python, etc.). clamav-scanner-upstart would not fall into that category. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
James Antill (ja...@fedoraproject.org) said: Gah, I see the problem. clamav-scanner-upstart is in the transaction, to be installed, but we are only looking in the rpmdb. My fault, off to do a patch. I've kicked off a new rawhide with the patched yum. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10
Bill Nottingham (nott...@redhat.com) said: It's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. Once you reboot, things should work pretty much the same. One notable change that was made is that we were able to simplify the jobs to the point where the number of login consoles is now configurable, without editing or removing upstart job definitions. This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; the default value is /dev/tty/[1-6], which means that mingetty will be started on ttys 1 through 6. Shell globs are accepted. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
upstart-0.6.3 in rawhide, tomorrow 2009-12-10
https://fedoraproject.org/wiki/Features/Upstart0.6.0 was approved at last week's FESCo meeting. It was built today, and will land in rawhide tomorrow. What this means for you: It's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. Once you reboot, things should work pretty much the same. All users have been converted with the exception of readahead[1], unless we missed some. Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Bill [1] because I missed in in the first scan and haven't had a chance to talk to the maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
James Antill (ja...@fedoraproject.org) said: Does this mean that running dbus will be required to reboot/shutdown the system? No. The init daemon speaks the dbus protocol, and can be communicated with over the system daemon. But it can also be talked to directly. Looking at upstart-0.6.3-3.fc13.src.rpm, the specfile includes /sbin/shutdown etc. ... and looking at the tarball those seem to come from util/*.c. Which AFAICS require DBus to work. ... which does not *require* the system dbus daemon. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Hans Ulrich Niedermann (h...@n-dimensional.de) said: The big issue is with KMS on using radeonhd is like shooting yourself in the face. Either we need to patch radeonhd in Fedora to not start with KMS enabled or remove it from the distro. I am working on such a patch to radeonhd right now. The patch has been finished and has been tested on my system. Packages with the patch have been built and are both in rawhide and on their way towards updates-testing/ and updates/ for F11 and F12 (xorg-x11-drv-radeonhd-1.3.0-4.2.20091204git.fc*). Cool. Objection withdrawn. :) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 2009-12-04
=== #fedora-meeting: FESCo meeting 20091204 === Meeting started by notting at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-12-04/fesco.2009-12-04-17.00.log.html . Meeting summary --- * ACTION: notting will close out ticket 274 (notting, 17:04:23) * F13 schedule (notting, 17:04:38) * AGREED: F13 schedule as proposed is accepted. (notting, 17:10:39) * Feature Intellij IDEA (notting, 17:11:51) * LINK: http://www.jetbrains.com/idea/nextversion/editions_comparison_matrix.html (Kevin_Kofler, 17:15:54) * ACTION: this was already accepted at the 2009-11-20 meeting (notting, 17:20:03) * Feature - Better Hostname (notting, 17:22:47) * ACTION: discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page (notting, 17:33:21) * Feature - User Account Dialog (notting, 17:33:35) * ACTION: User Account Dialog feature has been accepted for F13 (notting, 17:38:37) * Feature - Copy/Paste Just Works (notting, 17:38:56) * ACTION: CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. (notting, 17:44:30) * ACTION: correction: Fedora 13 (notting, 17:45:18) * Feature - Upstart 0.6.x (notting, 17:45:49) * ACTION: Upstart 0.6.x has been accepted as a Fedora 13 feature (notting, 17:50:08) * Feature - NetBeans 6.8 (notting, 17:50:24) * ACTION: NetBeans 6.8 feature has been approved for Fedora 13 (notting, 17:54:30) * Feature - RPM 4.8 (notting, 17:54:45) * ACTION: RPM 4.8 has been accepted as a Fedora 13 feature (notting, 17:57:58) * Feature - Rollback with BTRFS (notting, 17:58:11) * AGREED: Rollback with BTRFS has been approved as a F13 feature (notting, 18:17:54) * Open floor (notting, 18:18:43) * FPC report (notting, 18:20:11) * AGREED: pkgconfig guideline change approved (notting, 18:22:59) * Emacs Packaging (notting, 18:23:09) * AGREED: Emacs guideline change approved (notting, 18:24:57) * PHP guidelines revised (notting, 18:25:30) * AGREED: PHP guideline revision approved. (notting, 18:29:17) * Open floor (notting, 18:29:25) Meeting ended at 18:33:36 UTC. Action Items * notting will close out ticket 274 * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature Action Items, by person --- * notting * notting will close out ticket 274 * sk * CopyPasteJustWorks is not approved as a feature for Fedora 12. FESCo suggests the submitter work with the Desktop spin maintainers on this issue. * **UNASSIGNED** * this was already accepted at the 2009-11-20 meeting * discussion on Better Hostname/Computer Name is deferred pending answers to questions on the discussion page * User Account Dialog feature has been accepted for F13 * correction: Fedora 13 * Upstart 0.6.x has been accepted as a Fedora 13 feature * NetBeans 6.8 feature has been approved for Fedora 13 * RPM 4.8 has been accepted as a Fedora 13 feature People Present (lines said) --- * notting (118) * Kevin_Kofler (60) * nirik (56) * dwmw2 (38) * cjb (19) * josef (17) * sharkcz (17) * zodbot (15) * tibbs|h (12) * sadmac (3) * mjg59 (1) * miniperl (1) * skvidal (0) * j-rod (0) * sk (0) * jds2001 (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Upstart 0.6.3 coming to a rawhide near you
https://fedoraproject.org/wiki/Features/Upstart0.6.0 was approved at today's FESCo meeting. We hope to land this in the next week or so. What this means for you (for very specific values of you): If you own any of the following packages, you have upstart job files that will need modified for any needed format changes, and the new location. * vpnc rjones * ConsoleKitmccann * clamavensc * dhcp-forwarderensc * hdapsdttorcz * ip-sentinel ensc * milter-greylist ensc * olpc-utilspbrobinson * tor ensc We're willing to do the legwork for you, or you can do the update yourself once we land 0.6.x; give us a reply with which you'd prefer. See the feature page for more details on the changes required. What this means for you (for very general values of you): Once it lands, it's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. We can investigate adding some compat code to ease this, if people would really prefer. Once you reboot, things should work pretty much the same. Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Questions? Comments? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
Bill Nottingham (nott...@redhat.com) said: Obvious FAQ: Q: Should we port our SysV scripts to native upstart scripts? A: No, not at this time. Q: I'd like to play with it before it lands. A: There's a repo at http://notting.fedorapeople.org/upstart0.6/. You can also check the new upstart package out of devel/ CVS, and the initscripts changes out of the upstart-0.6.0-branch in initscripts git. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
Miroslav Lichvar (mlich...@redhat.com) said: On Fri, Dec 04, 2009 at 04:10:34PM -0500, Bill Nottingham wrote: https://fedoraproject.org/wiki/Features/Upstart0.6.0 The features highlight list has: Communication with the init daemon over D-Bus. Questions? Comments? Does this mean that running dbus will be required to reboot/shutdown the system? No. The init daemon speaks the dbus protocol, and can be communicated with over the system daemon. But it can also be talked to directly. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20091203) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. This meeting may be cancelled if we cannot reach quorum. FESCo members who cannot make it are encouraged to vote or comment in the tickets. 274 Linville requests provenpackager membership 281 Approve Fedora 13 Schedule Features: 272 Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA 278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname 279 User Account Dialog - https://fedoraproject.org/wiki/Features/UserAccountDialog 286 Copy/Paste Just Works - https://fedoraproject.org/wiki/Features/CopyPasteJustWorks 287 Upstart 0.6.x - https://fedoraproject.org/wiki/Features/Upstart0.6.0 288 NetBeans 6.8 - https://fedoraproject.org/wiki/Features/NetBeans_6.8 289 RPM 4.8 - https://fedoraproject.org/wiki/Features/RPM4.8 290 Rollback with BTRFS - https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs 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. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20091204) FESCo meeting
Bill Nottingham (nott...@redhat.com) said: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. Despite what the original subject said, that should be tomorrow, December *4th* at 17:0UTC. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Matěj Cepl (mc...@redhat.com) said: Moreover, I don't know what's your problem with radeonhd driver in Fedora. Hanz does IMHO excellent job on maintaining it and it doesn't drag much additional resources on anybody (except on me, perhaps, because I triage bugs for him as well, which is the reason that this time I even a little know what I am talking about ;)). And of course comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati bugs (http://is.gd/59Hp0) is unfair, because there are many more users of -ati driver, but at least it shows that radeonhd is really not burning issue. What's the problem? Does not work at all with KMS, which is on by default; is unsupported by the people that maintain the servers and the rest of the drivers. Following a sane OAOO strategy, we'll get better results if we try and get all fixes on a single driver path moving forwards. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Ralf Corsepius (rc040...@freenet.de) said: Does the FSF/GPL demand to keep a repo around for ISOs? A rolling Everything would not touch the ISOs. They would still be around. The LiveCD/spins satisfy their source requirements via the source repositories; they do not compose separate live source images. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
Dan Williams (d...@redhat.com) said: ONBOOT=yes BOOTPROTO=dhcp TYPE=Wireless NM_CONTROLLED=yes USERCTL=yes PEERDNS=yes IPV6INIT=no MODE=Auto This is the problem. Auto is not a valid mode. It's a valid mode according to the iwconfig man page. I have no idea what cards actually support it. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Dave Airlie (airl...@redhat.com) said: On Fri, 2009-11-27 at 08:07 +0200, Pekka Savola wrote: Well, here's one graphics regression: https://bugzilla.redhat.com/show_bug.cgi?id=540476 radeon.modeset=0 worked around the problem. (I'm not sure if it's filed against the right component.) Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk. So you've proven you can break your own machine that is all. So, if our X maintainers won't handle bugs with it, we have a working default alternative that is maintained upstream, and it's *known* to be broken in the default configuration, why ship it? If we're trying to focus on quality, I'm not sure why we'd ship something that's known broken. Hans, are you OK if we block this from rawhide? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Ian Pilcher (arequip...@gmail.com) said: On 12/01/2009 09:35 AM, Bill Nottingham wrote: So, if our X maintainers won't handle bugs with it, we have a working default alternative that is maintained upstream, and it's *known* to be broken in the default configuration, why ship it? If we're trying to focus on quality, I'm not sure why we'd ship something that's known broken. Because the alternative may be more broken for some people? https://bugzilla.redhat.com/show_bug.cgi?id=495688 If the e1000 driver is broken in the kernel for some people, we don't support shipping an alternate driver. If a new version of the intel graphics driver is broken for some people, we don't support shipping a pre-KMS version of the driver. Why would we do differently here? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Gene Czarcinski (g...@czarc.net) said: Keep it simple (KISS) for the initial attempt. It will grow more complicated all by itself as time passes. BTW, the security policy should assume that a grub password is in use so that a user cannot do something like disabling selinux by editing the kernel command line. This should be tested by the security QA. That seems very broken. A security policy that is violated on every single out of the box install that doesn't do customization? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
inode0 (ino...@gmail.com) said: So the answers are now free for public consumption on this page: https://fedoraproject.org/wiki/Elections/F13_Questionnaire I just want to thank you again for all your work on this. I understand it is a burden to candidates and a lot of work for you to collect and organize the answers but it sure makes for some interesting reading. For those who don't personally know the candidates you have made a big contribution to the recent elections. Agreed; thanks for all the hard work here! Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Gregory Maxwell (gmaxw...@gmail.com) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
Adam Williamson (awill...@redhat.com) said: It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. Yes, but how often have we touted XO, Sugar, et. al. as being 'based on Fedora' over the past 4 years? Heck, you could argue it's gotten more press than some of our official spins. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
James Antill (ja...@fedoraproject.org) said: ...on the upside IIRC notting tried the 64bit kernel with 32bit userspace for F11, and had a single line patch (to rpmUtils.arch) to make yum happy. A single line patch which *everyone* hated., as it essentially keyed off the wordsize of the python you were running. The problem is that if you do 32-on-64, at the first instance yum substitutes in x86_64 for your base arch, and then you magically change into a 64-on-64 system. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) Bill -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: PackageKit policy: background and plans
James Morris (jmor...@namei.org) said: MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. What about when the system is rebooted? One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. Your complaint appeared to be that someone could switch from targeted to minimal (or similar) by simply installing the other package. It *does not work that way*, and it never has. If you're saying that an upgrade to a later targeted policy might break the local customizations, doesn't that mean the targeted policy maintainer made a mistake? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who handles lidclose at login screen?
Orion Poplawski (or...@cora.nwra.com) said: What is responsible for suspending a laptop when the lid is closed and it is at the login screen? Running kdm and the machine does not suspend. In principle, whatever handles it in your session. gnome-power-manager runs as part of the gdm session, so the KDE equivalent should be running under kdm. There is no session - I'm at the login screen. With GDM, the login manager is running as part of a session for the 'gdm' user, using the normal gnome session tools. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Finance-Quote/F-12 .cvsignore, 1.3, 1.4 perl-Finance-Quote.spec, 1.9, 1.10 sources, 1.3, 1.4
Author: notting
Update of /cvs/extras/rpms/perl-Finance-Quote/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31518/F-12
Modified Files:
.cvsignore perl-Finance-Quote.spec sources
Log Message:
update to 1.17 (#540340, bba...@gmail.com)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-12/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 9 Jan 2007 04:38:01 - 1.3
+++ .cvsignore 23 Nov 2009 18:16:01 - 1.4
@@ -1 +1 @@
-Finance-Quote-1.13.tar.gz
+Finance-Quote-1.17.tar.gz
Index: perl-Finance-Quote.spec
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-12/perl-Finance-Quote.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Finance-Quote.spec 26 Jul 2009 06:07:07 - 1.9
+++ perl-Finance-Quote.spec 23 Nov 2009 18:16:01 - 1.10
@@ -1,6 +1,6 @@
Name: perl-Finance-Quote
-Version:1.13
-Release: 4%{?dist}
+Version:1.17
+Release: 1%{?dist}
Summary:A Perl module that retrieves stock and mutual fund quotes
Group: Development/Libraries
License:GPLv2+
@@ -9,7 +9,11 @@ Source0: http://prdownloads.sourceforge.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildRequires: perl(HTML::TableExtract) perl(ExtUtils::MakeMaker)
+# Required for compile tests; no 'online' tests are run during the build
+BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(Crypt::SSLeay) perl(HTTP::Request::Common)
+BuildRequires: perl(HTML::TableExtract) perl(HTML::TreeBuilder)
+BuildRequires: perl(Test::More)
%description
This module retrieves stock and mutual fund quotes from various exchanges
@@ -44,6 +48,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Mon Nov 23 2009 Bradley Baetz bba...@gmail.com - 1.17-1
+- Update to 1.17
+- Add extra BuildRequires needed for tests to pass
+
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-12/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 9 Jan 2007 04:38:01 - 1.3
+++ sources 23 Nov 2009 18:16:01 - 1.4
@@ -1 +1 @@
-3619ccb3fb09ed9eebe1941e6cf361c9 Finance-Quote-1.13.tar.gz
+446dba3837ffa395bffdea268824e0c1 Finance-Quote-1.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Finance-Quote/devel .cvsignore, 1.3, 1.4 perl-Finance-Quote.spec, 1.9, 1.10 sources, 1.3, 1.4
Author: notting
Update of /cvs/extras/rpms/perl-Finance-Quote/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31518/devel
Modified Files:
.cvsignore perl-Finance-Quote.spec sources
Log Message:
update to 1.17 (#540340, bba...@gmail.com)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 9 Jan 2007 04:38:01 - 1.3
+++ .cvsignore 23 Nov 2009 18:16:02 - 1.4
@@ -1 +1 @@
-Finance-Quote-1.13.tar.gz
+Finance-Quote-1.17.tar.gz
Index: perl-Finance-Quote.spec
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/devel/perl-Finance-Quote.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Finance-Quote.spec 26 Jul 2009 06:07:07 - 1.9
+++ perl-Finance-Quote.spec 23 Nov 2009 18:16:02 - 1.10
@@ -1,6 +1,6 @@
Name: perl-Finance-Quote
-Version:1.13
-Release: 4%{?dist}
+Version:1.17
+Release: 1%{?dist}
Summary:A Perl module that retrieves stock and mutual fund quotes
Group: Development/Libraries
License:GPLv2+
@@ -9,7 +9,11 @@ Source0: http://prdownloads.sourceforge.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildRequires: perl(HTML::TableExtract) perl(ExtUtils::MakeMaker)
+# Required for compile tests; no 'online' tests are run during the build
+BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(Crypt::SSLeay) perl(HTTP::Request::Common)
+BuildRequires: perl(HTML::TableExtract) perl(HTML::TreeBuilder)
+BuildRequires: perl(Test::More)
%description
This module retrieves stock and mutual fund quotes from various exchanges
@@ -44,6 +48,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Mon Nov 23 2009 Bradley Baetz bba...@gmail.com - 1.17-1
+- Update to 1.17
+- Add extra BuildRequires needed for tests to pass
+
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 9 Jan 2007 04:38:01 - 1.3
+++ sources 23 Nov 2009 18:16:02 - 1.4
@@ -1 +1 @@
-3619ccb3fb09ed9eebe1941e6cf361c9 Finance-Quote-1.13.tar.gz
+446dba3837ffa395bffdea268824e0c1 Finance-Quote-1.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Finance-Quote/F-11 .cvsignore, 1.3, 1.4 perl-Finance-Quote.spec, 1.8, 1.9 sources, 1.3, 1.4
Author: notting
Update of /cvs/extras/rpms/perl-Finance-Quote/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31518/F-11
Modified Files:
.cvsignore perl-Finance-Quote.spec sources
Log Message:
update to 1.17 (#540340, bba...@gmail.com)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-11/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 9 Jan 2007 04:38:01 - 1.3
+++ .cvsignore 23 Nov 2009 18:16:01 - 1.4
@@ -1 +1 @@
-Finance-Quote-1.13.tar.gz
+Finance-Quote-1.17.tar.gz
Index: perl-Finance-Quote.spec
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-11/perl-Finance-Quote.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-Finance-Quote.spec 26 Feb 2009 16:37:05 - 1.8
+++ perl-Finance-Quote.spec 23 Nov 2009 18:16:01 - 1.9
@@ -1,6 +1,6 @@
Name: perl-Finance-Quote
-Version:1.13
-Release: 3%{?dist}
+Version:1.17
+Release: 1%{?dist}
Summary:A Perl module that retrieves stock and mutual fund quotes
Group: Development/Libraries
License:GPLv2+
@@ -9,7 +9,11 @@ Source0: http://prdownloads.sourceforge.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildRequires: perl(HTML::TableExtract) perl(ExtUtils::MakeMaker)
+# Required for compile tests; no 'online' tests are run during the build
+BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(Crypt::SSLeay) perl(HTTP::Request::Common)
+BuildRequires: perl(HTML::TableExtract) perl(HTML::TreeBuilder)
+BuildRequires: perl(Test::More)
%description
This module retrieves stock and mutual fund quotes from various exchanges
@@ -44,6 +48,13 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Mon Nov 23 2009 Bradley Baetz bba...@gmail.com - 1.17-1
+- Update to 1.17
+- Add extra BuildRequires needed for tests to pass
+
+* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.13-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Finance-Quote/F-11/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 9 Jan 2007 04:38:01 - 1.3
+++ sources 23 Nov 2009 18:16:01 - 1.4
@@ -1 +1 @@
-3619ccb3fb09ed9eebe1941e6cf361c9 Finance-Quote-1.13.tar.gz
+446dba3837ffa395bffdea268824e0c1 Finance-Quote-1.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Local users get to play root?
Benny Amorsen (benny+use...@amorsen.dk) said: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON. It's not a blanket prohibition. (See also opensshd, rsyslog, etc.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
Rudolf Kastl (che...@gmail.com) said: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me. It's a usermode bug in that there's not a wrapper for shutdown (as opposed to halt/poweroff/reboot.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
James Morris (jmor...@namei.org) said: - The local session can now install any signed packages from the Fedora repos: - I think this includes old versions of packages (correct?) Incorrect. MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Old/compat package naming
Lubomir Rintel (lkund...@v3.sk) said: glib1:1.2.10-32.fc11 glib2 2.20.5-1.fc11 gtk+1:1.2.10-68.fc11 gtk22.16.6-2.fc11 Given the history of these, this sounds like way more work to change than it's worth. (They'd certainly have to still provide 'glib2' and 'gtk2' for many years in the future.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: where did window properties go?
Andre Robatino (an...@bwh.harvard.edu) said: If control-center-extra goes away, then install gconf-editor, then under apps-metacity-general, set focus_mode to sloppy. (Thanks to Adam Williamson for pointing this out.) You can do this with gconftool-2, without the need for gconf-editor. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
Colin Walters (walt...@verbum.org) said: Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin. This makes sense to me; but there are details to work out. * Do we have any guidelines on what the policy should be in upstream source? Corresponding Fedora RPMs? No, but we probably should. * Do we have a fedora-default-policykit-policy? polkit-desktop-policy? * How do we get this installed on upgrades? Code in preupgrade? In that case, it gets pulled in as a gnome-session dependency. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Jeff Garzik (jgar...@pobox.com) said: Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions. Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to: - DoS everyone on it - get a root shell -- install whatever they want -- put viruses on - hell, slap in a livecd or USB key and reinstall the box It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS. But really, given that users out of the box can do *far far worse*, I'm not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are tired of bagging tea and want new things to be outraged about. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Jeff Garzik (jgar...@pobox.com) said: This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. PackageKit has only ever been included in destkop package groups. While these groups are enabled by default, they are with the caveat of: The default installation of Fedora includes a set of software applicable for general internet usage. (This was all easily verifyable, if you'd prefer to look, instead of rant.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Eric Christensen (e...@christensenplace.us) said: It's a behavior change, for sure. For people who want to lock down their systems, it's a default they will need to be able to change, and they should have been able to discover it through the normal mechanisms for that. (i.e., the release notes.). It likely should have been discussed when it was introduced - it's obviously not something that's applicable to all usage cases for the OS. You are assuming that the users have physical access to the box and also know how to get a root shell and that the box hasn't been hardened (before the PK vulnerability was known). Sure, I said 'out of the box'. Out of the box none of those other hardening steps are done either, which is why if this is a policy that we want, it should be documented as a hardening step that can be taken. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Jeff Garzik (jgar...@pobox.com) said: This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. PackageKit has only ever been included in destkop package groups. While these groups are enabled by default, they are with the caveat of: The default installation of Fedora includes a set of software applicable for general internet usage. Completely irrelevant, because... setroubleshoot and other useful server tools REQUIRE PackageKit. You mean the tools which *also* aren't ever installed except in desktop groups? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCO ticket#270 - preupgrade and F-12
Toshio Kuratomi (a.bad...@gmail.com) said: There are definitely workarounds available, but none that meet the criteria for preupgrade as an effortless upgrade option. So I'm a bit confused by what is so hard here. preupgrade starts up, finds it can't store stage2, and then tells you that you'll need to have a wired connection to the internet if you want to use it. So you have to download stage2 when you reboot and you have to cart your laptop over to the router to plug it in while it does so... it's not like I'm going to be using it for work while anaconda is running Basically, the case where it fails is when there's enough space to download stage2, but not enough space left after downloading stage2 to do the upgrade. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
Daniel J Walsh (dwa...@redhat.com) said: On 11/04/2009 01:38 PM, Bill Nottingham wrote: Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. That sounds like a reason to not ship seedit. Am I missing something? Bill I would not ship it. Is there a schedule for when seedit will be able to function in a non-destructive mode? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are conflicts in debuginfo packages OK?
Frank Ch. Eigler (f...@redhat.com) said: I'm guessing that we don't offer them multilib means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts. Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel. Not unless someone changes the layout of debuginfo entirely, as they use common paths: /usr/src/debug/source tree name /usr/lib/debug/usr/bin/... Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
intent to retire: kudzu
I'd like to retire kudzu for F-13. Why? - There are places where it almost certainly does not work with current kernels - It's so deprecated that one of its replacements (HAL) has since been frozen and deprecated - Given that, its upstream is very dead However, it is still being required by two programs: - hwbrowser - fwfstab If someone wants to keep it limping along for thsese two programs I can orphan it. But I'd really rather just retire it. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. That sounds like a reason to not ship seedit. Am I missing something? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
Eric Springer (erik...@gmail.com) said: It's probably abusing the system and breaks a million guidelines, but what about making a no-offensive-packages package that explicitly conflicts with a list of offensive packages? I suspect the problem with that is attempting to determine a universal concept of 'offensive'. Heck, we might have no-offensive-packages-kde that conflicts with 'gnome-*', and no-offensive-packages-gnome... Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
Darryl L. Pierce (dpie...@redhat.com) said: You're correct in that removing the KDE group attempts to remove the NetworkManager-gnome rpm. I remembered uninstalling KDE also removed NetworkManager-gnome which borked my laptop until I re-installed the RPM. That's something that should be fixed. I believe the documented solution is 'groupremove is bad and does not usually do what you want', FWIW. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the mass rebuild and i586 rpms?
Orion Poplawski (or...@cora.nwra.com) said: I just rebuilt: itcl-3.4-5.fc12 - no changes from original failed rebuild irda-utils-0.9.18-10.fc12 - added a minor patch to fix install issue xfconf-4.6.1-4.fc12 - added missing BRs Does it make sense to tag them into F-12 at this point? Wouldn't hurt - send tag requests. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20091016 changes
Rawhide Report (rawh...@fedoraproject.org) said: sugar-toolkit-0.86.1-1.fc12.i686 requires python-json This was a tagging mixup. It will be fixed. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
Steven James Drinnan (ste...@scc.hk) said: I will file a ticket. But my point was the image of Fedora.Does Fedora want be associated with software vendors that use this type of language? There are worse things in the package collection, alas, depending on your point of view. In any case, gestikk is not installed by default, and is not listed in a group to be selected in the GUI. If upstream maintains this sort of attitude towards the strings they ship, I'm fairly sure it never will be installed by default. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
Ahmed Kamal (email.ahmedka...@googlemail.com) said: Also the rawhide db itself. A guaranteed 8-12 megabyte download usually swamps out any saving from presto (barring changes to eclipse, kernel and openoffice). Why aren't we rsync'ing that 12MB db, instead of re-downloading ? Wasn't there some web friendly rsync fork rsync over http/ftp? We don't really have that. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
Jeffrey Ollie (j...@ocjtech.us) said: I was wondering what the consensus on switching to native Upstart scripts (/etc/event.d/*) vs. keeping the traditional SysV init scripts (/etc/rc.d/init.d) for daemons was? I was looking at switching Asterisk over and have an Upstart script that seems to work fairly well. I would be making the change for F-13... 1) Likely for F-13 we're moving to upstart 0.6.x. This will likely require changes (if nothing else, to the script location), so you're best holding off until after then. 2) We currently have no mechanism for the following: - not starting services automatically that happen to have jobs installed (i.e., chkconfig service off) - enforcing dependencies between SysV and upstart scripts - if a package that provides a service that a SysV service depends on (via LSB headers) changes to an upstart script, things go wrong. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik (jgar...@pobox.com) said: But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has very few users. This is demonstratable by smolt stats and download stats. - ppc has declining hardware availability, unless you're counting increased scavenging via dumpsters. - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. In essence, if the bug doesn't affect the build or install environment, it *doesn't get noticed*, in most regards. Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated an ability to detect problems not found on LE, it seems like this policy change will directly lead to missed bugs, and an attendent decline in software quality. If you feel that this is the case, *step up and join the PPC secondary arch effort*. They could use the help. But I don't see the logic in making Fedora a charity case. As to the RHEL argument, well, that's a RHEL problem. If Red Hat (or anyone, really) feels that it's worth a significant effort to have an up-to-date, maintained, PPC tree, then they should pony up for that effort. Saying Fedora should do this! and not providing real resources to accomplish that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: New deltarpm -- who do I talk to about testing?
Toshio Kuratomi (a.bad...@gmail.com) said: I have a new deltarpm package built for the rel-eng repo: http://koji.fedoraproject.org/koji/taskinfo?taskID=1721745 I can put it into the rel-eng repository to update the servers but who do I talk to about testing it? We'll also need approval to brakinfra change freeze to deploy it once it's tested. If it's in rawhide, it's already being tested to produce rawhide deltas. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New deltarpm -- who do I talk to about testing?
Toshio Kuratomi (a.bad...@gmail.com) said: I can put it into the rel-eng repository to update the servers but who do I talk to about testing it? We'll also need approval to brakinfra change freeze to deploy it once it's tested. If it's in rawhide, it's already being tested to produce rawhide deltas. Cool. So is the deltarpm rpm in the releng repo: http://infrastructure.fedoraproject.org/releng/SRPMS/ just extraneous? No, that's used for composing updates. I know, it's weird to have different systems for different releases. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson (ste...@redhat.com) said: Right or wrong.. I took Final Feature Freeze as the last chance of getting a feature into F12.. And I will be the first to admit I do not read all the rule and regulations of all the steps of a release... I look at dates.. When is the alpha and when is the beta. After a beta release I don't even try to get anything new in, just bug fixes... http://fedoraproject.org/wiki/Releases/12/Schedule 2009-07-28 Feature Freeze--Planning Development Ends Are we actually exporting that different elsewhere? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
Andre Robatino (an...@bwh.harvard.edu) said: If I understand correctly what the problem is - that successfully xz-uncompressing a file requires being on the same endian arch as the one it was compressed on - that's just wrong. It shouldn't be platform-dependent at all. That is not the issue. There are two issues: - Compressing a file on different arches, while it produces output that any arch can decompress, does produce *different* output. - Compression of xz is not fast. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
Jonathan Dieter (jdie...@gmail.com) said: The second one has to do with the fact that when rebuilding the rpms, we have to recompress the data, and xz compression is over 10x slower than gzip. Stats of the day... I took an existing xz-compressed RPM, and built a newer release of that package with varying xz levels. The numbers are: - the new package size at that XZ compression level - the time to create a new deltarpm from a delta to that new version level 1 1416k real0m0.935s user0m0.893s sys 0m0.036s level 2 952k real0m0.839s user0m0.790s sys 0m0.048s level 3 848k real0m2.762s user0m2.702s sys 0m0.055s level 4 832k real0m2.902s user0m2.817s sys 0m0.084s level 5 824k real0m3.269s user0m3.131s sys 0m0.128s level 6 812k real0m4.364s user0m4.026s sys 0m0.164s level 7 (what we do now) 812k real0m4.698s user0m4.516s sys 0m0.176s So... just set the xz compression level to 2, let it be that way for future builds, and go about our business? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Josh Boyer (jwbo...@gmail.com) said: Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. I'm not sure how 'simple' that is in the koji configuration. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Josh Boyer (jwbo...@gmail.com) said: I'm not sure how 'simple' that is in the koji configuration. It will have to be done anyway, yes? Well, that would involve disabling all ppc builders for a release entirely, which is much simpler. But this isn't the right list anyway. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Jonathan Dieter (jdie...@gmail.com) said: He did bring up some other very good points, though. Xz's compression output hasn't been set in sand, much less stone. The file format will stay the same, but the same command-line options may result in different compressed files. ... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
Aditya Patawari (adi...@adityapatawari.com) said: How would this be different from each LiveCD group just targeting a DVD size and changing their spin appropriately? Actually instead of increasing the size and getting a cluttered install, I am planning to include an internal repository. After installation end user will get the normal live cd stuff and an inbuilt repo which can be used to install packages as per the need. It will reduce the need of internet and will also increase the package installation speed. ... how is that significantly different than what we have now? Now: - user downloads DVD iso - user picks from arbitrary set of software - additional software can be selected from network - user installs New: - user downloads DVD live iso - user partitions, has to include space for all other software on DVD (!) - user installs - user reboots - user can pick from arbitary set of software to add on - additional software can be selected from network How is this better? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Jonathan Dieter (jdie...@gmail.com) said: ... in what way does he mean this? Obviously passing -1 ... -9 causes different output, much like it does in gzip/bzip2/etc. He means that the file generated using -5 in the future may be different than the file generated using -5 now. As long as that file is decompressible by older versions, then it's only a deltarpm issue. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
John Reiser (jrei...@bitwagon.com) said: If I had relied solely on Rawhide report, then there would have been no progress from Tuesday morning to Thursday evening. The delays in rawhide had nothing to do with the new gcc, FWIW. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 Snapshot 1 available
Fedora 12 Snapshot 1 is now available for testing. These snapshots consist of live images only. Available at http://torrent.fedoraproject.org/: Fedora 12 Live Snapshot 1, for i686 and x86_64 Fedora 12 Live KDE Snapshot 1, for i686 and x86_64 Available at http://spins.fedoraproject.org/: Fedora 12 Live LXDE Snapshot 1, for i686 and x86_64 Fedora 12 Live XFCE Snapshot 1, for i686 Please report issues in bugzilla. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
Hans de Goede (j.w.r.dego...@hhs.nl) said: The fact that it wasn't turned on at Alpha means it really shouldn't be on now, not without FESCo approval. That is interesting reasoning, first keep it out of Alpha even though it was ready as you were afraid it would delay the Alpha further (although there were no open bugs) and no now use that to also keep it out of Fedora 12 entirely. I agree - certainly, there has been nothing raised to FESCo yet to disable it, and it was not removed from the feature list in any FESCo discussion. That discussion can certainly be had if someone wants to raise it to FESCo. We've got some licensing concerns with a pre-generated binary blob of bits from other packages being shipped with the kernel package, and the kernel srpm doesn't have any sources to match those binary blobs. We already do the same with the stage1 and stage2 images of anaconda. The initrd is just a cpio archive, like the livecd images are just an iso, it is all mere aggregation. The issue is that stage1/stage2 are generated at *tree* build time, and therefore are guaranteed to match the tree (and source RPMs) we ship. As dracut images are currently built at *kernel* build time, that is not the case. Moving to building initramfs at kernel install time would solve this. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
Hans de Goede (j.w.r.dego...@hhs.nl) said: It really is like having to support gentoo, versus having to support a distro using pre build packages. And I would really like to move to the having to support a pre-build package model for the initrd. The problem is this: The kernel binary RPM contains this pre-built initrd. The kernel source RPM does not contain the sources necessary to make this pre-built initrd. This makes me rather uncomfortable from a Licensing perspective. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Not really. In the case of initrd-built-with-kernel, it could be packages in the buildroot that never leave koji for release/updates, and are then garbage collected. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20090903) FESCo meeting
The following is a list of topics to be discussed at tomorrow's FESCo meeting, at 17:00UTC in #fedora-meeting on irc.freenode.net 243 New entry of 'Build packages for which Fedora is upstream for all language translators' review correction' for F12 schedule 238 Can libvdpau go in Fedora? 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. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Directory draft (was Re: Triggers just to avoid unowned directories?)
Michel Alexandre Salim (michael.silva...@gmail.com) said: Multi-ownership seems *far* preferable to me than using triggers to move files around, or moving a prelink-specific directory to the base filesystem package. Then the guidelines should be fixed to create less confusion over the matter. Another precedence is with bash-completion -- the consensus is for packages that provide completion scripts to own /etc/bash_completion.d OK, I've written up the following, which should be more clear: https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft Comments? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fedora-packaging] Re: Directory draft (was Re: Triggers just to avoid unowned directories?)
Toshio Kuratomi (a.bad...@gmail.com) said: Section 1.3 Optional functoinality is a special case of Section 1.5 Common directory without one requiring the other. I'd combine them like this: I've updated the proposal based on this and other feedback. And one more idea to throw out there: How sacred is filesystem? How costly are adding new directories to it? For something like /etc/prelink.conf.d, adding to filesystem seems like the preferred option. If there's little cost involved, adding to filesystem for things like /etc/bash_completion.d also seems like the preferred solution. If there's no reason we shouldn't be expanding filesystem, I'd list that as an option in the directory draft as well. My main objections would be: 1) filesystem started out as just the FHS dirs 2) We don't want a bunch of orphan directories if things like prelink change 3) We don't want to tie package submission on changes that would require updates on unrelated packages in older distributions. It's a combination of philosophical (#1) and practical (#2 and #3) concerns. We could expclitly state this in the draft if you want. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pkgs in rawhide which are obsoleted by something in rawhide
Seth Vidal (skvi...@fedoraproject.org) said: Working on something else I stumbled across this: http://fpaste.org/jDwM/ that's a list of pkgs in rawhide which are obsoleted by something else in rawhide. seems a bit dodgy to me. Can you file bugs? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Triggers just to avoid unowned directories?
Robert Relyea (rrel...@redhat.com) said: triggers were the suggestion of the package reviewer to avoid multi-ownership(IIRC). If there is unanimity on what the correct solution should be, I'm sure Elio would be happy to implement it. Moving /etc/prelink.conf.d to filesystem would obviously be the simplest for the nss package. Multi-ownership seems *far* preferable to me than using triggers to move files around, or moving a prelink-specific directory to the base filesystem package. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
Peter Robinson (pbrobin...@gmail.com) said: On Thu, Aug 20, 2009 at 5:30 PM, Bill Nottinghamnott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: I would like to add a group for the Moblin Desktop. My proposed patch is below and feedback is welcome. ... this seems small. There are no other apps required? Yes there are. I haven't added them yet as I wanted to get the group in first. Might as well add them in, I'm not sure there's a benefit to waiting. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 to require i686, but which CPUs do not qualify?
Joachim (joachim.frie...@googlemail.com) said: Moreover, it is even pulled in by basic packages like gnome-games (!). Well, you know, if you want to play sudoku, you *need* a linear algebra package. (See earlier threads about numpy dependencies in pygtk.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firefox SELinux bug from Alpha Blockers meeting.
Mathieu Bridon (bochecha) (boche...@fedoraproject.org) said: I just wanted to know if I should open a new bug report for Epiphany as SEAlert got confused or if it is indeed the same bug, in which case I'll be patient. See bug 516057. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: UTF-8 specfiles, better upstream tarball commits coming
Ville Skyttä (ville.sky...@iki.fi) said: I ran a few scripts on the CVS tree and will commit the resulting improvements in a few days to devel and rebuild changed packages if ACL's allow. Let me know if you for some reason don't want your packages touched (affected package lists below). If I may ask - is there a reason to do rebuilds? Given that there's no functional differences, isn't having the changes in CVS for the next rebuild 'good enough'? Packages that may have a better upstream tarball available: --- (not necessarily all of these will be touched) ... lzma ... I'd assume this would not be changed, for bootstrapping reasons. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: I considered IT might be redundant information, too, when I created the groups, but also both the terms Forensics or Wireless are not IT specific, therefore I put the IT-security explanation into the description. There can be wireless analysis that is not security related, e.g. to find sources of disturbance and there are a lot of forensics tasks that are not IT-security related, but still could be assisted via software. Rather than going back and forth about concepts, I might as well just describe how I would organize what you have now: network-debugging - Network Analysis Tools - Tools for analyzing and securing computer networks. (This would include the packages from both your proposed 'reconnaissance' and 'wireless' groups, as well as some other tools currently in 'System Tools'.) forensics - Computer Forensic Tools - Tools for performing computer forensics and data recovery. (I'd move the password tools here, as well. Not sure how clamav fits here; I think its current placement at the mail server level makes more sense.) The intrusion detection group looks OK as a concept. As for the code analysis group, I'd argue that should be moved into the development category. Is this something you'd find usable? Additional groups under Base System, not sub-sub-groups. This is no solution to grouping the packages together and still be able to know which packages are for which sub group of tasks. Btw. these tools to also not build a base system or at least what I would think of a base system, because their use case is for certain special tasks and does not form a base for other tools to build on, e.g. cron performs a base set of features that can be used by other packages. But this might not the criteria for packages in the base system category. Right now our toplevel groups are: - Language support (self explanatory) - Desktops (fairly self explanatory) - Applications (End-user desktop applications) - Development (tools for software development) - Servers (various system services) - Base system (administration tools, and other components) Perhaps a better solution is a new toplevel category of 'System Administration' (where most of your new groups would fall under); this widens the scope of it from just 'IT Security' to a larger scope that fits the existing categories. That might be a larger reorganization, though, as the group changes would have to filter down to the various spins. - the 'all packages are default' paradigm I could accept to make packages not default that are e.g. already meant to be deprecated by upstream, like airsnort. But I do not think that the audience of these tools would only want to be presented some random password cracker like it is a guideline to have only one IM client on the Fedora Desktop live image. This is also reflected with the package set of the security live image, which also contains all these tools and not only selected ones. Sure, but the live spin can do %group --optional to pull those in. To expand on what I said before, we have three main concepts for applying defaults in comps: - Lots of tools that occupy the same usage case (office tools, etc.) Pick one best-of-breed default, the rest are optional. - Lots of tools that occupy the same space, but are not interchangable. (games) Everything's optional. Pick what you want. - A basic usage case, with various add-ons and similar tools. (many of the server groups, 'system tools', etc.) A base set that's default; other tools are optional. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Jesse Keating (jkeat...@redhat.com) said: Ralf, this entire service is informational only. Maintainers don't need to do anything with this information, particularly if it isn't being filed as bugs and only provided on a webpage. They can simply ignore the information or even pretend that the website doesn't exist. The opt-out that Till is talking about is that by default, his service would manage every package it is capable of. A maintainer would have to opt-out of having their package monitored. But again, even if the package /is/ monitored, they don't have to do anything with that information. There is no bureaucracy here, just potentially useful information a maintainer can choose to look at or not. My concerns are twofold: - BZ seems the wrong place. It's the only push mechanism we have other than raw e-mail, though. - Not to generalize too much, but we have maintainers: - who maintain only a few packages Likely, these people are already plugged into their upstreams and don't need the extra notification. - who maintain a lot of packages (woo, 100 perl modules) These people are more likely to need it. Which of these groups do we want to optimize for by default? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. No, it's not just in the description. These tools can be used to perform IT security related wireless auditing. In this example, IT security related (aside from missing a hyphen or two) is completely superfluous. I don't understand what you want to say with password recovery is password recovery. There is nothing to argue about, but nevertheles the groups are related to each other, How so? aide is not really related to password recovery at all, at least not in any generally describable way. already expresses itself that they are all on the security spin. Also it allows other people to easier ignore them, instead of cluttering other categories. Put it this way: - These packages are all in other groups under 'Base System' - Ergo, if they're being grouped together, the resulting group should still be under 'Base System' Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Peter Robinson (pbrobin...@gmail.com) said: From the sidelines it seems that there is a confusion on what the % actually means. Some think that 100% means ready to be tested and others think that 100% means It's been tested, the final builds are in and all known and cared about bugs are fixed. My understanding was the later. All working tested and ready to go. What is it meant to mean. Yeah, I think this is sort of an issue with pushing everything down to a simple number. In my view, '100%' would mean I'm done with this, and not touching it modulo bugs. It can have a lower percentage and still be testable. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
'IT Security' in comps? (was Re: comps comps-f12.xml.in,1.71,1.72
Recently, you've added the following groups to comps: it-security-code-analysis it-security-forensics it-security-intrusion-detection it-security-reconnaissance it-security-wireless it-security-password-recovery You've also added a new toplevel category. This means this new nebulous 'IT Securty' item is pushed at the toplevel, much as 'Desktops' or 'Language Support'. That seems misplaced to me. While I know that we do allow some discretion in adding to comps, none of this was discussed beforehand on this list (that I saw), or in FESCo. These sorts of large scale changes are the sorts of things that should be discussed. What is the overall goal of these changes? Why isn't this just done via a menus package in the security spin? Wouldn't that be more useful? Many of these packages are *already* in other groups; having them now be explicitly listed in multiple groups doesn't really make sense to me, especially when we already have 'Administration Tools' and 'System Tools' groups. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: You've also added a new toplevel category. This means this new nebulous 'IT Securty' item is pushed at the toplevel, much as 'Desktops' or 'Language Support'. That seems misplaced to me. How can I bundle the groups, if not with a category? Or can there be subcategories? I'm not sure they need to be bundled. Especially with 'IT' as a prefix; code analysis is code analysis; password recovery is password recovery. There's also ongoing work on package tagging that may fit better for more finer grained usages such as these. I asked on this list and got a reply from Jesse Keating: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02292.html My mistake. Why isn't this just done via a menus package in the security spin? Wouldn't that be more useful? No, because this does not help me with my search from yum. Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Btw. this is true for other package groups, too. E.g. we have a KDE spin and a KDE group in comps. Sure, but KDE is a much broader use case. I feel that the groups as you defined them are probably too fine grained. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
drago01 (drag...@gmail.com) said: (done that for you http://koji.fedoraproject.org/koji/taskinfo?taskID=1574035 ) I see. I guess they'll let you and/or me know if this wasn't the right thing to do. Well rel-eng did the mass rebuild and give us a list of the failed packages, fixing them does not create extra but _less_ work for them ;) Exactly; while rel-eng *could* resubmit failed builds, and may submit some at some point, we are perfectly happy not to have to, and doing so will speed things along in general. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mailing list migration procedures
Jon Stanley (jonstan...@gmail.com) said: I'd like some mailman experts (if we have any) to take a look at this procedure to migrate lists from redhat.com to lists.fp.o and let me know if there's something obviously missing from it or if there's some way that it can be improved. Feel free to make any edits you deem necessary. https://fedoraproject.org/wiki/Mailman_Infrastructure_SOP#Mailman_migration My concern is more procedural than infrastructural - I'd like to make sure we schedule the mass migration in such a way that it does not heavily disrupt development schedules; generally, this would mean doing it sometime after a release but before the alpha of the next release. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suggested new Group in comps
Robert Rati (rr...@redhat.com) said: Right now condor is not listed in the comps file, so isn't available to install from kickstart (as I understand it). That is incorrect. All packages are available from kickstart, regardless of their status in comps. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggested new Group in comps
Robert Rati (rr...@redhat.com) said: So comps just controls the list of packages available in the GUI? Correct. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFC PATCH] Disable alsa snd-pcsp driver
Because ... why would you want to use this? Ever? Bill ? diff ? kern.diff ? linux-2.6.28.tar.bz2 ? patch-2.6.29-rc8-git6.bz2 ? patch-2.6.29-rc8.bz2 Index: config-generic === RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v retrieving revision 1.314 diff -u -r1.314 config-generic --- config-generic 28 Jul 2009 13:35:42 - 1.314 +++ config-generic 29 Jul 2009 14:52:04 - @@ -2659,7 +2659,7 @@ CONFIG_SND_NM256=m CONFIG_SND_OXYGEN=m CONFIG_SND_RME32=m -CONFIG_SND_PCSP=m +# CONFIG_SND_PCSP is not set CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME96=m ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Updated Fedora 12 Schedule (take 2)
Mark McLoughlin (mar...@redhat.com) said: http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng.ics In the F-11 schedule, we had 85 days between Feature Freeze and GA. And then GA slipped by two weeks. In the F-12 schedule, we now have 99 days between Feature Freeze and GA. This seriously cuts into development time, and we already have a shorter releases cycle. Why is that? At least one week of this (that I recall) is to have the feature freeze be a week before the 'code freeze' for the milestone; the idea is that to avoid the 'all features land at once, and we have to spend a week cleaning them up' problem. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mass rebuild slightly delayed...
... as we sort through some toolchain issues. It will start as soon as reasonably possible. Bill ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for Fedora 12
Axel Thimm (axel.th...@atrpms.net) said: if I touch a package today, would it need to be rebuilt, and if not, would I need to create the noautobuild file? Any package that builds after redhat-rpm-config-9.0.3-12.fc12 is added to the buildroot is OK. This has not happened yet. (waiting on a newRepo task.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for Fedora 12
Axel Thimm (axel.th...@atrpms.net) said: could this be automated in a way that if a package is built after that it doesn't get tagged for the mass rebuild? This will get covered, yes. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mass rebuild for Fedora 12
Fedora Release Enginerering is going to be starting a mass rebuild this Thursday, July 28th, for the following Fedora 12 features: - XZ RPM Payloads - x86 Architecture Support Just as in the Fedora 11 mass rebuild, if you'd like to opt out for your packages, check a file into your package's devel/ branch, named 'noautobuild'. This file should contain a short rationale of why you wish to do the build yourself. Note that if you do not do a rebuild during the timeframe before Alpha, one will be done regardless of the presence of this file. Also note that delta RPMS will be disabled in rawhide for the duration of this mass rebuild; delta rpms across payload format changes in RPM are not useful. For more information, see: https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for Fedora 12
Bill Nottingham (nott...@redhat.com) said: Fedora Release Enginerering is going to be starting a mass rebuild this Thursday, July 28th, for the following Fedora 12 features: That would be Thursday the 23rd, as per the web page. - XZ RPM Payloads - x86 Architecture Support Bill ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] build a 'full' package on i686
Dave Jones (da...@redhat.com) said: +# We only build -PAE on 686. %ifarch i686 -%define with_up 0 %define with_pae 1 %else %define with_pae 0 The naming of 'with_up' is subtle here. With this change, we'll try building a '686' kernel as well as a '686-PAE'. That was the intent, as the i586 package would be going away. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
