Re: first and only X needs to be on tty7
On 05/05/2014 09:21 PM, Felix Miata wrote: For years, probably since the time of that document, I've had Option"DontZap""off" Option"ZapWarning""off" somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed. I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection -- 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: F21 System Wide Change: Java 8
One of the biggest offenders (Eclipse) is now happily compiling(always has been running fine) with Java 8 and while looking at fixing it many other issues has been identified and fixed so personally I'm fine with OpenJDK7 being obsoleted now. Alexander Kurtakov Red Hat Eclipse team - Original Message - > From: "Aleksandar Kurtakov" > To: "Deepak Bhole" , "Development discussions related to > Fedora" > Sent: Wednesday, March 26, 2014 3:41:30 PM > Subject: Re: F21 System Wide Change: Java 8 > > I'm not proposing having OpenJDK7 in Fedora 21. What I'm asking for is to > have them both for a month or two before obsoleting so transition can be > smoother if problems appear. > > Alexander Kurtakov > Red Hat Eclipse team > > - Original Message - > > From: "Deepak Bhole" > > To: "Development discussions related to Fedora" > > > > Sent: Wednesday, March 26, 2014 3:31:59 PM > > Subject: Re: F21 System Wide Change: Java 8 > > > > * Christopher [2014-03-25 19:59]: > > > I also would like to see 1.7.0 stick around for awhile. Not > > > necessarily as the default, but at least available in the repos. As it > > > stands, it's difficult to use a modern Fedora on projects that are > > > still developing against JDK 1.6. > > > > > > > Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within > > the support time-frame of the F21. This is one the reasons why we would > > like to be able to switch over to OpenJDK8 asap for F21. > > > > 1: http://www.oracle.com/technetwork/java/eol-135779.html > > > > Deepak > > > > > -- > > > Christopher L Tubbs II > > > http://gravatar.com/ctubbsii > > > > > > > > > On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov > > > wrote: > > > > Please keep java 1.7.0 around for some time. It would make moving > > > > easier > > > > if we have to jump back for a build or two. > > > > > > > > Alexander Kurtakov > > > > Red Hat Eclipse team > > > > > > > > - Original Message - > > > >> From: "Omair Majid" > > > >> To: "Development discussions related to Fedora" > > > >> > > > >> Sent: Tuesday, March 25, 2014 9:07:39 PM > > > >> Subject: Re: F21 System Wide Change: Java 8 > > > >> > > > >> * Mikolaj Izdebski [2014-03-24 11:55]: > > > >> > That's exactly the problem. We need to use a modified version of > > > >> > java-1.8.0-openjdk with extra provides and adjusted priorities for > > > >> > alternatives. > > > >> > > > >> I have started a new java-1.8.0-openjdk build that should fix this: > > > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 > > > >> > > > >> > Blocking java-1.7.0-oepnjdk may also be required. > > > >> > This > > > >> > makes it impossible to scratch-build Java packages using f21-build > > > >> > target in current state. > > > >> > > > >> Is there anything I can/should do here? Shall I file a rel-eng ticket > > > >> to > > > >> block java-1.7.0-openjdk? Would it be worth waiting a little while to > > > >> ensure that there are no show-stopper bugs in java-1.8.0-openjdk? > > > >> > > > >> Thanks, > > > >> Omair > > > >> > > > >> -- > > > >> PGP Key: 66484681 (http://pgp.mit.edu/) > > > >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > > > >> -- > > > >> 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 > > > -- > > > 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 > -- > 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: F21 System Wide Change: Java 8
is this version of eclipse be ported to rhel dev tools for rhel-6 and rhel-7? On 05/06/2014 09:50 AM, Aleksandar Kurtakov wrote: > One of the biggest offenders (Eclipse) is now happily compiling(always has > been running fine) with Java 8 and while looking at fixing it many other > issues has been identified and fixed so personally I'm fine with OpenJDK7 > being obsoleted now. > > Alexander Kurtakov > Red Hat Eclipse team > > - Original Message - >> From: "Aleksandar Kurtakov" >> To: "Deepak Bhole" , "Development discussions related to >> Fedora" >> Sent: Wednesday, March 26, 2014 3:41:30 PM >> Subject: Re: F21 System Wide Change: Java 8 >> >> I'm not proposing having OpenJDK7 in Fedora 21. What I'm asking for is to >> have them both for a month or two before obsoleting so transition can be >> smoother if problems appear. >> >> Alexander Kurtakov >> Red Hat Eclipse team >> >> - Original Message - >>> From: "Deepak Bhole" >>> To: "Development discussions related to Fedora" >>> >>> Sent: Wednesday, March 26, 2014 3:31:59 PM >>> Subject: Re: F21 System Wide Change: Java 8 >>> >>> * Christopher [2014-03-25 19:59]: I also would like to see 1.7.0 stick around for awhile. Not necessarily as the default, but at least available in the repos. As it stands, it's difficult to use a modern Fedora on projects that are still developing against JDK 1.6. >>> >>> Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within >>> the support time-frame of the F21. This is one the reasons why we would >>> like to be able to switch over to OpenJDK8 asap for F21. >>> >>> 1: http://www.oracle.com/technetwork/java/eol-135779.html >>> >>> Deepak >>> -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov wrote: > Please keep java 1.7.0 around for some time. It would make moving > easier > if we have to jump back for a build or two. > > Alexander Kurtakov > Red Hat Eclipse team > > - Original Message - >> From: "Omair Majid" >> To: "Development discussions related to Fedora" >> >> Sent: Tuesday, March 25, 2014 9:07:39 PM >> Subject: Re: F21 System Wide Change: Java 8 >> >> * Mikolaj Izdebski [2014-03-24 11:55]: >>> That's exactly the problem. We need to use a modified version of >>> java-1.8.0-openjdk with extra provides and adjusted priorities for >>> alternatives. >> >> I have started a new java-1.8.0-openjdk build that should fix this: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 >> >>> Blocking java-1.7.0-oepnjdk may also be required. >>> This >>> makes it impossible to scratch-build Java packages using f21-build >>> target in current state. >> >> Is there anything I can/should do here? Shall I file a rel-eng ticket >> to >> block java-1.7.0-openjdk? Would it be worth waiting a little while to >> ensure that there are no show-stopper bugs in java-1.8.0-openjdk? >> >> Thanks, >> Omair >> >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> -- >> 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 -- 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 >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Levente "Si vis pacem para bellum!" -- 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: F21 System Wide Change: Java 8
- Original Message - > From: "Farkas Levente" > To: "Development discussions related to Fedora" > > Sent: Tuesday, May 6, 2014 11:23:18 AM > Subject: Re: F21 System Wide Change: Java 8 > > is this version of eclipse be ported to rhel dev tools for rhel-6 and > rhel-7? As you probably have guessed I can not answer such questions. You can either speak to your TAM or wait for public announcements. Alexander Kurtakov Red Hat Eclipse team > > On 05/06/2014 09:50 AM, Aleksandar Kurtakov wrote: > > One of the biggest offenders (Eclipse) is now happily compiling(always has > > been running fine) with Java 8 and while looking at fixing it many other > > issues has been identified and fixed so personally I'm fine with OpenJDK7 > > being obsoleted now. > > > > Alexander Kurtakov > > Red Hat Eclipse team > > > > - Original Message - > >> From: "Aleksandar Kurtakov" > >> To: "Deepak Bhole" , "Development discussions related > >> to Fedora" > >> Sent: Wednesday, March 26, 2014 3:41:30 PM > >> Subject: Re: F21 System Wide Change: Java 8 > >> > >> I'm not proposing having OpenJDK7 in Fedora 21. What I'm asking for is to > >> have them both for a month or two before obsoleting so transition can be > >> smoother if problems appear. > >> > >> Alexander Kurtakov > >> Red Hat Eclipse team > >> > >> - Original Message - > >>> From: "Deepak Bhole" > >>> To: "Development discussions related to Fedora" > >>> > >>> Sent: Wednesday, March 26, 2014 3:31:59 PM > >>> Subject: Re: F21 System Wide Change: Java 8 > >>> > >>> * Christopher [2014-03-25 19:59]: > I also would like to see 1.7.0 stick around for awhile. Not > necessarily as the default, but at least available in the repos. As it > stands, it's difficult to use a modern Fedora on projects that are > still developing against JDK 1.6. > > >>> > >>> Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within > >>> the support time-frame of the F21. This is one the reasons why we would > >>> like to be able to switch over to OpenJDK8 asap for F21. > >>> > >>> 1: http://www.oracle.com/technetwork/java/eol-135779.html > >>> > >>> Deepak > >>> > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov > wrote: > > Please keep java 1.7.0 around for some time. It would make moving > > easier > > if we have to jump back for a build or two. > > > > Alexander Kurtakov > > Red Hat Eclipse team > > > > - Original Message - > >> From: "Omair Majid" > >> To: "Development discussions related to Fedora" > >> > >> Sent: Tuesday, March 25, 2014 9:07:39 PM > >> Subject: Re: F21 System Wide Change: Java 8 > >> > >> * Mikolaj Izdebski [2014-03-24 11:55]: > >>> That's exactly the problem. We need to use a modified version of > >>> java-1.8.0-openjdk with extra provides and adjusted priorities for > >>> alternatives. > >> > >> I have started a new java-1.8.0-openjdk build that should fix this: > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 > >> > >>> Blocking java-1.7.0-oepnjdk may also be required. > >>> This > >>> makes it impossible to scratch-build Java packages using f21-build > >>> target in current state. > >> > >> Is there anything I can/should do here? Shall I file a rel-eng ticket > >> to > >> block java-1.7.0-openjdk? Would it be worth waiting a little while to > >> ensure that there are no show-stopper bugs in java-1.8.0-openjdk? > >> > >> Thanks, > >> Omair > >> > >> -- > >> PGP Key: 66484681 (http://pgp.mit.edu/) > >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > >> -- > >> 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 > -- > 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 > >> -- > >> devel mailing list > >> devel@lists.fedoraproject.org > >> https://admin.fedoraproject.org/mailman/listinfo/devel > >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > -- > Levente "Si vis pacem para bellum!" > -- > devel mailing list > devel@lists
PHPUnit 4.1 in rawhide/epel7
Hi, FYI, I just finished the update of PHPUnit 4.1 in rawhide/epel7. This new major version is no more from pear channel, but from git sources (the "phpunit" pear channel is no more updated and will closed soon). Remi. -- 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 1094660] New: ctstream-19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1094660 Bug ID: 1094660 Summary: ctstream-19 is available Product: Fedora Version: rawhide Component: ctstream Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 19 Current version/release in Fedora Rawhide: 18-1.fc21 URL: http://xpisar.wz.cz/ctstream/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=8QxgQtJ7go&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: making Ctrl-Alt-Bksp work (was: first and only X needs to be on tty7)
On 2014-05-06 00:13 (GMT-0700) Samuel Sieb composed: Felix Miata wrote: For years, probably since the time of that document, I've had Option"DontZap""off" Option"ZapWarning""off" somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed. I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection Thank you! Turns out DontZap works with either false or off, but the difference between SUSE and Fedora is the addtional need for XkbOptions in Fedora, and here's why: /usr/share/X11/xkb/rules/ --- evdev 2014-01-29 22:45:32.0 -0500 +++ evdev-suse 2014-04-09 15:51:53.0 -0400 @@ -857,9 +857,9 @@ *yu unicodeyz = +srp(latinunicodeyz):4 ! model= symbols - $evdevkbds= +inet(evdev)+inet(%m) - applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys) - * = +inet(evdev) + $evdevkbds= +inet(evdev)+inet(%m)+terminate(ctrl_alt_bksp) + applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)+terminate(ctrl_alt_bksp) + * = +inet(evdev)+terminate(ctrl_alt_bksp) ! modellayout = symbols Using the SUSE evdev file in place of Fedora's my original xorg.con* that used to work also in Fedora works in it again without need for the XkbOptions addition. -- "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
Mass-bug filing for removed OpenJDK 9 internal APIs
I plan to file bugs against packages which contain hard (i.e. not reflection-based) references to internal OpenJDK classes and methods which have been removed from OpenJDK 9. The total number of affected packages is around 40. The bug reports will mention the recommended replacements in the public API. This does not affect features like the support for pointer arithmetic and arbitrary memory access, at least not until they are removed upstream. Comments? -- Florian Weimer / Red Hat Product Security Team -- 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-java] Mass-bug filing for removed OpenJDK 9 internal APIs
On 05/06/2014 02:00 PM, Florian Weimer wrote: > I plan to file bugs against packages which contain hard (i.e. not > reflection-based) references to internal OpenJDK classes and methods > which have been removed from OpenJDK 9. The total number of affected > packages is around 40. The bug reports will mention the recommended > replacements in the public API. > > This does not affect features like the support for pointer arithmetic > and arbitrary memory access, at least not until they are removed upstream. > > Comments? IMO go ahead, but please add them to some tracking bug. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Don't use at_console in DBus policy files
at_console="true" (or similar) in a DBus policy file uses pam_console to try to limit sending of messages to a DBus service. This is an old relic from before polkit. Many distros that don't implement it, or implement it completely differently. Last time I heard, kdbus won't support it. NetworkManager has removed at_console from their policy [0] and I've filed some bugs against firewalld [1], setroubleshoot [2], abrt [3] to remove it from the relevant DBus policy files. Is there a good way to grep across the whole of Fedora to see which other packages have at_console in their /etc/dbus-1/*/* policy? Cheers, Stef [0] https://bugzilla.redhat.com/show_bug.cgi?id=979416 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1094745 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1094752 [3] https://github.com/abrt/abrt/pull/816 -- 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: first and only X needs to be on tty7
Hi, On 05/05/2014 05:45 PM, Felix Miata wrote: > On 2014-05-05 12:34 (GMT+0200) Lennart Poettering composed: > >> Felix Miata wrote: > >>> How can I get it to go there and stay there? When starting F21 in >>> multi-user, logging in on tty3 and running startx, KDE shows up on >>> tty3, where, as it's currently broken[1], it needs to be killed to >>> escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* >>> entries intended that Ctrl-Alt-BS be enabled for that purpose), and >>> switching to tty3 is unavailable to use Ctrl-C to kill it as can be >>> done when started from tty3 but running on tty7. The only way out is >>> logging in somewhere else, or CAD. This shouldn't be. > >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1092852 > >> To get the device permissions right startx can only "upgrade" a text >> session to a graphical one, > > There is a relatively recent change, as it used to be that the first X > instance would always start on tty7 no matter how started. I still have a DM > running there if in graphical target. > > What is this permissions business? IOW, what search terms would lead me to an > explanation of the changes, or at least a non-simplistic but not overly > detailed why they occurred? > >> it cannot open a new VT. > > Why? Part of the reasons are explained here: http://hansdegoede.livejournal.com/14268.html Note that this only is valid from F-21 on-wards, but it is strongly related to why it cannot be done either in F-20. Regards, Hans -- 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: Don't use at_console in DBus policy files
On Tue, May 06, 2014 at 02:29:38PM +0200, Stef Walter wrote: > Is there a good way to grep across the whole of Fedora to see which > other packages have at_console in their /etc/dbus-1/*/* policy? Here is one way to do this: repoquery --whatprovides '/etc/dbus-1/*/*' The above command will list all the RPMs in your version of Fedora that contain a file matching that pattern (not just ones containing at_console). Note you must use quotes around the wildcard. To download them, do: cd /tmp mkdir test cd test wget `repoquery --location --whatprovides '/etc/dbus-1/*/*'` Now you can unpack those and examine them: for f in *.rpm; do rpm2cpio $f | cpio -id; done grep at_console etc/dbus-1/*/* To match the filename back to the original package, use something like this: $ repoquery --whatprovides /etc/dbus-1/system.d/FirewallD.conf firewalld-0:0.3.9.3-1.fc20.noarch firewalld-0:0.3.8-1.fc20.noarch HTH, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- 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: Don't use at_console in DBus policy files
On Fedora 20, I'm seeing this list: /etc/dbus-1/system.d/bluetooth.conf: bluez-0:5.12-1.fc20.x86_64 /etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf: system-config-printer-libs-0:1.4.3-2.fc20.noarch /etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf: system-config-printer-libs-0:1.4.3-2.fc20.noarch /etc/dbus-1/system.d/com.redhat.tuned.conf: tuned-0:2.3.0-2.fc20.noarch tuned-0:2.3.0-3.fc20.noarch /etc/dbus-1/system.d/connman.conf: connman-0:1.21-1.fc20.x86_64 /etc/dbus-1/system.d/dbus-abrt.conf: abrt-dbus-0:2.2.1-1.fc20.x86_64 /etc/dbus-1/system.d/FirewallD.conf: firewalld-0:0.3.9.3-1.fc20.noarch /etc/dbus-1/system.d/nm-ifcfg-rh.conf: NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 /etc/dbus-1/system.d/nm-user-settings.conf: sugar-0:0.100.2-1.fc20.noarch /etc/dbus-1/system.d/ofono.conf: ofono-0:1.14-1.fc20.x86_64 /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf: setroubleshoot-server-0:3.2.17-1.fc20.x86_64 /etc/dbus-1/system.d/org.fedoraproject.SetroubleshootFixit.conf: setroubleshoot-server-0:3.2.17-1.fc20.x86_64 /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf: NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 /etc/dbus-1/system.d/org.selinux.conf: policycoreutils-python-0:2.2.5-3.fc20.x86_64 /etc/dbus-1/system.d/wicd.conf: wicd-common-0:1.7.2.4-7.fc20.noarch /etc/dbus-1/system.d/yum-updatesd.conf: yum-updatesd-1:0.9-15.fc20.noarch Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote: > On Mon, May 5, 2014 at 6:15 PM, Matthew Miller > wrote: > > > And calling /usr/libexec "Fedora-only" is of course kind of > > funny. > > "libexec" is Fedora-only, no other major distro used it, not even LSB > allowed it. > > It makes no sense to ever have that, and the rest of the world > realized that long ago. libexec is from the GNU Coding Standards, which a lot of Linux-isms come from: http://www.gnu.org/prep/standards/standards.html The rationale was always clear to me: libexec is for storing executable programs to be run by other programs rather than directly by users. *Even* GNU violates this "standard" with the installation of /usr/lib/gcc (among other things). The FSSTND, FHS, and LSB never made mention of libexec. They neither forbid it nor explicitly required it, so it's like every other made up standard that came along. No one really cared enough to stop it because it didn't matter. I think the annoying thing is if you're typing out a path that includes /usr/lib, you can't easily hit TAB to get in to lib. And that's worth fixing. -- David Cantrell Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- 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 1094395] perl-IPC-Run make check failure for ppc64le archi
https://bugzilla.redhat.com/show_bug.cgi?id=1094395 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Fixed In Version||perl-IPC-Run-0.92-5.fc21 Resolution|--- |RAWHIDE Assignee|st...@silug.org |p...@city-fan.org Last Closed||2014-05-06 10:08:13 --- Comment #1 from Paul Howarth --- Test suite patch applied in perl-IPC-Run-0.92-5.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=UcnrN41xua&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: Incorrect order of /usr/bin and /usr/sbin in path
2014-05-06 16:06 GMT+02:00 David Cantrell :
> I think the annoying thing is if you're typing out a path that includes
> /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> fixing.
>
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
2) Changing the file system hierarchy and repackaging dozens of hundreds of
packages to make tab completion, let alone tab completion for files that
users shouldn't ordinarily explicitly refer to, easier, is *not* worth
doing.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Jason Taylor
Hi All, In my adventures in the world of Linux admin work I recently came across a need for a package that isn't in the Fedora or EPEL repositories. This led me down the path of submitting (https://bugzilla.redhat.com/show_bug.cgi?id=1094804). This is the my first attempt at packaging but am very interested in doing more. I followed the package maintainer guide so hopefully I didn't do anyhing too terrible. Any help or pointers welcomed. TIA.. Regards, JT Jason Taylor | Secure-24 | 26955 Northwestern Highway, Ste. 200 | Southfield | MI | 48033 | USA | www.Secure-24.com | W (248) 784-1021 ext. 617 | C (586) 298-2072 | jason.tay...@secure-24.com This communication and any attached files may contain information that is confidential or privileged. Any unauthorized review, use, disclosure or distribution is prohibited. If this communication has been received in error, please notify me and delete or destroy it immediately. -- 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-05-07)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 #topic #1250 F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250 #topic #1291 F21 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 .fesco 1291 https://fedorahosted.org/fesco/ticket/1291 #topic #1297 F21 System Wide Change: Workstation: Enable Software Collections - https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections .fesco 1297 https://fedorahosted.org/fesco/ticket/1297 = New business = #topic #1303 Add exception for enabling nss-pam-ldapd's nslcd to start by default in obsoleting-install cases .fesco 1303 https://fedorahosted.org/fesco/ticket/1303 #topic #1304 replacing reSIProcate in Fedora 20 .fesco 1304 https://fedorahosted.org/fesco/ticket/1304 #topic #1305 F21 System Wide Change: Application Installer Continued - https://fedoraproject.org/wiki/Changes/AppInstallerContinued .fesco 1305 https://fedorahosted.org/fesco/ticket/1305 #topic #1306 F21 System Wide Change: Wayland - https://fedoraproject.org/wiki/Changes/Wayland .fesco 1306 https://fedorahosted.org/fesco/ticket/1306 #topic #1307 F22 System Wide Change: Default Local DNS Resolver - https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver .fesco 1307 https://fedorahosted.org/fesco/ticket/1307 #topic #1302 Fedora Core OS Product .fesco 1302 https://fedorahosted.org/fesco/ticket/1302 = 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. -- 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: Incorrect order of /usr/bin and /usr/sbin in path
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
>2014-05-06 16:06 GMT+02:00 David Cantrell <[1]dcantr...@redhat.com>:
>
> I think the annoying thing is if you're typing out a path that
> includes
> /usr/lib, you can't easily hit TAB to get in to lib. Â And that's
> worth
> fixing.
>
>Oh my...
>1) With the existence of /usr/lib{,64}, the additional existence of
>/usr/libexec doesn't make any difference AFAICT.
Yeah, that's true. The system in front of me is apparently still 32-bit.
>2) Changing the file system hierarchy and repackaging dozens of
>hundreds of packages to make tab completion, let alone tab completion
>for files that users shouldn't ordinarily explicitly refer to, easier,
>is not worth doing.
I agree with this. We're talking about janitorial work here and just
generating a lot of change. I'm not opposed to it if we were just something
we said, "hey, they next time you update your package, can you move these
files" and then eventually libexec would just empty out. Or not, I
really have no strong opinions either way.
--
David Cantrell
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
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: Incorrect order of /usr/bin and /usr/sbin in path
On 05/06/2014 12:25 AM, Toshio Kuratomi wrote:
>
> %{_libexecdir} and %{_libdir}/$pkg are both valid in the packaging
> guidelines.
Yep, and both valid variants differ from what other distros use. Debian
uses /usr/lib/$pkg for @libexecdir@.
>
> If upstream is using the autotools you should just use @pkglibexecdir@ or
> @libexecdir@. Linux distributions, BSDs and etc all set --libexecdir to
> the proper location for their tastes.
I agree with you here. As long as the helpers are only used internally,
it's indeed very simple. It doesn't matter what it exactly expands to:
the app can always find its own files since it can easily keep track how
it was configured.
But there is another class of packages that provide system wide
services. Those packages install system wide helpers and expect _other_
programs to run these.
At that point, the location of /usr/libexec/ vs /usr/lib/$pkg/ vs
/usr/$lib/$pkg becomes the interface that other programs are supposed to
use. And when those differ between different distros, it becomes
difficult for _consumers_ to know where they are installed.
This is why systemd insists on using /usr/lib/systemd on all distros so
that it would be consistent for consumers.
(I wrote a long text here how I ran into this issue having to detect
/usr/libexec/pk-trigger-offline-update (Fedora) vs
/usr/lib/packagekit/pk-trigger-offline-update (Debian), but decided to
delete it since it seemed too specialized.)
> If upstream does not use autotools then they may end up having to do
> a platform check for helper_dir. But they could also end up having to do
> a platform check for shared libraries or arch-specific data files. The
> difference between Fedora and other distros is really multilib, not libexec.
No, I disagree, those are separate issues.
Using /usr/lib/$pkg for helper binaries is no more or no less multilib
compatible than /usr/libexec. Neither one supports parallel installation
of executables.
>> Relaxing the guidelines would allow those upstreams to write saner code,
>> and be more compatible across various distributions.
>
> If we get rid of multilib then that would be fine otherwise it'll be more
> error prone to add %{_prefix}/lib into the mix with %{_libexecdir} and
> %{_libdir}. Most upstreams do not know about or care about multilib. This
> means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
> that must go in %{_libdir}/$pkg.
Yes, that's a fair point. More options makes it easier for packagers to
mess up in some way. I guess that's also why some people here are
advocating for complete removal of /usr/libexec to reduce the number of
options.
--
Kalev
--
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-java] Mass-bug filing for removed OpenJDK 9 internal APIs
- Original Message - > From: "Florian Weimer" > To: "Development discussions related to Fedora" > , "Fedora Java Development List" > > Sent: Tuesday, May 6, 2014 3:00:54 PM > Subject: [fedora-java] Mass-bug filing for removed OpenJDK 9 internal APIs > > I plan to file bugs against packages which contain hard (i.e. not > reflection-based) references to internal OpenJDK classes and methods > which have been removed from OpenJDK 9. The total number of affected > packages is around 40. The bug reports will mention the recommended > replacements in the public API. > > This does not affect features like the support for pointer arithmetic > and arbitrary memory access, at least not until they are removed upstream. > > Comments? It seems resonable to report these bugs to upstream projects too. OpenJDK 9 is just too early in development to take it seriously from Fedora POV now. I don't mind having tracking bug @fedora but if it's not sent upstream it will stay that way at least until Fedora starts to ship OpenJDK 9 JVM. Alexander Kurtakov Red Hat Eclipse team > > -- > Florian Weimer / Red Hat Product Security Team > -- > java-devel mailing list > java-de...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- 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 20 Puppet update and SELinux policy
Hey all, I am going to push the update to stable. There were no reports of misbehavior. In any case, check for AVC denials after Puppet upgrade and relabel system if necessary. LZ On Tue, Apr 22, 2014 at 02:46:33PM +0200, Lukas Zapletal wrote: > Hello, > > we are rolling out update of Puppet to 3.4.3 in Fedora 20 and Rawhide that > adds one important change. We have found that puppet master was running > unconfined, therefore the Puppet SELinux policy was not effective in Fedoras. > > The puppet package update fixes one little issue (missing runtime > dependency) and corrects startup wrappers for systemd which puts Puppet > Master into the correct SELinux domain puppetmaster_t. Since this has > some security impact, we have decided to backport this change into > Fedora 20 too. > > https://admin.fedoraproject.org/updates/puppet-3.4.3-3.fc20 > > Until now, puppet master was running unconfined (this is a regression), > the update might need relabelling of the system (/etc/puppet, > /var/lib/puppet) or checking out audit.log. Please help me with testing > this update: > > yum --enablerepo=updates-testing update selinux-policy puppet > puppet-server > > Thanks for help. > > -- > Later, > > Lukas "lzap" Zapletal > irc: lzap #theforeman > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Later, Lukas "lzap" Zapletal irc: lzap #theforeman -- 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: Don't use at_console in DBus policy files
On Tue, 2014-05-06 at 14:36 +0100, Richard W.M. Jones wrote: > On Fedora 20, I'm seeing this list: > > /etc/dbus-1/system.d/nm-ifcfg-rh.conf: > NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 > /etc/dbus-1/system.d/nm-user-settings.conf: sugar-0:0.100.2-1.fc20.noarch > /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf: > NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64 The NetworkManager at_console removal is in F21+ as of NM 0.9.9.1 and later, so this would be expected on F20. Dan -- 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: Incorrect order of /usr/bin and /usr/sbin in path
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
> 2014-05-06 16:06 GMT+02:00 David Cantrell :
>
> > I think the annoying thing is if you're typing out a path that includes
> > /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> > fixing.
> >
>
> Oh my...
>
> 1) With the existence of /usr/lib{,64}, the additional existence of
> /usr/libexec doesn't make any difference AFAICT.
Well getting rid of /usr/lib64 and multilib would be another
worthwhile long-term goal. Debian have used a more sensible scheme:
https://wiki.debian.org/Multiarch
For entertainment:
https://bugzilla.redhat.com/show_bug.cgi?id=235752
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
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: Incorrect order of /usr/bin and /usr/sbin in path
On 6 May 2014 10:49, Richard W.M. Jones wrote:
> On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
> > 2014-05-06 16:06 GMT+02:00 David Cantrell :
> >
> > > I think the annoying thing is if you're typing out a path that includes
> > > /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> > > fixing.
> > >
> >
> > Oh my...
> >
> > 1) With the existence of /usr/lib{,64}, the additional existence of
> > /usr/libexec doesn't make any difference AFAICT.
>
> Well getting rid of /usr/lib64 and multilib would be another
> worthwhile long-term goal. Debian have used a more sensible scheme:
>
> https://wiki.debian.org/Multiarch
>
> For entertainment:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=235752
>
>
I would go through the Debian bug system to find all the issues they have
with their multiarch scheme and certain software. Both 'solutions' cause
issues at time and headaches for packagers to sysadmins to users. Now
whether or not one set of headaches/problems is less painful I don't know..
[I only know this because the one thing my Debian friends ever tell me
that Red Hat got right was with multilib versus multiarch ... of course
they could just be throwing me a bone.]
--
Stephen J Smoogen.
--
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: Network-related change from f20->rawhide?
On Mon, 2014-05-05 at 12:34 -0500, Jon Ciesla wrote: > I've got a pair of odd build failures that I'm probably missing something > obvious on. I'm trying to update both openvpn and dietlibc to their latest > upstreams for rawhide. They build fine locally on f20, in mock for f20, > and fail locally in rawhide and mock for rawhide. Looking at the logs, the > code actually seems to build, but the tests are failing. > > Openvpn: > http://kojipkgs.fedoraproject.org//work/tasks/8039/6808039/build.log > > dietlibc: > http://kojipkgs.fedoraproject.org//work/tasks/5251/6815251/build.log > > I'm probably just overbusy and missed something obvious, but if someone > could point me in the right direction I'd appreciate it. > > Thanks in advance, > > -J For the record: RhBug[0] (opened when doesn't work one of my connections) > Tomas Mraz 2014-03-31 05:35:25 EDT > I suppose the certificate is signed with use of MD5 hash. This was disabled > in Rawhide as certificates signed with MD5 hashes are not secure. Please > update your certificates to be signed with at least SHA1 or even better > SHA256. Upstream Bug[1] (Jon opened after some discussion in chat) > Or even better, replace them with a script that generates a test certificate > chain. Such scripts should then indeed use stronger algorithms and larger key > sizes. > Will be fixed 'soonish'. [0]https://bugzilla.redhat.com/show_bug.cgi?id=1081708 [1]https://community.openvpn.net/openvpn/ticket/400 -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Five Things in Fedora This Week (2014-05-06)
Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-05-06/ Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for May 6th, 2014: Add Your Art to Fedora -- Every Fedora release ships with a collection of non-default desktop wallpaper, provided by (and selected by!) the Fedora community. On his blog, Fedora Design Team member Sirko Kemter announces that the artwork submission period for Fedora 21 is now open. Entries must be licensed under a liberal open content license and meet some basic technical and content requirements. The deadline is August 16th, but it never hurts to start creating early. Both submissions and voting are handled by Nuancier, a web application dedicated to the task. You can see last year’s results, too! * http://karl-tux-stadt.de/ktuxs/?p=4579 * https://apps.fedoraproject.org/nuancier/ * https://apps.fedoraproject.org/nuancier/results/1/ LinuxFest Northwest --- The 15th annual LinuxFest Northwest was held last week in (as it always is) Bellingham, Washington. Fedora was well-represented, of course. Jeff Sandys provides a brief blog report on the event, with a title implying more to come. Also worth watching is Brian Lunduke’s annual “Linux Sucks” report. Make sure to stick around for the second half — Fedora comes out rather well overall, despite the talk’s tongue-in-cheek title. * http://www.linuxfestnorthwest.org/ * http://alg0rhythm.livejournal.com/8885.html * https://www.youtube.com/watch?v=5pOxlazS3zs Fedora Regional Budgets --- Fedora Ambassadors are the outreach arm of the project — volunteers who spread the word of our collective greatness. Often, this is through organizing and attending events, and of course that takes money for travel, lodging, swag, and so on. Curious how this breaks down? Jiří Eischmann (a member of FAmSCo, the Fedora Ambassadors Steering Committee) has a blog post reviewing the (just completed) Fiscal Year 2014 Regional Budgets. * https://fedoraproject.org/wiki/Ambassadors * https://fedoraproject.org/wiki/Fedora_Ambassadors_Steering_Committee * https://eischmann.wordpress.com/2014/04/30/fedora-regional-budgets-in-fy2014/ Fedora.next QA Test Plans - Fedora’s Quality Assurance team has been working with the various new Fedora Working Groups (see the Fedora.next article series if you haven’t been following along) to create plans for testing the different products envisioned in the brave new world of Fedora 21 and beyond. At yesterday’s QA meeting, Adam Williamson, Ankur Sinha, and Mike Ruckman discussed draft plan documents for Server, Workstation, and Cloud, and Adam is planning to put the three together and come up with an idea of what overall test coverage looks like. Sound interesting to you? Take a look at the Join QA wiki page, or if you’re especially interested in a particular area, the corresponding Special Interest Group. * https://fedoraproject.org/wiki/QA * http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-i-why/ * https://lists.fedoraproject.org/pipermail/test/2014-May/121261.html * https://fedoraproject.org/wiki/User:Adamwill/Draft_Server_test_outline * https://fedoraproject.org/wiki/User:Ankursinha/Workstation_test_outline * https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs * https://fedoraproject.org/wiki/QA/Join Fedora Dockerfiles Collection - You’ve probably heard of Docker by now — containers have gained huge traction as an attractive alternative to full virtualization, and Docker may be the buzziest container-related technology of all. It provides a simple command-line tool for fetching special images and launching them as application containers, where each gets a special view of the system where it appears to be the only thing running — the process is isolated from the rest of the system. Docker containers bring along their entire runtime, so each image is its own little Fedora (or, of course, other Linux system — CentOS or Ubuntu or whatever, if you want). And these images are created on top of a *base image* using a recipe called a Dockerfile. (It’s something like an RPM spec file or a kickstart script, if you’re familiar with those.) Fedora contributor Scott Collier maintains a collection of examples named, simply enough, `fedora-dockerfiles`, and this week he notes that there’s a new version. This contains examples including the Apache httpd webserver, PostgreSQL database, and many more… even a ready-to-go WordPress installation. Scott also has quick instructions on building and running images from these Dockerfiles in an earlier blog post. It’s pretty simple, really — which is the appeal. Oh, and be aware that we are m
