Re: Dealing with circular BuildRequires?
On 2011-10-05, Tom Lane t...@redhat.com wrote: What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... I've written an ultimate heavy-parallel rebuilding tool. (Actually it's so much parallel that Fedora infrustructure, git repositories namely, spontaneously fails.) It's packaged in `perl-Fedora-Rebuild' package, there is sample executable `rebuildperl'. Currently it's under-documented, not optimized and with some internal bugs. But I will develop it more because we need it for each year Perl rebuild, so the tool will improve. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-10-05, Tom Lane t...@redhat.com wrote: My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. Few days ago I've been asked by Marcela how should I cope with this problem (just another library). I proposed this solution: Package current shared library (and only the library, no development files or dodocumentation or bundled tools) as new package. I call the new package `shaddow package' not to confuse with already existing `compat' packages (that should deliver full-featured environment as header files). This shaddow package will RPM-provide current SONAME, thus after injecting this package into repositories, you can fluently upgrade library in the original package and then rebuild all reverse dependencies (i.e. applications like gimp) without any stress. The shaddow package will get pulled into build root automatically by the SONAME provide. Once all depending packages are rebuilt, the shaddow package becames unnecessary, but you can keep it living in repositories because it can be reused on next SONAME upgrade just by moving then-current library into the shaddow package. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tcplay: BSD-licensed alternative to TrueCrypt
There was discussion back in 2007 of TrueCrypt, and the conclusion was that the license was non-free, with several major problems. There is now a BSD-licensed alternative to TrueCrypt called tcplay, which works with Linux using the device mapper: https://github.com/bwalex/tc-play I've sucessfully used it to read and write encrypted NTFS volumes created with TrueCrypt on Windows 7. I have submitted a package for review: https://bugzilla.redhat.com/show_bug.cgi?id=743497 Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Power Management Test day (2011-09-29) Stats
Hi, thanks all who attended the Power Management Test day, the feedback was really great. Stats follows thanks regards Jaroslav P.S.: If you missed the event you can still post your results at http://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement --- Power Management Test Day Stats (2011-09-29): Submitted results: 20 Unique testers: 17 Unique machines: 19 Submitted results with valid measurement data (the test day had two parts - usual test cases and very simple measurement / benchmark): 15 Test cases available (sum for all testers): 140 Test cases finished (sum for all testers): 127 Test cases not tested (sum for all testers): 13 All testers finished in total 90.71 % of available test cases. Test cases passed: 100 (e.g. 78.74 % of finished) Test cases passed with warn: 109 (e.g. 85.83 % of finished) Test cases failed: 18 (e.g. 14.17 % of finished) That means better than 85 % success rate if warn is counted as pass. Please note the following results are are provided here only for informative purposes. The measurement method used during the test day was very simple, thus the resulting data are only very rough estimation. Power savings for laptop-battery-powersave tuned profile: Max. reported power savings: 650 mWh Min. reported power savings: -702 mWh (e.g. not savings) Average power savings for all machines (stddev in braces): 138.1 (361.9) mWh Power consumption highlights: The machine that consumed the most energy: HP Pavilion dv6 Energy consumed after 15 mins in active idle (laptop-battery-powersave tuned profile): 10368 mWh The machine that consumed the least energy: EeePC Asus 1000H Energy consumed after 15 mins in active idle (laptop-battery-powersave tuned profile): 2057 mWh Bugs reported or mentioned during the test day: 5 List of bugs: Bug 637397 - [Pineview] Samsung N150 plus netbook: no brightness control Bug 719679 - Sometimes, suspend on close-lid may be the best choice for a docked laptop Bug 742061 - [abrt] kernel: WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x3b/0x41 [mac80211](): TAINTED -W Bug 742325 - SELinux is preventing /usr/libexec/colord from 'read' accesses on the file mtab. Bug 742344 - [nouveau] Resume from suspend is broken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
Hi Eric, On 10/06/2011 10:37 AM, Eric Smith wrote: There was discussion back in 2007 of TrueCrypt, and the conclusion was that the license was non-free, with several major problems. There is now a BSD-licensed alternative to TrueCrypt called tcplay, which works with Linux using the device mapper: https://github.com/bwalex/tc-play I've sucessfully used it to read and write encrypted NTFS volumes created with TrueCrypt on Windows 7. Splendid! I've been looking for something like this for a while. Looks like it's time to create a new DragonFly BSD guest machine and restart tracking what they're doing too, they have some cool stuff there. I have submitted a package for review: https://bugzilla.redhat.com/show_bug.cgi?id=743497 I've posted my review, do take a look when you have time. Best regards, -- Michel Alexandre Salim µblog: http://identi.ca/hircus http://twitter.com/hircus GPG key ID: 78884778 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Le Mer 5 octobre 2011 21:44, Simo Sorce a écrit : Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? Unfortunately, when you get into situations with more than 150% difference in pixel densities between displays (as we've been creeping towards in the last decade) that's the only way to display text the user will be able to read. You can check it now easily, just get a run-of-the-mill full-hd 15 laptop (not even a tiny netbook), a run-of-the-mill 22 or more screen (nothing especially uncommon either), create an extended desktop with both screens and try to set a satisfying font size. I defy you to find a setting that won't look way too small or way too big on one of the screens. And it won't matter if the user likes small or big fonts. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit : This... works badly. Really. Open gimp and add some text. Now double the size of the font. Save the image and open it in image viewer, and zoom out so the text is half the size. It doesn't look the same as your original text. Rendering fonts (and even SVGs) well requires you to know the scale that you're rendering to. More pixels mean you can add more detail. If you shrink that then the additional detail is still there, getting in the way of the actually important information. Doing this properly requires that the original object renderer be part of the scaling process, and doing that on the fly with reasonable performance just isn't part of our rendering stack at the moment. Which is exactly why forcing 96dpi on displays which have very different pixel densities *today* is not a good idea at all. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 711486] Missing dependency (perl-ExtUtils-MakeMaker) in perl-CPANPLUS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711486 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-5.14.0-161.fc16 --- Comment #6 from Petr Pisar ppi...@redhat.com 2011-10-06 07:13:28 EDT --- Fixed as perl-5.14.0-161.fc16 in F16 and higher. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 711486] Missing dependency (perl-ExtUtils-MakeMaker) in perl-CPANPLUS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711486 --- Comment #5 from Petr Pisar ppi...@redhat.com 2011-10-06 07:10:04 EDT --- (In reply to comment #0) Steps to Reproduce: 1.Install perl-CPANPLUS 2.Remove perl-ExtUtils-MakeMaker 3.run 'cpanp' Actual results: Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/IPC/Cmd.pm line 210. This is about perl-IPC-Cmd should require perl(ExtUtils::MakeMaker). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On Thu, Oct 6, 2011 at 3:37 AM, Eric Smith e...@brouhaha.com wrote: There was discussion back in 2007 of TrueCrypt, and the conclusion was that the license was non-free, with several major problems. Just an FYI, unless you specifically want to stay away from problematic licences (i.e. Fedora) but don't have a problem using RPM Fusion, you can install RealCrypt. It's IS TruCrypt just re-branded. If I remember correctly it's not that TrueCrypt is non-free, but that the license is incompatible with Fedora and upstream was not willing to budge on that so it was re-branded instead. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-10-07 @ 17:00 UTC - F16 Final Blocker Bug Review #2
# F16 Final Blocker Review meeting #2 # Date: 2011-10-07 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net The second Fedora 16 final blocker bug review meeting will be this Friday at 17:00 UTC in #fedora-bugzappers. We'll be running through the final blockers and nice-to-haves. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [2] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . Thanks, Tim [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 13:13 +0200, Nicolas Mailhot wrote: Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit : This... works badly. Really. Open gimp and add some text. Now double the size of the font. Save the image and open it in image viewer, and zoom out so the text is half the size. It doesn't look the same as your original text. Rendering fonts (and even SVGs) well requires you to know the scale that you're rendering to. More pixels mean you can add more detail. If you shrink that then the additional detail is still there, getting in the way of the actually important information. Doing this properly requires that the original object renderer be part of the scaling process, and doing that on the fly with reasonable performance just isn't part of our rendering stack at the moment. Which is exactly why forcing 96dpi on displays which have very different pixel densities *today* is not a good idea at all. Non sequitur. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Em Qui, 2011-10-06 às 08:21 -0400, Simo Sorce escreveu: On Thu, 2011-10-06 at 13:06 +0200, Nicolas Mailhot wrote: Le Mer 5 octobre 2011 21:44, Simo Sorce a écrit : Are you saying fonts should change on the fly when I move an app between 2 monitors that have different DPIs ? Unfortunately, when you get into situations with more than 150% difference in pixel densities between displays (as we've been creeping towards in the last decade) that's the only way to display text the user will be able to read. You can check it now easily, just get a run-of-the-mill full-hd 15 laptop (not even a tiny netbook), a run-of-the-mill 22 or more screen (nothing especially uncommon either), create an extended desktop with both screens and try to set a satisfying font size. I defy you to find a setting that won't look way too small or way too big on one of the screens. And it won't matter if the user likes small or big fonts. Nicolas I am aware of the issue, but I am also aware of the technical difficulties in doing something like that. It's not possible today and I am not sure it will be in the near future. So currently the only option is to tell the user that we do not support multiple displays where pixel density varies by moire than 10% between them. I would even go as far as saying that by default gnome should refuse to let you join together screens of so high difference in density except we cannot trust the HW info apparently, so all we are left with is a bad user experience. Please don't. I extend my 11 laptop on a 32 TV and despite poor readability of regular fonts it still works just fine for what I need - movie playback, photo viewing, PDF presentations, etc. -- Evandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 01:13:21PM +0200, Nicolas Mailhot wrote: Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit : This... works badly. Really. Open gimp and add some text. Now double the size of the font. Save the image and open it in image viewer, and zoom out so the text is half the size. It doesn't look the same as your original text. Rendering fonts (and even SVGs) well requires you to know the scale that you're rendering to. More pixels mean you can add more detail. If you shrink that then the additional detail is still there, getting in the way of the actually important information. Doing this properly requires that the original object renderer be part of the scaling process, and doing that on the fly with reasonable performance just isn't part of our rendering stack at the moment. Which is exactly why forcing 96dpi on displays which have very different pixel densities *today* is not a good idea at all. Knowing the number of pixels available means that the output will be legible, even if you'd prefer it to be a different size. Rescaling after rendering means that the output will be illegible, even if it's the correct size. Given that we don't have the ability to dynamically re-render everything the moment an application is moved between screens, what's your proposed solution? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power Management Test day (2011-09-29) Stats
Jaroslav Skarvada wrote: thanks all who attended the Power Management Test day, the feedback was really great. Stats follows On the topic of power management: Is there anything being done to address the regressions[1] in 2.6.38+ kernels? [1] http://www.phoronix.com/scan.php?page=articleitem=linux_2638_aspm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 10/05/2011 07:49 PM, Matthew Garrett wrote: But what about the single monitor case? Let's go back to your Vaio. It's got a high DPI screen, so let's adjust to that. Now you're happy. Right up until you plug in an external monitor and now when you run any applications on the external display your fonts are twice the size they should be. WOOHOO GO TEAM of course that won't make us look like amateurs at all. So you need another heuristic to handle that, and of course heuristic is an ancient african word meaning maybe bonghits will make this problem more tractable. Heh, I don't know about Adam's Vaio, but mine (the now-discontinued 13 Y, a.k.a. Vaio-S-with-ULV-without-optical-drive) has all sorts of strange quirks (e.g. totally broken ACPI backlight interface; Matthew would remember this) -- and it turns out that it did what ajax noted earlier too: xrandr reports a 0x0 physical screen size. *sigh*. So much for quality products. But maybe a quick 'I know I have a 13.3 widescreen laptop, you know the resolution, just make things work' should work for the single-screen case (esp if we stick to certain target DPIs as Adam suggested). One shouldn't ask the typical user for information that's too cumbersome to use, oui? Like asking them to use a physical ruler to match up against. -- Michel Alexandre Salim µblog: http://identi.ca/hircus http://twitter.com/hircus GPG key ID: 78884778 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 03:57:38PM +0200, Michel Alexandre Salim wrote: But maybe a quick 'I know I have a 13.3 widescreen laptop, you know the resolution, just make things work' should work for the single-screen case (esp if we stick to certain target DPIs as Adam suggested). One shouldn't ask the typical user for information that's too cumbersome to use, oui? Like asking them to use a physical ruler to match up against. Like I said, that works fine right up until the point where you plug in a monitor with a different DPI. What do we do then? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 10/06/2011 09:45 AM, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 03:57:38PM +0200, Michel Alexandre Salim wrote: But maybe a quick 'I know I have a 13.3 widescreen laptop, you know the resolution, just make things work' should work for the single-screen case (esp if we stick to certain target DPIs as Adam suggested). One shouldn't ask the typical user for information that's too cumbersome to use, oui? Like asking them to use a physical ruler to match up against. Like I said, that works fine right up until the point where you plug in a monitor with a different DPI. What do we do then? Use the same DPI of the main monitor? what is the difference of using the wrong DPI obtained from the main monitor on the external one and using the hardcoded 96 value when the external monitor is not 96dpi. both are wrong without solution, why not at least give the user the option to set the correct DPI for the internal one, using 96 as default -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Like I said, that works fine right up until the point where you plug in a monitor with a different DPI. What do we do then? I would wager that the majority of Fedora systems are single monitor (or, in the case of notebooks, single monitor much of the time); can't we at least try to correct for that case first, and _then_ try to deal with multi-monitor setups? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 09:30:50AM -0500, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Like I said, that works fine right up until the point where you plug in a monitor with a different DPI. What do we do then? I would wager that the majority of Fedora systems are single monitor (or, in the case of notebooks, single monitor much of the time); can't we at least try to correct for that case first, and _then_ try to deal with multi-monitor setups? Changing the current behaviour doesn't make the most common case significantly better, but potentially makes a less common (but still common) case significantly worse. What's the benefit? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/5/11 12:54 PM, Richard W.M. Jones wrote: On Wed, Oct 05, 2011 at 09:58:59AM -0500, Eric Sandeen wrote: right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. You almost preempted my question: Could I use this for every ext4 filesystem I make? Honestly from a virt / libguestfs p.o.v. it sounds like something we should always do. Yes, and sorry for the earlier confusion - it should be on by default for newer kernels + e2fsprogs. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Is there a circumstance where this is bad? I'm thinking perhaps a case where you create a filesystem and immediately try to populate it with lots of files. I do have some concerns about that. I think it will take some careful benchmarking to know for sure whether it is an issue. Commit bfff68738f1cb5c93dab1114634cea02aae9e7ba has a good summary of how it all works, and what some impact on early fs operations may be: We do not disturb regular inode allocations in any way, it just do not care whether the inode table is, or is not zeroed. But when zeroing, we have to skip used inodes, obviously. Also we should prevent new inode allocations from the group, while zeroing is on the way. For that we take write alloc_sem lock in ext4_init_inode_table() and read alloc_sem in the ext4_claim_inode, so when we are unlucky and allocator hits the group which is currently being zeroed, it just has to wait. -Eric Rich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power Management Test day (2011-09-29) Stats
- Original Message - Jaroslav Skarvada wrote: thanks all who attended the Power Management Test day, the feedback was really great. Stats follows On the topic of power management: Is there anything being done to address the regressions[1] in 2.6.38+ kernels? I cannot reproduce these numbers on our testing machine - in [1] power consumption in active idle is +- measurement error, in other tests it is mostly higher power consumption, but also higher performance. Similar for idle graph in [2]. I will try to get one of the mentioned machines and recheck. More detailed comparison of power consumption of various Fedoras is on my todo list regards Jaroslav [1] http://jskarvad.fedorapeople.org/pm-tests/ [2] http://pm-blog.yarda.eu/2011/09/power-consumption-comparison-of-firefox.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power Management Test day (2011-09-29) Stats
Jaroslav Skarvada wrote: I cannot reproduce these numbers on our testing machine - in [1] power consumption in active idle is +- measurement error, in other tests it is mostly higher power consumption, but also higher performance. Similar for idle graph in [2]. I will try to get one of the mentioned machines and recheck. More detailed comparison of power consumption of various Fedoras is on my todo list Good to know. I did not see any wild regressions either and I do not take Phoronix's reviews very seriously, but I was curious. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Le Jeu 6 octobre 2011 16:33, Matthew Garrett a écrit : On Thu, Oct 06, 2011 at 09:30:50AM -0500, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Like I said, that works fine right up until the point where you plug in a monitor with a different DPI. What do we do then? I would wager that the majority of Fedora systems are single monitor (or, in the case of notebooks, single monitor much of the time); can't we at least try to correct for that case first, and _then_ try to deal with multi-monitor setups? Changing the current behaviour doesn't make the most common case significantly better, but potentially makes a less common (but still common) case significantly worse. What's the benefit? Have the same font size value mean the same thing in gnome and not-gnome apps? Help people who use several computers calibrate them so they get the same font sizes on all of them without having to remember size 14 means something on one computer and another on others? Support single-screen high-density screen setups by default? Make network homes work as long as every client uses a display with working EDID? Really, this focus on not letting people provide simple display sizes when the EDID is broken¹ is ridiculous. Especially when *at the same time* GNOME 3.2 advertises support for colour correcting displays using ridiculously complex procedures² As you've already pointed out, the new heuristic does not solve the complex cases. So it's no use enumerating them to justify it. It won't make them go away and they will need handling sooner or later with the heuristic or without it. In the meanwhile all the heuristic does is introduce inconsistencies in font handling between GNOME and everyone else. ¹ Which BTW is not the general case, most EDIDs are fine and have been for years ² Which I support (and indeed have packaged argyll for Fedora in the past) but it is hardly simple -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote: Grovelling around in the F15 xorg-server sources and reviewing the Xorg log file on my F15 box, I see, with _modern hardware_ at least, that we do have the monitor geometry available from DDC or EDIC, and obviously it is trivial to compute the actual, correct DPI for each screen. I am clearly going to have to explain this one more time, forever. Let's see if I can't write it authoritatively once and simply answer with a URL from here out. (As always, use of the second person you herein is plural, not singular.) EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
The heuristic isn't the problem. The problem is that we have no technology that allows us to handle the complicated case of multiple displays, and solving it purely for the simple case makes the complicated case *worse*. Adding additional complexity for what would be, at best, a different set of problems doesn't seem like a worthwhile way to spend time. The only people who are actively upset by the status quo are the ones who have the ability to fix it for their case, anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Le Jeu 6 octobre 2011 15:37, Matthew Garrett a écrit : On Thu, Oct 06, 2011 at 01:13:21PM +0200, Nicolas Mailhot wrote: Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit : This... works badly. Really. Open gimp and add some text. Now double the size of the font. Save the image and open it in image viewer, and zoom out so the text is half the size. It doesn't look the same as your original text. Rendering fonts (and even SVGs) well requires you to know the scale that you're rendering to. More pixels mean you can add more detail. If you shrink that then the additional detail is still there, getting in the way of the actually important information. Doing this properly requires that the original object renderer be part of the scaling process, and doing that on the fly with reasonable performance just isn't part of our rendering stack at the moment. Which is exactly why forcing 96dpi on displays which have very different pixel densities *today* is not a good idea at all. Knowing the number of pixels available means that the output will be legible, even if you'd prefer it to be a different size. I don't call text which is significantly too big or too small legible. When apps that use different toolkits perform different font size adjustments, the resulting UIs are inconsistent and generally tiring (uniformity is a huge factor in text readability) When basic font sizes are out of whack because the desktop pretends the pixel density is way different than it is really users try to compensate using all the available size settings in their apps. The result is a huge heterogeneous mess. Settings and documents can not be moved from one computer to another without strange font size changes. Different fonts are not adjusted the same way by users, because of size rounding in UIs, breaking font set harmony. Sometimes you get apps that adjust via zooming without re-rendering -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Le Jeu 6 octobre 2011 17:18, Matthew Garrett a écrit : The heuristic isn't the problem. The problem is that we have no technology that allows us to handle the complicated case of multiple displays, and solving it purely for the simple case makes the complicated case *worse*. How does it make it worse? The heuristic does not solve the complicated case *at all*. How does removing it could possibly make it worse? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:18 +0100, Matthew Garrett wrote: The heuristic isn't the problem. The problem is that we have no technology that allows us to handle the complicated case of multiple displays, and solving it purely for the simple case makes the complicated case *worse*. Adding additional complexity for what would be, at best, a different set of problems doesn't seem like a worthwhile way to spend time. The only people who are actively upset by the status quo are the ones who have the ability to fix it for their case, anyway. I am sure display manager can easily grow a button to say something along the lines of: change font resolution to better fit multiple monitors. so that when someone that has widely varying DPIs between monitors plugs a second monitor in they can press that button and get whatever default you like best for that use case. Simo. flamebaitI am not asking for a slider because I guess the options police would shot it down :-P /flamebait -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (743966) Compiler warnings in account usability plugin
https://bugzilla.redhat.com/show_bug.cgi?id=743966 https://bugzilla.redhat.com/attachment.cgi?id=526727action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 05:33:48PM +0200, Nicolas Mailhot wrote: Le Jeu 6 octobre 2011 17:18, Matthew Garrett a écrit : The heuristic isn't the problem. The problem is that we have no technology that allows us to handle the complicated case of multiple displays, and solving it purely for the simple case makes the complicated case *worse*. How does it make it worse? The heuristic does not solve the complicated case *at all*. How does removing it could possibly make it worse? What heuristic? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. How about an actual DPI value? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 11:35:08AM -0400, Simo Sorce wrote: I am sure display manager can easily grow a button to say something along the lines of: change font resolution to better fit multiple monitors. so that when someone that has widely varying DPIs between monitors plugs a second monitor in they can press that button and get whatever default you like best for that use case. We could do that, but you'd still need toolkit support for triggering a re-render of everything. And it'd be pretty dreadful UI (why doesn't this just happen automatically?). And suddenly everything on your internal display would be a different size and possibly even in a different place. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 11:39:16AM -0400, Jon Masters wrote: On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. How about an actual DPI value? The DPI depends on the mode. Not all the world is an LCD, and even there it depends on whether you're native, scaling or scaling with constrained aspect ratio. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:44 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:35:08AM -0400, Simo Sorce wrote: I am sure display manager can easily grow a button to say something along the lines of: change font resolution to better fit multiple monitors. so that when someone that has widely varying DPIs between monitors plugs a second monitor in they can press that button and get whatever default you like best for that use case. We could do that, but you'd still need toolkit support for triggering a re-render of everything. And it'd be pretty dreadful UI (why doesn't this just happen automatically?). And suddenly everything on your internal display would be a different size and possibly even in a different place. The consequences are exactly the reason why I think it should not happen automatically and a button would be the right compromise. Avoids WTF surprises if you just plug a monitor in and suddenly all your stuff changes, and still allows you to fix the size if the other monitor is too screwed up with the settings you have due to your main monitor. In all cases where you have widely different DPIs I am sure you will find 50% of the people wanting the exact opposite oft he other 50% to happen so not doing anything and letting the user adjust the situation only if he wants to seem the better way. Plus IIRC display manger tries to remember settings, so this is something that could be remembered as well so users do not get annoyed with but I already told it to do that yesterday when I plugged in the video projector the firs time. That said, I am not responsible for any of these changes, so I will leave it in the hands of the maintainers hoping this discussion have improved everyone understanding of the issues involved. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:46 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:39:16AM -0400, Jon Masters wrote: On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. How about an actual DPI value? The DPI depends on the mode. Not all the world is an LCD, and even there it depends on whether you're native, scaling or scaling with constrained aspect ratio. My main use case here is video projectors, and in that case there is no way on earth you'll ever know the DPI as it depends on the distance from the wall, and again even if you knew the distance from the wall you'd know nothing because the optimal DPI will also depend on the distance of the crowd from the wall. So in that case you really should just give an option to the user to easily change DPI (no need to call the option 'DPIs', it can be a slider with no mention of DPI if you prefer) *if* it is needed. Chances are that a much wider font resulting from high density primary display derived DPI number combined with low resolution video projector screen will show big fonts and that will happen to be *exactly* what you want so the guy back there at the end of the room has a chance to actually read something :) Then there will be guy X that hates the big fonts or has a ridiculously low DPI primary screen and he'll not be happy. You cannot please everyone with a default, but you can with an easy to discover option. So whatever is the situation the slider should be right there in the tool you use to manage the additional monitors or people will be forced to search and find the menu where he can change something to try to get a better font size and all resulting in poor experience as that menu is normally well hidden as it is a rarely used option normally. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 12:00:36PM -0400, Simo Sorce wrote: So in that case you really should just give an option to the user to easily change DPI (no need to call the option 'DPIs', it can be a slider with no mention of DPI if you prefer) *if* it is needed. Chances are that a much wider font resulting from high density primary display derived DPI number combined with low resolution video projector screen will show big fonts and that will happen to be *exactly* what you want so the guy back there at the end of the room has a chance to actually read something :) I absolutely agree that there should be an easy mechanism to globally change font size. But I don't think tying it to DPI is helpful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 11:14 -0400, Jon Masters wrote: On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Given that successive revisions of the spec have gone out of their way to make it acceptable for displays to provide _less_ useful information, on the grounds of manufacturing cost reduction, I think the momentum is quite in the other direction. More pragmatically, VESA are not the people with any influence here. The only thing that matters to a monitor vendor is what Windows does when you plug it in. Linux can stamp its little foot all it wants. No one will care. If you want to be a big enough player in that market to have some influence, you have to start by playing in the sandbox that's already built, and in that sandbox physical dimensions are just not reliable and never will be. Cope. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 12:00:36 -0400, Simo Sorce s...@redhat.com wrote: My main use case here is video projectors, and in that case there is no way on earth you'll ever know the DPI as it depends on the distance from the wall, and again even if you knew the distance from the wall you'd know nothing because the optimal DPI will also depend on the distance of the crowd from the wall. What you really want to know is the resolution per angle or arc. And that would be relatively constant for a project regardless of distance from the surface it is projecting on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 12:12 -0400, Adam Jackson wrote: On Thu, 2011-10-06 at 11:14 -0400, Jon Masters wrote: On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Given that successive revisions of the spec have gone out of their way to make it acceptable for displays to provide _less_ useful information, on the grounds of manufacturing cost reduction, I think the momentum is quite in the other direction. More pragmatically, VESA are not the people with any influence here. The only thing that matters to a monitor vendor is what Windows does when you plug it in. Linux can stamp its little foot all it wants. No one will care. If you want to be a big enough player in that market to have some influence, you have to start by playing in the sandbox that's already built, and in that sandbox physical dimensions are just not reliable and never will be. Cope. Ok. I can cope, and not to flog a dead horse here...but has any effort been made anywhere on the Open Source side of things to influence future EDID specs? I'm sure Linux can stamp all it wants and nobody will care, but it probably doesn't hurt to raise this for discussion next time there's an update to the standard - or, shock, reach out to MSFT and see if they have any interest in working together on fixing this experience which perhaps also causes problems they care about on Windows. Just a suggestion. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 17:12 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 12:00:36PM -0400, Simo Sorce wrote: So in that case you really should just give an option to the user to easily change DPI (no need to call the option 'DPIs', it can be a slider with no mention of DPI if you prefer) *if* it is needed. Chances are that a much wider font resulting from high density primary display derived DPI number combined with low resolution video projector screen will show big fonts and that will happen to be *exactly* what you want so the guy back there at the end of the room has a chance to actually read something :) I absolutely agree that there should be an easy mechanism to globally change font size. But I don't think tying it to DPI is helpful. Sure call it the way you prefer, does need to be DPI necessarily, but the concept of DPI would give a clue to all apps about what they are asked to do, whether it is font or some other rendering. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On Wed, Oct 05, 2011 at 12:02:33PM -0400, Tom Lane wrote: Petr Pisar ppi...@redhat.com writes: On 2011-10-05, Tom Lane t...@redhat.com wrote: For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. We had similar problem when upgrading Perl to 5.14. First, we choosed dependecy-ordered builds which stopped after rebuilding about one thousand packages. Then we hit circular dependencies blocking remaining eight hunderds packages. What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... smock possibly, modulo the shortcomings that Seth Vidal correctly pointed out. It is here: http://git.annexia.org/?p=fedora-mingw.git;a=tree;f=smock;hb=HEAD Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 12:00 -0400, Simo Sorce wrote: So in that case you really should just give an option to the user to easily change DPI (no need to call the option 'DPIs', it can be a slider with no mention of DPI if you prefer) *if* it is needed. There actually is one, only it's called the Text Scaling Factor, and it's hidden in the Accessibility panel. It effectively sets the DPI to 96*TSF, so you have to do desired dpi / 96 to figure out what you want to set it to. (That's a much better UI! Now, both people who know what DPI is and how to calculate it and people who don't are lost and confused. equality ho! ) -- 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
Re: Why EDID is not trustworthy for DPI
On 2011/10/06 15:33 (GMT+0100) Matthew Garrett composed: On Thu, Oct 06, 2011 at 09:30:50AM -0500, Chris Adams wrote: I would wager that the majority of Fedora systems are single monitor (or, in the case of notebooks, single monitor much of the time); can't we at least try to correct for that case first, and _then_ try to deal with multi-monitor setups? Changing the current behaviour doesn't make the most common case significantly better, but potentially makes a less common (but still common) case significantly worse. What's the benefit? Nearly always the permanent display will have the higher actual DPI. This means: 1-96 makes everything undersize too often on internal displays 2-the external display has bigger text than the internal 3-accurate on the internal rarely means no text anywhere is illegible 4-it's invariably easier to make too big Xorg text smaller than the converse 5-what Nicolas Mailhot wrote What happens to/for multiple display users should only be fussed over after an appropriate strategy is developed for the vast majority that use a single display at a time. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 11:41 -0500, Bruno Wolff III wrote: On Thu, Oct 06, 2011 at 12:00:36 -0400, Simo Sorce s...@redhat.com wrote: My main use case here is video projectors, and in that case there is no way on earth you'll ever know the DPI as it depends on the distance from the wall, and again even if you knew the distance from the wall you'd know nothing because the optimal DPI will also depend on the distance of the crowd from the wall. What you really want to know is the resolution per angle or arc. And that would be relatively constant for a project regardless of distance from the surface it is projecting on. No, I do not really care because the apparent size of stuff depends on the distance of the viewer from the projected surface too, so having that value doesn't really tell you how big you should display stuff. Also I do not need to know the resolution per arc to know that 10 pixels are always 10 pixel just bigger because the wall is farther, except they are still too little for the job because the crowd is even farther from the wall than the projector is :) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Simo Sorce (s...@redhat.com) said: My main use case here is video projectors, and in that case there is no way on earth you'll ever know the DPI as it depends on the distance from the wall, and again even if you knew the distance from the wall you'd know nothing because the optimal DPI will also depend on the distance of the crowd from the wall. Obviously you embed radar in every projector. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please review: convert memberof to use transactions
Rich Megginson wrote: There are 3 patches. 0001 fixes a problem with betxn and modrdn to make the ENTRY_POST_OP available to betxnpostop plugins. 0002 allows us to pass the plugin config entry to plugin_init functions (yay! finally!). 0003 is the actual change to memberof. ack. ack. ack. So, once betxn is set to the memberof plugin type, memberof mod operations are included in the same transaction? -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: convert memberof to use transactions
On 10/06/2011 12:04 PM, Noriko Hosoi wrote: Rich Megginson wrote: There are 3 patches. 0001 fixes a problem with betxn and modrdn to make the ENTRY_POST_OP available to betxnpostop plugins. 0002 allows us to pass the plugin config entry to plugin_init functions (yay! finally!). 0003 is the actual change to memberof. ack. ack. ack. So, once betxn is set to the memberof plugin type, memberof mod operations are included in the same transaction? Right. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 6, 2011 at 10:01 AM, Bill Nottingham nott...@redhat.com wrote: Obviously you embed radar in every projector. Quite possible to do with existing off the shelf ultrasonic or diode laser telemetry being used for DYI robotic range finding. In fact you can get ones that use i2c for data acquisition.I could probably mock something up with an arduino unit to do the measurement. Though I'd need some help getting a projector to use the calculation and hand it back over the wire to the computer. -jefsort of kidding...sort ofspaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On Oct 5, 2011, at 11:27 PM, Petr Pisar wrote: I've written an ultimate heavy-parallel rebuilding tool. (Actually it's so much parallel that Fedora infrustructure, git repositories namely, spontaneously fails.) It's packaged in `perl-Fedora-Rebuild' package, there is sample executable `rebuildperl'. Currently it's under-documented, not optimized and with some internal bugs. But I will develop it more because we need it for each year Perl rebuild, so the tool will improve. What failure did you create, and was there a ticket about this? If you're able to create a failure with load I'm VERY interested in this. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Once upon a time, Bill Nottingham nott...@redhat.com said: Obviously you embed radar in every projector. Projectors with auto-focus already detect the distance to the screen (I think they use IR). I don't expect that they change the EDID screen size reporting though. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self-introduction
My name is Greg, my handle these days is xaeth, which is effectively a shortened versin of a name I made up for accessing a MUD with strict name requirements the better part of a decade ago (I haven't played since around then either). @dayjob I am one of their lead linux engineers. I work with improving various bits of their platform and processes. One of the first things I had to learn when starting there 4 years ago was RPMs. Since then I became a stickler about enforcing the Fedora Packaging Guidelines as our internal guidelines. Sadly, there is always room for improvement, especially when re-packaging software from 3rd party vendors. The other thing I had to learn a lot about was python, and we started to make that our primary admin scripting tool internally. I started helping out on the func and cobbler projects over the last year, but currently project @dayjob is preventing me from contributing as much as I want to at the moment (I've barely touched func since 0.29, i'm sorry seth). I am also starting to use augeas more and more in our puppet setup. There is a python-augeas package, but it is not in EPEL at the moment. I've built the package and submitted the 1 patch I had in, but due to a lack of an EPEL maintainer it hasn't gotten release to EPEL. The other day on the list we got into a discussion on augeas-devel and I volunteered to take on the role if possible. I've read through the Package_Maintainers wiki. At one point in one of the docs it mentions that do do this I should follow the Become a co-maintainer process, but I guess I missed that specific processes' documentation. So I'm at the point where I am introducing myself in the regular process :) hi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 13:36 -0500, Chris Adams wrote: Once upon a time, Bill Nottingham nott...@redhat.com said: Obviously you embed radar in every projector. Projectors with auto-focus already detect the distance to the screen (I think they use IR). I don't expect that they change the EDID screen size reporting though. But you don't (only) need to know the distance between the projector and the screen, you need to know the distance between the *audience* and the screen. So, logically, what we need to do is make projectors capable of using Bluetooth to figure out what cellphones are nearby, and Facebook and Foursquare to check on their GPS locations... -- 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
Re: Power Management Test day (2011-09-29) Stats
On Thu, 2011-10-06 at 06:35 -0400, Jaroslav Skarvada wrote: Hi, thanks all who attended the Power Management Test day, the feedback was really great. Stats follows thanks regards Jaroslav Big thanks for doing all the organization and publicity for this, sorry we couldn't help out too much with all the Beta stuff going on! Looks like it went really well. -- 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
Re: Why EDID is not trustworthy for DPI
Le jeudi 06 octobre 2011 à 16:41 +0100, Matthew Garrett a écrit : On Thu, Oct 06, 2011 at 05:33:48PM +0200, Nicolas Mailhot wrote: Le Jeu 6 octobre 2011 17:18, Matthew Garrett a écrit : The heuristic isn't the problem. The problem is that we have no technology that allows us to handle the complicated case of multiple displays, and solving it purely for the simple case makes the complicated case *worse*. How does it make it worse? The heuristic does not solve the complicated case *at all*. How does removing it could possibly make it worse? What heuristic? The one you were writing about Me, I don't care about which heuristic you were thinking of. Any heuristic will annoy large numbers of users when you're dealing with text. The rules should be simple and stupid: A. on a single-screen system 1. use the xorg-detected screen size to compute actual DPI, base font sizes on it 2. if autodetection didn't work or the results looks wrong (because the hardware is broken, or it's not designed to be used on a desk but is a TV/a projector), ask the user to provide the screen size (displaying slider + a ruler in the locale's length unit, with the length unit displayed on screen too; users are smart enough to fake lengths if they want to). If you want market forces to work, crowdsource the complaining and tell the user his hardware is broken and he should take it with the manufacturer. 3. save the results and reuse them each time the same screen is used 4. propagate the resulting dpi so every toolkit can use them (ideally propagate it down to the xorg level so every toolkit that uses xorg dpi will just work) B. when a second screen is detected 1. use the same rules to get its size 2. if the computed dpi for the second screen is too different from the first one, ask the user what to do (optimize for screen 1, for screen 2, deoptimize both with a middle setting) 3. save the results to apply them automatically the next time this screen combination is encountered 4. longer term start thinking about how to apply different dpi to different outputs as screen densities have been clearly diverging for some years, and the compination of fixed-size laptops and increasing resolutions can only mean more divergence in the future C. for font sizes 1. display them in points (pt) or pixels (px), 2. display the unit you're using. Don't make the user guess what the perverted font dialog author had in mind 3. let the user specify them in points or pixels as he prefers, regardless of the default display unit 4. accept decimals, do not try to round sizes to integers 5. do not try to invent a new unit. Yes historical units are stupid and badly thought, but so are imperial units and letter format, and that's what some countries still use. Units are not there to be smart units are there so different people can agree on measurements. Points is what users will see in every electronic document they will be filling, no new unit will be better enough to outweight the hassle of the user having to deal with a new unit. If you have time to waste, go rewrite every electronic document app and format in the market to use your unit, and only afterwards inflict it on desktop users. And if you still think being pedantic about font size units is a good idea, try to use only Kelvins when speaking to others about temperatures and see how they react. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Power Management Test day (2011-09-29) Stats
On Thu, 2011-10-06 at 09:56 -0500, Michael Cronenworth wrote: Jaroslav Skarvada wrote: I cannot reproduce these numbers on our testing machine - in [1] power consumption in active idle is +- measurement error, in other tests it is mostly higher power consumption, but also higher performance. Similar for idle graph in [2]. I will try to get one of the mentioned machines and recheck. More detailed comparison of power consumption of various Fedoras is on my todo list Good to know. I did not see any wild regressions either and I do not take Phoronix's reviews very seriously, but I was curious. If you read Phoronix's articles (not just their headlines), even they admit that this is not really a 'regression'. It's a perfectly sensible bug fix. PCIe Active State Power Management was found to cause crashes on some hardware, so since 2.6.38 it's explicitly disabled when the system BIOS says it's not supported and only enabled where the BIOS explicitly claims support for it (which is few machines). It's clearly a defensible decision to prioritize 'not crashing people's machines' over 'ideal PM out of the box', and describing this as a 'regression' is hardly accurate. You can enable ASPM on machines where it's disabled by default with a kernel parameter, if you're happy to turn it off again yourself if it causes crashes, and if it actually makes a noticeable difference on your machine. See http://www.fewt.com/2011/09/about-kernel-30-power-regression-myth.html -- 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
Re: Why EDID is not trustworthy for DPI
On 2011/10/06 13:59 (GMT-0400) Simo Sorce composed: the crowd is even farther from the wall than the projector is :) Church sanctuary projectors are typically near the back, which means huge numbers of, if not most people, are closer to the viewing surface than the projector is. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Tue, Oct 04, 2011 at 10:51:43PM -0700, Adam Williamson wrote: (That said, there definitely needs to be a way to disable it, and maybe it should even be disabled by default. I personally always uninstall yum- presto. For me, it's much faster to just download packages than to rebuild them from deltas. Only users on really slow connections benefit from it.) My desktop can rebuild deltas at ~3MB/sec. So even my really fast internet connection is slower than delta rebuild. Your internet connection is clearly not fast enough. :) -- 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
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 09:22:22PM +0200, Nicolas Mailhot wrote: Le jeudi 06 octobre 2011 à 16:41 +0100, Matthew Garrett a écrit : What heuristic? The one you were writing about The heuristic I was writing about is the Trust the DPI we get from EDID if it's within some size range. We don't implement that. We have no heuristic approach at all. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 2011/10/06 21:22 (GMT+0200) Nicolas Mailhot composed: C. for font sizes 1. display them in points (pt) or pixels (px), no 2. display the unit you're using. Don't make the user guess what the perverted font dialog author had in mind no 3. let the user specify them in points or pixels as he prefers, regardless of the default display unit no Instead, display fonts of different sizes and have user pick one. No need for user to know or care about units or numbers or DPI, same as web authors needlessly fixated on pixels instead of the fact that personal computers are expected to be personalized, which means desktop objects larger or smaller than as shipped from the vendor. DPI is nothing but a way to describe pixel density, and users shouldn't care about numbers, only higher or lower, good or not good, better or not better. Higher DPI _is_ better, because higher means more resolution, more accuracy, and more pleasing viewing, but only as long as naive application and web site stylists don't force to sizes that work only on lower density screens they're viewing during construction. http://people.gnome.org/~federico/news-2007-01.html -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Thu, 2011-10-06 at 15:35 -0400, Matthew Miller wrote: On Tue, Oct 04, 2011 at 10:51:43PM -0700, Adam Williamson wrote: (That said, there definitely needs to be a way to disable it, and maybe it should even be disabled by default. I personally always uninstall yum- presto. For me, it's much faster to just download packages than to rebuild them from deltas. Only users on really slow connections benefit from it.) My desktop can rebuild deltas at ~3MB/sec. So even my really fast internet connection is slower than delta rebuild. Your internet connection is clearly not fast enough. :) Not all of us get university pipes all our lives, Matt ;) -- 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
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-10-04 at 09:07 -0700, Adam Williamson wrote: On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote: - Original Message - The setup inside Red Hat cannot be (directly) copied outside at this time. Instead the autoQA project was started to re-create it as an open source project. That's where effort should continue. Am I right in saying that AutoQA is basically mired in the muck and going nowhere at the moment? at the moment, yes, but that's with a very narrow scope of at the moment - i.e. for the last few weeks. I don't want Kamil's email to give the impression that AutoQA has been going nowhere for months, because that certainly isn't the case. Work has slowed down in the last few weeks because Fedora 16 Beta testing was extremely problematic and sucked up most of the AutoQA manpower, and QA is anyway undermanned (from a Red Hat paid staff viewpoint) ATM. It should speed up again to a lesser degree now, and to a greater degree when Final is done and we have a couple more bodies in place. I think adding some more rpmdiff-type tests to current AutoQA wouldn't actually be a huge stretch, but I'd bow to Tim or Kamil on the detail front there. Not to bash the thing to death, but Kamil did a presentation on AutoQA at FUDCon Milan, the slides are well worth reading: https://fedoraproject.org/w/uploads/2/27/AutoQA-FUDCon-Milan-2011.odp they provide a pretty good potted explanation of what the big priorities in AutoQA development are right now, why they're important, why AutoQA can't really accept outside test contributions right now (and what needs fixing before it can), and in general why AutoQA is kind of in 'swan mode' at the moment - it looks like nothing much is going on above the waterline, but below the surface the legs are pumping away madly :) -- 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
Re: Why EDID is not trustworthy for DPI
Le jeudi 06 octobre 2011 à 15:39 -0400, Felix Miata a écrit : Instead, display fonts of different sizes and have user pick one. No need for user to know or care about units or numbers or DPI, That does not work because those units are used in different electronic formats, for example office suites. You can invent all the new font mesurements you want at the end of the day a lot of users will open libreoffice or another app that requires them to know the size of a 12pt font. All you get by using another unit elsewhere is a new translation table and lots of confused users. (you can replace office suite with blog + custom css that works well on your computer but is hideously small/large when you check your site from you ma's computer) After all the 'need to hide dpi and units' madness started many users started to use custom font scales on their computer, and got really annoyed when they realised later that: 1. changing their hardware changed the meaning of all the sizes they got used to 2. they could not agree with their friends what sizes meant, and the office documents they had to produce where missized That's the same reason you need to colour correct your screen if you're serious about photography. In theory your screen colour drift does not mater because you can compensate for it camera-size. In practice the compensation ends up as huge colour mistakes as soon as you try to use the result on something else (another screen, printing the result, does not matter if you don't stick to a common non local baseline things will drift) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package review SIG dead?
After some initial interest there doesn't appear to be any activity unless I'm missing something. I am still interested. Anyone else? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On Thu, Oct 6, 2011 at 4:54 AM, Richard Shaw hobbes1...@gmail.com wrote: On Thu, Oct 6, 2011 at 3:37 AM, Eric Smith e...@brouhaha.com wrote: There was discussion back in 2007 of TrueCrypt, and the conclusion was that the license was non-free, with several major problems. Just an FYI, unless you specifically want to stay away from problematic licences (i.e. Fedora) but don't have a problem using RPM Fusion, you can install RealCrypt. It's IS TruCrypt just re-branded. If I remember correctly it's not that TrueCrypt is non-free, but that the license is incompatible with Fedora and upstream was not willing to budge on that so it was re-branded instead. The TrueCrypt License is, in fact, non-free for several reasons: http://lists.freedesktop.org/archives/distributions/2008-October/000276.html -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review SIG dead?
RS == Richard Shaw hobbes1...@gmail.com writes: RS After some initial interest there doesn't appear to be any activity RS unless I'm missing something. Never could gather enough interest for anyone to actually do anything. Basically I stopped after I called for a couple of folks to help me with some things and there was no response whatsoever. RS I am still interested. Anyone else? These days my interest is only occasional. If someone else is actually willing to do something, then I'm willing to participate on some level. But I'm not enough of an organizer, and I don't have enough free time, to be the person who makes it happen. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, Oct 06, 2011 at 12:00:26PM -0700, Adam Williamson wrote: On Thu, 2011-10-06 at 13:36 -0500, Chris Adams wrote: Once upon a time, Bill Nottingham nott...@redhat.com said: Obviously you embed radar in every projector. Projectors with auto-focus already detect the distance to the screen (I think they use IR). I don't expect that they change the EDID screen size reporting though. But you don't (only) need to know the distance between the projector and the screen, you need to know the distance between the *audience* and the screen. So, logically, what we need to do is make projectors capable of using Bluetooth to figure out what cellphones are nearby, and Facebook and Foursquare to check on their GPS locations... Every time DPI discussion begins, sooner or later projectors and points-per-arc are appear. They are like Godwin Law for DPI Discussions. I think everybody agrees that true DPI cannot be found. But true DPI is only needed if we want PERFECT setup. Perfect isn't possible. Can we just give up on perfect setup and instead just go with GOOD ENOUGH? Good Enough is getting real DPI for main screen and not really caring about secondary screens. Just read DPI from laptop panel (or first detected output on desktops) and use it instead of 96. Let's not care about not-so-common case of wildly different DPI on connected screens. (hey, my 300 DPI cellphone has HDMI output. I can connect it to 70 TV which gives 32 DPI. Let's don't even try to accomodate real DPI of TV!) -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review SIG dead?
Am 06.10.2011 22:17, schrieb Richard Shaw: After some initial interest there doesn't appear to be any activity unless I'm missing something. I am still interested. Anyone else? Thanks, Richard Yes, of course. I think we need some infrastructure besides the wiki. And a policy for handling old review requests, to shrink the continuously growing new package review tickets list a bit. There are a lot of tickets where the packager is no longer responsible. The list becomes confused more and more, and it's not attractive for potential reviewers, unless someone is interested in to see a certain software in Fedora. Besides that, there are quite old package reviews with the FE_NEEDSPONSOR blocker set, and they seem to be one-time-wonders in many cases. I'm in doubt if they will find a sponsor one day. Examples for such outdated tickets are bugs # 605290, 616935, 636930 and many more. In fact, all review tickets which are still incomplete and idle for more than half a year are outdated and should be closed (after a last attempt to ping the packager). Best Regards, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On Thu, Oct 6, 2011 at 3:28 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:54 AM, Richard Shaw hobbes1...@gmail.com wrote: If I remember correctly it's not that TrueCrypt is non-free, but that the license is incompatible with Fedora and upstream was not willing to budge on that so it was re-branded instead. The TrueCrypt License is, in fact, non-free for several reasons: http://lists.freedesktop.org/archives/distributions/2008-October/000276.html That's being rather pedantic... Yes it's considered non-free because of the screwy licensing agreement, however, the software is free to download and use, it is open source. Actually your link supports my last statement quite nicely. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On Thu, 2011-10-06 at 15:54 -0500, Richard Shaw wrote: On Thu, Oct 6, 2011 at 3:28 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:54 AM, Richard Shaw hobbes1...@gmail.com wrote: If I remember correctly it's not that TrueCrypt is non-free, but that the license is incompatible with Fedora and upstream was not willing to budge on that so it was re-branded instead. The TrueCrypt License is, in fact, non-free for several reasons: http://lists.freedesktop.org/archives/distributions/2008-October/000276.html That's being rather pedantic... Yes it's considered non-free because of the screwy licensing agreement, however, the software is free to download and use, it is open source. Actually your link supports my last statement quite nicely. Um. What? How can the software be open source if the license is not? The license is what determines the status of the software. At the time of that mail there were very definitely issues in the TC license which prevented it from being Free or Open Source under the FSF or OSI definitions. I believe the license has been changed since then, though, and I don't know if it's been re-evaluated. Spot is pretty familiar with the case, so he might be able to help out. -- 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
Re: tcplay: BSD-licensed alternative to TrueCrypt
Do what thou wilt shall be the whole of the Law. On Thu, Oct 6, 2011 at 3:54 PM, Richard Shaw hobbes1...@gmail.com wrote:t, however, the software is free to download and use, it is open source. (free (of cost) open source) != Free software. Richard charles zeitler -- Love is the law, love under will. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On 10/6/2011 12:41 PM, Bruno Wolff III wrote: On Thu, Oct 06, 2011 at 12:00:36 -0400, Simo Sorces...@redhat.com wrote: My main use case here is video projectors, and in that case there is no way on earth you'll ever know the DPI as it depends on the distance from the wall, and again even if you knew the distance from the wall you'd know nothing because the optimal DPI will also depend on the distance of the crowd from the wall. What you really want to know is the resolution per angle or arc. And that would be relatively constant for a project regardless of distance from the surface it is projecting on. What the ordinary user would like would be for Fedora to set the correct resolution on the damn monitor. or at least offer a choice other than *really crappy* or *even more crappy.* I can think of several other Linux Distributions that can do this during *the install*. No barriers to leap. No doors to open. No oceans to swim. No mountains to climb. It 'just works'. No distro names for politeness. Ask I and will post names. I can think of three that I know for a fact that do this. As good as it is there are things at which Fedora flat out sucks! -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with circular BuildRequires?
On Thu, 2011-10-06 at 18:36 +0100, Richard W.M. Jones wrote: On Wed, Oct 05, 2011 at 12:02:33PM -0400, Tom Lane wrote: Petr Pisar ppi...@redhat.com writes: On 2011-10-05, Tom Lane t...@redhat.com wrote: For example, cairo BuildRequires: librsvg2-devel, and librsvg2 BuildRequires: cairo-devel, so there is no order in which I can rebuild them. How the heck did we get into such a situation, and what should I do about it? Neither specfile appears to have any provision for bootstrapping. We had similar problem when upgrading Perl to 5.14. First, we choosed dependecy-ordered builds which stopped after rebuilding about one thousand packages. Then we hit circular dependencies blocking remaining eight hunderds packages. What exactly did you do for dependency-ordered builds? What I could really use right now is a tool that would sort the package list into dependency order for me, and point to where there are circularities. I'd like to think that wheel has been invented already ... smock possibly, modulo the shortcomings that Seth Vidal correctly pointed out. It is here: http://git.annexia.org/?p=fedora-mingw.git;a=tree;f=smock;hb=HEAD Rich, To be fair -smock tries - which is good. I wished it tried in python but that's just a nitpick :). The reality is - if we want to take a giant pile of srpms in an arbitrary order and build all of them in the right order - we're going to need to get a great deal more rigorous about what we put into specfiles. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About Feature enhancement Updates Policy
Adam Williamson wrote: Just to make sure something in Kevin's mail is sufficiently emphasized: the thing that's bad in the Abiword example is not the 'feature enhancement' part, it's the 'user experience change' part. The WordStar 4.0 compatibility is fine, it's the pie menus that are a problem. An update which enhances features without changing the normal user experience is not against the policy. But how is hiding http://; by default (with the preference to unbreak this tucked away under about:config) in a Firefox security update not against the policy? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
Richard Shaw wrote: That's being rather pedantic... Yes it's considered non-free because of the screwy licensing agreement, however, the software is free to download and use, Free of charge (gratis) != Free Software Free Software as defined by the Free Software Foundation refers to freedom, not price. Freedom to download and use is not sufficient, freedom to study, modify and distribute is essential, and may not be restricted by arbitrary limitations (nor of course forbidden entirely), otherwise the software is not free. it is open source. The source code is available != the software is Open Source. Open Source is a term defined by the Open Source Initiative, which means almost the same thing as Free Software. The source code being merely available can be termed Shared Source (a term coined by M$), source-available or whatever, but NOT Open Source. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About Feature enhancement Updates Policy
On Fri, 2011-10-07 at 05:37 +0200, Kevin Kofler wrote: Adam Williamson wrote: Just to make sure something in Kevin's mail is sufficiently emphasized: the thing that's bad in the Abiword example is not the 'feature enhancement' part, it's the 'user experience change' part. The WordStar 4.0 compatibility is fine, it's the pie menus that are a problem. An update which enhances features without changing the normal user experience is not against the policy. But how is hiding http://; by default (with the preference to unbreak this tucked away under about:config) in a Firefox security update not against the policy? Firefox is a special case because it's pretty impossible to backport fixes to an old Firefox branch. The policy does allow for flexibility in the case of recalcitrant upstreams. You already know this, as it's already been explained when you've complained about Firefox in the past. Continuing to raise it as if an explanation hadn't been provided is disingenous. -- 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
[Bug 743567] CVE-2011-3599 perl-Crypt-DSA: Cryptographically insecure method used for random numbers generation on systems without /dev/random
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=743567 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Summary|perl-Crypt-DSA: |CVE-2011-3599 |Cryptographically insecure |perl-Crypt-DSA: |method used for random |Cryptographically insecure |numbers generation on |method used for random |systems without /dev/random |numbers generation on ||systems without /dev/random Alias||CVE-2011-3599 --- Comment #4 from Jan Lieskovsky jlies...@redhat.com 2011-10-06 04:52:51 EDT --- The CVE identifier of CVE-2011-3599 has been assigned to this issue: http://www.openwall.com/lists/oss-security/2011/10/05/9 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 711486] Missing dependency (perl-ExtUtils-MakeMaker) in perl-CPANPLUS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711486 --- Comment #7 from Petr Pisar ppi...@redhat.com 2011-10-06 07:40:23 EDT --- F14 not affected. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 711486] Missing dependency (perl-ExtUtils-MakeMaker) in perl-CPANPLUS
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=711486 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution||CURRENTRELEASE Last Closed||2011-10-06 07:48:26 --- Comment #8 from Petr Pisar ppi...@redhat.com 2011-10-06 07:48:26 EDT --- F15 not affected. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-Graphics
perl-Bio-Graphics has broken dependencies in the rawhide tree: On x86_64: perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig) On i386: perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: convert memberof to use transactions
There are 3 patches. 0001 fixes a problem with betxn and modrdn to make
the ENTRY_POST_OP available to betxnpostop plugins. 0002 allows us to
pass the plugin config entry to plugin_init functions (yay! finally!).
0003 is the actual change to memberof.
From 0cc8c050795e575617fcb1f88ce9890a2358 Mon Sep 17 00:00:00 2001
From: Rich Megginson rmegg...@redhat.com
Date: Thu, 6 Oct 2011 08:12:21 -0600
Subject: [PATCH 1/3] set the ENTRY_POST_OP for modrdn betxnpostoperation plugins
The ENTRY_POST_OP needs to be set before calling the betxnpostoperation plugins
for the modrdn operation (e.g. for memberof).
---
ldap/servers/slapd/back-ldbm/ldbm_modrdn.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c b/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c
index 4aa771f..bcbe9c7 100644
--- a/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c
+++ b/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c
@@ -916,6 +916,7 @@ ldbm_back_modrdn( Slapi_PBlock *pb )
modify_switch_entries( newparent_modify_context,be);
}
+slapi_pblock_set( pb, SLAPI_ENTRY_POST_OP, postentry );
/* call the transaction post modrdn plugins just before the commit */
if ((retval = plugin_call_plugins(pb, SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN))) {
LDAPDebug1Arg( LDAP_DEBUG_ANY, SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin
@@ -994,6 +995,8 @@ error_return:
{
slapi_entry_free( postentry );
postentry= NULL;
+/* make sure caller doesn't attempt to free this */
+slapi_pblock_set( pb, SLAPI_ENTRY_POST_OP, postentry );
}
if (e entryrdn_get_switch())
{
@@ -1117,7 +1120,6 @@ common_return:
{
slapi_pblock_set(pb, SLAPI_URP_NAMING_COLLISION_DN, slapi_ch_strdup (dn));
}
-slapi_pblock_set( pb, SLAPI_ENTRY_POST_OP, postentry );
if (pb-pb_conn)
{
slapi_log_error (SLAPI_LOG_TRACE, ldbm_back_modrdn, leave conn=% NSPRIu64 op=%d\n, pb-pb_conn-c_connid, operation-o_opid);
--
1.7.1
From 4a5b40295a2b9f7fce161278c9ccd76e5eff8b55 Mon Sep 17 00:00:00 2001
From: Rich Megginson rmegg...@redhat.com
Date: Wed, 5 Oct 2011 16:53:30 -0600
Subject: [PATCH 2/3] pass the plugin config entry to the plugin init function
A plugin init function can get the plugin config entry (that is, its own
config entry) by using the pblock parameter SLAPI_PLUGIN_CONFIG_ENTRY
int
my_plugin_init(Slapi_PBlock *pb)
{
Slapi_Entry *my_config_entry = NULL;
slapi_pblock_get(pb, SLAPI_PLUGIN_CONFIG_ENTRY, my_config_entry);
---
ldap/servers/slapd/plugin.c |1 +
ldap/servers/slapd/plugin_internal_op.c | 14 +-
ldap/servers/slapd/slapi-plugin.h |5 +
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/ldap/servers/slapd/plugin.c b/ldap/servers/slapd/plugin.c
index c145eff..19d6d38 100644
--- a/ldap/servers/slapd/plugin.c
+++ b/ldap/servers/slapd/plugin.c
@@ -2294,6 +2294,7 @@ plugin_setup(Slapi_Entry *plugin_entry, struct slapi_componentid *group,
}
slapi_pblock_set(pb, SLAPI_PLUGIN_ENABLED, enabled);
+ slapi_pblock_set(pb, SLAPI_PLUGIN_CONFIG_ENTRY, plugin_entry);
if ((*initfunc)(pb) != 0)
{
diff --git a/ldap/servers/slapd/plugin_internal_op.c b/ldap/servers/slapd/plugin_internal_op.c
index 75d4e4a..c8e6000 100644
--- a/ldap/servers/slapd/plugin_internal_op.c
+++ b/ldap/servers/slapd/plugin_internal_op.c
@@ -876,7 +876,7 @@ void set_common_params (Slapi_PBlock *pb)
* copy of the entry, NULL can be passed for ret_entry.
*/
int
-slapi_search_internal_get_entry( Slapi_DN *dn, char ** attrs, Slapi_Entry **ret_entry , void * component_identity)
+slapi_search_internal_get_entry_ext( Slapi_DN *dn, char ** attrs, Slapi_Entry **ret_entry , void * component_identity, void *txn )
{
Slapi_Entry **entries = NULL;
Slapi_PBlock *int_search_pb = NULL;
@@ -892,6 +892,7 @@ slapi_search_internal_get_entry( Slapi_DN *dn, char ** attrs, Slapi_Entry **ret_
0 /* attrsonly */, NULL /* controls */,
NULL /* uniqueid */,
component_identity, 0 /* actions */ );
+ slapi_pblock_set( int_search_pb, SLAPI_TXN, txn );
slapi_search_internal_pb ( int_search_pb );
slapi_pblock_get( int_search_pb, SLAPI_PLUGIN_INTOP_RESULT, rc );
if ( LDAP_SUCCESS == rc ) {
@@ -913,3 +914,14 @@ slapi_search_internal_get_entry( Slapi_DN *dn, char ** attrs, Slapi_Entry **ret_
int_search_pb = NULL;
return rc;
}
+
+/*
+ * Given a DN, find an entry by doing an internal search. An LDAP error
+ * code is returned. To check if an entry exists without returning a
+ * copy of the entry, NULL can be passed for ret_entry.
+ */
+int
+slapi_search_internal_get_entry( Slapi_DN *dn, char ** attrs, Slapi_Entry **ret_entry , void * component_identity)
+{
+ return slapi_search_internal_get_entry_ext(dn, attrs, ret_entry, component_identity, NULL);
+}
diff --git a/ldap/servers/slapd/slapi-plugin.h b/ldap/servers/slapd/slapi-plugin.h
index 4764e50..862a23b
Re: [389-devel] Please review: convert memberof to use transactions
Rich Megginson wrote: On 10/06/2011 12:04 PM, Noriko Hosoi wrote: Rich Megginson wrote: There are 3 patches. 0001 fixes a problem with betxn and modrdn to make the ENTRY_POST_OP available to betxnpostop plugins. 0002 allows us to pass the plugin config entry to plugin_init functions (yay! finally!). 0003 is the actual change to memberof. ack. ack. ack. So, once betxn is set to the memberof plugin type, memberof mod operations are included in the same transaction? Right. Cool! That'll be very useful! -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
