Re: Are we rebasing xorg-x11 packages in F20?
On Tue, Nov 25, 2014 at 10:32:27AM -0500, Adam Jackson wrote: > want two outputs both named VGA-0. And caring about the names is > somewhat futile anyway since what you're usually more concerned with is > the _monitor_, which is why all sane desktops save configurations based > on EDIDs not on output names. /etc/gnome-settings-daemon/xrandr/monitors.xml also uses output names. So does the kernel when configuring enabled outputs via video= on the kernel commandline. I would also prefer a command line argument that allows to enable the output where a display is connected when my system is docked and the lid is closed, there is no such thing afaik. Regards Till -- 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: systemd.timer: Get next start time from unit being run?
Richard Shaw writes: I've got a TV schedule grabber script that needs to be run on a more or less daily basis. That would be good enough, but the script suggests a next start time in it's output when it completes. If I can figure out a way to pull that time from the script, is there a way to pass that to systemd? How about using at(1) to schedule the next script run? pgpCzR31qBG8M.pgp Description: PGP signature -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, Nov 25, 2014 at 10:23 AM, Kevin Fenzi wrote: > On Tue, 25 Nov 2014 09:56:59 -0500 > Simo Sorce wrote: > >> We can install machine w/o user accounts, removing the ability to log >> in as root via ssh means those machines will not be accessible. > > This has been the reason this hasn't been changed the last few times > someone proposed to change it. > > I don't know how many folks do installs with no user config, but it's > definitely possible right now and that could mean they wouldn't be able > to reach their instance. We could of course change that so creating a > new user is forced, but I'm really not sure it's that much advantage. > >> If you want to remove root access that should be conditionally done at >> firstboot only if a user account was created. > > This seems a more reasonable place to look to change this, I agree. > > kevin No user config *and no console access* is where it breaks down. Most people who run real servers use either virtualization, which provides a form of console access, or remote KVM's, or have hands and eyes. -- 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: Are we rebasing xorg-x11 packages in F20?
On Tue, 2014-11-25 at 14:04 +0100, Simone Caronni wrote: > On 25 November 2014 at 13:20, Lukas Zapletal wrote: > I don't understand why I noticed this today, it looks like the > latest > update was a Critical Path one (???) when Fedora 20 was stable > for six > months. > > > https://admin.fedoraproject.org/updates/FEDORA-2014-7331/xorg-x11-server-utils-7.7-6.fc20 > > > from what I've seen xorg packages are always marked as Critical Path. > > The update you are referring to is six months old, are you sure the > xrandr command is the culprit and not something else? Did you skip > updates for six months? > > > There's an intel driver from 18th november, for example: > > https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 > > > > This seems to be much more related to your issues. I don't had any > output renaming recently in the past year (Nouveau here). FWIW my case is Intel too and this change did occur in the most recent update, over possibly a week but certainly not two weeks, and the device naming did change. > > > Regards, > > --Simone > > > > > > -- > You cannot discover new oceans unless you have the courage to lose > sight of the shore (R. W. Emerson). > > http://xkcd.com/229/ > http://negativo17.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: Agenda for Env-and-Stacks WG meeting (2014-11-05)
Thanks, fixed in the invitation for tomorrow. Honza - Original Message - > On Wed, Nov 05, 2014 at 04:42:01AM -0500, Jens Petersen wrote: > > WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 9:00 Boston, > > 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode. > > Boston is in the US/Eastern time zone, so, it's actually 7am Boston > time, not 9. > > -- > Matthew Miller > > Fedora Project Leader > ___ > env-and-stacks mailing list > env-and-sta...@lists.fedoraproject.org > https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks > -- 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: Agenda for Env-and-Stacks WG meeting (2014-11-26)
Sorry, wrong date, 2014-11-26 is correct. Honza - Original Message - > WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston, > 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode. > > = Topics = > * Follow-ups > * Language specific repositories > * Election planning > * Chairman for next meeting > * Open Floor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-11-25)
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode. = Topics = * Follow-ups * Language specific repositories * Election planning * Chairman for next meeting * Open Floor -- 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: timedatex replacing systemd-timedated for NTP packages
On Tue, Nov 25, 2014 at 10:51 AM, Florian Weimer wrote: > Some networks have bad NTP service in the sense that they hand out incorrect > time (not just off by a few seconds, but days or months, enough to skew > certificate validity). I'm not sure what we're supposed to do about such sabotage on the network, that seems distinctly a local issue. We should do the best we can right now, while providing a manual switch for the user to alter the default. It used to be the case that we used these servers: 0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org Chrony isn't installed or running on Fedora 21 Server, so at least on server I have no idea at the moment were the ntp pool is specified. > Your proposed solution would make GNOME unusable on > such networks. Other bad things might happen there, but just pretending > that everything this phenomenon does not exist and that we know better than > the user what the correct system time should be in all cases seems very > unhelpful. Time is a basic requirement, it's correct for Fedora installs to point to a Fedora Project ntp pool by default for Server and Workstation products; for cloud they may have different (?) requirements. I expect "manual time" setting to be exist, and it'd be synonymous with ntp off. > Now if Fedora offered a high-availability cryptographic time service (we > actually do, sort of), things might be different—but not much, because then > we'd be having a discussion about phoning home instead. The pool still exists. Are we not supposed to use them? [root@f21s ~]# nslookup 0.fedora.pool.ntp.org Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: 0.fedora.pool.ntp.org Address: 69.28.67.44 Name: 0.fedora.pool.ntp.org Address: 209.118.204.201 Name: 0.fedora.pool.ntp.org Address: 204.2.134.164 Name: 0.fedora.pool.ntp.org Address: 204.2.134.163 -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo meeting (2014-11-26 at 18UTC)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:00UTC in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic ticket #1349 Fedora 22 scheduling strategy (and beyond) .fesco 1349 #topic #1369packages should disable internal crash handlers and depend on ABRT .fesco 1369 = New business = None = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. pgpwVbd5XPg5u.pgp Description: OpenPGP digital signature -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, Nov 25, 2014 at 09:20:35PM +0100, Petr Lautrbach wrote: > There are several use cases when local non-root users are not needed at > all as others already pointed out. Including in some cases where there should both be no root password _and_ no local non-system users. > The change itself is simple however the problem is more complex overall. > Here are some thoughts I have about the change: > - administrators are alerted when they use weak password for root by > anaconda This has long been the case. However, if it explains _why_, I forget, for the same reason that this never works. (Yeah yeah whatever, I just want to install my system now and keep using "godmode" as my root password just like I always have so I don't forget it.) [more snipped] > - default sudoers uses password of an user for authentication, so even > when I have a non-root user in wheel group, I only need one user's > password to become root This is also the case already. -- Matthew Miller Fedora Project Leader -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/21/2014 08:11 AM, P J P wrote: > Hello, > > Sshd(8) daemon by default allows remote users to login as root. > > 1. Is that really necessary? The original bug report [1] was kept opened mainly due to the lack of adding user functionality in anaconda. This is no more true, anaconda has ability to add an user although it's not enforced. [1] https://bugzilla.redhat.com/show_bug.cgi?id=89216 > 2. Lot of users use their systems as root, without even creating a non-root > user. > Such practices need to be discouraged, not allowing remote root login > could be > useful in that. There are several use cases when local non-root users are not needed at all as others already pointed out. The change itself is simple however the problem is more complex overall. Here are some thoughts I have about the change: - administrators are alerted when they use weak password for root by anaconda - Fedora Workstation and Live installations don't enable sshd.service - even if the default was 'PermitRootLogin without-password' you would need to inject an ssh key and when you are able to inject a key, you are able to change the default configuration - I personally use several Fedora systems without non-root users in local network. - default sudoers uses password of an user for authentication, so even when I have a non-root user in wheel group, I only need one user's password to become root - how much users of these enforced users will be 'user' or 'test'? Petr -- Petr Lautrbach signature.asc Description: OpenPGP digital signature -- 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: Best way to use zram in Fedora 21?
Am 25.11.2014 um 21:03 schrieb Juan Orti: Hi, I know how to manually configure the zram, but what's the best way to do it? I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric. Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic. I think this is a very interesting feature for memory constrained VMs and other devices. [1] https://github.com/mystilleef/FedoraZram i am using the attached src.rpm for many months on Fedora (F19, F20) zram-1.0.1-1.fc20.20141120.rh.src.rpm Description: application/rpm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Best way to use zram in Fedora 21?
Hi, I know how to manually configure the zram, but what's the best way to do it? I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric. Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic. I think this is a very interesting feature for memory constrained VMs and other devices. [1] https://github.com/mystilleef/FedoraZram signature.asc Description: This is a digitally signed message part -- 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: Agenda for Env-and-Stacks WG meeting (2014-11-05)
On Wed, Nov 05, 2014 at 04:42:01AM -0500, Jens Petersen wrote: > WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 9:00 Boston, > 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode. Boston is in the US/Eastern time zone, so, it's actually 7am Boston time, not 9. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Open Seat on the Fedora Server Working Group
This past week, David Strauss chose to step down from his position on the Fedora Server Working Group, citing a lack of alignment with his current work usage. The Fedora Server SIG would like to thank David for his contributions up to this point and wish him well. This means that there is currently a vacancy in the Fedora Server Working Group. The Working Group is the nine-person volunteer body that oversees the development, testing, release, documentation, marketing and evangelism of the Fedora Server. Membership on this Working Group is a moderate commitment requiring a participation of a minimum of two hours a week, one hour of which being the (usually) weekly meeting. Membership on the Fedora Server Working Group does not require you to be a developer, tester or administrator. Anyone who is interested in advancing any of the Fedora Server's goals[2] is eligible to self-nominate. Document-writers, translators, Fedora Ambassadors, end-users and anyone else can become a part of this team. If you feel that you are interested in becoming more involved with the Fedora Server, we encourage you to self-nominate by joining the Fedora Server mailing list[1] and sending a self-introduction and nomination email to that list. We will have open nominations from now until Tuesday, December 9th, where we will vote on the new member at the weekly meeting. If you self-nominate but aren't selected to serve on the Working Group, do not fret! The Server SIG is open to all and the Working Group will always listen to your advice and concerns, so please stick around! While the Working Group is the final authority and voting body when disagreements come up or official decisions (like branding) need to be made, we are not the only people working on the Fedora Server. The Server SIG is small today, but growing. We would very much like to have you join us. [1] https://admin.fedoraproject.org/mailman/listinfo/server [2] https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product_Objectives signature.asc Description: This is a digitally signed message part ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 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: Are we rebasing xorg-x11 packages in F20?
On Tue, Nov 25, 2014 at 6:15 PM, Tom Hughes wrote: > On 25/11/14 16:55, Adam Jackson wrote: >> >> On Tue, 2014-11-25 at 15:57 +, Tom Hughes wrote: >> >>> I thought multi-gpu randr was supported in 1.4? I certainly see one >>> provider for each of the two gpus in this machine, and can see five >>> connectors across the two with three monitors connected. It looks like >>> it just adds an extra digit to the connector names on the second card: >> >> >> In the optimus sense of multi-gpu, yes, that works. In the classic >> Xinerama sense of "two PCIE cards installed next to each other", not so >> much. > > > That isn't optimus, at least not as I understand optimus, it's two Nvidia > PCIe cards: > > 03:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] > (rev a1) > 04:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] Optimus means one card renders in the other cards framebuffer and only one of them actually scans out that framebuffer and puts it on screen. -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/25/2014 11:05 AM, P J P wrote: Hi, On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's, so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple, True, it is complex. Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5). (Just a thought) --- Regards -Prasad http://feedmug.com thanks, in my multiple re installs, I can live with the following: an user prompt to create a user account and press no or setting an one more option in kickstart to prevent create a user account and change myself the ssh default to permit rootlogin to yes but not with: creating a user account by default logging with that account, change the sshd default to yes logoff logging with root delete the user account -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
systemd.timer: Get next start time from unit being run?
I've got a TV schedule grabber script that needs to be run on a more or less daily basis. That would be good enough, but the script suggests a next start time in it's output when it completes. If I can figure out a way to pull that time from the script, is there a way to pass that to systemd? Thanks, Richard -- 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: timedatex replacing systemd-timedated for NTP packages
On 11/25/2014 06:25 PM, Lennart Poettering wrote: On Tue, 25.11.14 18:04, Florian Weimer (fwei...@redhat.com) wrote: On 11/25/2014 05:15 PM, Lennart Poettering wrote: Really? if you want a UI that controls whether NTP server software is running, why not call into the EnableUnitFiles() APIs directly? Both chronyd and ntpd are often used as clients. Miroslav wasn't talking about server usage scenarios, but replacing systemd's NTP client with either ntpd or chronyd. But if you do that, GNOME currently does not report correctly if the system uses NTP time, which is the bug Miroslav is trying to solve. Well, GNOME really shouldn't show an NTP check box in the first place. Instead it NTP should be always on, but GNOME should provide a way to manually set the time if no NTP synchronization could be acquired. More specifically, the NTPSynchronized property of timedated reflects the kernel's UNSYNC flag, and if that boolean is false, then GNOME should provide a fallback UI for setting the clock manually, but only then. Some networks have bad NTP service in the sense that they hand out incorrect time (not just off by a few seconds, but days or months, enough to skew certificate validity). Your proposed solution would make GNOME unusable on such networks. Other bad things might happen there, but just pretending that everything this phenomenon does not exist and that we know better than the user what the correct system time should be in all cases seems very unhelpful. Now if Fedora offered a high-availability cryptographic time service (we actually do, sort of), things might be different—but not much, because then we'd be having a discussion about phoning home instead. -- Florian Weimer / Red Hat Product Security -- 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: timedatex replacing systemd-timedated for NTP packages
On Tue, 25.11.14 11:08, Michael Catanzaro (mcatanz...@gnome.org) wrote: > On Tue, 2014-11-25 at 17:15 +0100, Lennart Poettering wrote: > > I am sorry, but timedated is really not the place to control NTP > > *server* software. It's simply, desktopy stuff, for controlling NTP > > clients. > > Of course, but the desktopy NTP client in Fedora Workstation is chrony, > as you know full well. Unless that changes, we need timedatex. Even if > we decide to drop chrony, we still need timedatex to ensure NTP is not > broken for users who upgrade from F21 to F22. (Unless you have another > plan for handling such an upgrade?) Drop the NTP checkbox. Enable chrony by default. Done. Lennart -- Lennart Poettering, Red Hat -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, 25 Nov 2014 17:05:59 + (UTC) P J P wrote: > Hi, > > > On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: > > I have a server which only runs several VM's with specific > > services, no need user accounts in the host or in the VM's, > > > > so you propose when I reiinstall any of them create a user account > > in each of them, that will cause boot the first time change to > > permit root login and delete the *forced* user account > > > > and the server is hosted remotely, so if anything is wrong with it > > I can only access via ssh so this *feature change* is no simple, > > > True, it is complex. > > Maybe we could have an option in firstboot(and other such places) by > which user can override the default non-root account creation. Ie. > Say a user is prompted to create non-root user account; He/she can > choose to override it and not create one. In such workflow, he/she is > warned about the possible lockout situation and duly advised to > explicitly enable remote root login in sshd_config(5). > > (Just a thought) If the user is not created you do not change the sshd_config defaults and let root log in. Simple, and does not break current kickstarts. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: timedatex replacing systemd-timedated for NTP packages
On Tue, 25.11.14 18:04, Florian Weimer (fwei...@redhat.com) wrote: > On 11/25/2014 05:15 PM, Lennart Poettering wrote: > >Really? if you want a UI that controls whether NTP server software is > >running, why not call into the EnableUnitFiles() APIs directly? > > Both chronyd and ntpd are often used as clients. Miroslav wasn't talking > about server usage scenarios, but replacing systemd's NTP client with either > ntpd or chronyd. But if you do that, GNOME currently does not report > correctly if the system uses NTP time, which is the bug Miroslav is trying > to solve. Well, GNOME really shouldn't show an NTP check box in the first place. Instead it NTP should be always on, but GNOME should provide a way to manually set the time if no NTP synchronization could be acquired. More specifically, the NTPSynchronized property of timedated reflects the kernel's UNSYNC flag, and if that boolean is false, then GNOME should provide a fallback UI for setting the clock manually, but only then. Manually setting the clock is something we shouldn't really encourage, unless there was no way to get a full NTP sync. But if we can get an NTP sync then we should always prefer that. Hence: removing the NTP switch from the GNOME UI would be best really. That doesn't of course mean that admins shouldn't be able to manually override the clock settings, but that can happen with low-level tools like timedatectl or even "date" or "hwclock", it needs no friendly exposure in the graphical UI. Changing the clock manually really should be something for gurus only, not for the uninitiated... Never forget that tons of things break if the clock is set incorrectly (kerberos, nfs, smb, email, make, ...). Users might think that setting the clock to 1998 is a good idea, but it really isn't, and hence we shouldn't by default provide a UI for that... Lennart -- Lennart Poettering, Red Hat -- 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: Are we rebasing xorg-x11 packages in F20?
On 25/11/14 16:55, Adam Jackson wrote: On Tue, 2014-11-25 at 15:57 +, Tom Hughes wrote: I thought multi-gpu randr was supported in 1.4? I certainly see one provider for each of the two gpus in this machine, and can see five connectors across the two with three monitors connected. It looks like it just adds an extra digit to the connector names on the second card: In the optimus sense of multi-gpu, yes, that works. In the classic Xinerama sense of "two PCIE cards installed next to each other", not so much. That isn't optimus, at least not as I understand optimus, it's two Nvidia PCIe cards: 03:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) 04:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hi, > On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote: > I have a server which only runs several VM's with specific services, no > need user accounts in the host or in the VM's, > > so you propose when I reiinstall any of them create a user account in > each of them, that will cause boot the first time change to permit root > login and delete the *forced* user account > > and the server is hosted remotely, so if anything is wrong with it I can > only access via ssh so this *feature change* is no simple, True, it is complex. Maybe we could have an option in firstboot(and other such places) by which user can override the default non-root account creation. Ie. Say a user is prompted to create non-root user account; He/she can choose to override it and not create one. In such workflow, he/she is warned about the possible lockout situation and duly advised to explicitly enable remote root login in sshd_config(5). (Just a thought) --- Regards -Prasad http://feedmug.com -- 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: timedatex replacing systemd-timedated for NTP packages
On Tue, 2014-11-25 at 17:15 +0100, Lennart Poettering wrote: > I am sorry, but timedated is really not the place to control NTP > *server* software. It's simply, desktopy stuff, for controlling NTP > clients. Of course, but the desktopy NTP client in Fedora Workstation is chrony, as you know full well. Unless that changes, we need timedatex. Even if we decide to drop chrony, we still need timedatex to ensure NTP is not broken for users who upgrade from F21 to F22. (Unless you have another plan for handling such an upgrade?) signature.asc Description: This is a digitally signed message part -- 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: timedatex replacing systemd-timedated for NTP packages
On 11/25/2014 05:15 PM, Lennart Poettering wrote: Really? if you want a UI that controls whether NTP server software is running, why not call into the EnableUnitFiles() APIs directly? Both chronyd and ntpd are often used as clients. Miroslav wasn't talking about server usage scenarios, but replacing systemd's NTP client with either ntpd or chronyd. But if you do that, GNOME currently does not report correctly if the system uses NTP time, which is the bug Miroslav is trying to solve. -- Florian Weimer / Red Hat Product Security -- 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: Are we rebasing xorg-x11 packages in F20?
On Tue, 2014-11-25 at 15:57 +, Tom Hughes wrote: > I thought multi-gpu randr was supported in 1.4? I certainly see one > provider for each of the two gpus in this machine, and can see five > connectors across the two with three monitors connected. It looks like > it just adds an extra digit to the connector names on the second card: In the optimus sense of multi-gpu, yes, that works. In the classic Xinerama sense of "two PCIE cards installed next to each other", not so much. - ajax -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/25/2014 09:45 AM, P J P wrote: On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote: On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce wrote: We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible. This has been the reason this hasn't been changed the last few times someone proposed to change it. I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage. If you want to remove root access that should be conditionally done at firstboot only if a user account was created. This seems a more reasonable place to look to change this, I agree. True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that. no need to create a user account in *all* installs I have a server which only runs several VM's with specific services, no need user accounts in the host or in the VM's, so you propose when I reiinstall any of them create a user account in each of them, that will cause boot the first time change to permit root login and delete the *forced* user account and the server is hosted remotely, so if anything is wrong with it I can only access via ssh so this *feature change* is no simple, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1167721] perl-Test-Module-Used-0.2.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1167721 --- Comment #2 from Fedora Update System --- perl-Test-Module-Used-0.2.6-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Test-Module-Used-0.2.6-1.fc21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=v3VHqk&a=cc_unsubscribe -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
Hello Matthew, > On Tuesday, 25 November 2014 9:21 PM, Matthew Miller wrote: > Keep in mind that in cloud, cloud-init does the same thing (instead of > firstboot). Ah I see, cool! --- Regards -Prasad http://feedmug.com -- 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: timedatex replacing systemd-timedated for NTP packages
On Tue, 25.11.14 16:23, Miroslav Lichvar (mlich...@redhat.com) wrote: > This is about bug #1136905 [1], discussed previously on the systemd list > [2] and also on our desktop list [3]. > > The issue is that systemd-timedated now supports only systemd-timesyncd > for NTP and ignores other NTP services installed on the system. It doesn't > know that chronyd or ntpd is enabled (usually by system-config-date after > the installation) and switching NTP in timedate clients such as > timedatectl and GNOME control center is broken. > > If we want to have this working correctly with chronyd/ntpd, at this point > it seems the only reasonable option is to replace systemd-timedated. > timedatex is a new implementation of the timedate interface that was > recently added to Fedora. It reads the list of NTP units from a directory > as systemd-timedated used to do. When installed, systemd will start it for > the timedate bus name instead of systemd-timedated. The timedate clients > should work as expected, please report bugs if not. > > One suggestion was to install it as a dependency of the NTP packages. > Is this a good idea? Should this first go through the Fedora change > process or at least be documented somewhere? Really? if you want a UI that controls whether NTP server software is running, why not call into the EnableUnitFiles() APIs directly? Also, if you want timedated to be a frontend for configuring *server* software, will you add another tool next, for controlling a HTTP server? I am sorry, but timedated is really not the place to control NTP *server* software. It's simply, desktopy stuff, for controlling NTP clients. And if you install a full NTP server, then the NTP client already gets kicked out of the initil transaction and all is good. The way to configure server software is via "systemctl enable" and "systemctl disable" not via "timedatectl". Lennart -- Lennart Poettering, Red Hat -- 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: Are we rebasing xorg-x11 packages in F20?
On 25/11/14 15:32, Adam Jackson wrote: But when I say "come from the server" I really mean the 2D X driver makes up the name and the server just reports it. And indeed, between xorg-x11-drv-intel-2.21.15-4 and -9 output naming was changed to include a dash (if using UXA), which happened because the output setup code was synced with the version in the generic modesetting driver (which also happens to match radeon and nouveau). Upstream intel omits the dash for both sna and uxa still though. And if we were to ever get multi-gpu randr working the names would destabilize again, since we'd have to move the %d part of the name up to the core server since you really don't want two outputs both named VGA-0. And caring about the names is somewhat futile anyway since what you're usually more concerned with is the _monitor_, which is why all sane desktops save configurations based on EDIDs not on output names. I thought multi-gpu randr was supported in 1.4? I certainly see one provider for each of the two gpus in this machine, and can see five connectors across the two with three monitors connected. It looks like it just adds an extra digit to the connector names on the second card: DVI-I-1 connected primary 2560x1600+0+0 (normal left inverted right x axis y axis) 646mm x 406mm DVI-I-2 connected 1200x1600+2560+0 right (normal left inverted right x axis y axis) 408mm x 306mm DVI-I-1-3 connected (normal left inverted right x axis y axis) HDMI-1-1 disconnected (normal left inverted right x axis y axis) VGA-1-1 disconnected (normal left inverted right x axis y axis) The fact that X crashes (BZ#1110273) if I try and rotate the monitor on the second graphics card means I can't actually use them all, but it works if I don't try and rotate it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
> On Tuesday, 25 November 2014 9:07 PM, Simo Sorce wrote: > My machines get joined to an IPA domain as soon as they are finished > installing, I do *not* want a local user, it would be a liability. Well, I think this is more specific case for which remote 'root' login could be enabled by user. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, Nov 25, 2014 at 03:45:08PM +, P J P wrote: > True, this concern has been raised before. We need to ensure that > user creates at least one non-root user account; firstboot is just > the right place to ensure that. Keep in mind that in cloud, cloud-init does the same thing (instead of firstboot). -- Matthew Miller Fedora Project Leader -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
> On Tuesday, 25 November 2014 8:53 PM, Kevin Fenzi wrote: > > On Tue, 25 Nov 2014 09:56:59 -0500 > Simo Sorce wrote: > >> We can install machine w/o user accounts, removing the ability to log >> in as root via ssh means those machines will not be accessible. > > This has been the reason this hasn't been changed the last few times > someone proposed to change it. > > I don't know how many folks do installs with no user config, but it's > definitely possible right now and that could mean they wouldn't be able > to reach their instance. We could of course change that so creating a > new user is forced, but I'm really not sure it's that much advantage. > >> If you want to remove root access that should be conditionally done at >> firstboot only if a user account was created. > > This seems a more reasonable place to look to change this, I agree. True, this concern has been raised before. We need to ensure that user creates at least one non-root user account; firstboot is just the right place to ensure that. --- Regards -Prasad http://feedmug.com -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, 25 Nov 2014 08:23:22 -0700 Kevin Fenzi wrote: > On Tue, 25 Nov 2014 09:56:59 -0500 > Simo Sorce wrote: > > > We can install machine w/o user accounts, removing the ability to > > log in as root via ssh means those machines will not be accessible. > > This has been the reason this hasn't been changed the last few times > someone proposed to change it. > > I don't know how many folks do installs with no user config, but it's > definitely possible right now and that could mean they wouldn't be > able to reach their instance. We could of course change that so > creating a new user is forced, but I'm really not sure it's that much > advantage. My machines get joined to an IPA domain as soon as they are finished installing, I do *not* want a local user, it would be a liability. > > If you want to remove root access that should be conditionally done > > at firstboot only if a user account was created. > > This seems a more reasonable place to look to change this, I agree. > > kevin -- Simo Sorce * Red Hat, Inc * New York -- 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: Are we rebasing xorg-x11 packages in F20?
On Tue, 2014-11-25 at 09:14 +0100, Lukas Zapletal wrote: > my desktop was completely broken this morning because my startup scripts > rely on xrandr utility. An older update from this summer which I applied > recently changed it's output so device ids now contain dash characters > (e.g. instead VGA0 I see VGA-1). No it didn't. xorg-x11-server-utils did update from xrandr 1.4.0 to 1.4.2 between F20 gold and current updates, but as a quick glance at the upstream changelog shows [1], nothing between those two versions changed anything about output naming. It would be insane to do so; those names come from the server, so changing them in xrandr would mean xrandr disagreeing with everything else. But when I say "come from the server" I really mean the 2D X driver makes up the name and the server just reports it. And indeed, between xorg-x11-drv-intel-2.21.15-4 and -9 output naming was changed to include a dash (if using UXA), which happened because the output setup code was synced with the version in the generic modesetting driver (which also happens to match radeon and nouveau). Upstream intel omits the dash for both sna and uxa still though. And if we were to ever get multi-gpu randr working the names would destabilize again, since we'd have to move the %d part of the name up to the core server since you really don't want two outputs both named VGA-0. And caring about the names is somewhat futile anyway since what you're usually more concerned with is the _monitor_, which is why all sane desktops save configurations based on EDIDs not on output names. tl;dr it's a mess, sorry about that. Stable output naming isn't something that any of our desktop environments care about, afaik, so it's not something I'd ever see as a regression. In a sense, noticing this level of implementation detail is the price you pay for choosing not to run something that gets it right for you. [2] [1] - http://cgit.freedesktop.org/xorg/app/xrandr/log/ [2] - And Linux, as we know, is all about choice. - ajax -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Tue, 25 Nov 2014 09:56:59 -0500 Simo Sorce wrote: > We can install machine w/o user accounts, removing the ability to log > in as root via ssh means those machines will not be accessible. This has been the reason this hasn't been changed the last few times someone proposed to change it. I don't know how many folks do installs with no user config, but it's definitely possible right now and that could mean they wouldn't be able to reach their instance. We could of course change that so creating a new user is forced, but I'm really not sure it's that much advantage. > If you want to remove root access that should be conditionally done at > firstboot only if a user account was created. This seems a more reasonable place to look to change this, I agree. kevin pgpcbATTMtWgN.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File POE-Component-SSLify-1.012.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-POE-Component-SSLify: fc90d5016fb1427090eb865d72f60aba POE-Component-SSLify-1.012.tar.gz -- 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
timedatex replacing systemd-timedated for NTP packages
This is about bug #1136905 [1], discussed previously on the systemd list [2] and also on our desktop list [3]. The issue is that systemd-timedated now supports only systemd-timesyncd for NTP and ignores other NTP services installed on the system. It doesn't know that chronyd or ntpd is enabled (usually by system-config-date after the installation) and switching NTP in timedate clients such as timedatectl and GNOME control center is broken. If we want to have this working correctly with chronyd/ntpd, at this point it seems the only reasonable option is to replace systemd-timedated. timedatex is a new implementation of the timedate interface that was recently added to Fedora. It reads the list of NTP units from a directory as systemd-timedated used to do. When installed, systemd will start it for the timedate bus name instead of systemd-timedated. The timedate clients should work as expected, please report bugs if not. One suggestion was to install it as a dependency of the NTP packages. Is this a good idea? Should this first go through the Fedora change process or at least be documented somewhere? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1136905 [2] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022367.html [3] http://lists.fedoraproject.org/pipermail/desktop/2014-September/010749.html -- Miroslav Lichvar -- 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On Sat, 22 Nov 2014 08:24:32 + (UTC) P J P wrote: > > On Saturday, 22 November 2014 1:39 AM, Richard W.M. Jones wrote: > >> On Fri, Nov 21, 2014 at 09:11:51AM +0100, Florian Weimer wrote: > >> The latter. We have to install authorized_keys inside the VM > >> anyway, so we can touch sshd_config, too. > > > > Virt-builder has a new '--ssh-inject' feature (in F22 only). > > > > $ virt-builder fedora-20 --ssh-inject root > > > > would inject your current ssh key into the root account of the new > > VM. There are other variations, including ways to create a non-root > > user account, see: > > > > http://libguestfs.org/virt-builder.1.html > > > > > Excellent! :) > > > So far the consensus seem that it is okay to reverse the current > default and set PermitRootLogin=no. I'll talk to the upstream > maintainer - plautrba(https://fedoraproject.org/wiki/User:Plautrba). > > Thank you. We can install machine w/o user accounts, removing the ability to log in as root via ssh means those machines will not be accessible. If you want to remove root access that should be conditionally done at firstboot only if a user account was created. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: Suggested Freeze Policy change for Fedora 22+
- Original Message - > > > > On Tue, 2014-11-25 at 10:21 +0100, drago01 wrote: > > On Mon, Nov 24, 2014 at 8:46 PM, Stephen Gallagher > > wrote: > > > > > > > > > Yeah, that's a valid concern and one I'm not ignoring. I'm just > > > concerned that (going by F21 Alpha and Beta) the "hero testing" doesn't > > > result in avoiding a slip most of the time. In the case of Alpha, that > > > was going on for a month before we finally were able to release. That's > > > not fair to QA and it *certainly* doesn't make it seem like something > > > new contributors would want to put themselves through. > > > > If your goal is preventing slips you are doing it wrong (tm). Your > > proposal would as Kevin said just result into *more* slips. > > What we should do is to find out *why* we slip every time and address > > that. The handling of the Go/NoGo meeting isn't really the problem, > > you are fighting the symptoms instead of the disease. > > > > So you'd have to 1) find out what causes us to slip so often (*cough* > > anaconda *cough* [1]) and 2) talk to the related developers / involved > > parties to find a way to solve it in a way that is acceptable to both > > sides (in that example rel eng / qa / anaconda devs). > > > > Well, that's actually one piece this is trying to address. By > publicizing and making clear that "Developers must have their packages > *submitted for stable*" at a specific time, we help those developers > schedule their time more accurately. > > As I said before, part of the problem is that most developers (anaconda > included, I suspect) have been operating under the impression that as > long as the package is prepped before *Thursday*, it's all good. But > this doesn't allow time for adequate testing and discovery of remaining > issues. From my experience, many misunderstandings comes from "release is next Tuesday, it will be ready on Monday". So even one milestone later;-) The good thing is, Adam is usually sending email to devel list as reminder. And it actually follows what you proposed :). Asking devels to fix stuff by Tuesday, info we would have to slip in case it's not etc. Just it never was strict deadline and many times it was in the way - hey, we're so close, let's try to be crazy heroes, we can make it. So yes, we already do almost what you proposed, just it's not enforced. If there's demand for it, I'm not against it. It's a bit less flexible but can lower pressure on many folks (but prolong release -> more pressure but spread in more time). Jaroslav > > 1: Ok I didn't check the data but my impression is that most blocker > > bugs are in that area I might be wrong though ... but the data is > > available to check that. > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora scientific packaging
On Mon, Nov 24, 2014 at 07:21:03PM -0600, Mukundan Ragavan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 11/24/2014 03:49 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Nov 22, 2014 at 10:12:46PM +0100, Zbigniew > > Jędrzejewski-Szmek wrote: > >> I have working packages [1] for genesis and moose (both neuron > >> simulators). I didn't submit them because genesis is old and > >> buggy, and moose a bit unstable, but with the release of v. 3 > >> I'll submit it as a Fedora package. I'm now working on pysb and > >> bionetgen as a dependency. Apart from some bundling which is > >> relatively easy to undo, everything seems nice and simple. > > python-pygraphviz [1], bionetgen [2], and python-pysb [3] are now > > ready. Reviewers very much welcome, altruistic or barter (swap) > > based. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1167460 [2] > > https://bugzilla.redhat.com/show_bug.cgi?id=1167467 [3] > > https://bugzilla.redhat.com/show_bug.cgi?id=1167478 > > > > Zbyszek > > > > Well, I can review all these three packages. We have break coming up > (from Thursday) and I can review it that day. Great, thanks. Zbyszek -- 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: Suggested Freeze Policy change for Fedora 22+
On Tue, 2014-11-25 at 10:21 +0100, drago01 wrote: > On Mon, Nov 24, 2014 at 8:46 PM, Stephen Gallagher > wrote: > > > > > > Yeah, that's a valid concern and one I'm not ignoring. I'm just > > concerned that (going by F21 Alpha and Beta) the "hero testing" doesn't > > result in avoiding a slip most of the time. In the case of Alpha, that > > was going on for a month before we finally were able to release. That's > > not fair to QA and it *certainly* doesn't make it seem like something > > new contributors would want to put themselves through. > > If your goal is preventing slips you are doing it wrong (tm). Your > proposal would as Kevin said just result into *more* slips. > What we should do is to find out *why* we slip every time and address > that. The handling of the Go/NoGo meeting isn't really the problem, > you are fighting the symptoms instead of the disease. > > So you'd have to 1) find out what causes us to slip so often (*cough* > anaconda *cough* [1]) and 2) talk to the related developers / involved > parties to find a way to solve it in a way that is acceptable to both > sides (in that example rel eng / qa / anaconda devs). > Well, that's actually one piece this is trying to address. By publicizing and making clear that "Developers must have their packages *submitted for stable*" at a specific time, we help those developers schedule their time more accurately. As I said before, part of the problem is that most developers (anaconda included, I suspect) have been operating under the impression that as long as the package is prepped before *Thursday*, it's all good. But this doesn't allow time for adequate testing and discovery of remaining issues. > 1: Ok I didn't check the data but my impression is that most blocker > bugs are in that area I might be wrong though ... but the data is > available to check that. signature.asc Description: This is a digitally signed message part -- 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: Are we rebasing xorg-x11 packages in F20?
Am 25.11.2014 um 14:31 schrieb Lukas Zapletal: There's an intel driver from 18th november, for example: https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 This seems to be much more related to your issues. I don't had any output renaming recently in the past year (Nouveau here). That answers the question why I experienced the change today, and not six months ago :-) I understand why drivers are updated for stable releases, that's fine. Not sure about the Critical Path (graphics drivers can bite, more testing time is perhaps the better) how much testing? and the important question: testing exactly what? the intel driver was built 2014-09-10 installed xorg-x11-drv-intel-2.21.15-9.fc20.x86_64 from koji 2 weeks ago on 4 machines (Sandy Bridge and IvyBridge) without any issue on Fedora machines installed in 2011 signature.asc Description: OpenPGP digital signature -- 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: Are we rebasing xorg-x11 packages in F20?
- Original Message - > > There's an intel driver from 18th november, for example: > > > > https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 > > > > This seems to be much more related to your issues. I don't had any output > > renaming recently in the past year (Nouveau here). > > That answers the question why I experienced the change today, and not > six months ago :-) > > I understand why drivers are updated for stable releases, that's fine. Could it be driver update? ;-) > Not sure about the Critical Path (graphics drivers can bite, more > testing time is perhaps the better) but if this is our policy, there > must be some reasons for that. One reason why you can see such updates is F21 - as it was significantly delayed, this way we're able help F20 users to enable theirs new HW, improve performance etc. But downside of it is, that it can cause issues elsewhere. R. > > Thanks! > > -- > Later, > Lukas #lzap Zapletal > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Are we rebasing xorg-x11 packages in F20?
On 25.11.2014 10:26, drago01 wrote: > On Tue, Nov 25, 2014 at 9:14 AM, Lukas Zapletal wrote: >> Hello, >> >> my desktop was completely broken this morning because my startup scripts >> rely on xrandr utility. An older update from this summer which I applied >> recently changed it's output so device ids now contain dash characters >> (e.g. instead VGA0 I see VGA-1). > > Which desktop are you using? You shouldn't have to mess with startup > scripts that call xrandr to get a monitor setup working. > Oh, is it really so? $ lightdm --show-config [LightDM] A minimum-vt=1 [SeatDefaults] A greeter-session=lightdm-greeter A session-wrapper=/etc/X11/xinit/Xsession A display-setup-script=/usr/bin/conf-nouveau Sources: A /etc/lightdm/lightdm.conf -- 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: Are we rebasing xorg-x11 packages in F20?
> There's an intel driver from 18th november, for example: > > https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 > > This seems to be much more related to your issues. I don't had any output > renaming recently in the past year (Nouveau here). That answers the question why I experienced the change today, and not six months ago :-) I understand why drivers are updated for stable releases, that's fine. Not sure about the Critical Path (graphics drivers can bite, more testing time is perhaps the better) but if this is our policy, there must be some reasons for that. Thanks! -- Later, Lukas #lzap Zapletal -- 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: Are we rebasing xorg-x11 packages in F20?
On 25 November 2014 at 13:20, Lukas Zapletal wrote: > I don't understand why I noticed this today, it looks like the latest > update was a Critical Path one (???) when Fedora 20 was stable for six > months. > > > https://admin.fedoraproject.org/updates/FEDORA-2014-7331/xorg-x11-server-utils-7.7-6.fc20 from what I've seen xorg packages are always marked as Critical Path. The update you are referring to is six months old, are you sure the xrandr command is the culprit and not something else? Did you skip updates for six months? There's an intel driver from 18th november, for example: https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20 This seems to be much more related to your issues. I don't had any output renaming recently in the past year (Nouveau here). Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.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: Are we rebasing xorg-x11 packages in F20?
> Anyhow, I hit the same thing this morning, with LVDS1 changing > to LVDS-0, HDMI3 to HDMI-2 and VGA1 to VGA-0. This was on an > Intel adapter. Exactly. I use i3wm and I use xrandr to determine if I have my laptop docked with IPS panel, docked with VGA monitor or standalone. Then I setup all my workspace appropriately. > It's not a big deal, however, it was rather unexpected in the > middle of a stable release... Yeah, I have fixed that after 10 minutes this morning. I just want to ask *why* we rebase things for stable releases. If I want to live on the edge, I use Rawhide. I don't understand why I noticed this today, it looks like the latest update was a Critical Path one (???) when Fedora 20 was stable for six months. https://admin.fedoraproject.org/updates/FEDORA-2014-7331/xorg-x11-server-utils-7.7-6.fc20 Something is not right here. a) We should not be bumping up versions of packages for stable releases. b) We should definitely not do this with Critical Paths. -- Later, Lukas #lzap Zapletal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141125 changes
Compose started at Tue Nov 25 07:15:03 UTC 2014 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [ostree] ostree-grub2-2014.11-1.fc21.armv7hl requires grub2 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc21.noarch requires ldc Broken deps for i386 -- [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 Broken deps for x86_64 -- [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 New package: gnome-shell-extension-background-logo-3.14.0-1.fc21 Background logo extension for GNOME Shell Updated Packages: anaconda-21.48.16-1.fc21 * Thu Nov 20 2014 Samantha N. Bueno - 21.48.16-1 - Support high contrast mode in fedora-welcome (#1160499) (dshea) * Tue Nov 18 2014 Samantha N. Bueno - 21.48.15-1 - do not delete liveimg --url=file:/// file (gczarcinski) - Provide useful hints on TTY1 during the installation (mkolman) - Fix typo from commit 9b3259874. (#1120964) (dlehman) - Remove the old custom partitioning help dialog (mkolman) - Check if we read something when emptying stdin queue (vpodzime) - Require min entropy for 'part --encrypted' devices (#1162695) (vpodzime) - Don't rely on terminal attributes being configurable (#1162702) (vpodzime) - Disable payloads that failed to setup (#1162732) (dshea) - Don't change langpacks config of installer environment (#1066017) (rvykydal) Size change: -174090 bytes ark-4.14.3-2.fc21 - * Tue Nov 18 2014 Rex Dieter 4.14.3-2 - omit KXMLGUIClient patch, it was fixed differently upstream (kde#340991) Size change: -197 bytes cockpit-0.27-2.fc21 --- * Fri Nov 21 2014 Stef Walter - 0.27-2 - Add Fedora specific branding rhbz#1161775 Size change: 54245 bytes fedora-release-21-2 --- * Thu Nov 20 2014 Kalev Lember - 21-2 - Ship an override file to enable the gnome-shell background logo extension in Workstation (#1161637) - fix up handling of schema file from inccorect initail handling - dennis Size change: 829 bytes fedora-repos-21-2 - * Sat Nov 22 2014 Dennis Gilmore 21-2 - Obsolete fedora-repos-anaconda < 21-1 - due to initial confusion over it some people got it installed Size change: 265 bytes freeipa-4.1.1-2.fc21 * Thu Nov 20 2014 Simo Sorce - 4.1.1-2 - Patch blokers and feature freze exceptions - Resolves: bz1165674 - Resolves: bz1165856 (CVE-2014-7850) - Fixes DNS install issue that prevents the server from working Size change: 98438 bytes gearbox-10.11-10.fc21.1 --- * Wed Nov 19 2014 Till Maas - 10.11-10.1 - Really remove ice-devel dependency * Tue Nov 18 2014 Rich Mattes - 10.11-10 - Remove ice requirement in devel subpackage * Tue Nov 18 2014 Rich Mattes - 10.11-9 - Remove ice requirement Size change: 311 bytes gnome-boxes-3.14.2-2.fc21 - * Fri Nov 21 2014 Zeeshan Ali 3.14.2-2 - Temporarily remove libvirt-daemon-config-network dep for rhbz#1164492. Size change: 216 bytes openldap-2.4.40-2.fc21 -- * Fri Nov 14 2014 Jan Synáček - 2.4.40-2 - enhancement: support TLSv1 and later (#1160466) Size change: 1037 bytes python-blivet-0.61.10-1.fc21 * Tue Nov 18 2014 Samantha N. Bueno - 0.61.10-1 - Round filesystem target size to whole resize tool units. (#1163410) (dlehman) - New method to round a Size to a whole number of a specified unit. (dlehman) - Fix units for fs min size padding. (dlehman) - Disable resize operations on filesystems whose current size is unknown. (dlehman) - Run fsck before obtaining minimum filesystem size. (#1162215) (dlehman) - Do not translate empty strings, gettext translates them into system information (vtrefny) - Add more arguments to mpathconf (#1154347) (dshea) Size change: 3865 bytes Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 10 Size of added packages: 64292 (63 k) Size change of modified packages: -15081 (-15 k) Size of removed packages: 0 (0 ) Size change: 49211 (48 k) Compose finished at Tue Nov 25 11:46:53 UTC 2014 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141125 changes
s glibc-2.20.90-9.fc22 * Wed Nov 19 2014 Carlos O'Donell - 2.20.90-9 - Sync with upstream master. Size change: 25438 bytes gnome-logs-3.15.2-1.fc22 * Mon Nov 24 2014 David King - 3.15.2-1 - Update to 3.15.2 Size change: 4839 bytes gofer-2.0.0-1.fc22 -- * Mon Nov 24 2014 Jeff Ortel 2.0.0-1 - The transport concept has been revised and renamed to messaging adapters. - The transport parameter and configuation deprecated. - The URL updated to specify the messaging adapter. - Messaging adapters have descriptors and are loaded much like plugins. - Better unit test coverage. - Performance improvements and bug fixes. Size change: 20772 bytes golang-googlecode-go-exp-0-0.3.hgbd8df7009305.fc22 -- * Fri Nov 21 2014 jchaloup - 0-0.3.hgbd8df7009305 - Extend import paths for golang.org/x/ related: #1148481 * Sun Oct 26 2014 jchaloup - 0-0.2.hgbd8df7009305 - Choose the correct architecture related: #1148481 Size change: -564 bytes golang-googlecode-net-0-0.17.hg90e232e2462d.fc22 * Mon Nov 24 2014 jchaloup - 0-0.17.hg90e232e2462d - Extend import paths for golang.org/x/ - context test failing on master related: #1009967 Size change: -184 bytes golang-googlecode-text-0-0.2.hg024681b033be.fc22 * Fri Nov 21 2014 jchaloup - 0-0.2.hg024681b033be - Extend import paths for golang.org/x/ - Choose the correct architecture related: #1056285 Size change: -435 bytes google-roboto-fonts-1.2-5.fc22 -- * Mon Nov 24 2014 David Tardon - 1.2-5 - use just Roboto as the font's name in metainfo Size change: -971 bytes gradle-2.2-4.fc22 - * Mon Nov 24 2014 Mikolaj Izdebski - 2.2-4 - Add support for custom Wagon providers * Mon Nov 24 2014 Mikolaj Izdebski - 2.2-3 - Restore support for userName in authentication info Size change: 50 bytes gsi-openssh-6.6.1p1-3.fc22 -- * Mon Nov 24 2014 Mattias Ellert - 6.6.1p1-3 - Based on openssh-6.6.1p1-8.fc21 Size change: 3974 bytes gtk3-3.15.2-1.fc22 -- * Mon Nov 24 2014 Kalev Lember - 3.15.2-1 - Update to 3.15.2 Size change: 87358 bytes javapackages-tools-4.2.0-8.fc22 --- * Mon Nov 24 2014 Michal Srb - 4.2.0-8 - Add namespace support in %mvn_artifact Size change: 1164 bytes jenkins-icon-shim-1.0.4-1.fc22 -- * Mon Nov 24 2014 Michal Srb - 1.0.4-1 - Update to upstream version 1.0.4 Size change: 992 bytes julia-0.3.3-1.fc22 -- * Sun Nov 23 2014 Milan Bouchet-Valat - 0.3.3-1 - New upstream release. - Bump libuv to follow upstream. Size change: 11726 bytes kernel-3.18.0-0.rc6.git0.1.fc22 --- * Mon Nov 24 2014 Josh Boyer - Linux v3.18-rc6 - Add quirk for Laser Mouse 6000 (rhbz 1165206) * Fri Nov 21 2014 Josh Boyer - Move TPM drivers to main kernel package (rhbz 1164937) * Wed Nov 19 2014 Josh Boyer - Disable SERIAL_8250 on s390x (rhbz 1158848) Size change: 28170 bytes kf5-5.4.0-2.fc22 * Mon Nov 24 2014 Rex Dieter 5.4.0-2 - macros.kf5: PATH, prepend %_qt5_bindir instead of %_kf5_bindir (ie, /usr/bin) Size change: -929 bytes kubernetes-0.5-125.0.git162e498.fc22 * Mon Nov 24 2014 Eric Paris - 0.5-125.0.git162e498 - Bump to upstream 162e4983b947d2f6f858ca7607869d70627f5dff Size change: 1911 bytes ldns-1.6.17-12.fc22 --- * Mon Nov 24 2014 Paul Wouters - 1.6.17-11 - Only cond_without sets "with ", so use underscores - multilib.patch was setting LIBDIR_SEC once without leading / Size change: 227 bytes libappstream-glib-0.3.3-1.fc22 -- * Mon Nov 24 2014 Richard Hughes 0.3.3-1 - New upstream release - Allow filtering addons in the status html pages - Detect missing parents in the old metadata - Do not fail to load all the desktop files if one is bad - Improve appdata-xml.m4 deprecation notice Size change: -1038 bytes libdom-0.1.1-1.fc22 --- * Mon Sep 01 2014 Christopher Meng - 0.1.1-1 - Update to 0.1.1 Size change: 30273 bytes libgusb-0.2.1-1.fc22 * Mon Nov 24 2014 Richard Hughes 0.2.1-1 - New upstream version - Always set a device platform ID - Ignore 'unsupported' as a return value for kernel drivers Size change: -786 bytes libodfgen-0.1.2-1.fc22 -- * Mon Nov 24 2014 David Tardon - 0.1.2-1 - new upstream release Size change: 8231 bytes linpsk-1.2-5.fc22 - * Mon Nov 24 2014 Jaroslav Škarvada - 1.2-5 - Used 64x64 icon from SVN Resolves: rhbz#1157554 Size change: 943 bytes net-tools-2.0-0.31.20141124git.fc22 --- * Mon Nov 24 2014 Jiri Popelka - 2.0-0.31.20141124git - latest upstream snapshot (#1162284) S
Re: Are we rebasing xorg-x11 packages in F20?
On Tue, Nov 25, 2014 at 10:26:43AM +0100, drago01 wrote: > On Tue, Nov 25, 2014 at 9:14 AM, Lukas Zapletal wrote: > > Hello, > > > > my desktop was completely broken this morning because my startup scripts > > rely on xrandr utility. An older update from this summer which I applied > > recently changed it's output so device ids now contain dash characters > > (e.g. instead VGA0 I see VGA-1). > > Which desktop are you using? You shouldn't have to mess with startup > scripts that call xrandr to get a monitor setup working. We have plenty of simple window managers in Fedora. These generally don't do things like monitor setup for you. Anyhow, I hit the same thing this morning, with LVDS1 changing to LVDS-0, HDMI3 to HDMI-2 and VGA1 to VGA-0. This was on an Intel adapter. It's not a big deal, however, it was rather unexpected in the middle of a stable release... P pgp53IdQwV702.pgp Description: PGP signature -- 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: Are we rebasing xorg-x11 packages in F20?
On 25/11/14 09:26, drago01 wrote: > Which desktop are you using? You shouldn't have to mess with startup > scripts that call xrandr to get a monitor setup working. Here's one example: Intel drv, monitor with broken EDID, Gnome 3.12. This is limited to either 800x60 or 1024x768 (forget which). (Have not tested this on 3.14.) Colin 0xC5326EE5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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: Are we rebasing xorg-x11 packages in F20?
On Tue, Nov 25, 2014 at 9:14 AM, Lukas Zapletal wrote: > Hello, > > my desktop was completely broken this morning because my startup scripts > rely on xrandr utility. An older update from this summer which I applied > recently changed it's output so device ids now contain dash characters > (e.g. instead VGA0 I see VGA-1). Which desktop are you using? You shouldn't have to mess with startup scripts that call xrandr to get a monitor setup working. -- 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: Suggested Freeze Policy change for Fedora 22+
On Mon, Nov 24, 2014 at 8:46 PM, Stephen Gallagher wrote: > > > Yeah, that's a valid concern and one I'm not ignoring. I'm just > concerned that (going by F21 Alpha and Beta) the "hero testing" doesn't > result in avoiding a slip most of the time. In the case of Alpha, that > was going on for a month before we finally were able to release. That's > not fair to QA and it *certainly* doesn't make it seem like something > new contributors would want to put themselves through. If your goal is preventing slips you are doing it wrong (tm). Your proposal would as Kevin said just result into *more* slips. What we should do is to find out *why* we slip every time and address that. The handling of the Go/NoGo meeting isn't really the problem, you are fighting the symptoms instead of the disease. So you'd have to 1) find out what causes us to slip so often (*cough* anaconda *cough* [1]) and 2) talk to the related developers / involved parties to find a way to solve it in a way that is acceptable to both sides (in that example rel eng / qa / anaconda devs). 1: Ok I didn't check the data but my impression is that most blocker bugs are in that area I might be wrong though ... but the data is available to check that. -- 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: Are we rebasing xorg-x11 packages in F20?
> Using what gfxchip? VGA0 I don't remember ever seeing. Most I remember seeing: Yeah, that was a typo. It's actually DP-1 and LVDS-0 (Thinkpad T403s with Intel). Anyway, this changed from DP1 and LVDS0. -- Later, Lukas #lzap Zapletal -- 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: Are we rebasing xorg-x11 packages in F20?
Lukas Zapletal composed on 2014-11-25 09:14 (UTC+0100): > my desktop was completely broken this morning because my startup scripts > rely on xrandr utility. An older update from this summer which I applied > recently changed it's output so device ids now contain dash characters > (e.g. instead VGA0 I see VGA-1). Using what gfxchip? VGA0 I don't remember ever seeing. Most I remember seeing: VGA # Intel analog (old) VGA1# Intel analog HDMI1 # Intel HDMI aka DVI DP1 # Intel DisplayPort VGA-1 # Nouveau analog DVI0# Nouveau & NV DVI DVI-I-1 # Nouveau DVII multihead DVI-I-2 # Nouveau DVII multihead VGA-0 # Radeon analog DVI-0 # Radeon DVI > I just wonder why this landed into stable repository. The package > changelog really shows it's a rolling release kinda thing. > http://pkgs.fedoraproject.org/cgit/xorg-x11-server-utils.git/log/?h=f20 > I understand some packages has exceptions, like kernel, firmware and > such things. But xorg tools? Thanks for explanation. -- "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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Are we rebasing xorg-x11 packages in F20?
On Tue, 2014-11-25 at 09:14 +0100, Lukas Zapletal wrote: > Hello, > > my desktop was completely broken this morning because my startup scripts > rely on xrandr utility. An older update from this summer which I applied > recently changed it's output so device ids now contain dash characters > (e.g. instead VGA0 I see VGA-1). Yeah, it's a bit annoying, just got caught by it myself. I have a simple kvm switch and I can't leave it to defaults or I get a low res display. So I have to use a /etc/X11/xorg.conf.d/00-monitor.conf. > > I just wonder why this landed into stable repository. The package > changelog really shows it's a rolling release kinda thing. > > http://pkgs.fedoraproject.org/cgit/xorg-x11-server-utils.git/log/?h=f20 > > I understand some packages has exceptions, like kernel, firmware and > such things. But xorg tools? Thanks for explanation. > > -- > Later, > Lukas #lzap Zapletal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Are we rebasing xorg-x11 packages in F20?
Hello, my desktop was completely broken this morning because my startup scripts rely on xrandr utility. An older update from this summer which I applied recently changed it's output so device ids now contain dash characters (e.g. instead VGA0 I see VGA-1). I just wonder why this landed into stable repository. The package changelog really shows it's a rolling release kinda thing. http://pkgs.fedoraproject.org/cgit/xorg-x11-server-utils.git/log/?h=f20 I understand some packages has exceptions, like kernel, firmware and such things. But xorg tools? Thanks for explanation. -- Later, Lukas #lzap Zapletal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
