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 13:27 -0500, Fulko Hew wrote: > On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson 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: 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 17:32 +, Andrew Haley wrote: > On 01/06/2010 05:00 PM, Adam Jackson wrote: > > 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. > > Er, why would you want Firefox to be holding focus when it pops up? I can't > think of any reason. To pick an example from my daily life: Someone pastes a bugzilla URL at me on IRC, and I need to go scroll through it to see what they're talking about. - 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 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 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: 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: 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: 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: 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 (-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: 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: 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: Identifying remaining core font users
On Thu, 2009-11-12 at 16:00 +0100, Andreas Schwab wrote: > Adam Jackson writes: > > On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: > >> Nicolas Mailhot 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: Identifying remaining core font users
On Thu, 2009-11-12 at 14:59 +0100, Andreas Schwab wrote: > Nicolas Mailhot 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: 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
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: 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: 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: 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=767&sc=1 ). > > Look here for the log and read the commit messages: > http://svn.debian.org/wsvn/debburn/cdrkit/trunk/wodim/?op=log&rev=0&sc=0&isdir=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 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 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: 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 :
> > 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 requires libgcc, actually?
On Wed, 2009-10-28 at 10:41 +0100, Nicolas Chauvet wrote: > 2009/10/28 Linus Walleij : > > 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: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
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 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: > >> Has anyone been looking into building Fedora with it to see how the > >> performance impact is? > > > > I'm going to go out on a limb here and say that the dominating factor in > > our performance is the code itself. > > 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? - 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 Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote: > LLVM 2.6 has been announced with Clang declared as production quality in > this release > > http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/33.html > > Has anyone been looking into building Fedora with it to see how the > performance impact is? I'm going to go out on a limb here and say that the dominating factor in our performance is the code itself. Also, last time I checked, llvm's dwarf support was even worse than gcc's. No thanks. - 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: Unreadable binaries
On Thu, 2009-10-22 at 11:04 +0100, Richard W.M. Jones wrote: > $ ll /usr/libexec/pt_chown > -rws--x--x 1 root root 28418 2009-09-28 13:42 /usr/libexec/pt_chown > $ ll /usr/bin/chsh > -rws--x--x 1 root root 18072 2009-10-05 16:28 /usr/bin/chsh > > What is the purpose of making binaries like these unreadable? > > Originally I thought it was something to do with them being setuid, > but there are counterexamples: > > $ ll /usr/bin/passwd > -rwsr-xr-x 1 root root 25336 2009-09-14 13:14 /usr/bin/passwd Historically, the kernel considers read permission on a binary to be a prerequisite for generating core dumps on fatal signal; which you typically want to prevent, since that becomes a way to read /etc/shadow. Pretty sure that's still the case, which means any u+s binaries with group/other read permission are bugs. - 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=1761549&name=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
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=1761549&name=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: 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
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 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: 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: 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 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=) at WaitFor.c:228 > #2 0x00446ef2 in Dispatch () at dispatch.c:386 > #3 0x0042d205 in main (argc=, > argv=0x7fffa2ac9218, envp=) 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: Help with debuging Xserver / Goes in an infinite loop
On Mon, 2009-10-05 at 17:39 +0200, Joshua C. wrote: > 2009/10/5 Adam Jackson : > > On Sat, 2009-10-03 at 17:13 +0200, Joshua C. wrote: > >> 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? > > When should I issue this command? After attaching gdb and sending the > handle options I type in cont and the server keeps going until it > freezes the mashine. No other messages are reported. Before typing in cont, of course. "cont" continues execution from where you're currently stopped. "bt" shows a backtrace of where you're currently stopped. - 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: Intel graphics users: send me your VBIOS
On Fri, 2009-09-25 at 15:38 +0100, Jonathan Underwood wrote: > 2009/9/22 Adam Williamson : > > On Sat, 2009-09-19 at 12:30 -0400, Carlos Romero wrote: > >> I have a question: is there any way to disable lvds and use vga as the > >> primary, the sony phoenix bios has no options leaving me 60% blind > >> with a cracked panel. I guess there might be a bit in nvram. > > > > xrandr --output LVDS -off > > xrandr --auto > > > > something like that (it may be LVDS-0 or LVDS-1 or something, just look > > at the output of plain 'xrandr'). To make it semi-permanent, make the > > change in gnome-display-properties; the layout you set in > > gnome-display-properties is saved across GNOME sessions as your user. To > > make it completely solid across all X sessions for all users, you can do > > it in xorg.conf , following the syntax documented here: > > > > http://wiki.debian.org/XStrikeForce/HowToRandR12 > > That reminds me, I am seeing xrandr settings not persist across > suspend/resume - which component is that best filed against - kernel > or xorg? Start with X. In fact, in general, report KMS bugs against X, it's easier than trying to find them in the huge pile of kernel bugs. - 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: Retiring pangox
On Thu, 2009-09-24 at 21:53 -0400, Behdad Esfahbod wrote: > Hi, > > The pangox backend of pango have been deprecated for years (2001ish) and I'm > going to remove it upstream in a week or two. Matthias suggested we get rid > of it in f12. I totally welcome that. So I want to rebuild pango with > pangox > disabled in the coming days. > > I don't know of even one package that actually uses the pangox backend/API. > I > did a quick query [1] and seems like most packages linking to it are doing > that because gtkglext2 wrongly has pangox in its .pc file. I will patch > gtkglext2 to fix that, but all the dependent packages need to be rebuilt. > There are some alarming ones though. In particular: > >xorg-x11-drv-nvidia-0:185.18.36-1.fc11.i586 >AdobeReader_deu-0:9.1.3-1.i486 >AdobeReader_jpn-0:9.1.3-1.i486 > > Any help figuring out what's going on and how to move forward is appreciated. Well, those are rpmfusion packages, not Fedora, so in some sense, meh. But I bet those packages are just pulling in pangox from gtkglext2 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: 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
Intel graphics users: send me your VBIOS
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. Thanks! - 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 fonts in Fedora
On Fri, 2009-09-18 at 16:51 +0200, Daniel Mach wrote: > On 09/18/2009 04:42 PM, Colin Walters wrote: > > On Fri, Sep 18, 2009 at 2:05 PM, Daniel Mach wrote: > > > >> I've manually installed KDE desktop (yum install ..., i.e. without > >> anaconda) and found that no fonts were installed. > >> > > Use "yum groupinstall" to add a desktop. > > > > > Which group should I install? > yum install @base-x is definitely not a good choice, it installs a lot > of packages I don't really want. > It's 107 additional packages to my current installation. @base-x is a pretty broken comps group, to be honest. I'd really like to see a split between "the minimal stuff needed to make X work" and "a bunch of desktop-agnostic stuff". Actually, that's not true. Someone should own the choose-your-own-adventure desktop experience and come up with a decent way of selecting devilspie/fluxbox/twm/ratpoison etc. And I'm going to bet that that won't be comps groups, which means they shouldn't be listed in comps at all. - 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: GNU libc confusion with symbols undefined.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
> I'm trying to understand the following here
>
> I have a simple test program that calls memcpy/malloc/printf
>
> int
> main(int argc, char **argv)
> {
> char * p = malloc(10);
> memcpy(p,"Hello",6);
> printf("%s\n", p);
> }
>
> When looking at the symbol list why are the following routines undefined? And
> why is it referncing GLIBC_2.2.5?
>
> $ nm /tmp/f |grep ' U '
> U __libc_start_main@@GLIBC_2.2.5
> U malloc@@GLIBC_2.2.5
> U memcpy@@GLIBC_2.2.5
> U printf@@GLIBC_2.2.5
They're "undefined" in your binary because your binary does not define
them. It references them, and some other library you're linked against
provides 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: Mouse pointer freezing in f12 and f11
On Fri, 2009-09-18 at 15:11 +1000, Rodd Clarkson wrote: > On Wed, 2009-09-16 at 21:15 +1000, Rodd Clarkson wrote: > > I'm pretty sure that this problem only occurs before I've cycled through > > a suspend-resume. > > > > I suspect bluetooth issues because the bluetooth icon appears until I do > > the suspend-resume cycle and then the icon doesn't appear and bluetooth > > doesn't work (but the mouse does). > > > > Keyboard navigation still works, and I can switch to a VT too. > > Alright, I've had this happen after a suspend-resume cycle, and it > appears that it's not bluetooth related as the output of xinput is the > same before as after. > > Do you want me to file a bug on this and then work from there? Yeah. Likely a kernel bug. Try running something like evtest on the pointer device after resume and see if you get events at all: http://people.freedesktop.org/~ajax/evtest.c If you get events that way, then X is confused; if you don't, then the kernel driver is confused. - 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 11:27 -0700, Toshio Kuratomi wrote:
> On 09/15/2009 06:55 AM, Adam Jackson wrote:
> > 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.
> >
> The rules against shared libraries aren't because of saving space::
>
> https://fedoraproject.org/wiki/No_Bundled_Libraries
I'm aware, I just don't think they read strongly enough on this case to
matter. The copy of zlib is there _because_ it can't change, so the
arguments for changing things OAOO are really weak.
I'm also not aware of any precedent for what to name a library like
this. %{_libdir}/libfedora-rsync-zlib.so.0 ? What version number do we
pick? Who's responsible for making sure it gets bumped when it should?
Seems like a lot of policy to type for very little practical gain.
Speaking more generally, the package review process makes it very hard
to get anything in the door if it doesn't fit the existing rules, and
the rules do not change quickly. We would probably deliver more value
if we were willing to accept packages with merely a _plan_ to fix the
deviations. As a bonus, we'd have a list of things to do for people
looking for ways to contribute.
- 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: EDID necessary for fixed-format displays?
On Tue, 2009-09-15 at 11:13 -0700, John Reiser wrote: > > We get FF [fixed format] displays pretty much right, > > What is holding up https://bugzilla.redhat.com/show_bug.cgi?id=493441 Primarily that it's rage128 hardware, which no one likes working on. > where a 1024x768 LCD panel is recognized only as 800x600, and with > no option to choose 1024x768, except via explicit /etc/X11/xorg.conf ? > > That box does not have EDID, but Xorg.0.log shows > (II) R128(0): Panel size: 1024x768 > so the driver does know the truth. > It looks like a lazy driver if EDID is the only way to success. Pretty sure I've seen other cases where r128 gets the panel size wrong. We do something similar in the vesa driver though, where we'll call out to the VBE panel ID method if there's no EDID. I'd be interested to see what vesa does on that hardware. The panel size dump in r128 is scraping out of some scratch registers that happen to be the right size sometimes, where the VBE call might actually be reliable. - 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
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: 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
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: 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: 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 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: 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 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: 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: 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
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 '\' 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 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 Mon, 2009-08-10 at 14:40 -0500, Jon Ciesla wrote: > Adam Jackson wrote: > > 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 > > > 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. - 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])) == "": -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: 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: 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: 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: 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: 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 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: 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: 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: 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 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 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 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: Lower Process Capabilities
On Tue, 2009-07-28 at 01:12 +0200, yersinia wrote: > On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson wrote: > > 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. > > Put an example, thanks. Trim message bodies when quoting, thanks. You can create an selinux context that is not allowed to exec, or only allowed to exec certain things. Or not allowed to connect to TCP sockets. Or pretty much anything else a normal user would otherwise be allowed to do. - 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 17:46 -0400, Simo Sorce wrote: > On Tue, 2009-07-07 at 16:39 -0400, Adam Jackson wrote: > > 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... > > ... which has nothing to do with patents, or property rights ... Eek, that's actually a good point, Berne is copyright not patent. Mea culpa. - 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: http://www.fsf.org/news/dont-depend-on-mono
On Tue, 2009-07-07 at 07:14 -0700, Jesse Keating wrote: > On Jul 7, 2009, at 3:15, Dodji Seketeli wrote: > > Le 07/07/2009 12:02, Rui Miguel Silva Seabra a écrit : > >> What you're explicitly told s that you won't be sued if you do so > >> without the right. > >> > >> And you have no right! > > > > Just to try to understand your point. > > > > 1/You don't have the rights to do A. > > 2/ But you do A, you won't be sued. > > > > Doesn't that make 1/ irrelevant in practice ? > > No, it just means that the promise to not sue can be lifted at any > time and leave every user vulnerable. Except that, for the Microsoft Community Promise, it can not. - 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 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 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: 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: 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 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: 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 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 : > > 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: http://www.fsf.org/news/dont-depend-on-mono
On Mon, 2009-06-29 at 08:38 +0100, Frank Murphy wrote: > Is there any contingency plans in place, > for a worst case scenario if C#, is lost? > FesCo? > Legal? > > Is there any searchable parameter, > to work out what something is coded in\depending on (code wise) The contingency plan, I imagine, is "take off, nuke the site from orbit". As for listing dependencies, yes, we have tools for that: atropine:~% repoquery --whatrequires --alldeps mono-core evolution-sharp-0:0.20.0-1.fc11.i586 mono-nunit-0:2.4-19.fc11.i586 bytefx-data-mysql-0:2.4-19.fc11.i586 mono-sharpcvslib-0:0.35-9.fc11.i586 ice-csharp-0:3.3.1-1.fc11.i586 gnome-rdp-0:0.2.3-3.fc11.i586 cowbell-0:0.3-0.svn34.4.fc10.i386 mono-tools-0:2.4-8.1.fc11.i586 muine-0:0.8.10-4.fc11.i586 bless-0:0.6.0-2.fc11.i586 banshee-mirage-0:0.4.0-5.fc11.i586 avahi-sharp-0:0.6.25-1.fc11.i586 flickrnet-0:2.1.5-2.fc11.i586 mono-moonlight-0:2.4-19.fc11.i586 mono-data-sqlite-0:2.4-19.fc11.i586 mono-web-0:2.4-19.fc11.i586 mono-data-firebird-0:2.4-19.fc11.i586 xsp-0:2.4-8.fc11.i586 gbrainy-0:1.1-3.fc11.i586 banshee-0:1.4.3-3.fc11.i586 gtk-sharp2-0:2.12.7-4.fc11.i586 monsoon-0:0.21-1.fc11.i586 kimono-0:4.2.4-2.fc11.i586 flickrnet-0:2.1.5-1.fc11.i586 webkit-sharp-0:0.2-3.fc11.i586 mono-jscript-0:2.4-19.fc11.i586 incollector-0:1.0-8.fc11.i586 monsoon-0:0.20-2.fc11.i586 podsleuth-0:0.6.3-2.fc11.i586 log4net-0:1.2.10-5.fc11.i586 webkit-sharp-0:0.2-1.fc11.i586 monodoc-0:2.4-19.fc11.i586 ipod-sharp-0:0.8.1-2.fc11.i586 gtksourceview-sharp-0:2.0.12-8.fc11.i586 mono-nat-0:1.0-3.fc11.i586 kimono-0:4.2.2-5.fc11.i586 gnome-guitar-0:0.8.1-2.fc11.i586 gnome-sharp-0:2.24.0-3.fc11.i586 mono-addins-0:0.4-6.20091702svn127062.1.fc11.i586 beagle-thunderbird-0:0.3.9-6.fc11.i586 gecko-sharp2-0:0.13-2.fc11.i586 mono-devel-0:2.4-19.fc11.i586 avahi-ui-sharp-0:0.6.25-1.fc11.i586 mono-extras-0:2.4-19.fc11.i586 monodoc-devel-0:2.4-19.fc11.i586 xsp-tests-0:2.4-8.fc11.i586 mono-data-oracle-0:2.4-19.fc11.i586 gtk-sharp-gapi-0:1.0.10-22.fc11.i586 mono-nunit-devel-0:2.4-19.fc11.i586 cdcollect-0:0.6.0-7.fc11.i586 gtksourceview2-sharp-0:1.0-3.svn89788.3.fc11.i586 tasque-0:0.1.8-2.fc11.i586 mono-nunit22-1:2.2.10-9.fc11.i586 boo-0:0.8.1.2865-6.fc11.i586 gmime-sharp-0:2.4.3-3.fc11.i586 dbus-sharp-0:0.63-11.fc11.i586 graphviz-sharp-0:2.20.3-3.fc11.i586 gnome-desktop-sharp-0:2.26.0-1.fc11.i586 notify-sharp-0:0.4.0-0.6.20080912svn.fc11.i586 sublib-0:0.9-4.fc11.i586 ibm-data-db2-0:2.4-19.fc11.i586 mono-winforms-0:2.4-19.fc11.i586 mono-data-sybase-0:2.4-19.fc11.i586 mono-basic-0:2.4-5.fc11.i586 ndesk-dbus-0:0.6.1a-4.fc11.i586 mono-locale-extras-0:2.4-19.fc11.i586 mono-core-0:2.4-19.fc11.i586 monosim-0:1.3.0.2-2.fc11.i586 mono-ndoc-0:1.3.1-4.fc11.i586 tomboy-0:0.14.1-2.fc11.i586 mono-data-postgresql-0:2.4-19.fc11.i586 beagle-evolution-0:0.3.9-6.fc11.i586 ndesk-dbus-glib-0:0.4.1-4.fc11.i586 gnome-do-0:0.8.1.3-5.fc11.i586 mono-nat-0:1.0-2.fc11.i586 taglib-sharp-0:2.0.3.2-2.fc11.i586 f-spot-0:0.5.0.3-8.fc11.i586 mono-cecil-flowanalysis-0:0.1-0.8.20080409svn100264.fc11.i586 banshee-mirage-0:0.5.0-2.fc11.i586 themonospot-0:0.7.1.1-2.fc11.i586 mod_mono-0:2.4-4.1.fc11.i586 mono-zeroconf-0:0.7.6-8.fc11.i586 gnome-keyring-sharp-0:1.0.1-0.2.115768svn.fc11.i586 beagle-0:0.3.9-6.fc11.i586 gnome-subtitles-0:0.8-7.fc11.i586 db4o-0:6.1-6.fc11.i586 mono-data-0:2.4-19.fc11.i586 monotorrent-0:0.72-2.fc11.i586 tomboy-0:0.14.2-1.fc11.i586 mono-debugger-0:2.4-8.fc11.i586 bareftp-0:0.2.2-2.fc11.i586 banshee-musicbrainz-0:1.4.3-3.fc11.i586 gsf-sharp-0:0.8.1-9.fc11.i586 gnome-guitar-0:0.8.1-4.fc11.i586 gtk-sharp-0:1.0.10-22.fc11.i586 beagle-gnome-0:0.3.9-6.fc11.i586 mono-web-devel-0:2.4-19.fc11.i586 nant-1:0.85-27.fc11.i586 - 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: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, 2009-06-17 at 10:06 -0400, Chuck Anderson wrote: > On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: > > b.2) extend the autorequires/autoprovides in some (handwaves) way to > > better indicate the desired match > > I like this idea better. AutoReq/Prov should only search system-wide > deafult search paths for .so's, perl modules, and any other such > objects that it supports. "system-wide" includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Really we just need the moral equivalent of %exclude for autoreqprovs. - 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 15:13 -0500, King InuYasha wrote: > EFI support is not the same as fake-EFI. Your mail client has atrociously bad indentation. Fix it. It appears from light googling that what you mean by "fake EFI" is "a boot loader that fakes enough of EFI to be able to boot OSX on a non-Apple machine". I wasn't aware it was a goal of the Fedora project to enable you to boot some _other_ OS on arbitrary hardware, when the license of that other OS expressly forbids you from doing so. - 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: 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
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
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
