EKOPath compiler in the next Fedora releases
Hi there, Is there any plan to have the EKOPath compiler, from PathScale, shipped as part of the future Fedora releases? It doesn't necessarily mean having Fedora's packages built with it, but merely packaging it as a first step. Any thoughts? -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EKOPath compiler in the next Fedora releases
Well assuming no legal issues anyone can package it and submit it for review ... I do know that SLES and RH releases are being worked on. It should also become available for Scientific Linux too at some point. -Ilyes On Sat, Aug 13, 2011 at 1:23 PM, drago01 drag...@gmail.com wrote: On Sat, Aug 13, 2011 at 1:37 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi there, Is there any plan to have the EKOPath compiler, from PathScale, shipped as part of the future Fedora releases? It doesn't necessarily mean having Fedora's packages built with it, but merely packaging it as a first step. Any thoughts? Well assuming no legal issues anyone can package it and submit it for review ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EKOPath compiler in the next Fedora releases
You (or anyone else) is still free to just package it. Sure. I'm trying to put together an initial spec file for Fedora. -Ilyes On Sat, Aug 13, 2011 at 1:36 PM, drago01 drag...@gmail.com wrote: On Sat, Aug 13, 2011 at 2:34 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Well assuming no legal issues anyone can package it and submit it for review ... I do know that SLES and RH releases are being worked on. It should also become available for Scientific Linux too at some point. So? You (or anyone else) is still free to just package it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EKOPath compiler in the next Fedora releases
We should also target and package a clearly stated and defined (features) version of the compiler, that has been tested and validated. -Ilyes On Sat, Aug 13, 2011 at 4:00 PM, Jussi Lehtola jussileht...@fedoraproject.org wrote: On Sat, 13 Aug 2011 16:42:13 +0200 Björn Persson bj...@xn--rombobjrn-67a.se wrote: Ilyes Gouta wrote: I'm trying to put together an initial spec file for Fedora. According to PathScale's license document their products are partly free and partly unfree. You can of course only package the free parts. How useful are they without the unfree parts? Björn Persson http://www.pathscale.com/ekopath4-open-source-announcement June 13th, 2011 PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers. The sources seem to be available at https://github.com/path64 The compiler part is GPLv3, the debugger is CDDL. I tried to get the compiler packaged for a few hours, but ran into some problems in the build phase; the compiler segfaulted in the bootstrap phase. This was on Fedora 15. My spec file is attached, maybe someone can get it to build. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
Are there any plans to bring gimp 2.7.x - 2.8 into F16 ? Is there a specific reason to? The home page states that the whole 2.7.x series should be considered unstable. Alright, would then the 2.8.x series be in F16? -Ilyes Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Fri, Nov 4, 2011 at 2:40 PM, Matthias Clasen mcla...@redhat.com wrote: On Thu, 2011-11-03 at 23:09 -0700, Adam Williamson wrote: But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell. That's pretty accurate, yes. One nice outcome is that we could end up with an optimized reference s/w renderer (and kernel/user land stack) for all platforms. Which is cool! :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Building and exporting libgbm from the mesa package
Hi, Any reasons on why libgbm isn't being built and packaged in the current mesa SPEC file? libgbm is a dependency for wayland-demos. The --enable-gbm configure option depends on --enable-shared-glapi. Is there any constraint? -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WebKit(s) SIG
Hi, I'm interested too! Do we cover embedded platforms? -Ilyes Gouta On Fri, Aug 6, 2010 at 9:48 PM, Martin Sourada martin.sour...@gmail.com wrote: On Fri, 2010-08-06 at 18:11 +0200, Jaroslav Reznik wrote: There is already WebKit page on Wiki [1] but I'd like to use this one as the entry point for users, not for more concrete technical discussion. So I created another page under SIGs category [2] (is there any policy for creation of SIGs? I wasn't very successful looking for it but I'm quite tired already). Please sign up and edit tasks section according to what do you find to be important to start SIG. So, I've done some initial filling up the WebKitsInFedora [3] page. It will probably need more details on what svn snapshots the various versions use, adding reference to spot's chromium, what are the port specifics (libsoup vs. curl, ...),... Feel free to add this info :) [1] https://fedoraproject.org/wiki/WebKit [2] https://fedoraproject.org/wiki/SIGs/WebKit [3] https://fedoraproject.org/wiki/SIGs/WebKit/WebKitsInFedora Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changelog for the latest Fedora kernel release/updates
Hi, Where can I get such information? And is it possible to indicate where I can locate Fedora's kernel git tree? -Ilyes Gouta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changelog for the latest Fedora kernel release/updates
Hi Pierre-Yves, How you're doing? We met at Fosdem last time. I'm the Tunisian guy :) OK, thanks. The git tree would be interesting too :) -Ilyes Gouta On Sat, Aug 7, 2010 at 10:18 AM, Pierre-Yves pin...@pingoured.fr wrote: On Sat, 2010-08-07 at 10:09 +0100, Ilyes Gouta wrote: Where can I get such information? And is it possible to indicate where I can locate Fedora's kernel git tree? rpm -q --changelog should be a start. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changelog for the latest Fedora kernel release/updates
Hi, So fedpkg is only available in updates-testing. Any direct link? fedpkg is included in the package fedora-packager and it is already in the updates repo. Great! I guess I can directly clone from git://pkgs.fedoraproject.org/kernel.git, but I'll try to stick to fedpkg for a while. Thanks, everyone! -Ilyes Gouta Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changelog for the latest Fedora kernel release/updates
I do need to be in a ACL and have a public key, isn't? :) -Ilyes Gouta On Sat, Aug 7, 2010 at 12:43 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, So fedpkg is only available in updates-testing. Any direct link? fedpkg is included in the package fedora-packager and it is already in the updates repo. Great! I guess I can directly clone from git://pkgs.fedoraproject.org/kernel.git, but I'll try to stick to fedpkg for a while. Thanks, everyone! -Ilyes Gouta Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Hi, Since JavaScript has a client-side execution model and since the all the JS scripts are downloaded in plain text format (even if sometimes obfuscated) along with the html code, then can't we assume that JS code is available in source format and hence can't be classified as closed source programs? What I suggest is just to use the same old JavaScript interpreter we have used before the JIT was introduced, which they undoubtedly keep working for So much effort and expertise were spent to bring JS execution to higher performance levels using VMs like V8, Tamarin, Squirrelfish, and we're speaking here about a 6x to 8x speed up ratio compared to an interpreted execution. JIT VMs are important for the end-user experience, being in the context of the web or webapp and are a corner stone for the next-gen Web where most applications are going to be written in HTML5 and JavaScript and almost near-native execution performance is going to be desired (think canvas and WebGL for in-browser standard 2D and 3D rendering), and In my opinion Fedora should pave the way for such kind of bleeding edge tech. Security comes from an implementation which is specification compliant and projects such as Firefox, WebKit (and any other browser which claims to be standard compliant) that won't save any effort to get to that point. Techniques such as sand-boxing would also help a lot mitigating malware and other security issues and constitutes a complementary design approach for an overall improved browser security model. -Ilyes Gouta On Thu, Aug 19, 2010 at 5:10 AM, Matt McCutchen m...@mattmccutchen.net wrote: On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote: Adam Williamson wrote: Shipping a Firefox with no ability to use Javascript would be more or less equal to not shipping it, frankly. No-one would use the thing. What I suggest is just to use the same old JavaScript interpreter we have used before the JIT was introduced, which they undoubtedly keep working for those platforms which don't have JIT support available at all. That doesn't mean no JavaScript support, just a performance impact which is probably negligible on most sites Gmail makes very heavy use of JavaScript, so I bet the difference there is significant. There may be Free Software web applications for which the same is true, I'm just not familiar with them. I know you won't believe me; someone who knows how will have to perform a test. and much better security. You haven't convinced me of this. Are vulnerabilities that let one inject enough code to exploit the JIT (particularly after the SELinux patch) really that easy to find? But others have a better understanding of attacks in machine code than I do. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Kevin, Free Software is not just about availability of source code. (That's exactly why the term Open Source is misleading!) It's no use having the source code if you aren't allowed to legally do anything with it. I did't claim that JS code is open source. It's just that, we all being able to pull JS code in plain text from a given server, from any place on the world, doesn't really help classifying that code as a closed source. Heck, we can even change on the fly a JS piece within the browser via a JS console (think Greasemonkey for FF, Chome's JS console). Obfuscation however corroborates the latter aspect. Security against buffer overflow exploits comes from a security-conscious design. That's what I meant by a (correct) specification and a compliant implementation. Converting untrusted code into native machine code and executing that is NOT a security-conscious design, it just begs to get exploited. Still, it's can be correctly designed to really lower the risk (or even eliminate it). That's there is *still* room to make it safer and I don't see why it has to be completely disabled, banned and shutdown. Techniques such as process isolation (when running JIT'ed code), I/O sand-boxing, lowered/restricted privilege resource access, etc. *do* help. The web is a medium for information, not code. If you really want a platform for remote services (which I'm not convinced I want, I'd rather control the software I'm running), you need to help design a real cloud platform from ground up. It's changing. HTML5 and JS are going to be the front-ends for such remote services provided by those cloud platforms. And these are the standard way (vs. Adobe's Flash for example) to deliver a rich experience to the end-user, right in his browser, and IMHO we should support that. -Ilyes Gouta On Thu, Aug 19, 2010 at 3:22 PM, Kevin Kofler kevin.kof...@chello.at wrote: Ilyes Gouta wrote: Since JavaScript has a client-side execution model and since the all the JS scripts are downloaded in plain text format (even if sometimes obfuscated) along with the html code, then can't we assume that JS code is available in source format and hence can't be classified as closed source programs? Free Software is not just about availability of source code. (That's exactly why the term Open Source is misleading!) It's no use having the source code if you aren't allowed to legally do anything with it. In addition: * Obfuscated code is not source code. * Those web apps also have lots of server-side code which is entirely secret. the next-gen Web where most applications are going to be written in HTML5 and JavaScript and almost near-native execution performance is going to be desired I want none of that useless crap, thank you very much! Applications should be written as applications, delivered through our package repository, in a compiled language. Web sites should just be web sites and have as little code as possible (ideally none). The web is a medium for information, not code. If you really want a platform for remote services (which I'm not convinced I want, I'd rather control the software I'm running), you need to help design a real cloud platform from ground up. The way the web is being abused as a software platform is really appalling. It's really not designed for that, and we have tons of ugly workarounds such as session cookies, AJAX etc. JavaScript JITs are a part of those broken workarounds. Security comes from an implementation which is specification compliant Nonsense. Standards-compliance is completely orthogonal to security. Security against buffer overflow exploits comes from a security-conscious design. Converting untrusted code into native machine code and executing that is NOT a security-conscious design, it just begs to get exploited. Techniques such as sand-boxing would also help a lot mitigating malware and other security issues But an interpreter can enforce the sandboxing in a much more robust and failsafe way than a JIT. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Hi, Well, that's not what HTML, nor the underlying HTTP, was designed for. I don't see it as being an appropriate platform for software at all. (And I don't see plugins such as Flash as being the solution either. I believe this needs a completely different protocol, e.g. NX is something going in that direction.) As always Kevin I agree with you. These people don't understand basic OSI network layers; rather obvious textbook stuff. The cool thing about JS and all what's happening today in the browser world, is that everything is being done at the application layer (level 4) of the OSI model, a fact which gives a rather unique opportunity and freedom to software designers to specify applications protocols easily and without huge constraints vs. what someone has to deal with if you're at level 3, that's IP. However, like any protocols meant to be adopted by the majority, app. protocols must also gain the approbation and consensus of a majority and ideally the spec. must be made accessible to everyone and implemented accordingly. This is what drives tech. adoption and global deployment (think HTTP, SOAP, XML and on the other hand hopefully WebM vs. H.264) and a basis and a foundation for the next iteration. It happens that HTML (and its siblings) and JS are part of this wild landscape and both are *evolving*, and (IMHO) I would like to see Fedora leading (and pursuing) the way with this. -Ilyes Gouta And IMHO, as a Free Software distribution, we should do all we can to promote Free Software installed on the end user's machine where he/she has full control (freedom!) over the software rather than remote services, web or otherwise. If we tolerate any non free software then what's the point? Why not just run Windows or OSX? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Hi, Still, it's can be correctly designed to really lower the risk (or even eliminate it). I don't believe the risk can be eliminated entirely. There will always be unacceptable risk if you execute native code generated at runtime from an untrusted source. How about a very well maintained open source piece of software, such as Firefox, WebKit and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a source of that generated native code at runtime? This would immensely help verifying the emitter of such a code and take the appropriate action, if needed. -Ilyes Gouta It's changing. HTML5 and JS are going to be the front-ends for such remote services provided by those cloud platforms. And these are the standard way (vs. Adobe's Flash for example) to deliver a rich experience to the end-user, right in his browser, and IMHO we should support that. Well, that's not what HTML, nor the underlying HTTP, was designed for. I don't see it as being an appropriate platform for software at all. (And I don't see plugins such as Flash as being the solution either. I believe this needs a completely different protocol, e.g. NX is something going in that direction.) And IMHO, as a Free Software distribution, we should do all we can to promote Free Software installed on the end user's machine where he/she has full control (freedom!) over the software rather than remote services, web or otherwise. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Matej, and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a well-maintained piece of pre-Alpha unreleased code. I brought this one because of the architecture redesign, that tries to address some security and performance points, not for the code quality per se., which is still being worked on. -Ilyes Gouta Please, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC SCSI is *not* magic. There are *fundamental* *technical* reasons why you have to sacrifice a young goat to your SCSI chain every now and then. -- John F. Woods (j...@funhouse.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
Hi, What about the WebKit SIG that Jaroslav Reznik wants to setup? http://lists.fedoraproject.org/pipermail/devel/2010-August/140497.html -Ilyes Gouta On Sat, Aug 21, 2010 at 1:28 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Matej, and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a well-maintained piece of pre-Alpha unreleased code. I brought this one because of the architecture redesign, that tries to address some security and performance points, not for the code quality per se., which is still being worked on. -Ilyes Gouta Please, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC SCSI is *not* magic. There are *fundamental* *technical* reasons why you have to sacrifice a young goat to your SCSI chain every now and then. -- John F. Woods (j...@funhouse.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with F17 yum requesting old repodata?
Hi, On Nov 24, 2012 8:20 AM, Dariusz J. Garbowski thufo...@yahoo.co.uk wrote: On 24/11/12 05:37 AM, Chris Adams wrote: Once upon a time, Kevin Fenzi ke...@scrye.com said: It should also be normally trying multiple mirrors, not a bunch of times to the same one. :( [...] Actually, when I account for the different hashes and arches, the failing requests for updates/17/*/repodata/*-other.sqlite.bz2 files are accounting for almost 2/3 of all HTTP requests to my mirror. I am not seeing any FTP requests; does yum try FTP these days? It doesn't appear to be causing any problem (no load impact, just bigger logs; the daily error_log isn't usually 250MB+) on my mirror, but I expect it is causing issues for clients. This is what I get for the last few days: # yum --skip-broken update Loaded plugins: langpacks, presto, refresh-packagekit adobe-linux-x86_64 | 951 B 00:00 rpmfusion-free-updates | 3.3 kB 00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00 updates/17/x86_64/metalink | 16 kB 00:00 updates | 4.7 kB 00:00 00c7410a78aa8dd0f4934ed4935377 FAILED HTTP Error 404 - Not Found : http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2 http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found : http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2 Trying other mirror. updates/primary_db | 6.9 MB 00:06 updates/group_gz| 435 kB 00:00 Resolving Dependencies -- Running transaction check --- Package ctags.x86_64 0:5.8-7.fc17 will be updated --- Package ctags.x86_64 0:5.8-9.fc17 will be an update --- Package dbus.x86_64 1:1.4.10-6.fc17 will be updated --- Package dbus.x86_64 1:1.4.10-7.fc17 will be an update ... I'm seeing those here too. This is global. -Ilyes -- Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. -Ilyes -- Forwarded message -- From: Chris Wilson ch...@chris-wilson.co.uk Date: Sat, Dec 15, 2012 at 11:07 AM Subject: [ANNOUNCE] xf86-video-intel 2.20.16 To: xorg-annou...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org, x...@lists.freedesktop.org Rejoice! We have found a trick to make 830gm/845g stable at long last. Ever since the switch to GEM and dynamic video memory, those early second generation chipsets have been plagued by instability. The lack of flushing cachelines from the CPU to GMCH was eventually solved by using an undocmented bit, but 830/845 were still hanging under memory pressure. These deaths were all due to garbage finding its way into the command streamer, and they go away if we take a leaf out of the original driver and never reuse those pages for anything else. So for the first time ever, I have been able to complete running the test suite on an 845g, even whilst thrashing the page and buffer caches! -Chris * Run the SF stage as single-threaded on gen4 to workaround a few issues https://bugs.freedesktop.org/show_bug.cgi?id=57410 * Keep the scanout SURFACE_STATE separate to avoid overriding its memory access control on gen6/7 (i.e. writes to the scanout need to be kept out of the render cache) * Tune batch flushing after an operation to an exported surface under a compositor. * Make sure the source is on the CPU for inplace composition of trapezoids using the CPU https://bugs.freedesktop.org/show_bug.cgi?id=56825 * Immediately flush in the block hander after a split batch to reduce latency between the two halves of an operation. https://bugs.freedesktop.org/show_bug.cgi?id=51718 * Install a fallback config if we fail to install the desired config at VT switch (i.e. booting, after resume with 3 incompatible pipes on Ivybridge) * Pin batches to avoid CS incoherence on 830/845 https://bugs.freedesktop.org/show_bug.cgi?id=26345 Chris Wilson (53): sna: Tidy addition of fake GTF modes for panels sna/gen4: Avoid emitting URB_FENCE across a cache-line sna/gen4: Remove unused CC viewport sna/gen4: Special case solids through the general vertex emitter sna/gen4: Workaround render corruption with multiple SF threads sna/gen6+: Cache the scanout targets separately to avoid override PTE caching sna: Assume that future hardware only gets more flexible sna: Don't disable CPU bo if supported on unknown hw Refactor the common probe methods for scrn construction sna/gen4+: Add common glyph-to-dst emitters Fix compilation of UMS probe following 13f47008ec Remove the default log message sna: Mark proxies as dirty on first relocation sna: Only flush at the low apeture watermark if idle sna: Only flush before adding fresh surfaces to the batch sna: Only inspect the target ring for busyness sna: Convert the ring from BLT/3D to the internal index for kgem_ring_is_idle() sna: Flush upon change of target if GPU is idle sna: Replace remaining kgem_is_idle() with kgem_ring_is_idle() sna/gen4+: Refine test for preferring GPU spans sna: Move source to CPU prior to referencing for inplace trapezoids sna/sprite: Add a DBG to report whether the kernel supports sprites sna: Immediately flush a split batch sna: Compromise and only flush a split batch if writing to scanout sna: Avoid reusing the same 'busy' bit for two different meanings. sna: Try installing a fallback config on VT enter in case full desiredMode fails sna/dri: Only special case 'divisor msc-passed' for immediate flipping sna/dri: Disable name exchanges for SwapBuffers sna/dri: Query current msc before use sna/dri: Fix handling of current_msc target_msc sna/gen4: Use the single-threaded SF w/a for spans as well sna/gen3+: Use nearest for unscaled videos sna/gen2: STIPPLE requires an argument sna: Pin some batches to avoid CS incoherence on 830/845 sna: Fix the error path in kgem_init_pinned_batches() to use the right iter sna: Improve the initialisation failure path for pinned batches sna: Only flush the batch after an actual relocation sna: Fix typo for 830/845 gen sna: Fix up BLT overwrite detection to use target_handle sna/gen2: Align surface sizes to an even tile sna/gen2: Program solid mask using the DIFFUSE component sna/gen3: Remove incorrect optimisation of an opaque source for CA sna/gen2: Assertions sna/gen2: Initialise channel-is_affine for solid sna/gen2: Reorder reuse_source() to avoid NULL dereference for solids sna/gen3: Remove stray setting of vertex_start sna/gen3: Don't combine primitives if beginning a ca 2-pass
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.comwrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. This update is an exception, but xorg-x11-drv package updates are usually fairly dull and not worth caring much about these days. I don't think you can use this update as a typical example of an xorg-x11-drv update. I'm sure ajax is considering whether this one is appropriate as an update. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
Hi Adam, On Dec 15, 2012 9:48 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. I'm confused. If this update breaks your system, why would you want us to move to it? No, the 2.20.14 which is in updates-testing isn't stable. From the changelog, the 2.20.16 looks like it has fixes for the issues reported for GM45. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, On Dec 16, 2012 2:30 AM, Sérgio Basto ser...@serjux.com wrote: On Dom, 2012-12-16 at 01:46 +0200, Ebru Arslan wrote: I am using Adlink cPCI 3970D board. and my system also include cPCI 3455 driver compatible just Fedora 14 32 bit. why is not compatible with newer Fedoras ? is the kernel ? There might be few drm fixes that are only available on recent kernels. -Ilyes so I dont have chance to use other revision. how can i fix this case? cPCI 3970D include intel HD 3000 i915 graphic chipset. and i am developing opengl programming. -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, Just testing the 2.20.16 release and everything looks good so far on GM45. -Ilyes On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto ser...@serjux.com wrote: On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and this platform using Intel HD 3000 i915 graphic. I install Base video mode. after that i dont achieve install intel driver. i need installation steps of xf86-video-intel 2.20.16 . libdrm version,X-server version, etc. also create problem when i make ./configure but i already updated Fedora 14 . When I want update packages I do custom rpms, and recently use mock (*) to build the packages. #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git #cd xorg-x11-drv-intel/ edit xorg-x11-drv-intel.spec change version to Version: 2.20.16 fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) and finally rpm -Uvh the build rpms if not have mock and fedpkg in F14 you could try rpmbuild -ba xorg-x11-drv-intel.spec ... (*) my notes to use mock http://www.serjux.com/alps/how_to_use_mock.txt On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Adam, On Dec 15, 2012 9:48 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. I'm confused. If this update breaks your system, why would you want us to move to it? No, the 2.20.14 which is in updates-testing isn't stable. From the changelog, the 2.20.16 looks like it has fixes for the issues reported for GM45. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
and performance (blt and blending, cairo-demos) is way better than the 2.20.10 and 2.20.14 releases. -Ilyes On Sun, Dec 16, 2012 at 10:47 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, Just testing the 2.20.16 release and everything looks good so far on GM45. -Ilyes On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto ser...@serjux.com wrote: On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and this platform using Intel HD 3000 i915 graphic. I install Base video mode. after that i dont achieve install intel driver. i need installation steps of xf86-video-intel 2.20.16 . libdrm version,X-server version, etc. also create problem when i make ./configure but i already updated Fedora 14 . When I want update packages I do custom rpms, and recently use mock (*) to build the packages. #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git #cd xorg-x11-drv-intel/ edit xorg-x11-drv-intel.spec change version to Version: 2.20.16 fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) and finally rpm -Uvh the build rpms if not have mock and fedpkg in F14 you could try rpmbuild -ba xorg-x11-drv-intel.spec ... (*) my notes to use mock http://www.serjux.com/alps/how_to_use_mock.txt On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Adam, On Dec 15, 2012 9:48 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. I'm confused. If this update breaks your system, why would you want us to move to it? No, the 2.20.14 which is in updates-testing isn't stable. From the changelog, the 2.20.16 looks like it has fixes for the issues reported for GM45. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, On Mon, Dec 17, 2012 at 12:27 AM, Tom London seli...@gmail.com wrote: I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. Sigh. Spoke too soon. Hang resurfaced. See: https://bugzilla.redhat.com/show_bug.cgi?id=877461 It still worth the update, IMHO. The 2.20.16 is just way better than the 2.20.10. As the gdm crash is still there, despite the 2.20.16 being the latest release, it might make sense to report the bug (with all the relevant information) directly on https://bugs.freedesktop.org/ -Ilyes tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, On Sun, Dec 16, 2012 at 9:44 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 16.12.2012 21:39, schrieb Tom London: I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. can we please have a koji-build? +1 i notice slow gui / hangs after running KDE fpr many hours on machines with VMware-Workstations guests in background which is a little bit strange on IvyBrdige machines with 16 GB RAM and RAID10 Sounds bleedin' 'n cuttin' egde! :) Please file a bug ! and let's have the 2.20.16 meanwhile, please! Cheers, -Ilyes after logout / login all is snappy again and note that the in the background running VMs are not touched - so this must be graphics related at all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCE] xf86-video-intel 2.20.16
Hey, Would it be possible to also push the xf86-video-intel-2.20.16 update to Fedora 16 (technically it's not EOL yet)? -Ilyes On Wed, Dec 19, 2012 at 5:45 PM, Ebru Arslan earslan2...@gmail.com wrote: i did like that but it doesnt work. I updated Fedora 14 32 bit. then i installed driver from intelligraphic.org. know Fedora 14 is start but after that stuck. On 12/18/12, Sérgio Basto ser...@serjux.com wrote: On Ter, 2012-12-18 at 10:39 +0200, Ebru Arslan wrote: libdrm revision is 2.2.22 but i configure 2.4.40. but system still see previous one. so my all autogen.sh working result is fail. Do the package for libdrm and upgrade with rpm -Uvh #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/libdrm.git #cd libdrm edit xorg-x11-drv-intel.spec change version to #rpmbuild -ba libdrm.spec rpm -Uvh packages built . -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ANNOUNCE] xf86-video-intel 2.20.16
Hi, On Sat, Dec 22, 2012 at 10:03 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hey, Would it be possible to also push the xf86-video-intel-2.20.16 update to Fedora 16 (technically it's not EOL yet)? I just ran a xorg-x11-drv-intel scratch build for f16 w/ the new xf86-video-intel-2.20.16 and the older intel-gpu-tools-20110817 snapshots and AFAICT it looks good: http://koji.fedoraproject.org/koji/taskinfo?taskID=4815120 Is it possible to have the update for Fedora 16? -Ilyes -Ilyes On Wed, Dec 19, 2012 at 5:45 PM, Ebru Arslan earslan2...@gmail.comwrote: i did like that but it doesnt work. I updated Fedora 14 32 bit. then i installed driver from intelligraphic.org. know Fedora 14 is start but after that stuck. On 12/18/12, Sérgio Basto ser...@serjux.com wrote: On Ter, 2012-12-18 at 10:39 +0200, Ebru Arslan wrote: libdrm revision is 2.2.22 but i configure 2.4.40. but system still see previous one. so my all autogen.sh working result is fail. Do the package for libdrm and upgrade with rpm -Uvh #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/libdrm.git #cd libdrm edit xorg-x11-drv-intel.spec change version to #rpmbuild -ba libdrm.spec rpm -Uvh packages built . -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Installing glib2-devel.i686 alongside glib2-devel.x86_64 on Fedora?
Hi, I'm attempting to build a software requiring glib2-devel.i686, however when attempting to yum install it, RPM generates a transaction error and states that few files from glib2-devel.i686 conflict w/the x86_64 flavor. The listed conflicting files seem related to gdb and systemtap (tools) integration, i.e not directly related to the glib2 core library. Is it at all possible to have both glib2-devel packages installed on the same machine? Regards, -Ilyes # yum install glib2-devel.i686 Loaded plugins: langpacks, presto Resolving Dependencies -- Running transaction check --- Package glib2-devel.i686 0:2.32.4-2.fc17 will be installed -- Processing Dependency: libelf.so.1(ELFUTILS_1.5) for package: glib2-devel-2.32.4-2.fc17.i686 -- Processing Dependency: libelf.so.1(ELFUTILS_1.0) for package: glib2-devel-2.32.4-2.fc17.i686 -- Processing Dependency: libelf.so.1 for package: glib2-devel-2.32.4-2.fc17.i686 -- Running transaction check --- Package elfutils-libelf.i686 0:0.154-2.fc17 will be installed -- Finished Dependency Resolution Dependencies Resolved = Package Arch VersionRepository Size = Installing: glib2-devel i686 2.32.4-2.fc17 updates 1.8 M Installing for dependencies: elfutils-libelf i686 0.154-2.fc17 updates 178 k Transaction Summary = Install 1 Package (+1 Dependent package) Total size: 2.0 M Installed size: 21 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Check Error: file /usr/bin/gdbus-codegen from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/glib-2.0/gdb/glib.pyc from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/glib-2.0/gdb/glib.pyo from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/glib-2.0/gdb/gobject.pyc from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/glib-2.0/gdb/gobject.pyo from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/systemtap/tapset/glib.stp from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 file /usr/share/systemtap/tapset/gobject.stp from install of glib2-devel-2.32.4-2.fc17.i686 conflicts with file from package glib2-devel-2.32.4-2.fc17.x86_64 Error Summary - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing glib2-devel.i686 alongside glib2-devel.x86_64 on Fedora?
Hi, On Thu, Dec 27, 2012 at 5:01 PM, Josh Stone jist...@redhat.com wrote: On 12/27/2012 05:30 AM, Ilyes Gouta wrote: Hi, I'm attempting to build a software requiring glib2-devel.i686, however when attempting to yum install it, RPM generates a transaction error and states that few files from glib2-devel.i686 conflict w/the x86_64 flavor. The listed conflicting files seem related to gdb and systemtap (tools) integration, i.e not directly related to the glib2 core library. Is it at all possible to have both glib2-devel packages installed on the same machine? This is a known issue - see: https://bugzilla.redhat.com/show_bug.cgi?id=718404 Alright, thanks for the references. -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wayland and broadway support in gtk
Yes, please! It would be about the right time to start enabling Wayland in distributions. -Ilyes On Thu, Jan 24, 2013 at 6:10 PM, Matthias Clasen mcla...@redhat.com wrote: Hi, I'm tentatively planning to enable the Wayland and Broadway backends in GTK+ for f19. From a quick test build, this adds 3 library dependencies to gtk (libwayland-client, libwayland-cursor and libxkbcommon), and the size of libgdk grows from ~550k to ~700k. I think this is not a terrible burden, and this will make it much easier to experiment with Wayland and Broadway in Fedora. Comments ? Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Intel's SU4100 support on Fedora 12
Hi, I own a laptop which has an Intel SU4100 (http://ark.intel.com/Product.aspx?id=43568), a dual core CPU and has 4 Gb of RAM. The Fedora 12 install DVD, picks up the PAE kernel for my machine while I expected a SMP, PAE enabled kernel instead. Is it possible to manually select such a kernel, during an install? Is it possible to change the kernel configuration so that the next yum update picks up the SMP enabled one? -Ilyes Gouta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel's SU4100 support on Fedora 12
Hi, while), it is detected at runtime. When installing the system, right? So it's done once? I believe grub has a static configuration which indicates the location of the kernel image. Also for this system I recommend using x86_64. I don't remember the installer giving me the choice between running a PAE 32bit kernel, or a x86_64 kernel on my machine. Thanks, -Ilyes Gouta On Mon, Apr 5, 2010 at 12:43 PM, drago01 drag...@gmail.com wrote: On Mon, Apr 5, 2010 at 1:39 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, I own a laptop which has an Intel SU4100 (http://ark.intel.com/Product.aspx?id=43568), a dual core CPU and has 4 Gb of RAM. The Fedora 12 install DVD, picks up the PAE kernel for my machine while I expected a SMP, PAE enabled kernel instead. Is it possible to manually select such a kernel, during an install? Is it possible to change the kernel configuration so that the next yum update picks up the SMP enabled one? We don't ship separate UP/SMP kernel anymore (and have not for a while), it is detected at runtime. Also for this system I recommend using x86_64. P.S: This is off topic on this list btw. you should ask such question on the fedora-list rather than fedora-devel-list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sched_autogroup interactivity patch for the desktop
Hi, http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kernel-Patch-That-Does-Wonders patch: http://marc.info/?l=linux-kernelm=128978361700898w=2 Can we have this patch back ported into the current kernel for Fedora 14 and possibly posted as an update? :) Would be wonderful! -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
Hi, According to phoronix, it would be queued for the 2.6.38 release. actually works. If you really want it, Fedora provides all the tools to build your own custom kernel package. It's already on my todo list :) -Ilyes On Tue, Nov 16, 2010 at 5:38 PM, Jason L Tibbitts III ti...@math.uh.eduwrote: IG == Ilyes Gouta ilyes.go...@gmail.com writes: IG Can we have this patch back ported into the current kernel for IG Fedora 14 and possibly posted as an update? :) IG Would be wonderful! Would be more wonderful to wait until the upstream development has actually finished before cramming it into our packages and hoping it actually works. If you really want it, Fedora provides all the tools to build your own custom kernel package. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
Thanks Kyle for making it available! -Ilyes On Tue, Nov 16, 2010 at 5:39 PM, Kyle McMartin k...@mcmartin.ca wrote: On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote: Can we have this patch back ported into the current kernel for Fedora 14 and possibly posted as an update? :) Would be wonderful! Try this, http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/ i686 coming whenever mock finishes. regards, Kyle. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
Hi Leenart, Dhaval Giani pointed out to me that the same can be done from userspace simply by creating a cgroup for each session in the cpu hierarchy. Turns So a session's (as you're referring) initiator to would be the terminal emulator process that has a virtual tty and systemd detect those and setup a proper cgroup so that we could differentiate when scheduling with other processes? -Ilyes On Tue, Nov 16, 2010 at 6:14 PM, Lennart Poettering mzerq...@0pointer.dewrote: On Tue, 16.11.10 16:58, Ilyes Gouta (ilyes.go...@gmail.com) wrote: Hi, http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kernel-Patch-That-Does-Wonders patch: http://marc.info/?l=linux-kernelm=128978361700898w=2 Can we have this patch back ported into the current kernel for Fedora 14 and possibly posted as an update? :) This appears completely backwards to me. Attaching things like this to a TTY is just wrong, because normally we don't have a single TTY around on most graphical sessions. The kernel doesn't really have a notion of what a session is (only the audit subsystem kinda has), but if this grouping behaviour is supposed to be bound to a session, then attaching it to a TTY is a pretty shitty replacement. Dhaval Giani pointed out to me that the same can be done from userspace simply by creating a cgroup for each session in the cpu hierarchy. Turns out systemd actually does pretty much that, except in the named systemd hierarchy. It is trivial modification to create a group in both hierarchies. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
Hi Kyle, I'm getting these while running kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/ http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/ [ 234.580039] BUG: sleeping function called from invalid context at mm/slub.c:1701 [ 234.580048] in_atomic(): 0, irqs_disabled(): 1, pid: 4272, name: gnome-terminal [ 234.580054] Pid: 4272, comm: gnome-terminal Not tainted 2.6.35.8-59.xsched1.fc14.x86_64 #1 [ 234.580058] Call Trace: [ 234.580070] [8103d03d] __might_sleep+0xed/0xef [ 234.580079] [811096b8] kmem_cache_alloc_notrace+0x37/0xb2 [ 234.580085] [8104af89] sched_autogroup_create_attach+0x26/0xe1 [ 234.580092] [812a21e0] __proc_set_tty+0x10d/0x116 [ 234.580098] [812a39be] tty_ioctl+0x3fc/0x7c5 [ 234.580103] [811244d7] vfs_ioctl+0x32/0xa6 [ 234.580108] [81124a34] do_vfs_ioctl+0x46d/0x4a6 [ 234.580112] [81124ac3] sys_ioctl+0x56/0x79 [ 234.580119] [81009c72] system_call_fastpath+0x16/0x1b -Ilyes On Tue, Nov 16, 2010 at 5:42 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Thanks Kyle for making it available! -Ilyes On Tue, Nov 16, 2010 at 5:39 PM, Kyle McMartin k...@mcmartin.ca wrote: On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote: Can we have this patch back ported into the current kernel for Fedora 14 and possibly posted as an update? :) Would be wonderful! Try this, http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/ i686 coming whenever mock finishes. regards, Kyle. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sched_autogroup interactivity patch for the desktop
Hi, I've been reading http://lkml.org/lkml/2010/11/16/402 and actually Lennart has put some solid thoughts and arguments there and IMHO it was *somehow* pretty convincing that this should be done at user-space, in conjunction with tools such as systemd, albeit introducing more complexity in form of configuration infrastructure and whatnot. Having this being done automatically by the kernel looks really easy and yet promising. The downside of it is that it just feels like it's something rigged towards a special class of applications (TTY based, build jobs) and would act behind the scene without user-space knowing (explicitly) about this classification, cgroups being spawned and subtasks associated to them. Still, It would be nice to have this differentiation in place, being implemented in either forms, since it brings a certain win for the desktop user and developer. I think having a term open for churning code is part (or a possible user-case) of the desktop experience :) -Ilyes 2010/11/17 Michał Piotrowski mkkp...@gmail.com Hi, 2010/11/16 Ilyes Gouta ilyes.go...@gmail.com: Hi, http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kernel-Patch-That-Does-Wonders patch: http://marc.info/?l=linux-kernelm=128978361700898w=2 Can we have this patch back ported into the current kernel for Fedora 14 and possibly posted as an update? :) Let me guess - Canonical already announced (or will do so within the next few hours) that they will use this patch in the new Ubuntu :) Would be wonderful! Surely this would be -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backported gtk3 for F14 available
On Sun, Feb 13, 2011 at 11:56 PM, drago01 drag...@gmail.com wrote: On Thu, Feb 10, 2011 at 10:28 PM, Matthias Clasen mcla...@redhat.com wrote: On Thu, 2011-02-10 at 19:30 +0100, Kevin Kofler wrote: [...] Interesting idea. Note that I've _just_ released the stable GTK+ 3.0.0. We could think about updating the gtk3 package in F14 to 3.0.0 if that is useful for people. We had essentially abandoned this and a few other packages in F14 after GNOME 3 was delayed to F15, and nothing in the repo should depend on it... Well mutter and gnome-shell do. -- Yes, please! devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PackageKit in Fedora 15 (beta)
Hi, Removing PackageKit In Fedora 14 was easy and painless since it causes up to 5 packages, all *really* related to PackageKit in the form of a yum-plugin and few other things. On Fedora 15, trying to yum remove PackageKit causes the system to attempt removing up to 74 MB worth of software, including gdm, empathy, bluez and gnome-shell Which is pointless. Is it *really* required to have PackageKit so deeply integrated and made an essential package on the system. AFAIK, it's essentially a helper and a front-end for yum, right? Is it possible to recover Fedora 14's lightweight dependencies set, for PackageKit? Thanks, -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
Hi, I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263 https://bugzilla.redhat.com/show_bug.cgi?id=699263-Ilyes On Sun, Apr 24, 2011 at 7:12 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 24.04.2011 20:04, schrieb Ilyes Gouta: Hi, Removing PackageKit In Fedora 14 was easy and painless since it causes up to 5 packages, all *really* related to PackageKit in the form of a yum-plugin and few other things. On Fedora 15, trying to yum remove PackageKit causes the system to attempt removing up to 74 MB worth of software, including gdm, empathy, bluez and gnome-shell Which is pointless. Is it *really* required to have PackageKit so deeply integrated and made an essential package on the system. AFAIK, it's essentially a helper and a front-end for yum, right? Is it possible to recover Fedora 14's lightweight dependencies set, for PackageKit? Thanks, -Ilyes generellay the dependecies are getting bigger with every release it should be possible to install a leightweigt system yes, hard-disk are getting cheaper but time! on the other hand running 20-30 Fedora VMs on a SAN-Storage disk space is not so cheap as at home and the overhead multiplies means: i like to remove everything that is not active used because distupgrades and normal updates are much bigger and especially on servers everything which is not installed is not vulnerable -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
Hi Rahul, It isn't a feature that is driven by Fedora and hence it won't be in the feature list. It is just what happens when more upstream software take advantage of it over time.. Yes, NOW it's clear! Thanks Rahul! -Ilyes On Sun, Apr 24, 2011 at 8:16 PM, Rahul Sundaram methe...@gmail.com wrote: On 04/25/2011 12:36 AM, Ilyes Gouta wrote: Rahul, If you aren't actively using the GNOME or KDE frontend, just remove those and leave the framework as it is. That was tough :) AFAIK (and I might be wrong) deep PacakgeKit integration wasn't clearly mentioned in Fedora 15's feature set list. It isn't a feature that is driven by Fedora and hence it won't be in the feature list. It is just what happens when more upstream software take advantage of it over time.. I was just asking if it was possible to recover to a situation where the user would still have the choice, to use or not use PackageKit. That's all. Fedora 14 gave that choice. Alright, thanks for explaining! Just leave it installed. You don't have to use it. That is still a choice. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
Hi Matej, Christoph Wickert provided an analysis in https://bugzilla.redhat.com/show_bug.cgi?id=699263 -Ilyes On Mon, Apr 25, 2011 at 8:19 PM, Matej Cepl mc...@redhat.com wrote: Dne 25.4.2011 10:35, Rahul Sundaram napsal(a): You can [...] remove PackageKit-yum-plugin. Unfortunately not ... it takes away (among other things bluez, control-center, gammu, gdm, gnome-bluetooth, orca, and gnome-shell). Anybody any ideas how to get rid of it? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
Hi Matěj, Ceterum autem censeo, Carthaginem esse delendam. So this is Latin, what does it mean? Btw, I'm from Tunisia (Tunis), the country of Carthage (historically) ;) -Ilyes On 26 avr. 2011, at 06:57, Matej Cepl mc...@redhat.com wrote: Dne 25.4.2011 21:26, Ilyes Gouta napsal(a): Christoph Wickert provided an analysis in https://bugzilla.redhat.com/show_bug.cgi?id=699263 Which again lead to my broken gramophone song … we suck for not having Suggests/Recommends. Ceterum autem censeo, Carthaginem esse delendam. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 and Sandy Bridge graphics
Hi Reindl, You could also build it from sources. You should already have the latest kernel and the X server updates, compiling the intel driver will then produce a couple of user-space shared libraries that you can place in /usr/lib64/xorg/modules/drivers. That's it. -Ilyes 2011/6/12 Reindl Harald h.rei...@thelounge.net: Am 12.06.2011 19:14, schrieb Lucas: On 06/12/2011 09:12 PM, Reindl Harald wrote: Look, to be able to use Sandy Bridge you need - i915 driver, kernel, and Xorg. You can add Fedora 15 repository and update only kernel, Xorg and intel driver. All of this you can download from koji and install manually. i tried this before my first post this is simply not true because this forces glibc as requirement -- Führe Transaktionsprüfung aus --- Paket kernel.x86_64 0:2.6.38.8-31.fc15 markiert, um installiert zu werden --- Paket kernel-devel.x86_64 0:2.6.38.8-31.fc15 markiert, um installiert zu werden --- Paket kernel-headers.x86_64 0:2.6.38.8-31.fc15 markiert, um aktualisiert zu werden --- Paket libdrm.x86_64 0:2.4.25-1.fc15 markiert, um aktualisiert zu werden --- Paket linux-firmware.noarch 0:20110601-1.fc15 markiert, um aktualisiert zu werden --- Paket xorg-x11-drv-intel.x86_64 0:2.14.0-6.fc15 markiert, um aktualisiert zu werden -- Verarbeite Abhängigkeiten: libc.so.6(GLIBC_2.14)(64bit) für Paket: xorg-x11-drv-intel-2.14.0-6.fc15.x86_64 --- Paket xorg-x11-server-Xorg.x86_64 0:1.10.1-14.fc15 markiert, um aktualisiert zu werden -- Verarbeite Abhängigkeiten: libc.so.6(GLIBC_2.14)(64bit) für Paket: xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64 --- Paket xorg-x11-server-common.x86_64 0:1.10.1-14.fc15 markiert, um aktualisiert zu werden -- Abhängigkeitsauflösung beendet Fehler: Package: xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64 (/xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64) Requires: libc.so.6(GLIBC_2.14)(64bit) Fehler: Package: xorg-x11-drv-intel-2.14.0-6.fc15.x86_64 (/xorg-x11-drv-intel-2.14.0-6.fc15.x86_64) Requires: libc.so.6(GLIBC_2.14)(64bit) Sie können versuchen --skip-broken zu benutzen, um das Problem zu umgehen. You could try running: rpm -Va --nofiles --nodigest [root@rh:/downloads]$ ls insgesamt 40M drwxr-xr-x 16 harry verwaltung 4,0K 2011-06-09 10:58 teletest -rw-r--r-- 1 harry verwaltung 23M 2011-06-12 19:17 kernel-2.6.38.8-31.fc15.x86_64.rpm -rw-r--r-- 1 harry verwaltung 6,8M 2011-06-12 19:17 kernel-devel-2.6.38.8-31.fc15.x86_64.rpm -rw-r--r-- 1 harry verwaltung 739K 2011-06-12 19:16 kernel-headers-2.6.38.8-31.fc15.x86_64.rpm -rw-r--r-- 1 root root 69K 2011-04-15 05:54 libdrm-2.4.25-1.fc15.x86_64.rpm -rw-r--r-- 1 harry verwaltung 8,3M 2011-06-12 19:17 linux-firmware-20110601-1.fc15.noarch.rpm -rw-r--r-- 1 root root 202K 2011-04-28 19:13 xorg-x11-drv-intel-2.14.0-6.fc15.x86_64.rpm -rw-r--r-- 1 root root 77K 2011-05-05 22:55 xorg-x11-server-common-1.10.1-14.fc15.x86_64.rpm -rw-r--r-- 1 root root 1,4M 2011-05-05 22:52 xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64.rpm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
About packaging Zotero standalone for Fedora
Hi, Zotero is a referencing tool that helps the user collecting, maintaining and generating citations from research papers and so on. Since version 3.0, Zotero has also been available as a standalone executable (previously a Firefox plugin) based on the XULRunner runtime; and I'm thinking about packaging it for Fedora. The code base is licensed under AGPLv3, however the program's name 'Zotero' is a registered trademark (http://www.zotero.org/support/terms/trademark) I asked the developers (http://forums.zotero.org/discussion/23104/packaging-zotero-for-gnulinux-distributions/#Item_0) if it was OK to use that same name (even if the source package ends up slightly changed - mostly the build system actually), but then here I am asking the same question in order to get more feedback from the Fedora packaging community: What's the position of Fedora regarding using the same trademarked program names for the packages? This case would look similar to the Firefox package and I'm interested in understanding how this is handled in Fedora. Thanks, -Ilyes P.S: I'm already a Fedora packager. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
About packaging Zotero (trademarked name) standalone for Fedora (was: About packaging Zotero standalone for Fedora)
Hi, I'm reposting this e-mail, slightly edited and with a much more clear subject, highlighting the issue. Hi, Zotero is a referencing tool that helps the user collecting, maintaining and generating citations from research papers and so on. Since version 3.0, Zotero has also been available as a standalone executable (previously a Firefox plugin) based on the XULRunner runtime; and I'm thinking about packaging it for Fedora. The code base is licensed under AGPLv3, however the program's name 'Zotero' is a registered trademark (http://www.zotero.org/support/terms/trademark) I asked the developers (http://forums.zotero.org/discussion/23104/packaging-zotero-for-gnulinux-distributions/#Item_0) if it was OK to use that same name (even if the source package ends up slightly changed - mostly the build system actually), but then here I am asking the same question in order to get more feedback from the Fedora packaging community: What's the position of Fedora regarding using the same trademarked program names (even if the source code is under an open source license) ? This case would look similar to the Firefox package and I'm interested in understanding how this is handled in Fedora. Thanks, -Ilyes P.S: I'm already a Fedora packager. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About packaging Zotero (trademarked name) standalone for Fedora (was: About packaging Zotero standalone for Fedora)
Hi, Thanks Rex for the heads up :) Yes, the goal is to just package the software, the source code won't likely be changed - so it wouldn't constitute a derivative work (in the sense of a forked source code). @Toshio : Are there specific trademark licensing terms? I think we'd want to know what those are. And if they're too onerous (Personally, I'd rather not have more software that was as restrictive as firefox) we'd probably want to change the name/other trademarked assets. http://www.zotero.org/support/terms/trademark It's explained in that page that the trademark should be explicitly and specifically licensed (in writing from George Mason University) if used alongside any derivative work; which isn't the case in this effort as the goal is to just package that same software. Zotero developer Simon Kornblith confirmed that it would be OK (see http://forums.zotero.org/discussion/23104/packaging-zotero-for-gnulinux-distributions/#Item_0). Alright, I'm then proceeding with the packaging. -Ilyes On Mon, Apr 30, 2012 at 2:24 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Apr 30, 2012 at 07:47:32AM -0500, Rex Dieter wrote: Ilyes Gouta wrote: What's the position of Fedora regarding using the same trademarked program names (even if the source code is under an open source license) ? There's lots of software in fedora already with names that are trademarked, so that alone is no cause for concern. Are there specific trademark licensing terms? I think we'd want to know what those are. And if they're too onerous (Personally, I'd rather not have more software that was as restrictive as firefox) we'd probably want to change the name/other trademarked assets. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About packaging Zotero (trademarked name) standalone for Fedora (was: About packaging Zotero standalone for Fedora)
Hi, On Mon, Apr 30, 2012 at 5:31 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Apr 30, 2012 at 02:51:52PM +0100, Ilyes Gouta wrote: Alright, I'm then proceeding with the packaging. I've opened this ticket with the Fedora Packaging Committee. I don't know that it belongs there but next time we meet we'll discuss it and send it to a different group if that's what we decide needs to happen: https://fedorahosted.org/fpc/ticket/170 Thanks Toshio for the extensive explanations! Yes, this is exactly the kind of information I'm looking for. Don't let this stop you from starting to package this. The worst case scenario would be that you'd need to replace the trademarked name in the software when we build it and name the package something different. And that's the worst case... there's other possible outcomes as well. Let's see how it goes with the FPC, that's important. I'm thinking about Zoterino as a fallback name for the software/package; if it happens that embedding a trademarked name isn't possible/desirable. -Ilyes -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About packaging Zotero (trademarked name) standalone for Fedora (was: About packaging Zotero standalone for Fedora)
Hi, On Mon, Apr 30, 2012 at 8:00 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Mon, Apr 30, 2012 at 5:31 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Apr 30, 2012 at 02:51:52PM +0100, Ilyes Gouta wrote: Alright, I'm then proceeding with the packaging. I've opened this ticket with the Fedora Packaging Committee. I don't know that it belongs there but next time we meet we'll discuss it and send it to a different group if that's what we decide needs to happen: https://fedorahosted.org/fpc/ticket/170 Thanks Toshio for the extensive explanations! Yes, this is exactly the kind of information I'm looking for. Don't let this stop you from starting to package this. The worst case scenario would be that you'd need to replace the trademarked name in the software when we build it and name the package something different. And that's the worst case... there's other possible outcomes as well. Let's see how it goes with the FPC, that's important. In fact, having a clear and formal answer (a yes or a no) from the FPC and/or FESCo would be best. -Ilyes I'm thinking about Zoterino as a fallback name for the software/package; if it happens that embedding a trademarked name isn't possible/desirable. -Ilyes -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to obtain the latest rawhide mesa package via Fedora's scm?
Hi, I read a recent Fedora rawhide report and found that mesa is now at 8.1 (master @ upstream), but then couldn't fetch the Fedora branch using fedpkg, as I usually do. $ fedpkg switch-branch f17(OK) $ fedpkg switch-branch master(OK, still has the mesa-20120424 snapshot) $ fedpkg switch-branch f18(NOK, doesn't exist yet) mesa-8.1-0.2.fc18 - * Thu Apr 26 2012 Adam Jackson a...@redhat.com 8.1-0.2 - Don't build vmware stuff on non-x86 (#815444) Any pointers on how to get that update? I intend to build it locally as I'm also testing Wayland master; which now requires new symbols from gbm, such as gbm_surface_lock_front_buffer() and gbm_bo_get_format(). Thanks, -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to obtain the latest rawhide mesa package via Fedora's scm?
The .spec file clearly states Version 8.1, sorry for the noise. -Ilyes On Tue, May 1, 2012 at 12:22 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, I read a recent Fedora rawhide report and found that mesa is now at 8.1 (master @ upstream), but then couldn't fetch the Fedora branch using fedpkg, as I usually do. $ fedpkg switch-branch f17 (OK) $ fedpkg switch-branch master (OK, still has the mesa-20120424 snapshot) $ fedpkg switch-branch f18 (NOK, doesn't exist yet) mesa-8.1-0.2.fc18 - * Thu Apr 26 2012 Adam Jackson a...@redhat.com 8.1-0.2 - Don't build vmware stuff on non-x86 (#815444) Any pointers on how to get that update? I intend to build it locally as I'm also testing Wayland master; which now requires new symbols from gbm, such as gbm_surface_lock_front_buffer() and gbm_bo_get_format(). Thanks, -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
TextMate 2 open sourced!
Hi, http://blog.macromates.com/2012/textmate-2-at-github/ TextMate 2 is (for now) placed under GPL3. Source code is available at github: https://github.com/textmate/textmate How about packaging it for Fedora? -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TextMate 2 open sourced!
On Fri, Aug 10, 2012 at 12:30 AM, Onuralp SEZER
thunderbir...@fedoraproject.org wrote:
Well , When check https://github.com/textmate/textmate#prerequisites
From the few prerequisites, it looks like it's doable.
I'm not sure about the Objective-C and Cocoa bits .. Maybe they can be ported?
-Ilyes
in here. Just we need packages and It can be compile it. And If It's become
open-source just MAC OSX. Yes then you right It won't be compile because of
OS X's Cocoa
On 10 August 2012 02:25, Ilyes Gouta ilyes.go...@gmail.com wrote:
The Frameworks/Oak* code looks like it calls to few routines written
in Objective-C (and probably to few OS X API) ..
Is the code base build-able for Linux (assuming no big dependencies on
OS X's Cocoa)?
-Ilyes
On Thu, Aug 9, 2012 at 10:38 PM, Onuralp SEZER
thunderbir...@fedoraproject.org wrote:
Well I did chnages in the files but problem is still going and errors is
still same.
On 9 August 2012 23:27, Onuralp SEZER thunderbir...@fedoraproject.org
wrote:
Let me try then I will get backup and I'm going to try now.
On 9 August 2012 23:26, Kellerman Rivero Suarez krsl...@gmail.com
wrote:
I correct my previous email, the type __ int128 apparently not
recognized
by GCC, or so I understand, I think there will be that to try and
replace it
with __ int128_t
2012/8/9 Kellerman Rivero Suarez krsl...@gmail.com
Most problems seem to be associated with int_128. In gcc version most
appropriate for that type of data is int_128_t. You'll have to rename
the
sources to see if it works
2012/8/9 Onuralp SEZER thunderbir...@fedoraproject.org
Well I downloaded from git-hub and try to compile but It said ;
[root@fedora17 textmate]# ./configure
which: invalid option -- 's'
which: no xcrun in
(/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/onuralp/chromiumos/depot_tools:/home/onuralp/.cabal/bin:/home/onuralp/.xmonad/bin:/home/onuralp/.local/bin:/home/onuralp/bin:/home/onuralp/chromiumos/depot_tools:/home/onuralp/.cabal/bin:/home/onuralp/.xmonad/bin:/root/.cabal/bin)
clang is too old to build this project.
Please see README.md for build instructions.
So then I tried get new clang 3.2 version from source, and I got
this
error now ;
[root@fedora17 build]# make
make[1]: Entering directory `/home/onuralp/build/lib/Support'
llvm[1]: Compiling APFloat.cpp for Debug+Asserts build
In file included from /home/onuralp/llvm/lib/Support/APFloat.cpp:15:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APFloat.h:104:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APInt.h:18:
In file included from
/home/onuralp/llvm/include/llvm/ADT/ArrayRef.h:13:
In file included from
/home/onuralp/llvm/include/llvm/ADT/SmallVector.h:24:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iterator:63:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
In file included from /home/onuralp/llvm/lib/Support/APFloat.cpp:15:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APFloat.h:104:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APInt.h:20:
In file included from
/home/onuralp/llvm/include/llvm/Support/MathExtras.h:17:
In file included from
/home/onuralp/llvm/include/llvm/Support/SwapByteOrder.h:20:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27:
error:
use of undeclared identifier '__int128'; did you mean
'__int128_t'?
struct numeric_limits__int128
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:36:
error:
expected ''
struct numeric_limitsunsigned __int128
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1478:5:
error:
cannot combine with previous '(error)' declaration specifier
struct numeric_limitsunsigned __int128
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0
Re: TextMate 2 open sourced!
Maybe this is when we should bring in GNUstep as the alternate Cocoa API
implementation for UNIX/Linux.
-Ilyes
On Aug 10, 2012 12:53 AM, Onuralp SEZER thunderbir...@fedoraproject.org
wrote:
From the few prerequisites, it looks like it's doable.
+1 for that .
I'm not sure about the Objective-C and Cocoa bits .. Maybe they can be
ported?
I never ported OS X apps so We need check source and Cocoa syntax for
making sure.
On 10 August 2012 02:45, Ilyes Gouta ilyes.go...@gmail.com wrote:
On Fri, Aug 10, 2012 at 12:30 AM, Onuralp SEZER
thunderbir...@fedoraproject.org wrote:
Well , When check https://github.com/textmate/textmate#prerequisites
From the few prerequisites, it looks like it's doable.
I'm not sure about the Objective-C and Cocoa bits .. Maybe they can be
ported?
-Ilyes
in here. Just we need packages and It can be compile it. And If It's
become
open-source just MAC OSX. Yes then you right It won't be compile
because of
OS X's Cocoa
On 10 August 2012 02:25, Ilyes Gouta ilyes.go...@gmail.com wrote:
The Frameworks/Oak* code looks like it calls to few routines written
in Objective-C (and probably to few OS X API) ..
Is the code base build-able for Linux (assuming no big dependencies on
OS X's Cocoa)?
-Ilyes
On Thu, Aug 9, 2012 at 10:38 PM, Onuralp SEZER
thunderbir...@fedoraproject.org wrote:
Well I did chnages in the files but problem is still going and
errors is
still same.
On 9 August 2012 23:27, Onuralp SEZER
thunderbir...@fedoraproject.org
wrote:
Let me try then I will get backup and I'm going to try now.
On 9 August 2012 23:26, Kellerman Rivero Suarez krsl...@gmail.com
wrote:
I correct my previous email, the type __ int128 apparently not
recognized
by GCC, or so I understand, I think there will be that to try and
replace it
with __ int128_t
2012/8/9 Kellerman Rivero Suarez krsl...@gmail.com
Most problems seem to be associated with int_128. In gcc version
most
appropriate for that type of data is int_128_t. You'll have to
rename
the
sources to see if it works
2012/8/9 Onuralp SEZER thunderbir...@fedoraproject.org
Well I downloaded from git-hub and try to compile but It said ;
[root@fedora17 textmate]# ./configure
which: invalid option -- 's'
which: no xcrun in
(/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/onuralp/chromiumos/depot_tools:/home/onuralp/.cabal/bin:/home/onuralp/.xmonad/bin:/home/onuralp/.local/bin:/home/onuralp/bin:/home/onuralp/chromiumos/depot_tools:/home/onuralp/.cabal/bin:/home/onuralp/.xmonad/bin:/root/.cabal/bin)
clang is too old to build this project.
Please see README.md for build instructions.
So then I tried get new clang 3.2 version from source, and I got
this
error now ;
[root@fedora17 build]# make
make[1]: Entering directory `/home/onuralp/build/lib/Support'
llvm[1]: Compiling APFloat.cpp for Debug+Asserts build
In file included from
/home/onuralp/llvm/lib/Support/APFloat.cpp:15:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APFloat.h:104:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APInt.h:18:
In file included from
/home/onuralp/llvm/include/llvm/ADT/ArrayRef.h:13:
In file included from
/home/onuralp/llvm/include/llvm/ADT/SmallVector.h:24:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iterator:63:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38:
error:
use of undeclared identifier '__ATOMIC_ACQ_REL'
{ __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
In file included from
/home/onuralp/llvm/lib/Support/APFloat.cpp:15:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APFloat.h:104:
In file included from
/home/onuralp/llvm/include/llvm/ADT/APInt.h:20:
In file included from
/home/onuralp/llvm/include/llvm/Support/MathExtras.h:17:
In file included from
/home/onuralp/llvm/include/llvm/Support/SwapByteOrder.h:20:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27:
error
Re: TextMate 2 open sourced!
Hi, In other words,should we have to push this package into fedora?(if build successfully?) Building TM2's code base for Linux is the most difficult part of the effort; as it (may) involve interacting with many bleeding-edge s/w components such as clang, Objective-C, and probably GNUstep for the Oak framework thing. Once there, packaging it for Fedora is easy, as dependencies would have been sorted out already. It's nice to see clang and llvm being required by another package besides mesa-dri :) -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TextMate 2 open sourced!
Hi, While gedit is nice, it is a GTK+ app. Do we actually have a decent selection of open source text editors for the GNUStep environment? As far as I know, we don't. TextMate would target a different group of people, those who use the NeXTSTEP/GNUStep environment. Ehm, ... does anybody really care about GNUStep anymore? I mean really ... it has absolutely awesome design (persistent objects are cool) but does anybody care? In whole bruhaha around Gnome 3, I have never heard anybody to say I hate Gnome 3, so I am switching to GNUStep. Well, IMHO besides the less is more philosophy (which is good too), the major risk is clang. Is Fedora ready to host clang compiled and linked binaries (and libraries)? Do we also need GNUstep compiled via clang for TextMate to build? Are clang and GCC binaries inter-operable (when linked against the same run-time libraries)? -Ilyes Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
Hi Gerry, Try contacting the main dev. mailing-list of DirectFB. I'm sure you'll get an answer there. Btw, DirectFB-1.5.3 is rather old, DirectFB-1.6.1 is rather the latest stable release. -Ilyes On Aug 28, 2012 1:04 AM, Gerry Reno gr...@verizon.net wrote: On 08/24/2012 06:56 PM, Gerry Reno wrote: I have had no success whatsoever getting DirectFB to run under F17 as a regular user on my HP laptop. # yum list DirectFB Installed Packages directfb.x86_64 1.5.3-7.fc17 @updates I have discussed the problems on the DirectFB mailing list and they direct me back to the distro. When trying to run any DirectFB command as a regular user I get permission errors like this: $ dfbinfo ~~| DirectFB 1.5.3 |~~ (c) 2001-2010 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2012-05-19 15:35) (*) Direct/Memcpy: Using Generic 64bit memcpy() (!) DirectFB/core/vt: Error opening `/dev/tty1'! -- Permission denied (!) DirectFB/Core: Could not initialize 'system_core' core! -- A general initialization error occured (#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured Even when I go and change the permissions on /dev/ttyX and /dev/fb/0 and then put those into udev rules then I still get an error about MEDIUMRAW mode. I am able to run some DirectFB commands as root but that is no good for creating app for general user. Can anyone, developer, packager, shed some light on why DirectFB will not run on F17 as a regular user? Thank you. . So after fixing permissions on tty and fb I can get to here: $ dfbinfo ~~| DirectFB 1.5.3 |~~ (c) 2001-2010 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2011-08-23 22:08) (!) DirectFB/fbdev/vt: K_MEDIUMRAW failed! -- Operation not permitted (!) DirectFB/Core: Could not initialize 'system_core' core! -- A general initialization error occured (#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured $ What needs to be done to fix this error? Google is absolutely no help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
Gerry, You could also use DirectFB's X11 system module, so that you can run DirectFB-based applications in a usual X11 window. You can tell DirectFB so by using the DFBARGS environment variable: $ export DFBARGS=system=x11,mode=1280x800 (probably also w/ disable-module=gl) $./your_directfb_application Nicolas Chauvet is now upstreaming changes for Fedora to directfb-dev ML. -Ilyes On Wed, Aug 29, 2012 at 8:29 PM, Gerry Reno gr...@verizon.net wrote: On 08/29/2012 02:33 PM, Tom Callaway wrote: On 08/29/2012 09:25 AM, Gerry Reno wrote: DirectFB says that there are Fedora packaging errors which are causing the undefined symbol on XUnlockDisplay and inability to run as normal user. Upstream is wrong, btw. The dlopen problem is caused by the fact that they don't pass the $(X11VDPAU_LIBS) to the LDFLAGS for linking libdirectfb_vdpau.la. The core issue behind why dfbinfo doesn't run as a normal user is due to the fact that the Linux kernel requires CAP_SYS_TTY_CONFIG to do any TTY ioctl() calls. UID 0 (root) has that, but normal users do not. It is possible to give a binary that capability using the setcap command. The missing udev rules also factor into this, I suspect. Last but not least, I believe a normal user needs to be in at least the tty and video groups. (and they need to be active, as reported by `groups`). Since there is no real way to handle this in the package, it just needs to be done by any user who wants to use dfbinfo: usermod -a -G tty video USERNAME I made an updated package (1.6.1) that has these fixes applied and sets the CAP_SYS_TTY_CONFIG capability to the dfbinfo binary. (Other DirectFB binaries probably need the same magic, but as I am not a DirectFB user, I can't really say which ones.) Please note that I could only get the dfbinfo results as an unprivileged user from the console (not from within X), and those results are not identical to what I get when I run it as root. When I tried to run it from X, my X session crashed and the kernel panicked. Good times. :) Anyways, Gerry, please test and let me know if these packages work for you, and once I hear back, I'll push out updates. http://koji.fedoraproject.org/koji/taskinfo?taskID=4435408 ~tom == Fedora Project Thanks Tom. I'll try to check your updates later today and report back. Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
use of undeclared identifier '__ATOMIC_ACQ_REL' when building llvm-3.1 on Fedora 17
Hi,
I'm getting the following errors, when attempting to build llvm-3.1
(from f18) on my Fedora 17 setup.
In file included from APInt.cpp:16:
In file included from
/home/ilyes/fedora-scm/llvm/llvm-3.1.src/include/llvm/ADT/APInt.h:18:
In file included from
/home/ilyes/fedora-scm/llvm/llvm-3.1.src/include/llvm/ADT/ArrayRef.h:13:
In file included from
/home/ilyes/fedora-scm/llvm/llvm-3.1.src/include/llvm/ADT/SmallVector.h:23:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iterator:63:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45:
error: use of undeclared identifier '__ATOMIC_ACQ_REL'
{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38:
error: use of undeclared identifier '__ATOMIC_ACQ_REL'
{ __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
I've got also a bunch of these:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/limits:1404:27:
error: use of undeclared identifier '__int128'; did you mean
'__int128_t'?
and this is with gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC).
Any ideas on how to fix this? Do I need an updated GCC?
Regards,
-Ilyes
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use of undeclared identifier '__ATOMIC_ACQ_REL' when building llvm-3.1 on Fedora 17
Hi,
I've locally built and installed Fedora 18's GCC 4.7.1 packages (gcc
version 4.7.1 20120720 (Red Hat 4.7.1-5) (GCC)) on my F17 box and just
restarted building (F18's) llvm-3.1/clang-3.1 packages. It looks good
so far.
-Ilyes
On Sun, Sep 2, 2012 at 3:30 AM, TASAKA Mamoru mtas...@fedoraproject.org wrote:
Ilyes Gouta wrote, at 09/01/2012 11:06 PM +9:00:
Hi,
I'm getting the following errors, when attempting to build llvm-3.1
(from f18) on my Fedora 17 setup.
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/iterator:63:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:39:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ios:42:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:40:
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:48:45:
error: use of undeclared identifier '__ATOMIC_ACQ_REL'
{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ext/atomicity.h:52:38:
error: use of undeclared identifier '__ATOMIC_ACQ_REL'
{ __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
This issue is currently tracked on:
https://bugzilla.redhat.com/show_bug.cgi?id=845713
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use of undeclared identifier '__ATOMIC_ACQ_REL' when building llvm-3.1 on Fedora 17
Hi Lars, Indeed! I removed an older clang-3.0 package before rebuilding the f18 set. Cool. The builds should now complete then. -Ilyes On Sun, Sep 2, 2012 at 10:29 AM, Lars Seipel lars.sei...@gmail.com wrote: On Saturday 01 September 2012 15:06:40 Ilyes Gouta wrote: and this is with gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC). This doesn't look like you're building with GCC. Do you have an older version of clang somewhere in your path? IIRC llvm's configure script prefers to choose clang when it's there. Clang then chokes on the libstdc++ headers. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building and exporting libgbm from the mesa package
Hi, This is to reboot the discussion about: why not also building the libgbm part of Mesa in Fedora? Having it would make it easier to test Wayland and friends. Any reasons on why not having it so far? -Ilyes On Sat, Dec 3, 2011 at 9:49 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, Any reasons on why libgbm isn't being built and packaged in the current mesa SPEC file? libgbm is a dependency for wayland-demos. The --enable-gbm configure option depends on --enable-shared-glapi. Is there any constraint? -Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building and exporting libgbm from the mesa package
Cool! That's what I want to be part of, too :) Could these be installed on a Fedora 16? Thanks, -Ilyes On Fri, Feb 24, 2012 at 10:16 PM, Adam Jackson a...@redhat.com wrote: On Fri, 2012-02-24 at 21:28 +0100, Ilyes Gouta wrote: This is to reboot the discussion about: why not also building the libgbm part of Mesa in Fedora? Having it would make it easier to test Wayland and friends. Any reasons on why not having it so far? Thorsten Leemhuis has very graciously stepped up to bring F17's Mesa and Wayland packaging up to date: https://admin.fedoraproject.org/updates/FEDORA-2012-2244/mesa-8.0.1-2.fc17,wayland-0.85.0-1.fc17 It was great, he showed up with patches and I said yeah those look fine and then he committed them. I wish I got more drive-by contributions like that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packaging Google Font Directory for Fedora 14
Hi, Google released a set of high quality fonts as open source and I'm wondering of those can be packaged and included for/in the next Fedora 14. Would that be possible? http://code.google.com/p/googlefontdirectory/ -Ilyes Gouta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Hey Lennart, So how fast is a systemd boot (with all the changes to the scripts) compared to the current F13 setup? How about a ratio? -Ilyes Gouta On Sat, May 22, 2010 at 11:40 PM, Rahul Sundaram methe...@gmail.com wrote: On 05/23/2010 04:04 AM, Lennart Poettering wrote: ATM everything looks rosy. I just finished porting over all F13 installed-by-default daemons to socket activation, and a few more (and the patches are good enough to be upstreamable). I'll publish the numbers of a 100% socket-activated boot soon. Codewise only very little is missing to be fully ready for Fedora (in fact selinux support is the only item really mattering on my todo list). It would great to have a repo or something to try it out quickly and provide some feedback. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi,
SSE and friends are arch. specific and according to the feature list
the upstream is displaying, I don't think it would offer any other
benefits for the other archs.
There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw
decodes.
How about this: since libjpeg is picking momentum and there are
actually people updating the code base, why not push for a
libjpeg-turbo merge into the original ijg's code and get Fedora to
rebase on that unique source instead? That way ijg can test for any
regressions using their conformance tests.
Regards,
-Ilyes Gouta
On Tue, May 25, 2010 at 3:23 PM, Adam Goode a...@spicenitz.org wrote:
On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream?
(For the primary architectures anyway).
I think this is a great idea, libjpeg is the bottleneck for a lot of my
code.
One issue: are there C fallbacks for all the arch-specific code? It
would be great if secondary architectures could just use libjpeg-turbo
as well.
Adam
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
Hi, That's always been how it's looked to me as well, FWIW. Given that we default to using free world fonts and can't ship Microsoft's fonts it would seem sensible to default to the autohinter rather than the BCI, in my opinion. I definitely prefer the autohinter's interpretation of the fonts I usually use (Deja Vu / Vera). I think it all boils down to this question: Do we want Fedora to provide full support for the TrueType standard (actually file format is much more appropriate) or not? I'd say the principle should be that we should use whichever non-encumbered method gives the closest rendering to that intended by the font designer of our default font set for any particular release. From what I know, the FreeType API doesn't allow to switch from one method to another on a per-font basis. But to move on and completely disable such a feature (bci) is a hefty price to pay. Would be nice if we could build a kind of a whitelist where bci would be used against this and that font and disabled otherwise. -Ilyes Gouta On Tue, May 25, 2010 at 5:17 PM, Adam Williamson awill...@redhat.com wrote: On Sun, 2010-05-23 at 21:51 +0200, drago01 wrote: On Sun, May 23, 2010 at 9:11 PM, Gianluca Sforna gia...@gmail.com wrote: On Sun, May 23, 2010 at 6:57 PM, Roberto Ragusa m...@robertoragusa.it wrote: I'm well aware that many people have different tastes about font readability and that I'm probably out of the majority (who wants like on Windows rendering). This awareness was actually the reason of my post: to have guys remember that not everyone welcomes the bci. Actually, one of the first questions I get from users switching from Ubuntu is why our fonts look worse than theirs. As of today, I haven't a good answer, if anyone knows better I'd really love to hear where we differ and if/how we plan to close the gap. We neither do have the BCI nor the subpixel hinter enabled. The patents for the former expired but apparently some fonts look worse with it so we decided to disable it. (I have been running with it enabled for years and for me stuff does look _way_ better with the bci ... but well this is a subjective thing). AIUI, Microsoft fonts - Arial and the rest - are designed with BCI in mind and look better that way. Free world fonts - Deja Vu and so on - were designed with the autohinter in mind, and tend to look better that way. That's always been how it's looked to me as well, FWIW. Given that we default to using free world fonts and can't ship Microsoft's fonts it would seem sensible to default to the autohinter rather than the BCI, in my opinion. I definitely prefer the autohinter's interpretation of the fonts I usually use (Deja Vu / Vera). I'd say the principle should be that we should use whichever non-encumbered method gives the closest rendering to that intended by the font designer of our default font set for any particular release. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi,
A merge is the most appropriate here. After all libjpeg-turbo just
offers a set of x86 specific SSE/MMX routines such as IDCT (maybe
huffman, but I didn't check that) that would be easily plugged into
ijg, but doesn't change the foundations (architecture and exposed
public API) of libjpeg.
Also, one has to think about the applications that depend on it: what
if they break and/or require changes.
-Ilyes Gouta
On Wed, May 26, 2010 at 1:45 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Ilyes Gouta wrote:
There is one strong point that libjpeg-{6b, 8ab} inherited since it's
been there for a lof time: a *defacto* standard for JPEG
compression/decompression that has been heavily depolyed, used and
tested code for various application/, thoughtout the time, for more
than a decade! I think that's important and would enable it to keep
its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a
couple of ways to accelerate JPEG decoding by turning on the IDCT
level decimation (basically for free resize) and enabling YUV raw
decodes.
This kind of arguments doesn't really make sense for Fedora. We should ship
the best implementation, not the most tried and true one. Fedora is about
advancing Free Software, not being conservative. If you see any concrete
issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it
just because it's not the same old stuff.
Something which is IMHO more important to consider is whether libjpeg-turbo
is missing any improvements which are in the current IJG codebase, e.g. new
APIs apps may start relying on at some point. (In that case, we need to
either decide which to ship or ship both.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
+1 On Wed, May 26, 2010 at 6:30 PM, Martin Sourada martin.sour...@gmail.com wrote: On Wed, 2010-05-26 at 10:29 -0400, Matthew Miller wrote: On Sun, May 23, 2010 at 09:51:53PM +0200, drago01 wrote: The patents for the former expired but apparently some fonts look worse with it so we decided to disable it. (I have been running with it enabled for years and for me stuff does look _way_ better with the bci ... but well this is a subjective thing). Take a look at the two screenshots I attached to bug https://bugzilla.redhat.com/show_bug.cgi?id=547532. I think that, while it might be subjective, it's pretty clear that the without bytecode version is much, much better for Inconsolata -- which I spend my day using. Depends on the criteria you use. The with bytecode version has better kerning, better shapes, better flow, but is blurry (yeah, without subpixel hintinting the fonts just are blurry and that's the main cause why people say they look ugly). The with bytecode on the other hand is perfectly crisp, but the shapes are worse, the flow is not so smooth, some letters look a little deformed... With that said I use subpixel hinting and I usually personally prefer the autohinter (but this one depends on the font, some look better to me autohinted, some using BCI...). But generally, if font looks bad hinted when using BCI, it's most likely a bug in font, but when BCI is not present we need to fall back to autohinter, not just turn off the hinting. Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi Adam, it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. Can you please give some details on this point? -Ilyes Gouta On Mon, May 31, 2010 at 4:33 PM, Adam Tkac at...@redhat.com wrote: On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote: On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote: How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead? The problem, as I said before, is that the libjpeg upstream is not being developed in an open manner. This is pretty big issue. I've emailed Adam Tkac to bring his attention to this thread (he's involved with libjpeg-turbo) and hopefully he'll bring some more up to date information about this matter. Sorry for late response, this mail got lost in my queue. libjpeg-turbo is a fork of the original libjpeg-6b release created and maintained by VirtualGL and TigerVNC developers. Main focus is on performance and API+ABI compatibility with libjpeg. Although libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. When SSE is used then libjpeg and libjpeg-turbo performance is simply incomparable. And there are still number of areas for optimizations, for example on we are currently using only half of SSE registers on 64bit platforms. About the merge of this code with the original ijg's code. Yes, I must admit it is possible but personally I don't like it much. In my opinion libjpeg-turbo is far more ahead than libjpeg so it's easier for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not able to find CVS/SVN/git repository of the libjpeg code. In my opinion if will be great benefit for Fedora to simply replace libjpeg by libjpeg-turbo. It works fine on secondary architectures and if processor doesn't support MMX/SSE then it falls back to non-ASM code (which is still faster than libjpeg code, as I wrote above). Btw this library is used since Fedora 11 in tigervnc package for JPEG compression/decompression and it works without any problem on all supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x). So, if I summarize pros and cons for libjpeg-turbo: +: _really_ faster than libjpeg more portable more open than IJG code API/ABI compatible with libjpeg (AFAIK) works on all platforms (not only on SSE capable platforms) -: not developed by IJG :) I'm going to create a Fedora feature for this task. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
Hi, I'm still interested in seeing a linjpeg-turbo merger with ijg's own code base. I'd say that the most performance boost brought in by libjpeg-turbo is due to the specialized SIMD routines, which theoretically can be easily merged. libjpeg-turbo has also some weaknesses such as (as provided from the project's homepage): 1. Worse chroma upsampling quality, where libjpeg-turbo is favoring speed over accuracy when upsamling the chroma components 2. JPEG's standard restart marker aren't properly handled, in favor of a faster huffman decoding 3. Asymetric performance gain between 32bit and 64bit arch., which means specific, per arch. code paths and not algorithmic and architecture wise tweaks that could benefit all the architectures. To me, 1. and 2. are a bit worrying, I don't want to scarify standard correctness over a 15% perf. boost. The only items that stands out are the SIMD routines which can be merged with the ijg's official libjpeg, and I think we should push in that direction instead. -Ilyes Gouta On Tue, Jun 1, 2010 at 12:00 PM, Adam Tkac at...@redhat.com wrote: On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote: On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote: On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote: I'm going to create a Fedora feature for this task. Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo. Thanks. Is there an SRPM we can give it a test? Yes, I just created it, check http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the feature page because no package linked against current libjpeg needs to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply build install libjpeg-turbo and you should immediately see performance benefits. If you prefer to test libjpeg-turbo in more conservative way you can build SRPM and then extract libjpeg.so from it (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font rendering in F13
Hi, http://apple.slashdot.org/story/10/07/19/1524250/FreeType-Project-Cheers-TrueType-Patent-Expiration Are we going to have it enabled for Fedora 14? -Ilyes Gouta On Wednesday, May 26, 2010, Matthew Miller mat...@mattdm.org wrote: On Wed, May 26, 2010 at 07:30:56PM +0200, Martin Sourada wrote: Depends on the criteria you use. The with bytecode version has better kerning, better shapes, better flow, but is blurry (yeah, without Not just blurry, though -- awkwardly blurry. At screen resolution, in fact, I think it's pushing it to even say that the blurriness makes better shapes -- there's not enough pixels to make that work. The font has no bytecode, so it's not being hinted. But generally, if font looks bad hinted when using BCI, it's most likely a bug in font, but when BCI is not present we need to fall back to autohinter, not just turn off the hinting. Absolutely. I'm not opposed to the BCI, just opposed to failing to autohint non-bytecoded glyphs when the feature is enabled. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: directfb, fusionsound packaged, review for submition and sdl2 bridge
Hi, On Sun, Jan 19, 2014 at 10:16 AM, Ville Skyttä ville.sky...@iki.fi wrote: On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño juanmabcm...@gmail.com wrote: The packages built okay without the optional kernel module (to know, linux-fusion is the one), if that turns to be obligatory, again, i'd take alsa packaging as a cool example :) ALSA kernel modules are included in the upstream kernel, AFAIK DirectFB ones are not. In order to be included in Fedora, they need to be upstream or Fedora kernel maintainers convinced to ship them within the kernel package. http://fedoraproject.org/wiki/Packaging:KernelModules It should be possible to build DirectFB-multi without the linux-fusion kernel module, so that's reverting to shmem and UNIX sockets for IPC. I remember I saw fixes for Fusion userspace posted against the -1.7 branch. Ilyes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
