Re: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 7:13 PM, Marcela Mašláňová wrote: > On 03/25/2014 08:42 AM, Cole Robinson wrote: >> >> On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: >>> >>> On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? >>> Alternative idea -- maybe identify all packages which are not ciritcal >>> and >>> have an open merge review. Take those packages out of the repository. >>> >> >> What does that solve? How does that benefit anybody? >> >>> Then revisit the list and formulate a plan on what to do with thoes (even >>> if >>> the plan is then, these were critical enough to leave in so we'll give >>> them >>> a pass on going through a formal review). >>> >> >> The original premise of these tickets makes sense. But here we are 7+ >> years >> later. The spec we would review today is in many cases nothing like the >> spec >> when the bug was filed. Why should these packages be subject to a review >> _now_ >> when there's a thousand packages in the repo that saw an initial review, >> and >> are then left entirely alone for 6 years? Because 7 years ago we merged >> core >> and extras? I'm not convinced. >> >> The bottom line IMO is that these bugs are generating very little benefit, >> and >> are actively detrimental. They shouldn't be given any extra weight for >> history's sake. >> >> - Cole >> > I concur. Let's close those bugs. If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Looking for a new primary maintainer for gnote
Hi, I'm not using Gnote any more. I've moved to bijiben a while back. Would any one like to take over the package as a primary maintainer? I don't mind helping with updates from time to time since they're generally quite easy, but since I don't use it at all I'm not the best choice for a primary maintainer. Rahul moved away from gnote too so I've taken over ownership temporarily. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, Mar 25, 2014 at 1:07 PM, Kevin Kofler wrote: > My point is that it must ALSO be possible to install the preferred desktop > directly, without installing GNOME first. Exactly this. Installing MATE from the spin is not exactly the same thing as installing it from the netinstall or the DVD. The spin does not include the same packages as the DVD and the netinstall due to size constraints. If we can keep the netinstall, which allows people to do exactly this, then I really could careless what happens with workstation (and I'm also a happy camper, as I imagine you and many others would be too). 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: F21 System Wide Change: Java 8
On Wed, Mar 26, 2014 at 9:59 AM, Christopher wrote: > 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. +1. There's a lot of stuff that simply won't work with 1.8 yet - most of the Atlassian suite for a start. -- Rob K http://ningaui.net I swear, if I collected all seven dragonballs, I'd bring back Jon Postel. - Raph -- 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
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. -- 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
Schedule for Wednesday's FESCo Meeting (2014-03-26)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18: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 HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1178 Fedora 21 scheduling strategy .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 #topic #1243 Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making .fesco 1243 https://fedorahosted.org/fesco/ticket/1243 #topic #1253 requesting exception for linking cscppc and cswrap with glibc-static .fesco 1253 https://fedorahosted.org/fesco/ticket/1253 = New business = #topic #1250 F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250 Security Policy In The Installer - https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller #topic #1262 F21 System Wide Change: Modular Kernel Packaging for Cloud - https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud .fesco 1262 https://fedorahosted.org/fesco/ticket/1262 #1263 F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs .fesco 1263 https://fedorahosted.org/fesco/ticket/1263 #1264 F21 System Wide Change: Ruby on Rails 4.1 .fesco 1264 https://fedorahosted.org/fesco/ticket/1264 #1265 Fedora Plasma Product .fesco 1265 https://fedorahosted.org/fesco/ticket/1265 #topic #1266 Updates to the non-responsive policy .fesco 1266 https://fedorahosted.org/fesco/ticket/1266 = 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
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 703 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 132 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 45 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 34 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0845/asterisk-1.8.26.1-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0846/mediawiki119-1.19.13-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0852/lighttpd-1.4.35-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0888/v8-3.14.5.10-7.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0889/moodle-2.4.9-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0938/seamonkey-2.21-5.ESR_24.4.0.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0951/check-mk-1.2.4-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing check-mk-1.2.4-1.el6 cmockery2-1.3.7-1.el6 fedmsg-0.7.7-1.el6 libxc-2.1.0-2.el6 python-argcomplete-0.7.0-1.el6 python-fedmsg-meta-fedora-infrastructure-0.2.11-1.el6 python-recaptcha-client-1.0.6-4.el6 tcpreplay-4.0.4-1.el6 x2goserver-4.0.1.13-4.el6 Details about builds: check-mk-1.2.4-1.el6 (FEDORA-EPEL-2014-0951) A new general purpose Nagios-plugin for retrieving data Update Information: New upstream release, fixes CVEs: - CVE-2014-2329 - CVE-2014-2330 - CVE-2014-2331 - CVE-2014-2332 ChangeLog: * Tue Mar 25 2014 Andrea Veri - 1.2.4-1 - New upstream release. Fixes the following CVEs: - CVE-2014-2329 - CVE-2014-2330 - CVE-2014-2331 - CVE-2014-2332 References: [ 1 ] Bug #1080303 - CVE-2014-2329 CVE-2014-2330 CVE-2014-2331 CVE-2014-2332 check-mk: multiple flaws fixed in versions 1.2.2p3 and 1.2.3i5 https://bugzilla.redhat.com/show_bug.cgi?id=1080303 cmockery2-1.3.7-1.el6 (FEDORA-EPEL-2014-0959) Lightweight C unit testing framework Update Information: Fixed memory check functions References: [ 1 ] Bug #1079647 - Cmockery2 does not pass tests in el5-ppc arch https://bugzilla.redhat.com/show_bug.cgi?id=1079647 fedmsg-0.7.7-1.el6 (FEDORA-EPEL-2014-0953) Tools for Fedora Infrastructure real-time messaging Update Information: Various enhancements and bugfixes. Fix user warning on import. New options to fedmsg-config. Latest upstream. Seamlessly switch between gpg and x509 validation. Messages carry a new 'crypto' field indicating their signature type. Fixes to fedmsg-tail. ChangeLog: * Tue Mar 25 2014 Ralph Bean - 0.7.7-1 - fedmsg-config and fedmsg-tail now share the --query option. - Added a deployment doc. - New fedmsg.crypto.validate_signed_by convenience function. - Username is now automatically appended to the fedmsg-logger meta subtitle. - A UserWarning is now issued if no fedmsg.meta plugins are found. - Fixed the fedmsg.meta __name__ regex. - Removed TCP_KEEPALIVE debug statements. * Fri Feb 21 2014 Ralph Bean - 0.7.6-2 - Copy test config into the test directory before building. * Fri Feb 21 2014 Ralph Bean - 0.7.6-1 - Latest upstream. - New option to fedmsg-config to query for particular values. - Avoid pkg_resources warning. * Sun Feb 9 2014 Ralph Bean - 0.7.5-1 - Latest upstream. - Gource tail is removed. - Fixes to fedmsg-tail. - Updated documentation. - Messages now carry a 'crypto' field indicating their sig type. - Seamless switching between x509 and gpg crypto validation. References: [ 1 ] Bug #1066625 - UserWarning when importing fedmsg.meta https://bugzilla.redhat.com/show_bug.cgi?id=1066625 ---
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 703 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 193 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 157 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 132 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 122 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 37 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0837/lighttpd-1.4.35-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0834/389-ds-base-1.2.11.28-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0840/mediawiki119-1.19.13-1.el5 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0918/php-pecl-Fileinfo-1.0.4-3.el5,php-pecl-zip-1.8.10-3.el5,php-extras-5.1.6-6.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0952/check-mk-1.2.4-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing check-mk-1.2.4-1.el5 cmockery2-1.3.7-1.el5 libxc-2.1.0-2.el5 python-libcloud-0.14.1-1.el5 tcpreplay-4.0.4-1.el5 Details about builds: check-mk-1.2.4-1.el5 (FEDORA-EPEL-2014-0952) A new general purpose Nagios-plugin for retrieving data Update Information: New upstream release, fixes CVEs: - CVE-2014-2329 - CVE-2014-2330 - CVE-2014-2331 - CVE-2014-2332 ChangeLog: * Tue Mar 25 2014 Andrea Veri - 1.2.4-1 - New upstream release. Fixes the following CVEs: - CVE-2014-2329 - CVE-2014-2330 - CVE-2014-2331 - CVE-2014-2332 References: [ 1 ] Bug #1080303 - CVE-2014-2329 CVE-2014-2330 CVE-2014-2331 CVE-2014-2332 check-mk: multiple flaws fixed in versions 1.2.2p3 and 1.2.3i5 https://bugzilla.redhat.com/show_bug.cgi?id=1080303 cmockery2-1.3.7-1.el5 (FEDORA-EPEL-2014-0950) Lightweight C unit testing framework Update Information: Fixed memory check functions References: [ 1 ] Bug #1079647 - Cmockery2 does not pass tests in el5-ppc arch https://bugzilla.redhat.com/show_bug.cgi?id=1079647 libxc-2.1.0-2.el5 (FEDORA-EPEL-2014-0917) Library of exchange and correlation functionals to be used in DFT codes Update Information: Update to 2.1.0, bringing much more functionals. Enable single precision routines as well. ChangeLog: * Mon Mar 24 2014 Susi Lehtola - 2.1.0-2 - Re-enable builds on ppc and ppc64 on EPEL. * Fri Mar 21 2014 Susi Lehtola - 2.1.0-1 - Enable single precision routines as well. - Update to 2.1.0. python-libcloud-0.14.1-1.el5 (FEDORA-EPEL-2014-0954) A Python library to address multiple cloud provider APIs Update Information: Initial build of 0.14.1 for EL5 tcpreplay-4.0.4-1.el5 (FEDORA-EPEL-2014-0956) Replay captured network traffic Update Information: Fixes include: - Number of packets inaccurate when using --netmap method (#76) - Unexpected packet counts with --loop and --cachefile enabled (#75) - Improved error messages when interface is a file (#74) - Missing interfaces with --listnics option (#67) - Compile issue with netmap v10 and debugging (#66) - Bad values with --stats and -t options (#65) ChangeLog: * Tue Mar 25 2014 Bojan Smojver - 4.0.4-1 - bump up to 4.0.4
Re: qemu / VNC / vino
On Tue, 2014-03-25 at 17:51 -0400, Cole Robinson wrote: > There was a bug about that in the past, but we rejected changing the default > range. Libvirt and xen and qemu have all used the assumption of starting at > port 5900 for too long, we didn't want to deal with any potential fallout for > something that affects a small number of users, and that nowadays has a manual > workaround. > > vino could always be extended to try a little harder/smarter to find a free > port, which libvirt has done for years. Yeah I see what you're saying. Just a couple points in favor of changing qemu/libvirt... #1) If someone is using a normal desktop and vino finds a collision it has no way of informing the user. It could find a free port but telling someone to connect to my host, I have no way of knowing what port it is using without going into a terminal and looking for listening ports. The libvirt/qemu would continue to work by default if the default was set to something else. In qemu.conf and I presume the other backends libvirt/virt-manager supported. #2) In the case where an admin/user wants to have access to the VM host from a *remote* host. They have to change some configuration since qemu-system-x86_64 is only listening on 127.0.0.1 not on any external interface. At this point the admin is not likely configuring this on a desktop and if they are can specify any port they'd like and should realize that if they are using vino (or something similar), they have to use different ports. (Which I would know too - I just didn't know why qemu was listening on that port when I didn't have any gui up accessing that host...). #3) Based on bugs I've seen on gnome I can't see them changing it much. (I just posted a bug to vinagre/ a vnc/rdp client) which doesn't notify the user of a password prompt *or* to accept a certificate on SSL connections. The devs basically said don't use vinagre, use the command line program that is being used by vinagre. Kinda odd... So I understand if nothing gets changed but it would be nice if it was reconsidered. I may not understand all the implications but if the default local port was configured to not collide. I dunno, I'd enjoy it. :) Granted I'm enjoying it at the moment anyway. Thanks, -- Nathanael -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, Mar 25, 2014 at 5:28 PM, Matthew Miller wrote: > On Tue, Mar 25, 2014 at 05:09:09PM -0400, Josh Boyer wrote: >> >> I said it's "madness" and "totally wacky" to NOT HAVE THE OPTION of >> >> installing your desktop directly, before first installing GNOME. That is >> >> also what I said "almost all users are NOT going to put up with". >> > I haven't heard anyone suggesting that, so it seems like a lot of madness >> > and wackiness about nothing. >> In the context of Workstation, KDE (or any other DE) inclusion has >> been discussed as being available through software-installer. If that >> is the only option, then it would mean GNOME must be installed and >> booted into to run software-installer to install KDE. I'm personally >> unsure if the live image installation can handle multiple DEs. Even >> if that isn't the only install option, most of the GNOME stack is >> still required to be installed. > > But this is *only* in the Workstation context... it would have no effect on > the KDE spin, which would still be available... right? As far as I know, yes. I see no reason for any of the existing spins to no longer exist outside of those working on them losing interest. josh -- 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: qemu / VNC / vino
On 03/25/2014 05:43 PM, Nathanael D. Noblet wrote:
> On Tue, 2014-03-25 at 18:24 +, Daniel P. Berrange wrote:
>
>> In /etc/libvirt/qemu.conf you can set remote_display_port_{min,max}
>> to control the port range used
>
> So that is awesome thank you.
>
> Given that by default virt-manager/libvirt/qemu listens to
> 127.0.0.0:PORT as opposed to 0.0.0.0:PORT. Should this be filed as a
> bug? As in could the default port qemu started on be 6900 instead of
> 5900 so that this doesn't happen? I realize that 5900 is the standard
> vnc port... I'm just wondering if there is a use case where changing
> that config breaks anything?
>
There was a bug about that in the past, but we rejected changing the default
range. Libvirt and xen and qemu have all used the assumption of starting at
port 5900 for too long, we didn't want to deal with any potential fallout for
something that affects a small number of users, and that nowadays has a manual
workaround.
vino could always be extended to try a little harder/smarter to find a free
port, which libvirt has done for years.
- Cole
--
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: qemu / VNC / vino
On Tue, 2014-03-25 at 18:24 +, Daniel P. Berrange wrote:
> In /etc/libvirt/qemu.conf you can set remote_display_port_{min,max}
> to control the port range used
So that is awesome thank you.
Given that by default virt-manager/libvirt/qemu listens to
127.0.0.0:PORT as opposed to 0.0.0.0:PORT. Should this be filed as a
bug? As in could the default port qemu started on be 6900 instead of
5900 so that this doesn't happen? I realize that 5900 is the standard
vnc port... I'm just wondering if there is a use case where changing
that config breaks anything?
--
Nathanael
--
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, Mar 25, 2014 at 05:09:09PM -0400, Josh Boyer wrote: > >> I said it's "madness" and "totally wacky" to NOT HAVE THE OPTION of > >> installing your desktop directly, before first installing GNOME. That is > >> also what I said "almost all users are NOT going to put up with". > > I haven't heard anyone suggesting that, so it seems like a lot of madness > > and wackiness about nothing. > In the context of Workstation, KDE (or any other DE) inclusion has > been discussed as being available through software-installer. If that > is the only option, then it would mean GNOME must be installed and > booted into to run software-installer to install KDE. I'm personally > unsure if the live image installation can handle multiple DEs. Even > if that isn't the only install option, most of the GNOME stack is > still required to be installed. But this is *only* in the Workstation context... it would have no effect on the KDE spin, which would still be available... right? -- Matthew Miller-- Fedora Project-- -- 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: EPEL Clang package doesn't work on Amazon Linux
Here is a gist containing the output of attempting to compile the program
after installing the clang package on each platform I mentioned:
https://gist.github.com/TylerBrock/9771402
-Tyler
On Tue, Mar 25, 2014 at 4:54 PM, Tyler Brock wrote:
> To my knowledge it was originally based on CentOS but it has since
> diverged.
>
> It may be useful to mention that this same issue affects multiple Red Hat
> derivatives (including RHEL 6.4 itself) and not just Amazon Linux. I
> attempted the same process on Red Hat 6.4, Fedora 20, and Amazon Linux
> 2013.09, and it fails on all three of these distributions with the same
> errors. In fact, the only distribution on which I have been able to get it
> to work is CentOS 6.4.
>
> -Tyler
>
>
> On Tue, Mar 25, 2014 at 1:46 AM, Dave Johansen wrote:
>
>> On Mon, Mar 24, 2014 at 6:38 PM, Tyler Brock wrote:
>>
>>> Hey Everyone,
>>>
>>> I've been trying to use clang package on Amazon linux via EPEL and have
>>> installed version 3.4-9.el6 yet am unable to compile even the simplest of
>>> programs:
>>> #include
>>>
>>> int main(){
>>> std::cout << "Hello World" << std::endl;
>>> }
>>>
>>> Saving the above into a file named test.cpp and compiling with "clang++
>>> test.cpp" produces the following error:
>>>
>>> test.cpp:1:10: fatal error: 'iostream' file not found
>>> #include
>>> ^
>>> 1 error generated.
>>>
>>> When attempting the same with gcc (g++) it works as expected so It seems
>>> like the clang compiler cannot find the required C++ headers and library
>>> files.
>>>
>>> I have contacted Amazon AWS support and they verified that the issue is
>>> reproducible by them running the latest version of Amazon Linux with
>>> updated packages from EPEL.
>>>
>>> I've tried installing devel headers for clang and multiple versions of
>>> libstd++ which seem to be placed in /usr/include/c++/ but
>>> which, when used by gcc, do not require the path to them be specified at
>>> all. It just works.
>>>
>>> I have a feeling the clang package is not built to work properly with
>>> Amazon Linux as C++ headers and library files (for either for libc++ or
>>> libstdc++) such as iostream should be found by default. Any help in
>>> resolving the matter would be greatly appreciated.
>>>
>>> It may also be worth noting that on CentOS the clang package seems to
>>> work fine.
>>>
>>
>> I'm the maintainer of clang in the EPEL, but honestly I know nothing
>> about Amazon Linux. Is it an "EL variant" or claim any sort of
>> compatibility with EL? A known issue even on EL/CentOS with clang is that
>> much of the C++11/14 support won't work because of the old version of the
>> standard library that is available on EL. It sounds like this isn't your
>> issue, but if C++11/14 support is desired, then the devtoolset (
>> http://rhn.redhat.com/errata/RHEA-2013-1226.html ) is the best route to
>> follow.
>>
>> ___
>> epel-devel mailing list
>> epel-de...@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>>
>>
>
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, Mar 25, 2014 at 5:02 PM, Matthew Miller wrote: > On Tue, Mar 25, 2014 at 09:41:19PM +0100, Kevin Kofler wrote: >> I said it's "madness" and "totally wacky" to NOT HAVE THE OPTION of >> installing your desktop directly, before first installing GNOME. That is >> also what I said "almost all users are NOT going to put up with". > > I haven't heard anyone suggesting that, so it seems like a lot of madness > and wackiness about nothing. In the context of Workstation, KDE (or any other DE) inclusion has been discussed as being available through software-installer. If that is the only option, then it would mean GNOME must be installed and booted into to run software-installer to install KDE. I'm personally unsure if the live image installation can handle multiple DEs. Even if that isn't the only install option, most of the GNOME stack is still required to be installed. josh -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, Mar 25, 2014 at 09:41:19PM +0100, Kevin Kofler wrote: > I said it's "madness" and "totally wacky" to NOT HAVE THE OPTION of > installing your desktop directly, before first installing GNOME. That is > also what I said "almost all users are NOT going to put up with". I haven't heard anyone suggesting that, so it seems like a lot of madness and wackiness about nothing. -- Matthew Miller-- Fedora Project-- -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
Adam Williamson wrote: > *My* point is that you should make your rhetoric match your point. Two > or three of those quotations were direct rips from your previous emails > on the topic. If you don't actually mean those things, then I suggest > not writing them. I said it's "madness" and "totally wacky" to NOT HAVE THE OPTION of installing your desktop directly, before first installing GNOME. That is also what I said "almost all users are NOT going to put up with". If you took this to mean that nobody would ever want to install some other desktop in addition to GNOME on a GNOME install, you clearly misunderstood me. I am sorry for that. My point is that most users WILL have a preferred desktop and will want that desktop to be the one their distribution gets installed with. They may or may not want to try out other desktop environments at a later point. (To be honest, I think most people won't, but for those who will, OF COURSE it should be possible!) Kevin Kofler -- 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-03-25)
Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-03-25/ Fedora is big project, and it’s hard to follow it all. This new feature will highlight interesting happenings in five different areas every week. It won’t be comprehensive news coverage — just quick summaries with links to each. So, here we go for March 25th, 2014: Snapshot support in virt-manager Virt-manager is a GUI for managing virtual machines on your local system or remotely. It’s handy for intermediate/advanced users or for sysadmins who are not in the mood for the command line. With version 1.0, now in Rawhide and updates for F20, virt-manager now supports snapshots. Developer Cole Robinson has a blog post with details and a walkthrough of the new GUI. (A similar feature may come to Gnome Boxes in the future via Summer of Code work.) * http://virt-manager.org/ * http://blog.wikichoon.com/2014/03/snapshot-support-in-virt-manager.html * http://zee-nix.blogspot.com/2014/03/boxes-312.html From upstream code to packages in a repo, automatically every day - Fedora’s new Copr system lets any Fedora contributor easily maintain and publish a repository of whatever software you want, as long as it falls within our legal guidelines. (*cough* Fedora PPAs *cough*) But what if that’s not automatic enough? What if you want to track a fast-moving upstream without having to update source RPMs constantly? Prolific Fedora hacker Pierre-Yves Chibon (“pingou”) presents dgroc, for “Daily Git Rebuild On Copr”. It basically does just what it says — takes care of the updating and building in Copr, so you can focus on the software rather than the packaging. * http://copr.fedoraproject.org/ * http://blog.pingoured.fr/index.php?post/2014/03/20/Introducing-dgroc Fedora Plasma? A proposal from the KDE SIG -- The Fedora KDE SIG has been working on a proposal for a Fedora Product based on KDE Plasma Desktop, with a primary focus on education and scientific users. Contributor (and board member) Rex Dieter sent the a request for feedback to the Fedora Advisory Board today; if accepted, this will join already-planned Cloud, Server, and Workstation products. The discussion around this will be interesting to follow. Most people in the project agree that products in the Fedora.next framework should be held to a high standard, and that we shouldn’t have endless proliferation, but how, where, and when we draw that line is not settled. * http://fedoraproject.org/wiki/SIGs/KDE * https://lists.fedoraproject.org/pipermail/advisory-board/2014-March/012449.html FPL Robyn Bergeron on Fedora, Red Hat, and the Future - Fedora Project Leader Robyn Bergeron has a new blog post, _Fedora, Red Hat, and investing in the future_, with thoughts on Red Hat’s investment in our project, Fedora’s value to Red Hat, and the Fedora.next plans. * http://robyn.io/2014/03/25/fedora-red-hat-and-investing-in-the-future/ Fedora Atomic - Since this week has been a little slow, I’m going to cheat a bit and pull something big from the backlog. Fedora developer Colin Walters has launched a new project called Fedora Atomic. This system constructs git-like trees from existing official Fedora RPMs, and moves operating-system deployment from managing packages to managing these trees, with (as the name suggests) fully-atomic updates and rollbacks. It’s still in early development, but moving quickly, and the Fedora Cloud SIG is considering using it for some special-purpose images (including a minimal Docker host). Sound interesting — or scary? Learn more at the links below * http://rpm-ostree.cloud.fedoraproject.org/ * http://rpm-ostree.cloud.fedoraproject.org/#/background * Thanks to Stephen Gallagher for content suggestions this week, and Joe Brockmeier for proofreading. If you have tips for the next week, please send ‘em to me. -- Matthew Miller-- Fedora Project-- -- 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: NetworkManager "forget" user network configurations: bug or feature?
Adam Williamson wrote: > Um. Are you sure this is what is happening? Are you sure these aren't > set as systemwide connections? NetworkManager 0.9 stores all connections systemwide, with permissions optionally restricting them to specific users. Kevin Kofler -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Tue, 2014-03-25 at 21:07 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > I think this is rather overstating the case. I certainly don't think > > (and I already wrote) that it's enough to make everyone happy, but I > > think it actually is what some people want. Quite a lot of people > > install Ubuntu, for instance, and then add on GNOME or KDE or something > > as a secondary environment to play around with: they want to have the > > 'standard product' installed, and another desktop available as a kind of > > alternative on top of that, or they just want to make sure they have all > > the 'standard' bits installed under/alongside their chosen desktop in > > case anything else is expecting them (the "platform" approach). > > > > Saying that "nobody" wants this, it's "madness", "totally wacky", > > "almost all users are NOT going to put up with this" is going rather too > > far. I think it's entirely worth the Desktop product making this > > possible and I suspect quite a lot of people will use it, but I don't > > think it's sufficient grounds for downgrading the spins too far in > > importance or dropping them. > > You're misunderstanding me here. My point is *My* point is that you should make your rhetoric match your point. Two or three of those quotations were direct rips from your previous emails on the topic. If you don't actually mean those things, then I suggest not writing them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
Adam Williamson wrote: > I think this is rather overstating the case. I certainly don't think > (and I already wrote) that it's enough to make everyone happy, but I > think it actually is what some people want. Quite a lot of people > install Ubuntu, for instance, and then add on GNOME or KDE or something > as a secondary environment to play around with: they want to have the > 'standard product' installed, and another desktop available as a kind of > alternative on top of that, or they just want to make sure they have all > the 'standard' bits installed under/alongside their chosen desktop in > case anything else is expecting them (the "platform" approach). > > Saying that "nobody" wants this, it's "madness", "totally wacky", > "almost all users are NOT going to put up with this" is going rather too > far. I think it's entirely worth the Desktop product making this > possible and I suspect quite a lot of people will use it, but I don't > think it's sufficient grounds for downgrading the spins too far in > importance or dropping them. You're misunderstanding me here. My point is NOT that it should not be POSSIBLE to add other desktops to an installed system. OF COURSE that should be possible! I have always opposed any attempts at making the different desktop environments mutually exclusive (see also NM 0.9 and BlueZ 5, where in both cases I got the plans to ship both the old and new version in such a way that the desktop environments would have conflicted with each other at RPM level blocked). My point is that it must ALSO be possible to install the preferred desktop directly, without installing GNOME first. Kevin Kofler -- 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
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
Re: NetworkManager "forget" user network configurations: bug or feature?
2014-03-25 16:20 GMT-03:00 Adam Williamson : > On Tue, 2014-03-25 at 16:19 -0300, Sergio Belkin wrote: > > Hi Fedora folks, > > > > Since NetworkManager I suffer the same issue, release after release, ok, > > it's not a Fedora issue > > > > If I preserve the home partition and perform a newly installation, eg > > f19->f20 NetworkManager configurations per user are lost. I think that > > NM should respect the user settings and not "happily" send them to trash. > > > > But what do you think? What is the rationale of saving user > > configurations in the /etc directory? > > > > What do you think? > > Um. Are you sure this is what is happening? Are you sure these aren't > set as systemwide connections? > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Adam, I've found that by default when I create a user, the checkbox in NetworkManager that says "All users may connect to this network" is checked! If I uncheck anyway the network configuration files are in /etc/sysconfig/network-scripts/ Really I don't understand this behavior (using mate-desktop on F20) -- -- Sergio Belkin http://www.sergiobelkin.com LPIC-2 Certified - http://www.lpi.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: NetworkManager "forget" user network configurations: bug or feature?
On Tue, 2014-03-25 at 16:19 -0300, Sergio Belkin wrote: > Hi Fedora folks, > > Since NetworkManager I suffer the same issue, release after release, ok, > it's not a Fedora issue > > If I preserve the home partition and perform a newly installation, eg > f19->f20 NetworkManager configurations per user are lost. I think that > NM should respect the user settings and not "happily" send them to trash. > > But what do you think? What is the rationale of saving user > configurations in the /etc directory? > > What do you think? Um. Are you sure this is what is happening? Are you sure these aren't set as systemwide connections? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
NetworkManager "forget" user network configurations: bug or feature?
Hi Fedora folks, Since NetworkManager I suffer the same issue, release after release, ok, it's not a Fedora issue If I preserve the home partition and perform a newly installation, eg f19->f20 NetworkManager configurations per user are lost. I think that NM should respect the user settings and not "happily" send them to trash. But what do you think? What is the rationale of saving user configurations in the /etc directory? What do you think? -- Sergio Belkin Certificado Linux LPIC-2 -- 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
* 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
Re: Let's close the remaining merge reviews
On 03/25/2014 08:42 AM, Cole Robinson wrote: On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. What does that solve? How does that benefit anybody? Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole I concur. Let's close those bugs. Marcela -- 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: qemu / VNC / vino
On Tue, Mar 25, 2014 at 12:06:31PM -0600, Nathanael D. Noblet wrote:
> Hello,
>
> So I've found a 'bug'. I have a group of developers who use
> vagrant/libvirt to develop against. We use VNC since we are a
> distributed team to connect to each other's desktops/workstations for
> when we're at the 'huh this makes no sense'.
>
> If libvirt/qemu-system-x86_64 starts before vino-server (which is
> common since we don't leave the vnc access on all the time). Then vino
> only listens on ipv6 instead of ipv4 and ipv6. At that point no one can
> connect to the workstation over vnc since we are all ipv4 connected.
>
> I'm not sure where the bug is and it isn't really a big bug as much as
> I need to be able to tell either vino or qemu-system-x what ports to
> use.
>
> Thoughts? What should I look at/report?
In /etc/libvirt/qemu.conf you can set remote_display_port_{min,max}
to control the port range used
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
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: qemu / VNC / vino
On 03/25/2014 02:06 PM, Nathanael D. Noblet wrote: > Hello, > > So I've found a 'bug'. I have a group of developers who use > vagrant/libvirt to develop against. We use VNC since we are a > distributed team to connect to each other's desktops/workstations for > when we're at the 'huh this makes no sense'. > > If libvirt/qemu-system-x86_64 starts before vino-server (which is > common since we don't leave the vnc access on all the time). Then vino > only listens on ipv6 instead of ipv4 and ipv6. At that point no one can > connect to the workstation over vnc since we are all ipv4 connected. > > I'm not sure where the bug is and it isn't really a big bug as much as > I need to be able to tell either vino or qemu-system-x what ports to > use. > > Thoughts? What should I look at/report? > On Fedora 20, /etc/libvirt/qemu.conf allows you to set a port range that libvirt will allocate for VMs. You can use that to avoid the vino collision. - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
qemu / VNC / vino
Hello, So I've found a 'bug'. I have a group of developers who use vagrant/libvirt to develop against. We use VNC since we are a distributed team to connect to each other's desktops/workstations for when we're at the 'huh this makes no sense'. If libvirt/qemu-system-x86_64 starts before vino-server (which is common since we don't leave the vnc access on all the time). Then vino only listens on ipv6 instead of ipv4 and ipv6. At that point no one can connect to the workstation over vnc since we are all ipv4 connected. I'm not sure where the bug is and it isn't really a big bug as much as I need to be able to tell either vino or qemu-system-x what ports to use. Thoughts? What should I look at/report? -- Nathanael -- 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
* Mikolaj Izdebski [2014-03-24 11:41]: > On 03/22/2014 06:15 AM, Miloslav Trmač wrote: > > Given the known large number of failures (OptionalJavadocs says "80% build > > failure rate" without saying that all are JavaDoc-related), we really > > should do a mass rebuild to identify which packages fail to build *and* to > > file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and > > then scrambling to fix dozens/hundreds of build failures in to avoid > > slipping the schedule. We don't necessarily need an official one, perhaps > > only in a never-to-be-merged side tag (or even scratch builds?) > > Agreed. Should I update the proposal to clarify that a mass rebuild is required, then? 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
[CANCELED] Agenda for Env-and-Stacks WG meeting (2014-03-25)
On Mon, 2014-03-24 at 15:20 -0400, Marcela Mašláňová wrote: > WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon) > Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode. Today's meeting was canceled since there were only hhorak, drieden and me present. > == Topic == > * work more on Open Questions: > https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 > * obs-signd is probably the easier to deploy -> add ad proposed solution? > * conflicts within Playground repo -> discussed a little on mailing > list, but no final proposal > * 1 Big repo vs multiple small ones -> discussed on mailing list, no > consensus reached Please, share your opinions/thoughts on these topics in the appropriate mailing-list threads. The Conflicts policy and the "1 big repo vs. multiple small ones" is an important decision that will affect further planning of the Playground repository and hence it is important to voice your views. Regards, Tadej -- 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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On 03/25/2014 01:24 PM, Matthew Miller wrote: On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote: For the record Fedora is not a bleeding edge distro anymore or first in anything maybe some people should consider the difference between "leading" and "bleeding" smart: leading if things are ready dumb: bleeding for any price I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully: First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution. Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here. Leading and bleeding go hand in hand being "first" In this particular case we already are years behind Arch and soon to be behind OpenSuse and others aswell. So if this is the case when people want to modernize and cleanup the distribution then perhaps it's time for the board revisit and redefine the foundation for firs so contributors can avoid Fedora and move to more acceptable distribution of their contributions like Arch if they want to be part of distribution that is leading and is "first". JBG -- 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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
Am 25.03.2014 15:54, schrieb Jóhann B. Guðmundsson: > On 03/25/2014 02:41 PM, Reindl Harald wrote: >> stop your destructive FUD, without users developers and contributors are >> *meaningless* >> and with throwing alpha-state software to the users and make them bleed all >> the >> time you will end in no users at all >> >> if you don't understand that, don't care for users and don't like Fedora >> as you statet often enough because you hate Redhat, well, you know what >> you have to do > > I think you should keep your mouth shut accusing me of destructive FUD i can seek in the archives how often you attack Redhat and so on https://lists.fedoraproject.org/pipermail/devel/2013-February/177915.html > I'm not the one that is calling developers idiots [1] you state [1] two times and list it once with a broken link here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1072368 nobody right in his mind states *18* loglines for every single cronjob are fine - multiply that with 85 cronjobs on our main server, some of them every minute for good reasons then you have 2 additional lines in /var/log/cron and a few in /var/log/secure - frankly call that a self-DOS in case of a central logserver for 30 machines with a database backend to feed own filter and search applications ___ well deserved in case "flood logs is fine" while that is a naked Rawhide VM and a production server with cronjobs would produce many ten if not hundret thousands of log messages leading to no longer face serious ones and without useful prefixes to filter them outin rsyslog.conf > then complain about them adding you to their killfile list [2] the problem with Lennart is that he can't stand *any* critism and is pissed off or ignoring anything people tell him bugreports are ignored over months and then after list them again all commented within minutes - fine no reply - interesting http://www.spinics.net/lists/fedora-devel/msg196606.html > The fact is all the distribution are deprecating tcpwrappers and denyhosts > along with it including Debian [1] due to it being maintained and a > security risk don't mix two things where is the security relevant bug of tcpwrappers? "it did not get new versions" is not a problem only people like you don't understand that things which ain't broken don't need to be fixed and get new bugs due that > But hey let's keep Fedora out of sync with other distribution and > hold progress back to please your usecase *what progress* *what are you missing* > 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7327122 is broken and don't exist at debian nor at Redhat > 2. https://lists.fedoraproject.org/pipermail/devel/2014-March/197093.html > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732712 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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
Everyone in this thread: Please re-read our code of conduct (in the footer of every single message). Stop attacking people. Please stick to constructive comments about ideas instead. kevin signature.asc 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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On 03/25/2014 02:41 PM, Reindl Harald wrote: stop your destructive FUD, without users developers and contributors are*meaningless* and with throwing alpha-state software to the users and make them bleed all the time you will end in no users at all if you don't understand that, don't care for users and don't like Fedora as you statet often enough because you hate Redhat, well, you know what you have to do I think you should keep your mouth shut accusing me of destructive FUD I'm not the one that is calling developers idiots [1] then complain about them adding you to their killfile list [2] The fact is all the distribution are deprecating tcpwrappers and denyhosts along with it including Debian [1] due to it being maintained and a security risk But hey let's keep Fedora out of sync with other distribution and hold progress back to please your usecase JBG 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7327122 2. https://lists.fedoraproject.org/pipermail/devel/2014-March/197093.html 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732712 -- 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: EPEL Thunderbird and/or claws-mail in epel 7 beta
On Mon, 24 Mar 2014 16:59:34 +0100 Jan Horak wrote: > On 03/06/2014 09:24 PM, Orion Poplawski wrote: > > On 03/06/2014 10:24 AM, Clyde E. Kunkel wrote: > >> Hi, > >> > >> Will the subject packages be included in epel 7? I don't see them > >> listed on the web pages at > >> http://dl.fedoraproject.org/pub/epel/beta/7/SRPMS/repoview/ > >> > >> tia > > > > Someone will have to step up and maintain them there. (I hope it > > doesn't end up being me). Fairly surprised that TB isn't in RHEL, > > I guess they're just backing evolution. > > > > Jan - any interest? > > > Okay, I'll do it. I just have to get familiar how EPEL works. I think for TB will work the following - request an EPEL-7 branch - git checkout epel7 - git merge master - fedpkg build Dan ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
Am 25.03.2014 15:22, schrieb Jóhann B. Guðmundsson: > On 03/25/2014 01:24 PM, Matthew Miller wrote: >> On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote: For the record Fedora is not a bleeding edge distro anymore or first in anything >>> maybe some people should consider the difference between "leading" and >>> "bleeding" >>> smart: leading if things are ready >>> dumb: bleeding for any price >> I agree with Harald here. I think some people have always wanted it to be, >> but Fedora never really has been chartered to be "bleeding". To quote the >> "first" foundation more fully: >> >>First represents our commitment to innovation. We are not content to let >>others do all the heavy lifting on our behalf; we provide the latest in >>stable and robust, useful, and powerful free software in our Fedora >>distribution. >> >> Note "latest in stable and robust", not "latest bleeding edge". There is >> supposed to be a balance here. > > Leading and bleeding go hand in hand being "first" no, the is a sharp line to draw > In this particular case we already are years behind Arch and soon to be > behind > OpenSuse and others aswell as long as you do not make any points this is FUD > So if this is the case when people want to modernize and cleanup the > distribution then > perhaps it's time for the board revisit and redefine the foundation for firs > so > contributors can avoid Fedora and move to more acceptable distribution of > their > contributions like Arch if they want to be part of distribution that is > leading and is "first" stop your destructive FUD, without users developers and contributors are *meaningless* and with throwing alpha-state software to the users and make them bleed all the time you will end in no users at all if you don't understand that, don't care for users and don't like Fedora as you statet often enough because you hate Redhat, well, you know what you have to do 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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On Tue, 2014-03-25 at 09:24 -0400, Matthew Miller wrote: > I agree with Harald here. I think some people have always wanted it to be, > but Fedora never really has been chartered to be "bleeding". To quote the > "first" foundation more fully: > > First represents our commitment to innovation. We are not content to let > others do all the heavy lifting on our behalf; we provide the latest in > stable and robust, useful, and powerful free software in our Fedora > distribution. > > Note "latest in stable and robust", not "latest bleeding edge". There is > supposed to be a balance here. I think Fedora is hitting that balance relatively well when it releases new distros. There are always packages with serious bugs, and there are always packagers that choose to ship development snapshots, but for the most part, new releases are not the problem. I do not consider a new Fedora release to be any less stable than comparable distributions. On the contrary, I think the QA team does a very good job of finding and resolving blocker bugs, a process no other comparable distro has. The problem is that stable releases don't stay stable. The updates pipe turns on prior to day one, and maintainers can release whatever they want onto the distribution. We see unjustified major version updates because someone requests a backport of something shiny and new, and with them come major new bugs, or even major dependency issues. The existing update policy [1] does a good job of describing what is appropriate for a stable release update. It's notably much more lenient than any other major distribution. You cannot get even a minor (bugfix) version update into Ubuntu/Debian/openSUSE/(Mageia?) just because: you usually need to pick a change that you really want, and backport just that change. In contrast, minor version updates are fine for Fedora: our update policy only prevents updates to major releases with new features, and even then, qualifies this with language like "if at all possible." The existing update policy does a bad job of describing when an appropriate update is suitable for release. There's really no good reason a noncritical update can go straight to stable after less than a week in updates-testing, for example. The existing update policy is also not properly enforced. (I could give examples, but I don't much see the point in picking on individual packages here: suffice to say that I don't think FESCO is asked to approve all updates that require approval.) Lastly, there aren't enough automated checks on the updates: an update that accidentally adds a dependency on a new graphical program should be caught automatically, for example. Ideally, there would be someone other than the package maintainer who has to press the Release Update button: not to be an update Nazi, but to make sure the basic rules are followed, and to catch updates that aren't justified by the changelog. \$0.02 [1] https://fedoraproject.org/wiki/Updates_Policy 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: proactively deprecating things that should be -- base design wg [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On Mon, Mar 24, 2014 at 3:07 PM, Matthew Miller wrote: > On Mon, Mar 24, 2014 at 07:18:58PM +0100, Lennart Poettering wrote: >> It's a pity though that nobody in Fedora is actively working on getting >> rid of legacy cruft. I really wished we had some people who oversee >> deprecating things more proactively, figure out how to deprecate things, >> write stub code to provide smooth transitions, write release notes and >> so on. Being at the bleeding edge of things also means deciding that >> some things really should go, from time to time... > > I absolutely agree. This should be an important fuction of the Base Design > working group. Before that, we also have a "Minimal Core" SIG with some > interest but not much activity (that last may somewhat be my fault, since I > kicked it off but my attention wandered). You should really make a point of telling the Base WG this directly. Nobody in that WG even has something like this on their radar. At the moment it's just reviewing Tech Specs looking for Base work items (none found), discussing the concept of Base, and doing some dependency trimming. > >>Besides deprecating >> old cruft like libwrap, this would also mean removing all the old crap >> from comps "standard" that we still install by default (894110)... > > https://bugzilla.redhat.com/show_bug.cgi?id=894110 > > There wasn't previously a great framework for discussing this kind of thing. > I hope that we do have that now. And just as you don't have to be a voting > WG member to contribute to a product SIG, it would be helpful for anyone > interested in this to provide constructive feedback to the Base Design > group. It would if the Base Design group thought that kind of thing was something FESCo wanted them to tackle. Please help the WG more clearly define the things they're supposed to be doing. IMO, the Base WG seems to have been created because someone thought it would be a good idea to have one without really elaborating on what that meant. As a byproduct, the WG is left to figure it out on their own and hasn't really firmly grasped what it's for. It is the WG equivalent of staring at the stars and wondering "why do I exist?". josh -- 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: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: > > I like the idea of actually revisiting the list and deciding what to do, > > although pulling them out of the repository seems unnecessarily drastic. > This always winds up being the suggestion. Nobody actually does > anything about it. I'd only be supportive of this on two conditions: Well, I was looking through the list there are some important packages in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. :) Many of these really deserve the attention. Others maybe not so much. tix? Pyrex? (Also I notice festival is in there -- that's partly package and based on long-ago work I did before the merge and I *know* it needs an update... *sigh*) > 1) Actual bugs impacting actual people as a result of an improper spec > file were present > 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, > ?) agreed to conduct audits across all packages for guideline > adherence at regular intervals. > > I'd be willing to not require item 1 if item 2 were actually done. It > never has been, and if it had it would already suffice for the purpose > the merge review tickets would serve today. I don't think that we need to do it across *all* packages. I'd like to see it done initially for all packages that end up part of the base design. That's a more manageable chunk and will focus the effort where it will have the most benefit. > We have a lot of guidelines. Enough that it can be rather daunting to > a new packager to even start packaging something. What we have always > lacked is enforcement and accountability on those guidelines _after_ > something is in the distro. Fix that problem and everything else > relating to it will be solved. +1 -- Matthew Miller-- Fedora Project-- -- 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: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 2:43 PM, Matthew Miller wrote: > On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: >> > I like the idea of actually revisiting the list and deciding what to do, >> > although pulling them out of the repository seems unnecessarily drastic. >> This always winds up being the suggestion. Nobody actually does >> anything about it. I'd only be supportive of this on two conditions: > > Well, I was looking through the list there are some important packages > in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. > :) Many of these really deserve the attention. > > Others maybe not so much. tix? Pyrex? > > (Also I notice festival is in there -- that's partly package and based on > long-ago work I did before the merge and I *know* it needs an update... > *sigh*) > >> 1) Actual bugs impacting actual people as a result of an improper spec >> file were present >> 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, >> ?) agreed to conduct audits across all packages for guideline >> adherence at regular intervals. >> >> I'd be willing to not require item 1 if item 2 were actually done. It >> never has been, and if it had it would already suffice for the purpose >> the merge review tickets would serve today. > > I don't think that we need to do it across *all* packages. I'd like to see > it done initially for all packages that end up part of the base design. > That's a more manageable chunk and will focus the effort where it will have > the most benefit. The benefit would be? We shouldn't waste so much time and resources for a questionable gain. If there are issues with some packages file bugs (with patches) or better just fix it and be done with it. -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Mon, Mar 24, 2014 at 07:07:43PM -0500, Michael Catanzaro wrote: > > Who the hell wants to install Gnome to install MATE or KDE or XFCE? > Nobody, it's madness. I don't think anyone wants to _have_ to, but I think it would be great if we made it _easy to_ for people who _do_ have Gnome installed to easily explore different desktop stacks just like they can applications. -- Matthew Miller-- Fedora Project-- -- 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: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 9:43 AM, Matthew Miller wrote: > On Tue, Mar 25, 2014 at 09:29:12AM -0400, Josh Boyer wrote: >> > I like the idea of actually revisiting the list and deciding what to do, >> > although pulling them out of the repository seems unnecessarily drastic. >> This always winds up being the suggestion. Nobody actually does >> anything about it. I'd only be supportive of this on two conditions: > > Well, I was looking through the list there are some important packages > in here, including gcc, nss, samba, httpd, and a lot more. And tcp_wrappers. > :) Many of these really deserve the attention. I find that difficult to believe given that they haven't had said attention in 7 years and stuff is still working. >> 1) Actual bugs impacting actual people as a result of an improper spec >> file were present >> 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, >> ?) agreed to conduct audits across all packages for guideline >> adherence at regular intervals. >> >> I'd be willing to not require item 1 if item 2 were actually done. It >> never has been, and if it had it would already suffice for the purpose >> the merge review tickets would serve today. > > I don't think that we need to do it across *all* packages. I'd like to see > it done initially for all packages that end up part of the base design. > That's a more manageable chunk and will focus the effort where it will have > the most benefit. Under the premise that some is better than none, OK. I have doubts that regularly scheduled _recurring_ audits will actually be done at all for any set of packages though. The argument is always lack of people doing it. The solution is automation. The argument against _that_ is lack of people doing it and complexity to do it properly in an automated fashion. Vicious cycles are vicious. josh -- 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: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 6:59 PM, Josh Boyer wrote: > > On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller > wrote: > > On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: > >> Alternative idea -- maybe identify all packages which are not ciritcal and > >> have an open merge review. Take those packages out of the repository. > >> Then revisit the list and formulate a plan on what to do with thoes (even > >> if > >> the plan is then, these were critical enough to leave in so we'll give them > >> a pass on going through a formal review). > > > > I like the idea of actually revisiting the list and deciding what to do, > > although pulling them out of the repository seems unnecessarily drastic. > > This always winds up being the suggestion. Nobody actually does > anything about it. This is also what I have seen. We have seen many discussions on merge-review closure since last few years but no one step forward to work on it. Why to discuss such things if we all contributors can review packages and help maintainers to have their packages as per current packaging guidelines? The only problem I have seen while working on such reviews is that some maintainers find them low priority and did not respond. Sometime ago I decided to work on this and also wanted to clean spec myself and review the same package myself but our policies does not allow this. So I occasionally visit merge-reviews and try to finish them with the help of current package owner. Regards, Parag. -- 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: Let's close the remaining merge reviews
On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller wrote: > On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: >> Alternative idea -- maybe identify all packages which are not ciritcal and >> have an open merge review. Take those packages out of the repository. >> Then revisit the list and formulate a plan on what to do with thoes (even if >> the plan is then, these were critical enough to leave in so we'll give them >> a pass on going through a formal review). > > I like the idea of actually revisiting the list and deciding what to do, > although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. I'd only be supportive of this on two conditions: 1) Actual bugs impacting actual people as a result of an improper spec file were present 2) One of the bodies responsible for packages in Fedora (FESCo, FPC, ?) agreed to conduct audits across all packages for guideline adherence at regular intervals. I'd be willing to not require item 1 if item 2 were actually done. It never has been, and if it had it would already suffice for the purpose the merge review tickets would serve today. We have a lot of guidelines. Enough that it can be rather daunting to a new packager to even start packaging something. What we have always lacked is enforcement and accountability on those guidelines _after_ something is in the distro. Fix that problem and everything else relating to it will be solved. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote: > > For the record Fedora is not a bleeding edge distro anymore or first in > > anything > maybe some people should consider the difference between "leading" and > "bleeding" > smart: leading if things are ready > dumb: bleeding for any price I agree with Harald here. I think some people have always wanted it to be, but Fedora never really has been chartered to be "bleeding". To quote the "first" foundation more fully: First represents our commitment to innovation. We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution. Note "latest in stable and robust", not "latest bleeding edge". There is supposed to be a balance here. -- Matthew Miller-- Fedora Project-- -- 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: Let's close the remaining merge reviews
On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: > Alternative idea -- maybe identify all packages which are not ciritcal and > have an open merge review. Take those packages out of the repository. > Then revisit the list and formulate a plan on what to do with thoes (even if > the plan is then, these were critical enough to leave in so we'll give them > a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. -- Matthew Miller-- Fedora Project-- -- 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: Let's close the remaining merge reviews
On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: > On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: >> >> An alternative would be to reassign every open merge review to the component >> in question, and let maintainers handle it as they like. >> >> Thoughts? >> > Alternative idea -- maybe identify all packages which are not ciritcal and > have an open merge review. Take those packages out of the repository. > What does that solve? How does that benefit anybody? > Then revisit the list and formulate a plan on what to do with thoes (even if > the plan is then, these were critical enough to leave in so we'll give them > a pass on going through a formal review). > The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole -- 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: Let's close the remaining merge reviews
- Original Message - > On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi wrote: > > On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: > >> > >> An alternative would be to reassign every open merge review to the > >> component > >> in question, and let maintainers handle it as they like. > >> > >> Thoughts? > >> > > Alternative idea -- maybe identify all packages which are not ciritcal and > > have an open merge review. Take those packages out of the repository. > > That's a bit harsh ... we have been shipping those packages for years, why > suddenly drop them? What problem does this solve? Yep, it's really too strict. Also setting the bar how much package is critical sounds weird. For reviews - I'd say most of the review requests bugs are already obsolete. What would actually help making Fedora better would be regular fedora- review (*) runs - even I'm again a bit sceptical we would be able to go through it same as for merge reviews. But for more active maintainers it could help them to make SPECs better. (*) not full review, much more easier tool to check basic sanity of SPECs... Jaroslav > -- > 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
Reminder: Change Proposals Submission Deadline in two weeks
Hi, the Change Proposals Submission Deadline is coming soon, in two weeks [1] - 2014-04-08. I'd like to ask especially WGs to work on the PRD/Tech Specs break out into the Change Proposals - so the scope of release can be evaluated and also for tracking purposes to knwo where we are with Fedora 21/Next release. Help us with Fedora 21 and .next initiative planning and development coordination! See https://fedoraproject.org/wiki/Changes/Policy for current policy for submissions and start a new proposal using this template https://fedoraproject.org/wiki/Changes/EmptyTemplate Let me know in case of any issues, I'll try to help you! [1] https://fedoraproject.org/wiki/Releases/21/Schedule Jaroslav ___ 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 25/03/14 03:00 AM, Michael Catanzaro wrote: On Mon, 2014-03-24 at 17:14 -0700, Adam Williamson wrote: Saying that "nobody" wants this, it's "madness", "totally wacky", "almost all users are NOT going to put up with this" is going rather too far. I think it's entirely worth the Desktop product making this possible and I suspect quite a lot of people will use it, but I don't think it's sufficient grounds for downgrading the spins too far in importance or dropping them. That language was probably too harsh, sorry. Let's try again: I think a large (or huge) subset of users will be dissatisfied with the procedure for installing alternate desktops through GNOME Software, and will opt to not install Workstation at all. I don't think this will be a surprise to anybody. As long as we still have spins, it's not really a big deal. The question this brings up then is: what's the point of Workstation then? (We have come full circle back to this question...) Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
