Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 14 Jan 2015, at 12:34, Miloslav Trmač wrote: I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication It seems that the boxes affected by this proposal are either product=server or product=nonproduct. For servers, immediately after installing, I log in as root and run a set-up or configuration script which, among other things, sets the box to a non-graphical target and prevents firstboot from ever running. I'm not sure why one would run firstboot on a server. I also do something similar and prevent firstboot from running on boxes set up as general desktops for office workers, etc., as I don't want the first random user who logs into a box to be able to become part of the wheel group and have access to sudo. As far as I can see, firstboot is only useful on one's personal box. -- Mike Pinkerton -- 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: How to contact Michale Cromeworth
On 01/14/2015 12:39 PM, Chris Adams wrote: MX-CNAME is against RFCs but in common enough real-world usage that anything that doesn't handle it is generally considered broken. However, that isn't the case for cchtml.com; the MX points to cchtml.com, not mail.cchtml.com, and cchtml.com has an A record. That was not the case 30 minutes ago. I modified the MX record to point to cchtml.com. My registrar may have changed something recently as the interface allows for an IP address and that wasn't what it was doing. -- 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: How to contact Michale Cromeworth
Am 14.01.2015 um 19:39 schrieb Chris Adams: MX-CNAME is against RFCs but in common enough real-world usage that anything that doesn't handle it is generally considered broken. Well, one of the biggest German freemailers refused to send emails for recipient domains using MX is CNAME when using their web interface (as of 2014). fs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Split DNS broken again - test case?
https://bugzilla.redhat.com/show_bug.cgi?id=1161232 It seems like this is the 3rd or 4th time that this functionality has been broken, leaving anyone who needs to simultaneously connect to both VPN and other non-public (e.g. home network) resources up a creek. Would this be worth of a test case? -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 2015-01-14 at 16:54 +, P J P wrote: Hi, On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. It'll help if you could add your details to the ether pad, for later reference. Still, you can't just invoke features into existence by describing them on a Change page. There needs to be a credible plan for actually *doing* that work, yet so far as I can tell, none of the anaconda developers is involved the Change proposal, nor has anyone said I will write the code to make this work. In a project like Fedora, it doesn't always work out well to do things the way this Change seems to be going: think of one change you want to do, write up a Change for it, realize that lots of other things would have to be done to make the change viable, and just write those things into the Change as bullet points, and assume that somehow they'll be made to happen if the change is approved. Two other outcomes are more likely: 1) the Change will be rejected because FESCo is worried about whether the necessary work will actually get done, 2) the Change will get accepted but all the necessary work won't actually get done, and the Change will have to be backed out (wasting a lot of everyone's time), or the Change will go in broken and everyone loses. Basically, when proposing a Change, you need to make sure that you have a plausible plan for all the necessary work to get done *ahead of time* - i.e. you need actual people who have said yes, I will do this work, and I can believably commit to having it done in time. It doesn't work, normally, to draw up a Change which requires work to be done, then expect that you can get the Change accepted and resources will somehow transpire to do the work. -- 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
Summary/Minutes from today's FESCo Meeting (2015-01-14)
=== #fedora-meeting: FESCO (2015-01-14) === Meeting started by mattdm at 18:01:50 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-01-14/fesco.2015-01-14-18.01.log.html . Meeting summary --- * init process (mattdm, 18:01:56) * 1349 Fedora 22 scheduling strategy (and beyond) (mattdm, 18:06:50) * LINK: https://fedorahosted.org/fesco/ticket/1349 (mattdm, 18:06:54) * AGREED: While Fedora prefers to always carry the latest features, FESCo has determined that the Fedora 22 schedule is not compatible with including a mass-rebuild. FESCo would prefer to hold to a time-based schedule. (+6, 1, -1) (sgallagh, 19:02:40) * meeting schedule, continued (mattdm, 19:08:58) * #1374 SElf Contained Changes (mattdm, 19:11:02) * LINK: https://fedorahosted.org/fesco/ticket/1374 (mattdm, 19:11:14) * AGREED: Lohit2 Odia Telugu self-contained change passes +7/-0 (mattdm, 19:15:47) * AGREED: New Default Console Font self-contained change passes +7/-0 (mattdm, 19:16:07) * #1307 F22 System Wide Change: Default Local DNS Resolver (mattdm, 19:16:45) * LINK: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver (mattdm, 19:16:49) * LINK: https://fedorahosted.org/fesco/ticket/1307 (mattdm, 19:16:51) * ACTION: pjp to add some notes about docker and cloud to the feature page :) (mattdm, 19:24:16) * ACTION: pavlix to look at init.d/network (thozza, 19:24:36) * AGREED: Default Local DNS Resolver accepted for F22 (+7/0/0) (mattdm, 19:25:17) * #1379 F22 System Wide Change: Change xorg input stack to use libinput (mattdm, 19:25:31) * LINK: https://fedoraproject.org/wiki/Changes/LibinputForXorg (mattdm, 19:25:34) * LINK: https://fedorahosted.org/fesco/ticket/1379 (mattdm, 19:25:36) * AGREED: Change xorg input stack to use libinpu accepted for F22 (+7/0/0) (mattdm, 19:28:43) * #1382 F22 System Wide Change: Fedora 22 Boost 1.58 Uplift (mattdm, 19:29:59) * LINK: https://fedoraproject.org/wiki/Changes/F22Boost158 (mattdm, 19:30:03) * LINK: https://fedorahosted.org/fesco/ticket/1382 (mattdm, 19:30:05) * AGREED: Side-tags must be merged into Rawhide by February 6th, with Branch occurring on February 10th as previously scheduled. (+7/0/0) (mattdm, 19:37:44) * AGREED: Boost 1.58 accepted for F22 (+6/-0/1) (mattdm, 19:43:03) * timing makes 1.57 likely (as page explains) (mattdm, 19:43:24) * #1383 F22 System Wide Change: GHC 7.8 (mattdm, 19:43:59) * LINK: https://fedoraproject.org/wiki/Changes/GHC_7.8 (mattdm, 19:44:02) * LINK: https://fedorahosted.org/fesco/ticket/1383 (mattdm, 19:44:04) * AGREED: GHC 7.8 accepted for F22 (+7/0/0) (mattdm, 19:45:52) * #1384 F22 System Wide Change: Harden all packages with position-independent code (mattdm, 19:45:59) * LINK: https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code (mattdm, 19:46:03) * LINK: https://fedorahosted.org/fesco/ticket/1384 (mattdm, 19:46:05) * AGREED: System Wide Change: Harden all packages with position-independent code NOT accepted for F22 (0,-7,0) (mattdm, 19:49:04) * F23 decision defered until next week (mattdm, 19:55:43) * #1385 F22 System Wide Change: Ruby 2.2 (mattdm, 19:56:00) * LINK: https://fedoraproject.org/wiki/Changes/Ruby_2.2 (mattdm, 19:56:03) * LINK: https://fedorahosted.org/fesco/ticket/1385 (mattdm, 19:56:05) * AGREED: System Wide Change: Ruby 2.2 accepted for F22 (+6/0/0) (mattdm, 19:56:55) * #1386 F22 System Wide Change: Set sshd(8) PermitRootLogin=no * # (mattdm, 19:57:04) * LINK: * https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no (mattdm, 19:57:08) * LINK: https://fedorahosted.org/fesco/ticket/1386 (mattdm, 19:57:10) * The change text now actually proposes PermitRootLogin=without-password (mitr, 20:06:40) * AGREED: Set sshd(8) PermitRootLogin=no as systemwide DOES NOT * pass for F22 (+0/-5/2) (mattdm, 20:08:35) * Next week's chair (mattdm, 20:09:20) * dgilmore is the heroic chair for next week's meeting (mattdm, 20:09:43) * Open Floor (mattdm, 20:09:47) Meeting ended at 20:12:12 UTC. Action Items * pjp to add some notes about docker and cloud to the feature page :) * pavlix to look at init.d/network Action Items, by person --- * pavlix * pavlix to look at init.d/network * pjp * pjp to add some notes about docker and cloud to the feature page :) * **UNASSIGNED** * (none) People Present (lines said) --- * mattdm (230) * sgallagh (116) * dgilmore (108) * nirik (96) * mitr (73) * jwb (67) * jreznik (38) * jakubrh (37) * kalev (35) * thozza (30) * pjp (28) * zodbot (20) * moezroy (9) * vondruch (6) * rdieter (5) * drago01 (5) * pavlix (5) * hansg (5) * tyll (2)
Re: GUI applications writing garbage to stdout/stderr
On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se wrote: Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. The programs mentioned above do not have a debugging or verbosity flag, like e.g. nmap -dd. The output can help pinpoint anything from minor aesthetic glitches, like a missing gtk theme, to crashes at startup. And that is a lot faster than querying the environment or running debuggers. -- 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: Koji build root caching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jan 2015 16:40:35 +0100 Vít Ondruch vondr...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 16:00 Dennis Gilmore napsal(a): On Wed, 14 Jan 2015 14:57:59 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. Actually this is not anytime. newRepo has to be run, which is not run more then 4 times per hour I'd say. If the new snapshot is prepared as part of newRepo task, the mock could reuse the snapshot. ok I have a data point here https://ausil.fedorapeople.org/buildroots the file in the link is the output of a sql query on koji's db it gives the number of times a unique repo was used on a builder to do a build. so basically it tells you if we cached the buildroots somehow how many times they would get used. $ grep ^ 19 | buildroots|wc -l 1 $ grep ^ 18 | buildroots|wc -l 0 $ grep ^ 17 | buildroots|wc -l 0 $ grep ^ 16 | buildroots|wc -l 2 $ grep ^ 15 | buildroots|wc -l 1 $ grep ^ 14 | buildroots|wc -l 0 $ grep ^ 13 | buildroots|wc -l 8 $ grep ^ 12 | buildroots|wc -l 13 $ grep ^ 11 | buildroots|wc -l 14 $ grep ^ 10 | buildroots|wc -l 15 $ grep ^ 9 | buildroots|wc -l 20 $ grep ^ 8 | buildroots|wc -l 24 $ grep ^ 7 | buildroots|wc -l 40 $ grep ^ 6 | buildroots|wc -l 59 $ grep ^ 5 | buildroots|wc -l 84 $ grep ^ 4 | buildroots|wc -l 155 $ grep ^ 3 | buildroots|wc -l 409 $ grep ^ 2 | buildroots|wc -l 1446 $ grep ^ 1 | buildroots|wc -l 4794 What I get from this is that in the majority of cases caching won't help at all. The cost of creating the cache is higher than the benefit we would get. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtvHgAAoJEH7ltONmPFDRP/sP/1iteUyvThkZLQGH4o+MY4uX oIwdgwQQwkkjvpCyjFP1yyO5aJa/BTiOGSMtT0vQtnfAl+qYs7IiqGH6VJkNt+Io Lmqr0yItXLr6ZyTwuKha2XYa88g+q657VmaJT/OmXGqi0Ezx8Rj/6NLXcV6twgKW LD3YjxtPmyxX79p7RrkrI5+iJ+Iyw48HLepZup+XOfydOJ0RWZccRVlm0c0MYzt1 P6H0M+iiDikLl2NE1/jCTx+/P9yQNSQ8zhMVCjhevGiHSHmhIZmcpPib/IYGfRBN OmgTaQ9XSaePNNrE4iqq6bQQ9fKqpA1FDlj1U2IaEHTh0CQ9zLCqKBuOl0ky98zY /m3obzNSYu441tl/1Ig6imzRXga/iQ0jo8WnQoW8Grh3JtGpNM6NVPEUkkyKWCxE XuagkPGWqP7x8YT/czn0Y9ZGjA+jIijzhdcAJ8R9R94wuhy+wvY5F69z6FKSycX6 Mho6yGj6cOrIB+F3Vs2+zn4rmtsU8jT7uhYc81CHJ0pEilcnINvFW9VDw7gYKq1E LFzxMeixQugtGO39PqVFdG7WErqX2pjInJLu/CZIVz0bofQ17RuE006yl1pS4+jG HoF6pCbZlapsRWS6TqXiMPhTSruszbZ733zihOgbDNSB6kIXZgI9nqj/jN8s8Dw1 ikGLTDN8nrnFxWMSt9pY =/MGg -END 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: GUI applications writing garbage to stdout/stderr
On Thu, Jan 15, 2015 at 12:35:02AM +0100, Reindl Harald wrote: Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos: On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se mailto:Bjorn@rombobjörn.se wrote: If they don't have such a build-time option, then what I'm saying is that if one were to suppress the messages, then one should do it with a run-time option, not a build-time option. Then no different build would be needed and debugging would be easy. No argument from me there. I just hate it when things start dying and leave you clueless (without as much as a -v option). And let's not forget that a special debug build may not suffer from the same issues as the regular one. It has happened to me on occasion. Perhaps over the years I've grown accustomed to the gibberish in my terminal and started considering it normal, instead of buggy, as Reindl Harald points out the real problem with that crap messages is that if you are about writing a longer command line and the in background mode started GUI app decides to blow out it's helpful messages they appear unasked in the middle of your input and so the only thing you can do is CTRL+C and hope the next try don't get interrupted again ^L should work. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Remove gcc, gcc-c++ and make from minimal build root
On 01/14/2015 04:38 AM, Vít Ondruch wrote: And it seems that this is the number of packages written in C++: $ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires 'libstdc++.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l 2396 I'd like to point out at this place, that this would help also the 5006 packages written in C, since they don't need C++ to build. Only 14.8 % of packages, which happens to be written in C++, would not benefit from this change. Instead of dropping make, gcc, and gcc-c++ from the minimal build root, would it make sense just to drop gcc-c++? That would only affect a small minority of packages, while eliminating some amount of additional packages in the buildroot. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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: GUI applications writing garbage to stdout/stderr
Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos: On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se mailto:Bjorn@rombobjörn.se wrote: If they don't have such a build-time option, then what I'm saying is that if one were to suppress the messages, then one should do it with a run-time option, not a build-time option. Then no different build would be needed and debugging would be easy. No argument from me there. I just hate it when things start dying and leave you clueless (without as much as a -v option). And let's not forget that a special debug build may not suffer from the same issues as the regular one. It has happened to me on occasion. Perhaps over the years I've grown accustomed to the gibberish in my terminal and started considering it normal, instead of buggy, as Reindl Harald points out the real problem with that crap messages is that if you are about writing a longer command line and the in background mode started GUI app decides to blow out it's helpful messages they appear unasked in the middle of your input and so the only thing you can do is CTRL+C and hope the next try don't get interrupted again 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: GUI applications writing garbage to stdout/stderr
Alexander Ploumistos wrote: On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se wrote: Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. The programs mentioned above do not have a debugging or verbosity flag, like e.g. nmap -dd. Do they have a build-time option to make the different build you mentioned? If so, then that's the reason why they would be difficult to troubleshoot if the messages were suppressed. The developers could easily have made Marcel happy, and at the same time kept the programs easy to debug, simply by making it a run-time option instead of a build-time option. If they don't have such a build-time option, then what I'm saying is that if one were to suppress the messages, then one should do it with a run-time option, not a build-time option. Then no different build would be needed and debugging would be easy. -- Björn Persson pgpDpsssop0Og.pgp Description: OpenPGP digital signatur -- 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: GUI applications writing garbage to stdout/stderr
Am 15.01.2015 um 00:36 schrieb Zbigniew Jędrzejewski-Szmek: the real problem with that crap messages is that if you are about writing a longer command line and the in background mode started GUI app decides to blow out it's helpful messages they appear unasked in the middle of your input and so the only thing you can do is CTRL+C and hope the next try don't get interrupted again ^L should work which clears also the screen - bad if the input you make depends on the output of previous commands, the same if your foreground terminal app is producing output intended for copypaste into a mail after finish a application has *no* valid reason to spit debug output left and right unasked, and as said proven by deprecation warnings over years even the upstream developers don't read them - so why annoy endusers 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: GUI applications writing garbage to stdout/stderr
Am 15.01.2015 um 00:13 schrieb Reindl Harald: Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos: On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote: Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. The programs mentioned above do not have a debugging or verbosity flag, like e.g. nmap -dd then they are broken and instead that the developer spits full my terminal started a remote X11 appplication because i touch something in that window he better would include such a switch defaulting to off start kate (kde app) in a remote SSH session like below udisks2 is masked? so what - i know that hence there is a entry in rsyslog to shut up that crap appears everytime you successful open a file and BTW messages like Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) which appears for many years now prove that it is *completly useless* and even the developers of the application itself don't care otherwise such warning would go away over time the same for broken desktop-files and what not reported again and again in that context and nobody cares about - so why annoy the ordinary user with that debug informations all day long? 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
Unplanned Fedora Outage 2015-01-14 21:30
Fedora had a 35 minutes off the internet outage starting around 21:30 UTC. This was due to my pushing an incomplete DNS table out causing named to crash when it got to starting the file getfedora.com and not finding it. Problem was backed out and changed but because of a bootstrap issue of needing dns to get to dns in a couple of places it had to be done by hand to get all DNS servers back up. I am looking at what I can do to not have this happen again or make backing out faster. My apologies for the many many many pages people in sysadmin got. -- 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: GUI applications writing garbage to stdout/stderr
Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos: On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote: Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. The programs mentioned above do not have a debugging or verbosity flag, like e.g. nmap -dd then they are broken and instead that the developer spits full my terminal started a remote X11 appplication because i touch something in that window he better would include such a switch defaulting to off start kate (kde app) in a remote SSH session like below udisks2 is masked? so what - i know that hence there is a entry in rsyslog to shut up that crap appears everytime you successful open a file Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kbuildsycoca4 running... Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QDBusObjectPath) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath) Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QString) Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QDBusObjectPath) Object::connect: No such signal QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath) Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. Failed enumerating UDisks2 objects: org.freedesktop.systemd1.Masked Unit udisks2.service is masked. 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: GUI applications writing garbage to stdout/stderr
On Thu, Jan 15, 2015 at 12:36:27AM +0200, Alexander Ploumistos wrote: On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson Bjorn@rombobjörn.se wrote: Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. The programs mentioned above do not have a debugging or verbosity flag, like e.g. nmap -dd. The output can help pinpoint anything from minor aesthetic glitches, like a missing gtk theme, to crashes at startup. And that is a lot faster than querying the environment or running debuggers. According to this logic, any program should spout maximum possible information, because it might be useful. The reality is different — only some users debug those issues some of the time. They can easily flip a switch or set an environment variable when they want to use debug output. For the majority of users useless output annoys and makes it harder to find relevant things or use the tools from the command line. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GUI applications writing garbage to stdout/stderr
On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson Bjorn@rombobjörn.se wrote: If they don't have such a build-time option, then what I'm saying is that if one were to suppress the messages, then one should do it with a run-time option, not a build-time option. Then no different build would be needed and debugging would be easy. No argument from me there. I just hate it when things start dying and leave you clueless (without as much as a -v option). And let's not forget that a special debug build may not suffer from the same issues as the regular one. It has happened to me on occasion. Perhaps over the years I've grown accustomed to the gibberish in my terminal and started considering it normal, instead of buggy, as Reindl Harald points out. -- 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: GUI applications writing garbage to stdout/stderr
Alexander Ploumistos wrote: On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. Nah, it takes only a command line parameter to turn on debug logging. An environment variable could also be used. A different build isn't needed. It's no harder to make logging conditional at run time than it is to make it conditional at build time. -- Björn Persson pgpe3awOb9zZ2.pgp Description: OpenPGP digital signatur -- 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: Split DNS broken again - test case?
On Wed, 2015-01-14 at 14:29 -0600, Ian Pilcher wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1161232 It seems like this is the 3rd or 4th time that this functionality has been broken, leaving anyone who needs to simultaneously connect to both VPN and other non-public (e.g. home network) resources up a creek. Would this be worth of a test case? It seems that the issue never actually got fixed, so it was always broken. Patches have been submitted upstream (to the bug linked from rhbz#1161232) which will be backported to F21's 0.9.10 and submitted as an update soon. 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
wxPython 3.0 in Rawhide
All, As discussed in [1], I've updated the wxPython package into Rawhide to wxPython 3.0. I'll start working on testing all of the dependent packages. If any maintainers of dependent packages can test their packages, that would be helpful too. Please let me know the status, or update the changes wiki page. Thanks, Scott [1] https://fedoraproject.org/wiki/Changes/wxPython3 -- 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-devel] Questiona regarding c++11 support
Dear all, I am not sure whether this has been discussed before or whether it's appropriate to discuss this in this list. My question is about c++11 support for the projects on epel (probably more specifically, epel7). Do we have any kind of general policy regarding c++11 support? I am asking this because recently we encountered a problem related to this. The case is that our project is built with option '-std=c++11' while the library used by our project on epel (specifically mongo-cxx-driver) was not built with this option, and our process simply crashes during start. The root cause is the ABI built with c++11 option is actually not compatible with that without it. Please refer to https://gcc.gnu.org/wiki/Cxx11AbiCompatibility. So the '-std=c++11' draws a clear line between binaries/libraries, all of them must be built either with it or without it(C code is probably fine). You cannot mix them togother, otherwise there might be risks. Is there any general policy regarding this c++11 support? Or just maintainers make the decision for specific project? If the question is not approriate to discuss in this list, please ignore it. Or if anyone has any idea about where I can find relevant information, could you please share with me? Thanks~ -- Best Regards Jacky [wargaming.net] EgzO3mXGcK This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
gcc and re-initialization of dynamic libraries?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 https://bugzilla.redhat.com/show_bug.cgi?id=1083292 I know that this isn't directly related to Fedora, but I was wondering if anyone had any recommendations on how to proceed with this. clang and icpc generate code that has the correct behavior (or at least what I believe is the correct behavior), but because of some flags that are set by gcc it doesn't re-initialize the dynamic library as expected. Any ideas/suggestions? Thanks, Dave -- 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 5:51 PM, Miloslav Trmač m...@redhat.com wrote: * Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release This is an invasive contingency mechanism, requiring retesting a lot of functionality; the contingency deadline for this (i.e. when we need to be comfortable that the revert will not be needed, should certainly be at the usual beta freeze at the latest, if not earlier. Invoking this contingency mechanism “before release”, say during the GA RC phase, would really not be feasible without a massive slip. Any revert of this would mean another mass rebuild similar to what was needed in F-21 which will guarantee a slip of probably two weeks, late in the beta phase this becomes more of an issue. 18K packages do take some time to rebuild, tag etc. Peter -- 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote: - Original Message - On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote: http://gcc.gnu.org/gcc-5/porting_to.html → 404 That will be added likely after the test mass rebuild with what we find during that. Do you have any estimate when it will be done? F22 schedule is/will be pretty tight. We already have problem scheduling mass rebuild and I expect GCC 5 would require as long as possible period to fix issues/build problems. This How is that different from any other past Fedora releases (with the exception of F21)? If I remember well, at least starting with GCC 4.3 (March 2008) new GCC was deployed always in the spring release of Fedora, we've skipped 4.2 before that and as there was no spring release last year, GCC 4.9 was kind of an exception too. time, schedule is more strict time based - what would it mean for you if GCC 5 will miss F22? I'm not saying it's going to happen but it could be option. Well, if we want to turn Fedora into a collection of obsolete software rather than trying to lead progress, we don't have to update anything. In the past, from my experience with both GCC distro maintainer and upstream maintainer hats, shipping GCC early in Fedora helped both projects, the early deployment in Fedora helped Fedora developers to use latest langauge features (e.g. GCC 5 will finally have C++11 compliant std::string or std::list, and feature completeness on the C++14 language side, see changes.html for other stuff), help upstreams make the packages more portable and enjoy better generated code (e.g. if you really want to make PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea because only in 5 you can actually rely on PIE copy relocs and not get hit as much by the PIE penalty as before), and for the GCC project lead to wider testing and more bugfixes. Jakub -- 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: F22 System Wide Change: GCC5
On 14 January 2015 at 14:31, Jakub Jelinek ja...@redhat.com wrote: Again, how is that different from F9, F11, F13, F15, F17, F19? Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler, which could have quite some consequences. Or do you plan to have -std=gnu89 added to the default compiler flags? -- 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: Summary/Minutes from today's FESCo Meeting (2015-01-07)
On Wed, Jan 14, 2015 at 4:32 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote: The Fedora 21 mass rebuild took about 40 hours. ;) BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty. What are the goals of a mass rebuild now, given that we just had one before F21 Beta? This is actually that reason I liked how we constructed schedule last two releases - based on proposed changes, taking look what needs mass rebuild etc. And it could even end with no mass rebuild (or mass rebuild request can come on Jan-20 when the deadline for changes is). But I was alone who liked the old-new way and FESCo decided to set schedule the old-old way, I'm just the guy who puts it to the wiki :). You aren't alone. I'm still not convinced the strict time-based schedule will work, but most of FESCo wanted to give it a shot. Rather then be a stick in the mud, I went with don't be afraid to fail. Who knows, maybe it will work out. If it does, I think it's going to change some of the things people expect from Fedora in both good and bad ways. Good, delivered on time. Bad (maybe), delivered with less cutting-edge packages. 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: Remove gcc, gcc-c++ and make from minimal build root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jan 2015 14:57:59 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. while it may not be intentional you can get differences in setup and behaviour due to scriptlets doing different things on update and initial install. to get reproducability you would need to start with the same packages set and get the same updates. it really is not simple to do nor to track. which is why we purposely disable all caching. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtoSFAAoJEH7ltONmPFDR4ssP/RF2a1sQ1h+M7bU6A455311X Q1JH7h6gcBLiYlcDfDURB2EoeQTqTkyqNgXRjNIZQc9B74/DprH2Tqipz/E3dvt2 i9oRL7yyO7uzaj+Epyg0Pa1ktCz4eEqvuTdUokgQtbwtK4nkgj7O5G9ui48vCbE2 bqsLzcavQqHb/UHT1yqBiEQaTptu07u8/KFRWwTI2HNAS8naQ+07/e26OkGT+NDZ QT2nnVPPOAd21wps5Bi2r33CZzQHwQRnUd+XcXn0hARWy+9A06T4/4x0/N8C60Rf NgDF0RyJouIilw4Y0YGijBPMY5aQ88YljVYm5UG8foGxi2romvW0DmpNumlB+1S+ gHS27G3EgY8zdlvZcIOlOR6TLRpfFBmGEMz9JrvNNoDaKEqBlBxt55AOBRw16oFQ Oq9jdYMq1hlIjz58812yd/Qoc0RqreMU5UVX8NxLw0GLKUeDMTWyCU+jmqKWiWnC 99DiUOTjwncZL55wjXEgFAztL9XxcsJcFuzz3WJR84RI4OUNZbpyFlJ8u1/a5iaL JYx1j6MrkVMBjtz3W8jOQ4218feB/kiGNbm37hH+GHTeuFPTIUu/dv/eE0LSMT0T LFLSqe6toEZrlapIEmYEuHNpLnOPg1Y/0+mAEj6PEwVKWyXKDms53rICKq3y9dw2 2fhJJ4duyZKIYSfWA8KJ =jxfx -END 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 14 January 2015 at 14:31, Simo Sorce s...@redhat.com wrote: On Wed, 14 Jan 2015 05:53:23 + (UTC) P J P pj.pan...@yahoo.co.in wrote: IMO, the ones opposing are those who fear their current setups/practices would break. Because they need remote 'root' access in their set-up. Which is a genuine use-case. And to support it, we could provide an option to enable remote root access with 'PermitRootLogin=Yes', based on the the user's response to Anaconda at install time, as was suggested in previous email. However, let's not assume _all_ Fedora users have this use-case. Workstation do not even enable sshd (IIRC) so this impacts the server images (cloud images already do their magic with sshd so I am not counting them here), and server has different use cases and security implications than a generic population. Not just workstation, spin images, it's a decision pre-dating workstation. -- imalone http://ibmalone.blogspot.co.uk -- 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 03:05:09PM +, Peter Robinson wrote: Well, if we want to turn Fedora into a collection of obsolete software rather than trying to lead progress, we don't have to update anything. I think that's a bit of an over reaction, ultimately F-22 is due to branch on February 10th which is less than a month from now, the moment it branches gcc5 could land and people are then free to rebuild anything they like and gcc5 will be in the October release which is in all likely hood earlier than most other distros would adopt it anyway. For a product with a rough schedule every 6 month and another quite time based every 12 months that is significant. It turns Fedora from being one of the first distros to ship the new compilers to one of the last if not the last one. Jakub -- 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: F22 Self Contained Change: Gnome Shell - New Notifications
On Wed, 2015-01-14 at 13:24 +, Peter Robinson wrote: On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote: = Proposed Self Contained Change: Gnome Shell - New Notifications = https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications Change owner(s): Florian Müllner fmuel...@redhat.com Redesign the way in which notifications are shown and kept available in gnome- shell. == Detailed Description == The message tray is one of the remaining weaker points of the original gnome- shell design. This change will replace it with a new implementation of notifications that avoids the problems of the current implementation. Is there a place where the detailed description is more detailed? A wiki page on gnome.org maybe listing the current problems and the new approach taken? I'm curious and would like to read more about this :) Allan Day, one of the gnome designers, did a pretty good overview in a couple of blog posts. http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/ Good point - I've added that link to the page now. -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 05:53:23 + (UTC) P J P pj.pan...@yahoo.co.in wrote: Hello Simo, On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote: Sorry this is false. You got enough emails telling you this change is undesirable, that's the definition of opposition and means you have no _consensus_. IIUC, that was for disabling remote root access completely with 'PermitRootLogin=no'. As the 'PermitRootLoing=without-password' option seems more preferred. As for the emails, many folks have also said that it is a useful change. Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. IMO, the ones opposing are those who fear their current setups/practices would break. Because they need remote 'root' access in their set-up. Which is a genuine use-case. And to support it, we could provide an option to enable remote root access with 'PermitRootLogin=Yes', based on the the user's response to Anaconda at install time, as was suggested in previous email. However, let's not assume _all_ Fedora users have this use-case. Workstation do not even enable sshd (IIRC) so this impacts the server images (cloud images already do their magic with sshd so I am not counting them here), and server has different use cases and security implications than a generic population. - IMHO, the change helps to harden Fedora systems and raise the security bar a notch higher. It is similar to how we run services as non-root user instead of 'root' user. I disagree that there is any similarity, and it doesn't bring security up a notch, most ssh attempts already probe for multiple users, preventing just root+password login is just cosmetics if user+password+sudo can do the same operations when broken in. If you want to do something effective against password guessing attack there are a few much better (and easy to implement) methods: 1) require a longer root password, so that brute forcing just fail 2) implement throttling so that trying to log in as root is slowed down considerably (and the related brute-force) 3) implement temporary black-listing, so that an IP that fails a pre-set number of times simply gets black-list for a pre-set period of time. - The proposed change of using ssh keys for remote 'root' access introduces that mechanism to a wider audience, which in turn would help increase its usage in the future. Hence bring more value in the long term. Except you have no mechanism to inject a key at installation time, you would have to implement that first, *then* you can think of changing the default. - IMO, it is beneficial to supply hardened default configurations, because they protect maximum users and have greater impact, than otherwise. Security is not a feature, it must be available by default. Security and Usability are always at odds, exceeding in one and destroying the other is always as bad. The solution you propose only minimally affect security, the security increase is really negligible. But the usability is affected greatly, I think disproportionally, which is why I am opposed to this change. I am not against hardening, but this is just make things diofficult for little to no gain. - Of course that does not mean we overlook the usability aspect. As said before intention is _not_ to trouble users, but increase their safety as much as we can. The intention may be not, then I'll call it poor execution/planning and still oppose this move *at this time* unless there is proof we address the usability problem first. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote: On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote: http://gcc.gnu.org/gcc-5/porting_to.html → 404 That will be added likely after the test mass rebuild with what we find during that. Do you have any estimate when it will be done? F22 schedule is/will be pretty tight. We already have problem scheduling mass rebuild and I expect GCC 5 would require as long as possible period to fix issues/build problems. This time, schedule is more strict time based - what would it mean for you if GCC 5 will miss F22? I'm not saying it's going to happen but it could be option. I was thinking exactly that, mass rebuild is scheduled for Jan 30th according to the schedule [1] with branching 10 days or so later. That is only two weeks away. With statements like The release will happen probably in the first half of April when we're already suppose to be be in freeze from end of March I think this would be better landing in F-23 right after we branch F-22 off on Feb 10th. Ultimately the above gives us no room to move and a roll back is another mass rebuild which will only cause more delay! Again, how is that different from F9, F11, F13, F15, F17, F19? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Linux-Pid] Specify all dependencies
commit 5f5a4df31398551361d1b0f75a1ecb90942b4381
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 14 15:32:31 2015 +0100
Specify all dependencies
perl-Linux-Pid.spec | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
---
diff --git a/perl-Linux-Pid.spec b/perl-Linux-Pid.spec
index 5566264..8e706a8 100644
--- a/perl-Linux-Pid.spec
+++ b/perl-Linux-Pid.spec
@@ -1,6 +1,6 @@
Name: perl-Linux-Pid
Version:0.04
-Release:23%{?dist}
+Release:24%{?dist}
Summary:Get the native PID and the PPID on Linux
Group: Development/Libraries
@@ -9,12 +9,20 @@ URL:http://search.cpan.org/dist/Linux-Pid/
Source0:
http://www.cpan.org/modules/by-module/Linux/Linux-Pid-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
+# Carp not used at tests
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: perl(XSLoader)
+# Tests:
+BuildRequires: perl(Config)
BuildRequires: perl(Test::More)
BuildRequires: perl(threads)
BuildRequires: perl(threads::shared)
-BuildRequires: perl(XSLoader)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Carp)
%global __provides_exclude ^Pid\.so
@@ -60,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Jan 14 2015 Petr Pisar ppi...@redhat.com - 0.04-24
+- Specify all dependencies
+
* Tue Aug 26 2014 Jitka Plesnikova jples...@redhat.com - 0.04-23
- Perl 5.20 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Linux-Pid] Fix dependency filtering
commit a38f98427aa354088ce55c45be29322c7e08c593
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 14 15:36:03 2015 +0100
Fix dependency filtering
perl-Linux-Pid.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-Linux-Pid.spec b/perl-Linux-Pid.spec
index 8e706a8..aab6e80 100644
--- a/perl-Linux-Pid.spec
+++ b/perl-Linux-Pid.spec
@@ -24,7 +24,7 @@ BuildRequires: perl(threads::shared)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Carp)
-%global __provides_exclude ^Pid\.so
+%{?perl_default_filter}
%description
Linux::Pid gets the native PID and the PPID on Linux. It's useful with
@@ -70,6 +70,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Wed Jan 14 2015 Petr Pisar ppi...@redhat.com - 0.04-24
- Specify all dependencies
+- Fix dependency filtering
* Tue Aug 26 2014 Jitka Plesnikova jples...@redhat.com - 0.04-23
- Perl 5.20 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 02:37:02PM +, Jonathan Underwood wrote: On 14 January 2015 at 14:31, Jakub Jelinek ja...@redhat.com wrote: Again, how is that different from F9, F11, F13, F15, F17, F19? Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler, which could have quite some consequences. Or do you plan to have -std=gnu89 added to the default compiler flags? That is to be decided based on Mass rebuild results. I think in many packages it means no changes needed at all, in others only very small changes, then of course there could be packages with helplessly obsolete codebases where -std=gnu89 will be probably the only possibility, at least short term. The C99-C11 step is a fairly minor, C89-C99 is bigger, but mainly for old packages that haven't ever seen -Wmissing-prototypes or similar options. Jakub -- 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: F22 System Wide Change: GCC5
On 14 January 2015 at 14:37, Jonathan Underwood jonathan.underw...@gmail.com wrote: Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler Is there any easy way for humble little upstream maintainers to test their code with the new compiler? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-01-07)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jan 2015 10:48:16 +0100 Vít Ondruch vondr...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a): On Tue, 13 Jan 2015 15:58:51 -0700 Kevin Fenzi ke...@scrye.com wrote: On Tue, 13 Jan 2015 15:50:06 -0700 Stephen John Smoogen smo...@gmail.com wrote: You forgot too many packages? There are 15842 packages in Fedora 21 and 16230 in Rawhide. That is a lot of packages that have to be rebuilt possibly multiple times due to FTBFS, multiple architectures, etc. 2.5 weeks is 25200 minutes. That means a mass rebuild is doing 0.6 packages a minute across 3 architectures. That is pretty darn fast The Fedora 21 mass rebuild took about 40 hours. ;) That's really not the reason for more time, its the fallout from that. When the mass rebuild is tagged in, sometimes there's things broken in the build root, those need humans to look at and fix. Then, there are all the packages that didn't build for whatever reason, those need humans to look at them and fix them up. The ones with broken deps need fixing, etc. So, while the mass rebuild itself is less than 2 days, it takes a while to stablize things after that. If we branched right after the mass rebuild we would have to then stablize both rawhide and f22. It's hard to say how much time we really need there... it depends on how much stuff got broken, how hard it is to fix and how much time maintainers have to fix things. right. in the past the building took around a week or a bit more, we have gotten that down. which is why I said we could drop the 4 weeks to 3. the time consuming part is the cleanup and fixing of issues. that needs people. If everything is perfect a week could well be sufficient. Ideally we want secondary arches to be done in the window as well. just to make sure that there is no fallout on them requiring a second rebuild. which could also happen on primary. we have had ABI issues etc in the past on all arches. Dennis What I would love to see is to leave out the packages which are build in side tag from mass rebuild. E.g. if I have side tag for Ruby, I rebuild every package in the side tag in two weeks before mass rebuild, I can hardly see any justification to build them once again (unless there lands gcc in the man time or something like this). So if you could exclude the packages which are already build in side tag from mass rebuild, it would help you with following merge and it would give me additional time to rebuild Ruby packages. Is something like this feasible? It really depends on a lot of things. like does gcc 5 land after you have started your builds? we can go about excluding things viaa few different means. but it all really depends on a bunch of currently unknown factors. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtoLsAAoJEH7ltONmPFDRBp8P/RpWJ1hF3plD/zUMh6jR8bZS frgXBJ/R9uFvLXASEAfLoaHjrALeygRCF/ZDvd5RaZz3folzXF7YYhXsAijTRiwU vfmZj4svkJrDCU+uSWZeIC/KKmza4n4mFw8894njJCHfxggD6VupsYAoaQfWboBa gz4mC9srLZX10KOhyPuf+5GZ+ywZbsf0ELkdYitTGVYjYWrxhHjW9pC7dLCBUk+a 4d+Y3fNHqzNzOLIhL/NASB1cJpPqTV89g5yemDjGPPojUtj2qK2IAxHIh573JfgN dmjmAHsgOBA1GneUXLlMi/X42S9rm5gYNf+Cbr3sIhQghUUC79aeW0gG93PzTxGk iI106UaxEYuJ/NZXWMOkHaw/pvLluo8CtneXXskGRGdPAKHGrdyqtfFP93UfDn5t uGkJ403ESZSxkSv1sDJW9IhUdyJyVcp/tvyCHCgPnGpEz7eDEj3K52jPlLOLPmeT nWSvw7doMBUJX0oHtbDsSGm7jt3QhAHX/ru5LsQYNARn1A406vffqYnZnN3FpVHL Mnt9fVzm8iH/8wtz3taRQuTVOWLXyJzrq1+CTqxvkxp72sLxgRAMog+paUoD77IZ EX/b9L65pQ4WxLAHkm4mSd0yyJb29xLNWchahqwu1w2dBTo0hX5jXlpgejFyBcPw bRyCWm2X1sgM3p8QAqkO =gxJf -END 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
Koji build root caching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 16:00 Dennis Gilmore napsal(a): On Wed, 14 Jan 2015 14:57:59 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. Actually this is not anytime. newRepo has to be run, which is not run more then 4 times per hour I'd say. If the new snapshot is prepared as part of newRepo task, the mock could reuse the snapshot. Vít while it may not be intentional you can get differences in setup and behaviour due to scriptlets doing different things on update and initial install. to get reproducability you would need to start with the same packages set and get the same updates. it really is not simple to do nor to track. which is why we purposely disable all caching. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUto3yAAoJEAzgnueZF7h8WqoP/28+1zNKBSnYp8UfKJkBgltT qslYPgfwKWIVDsYVAKDf1Yqi/hYXl7cQuNOwDwgROO8Y34R0zPKGOVavl9CX7j4u +i8UGdpa9AmFe2WffTa6Z3U9rw93sMlPYtNhMKv3LeyQfgbhEIIqhVe4RL7bnht6 WfGrxWonWfipI8SL/jm60DgbT7634uoj0XZoVekETBoF67nmW5Y1U3zoLnpTJnEM ZO0+i2hHYPfRE3nPgN6Vw983Mh8pGya2vGFyRmyL5mjgz8i5fiSD0zjxhoX6BBF9 QYqVVPCCs8IJRhvX27AOSOKc9O3aBLYg1DczSpHTWMKGGTr9TgtgU5mOQuAhA06q 8c65nI5t/owmNwjQeC2uiQHa8jaqBtpmHYDevcjnqhsSfbCcdvLRjS7b80bvNWdg IcEv9ui6Af8+x75hTVhGUyvb7N02rQaOQx9MSVrWISG59AvRpBvE0HXM2d9lSdnN Kzs9EHerihLO+doZNZBD6qj9AaSzY2tKXJtBQL3myhi0Oj2wmUulUAm67VZmP4XK zZ9JGZ7DJCQOFAL2xkl/t1t4/0tDFwBZM1OFt8wQjE91CS3eCpV1iQRDVtDWZx2B Ih6y3gRNfJMRLBdUHSVfvU32kNmvxkloT98mv5F5bhJH4cYiY8OxmEoEvmg29u/y n7Ry0RU1Z37l7v5LvfRB =TqRs -END 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 9:28 AM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote: - Original Message - On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote: http://gcc.gnu.org/gcc-5/porting_to.html → 404 That will be added likely after the test mass rebuild with what we find during that. Do you have any estimate when it will be done? F22 schedule is/will be pretty tight. We already have problem scheduling mass rebuild and I expect GCC 5 would require as long as possible period to fix issues/build problems. This How is that different from any other past Fedora releases (with the exception of F21)? If I remember well, at least starting with GCC 4.3 (March 2008) new GCC was deployed always in the spring release of Fedora, we've skipped 4.2 before that and as there was no spring release last year, GCC 4.9 was kind of an exception too. The difference this time is that FESCo decided to set a time-based schedule and adhere to it. The past two releases were set based on submitted Changes (with F21 being weird all around). Before that, the schedule was time-based but not strictly stuck to which led to lots of slips. Essentially, this is an attempt to _actually_ do a time-based schedule. That being said, FESCo is discussing the schedule again today because there's no room for a mass rebuild at all. It will be interesting to see if they actually stick to the plan and defer any Change that requires a mass rebuild. 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote: On 14 January 2015 at 14:37, Jonathan Underwood jonathan.underw...@gmail.com wrote: Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler Is there any easy way for humble little upstream maintainers to test their code with the new compiler? You mean for the C89 - C11 default change, or for other changes in GCC 5? For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8). The latter is mainly C++ or new features, so something you don't hit on average C code. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Data-Flow] Specify all dependencies
commit fe850d568e8d59fb2c295c191fa53ee85f7f7c50
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 14 15:46:28 2015 +0100
Specify all dependencies
perl-Data-Flow.spec | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
---
diff --git a/perl-Data-Flow.spec b/perl-Data-Flow.spec
index 76a524a..f3aa2fd 100644
--- a/perl-Data-Flow.spec
+++ b/perl-Data-Flow.spec
@@ -1,6 +1,6 @@
Name: perl-Data-Flow
Version:1.02
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Perl extension for simple-minded recipe-controlled build of
data
# Author declared license there:
# https://rt.cpan.org/Public/Bug/Display.html?id=18068#txn-175743
@@ -9,11 +9,14 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Data-Flow/
Source0:
http://www.cpan.org/authors/id/I/IL/ILYAZ/modules/Data-Flow-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-# Run-time
-BuildRequires: perl(Exporter)
+# Run-time:
BuildRequires: perl(AutoLoader)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(Exporter)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
%{summary}.
@@ -22,13 +25,12 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
%setup -q -n Data-Flow-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -40,6 +42,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jan 14 2015 Petr Pisar ppi...@redhat.com - 1.02-9
+- Specify all dependencies
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 1.02-8
- Perl 5.20 rebuild
--
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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 03:47:18PM +0100, Jakub Jelinek wrote: On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote: On 14 January 2015 at 14:37, Jonathan Underwood jonathan.underw...@gmail.com wrote: Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler Is there any easy way for humble little upstream maintainers to test their code with the new compiler? You mean for the C89 - C11 default change, or for other changes in GCC 5? For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8). The latter is mainly C++ or new features, so something you don't hit on average C code. I think it's a valid request. Of course packagers can approximate, but to test for issues it would be best to have a simple way to build with gcc5 from the latest snapshot. How do you expect people to make an informed decision otherwise? Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote: http://gcc.gnu.org/gcc-5/porting_to.html → 404 That will be added likely after the test mass rebuild with what we find during that. Do you have any estimate when it will be done? F22 schedule is/will be pretty tight. We already have problem scheduling mass rebuild and I expect GCC 5 would require as long as possible period to fix issues/build problems. This time, schedule is more strict time based - what would it mean for you if GCC 5 will miss F22? I'm not saying it's going to happen but it could be option. I was thinking exactly that, mass rebuild is scheduled for Jan 30th according to the schedule [1] with branching 10 days or so later. That is only two weeks away. With statements like The release will happen probably in the first half of April when we're already suppose to be be in freeze from end of March I think this would be better landing in F-23 right after we branch F-22 off on Feb 10th. Ultimately the above gives us no room to move and a roll back is another mass rebuild which will only cause more delay! Peter [1] https://fedoraproject.org/wiki/Releases/22/Schedule -- 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: F22 System Wide Change: GCC5
http://gcc.gnu.org/gcc-5/porting_to.html → 404 That will be added likely after the test mass rebuild with what we find during that. Do you have any estimate when it will be done? F22 schedule is/will be pretty tight. We already have problem scheduling mass rebuild and I expect GCC 5 would require as long as possible period to fix issues/build problems. This How is that different from any other past Fedora releases (with the exception of F21)? If I remember well, at least starting with GCC 4.3 (March 2008) new GCC was deployed always in the spring release of Fedora, we've skipped 4.2 before that and as there was no spring release last year, GCC 4.9 was kind of an exception too. time, schedule is more strict time based - what would it mean for you if GCC 5 will miss F22? I'm not saying it's going to happen but it could be option. Well, if we want to turn Fedora into a collection of obsolete software rather than trying to lead progress, we don't have to update anything. I think that's a bit of an over reaction, ultimately F-22 is due to branch on February 10th which is less than a month from now, the moment it branches gcc5 could land and people are then free to rebuild anything they like and gcc5 will be in the October release which is in all likely hood earlier than most other distros would adopt it anyway. In the past, from my experience with both GCC distro maintainer and upstream maintainer hats, shipping GCC early in Fedora helped both projects, the early deployment in Fedora helped Fedora developers to use latest langauge features (e.g. GCC 5 will finally have C++11 compliant std::string And how is that any different if it lands in f-23/rawhide in mid Feb? or std::list, and feature completeness on the C++14 language side, see changes.html for other stuff), help upstreams make the packages more portable and enjoy better generated code (e.g. if you really want to make PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea because only in 5 you can actually rely on PIE copy relocs and not get hit as much by the PIE penalty as before), and for the GCC project lead to wider testing and more bugfixes. So the feature gets delayed by a release and it gets enabled in F-23 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-IO-stringy] Correct changelog date
commit a25222cb60a95469eef076d20d326077d5c423b2
Author: Petr Písař ppi...@redhat.com
Date: Thu Jan 15 07:53:09 2015 +0100
Correct changelog date
perl-IO-stringy.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-IO-stringy.spec b/perl-IO-stringy.spec
index fd70f74..9e12dc6 100644
--- a/perl-IO-stringy.spec
+++ b/perl-IO-stringy.spec
@@ -156,7 +156,7 @@ rm -rf %{buildroot}
- assume rpm knows about %%check and %%{perl_vendorlib}
- cosmetic spec file changes
-* Fri Apr 7 2005 Michael Schwendt mschwendt[AT]users.sf.net
+* Wed Apr 06 2005 Michael Schwendt mschwendt[AT]users.sf.net
- rebuilt
* Tue Feb 15 2005 Ville Skyttä ville.skytta at iki.fi 2.110-1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-stringy] Specify all dependencies
commit 3d4630751c1c599e2d8cda14adb59f578d66477a
Author: Petr Písař ppi...@redhat.com
Date: Thu Jan 15 07:48:37 2015 +0100
Specify all dependencies
perl-IO-stringy.spec | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
---
diff --git a/perl-IO-stringy.spec b/perl-IO-stringy.spec
index 5ca50ea..fd70f74 100644
--- a/perl-IO-stringy.spec
+++ b/perl-IO-stringy.spec
@@ -1,21 +1,28 @@
Summary: I/O on in-core objects like strings and arrays for Perl
Name: perl-IO-stringy
Version: 2.110
-Release: 26%{?dist}
+Release: 27%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/IO-stringy/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DS/DSKOLL/IO-stringy-%{version}.tar.gz
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(FileHandle)
BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Handle)
-BuildRequires: perl(lib)
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
BuildRequires: perl(Symbol)
+BuildRequires: perl(vars)
+# Tests:
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(lib)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
@@ -64,6 +71,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::WrapTie.3pm*
%changelog
+* Thu Jan 15 2015 Petr Pisar ppi...@redhat.com - 2.110-27
+- Specify all dependencies
+
* Tue Aug 26 2014 Jitka Plesnikova jples...@redhat.com - 2.110-26
- Perl 5.20 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-File-Which] Specify all dependencies
commit 98512bb983c0a188364f14763b8d77488a82ef42
Author: Petr Písař ppi...@redhat.com
Date: Thu Jan 15 08:14:27 2015 +0100
Specify all dependencies
perl-File-Which.spec | 21 +
1 files changed, 17 insertions(+), 4 deletions(-)
---
diff --git a/perl-File-Which.spec b/perl-File-Which.spec
index 30b77bc..6b1a741 100644
--- a/perl-File-Which.spec
+++ b/perl-File-Which.spec
@@ -1,21 +1,31 @@
Name: perl-File-Which
Version:1.09
-Release:18%{?dist}
+Release:19%{?dist}
Summary:Portable implementation of the 'which' utility
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/File-Which/
Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/File-Which-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+# Run-time:
%if !%{defined perl_bootstrap}
BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
-BuildRequires: perl(File::Spec)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Script)
+BuildRequires: perl(File::Spec) = 0.60
+BuildRequires: perl(Getopt::Std)
+BuildRequires: perl(vars)
+# Tests:
+BuildRequires: perl(Test::More) = 0.80
+BuildRequires: perl(Test::Script) = 1.05
%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(File::Spec) = 0.60
+
+# Remove under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Spec\\)$
%description
File::Which is a portable implementation (in Perl) of 'which', and can
@@ -51,6 +61,9 @@ make test
%changelog
+* Thu Jan 15 2015 Petr Pisar ppi...@redhat.com - 1.09-19
+- Specify all dependencies
+
* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 1.09-18
- Perl 5.20 re-rebuild of bootstrapped packages
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 Self Contained Change: Gnome Shell - New Notifications
On Wed, Jan 14, 2015 at 10:31:05AM -0500, Matthias Clasen wrote: On Wed, 2015-01-14 at 13:24 +, Peter Robinson wrote: On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote: = Proposed Self Contained Change: Gnome Shell - New Notifications = https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications Change owner(s): Florian Müllner fmuel...@redhat.com Redesign the way in which notifications are shown and kept available in gnome- shell. == Detailed Description == The message tray is one of the remaining weaker points of the original gnome- shell design. This change will replace it with a new implementation of notifications that avoids the problems of the current implementation. Is there a place where the detailed description is more detailed? A wiki page on gnome.org maybe listing the current problems and the new approach taken? I'm curious and would like to read more about this :) Allan Day, one of the gnome designers, did a pretty good overview in a couple of blog posts. http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/ Good point - I've added that link to the page now. Thank you both :) Pierre -- 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-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 997 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 216 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 87 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3434/pylint-1.3.1-1.el6,python-astroid-1.2.1-2.el6,python-logilab-common-0.62.1-2.el6 62 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4008/cross-binutils-2.23.51.0.3-1.el6.1 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4242/facter-1.6.18-8.el6 38 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4485/python-tornado-2.2.1-7.el6 30 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4669/libhtp-0.5.16-1.el6 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4766/mediawiki119-1.19.23-1.el6 20 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4884/mapserver-6.0.4-1.el6 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4918/dokuwiki-0-0.23.20140929b.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0151/docker-io-1.4.1-2.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0193/bsd-mailx-8.1.2-5.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0232/chicken-4.9.0.1-2.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0278/Django14-1.4.18-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0279/drupal7-context-3.6-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing Django14-1.4.18-1.el6 drupal7-context-3.6-1.el6 drupal7-rules-2.8-1.el6 perl-Digest-SHA3-0.24-1.el6 perl-REST-Client-272-1.el6 perl-URL-Encode-XS-0.03-1.el6 Details about builds: Django14-1.4.18-1.el6 (FEDORA-EPEL-2015-0278) A high-level Python Web framework Update Information: Fix for CVE-2015-0221 ChangeLog: * Wed Jan 14 2015 Matthias Runge mru...@redhat.com - 1.4.18-1 - fix CVE-2015-0221 (rhbz#1181949) * Tue Nov 11 2014 Matthias Runge mru...@redhat.com - 1.4.16-1 - update to 1.4.16 References: [ 1 ] Bug #1179679 - CVE-2015-0221 Django: denial of service attack against django.views.static.serve https://bugzilla.redhat.com/show_bug.cgi?id=1179679 drupal7-context-3.6-1.el6 (FEDORA-EPEL-2015-0279) Allows contextual conditions and reactions management Update Information: [SA-CONTRIB-2015-004 - Context - Open Redirect](https://www.drupal.org/node/2403351) ChangeLog: * Tue Jan 13 2015 Shawn Iwinski shawn.iwin...@gmail.com - 3.6-1 - Updated to 3.6 (DRUPAL-SA-CONTRIB-2015-004 / BZ #1180429) References: [ 1 ] Bug #1180429 - drupal7-context-3.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1180429 drupal7-rules-2.8-1.el6 (FEDORA-EPEL-2015-0271) React on events and conditionally evaluate actions Update Information: ## 7.x-2.8 * Issue #2013513 by EmanueleQuinto, das-peter: Action: type conversion for token * Issue #2324587 by fago: Rules might be triggered too early in the bootstrap * Issue #1810656 by pjcdawkins, moonray, GoddamnNoise, deggertsen, nielsdefeyter, xandeadx: Rules UI does not work with JQuery 1.7+ * Issue #2161847 by axel.rutz, maikeru, Mschudders | kenorb: Fixed Fatal error: Unsupported operand types in rules.module on line 227. * Issue #2190553 by das-peter, fago: Add locking to cache rebuild to avoid stampeding. * Issue #2014065 by heddn, fago | jhodgdon: UI very confusing for Data Comparison for Boolean values. * Issue #2103079 by axel.rutz, lootoo: Allow providing Rules metadata assertions for lists of entities. * Issue #2206545 by pjcdawkins, sanchiz: Replace field_info_fields() with field_info_field_map() for Drupal = 7.22. * Issue #1077700 by arithmetric: Add Drush integration for en/disabling rules. ChangeLog: * Tue Jan 13 2015 Shawn Iwinski shawn.iwin...@gmail.com - 2.8-1 - Updated to 2.8 (BZ #1180431) - Spec
[EPEL-devel] Fedora EPEL 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 997 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 451 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 216 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 70 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3784/mantis-1.2.17-3.el5 66 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3849/sblim-sfcb-1.3.8-2.el5 32 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4430/phpMyAdmin4-4.0.10.7-2.el5 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4917/dokuwiki-0-0.23.20140929b.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0074/nail-12.4-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0261/libsndfile-1.0.17-6.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0280/drupal7-context-3.6-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing drupal7-context-3.6-1.el5 drupal7-rules-2.8-1.el5 Details about builds: drupal7-context-3.6-1.el5 (FEDORA-EPEL-2015-0280) Allows contextual conditions and reactions management Update Information: [SA-CONTRIB-2015-004 - Context - Open Redirect](https://www.drupal.org/node/2403351) ChangeLog: * Tue Jan 13 2015 Shawn Iwinski shawn.iwin...@gmail.com - 3.6-1 - Updated to 3.6 (DRUPAL-SA-CONTRIB-2015-004 / BZ #1180429) References: [ 1 ] Bug #1180429 - drupal7-context-3.6 is available https://bugzilla.redhat.com/show_bug.cgi?id=1180429 drupal7-rules-2.8-1.el5 (FEDORA-EPEL-2015-0270) React on events and conditionally evaluate actions Update Information: ## 7.x-2.8 * Issue #2013513 by EmanueleQuinto, das-peter: Action: type conversion for token * Issue #2324587 by fago: Rules might be triggered too early in the bootstrap * Issue #1810656 by pjcdawkins, moonray, GoddamnNoise, deggertsen, nielsdefeyter, xandeadx: Rules UI does not work with JQuery 1.7+ * Issue #2161847 by axel.rutz, maikeru, Mschudders | kenorb: Fixed Fatal error: Unsupported operand types in rules.module on line 227. * Issue #2190553 by das-peter, fago: Add locking to cache rebuild to avoid stampeding. * Issue #2014065 by heddn, fago | jhodgdon: UI very confusing for Data Comparison for Boolean values. * Issue #2103079 by axel.rutz, lootoo: Allow providing Rules metadata assertions for lists of entities. * Issue #2206545 by pjcdawkins, sanchiz: Replace field_info_fields() with field_info_field_map() for Drupal = 7.22. * Issue #1077700 by arithmetric: Add Drush integration for en/disabling rules. ChangeLog: * Tue Jan 13 2015 Shawn Iwinski shawn.iwin...@gmail.com - 2.8-1 - Updated to 2.8 (BZ #1180431) - Spec cleanup - Removed RPM README b/c it only explained common Drupal workflow - %license usage * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Sun May 11 2014 Peter Borsa peter.bo...@gmail.com - 2.7-1 - Update to upstream 2.7 release for bug fixes - Upstream changelog for this release is available at https://drupal.org/node/2257127 References: [ 1 ] Bug #1180431 - drupal7-rules-2.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=1180431 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F22 System Wide Change: GCC5
On 14 January 2015 at 14:47, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote: On 14 January 2015 at 14:37, Jonathan Underwood jonathan.underw...@gmail.com wrote: Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler Is there any easy way for humble little upstream maintainers to test their code with the new compiler? You mean for the C89 - C11 default change, or for other changes in GCC 5? For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8). Perhaps it would be worth adding -std=gnu11 to the F22 default flags now and having a rebuild, before gcc5 lands, to start shaking out problems now? -- 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: Summary/Minutes from today's FESCo Meeting (2015-01-07)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 15:53 Dennis Gilmore napsal(a): On Wed, 14 Jan 2015 10:48:16 +0100 Vít Ondruch vondr...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a): On Tue, 13 Jan 2015 15:58:51 -0700 Kevin Fenzi ke...@scrye.com wrote: On Tue, 13 Jan 2015 15:50:06 -0700 Stephen John Smoogen smo...@gmail.com wrote: You forgot too many packages? There are 15842 packages in Fedora 21 and 16230 in Rawhide. That is a lot of packages that have to be rebuilt possibly multiple times due to FTBFS, multiple architectures, etc. 2.5 weeks is 25200 minutes. That means a mass rebuild is doing 0.6 packages a minute across 3 architectures. That is pretty darn fast The Fedora 21 mass rebuild took about 40 hours. ;) That's really not the reason for more time, its the fallout from that. When the mass rebuild is tagged in, sometimes there's things broken in the build root, those need humans to look at and fix. Then, there are all the packages that didn't build for whatever reason, those need humans to look at them and fix them up. The ones with broken deps need fixing, etc. So, while the mass rebuild itself is less than 2 days, it takes a while to stablize things after that. If we branched right after the mass rebuild we would have to then stablize both rawhide and f22. It's hard to say how much time we really need there... it depends on how much stuff got broken, how hard it is to fix and how much time maintainers have to fix things. right. in the past the building took around a week or a bit more, we have gotten that down. which is why I said we could drop the 4 weeks to 3. the time consuming part is the cleanup and fixing of issues. that needs people. If everything is perfect a week could well be sufficient. Ideally we want secondary arches to be done in the window as well. just to make sure that there is no fallout on them requiring a second rebuild. which could also happen on primary. we have had ABI issues etc in the past on all arches. Dennis What I would love to see is to leave out the packages which are build in side tag from mass rebuild. E.g. if I have side tag for Ruby, I rebuild every package in the side tag in two weeks before mass rebuild, I can hardly see any justification to build them once again (unless there lands gcc in the man time or something like this). So if you could exclude the packages which are already build in side tag from mass rebuild, it would help you with following merge and it would give me additional time to rebuild Ruby packages. Is something like this feasible? It really depends on a lot of things. like does gcc 5 land after you have started your builds? we can go about excluding things viaa few different means. but it all really depends on a bunch of currently unknown factors. Dennis Yes sure, depends on precise timing. It could be also solved by sidetag mini-mass rebuild ... Vít -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUto6kAAoJEAzgnueZF7h8CEYQAIVjaHhx6MxII4XaRLygGEoB iJqiH1D0b2FWmPwwAVMQ0Lzqibj19VbyLqm9+3FsxZcSs4X2uJ4oACKJlAAfv4Yc imK4oMQiB4iSnOpxk5IFQpDvm1yU+1yl6S7O3CA/R/sLOzXuM+nd7iqWwkVYYG2V 1vvilhLKcwm51wDJ+HlIvmIWFjR0yRy1Q8LFybdveKR3XlJHIPhAY+F8BHRM8SfI tcQ46lS/YOQYZa0VDxO3x6pY6759OOHEI02DQG7agU3KT15Vk6Cg4qw9HUXoJDvM IN35Wnr/nFKfwwxRYyQWYBNnfXnK1KM8UONNG+wQ/ieXTQet7/DWLWLzfr4Dccz0 FZ30tirxhX7UDinKgk6sYytxjxbQGOdb8NB3KO+/ddmFQN5FMnWhiEWQGitHt221 vHil3HV6FaUQ71c7hBWWQftOIDbRIUaz4oH3NCzw0tnilQzq2CWmVekYip0zQ+/u c1HoMUu1B+JddklZJ+a6Ad92eKEZiJCsZESJDxN71SNgWTpy1DOXPAiIUsFQBdJp X+Lr9SMc515UME1uvEBC7RO5ufC7cWoCq1KkCm1J5xViX3UR5KTcbMuVVdqPgegM 7taueRHcn2HX3+8LcC5ZTgTWaPX26IXwWZQ3y86Yd/oIqTwC6obJY4g9GcBodFdx sQxIvjcwJSBYsVSUBEbo =B71B -END 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: F22 Self Contained Change: Gnome Shell - New Notifications
Jaroslav Reznik píše v St 14. 01. 2015 v 13:00 +0100: = Proposed Self Contained Change: Gnome Shell - New Notifications = https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications Change owner(s): Florian Müllner fmuel...@redhat.com Redesign the way in which notifications are shown and kept available in gnome- shell. == Detailed Description == The message tray is one of the remaining weaker points of the original gnome- shell design. This change will replace it with a new implementation of notifications that avoids the problems of the current implementation. == Scope == * Proposal owners: ** Implement the new design ** Get the changes reviewed and merged upstream * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) == Contingency Plan == N/A (not a System Wide Change) What is still not very clear to me is if IM will still be somehow integrated into the Shell. I know I will be able to reply directly in the notification, but now if I miss the notification I can always go back to the contact in the message tray and see the conversation there. It's been a killer feature for me and many people around me and since Empathy itself is not very usable in GNOME 3 it'd be a pity to lose the integration. What about app icons for the notification area (Dropbox, Pidgin,...), where will they go? Jiri -- 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: F22 Self Contained Change: Wine to use mesa Direct3D
On Wed, Jan 14, 2015 at 5:16 PM, Michael Cronenworth m...@cchtml.com wrote: On 01/14/2015 06:28 AM, Jaroslav Reznik wrote: [snip] * Contingency mechanism: Revert and try to do in next release I don't see this one happening. The patch set is large. Upstream has rejected it. The affected user base is small. I'm unconvinced right now that it's worth the time and effort to maintain. I will cite Axel Davy who wrote this patchset (he sent this privately to me, you and other maintainer) 1) you can find a list of D3D11 only apps here: http://en.wikipedia.org/wiki/List_of_games_with_DirectX_11_support As you can see all d3d11 apps before 2012 had a d3d9 backend, and some d3d11 apps still had a d3d9 backend after that. A lot of new games released this year (most non-big production games) are still using d3d9. 2) After several discussions with wine devs, they said they would never consider putting us upstream, but that we could with - a lot of work and refactoring - compile our mesa code with the wine compiler and get a resulting d3d9.dll that we could distribute and give to users so that they can use it instead of wine dll. This scheme requires work, and we would like to let the possibility to have nine outside of wine. It's probably not going to happen in the next two years, but who knows... 3) wine nine code doesn't change a lot of wine code. Most of the ~20 patches are on our code. Our team take care of rebasing often under the last version of wine. 4) Do you play some games with wine ? Some games have severe issues, like stutter, etc. While on radeon cards, there is obvious gains, on nouveau there is too according to one of our nouveau tester. I think for fedora it would make sense to keep the mesa nine package, but I'm not 100% sure for the wine part. We are probably going to have PlayOnLinux support soon, which allows to install easily different version of wine, including non-official ones. Users wanting to use wine nine could go through that if it isn't shipped in the main wine package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -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
Re: Hundreds of bugzilla mails on one day
On Sat, Jan 10, 2015 at 12:43:46PM +0100, drago01 wrote: Yeah I just delete those mails now days. Its just spam F19 is EOL is not news that I need to get 1000 times. Right, clearly, that message is not really for _you_. It's for the people who reported the bug. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Invitation to DevConf.cz 2015
Hi, let me invite you to DevConf.cz 2015 [1] which will take place in Brno, Czech Republic on Feb 6-8. The third day of the conference will again be Fedora Day with a lot of Fedora-focused talks and discussions (and also with a lot of Fedora contributors around). You can find the list of Fedora-focused talks and workshops at [2]. There are, of course, much more talks on Fedora-related technologies, just check the schedule [3]. Jiri [1] http://devconf.cz/ [2] https://eischmann.wordpress.com/2015/01/13/fedora-at-devconf-cz-2015/ [3] http://devconf.cz/schedule -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to contact Michale Cromeworth
Halle, I have got a mail from a guy which ask me for co-maintainership of the inady-mt package. Unfortunately, I have got the below error report on the try to contact him via mail. So I would like to ask how I can contact him via an alternative mail contact. Best Regards: Jochen Schmitt - Forwarded message from Mail Delivery System mailer-dae...@kundenserver.de - Date: Sat, 03 Jan 2015 20:47:02 +0100 From: Mail Delivery System mailer-dae...@kundenserver.de To: joc...@herr-schmitt.de Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: m...@cchtml.com: no valid MX hosts found --- The header of the original message is following. --- Received: from omega.inet.herr-schmitt.de ([80.128.217.208]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0M0MwL-1Xp8iK3d5J-00uZ2Z for m...@cchtml.com; Sat, 03 Jan 2015 20:41:45 +0100 Received: by omega.inet.herr-schmitt.de (Postfix, from userid 1000) id 0D6CB60382; Sat, 3 Jan 2015 20:41:09 +0100 (CET) Date: Sat, 3 Jan 2015 20:41:09 +0100 From: Jochen Schmitt joc...@herr-schmitt.de To: Michael Cronenworth m...@cchtml.com Subject: Re: inadyn-mt help Message-ID: 20150103194108.gb1...@omega.inet.herr-schmitt.de References: 5499e0df.3030...@cchtml.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 5499e0df.3030...@cchtml.com User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:jTSMh79IfVn8wJZUna2WoNiPIhCAPcRhE/vWzPNUmm75tiuIMaV pfnQYi00z1YKcr6YXhDhQ4PcD3cEJQrR08EMILgoGBvVa8+rHWpvshkAqOX2CNuPqxvP0+R /anI9CkhfEh3LnJZoVZvrVfge/kaEzDiOdFmYrfmyy6CpiKLdYpQxeKBv1EJGeyEMM3Eq92 RLkoS3LjtCUSw5kMr1RmQ== X-UI-Out-Filterresults: notjunk:1; - End forwarded message - -- 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: Summary/Minutes from today's FESCo Meeting (2015-01-07)
- Original Message - On Wed, Jan 14, 2015 at 4:32 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote: The Fedora 21 mass rebuild took about 40 hours. ;) BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty. What are the goals of a mass rebuild now, given that we just had one before F21 Beta? This is actually that reason I liked how we constructed schedule last two releases - based on proposed changes, taking look what needs mass rebuild etc. And it could even end with no mass rebuild (or mass rebuild request can come on Jan-20 when the deadline for changes is). But I was alone who liked the old-new way and FESCo decided to set schedule the old-old way, I'm just the guy who puts it to the wiki :). You aren't alone. I'm still not convinced the strict time-based schedule will work, but most of FESCo wanted to give it a shot. Rather then be a stick in the mud, I went with don't be afraid to fail. Who knows, maybe it will work out. If it does, I think it's going to change some of the things people expect from Fedora in both good and bad ways. Good, delivered on time. Bad (maybe), delivered with less cutting-edge packages. I didn't mean it bad and yes - the result may lead to less cutting edge packages but on the other hand with predictable schedule, you know the next window is pretty soon (within 6 months). I'm just not convinced (planned) slips are that big deal (unless Phoronix forum complaints makes it a big deal;-). It can put more stress on folks, flexibility has some costs but... And we have that power to define what Fedora should be and I accepted it :). Jaroslav 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 -- 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 1:46 PM, Jonathan Underwood jonathan.underw...@gmail.com wrote: On 14 January 2015 at 14:47, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote: On 14 January 2015 at 14:37, Jonathan Underwood jonathan.underw...@gmail.com wrote: Only a partial answer to your question, but one fairly significant change (as you know) compared to the GCC upgrades for those releases is moving from C89 to C11 as the default C standard for the compiler Is there any easy way for humble little upstream maintainers to test their code with the new compiler? You mean for the C89 - C11 default change, or for other changes in GCC 5? For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8). Perhaps it would be worth adding -std=gnu11 to the F22 default flags now and having a rebuild, before gcc5 lands, to start shaking out problems now? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct +1 for this. Will help a lot to see how all the code base is behaving well on new standards -- 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote: I was thinking exactly that, mass rebuild is scheduled for Jan 30th according to the schedule [1] with branching 10 days or so later. That is only two weeks away. With statements like The release will happen probably in the first half of April when we're already suppose to be be in freeze from end of March I think this would be better landing in F-23 right after we branch F-22 off on Feb 10th. Ultimately the above gives us no room to move and a roll back is another mass rebuild which will only cause more delay! Again, how is that different from F9, F11, F13, F15, F17, F19? We are learning not to do the same mistakes all over again ☺ Now it could, I guess, be argued, that gcc has a long history of not having egregious failure modes we are learning from, and should be allowed to land later. OTOH there is also, IIRC, a history of having to do a second (full or partial) or even a third rebuild due to necessary gcc bug fixes, and landing the .0 version at the time we ship Beta is basically an explicit bet that there will be no such bug in .0, or we are slipping. 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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 Vincent Danen vda...@redhat.com changed: What|Removed |Added Whiteboard|impact=moderate,public=2014 |impact=moderate,public=2014 |1126,reported=20141201,sour |1126,reported=20141201,sour |ce=oss-sec,cvss2=4.3/AV:N/A |ce=oss-sec,cvss2=4.3/AV:N/A |C:M/Au:N/C:N/I:N/A:P,cwe=CW |C:M/Au:N/C:N/I:N/A:P,cwe=CW |E-617,rhel-6/libyaml=affect |E-617,rhel-6/libyaml=affect |ed,rhel-7/libyaml=affected, |ed,rhel-7/libyaml=affected, |rhscl-1/libyaml=defer,fedor |rhscl-1/libyaml=affected,fe |a-all/libyaml=affected,epel |dora-all/libyaml=affected,e |-all/libyaml=affected,mrg-1 |pel-all/libyaml=affected,mr |/libyaml=wontfix,mrg-2/liby |g-1/libyaml=wontfix,mrg-2/l |aml=wontfix,rhn_satellite_5 |ibyaml=wontfix,rhn_satellit |.3/libyaml=defer,rhn_satell |e_5.3/libyaml=defer,rhn_sat |ite_5.4/libyaml=defer,rhn_s |ellite_5.4/libyaml=defer,rh |atellite_5.5/libyaml=defer, |n_satellite_5.5/libyaml=def |rhn_satellite_5.6/libyaml=d |er,rhn_satellite_5.6/libyam |efer,rhn_satellite_6/libyam |l=defer,rhn_satellite_6/lib |l=defer,rhn_satellite_6/rub |yaml=defer,rhn_satellite_6/ |y193-libyaml=defer,rhui-2/l |ruby193-libyaml=defer,rhui- |ibyaml=affected,sam-1/libya |2/libyaml=affected,sam-1/li |ml=defer,cfme-5/mingw-libya |byaml=defer,cfme-5/mingw-li |ml=defer,cfme-5/ruby193-lib |byaml=defer,cfme-5/ruby193- |yaml=defer,openstack-4/liby |libyaml=defer,openstack-4/l |aml=new,openstack-5/libyaml |ibyaml=new,openstack-5/liby |=new,openshift-1/ruby193-li |aml=new,openshift-1/ruby193 |byaml=defer,fedora-all/perl |-libyaml=defer,fedora-all/p |-YAML-LibYAML=affected,epel |erl-YAML-LibYAML=affected,e |-6/perl-YAML-LibYAML=affect |pel-6/perl-YAML-LibYAML=aff |ed,epel-7/perl-YAML-LibYAML |ected,epel-7/perl-YAML-LibY |=affected,jboss/inktank-1.2 |AML=affected,jboss/inktank- |-libyaml=notaffected|1.2-libyaml=notaffected -- 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=VCIK6kIq3Ca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 Vincent Danen vda...@redhat.com changed: What|Removed |Added Depends On||1182257 Depends On||1182258 -- 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=m46hIHYLOda=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: GCC5
* Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release This is an invasive contingency mechanism, requiring retesting a lot of functionality; the contingency deadline for this (i.e. when we need to be comfortable that the revert will not be needed, should certainly be at the usual beta freeze at the latest, if not earlier. Invoking this contingency mechanism “before release”, say during the GA RC phase, would really not be feasible without a massive slip. 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
Re: How to contact Michale Cromeworth
On Wed, Jan 14, 2015 at 11:37:22AM -0600, Chris Adams wrote: Look at your results; you did not get that result in your dig. You got tahk you for your information, but the error message was created by a relay host located by my ISP. failure while trying to resolve cchtml.com/MX. It works for me from several locations on the Internet, so the problem would appear to be with your DNS. I have retried to send the message without any success. But I have tried to maske an DNS query directly agins the Google DNS and have find out, that the hostname, which you have specified as a mail excahnge is a CNAME. But this is not allowed for MX records. MX records have to point to A reords instead of CNAME records. Best Regards: Jochen Schmitt Skript gestartet auf Mi 14 Jan 2015 18:42:28 CET ; DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 @8.8.8.8 mail.cchtml.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 61595 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mail.cchtml.com. IN A ;; ANSWER SECTION: mail.cchtml.com.1720IN CNAME cchtml.com. cchtml.com. 100 IN A 71.86.124.216 ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mi Jan 14 18:42:28 CET 2015 ;; MSG SIZE rcvd: 74 Skript beendet: Mi 14 Jan 2015 18:42:28 CET -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jan 2015 12:34:22 -0500 (EST) Miloslav Trmač m...@redhat.com wrote: On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@yahoo.co.in wrote: On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. That’s not how, to my knowledge, ssh keys are usually deployed; there is one private key per user (or, for the paranoid, one private key per client machine / user’s home directory), not one private key per the server one is connecting to. And creating a key does not really solve the problem: how do the administrators get the key so that they can connect? I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication ☺ ). Mirek except that will not work when you do not have access to a console and only have ssh access Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtq2ZAAoJEH7ltONmPFDRzqsQAI59frCILBqB6zUWedryB5yp 378Wakimicon8HAHuUEqZb334246k4U3/d4FPaspGiqKtqSf2w1Y2nixFNdxGqor mH5oyoToddasptFS2okRGh8IaPnZiBNXPVZ6emKrjeL+ln2DMsfSCPA9NN15AO/I KllQ4j3YhDVm4qmL9a25pcNcPjUlIi1C6amR19eOkG7+788+7pMQ0yzcDcn3ow3O F8u+j5bwPdPfwL/sEe6ZyGNgfHJEx+wtYCQjXMCQp3VkYHMkqHwkjR/q63l5TMtb 5SIFwzP6wmAaLvU3Nz4jEu8GWNQwm86cYIiEj1cRSN9muKffoIuJopKM1fchbveh VuPH+FjZhvWShvN5tddaunOkGN2WtFJp8rgnWeVtT/09H+PbkzT3pigZt2OElnD/ 49DWLork4uLOSuVPQvqMjMMsUbg1SLv9tB6AA45gtkEgkg+X256MdHUVK49HfOXS ogCfgx7CfCPCd6cOEHx+exK3Xg9JlxqboIklR1pFyDLcyQUDkXaV0wrXq23hhrci kLUpZ7yYTZwvHgKrQfQ99ael5alAHyCb/ZvWyAZyAoMeoJQKZoyCvNI5BWsVoGPQ Ir1Z/nEGz2T/RbbpVrLvH5VzwkWY0hZyCEUwa+Wrh/LfyFBjxN6YM+YTdoPSI4Et cifUPiu3gJqlrMnOJvyt =nj7u -END 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: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 12:51:24PM -0500, Miloslav Trmač wrote: * Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release This is an invasive contingency mechanism, requiring retesting a lot of functionality; the contingency deadline for this (i.e. when we need It is a contingency mechanism which we never invoked in the past. If there are bugs on the GCC side, they are just fixed. And the GCC GA release time isn't that much special time, it is time when the compiler is declared officially GA, but bugs are fixed before and after that time under completely the same policy, only regression bugfixes and documentation bugfixes are allowed starting with this Saturday onwards (last two months allowed general bugfixes too, so not only for things that regressed from earlier GCC releases). So from the Fedora POV, starting this Saturday only regression bugfixes will be allowed from now on until all Fedoras that will ship GCC 5 go EOL. Jakub -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 12:34:22 -0500 (EST) Miloslav Trmač m...@redhat.com wrote: On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@yahoo.co.in wrote: I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication ☺ ). Mirek except that will not work when you do not have access to a console and only have ssh access At this point/in this sub-discussion, I personally very much don’t care. Let’s collect the requirements first. 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
Re: How to contact Michale Cromeworth
On 01/14/2015 11:52 AM, Jochen Schmitt wrote: I have retried to send the message without any success. But I have tried to maske an DNS query directly agins the Google DNS and have find out, that the hostname, which you have specified as a mail excahnge is a CNAME. But this is not allowed for MX records. MX records have to point to A reords instead of CNAME records. Yes, my registrar over-simplified the mail record interface. I have now fixed that. Regardless, this is the first time I've had an issue with receiving e-mail. -- 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: How to contact Michale Cromeworth
Am 14.01.2015 um 18:26 schrieb Jochen Schmitt: It very important, that your domain provides any MX records because this is absolutly require to send mails to your domain bullshit - fix your mailserver there is no need for a MX record read the SMTP RFC the only reason when you need a MX is if your inbound mailserver is on a different machine then the A-record for the domain [harry@srv-rhsoft:~]$ nslookup cchtml.com Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: cchtml.com Address: 71.86.124.216 [harry@srv-rhsoft:~]$ telnet 71.86.124.216 25 Trying 71.86.124.216... Connected to 71.86.124.216. Escape character is '^]'. 220 cchtml.com ESMTP Postfix EHLO harry 250-cchtml.com 250-PIPELINING 250-SIZE 2048 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIM 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@yahoo.co.in wrote: Hi, On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. Sorry, but what is the point of this operation, wrt auth with keys issue ? It'll help if you could add your details to the ether pad, for later reference. here - https://www.piratepad.ca/p/ssh-remoterootloigin The intention may be not, then I'll call it poor execution/planning and still oppose this move *at this time* unless there is proof we address the usability problem first. We are still in the proposal state, not execution yet. IMO, before we request the respective upstream developers to provide the needed functionality, we need to state and agree on the usability requirements. That'll be useful in the evaluation of the feature by the FES committee too. Otherwise it's a chicken-and-egg problem. It *is* a chicken-egg issue to some degree. I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to contact Michale Cromeworth
On Wed, Jan 14, 2015 at 10:47:07AM -0600, Michael Cronenworth wrote: Hi, I'm here. I'm not sure why your e-mail failed. Could you try it again? When I call dig with your domain, I have to recornized, thatyour domain doesn't provides any MX records. I have tried to contact the homstmaster of your domain without any response. It very important, that your domain provides any MX records because this is absolutly require to send mails to your domain. Best Regards: Jochen Schmitt Skript gestartet auf Mi 14 Jan 2015 18:16:05 CET ; DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 cchtml.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 62795 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cchtml.com.IN MX ;; Query time: 6 msec ;; SERVER: 192.168.178.2#53(192.168.178.2) ;; WHEN: Mi Jan 14 18:16:05 CET 2015 ;; MSG SIZE rcvd: 39 Skript beendet: Mi 14 Jan 2015 18:16:05 CET -- 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: How to contact Michale Cromeworth
On 01/14/2015 11:26 AM, Jochen Schmitt wrote: When I call dig with your domain, I have to recornized, thatyour domain doesn't provides any MX records. I have tried to contact the homstmaster of your domain without any response. It very important, that your domain provides any MX records because this is absolutly require to send mails to your domain. My domain does list an MX record. I'm afraid there is a problem with your local DNS. $ dig @8.8.8.8 MX cchtml.com ; DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 @8.8.8.8 MX cchtml.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 30951 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;cchtml.com.IN MX ;; ANSWER SECTION: cchtml.com. 1799IN MX 10 mail.cchtml.com. ;; Query time: 128 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jan 14 11:27:06 CST 2015 ;; MSG SIZE rcvd: 60 -- 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: How to contact Michale Cromeworth
Once upon a time, Jochen Schmitt joc...@herr-schmitt.de said: When I call dig with your domain, I have to recornized, thatyour domain doesn't provides any MX records. I have tried to contact the homstmaster of your domain without any response. Look at your results; you did not get that result in your dig. You got a status: SERVFAIL, which means your recursive server had some type of failure while trying to resolve cchtml.com/MX. It works for me from several locations on the Internet, so the problem would appear to be with your DNS. -- Chris Adams li...@cmadams.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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wednesday, 14 January 2015 10:44 PM, Simo Sorce wrote: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. Sorry, but what is the point of this operation, wrt auth with keys issue ? Well, it can be used it to export to other machines. It'll require you to login as non-root user first. Being able to authenticate as root right after installation would be the requirement for me. Right. But how would you inject a key for that? If you must have only 'root' account in your set-up, remote root access could be enabled by default. Feature page lists ... Omission of such user account should prompt user if they wish to enable remote 'root' login, and set the parameter appropriately. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to contact Michale Cromeworth
On 01/14/2015 10:42 AM, Jochen Schmitt wrote: I have got a mail from a guy which ask me for co-maintainership of the inady-mt package. Unfortunately, I have got the below error report on the try to contact him via mail. So I would like to ask how I can contact him via an alternative mail contact. Best Regards: Jochen Schmitt Hi, I'm here. I'm not sure why your e-mail failed. Could you try it again? -- 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 628655] perl segfaults when joining a thread and using perl-Tk
https://bugzilla.redhat.com/show_bug.cgi?id=628655 Andreas Bierfert andreas.bierf...@lowlatency.de changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |NEXTRELEASE Flags|needinfo?(andreas.bierfert@ | |lowlatency.de) | Last Closed|2012-08-07 15:26:53 |2015-01-14 12:31:55 --- Comment #11 from Andreas Bierfert andreas.bierf...@lowlatency.de --- Yes. Thanks for the reminder... -- 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=lE4ugCJnfQa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Hi, On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. It'll help if you could add your details to the ether pad, for later reference. here - https://www.piratepad.ca/p/ssh-remoterootloigin The intention may be not, then I'll call it poor execution/planning and still oppose this move *at this time* unless there is proof we address the usability problem first. We are still in the proposal state, not execution yet. IMO, before we request the respective upstream developers to provide the needed functionality, we need to state and agree on the usability requirements. That'll be useful in the evaluation of the feature by the FES committee too. Otherwise it's a chicken-and-egg problem. I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 05:05:50PM +, David Howells wrote: Jaroslav Reznik jrez...@redhat.com wrote: Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. Does cross-gcc need to switch simultaneously? Some packages are built with that, I believe. It is a different package, so it can switch independently. Jakub -- 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: F22 System Wide Change: GCC5
Jaroslav Reznik jrez...@redhat.com wrote: Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. Does cross-gcc need to switch simultaneously? Some packages are built with that, I believe. David -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Wed, 14 Jan 2015 16:54:09 + (UTC) P J P pj.pan...@yahoo.co.in wrote: On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote: Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. Except you have no mechanism to inject a key at installation time, Sure. Could you please elaborate how would you like this key to be injected into the 'root' account? Feature page does have a listed workflow change: Anaconda installer OR maybe OpenSSH package needs to create initial set of authentication keys for 'root' user. That’s not how, to my knowledge, ssh keys are usually deployed; there is one private key per user (or, for the paranoid, one private key per client machine / user’s home directory), not one private key per the server one is connecting to. And creating a key does not really solve the problem: how do the administrators get the key so that they can connect? I'd request all(those who are opposing) too describe their requirements in the etherpad page above. Being able to authenticate as root right after installation would be the requirement for me. Let’s be precise here; “able to authenticate as root” is an implementation detail; the underlying requirement is something else. “Able to set up IPA”? “Able to run administrative commands in shell?” (e.g. we could just, as a part of firstboot, open a root shell without any authentication ☺ ). 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
Re: How to contact Michale Cromeworth
On Wed, 14 Jan 2015 11:27:51 -0600 Michael Cronenworth m...@cchtml.com wrote: On 01/14/2015 11:26 AM, Jochen Schmitt wrote: When I call dig with your domain, I have to recornized, thatyour domain doesn't provides any MX records. I have tried to contact the homstmaster of your domain without any response. It very important, that your domain provides any MX records because this is absolutly require to send mails to your domain. My domain does list an MX record. I'm afraid there is a problem with your local DNS. ...snip... In addition, just to be clear, a MX record is not actually required. If there's no MX record, a A record should be used. (If any). If there's no MX or A, then there's a problem. :) kevin pgpQGEoB98CTW.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to contact Michale Cromeworth
Once upon a time, Jochen Schmitt joc...@herr-schmitt.de said: I have retried to send the message without any success. But I have tried to maske an DNS query directly agins the Google DNS and have find out, that the hostname, which you have specified as a mail excahnge is a CNAME. But this is not allowed for MX records. MX records have to point to A reords instead of CNAME records. MX-CNAME is against RFCs but in common enough real-world usage that anything that doesn't handle it is generally considered broken. However, that isn't the case for cchtml.com; the MX points to cchtml.com, not mail.cchtml.com, and cchtml.com has an A record. -- Chris Adams li...@cmadams.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
Self Introduction and Review Request: Sinny Kumari
Hi List, I just pushed a package for review at https://bugzilla.redhat.com/show_bug.cgi?id=1182261 and would like some review on it. I work at Red Hat India and contribute to KDE in my free time. I blog at http://sinny.io/ and also give talks at local FOSS events (the last one was on basic RPM packaging at Fedora 21 release party in Bangalore). Please review my package and let me know if any changes are needed. I will be more than happy to work on it. Thanks Sinny Kumari -- 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: Remove gcc, gcc-c++ and make from minimal build root
Hi, I don't think the original question was all that great. If we were to script the change to add the BRs, it would take time but it would mostly be a one-time cost. Reducing buildroot time creation, network bandwidth, and storage savings is a reduction over each new buildroot instance creation over a long period of time. IMO it isn't that clear there is a significant win due to the caching mock is doing. mock creates the minimal buildroot every once in a while, then keeps reusing it for builds. So, with a hot cache the build goes like this: (1) unpack cached minimal buildroot (2) rpm install build deps (3) do the build Taking gcc out of the minimal buildroot is an obvious win for packages not using gcc. But for packages using gcc it just moves gcc installation from step (1) to step (2), and I expect this will slow down the builds due to unpacking the cached buildroot being faster than doing an rpm install. So effectively we are going to trade faster non-gcc builds for slower gcc builds. Which still might be a net win at the end, but just from looking at the proposal it isn't obvious whenever it actually is or not. cheers, Gerd -- 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 1180476] perl-Devel-PPPort-3.27 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1180476 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Devel-PPPort-3.26 is |perl-Devel-PPPort-3.27 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 3.27 Current version/release in Fedora Rawhide: 3.25-2.fc22 URL: http://search.cpan.org/dist/Devel-PPPort/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=KwQPn3xgNca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1181998] New: perl-Pod-Simple-3.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1181998 Bug ID: 1181998 Summary: perl-Pod-Simple-3.29 is available Product: Fedora Version: rawhide Component: perl-Pod-Simple Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org Latest upstream release: 3.29 Current version/release in Fedora Rawhide: 3.28-310.fc22 URL: http://search.cpan.org/dist/Pod-Simple/ 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 Soon this service will be implemented by a new system: https://release-monitoring.org/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=BmgFcRwruva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Summary/Minutes from today's FESCo Meeting (2015-01-07)
- Original Message - On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote: The Fedora 21 mass rebuild took about 40 hours. ;) BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty. What are the goals of a mass rebuild now, given that we just had one before F21 Beta? This is actually that reason I liked how we constructed schedule last two releases - based on proposed changes, taking look what needs mass rebuild etc. And it could even end with no mass rebuild (or mass rebuild request can come on Jan-20 when the deadline for changes is). But I was alone who liked the old-new way and FESCo decided to set schedule the old-old way, I'm just the guy who puts it to the wiki :). 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
Re: F22 Self Contained Change: Gnome Shell - New Notifications
On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote: = Proposed Self Contained Change: Gnome Shell - New Notifications = https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications Change owner(s): Florian Müllner fmuel...@redhat.com Redesign the way in which notifications are shown and kept available in gnome- shell. == Detailed Description == The message tray is one of the remaining weaker points of the original gnome- shell design. This change will replace it with a new implementation of notifications that avoids the problems of the current implementation. Is there a place where the detailed description is more detailed? A wiki page on gnome.org maybe listing the current problems and the new approach taken? I'm curious and would like to read more about this :) Thanks, Pierre -- 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: F22 Self Contained Change: Gnome Shell - New Notifications
On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote: = Proposed Self Contained Change: Gnome Shell - New Notifications = https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications Change owner(s): Florian Müllner fmuel...@redhat.com Redesign the way in which notifications are shown and kept available in gnome- shell. == Detailed Description == The message tray is one of the remaining weaker points of the original gnome- shell design. This change will replace it with a new implementation of notifications that avoids the problems of the current implementation. Is there a place where the detailed description is more detailed? A wiki page on gnome.org maybe listing the current problems and the new approach taken? I'm curious and would like to read more about this :) Allan Day, one of the gnome designers, did a pretty good overview in a couple of blog posts. http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/ Peter -- 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: Remove gcc, gcc-c++ and make from minimal build root
On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: Summary/Minutes from today's FESCo Meeting (2015-01-07)
On Wed, 14 Jan 2015 01:53:02 -0600 Yaakov Selkowitz yselk...@redhat.com wrote: On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote: The Fedora 21 mass rebuild took about 40 hours. ;) BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty. What are the goals of a mass rebuild now, given that we just had one before F21 Beta? We don't yet know. Changes are still being submitted and discussed and reviewed by FESCo. Until the change submission deadline + 1 week we will not have a full list of changes and be able to tell if a mass rebuild is needed and for what. There are of course already some changes that call for one... like enabling hardened_build for all packages and gcc 5.0. kevin pgp3PVu7aP2WI.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: GCC5
On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 14, 2015 at 12:53:18PM +0100, Jaroslav Reznik wrote: = Proposed System Wide Change: GCC5 = https://fedoraproject.org/wiki/Changes/GCC5 Change owner(s): Jakub Jelínek ja...@redhat.com Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. == Detailed Description == GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April. We are working on scratch gcc rpms and will perform a test mass rebuild. Other distributions have performed test mass rebuilds already. == Scope == All packages should be rebuilt with the new gcc once it hits f22. * Proposal owners: Build gcc in f22, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html → 404 (also on the wiki) BTW: is there a copr or another place to get gcc5 without compiling from source? -- 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: F22 System Wide Change: GCC5
Dne 14.1.2015 v 12:53 Jaroslav Reznik napsal(a): = Proposed System Wide Change: GCC5 = https://fedoraproject.org/wiki/Changes/GCC5 Change owner(s): Jakub Jelínek ja...@redhat.com Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. == Detailed Description == GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April. We are working on scratch gcc rpms and will perform a test mass rebuild. Other distributions have performed test mass rebuilds already. == Scope == All packages should be rebuilt with the new gcc once it hits f22. * Proposal owners: Build gcc in f22, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. Ah, few days/weeks. Now I really can't see how this will fit into schedule. Vít * Release engineering: Organize a mass rebuild * Policies and guidelines: No policies need to be changed == Contingency Plan == If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in 12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past, but worst case we can mass rebuild everything with older gcc again. * Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No ___ 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: Summary/Minutes from today's FESCo Meeting (2015-01-07)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a): On Tue, 13 Jan 2015 15:58:51 -0700 Kevin Fenzi ke...@scrye.com wrote: On Tue, 13 Jan 2015 15:50:06 -0700 Stephen John Smoogen smo...@gmail.com wrote: You forgot too many packages? There are 15842 packages in Fedora 21 and 16230 in Rawhide. That is a lot of packages that have to be rebuilt possibly multiple times due to FTBFS, multiple architectures, etc. 2.5 weeks is 25200 minutes. That means a mass rebuild is doing 0.6 packages a minute across 3 architectures. That is pretty darn fast The Fedora 21 mass rebuild took about 40 hours. ;) That's really not the reason for more time, its the fallout from that. When the mass rebuild is tagged in, sometimes there's things broken in the build root, those need humans to look at and fix. Then, there are all the packages that didn't build for whatever reason, those need humans to look at them and fix them up. The ones with broken deps need fixing, etc. So, while the mass rebuild itself is less than 2 days, it takes a while to stablize things after that. If we branched right after the mass rebuild we would have to then stablize both rawhide and f22. It's hard to say how much time we really need there... it depends on how much stuff got broken, how hard it is to fix and how much time maintainers have to fix things. right. in the past the building took around a week or a bit more, we have gotten that down. which is why I said we could drop the 4 weeks to 3. the time consuming part is the cleanup and fixing of issues. that needs people. If everything is perfect a week could well be sufficient. Ideally we want secondary arches to be done in the window as well. just to make sure that there is no fallout on them requiring a second rebuild. which could also happen on primary. we have had ABI issues etc in the past on all arches. Dennis What I would love to see is to leave out the packages which are build in side tag from mass rebuild. E.g. if I have side tag for Ruby, I rebuild every package in the side tag in two weeks before mass rebuild, I can hardly see any justification to build them once again (unless there lands gcc in the man time or something like this). So if you could exclude the packages which are already build in side tag from mass rebuild, it would help you with following merge and it would give me additional time to rebuild Ruby packages. Is something like this feasible? Vít -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUtjtgAAoJEAzgnueZF7h8FNAP/R+qxtq1XEJcK1MakXamiVhy DDjjgOEgBaHchx2lVRKQbslq8K1Uk7X/gryLu/YD88z+4umoAyXFoD/6RTHQmJct 6YEFndsKToJqtVuQ2Mmx8PxjtruVvaZs37DOZ8bw+KP2QSC4CvWaOmGB4SN2xcSv IPPAz1YHSV7TGnQWXDemVP7OHEfhkiPRkI+B4MXUGkwj3bgZOoFZFxOFCOfSs7nQ 2zFe9aCPktDsIBr99aO0BzICiCKsJRzZmxh+rplTR6uvvO2LzPBeEeiUY/nQh/Dh Rp4Yl0xuM9wYXzG/ewzcqJ/1++Wz/EibsVhO3ZgrzLcajjHd0Ie421MB31YqW1EF /Z06rTr9iaCudAkmiMO4jPvXr692XO6vHrTQL6THMbA0nK4SiI/lnu2Kkn5qXf5M O26KgYZ8aXSgJiIcW/W9rPO2zq5FgR1EGJPdcuP7LNobfIUX+58tkjtnuhYOWuKB 6H3923VOHJws39PRIrd0Upoh+ZJkxobotsYUCgMplOJR+XKY8/7DaHr+J8eKNKOn PeVsCiZR1E73wQqCTf01Aj5GaY/0Fumwb76cQW4tbvfVuFJD6qY3gr6PTSC2pkFo LccTorT+zrAu0EI9tIKgb0MZ1ih+tQ7x8QZvm1rrxxh7RH6A+5qNlxEvla7S7WsJ +YeUbwHbvjZlLFUHJUOu =p/dY -END 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: GUI applications writing garbage to stdout/stderr
On Wed, Jan 14, 2015 at 12:22 PM, Marcel Oliver m.oli...@jacobs-university.de wrote: Some of the main culprints for me are nemo, evince, and okular; The applications that you mention are parts of specific desktop environments. The messages that you see are not meant to be visible to the user, unless something breaks; in such a case, such programs would pop up a warning/info/error window, notifying the user about the problem. Messages about missing themes or services that belong to the parent DE, but which are not essential to the core functionality of the programs, do not (usually) fall under that category, given that they don't stop the programs from working and in most cases they are logged somewhere (e.g. in .xsession-errors or journald). On the other hand, if every message that was not meant for the user were suppressed, it would be very difficult to troubleshoot such a program, should an actual bug come along, because you would need a different build to get useful output in the console or a logging service. So, your options are to learn to live with the output of these programs, redirect it to the null device, start them from their launchers or via the command prompt (Alt+F2). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Test-CPAN-Meta-JSON-0.16.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-CPAN-Meta-JSON: 1d6f3ff573e8b8b3daf89f677b7404bf Test-CPAN-Meta-JSON-0.16.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Content of change announcements Was:F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades
- Original Message - On Tue, Jan 13, 2015 at 3:27 PM, Miloslav Trmač m...@redhat.com wrote: Jaroslav, there is a lot more information on the actual wiki page. Like the fact that this is only for particular opt-in new installs and that yum/dnf/RPM can only operate in read-only mode on such installs. Could you resend this with the entirety of the text? It might lead to fewer questions. This is being sent to devel-announce, so should not overwhelm people who are not interested. That’s why it includes the basic description (to let you decide whether you are interested) and the Scope section (to let you check whether this will, through the “Other developers” bullet point, place demands on you). It is somewhat important that everybody reads these parts; wouldn’t including the full page drown these parts out? No. People can stop reading wherever they'd like. Omitting relevant information from the actual Change page makes it rather difficult to _discuss_ the Change on the devel list, which is the main reason they are sent. Doing the discussion on the wiki is terrible. I would much rather be able to quote the sections via email. Actually it was Mitr who asked me first to add more parts into email announcement but then we talked about it - and I think current way is a good compromise - to give overview of change but not to overload people with two many details. Also it really depends on how change is filled, usually detailed description and scope are that parts really needed to do the decision/get overview of changes in detail. With more aim on contingency plans, I can add contingency plan section. By these three, you have covered 95% of content of standard changes. Let's try it. You can easily copy excerpt from wiki to the email and start that discussion, wiki for discussion is not needed (and really very bad place to do so). Btw. it's my opinion, if more people would like to see the whole change page announced, I'll do it. Or any other ideas in the way how announcement is structured... Jaroslav 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-CGI-Fast] Specify run-time dependency versions
commit f74b3fbf7b5b34b64e102cce588f4b657da61688
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 14 12:46:36 2015 +0100
Specify run-time dependency versions
perl-CGI-Fast.spec | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
---
diff --git a/perl-CGI-Fast.spec b/perl-CGI-Fast.spec
index f702f9a..6997bce 100644
--- a/perl-CGI-Fast.spec
+++ b/perl-CGI-Fast.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Fast
Version:2.05
-Release:1%{?dist}
+Release:2%{?dist}
Summary:CGI Interface for Fast CGI
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,17 +11,19 @@ Source0:
http://www.cpan.org/authors/id/L/LE/LEEJO/CGI-Fast-%{version}.ta
Patch0: CGI-Fast-2.04-Make-Test-Deep-tests-optional.patch
BuildArch: noarch
BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
BuildRequires: perl(CGI) = 4.00
%if 0%(perl -e 'print $] = 5.019')
BuildRequires: perl(deprecate)
%endif
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(FCGI) = 0.67
BuildRequires: perl(File::Spec) = 0.82
BuildRequires: perl(if)
BuildRequires: perl(strict)
-BuildRequires: perl(Test::More) = 0.98
BuildRequires: perl(vars)
+# Tests:
+BuildRequires: perl(Test::More) = 0.98
BuildRequires: perl(warnings)
# Optional tests:
%if !%{defined perl_bootstrap}
@@ -31,13 +33,13 @@ Requires: perl(:MODULE_COMPAT_%(eval `perl
-V:version`; echo $version))
%if 0%(perl -e 'print $] = 5.019')
Requires: perl(deprecate)
%endif
+Requires: perl(CGI) = 4.00
Requires: perl(FCGI) = 0.67
Requires: perl(File::Spec) = 0.82
-
# perl-CGI-Fast was split from perl-CGI
Conflicts: perl-CGI 4.00
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((FCGI|File::Spec)\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((CGI|FCGI|File::Spec)\\)$
%description
CGI::Fast is a subclass of the CGI object created by CGI.pm. It is
@@ -69,6 +71,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Jan 14 2015 Petr Pisar ppi...@redhat.com - 2.05-2
+- Specify run-time dependency versions
+
* Mon Dec 15 2014 Jitka Plesnikova jples...@redhat.com - 2.05-1
- 2.05 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F22 System Wide Change: GCC5
= Proposed System Wide Change: GCC5 = https://fedoraproject.org/wiki/Changes/GCC5 Change owner(s): Jakub Jelínek ja...@redhat.com Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. == Detailed Description == GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April. We are working on scratch gcc rpms and will perform a test mass rebuild. Other distributions have performed test mass rebuilds already. == Scope == All packages should be rebuilt with the new gcc once it hits f22. * Proposal owners: Build gcc in f22, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. * Release engineering: Organize a mass rebuild * Policies and guidelines: No policies need to be changed == Contingency Plan == If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in 12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past, but worst case we can mass rebuild everything with older gcc again. * Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No ___ 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
