Re: Removing %clean
Till Maas writes: >> Tom "spot" Callaway wrote: >> > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ >> > mkdir "$RPM_BUILD_ROOT"\ > It prevents a race condition in case that $(dirname "$RPM_BUILD_ROOT") > already > exists or if all directories in the path to this directory are only writable > by trustworthy users. In the default configuration, this was the /var/tmp > directory, where every user could create a directory, make it writable for > others and sneak content into the final rpm. The two mkdirs are in reverse order though. Is that intentional? /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
Robert Marcano writes: > I think you are right about x86_64 probably is going to have a DVD > Rom, I only have needed the CDs when installing i386 servers isolated > from the internet. I think we should start considering the option to > ship the net install ISO as a hard disk image to be used for USB boot, > I frequently install systems without optical media and that conversion > step (ISO to HD) is not intuitive for all users Indeed, if Fedora cared about 2% of users then there would be an USB install/upgrade option. Since there isn't one, PXE will have to do, but that isn't likely to fly for the inexperienced user. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Much improvement for minimal installs
I just want to say thanks for improving the minimal install so much in Fedora 11. Now I can remove: *dbus* wireless-tools *dhcp* and lots of other things. To all those who made this possible: Thank You! /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: xterm terminfo spec change in ncurses
Miroslav Lichvar writes: > On Fri, Jun 26, 2009 at 03:58:59PM -0500, Michael Cronenworth wrote: >> The application is hardcoded to look for pre-2009 xterm sequences. >> Particularly the ^[O2S style sequences. It does not use ncurses at all. > > That's bad. Do you have the source code? Adding few tigetstr calls > should fix it. If the xterm escape sequences are changed, remote sessions between old terminfo and new xterm or the other way around break. That is highly undesirable. You can get around it by changing the terminal name for xterm, but then you need to distribute new terminfo files to all Unix computers in the world. No fun. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson writes: > To bring it back to where we came in, we have a problem in that the KDE > team are following one policy (update to the latest KDE release on the > basis that it brings in new shiny goodness and fixes more stuff than it > breaks) while the GNOME team are following the other (don't go to the > latest point release in the interest of consistency). This doesn't make > sense The KDE packagers have decided that KDE is good enough at avoiding regressions that upgrading from 4.2 to 4.3 is reasonably safe. (Or alternatively, that KDE 4.2 was so bad that 4.3 could only be an improvement.) The Gnome packagers have the opposite views of Gnome. Those 2 views do not conflict, and even if the teams were using the exact same criteria, they could still come to those conclusions. You can only call it inconsistent if KDE and Gnome have exactly the same release policy and exactly the same history of bugs (or the absence of bugs). This is clearly not the case. /Benny -- 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
Kevin Kofler writes: > That newsgroup is the Gmane gateway to this very list. Blame Gmane for not > properly translating the Reply-to when injecting messages to the mailing > list. If you reply to mail instead of to the news group, you should get the desired effect. I'm doing it right now in Gnus. Of course it would be even nicer if the Reply-To was gone too, but I can just add broken-reply-to in my Gnus settings for this list as a workaround. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Asterisk - attached patch needed to enable build in Rawhide
Jeffrey Ollie writes: > I plan on getting an update to Asterisk out ASAP, but it's taking > _forever_ to rebuild the git repository that I use to maintain the > various patches. I'll do a quick rebuild with the attached patch so > I'm not blocking the openssl update. Is it really worth maintaining a significant amount of patches? With my private build of 1.6.1.6 I currently use these patches: Patch1: 0001-Modify-init-scripts-for-better-Fedora-compatibility.patch Patch2: 0002-Modify-modules.conf-so-that-different-voicemail-modu.patch Patch5: 0005-Build-using-external-libedit.patch Patch6: 0006-Revert-changes-to-pbx_lua-from-rev-126363-that-cause.patch Patch8: 0008-change-configure.ac-to-look-for-pkg-config-gmime-2.4.patch Patch10: 0010-my-guess-as-replacements-for-the-missing-broken-stuf.patch Patch11: 0011-Fix-up-some-paths.patch Patch12: 0012-Add-LDAP-schema-that-is-compatible-with-Fedora-Direc.patch I have changed some of the patches a little compared to the 1.6.1rc1 versions, just to make them apply. I have removed chan_mobile; if upstream prefers it to be in asterisk-addons, it seems a bit futile to keep trying to patch it in. I should probably drop Patch 6; if upstream hasn't dropped it in 6 months then it's probably something we have to live with. Not that I use Lua. Patches 2, 5, 8, and 12 ought to go upstream... /Benny -- 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
Colin Walters writes: > I'd imagine that running the "live Anaconda" UI from inside the GDM X > session wouldn't take significantly more resources than the Anaconda > OS after creating an image that doesn't have games, etc. Images sound significantly more difficult to create and maintain than kickstart-files. I would really hate to lose kickstart. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anaconda multiple Ethernet cards question
Aioanei Rares writes: > I think it would be niftier if the identification string of the card > was printed also (eg VIA Rhine III) so people would know what card to > choose and how. For extra points, add a "identify nic" button which blinks the LED's of the appropriate nic. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Jesse Keating writes: > And that's a people problem more than a process problem. If nobody > tests it in updates-testing, then how is the maintainer to know that it > is problematic? Certainly not solvable with even more repos for testing > content... I ran updates-testing for a while, but it didn't result in me writing any bug reports. I wasn't particularly aware of whether a package came from updates-testing, so that it was worth spending a little bit of energy testing that particular package. Would it be possible to make a little application which pops up on login or every day (whichever comes first) saying "These applications are new in updates-testing, would you like to help testing one?". Then you could pick one and give it a try, and perhaps a few days later there would be a pop up asking how it went? Strictly opt-in, of course. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
Bruno Wolff III writes: > Postgres isn't even updatable. You need to do dumps before doing the upgrade. > So downgrades aren't too much worse than upgrades. (Though the new dumps > might use new features that will need to get modified to make them readable > by old versions.) Note that there is experimental support for in-place upgrades in PostgreSQL 8.4. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Font rendering slightly degraded in recent rawhide
Matěj Cepl writes: > I don't think we should back progress in order to be friendly to buggy > closed Microsoft fonts. I know they are quite common outside of the > Linux world, but I think > > a) our free fonts are now so good, that we could limit ourselves to > this FSF-nirvana ghetto, it doesn't cost that much, > b) many modern fonts (e.g., my preferred Inconsolata) just rely on > real hinting being present, and it doesn't work that well with > auto-hinter. Just because of this font, I have switched to > freefont-freeworld and I cannot be more happy with it. It would be nice if fonts like Inconsolata somehow set a flag that they require hinting. This would prevent the side effects on old fonts. Your post prompted me to try out Inconsolata in F11. I do not find the Inconsolata hinting all that impressive though. No hinting at all is indeed horrible. With full hinting, the "g" gets deformed on my screen, where it is quite good with medium hinting. The vertical stroke in the "a" is quite wide and distracting no matter which hinting is chosen. Back to DejaVu Sans Mono Book. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
Kevin Kofler writes: > This is, sadly, intentional. I and others have been complaining about this > for months, we got ignored, all in the names of making things work for > people who are not smart enough to figure out whether their computer is 64- > bit or not. The argument that almost all new non-netbook machines are 64-bit > anyway also got ignored. If only the 32-bit version was smart enough to install a 64-bit kernel when appropriate, this would not be such a disaster. Running a 32-bit kernel with 4GB of memory is asking for trouble, and machines with 4GB are probably as common as netbooks. 32-bit or 64-bit userland doesn't make such a difference. /Benny -- 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?
Seth Vidal writes: > 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. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
Kevin Kofler writes: > (and not really implementable for the live images) Why not? It should be reasonably easy to handle that in the boot loader. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
Kevin Kofler writes: > If we don't want to live in the past, we should go away from 32-bit, not > from CDs. ;-) Doubling the download size for everyone is a bad solution. An extra kernel shouldn't be that big a problem. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Nathanael Noblet writes: > However the setup/configuration of postgreSQL compared to MySQL is > basically something easy, versus something where I don't have a clue > what is going on, and there are million ways to do it, and when I'm > done I have no idea if I'm wide open to the entire world, or as secure > as on MySQL. We're on a Fedora list here. Setting up PostgreSQL consists of doing yum install postgresql-server, chkconfig postgresql on, service postgresql start. That will give you an installation with quite reasonable defaults including Unix-socket connectivity. Of course then you discover all the PHP toys written for MySQL which can't be told to connect a) by Unix sockets and b) without a username and password. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
