Re: Question about dist-cvs make targets
On Thu, 2010-01-07 at 07:51 -1000, David Cantrell wrote:
I was using 'unused-patches' until the packaging guidelines had us change
Patch lines to use %{name} if that applied. The unused-patches target would
be helpful if it could expand RPM macros.
That's a guideline worth ignoring.
If I'm being less charitable, that's a guideline worth deleting.
- ajax
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: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: I'd like to suggest an enhancement for Fedora 13: nothing should ever steal focus from the window I am typing in. If I am typing in a shell window, or in a word processor, or an e-mail, nothing should ever take keyboard focus away from that window. Clearly I'm missing something, otherwise we would have this, hence the posting to the list :) PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of you were just typing into some other window, this must be a focus steal, then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as stealing or not, then great. - ajax 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: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: On 1/6/10 11:07 AM, Adam Jackson wrote: PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of you were just typing into some other window, this must be a focus steal, then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as stealing or not, then great. I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. - ajax 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: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. And now make that work for the case where firefox decides to take 10 secs to start up, so you start in another window, then firefox jumps up and grabs focus. Thanks. There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. - ajax 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: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote: Quoting Adam Jackson (a...@redhat.com): On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. Yes, exactly. You're saying that 1. there are cases where you want a window to pop up 2. it's too complicated to figure out which windows should pop up 3. so windows should always pop up, no point being configurable and ridiculing us over (2). I'm saying there are no cases where I want a popup, so we can easily have 2 configurable options: always have windows pop up and take focus, never have them do so. Ahh, I see the misunderstanding here: I'm not arguing point three. I'm not even really arguing point 2, as you phrased it; it's not _too_ complicated, it's merely complicated. I'm arguing that there exists an implementation that tries to prevent focus stealing, and trying to illustrate why that's a hard problem. And thus, why the OP's RFE as stated, is either not achievable, or not desirable. I mean, in some sense, this is all academic anyway. It's trivial to write an X app that steals focus, regardless of what the window manager attempts to implement. But even assuming you're running relatively well-behaved applications, it's still not an easy problem. - ajax 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: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 13:27 -0500, Fulko Hew wrote: On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson a...@redhat.com wrote: There is no case where _you_ want this, sure. I'd say... only take focus if its a child/creation of the window currently in focus. creation of is not something that's particularly well defined in X. Child windows are clipped to (wholly contained within) their parent, so in the evolution example from earlier, the compose window is a child of the root window, not of the mailbox view window. So at window creation time, there's no obvious relationship between the compose and mailbox windows. They do happen to have the same WM_CLASS and WM_CLIENT_LEADER window properties. But that still only addresses automatic focus changes within a single application. Automatic focus changes across apps is probably desirable; otherwise, nothing you launch from the gnome panel will launch focused, which is rather absurd. - ajax 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: Should we digg PI
On Tue, 2010-01-05 at 20:22 +0200, Adrian wrote: Hi, A news of a new calculation of PI is on the net. Should we digg (http://digg.com/d31EgvV) the article in order to promote the fact that the author used Fedora 10 for he's success ? This sounds like a question about Fedora advocacy, not Fedora development. You probably want fedora-ambassadors-l...@. - ajax 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: FESCo election results December 2009
On Fri, 2009-12-18 at 12:19 -0500, Paul W. Frields wrote: Information: At close of voting there were: 216 valid ballots Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 That's right, I'm so awesome I got more than the maximum number of votes. - ajax 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: Add extra generated RPM requires - how?
On Fri, 2009-12-18 at 20:26 +, Richard W.M. Jones wrote: For libguestfs [RHBZ#547496] I want to add some extra 'Requires' dependencies by running a shell script over a particular file that gets generated during the build. What's the best way, or a way, to do this? It's... not easy. You want to overload the %__find_provides macro to invoke your script as well as the standard script for things like library sonames. If you get it working let me know, I want basically the same thing for the X server and have so far been defeated. - ajax 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: X on UEFI systems.
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: On 12/11/2009 02:41 PM, Adam Williamson wrote: On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). ...nd (oh boy, I love it when a plan comes together) mark it as blocking F13Beta , because I reckon this breaks beta criterion #4: https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria I like the sentiment here, but I'm not sure this is really in the spirit of the criteria - Vasily, as I understand it, is still in the process of implementing the support for UEFI on VirtualBox. There's at least two issues here. One is that we're not shipping the native X driver for vbox video yet. Last I checked this was because it's hidden away in the vbox source, and didn't build against whatever X server we were shipping, and that vbox upstream didn't _want_ it shipped externally yet because they hadn't finalized the interface. The other is that the kernel doesn't seem to be binding an efifb device to it, and/or that it is and X is not noticing that and thus loads vesa instead of fbdev. - ajax 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: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Wed, 2009-12-02 at 11:01 +, Ikem Krueger wrote: Nope, Bryce doesn't get to work on upstream in any significant way as part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.) Did you chatted with Bryce? Let's chat with git: atropine:~/xserver% git log --author=bryce | grep -c ^commit 0 atropine:~/drivers/intel% git log --author=bryce --pretty=oneline 6b93afc564a5e74b0eaaa46c95f557449951b3b9 add pipe a force quirk for Dell mini 6c56521bdc0443c0656271caaa795feb13bc1d6b pipe-a quirk for thinkpad x30 83377b543defdca7226d7c1a7794e4ff3d8b4c84 Pipe-A quirk for HP 2730p (bug #18852) 6c4e134a1a30785c2e5c6d57b21fde54a2dd3413 PipeA quirk for Quanta/W251U (launchpad bug #244242) afa630b448e5993850433c9f0b129758ec4d37b5 Add TV out quirk for HP Compaq nx6110 231a302013981cc597ba09ee89b367c8ab56e8ba Two more Dell quirks d91d9e6a2f2ba18b35cb6fd7bc3fe8bc617eb44f More Pipe A force quirks be746a90a87d7a9807fa4243493e7e4d48f7f1c0 More quirks from ubuntu/dell 37bc23660a8c346f1eaa6c93ed2c7a840828f0b0 Quirks from Ubuntu/Dell atropine:~/drivers/ati% git log --author=bryce --pretty=oneline c71b2f050e8996787eae463eddbfdb5864ffa65a radeon: AGPMode quirk needed for SiS e3659ed06fc5bb8817f1dbd7c2d6bc94c67b30f7 radeon: AGPMode quirk needed for IBM Thinkpad T40 with Mobility M7 LW 2391531ed6b7c11ddd5ab91b2369821cc5f8b8a7 radeon: AGPMode quirk needed for HP Omnibook 6200 49b57767d0d2c041517b0764c2ed2d2ba5a7092c Quirk for RV280 on 82865G/PE/P DRAM Controller/Host-Hub fe73d9a7dfe8ec5c8f1a8dc08e14b4e138aa9276 Add another AGP quirk 36a7dc6ea1e1929e986ab1159497c71521cb2f10 Additional AGP quirks 937b7ac2a259cf504a19dcf62a58b1db1afb8eb9 Add AGP quirk table 1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445 radeon: Fix pasto in connector table setup for vga powerbooks - ajax 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: Notification of uploads to the lookaside cache
On Sat, 2009-11-21 at 19:34 -0500, Jon Stanley wrote: As part of our ever vigilant stance towards security around our packaging process, we have added a new feature to upload.cgi (which accepts file uploads into the lookaside cache) which will email the package owner (package-ow...@fedoraproject.org, specifically) and fedora-extras-comm...@redhat.com whenever a file is uploaded to the lookaside cache. Previously this was a big black box and an area of concern. The message will contain the name of the file, the package concerned, the md5sum, and the user that uploaded it. An example is below: File upload.cgi for package sportrop-fonts has been uploaded to the lookaside cache with md5sum 26489f9e92601f0f84cfbb278c2b98e1 by jstanley Please let me know if you have any questions, comments, or room for improvement! Can we get an X-Fedora-Upload: header in these or something? Filtering by subject line always makes me feel dirty. - ajax 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: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Mon, 2009-11-30 at 10:01 -0700, Linuxguy123 wrote: http://www.linux-magazine.com/Online/News/Ubuntu-X.org-Guru-Calls-for-Desktop-Help Let's see if I can summarize this article: - we're getting too many bugs - more testing will find more bugs - therefore we should test more so we have fewer bugs Interesting bit of logic there. - ajax 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: [RFC] unified i386/x86_64 install media.
On Tue, 2009-11-24 at 13:50 -0600, Dennis Gilmore wrote: syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. As I'm actually trying this on one of the laptops on my desk, I'd point out that this almost certainly requires yum changes to work well. yum gets its idea of arch from uname, which reports what the kernel is, not what the current glibc is. Not that it's not a good idea - it seems to work surprisingly well - but it's not turnkey yet. - ajax 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: Right-click for wacom driver?
On Sun, 2009-11-22 at 15:25 -0800, Luya Tshimbalanga wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While working on Flash development in Windows XP TabletPC, I noticed the right-click is done by pressing the stylus for few second and icon will display the right-click mouse delay. I wonder if the new xorg-x11-drv-wacom can do similar action for stylus that don't have eraser action. I am not sure if the current linuxwacom can do similar action. If so, how can it be done? In related news, I have a tablet PC where the button on the stylus is right-click under Windows, but appears to be Erase under X, meaning I don't have any way to right-click. Worth changing the default? Alternatively, is Gnome getting a UI and gconf persistence for input settings any time soon? - ajax 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: abrt + X Error = zillions of duplicate bug reports?
On Sun, 2009-11-22 at 19:21 +0100, Martin Sourada wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) I know this is non-obvious, but: BadIDChoice or BadImplementation X errors are _always_ bugs in libX11 or the server itself, respectively. Please reassign BadIDChoice bugs to libX11. - ajax 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: Identifying remaining core font users
On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: Nicolas Mailhot nicolas.mail...@laposte.net writes: Therefore, I'd like to identify remaining core font users, and remind them periodically their core font use is not good for their users or for Fedora. What's wrong with proving support for core fonts as a fallback? That's what Emacs is doing, for example. As a fallback for what? - ajax 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: Identifying remaining core font users
On Thu, 2009-11-12 at 16:00 +0100, Andreas Schwab wrote: Adam Jackson a...@redhat.com writes: On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: Nicolas Mailhot nicolas.mail...@laposte.net writes: Therefore, I'd like to identify remaining core font users, and remind them periodically their core font use is not good for their users or for Fedora. What's wrong with proving support for core fonts as a fallback? That's what Emacs is doing, for example. As a fallback for what? If a suitable xft font is not found. Though the X server is not using fontconfig for finding fonts (for lame historical reasons), it looks in a subset of the set of paths that fontconfig will look at. (Xft is a renderer, not a font looker upper, but your meaning was clear.) - ajax 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: drop SECURITY_FILE_CAPABILITIES? (fwd)
On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote: On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote: How might this affect the Fedora kernel? We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway. google codesearch to the rescue: http://google.com/codesearch?hl=ensa=Nfilter=0q=prctl.*PR_CAPBSET_DROP - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rpms/xorg-x11-font-utils/devel .cvsignore, 1.14, 1.15 sources, 1.14, 1.15 xorg-x11-font-utils.spec, 1.34, 1.35
Author: ajax
Update of /cvs/pkgs/rpms/xorg-x11-font-utils/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9202
Modified Files:
.cvsignore sources xorg-x11-font-utils.spec
Log Message:
* Tue Nov 10 2009 Adam Jackson a...@redhat.com 7.2-11
- font-util 1.1.0
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/.cvsignore,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -p -r1.14 -r1.15
--- .cvsignore 13 Oct 2009 19:59:49 - 1.14
+++ .cvsignore 10 Nov 2009 19:08:06 - 1.15
@@ -5,3 +5,4 @@ mkfontscale-1.0.1.tar.bz2
bdftopcf-1.0.1.tar.bz2
mkfontscale-1.0.7.tar.bz2
mkfontdir-1.0.5.tar.bz2
+font-util-1.1.0.tar.bz2
Index: sources
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/sources,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -p -r1.14 -r1.15
--- sources 13 Oct 2009 19:59:49 - 1.14
+++ sources 10 Nov 2009 19:08:06 - 1.15
@@ -1,5 +1,5 @@
-b81535f78fe05732931f02841e5ca37b font-util-1.0.1.tar.bz2
b0ebd86029571239b9d7b0c61191b591 fonttosfnt-1.0.3.tar.bz2
9685fab33d39954ab8a0d22e0969d5a4 bdftopcf-1.0.1.tar.bz2
96ca346f185c0ab48e42bf5bb0375da5 mkfontscale-1.0.7.tar.bz2
9365ac66d19186eaf030482d312fca06 mkfontdir-1.0.5.tar.bz2
+9538043de60d685fc4253b0dc2924d58 font-util-1.1.0.tar.bz2
Index: xorg-x11-font-utils.spec
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/xorg-x11-font-utils.spec,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -p -r1.34 -r1.35
--- xorg-x11-font-utils.spec13 Oct 2009 19:59:49 - 1.34
+++ xorg-x11-font-utils.spec10 Nov 2009 19:08:06 - 1.35
@@ -5,7 +5,7 @@ Name: xorg-x11-%{pkgname}
# IMPORTANT: If package ever gets renamed to something else, remove the Epoch
line!
Epoch: 1
Version: 7.2
-Release: 10%{?dist}
+Release: 11%{?dist}
License: MIT
Group: User Interface/X
URL: http://www.x.org
@@ -15,7 +15,7 @@ Source0: ftp://ftp.x.org/pub/individual/
Source1: ftp://ftp.x.org/pub/individual/app/fonttosfnt-1.0.3.tar.bz2
Source2: ftp://ftp.x.org/pub/individual/app/mkfontdir-1.0.5.tar.bz2
Source3: ftp://ftp.x.org/pub/individual/app/mkfontscale-1.0.7.tar.bz2
-Source4: ftp://ftp.x.org/pub/individual/font/font-util-1.0.1.tar.bz2
+Source4: ftp://ftp.x.org/pub/individual/font/font-util-1.1.0.tar.bz2
Patch0: font-util-1.0.1-mapdir-use-datadir-fix.patch
Patch1: font-util-1.0.1-autoconf-add-with-fontdir-option.patch
@@ -47,8 +47,8 @@ populated fonts.
%prep
%setup -q -c %{name}-%{version} -a1 -a2 -a3 -a4
-%patch0 -p0 -b .font-util-mapdir-use-datadir-fix
-%patch1 -p0 -b .autoconf-add-with-fontdir-option
+#patch0 -p0 -b .font-util-mapdir-use-datadir-fix
+#patch1 -p0 -b .autoconf-add-with-fontdir-option
%build
# Build all apps
@@ -61,7 +61,8 @@ populated fonts.
autoconf
;;
esac
- %configure
+ # this --with-mapdir should be redundant?
+ %configure --with-mapdir=%{_datadir}/X11/fonts/util
make
popd
done
@@ -113,6 +114,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Nov 10 2009 Adam Jackson a...@redhat.com 7.2-11
+- font-util 1.1.0
+
* Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.2-10
- mkfontscale 1.0.7
- mkfontdir 1.0.5
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: odd file requires
On Mon, 2009-11-09 at 11:58 -0500, Seth Vidal wrote: Hey folks, I put together this list for things I'd like to work on for f13. It's a list of packages with a file-requires that falls outside of *bin/* and /etc/* and then the provider(s) for those files. http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt I've gone through some of them and I'm looking for where we can clean up a few more. Take a look through, see if you see a package you're responsible for and, if you can, figure out a way to not need the file-requires. Well, I'm on the provider end of these two. /usr/share/X11/app-defaults Required By: x11-ssh-askpass-1.2.4.1-7.fc12 Provided By: libXt-1.0.7-1.fc12 libXt is always going to be the thing providing this, app-defaults are an Xt-ism. /usr/share/X11/rgb.txt Required By: perl-Image-Info-1.28-4.fc12 Provided By: xorg-x11-server-utils-7.4-13.fc12 Requires: rgb is sufficient for the same reason. Fixed both in devel/. - ajax 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
rpms/perl-Image-Info/devel perl-Image-Info.spec,1.25,1.26
Author: ajax
Update of /cvs/pkgs/rpms/perl-Image-Info/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19121
Modified Files:
perl-Image-Info.spec
Log Message:
* Mon Nov 09 2009 Adam Jackson a...@redhat.com 1.28-5
- Requires: rgb, not Requires: /usr/share/X11/rgb.txt
Index: perl-Image-Info.spec
===
RCS file: /cvs/pkgs/rpms/perl-Image-Info/devel/perl-Image-Info.spec,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -p -r1.25 -r1.26
--- perl-Image-Info.spec26 Jul 2009 08:47:56 - 1.25
+++ perl-Image-Info.spec9 Nov 2009 19:24:19 - 1.26
@@ -2,7 +2,7 @@
Name: perl-Image-Info
Version:1.28
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Image meta information extraction module for Perl
Group: Development/Libraries
@@ -14,7 +14,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(Image::Xbm), perl(Image::Xpm), perl(XML::Simple)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
-Requires: %{rgbtxt}
+Requires: rgb
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Nov 09 2009 Adam Jackson a...@redhat.com 1.28-5
+- Requires: rgb, not Requires: /usr/share/X11/rgb.txt
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.28-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Wed, 2009-11-04 at 08:38 -0800, John Reiser wrote:
I have three applications that fundamentally fail to work
if mmap(0,PAGE_SIZE,,MAP_FIXED,,) is disallowed. Addressing
memory at address 0 is fundamental to the way that they work.
Using any other page would totally prevent two of the apps
from working at all, and would severely cripple the third.
They are not old [W]indows apps. They are every-day utilities
and development tools written for Linux, and I object to them
being broken.
You're saying you have apps that rely on being able to dereference the
zero page, and _not_ because the processor mode requires it? I thought
the vax died long ago.
The kernel could remove 99.9% of the vulnerability, with
no dynamic cost to processes that don't use page 0, by:
1. Reduce STACK_TOP by one page, and reserve the corresponding
virtual page frame.
2. If a process does mmap(0,,,MAP_FIXED,,) then turn on the
process status bit which forces slow path for kernel entry
via system call from that process. In the slow path, check for
a mapping at page 0 and if so then move that mapping to the
reserved page at STACK_TOP, and turn off the mapping at page 0.
Reverse the substitution when returning from the syscall.
3. Add the necessary check in the trap handler for
copy_{to,from}_user() to handle intended kernel access to page 0
(including I/O) by substituting the reserved page instead.
This would allow mmap(0,,,MAP_FIXED,,) yet still protect all
synchronous kernel execution. The only remaining window of
vulnerability is interrupt handlers. If an interrupt handler
is touching *any* user address space then the problems are more
serious than mmap(0).
The problem is that the address space doesn't change when in the
interrupt handler; the zero page will still be mapped, so if there's a
bug in the interrupt handler that would normally oops, well, now it
won't.
Yes, bugs like that _have_ been found. Pretty sure they've been
exploited in the wild too.
You could probably fix this by checking if the zero page is mapped at
any context switch into the kernel (including interrupt) and doing
mprotect(PROT_NONE) on it if so. This adds a small but more or less
fixed overhead on every interrupt, plus a fairly high overhead when an
interrupt fires while the zero-mapping process is running.
- ajax
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: PPC not getting __WORDSIZE set
On Mon, 2009-11-02 at 23:34 +0100, Jakub Jelinek wrote: On Mon, Nov 02, 2009 at 05:15:50PM -0500, Bryan Kearney wrote: Word of warning.. I am no too familiar with C across platforms. I am trying to package ruby-ffi (spec file is at [1]) and when I do a scratch build in Koji [2] it runs fine on x86 but is failing in ppc_64. It appears that __WORDSIZE is not being set [3]. I looked at the CFLags for the x86_64 and they are the same, so I assumed things would run fine. Can anyone point me at what to look at next? __WORDSIZE is a glibc internal macro, packages shouldn't be using it. Whether it is defined or not depends on whether any of the headers that are included needed to check that macro or not. You should be using __LP64__ or similar macros instead. atropine:~% : | cpp -dM | grep -c LP 0 What header defines __ILP32__ or __LP64__? Of course there's also: atropine:~% : | cpp -dM | grep SIZEOF #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __SIZEOF_LONG__ 4 #define __SIZEOF_LONG_DOUBLE__ 12 #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 #define __SIZEOF_PTRDIFF_T__ 4 #define __SIZEOF_FLOAT__ 4 #define __SIZEOF_SHORT__ 2 #define __SIZEOF_WCHAR_T__ 4 #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_LONG_LONG__ 8 - ajax 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: A question about allow_unconfined_mmap_low in f11 amd selinux
On Tue, 2009-11-03 at 21:31 +, Mike Cloaked wrote: For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? You can't. If I'm being slightly less flip: run wine in a kvm instance with selinux disabled, forward X to the host. - ajax 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: What to do with package that wants to use sse?
On Sat, 2009-10-31 at 09:25 +0100, Nicolas Chauvet wrote:
2009/10/31 Bruno Wolff III br...@wolff.to:
I am working on packaging pagedgeometry and I noticed that when building
on gcc it passes -msse which I am guessing says to use sse instructions.
I think that even in F12 we can't assume these instructions are available.
The package may gain a lot of benefit from using those instructions.
(I haven't tested that yet as I am still pretty early in the process.)
Is there some relatively standard way to handle something like this?
-msse is fine for x86_64 and ia64 by default (but not for non-intel arches).
The only way to have sse enabled on ix86 is for a library to be built
twice, the provides the sse version in %{_libdir}/sse2. The linker
will then enable the appropriate library at runtime.
Strictly, this is not true. Newer binutils has a feature called
indirect functions that lets you do (logically, this is not what the
syntax actually looks like):
typedef void *(*memcpy_func)(void *, void *, size_t);
static void *_mmx_memcpy(void *d, void *s, size_t n) { ... }
static void *_sse_memcpy(void *d, void *s, size_t n) { ... }
/* ... */
__attribute__((indirect)) memcpy_func *memcpy()
{
if (has_mmx())
return _mmx_memcpy;
if (has_sse())
return _sse_memcpy;
/* ... */
}
The indirect function is called at symbol resolution time instead of the
normal lookup rules, so you can build a single object with support for
multiple ISA extensions, without the runtime lookup penalty.
- ajax
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: What to do with package that wants to use sse?
On Mon, 2009-11-02 at 08:49 -0600, Bruno Wolff III wrote: On Mon, Nov 02, 2009 at 09:43:30 -0500, Adam Jackson a...@redhat.com wrote: Strictly, this is not true. Newer binutils has a feature called indirect functions that lets you do (logically, this is not what the syntax actually looks like): Can you point us to some documentation on this? Is this something that is encouraged for use in Fedora? Well, the best documentation I can find is the thread discussing the implementation: http://www.x86-64.org/pipermail/discuss/2009-June/010546.html and the testcase in binutils: http://github.com/jiez/binutils/blob/master/ld/testsuite/ld-ifunc/lib.c glibc seems to be using it in a few places in F12, so I can't imagine it's too broken. That said, I don't think it's the _recommended_ solution for Fedora yet. - ajax 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: Wodim trouble
On Mon, 2009-11-02 at 18:16 +0100, Michal Schmidt wrote: Dne 2.11.2009 17:31, Kevin Kofler napsal: Ankur Sinha wrote: wodim is completely unmaintained since May 6th 2007, don't expect to see any fixes anytime soon as long as Redhat continues to distribute wodim instead of the original software. Can someone please clear this up? It's just the usual FUD from Jörg Schilling. Ignore it. The latest commit to cdrkit upstream was 3 weeks ago. Although you are technically right, the commits for the last two years have been boring cleanups, typo fixes and warning silencers. They don't seem to be fixing any actual bugs in CD/DVD burning. The last commit that did something which looks like a technical change was indeed on 2007-05-06 ( http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?rev=767sc=1 ). Look here for the log and read the commit messages: http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=logrev=0sc=0isdir=1 So wodim does not look like a well maintained project to me. That may be true, but since cdrecord is not shippable, it's a pretty vacuous truth. The solution is obviously to fix the bug and help revive upstream, or else host a development tree on fh if upstream stays idle. - ajax 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: What requires libgcc, actually?
On Wed, 2009-10-28 at 10:41 +0100, Nicolas Chauvet wrote: 2009/10/28 Linus Walleij linus.ml.wall...@gmail.com: Just a quick question for those who know: The shared libs from libgcc: /lib/libgcc*so* are not required by anything: [r...@localhost ~]# rpm -q --whatrequires libgcc-4.4.1-2.fc11.i586 no package requires libgcc-4.4.1-2.fc11.i586 Use this instead: repoquery --whatrequires libgcc_s.so.1()(64bit) or on 32bit systems: repoquery --whatrequires libgcc_s.so.1 Or more generally: % repoquery --whatrequires --alldeps libgcc - ajax 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: RFC: proposed macro deffinitions for F-13
On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between 32bit/64bit
or
multilib arches have defines for the appropriate arches. sometimes
incomplete
since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should add.
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
Remind me what the asymmetry is for here? Why is %{ix86} not in
%{multilib32} ?
In general I'd kind of prefer to see headers modified to use gcc's
predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
can get.
- ajax
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: Looking into LLVM
On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote: On 10/26/2009 08:15 PM, Adam Jackson wrote: On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote: On 10/26/2009 07:03 PM, Adam Jackson wrote: On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote: I meant performance, primarily in terms of speed of compilation. Not the code itself. Suppose it's faster. Say even by a factor of 100. So what? What problem would that solve? The problem of slow compilation? :-) Which affects who? koji certainly seems to be keeping up with the load. What I'm trying to pry out of you is what you'd be hoping to accomplish by using it. The answer so far seems to be I'd spend less time building things, at the cost of some unknown amount of time invested in fixing everything to build again. That doesn't sound like progress. - ajax 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: Looking into LLVM
On Mon, 2009-10-26 at 20:21 +0530, Rahul Sundaram wrote: On 10/26/2009 08:21 PM, Adam Jackson wrote: Which affects who? koji certainly seems to be keeping up with the load. What I'm trying to pry out of you is what you'd be hoping to accomplish by using it. The answer so far seems to be I'd spend less time building things, at the cost of some unknown amount of time invested in fixing everything to build again. That doesn't sound like progress. Certainly status quo is easier. Less time building things is a obvious benefit. We don't know the cost unless we try. Doing a scratch build similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing that we should never try at all doesn't seem appealing to me. Please don't put words in my mouth, I did not say never try at all. I said that spending less time building things is only an obvious benefit if we don't lose real functionality, and don't waste time placating the compiler to get things to build. But hey, if you're volunteering to run the experiment, go wild. - ajax 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
On updates to stable releases
I don't really want to revive the thread about automake 1.11, but I do want to point out that it did break actual buildability: http://koji.fedoraproject.org/koji/getfile?taskID=1761549name=build.log Please, people. Don't update things in stable releases just for fun. Particularly if your package is part of the build environment for something else. I don't care if it bills itself as just a bugfix release; that's how you know it's lying. - ajax 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: On updates to stable releases
On Wed, 2009-10-21 at 16:30 -0400, Seth Vidal wrote: On Wed, 21 Oct 2009, Adam Jackson wrote: I don't really want to revive the thread about automake 1.11, but I do want to point out that it did break actual buildability: http://koji.fedoraproject.org/koji/getfile?taskID=1761549name=build.log Please, people. Don't update things in stable releases just for fun. Particularly if your package is part of the build environment for something else. I don't care if it bills itself as just a bugfix release; that's how you know it's lying. Except when it is just a bugfix release and it maintains api compat. Yum has been, on the whole, pretty good about maintaining compatibility while fixing bugs. I was being hyperbolic, yes. - ajax 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: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, 2009-10-08 at 23:56 -0400, James Antill wrote: On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote: The thing with doing updates for F11 is the regression rate due to lack of QA, I put Mesa packages into updates-testing that fixed a lot of r300/r500 bugs back at the start of F11 and it went into testing a few weeks later and broke Intel, I got 0 reports during that u-t phase about breakage. So now I have a package in stable that lets 3D works for x num of people and breaks compiz for y number. The problem is that PPAs/KoPeRs are going to get much less testing than stuff in updates-testing, so if you don't think you are getting enough testing in updates-testing I really don't see how KoPeRs will solve that problem. The problem for X is we have multiple interdependent parts, so if we actually want to pull in an update we need to get X + kernel + driver + mesa + libdrm all tagged into a buildroot override. This is... slightly risky. Kernel is a particularly fun bit, since there are other reasons why a kernel update would want to go out; you don't want to break drm for Peter to fix Paul's wireless. If we were more aggressive about backporting the kernel drm bits, and there was some slightly easier (preferably Makefile.common-driven) way of getting a package into the buildroot before being in -updates proper, we could probably do without lookaside repos. - ajax 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: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26, 1.27 sources, 1.10, 1.11
On Tue, 2009-10-13 at 22:04 +0530, Parag N(पराग़) wrote:
-BuildRequires: pkgconfig
-BuildRequires: libX11-devel
-BuildRequires: libXext-devel
+BuildRequires: pkgconfig(xext)
%description
X-Resource is an extension that allows a client to query
@@ -21,7 +19,6 @@ the X server about its usage of various
Summary: Development files for %{name}
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
-Requires: pkgconfig
According to Review Guidelines MUST: Packages containing
pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory
ownership and usability), this should not be removed.
atropine:~% repoquery --whatprovides 'pkgconfig(xext)'
libXext-devel-0:1.0.99.4-3.fc12.i686
atropine:~% repoquery --requires libXext-devel | grep pkg
pkgconfig
pkgconfig(x11)
pkgconfig(xextproto)
So, whatever. Clearly the pkgconfig autorequires are doing the right
thing: -devel packages that provide a .pc file pick up a Requires:
pkgconfig. The guidelines should be fixed.
- ajax
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: rpms/libXt/devel .cvsignore, 1.11, 1.12 libXt.spec, 1.33, 1.34 sources, 1.12, 1.13
On Tue, 2009-10-13 at 22:18 +0530, Parag N(पराग़) wrote: -# needed by xt.pc -Requires: xorg-x11-proto-devel -Requires: libX11-devel -Requires: libSM-devel - I am confused here. Why this is removed? I still see xt.pc needs those Requires. Because rpm is smart enough to figure that out for itself now. - ajax 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: rpms/libXres/devel .cvsignore, 1.9, 1.10 libXres.spec, 1.26, 1.27 sources, 1.10, 1.11
On Tue, 2009-10-13 at 10:32 -0700, Toshio Kuratomi wrote: If all Fedora releases have the autoprovides but EL-5 is still affected, the draft can be as simple as: rpm detects pkgconfig dependencies in all Fedora releases, please move the pkgconfig requires from [LINK] to the EPEL specific guidelines. Done: https://fedoraproject.org/wiki/PackagingDrafts/PkgconfigAutoRequires AFAICT this became automagic in F-10, but I can't find any overt history of that in redhat-rpm-macros. - ajax 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
rpms/libXfont/devel .cvsignore, 1.17, 1.18 libXfont.spec, 1.47, 1.48 sources, 1.18, 1.19
Author: ajax
Update of /cvs/pkgs/rpms/libXfont/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12515
Modified Files:
.cvsignore libXfont.spec sources
Log Message:
* Tue Oct 13 2009 Adam Jackson a...@redhat.com 1.4.1-1
- libXfont 1.4.1
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/.cvsignore,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -p -r1.17 -r1.18
--- .cvsignore 18 Feb 2009 19:10:56 - 1.17
+++ .cvsignore 13 Oct 2009 17:37:25 - 1.18
@@ -1 +1 @@
-libXfont-1.4.0.tar.bz2
+libXfont-1.4.1.tar.bz2
Index: libXfont.spec
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/libXfont.spec,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -p -r1.47 -r1.48
--- libXfont.spec 25 Jul 2009 05:12:25 - 1.47
+++ libXfont.spec 13 Oct 2009 17:37:25 - 1.48
@@ -1,7 +1,7 @@
Summary: X.Org X11 libXfont runtime library
Name: libXfont
-Version: 1.4.0
-Release: 5%{?dist}
+Version: 1.4.1
+Release: 1%{?dist}
License: MIT
Group: System Environment/Libraries
URL: http://www.x.org
@@ -9,12 +9,11 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Source0: http://www.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
+BuildRequires: pkgconfig(fontsproto)
BuildRequires: xorg-x11-util-macros
-BuildRequires: xorg-x11-proto-devel
BuildRequires: xorg-x11-xtrans-devel = 1.0.3-3
BuildRequires: libfontenc-devel
BuildRequires: freetype-devel
-BuildRequires: autoconf automake libtool
%description
X.Org X11 libXfont runtime library
@@ -23,7 +22,7 @@ X.Org X11 libXfont runtime library
Summary: X.Org X11 libXfont development package
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
-Requires: libfontenc-devel pkgconfig
+Requires: libfontenc-devel
%description devel
X.Org X11 libXfont development package
@@ -79,6 +78,9 @@ rm -rf $RPM_BUILD_ROOT
%{_libdir}/pkgconfig/xfont.pc
%changelog
+* Tue Oct 13 2009 Adam Jackson a...@redhat.com 1.4.1-1
+- libXfont 1.4.1
+
* Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/sources,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- sources 18 Feb 2009 19:10:56 - 1.18
+++ sources 13 Oct 2009 17:37:25 - 1.19
@@ -1 +1 @@
-3a8e06b25912ef339d70a8ba003da9b5 libXfont-1.4.0.tar.bz2
+4f2bed2a2be82e90a51a24bb3a22cdf0 libXfont-1.4.1.tar.bz2
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/libXfont/F-12 libXfont.spec,1.47,1.48 sources,1.18,1.19
Author: ajax
Update of /cvs/pkgs/rpms/libXfont/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12788
Modified Files:
libXfont.spec sources
Log Message:
* Tue Oct 13 2009 Adam Jackson a...@redhat.com 1.4.1-1
- libXfont 1.4.1
Index: libXfont.spec
===
RCS file: /cvs/pkgs/rpms/libXfont/F-12/libXfont.spec,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -p -r1.47 -r1.48
--- libXfont.spec 25 Jul 2009 05:12:25 - 1.47
+++ libXfont.spec 13 Oct 2009 17:38:41 - 1.48
@@ -1,7 +1,7 @@
Summary: X.Org X11 libXfont runtime library
Name: libXfont
-Version: 1.4.0
-Release: 5%{?dist}
+Version: 1.4.1
+Release: 1%{?dist}
License: MIT
Group: System Environment/Libraries
URL: http://www.x.org
@@ -9,12 +9,11 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Source0: http://www.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
+BuildRequires: pkgconfig(fontsproto)
BuildRequires: xorg-x11-util-macros
-BuildRequires: xorg-x11-proto-devel
BuildRequires: xorg-x11-xtrans-devel = 1.0.3-3
BuildRequires: libfontenc-devel
BuildRequires: freetype-devel
-BuildRequires: autoconf automake libtool
%description
X.Org X11 libXfont runtime library
@@ -23,7 +22,7 @@ X.Org X11 libXfont runtime library
Summary: X.Org X11 libXfont development package
Group: Development/Libraries
Requires: %{name} = %{version}-%{release}
-Requires: libfontenc-devel pkgconfig
+Requires: libfontenc-devel
%description devel
X.Org X11 libXfont development package
@@ -79,6 +78,9 @@ rm -rf $RPM_BUILD_ROOT
%{_libdir}/pkgconfig/xfont.pc
%changelog
+* Tue Oct 13 2009 Adam Jackson a...@redhat.com 1.4.1-1
+- libXfont 1.4.1
+
* Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/libXfont/F-12/sources,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- sources 18 Feb 2009 19:10:56 - 1.18
+++ sources 13 Oct 2009 17:38:41 - 1.19
@@ -1 +1 @@
-3a8e06b25912ef339d70a8ba003da9b5 libXfont-1.4.0.tar.bz2
+4f2bed2a2be82e90a51a24bb3a22cdf0 libXfont-1.4.1.tar.bz2
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/xorg-x11-font-utils/devel .cvsignore, 1.13, 1.14 sources, 1.13, 1.14 xorg-x11-font-utils.spec, 1.33, 1.34
Author: ajax
Update of /cvs/pkgs/rpms/xorg-x11-font-utils/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23781
Modified Files:
.cvsignore sources xorg-x11-font-utils.spec
Log Message:
* Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.2-10
- mkfontscale 1.0.7
- mkfontdir 1.0.5
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/.cvsignore,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- .cvsignore 26 Apr 2007 14:44:44 - 1.13
+++ .cvsignore 13 Oct 2009 19:59:49 - 1.14
@@ -3,3 +3,5 @@ fonttosfnt-1.0.3.tar.bz2
mkfontdir-1.0.3.tar.bz2
mkfontscale-1.0.1.tar.bz2
bdftopcf-1.0.1.tar.bz2
+mkfontscale-1.0.7.tar.bz2
+mkfontdir-1.0.5.tar.bz2
Index: sources
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/sources,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- sources 26 Apr 2007 14:44:44 - 1.13
+++ sources 13 Oct 2009 19:59:49 - 1.14
@@ -1,5 +1,5 @@
b81535f78fe05732931f02841e5ca37b font-util-1.0.1.tar.bz2
b0ebd86029571239b9d7b0c61191b591 fonttosfnt-1.0.3.tar.bz2
-4d0f89a23f77e22f1671a77bf0898955 mkfontdir-1.0.3.tar.bz2
-1e74e68eb9e8e91c6b7b615d80dc5ee1 mkfontscale-1.0.1.tar.bz2
9685fab33d39954ab8a0d22e0969d5a4 bdftopcf-1.0.1.tar.bz2
+96ca346f185c0ab48e42bf5bb0375da5 mkfontscale-1.0.7.tar.bz2
+9365ac66d19186eaf030482d312fca06 mkfontdir-1.0.5.tar.bz2
Index: xorg-x11-font-utils.spec
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/devel/xorg-x11-font-utils.spec,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -p -r1.33 -r1.34
--- xorg-x11-font-utils.spec27 Jul 2009 08:36:22 - 1.33
+++ xorg-x11-font-utils.spec13 Oct 2009 19:59:49 - 1.34
@@ -5,7 +5,7 @@ Name: xorg-x11-%{pkgname}
# IMPORTANT: If package ever gets renamed to something else, remove the Epoch
line!
Epoch: 1
Version: 7.2
-Release: 9%{?dist}
+Release: 10%{?dist}
License: MIT
Group: User Interface/X
URL: http://www.x.org
@@ -13,20 +13,17 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Source0: ftp://ftp.x.org/pub/individual/app/bdftopcf-1.0.1.tar.bz2
Source1: ftp://ftp.x.org/pub/individual/app/fonttosfnt-1.0.3.tar.bz2
-Source2: ftp://ftp.x.org/pub/individual/app/mkfontdir-1.0.3.tar.bz2
-Source3: ftp://ftp.x.org/pub/individual/app/mkfontscale-1.0.1.tar.bz2
+Source2: ftp://ftp.x.org/pub/individual/app/mkfontdir-1.0.5.tar.bz2
+Source3: ftp://ftp.x.org/pub/individual/app/mkfontscale-1.0.7.tar.bz2
Source4: ftp://ftp.x.org/pub/individual/font/font-util-1.0.1.tar.bz2
Patch0: font-util-1.0.1-mapdir-use-datadir-fix.patch
Patch1: font-util-1.0.1-autoconf-add-with-fontdir-option.patch
-BuildRequires: pkgconfig
-BuildRequires: libXfont-devel
-BuildRequires: libX11-devel
+BuildRequires: pkgconfig(xfont) pkgconfig(x11)
BuildRequires: libfontenc-devel = 0.99.2-2
BuildRequires: freetype-devel
BuildRequires: zlib-devel
-
BuildRequires: autoconf
Provides: %{pkgname}
@@ -116,6 +113,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.2-10
+- mkfontscale 1.0.7
+- mkfontdir 1.0.5
+
* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:7.2-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/xorg-x11-font-utils/F-12 sources, 1.13, 1.14 xorg-x11-font-utils.spec, 1.33, 1.34
Author: ajax
Update of /cvs/pkgs/rpms/xorg-x11-font-utils/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv24541
Modified Files:
sources xorg-x11-font-utils.spec
Log Message:
* Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.2-10
- mkfontscale 1.0.7
- mkfontdir 1.0.5
Index: sources
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/F-12/sources,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- sources 26 Apr 2007 14:44:44 - 1.13
+++ sources 13 Oct 2009 20:02:37 - 1.14
@@ -1,5 +1,5 @@
b81535f78fe05732931f02841e5ca37b font-util-1.0.1.tar.bz2
b0ebd86029571239b9d7b0c61191b591 fonttosfnt-1.0.3.tar.bz2
-4d0f89a23f77e22f1671a77bf0898955 mkfontdir-1.0.3.tar.bz2
-1e74e68eb9e8e91c6b7b615d80dc5ee1 mkfontscale-1.0.1.tar.bz2
9685fab33d39954ab8a0d22e0969d5a4 bdftopcf-1.0.1.tar.bz2
+96ca346f185c0ab48e42bf5bb0375da5 mkfontscale-1.0.7.tar.bz2
+9365ac66d19186eaf030482d312fca06 mkfontdir-1.0.5.tar.bz2
Index: xorg-x11-font-utils.spec
===
RCS file: /cvs/pkgs/rpms/xorg-x11-font-utils/F-12/xorg-x11-font-utils.spec,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -p -r1.33 -r1.34
--- xorg-x11-font-utils.spec27 Jul 2009 08:36:22 - 1.33
+++ xorg-x11-font-utils.spec13 Oct 2009 20:02:37 - 1.34
@@ -5,7 +5,7 @@ Name: xorg-x11-%{pkgname}
# IMPORTANT: If package ever gets renamed to something else, remove the Epoch
line!
Epoch: 1
Version: 7.2
-Release: 9%{?dist}
+Release: 10%{?dist}
License: MIT
Group: User Interface/X
URL: http://www.x.org
@@ -13,20 +13,17 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Source0: ftp://ftp.x.org/pub/individual/app/bdftopcf-1.0.1.tar.bz2
Source1: ftp://ftp.x.org/pub/individual/app/fonttosfnt-1.0.3.tar.bz2
-Source2: ftp://ftp.x.org/pub/individual/app/mkfontdir-1.0.3.tar.bz2
-Source3: ftp://ftp.x.org/pub/individual/app/mkfontscale-1.0.1.tar.bz2
+Source2: ftp://ftp.x.org/pub/individual/app/mkfontdir-1.0.5.tar.bz2
+Source3: ftp://ftp.x.org/pub/individual/app/mkfontscale-1.0.7.tar.bz2
Source4: ftp://ftp.x.org/pub/individual/font/font-util-1.0.1.tar.bz2
Patch0: font-util-1.0.1-mapdir-use-datadir-fix.patch
Patch1: font-util-1.0.1-autoconf-add-with-fontdir-option.patch
-BuildRequires: pkgconfig
-BuildRequires: libXfont-devel
-BuildRequires: libX11-devel
+BuildRequires: pkgconfig(xfont) pkgconfig(x11)
BuildRequires: libfontenc-devel = 0.99.2-2
BuildRequires: freetype-devel
BuildRequires: zlib-devel
-
BuildRequires: autoconf
Provides: %{pkgname}
@@ -116,6 +113,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Oct 13 2009 Adam Jackson a...@redhat.com 7.2-10
+- mkfontscale 1.0.7
+- mkfontdir 1.0.5
+
* Mon Jul 27 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:7.2-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, 2009-10-07 at 10:44 -0400, Josh Boyer wrote: On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote: A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the new 1.7 XServer and 7.6 mesa would be very useful. No, not really. I understand that changing the Graphics system could break many users systems, so maybe a build of all the necessary packages could be put into the testing repository or perhaps a special graphics-testing repository could be added. This would help get the graphics issues fixed prior to F12's release ... Actually, installing rawhide or the F-12 Beta (or using a livecd) would help get the graphics issues fixed prior to F-12 release. That is going to help much more than wasting the developer's time trying to backport everything to F-11, pushing it to updates-testing, and dealing with all the fallout. In fact, the major reason for not backporting the intel driver to F11 is that it requires a bunch of kernel changes that no one really has time for. Among other things, 830 through 865 require GEM in the intel 2.9, which we have disabled for the F11 kernel for those chips because (as shipped) it's utterly broken. - ajax 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: Help with debuging Xserver / Goes in an infinite loop
On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote: I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I read the instructions here http://www.x.org/wiki/Development/Documentation/ServerDebugging but this didin't help. My Xserver goes in an infinite loop and starts consuming 100% my cpu. Therefore the whole system freezes and I have to manually reboot it. This happens all the time when I use firefox on random sites. After restart there is nothing in the xorg.0.log and everything repeats itself when I start firefox again. Therefore I need to remove the savesession.js from the firefox home directory. On the second mashine I also turned this on: handle SIGUSR1 nostop, handle SIGUSR2 nostop, handle SIGPIPE nostop. The Xserver just keeps running and I get no messages on the second mashine. How to debug it? I wouldn't expect you to get messages on the second machine. If you're using 100% of the CPU it's because you're busy doing something _other_ than printing to the log. What does 'bt' in gdb show? - ajax 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: Help with debuging Xserver / Goes in an infinite loop
On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote: (gdb) bt #0 0x003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6 #1 0x004e615a in WaitForSomething ( pClientsReady=value optimized out) at WaitFor.c:228 #2 0x00446ef2 in Dispatch () at dispatch.c:386 #3 0x0042d205 in main (argc=value optimized out, argv=0x7fffa2ac9218, envp=value optimized out) at main.c:397 Okay, this isn't the server actually taking 100% of the CPU (almost certainly), it's before that. If you type 'cont' to resume, and then ^C the gdb process once the CPU goes wild, you should break back to the gdb prompt; _that_'s the backtrace I need. Of course, you might not, in which case debugging this gets a bit harder. - ajax 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: Anaconda/install question: Core packages but only for virtual machines
On Thu, 2009-09-24 at 09:46 +0100, Richard W.M. Jones wrote: In comps.xml there's a Core group which I think is a minimal set of packages that always get installed by Anaconda (maybe I'm wrong about that). Is there a group for packages that always get installed, but only inside virtual machines? [*] There is not. If you were to create one, you'd almost certainly need to add some more magic to platform.py in anaconda to make it do anything. - ajax 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: Intel graphics users: send me your VBIOS
On Fri, 2009-09-18 at 14:45 -0400, Adam Jackson wrote: If you have a machine with an Intel graphics chip, I need your help. I'm trying to make LVDS connection detection actually reliable, and I think I have a solution that involves parsing BIOS data tables. But I need more testcases to raise my confidence that it's actually a reliable method. So, do this: % sudo dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1 and email me that rom file, along with a brief description of the machine, and in particular what graphics outputs (DVI, VGA, LVDS...) are _actually_ present on the machine. Just as a clarification: the problem I'm trying to solve here is the appearance of an LVDS output (from X's perspective) when there is not one actually present. So, ROMs from machines that have had a phantom LVDS connector at some point in the past are especially valuable. IIRC the Mac Mini and Dell Studio compact machines have had this problem before. There's one particular field in the connector table for LVDS that seems to be indicative of LVDS presence. So far, for machines where LVDS really is present, it's consistently non-zero (and these are very common, since everybody buys laptops these days). I'd like to find more machines where LVDS is _not_ present to see if it's consistently zero there; so far that seems to be the case, but I've only got two samples... - ajax 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: Mouse pointer freezing in f12 and f11
On Thu, 2009-09-10 at 19:29 +1000, Rodd Clarkson wrote: I've had a problem with X in f12 or some time that sees the mouse pointer freezing. I'm now having the same issue in f11. I'm happy to file a bug in bugzilla, but I'm hoping someone mught be able to point me in the right direction. After some time after running X the mouse pointer will freeze. Switching to a VT doesn't help, but I can use the keyboard to close apps and do a little navigation. Also pushing the power button will see a dialog to allow me to shutdown, suspend, etc. I can suspend and resume and this fixes the problem. I'm not however convinced that it's an X bug. I think it might be related to bluetooth (I believe that my mouse and keyboard have something to do with bluetooth on this laptop) and that the suspend resume cycle restarts bluetooth and fixes the problem. You could verify this with DISPLAY=:0 xinput list when the mouse pointer stops. If you don't see the bluetooth mouse in the list, then the kernel is refusing to re-plug it right. If you _do_ see the mouse in the list, then X is confused somewhere. Does keyboard navigation still work when this happens? Does alt-tab switch windows, etc. - ajax 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 forked zlibs in rsync and zsync
On Tue, 2009-09-15 at 13:44 +0200, Josephine Tannhäuser wrote: Hey, I googled for it and found Karims blogpost and Simon aka kassamedias answer (comment 3) http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ If we _really_ cared about doing this OAOO, we could probably get the rsync package to drop out its own zlib copy as a shared lib, make that a subpackage, and link zsync against that. But, for 74k of shared library, I just don't care that much. This shouldn't block packaging zsync. - ajax 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
Default heuristics for variable-format displays
In attempting to document how displays are expected to work in F12 [1], I realized we still don't have a decent heuristic for some cases. Broadly, displays are either fixed-format or variable-format. FF means you have some set number of pixels, like an LCD. VF means you don't, like a CRT. (Projectors are often somewhere in between, we'll pretend they don't exist for a moment.) We get FF displays pretty much right, since they tend to describe themselves well enough in EDID to figure out what their native size is. Some VF displays are polite enough to define a preferred mode, and for that case we'll default to that. But, many VF displays don't define a preferred mode. How are we to choose? What's currently implemented will pick something along the lines of the largest available mode that matches our guess at the physical aspect ratio and that fits in the card's DAC and memory bandwidth limits. Which is awful. So I'm thinking something like (in wretched pseudopython): def mode_dpi_cmp(x, y): return cmp(abs(x.dpi - 96), abs(y.dpi - 96)) def mode_size_cmp(x, y): return cmp(x.width * x.height, y.width * y.height) def best_mode(modes, dpi_known = True): l = filter(lambda x: x.refresh = 72, modes) if l == []: l = modes if dpi_known: l.sort(cmp=mode_dpi_cmp) else: l.sort(cmp=mode_size_cmp) return l[0] Which is _pretty_ good, except you'd kinda like to match aspect ratio if you happen to know AR but not DPI. Which is trivial to add, but starts to be hard to read. If anyone has ideas I'm all ears, but I'd like to get this implemented sometime this week, so speak up. [1] https://fedoraproject.org/wiki/Desktop/Whiteboards/HardwareHandling - ajax 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: Default heuristics for variable-format displays
On Tue, 2009-09-15 at 10:48 -0700, Adam Williamson wrote: I know that, in the dinosaur days of CRT, I could 'see' flicker (and get flicker-generated headaches) at anything under 80Hz, and I know there are even more sensitive people than that. So 72Hz may be a bit of a low 'safe refresh rate' cutoff. I'd like it to be 80 at least. 72/75 were better than 65 for me, but definitely not acceptable for long-term work. The struggle here is that you may not actually have any modes in the pool with refresh rates that high. I'm remembering 72Hz as some OSHA recommendation but I'm not able to find a reference to it quickly. Both the EU and EnergyStar seem to indicate that CRTs should be measured for power at the largest resolution supported at 75Hz, but that's a power recommendation, not an ergonomic one. There's also a (rather small) power usage argument here. Higher refresh rates require more memory bandwidth, which means more memory cycles, which means more power draw. It's linear on number of pixels, but the coefficient is pretty low, so maybe it's not worth worrying about. I suppose you could successively run the filter() step in the given algorithm until you get a non-empty list. Nggh though. - ajax 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: Triggers just to avoid unowned directories?
On Tue, 2009-09-01 at 07:35 +0200, Michael Schwendt wrote: The packaging style in the nss-softokn package continues to bug me. There are RPM triggers being used to install/remove a prelink config file whenever the prelink package gets installed/removed. According to a comment in the spec file, it is only done like that because the package doesn't want to own the /etc/prelink.conf.d directory. Nothing else is run in the scriptlets, just a file is moved or deleted. Previously, albeit in the different nss package, it used to be duplicate directory ownership: $ repoquery --whatprovides /etc/prelink.conf.d prelink-0:0.4.0-7.fc11.i586 nss-0:3.12.3.99.3-2.11.4.fc11.i586 nss-0:3.12.3-4.fc11.i586 Is this a result of the recent move to avoid duplicate directory ownership? rpm could start refcounting directories any day now and that'd be just fine. Some people like multiple ownership, some don't. The package guidelines recommend against it, but don't forbid it. It's a judgement call. In this particular case I think multiple ownership of the directory is better than triggers, but that moving /etc/prelink.conf.d to filesystem would be even better. - ajax 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: 20090901 changes
On Tue, 2009-09-01 at 11:02 +, Rawhide Report wrote: redhat-lsb-3.2-5.fc12.i686 requires /usr/bin/[ This appears to be a bug in the report script? [ definitely exists in coreutils-7.5-3.fc12. - ajax 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: Triggers just to avoid unowned directories?
On Tue, 2009-09-01 at 11:10 -0400, Tom spot Callaway wrote:
On 09/01/2009 09:34 AM, Adam Jackson wrote:
rpm could start refcounting directories any day now and that'd be just
fine.
Is there an open trac ticket on this issue with the RPM upstream?
Not that I can see. I had assumed their trac was more or less moribund,
since things like %{patches} and prov/req filtering have been
implemented but are still open tickets, but I guess we have those
implemented in redhat-rpm-macros and not rpm proper.
I'd kind of like to have a complete idea of how automatic-dirs would
behave though. What happens when an autodir is on the filesystem and a
new package comes along to explicitly own it, possibly with different
permissions? Does it revert when that package is uninstalled? Do
autodirs containing only .rpm{new,save} after package removal get
garbage collected? etc.
- ajax
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: Need help with stack smash
On Thu, 2009-08-27 at 12:36 -0600, Orion Poplawski wrote: I'm trying to debug a stack smash in of the hdf test programs but am having a hard time tracking down exactly where the smash happens. Is there any way to watch the guard variable with gdb to find exactly when it happens? Something similar? (gdb) help watch Set a watchpoint for an expression. A watchpoint stops execution of your program whenever the value of an expression changes. Note that this means what it says: if your expression contains a symbol that goes out of scope before the change happens, then the watchpoint will be forgotten, because the value of the expression will change from being a value to being not-a-thing. So you would need to set the watch on the address in memory of what you're trying to watch, and not necessarily on its symbolic name. - ajax 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: Policy on removing %changelog entries?
On Thu, 2009-08-27 at 13:36 -0400, Tom spot Callaway wrote: On 08/27/2009 01:21 PM, Jeff Garzik wrote: What is the policy regarding deletion of individual entries in the middle of %changelog? A developer added a %changelog entry to each of my cloud daemons' packages, on the main fedora-cvs devel branch of each. Then, a day or so later, after other %changelog entries had been added by me... the same developer removed one %changelog entry from the middle of %changelog, and added another entry at the top. I thought the policy was to never delete %changelog entries, ever? Yeah, you really shouldn't delete %changelog entries. The only reasonable exception is that if you wanted to archive really old entries to keep the spec file small, I think that has been done in the past. I do occasionally clobber the changelog entry for a given EVR if it fails to build, since from the koji-output perspective, you can't tell the difference. Changing other things is impolite though. - ajax 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: Plan for tomorrow's (20090821) FESCo meeting
On Fri, 2009-08-21 at 15:39 +0200, Jochen Schmitt wrote: On Thu, 20 Aug 2009 22:10:59 -0400, you wrote: 238 Can libvdpau go in Fedora? As far I understand this package itself is open source but has a dependency to the properitary nVidia video driver which is provides by rpmfusion.org. For this reason I vote agains the inclusion of this package into Fedora because I introduce a requirement reference to a third-party repository. I think there's precedents for accepting it for Fedora: - libXNVCtrl, another X extension library that happens to only do anything when the user is running the nvidia binary driver, but which is itself MIT-licensed. - gstreamer-plugins-flumpegdemux, which allows you to separate the audio and video streams from MPEG files, even though the decoding itself is off-limits for Fedora It happens that only nvidia implements VDPAU at the moment, but so what? Any other vendor could too. - ajax 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: Plan for tomorrow's (20090821) FESCo meeting
On Fri, 2009-08-21 at 16:26 +0200, Jochen Schmitt wrote: - From my point of view. This cases demostrate, that we need a clarification about the requirements which a package has to fullfill for inclusssion into Fedora. I don't disagree, but... Package which are only useable if you have installed a package which is not part of Fedora may not allow for Fedora. This is the argument why we not contributes eumulators. In common emulators requires special ROM images which contains copyright content. I think this is a faulty generalization. X is a network protocol. vdpau and xnvctrl applications can be perfectly functional running on a Fedora machine with no nvidia driver installed, if they happen to be talking to some _other_ machine somewhere in the world that does support those extensions. One might argue that this is a trivial distinction, and that it still requires some non-free blob to be made to work, but to make that assertion you're basically saying that interoperability is only acceptable if there's some free implementation of what you're interoperating with. If you follow that idea through, you end up removing pilot-link, libgpod... The emulator rule-of-thumb makes sense to the extent that the emulator itself is the end goal. If the only reason you could want it installed is to play some arcade game ROM then there's pretty clearly no interoperability argument to be made. But libvdpau isn't the end goal; the VDPAU app is the end goal. libvdpau is just how you get there. The emulator RoT also assumes that the copyright holder of the magic bits doesn't _want_ you to use them. NVIDIA clearly wants people to use VDPAU. - ajax 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: any automatic tools for update spec files?
On Thu, 2009-08-13 at 17:53 +0800, Chen Baozi wrote: hello, I'm wondering whether there is a tool for automatic updating spec files, for example auto-updating the changlog session. For things like automated rebuilds, look at rpmdev-bumpspec(1). - ajax signature.asc Description: This is a digitally signed message part -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: pygtk2 and its numpy dependency
On Tue, 2009-08-11 at 07:12 -0500, Jon Ciesla wrote:
Adam Jackson wrote:
On Mon, 2009-08-10 at 14:40 -0500, Jon Ciesla wrote:
Since pygtk2 does actually use numpy, isn't d) the best (albeit most
annoying) option?
Internally? Or just to implement that one entrypoint? I believe it to
be the latter.
Having double-checked: it's just to implement get_pixels_array().
I'm not sure, but what practical difference would that make?
Well, it's a soft dep...
If built with numpy support, get_pixels_array() starts off with:
if (!have_numpy())
return NULL;
The important bit of have_numpy() looks like:
static int import_done = 0;
if (!import_done()) {
import_done = 1;
import_array1(1);
if (PyErr_Occurred()) {
/* throw */
}
}
import_array1() is a small wrapper around _import_array(), which starts
off with:
PyObject *numpy = PyImport_ImportModule(numpy.core.multiarray);
if (numpy == NULL) return -1;
And it turns out this is all static inlines that get built straight into
pygtk2 itself. In other words, if this bit of pygtk2 were written in
python, it'd look like:
class gdk:
def get_pixels_array(self):
import numpy.core.multiarray
# do a bunch of stuff
and if that python module weren't available it'd just throw an
exception.
So: python apps that call get_pixels_array() can Requires: numpy
themselves, and then that entrypoint will work. Python apps that
_don't_, need not, and then numpy and its deps go missing, but it
doesn't matter because you never call get_pixels_array() so the
exception never happens.
So I think my b) suggestion (of replicating the ABI in pygtk2) is
actually redundant, it's what's already happening. pygtk2 already knows
the object layout of numpy arrays thanks to #includes of doom, it just
doesn't try to create them unless the rest of the numpy exists.
The question is only whether to keep the 'Requires: numpy' in pygtk2 or
to push it out to apps that use get_pixels_array(). And I think the
latter sounds just fine to me.
- ajax
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: pygtk2 and its numpy dependency
On Tue, 2009-08-11 at 10:05 -0500, Jon Ciesla wrote: Adam Jackson wrote: The question is only whether to keep the 'Requires: numpy' in pygtk2 or to push it out to apps that use get_pixels_array(). And I think the latter sounds just fine to me. That's fine with me, assuming there's a way to determine that list. To a first approximation: find . -name \*.py | xargs grep '\get_pixels_array\' It appears to be a remarkably uncommon function name. This won't catch anyone calling it from C code instead, but anyone doing that is a cretin. - ajax 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: pygtk2 and its numpy dependency
On Tue, 2009-08-11 at 12:05 -0700, Toshio Kuratomi wrote: On 08/10/2009 12:36 PM, Adam Jackson wrote: pygtk2 implements a function called gtk.gdk.get_pixels_array(), which returns the pixel contents of a GDK pixbuf as a numpy array. Fine and dandy, but this means it links against numpy (7 megs) which is itself linked against atlas (12 megs). Kind of a lot for a single function, especially on a live image. Especially for a function that's basically unused! gnome-applet-music uses it to implement a poor-man's Porter-Duff blend, and that's the only caller currently packaged in Fedora, at least according to package deps. I have a patch (attached) that fixes that [1], which means we could compile our pygtk2 without numpy support and not break anything in Fedora proper. Package deps are of minimal use in detecting this. We have to detect when this function is used by an application which isn't part of package deps. gnome-games and specto are two packages that make use of this function. I did check this by installing all the packages in the distro with a pygtk2 dep and then grepping their installed .py files. Not sure how gnome-games escaped... - ajax 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
pygtk2 and its numpy dependency
pygtk2 implements a function called gtk.gdk.get_pixels_array(), which returns the pixel contents of a GDK pixbuf as a numpy array. Fine and dandy, but this means it links against numpy (7 megs) which is itself linked against atlas (12 megs). Kind of a lot for a single function, especially on a live image. Especially for a function that's basically unused! gnome-applet-music uses it to implement a poor-man's Porter-Duff blend, and that's the only caller currently packaged in Fedora, at least according to package deps. I have a patch (attached) that fixes that [1], which means we could compile our pygtk2 without numpy support and not break anything in Fedora proper. However, google codesearch does turn up what look like a few other users of that function, some of which we may actually want to ship someday. So we've got options: a) remove the explicit Requires: numpy from pygtk2, require apps that actually want this function to Require it themselves b) fake the numpy data type ABI in pygtk2 itself by cult-and-pasting it from numpy c) declare that get_pixels_array() just doesn't work in Fedora (historically true, back in like FC3) d) leave things as they are I lean towards a). I think b) is icky but doable, since that ABI is effectively unbreakable anyway (inherited from the older python-numeric module). The other two are way lame. Thoughts? [1] - Readers are invited to count the wtf's in the code being replaced, as well as in its callers. Don't treat it as a drinking game though. - ajax diff -up ./music-applet-2.5.1/src/musicapplet/applet.py.jx ./music-applet-2.5.1/src/musicapplet/applet.py --- ./music-applet-2.5.1/src/musicapplet/applet.py.jx 2009-08-10 15:03:29.0 -0400 +++ ./music-applet-2.5.1/src/musicapplet/applet.py 2009-08-10 15:03:36.0 -0400 @@ -831,22 +831,11 @@ class Rating (gtk.EventBox): def create_colorized_pixbuf (self, stock_pixbuf, color): -pixbuf = stock_pixbuf.copy () -red_scale = color.red / 65535.0 -green_scale = color.green / 65535.0 -blue_scale = color.blue / 65535.0 -for row in pixbuf.get_pixels_array (): -for pixel in row: -# Yay API changes! -if str (type (pixel[0])) == type 'array': -pixel[0][0] *= red_scale -pixel[1][0] *= green_scale -pixel[2][0] *= blue_scale -else: -pixel[0] *= red_scale -pixel[1] *= green_scale -pixel[2] *= blue_scale -return pixbuf + pixbuf = stock_pixbuf.composite_color_simple(stock_pixbuf.get_width(), + stock_pixbuf.get_height(), + gtk.gdk.INTERP_NEAREST, + 255, 1, color, color) + return pixbuf 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: Fedora 12 Features Proposed for Removal
On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: https://fedoraproject.org/wiki/Features/DisplayPort I updated this a few days ago. I guess it's still not good enough to be called a feature? I really don't know how much more testing instructions I need to provide, and it seems disingenuous to call it 100% when there's almost certainly bugs remaining and hardware we don't support right. But if this is just a feature for the sake of release notes, then sure, drop it from the list. - ajax 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: non root X
On Fri, 2009-08-07 at 05:04 +1000, Dave Airlie wrote: On Thu, 2009-08-06 at 01:36 -0400, Ben Boeckel wrote: Could permissions be raised temporarily? PolicyKit with (defaulted) auto-approve to load an appropriate driver? Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. SELinux, as a rule, does not grant rights, only removes them. - ajax 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: non root X
On Thu, 2009-08-06 at 14:50 -0500, Serge E. Hallyn wrote: Quoting Dave Airlie (airl...@redhat.com): Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO at login through pam_cap.so. If you also make the x driver setuid-root, then on filesystems (like NFS) or kernels which don't support file capabilities, it'll run setuid root as it does now, while if file caps are supported then it should run as the calling user with just the granted capabilities. It doesn't work like that. Drivers are DSOs, not executables. You don't get capabilities magically blessed into your executable just because you dlopen()d a DSO that has them set. Also, having actually done the audit for this, the set of capabilities the X server would need to run with restricted-caps is essentially equivalent to root in the first place. SYS_RAWIO + SYS_ADMIN + DAC_OVERRIDE plus some others I'm forgetting. Really not a solution. - ajax 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: F12 Alpha Test install
On Tue, 2009-08-04 at 21:51 -0500, Mike Chambers wrote: 2 - My mouse was not detected at all during install. Or at least, I never saw the mouse arrow during it. Had to use keyboard the whole time. Pretty sure this is an anaconda glitch. X doesn't show a cursor until you define one. I'll look into it. - ajax 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: X defaulting to side-by-side output on multiple displays: Anaconda implications?
On Thu, 2009-07-30 at 16:03 -0700, Adam Williamson wrote: I remember seeing a recent announcement from the X guys that henceforth, X will be defaulting to side-by-side mode on systems with multiple displays, rather than clone mode. I just realized this may have implications for anaconda. Is whatever WM we load anaconda in capable of handling this, or are we going to wind up with anaconda centred across the middle of both displays on systems with two monitors? mini-wm is a focus-only window manager. It doesn't modify requested window positions; wherever you ask to be placed, there you are. anaconda itself doesn't ask for anything special in terms of main UI placement, that I can see. I believe gtk's placement algorithm will try to avoid placing us across screen boundaries though. - ajax 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: 20090729 changes
On Tue, 2009-08-04 at 14:19 -0400, Casey Dahlin wrote: Possibly off topic, I've had issues with certain apps (totem comes to mind) not going full-screen on the screen I want them to. Is this another outstanding issue? It's an app issue, but sure. - ajax 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: kde-4.3.0 coming to F-10, F-11
On Tue, 2009-08-04 at 13:55 -0500, Rex Dieter wrote: The KDE SIG is now working on KDE-4.3.0-related builds for Fedora 10 and 11 candidate updates. As this requires some buildroot overrides, if your package uses KDE libraries, it may inadvertently build against KDE 4.3.0 libraries and may, at least in some cases, NOT work with 4.2.4. So please either hold off on update builds for packages using KDE libraries or contact us (on the #fedora-kde IRC chan or the fedora-kde mailing list). Not that I'm an F-10 user, or a KDE user, but: F-10? Seriously? - ajax 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: 20090729 changes
On Wed, 2009-07-29 at 11:13 +, Rawhide Report wrote: xorg-x11-server-1.6.99-21.20090724.fc12 --- * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-19.20090724 - xserver-1.6.99-randr-error-debugging.patch: Dump RANDR protocol errors to the log. - Un-package xf8_16bpp, no one cares. * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-20.20090724 - xserver-1.6.99-use-pci-access-boot.patch: Some chips (thanks Intel) will change their PCI class at runtime if you disable their VGA decode, so consider both 0x0300 and 0x0380 classes when looking for the boot VGA. * Tue Jul 28 2009 Adam Jackson a...@redhat.com 1.6.99-21.20090724 - xserver-1.6.99-right-of.patch: Default to right-of initial placement for RANDR 1.2 drivers with enough virtual space. I just want to highlight this, as it's a behaviour change that might surprise people. With this change you'll get a spanning desktop by default if possible, which matches the behaviour of every other major window system and is what you usually configured in the session anyway. The cloning heuristic was pretty losing to begin with, since the available mode lists for each output don't have a lot of commonality. There are still some rough edges here. X will center the mouse over the root window, and not over a particular screen, which is usually wrong. gdm extends the error by displaying the greeter on the screen that contains the cursor; so if for example your external display is larger than your laptop display, the cursor will be centered on the external, and gdm will show up there instead of on the LVDS like you probably expected. Known bug, we're working on it. Also, Intel gen3 hardware (915 and 945 variants) hit a corner case here, where the maximum 3d pitch is 2048 but the maximum scanout pitch is 4096. So if you're using compiz or another GL compositor in your session, you'll see garbage rendering off to the right. This isn't a _new_ problem, but you might hit it now when you didn't before. However, with KMS, we'll resize the render buffers on RANDR events, so if you switch back to cloning in your session GL compositors should look right. - ajax 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: Updated Anaconda packages
On Wed, 2009-07-29 at 12:39 +0200, Ralf Corsepius wrote: On 07/29/2009 08:03 AM, Adam Williamson wrote: On Tue, 2009-07-28 at 01:51 +0200, Ralf Corsepius wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. I'm terribly sorry - what color exactly did you want us to paint your fricking pony, Ralf? Plonk. That's sorta purplish pinkish black, right? - ajax 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: Lower Process Capabilities
On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - ajax 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: http://www.fsf.org/news/dont-depend-on-mono
On Tue, 2009-07-07 at 09:56 +0100, Rui Miguel Silva Seabra wrote: On Tue, Jul 07, 2009 at 10:24:24AM +0200, drago01 wrote: http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx Oh poo, and what's the difference? None. None whatsoever but more marketing. You can't distribute GPL'ed software unless you have the right to do it. The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. I am unable to read the Community Promise in any way that implies either of the above. Please cite exactly which statement in the Community Promise you take issue with. http://www.microsoft.com/interop/cp/default.mspx - ajax 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: http://www.fsf.org/news/dont-depend-on-mono
On Tue, 2009-07-07 at 14:27 +0100, Jonathan Underwood wrote: Not answering Ajax's question specifically, but this looks a bit iffy: If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. So, say a few years have passed and C# and the CLI is now a very key component of the stack, and Red Hat (for example) filed a patent lawsuit against MS for something unrelated, MS could turn around and revoke the promise not to sue Red Hat for distributing a C#/CLI implementation, crippling the product that Red Hat now relies on. So there's two things wrong here. The first one is the turn around statement. The very first sentence starts with Microsoft irrevocably promises. Any assurance made by the Community Promise is forever. The second is the retaliation model. In the language of the Promise: If you [sue for patent] against a Microsoft implementation of any Covered Specification [...]. A Covered Specification is one that they're covering with this promise. So, if Frobnitz Inc. distributed Mono, and then filed suit against Microsoft for infringing one of Frobnitz' patents in the Microsoft C# implementation, they would lose the right to distribute Mono [1]. However, if Frobnitz distributes Mono, and then files suit against Microsoft for a rendering technique patent used in Internet Explorer, they would still be allowed to distribute Mono [2]. In other words, it's a MAD agreement. You're not even agreeing that any patents they may hold that read on the Covered Spec are _valid_. You're simply agreeing that neither of you will assert any patent claims against the other, for the scope of the Covered Specs, iff you chose to use/make/sell/distribute/etc an implementation of one of the Covered specs. Now this still might not be something you want to agree to. For example, if you hold patents that you think already read on MS's C# implementation, you might not want to lose the ability to exercise them. The question may also be made irrelevant by some third-party patent claim that you think would read on a Covered Spec. Finally, there is the detail that the Promise only extends to what they call Microsoft Necessary Claims, which are patents necessary to implement any required portion of the spec. There's some wiggle room in the word necessary; you might be able to implement a given feature some other way, in which case the patent would presumably not be covered. There's also no assurance over patents involved for optional functionality. (Not a lawyer. Not even a Microsoft fan.) [1] - Specifically, they would lose any rights given to them by the Community Promise. They might still have the right to distribute through some other legal mechanism. [2] - Again, they would only still retain the right to distribute to the extent that they are not infringing some other legal agreement between them and Microsoft. - ajax 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: http://www.fsf.org/news/dont-depend-on-mono
On Tue, 2009-07-07 at 16:06 +0200, Julian Aloofi wrote: Unfortunately the patent promise covers more things than just C# / CLI patents. And it seems like you're going to lose the whole promise when you just sue them over one specification in there, e.g. the XPS specification. Maybe that's less of a problem for Red Hat because they don't like patents anyway and are not likely holding any XPS related patents, but it could be a problem for the OIN. The relevant sentence to the above argument is: If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. This may be ambiguously worded. any Covered Implementation might mean the one(s) corresponding to the Covered Specification you're bringing suit against, or it might mean any Covered Implementation of yours at all. The FAQ on the same page seems to indicate that the corresponding interpretation is intended: As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft's implementation of the _same_ [emphasis mine] Covered Specification. This type of suspension clause is common industry practice. But I'd definitely ask a lawyer for the real answer, and probably ask Microsoft to clarify the language if I were to rely on it. - ajax 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: http://www.fsf.org/news/dont-depend-on-mono
On Tue, 2009-07-07 at 21:11 +0100, Rui Miguel Silva Seabra wrote: On Tue, Jul 07, 2009 at 04:06:02PM +0200, drago01 wrote: On Tue, Jul 7, 2009 at 12:02 PM, Rui Miguel Silva Seabra wrote: On Tue, Jul 07, 2009 at 11:07:52AM +0200, drago01 wrote: The promise makes quite sure to tell you you have no right[1], but you can infringe that they won't sue *you*[2]. [1] = means you can't do it with GPL It explicitly grant this right. What you're explicitly told s that you won't be sued if you do so without the right. And you have no right! If I told you you can do whatever you want with this and I won't sue you or you have the right to implement this Where exactly is the difference? In one you can be sued (because it's not only Microsoft who can do that in some jurisdictions) and you're doing something which is illegal. At the risk of getting bogged down in details: My understanding is that, in such countries, in order to have any standing in such a case, the third party bringing the suit against you would have to have some claim to a grievance against you as a result of your illegal action against Microsoft. I would be delighted to hear a scenario in which you think this could arise. Also, please do remember that it is _not_ in itself illegal to distribute software that embodies someone else's patent. It's only illegal to do so without the owner's consent. If this is _not_ the case in some country, then everyone in that country needs to stop using the Linux kernel right now, because - to pick a trivial example - RCU is definitely patented. I mean, basically you're asserting that - for whatever bizarro country you're talking about - not only can you not waive your own property rights, but other people can be sued for accepting your waiver at face value. Now, there do exist a handful of countries that haven't accepted the Berne Convention, but they tend to be countries with an even weaker notion of copyright... - ajax 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: an update to automake-1.11?
On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: Richard W.M. Jones writes: On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: What line number changes? You cut a patch against configure, and you're done. That's it. And you get a big patch containing line numbers. Here's a single line change to configure.ac, and the corresponding patch that generates: == Who said anything about patching configure.ac? The cited link is not a patch to the configure script, it's a result of a patch to configure.ac. I'll repeat again: patch configure, not configure.ac. I said patch configure, and you reply, well, it won't work because if you patch configure.ac, run autoconf, then generate the patch between the original configure, and the new configure, I get a big hairball. Duh. The fundamental problem with patching configure instead of configure.ac (or Makefile instead of Makefile.am) is that it's changing the wrong semantic level. As a bad example (because sed would be a better tool), imagine a patch to Makefile that does basically s/-O2/-Os/g. Now upstream makes a new release, and adds a new build target. Your patch might still apply, but it'll miss the CFLAGS emitted for the new target, and your patch will no longer _mean_ the same thing it used to. This is the same reason we patch .c files, and not the intermediate .i or .S. Don't let the fact that you never see the intermediate files in the tarball confuse you. You don't see them because they're not abstraction levels humans should have to deal with; and neither is the complete expanded configure script. - ajax 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: an update to automake-1.11?
On Mon, 2009-07-06 at 14:22 +0200, Kevin Kofler wrote: Sam Varshavchik wrote: How exactly would that violate the GPL? You aren't patching the actual source code. Assuming GPLv2, the term in the license that you're referring to is preferred form. There is clearly some difference of opinion as to what the preferred form is here. In a strict construction sense, the preferred form for modification is whatever the modifier opted to modify. More concretely, the source code on offer in section 3 is the corresponding source, meaning, the code and changes _you_ used to produce the binary. If you changed the generated source, well, that's a thing you can do, and it means you have to distribute those changes. If you change the metasource, that's also a thing you can do, and you have to distribute the recipe for creating the generated source. In other words: no. - ajax 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: an update to automake-1.11?
On Mon, 2009-07-06 at 17:53 -0400, Sam Varshavchik wrote: So, the choices are, once it's identified where configure goes wrong are: 1) Fix the configure script, with shellcode whose contents are well understood 2) Patch configure.ac, and feed it to a code generator that spits out a brand new configure script. Your turn. Of course, if you take #2, you would, of course, verify which specific version of autoconf the upstream used, and whether the differences between your's and upstream's autoconf does not have any other impacts on the configure script. I suppose it depends whether you consider the initial act of package creation, or the continued maintenance of that packaging, to be more time consuming. All I know is that rediffing patches to configure.ac takes way less time than rediffing against configure, and that as a practice that hasn't (non-trivially) bitten me once in over three years, where configure patches have. - ajax 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: Missing libxklavier.so.12 dependency
On Thu, 2009-07-02 at 15:02 -0400, Clemens Eisserer wrote: Hi, For a few days now updating rawhide doesn't work, because it misses a dependency: kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems -- Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) Error: Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) 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 Is this anything to worry about my system, or will that be fixed anyway? Known breakage, announced here: https://www.redhat.com/archives/fedora-devel-list/2009-July/msg00031.html and fixed here: * Wed Jul 01 2009 Rex Dieter rdie...@fedoraproject.org 4.2.95-4 - rebuild (libxklavier) - ajax 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: an update to automake-1.11?
On Wed, 2009-07-01 at 11:51 -0400, Seth Vidal wrote: On Wed, 1 Jul 2009, Kevin Kofler wrote: Seth Vidal wrote: yum install system-autodeath That just turns off networking (so then how do you preupgrade from there? And it lets people keep running their obsolete stuff forever in their closet) and it has to be explicitly installed. yum install sense-of-humor He can't, KDE doesn't support that yet. - ajax 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: RFC: Kernel changes that may affect desktops
On Tue, 2009-06-30 at 13:42 -0500, Jud Craft wrote: Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one use at your own risk desktop? Strictly, they're all use at your own risk. - ajax 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: Raising the bar
On Mon, 2009-06-29 at 23:48 +0400, Peter Lemenkov wrote: 2009/6/29 Matthias Clasen mcla...@redhat.com: Hey all, we'd like to announce the 'Fit and Finish' initiative for Fedora, http://fedoraproject.org/wiki/Fit_and_Finish with the goal to improve the user experience of the Fedora desktop. If you wish to improve *user* experience, then you should focus entirely on actual Fedora releases rather than on Rawhide. However I see that in testing days you still encourage only users with up-to-date Rawhide installations. That's not an option for wide audience, and, therefore this initiative will be doomed. -- With best regards! I have difficulty reconciling your last sentence, and your .sig. In addition to rawhide live media, as Matthias mentioned, we'll be happy to take bug reports against current releases. They're of slightly less value, since they are effectively a list of things to check the next rawhide against, and may never get fixed in the stream they're reported against due to all the usual technical reasons (backport difficulty, etc), but that doesn't mean they're valueless. - ajax 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: GRUB 2 in Ubuntu 9.10
On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. - ajax 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: [PATCH] spec: fix hardlink usage with RHEL
On Mon, 2009-06-08 at 14:43 -0400, Aristeu Rozanski wrote:
Currently, the spec has *fc* hardcoded to the hardlink command. Not sure if
it wouldn't be better just use /usr/src/kernels/*.
---
kernel.spec |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- spec-diffs.orig/kernel.spec 2009-06-08 12:35:34.0 -0400
+++ spec-diffs/kernel.spec2009-06-08 14:36:12.0 -0400
@@ -1630,7 +1630,12 @@ if [ $HARDLINK != no -a -x /usr/sbin
then\
(cd /usr/src/kernels/%{KVERREL}%{?1:.%{1}} \
/usr/bin/find . -type f | while read f; do\
- hardlink -c /usr/src/kernels/*.fc*.*/$f $f\
+ if [ -n %{?rhel} ]\
+ then\
+ hardlink -c /usr/src/kernels/*.el*.*/$f $f\
+ else\
+ hardlink -c /usr/src/kernels/*.fc*.*/$f $f\
+ fi\
done)\
fi\
%{nil}
Could just do %{dist} instead of .fc* and .el* I suspect.
- ajax
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Make Fedora 11 use vx800 chipset correctly
On Thu, 2009-05-28 at 11:18 +, Kristaps Viesalgs wrote: Hi! Here is my problem: I am trying to Fedora LIVE USB boot properly X on vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook reference design). Default driver \openchrome\ because of unsupported vx800 can\'t do that. Only some snv version of this driver can boot X correctly. Assuming snv means svn, I defer to the opinion of the openchrome maintainer on this point. We regularly ship svn snapshots of the openchrome driver, but we seem to be on one from March 21. Don't know why it hasn't been updated yet. But it is only one part of prolem: using boot option video=vesafb vga=791, mouse cursor goes invisible. Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? vesafb is garbage. Don't use it. If you install with 'xdriver=vesa', the installer will write out a minimal config file setting the X driver to vesa. Is Fedora planning to make for VIA graphic chipset autoconfiguration utility? It would be very very useful. Why would we do that when we could just package a version of the driver that just works? - ajax 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: Make Fedora 11 use vx800 chipset correctly
On Thu, 2009-05-28 at 10:48 -0400, Adam Jackson wrote: On Thu, 2009-05-28 at 11:18 +, Kristaps Viesalgs wrote: Hi! Here is my problem: I am trying to Fedora LIVE USB boot properly X on vx800 chipset/Chrome9 integrated GPU on VED8900 netbook (VIA OpenBook reference design). Default driver \openchrome\ because of unsupported vx800 can\'t do that. Only some snv version of this driver can boot X correctly. Assuming snv means svn, I defer to the opinion of the openchrome maintainer on this point. We regularly ship svn snapshots of the openchrome driver, but we seem to be on one from March 21. Don't know why it hasn't been updated yet. Actually, having looked closer at the package, I see: # 1106:1122 - VX800 (PCI_CHIP_VT3353) alias pcivideo:v1106d1122sv*sd*bc*sc*i* openchrome Which would seem to indicate that it _does_ support this chip. Perhaps you could explain what goes wrong when trying to run X on it? The /var/log/Xorg.0.log file from trying to run it would be informative. - ajax 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
Dead package notice: freetype1
freetype1 is gone from F12. Nobody's currently using it, and more importantly nobody ought to be, anywhere, ever. - ajax 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
rpms/freetype1/devel dead.package, NONE, 1.1 freetype-1.3.1-1.4pre.patch, 1.1, NONE freetype-1.4-disable-ft1-bci.patch, 1.1, NONE freetype-1.4pre-CVE-2008-1808.patch, 1.1, NONE freetype1.spec, 1.6, NO
Author: ajax Update of /cvs/pkgs/rpms/freetype1/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25451 Added Files: dead.package Removed Files: freetype-1.3.1-1.4pre.patch freetype-1.4-disable-ft1-bci.patch freetype-1.4pre-CVE-2008-1808.patch freetype1.spec sources Log Message: Unused in Fedora, and unmaintained upstream. --- NEW FILE dead.package --- Unused in Fedora, and unmaintained upstream. --- freetype-1.3.1-1.4pre.patch DELETED --- --- freetype-1.4-disable-ft1-bci.patch DELETED --- --- freetype-1.4pre-CVE-2008-1808.patch DELETED --- --- freetype1.spec DELETED --- --- sources DELETED --- ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/freetype1/F-11 freetype1.spec,1.6,1.7
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29325
Modified Files:
freetype1.spec
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
Index: freetype1.spec
===
RCS file: /cvs/pkgs/rpms/freetype1/F-11/freetype1.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- freetype1.spec 24 Feb 2009 18:30:12 - 1.6
+++ freetype1.spec 26 May 2009 20:28:24 - 1.7
@@ -4,7 +4,7 @@
Name: freetype1
Version:1.4
-Release:0.7.pre%{?dist}
+Release:0.8.pre%{?dist}
Summary:Free TrueType font rendering engine, compatibility version
Group: System Environment/Libraries
License:FTL
@@ -15,6 +15,9 @@ Source: http://downloads.sourcef
Patch0: freetype-1.3.1-1.4pre.patch
Patch1: freetype-1.4-disable-ft1-bci.patch
Patch2: freetype-1.4pre-CVE-2008-1808.patch
+Patch3:cve-2006-1861.patch
+Patch4:cve-2007-2754.patch
+
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: zlib-devel libXt-devel gettext
@@ -61,6 +64,8 @@ developing applications that use %{name}
%endif
%patch2 -p1
+%patch3 -p1
+%patch4 -p1
iconv -f ISO-8859-1 -t UTF-8 docs/i18n.txt docs/i18n.txt.tmp
touch -r docs/i18n.txt docs/i18n.txt.tmp
@@ -125,6 +130,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
+- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
+
* Tue Feb 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-0.7.pre
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/freetype1/F-11 cve-2006-1861.patch, NONE, 1.1 cve-2007-2754.patch, NONE, 1.1
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29730
Added Files:
cve-2006-1861.patch cve-2007-2754.patch
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
cve-2006-1861.patch:
--- NEW FILE cve-2006-1861.patch ---
diff -up
freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
2009-05-12 19:40:52.0 -0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:41:03.0 -0400
@@ -270,6 +270,10 @@
j= 0;
flag = exec-pts.touch;
+/* CVE-2006-1861 */
+if ( flag == NULL )
+ return TT_Err_Invalid_Composite; /* for lack of a better err code */
+
while ( j n_points )
{
Byte c, cnt;
cve-2007-2754.patch:
--- NEW FILE cve-2007-2754.patch ---
diff -up freetype-pre1.4/lib/ttgload.c.ttf-overflow
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.ttf-overflow 2009-05-12 19:25:25.0
-0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:28:15.0 -0400
@@ -236,7 +236,7 @@
FORGET_Frame();
-if ( n_points left_points )
+if ( n_points 0 || n_points left_points )
{
PTRACE0(( ERROR: Too many points in glyph %ld\n, subg-index ));
return TT_Err_Too_Many_Points;
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/freetype1/F-10 cve-2006-1861.patch, NONE, 1.1 cve-2007-2754.patch, NONE, 1.1 freetype1.spec, 1.5, 1.6
Author: ajax
Update of /cvs/pkgs/rpms/freetype1/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30111
Modified Files:
freetype1.spec
Added Files:
cve-2006-1861.patch cve-2007-2754.patch
Log Message:
* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
cve-2006-1861.patch:
--- NEW FILE cve-2006-1861.patch ---
diff -up
freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.freetype-pre1.4-CVE-2006-1861-null-pointer
2009-05-12 19:40:52.0 -0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:41:03.0 -0400
@@ -270,6 +270,10 @@
j= 0;
flag = exec-pts.touch;
+/* CVE-2006-1861 */
+if ( flag == NULL )
+ return TT_Err_Invalid_Composite; /* for lack of a better err code */
+
while ( j n_points )
{
Byte c, cnt;
cve-2007-2754.patch:
--- NEW FILE cve-2007-2754.patch ---
diff -up freetype-pre1.4/lib/ttgload.c.ttf-overflow
freetype-pre1.4/lib/ttgload.c
--- freetype-pre1.4/lib/ttgload.c.ttf-overflow 2009-05-12 19:25:25.0
-0400
+++ freetype-pre1.4/lib/ttgload.c 2009-05-12 19:28:15.0 -0400
@@ -236,7 +236,7 @@
FORGET_Frame();
-if ( n_points left_points )
+if ( n_points 0 || n_points left_points )
{
PTRACE0(( ERROR: Too many points in glyph %ld\n, subg-index ));
return TT_Err_Too_Many_Points;
Index: freetype1.spec
===
RCS file: /cvs/pkgs/rpms/freetype1/F-10/freetype1.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- freetype1.spec 14 Jun 2008 08:41:03 - 1.5
+++ freetype1.spec 26 May 2009 20:31:01 - 1.6
@@ -4,7 +4,7 @@
Name: freetype1
Version:1.4
-Release:0.6.pre%{?dist}
+Release:0.8.pre%{?dist}
Summary:Free TrueType font rendering engine, compatibility version
Group: System Environment/Libraries
License:FTL
@@ -15,6 +15,9 @@ Source: http://downloads.sourcef
Patch0: freetype-1.3.1-1.4pre.patch
Patch1: freetype-1.4-disable-ft1-bci.patch
Patch2: freetype-1.4pre-CVE-2008-1808.patch
+Patch3:cve-2006-1861.patch
+Patch4:cve-2007-2754.patch
+
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: zlib-devel libXt-devel gettext
@@ -61,6 +64,8 @@ developing applications that use %{name}
%endif
%patch2 -p1
+%patch3 -p1
+%patch4 -p1
iconv -f ISO-8859-1 -t UTF-8 docs/i18n.txt docs/i18n.txt.tmp
touch -r docs/i18n.txt docs/i18n.txt.tmp
@@ -125,6 +130,12 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue May 26 2009 Adam Jackson a...@redhat.com 1.4-0.8.pre
+- cve-2006-1861.patch, cve-2007-2754.patch: Port of freetype2 fixes. (#502565)
+
+* Tue Feb 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-0.7.pre
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
* Sat Jun 14 2008 Hans de Goede j.w.r.dego...@hhs.nl 1.4-0.6.pre
- Backport fixes for CVE-2008-1806, CVE-2008-1807 and CVE-2008-1808 to
freetype 1 (where applicable, bz 450773, 450774)
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/xorg-x11-fonts/devel xorg-x11-fonts.spec,1.28,1.29
Author: ajax
Update of /cvs/pkgs/rpms/xorg-x11-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv32360
Modified Files:
xorg-x11-fonts.spec
Log Message:
* Thu Feb 26 2009 Adam Jackson a...@redhat.com 7.2-8
- Yet another rebuild attempt.
Index: xorg-x11-fonts.spec
===
RCS file: /cvs/pkgs/rpms/xorg-x11-fonts/devel/xorg-x11-fonts.spec,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- xorg-x11-fonts.spec 26 Feb 2009 11:29:58 - 1.28
+++ xorg-x11-fonts.spec 26 Feb 2009 22:30:41 - 1.29
@@ -26,7 +26,7 @@
Summary: X.Org X11 fonts
Name: xorg-x11-fonts
Version: 7.2
-Release: 7%{?dist}
+Release: 8%{?dist}
License: MIT and Lucida and Public Domain
Group: User Interface/X
URL: http://www.x.org
@@ -1158,6 +1158,9 @@
%ghost %verify(not md5 size mtime) %{_x11fontdir}/cyrillic/fonts.cache-*
%changelog
+* Thu Feb 26 2009 Adam Jackson a...@redhat.com 7.2-8
+- Yet another rebuild attempt.
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 7.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/libXfont/devel .cvsignore, 1.16, 1.17 import.log, 1.1, 1.2 libXfont.spec, 1.42, 1.43 sources, 1.17, 1.18 libXfont-1.3.1-fast-retry.patch, 1.1, NONE libXfont-1.3.1-visibility.patch, 1.1, NONE libX
Author: ajax
Update of /cvs/pkgs/rpms/libXfont/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19423/devel
Modified Files:
.cvsignore import.log libXfont.spec sources
Removed Files:
libXfont-1.3.1-fast-retry.patch
libXfont-1.3.1-visibility.patch
libXfont-1.3.3-no-fontcache.patch
Log Message:
libXfont 1.4.0
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/.cvsignore,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- .cvsignore 28 Aug 2008 18:47:05 - 1.16
+++ .cvsignore 18 Feb 2009 19:10:56 - 1.17
@@ -1 +1 @@
-libXfont-1.3.3.tar.bz2
+libXfont-1.4.0.tar.bz2
Index: import.log
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/import.log,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- import.log 28 Aug 2008 18:47:05 - 1.1
+++ import.log 18 Feb 2009 19:10:56 - 1.2
@@ -1 +1,2 @@
libXfont-1_3_3-1_fc10:HEAD:libXfont-1.3.3-1.fc10.src.rpm:1219949211
+libXfont-1_4_0-1_fc11:HEAD:libXfont-1.4.0-1.fc11.src.rpm:1234984215
Index: libXfont.spec
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/libXfont.spec,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- libXfont.spec 28 Aug 2008 18:47:05 - 1.42
+++ libXfont.spec 18 Feb 2009 19:10:56 - 1.43
@@ -1,17 +1,13 @@
Summary: X.Org X11 libXfont runtime library
Name: libXfont
-Version: 1.3.3
+Version: 1.4.0
Release: 1%{?dist}
License: MIT
Group: System Environment/Libraries
URL: http://www.x.org
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Source0: ftp://ftp.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
-
-Patch1: libXfont-1.3.1-visibility.patch
-Patch2: libXfont-1.3.1-fast-retry.patch
-Patch3: libXfont-1.3.3-no-fontcache.patch
+Source0: http://www.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
BuildRequires: xorg-x11-util-macros
BuildRequires: xorg-x11-proto-devel
@@ -41,12 +37,9 @@
%prep
%setup -q
-%patch1 -p1 -b .visibility
-%patch2 -p1 -b .retry
-%patch3 -p1 -b .no-fc
%build
-autoreconf -v --install || exit 1
+export CFLAGS=$RPM_OPT_FLAGS -Os
%configure --disable-static
make %{?_smp_mflags}
@@ -85,7 +78,6 @@
%{_includedir}/X11/fonts/fontconf.h
%{_includedir}/X11/fonts/fontencc.h
%{_includedir}/X11/fonts/fontmisc.h
-%{_includedir}/X11/fonts/fontmod.h
%{_includedir}/X11/fonts/fontshow.h
%{_includedir}/X11/fonts/fontutil.h
%{_includedir}/X11/fonts/fontxlfd.h
Index: sources
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/sources,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- sources 28 Aug 2008 18:47:05 - 1.17
+++ sources 18 Feb 2009 19:10:56 - 1.18
@@ -1 +1 @@
-4f174b9613f87cf00d731da428a1b194 libXfont-1.3.3.tar.bz2
+3a8e06b25912ef339d70a8ba003da9b5 libXfont-1.4.0.tar.bz2
--- libXfont-1.3.1-fast-retry.patch DELETED ---
--- libXfont-1.3.1-visibility.patch DELETED ---
--- libXfont-1.3.3-no-fontcache.patch DELETED ---
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: [PATCH] build in microcode driver on x86
On Wed, 2009-01-14 at 13:49 -0500, Dave Jones wrote: On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it. We had this discussion yesterday on irc, but I never really got this in my head. It works ok with microcode.dat, but what happens if Intel release an update in /lib/firmware/intel-ucode/$f-$m-$s format ? Just to be clear, by works ok you mean we request_firmware() for f/m/s and get nothing, and then some time later an initscript loads microcode.dat instead. If you actually need the microcode to get out of initramfs, you have already lost, and this move won't change anything. The driver will do a request_firmware, but if we build the driver in, we'll be in the initrd, where that file won't exist. To make it work, we'll either have to.. - have the firmware in the initramfs Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Mon, 2008-10-13 at 10:59 -0400, Jarod Wilson wrote: On Friday 10 October 2008 21:23:34 Dave Airlie wrote: nvidia-agp I apologise for, it just came with that name from upstream, I meant to rename it to at least agp-nvidia. I don't suppose we could use a subdirectory called patches if we want to keep ls clean.. this being the 21st century :) I vaguely recall trying a test implementation of this at one point, and if I recall correctly, it made rpm very unhappy. However, its been a while, maybe this is doable with the latest rpm and/or maybe my recollections are wrong. A patches subdir would certainly clean things up considerably, and then I think a constant patch name prefix matters a lot less (certainly still could stand to apply some standard formula to naming, of course, but it wouldn't impact tab completion near as much anymore). rpm still doesn't like this. Adding it isn't _that_ hard, last time I looked, and it's not like it introduces any new collision opportunities for people who use the system-wide %_sourcedir. Probably worth running this past rpm-maint@ though. - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rawhide patches.
On Thu, 2008-09-25 at 14:57 -0400, Dave Jones wrote: linux-2.6-net-silence-noisy-printks.patch linux-2.6-piix3-silence-quirk.patch linux-2.6-quiet-iommu.patch linux-2.6-silence-acpi-blacklist.patch linux-2.6-silence-fbcon-logo.patch linux-2.6-silence-noise.patch Fedora local 'hush' patches. I did a good number of these (and added another one today). The PIIX3 and ACPI ones are plausible for upstream, I'll resend them. The IOMMU one is possibly controversial, but I've seriously never seen any machine ever where there's a BIOS option to make those messages go away. I suppose I should fire it at lkml just to generate flames. I also added one today to shut up the KERNEL ALIVE on amd64. I think notting had a better version of this? I just ripped them out, they could probably be redone in such a way that they honor 'quiet' on the command line but I really can't see the point of having them at all. - ajax ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
rpms/libXfont/devel import.log, NONE, 1.1 libXfont-1.3.1-fast-retry.patch, NONE, 1.1 libXfont-1.3.3-no-fontcache.patch, NONE, 1.1 .cvsignore, 1.15, 1.16 libXfont.spec, 1.41, 1.42 sources, 1.16, 1.17 c
Author: ajax
Update of /cvs/pkgs/rpms/libXfont/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6038/devel
Modified Files:
.cvsignore libXfont.spec sources
Added Files:
import.log libXfont-1.3.1-fast-retry.patch
libXfont-1.3.3-no-fontcache.patch
Removed Files:
cve-2008-0006.patch
Log Message:
libXfont 1.3.3
--- NEW FILE import.log ---
libXfont-1_3_3-1_fc10:HEAD:libXfont-1.3.3-1.fc10.src.rpm:1219949211
libXfont-1.3.1-fast-retry.patch:
--- NEW FILE libXfont-1.3.1-fast-retry.patch ---
diff -up libXfont-1.3.1/src/fc/fsio.c.jx libXfont-1.3.1/src/fc/fsio.c
--- libXfont-1.3.1/src/fc/fsio.c.jx 2007-09-04 20:18:23.0 -0400
+++ libXfont-1.3.1/src/fc/fsio.c2008-04-21 16:13:08.0 -0400
@@ -125,8 +125,6 @@ _fs_connect(char *servername, int *err)
_FontTransSetOption(trans_conn, TRANS_NONBLOCKING, 1);
do {
- if (i == TRANS_TRY_CONNECT_AGAIN)
- sleep(1);
i = _FontTransConnect(trans_conn,servername);
} while ((i == TRANS_TRY_CONNECT_AGAIN) (retries-- 0));
libXfont-1.3.3-no-fontcache.patch:
--- NEW FILE libXfont-1.3.3-no-fontcache.patch ---
diff -up libXfont-1.3.3/configure.ac.jx libXfont-1.3.3/configure.ac
--- libXfont-1.3.3/configure.ac.jx 2008-07-02 15:29:49.0 -0400
+++ libXfont-1.3.3/configure.ac 2008-08-28 14:44:03.0 -0400
@@ -180,7 +180,7 @@ fi
# Font cache extension support?
#
-AC_ARG_ENABLE(fontcache, [ --disable-fontcache
],[XFONT_FONTCACHE=$enableval],[XFONT_FONTCACHE=yes])
+AC_ARG_ENABLE(fontcache, [ --disable-fontcache
],[XFONT_FONTCACHE=$enableval],[XFONT_FONTCACHE=no])
AM_CONDITIONAL(XFONT_FONTCACHE, [test x$XFONT_FONTCACHE = xyes])
if test x$XFONT_FONTCACHE = xyes; then
AC_DEFINE(FONTCACHE,1,[Support the font caching extension])
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/.cvsignore,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- .cvsignore 24 Sep 2007 18:28:28 - 1.15
+++ .cvsignore 28 Aug 2008 18:47:05 - 1.16
@@ -1 +1 @@
-libXfont-1.3.1.tar.bz2
+libXfont-1.3.3.tar.bz2
Index: libXfont.spec
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/libXfont.spec,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- libXfont.spec 12 Feb 2008 15:57:33 - 1.41
+++ libXfont.spec 28 Aug 2008 18:47:05 - 1.42
@@ -1,7 +1,7 @@
Summary: X.Org X11 libXfont runtime library
Name: libXfont
-Version: 1.3.1
-Release: 4%{?dist}
+Version: 1.3.3
+Release: 1%{?dist}
License: MIT
Group: System Environment/Libraries
URL: http://www.x.org
@@ -9,14 +9,16 @@
Source0: ftp://ftp.x.org/pub/individual/lib/%{name}-%{version}.tar.bz2
-Patch0: cve-2008-0006.patch
Patch1: libXfont-1.3.1-visibility.patch
+Patch2: libXfont-1.3.1-fast-retry.patch
+Patch3: libXfont-1.3.3-no-fontcache.patch
BuildRequires: xorg-x11-util-macros
BuildRequires: xorg-x11-proto-devel
BuildRequires: xorg-x11-xtrans-devel = 1.0.3-3
BuildRequires: libfontenc-devel
BuildRequires: freetype-devel
+BuildRequires: autoconf automake libtool
Obsoletes: XFree86-libs, xorg-x11-libs
@@ -39,10 +41,12 @@
%prep
%setup -q
-%patch0 -p1 -b .cve-2008-0006
%patch1 -p1 -b .visibility
+%patch2 -p1 -b .retry
+%patch3 -p1 -b .no-fc
%build
+autoreconf -v --install || exit 1
%configure --disable-static
make %{?_smp_mflags}
@@ -92,6 +96,11 @@
%{_libdir}/pkgconfig/xfont.pc
%changelog
+* Thu Aug 28 2008 Adam Jackson [EMAIL PROTECTED] 1.3.3-1
+- libXfont 1.3.3.
+- libXfont-1.3.1-fast-retry.patch: Retry font server connections faster.
+ (#443070)
+
* Tue Feb 12 2008 Adam Jackson [EMAIL PROTECTED] 1.3.1-4
- libXfont-1.3.1-visibility.patch: Prevent a symbol collision with
ghostscript. (#216124)
Index: sources
===
RCS file: /cvs/pkgs/rpms/libXfont/devel/sources,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- sources 24 Sep 2007 18:28:28 - 1.16
+++ sources 28 Aug 2008 18:47:05 - 1.17
@@ -1 +1 @@
-b2f396b62633819bbdd9748383876e21 libXfont-1.3.1.tar.bz2
+4f174b9613f87cf00d731da428a1b194 libXfont-1.3.3.tar.bz2
--- cve-2008-0006.patch DELETED ---
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[PATCHES] Makefile.common speedups
Attached are two (orthogonal) patches to make evaluation of
Makefile.common a bit faster.
The first one is possibly contentious. Currently, early-branching works
by checking for the existence of the other branch, by using 'cvs rlog'.
That kinda sucks, because it means you can't do 'make local' while
disconnected, and even when connected it's not fast. The patch changes
it to look for the package's name in a new file,
common/early-branched-packages. By keeping that file together with
Makefile.common we get pretty much the behaviour we're used to: when
build targets change, you have to update common/. Note that if we apply
this patch we will also need to create that (empty) file.
This would change the cvsadmin procedure for early branching, but
hopefully not by a burdensome amount.
The second one is just a refactoring to only ask rpm for %VERSION and
%RELEASE once. In principle, for packages that overrode both VERSION
and RELEASE in their Makefile, this would actually make things slower,
since now you'd be forcing rpm to run. According to my pkgcvs checkout,
no such packages exist.
Tested locally on a 3.2GHz P4. 'time make' baseline was 1.3 seconds.
First patch dropped that to about 0.6 seconds. Second patch on top of
that dropped down to about 0.38 seconds.
- ajax
From 602511573793dd1a5b5cc5204238bef5cb50df9f Mon Sep 17 00:00:00 2001
From: Adam Jackson [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 11:26:33 -0400
Subject: [PATCH] Redo early branching
---
Makefile.common | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/Makefile.common b/Makefile.common
index aa0a126..faf63ef 100644
--- a/Makefile.common
+++ b/Makefile.common
@@ -19,12 +19,15 @@ COMMON_DIR := $(shell $(find-common-dir))
ifndef HEAD_BRANCH
HEAD_BRANCH := devel
endif
-BRANCH:=$(shell pwd | awk -F '/' '{ print $$NF }' )
-# check to see if this is an early branched package; we should make this more
-# generic in the future
-ifeq ($(BRANCH),devel)
-BRANCH:=$(shell cvs rlog rpms/$(NAME)/F-9/$(SPECFILE) /dev/null 21 echo F-10 || echo devel)
+
+BASEDIR := $(shell basename `pwd`)
+
+ifeq ($(BASEDIR),devel)
+BRANCH := $(shell grep -q '\$(NAME)\' $(COMMON_DIR)/early-branched-packages echo F-11 || echo devel)
+else
+BRANCH := $(BASEDIR)
endif
+
BRANCHINFO = $(shell grep ^$(BRANCH): $(COMMON_DIR)/branches | cut -d: --output-delimiter= -f2-)
TARGET := $(word 1, $(BRANCHINFO))
DIST = $(word 2, $(BRANCHINFO))
--
1.5.6
From c7ae6df63a762850507f503bb652186640558252 Mon Sep 17 00:00:00 2001
From: Adam Jackson [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 11:36:20 -0400
Subject: [PATCH] Invoke rpm less
---
Makefile.common | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Makefile.common b/Makefile.common
index faf63ef..8311bb6 100644
--- a/Makefile.common
+++ b/Makefile.common
@@ -85,7 +85,7 @@ SPECDIR := $(shell pwd)
endif
ifndef RPM_DEFINES
-RPM_DEFINES = --define _sourcedir $(SOURCEDIR) \
+RPM_DEFINES := --define _sourcedir $(SOURCEDIR) \
--define _specdir $(SPECDIR) \
--define _builddir $(BUILDDIR) \
--define _srcrpmdir $(SRCRPMDIR) \
@@ -95,16 +95,20 @@ endif
# Initialize the variables that we need, but are not defined
# the version of the package
+
+VER_REL := $(shell rpm $(RPM_DEFINES) -q --qf %{VERSION} %{RELEASE}\n --specfile $(SPECFILE)| head -1)
+
ifndef NAME
$(error You can not run this Makefile without having NAME defined)
endif
ifndef VERSION
-VERSION := $(shell rpm $(RPM_DEFINES) -q --qf %{VERSION}\n --specfile $(SPECFILE)| head -1)
+VERSION := $(word 1, $(VER_REL))
endif
# the release of the package
ifndef RELEASE
-RELEASE := $(shell rpm $(RPM_DEFINES) -q --qf %{RELEASE}\n --specfile $(SPECFILE)| head -1)
+RELEASE := $(word 2, $(VER_REL))
endif
+
# this is used in make patch, maybe make clean eventually.
# would be nicer to autodetermine from the spec file...
RPM_BUILD_DIR ?= $(BUILDDIR)/$(NAME)-$(VERSION)
--
1.5.6
signature.asc
Description: This is a digitally signed message part
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
