Fwd: Power Managemet Testday 22. Oct 2009
Original Message Subject:Power Managemet Testday 22. Oct 2009 Date: Thu, 22 Oct 2009 03:04:12 -0400 (EDT) From: Jan Scotka jsco...@redhat.com To: Marcela Maslanova mmasl...@redhat.com Hi folks, Today 2009-10-22 is planned next Power Management Test Day. We will be glad to see you all there. For more info: https://fedoraproject.org/wiki/Features/PowerManagementF12 and link to today testday: https://fedoraproject.org/wiki/Test_Day:2009-10-22 please join #fedora-test-day on freenode irc From 12:00 to 21:00 UTC (8am - 5pm EDT) and append your results. Regards Honza -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
On Wednesday 21 October 2009 23:27:31 Adam Williamson wrote: On Wed, 2009-10-21 at 15:16 +0800, Liang Suilong wrote: Today I upgrade my Fedora to Fedora 12 Beta, It looks very well. But I found ATi display driver does not run well. My display card is Sapphire HD3650 with 256MB GDDR3 VRAM (RV635). I choose OSS driver for my card. Glxgears runs so smoothly with xorg-x11-drv-ati because of KMS by default, nevertheless, rolling up and down in the gnome-terminal is quite slow. The performance of glxgears is about 210 frams per second. In addition, Switching to another window in Fedora 12 Beta is not as fast in Fedora 11. Later, I install xorg-x11-drv-radeonhd and set it by default in the system-config-display. Then I restart the X. I can not log into gnome. The screen turns white. I found xorg-x11-drv-radeonhd is too old, The version is 1.2.5 in the rawhide and the latest version 1.3.0 has been released for a long time. Now I turn back to xorg-x11-drv-ati. At last, I do not know which packages causes the problem, maybe xorg-x11-drv-ati, maybe xorg-x11-drv-radeonhd, maybe Mesa. So I suggest that packager updates some packge related to ATi R600/R700 display card. Fedora doesn't really care about the radeonhd driver. We may well even remove it at some point soon. The ati driver is the one you should use on Fedora, that's why it's the default. You do not get 3D acceleration out of the box on that card, r600 3D acceleration is too early to be enabled by default. If you want to try it out, install the mesa-dri-drivers-experimental package. For the slow 2D performance - _how_ slow is it, really? gnome-terminal has never been much of a speed demon. Does it get any faster if you boot with 'nomodeset' as a kernel parameter? Hi, I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic card, I was going to file new bug. With kms enabled, everything is really slw, with 'nomodeset' it's much faster. I can't say exactly how slow it is, is there anything I can use for measuring? Michal btw, mesa-dri-drivers-experimental does not work at all for me (glx apps segfault) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Beta
Dne 21.10.2009 23:35, Adam Williamson napsal(a): 4 - F12 boots really slow on my laptop http://www.stardust.webpages.pl/files/tmp/bootchart.png something wrong is happening while udev loading I have filed a bug https://bugzilla.redhat.com/show_bug.cgi?id=528312 ... if you run udevadm monitor --env while udev is eating your CPU (yes, I know it is tough, I tried many times before I succeeded), who is to blame? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Don't anthropomorphize computers. They don't like it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11 AM EDT)
2009/10/21 John Poelstra poels...@redhat.com: 520750 - PackageKit - ASSIGNED - Software Update windows checks for update does not stop .. This has been reported by one person (no dupes), and I'm still waiting for more information. I suspect it's actually a hardware problem or file-system corruption on the reporters computer. Basically, I don't think this should be a blocker. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: extracting multiple sources in %setup
Le Jeu 22 octobre 2009 09:46, Marcus Moeller a écrit :
is there a way to extract multiple sources in a spec files %setup section?
Something like:
for i in {1..10}; do tar xfz %(SOURCE$i}; done
If you have multiple sources that's usually a sign you're doing something
wrong. It is very dangerous to aggregate sources from different upstreams in a
single rpm (release cycle and legal problems), or to group sources upstream
split (usually for ease of maintenance reasons)
--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: extracting multiple sources in %setup
On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
Hi,
is there a way to extract multiple sources in a spec files %setup section?
Something like:
for i in {1..10}; do tar xfz %(SOURCE$i}; done
Best Regards
Marcus
%setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9 -a 10
should work. I don't if there's any nicer way.
Orcan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
What does it mean package not tagged as an update candidate?
I'm trying to create an update for a new package (mingw32-freeglut, https://bugzilla.redhat.com/show_bug.cgi?id=528892) in F-12, but I get the error below: $ make update [...] Creating a new update for mingw32-freeglut-2.6.0-0.1.rc1.fc12 mingw32-freeglut-2.6.0-0.1.rc1.fc12 not tagged as an update candidate What does it mean? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thursday, 22 October 2009 at 00:07, Tom Lane wrote: Lyos Gemini Norezel lyos.gemininore...@gmail.com writes: Why not just require a secondary email address? Require a secondary email address? Not everyone has one, or wants to hand it over if they do. That sounds more like a recipe for driving maintainers away than making sure you can contact them. How about: Maintainers should provide a secondary e-mail address if their primary address is supplied by their current employer. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unable to download Fedora 12 beta using jigdo
Hi again, I finally managed to create the image by downloading net install .iso image and providing its install.img to jigdo! Good luck, Hedayat On ۰۹/۱۰/۲۲ 03:55, Hedayat Vatankhah wrote: Hi, I'm trying to download F12 beta DVD x86_64 iso using jigdo (I've used jigdo to download previous versions too). It successfully downloaded all files, but it doesn't accept downloaded install.img file and tries to download it again and again. I've tried downloading install.img several times (also using stand alone download applications) but jigdo doesn't accept any of them. As a result, jigdo doesn't compose the final .iso image because of 1 missing file. Does anybody have any ideas about the reason of failure? Has anybody downloaded F12 beta x86_64 using jigdo successfully? Thanks, Hedayat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
Hi, On 21.10.2009 20:10, Toshio Kuratomi wrote: * Should we formalize the unwritten policy for Red Hat maintainers who leave the company and don't want to maintain their packages anymore? * Do we need sanity checks to be sure maintainers who do want to keep their packages do so? I don't think so: in past it was always clear who wants to maintain the package further (at least because the maintainer changed his contact from @redhat.com to some private address). * Do we want something more generic that covers other compaines that pay their employees to package for Fedora? I'd rather set now this policy for RH employees (which will cover 99 % of cases) than discuss anything like secondary mail addresses and various situations which can raise up with other companies for the next month. The RH environment is clear to us and easy for manage to you (I mean there are no actual problems with handling this within RH), am I right? Regards, Milos -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Wed, Oct 21, 2009 at 11:10:22AM -0700, Toshio Kuratomi wrote: * Should we expedite these requests in the future if the email address for the maintainer is no longer in existence? Yes, please. If the mail address of a maintainers do not work anymore, then their packages should be orphaned, so that others can maintain them. If the mail address does not work, then all bug report notifications would get lost and also communication attempts using the package-owner aliases. Therefore it should be made sure there is always someone caring about these messages for each package. * Should we formalize the unwritten policy for Red Hat maintainers who leave the company and don't want to maintain their packages anymore? Yes, unwritten policies are always bad. * Do we need sanity checks to be sure maintainers who do want to keep their packages do so? What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. * Do we want something more generic that covers other compaines that pay their employees to package for Fedora? Does it need to be different than the currently unwritted Red Hat policy? If not, then it could just be the same policy Red Hat can be used as an example, if needed. Regards Till pgpu9CLr9PhC2.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Unreadable binaries
$ ll /usr/libexec/pt_chown -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown $ ll /usr/bin/chsh -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh What is the purpose of making binaries like these unreadable? Originally I thought it was something to do with them being setuid, but there are counterexamples: $ ll /usr/bin/passwd -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd Surely there is no possible secret in those binaries, since an attacker could just as easily download the binary RPMs on another machine in order to find out what is inside them. There's a genuine reason for me asking about this. When we build the libguestfs supermin appliance[1] we would like to be able to read these binaries as non-root. Rich. [1] http://libguestfs.org/README.txt section Supermin appliance -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What does it mean package not tagged as an update candidate?
On Thu, Oct 22, 2009 at 09:26:06 +0100, Richard W.M. Jones rjo...@redhat.com wrote: I'm trying to create an update for a new package (mingw32-freeglut, https://bugzilla.redhat.com/show_bug.cgi?id=528892) in F-12, but I get the error below: $ make update [...] Creating a new update for mingw32-freeglut-2.6.0-0.1.rc1.fc12 mingw32-freeglut-2.6.0-0.1.rc1.fc12 not tagged as an update candidate What does it mean? Probably that has to do with using bodhi for F12 being delayed for a while. You should open a release engineering ticket instead. There was an announcement from Warren about this within the last 24 hours. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Major reorganization of TeX Live packages
Hi, I would like to announce couple of major changes in the TeX Live 2009 repository. The main improvements are: * TL2009 now contains virtual provides to resolve dependencies among .sty files. This assures you have a complete set of other styles installed in order to use one. To install a particular style you can do e.g. yum install 'tex(upref.sty)' and you needn't to know it comes from texlive-amscls package. The exception are dependencies to styles which are either commercial (such as mathtime.sty) or not available from CTAN. These styles were blacklisted and dependency generator ignores them. * Upgradability from older TeX Live 2007 is now improved. You may remember that the biggest problem with upgrading TL is not in TeX Live itself but in utilities around it, like xdvipdfm, psutils, etc. that needs older kpathsea library than shipped with TL2009. I've done some modifications so that starting with texlive-2007-45 and higher, both newer and older libraries can coexist. So you should be able to run your F11 apps linked against old kpathsea together with new TL2009. * a version string was added to noarch packages to allow to upgrade all of the noarch packages even if upstream hasn't done any modifications. This allows me to not to break upgrade path if some major packaging changes are made and these packages need to be rebuilt. * TL packages released under GFSL license are now added. In case you have an older TL2009 installed on your system from the testing repository, please consider removing it and installing again. Thanks, Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
On 10/06/2009 06:29 AM, Adam Williamson wrote: On Mon, 2009-10-05 at 16:27 +0200, Hans de Goede wrote: Thanks for bringing this up. I'll create a patch for the scripts generating the livecd to add rd_NO_LUKS to the normal livecd syslinux.cfg entry. I already was planning on doing this, but I forgot. can you file a tag request to get this into the beta? it's the kind of thing that shouldn't show up in the beta, and we can't fix it with updates. and it's a pretty safe change (just switching a behaviour choice when we know both choices do what they're supposed to). CCing Jesse to accept the request. Hi, This is in rawhide now, must the beta though. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
On 10/22/2009 01:46 PM, Hans de Goede wrote: On 10/06/2009 06:29 AM, Adam Williamson wrote: On Mon, 2009-10-05 at 16:27 +0200, Hans de Goede wrote: Thanks for bringing this up. I'll create a patch for the scripts generating the livecd to add rd_NO_LUKS to the normal livecd syslinux.cfg entry. I already was planning on doing this, but I forgot. can you file a tag request to get this into the beta? it's the kind of thing that shouldn't show up in the beta, and we can't fix it with updates. and it's a pretty safe change (just switching a behaviour choice when we know both choices do what they're supposed to). CCing Jesse to accept the request. Hi, This is in rawhide now, must the beta though. That should read *missed* the beta though. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
Hi, I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic card, I was going to file new bug. With kms enabled, everything is really slw, with 'nomodeset' it's much faster. I can't say exactly how slow it is, is there anything I can use for measuring? Michal btw, mesa-dri-drivers-experimental does not work at all for me (glx apps segfault) To Michal Hlavinka, Hi, in Fedora 12, KMS for R600/R700 is an experimental features. The next mainline kernel, 2.6.32 will official support KMS of R600/R700. Xorg still does not release opensource drivers for R600/R700 to run 3D program. Mesa-dri-drivers-experimental is just a testing package. It can run compiz. But compiz is easy to crash with this dri-drivers. Believe that, Fedora developers still work hard for opensource ati driver. Please wait a moment. 3D acceleration is coming soon. -- urlhttp://www.liangsuilong.info/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
On 10/22/2009 01:56 PM, Liang Suilong wrote: I try to add kernel parameter nomodeset to turn off KMS. After logging in Gnome and run gnome-terminal, I can scroll up and down my mouse so smoothly. I do not feel scrolling in the terminal is slow. I noticed that performance with KMS is more affected than non-KMS by the debugging options which are enabled in Rawhide kernel. The final release will have most of them disabled, so there's a chance the performance with KMS will improve. You could try rebuilding the kernel without debugging to confirm it. Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
Jindrich Novy wrote: Hi, I would like to announce couple of major changes in the TeX Live 2009 repository. Where? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
On Thu, Oct 22, 2009 at 08:30:37AM -0400, Neal Becker wrote: Jindrich Novy wrote: Hi, I would like to announce couple of major changes in the TeX Live 2009 repository. Where? In the Fedora TeX Live 2009 testing repository, for more info: http://fedoraproject.org/wiki/Features/TeXLive Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Should installkernel be passing --dracut to new-kernel-pkg?
Hi, /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a make install from a kernel.org kernel tree tries to invoke /sbin/mkinitrd rather than dracut. Is that intentional? Also, any ideas on why a dracut-generated initramfs image generated for a kernel.org kernel tree would be so much larger than the Fedora kernel one (same .config)? 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img 82M /boot/initramfs-2.6.32-rc2.img -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Blocker Bug Meeting #1 :: 2009-10-23 @ 15:00 UTC (11 AM EDT)
On Thu, 2009-10-22 at 08:47 +0100, Richard Hughes wrote: 2009/10/21 John Poelstra poels...@redhat.com: 520750 - PackageKit - ASSIGNED - Software Update windows checks for update does not stop .. This has been reported by one person (no dupes), and I'm still waiting for more information. I suspect it's actually a hardware problem or file-system corruption on the reporters computer. Basically, I don't think this should be a blocker. Richard: Btw ... thanks for this feedback ahead of the meeting. With such a large list to review, it's extremely helpful when folks review their bugs ahead of time. We do our best to collaboratively review the bugs real-time. But having feedback from the maintainers and/or people experiencing the bug helps speed up the process. If you've got a spare minute waiting on a build ... take a look at the list of bugs: 1. Respond to the announcement with your $0.02 as Richard has done 2. Alternatively, update the bz with your thoughts * Is the severity appropriate? * Is there a workaround? * What impact does the presence of this failure have on users? * What is your favorite color? 3. As always, in a constructive manner, tell us how we can improve this process - https://fedoraproject.org/wiki/User_talk:Poelstra/blocker_bug_meeting_sop Thanks, James signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: extracting multiple sources in %setup
2009/10/22 Orcan Ogetbil oget.fed...@gmail.com:
On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
Hi,
is there a way to extract multiple sources in a spec files %setup section?
Something like:
for i in {1..10}; do tar xfz %(SOURCE$i}; done
Best Regards
Marcus
%setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9 -a
10
should work. I don't if there's any nicer way.
Orcan
It's also perfectly acceptable to call the %setup macro more than
once, if you need to.
There is some stuff in Max RPM about it:
http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-MULTI-SOURCE
--
Mat Booth
A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphan Package: system-config-cluster (was Re: Simplify non-responsive maintainers policy Part 2)
Hi, On Wed, 2009-10-21 at 11:10 -0700, Toshio Kuratomi wrote: On Wed, Oct 21, 2009 at 10:11:37AM +0100, Steven Whitehouse wrote: Hi, Jim Parsons left Red Hat a little while back and the only contact details I have is his Red Hat email address, which is of course no longer valid. I've opened a bugzilla #530027 as per the unresponsive maintainer procedure, but I was hoping to be able to skip the section regarding sending of messages since there seems little point sending to an email address which I know (and which other Red Hat employees can easily verify) will not be answered. Instead I've emailed the one other person who had access to that package and that has also gone unanswered (see the bugzilla). There are a number of outstanding bugs filed against system-config-cluster (including the fact that it seems that it has not passed an initial review) which I've listed out in the bugzilla. I would like to either fix (or preferably just remove) this package as it creates configs for GFS2 which are incorrect and is thus causing confusion to all who attempt to use it. Therefore this is my formal request to become maintainer of this package, I've talked to FESCo people on IRC and after some discussion I've gone ahead and reassigned ownership. Since people seem to like this, if you don't want to maintain and fix this package, please go through the orphan process rather than just retiring it. Ok. Thanks, I'll do my best to do the right thing here... To clarify some issues which came up during the discussions here, which have also been discussed by the cluster team, here are a few more notes on the topic. system-config-cluster is currently dead as an upstream project. If someone wants to take over the fedora package, then they will first have to take over the upstream side of things too. According to the instructions on the wiki, the correct procedure for such packages is to retire them rather than orphan them (as per https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers) although confusingly that page doesn't either point to or describe the retiring process (it seems to be only mentioned here: https://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife so far as I can see). Now taking into account the comments above, what I propose is to have a period of time in which we see if someone else will take on the package, and if not, I'll retire it. So here, for the first time of asking, is a request to see if anybody will take on the upstream maintenance of system-config-cluster. I have also discovered some further information about Conga (the preferred solution to GUI cluster configuration) and why it is now preferred. Some time ago an investigation was undertaken to try and gauge the usage of s-c-c and Conga and it was found that Conga had a larger user base. It also seemed that maintaining two tools to perform (largely) the same job was not a sensible use of development test time. Now there were also some comments about Conga relating to the more complicated set up, however the Conga team have actively been working on solving some of those issues and the latest versions are (I understand) improved in this area. The team however are actively looking for further suggestions, so if anybody has any ideas, please open a bugzilla against Conga and let them know. So I hope that goes some way towards addressing the concerns of people who are worried about the loss of this system-config-cluster package. Lastly, thanks for helping me sort out all the issues surrounding this package. It is very much appreciated, Steve. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 media-less installer totally broken
- Put the iso on a ntfs partition - Put the vmlinuz+initrd.img in F11's grub .. and boot into the installer, pointing it to install from HDD - The installer cannot pickup the iso Yeah this probably won't work because of the NTFSness, but what's the exact error message? What does the log on tty3 look like? - As an alternate I copied the iso to a server, and NFS shared its folder - I reboot the installer, point it to nfs .. again it fails to start anaconda What's the exact error message? What's the log on tty3 look like? - Third trial .. on that server I loop mount the iso on /opt and NFS share that - Boot installer, it tried to mount server:/opt/images (which fails!) (only /opt is shared) What, like you're not exporting the subtree? You need to do that - anaconda needs to access tree/images/install.img to be able to proceed. Again, what's the log on tty3 look like? - Fourth trial: I expand the iso image completely on disk into a new directory, boot into the installer pointing it at that - Installer finally picks up, anaconda starts .. I click next a few times, partition and format my disk, then an error message mentions cannot load image #1, please insert the CD and try again ... arrgh Yet again, what do the log files look like? Show me /tmp/anaconda.log, /tmp/storage.log, and /tmp/syslog. - Chris -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upload debug-like-info to Mozilla servers every update
On 10/14/2009 03:40 PM, Colin Walters wrote: On Wed, Oct 14, 2009 at 9:04 AM, Jan Horakjho...@redhat.com wrote: Mozilla prefers using their own system in this case. It has some pros, like user don't have to download debug packages (which is approx 80MB for each package). Building the symbols for Mozilla is also quite easy. They have everything prepared in their makefiles and their debug info is just one zip file. All we need is to put this zip file somewhere that mozilla could pull it (or we push it after package is released). This zip file should be left aside from regular rpm package (read unpublished). In that case I'd just make the mozilla spec file to put the .zip in the -debuginfo package. Then their crash handling code just needs to get the built RPM NVRA (it should probably be compiled in, but forking a rpm -q could work I guess), and their server side can fairly easily script a wget http://download.fedoraproject.org/.../mozilla-debuginfo-12345.rpm;. After more discussion on Mozilla bugzilla the Mozilla would prefer to give us an account to their crash-stat system and let us upload the mentioned zip file after each released update. The scp is used to upload debug symbols. However this require storage of private key which shouldn't be exposed to public. Is there any way to launch such operation and also keep the private key unpublished? I can provide complete script which will extract zip file from rpm files and upload them to Mozilla by using scp. -- Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unreadable binaries
On Thu, 2009-10-22 at 09:48 -0400, Adam Jackson wrote: On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote: $ ll /usr/libexec/pt_chown -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown $ ll /usr/bin/chsh -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh What is the purpose of making binaries like these unreadable? Originally I thought it was something to do with them being setuid, but there are counterexamples: $ ll /usr/bin/passwd -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd Historically, the kernel considers read permission on a binary to be a prerequisite for generating core dumps on fatal signal; which you typically want to prevent, since that becomes a way to read /etc/shadow. Pretty sure that's still the case, which means any u+s binaries with group/other read permission are bugs. dumpable flag gets cleared for suid/sgid binaries (as well as for non-readable binaries). -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F-12 Beta Blocker Meeting 2009-10-21 @ 15:00 UTC (11 AM EDT) - Recap
#fedora-bugzappers: F-12-Blocker bug review (part#1) Meeting started by jlaska at 15:01:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-21/fedora-bugzappers.2009-10-21-15.01.log.html . Meeting summary --- * gathering (jlaska, 15:01:27) * Walking through a sorted by-component list of F12Blocker bugs -- http://tinyurl.com/yk9wehr (jlaska, 15:05:14) * https://bugzilla.redhat.com/show_bug.cgi?id=514000 (jlaska, 15:07:53) * AGREED: Reported problem in 514000 is now resolved. This can be remove from blocker list. Any other issues should be filed as new bugs (jlaska, 15:13:53) * https://bugzilla.redhat.com/show_bug.cgi?id=529225 (jlaska, 15:14:07) * HELP: Can smolt provide a list of systems when searching by sybsystem PCI ID's (i.e. 17aa:20f2) (jlaska, 15:20:47) * AGREED: 529225 needs triage or devel review before we can add as a F12Blocker (jlaska, 15:21:16) * https://bugzilla.redhat.com/show_bug.cgi?id=466377 (jlaska, 15:21:48) * possibly further isolate the segfault to obtain a backtrace (jlaska, 15:27:29) * needs clarification as to whether the boot volume is low ... or sound doesn't work at all (jlaska, 15:29:08) * AGREED: 466377 not a blocker bug (jlaska, 15:29:51) * https://bugzilla.redhat.com/show_bug.cgi?id=523768 (jlaska, 15:29:57) * no indications that this affects a *lot* of users (jlaska, 15:33:03) * AGREED: remove 523768 from the blocker list (jlaska, 15:33:20) * https://bugzilla.redhat.com/show_bug.cgi?id=493058 (jlaska, 15:33:52) * AGREED: keep 493058 on the blocker list (jlaska, 15:38:05) * AGREED: move 493058 back to ASSIGNED and request retesting against Beta (jlaska, 15:38:16) * https://bugzilla.redhat.com/show_bug.cgi?id=503149 (jlaska, 15:38:36) * AGREED: 503149 not a release blocker ... workaround exists (jlaska, 15:40:26) * workaround noted in https://bugzilla.redhat.com/show_bug.cgi?id=503149#c11 (jlaska, 15:40:42) * https://bugzilla.redhat.com/show_bug.cgi?id=506013 (jlaska, 15:40:55) * AGREED: 506013 remains on the blocker list. (jlaska, 15:46:07) * AGREED: 506013 patches are included in F-12-Beta ... needs retesting (jlaska, 15:46:17) * if Connor's issue remains, it will be filed as a new bug (jlaska, 15:46:37) * https://bugzilla.redhat.com/show_bug.cgi?id=515441 (jlaska, 15:46:45) * triggered by providing incorrect NFS server:/path, and attempting to recover (jlaska, 15:50:06) * AGREED: 515441 remains on the blocker list. Needs retesting to confirm problem is resolved. (jlaska, 15:51:03) * https://bugzilla.redhat.com/show_bug.cgi?id=517260 (jlaska, 15:51:10) * this is specific to any USB live install's where the USB stick has more than 1 partition (jlaska, 15:52:12) * AGREED: 517260 remains on the list. Verification of fix against anaconda-12.39 needed. (jlaska, 15:53:21) * https://bugzilla.redhat.com/show_bug.cgi?id=517491 (jlaska, 15:53:28) * Current shrink test case - https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(shrink)_install (jlaska, 15:58:20) * AGREED: 517491 remains on the list. Awaiting additional clarification as to whether reported failure match the assessment of the problem. (jlaska, 16:00:48) * https://bugzilla.redhat.com/show_bug.cgi?id=524168 (jlaska, 16:00:53) * AGREED: 524168 remains on the list ... awaiting verification from reporter (jlaska, 16:04:26) * https://bugzilla.redhat.com/show_bug.cgi?id=525924 (jlaska, 16:04:43) * Liam tested this issue overnight and confirmed that the reported problem is fixed (jlaska, 16:06:00) * https://bugzilla.redhat.com/show_bug.cgi?id=526549 (jlaska, 16:06:52) * AGREED: 526549 remains on the list ... awaiting retest and a patch against autoqa/rats_install.py (jlaska, 16:09:53) * https://bugzilla.redhat.com/show_bug.cgi?id=526697 (jlaska, 16:10:11) * LINK: http://bugzilla.laska.org/ (adamw, 16:12:42) * AGREED: 526697 makes edits on existing partitions really unpleasant ... remains on the blocker list, awaiting retesting by jlaska (jlaska, 16:13:38) * https://bugzilla.redhat.com/show_bug.cgi?id=526699 (jlaska, 16:14:52) * AGREED: 526699 remains on the blocker list ... additional patch work/review in progress on anaconda-devel-list (jlaska, 16:18:34) * LINK: http://tinyurl.com/yk9wehr (cwickert, 16:21:05) * https://bugzilla.redhat.com/show_bug.cgi?id=527258 (adamw, 16:21:27) * ACTION: jlaska needs to retest several bugs (jlaska, 16:22:26) * AGREED: 527258 stays as blocker, needs retesting from jlaska (adamw, 16:24:03) * https://bugzilla.redhat.com/show_bug.cgi?id=527520 (adamw, 16:24:14) * having one of our official spins boot to text mode on a default install is Not Good :) (jlaska, 16:25:42) *
Fedora Test Day Summary - Confined Users
Greetings! This Tuesday was the Confined Users Test Day / FitFinish [1] (TD/FF). Though we expected higher attendance, the results are really valuable. The most valuable outcome of a test day could be a fact that we should bring more attention/people to using/testing SELinux policy and related tools. Thanks to all who participated and helped with the organization, especially to Dan Walsh who promptly started to resolve reported bugs and already fixed some important issues. Following bugs were reported during the TD/FF by the participants: ID Summary 529873 Openswan/pluto - AVC denials when starting the ipsec service 529870 SELinux is preventing /usr/bin/python getattr access on /home/jlaska/.gvfs. 529871 SELinux is preventing /usr/bin/python connectto access on /var/run/nscd/socket. 529758 SELinux is preventing /usr/sbin/sendmail.sendmail module_request access. 529803 Your system may be seriously compromised! /usr/sbin/nscd attempted to mmap low kernel memory. 529606 SELinux is preventing /usr/sbin/modem-manager read write access to device noz0. 529738 SELinux is preventing /lib64/dbus-1/dbus-daemon-launch-helper execute access on /usr/sbin/abrtd. 529827 guest_u user not able to run ps 529830 SELinux failed to limit the authority of execute of user_u 529903 SELinux is preventing bash create access. 529911 SELinux is preventing nautilus read write access on sr0. 529916 AVCs with confined mailuser sending e-mail 529933 SELinux is preventing /usr/sbin/abrtd setattr access on .abrt. 529934 SELinux is preventing /usr/sbin/abrtd write access on /root. 529951 SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents). 529953 hp cups selinux denial 529961 SELinux is preventing /usr/sbin/abrtd read access on Bugzilla.conf. Have a nice day, /Eduard [1] - https://fedoraproject.org/wiki/Test_Day:2009-10-20 [2] - http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/sect-Security-Enhanced_Linux-Targeted_Policy-Confined_and_Unconfined_Users.html [3] - http://magazine.redhat.com/2008/07/02/writing-policy-for-confined-selinux-users/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Beta
On Wed, 21 Oct 2009, Adam Williamson wrote: On Wed, 2009-10-21 at 17:08 -0500, Mike McGrath wrote: On Wed, 21 Oct 2009, Adam Williamson wrote: On Wed, 2009-10-21 at 12:31 +0200, Michał Piotrowski wrote: Hi, I just installed F12 Beta. Here are some thoughts 1 - during the first boot smolt panicked - there was an error related to time zones in python-sitepackages or something like that. Could you try to reproduce and provide more precise details on the error? There's not a lot we can do with that level of detail. The smolt firstboot thing is already fixed, just didn't make it in time for the beta, my bad. Is there a bug report I can reference so I can add this to the Common Bugs page with a reasonable level of detail? I don't remember if a bug got opened for that one or not, basically when firstboot loads the smolt module fails so it doesn't load. It's attempting to import a deprecated library that doesn't exist. It doesn't actually prevent any functionality other then users don't get prompted to enable smolt. Firstboot continues as normal with license, create user, date time, etc. -Mike-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Status of multiseat feature
Is anyone actively working on multiseat? https://fedoraproject.org/wiki/Features/Multiseat Linus Walleij -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
Hi all. It has been brought to my attention that my description of my future vision of rawhide as explained here is much clearer than previous attempts (including the current no frozen rawhide wiki page). So I felt it prudent to forward it along to the devel list for more eyes to look upon it and comment if desired. Thanks! Forwarded Message From: Jesse Keating jkeat...@redhat.com Reply-to: fedora-advisory-bo...@redhat.com To: fedora-advisory-bo...@redhat.com Subject: Re: What is the Fedora Project? Date: Wed, 21 Oct 2009 18:58:08 -0700 On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote: I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a way for developers to have trees that move at their pace, and are possibly quite broken from time to time in ways that differ from each other. If we were able to develop such a scenario, why not also provide the flipside of this idea -- make the One True Rawhide the place where we take in changes that don't break the world, while they're cobbled on in the other trees? Whether this is an extension of the KoPeR idea or something entirely difficult, it merits serious consideration. I very much like the aspect of the more stable rawhide here. Jesse Keating brought up some concerns about integration, but aren't those concerns something that people would be interested in solving? (I'm assuming those people are the wide variety of engineers working in the Fedora community who are smarter than I.) So my plans are really funny. I plan to make rawhide more unstable more of the time, and I plan to make rawhide more stable more of the time. Crazy eh? How can I do this? By splitting rawhide in two. Rawhide as we know it, /pub/fedora/linux/releases/development/ will remain rawhide. We may even change the path to say rawhide, just to catch things up and well I like keeping mirrors on their toes. Rawhide will be a repository of developmental and experimental packages. Things being worked on for the future. It will /not/ be an installable tree, rather it will just be a repository of packages, to be added on to an already stable base, eg you'd install F12, and enable rawhide to test rawhide. This will significantly lower the complaints that rawhide isn't installable. The second face of rawhide, will be the pending release, that is when it comes time to feature freeze a release, we'll split it away from rawhide. We'll publish to /pub/fedora/linux/releases/test/13-pending/ or some such. THIS tree will be installable. It will be composed each night, and we'll use bodhi to manage updates to this tree. That means this tree will have it's own updates testing where potential freeze breaks can be tested and commented on by all, but won't risk the base tree. If testing pans out, it'll get tagged for the release, if not it'll get thrown away. This tree will spawn 13-Alpha, 13-Beta, the snapshots in between, and eventually pub/fedora/linux/releases/13. Remember that first rawhide? Yeah, it kept going, unfrozen, leaping toward Fedora 14. You could still install 13-Alpha, or 13-pending, and enable/update to rawhide to start testing Fedora 14 stuff. What does this accomplish? It provides a very easy release valve. Instead of closing the valve and building up pressure while we freeze, and tempting people to push things into our pending release that really don't belong, we'll provide them a normal, never ending release of pressure, called rawhide. You can always find the latest stuff in rawhide, there is nothing newer (unless we make KoPeRs happen). We don't have to worry about rawhide being installable. We don't have to worry about people dumping highly experimental or developmental stuff in our pending release. We don't have to worry about the giant pile of builds for the next release building up while we polish the pending release. We don't have to worry about the giant pile of 0-day updates building up while we polish the pending release, as we'll be pushing these updates as we go. This is my vision on how to accomplish both a always active development stream, and a more stable pending release stream, keeping everybody happy. Want to help? I'll be at FUDCon Toronto discussing roadblocks to this vision and discussing why this vision sucks if anybody thinks that it does. Or just find me on IRC/email if you want to chat about it. ___ fedora-advisory-board mailing list fedora-advisory-bo...@redhat.com http://www.redhat.com/mailman/listinfo/fedora-advisory-board -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Status of multiseat feature
On Thu, 2009-10-22 at 18:20 +0200, Linus Walleij wrote: Is anyone actively working on multiseat? https://fedoraproject.org/wiki/Features/Multiseat The necessary infrastructure for multiseat is (slowly) being developed in ConsoleKit and gdm branches upstream. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote: This is my vision on how to accomplish both a always active development stream, and a more stable pending release stream, keeping everybody happy. Want to help? I'll be at FUDCon Toronto discussing roadblocks to this vision and discussing why this vision sucks if anybody thinks that it does. Or just find me on IRC/email if you want to chat about it. Not a bad idea. In all honesty, I find rawhide is rarely fully installable out of the box anyway...this isn't a grumble! I think it's better to embrace reality and have multiple trees, though I am interested in whether that pending release couldn't also one day have a counterpart that had more longevity - a testing release (not the same as the testing that we currently have through updates) :) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unreadable binaries
On Thu, Oct 22, 2009 at 09:59:00AM -0400, Stephen Smalley wrote: On Thu, 2009-10-22 at 09:48 -0400, Adam Jackson wrote: On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote: $ ll /usr/libexec/pt_chown -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown $ ll /usr/bin/chsh -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh What is the purpose of making binaries like these unreadable? Originally I thought it was something to do with them being setuid, but there are counterexamples: $ ll /usr/bin/passwd -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd Historically, the kernel considers read permission on a binary to be a prerequisite for generating core dumps on fatal signal; which you typically want to prevent, since that becomes a way to read /etc/shadow. Pretty sure that's still the case, which means any u+s binaries with group/other read permission are bugs. dumpable flag gets cleared for suid/sgid binaries (as well as for non-readable binaries). Stephen, what would be your advice if I asked for these binaries to become readable by non-root users? [It's not crucial at the moment, however, just reduces the effectiveness of febootstrap a little] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora with Universal Binaries?
Hello, I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, 2009-10-22 at 12:28 -0500, King InuYasha wrote: http://icculus.org/fatelf/ There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries Except, they're not really ELF binaries. ELF doesn't allow you to do both at the same time in the headers, so this adds a new header and is essentially an encapsulation for other ELF files. Thus, a kernel patch is required and it would be some time before all kernels supported it. I'm not against the notion of this...but I think some of the usual suspects need to get involved in standardizing such an ELF hack. (You might be able to do something with binfmt_misc as a hack) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20091022 changes
On Thu, 2009-10-22 at 13:06 +, Rawhide Report wrote: Compose started at Thu Oct 22 06:15:12 UTC 2009 Broken deps for i386 -- openscada-visStation-0.6.4-3.fc12.i686 requires openscada-Special-FlibSYS Updated Packages: xorg-x11-proto-devel-7.4-34.fc12 * Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.4-34 - kbproto 1.0.4 - xf86miscproto 0.9.3 - xproxymanagementprotocol 1.0.3 * Tue Oct 06 2009 Peter Hutterer peter.hutte...@redhat.com 7.4-32 - compositeproto 0.4.1 - xf86dgaproto 2.1 - dmxproto 2.3 - inputproto 2.0 - fixesproto 4.1.1 - randrproto 1.3.1 - recordproto 1.14 - xf86vidmodeproto 2.3 - xineramaproto 1.2 - xproto 7.0.16 * Tue Oct 06 2009 Peter Hutterer peter.hutte...@redhat.com 7.4-33 - Upload xf86dgaproto 2.1 tarball, this time for real. but yum update xorg-x11-proto-devel reports: [r...@samson yum-update]# yum update Loaded plugins: dellsysidplugin, dellsysidplugin2, refresh-packagekit Setting up Update Process Resolving Dependencies -- Running transaction check --- Package xorg-x11-proto-devel.noarch 0:7.4-34.fc12 set to be updated -- Processing Conflict: xorg-x11-proto-devel-7.4-34.fc12.noarch conflicts libXxf86dga-devel 1.1 -- Finished Dependency Resolution xorg-x11-proto-devel-7.4-34.fc12.noarch from rawhide has depsolving problems -- xorg-x11-proto-devel conflicts with libXxf86dga-devel Error: xorg-x11-proto-devel conflicts with libXxf86dga-devel You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Should the Rawhide report have identified this as a broken dependency? -- 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?
On Mon, 2009-10-19 at 20:20 +0100, Peter Robinson wrote: Hi All, I thought with the mass rebuild the i586 rpms were suppose to be gone but it seems the F-12 repository still has quite a few of them. Are the old packages that should have been blocked, ones that's that weren't rebuilt for some reason or something that I've just missed? Peter I did some work a week or two ago to see what was behind some of the packages a couple of weeks ago, and it is summarised below. Not only is there an issue with the i586 packages, but also a number of noarch packages. Point 5 below categories the apparent reason for the packages not having been rebuilt, and it appears possible that out of the 185 packages that have not been rebuilt, 95 might build successfully if just submitted for rebuilding. I was looking at the need-rebuild.py script, and have a few comments/questions (apologies if my terminology is incorrect - this area is new to me). 1. Is the script that is run and produces the output at http://jkeating.fedorapeople.org/needed-f12-rebuilds.html actually the script referred to at the bottom of that page (https://fedorahosted.org/rel-eng/browser/scripts) ? The reason I ask is that when I run the script, I get Included Koji instances: http://koji.fedoraproject.org/kojihub http://sparc.koji.fedoraproject.org/kojihub http://s390.koji.fedoraproject.org/kojihub http://arm.koji.fedoraproject.org/kojihub whereas the posted output only has Included Koji instances: http://koji.fedoraproject.org/kojihub http://sparc.koji.fedoraproject.org/kojihub 2. If the script is run against just koji.fedoraproject,org/kojihub (i.e. without the sub arches), it says 185 packages need rebuilding (instead of the 175 listed in the report); the following 10 packages are omitted when the sparc koji hub is also included: gmpc HippoDraw itcl latex2rtf prtconf PyKDE python-igraph silo spicebird xorg-x11-drv-sunffb This is caused by line 117 of the script: unbuilt = unbuilt unbuiltnew so if a package needs to be rebuilt on the primary arch, but not on the (in this case sparc) secondary arch, then it is dropped from needing to be rebuilt (it appears that a package will only be listed if it needs to be rebuild on every arch). There are several circumstances where this can happen (with the 10 missing packages listed): Built on sub arch but failed on primary arch gmpc - 0.18.0-1 build on sparc after epoch but 0.18.0-2 failed on koji HippoDraw itcl latex2rtf python-igraph Not a primary arch package (should the package be blocked in the primary arch kojihub?) == prtconf silo xorg-x11-drv-sunffb Blocked on secondary arch (so not included in unbuiltnew) = spicebird Built on sub arch but not submitted for rebuild on primary arch PyKDE Package does not exist in secondary arch (no example) = Would it be more relevant to list what needs to be rebuild separately for each arch (but see point 3 below)? 3. So far as I can see, there have not been mass rebuilds on the secondary arches, so is it relevant to search them for successful builds since the epoch? If it is relevant, they would appear to have different epochs in any case. 4. On the sparc (and other sub arches) kojihubs, there can be builds without a task, but the build itself can have a tag dist-f12 (see http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=19567 for example). Can that tag be safely used for checking if the build had a particular tag, rather than having to look at a task? Currrently the script can call getTaskInfo with a taskID of None, which is the cause of getTaskInfo returning a request with len 1, since that response is an error message for requesting TaskInfo with a task id of None. 5. I have looked at the 185 packages that have not been rebuilt, and the reasons fall into the following categories (details for each package are listed later): 1. Not submitted for rebuild (65) 2. Mock exited with status 10 (7) 3. Mock exited with status 30 (23) 4. No build on dist-12/dist-f12-rebuild/dist-f12-updates-candidate (6) 5. Build cancelled (1) 6. Mock exited with status 1 (83) I'm wondering if (re)submitting the packages in categories 1, 3, 4 and 5 might result in the majority being successfully built, possibly halving the number of packages that would then still need to be rebuilt. I have made some changes to need-rebuild.py to produce some of the information above, and am happy to provide them if they are of any interest. Not submitted for rebuild (65) == OpenEXR_CTL OpenEXR_Viewers PerceptualDiff Perlbal Pixie Pound PyAmanith PyKDE PyQuante PySBIG PySolFC PySolFC-cardsets aboot ccss django-typepad eclipse-setools education-bookmarks elilo eqntott fonts-hebrew-fancy gdata-sharp gnome-globalmenu icoutils
Re: Fedora with Universal Binaries?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.10.2009 19:38, schrieb Jon Masters: Except, they're not really ELF binaries. ELF doesn't allow you to do both at the same time in the headers, so this adds a new header and is essentially an encapsulation for other ELF files. Thus, a kernel patch is required and it would be some time before all kernels supported it. I'm not against the notion of this...but I think some of the usual suspects need to get involved in standardizing such an ELF hack. (You might be able to do something with binfmt_misc as a hack) Jon. Creating FatELF binaries doesn't solve any x86_64 related issues. For example: Old releases of blender was not able to creates proper .blend files when the binary was compiled for x86_64. In this case the created files was not usable on the x86_32 release. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkrgmcEACgkQZLAIBz9lVu++FgP/br8KeMY5vp8V88xv4hoH9pyV 2vuJJyhszaWl/qFN9Iax7Q5p1A3muC/BFHhUu6VWphB2xIj9EXkMhubgVtX7OBBc J+v/wv0bWU2kBVFsYDUcfoiTkxluI4uuttTRoqZm7TUuc9/EMBVwzWGeqsBYoFej xV9jjWk4dGJ/sFlFC3I= =uZBp -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, 2009-10-22 at 19:43 +0200, Jochen Schmitt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.10.2009 19:38, schrieb Jon Masters: Except, they're not really ELF binaries. ELF doesn't allow you to do both at the same time in the headers, so this adds a new header and is essentially an encapsulation for other ELF files. Thus, a kernel patch is required and it would be some time before all kernels supported it. I'm not against the notion of this...but I think some of the usual suspects need to get involved in standardizing such an ELF hack. (You might be able to do something with binfmt_misc as a hack) Jon. Creating FatELF binaries doesn't solve any x86_64 related issues. For example: Old releases of blender was not able to creates proper .blend files when the binary was compiled for x86_64. In this case the created files was not usable on the x86_32 release. That's just a cross-platform compat issue. People had issues like that for years porting between Mac and Windows with different type sizes and endianness. Without and direct knowledge of the problem, that sounds like somebody forgot to either (a) use an inherently cross-platform file format like XML, or (b) forgot to write sane file format encode/decode routines that were cross-platform clean, or (c) included executable code in the file format specification (which is pretty stupid). Or? We'd expect a program built on any platform to save/load a specific file format written by that same program built on any other platform. Otherwise that program is just broken. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote: Hi all. It has been brought to my attention that my description of my future vision of rawhide as explained here is much clearer than previous attempts (including the current no frozen rawhide wiki page). So I felt it prudent to forward it along to the devel list for more eyes to look upon it and comment if desired. Thanks! Forwarded Message From: Jesse Keating jkeat...@redhat.com Reply-to: fedora-advisory-bo...@redhat.com To: fedora-advisory-bo...@redhat.com Subject: Re: What is the Fedora Project? Date: Wed, 21 Oct 2009 18:58:08 -0700 On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote: I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a way for developers to have trees that move at their pace, and are possibly quite broken from time to time in ways that differ from each other. If we were able to develop such a scenario, why not also provide the flipside of this idea -- make the One True Rawhide the place where we take in changes that don't break the world, while they're cobbled on in the other trees? Whether this is an extension of the KoPeR idea or something entirely difficult, it merits serious consideration. I very much like the aspect of the more stable rawhide here. Jesse Keating brought up some concerns about integration, but aren't those concerns something that people would be interested in solving? (I'm assuming those people are the wide variety of engineers working in the Fedora community who are smarter than I.) So my plans are really funny. I plan to make rawhide more unstable more of the time, and I plan to make rawhide more stable more of the time. Crazy eh? How can I do this? By splitting rawhide in two. Rawhide as we know it, /pub/fedora/linux/releases/development/ will remain rawhide. We may even change the path to say rawhide, just to catch things up and well I like keeping mirrors on their toes. Rawhide will be a repository of developmental and experimental packages. Things being worked on for the future. It will /not/ be an installable tree, rather it will just be a repository of packages, to be added on to an already stable base, eg you'd install F12, and enable rawhide to test rawhide. This will significantly lower the complaints that rawhide isn't installable. The second face of rawhide, will be the pending release, that is when it comes time to feature freeze a release, we'll split it away from rawhide. We'll publish to /pub/fedora/linux/releases/test/13-pending/ or some such. THIS tree will be installable. It will be composed each night, and we'll use bodhi to manage updates to this tree. That means this tree will have it's own updates testing where potential freeze breaks can be tested and commented on by all, but won't risk the base tree. If testing pans out, it'll get tagged for the release, if not it'll get thrown away. This tree will spawn 13-Alpha, 13-Beta, the snapshots in between, and eventually pub/fedora/linux/releases/13. Remember that first rawhide? Yeah, it kept going, unfrozen, leaping toward Fedora 14. You could still install 13-Alpha, or 13-pending, and enable/update to rawhide to start testing Fedora 14 stuff. So to make this a reality, we need to ensure that whatever is in rawhide has a *=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was = whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a newer ENVR than that same package in any of the newer distros. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
King InuYasha wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ Yuck!!! Please don't infect GNU/Linux with this completely braindead crap! This wastes a lot of disk space and download bandwidth and probably also increases loading times for NO reason whatsoever. It also doubles the build times for any and all software. Just figure out what arch your machine is and install the correct package for your arch! Fat binaries are a method to make crappy binary-only software distribution easier, they have no room on a Free Software system. Let the Mac folks keep their fat crap and leave our binaries as native for the appropriate arch! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote: So to make this a reality, we need to ensure that whatever is in rawhide has a *=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was = whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a newer ENVR than that same package in any of the newer distros. Yes, but it may happen before the bodhi stage, when we get autoqa working on post-build tests. This kind of check could happen at SCM commit time, package build time, or finally bodhi push time. Seems reasonable that we'd want to catch it as early as possible, but that does force people to work on rawhide first, then work on the pending release which may be under critical time pressure. Certainly something to discuss. Catching it at bodhi time seems too late. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20091022 changes
Quentin Armitage wrote: Error: xorg-x11-proto-devel conflicts with libXxf86dga-devel [snip] Should the Rawhide report have identified this as a broken dependency? No. The Rawhide report only lists unresolvable dependencies, not conflicts. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, Oct 22, 2009 at 12:57 PM, Kevin Kofler kevin.kof...@chello.atwrote: King InuYasha wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ Yuck!!! Please don't infect GNU/Linux with this completely braindead crap! This wastes a lot of disk space and download bandwidth and probably also increases loading times for NO reason whatsoever. It also doubles the build times for any and all software. Just figure out what arch your machine is and install the correct package for your arch! Fat binaries are a method to make crappy binary-only software distribution easier, they have no room on a Free Software system. Let the Mac folks keep their fat crap and leave our binaries as native for the appropriate arch! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I dunno, it could be useful for Live CDs/USBs. It would let you pack multiple arches onto a single LiveCD/USB. You sound like one of those crazy people that disregard everything that may slightly help proprietary software. It's probably possible to strip out arches when they become unneeded, if so desired. I know it is possible under Mac OS X to do that. If you had a system that had extra arches you didn't need, you probably could just go and strip them out to save disk space. There isn't much proof to your statement about loading fat binaries. I don't notice a slow down in load times of Universal binaries on my Mac, but I do notice the disk space. As it is, Snow Leopard now uses Universal binaries to pack x86_32 and x86_64 into a single application container and can strip out PowerPC binary code. Don't knock it till you try it... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote: So to make this a reality, we need to ensure that whatever is in rawhide has a *=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was = whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a newer ENVR than that same package in any of the newer distros. Yes, but it may happen before the bodhi stage, when we get autoqa working on post-build tests. This kind of check could happen at SCM commit time, package build time, or finally bodhi push time. Seems reasonable that we'd want to catch it as early as possible, but that does force people to work on rawhide first, then work on the pending release which may be under critical time pressure. Certainly something to discuss. Catching it at bodhi time seems too late. We could allow adding numbers after the dist tag in release for this purpose. And if the fixed package would upgrade to a newer upstream version it should not be too big hassle to build it in the rawhide tree first. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
King InuYasha wrote: On Thu, Oct 22, 2009 at 12:57 PM, Kevin Kofler kevin.kof...@chello.at mailto:kevin.kof...@chello.at wrote: King InuYasha wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ Yuck!!! Please don't infect GNU/Linux with this completely braindead crap! This wastes a lot of disk space and download bandwidth and probably also increases loading times for NO reason whatsoever. It also doubles the build times for any and all software. Just figure out what arch your machine is and install the correct package for your arch! Fat binaries are a method to make crappy binary-only software distribution easier, they have no room on a Free Software system. Let the Mac folks keep their fat crap and leave our binaries as native for the appropriate arch! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com mailto:fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I dunno, it could be useful for Live CDs/USBs. It would let you pack multiple arches onto a single LiveCD/USB. Yeah, but they'd be larger, forcing removal of software from the images. You sound like one of those crazy people that disregard everything that may slightly help proprietary software. It's probably possible to strip out arches when they become unneeded, if so desired. I know it is possible under Mac OS X to do that. If you had a system that had extra arches you didn't need, you probably could just go and strip them out to save disk space. So. . .then why do it? There are practical considerations here. There isn't much proof to your statement about loading fat binaries. I don't notice a slow down in load times of Universal binaries on my Mac, but I do notice the disk space. As it is, Snow Leopard now uses Universal binaries to pack x86_32 and x86_64 into a single application container and can strip out PowerPC binary code. Don't knock it till you try it... Strip out where? Build time, install time, or run time? -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote: So to make this a reality, we need to ensure that whatever is in rawhide has a *=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was = whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a newer ENVR than that same package in any of the newer distros. Yes, but it may happen before the bodhi stage, when we get autoqa working on post-build tests. This kind of check could happen at SCM commit time, package build time, or finally bodhi push time. Seems reasonable that we'd want to catch it as early as possible, but that does force people to work on rawhide first, then work on the pending release which may be under critical time pressure. Certainly something to discuss. Catching it at bodhi time seems too late. Good point. SCM commit time (or tag time) with a CVS hook would be awesome as long as the hook was fast enough. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
Tomas Mraz wrote: We could allow adding numbers after the dist tag in release for this purpose. That is already allowed, and encouraged, for branch-specific modfications, http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
Hi Jindrich, (sorry for not replaying to the original message, I was reading the list through archives) I was using TeXLive 2009 repository before, without any problem. After seeing your message, I followed the instruction In case you have an older TL2009 installed on your system from the testing repository, please consider removing it and installing again. and after 'yum install texlive' I get a lot of missing dependencies. Installing texlive requires dvipdfm from the F12/rawhide repository, which requires kpathsea from the same repository and which in turn requires texlive-2007. Will it be fixed with texlive-2007-45 build? Another, probably related issue: Why there is not a xdvi (and also dvipdfm) binary in the Texlive 2009 repository. Should one use the one from F12? This seems strange to me to have such mixture of 2007 and 2009 versions. Jiri -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
tor 2009-10-22 klockan 12:28 -0500 skrev King InuYasha: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. There's already lib / lib64 for parallell-installation of libraries, though granted it's limited to only two arches, but yes, something that covers bin too would be useful. But I doubt fat binaries are the answer. You'd probably end up with having rpm merge /usr/bin/xxx from different packages into a single fatelf file upon installation, rather than putting the fat elves in the RPM file. Instead, I think it would be better to extend FHS to support parallell install of binaries in a way that gives each arch its own file. But still, regardless if you go with a new binary format or with fat filesystems, you end up blurring the line between native compilation and cross-compilation. An extended FHS would probably have to deal with that. (Fedora doesn't guarantee parallell install of -devel packages, for example.) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Major reorganization of TeX Live packages
On Thursday 22 October 2009 19:46:29 Jiri Cerny wrote: Hi Jindrich, (sorry for not replaying to the original message, I was reading the list through archives) I was using TeXLive 2009 repository before, without any problem. After seeing your message, I followed the instruction In case you have an older TL2009 installed on your system from the testing repository, please consider removing it and installing again. and after 'yum install texlive' I get a lot of missing dependencies. Installing texlive requires dvipdfm from the F12/rawhide repository, which requires kpathsea from the same repository and which in turn requires texlive-2007. Will it be fixed with texlive-2007-45 build? You can get the texlive-2007-45 build meanwhile with koji download-build --arch=i686 137706 in this case arch=i686 refers to the architecture of the machine where I am testing texlive and 137706 refers to the id of the build for texlive-2007-45 in f12 (it has been done for f10-13). With this update of the selected packages the update for the new texlive works. :-) Jiri -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 13:39 -0500, Rex Dieter wrote: Tomas Mraz wrote: We could allow adding numbers after the dist tag in release for this purpose. That is already allowed, and encouraged, for branch-specific modfications, http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches Heh, dunno why I thought it is disallowed. Then I don't see any problem with enforcing n-v-r ordering during cvs tagging. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
On Thu, 2009-10-22 at 09:17 +0200, Michal Hlavinka wrote: For the slow 2D performance - _how_ slow is it, really? gnome-terminal has never been much of a speed demon. Does it get any faster if you boot with 'nomodeset' as a kernel parameter? Hi, I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic card, I was going to file new bug. With kms enabled, everything is really slw, with 'nomodeset' it's much faster. I can't say exactly how slow it is, is there anything I can use for measuring? cairo-perf-trace is, afaik, the best we have: http://cworth.org/intel/performance_measurement/ I'm not sure if bug reports on this are useful. To some extent, slow performance with KMS on some chips is a known issue. Jerome, do you want bug reports from people who have this problem, or would more reports not provide any new information? btw, mesa-dri-drivers-experimental does not work at all for me (glx apps segfault) Your card's r700, not r600, so that's kind of expected; the current code isn't expected to work well on r700 (possibly not at all, I'm not 100% clear). r700 and r800 support should follow r600 relatively quickly, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: extracting multiple sources in %setup
On Thu, 2009-10-22 at 13:07 +, Mat Booth wrote:
2009/10/22 Orcan Ogetbil oget.fed...@gmail.com:
On Thu, Oct 22, 2009 at 3:46 AM, Marcus Moeller wrote:
Hi,
is there a way to extract multiple sources in a spec files %setup section?
Something like:
for i in {1..10}; do tar xfz %(SOURCE$i}; done
Best Regards
Marcus
%setup -q -c -n %{name} -a 0 -a 1 -a 2 -a 3 -a 4 -a 5 -a 6 -a 7 -a 8 -a 9
-a 10
should work. I don't if there's any nicer way.
Orcan
It's also perfectly acceptable to call the %setup macro more than
once, if you need to.
There is some stuff in Max RPM about it:
http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-MULTI-SOURCE
Just a +1 for this as a general reference; I use it all the time. It's
the first Google result for 'rpm setup macro', if you ever lose the
bookmark. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 11:33 -0700, Dan Williams wrote: Good point. SCM commit time (or tag time) with a CVS hook would be awesome as long as the hook was fast enough. Note, I didn't say CVS, I said SCM (: -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating jkeat...@redhat.com wrote: Hi all. It has been brought to my attention that my description of my future vision of rawhide as explained here is much clearer than previous attempts (including the current no frozen rawhide wiki page). [] Actually, the no frozen rawhide was very clear and this message just boggles the mind. What does this accomplish? It provides a very easy release valve. Instead of closing the valve and building up pressure while we freeze, and tempting people to push things into our pending release that really don't belong, we'll provide them a normal, never ending release of pressure, called rawhide. [] Great, you made life of lazy developers easy. What about users of Rawhide? I had Rawide installed on my main desktop since RHL 6. What am I supposed to do now? What tree to run? Your proposal has no guidelines for me (unlike the proposal to stop freezing Rawhide, which IMHO had a lot of merit). Note, I'm not interested in testing things sometimes. If I did, I would've been using RHEL WS or something. I want an always-useable development tip tree. The problem here is that Rawhide was a useful distribution for years. We were Gentoo before Gentoo, minus meaningless recompiles. And now? -- Pete -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On 10/21/2009 07:47 AM, Ralf Ertzinger wrote: Hi. On Tue, 20 Oct 2009 17:40:46 -0600, Stephen John Smoogen wrote: In most cases, you can get that information from the original RPM compared to the system... if you have the RPM :). rpm -Vppackage_file_goes_here Which is pretty much what I want, just pulling the data from an external (signed) source instead of the local RPM database. Sounds familiar. Solaris Fingerprint DB, anyone? http://sunsolve.sun.com/fileFingerprints.do Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha ngomp...@gmail.com wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. Sounds like a kludge to work around limitations of dpkg. -- Pete -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
On Thu, 2009-10-22 at 19:56 +0800, Liang Suilong wrote: To Adam Williamson I try to add kernel parameter nomodeset to turn off KMS. After logging in Gnome and run gnome-terminal, I can scroll up and down my mouse so smoothly. I do not feel scrolling in the terminal is slow. Thanks for testing. See my reply to Michal for the next steps: I'm checking with Jerome Glisse whether it's necessary for you to file a bug report in this case. We can sure that KMS for R600 cause the problem. But KMS in the mainline kernel is experimental. I believe that the bug will be fixed. Thanks to Fedora developers, I can enjoy compiz with opensource drivers. Yes, this is something the developers are working on for sure. Another things, xorg-x11-drv-ati with mesa-dri-drivers-experimental seems not to ru gnome-shell. Does it mean that ATi opensource need more OpenGL extensions to stand for gnome-shell? Well, on my test system it runs, but doesn't really work: there's a known bug which stops any input to gnome-shell working (so basically you can't _do_ anything with it, trying to click on any gnome-shell element doesn't work). As I said, this is a known bug in the Mesa stuff which should get fixed at some point. I imagine any other problem you're seeing with gnome-shell is similar in nature. As mentioned, this code is known to be pretty alpha :) Plymouth is so beautiful and smooth when I start up my Fedora 12, nevertheless, it does not work when I shutdown or reboot my box. I just can see a black screen or console status. How can I make plymouth run again? This could be related to disabling KMS, I suppose, but I don't know any more than that I'm afraid. ATi should learn Intel how to develop opensource drivers for their graphic card. The relationship between ati and radeonhd should be cooperation not competition. This is just my opinon. That's not quite the situation. The 'ati' driver is not written entirely by ATI/AMD, it is a proper communally-developed driver to which our Red Hat staff and others contribute significantly, based on information and specifications provided by ATI/AMD. 'radeonhd' is essentially a competing driver. The history is that the radeonhd driver came out before the ati/radeon driver (technically the driver in question is called 'radeon', the driver called 'ati' is really just a wrapper which loads either 'radeon', 'r128' or 'mach64' depending on the hardware that's detected) gained any support for r500+ chips at all. (Actually, a driver called 'avivo' came before either of those, but never mind that). After a while, the 'radeon' driver added support for r500+ chips, so there are now two different open source drivers, both officially part of the X.org project, which support r500+ devices. 'radeonhd' is supported by Novell and gets contributions from Novell's paid developers, 'radeon' is more supported by Red Hat. Obviously this isn't sustainable and eventually the two will merge somehow, but for now there's two drivers, and Fedora supports 'radeon'. 'radeonhd' is really only available from the Fedora repositories for research purposes. The fact that there are two open source drivers is not the fault of ATI/AMD in any way, they shouldn't take any blame for it. They have in fact been moving in a very good direction lately, and their relationship with the X development community is pretty much as good as Intel's now. Neither 'radeon' nor 'radeonhd' would have developed to the point they have without the help and support of ATI/AMD. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 2009-10-22 at 09:25 -0400, Lyos Gemini Norezel wrote: In this day and age? It's highly unusual for people to only have one. I'd say it's rather more common than it used to be; many people don't use ISP email any more, they just use a gmail or Yahoo! or whatever account for everything. Even when people have more than one, it's often the case they only have one personal email and the other is a business address they can't use for non-work-related purposes. Those of us who've been collecting addresses from different ISPs and so on for years are probably in the minority these days :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 2009-10-22 at 09:43 -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. /me looks around nervously :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote: Hi all. It has been brought to my attention that my description of my future vision of rawhide as explained here is much clearer than previous attempts (including the current no frozen rawhide wiki page). So I felt it prudent to forward it along to the devel list for more eyes to look upon it and comment if desired. I have two particular nits with it. One, it's pretty unwieldy, especially for part time maintainers (thinking how many hoops we'll have to jump through just to keep our packages up to date). Having to jump through the Bodhi hoops every time we just want to put a trivial update into a release that won't be coming out for five months feels like a pain. I'd worry about a lot of stuff going stale and smelly in the middle of the Bodhi process somewhere as maintainers lose track of where the hell they're up to with the four releases they have to cope with (the last two already-released releases, the upcoming release, and rawhide). Two, it makes testing things a bit more complex. Those of us who like to test upcoming stuff in real use - i.e. on our main machines - will have to choose whether to test rawhide, in which case we'll have more pain to deal with ourselves and won't be contributing as much to testing of the next stable release, or test the next stable release, in which case we aren't helping maintainers by making sure the stuff they're putting in rawhide isn't totally broken. But overall, the positives could certainly outweigh the negatives. Just thought I'd flag up the two major concerns I have in case anything could be done about them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 14:47 -0600, Pete Zaitcev wrote: On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating jkeat...@redhat.com wrote: Hi all. It has been brought to my attention that my description of my future vision of rawhide as explained here is much clearer than previous attempts (including the current no frozen rawhide wiki page). [] Actually, the no frozen rawhide was very clear and this message just boggles the mind. What does this accomplish? It provides a very easy release valve. Instead of closing the valve and building up pressure while we freeze, and tempting people to push things into our pending release that really don't belong, we'll provide them a normal, never ending release of pressure, called rawhide. [] Great, you made life of lazy developers easy. What about users of Rawhide? I had Rawide installed on my main desktop since RHL 6. What am I supposed to do now? What tree to run? Your proposal has no guidelines for me (unlike the proposal to stop freezing Rawhide, which IMHO had a lot of merit). Note, I'm not interested in testing things sometimes. If I did, I would've been using RHEL WS or something. I want an always-useable development tip tree. The problem here is that Rawhide was a useful distribution for years. We were Gentoo before Gentoo, minus meaningless recompiles. And now? -- Pete I wonder where your confusion comes from. With this rewording of the proposal, the proposal doesn't change. Rawhide the path on the mirror (pub/fedora/linux/releases/development/) never freezes, never stops. It's always developmental and testing packages. It is always there. It never freezes. You can turn on that repo and just run with it from now until you decide you don't want to use computers anymore. The proposal, both wordings, say that we'll stop slowing down rawhide, stop trying to use that path as a testing/polish point for a release. We'll do that somewhere else and let rawhide keep flowing. So you can continue to run rawhide all you want. Your entry point to rawhide may change slightly, you may have to start with the current Fedora release or the current testing release for the next Fedora, and then upgrade to the rawhide package set, but once you've done that you just stick on rawhide and never look back. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 22 Oct 2009, Chuck Anderson wrote: On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Pete Zaitcev writes: On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha ngomp...@gmail.com wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. Sounds like a kludge to work around limitations of dpkg. Not really. Something like this would allow you to have a single boot image for both 32 and 64 bit hosts. 32 bits will be here for a long, long time, of course, but its days are numbered, so I don't think it makes practical sense to invest the effort in implementing FAT ELF format. There might be some practical benefit if its scope was expanded to support arbitrary binary ABIs, i.e. a single ELF image containing x86_64 and sparc64, perhaps. pgpPUNmFHH98g.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
Le Jeu 22 octobre 2009 23:20, Jesse Keating a écrit : So you can continue to run rawhide all you want. Your entry point to rawhide may change slightly, you may have to start with the current Fedora release or the current testing release for the next Fedora, and then upgrade to the rawhide package set, but once you've done that you just stick on rawhide and never look back. IMHO you should be honest and call your F-next rawhide, and find some other name for the experimental stuff sandbox. Because your F-next is effectively what rawhide has been since before Fedora, and your rawhide is what people who do not care about releng have been trying to turn rawhide into in the past years. Well they can get their no-rules playground but I don't see why we should also give them the rawhide name. It has a fine history, much better than the eating babies ogre caricature. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 2009-10-22 at 16:42 -0500, Mike McGrath wrote: Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. Uh, we do? No-one's ever indicated that to me. Why would it be discouraged? Doesn't RH like its contributions to Fedora to be clear? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, Oct 22, 2009 at 04:42:16PM -0500, Mike McGrath wrote: On Thu, 22 Oct 2009, Chuck Anderson wrote: On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. Err surely just the opposite. At least anyone who works on both RHEL and Fedora will use their @redhat.com address because they need this to be able to see private BZ comments most people don't want to constantly be switching between 2 BZ account logins just to use alternate addr for Fedora. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
Le Jeu 22 octobre 2009 23:45, Adam Williamson a écrit : On Thu, 2009-10-22 at 16:42 -0500, Mike McGrath wrote: Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. Uh, we do? No-one's ever indicated that to me. Why would it be discouraged? Doesn't RH like its contributions to Fedora to be clear? The right solution is just to have some manager as fallback address. Telling people to use a non-rh address when their Fedora activity is linked to their @rh work is ridiculous. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, Oct 22, 2009 at 11:02:42 -0700, Jesse Keating jkeat...@redhat.com wrote: Yes, but it may happen before the bodhi stage, when we get autoqa working on post-build tests. This kind of check could happen at SCM commit time, package build time, or finally bodhi push time. Seems reasonable that we'd want to catch it as early as possible, but that does force people to work on rawhide first, then work on the pending release which may be under critical time pressure. Certainly something to discuss. Catching it at bodhi time seems too late. The *.fcxx.1 trick can be used to work around that if necessary. That may not be desirable though, as it seems to catch people by surprise. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 22 Oct 2009, Daniel P. Berrange wrote: On Thu, Oct 22, 2009 at 04:42:16PM -0500, Mike McGrath wrote: On Thu, 22 Oct 2009, Chuck Anderson wrote: On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ We generally discourage it but several still do it. Err surely just the opposite. At least anyone who works on both RHEL and Fedora will use their @redhat.com address because they need this to be able to see private BZ comments most people don't want to constantly be switching between 2 BZ account logins just to use alternate addr for Fedora. I actually have both. rhel bugs get assigned to svidal at redhat.com fedora bugs go to skvidal at sethdot.org -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
pxe-kexec
A few months ago I put together a package for pxe-kexec, a tool that uses kexec to boot already-running machine from a PXE server, which is handy for kicking off OS installs remotely. The package has been reviewed and is ready to go, except I'm not sponsored and haven't found the time to become one. Given my priorities I don't think I'd make a very responsive maintainer for pxe-kexec, but if anyone is interested in stepping in, please be my guest. https://bugzilla.redhat.com/show_bug.cgi?id=508352 --Ed -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 2009-10-22 at 18:26 -0400, Seth Vidal wrote: I actually have both. rhel bugs get assigned to svidal at redhat.com fedora bugs go to skvidal at sethdot.org Many people aren't willing to jump through the hoops necessary to manage that separation. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
On Thu, 2009-10-22 at 14:18 -0700, Adam Williamson wrote: I have two particular nits with it. One, it's pretty unwieldy, especially for part time maintainers (thinking how many hoops we'll have to jump through just to keep our packages up to date). Having to jump through the Bodhi hoops every time we just want to put a trivial update into a release that won't be coming out for five months feels like a pain. Who said anything about 5 months. 3 months max, which is just slightly longer than the amount of time they spend now doing Trac tickets to get something in. I'd worry about a lot of stuff going stale and smelly in the middle of the Bodhi process somewhere as maintainers lose track of where the hell they're up to with the four releases they have to cope with (the last two already-released releases, the upcoming release, and rawhide). rawhide would never use bodhi. If you build in devel/ it shows up in rawhide the next day. End of story. Bodhi would only be used for the pending and already done releases. Two, it makes testing things a bit more complex. Those of us who like to test upcoming stuff in real use - i.e. on our main machines - will have to choose whether to test rawhide, in which case we'll have more pain to deal with ourselves and won't be contributing as much to testing of the next stable release, or test the next stable release, in which case we aren't helping maintainers by making sure the stuff they're putting in rawhide isn't totally broken. For people like you, you'd just keep jumping when we branch off the next release. Like it or not, this is happening /already/. dist-f13 already has 953 packages with updates, and it isn't published /anywhere/ for /anybody/ to test it. We can only make that better, not worse. But overall, the positives could certainly outweigh the negatives. Just thought I'd flag up the two major concerns I have in case anything could be done about them. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
I think this is an awesome idea, and yes I think this version of the verbage is more clear. Kudos to Jesse (and all those involved in the development of the idea of the split rawhide) and I hope to see this come to fruition. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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?
Hi, On 22.10.2009 19:29, Quentin Armitage wrote: 1. Is the script that is run and produces the output at http://jkeating.fedorapeople.org/needed-f12-rebuilds.html actually the script referred to at the bottom of that page (https://fedorahosted.org/rel-eng/browser/scripts) ? The reason I ask is that when I run the script, I get Included Koji instances: http://koji.fedoraproject.org/kojihub http://sparc.koji.fedoraproject.org/kojihub http://s390.koji.fedoraproject.org/kojihub http://arm.koji.fedoraproject.org/kojihub whereas the posted output only has Included Koji instances: http://koji.fedoraproject.org/kojihub http://sparc.koji.fedoraproject.org/kojihub It is, but Jesse has disabled the other Koji hubs because sometimes they just time out, unfortunately. 2. If the script is run against just koji.fedoraproject,org/kojihub (i.e. without the sub arches), it says 185 packages need rebuilding (instead of the 175 listed in the report); the following 10 packages are omitted when the sparc koji hub is also included: gmpc HippoDraw itcl latex2rtf prtconf PyKDE python-igraph silo spicebird xorg-x11-drv-sunffb This is caused by line 117 of the script: unbuilt = unbuilt unbuiltnew so if a package needs to be rebuilt on the primary arch, but not on the (in this case sparc) secondary arch, then it is dropped from needing to be rebuilt Yes, that's how I did it -- my primary goal was to clear the list off secondary-arch-only stuff. There might be of course some cases like if somebody rebuilds a package only for a secondary arch but not for the primary one, but I don't think this is much a problem (there won't be many compared to the -- increasing -- number of secondary-arch-only stuff which we won't need). (it appears that a package will only be listed if it needs to be rebuild on every arch). No, the package appears if there is no build after the specified date in any of the archs (to be clear: as soon as the package is built in at least one arch, it will get off the list). There are several circumstances where this can happen (with the 10 missing packages listed): Built on sub arch but failed on primary arch gmpc - 0.18.0-1 build on sparc after epoch but 0.18.0-2 failed on koji HippoDraw itcl latex2rtf python-igraph Yes, those are not caught by this script now and should be rebuilt in primary arch as well of course. Not a primary arch package (should the package be blocked in the primary arch kojihub?) == prtconf silo xorg-x11-drv-sunffb There are much more of them! I don't know whether it is possible to block a package in a single Koji hub and if our infrastructure team is willing to go in this way -- Jesse? Blocked on secondary arch (so not included in unbuiltnew) = spicebird Should be probably blocked in all hubs too. The blocking mechanism definitely doesn't serve instead of ExcludeArch, am I right? Built on sub arch but not submitted for rebuild on primary arch PyKDE Should be rebuilt (I just started the build). Package does not exist in secondary arch (no example) = Would it be more relevant to list what needs to be rebuild separately for each arch (but see point 3 below)? 3. So far as I can see, there have not been mass rebuilds on the secondary arches, so is it relevant to search them for successful builds since the epoch? If it is relevant, they would appear to have different epochs in any case. Well, when I got to modifying the script (about half a year ago), the main problem was that there was too much noise consisting in secondary-arch-only packages. At that time there were more than 100 of such builds which is quite a lot. Also, secondary archs (re)builds are completely in the hands of secondary arch maintainers, they're not bound to the primary archs mass rebuilds. 5. I have looked at the 185 packages that have not been rebuilt, and the reasons fall into the following categories (details for each package are listed later): 1. Not submitted for rebuild (65) Yeah, there were some problems during the mass rebuild, IIRC (esp. with packages starting with o*, p* and maybe others). They should be definitely rebuilt. Looking at your lists, when rebuilding packages you should be aware of: 1) secondary-arch-only packages (xorg-x11-drv-sun*) 2) dead packages not blocked in Koji (a package is dead iff there is a dead.package file in the CVS; if it is then not blocked in Koji, please report to Jesse). 3) packages not built yet because they've just passed the review. I have made some changes to need-rebuild.py to produce some of the information above, and am happy to provide them if they are of any interest. Great! The more people get involved, the better:) Regards, Milos -- fedora-devel-list mailing list
RE: pxe-kexec
I'll take it if that's ok. I'm new to packaging and looking for more experience. -Scott -Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list- boun...@redhat.com] On Behalf Of Ed Swierk Sent: Thursday, October 22, 2009 6:12 PM To: Development discussions related to Fedora Subject: pxe-kexec A few months ago I put together a package for pxe-kexec, a tool that uses kexec to boot already-running machine from a PXE server, which is handy for kicking off OS installs remotely. The package has been reviewed and is ready to go, except I'm not sponsored and haven't found the time to become one. Given my priorities I don't think I'd make a very responsive maintainer for pxe-kexec, but if anyone is interested in stepping in, please be my guest. https://bugzilla.redhat.com/show_bug.cgi?id=508352 --Ed -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, 22 Oct 2009, Jesse Keating wrote: On Thu, 2009-10-22 at 18:26 -0400, Seth Vidal wrote: I actually have both. rhel bugs get assigned to svidal at redhat.com fedora bugs go to skvidal at sethdot.org Many people aren't willing to jump through the hoops necessary to manage that separation. I comment on all bugs from .redhat.com so there is less hoop jumping. but I get your point. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
King InuYasha wrote: I dunno, it could be useful for Live CDs/USBs. It would let you pack multiple arches onto a single LiveCD/USB. The Live CDs are already full without supporting this completely useless feature. Surely, the real solution is to position the 64-bit version more prominently (instead of driving everyone to the obsolescent 32-bit version), not to bloat the CDs with double-size binaries. You sound like one of those crazy people that disregard everything that may slightly help proprietary software. I don't see why we should ship our own binaries in a format which ONLY helps proprietary software. They can ship whatever they want if they can get the kernel to accept their nonstandard ELF. (That said, it's true that I also do think supporting anything which only helps proprietary software is counterproductive. This also includes some stuff we're currently doing, like shipping ancient compat-libstdc++ versions. We need to encourage third-party developers to ship Free Software, not proprietary software! But that wasn't even the point here, supporting Fat ELF isn't what I primarily object to, using it is!) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The future of rawhide (was [Fwd: Re: What is the Fedora Project?])
I would also like to jump on the help train if there is anything I am able to lend a hand with. -Adam (From Android) On Oct 22, 2009 9:05 PM, Mike McGrath mmcgr...@redhat.com wrote: On Thu, 22 Oct 2009, Adam Miller wrote: I think this is an awesome idea, and yes I think this ve... I agree, how can I help? -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/list... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Alexander Boström wrote: There's already lib / lib64 for parallell-installation of libraries, though granted it's limited to only two arches, but yes, something that covers bin too would be useful. bin is not multilib for a reason. You don't need 32-bit binaries on a 64-bit machine unless there's no 64-bit version. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Survey - May 2009
Jeff Spaleta wrote: On Wed, May 27, 2009 at 3:31 AM, Rahul Sundaram sunda...@fedoraproject.org wrote: Hi I did a quick survey from Fedora on what software Fedora users are using that is not available in the repo. Here are the results. If you find anything interesting, feel free to pick it up. https://fedoraproject.org/wiki/Packaging_Survey_May_2009 eucalyptus has a non-trivial list of java deps that we don't have packaged yet. I looked at the 1.5 pre-release tarballs in launchpad before ecualyptus opened up its bzr trees to the public. Ubuntu seems to have initially solved this problem in a way that our packaging review process would definitely not allow. They lumped a lot of individual java codebased together into a single package in order to streamline the effort to get eucalyptus into universe. http://packages.ubuntu.com/jaunty/eucalyptus-javadeps It would take a concerted effort of a number of contributors with reasonable java packaging experience to work together and coordinate package reviews to build up the complete set of java packages needed for full eucalyptus functionality. I would definitely not be among them. If people are serious about it. I really suggest they start forming up a team and start working on it now with F12 as a target release for the first full set of packages. -jef Did eucalyptus ever get packaged for F12 ? I didn't find anything in rawhide today when I checked it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 24613] fc-query can't query face 0
http://bugs.freedesktop.org/show_bug.cgi?id=24613 --- Comment #4 from Akira TAGOH ak...@tagoh.org 2009-10-21 23:37:27 PST --- (In reply to comment #3) Indeed, in the pattern you got after modifying that line, you see that charset is empty, that is, fontconfig could not recognize any character in the font and hence the face is useless. That's why fontconfig skips it. Sounds like NOTABUG to me. What kind of font is this? It's a Japanese bitmap font. so fontconfig is just checking to skip the broken BDF/PCF fonts highly likely not having any charset detected? I see - I don't still see there are any useful cases not skipping non-BDF/PCF fonts that has no charsets though. However the assumption as described at that comment isn't necessarily true. Since it was available before we are moving to Unicode, most BDF/PCF fonts available in the world should be encoded by none. but just put glyphs with the glyph IDs for the charset. in fact, it does in this case. FreeType is (internally) capable to add any CMaps that is used to look up the glyph ID from the character code though, no exported FT_CMap structure. if adding the own CMap to transcode Unicode to the charset, it may works as expected without modifying the application code. but I guess fontconfig won't support such fonts so far, because fontconfig and other rendering library focuses on Unicode only and using the internal APIs doesn't make sense? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 24613] fc-query can't query face 0
http://bugs.freedesktop.org/show_bug.cgi?id=24613 --- Comment #5 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-10-22 00:31:46 PST --- The correct solution is probably to write a filter that adds the freetype info to the font files, so they become normal unicody fonts any font libe can use. Then the fc-query error can be modified to just point people to this filter. I don't think Fedora should ship fonts that can not be used in fontconfig at this stage. If they can't be fixed easily, I'd say just drop them. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 530285] New: Specific Information about default font need to be displayed on global font settings' GUI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Specific Information about default font need to be displayed on global font settings' GUI https://bugzilla.redhat.com/show_bug.cgi?id=530285 Summary: Specific Information about default font need to be displayed on global font settings' GUI Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: fontconfig AssignedTo: besfa...@redhat.com ReportedBy: ape...@redhat.com QAContact: extras...@fedoraproject.org CC: besfa...@redhat.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-b...@redhat.com Classification: Fedora Target Release: --- Created an attachment (id=365660) -- (https://bugzilla.redhat.com/attachment.cgi?id=365660) Screenshot for the font GUI showing Sans Description of problem: (this cannot be termed as a bug) The default font for Malayalam in Fedora is smc-meera-fonts. When logging into Malayalam locale, the font details appearing on the GUI (System-Preferences-Appearance-Font) is as shown in screenshot. It says Sans instead of Meera. This does not give any information to the normal user about which font he is currently viewing on his desktop. I understand there are ways to get the font information from command line interface. But how to get this information on GUI? Please advise how this can be done and thus the purpose of GUI can be better served in a more useful way to the user. How reproducible: Always Steps to Reproduce: 1. Login to Malayalam (ml_IN) locale 2. Select System-Preferences-Appearance-Font) 3. Check the font information displayed on GUI Actual results: font appear as Sans Expected results: From user point of view I feel this must be shown as Meera, as Sans does not give any information about the default font used in Malayalam -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 530285] Specific Information about default font need to be displayed on global font settings' GUI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=530285 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG --- Comment #1 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-10-22 03:46:54 EDT --- This is not specific to Malayalam and is just the way the Linux font system works. We use synthetic fonts (not mere aliases) composed of many different fonts IIRC Microsoft has been copying this design in its new .Net stack -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 225617] Merge Review: bitmap-fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225617 --- Comment #24 from Pravin Satpute psatp...@redhat.com 2009-10-22 05:07:15 EDT --- (In reply to comment #23) 2. You have some stray fixed font in bitmap-console-fonts yep console9x15.pcf has written fontname FixedMedium in that case i think we will require Fixed subpackage, with this file included 3. Some of the files in bitmap-console-fonts declare their name as console8x8.pcf which is almost certainly a bug you are talking about fontname, or file name i did not found this in fontname, please provide bit more info. 4. The Lucida Typewriter fonts in bitmap-fonts should be pushed in a bitmap-lucida-typewriter-fonts subpackage in that case, bitmap-fonts rpm will be empty? 6. you can probably kill the common file and put each license %doc in the corresponding subpackage (just put the %doc line after the corresponding %_font_pkg call). You just need to have each subpackage require fontpackages-filesystem direcly so here we suppose to remove common package, also README will not require and put files for each subpackage in %doc, but we dont have any for console what to do for it? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 526204] Review Request: ucs-fixed-fonts selected set of bitmap fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526204 --- Comment #7 from Pravin Satpute psatp...@redhat.com 2009-10-22 06:01:59 EDT --- updated package link http://pravins.fedorapeople.org/ucs-miscfixed-fonts.spec http://pravins.fedorapeople.org/ucs-miscfixed-fonts-0.3-4.fc11.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/msimonson-anonymouspro-fonts/devel .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: ozamosi Update of /cvs/pkgs/rpms/msimonson-anonymouspro-fonts/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19493 Modified Files: .cvsignore sources Log Message: .cvsignore and sources entries for source Index: .cvsignore === RCS file: /cvs/pkgs/rpms/msimonson-anonymouspro-fonts/devel/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- .cvsignore 22 Oct 2009 04:48:01 - 1.1 +++ .cvsignore 22 Oct 2009 12:29:48 - 1.2 @@ -0,0 +1 @@ +AnonymousPro.zip Index: sources === RCS file: /cvs/pkgs/rpms/msimonson-anonymouspro-fonts/devel/sources,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- sources 22 Oct 2009 04:48:01 - 1.1 +++ sources 22 Oct 2009 12:29:48 - 1.2 @@ -0,0 +1 @@ +3cdcfc1979242670410e26ce42d226b0 AnonymousPro.zip ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/msimonson-anonymouspro-fonts/devel msimonson-anonymouspro-fonts-fontconfig.conf, NONE, 1.1 msimonson-anonymouspro-fonts.spec, NONE, 1.1
Author: ozamosi
Update of /cvs/pkgs/rpms/msimonson-anonymouspro-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25401
Added Files:
msimonson-anonymouspro-fonts-fontconfig.conf
msimonson-anonymouspro-fonts.spec
Log Message:
Add missing files
--- NEW FILE msimonson-anonymouspro-fonts-fontconfig.conf ---
?xml version=1.0?
!DOCTYPE fontconfig SYSTEM fonts.dtd
fontconfig
alias
familymonospace/family
prefer
familyAnonymous Pro/family
/prefer
/alias
alias
familyAnonymous Pro/family
default
familymonospace/family
/default
/alias
alias binding=same
familyAnonymous/family
accept
familyAnonymous Pro/family
/accept
/alias
/fontconfig
--- NEW FILE msimonson-anonymouspro-fonts.spec ---
%global fontname msimonson-anonymouspro
%global fontconf 61-%{fontname}.conf
%global archivename AnonymousPro
Name: %{fontname}-fonts
Version:1.001
Release:2%{?dist}
Summary:A coding-friendly monospace font
Group: User Interface/X
License:OFL
URL:http://www.ms-studio.com/FontSales/anonymouspro.html
Source0:http://www.ms-studio.com/FontSales/AnonymousPro.zip
Source1:%{name}-fontconfig.conf
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: fontpackages-devel
Requires: fontpackages-filesystem
%description
Anonymous Pro is a family of fixed-width fonts designed especially with coding
in mind. Characters that could be mistaken for one another (O, 0, I, l, 1,
etc.) have distinct shapes to make them easier to tell apart in the context of
source code.
It has support for most Western and European Latin-based languages, Greek, and
Cyrillic. It also includes special “box drawing” characters.
Anonymous Pro is based on an earlier font, Anonymous, which is a TrueType
version of Susan Lesch and David Lamkins’ font Anonymous 9, a freeware
Macintosh bitmap font.
%prep
%setup -q -n %{archivename}
for txt in OFL.txt OFL-FAQ.txt; do
fold -s $txt $txt.new
sed -i 's/\r//' $txt.new
touch -r $txt $txt.new
mv $txt.new $txt
done
%build
%install
rm -fr %{buildroot}
install -m 0755 -d %{buildroot}%{_fontdir}
install -m 0644 -p *.ttf %{buildroot}%{_fontdir}
install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
%{buildroot}%{_fontconfig_confdir}
install -m 0644 -p %{SOURCE1} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf} \
%{buildroot}%{_fontconfig_confdir}/%{fontconf}
%clean
rm -fr %{buildroot}
%_font_pkg -f %{fontconf} *.ttf
%doc *.txt
%changelog
* Sat Oct 17 2009 Robin Sonefors ozam...@flukkost.nu - 1.001-2
- Change summary, fix fontconfig file
* Thu Oct 15 2009 Robin Sonefors ozam...@flukkost.nu - 1.001-1
- Initial packaging
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 24613] fc-query can't query face 0
http://bugs.freedesktop.org/show_bug.cgi?id=24613 Behdad Esfahbod freedesk...@behdad.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 529196] Review Request: ms-anonymouspro-fonts - AnonymousPro fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=529196 --- Comment #8 from Fedora Update System upda...@fedoraproject.org 2009-10-22 11:11:18 EDT --- msimonson-anonymouspro-fonts-1.001-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/msimonson-anonymouspro-fonts-1.001-2.fc11 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/gdouros-aegean-fonts/devel gdouros-aegean-fonts-fontconfig.conf, NONE, 1.1 gdouros-aegean-fonts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: ozamosi
Update of /cvs/pkgs/rpms/gdouros-aegean-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16603
Modified Files:
.cvsignore sources
Added Files:
gdouros-aegean-fonts-fontconfig.conf gdouros-aegean-fonts.spec
Log Message:
First version
--- NEW FILE gdouros-aegean-fonts-fontconfig.conf ---
?xml version=1.0?
!DOCTYPE fontconfig SYSTEM fonts.dtd
fontconfig
alias
familyfantasy/family
prefer
familyAegean/family
/prefer
/alias
alias
familyAegean/family
default
familyfantasy/family
/default
/alias
/fontconfig
--- NEW FILE gdouros-aegean-fonts.spec ---
%global fontname gdouros-aegean
%global fontconf 65-%{fontname}.conf
Name: %{fontname}-fonts
Version:3.01
Release:2%{?dist}
Summary:A font for ancient scripts in the greater Aegean vicinity
Group: User Interface/X
License:Copyright only
URL:http://users.teilar.gr/~g1951d/
Source0:http://users.teilar.gr/~g1951d/Aegean.zip
Source1:%{name}-fontconfig.conf
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: fontpackages-devel
Requires: fontpackages-filesystem
%description
Aegean covers the following scripts and symbols supported by The Unicode
Standard 5.2: Basic Latin, Greek and Coptic, Greek Extended, some Punctuation
and other Symbols, Linear B Syllabary, Linear B Ideograms, Aegean Numbers,
Ancient Greek Numbers, Ancient Symbols, Phaistos Disc, Lycian, Carian, Old
Italic, Ugaritic, Old Persian, Cypriot Syllabary, Phoenician, Lydian, and
Archaic Greek Musical Notation.
Aegean also covers the following scripts and symbols not yet supported by
Unicode: Cretan Hieroglyphs, Cypro-Minoan, Linear A, the Arkalochori Axe,
Ancient Greek and Old Italic variant alphabets. These are allocated in the
Supplementary Private Use Plane 15.
It was created by George Douros.
%prep
%setup -q -c
%build
%install
rm -fr %{buildroot}
install -m 0755 -d %{buildroot}%{_fontdir}
install -m 0644 -p Aegean.otf %{buildroot}%{_fontdir}
install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
%{buildroot}%{_fontconfig_confdir}
install -m 0644 -p %{SOURCE1} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf} \
%{buildroot}%{_fontconfig_confdir}/%{fontconf}
%clean
rm -fr %{buildroot}
%_font_pkg -f %{fontconf} Aegean.otf
%doc Aegean.txt
%changelog
* Mon Oct 19 2009 Robin Sonefors ozam...@flukkost.nu - 3.01-1
- Fix description, License string
* Thu Oct 15 2009 Robin Sonefors ozam...@flukkost.nu - 3.01-1
- Initial packaging
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/gdouros-aegean-fonts/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 22 Oct 2009 04:49:14 - 1.1
+++ .cvsignore 22 Oct 2009 15:52:23 - 1.2
@@ -0,0 +1 @@
+Aegean.zip
Index: sources
===
RCS file: /cvs/pkgs/rpms/gdouros-aegean-fonts/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 22 Oct 2009 04:49:14 - 1.1
+++ sources 22 Oct 2009 15:52:24 - 1.2
@@ -0,0 +1 @@
+36201de0f8a523a3c002bb8619fc9da9 Aegean.zip
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 508899] Monospace no more
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=508899 --- Comment #12 from Behdad Esfahbod besfa...@redhat.com 2009-10-22 11:57:43 EDT --- I believe this is fixed in freetype 2.3.10. Building in rawhide. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 511580] FTBFS fonts-KOI8-R-1.0-11.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=511580 Matt Domsch matt_dom...@dell.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC||matt_dom...@dell.com Resolution||RAWHIDE --- Comment #8 from Matt Domsch matt_dom...@dell.com 2009-10-22 13:48:26 EDT --- http://koji.fedoraproject.org/koji/buildinfo?buildID=117606 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 529594] pango uses different fonts for LATIN and COMMON glyphs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=529594 --- Comment #20 from Behdad Esfahbod besfa...@redhat.com 2009-10-22 15:04:59 EDT --- Maybe someone can first describe what the problem is, without jumping to patching... My best guess so far is: In CJK locales, the Latin glyphs should be selected from the same font as the CJK glyphs, if the font supports that. If that's the problem, it's an old one, and one that we don't have a solution for just yet. Requires this before it can be fixed: https://bugs.freedesktop.org/show_bug.cgi?id=17311 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
