Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 25/03/14 03:00 AM, Michael Catanzaro wrote: On Mon, 2014-03-24 at 17:14 -0700, Adam Williamson wrote: Saying that nobody wants this, it's madness, totally wacky, almost all users are NOT going to put up with this is going rather too far. I think it's entirely worth the Desktop product making this possible and I suspect quite a lot of people will use it, but I don't think it's sufficient grounds for downgrading the spins too far in importance or dropping them. That language was probably too harsh, sorry. Let's try again: I think a large (or huge) subset of users will be dissatisfied with the procedure for installing alternate desktops through GNOME Software, and will opt to not install Workstation at all. I don't think this will be a surprise to anybody. As long as we still have spins, it's not really a big deal. The question this brings up then is: what's the point of Workstation then? (We have come full circle back to this question...) Regards, Dariusz -- 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: New UEFI guide on the wiki
On 05/02/14 05:46 PM, Przemek Klosowski wrote: On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to boot OS. Dariusz -- 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: Following MPI packaging guidelines
On 24/07/13 05:04 PM, Antonio Trande wrote: This phrase in MPI guidelines is little clear for me: Software that supports MPI MUST be packaged also in serial mode [i.e. no MPI], if it is supported by upstream. What does mean serial mode ? :) Serial in this case means non-parallel, running without MPI. Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hang on reboot with Fedora 19 (after software upgrades)
On 07/07/13 05:50 PM, Florian Weimer wrote: * Dan Fruehauf: Alt+F1, Alt+F2, any VTs loaded? Nope, and systemd isn't spawning shells anymore. I guess I have to reboot and save what's still there. Possibly linked to it: I had similar situation last night after reboot with new packages and updates installed. I installed from KDE from DVD image, then added 'Development and Creative Workstation' group and all current updates. After reboot login took me to Gnome fist time configuration. Confused, I wanted to login on a VT but there was none available, all I got was a cursor at the left right corner of the screen, no text, no login prompt. After I finished the configurator, logged out of Gnome, and logged into KDE, I see VTs work again. Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/05/13 08:40 AM, Pierre-Yves Chibon wrote: On Sat, 2013-05-04 at 15:22 -0700, Dan Mashal wrote: Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ). Straw man argument. So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users. Absolutely wrong. Well constructed arguments, with very nice examples... Michael proposes here a sort of middle ground, using the studies from different sources (referenced) and the apparent wish of the maintainer to go this way. I would like to point out that, as Adam Williamson nicely written in his analysis of the references quoted earlier in this thread, it's hard to call any of the references as studies -- most of them are opinions and not widely accepted either. -- Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with F17 yum requesting old repodata?
On 24/11/12 05:37 AM, Chris Adams wrote: Once upon a time, Kevin Fenzi ke...@scrye.com said: It should also be normally trying multiple mirrors, not a bunch of times to the same one. :( [...] Actually, when I account for the different hashes and arches, the failing requests for updates/17/*/repodata/*-other.sqlite.bz2 files are accounting for almost 2/3 of all HTTP requests to my mirror. I am not seeing any FTP requests; does yum try FTP these days? It doesn't appear to be causing any problem (no load impact, just bigger logs; the daily error_log isn't usually 250MB+) on my mirror, but I expect it is causing issues for clients. This is what I get for the last few days: # yum --skip-broken update Loaded plugins: langpacks, presto, refresh-packagekit adobe-linux-x86_64 | 951 B 00:00 rpmfusion-free-updates | 3.3 kB 00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00 updates/17/x86_64/metalink | 16 kB 00:00 updates | 4.7 kB 00:00 00c7410a78aa8dd0f4934ed4935377 FAILED HTTP Error 404 - Not Found : http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2 http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found : http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2 Trying other mirror. updates/primary_db | 6.9 MB 00:06 updates/group_gz| 435 kB 00:00 Resolving Dependencies -- Running transaction check --- Package ctags.x86_64 0:5.8-7.fc17 will be updated --- Package ctags.x86_64 0:5.8-9.fc17 will be an update --- Package dbus.x86_64 1:1.4.10-6.fc17 will be updated --- Package dbus.x86_64 1:1.4.10-7.fc17 will be an update ... -- Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On 20/06/12 02:47 PM, Charles Zeitler wrote: On Tue, Jun 19, 2012 at 11:17 PM, Adam Williamson awill...@redhat.com wrote I just tested a fresh install from F17 desktop live; the /home/user directory created after firstboot is 700. /home/user created by s-c-u is 700. /home/user created by useradd is 700. /home/user created by GNOME account tool is 700. So I can't recreate a 755 user dir in any way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net maybe you're not trying hard enough. btw, kde install gave me a 755 ~, and a mix of modes on sub-directories. Bingo! Pattern found? I installed KDE as well, from DVD image. Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On 20/06/12 07:31 PM, Jesse Keating wrote: On 06/20/2012 05:16 PM, Dariusz J. Garbowski wrote: On 20/06/12 02:47 PM, Charles Zeitler wrote: On Tue, Jun 19, 2012 at 11:17 PM, Adam Williamson awill...@redhat.com wrote I just tested a fresh install from F17 desktop live; the /home/user directory created after firstboot is 700. /home/user created by s-c-u is 700. /home/user created by useradd is 700. /home/user created by GNOME account tool is 700. So I can't recreate a 755 user dir in any way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net maybe you're not trying hard enough. btw, kde install gave me a 755 ~, and a mix of modes on sub-directories. Bingo! Pattern found? I installed KDE as well, from DVD image. Dariusz Are you creating users through a KDE utility? No. In this case we are talking about default user created during F17 installation. I'm guessing that maybe KDE does something naughty? In addition, just an hour ago, I tested useradd and s-c-u, both create user home with 700 permissions. Haven't tested KDE utility. Frankly, I don't even know which utility would that be (personally I use useradd for this stuff). -- Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On 26/04/12 03:18 AM, Adam Williamson wrote: On Wed, 2012-04-25 at 17:27 -0600, Dariusz J. Garbowski wrote: Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Once we actually go to firewalld by default, then yes, at least as long as lokkit and s-c-f are maintained. The procedure is, more or less: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service lokkit --enabled Thumbs up for this. Please keep it in working condition! Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
On 25/04/12 10:55 AM, Adam Williamson wrote: On Tue, 2012-04-24 at 09:30 -0500, Jon Ciesla wrote: Nothing is being taken away, the default is being changed. If you're using Fedora in production, I presume you're installing with Kickstart. It's worth noting that if the question is how does firewalld handle upgrades, I think it may be somewhat irrelevant because AFAIK even when firewalld was going to be the F17 default, we never implemented anything to cause upgraded systems to switch to it. It was only new installs which were getting firewalld. Upgraded ones stuck with the static iptables/s-c-f/lokkit system. Does that imply that new installs will be easily switched from firewalld to static iptables? I always do new install but I want to keep my firewall static, with my current iptables script. Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 15/02/12 01:30 PM, Adam Williamson wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. Right. And thanks to this thread I just learned what broke bash completion for me after fresh install of F16: 'rpm -e bash-completion' fixed bash for me :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On 08/10/11 01:15 PM, Eric Smith wrote: Milan Broz wrote: Truecrypt on Linux uses kernel dm-crypt, so it is all mainly about metadata format handling. I will probably try to add alternative to cryptsetup to handle directly Truecrypt format (which is documented on project page, outside of source), the same way I already added loop-aes support. tcplay also uses dm-crypt. The author found that the Truecrypt format documentation had a lot of errors; see the tcplay README for details. It appears that there are provisions for using an API from tcplay from other programs, but I haven't really examined that. Yes, there's an API defined and a test code that one use as an example. Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RPM] for Jokosher 0.11.5 (F15 noarch)
On 15/09/11 04:00 PM, Rahul Sundaram wrote: On 09/16/2011 02:10 AM, Manuel Escudero wrote: RPM - http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.noarch.rpm SRC.RPM - http://commondatastorage.googleapis.com/xenodecdn/jokosher-0.11.5-0.fc15.src.rpm it's a noarch package so it can be installed in both 32 and 64 bit systems, Jokosher upstream seems inactive. This type of software typically requires a active upstream to be maintained properly. There is *some* activity on the bug tracker, as well as this post on 2011-May-01: https://answers.launchpad.net/jokosher/+question/155290 Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BackupPC-3.2.1-1.fc14.x86_64 broken? [todays's Fedora 14 update]
Hi, Today's yum update on Fedora 14 resulted in about 10 seconds long 100% CPU load on one of the cores and an error in scriptlet: Running Transaction Updating : farsight2-0.0.22-1.fc14.x86_64 1/26 Updating : libcap-2.22-1.fc14.x86_64 2/26 Updating : 1:cups-libs-1.4.8-2.fc14.x86_64 Updating : 1:cups-1.4.8-2.fc14.x86_64 Updating : farsight2-python-0.0.22-1.fc14.x86_64 Updating : BackupPC-3.2.1-4.fc14.x86_64 Updating : libvpx-0.9.7.1-1.fc14.x86_64 Updating : system-config-firewall-base-1.2.27-2.fc14.noarch Updating : system-config-firewall-tui-1.2.27-2.fc14.noarch Updating : system-config-firewall-1.2.27-2.fc14.noarch Updating : libcap-devel-2.22-1.fc14.x86_64 Updating : rubygems-1.3.7-3.fc14.noarch Updating : 1:cups-libs-1.4.8-2.fc14.i686 Cleanup: 1:cups-1.4.6-1.fc14.x86_64 Cleanup: farsight2-python-0.0.21-2.fc14.x86_64 Cleanup: farsight2-0.0.21-2.fc14.x86_64 Cleanup: 1:cups-libs-1.4.6-1.fc14 Cleanup: BackupPC-3.2.1-1.fc14.x86_64 Non-fatal POSTUN scriptlet failure in rpm package BackupPC Cleanup: libvpx-0.9.6-1.fc14.x86_64 /var/tmp/rpm-tmp.99zFPZ: line 15: syntax error near unexpected token `fi' /var/tmp/rpm-tmp.99zFPZ: line 15: `fi' warning: %postun(BackupPC-3.2.1-1.fc14.x86_64) scriptlet failed, exit status 2 Cleanup: system-config-firewall-1.2.27-1.fc14.noarch Cleanup: system-config-firewall-tui-1.2.27-1.fc14.noarch Cleanup: libcap-devel-2.17-1.fc13.x86_64 Cleanup: libcap-2.17-1.fc13.x86_64 Cleanup: system-config-firewall-base-1.2.27-1.fc14.noarch Cleanup: rubygems-1.3.7-2.fc14.noarch Cleanup: 1:cups-libs-1.4.6-1.fc14 Cheers, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 ext4 discard option - why not default?
On 16/03/11 01:03 PM, Michał Piotrowski wrote: 2011/3/16 Jeff Moyerjmo...@redhat.com: Michał Piotrowskimkkp...@gmail.com writes: 2011/3/16 Jeff Moyerjmo...@redhat.com: Out of curiosity, what SSD do you have? ocz vertex 2 OK, haven't tested those. So far, I can not say anything about it. I just installed system. I've been using OCZ Vertex 2 with ext4 and discard for about a month now. No issues. # mount |sort |grep /dev/sda /dev/sda1 on /boot type ext2 (rw,noatime) /dev/sda2 on / type ext4 (rw,noatime,discard) # smartctl -i /dev/sda smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SandForce Driven SSDs Device Model: OCZ-VERTEX2 Serial Number:OCZ-MPQS5B86KYJ9HBMI Firmware Version: 1.29 User Capacity:115,033,153,536 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is:Wed Mar 16 19:11:48 2011 MDT SMART support is: Available - device has SMART capability. SMART support is: Enabled -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 05:00 AM, Peter Robinson wrote: On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. There's also the case used quite often in my company with Dell docking stations, where the lid is open and the user uses both external and internal display in multi-monitor setup. Another case, used more often, is two external monitors connected to the dock and closed lid in multi-monitor setup. Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 07:09 AM, Nathaniel McCallum wrote: On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote: On 05/10/10 05:00 AM, Peter Robinson wrote: On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. There's also the case used quite often in my company with Dell docking stations, where the lid is open and the user uses both external and internal display in multi-monitor setup. Another case, used more often, is two external monitors connected to the dock and closed lid in multi-monitor setup. The good news is that I'm pretty sure the dock is irrelevant (other than are we on battery power) in all those cases. The only thing that matters is which outputs are connected and what happens when the lid is closed. This seems like a cut-and-dry GPM policy issue. What about the case where we are on battery power and a projector or external monitor connected to the VGA port, no dock (with lid either open or closed for single or multi-monitor setup)? Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 08:40 AM, FlorianFesti wrote: On 10/05/2010 03:15 PM, Nathaniel McCallum wrote: If the lid is open, both output should be enabled by default (you are free to manually disable one). If the lid is closed on battery power the system should suspend (unless you choose otherwise in GPM prefs). I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. Dells can boot with lid closed when connected to dock. I do that every day :-) Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 26/08/10 12:03 PM, Alex Hudson wrote: On Thu, 2010-08-26 at 19:51 +0200, Kevin Kofler wrote: We probably need to attack this trend more aggressively, like putting expiration dates into the installer after which it'll just refuse to install Putting up a message saying this is no longer supported - fine. Agreed. Stopping people / making it impossible? That's not Freedom. It's... DRM! thufor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On 16/08/10 08:10 AM, Brandon Lozza wrote: By your logic we should ban gcc, java, mono, python, perl, bash ... as one can use them to create and/or run non free software. Also you may be aware that javascript has its uses *outside* of the web too (just like you can write apps in python you can do it in JS; and having a JIT that speeds them up is definitely a plus). I'm up for banning mono, and perhaps java now that Oracle is suing everyone Java != JavaScript -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PolicyKit-authentication-agents in Fedora
On 08/04/10 05:53 PM, Christoph Wickert wrote: Am Donnerstag, den 08.04.2010, 19:05 -0400 schrieb Tony Nelson: On 10-04-08 14:13:01, Christoph Wickert wrote: [snipped] I never said it is a useful decision rationale, it's something we cannot avoid. I agree it's not useful, but please address your complainants to the yum developers. ... Would it work to change the name to polkit-lxpolkit and have it Provide lxpolkit? Then polkit-kde would win and it has even more deps. ;) polkit-lx then? ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Color Management Test Day Thursday 2010-02-18
Features/ColorManagement describes per-screen / per-output support. I have a dual monitor setup here (potentially even triple-monitor if I could setup SurroundView with on-board Radeon and discrete Radeon card). I don't see test case for multi-monitor setups. Is this planned or supported already? Cheers, Dariusz On 16/02/10 02:31 PM, Adam Williamson wrote: It's Test Day time again! This Thursday, 2010-02-18, will be Color Management Test Day[1]. There's some exciting new color management features[2] in Fedora 13. That is to say, there are color management features in Fedora 13! We've never had any real color management in Fedora before, so this is great news for photographers and designers in particular - but everybody, really. The good news is testing for this Test Day is very easy - anyone with a monitor can do most of the testing. A scanner, printer, webcam or colorimeter let you do some other tests. You don't need a Rawhide installation to do the testing, just a nightly live image[3] will do fine, and the testing process is fully documented and won't take more than a few minutes. So come out and help us test! Even if you don't use Fedora, you can test very easily with a live image, and this is one of those features that's popping up in Fedora first but will soon appear in all distributions (as it'll be part of GNOME itself), so you'll be helping your own distribution by testing. The Test Day will run all day in Freenode IRC #fedora-test-day. [1] http://fedoraproject.org/wiki/Test_Day:2010-02-18_Color_management [2] https://fedoraproject.org/wiki/Features/ColorManagement [3] http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
