Re: Video performance degradation in F24
On 09/12/2016 01:21 PM, Zdenek Kabelac wrote: > Dne 12.9.2016 v 17:48 Basil Mohamed Gohar napsal(a): >> On 09/11/2016 02:19 PM, stan wrote: >>> On Sat, 10 Sep 2016 22:04:22 -0400 >>> Basil Mohamed Gohar wrote: >>> >>> >>>>> On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote: >>>>>> Even since I installed F24 on both my desktop as well as my laptop >>>>>> I've noticed a severe performance degradation in terms of video >>>>>> playback. >>> >>> Is this using a browser, or a player on the system, like vlc or mplayer? >>> What does your 'severe performance degradation' consist of? Dropped >>> frames? Lock up? Artifacts? Could network congestion or speed be a >>> factor? Or do you just mean that the gui is slow to respond? >>> >>>>>> >>>>>> I've noticed this performance issue in both MATE (my preferred DE) >>>>>> as well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an >>>>>> APU but also has a discrete card as well). >>>>>> >>>>>> I don't want to use devel just to report a problem, but I'd also >>> >>> This really belongs on users. You can subscribe to users by >>> sending an email message to >>> users-requ...@lists.fedoraproject.org >>> with subscribe in the subject line, and from email address >>> basilgo...@librevideo.org >>> >>>>>> like some help in diagnosing the issue so that a fix can be found >>>>>> – but unfortunately I don't really know where to start. >>> >>> What does top show happening on your system when you notice the problem? >>> How about iotop? Is there lots of disk usage happening? Are there >>> things like locate or other search aids running in the background to >>> update their databases? Are you updating your system when it seems >>> slow? Is your system memory constrained? Other cron scheduled jobs? >>> This usually is really heavy early in system usage as they build their >>> databases, and then tapers off as only incremental changes are made. >>> >>> It's unlikely to be due to F24, more likely to be due to your situation. > > Personally I'm also interested why the video playback in Firefox is so > horrible. > > I'm using C2D - this is easily capable to play high bitrate FullHD > movies in mplayer. > > Yet it gets chooked by quite low-bandwidth low quality 640-pixel-wide > videos from Youtube. > > Doesn't really matter much if the native h265 codec is used or it's > passed through the oldish 'flash' adobe plugin. > > Looking at 'perf' trace - it obviously spends ages in libxul - and it's > very quickly passing though ffmpeg library used now by 'ff'. > > There is some 'minor' difference between h265/flash playback > smoothness - but none of them is NOWHERE near to be usable. > > So whenever I want to see a video playing fluently without using some > later 4x3GHz i7 CPU - I simply need to download video and play via > mplayer > > I'd love to see some progress here - but it's getting worst with each > new relase of FF - not mentionion 'FF' starts to cut interfaces so less > and less plugins do work. And no I see zero interest of 'ff' group to > solve this issue for Linux - they mostly care purely about windows these > days :( > > > And of course horrible playback is in '-safe-mode' as well - so no > plugin could be accused for this. As well as I'm using -nodebug Fedora > kernels > and latest/greatest SNA xf86 driver. > > Regards > > Zdenek Funny, mplayer by default has the same or similar stuttering that I see in Totem and Firefox. I haven't tried with different draw/acceleration methods (there are plenty), so it's whatever's being used by default. Again, to contrast, VLC video playback is smooth as butter. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Video performance degradation in F24
On 09/11/2016 02:19 PM, stan wrote: > On Sat, 10 Sep 2016 22:04:22 -0400 > Basil Mohamed Gohar wrote: > > >>> On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote: >>>> Even since I installed F24 on both my desktop as well as my laptop >>>> I've noticed a severe performance degradation in terms of video >>>> playback. > > Is this using a browser, or a player on the system, like vlc or mplayer? > What does your 'severe performance degradation' consist of? Dropped > frames? Lock up? Artifacts? Could network congestion or speed be a > factor? Or do you just mean that the gui is slow to respond? > >>>> >>>> I've noticed this performance issue in both MATE (my preferred DE) >>>> as well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an >>>> APU but also has a discrete card as well). >>>> >>>> I don't want to use devel just to report a problem, but I'd also > > This really belongs on users. You can subscribe to users by > sending an email message to > users-requ...@lists.fedoraproject.org > with subscribe in the subject line, and from email address > basilgo...@librevideo.org > >>>> like some help in diagnosing the issue so that a fix can be found >>>> – but unfortunately I don't really know where to start. > > What does top show happening on your system when you notice the problem? > How about iotop? Is there lots of disk usage happening? Are there > things like locate or other search aids running in the background to > update their databases? Are you updating your system when it seems > slow? Is your system memory constrained? Other cron scheduled jobs? > This usually is really heavy early in system usage as they build their > databases, and then tapers off as only incremental changes are made. > > It's unlikely to be due to F24, more likely to be due to your situation. > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > I should add that the problem in Totem and Firefox worsens as the video takes-up more screen space - smaller windows (same resolution source file) render more smoothly. Again, VLC is just fine full screen, no noticeable performance issue. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Video performance degradation in F24
On 09/11/2016 02:19 PM, stan wrote: > On Sat, 10 Sep 2016 22:04:22 -0400 > Basil Mohamed Gohar wrote: > > >>> On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote: >>>> Even since I installed F24 on both my desktop as well as my laptop >>>> I've noticed a severe performance degradation in terms of video >>>> playback. > > Is this using a browser, or a player on the system, like vlc or mplayer? > What does your 'severe performance degradation' consist of? Dropped > frames? Lock up? Artifacts? Could network congestion or speed be a > factor? Or do you just mean that the gui is slow to respond? Okay, I've found the issue is in Firefox and Totem, but not VLC. So, apparently some form of acceleration is borked but not another (guessing). > >>>> >>>> I've noticed this performance issue in both MATE (my preferred DE) >>>> as well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an >>>> APU but also has a discrete card as well). >>>> >>>> I don't want to use devel just to report a problem, but I'd also > > This really belongs on users. You can subscribe to users by > sending an email message to > users-requ...@lists.fedoraproject.org > with subscribe in the subject line, and from email address > basilgo...@librevideo.org > >>>> like some help in diagnosing the issue so that a fix can be found >>>> – but unfortunately I don't really know where to start. > > What does top show happening on your system when you notice the problem? > How about iotop? Is there lots of disk usage happening? Are there > things like locate or other search aids running in the background to > update their databases? Are you updating your system when it seems > slow? Is your system memory constrained? Other cron scheduled jobs? > This usually is really heavy early in system usage as they build their > databases, and then tapers off as only incremental changes are made. > > It's unlikely to be due to F24, more likely to be due to your situation. There's nothing else going on in the systems - this is an upgrade from F22, so there's not any initialization processes going on. I did the upgrade weeks ago, anyway. CPU does spike, but that's normal for this kind of video playback, and it's definitely not maxed-out. > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Video performance degradation in F24
On 09/08/2016 01:27 AM, Benson Muite wrote: > Blog post here may be relevant: > > https://streamcomputing.eu/blog/2016-09-06/transition-period-for-fglrx-to-amdgpurocm-no-kernel-4-4-or-xorg-1-18-support/ > > > Not sure exact hardware you are using, so may not be directly relevant. > If it is, there is a recent Fedora magazine article on applying kernel > patches. > > > > On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote: >> Even since I installed F24 on both my desktop as well as my laptop I've >> noticed a severe performance degradation in terms of video playback. >> One point of note is that I did an upgrade from F22->F23->F24, only >> using F23 for the upgrade process. >> >> I've noticed this performance issue in both MATE (my preferred DE) as >> well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an APU but >> also has a discrete card as well). >> >> I don't want to use devel just to report a problem, but I'd also like >> some help in diagnosing the issue so that a fix can be found – but >> unfortunately I don't really know where to start. Benson, Thank you for that information. However, I don't use fglrx, I've always used the radeon drivers that come standard in Fedora. > [basilgohar@alpha ~]$ lsmod | grep radeon > radeon 1507328 9 > i2c_algo_bit 16384 1 radeon > drm_kms_helper143360 1 radeon > ttm90112 1 radeon > drm 339968 12 ttm,drm_kms_helper,radeon So, unless that issue also means standard open-source kernel drivers are lacking support for the kernel used in F24 (which would seem really very odd), then that particular issue is probably not the reason for my slow video. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Video performance degradation in F24
Even since I installed F24 on both my desktop as well as my laptop I've noticed a severe performance degradation in terms of video playback. One point of note is that I did an upgrade from F22->F23->F24, only using F23 for the upgrade process. I've noticed this performance issue in both MATE (my preferred DE) as well as Gnome. I have AMD CPUs with AMD GPUs (the laptop is an APU but also has a discrete card as well). I don't want to use devel just to report a problem, but I'd also like some help in diagnosing the issue so that a fix can be found – but unfortunately I don't really know where to start. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Rygel and firewalld's UPnP/SSDP handling
After seeing my phone (Samsung Galaxy S III) picking-up some media shared from my mother's Windows 7 laptop and the experience being reasonably positive (it more-or-less worked to play videos), I decided to try my hand at getting this to work in Fedora 22. I've been generally pleased with GNOME vs. MATE this time, so I've stuck with GNOME. The mechanism for sharing media from your desktop is handled through the Sharing menu, which for sharing media, uses rygel via the SSDP protocol (commonly called UPnP). There are a couple[1] of bugs[2] relative to these issues. The first firewalld issue is marked as resolved for F21, but I think the scope is from one Fedora system to another. There are even blog posts[3] celebrating that it's working with a simple toggle, but my shares on my Fedora system are still not visible via UPnP from my phone. There was a lot of confusion and work and research done in all of these issues, and I commend everyone's efforts, but its still not working. I think this is a great feature, because at least in a home environment, I can load-up my desktop with all the audio, video, and other media files we need/want, and then we can access those from our laptops and devices around the house as we go about our daily tasks. This is a use case that I think many families can relate to, and I think will go a long way towards enhancing the common user case for Fedora. I'm sorry if I'm kind of rambling, but after diving into those issues and research the problem both through the web and in the bug tracker, and I'm a little frustrated and I just feel this particular matters needs a concerned, overall effort to resolve the following issues: 1. The (lack of) support for UPnP as commonly available via other operative systems (Yes, I mean mostly Windows, I understand there are outstanding security issues with that). 2. Guides for how to get this working officially in Fedora in common setups (I could start with my own if that helps). There are probably more, and I'm not a strong systems developer, so I don't know how much code I can contribute, but I do want to help in way I can. I've wanted this to work for years, and I'm flustered enough to want to actually do something about it myself now. Anyone have some guidance or suggestions, or did I totally miss something here? [1] https://bugzilla.redhat.com/show_bug.cgi?id=626188 [2] https://bugzilla.redhat.com/show_bug.cgi?id=892801 [3] http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SSH server always terminating after some time
On 11/14/2014 08:49 AM, Florian Weimer wrote: > On 11/14/2014 02:46 PM, Basil Mohamed Gohar wrote: > > The only non-standard thing I can think I'm doing is running SSH on > > another port, and I've already gotten SELinux to accept that fact. The > > issue is not that it won't even connect. It's that it goes down without > > any logical explanation. The most I get from the log files > > (/var/log/secure) is this: > > > > Nov 9 12:04:29 alpha sshd[25259]: Received signal 15; terminating. > > Do you see anything in the journal (view it with journalctl -a) related > to that time frame? > Thanks for the tip. I'll skim through this and report back if I find anything interesting. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
SSH server always terminating after some time
I have found that in Fedora 20 I've been unable to keep my SSH server at my home up for long periods of time. I will enable it with systemctl and start it, and it will work for a time, but then later days (after, maybe, 3 or so days) it will be unavailable and I'll have to restart it. The only non-standard thing I can think I'm doing is running SSH on another port, and I've already gotten SELinux to accept that fact. The issue is not that it won't even connect. It's that it goes down without any logical explanation. The most I get from the log files (/var/log/secure) is this: Nov 9 12:04:29 alpha sshd[25259]: Received signal 15; terminating. But I have no idea why it terminated (except that it's close to midnight?) and especially don't know why it won't start back up again. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Multiple problems with multiple monitors
On 2014-10-13 10:23 AM, Basil Mohamed Gohar wrote: > I've searched for bugs related to the specific problems I've been having, and > I've not been able to find anything that describes what I'm seeing. > > I have an HP EliteBook 840 that also comes with an UltraDock, to which I've > plugged-in two external monitors and I use in conjunction with the built-in > laptop display. > > Issue #1: I use LUKS to encrypt my disk, and when I first start up the > computer, after choosing the kernel to boot into in GRUB, the GUI prompt for > the LUKS passphrase shows-up on the middle monitor, not the laptop's built-in > display. I don't mind this when I have multiple monitors plugged-in, but when > I boot-up without the external monitors, such as when I'm unplugged from the > UltraDock, I now get NO GUI prompt for the LUKS passphrase. I can enter it, > and I can see a text prompt if I hit ESC. I suspect its attempting to display > on the now phantom, unplugged monitor. Note, it was never plugged-in during > this cycle. The problem is, I don't even know what's instructing LUKS or the > GUI prompt to display on any monitor, so I don't know where to go to debug > this. > > Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. > When I redock after the laptop has been started when unconnected, one of the > two external monitors start-up (the one connected by VGA), but not the one > connected by a DisplayPort connection. And, recently (but not when I first > started using this laptop with the dock, which was about a month ago), now > when I start-up with the laptop docked and both external monitors connected, > both external monitors will be active, but the built-in display will show > nothing. Gnome Shell reports the built-in display is active, but will not > display anything unless I deactivate it and reactivate it via the settings > "Displays" utility. > > Issue #3: The monitor connected via DisplayPort display significant tearing > and delay on the upper-right half of the screen in the form of a triangle > taking-up half of the screen. Reading about displayport and tearing issues, I > guess the idea that these were resolved in the past. I don't know if this is > the same or something different. > > I don't mean to use devel as a bug reporting venue, but I think these issues > are either related or I just don't know how to address them to make > significant progress to fixing them. Any guidance is more than welcome. > Thanks! > > -- > Libre Video > http://librevideo.org So, a recent update which included a kernel update fixed issue #2, and I was really happy. Then, another update this week, which included multiple systemd updates, restored/rebroke issue #2 above (the docking/undocking) issue. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Multiple problems with multiple monitors
On 2014-10-13 05:18 PM, David Airlie wrote: I've searched for bugs related to the specific problems I've been having, and I've not been able to find anything that describes what I'm seeing. I have an HP EliteBook 840 that also comes with an UltraDock, to which I've plugged-in two external monitors and I use in conjunction with the built-in laptop display. What Fedora distro are you using? Does this laptop have multiple GPUs? what GPU is it etc. You probably should file a bug against the primary GPU with the dmesg. Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. When I redock after the laptop has been started when unconnected, one of the two external monitors start-up (the one connected by VGA), but not the one connected by a DisplayPort connection. And, recently (but not when I first started using this laptop with the dock, which was about a month ago), now when I start-up with the laptop docked and both external monitors connected, both external monitors will be active, but the built-in display will show nothing. Gnome Shell reports the built-in display is active, but will not display anything unless I deactivate it and reactivate it via the settings "Displays" utility. This sounds like MST releated but I can't say without more info. Dave. Completing my previous message with the requested information. Here is the GPU info as given by lspci: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8730M] I am running Fedora 20 on this laptop. From lshw output: product: HP EliteBook 840 G1 (D1F43AV) vendor: Hewlett-Packard version: A3009DD10303 So that I understand, should I file a bug against dmesg mentioning the Intel GPU listed above? And what other information do you need from me regarding the MST point above? I'm happy to provide whatever I can. Thanks again! -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Multiple problems with multiple monitors
On 10/13/2014 05:18 PM, David Airlie wrote: > >> >> >> I've searched for bugs related to the specific problems I've been having, and >> I've not been able to find anything that describes what I'm seeing. >> >> I have an HP EliteBook 840 that also comes with an UltraDock, to which I've >> plugged-in two external monitors and I use in conjunction with the built-in >> laptop display. > > What Fedora distro are you using? > > Does this laptop have multiple GPUs? what GPU is it etc. > > You probably should file a bug against the primary GPU with the dmesg. > >> Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. >> When I redock after the laptop has been started when unconnected, one of the >> two external monitors start-up (the one connected by VGA), but not the one >> connected by a DisplayPort connection. And, recently (but not when I first >> started using this laptop with the dock, which was about a month ago), now >> when I start-up with the laptop docked and both external monitors connected, >> both external monitors will be active, but the built-in display will show >> nothing. Gnome Shell reports the built-in display is active, but will not >> display anything unless I deactivate it and reactivate it via the settings >> "Displays" utility. > > This sounds like MST releated but I can't say without more info. > > Dave. > Thanks, Dave, I was hoping you'd see this. :) The laptop has two GPUs, one Intel and the other Radeon. I am not sure how to tell which display is controlled by which device. It is Fedora 20. I can get you more details when I get back to work tomorrow. I'm happy to provide whatever information is necessary, but that is part of the problem, I'm not sure what is useful to help figure this out. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Multiple problems with multiple monitors
I've searched for bugs related to the specific problems I've been having, and I've not been able to find anything that describes what I'm seeing. I have an HP EliteBook 840 that also comes with an UltraDock, to which I've plugged-in two external monitors and I use in conjunction with the built-in laptop display. Issue #1: I use LUKS to encrypt my disk, and when I first start up the computer, after choosing the kernel to boot into in GRUB, the GUI prompt for the LUKS passphrase shows-up on the middle monitor, not the laptop's built-in display. I don't mind this when I have multiple monitors plugged-in, but when I boot-up without the external monitors, such as when I'm unplugged from the UltraDock, I now get NO GUI prompt for the LUKS passphrase. I can enter it, and I can see a text prompt if I hit ESC. I suspect its attempting to display on the now phantom, unplugged monitor. Note, it was never plugged-in during this cycle. The problem is, I don't even know what's instructing LUKS or the GUI prompt to display on any monitor, so I don't know where to go to debug this. Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. When I redock after the laptop has been started when unconnected, one of the two external monitors start-up (the one connected by VGA), but not the one connected by a DisplayPort connection. And, recently (but not when I first started using this laptop with the dock, which was about a month ago), now when I start-up with the laptop docked and both external monitors connected, both external monitors will be active, but the built-in display will show nothing. Gnome Shell reports the built-in display is active, but will not display anything unless I deactivate it and reactivate it via the settings "Displays" utility. Issue #3: The monitor connected via DisplayPort display significant tearing and delay on the upper-right half of the screen in the form of a triangle taking-up half of the screen. Reading about displayport and tearing issues, I guess the idea that these were resolved in the past. I don't know if this is the same or something different. I don't mean to use devel as a bug reporting venue, but I think these issues are either related or I just don't know how to address them to make significant progress to fixing them. Any guidance is more than welcome. Thanks! -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 04/10/2014 01:23 PM, Peter Oliver wrote: > On 9 April 2014 22:10, Florian Festi wrote: >> >> On 04/09/2014 08:42 PM, Bill Nottingham wrote: >>> Given the number of packages that ship localization, this seems like it >>> would have a pretty dramatic effect on metadata size. Is this a concern? >> >> Meta data is a concern. But the major part of the meta data is file data >> and change logs. Everything else is less than 10%. So doubling or even >> tripling this part won't hurt. > > What about performance? I don't have any figures, but my feeling was > that TeX seemed to update awfully slowly after it was split into many > small packages. > If package metadata is a problem, what if we split up the repositories and allocate some, that we can deem to be, to some degree, optional, to be for these less-than-mandatory packages. So, for example, if the extra languages packages are put into their own repository. This would, of course, be unfair to the languages that are not considered main, and this would likely heavily be biased towards English given it probably has the widest coverage. But what if manpages were in their own repository? I guess my point is, can we spread the problem out across semi-optional repositories and handle dependencies in a soft a way such that they'll be installed if they are present [i.e., the repository(-ies) with the given dependency(-ies) is/are present] but then the install continues without a problem except maybe a gentle notice that there exist optional dependencies so someone can choose to enable the associated repositories? I don't know if this will introduce more problems than it solves, but for the typical 1TB+ desktop user of Fedora, we can enable pretty-much all of these "optional" repositories, and for the embedded and/or minimal/micro installs, these optional repositories can be left unenabled. I think this would require fewer changes to the dependency logic and RPM itself than, say, a complicated set of flags and package labeling/tagging. P.S. Please forgive me if I use terms that might have specific meaning to the packaging team (maybe tagging means something I don't intend in that context, I'm using it generically). -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 04/09/2014 03:33 AM, Marius A wrote: > > I think less than 0.1% of users ever look into /usr/share/doc, but I > don't have any data to back this up. I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just "documentation". For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. I don't know what the standard is for defining what, if anything, should be placed under /usr/share/doc, but as it stands now, we should at least know and acknowledge that it's not just READMEs and HTML files when we make the decision to not install it by default or to reduce the chance that it's installed. Having said that, I am all for saving space on a default install and/or making a more minimal install possible. I noticed just now that manpages are compressed, but with gz. I am sure this discussion has already happened, but maybe we can have an alternative man-xz format that will reduce the size of the individual packages for a Fedora Minimal or somesuch (I think manpages should be very, very far down on the list of what to be left out from an install, as they are sometimes the last resort on what to do). My two bits on the idea. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages have "proxy" word.
On 11/02/2013 12:46 PM, Eric Sandeen wrote: > On 11/2/13 10:50 AM, Kevin Kofler wrote: >> مصعب الزعبي wrote: >>> Then do new rule to write "proxies" instead of proxy, at Fedora packaging >>> guidlines. >> >> Renaming packages, censoring descriptions etc. in Fedora at the whims of >> governments (of countries Fedora isn't supposed to be exported to in the >> first place) is not going to happen. Sorry. >> >> Kevin Kofler >> > > I think your answer conflates two issues. > > If Syria is on the export control list, there's really no further discussion > to be had. > > But I wonder how many i.e. school nanny-filters ban URLs with the word > "proxy," and how that impacts the ability of users in any country to obtain > Fedora. > > The idea of an alternate URL using package hashes seemed reasonable to me, > to route around that sort of internet damage. > > -Eric > I think the solution in this case, that would require zero change to package names, and likely little else, would be to offer a way to choose only those repos that offer an https interface. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On 08/28/2013 10:41 AM, Solomon Peachy wrote: > On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote: >> Sorry to come out of left field like this, but would the system profile >> info we collect on install be useful in determining the weight of the >> need for some of these drivers? For example, if there is still a bunch >> of SIS video adapters out there, we might prioritize support for that >> driver, but then not for others that don't show-up in our hardware surveys. > > Another way to look at it is the platform capabilities of these graphics > devices. For example, Fedora 19's release notes claims a minimum of 1GB > RAM is required. Were there any pre-PCIe platforms capable of > supporting this much RAM? Plenty! The common limitation in the pre-PCIe era was 2GB or 4GB (e.g., common 32-bit architecture memory limits). I have several that are non-PCIe and have 2GB of RAM. They run Fedora just fine. They do, however, have more modern AGP-based video cards installed, however. I haven't bothered with the embedded video adapter on them, so I cannot speak to their suitability for running Fedora 19. > > Ditto on the embedded graphics (eg SiS or i810 etc) -- many of those > platforms had serious RAM limitations too. I have a pile of old P4+i845 > boxes stacked in a corner that max out at 512MB (due to chipset > limitations) which isn't even enough RAM to boot the Fedora installer in > text mode. > > On the other hand, graphics chips that were available on PCI add-in > cards could theoretically be used on modern systems, so those may be > worth continuing to support. > > - Solomon I just wanted to comment about the memory issue. I cannot say much else about the rest here. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On 08/27/2013 11:20 AM, Adam Jackson wrote: > On Tue, 2013-08-27 at 14:54 +, "Jóhann B. Guðmundsson" wrote: > >> Is it not better to drop entirely graphics drivers that do not have kms >> support and at the *same time* adopt the policy >> >> "From this point forward only graphics driver that have kms support will >> be allow to be packaged and shipped in the distribution" > > I don't know why that would be "better". There's no intrinsic reason > why we should forbid UMS drivers if there's a maintainer, it doesn't > necessarily make my life harder to allow that. And, given that the list > _does_ include hardware that people have filed bugs about in recent > memory, I figure I should allow those interested in to step forward. > > - ajax > Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys. Perhaps this step has already been taken. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning Blueman
As long as we're reminiscing, for what it's worth, Blueman was the *only* way I could reliably get A2DP/High quality audio to work with my wife's Bluetooth headphones (Nokia BH-503) until Fedora 19. It is a nice utility, no doubt, but now I can get the behavior I want/need using just the MATE Bluetooth tools and Pulseaudio's GUI configuration (to select between A2DP and headset mode). If it's not being maintained upstream, and if it's functionality is duplicated, it seems as though it might be time to retire it. I really liked seeing the real-time Bluetooth network/bandwidth usage, though. Something us geeks love, I suppose. :) -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dependency issue with some mate packages
On 06/12/2013 11:06 AM, Kevin Fenzi wrote: > On Wed, 12 Jun 2013 09:12:07 +0200 > Rave it wrote: > >> See https://bugzilla.redhat.com/show_bug.cgi?id=972548 >> >> This update should fix the dependency issue. >> mate-desktop-1.6.1-7.fc18 has been pushed to the Fedora 18 stable >> repository. >> >> mate-vfs and mate-mime-data is obsolete with MATE-1.6, you can savely >> remove this packages by hand. 'yum remove mate-vfs-smb mate-vfs-devel >> mate-mime-data-devel' Than do yum update again. > > Having to manually remove packages to update is not very ideal. ;( > > If these have completely gone away, perhaps you could obsolete them in > one of the core mate packages? > > Also, the comment in that bug with: > > "you may lose all your customizations by upgrading to 1.6" is a bit > troubling. Perhaps this shouldn't be pushed to a stable release? > > kevin > > > In my case, that was not necessary. A `yum upgrade` after that update was pushed went through without a problem. I did not need to uninstall any packages for the update to work after that. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dependency issue with some mate packages
I cannot update with yum upgrade due to some dependency issues related, it seems, to the mate-desktop package obsoleting a few other packages. I am including the full output because results can be related to loaded-plugins and possibly 3rd-party repositories. It seems that some *-devel packages are not being updated, while their binary/executable counterparts are, leading to the conflict. This has been an issue since at least last week. I tried running yum clean all over several days in case the error was caught and corrected already, or if it was due to an outdated mirror, but it appears to still be an issue. Here is the output when I attempt to run yum upgrade: [root@alpha ~]# time yum upgrade Loaded plugins: langpacks, presto, priorities, refresh-packagekit adobe-linux-x86_64 | 951 B 00:00:00 fedora/18/x86_64/metalink | 21 kB 00:00:00 fedora | 4.2 kB 00:00:00 fedora-chromium-stable | 3.4 kB 00:00:00 rpmfusion-free | 3.3 kB 00:00:00 rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 updates/18/x86_64/metalink | 16 kB 00:00:00 updates | 4.6 kB 00:00:00 (1/3): fedora-chromium-stable/primary_db | 20 kB 00:00:00 (2/3): updates/primary_db | 9.5 MB 00:00:05 (3/3): fedora/primary_db | 17 MB 00:00:07 (1/5): adobe-linux-x86_64/primary | 1.2 kB 00:00:00 (2/5): rpmfusion-nonfree-updates/primary_db | 133 kB 00:00:00 (3/5): rpmfusion-nonfree/primary_db | 147 kB 00:00:00 (4/5): rpmfusion-free-updates/primary_db | 330 kB 00:00:00 (5/5): rpmfusion-free/primary_db | 447 kB 00:00:00 fedora/group_gz | 368 kB 00:00:00 rpmfusion-free/group_gz | 1.7 kB 00:00:00 rpmfusion-free-updates/group_gz | 1.6 kB 00:00:00 rpmfusion-nonfree/group_gz | 1.0 kB 00:00:00 rpmfusion-nonfree-updates/group_gz | 986 B 00:00:00 updates/group_gz | 388 kB 00:00:00 adobe-linux-x86_64 2/2 Resolving Dependencies --> Running transaction check ---> Package LibRaw.x86_64 0:0.14.7-4.fc18 will be updated ---> Package LibRaw.x86_64 0:0.14.8-2.fc18 will be an update ---> Package audit.x86_64 0:2.3-2.fc18 will be updated ---> Package audit.x86_64 0:2.3.1-2.fc18 will be an update ---> Package audit-libs.i686 0:2.3-2.fc18 will be updated ---> Package audit-libs.x86_64 0:2.3-2.fc18 will be updated ---> Package audit-libs.i686 0:2.3.1-2.fc18 will be an update ---> Package audit-libs.x86_64 0:2.3.1-2.fc18 will be an update ---> Package audit-libs-python.x86_64 0:2.3-2.fc18 will be updated ---> Package audit-libs-python.x86_64 0:2.3.1-2.fc18 will be an update ---> Package calligra-kdchart.x86_64 0:2.6.3-1.fc18 will be updated ---> Package calligra-kdchart.x86_64 0:2.6.4-1.fc18 will be an update ---> Package fedora-bookmarks.noarch 0:15-0.4 will be updated ---> Package fedora-bookmarks.noarch 0:15-2.fc18 will be an update ---> Package flash-plugin.x86_64 0:11.2.202.285-release will be updated ---> Package flash-plugin.x86_64 0:11.2.202.291-release will be an update ---> Package gnutls.i686 0:2.12.23-1.fc18 will be updated ---> Package gnutls.x86_64 0:2.12.23-1.fc18 will be updated ---> Package gnutls.i686 0:2.12.23-2.fc18 will be an update ---> Package gnutls.x86_64 0:2.12.23-2.fc18 will be an update ---> Package gnutls-c++.x86_64 0:2.12.23-1.fc18 will be updated ---> Package gnutls-c++.x86_64 0:2.12.23-2.fc18 will be an update ---> Package gnutls-devel.x86_64 0:2.12.23-1.fc18 will be updated ---> Package gnutls-devel.x86_64 0:2.12.23-2.fc18 will be an update ---> Package gnutls-utils.x86_64 0:2.12.23-1.fc18 will be updated ---> Package gnutls-utils.x86_64 0:2.12.23-2.fc18 will be an update ---> Package im-chooser.x86_64 0:1.6.2-1.fc18 will be upd
Re: Installing on old systems with only PATA/IDE hard drives
On 05/13/2013 12:50 AM, John Reiser wrote: >> Any tips >> on what I can do to make a proper report out of this would be most >> appreciated, or just let me know if installs to PATA/EIDE systems are >> just no longer supported. > > I've got a i686 box with only PATA, and two root partitions of F19-Alpha-i386; > one via netinst+network, one via netinst+USB. (The box cannot boot via USB.) > Both roots have been "yum update" daily with updates-testing. > > The anaconda installer keeps its log files in /tmp, and you should attach > those files to a bug report. 'scp' them to another system (the network > will be up if the installer gets that far). Or, copy to a USB stick > then move that USB stick to another system. Then file the bug report. > > Change to console VT2 by typing where is Function key F2. > dmesg (or tail /tmp/syslog) to determine which /dev/sdX is the USB stick > mkdir /stick > mount /dev/sdX1 /stick > cd /stick > mkdir MMDDa # such as '0513a'; probably you're going to be doing this > more than once > cd 0513a > cp /tmp/* . # ignore the directories; you want the top-level files > sync > cd /tmp > umount /stick > Change back to installer graphics with . > Thanks, John. I'll try my best to follow these steps the next time I go through the install, and see what I can get. I'll put it all in a bug report, most likely. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Installing on old systems with only PATA/IDE hard drives
I thought that this might be an issue with incompatible hardware, as I was trying to install Fedora 18 on an old Dell (Celeron D processor) I'd bought for my mother that she was no longer using. However, I got an error when attempting to install when the process was probing the drives. I thought maybe it was something wonky with the Dell hardware, so I ignored it for the time being, as the only results when searching online were apparently older, seemingly unrelated bugs fixed in previous kernel commits. However, I ran into the same problem when attempting to install to a more recent AMD 64-bit system that I'd put together (and which has had older versions of Fedora installed on, but I cannot remember which at this time), but which still stalled at the same point during the install. In both cases, the install process dropped to the dracut emergency prompt, and in both cases, I was attempting to install from a USB stick. The USB stick image was verified in both cases, as well. The same issue happened with both DVD images as well as netinst images. I tried with both F18 and F19 Alpha. Both systems were installing to an 80GB EIDE/PATA hard drive. I encountered the same problem attempting to install to a 20GB drive as well. It's a little challenging because the disk is inaccessible, and I could not figure-out how to save the install log up to that point. Any tips on what I can do to make a proper report out of this would be most appreciated, or just let me know if installs to PATA/EIDE systems are just no longer supported. I could not find any language addressing this issue online, but that could be just insufficient Google-Fu. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mate-file-archiver dependency problems
On 02/21/2013 12:31 AM, Dan Mashal wrote: > > On Feb 20, 2013 6:29 PM, "Basil Mohamed Gohar" > mailto:basilgo...@librevideo.org>> wrote: > > > > For a while now the package "mate-file-archiver" has had a > dependency problem and cannot be updated. I've opened a ticket about > it (https://bugzilla.redhat.com/show_bug.cgi?id=908137) but it has > received no response for over two weeks. I am not sure that the > package is terribly important, but it is installed (probably because I > did something like `yum install mate-*`. > <https://admin.fedoraproject.org/mailman/listinfo/devel> > > Sorry for that. Will look into it asap. > > Dan > Thanks! I see the activity in the bug report now. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mate-file-archiver dependency problems
For a while now the package "mate-file-archiver" has had a dependency problem and cannot be updated. I've opened a ticket about it (https://bugzilla.redhat.com/show_bug.cgi?id=908137) but it has received no response for over two weeks. I am not sure that the package is terribly important, but it is installed (probably because I did something like `yum install mate-*`. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld and Ekiga
On 12/27/2012 11:40 AM, Antonio wrote: > Il 27/12/2012 16:27, Basil Mohamed Gohar ha scritto: > > On 12/27/2012 10:09 AM, Antonio wrote: > >> Hello everyone. > >> > >> Currently I use the latest version of Ekiga on Fedora 18 > >> Spherical Cow. My internet connection implicates an outdoor > >> antenna equipped with a management software that includes a > >> firewall (as well as other services like NAT, UPnP, DDNS, ...); > >> this firewall has been configured to allow the SIP calls from and > >> to Ekiga according to these information > >> http://wiki.ekiga.org/index.php/Internet_ports_used_by_Ekiga. > >> > >> Even the firewall of Fedora is actived but it doesn't seem > >> affect Ekiga work although its ports are not open nor any SIP > >> services are permitted. > >> > >> The current enabled zone is 'home': > >> > >> home interfaces: wlan0 services: ipp-client mdns dhcpv6-client > >> ssh samba-client ports: forward-ports: icmp-blocks: > >> > >> In your opinion, is it a correct behavior when Ekiga works > >> although firewalld closes all ports ? > >> > >> Thanks. > >> > > Antonio, > > > If your SIP connection is using a STUN server, then it is > > possible. > > > Precisely (sorry I had not mentioned this). > But should not be all connections blocked between application (ekiga) > and antenna's NAT ? > Someone with more networking experience than me should probably reply, but I believe incoming connections (relative to your system, that is) are what is blocked. And I think the usage of a STUN server allows your system to effectively initiate only "outgoing" connections as far as your firewall is concerned, much as how so-called passive FTP works in the same way. Connections initiated from your end are much lower risk, if you intended them, and as such are usually allowed by firewalls. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld and Ekiga
On 12/27/2012 10:09 AM, Antonio wrote: > Hello everyone. > > Currently I use the latest version of Ekiga on Fedora 18 Spherical Cow. > My internet connection implicates an outdoor antenna equipped with a > management software that includes a firewall (as well as other > services like NAT, UPnP, DDNS, ...); this firewall has been configured > to allow the SIP calls from and to Ekiga according to these > information http://wiki.ekiga.org/index.php/Internet_ports_used_by_Ekiga. > > Even the firewall of Fedora is actived but it doesn't seem affect > Ekiga work although its ports are not open nor any SIP services are > permitted. > > The current enabled zone is 'home': > > home > interfaces: wlan0 > services: ipp-client mdns dhcpv6-client ssh samba-client > ports: > forward-ports: > icmp-blocks: > > In your opinion, is it a correct behavior when Ekiga works although > firewalld closes all ports ? > > Thanks. > Antonio, If your SIP connection is using a STUN server, then it is possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why samba-client not installed by default?
On 12/19/2012 12:00 PM, Richard Shaw wrote: > On Wed, Dec 19, 2012 at 10:58 AM, drago01 wrote: >> On Wed, Dec 19, 2012 at 3:37 PM, Reindl Harald >> wrote: >>> >>> Am 19.12.2012 15:29, schrieb Ozan Çağlayan: On Wed, Dec 19, 2012 at 4:08 PM, Reindl Harald wrote: > because most people the days are using network-printers > even the cheap HP printers having WLAN/LAN and working without > any windows crap Agree but it doesn't change the fact that there are still plenty of printers shared through Windows. >>> maybe, but you have to read manuals all the time and can not >>> expect to have anything working out-of-the-box, there are >>> even people not owning a printer at all >> I disagree you should not have to read manuals all the time to do >> basic tasks like printing. >> >> @Ozan: File a bug and ask for the dep to be added. > I think printing should be something that just works as well but there > is a significant space cost to adding samba-client: > > # yum info samba-client > Loaded plugins: auto-update-debuginfo, changelog, presto, refresh-packagekit, > : remove-with-leaves, rpm-warm-cache > Installed Packages > Name: samba-client > Arch: x86_64 > Epoch : 2 > Version : 3.6.9 > Release : 96.fc17.1 > Size: 39 M > Repo: installed > From repo : updates > Summary : Samba client programs > URL : http://www.samba.org/ > License : GPLv3+ and LGPLv3+ > Description : The samba-client package provides some SMB/CIFS clients to > : complement the built-in SMB/CIFS filesystem in Linux. These > : clients allow access of SMB/CIFS shares and printing to SMB/CIFS > : printers. > > Perhaps there's a way to support SMB printing without 39MB of > additional disk usage? > > Richard Alternatively, maybe the dialog that searches for network printers can offer the option to install the necessary packages when first loaded, if the user has a way to indicate that their particular network printer was not found. More work, possibly the best compromise. I imagine this behaving in much the same was as searching for and installing drivers for printers would within the very same user-facing application. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: postfixadmin
On 07/01/2012 06:34 AM, Christopher Meng wrote: Who intend to package this?This software is useful and helpful for server admins. -- Best Regards, Christopher Meng--'Cicku' Ambassador/Contributor of Fedora Project and Contributor of GNU. Blog:http://cicku.me Twitter:@cickumqt Hope you can visit and leave some comments. More Contact info see here:http://about.me/cicku I think there is a newer, more up-to-date version of the same thing in the form of ViMbAdmin: https://github.com/opensolutions/vimbadmin/wiki I personally use this one after searching for something that does what Postfix Admin does. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On 06/24/2012 05:07 PM, Jef Spaleta wrote: On Sun, Jun 24, 2012 at 12:45 PM, Jef Spaleta wrote: Users with existing revelation configurations can blow away .gconf/apps/revelation and relogin to avoid the errors and reconfig revelation in the process. But clearly that is not optimal. If there is a packaging mechanism that I can use..I'm all ears. Replying to myself... it looks like the gconf schema handling scriptlets in this package has been busted for a long time. I'll spin up a new scratch build with adjusted scripted actions and see if that fixes the problem. Thanks for the breakage report Tom it helped point me in the correct direction. -jef I just wanted to say I'm glad someone is looking into updating Revelation and addressing these issues, as I've been using it for a long time and would like to continue doing so. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora remixes and Microsoft's secure booting crapola
On 05/31/2012 10:26 PM, Arun SAG wrote: I have been reading about secure boot. I understand that we are going to pay Microsoft to get our keys signed. Will this change affect people creating remixes? What about kernel modules from third party repositories like rpmfusion? Will it be affected? Not sure if you were subscribed to the list earlier, but there's a thread titled, "*countable infinities only" that discusses this exact point. The link to the online archives is here: https://lists.fedoraproject.org/pipermail/devel/2012-May/167605.html (Note that the first e-mail in that archive somehow got corrupted when being archived.) -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:53 PM, Gerry Reno wrote: > On 05/31/2012 12:51 PM, Matthew Garrett wrote: >> On Thu, May 31, 2012 at 12:49:53PM -0400, Gerry Reno wrote: >>> The issue could be solved by having the SecureBoot default setting depend >>> on the OS being booted: >>> >>> SecureBoot should only be Default:ON for Microsoft OS's and any other OS's >>> that want to deal with that >>> >>> and should be Default:OFF for all others. >> How do you distinguish between a non-Microsoft OS and a piece of malware >> that will then boot a Microsoft OS? >> > The Microsoft OS should refuse to boot if it is being invoked in an > unauthorized manner. > > . I take it that virtualization of the OS is completely off the table as well, then? (I think it must be, if this is the case.) -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:21 PM, Bill Nottingham wrote: > Basil Mohamed Gohar (basilgo...@librevideo.org) said: >>> Remove Microsoft's keys, problem solved. >> Ah, yes, but then you also won't be able to run Fedora, under the >> currently proposed solution. Oops! See how slick the slope is? > If you're dumb enough to 1) remove all the keys without putting a new key > in, and 2) leave secure boot enabled, sure. I'm not sure that's a case worth > solving for. > > Bill > Your explanation and Greg's made that clear to me, thanks. I see how that doesn't make any sense now, except in cases where the secure boot cannot be disabled, but keys may still be removed. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:18 PM, Miloslav Trmač wrote: > On Thu, May 31, 2012 at 6:16 PM, Gerry Reno wrote: >> On 05/31/2012 12:13 PM, Miloslav Trmač wrote: >>> On Thu, May 31, 2012 at 6:04 PM, Gerry Reno wrote: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement SecureBoot is not about security. It is about restriction. >>> That is just untrue. SecureBoot can be used to make sure you only run >>> the software you intended to run, which is impossible without >>> SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, >>> the technology is or can be made solid. >> No. The user is not in control here. Microsoft is in control. > Remove Microsoft's keys, problem solved. > Mirek Ah, yes, but then you also won't be able to run Fedora, under the currently proposed solution. Oops! See how slick the slope is? -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:06 PM, Peter Jones wrote: > On 05/31/2012 12:04 PM, Gerry Reno wrote: >> SecureBoot is not about security. It is about restriction. > > If you're looking for a mantra to recite ad infinitum, that's a fine > one, but > right now we're looking for ideas that are helpful and productive > instead. > It's very difficult to have this conversation if all the points about the principles of freedom upon which Fedora was founded, operates on, and is known for, are simply swept under the rug because they've passed some threshold of inconvenience that is not immediately apparent. We understand there is a solution, right now, for the main project and its releases that is "workable". It's cost $99, assuming that the license will be granted (which it surely will be, at first, to spur adoption of TC). But there will likely come a time when this solution will not work, for whatever reasons (think, Red Hat and Microsoft get into a legal tussle, or some security breach is brought to light making it seem like Red Hat is unreliable to get their bootloader signed anymore). Then, Fedora is in the same boat as everyone else, and we're left with no solution. By facing the problem in the same way as others will be forced to, Fedora as a whole project will be encouraged to fight for a solution that is equally accessible to others, as it is to them. This is, from the outside, what would be the most fair, sustainable, and congruent with the principles that Fedora has, so far, attempted to maintain. I'm sorry if this doesn't sound as pragmatic as "we just make a deal with the devil, just this once, and work on a better, long-term solution later". Anything else I would like to say has already been said elsewhere, so I hope those arguments don't just get swept under the rug as well. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 10:52 AM, Chris Adams wrote: > Once upon a time, Gregory Maxwell said: >> Under this model there will be two classes of distributor: One which >> loads easily on systems, and one which requires the additional effort >> of disabling secure boot or installing user keys. (And ARM will be >> even more interesting...) > The basic fact is that Microsoft drives the desktop x86 PC market. > Nobody else has the power they do, and that isn't going to change any > time soon. They are creating the two classes you describe. The > hardware is coming (like it or not), and Fedora can either change to > deal with it or not. > > If Fedora does nothing different than is being done today with F17, it > will always be in the second class, requiring the user to disable secure > boot. Even getting to the point where the user can generate/install > their own key requires more work. > > Once the work has been done to support signing with a user-generated > key, it isn't that much more of a step to get the Fedora-provided > binaries signed with a key that allows the distribution to step up to > your first class, where it will load easily on systems. > This is the crux of the issue at hand. It's that the rights and freedoms available to the original distribution will not be transitive to the users themselves, which, until now, has always been the case. This will exclude a whole class of usages that are currently available to Fedora users, such as the ReSpin projects that Fedora Unity used to produce from stock Fedora packages as well as any other downstream projects that build on Fedora. This is not something affecting only a limit set of cases. It's a major change to the ecosystem around Fedora. More importantly, it's a direct attack on the principles of the Fedora project. Fedora has always taken a strong (almost the strongest) stance on not including non-free software, and this stance has resulted in an amazing amount of work put into free-and-open alternatives to otherwise closed options, such as drivers, applications, and otherwise. This stance has ensured that the freedom that the Fedora Project enjoys transfers to everyone using Fedora downstream, whether an individual user, a developer, or an entirely different project. By caving before this really becomes an issue, the "pain" involved will not be felt as deeply, and thus work to get around the technical barriers presented by the secure boot initiative to freedom will be stifled at a much earlier stage. More importantly, this sets the tone that the right way to deal with this is to cave to the more powerful market forces rather than come-up with a more freedom-friendly alternative that provides as good or a better solution to the problem at hand. This is a matter of principle, and to look at it in any way different is to undermine the operating premises for many that Fedora is really about. I'm not in a position at this point to provide a specific solution to this, but Windows 8 is not even out yet. Fedora, Red Hat, and others may still have the option of putting pressure on either Microsoft or other entities (hardware manufacturers) to change how this is implemented to prevent the lockout that the key requirement causes in its current state. But announcing support for it before it's even in real systems widely is premature only serves their interests, not ours. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
