Re: EPEL Clang package doesn't work on Amazon Linux
On Mon, Apr 21, 2014 at 11:40 AM, Tyler Brock tyler.br...@gmail.com wrote: Hey Dave, hope you had a nice weekend. Any update on the rpms? Repos for x86 32-bit and 64-bit can be found at: http://daveisfera.fedorapeople.org/yum/llvm-3.4/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Agenda for Env-and-Stacks WG meeting (2014-04-22)
WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon) Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode. == Topic == Comments to topics from lists: * Allow to delete builds/coprs from playground? https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-April/000381.html * Playground dnf plugin - prototype and signing of packages https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-April/000376.html * open floor See you, Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On 04/16/2014 06:46 PM, Bill Nottingham wrote: I understand the pull vs push distinction ... I'm just not clear why pull would ever be a model you'd want to use. (vs something like a local cockpit agent.) Isn't remote Windows event logging pull-only (unless you somehow gate it to syslog)? So it would be consistent. Back in the old days, there was a lot of loathing going around for Windows event logging. People loved syslog, but really hated the Windows counterpart. The pull model was criticized as well, but I'm not sure if it was really pulling stuff or the bad interaction with other design considerations (like the need for DLLs with parsers for the log blobs). Does anybody know what the current Windows experience is like, especially related to the pull model? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
- Original Message - From: Liam l...@fightingcrane.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, April 21, 2014 10:10:13 PM Subject: Re: F21 System Wide Change: Workstation: Disable firewall On Apr 21, 2014 4:32 AM, drago01 drag...@gmail.com wrote: On Mon, Apr 21, 2014 at 3:49 AM, Liam l...@fightingcrane.com wrote: Sent from mYphone On Apr 20, 2014 7:02 PM, drago01 drag...@gmail.com wrote: On Mon, Apr 21, 2014 at 12:39 AM, Reindl Harald h.rei...@thelounge.net wrote: There have been other suggestions in this thread that are helpful like the network zones thing (but we still have too many zones) or enabling services should make them work i.e just enable the firewall rules. which make sense Oh finally you seem to understand what this is all about (a few mails ago this was supposed to be strongly prohibited ...) Now please goolge for Psychological Acceptability and Security you will find tons of scientific papers (read them) explaining about why it is wrong to silently break stuff or ask yes / no question or arguing with this is not a blackbox the user should learn nonsense. There is difference between a software developer, a sysadmin and a user that simply wants to share his music with his family. The latter should not have to learn about computer security to do it, while for the former it does not matter that much as you said because they ought to know what to do or where to get that information from. The later isn't the target for Workstation, I don't believe. Not the *primary* target but still one see the Other users section in the PRD. -- That's fine, but that's not who we need to be optimizing the experience for. We need to be focusing on our primary target. After that others can be considered. A developer can handle this if it is presented well, but we shouldn't let secondary users harm, at all, the experience of the primary user. If we do, then this reorganization isn't working, IMHO. I think this is a misunderstanding of who a developer might be and why they choose a system. Those of my friends and acquaintances, who are developers and who over the years have decided to switch their development laptops from Linux to predominantly MacOS X, has not done so because they had things they wanted to do that was 'impossible' to do with Linux or that they thought they could not figure out how to do with linux. Instead they moved because they got tired of spending time trying to make their system 'work'. This is in no way limited to dealing with the challenges of a firewall, but if we want to attract developers or any kind of user to our system we need to make it usable without needing daily google searches to figure out how you can do something and make parts of your system work. As a sidenote, there has been a lot of discussions on this an other Fedora lists over the last few Months where people have loudly come out against what they see as infringements on the Freedom part of the four F's. Having seen this thread I am disappointed to see that nobody has come out in defense of the Friends part of the four F's, because the language and tone used by some people on this thread has been beyond pale, accusing the other participants in the thread of stupidity, incompetence and general maliciousness. If this doesn't change maybe the time has come for a board ticket to change that F from Friends to Flames? Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Cockpit Management Console
- Original Message - On Mon, Apr 21, 2014 at 1:38 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2014 11:29 AM, Kevin Fenzi wrote: ...snip... Special Requests: Cockpit would like to request an additional 2-4 weeks on the Fedora 21 schedule to ensure completion of the core functionality. So, you want to push final release out to november? Or can you expand on what you mean by 'on the Fedora 21 schedule' ? When I spoke with the Cockpit developers, there was concern that they would not quite be feature-complete by the currently-targeted Alpha date. In order to have a little breathing room, it was decided that we should request additional time there. Perhaps we could shave a week off off each of the Beta and Final deadlines to accommodate an additional two weeks on Alpha? (Of course, that carries risks on test coverage as well...) The purpose of requesting the additional time was to alert FESCo that there is a risk of delaying the Alpha release for this Change (if approved) and communicating that up front. Instead of delaying the whole release even more ... would it make sense to simply ask for this feature to have an exception to let it land in beta instead of alpha? OTOH this would kind of limit testing time for it. I think this definitely better way - not being as strict regarding deadlines for Cockpit and get some test coverage during later Test Day. Cutting one week from Alpha/Beta cycle is doable but only when it's really, really needed. We did this voodoo magic a few times to avoid Christmas etc. and believe me - that note in the Task Juggler source for schedule - never, ever, do this - is just truth. It pains. So the question is - is this Change that Change, delaying the WHOLE Fedora 21 schedule so much desirable? But I still prefer being more flexible with deadlines + scope cutting. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Ruby193 in SCL
On 04/20/2014 06:46 PM, Kevin Kofler wrote: Lukas Zapletal wrote: This is a great change that actually allows other teams that heavily relies on Fedoras to put their software on hold for two Fedora releases. And that's a good thing how? Stale software relying on old compatibility libraries is exactly the opposite of what we want (fast innovation and an integrated system). Kevin Kofler If you have to support the same software even on old versions on older releases, then it's a good thing. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop * you nor i can say for sure avahi never ever get a critical security update See above. * you nor i can be sure that there is not another network-service is running * even if it is not running by intention it may be running by mistake as default * so after you installed a new system avahi is running and the firewall down See above. * how do you genius install the updates without a network and to *not* have to consider what is safe and what you have to stop after a fresh install before you can plug your machine to the network for install security relevant updates a firewall has to be enabled by default Again you 1) assume that we enable random services by default and the firewall is the only thing that protects freshly installed systems 2) that given the user options that do not work and force him to learn about computer networks to do basic tasks is how things should work both are false. Sure disabling the firewall is not the only way to solve 2) but the silently make things not work i.e the status quo or ask a user questions that he does not understand are no solutions. There have been other suggestions in this thread that are helpful like the network zones thing (but we still have too many zones) or enabling services should make them work i.e just enable the firewall rules. honestly it's good that you are out of this discussion because you seem to not have you clue about security nor understand the implications of who knows hat he is doing and why the one who don't need sane defaults No the reason is simply that talking to you is very annoying .. you resort to baseless attacks (like the this one) and strawmans. 1: http://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop -- 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: [GSoC 2014] Welcome to our GSoC students -- Perfect 10 !
On 04/21/2014 10:46 PM, Haïkel Guémar wrote: Hi, Google just published the list of the accepted GSoC proposals: http://www.google-melange.com/gsoc/projects/list/google/gsoc2014 We -the GSoC SIG- had a hard time to trim the list of proposals down to 10 slots and we're very pleased to see that all of them got accepted ! Thanks to my co-administrators: Buddhike (bckukera), Kushal (kushaldas), the mentors: Emily, Kaushal (kshlm), Mikolaj (mizdebsk),Pierre-Yves (pingou), Ratnadeep (rtntpro), Stanislas (sochotny), Vit Ondruch who did a great job reviewing and selecting the projects. It was a pleasure to work with you guys, this is YOUR success :o) And of course, congratulations to the students which will work with us within fedoraproject.org during that time (and hopefully, after ;) ) Selected projects: * isitfedoraruby: improvements to isitfedoraruby a RoR application used by the Ruby SIG to track the packaging of Ruby gems * shumgrepper: a web frontend to summershum a project that collects checksum of every file present in every packages bringing many possibilities to check integrity, duplication of sources files etc. * infrastructure to the FreeMedia: FreeMedia has provided fedora media to individuals who can't afford buying or downloading Fedora, this project aims to automate a currently manual process. * Fedora College: bringing a virtual classroom for new Fedora contributors * Implementation of logs browser and audio/video conferencing in Waarta: Waarta is an irc web client written in node.js providing an enhanced user experience. * UI for bugspad: bugspad is a rewrite of Bugzilla with speed and performance in mind. * Mock improvements: enhancements to speed up mock and make it more flexible * Backend improvements to GlitterGallery: Glitter Gallery is a tool used by the Fedora Design Team, it's kinda github for designers :) * UX improvements to GlitterGallery * GlusterFS-iostat: since GlusterFS wasn't a mentoring organization this year and this proposal was rock-solid, we shared a slot with them. It will be an useful addition to the storage offer within Fedora. Ladies, gentlemen, it's time to roll up your sleeves and get some work done ;) best regards, H. Thank you guys! Congratulations to everyone involved :) -- FAS : axilleas GPG : 0xABF99BE5 Blog: http://axilleas.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 22, 2014 at 11:23 AM, Thomas Woerner twoer...@redhat.com wrote: On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: I know and I didn't claim otherwise (I even cited the same link in my 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - From: Thomas Woerner twoer...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014 11:23:46 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop Thank you for digging that ticket up Thomas. I think that ticket mentions something maybe a bit overlooked in this thread so far, Real world security. I recommend everyone following this thread to watch this video of a talk by Russ Doty from Red Hat at this years DevConf in Brno. His talk is about real world security, especially in the context of enterprise computing, but the issues he articulate forms the underlaying challenges of this thread too. I think if everyone here see this talk we could hopefully move this thread into a more constructive format. Christian -- 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: The Forgotten F: A Tale of Fedora's Foundations
On Mon, 2014-04-21 at 08:36 -0400, Stephen Gallagher wrote: The language in this Foundation is sometimes dangerously unclear. For example, it pretty much explicitly forbids the use of non-free components in the creation of Fedora (sorry, folks: you can't use Photoshop to create your package icon!). At the same time, we regularly allow the packaging of software that can interoperate with non-free software; we allow Pidgin and other IM clients to talk to Google and AOL, we allow email clients to connect to Microsoft Exchange, etc. The real problem is that every time a question comes up against the Freedom Foundation, Fedora contributors diverge into two armed camps: the hard-liners who believe that Fedora should never under any circumstances work (interoperate) with proprietary services and the the folks who believe that such a hard-line approach is a path to irrelevance. There is also a third group, somewhere in between, who believe that's ok to ship Free Software that connects and interops with proprietary services (gtalk, aws, etc), but it's not ok to ship proprietary software, metadata about proprietary software or advertise proprietary services through our main UI tools. You should also keep in mind that Functional is very subjective and I don't see how it can walk through such debates. People will still align the Functional foundation to align with their point of view ;) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
- Original Message - From: Nikos Roussos comzer...@fedoraproject.org There is also a third group, somewhere in between, who believe that's ok to ship Free Software that connects and interops with proprietary services (gtalk, aws, etc), but it's not ok to ship proprietary software, metadata about proprietary software or advertise proprietary services through our main UI tools. You should also keep in mind that Functional is very subjective and I don't see how it can walk through such debates. People will still align the Functional foundation to align with their point of view ;) So this group believes it is ok to ship an open source twitter client in Fedora as long as the client doesn't know how to connect to twitter or has any metadata mentioning it can be used to connect to twitter? ;) Christian -- 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: The Forgotten F: A Tale of Fedora's Foundations
On Tue, 2014-04-22 at 06:46 -0400, Christian Schaller wrote: - Original Message - From: Nikos Roussos comzer...@fedoraproject.org There is also a third group, somewhere in between, who believe that's ok to ship Free Software that connects and interops with proprietary services (gtalk, aws, etc), but it's not ok to ship proprietary software, metadata about proprietary software or advertise proprietary services through our main UI tools. You should also keep in mind that Functional is very subjective and I don't see how it can walk through such debates. People will still align the Functional foundation to align with their point of view ;) So this group believes it is ok to ship an open source twitter client in Fedora as long as the client doesn't know how to connect to twitter or has any metadata mentioning it can be used to connect to twitter? ;) With metadata about proprietary software I mean metadata used to *install* proprietary software. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 05:43 AM, Christian Schaller wrote: - Original Message - From: Thomas Woerner twoer...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014 11:23:46 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop Thank you for digging that ticket up Thomas. I think that ticket mentions something maybe a bit overlooked in this thread so far, Real world security. I recommend everyone following this thread to watch this video of a talk by Russ Doty from Red Hat at this years DevConf in Brno. His talk is about real world security, especially in the context of enterprise computing, but the issues he articulate forms the underlaying challenges of this thread too. I think if everyone here see this talk we could hopefully move this thread into a more constructive format. Since you missed the link: https://www.youtube.com/watch?v=jYGgVUYjXQ8 I too recommend that everyone gives it a look. It is very insightful and helpful in understanding what people really do once this gets out the door. Major points: 1) People turn off security features that they can't easily figure out how to tune. 2) Hackers are a significantly smaller security threat than managers (I need it to work now, we can secure it later!) 3) Recovery and auditing are more important than prevention. Those are some of the basics, but it *really* is worth taking the 40 minutes to watch the whole thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWVRUACgkQeiVVYja6o6NLtACfchzhexg2gcT1q3oQLZXPsLmm IjUAn0lnph51CGi7Xvmpf+nNBaqBRtSW =VZ8i -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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2014 06:23 PM, Przemek Klosowski wrote: On 04/21/2014 01:27 PM, Stephen Gallagher wrote: On 04/21/2014 01:07 PM, Haïkel Guémar wrote: We should think on how we could improve collaboration with third-party repos, fedmsg/copr might be part of the technical solution. How about a Fedora Partnership Program ? We could open up at a certain extent our infrastructure and collaborate with software editors to make sure that their products have some support in Fedora. I love this idea and I think we should probably start another thread on it when this one starts to die down, assuming that the general sense is that the community wants to improve our third-party/non-FOSS relationships. The choices we make are determined by the possibilities we are presented with. While we all agree that it's neither possible nor desirable to prevent installation of whatever tools the end user wants, the Freedom absolutists would like to put up a barrier against non-Free software, or at least want Fedora to abstain from helping. I personally prefer that choice to be given to the users, who should be able to indicate what they want on their systems. Now, these abstract choices take shape during software installation, so it seems to me that they should be entered as user preferences in the software installer to shape the results of software search. In other words, ask the user what they want to see, and then let them choose from the results. We've discussed several such values-based choices: - the license conditions (Free vs. encumbered vs. non-Free and commercial) - tolerance for gritty old commandline tools vs. polished apps only - choice between full functionality vs. small size and/or speed I think they all can be seen as user preferences in the software installer discovery process, making the installer central to how the resulting system is put together. This is consistent with how Droid and iOS make software 'stores' and installation a central point of interaction for configuring their systems. I'd like to summon Máirín Duffy into this conversation here, if she's willing. She's done a fair amount of research into exactly how many and what kind of questions are reasonable to ask a user in startup before scaring them off or confusing them. If this is something we're interested in following up with, it would be good to have the interaction designers involved. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWVeoACgkQeiVVYja6o6P39ACfSzLZxvhNpsSeA/oJFBQ2+KQ7 HGIAoLGOCgXXKMeuzYZRytAhcfKOp5w+ =f0mB -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: The Forgotten F: A Tale of Fedora's Foundations
On 04/22/2014 11:43 AM, Stephen Gallagher wrote: I'd like to summon Máirín Duffy into this conversation here, if she's willing. She's done a fair amount of research into exactly how many and what kind of questions are reasonable to ask a user in startup before scaring them off or confusing them. If this is something we're interested in following up with, it would be good to have the interaction designers involved. Is it safe to assume that research is backup by public usability tests? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [GSoC 2014] Welcome to our GSoC students -- Perfect 10 !
Yay! Spamming the list for once, but indeed - congrats to everyone! This time around, we should plan a meeting on irc sometime :-) On Apr 22, 2014 1:16 AM, Haïkel Guémar hgue...@fedoraproject.org wrote: Hi, Google just published the list of the accepted GSoC proposals: http://www.google-melange.com/gsoc/projects/list/google/gsoc2014 We -the GSoC SIG- had a hard time to trim the list of proposals down to 10 slots and we're very pleased to see that all of them got accepted ! Thanks to my co-administrators: Buddhike (bckukera), Kushal (kushaldas), the mentors: Emily, Kaushal (kshlm), Mikolaj (mizdebsk),Pierre-Yves (pingou), Ratnadeep (rtntpro), Stanislas (sochotny), Vit Ondruch who did a great job reviewing and selecting the projects. It was a pleasure to work with you guys, this is YOUR success :o) And of course, congratulations to the students which will work with us within fedoraproject.org during that time (and hopefully, after ;) ) Selected projects: * isitfedoraruby: improvements to isitfedoraruby a RoR application used by the Ruby SIG to track the packaging of Ruby gems * shumgrepper: a web frontend to summershum a project that collects checksum of every file present in every packages bringing many possibilities to check integrity, duplication of sources files etc. * infrastructure to the FreeMedia: FreeMedia has provided fedora media to individuals who can't afford buying or downloading Fedora, this project aims to automate a currently manual process. * Fedora College: bringing a virtual classroom for new Fedora contributors * Implementation of logs browser and audio/video conferencing in Waarta: Waarta is an irc web client written in node.js providing an enhanced user experience. * UI for bugspad: bugspad is a rewrite of Bugzilla with speed and performance in mind. * Mock improvements: enhancements to speed up mock and make it more flexible * Backend improvements to GlitterGallery: Glitter Gallery is a tool used by the Fedora Design Team, it's kinda github for designers :) * UX improvements to GlitterGallery * GlusterFS-iostat: since GlusterFS wasn't a mentoring organization this year and this proposal was rock-solid, we shared a slot with them. It will be an useful addition to the storage offer within Fedora. Ladies, gentlemen, it's time to roll up your sleeves and get some work done ;) best regards, H. -- 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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2014 05:31 PM, Stephen John Smoogen wrote: On 21 April 2014 11:19, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2014 01:08 PM, Bruno Wolff III wrote: On Mon, Apr 21, 2014 at 12:37:57 -0400, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: Does Fedora need to be that gateway OS? Maybe Ubuntu would be a better intermediate step? If Fedora isn't that gateway OS, why are we bothering? What makes it likely that any user would switch to us if they've entered the FOSS community via Ubuntu? (Don't get me wrong, this is a question we also need to answer, but I don't think it's wise of us to be recommending that Ubuntu handles gathering our new users for us.) It is an interesting question... why are we bothering? When people bother because they need to be THE gateway.. they are setting themselves for a lifetime of disappointment. That ship sails completely with little to no control. Maybe I should have phrased that differently. If we aren't trying to be that gateway, why are we bothering?. Without users, we can't grow our contributor pool. Without growing our contributor pool, we won't innovate as fast as other distributions, which in turn will further reduce our user and contributor base. I have found that if you are going to bother.. do it because it is making something better for you, for something you care about. That is I'm certainly not trying to rule that out (it's why I'm here after all). But it's not *enough* (in my opinion). stuff you can control and not items left to the fact that people choose to use what everyone else uses or by the fact its name sounds exotic or they like Orange over Blue. Of course there will always be people who make frivolous choices, and I'm not expecting to cater to them. You're right, that way lies disappointment. I do think we *can* improve our appeal, though. We just need to agree that this is a real target and go after it. Maybe some real ideas now instead of me just spewing platitudes? :) I've argued for quite some time that the path to code contributions would be best paved by making Fedora the first Linux distribution with a fully-integrated development environment. Take something like Eclipse and Red Hat Developer Toolset and build our Microsoft Visual Studio with a public API. With a basic recompile of RHDTS for Fedora, we can carry backwards-compatible support for three years, making it actually possible to do development for Fedora (and as a bonus, stuff that will also run on RHEL with RHDTS). I'd also love to see such an environment designed from the beginning to integrate well with OpenShift/Docker for Continuous Deployment. If we can produce a cohesive project that's comparable to Visual Studio or Apple's Xcode, we can make a strong argument for application developers to want to use Fedora as their development platform. Once we've hooked them with Fedora as an operating environment, some at least will also turn into development contributors as well. Ambitious? Probably. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWWC4ACgkQeiVVYja6o6MYgwCdFjNIrgcLZyOg1QyMZo6eg+15 gy0AoKvNYi7MYdrv0r+oI4LHZdyqfZLk =mZ3X -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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 07:40 AM, Jóhann B. Guðmundsson wrote: On 04/22/2014 11:43 AM, Stephen Gallagher wrote: I'd like to summon Máirín Duffy into this conversation here, if she's willing. She's done a fair amount of research into exactly how many and what kind of questions are reasonable to ask a user in startup before scaring them off or confusing them. If this is something we're interested in following up with, it would be good to have the interaction designers involved. Is it safe to assume that research is backup by public usability tests? When I invoke Máirín, I usually find it safe to make that assumption, but I'll let her speak for herself on the matter. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWWMEACgkQeiVVYja6o6PjnwCfRjegU7gX+A0Ii2+6eY7b9S9v UW4An0/9eV3qHzr19e0ylkLXvru7HEsZ =Ct+r -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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - From: Stephen Gallagher sgall...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014 1:40:05 PM Subject: Re: F21 System Wide Change: Workstation: Disable firewall -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 05:43 AM, Christian Schaller wrote: - Original Message - From: Thomas Woerner twoer...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014 11:23:46 AM Subject: Re: F21 System Wide Change: Workstation: Disable firewall On 04/21/2014 12:22 AM, drago01 wrote: On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: * there are network services enabled by default Again that's a bug and a viloation of the guidelines. Which services are you talking about? Please file bugs. * avahi is one of them You keep listing this as an example but avahi is not only installed and enabled by default but also allowed configured to work in the default firewall setup since F18 [1] ... So the current default firewall won't protect you against avahi flaws. This has been added only because of a FESCo decision: https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop Thank you for digging that ticket up Thomas. I think that ticket mentions something maybe a bit overlooked in this thread so far, Real world security. I recommend everyone following this thread to watch this video of a talk by Russ Doty from Red Hat at this years DevConf in Brno. His talk is about real world security, especially in the context of enterprise computing, but the issues he articulate forms the underlaying challenges of this thread too. I think if everyone here see this talk we could hopefully move this thread into a more constructive format. Since you missed the link: https://www.youtube.com/watch?v=jYGgVUYjXQ8 oops, thanks for that, I had the link ready to be pasted, but forgot to actually paste it :) Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20 Puppet update and SELinux policy
Hello, we are rolling out update of Puppet to 3.4.3 in Fedora 20 and Rawhide that adds one important change. We have found that puppet master was running unconfined, therefore the Puppet SELinux policy was not effective in Fedoras. The puppet package update fixes one little issue (missing runtime dependency) and corrects startup wrappers for systemd which puts Puppet Master into the correct SELinux domain puppetmaster_t. Since this has some security impact, we have decided to backport this change into Fedora 20 too. https://admin.fedoraproject.org/updates/puppet-3.4.3-3.fc20 Until now, puppet master was running unconfined (this is a regression), the update might need relabelling of the system (/etc/puppet, /var/lib/puppet) or checking out audit.log. Please help me with testing this update: yum --enablerepo=updates-testing update selinux-policy puppet puppet-server Thanks for help. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
Hi folks, On 04/22/2014 07:40 AM, Jóhann B. Guðmundsson wrote: Is it safe to assume that research is backup by public usability tests? On 04/22/2014 07:55 AM, Stephen Gallagher wrote: When I invoke Máirín, I usually find it safe to make that assumption, but I'll let her speak for herself on the matter. We did tests at Red Hat's office in Boston for RHEL 7. Those tests were with experienced system administrators looking to install server targets. They were not looking to install workstations, and as they stated their typical install process is automated and involves kickstart; they do not perform attended installs frequently at all. The summary of results from that test are available here: https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00011.html (posted to https://fedoraproject.org/wiki/Anaconda/UX_Redesign) I'm fairly certain based on experience (if you want to question *that*, we can talk about that in more depth too) that this class of users: - Do not care about the license conditions. They trust that Red Hat has handled that appropriately for them. - Probably do have a preference for command line vs polished apps, but do not care about this when installing a server. (Generally the experienced admins favor command line whereas junior admins or admins that also work on Windows machines prefer polished apps) - Do care about full functionality vs. small size / speed. They make this selection interactively using the software selection / comps screen in the new anaconda; for day-to-day this is controlled via the selection of particular kickstarts or recipes in their automated provisioning systems. We also did tests at DevConf.cz last year. My OPW intern Stephanie Manuel designed the test with me and Jiri Eischmann, Jaroslav Reznik, and Filip Kosik among others, did an excellent job running the tests on-site. I have the videos but I do not have release forms for the testers who took that test, so I don't think I can post them - but it is a lot of data and I'm not sure how useful it would be to post or where I could post it. These users for the most part had a technical background, but were more workstation-oriented in installation although they only interacted with the installer itself. Filip provided the data and the analysis of the results on that test: https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00018.html All of the results from the tests were collated into one long issue list here: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Usability_Test_Suggestions Some of the choices Przemek suggested don't make sense depending on the context. E.g., full functionality vs. small size / speed I think has a different meaning depending on whether you have a workstation target (which, either way, will include X) or a server target (which might not necessarily include X.) Same with command line vs polished apps. Everything in our repos is free, so putting the choice in the installer seems off to me. Our policy (which is complex and obviously driven by things stronger than the UX) generally leaves it to users post-install to add encumbered software. I don't actually see the advantage to the user in changing that. PackageKit's UI used to have filters I think some were based on license. Maybe the GNOME software devs would be interested in having some kind of selection for the type of software offered to you. Similarly to how some Android app stores work - e.g. show me only free apps, or you can show me paid apps too. So to back this up, a lot - what install target are we talking about, exactly? And what type of users are we talking about? My guidance as an IXD would be completely different depending on these things. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On Tue, 2014-04-22 at 06:34 +0200, Lennart Poettering wrote: On Wed, 16.04.14 12:46, Bill Nottingham (nott...@splat.cc) wrote: Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) said: On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. What's the future of gatewayd if this becomes more widely used? gatewayd works in pull mode. Here I'm proposing a push model, where the client (i.e. machine generating the logs) pushes logs to the server at the time of its own chosing. gatewayd is probably better for some use cases, this for others. I understand the pull vs push distinction ... I'm just not clear why pull would ever be a model you'd want to use. (vs something like a local cockpit agent.) Pull is the only model that scales, since the centralized log infrastructure can schedule when it pulls from where and thus do this according to available resources. THe push model is prone to logging bursts overwhelming log servers if you scale your network up. I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. Except that the server may not need direct access to the clients (in NATted LANs for examples), so sometimes push is all you can count on, make sure you can think how to properly rate limit, give feedback to clients if necessary. A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. 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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 08:55 AM, Máirín Duffy wrote: Hi folks, On 04/22/2014 07:40 AM, Jóhann B. Guðmundsson wrote: Is it safe to assume that research is backup by public usability tests? On 04/22/2014 07:55 AM, Stephen Gallagher wrote: When I invoke Máirín, I usually find it safe to make that assumption, but I'll let her speak for herself on the matter. We did tests at Red Hat's office in Boston for RHEL 7. Those tests were with experienced system administrators looking to install server targets. They were not looking to install workstations, and as they stated their typical install process is automated and involves kickstart; they do not perform attended installs frequently at all. The summary of results from that test are available here: https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00011.html (posted to https://fedoraproject.org/wiki/Anaconda/UX_Redesign) I'm fairly certain based on experience (if you want to question *that*, we can talk about that in more depth too) that this class of users: - Do not care about the license conditions. They trust that Red Hat has handled that appropriately for them. - Probably do have a preference for command line vs polished apps, but do not care about this when installing a server. (Generally the experienced admins favor command line whereas junior admins or admins that also work on Windows machines prefer polished apps) - Do care about full functionality vs. small size / speed. They make this selection interactively using the software selection / comps screen in the new anaconda; for day-to-day this is controlled via the selection of particular kickstarts or recipes in their automated provisioning systems. We also did tests at DevConf.cz last year. My OPW intern Stephanie Manuel designed the test with me and Jiri Eischmann, Jaroslav Reznik, and Filip Kosik among others, did an excellent job running the tests on-site. I have the videos but I do not have release forms for the testers who took that test, so I don't think I can post them - but it is a lot of data and I'm not sure how useful it would be to post or where I could post it. These users for the most part had a technical background, but were more workstation-oriented in installation although they only interacted with the installer itself. Filip provided the data and the analysis of the results on that test: https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00018.html All of the results from the tests were collated into one long issue list here: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Usability_Test_Suggestions Some of the choices Przemek suggested don't make sense depending on the context. E.g., full functionality vs. small size / speed I think has a different meaning depending on whether you have a workstation target (which, either way, will include X) or a server target (which might not necessarily include X.) Same with command line vs polished apps. Everything in our repos is free, so putting the choice in the installer seems off to me. Our policy (which is complex and obviously driven by things stronger than the UX) generally leaves it to users post-install to add encumbered software. I don't actually see the advantage to the user in changing that. PackageKit's UI used to have filters I think some were based on license. Maybe the GNOME software devs would be interested in having some kind of selection for the type of software offered to you. Similarly to how some Android app stores work - e.g. show me only free apps, or you can show me paid apps too. So to back this up, a lot - what install target are we talking about, exactly? And what type of users are we talking about? My guidance as an IXD would be completely different depending on these things. Thanks for the detailed response, Máirín! What I think we're looking for is answers to some of the questions that keep coming up in Fedora Workstation and GNOME. Specifically, there's a contingent of people (myself included) that feels that our existing policy introduces arbitrary difficulty on the part of our users when trying to install software (free or non-free) that is not part of our standard repositories. There are many specific cases here, from the obvious apps/appstores like Chome, Steam, etc. to the less obvious: browser-based web apps. And then of course there are things like the proposed Playground repository and COPR, as well as the potential for other third-party repositories. So one of the key questions here is whether the current policy on essentially hiding (protecting?) the user from these external software sources is truly in keeping with our Foundations, Mission and general project health. If it is not, how do we address the problem in a way that doesn't sacrifice our core commitment to FOSS? One suggestion that came up was to allow people
Re: The Forgotten F: A Tale of Fedora's Foundations
- Original Message - Le lundi 21 avril 2014 à 11:17 -0400, Stephen Gallagher a écrit : I'm trying to assert with this proposal that the best way for us to advance free and open source software is to continue shipping only open-source software, while making it easy for users to *transition*. By setting a hard-line on our users and saying You can only use FOSS, unless you jump through these fourteen poorly-documented hoops, we're discouraging our user-base (and ultimately, contributor base) from growing. I simply cannot see any way that we are satisfying our Mission by discouraging users from operating the way that they want to. Please excuse the reductio ad absurdum ( and my display of Lati^W Wikipedia ) But if we look at the current way, I think a high percentage of people want to run windows and download movies for free out on the internet, mostly because non technical people are motivated to do that. So if we really want to satisfy them, we should do that. The fact we don't prove that we will always do something that discourage people from operating how they want ( ie, without caring about license, copyright, etc ) for a variety of reasons. And so that we have to balance the various factors. Well, one thing (and I'll repeat myself) - we tell our users you can't play mp3, you can play your movies in MPEG 4 format unless you do something, we can't tell you about. But we do not offer any option and we have that option available and it really goes very well with our values, our mission - free culture. And we should go beyond free software. Is there any reason why the installer does not work for free content? Connect it (and partner) for example with Jamendo. Show Blender foundation movies, many smaller clips around the internet, free shows... Yes, it's not as huge as non free culture. But last few years it'd becoming trend. We will never grow to the world dominance with our values but we can cover our-values-friendly communities and I really think there's a still pretty huge user base we can grow to. Or if we want world dominance, and seems like quite a big movement within project, maybe let's not pretend being something even our contributors do not believe. We can be second Ubuntu... 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: F21 System Wide Change: Workstation: Disable firewall
On Apr 22, 2014 3:05 AM, Christian Schaller cscha...@redhat.com wrote: ... As a sidenote, there has been a lot of discussions on this an other Fedora lists over the last few Months where people have loudly come out against what they see as infringements on the Freedom part of the four F's. Having seen this thread I am disappointed to see that nobody has come out in defense of the Friends part of the four F's, because the language and tone used by some people on this thread has been beyond pale, accusing the other participants in the thread of stupidity, incompetence and general maliciousness. If this doesn't change maybe the time has come for a board ticket to change that F from Friends to Flames? Christian A good point. There's a relative scarcity of discussion on the 'Friends' foundation. In one sense, a relationship moves from acquaintance to friendship when familiarity crosses a threshold. You expect an acquaintance to follow social niceties, but you trust a friend to be honest even at the expense of politeness. Of course we still need a code of conduct, and occasional friendly reminders to cool down and take a walk for a while, but friends should mostly be able to look past choice of language to evaluate message and good intentions. Equating disagreement with antipathy is more detrimental than vitriolic disagreement. We need the 'Friends' foundation to remind us that even in the hottest of flamewars, everyone has good intentions. Sometimes strong language is just a device for making a point. Even the wildest of idiom isn't inherently intended to convey personal disrespect. We need a reminder, especially with contentious issues, not to ignore valid points because they were delivered poorly and not to overvalue perspectives that were shared more politely. --Pete -- 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: The Forgotten F: A Tale of Fedora's Foundations
2014-04-22 16:10 GMT+02:00 Máirín Duffy du...@fedoraproject.org: To be honest, I'm fairly uncomfortable discussing this without Fedora Legal weighing in. I don't see any problem with re-visiting the decisions made along this path, but I also am pretty confident the folks who decided things had to be this way are really smart and had good reasons. ~m Well, we may end up lawyered by Legal, but I think it's good we try to realign ourselves and clear up few misunderstandings. H. -- 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: The Forgotten F: A Tale of Fedora's Foundations
On 04/22/2014 09:13 AM, Stephen Gallagher wrote: So one of the key questions here is whether the current policy on essentially hiding (protecting?) the user from these external software sources is truly in keeping with our Foundations, Mission and general project health. To be honest, I'm fairly uncomfortable discussing this without Fedora Legal weighing in. I don't see any problem with re-visiting the decisions made along this path, but I also am pretty confident the folks who decided things had to be this way are really smart and had good reasons. ~m -- 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: The Forgotten F: A Tale of Fedora's Foundations
Hi, On 04/22/2014 10:14 AM, H. Guémar wrote: Well, we may end up lawyered by Legal, but I think it's good we try to realign ourselves and clear up few misunderstandings. How do you propose we do that? ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Smaller Cloud Image Footprint
On Tue, Apr 22, 2014 at 06:01:31AM +0200, Lennart Poettering wrote: Note that it should be relatively straight-forward to implement a generator (even in shell...) that generates native systemd-networkd configuration snippets from ifcfg files at runtime (or upgrade-time), similar to how we convert fstab or crypttab to systemd units. With that in place it a smooth transition from the old networking scripts to networkd should be possible. That said, there are some things ifcfg supports (ISDN, IPX, ...) that we'll never support in networkd, hence we couldn't claim 100% compat with such a scheme. Yeah, I think that's fine -- the generator should log a warning (or error, depending on the option, I guess) and possibly the suggestion to use NetworkManager or legacy initscripts. https://bugzilla.redhat.com/show_bug.cgi?id=1090090 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140422 changes
Broken deps for i386 -- [MegaMek] MegaMek-0.30.11-13.fc20.i686 requires java-gcj-compat MegaMek-0.30.11-13.fc20.i686 requires java-gcj-compat [PyKDE] PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) = 0:10.0 [apper] apper-0.8.1-4.fc21.i686 requires libpackagekit-qt2.so.6 [aunit] aunit-2013-2.fc21.i686 requires libgnat-4.8.so [aws] aws-3.1.0-4.fc21.i686 requires libgnat-4.8.so aws-3.1.0-4.fc21.i686 requires libgnarl-4.8.so aws-devel-3.1.0-4.fc21.i686 requires libgnat-4.8.so aws-devel-3.1.0-4.fc21.i686 requires libgnarl-4.8.so [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ 0:4.9.0 [csound] csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [derelict] derelict-tcod-3-26.201410303git9570453.fc21.i686 requires tcod derelict-tcod-devel-3-26.201410303git9570453.fc21.i686 requires tcod [devtodo2] devtodo2-2.1-8.20120711git8dee6.fc21.i686 requires libgo.so.4 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [fedora-dockerfiles] fedora-dockerfiles-0-0.5.git122ef5d.fc21.noarch requires docker-io [florist] florist-2011-11.fc20.i686 requires libgnat-4.8.so florist-2011-11.fc20.i686 requires libgnarl-4.8.so [fmt-ptrn] fmt-ptrn-java-1.3.22-1.fc21.i686 requires libgcj.so.14 [frysk] frysk-0.4-39.fc19.i686 requires libgcj.so.14 [gammaray] gammaray-2.0.0-1.fc21.i686 requires qt(x86-32) = 1:4.8.5 gammaray-2.0.0-1.fc21.i686 requires libvtkjsoncpp.so.1 gammaray-2.0.0-1.fc21.i686 requires libvtkTestingIOSQL.so.1 gammaray-2.0.0-1.fc21.i686 requires libvtkTestingGenericBridge.so.1 gammaray-2.0.0-1.fc21.i686 requires libvtkRenderingHybridOpenGL.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gdb-heap] gdb-heap-0.5-15.fc21.i686 requires glibc(x86-32) = 0:2.18.90 [ghc-hjsmin] ghc-hjsmin-0.1.4.4-4.fc21.i686 requires libHSlanguage-javascript-0.5.8-ghc7.6.3.so ghc-hjsmin-0.1.4.4-4.fc21.i686 requires ghc(language-javascript-0.5.8-b540064e3f1e16c718a444f5c00bad3b) ghc-hjsmin-devel-0.1.4.4-4.fc21.i686 requires ghc-devel(language-javascript-0.5.8-b540064e3f1e16c718a444f5c00bad3b) [ghdl] ghdl-0.31-2.fc21.i686 requires libgnat-4.8.so [gnatcoll] gnatcoll-2013-4.fc21.i686 requires libgnat-4.8.so gnatcoll-2013-4.fc21.i686 requires libgnarl-4.8.so [gnome-pie] gnome-pie-0.5.5-3.20130330git0a5aa2.fc20.i686 requires libbamf3.so.0 [gofer] ruby-gofer-0.77-1.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [golang-github-smarterclayton-go-systemd] golang-github-smarterclayton-go-systemd-devel-0-0.4.git5cb9e9e.fc21.noarch requires golang(github.com/guelfey/go.dbus) [gtkd] gtkd-2.0.0-45.20140301gitaf01da8.fc21.i686 requires gstreamer-plugins-basexz [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [libyui-gtk] libyui-gtk-2.43.7-1.fc21.i686 requires libyui.so.5 [libyui-ncurses] libyui-ncurses-2.44.1-1.fc21.i686 requires libyui.so.5 [libyui-qt] libyui-qt-2.43.5-1.fc21.i686 requires libyui.so.5 [mapserver] mapserver-java-6.2.1-5.fc21.i686 requires java-gcj-compat [matreshka] matreshka-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-dd-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-mofext-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-ocl-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-uml-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-amf-utp-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-fastcgi-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-fastcgi-0.6.0-1.fc21.i686 requires libgnarl-4.8.so matreshka-soap-core-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-soap-wsse-0.6.0-1.fc21.i686 requires libgnat-4.8.so matreshka-sql-core-0.6.0-1.fc21.i686 requires libgnat-4.8.so
Re: F21 System Wide Change: Cockpit Management Console
On Tue, Apr 22, 2014 at 05:06:33AM -0400, Jaroslav Reznik wrote: Cutting one week from Alpha/Beta cycle is doable but only when it's really, really needed. We did this voodoo magic a few times to avoid Christmas etc. and believe me - that note in the Task Juggler source for schedule - never, ever, do this - is just truth. It pains. And in practice, it's probably a lie -- those cut weeks get added back as delays later, so it's really just shuffling numbers around for extra work and no benefit. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On Tue, Apr 22, 2014 at 06:34:48AM +0200, Lennart Poettering wrote: Pull is the only model that scales, since the centralized log infrastructure can schedule when it pulls from where and thus do this according to available resources. THe push model is prone to logging bursts overwhelming log servers if you scale your network up. This terminology is (excitingly?) reversed from push vs. pull in configuration management, where either clients pull from a server or have commands pushed to them. Maybe we could use different terms for logging instead, like send and fetch? Or maybe it's just me that's easily confused. I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. There are advantages and disadvantages to both. Disadvantages of pull (fetch) include: - If a client system is broken into, logs may be removed before they're fetched. (Of course, this is also a risk with a batched send/push scheme.) - Client system needs to hold logs until asked -- maybe a long time. Traditionally some devices don't hold logs at all and _just_ send them remotely. - Usually pull/fetch designs require more configuration, with the server needing a list of clients to check and the clients configured to allow connections from just that server in. But it's definitely better for scaling, and you don't have to worry about 100% log server uptime, and the log server itself can be kept more secure. And on the neutral side, the network design may make it hard to reach clients; they might be behind NAT/PNAT from the log server's point of view. That's not necessarily an inherent pro or con, but may make push/send fit better into a certain environment. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: The Forgotten F: A Tale of Fedora's Foundations
On Mon, Apr 21, 2014 at 05:50:20PM -0400, Josh Boyer wrote: Board seats should absolutely keep in mind various aspects of the entire project, but we need less partisanship and more open-mindedness at this level. We need people willing to work together to find out what is best for the Project as a whole, not argue on behalf of certain pieces of it. Compromise and cooperation are what will wind up getting us moving again. In other words, if we're going to have one foundation over the others, let's make it Friends. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 11:17 AM, Matthew Miller wrote: On Mon, Apr 21, 2014 at 05:50:20PM -0400, Josh Boyer wrote: Board seats should absolutely keep in mind various aspects of the entire project, but we need less partisanship and more open-mindedness at this level. We need people willing to work together to find out what is best for the Project as a whole, not argue on behalf of certain pieces of it. Compromise and cooperation are what will wind up getting us moving again. In other words, if we're going to have one foundation over the others, let's make it Friends. :) I can certainly get behind that. At this point, I formally withdraw the request to add Functional to the Foundations. This thread has convinced me that the real problem here is that we've been treating Freedom as more important than the others, and that we probably need to be rebalancing rather than superseding. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWiNkACgkQeiVVYja6o6OnjwCeP7/LutNbd1B8CHucnQP7Z4Rw NXwAn1FU34j5KRAAnPEHSw4DVPaeDVkw =CsTS -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: The Forgotten F: A Tale of Fedora's Foundations
On 04/22/2014 08:55 AM, Máirín Duffy wrote: Some of the choices Przemek suggested don't make sense depending on the context. E.g., full functionality vs. small size / speed I think has a different meaning depending on whether you have a workstation target (which, either way, will include X) or a server target (which might not necessarily include X.) Same with command line vs polished apps. Everything in our repos is free, so putting the choice in the installer seems off to me. Our policy (which is complex and obviously driven by things stronger than the UX) generally leaves it to users post-install to add encumbered software. I don't actually see the advantage to the user in changing that. PackageKit's UI used to have filters I think some were based on license. Maybe the GNOME software devs would be interested in having some kind of selection for the type of software offered to you. Similarly to how some Android app stores work - e.g. show me only free apps, or you can show me paid apps too. Thanks for bringing some data into this. I do realize that this is a difficult and multifaceted topic, and I don't have a solution to it. I just want to point out that our current practice is very fragmented and low level, and therefore difficult for end users. Taking the Free/non-Free issue, the real question is whether the user can tolerate somehow diminished functionality in exchange for a more open and standard-based system. We're not asking that question, however---we're talking about .repo files and RPMfusion URLs. /etc/yum.repos.d just is not the vocabulary that should be used to speak to new users. I am concerned that the ideas being offered attempt to elevate these choices to a higher level of abstraction but still are fragmented: a separate mechanism for GNOME, another one for OS install, different one for apps and non-apps(*). I am trying to see a commonality centered around the fact that all these are just special cases of a software installation / deinstallation workflow, i.e. selecting search parameters, obtaining and evaluating the results, and loading or removing the software. So to back this up, a lot - what install target are we talking about, exactly? And what type of users are we talking about? My guidance as an IXD would be completely different depending on these things. I hear you about the IXD but do you think that the cases are so different as to have no common workflow? For instance, I liked your insight that the experienced sysadmins aren't interested in licensing questions and rely on RedHat to make a reasonable choice. My suggestion, however, is to present a reasonable default but also provide a well-explained option to override it. This would be my preference in all cases you brought up: both OS installation and subsequent software maintenance; all types of install targets; and both beginner and advanced users. The specific UI might be different of course---I do get that too many spokes on install are confusing and hard to test, so maybe OS install should defer the choice to an already running system. Ceterum censeo, it's all about a well-oiled, flexible software installation/removal mechanism at the center of the OS administration. Greetings przemek klosowski (*) It reminds me of the sinking feeling I have when I have to use the alternatives (CPAN, npm, PIP, octave pkg) on package-based systems (RPM, deb): I feel I am doing the expedient thing that is agains my long term interests (It's the life little pleasures that make life miserable:) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Friends foundation [was Re: F21 System Wide Change: Workstation: Disable firewall]
On Tue, Apr 22, 2014 at 05:05:24AM -0400, Christian Schaller wrote: As a sidenote, there has been a lot of discussions on this an other Fedora lists over the last few Months where people have loudly come out against what they see as infringements on the Freedom part of the four F's. Having seen this thread I am disappointed to see that nobody has come out in defense of the Friends part of the four F's, because the language and tone used by some people on this thread has been beyond pale, accusing the other participants in the thread of stupidity, incompetence and general maliciousness. If this doesn't change maybe the time has come for a board ticket to change that F from Friends to Flames? Funny -- I just posted something in defense of Friends a minute before I read this. Yes, this definitely needs more emphasis from everyone, please. That includes taking the be excellent to each other communication guideline seriously, and everyone recognizing that the end goals are the same even if we disagree about how to get there -- people emphasizing freedom *also* want the system to be welcoming and easy to use, and people emphasizing features *also* want free software to win over closed source. As Josh has said a number of times recently, the internet is horrible for actually communicating. Refraining from actively nasty language is obviously the baseline, but also, take time to think about where the person you're talking to is really coming from, and where we can find common ground. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes for Env-and-Stacks WG meeting (2014-04-22)
#fedora-meeting: Env and Stacks (2014-04-22) Meeting started by mmaslano at 15:01:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-04-22/env-and-stacks.2014-04-22-15.01.log.html . Meeting summary --- * init process (mmaslano, 15:03:19) * Allow to delete builds/coprs from playground? (mmaslano, 15:05:32) * feature request - dnf plugin should be able to block view of some copr repositories in Playground (mmaslano, 15:08:39) Meeting ended at 15:24:08 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mmaslano (25) * hhorak (9) * zodbot (4) * randomuser (3) * samkottler (1) * drieden (1) * bkabrda (0) * abadger1999 (0) * tjanez (0) * juhp (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Is /bin/bash broken in the buildroot right now?
http://kojipkgs.fedoraproject.org/work/tasks/5520/6765520/root.log All the scriptlets are failing like this: DEBUG util.py:281: /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory DEBUG util.py:281: error: %pre(glibc-headers-2.19.90-11.fc21.i686) scriptlet failed, exit status 127 A bit later, /usr/bin/sort fails like this: DEBUG util.py:281: sort: error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory (On Fedora 20, /usr/bin/sort does not link to libcrypto) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Smaller Cloud Image Footprint
2014-04-21 16:18 GMT+02:00 Matthew Miller mat...@fedoraproject.org: On Thu, Apr 17, 2014 at 10:30:48PM +0200, Miloslav Trmač wrote: Writing too fast... you were actually arguing for a situation 2 used by default + 1 used but not used by default I think. In that case your argument is right but it's my turn to not accept your premise :) networkd was introduced in systemd-209, and F20 ships with -208, I.e. it has never shipped in a Fedora release, so it is not 1 used but not used by default; it's entirely new to Fedora *in F21*. Okay, fair enough. :) On reflecting, I think a generator which reads ifcfg-* format, and ifup/ifdown compat scripts should probably be considered hard prerequisites for using systemd-networkd by default. That gives a common language, keeps current tooling working, and makes an easy path for a user to switch if a particular need isn't covered. That might work: note that it still means that any applications depending on NetworkManager APIs are unusable on the cloud images: I suppose you don't want much intelligence inside the cloud image anyway, so that's not a blocker (but *would* be a blocker for any non-cloud uses). 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: The Forgotten F: A Tale of Fedora's Foundations
On Tue, Apr 22, 2014 at 11:17 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Apr 21, 2014 at 05:50:20PM -0400, Josh Boyer wrote: Board seats should absolutely keep in mind various aspects of the entire project, but we need less partisanship and more open-mindedness at this level. We need people willing to work together to find out what is best for the Project as a whole, not argue on behalf of certain pieces of it. Compromise and cooperation are what will wind up getting us moving again. In other words, if we're going to have one foundation over the others, let's make it Friends. :) Well, I was talking on a tangent of representation there. In the context of Board level member composition and priorities, maybe. It should certainly have equal footing with Freedom anyway. Features doesn't make a ton of sense at the Board level. The Board is very clearly never First in anything we do. The primary guiding Foundation(s) are going to differ from group to group though. Take FESCo and the FPC for example. In FESCo, Freedom is very seldom even in play because it is almost always a given, so Features and First tend to be the main Foundations in play. The FPC, on the other hand, often has to deal with Freedom due to content and licensing. I doubt they're making many Friends with all the packaging rules they come up with though ;). Anyway, overall I do think we as a Project need to keep Friends more in mind than we have been. I don't think we need to be literal friends with everyone, but we do need to consider how we can cooperate and compromise on things as they come up. 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: F21 System Wide Change: Workstation: Disable firewall
2014-04-20 22:56 GMT+02:00 Reindl Harald h.rei...@thelounge.net: than just install one of the already available by default unsecure operating systems instead damage Linux and bring it in the same bad shape Note that there *aren't* any major available by default unsecure operating systems nowadays: Windows has the capability of sharing to everyone via DLNA, but also the of concept home/work/public networks and uses it fairly agressively to restrict sharing. OS X doesn't have zones, but sharing services require authentication[1] (which is not *as* resilient as not having the connection open, but much better than allowing possibly anonymous DAAP). Mirek [1] Well, in addition to iTunes home sharing which is authenticated there is also an older, possibly unauthenticated, streaming mechanism. But that's a legacy thing that's more difficult to find and set up than iTunes home sharing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
2014-04-20 23:20 GMT+02:00 Lars Seipel lars.sei...@gmail.com: On Thu, Apr 17, 2014 at 11:44:58PM +0200, Miloslav Trmač wrote: We don't, actually. *Only* applications running in a session of a member of the wheel group would have that right, and those applications are pretty much root-equivalent anyway. (Many GNOME users probably use such a setup, but it's not at all the only one possible.) Ugh. This is implemented in PolicyKit? Where was this change discussed/announced and when did it happen? Reinterpreting wheel group membership to give user accounts mighty powers without requiring re-authentication is a pretty major change and probably unexpected for most users. I'm sorry, I was imprecise; it typically does require re-authentication with users' own password, but in X11 that password is available to any malicious program running in the session (e.g. by painting a fake screen lock), so I tend to discount it. 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: F21 System Wide Change: Workstation: Disable firewall
2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is *only* true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. 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: F21 System Wide Change: Workstation: Disable firewall
Am 22.04.2014 19:01, schrieb Miloslav Trmač: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is /only/ true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. and with *every* recovery you lose unconditional data you can't have perfect backups in real time not containing the issue too sorry, but after working 11 years without a need to recover i say recovery is nice and should be possible, but if you need it regulary you are doing something wrong 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: F21 Self Contained Change: Remote Journal Logging
2014-04-22 15:10 GMT+02:00 Simo Sorce s...@redhat.com: A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Isn't that an inherent capability of TCP? If it is not automatic, maybe it would only be up to the log receiver to appropriately decrease the receive buffers on their incoming sockets? 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: F21 System Wide Change: Workstation: Disable firewall
On 22 April 2014 05:40, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since you missed the link: https://www.youtube.com/watch?v=jYGgVUYjXQ8 I too recommend that everyone gives it a look. It is very insightful and helpful in understanding what people really do once this gets out the door. Major points: 1) People turn off security features that they can't easily figure out how to tune. 2) Hackers are a significantly smaller security threat than managers (I need it to work now, we can secure it later!) 3) Recovery and auditing are more important than prevention. Those are some of the basics, but it *really* is worth taking the 40 minutes to watch the whole thing. Uhm that is basic short-term outlook versus long-term outlook and seems to miss the cost it takes to deal with security before, during and after the effect. While the customer can take the point of view that they will turn off stuff because it gets in their way, we as the development side do not have that luxury. The cost of trying to get security into software or an OS is much much higher if we have to deal with it after the fact. This was a lesson that every OS company had to learn the hard way in the 1990's and early 2000's. The Unix companies had to deal with this in the 1990's when it became clear that the security threat landscape was different on a network than it was on a phone line. Just getting firewalls into the OS was a giant challenge and cost the companies a lot in support issues because it wasn't designed or tested with what they had. Microsoft went through multiple quarters of lost revenue and stock drops because they had to get a working firewall and other security measures that weren't really tested in the firstplace. Apple got away with it by buying an OS (NEXT) which had already gone through the 1990's firewall security and other challenges. They had stuff which was already designed in. To use an example he uses in the lecture... we are building the OS immune system. We can eat dirt during development and make it stronger or we can deal with it later when there is a threat we didn't know about and the OS immune system is screwed later. Saying oh they can turn it on misses the fact that we never thought of how it would affect application Y which we made crucial. -- 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: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. Russ 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: Is /bin/bash broken in the buildroot right now?
This is repeatable, and it's not just me that's reporting it. So far it only happens on i686 however. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: When a yum update sets up an MTA ...
On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fwei...@redhat.com wrote: On 04/21/2014 03:44 AM, Andrew Lutomirski wrote: Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'? I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy. Time to file a bunch of bugs? I can do it, but if someone has scripts, that could help. Are there any currently supported upgrade paths from sysv to systemd for any of these services? If F19 already had all of these, then it may make sense to just remove the migration code. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 Puppet update and SELinux policy
From: l...@redhat.com To: devel@lists.fedoraproject.org Date: 04/22/2014 08:47 Hello, we are rolling out update of Puppet to 3.4.3 in Fedora 20 and Rawhide that adds one important change. We have found that puppet master was running unconfined, therefore the Puppet SELinux policy was not effective in Fedoras. The puppet package update fixes one little issue (missing runtime dependency) and corrects startup wrappers for systemd which puts Puppet Master into the correct SELinux domain puppetmaster_t. Since this has some security impact, we have decided to backport this change into Fedora 20 too. https://admin.fedoraproject.org/updates/puppet-3.4.3-3.fc20 Until now, puppet master was running unconfined (this is a regression), the update might need relabelling of the system (/etc/puppet, /var/lib/puppet) or checking out audit.log. Please help me with testing this update: yum --enablerepo=updates-testing update selinux-policy puppet puppet-server Thanks for help. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Okay, count me in. Is there a BZ already in place for reporting issues or should such reports just go straight to Bodhi, or simply back here? -- John Florian -- 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: The Forgotten F: A Tale of Fedora's Foundations
On 22 April 2014 05:53, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2014 05:31 PM, Stephen John Smoogen wrote: On 21 April 2014 11:19, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2014 01:08 PM, Bruno Wolff III wrote: On Mon, Apr 21, 2014 at 12:37:57 -0400, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: Does Fedora need to be that gateway OS? Maybe Ubuntu would be a better intermediate step? If Fedora isn't that gateway OS, why are we bothering? What makes it likely that any user would switch to us if they've entered the FOSS community via Ubuntu? (Don't get me wrong, this is a question we also need to answer, but I don't think it's wise of us to be recommending that Ubuntu handles gathering our new users for us.) It is an interesting question... why are we bothering? When people bother because they need to be THE gateway.. they are setting themselves for a lifetime of disappointment. That ship sails completely with little to no control. Maybe I should have phrased that differently. If we aren't trying to be that gateway, why are we bothering?. Without users, we can't grow our contributor pool. Without growing our contributor pool, we won't innovate as fast as other distributions, which in turn will further reduce our user and contributor base. Actually you will find out that while having a healthy contributor pool is needed, having a large contributor base will inhibit development at times because so many people rely on old stuff that you tend towards only conservative changes if any at all. Debian is a pretty good example of this in action. Making medium to deep changes make our flamewars seem tame. If you want to be the keystone for innovation, you need to focus on the people who are looking for that which is a small segment of the population of users. I have found that if you are going to bother.. do it because it is making something better for you, for something you care about. That is I'm certainly not trying to rule that out (it's why I'm here after all). But it's not *enough* (in my opinion). stuff you can control and not items left to the fact that people choose to use what everyone else uses or by the fact its name sounds exotic or they like Orange over Blue. Of course there will always be people who make frivolous choices, and I'm not expecting to cater to them. You're right, that way lies disappointment. I do think we *can* improve our appeal, though. We just need to agree that this is a real target and go after it. The majority of people make choices due to frivolous choices. They usually come up with some sort of rational reason afterwords but the initial choice is 'frivolous'. [Humans are not rational creatures, we are creatures who use rationality to justify our stupidity later.. ] Maybe some real ideas now instead of me just spewing platitudes? :) I've argued for quite some time that the path to code contributions would be best paved by making Fedora the first Linux distribution with a fully-integrated development environment. Take something like Eclipse and Red Hat Developer Toolset and build our Microsoft Visual Studio with a public API. With a basic recompile of RHDTS for Fedora, we can carry backwards-compatible support for three years, making it actually possible to do development for Fedora (and as a bonus, stuff that will also run on RHEL with RHDTS). I'd also love to see such an environment designed from the beginning to integrate well with OpenShift/Docker for Continuous Deployment. Good idea, First we will need to interest the developers who want to scratch that itch to agree (either through payment or magic) to agree to work on one set of existing tools versus everyone building another set from scratch. Developers seem to be a very egotistical bunch who tend to think that they are the only ones who can do something right... and then reimplement LISP and emacs (or Algol and vi) poorly. -- 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: Is /bin/bash broken in the buildroot right now?
The issue appears to be varnish-libs-devel over-providing various things (pkg-config, env). Kevin Fenzi fixed it -- thanks! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote: 2014-04-22 15:10 GMT+02:00 Simo Sorce s...@redhat.com: A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Isn't that an inherent capability of TCP? Sure, that's one way when bandwidth is the issue. There are other issues though, and just closing the connection on the client if you do not want any traffic is a bit blunt. It also does not give the client any idea when it is ok to retry. If it is not automatic, maybe it would only be up to the log receiver to appropriately decrease the receive buffers on their incoming sockets? This is not a problem I care, the kernel already does it quite well. 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: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. All very true, but you do not remove the Deterrent, just because you have the other 4 layers (which we do *not* have very much in Fedora when it is used as a simple workstation). This is why people say we need to improve the Firewall experience not raise white flag and disable it. 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: When a yum update sets up an MTA ...
On Tue, 22 Apr 2014 10:33:12 -0700 Andrew Lutomirski l...@mit.edu wrote: On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fwei...@redhat.com wrote: On 04/21/2014 03:44 AM, Andrew Lutomirski wrote: Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'? I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy. Time to file a bunch of bugs? I can do it, but if someone has scripts, that could help. Please please please see: https://fedoraproject.org/wiki/Mass_bug_filing before you go filing any bugs. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
2014-04-21 17:56 GMT+02:00 Eric H. Christensen spa...@fedoraproject.org: On Mon, Apr 21, 2014 at 08:36:55AM -0400, Stephen Gallagher wrote: ...I'd like to suggest a fifth Foundation, one to ultimately supersede all the rest: Functional. I think anytime anyone suggests a new foundation that supersedes all of what the project and community has stood for for many years then they are doing it wrong. Well... I'd *much* rather have a honest discussion about the values like this than just committing code without any discussions, and then arguing that we've been doing this for years at a small scale so it's fine to do it on larger scale. These things *should* be discussed mostly top-down, not bottom-up. And the recet-ish discussions have revealed that the practice and the literal wording of the foundations *has* slightly diverged over time (both First, and, at least in your view, WRT Google search, Freedom), so revisiting, re-discussing, and re-affirming might be in order. I mean, Fedora has traditionally been very strong in upholding the values of FOSS. We live it, feed it, and use it. Does this mean that Fedora isn't always great when dealing with proprietary solutions later on (like Flash)? Sure, but that also means that there is more of a push to get FOSS solutions in place that remedy those issues. Fedora has never forebade a user to install third-party software (proprietary or otherwise) after the fact. The fact that many (most?) users don't have to do such things is a testiment to how well FOSS has been developed and meets the needs of our users. I find it difficult to believe that most users [don't have Flash installed]. AFAIK there is no data to say either way, and anecdotal evidence from around here isn't supportive. 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: The Forgotten F: A Tale of Fedora's Foundations
2014-04-21 19:07 GMT+02:00 Haïkel Guémar hgue...@fedoraproject.org: Le 21/04/2014 18:37, Stephen Gallagher a écrit : I spoke too strongly there, I think. We do however give a *very* strong impression that using non-FOSS solutions for anything at all is unwelcome at best. Consider the recent discussions around GNOME Software where we have 1) Forbidden it from automatically looking up software from non-Fedora repositories, even FOSS ones 2) Asserted that it must consider web apps (either FOSS or not) to be second-class citizens (and call it out as such) They actually are second-class citizens, we can't fix proprietary apps as we actually do with FOSS applications. That's not actually *exclusive* to proprietary applications; there seem to be quite a few Fedora packages where the maintainer can, or does, only forward bug reports upstream without trying to fix the code. *In theory*there's a difference, *in practice* there isn't. But if we were to consider them first-class citizens, without the editors cooperation, we would be bind to their willing which is against our mission statement. Unlike CentOS, we can't provide a stable base suitable to proprietary SW editors, all we can do is best effort. This is not true: the OS, not the applications, has the authority to define what is a stable base for applications to rely on, and the OS even has technical capability (via SELinux permissions or (nm -D) checks within installers) to enforce that they don't rely on anything else. Yes, we would have to commit to a set of useful stable ABIs; but that's not the same as freezing every interface in the system. And useful stable ABIs would be *equally beneficial* for the open-source projects, ensuring that the two-sided market of users/programmers is not losing programs just because somebody decided an API needs to be improved. 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: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. All very true, but you do not remove the Deterrent, just because you have the other 4 layers (which we do *not* have very much in Fedora when it is used as a simple workstation). Absolutely true - the foundation of the stack is Deter. The point is that we can't harden a system enough for Deter alone to be fully effective, so we need to have the complete security model. And you are right. We have a real opportunity to look at an overall people centric approach to security in Fedora. Look at the traditional threat models, look at the people issues, and look at an overall approach to maintaining system integrity. I'd like to see us exploring system integrity in greater depth. This is why people say we need to improve the Firewall experience not raise white flag and disable it. Agree. Unfortunately, the easy way out is to punch so many holes in the default firewall that it doesn't offer much protection... 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: The Forgotten F: A Tale of Fedora's Foundations
2014-04-21 19:37 GMT+02:00 Eric H. Christensen spa...@fedoraproject.org: And how are these contributors going to contribute to their proprietary solutions that we now provide for them? They aren't; isn't that a *benefit* for the open solutions? How do we support something that is simply provided to us as a binary and has no upstream bug tracking or support (outside of a support contract)? We don't; why would we be required to? How are these users going to react when all the software they know and love (that we provide) breaks due to no fault of our own? Blame the provide of the software, naturally. Are we going to hold back bug or security fix because it breaks a proprietary program but fixes it for everything else? No, we should instead improve our technology so that this doesn't need to happen. This is a *technically solved problem* at the very least since Windows 95, i.e for about 20 years; we have only not solved it because it's less work to say proprietary software is bad, go use Windows—but then we shouldn't be surprised if users do. 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
Mass bug proposal: packages that auto-enable systemd units
Hi all- I propose a mass bug against packages that install services and enable them without using the preset mechanism. Some of these can be security issues if they get installed as dependencies. As a related issue, it may pay to review the default presets. For example, rpcbind is enabled. This seems bad. I know of three of these bugs that already exist: https://bugzilla.redhat.com/show_bug.cgi?id=1089650 https://bugzilla.redhat.com/show_bug.cgi?id=1087951 https://bugzilla.redhat.com/show_bug.cgi?id=1087950 The text would be: --- cut here --- A number of packages install systemd units and enable them automatically. They should not. Please update the package to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd). If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file. Given that this issue can affect Fedora 20 users who install your package as a dependency, these bugs should be fixed in Fedora 20 and Rawhide. The affected packages are: OpenIPMI at avahi avahi-dnsconfd bcfg2 bcfg2-server bwbar cronie deltacloud-core device-mapper-multipath dmapd exim fsniper gpm groonga hsqldb iscsi-initiator-utils jabberd libvirt libvirt-client lvm2 mailman mdadm monit openct opendkim openssh-server partimage rhnsd rinetd rpcbind sendmail varnish vdsm xrdp yum-cron yum-updatesd --- cut here --- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
2014-04-22 20:19 GMT+02:00 Simo Sorce s...@redhat.com: On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote: 2014-04-22 15:10 GMT+02:00 Simo Sorce s...@redhat.com: A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Isn't that an inherent capability of TCP? Sure, that's one way when bandwidth is the issue. There are other issues though, and just closing the connection on the client if you do not want any traffic is a bit blunt. It also does not give the client any idea when it is ok to retry. Not like that—just stop reading from the socket, causing the server to advertise a zero-length window to the client. The client will then know that writes are blocking / not being processed. And when the server has more capacity, free up the buffers and the kernel will send a window update to the client automatically. 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: F21 System Wide Change: Cockpit Management Console
Jaroslav Reznik (jrez...@redhat.com) said: I think this definitely better way - not being as strict regarding deadlines for Cockpit and get some test coverage during later Test Day. I'd be fine with a later deadline for Cockpit if needed, especially since (from the feature page description) it doesn't seem to have much of a knock-on effect on other components. I'm actually a little curious how this isn't a standalone addition, aside from just the 'installed by default in Fedora Server' angle. Bill -- 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: Mass bug proposal: packages that auto-enable systemd units
Hello, 2014-04-22 20:50 GMT+02:00 Andrew Lutomirski l...@mit.edu: If your package has an exception from FESCo permitting it to enable itself, Note that many (most?) packages don't need an individual exception by FESCo: https://fedoraproject.org/wiki/Starting_services_by_default allows fairly wide categories. 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: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-22 at 14:41 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. All very true, but you do not remove the Deterrent, just because you have the other 4 layers (which we do *not* have very much in Fedora when it is used as a simple workstation). Absolutely true - the foundation of the stack is Deter. The point is that we can't harden a system enough for Deter alone to be fully effective, so we need to have the complete security model. And you are right. We have a real opportunity to look at an overall people centric approach to security in Fedora. Look at the traditional threat models, look at the people issues, and look at an overall approach to maintaining system integrity. I'd like to see us exploring system integrity in greater depth. This is why people say we need to improve the Firewall experience not raise white flag and disable it. Agree. Unfortunately, the easy way out is to punch so many holes in the default firewall that it doesn't offer much protection... not really true, having the default one allow access only from the local lan at most is a huge improvement rather than no firewall. All you need is a button that lets you select between 3 zones when you join a new network and you have a much better system already, nothing fancy, and the 3 zones correspond to the concepts of: open to everyone (effectively disables any protection) open to the local lan only (what you would select at home/work/trusted network) closed (what you would select in a public place on an untrusted network) It is quite simple to describe even to a non expert user what these means in general terms. Of course it won't be perfect, but much better than nothing, and much, much friendlier than what we have now. 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: F21 System Wide Change: Ruby193 in SCL
Marcela Mašláňová (mmasl...@redhat.com) said: On 04/14/2014 10:17 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Is the intent to only provide SCL versions of the older ruby rails, or also the current versions (i.e., move to SCL as the rails delivery mechanism going forward)? I'm doing one collection. If there is someone who want to donate his free time to do also new version, I'm fine with it, but I don't see any use-case right now. What I was thinking of was simply having a uniform way to access a rails stack (or whatever) - not having to have the developer/admin keep track of whether the version they want is packaged as an SCL or not, and having to adjust their environment/setup accordingly. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
Miloslav Trmač (m...@volny.cz) said: AFAICS this discussion basically says applications can't depend on firewalld, therefore they can't use firewalld APIs, therefore they wouldn't know whether the firewall restircts them, therefore firewalld must be removed. The only given reason why the applications can't depend on firewalld is vague claims that the D-Bus API is somehow unusable, which is clearly false because firewall-cmd is using exactly the same API. Well, just because an API *can* be coded to doesn't make it a good API. It would be great to get more concrete descriptions of where the API fails. Bill -- 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: Mass bug proposal: packages that auto-enable systemd units
On Tue, Apr 22, 2014 at 12:00 PM, Miloslav Trmač m...@volny.cz wrote: Hello, 2014-04-22 20:50 GMT+02:00 Andrew Lutomirski l...@mit.edu: If your package has an exception from FESCo permitting it to enable itself, Note that many (most?) packages don't need an individual exception by FESCo: https://fedoraproject.org/wiki/Starting_services_by_default allows fairly wide categories. Mirek Hmm. I can't actually find anything in that category in the list here except, sort of, OpenIPMI. OpenIPMI seems rather confused -- it has a systemd service that claims to be oneshot but still has a stop command. That service does one-shot stuff and (I think) starts a real daemon. It should probably be split into two units. In any event, the actual offending code in OpenIPMI is in %triggerun, so it should still go, and I think OpenIPMI has a preset entry anyway. Nonetheless, I'll add: If your package falls into the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of runs once then goes away services include iptables and udev. Also, yum-cron and varnish should be removed from the list. Varnish doesn't actually auto-enable itself, and yum-cron is dead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, 2014-04-22 at 15:04 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 14:41 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote: On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote: 2014-04-22 13:40 GMT+02:00 Stephen Gallagher sgall...@redhat.com: 3) Recovery and auditing are more important than prevention. This is only true for large managed enterprises, where recovery is possible in the first place (how many people don't have good backups?), and prevention is bordering on impossible (with the high number of systems and administrators). For individual users auditing is completely pointless, recovery is either impossible or a huge hassle, and prevention the only option. Well, the presentation was focused on enterprise systems... But there were some underlying themes: * Users will work around anything, including security features, that interfere with them doing their job. * It is impossible to completely secure a system. A prevention only approach doesn't work well. * An effective security model is built around Deter, Detect, Delay, Respond, Remediate. * Security is one of multiple threats to system integrity. All very true, but you do not remove the Deterrent, just because you have the other 4 layers (which we do *not* have very much in Fedora when it is used as a simple workstation). Absolutely true - the foundation of the stack is Deter. The point is that we can't harden a system enough for Deter alone to be fully effective, so we need to have the complete security model. And you are right. We have a real opportunity to look at an overall people centric approach to security in Fedora. Look at the traditional threat models, look at the people issues, and look at an overall approach to maintaining system integrity. I'd like to see us exploring system integrity in greater depth. This is why people say we need to improve the Firewall experience not raise white flag and disable it. Agree. Unfortunately, the easy way out is to punch so many holes in the default firewall that it doesn't offer much protection... not really true, having the default one allow access only from the local lan at most is a huge improvement rather than no firewall. All you need is a button that lets you select between 3 zones when you join a new network and you have a much better system already, nothing fancy, and the 3 zones correspond to the concepts of: open to everyone (effectively disables any protection) open to the local lan only (what you would select at home/work/trusted network) closed (what you would select in a public place on an untrusted network) This sounds a lot like the Network Manager model. Could this basic firewall configuration be integrated with the Network Manager interface? So that a user sets their security profile one place, and all related system settings and configurations are updated? It is quite simple to describe even to a non expert user what these means in general terms. Of course it won't be perfect, but much better than nothing, and much, much friendlier than what we have now. A combination of this and having all commonly used applications configure the firewall when installed/uninstalled looks like a good start, especially from a usability perspective. 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
Pkgdb2 making it to stg (pre-prod)
Dear all, A while ago I introduced you the dev instance of pkgdb2. Since then, I have been working some more on it. I recently updated pgkdb-cli to work with the new API [1] as well as writing a python module for those that want to script against said API [2]. On March 10th, pkgdb2 made it to staging [3], our pre-production environment, and on March 11th, I have updated its database to have a recent version of the pkgdb1 database, just converted for pkgdb2. This means that soon (I'm thinking early May), pkgdb2 will go live in production. If you have any tools that are relying on pkgdb, now would be a good time to start looking at the pkgdb2 API [4] and see if it does what you want to do. I will accept *minor* changes/enhancements to the current API, but only while it is only in staging. So if you want something changed in the API, now is a good time to ask. [1] https://github.com/fedora-infra/packagedb-cli/ [2] https://github.com/fedora-infra/packagedb-cli/blob/master/pkgdb2client.py [3] https://admin.stg.fedoraproject.org/pkgdb/ [4] https://admin.stg.fedoraproject.org/pkgdb/api/ Bug reports and RFE are of course welcome at either place: https://github.com/fedora-infra/pkgdb2 or https://fedorahosted.org/pkgdb2/ Thanks for your attention and have a nice day! 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: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 22, 2014 at 08:33:55PM +0200, Miloslav Trmač wrote: I find it difficult to believe that most users [don't have Flash installed]. AFAIK there is no data to say either way, and anecdotal evidence from around here isn't supportive. Well, since we're talking about Flash, Adobe has decided to not support the Linux version of Flash. In fact, updates have happened to Flash and the existing Flash package available through Adobe hasn't been updated. This means that users who are still using Adobe Flash are now vulnerable to known security issues and bugs. Gnash, the FOSS Flash solution, is still being developed and is probably a better solution. I just hope that HTML5 becomes the standard soon. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTVsN8AAoJEB/kgVGp2CYvxoEL/2emzjmEfjbA5i2/bit2LN4Q 8iCb9SPwD0ZKV0lEg0NaS4lhfvNxVoGGh+cINBG+fA0/4jHc1ZiQAByEuEQoo1QB JOPvB3j9kFDtpe81YZs+OwIoVifKwgQr4DfMxX876I73pcYukvj4/03VmQqrboF5 GEa7Z7wxDuGZX2ujrySVNF/n7WKz6LB3MkohVIm0ROHB8rUOPldennNBBzO0QLK9 465+seYwF7RfMtlameSdyjWEjm7ppoKwsJJ42C8ZX73cYdM3ZuYbDEbHrKWRl9r7 EcZPKfF1vQYGwDG4uLBxdz430XONJkuwuTtXymNlY7Q5HjusEY/xfQRjknBXx4MO NE5KNEm0XhNWsmpBrlTFVctJp8VAapM9dxyr6EE/o4sm1RVhgJaxiuNSlW5kYTz0 LiRquMl3YErZsbo8T53GzumyWUJDXbVQ4a1BSxYLOHdoYNGc/N3c6qCQ/DuLZug+ 1+1DNgxIxPxJ4Ouq9MpBaKg8G78Pehh1YBOqLEIGpw== =i/RH -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: F21 Self Contained Change: Remote Journal Logging
On Tue, 2014-04-22 at 20:58 +0200, Miloslav Trmač wrote: 2014-04-22 20:19 GMT+02:00 Simo Sorce s...@redhat.com: On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote: 2014-04-22 15:10 GMT+02:00 Simo Sorce s...@redhat.com: A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Isn't that an inherent capability of TCP? Sure, that's one way when bandwidth is the issue. There are other issues though, and just closing the connection on the client if you do not want any traffic is a bit blunt. It also does not give the client any idea when it is ok to retry. Not like that—just stop reading from the socket, causing the server to advertise a zero-length window to the client. The client will then know that writes are blocking / not being processed. And when the server has more capacity, free up the buffers and the kernel will send a window update to the client automatically. And you keep resources tied this way, it is better to tell the client to come back later, maybe give it a time when it is ok to come back. The client can decide what to do, whether to save logs or dump them, or retry earlier anyway if it is running out of buffer space and some such. But that is not for me to decide, so I'll stop here. 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: The Forgotten F: A Tale of Fedora's Foundations
2014-04-22 21:31 GMT+02:00 Eric H. Christensen spa...@fedoraproject.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 22, 2014 at 08:33:55PM +0200, Miloslav Trmač wrote: I find it difficult to believe that most users [don't have Flash installed]. AFAIK there is no data to say either way, and anecdotal evidence from around here isn't supportive. Well, since we're talking about Flash, Adobe has decided to not support the Linux version of Flash. In fact, updates have happened to Flash and the existing Flash package available through Adobe hasn't been updated. Citation please? http://helpx.adobe.com/en/flash-player/release-note/fp_13_air_13_release_notes.htmlshows the latest security update has been released in the 11.2 Linux desktop version at the same day as the 13 non-Linux version. And even if it were true, I *still* think that most users have it installed—vulnerable or not; it's just so valuable for many users that the question of security update availability doesn't even arise.[1] Mirek [1] ... which may quickly change if there were a media-worthy worm using it to propagate. Don't expect perfect rationaliy... -- 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: The Forgotten F: A Tale of Fedora's Foundations
On Tue, 22 Apr 2014 15:31:11 -0400 Eric H. Christensen spa...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 22, 2014 at 08:33:55PM +0200, Miloslav Trmač wrote: I find it difficult to believe that most users [don't have Flash installed]. AFAIK there is no data to say either way, and anecdotal evidence from around here isn't supportive. Well, since we're talking about Flash, Adobe has decided to not support the Linux version of Flash. In fact, updates have happened to Flash and the existing Flash package available through Adobe hasn't been updated. This means that users who are still using Adobe Flash are now vulnerable to known security issues and bugs. Gnash, the FOSS Flash solution, is still being developed and is probably a better solution. I just hope that HTML5 becomes the standard soon. Actually they have said they aren't going to update it to newer versions/add features, but will continue to provide security updates: Adobe will continue to provide security updates to non-Pepper distributions of Flash Player 11.2 on Linux for five years from its release. There have been 3 updates this year so far. Of course there's little way to see whats in those updates as they don't add changelog entries to their rpm or otherwise note what they did, and since we don't have source no one else can tell. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Five Things in Fedora This Week (2014-04-22)
Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-22/ Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for April 22nd, 2014: Making it easier to join Fedora --- The Fedora Join SIG is our special interest group dedicated to improving the experience for new contributors. It’s been dormant for a while, but it’s back with a bang thanks to Ankur Sinha, Amita Sharma, Sarup Banskota, and others. A recent IRC meeting came up with a couple of immediate ideas, including a Fedora site inspired by What can I do for Mozilla? If making Fedora more welcoming is interesting to you, join the mailing list and help keep up the momentum. * http://fedoraproject.org/wiki/Fedora_Join_SIG * http://meetbot.fedoraproject.org/fedora-meeting/2014-04-16/fedora_join_irc_meeting.2014-04-16-09.07.log.html * http://whatcanidoformozilla.org/ * https://admin.fedoraproject.org/mailman/listinfo/fedora-join Fedora Docs “Beats” --- Speaking of things you can do for Fedora… how about contributing expertise in your area for the Fedora 21 release notes? I know F21′s October release target seems a long way off, but there’s a lot to do and the summer is going to fly by. Docs team leader Pete Travis recently announced that F21 Beats are Open, noting: If you’re new to Docs, Beat writing is a good way to get started. Simply choose a package, service, or functionality that interests you and do a little research to see how will change in F21. You can check rawhide package changelogs, read the software changelogs in /usr/share/doc/$pkgname, scrape upstream mailing lists and commit logs, and /reach out to package maintainers or developers. As always, Pete also provides great, non-intimidating guidance for new docs contributors. * https://lists.fedoraproject.org/pipermail/docs/2014-April/015583.html Fedora Workstation, and an alternate view — both part of Fedora! Fedora Workstation developer Christian Schaller wrote a long blog post explaining some of the mindset and background behind the upcoming Fedora Workstation. If you care about Linux on the desktop, this is an interesting read, whether you’re a GNOME fan or not (and whether or not you agree). And if you *do* disagree, remember that that’s absolutely okay too. Longtime Fedora contributor Stephen Smoogen (a self-described “411 year old Linux administrator”) has a great blog post responding to one particular Fedora Workstation decision and why he’s not worried. Our “Fedora.next” efforts are additive rather than restrictive, and are centered around our Friends Foundation; we may disagree on details, but we can all work together to advance free software as a project. * http://blogs.gnome.org/uraeus/2014/04/16/preparing-the-ground-for-the-fedora-workstation/ * http://smoogespace.blogspot.com/2014/04/why-i-am-not-worried-about-lack-of.html * http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-i-why/ * https://fedoraproject.org/wiki/Foundations Fedora Atomic? -- At last week’s Red Hat Summit, Red Hat announced a new initiative called Project Atomic. This isn’t really new software, or a new operating system or distribution — it’s best described as a pattern for putting together some pieces we already have. Not surprisingly, a lot of these pieces were (and are) worked on by Fedora contributors, including rpm-ostree, Docker, systemd, and a new orchestration building-block called GearD (you can read more about GearD on the OpenShift blog and of course you can `yum install geard` to check it out). So… (you may be thinking…) how does this fit into Fedora? Well, most of these are parts that we have already been talking about in the Fedora Cloud Working Group, and it may be that GearD provides one of the key missing pieces. We’ve filed a Fedora 21 change proposal for a specially-tailored Docker Host Image, and although we haven’t made any decisions yet, it - looks like the Atomic patterns are very well aligned with what we want to do (and overlap with what we are already doing anyway), so that may end up being our “Fedora Atomic” cloud spin. One of the pieces of Project Atomic that the Cloud WG *hadn’t* looked at is Cockpit, a web-based server management GUI. The interesting thing is that this is one of the key features proposed for Fedora Server, and if we decide to include that part in our Docker cloud image, that will be a point of coherence across the products. (See the Project Atomic docs on what that might provide.) * http://www.redhat.com/summit/2014/updates/ * http://www.projectatomic.io/ * https://www.openshift.com/blogs/geard-the-intersection-of-paas-docker-and-project-atomic
Re: Mass bug proposal: packages that auto-enable systemd units
On 04/22/2014 06:50 PM, Andrew Lutomirski wrote: Hi all- I propose a mass bug against packages that install services and enable them without using the preset mechanism. Some of these can be security issues if they get installed as dependencies. I will revisit all of this once I run the systemd cleanup process JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Documentation and Docstring Format
On 04/17/2014 12:09 PM, Tim Flink wrote: On Thu, 17 Apr 2014 10:03:24 -0400 (EDT) Kamil Paral kpa...@redhat.com wrote: https://pythonhosted.org/an_example_pypi_project/sphinx.html#auto-directives I'm not suggesting that we drop everything and fix all the docstrings right now but I am suggesting that we start following the sphinx docstring format for new code and fix other-formatted docstrings as we come across them. Any objections? Well, my only objection is, that the Sphinx format has IMHO the worst impact on how docstrings look. That is my impression as well [1]. The improved versions of Markdown are more legible and easier to remember than ReST (+Sphinx) [2]. OTOH, there are certain Sphinx features that look really great (for example documentation of attributes or global variables). So let's try it. This gets down to personal preference but in general, I prefer ReST to markdown. I thought that we had already decided to use sphinx when mike did his documentation tool survey a couple of months ago. Maybe it is just me, but I use help() more often than html docs. The Spyder editor shows HTML output of docstrings, even though it seems it uses plain ReST conversion instead of Sphinx conversion. But other than that, I have no issues. I played with it a little and the syntax is quite complex. If we are to use it, we will need at least: 1. basic sphinx config committed into the repository 2. some instructions in the readme how to generate the docs Yeah, my plan is to have sphinx docs live in the same repo as libtaskotron so changes can be built locally before submitting any patches. build docs sounds like a reasonable section to have in the dev documentation. so that we can at least generate the docs locally and look at it before posting the patch. As Tim already said, sphinx is pretty strict in its syntax. There is one more alternative, I think - use Sphinx for docs generation, but keep the docstrings free-form (I assume there must be an option in Sphinx to do that). That way we lose some pretty formatting, but won't be forced to adhere to a particular syntax. I put an example of the output from both sphinx-style docstrings and freeform docstrings up on fedorapeople: http://tflink.fedorapeople.org/taskotron/test-libtaskotron-docs/library.html It sounds like the general consensus is that sphinx-style docstrings are ugly but generate nice html output and it's not clear whether the ugly-ness of the docstrings is worth the nice html api docs. My 2 cents: The sphinx docstrings are not that bad, and the HTML output in places like readthedocs.org is quite good. Besides, a good deal of python projects fully embrace sphinx, precisely the reason why we migrated all autotest, virt-test and related projects docstrings. Example straight from virt-test: http://virt-test.readthedocs.org/en/latest/api/modules.html From avocado: http://avocado-framework.readthedocs.org/en/latest/api/modules.html Besides, rst is a quite capable language to write great non API documentation and keep it in tree, using sphinx as well. So with one solution, you get it all. Another reason why having not-so-pretty docstrings in this case is worth the effort. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Mass bug proposal: packages that auto-enable systemd units
On Tue, Apr 22, 2014 at 2:19 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/22/2014 06:50 PM, Andrew Lutomirski wrote: Hi all- I propose a mass bug against packages that install services and enable them without using the preset mechanism. Some of these can be security issues if they get installed as dependencies. I will revisit all of this once I run the systemd cleanup process What's that? --Andy -- 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: Mass bug proposal: packages that auto-enable systemd units
On 04/22/2014 09:32 PM, Andrew Lutomirski wrote: On Tue, Apr 22, 2014 at 2:19 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/22/2014 06:50 PM, Andrew Lutomirski wrote: Hi all- I propose a mass bug against packages that install services and enable them without using the preset mechanism. Some of these can be security issues if they get installed as dependencies. I will revisit all of this once I run the systemd cleanup process What's that? Just a various stuff ( todo list ) that I know that needs to be performed once I have finished the legacy sysv to systemd migration in the distribution, to better integrate systemd in Fedora core/baseOS/containers/servers and what not. In that process I will be revisiting all components shipping unit files and depend on systemd amongst other things. Once that process is done ( ca 1000 - 1500 hours of work by my gestimation ) I will declare the init system replacement officially done. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug proposal: packages that auto-enable systemd units
On Tue, Apr 22, 2014 at 2:54 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/22/2014 09:32 PM, Andrew Lutomirski wrote: On Tue, Apr 22, 2014 at 2:19 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/22/2014 06:50 PM, Andrew Lutomirski wrote: Hi all- I propose a mass bug against packages that install services and enable them without using the preset mechanism. Some of these can be security issues if they get installed as dependencies. I will revisit all of this once I run the systemd cleanup process What's that? Just a various stuff ( todo list ) that I know that needs to be performed once I have finished the legacy sysv to systemd migration in the distribution, to better integrate systemd in Fedora core/baseOS/containers/servers and what not. In that process I will be revisiting all components shipping unit files and depend on systemd amongst other things. Once that process is done ( ca 1000 - 1500 hours of work by my gestimation ) I will declare the init system replacement officially done. I don't think that fixing the broken packages should need to wait for this migration to finish -- there is a security problem now, and it can be fixed now with local changes to the thirty-something affected packages. --Andy -- 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: Mass bug proposal: packages that auto-enable systemd units
On 04/22/2014 10:14 PM, Andrew Lutomirski wrote: I don't think that fixing the broken packages should need to wait for this migration to finish -- there is a security problem now, and it can be fixed now with local changes to the thirty-something affected packages. By all means provide patches and fix those packages if you think this is such a urgent matter. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug proposal: packages that auto-enable systemd units
On Tue, Apr 22, 2014 at 3:14 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/22/2014 10:14 PM, Andrew Lutomirski wrote: I don't think that fixing the broken packages should need to wait for this migration to finish -- there is a security problem now, and it can be fixed now with local changes to the thirty-something affected packages. By all means provide patches and fix those packages if you think this is such a urgent matter. This thread is about getting consensus for a mass bug filing. Can I take this as your agreement? Patches can come later. For the most part, they'll be trivial -- the specfiles can just switch to using the standard systemd scriptlets. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
java-1.8.0-openjdk i686 and x86_64 rpms
Hi, I see openjdk-1.8.0 got built and pushed as an update for fedora 19 http://koji.fedoraproject.org/koji/buildinfo?buildID=505651 . In the past the i686 rpms of openjdk were pushed into release x86_64 repo of fedora 19 (http://mirrors.kernel.org/fedora-enchilada/linux/releases/19/Everything/x86_64/os/Packages/j/) , But with this particular update the i686 rpm never got pushed into x86_64 repository http://mirrors.kernel.org/fedora-enchilada/linux/updates/19/x86_64/ Any reason why it is not happening? -- Arun S A G http://zer0c00l.in/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-04-23)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-04-23 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 = New business = #topic #1250F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250 #topic #1287approve directory /opt/fedora .fesco 1287 https://fedorahosted.org/fesco/ticket/1287 #topic #1288 F21 System Wide Change: Changes/(A)Periodic Updates to Images - https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images .fesco 1288 https://fedorahosted.org/fesco/ticket/1288 #topic #1289 F21 System Wide Change: Playground repository - https://fedoraproject.org/wiki/Changes/Playground_repository .fesco 1289 https://fedorahosted.org/fesco/ticket/1289 #topic #1290 F21 System Wide Change: Anaconda Support for Server Roles - https://fedoraproject.org/wiki/Changes/AnacondaServerRoleSupport .fesco 1290 https://fedorahosted.org/fesco/ticket/1290 #topic #1291 F21 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 .fesco 1291 https://fedorahosted.org/fesco/ticket/1291 #topic #1292 F21 System Wide Change: Cockpit Management Console - https://fedoraproject.org/wiki/Changes/CockpitManagementConsole .fesco 1292 https://fedorahosted.org/fesco/ticket/1292 #topic #1293 F21 System Wide Change: Fedora 21 Make 4.0 Update - https://fedoraproject.org/wiki/Changes/F21Make40 .fesco 1293 https://fedorahosted.org/fesco/ticket/1293 #topic #1294 F21 System Wide Change: TCL/TK 8.6 - https://fedoraproject.org/wiki/Changes/f21tcl86 .fesco 1294 https://fedorahosted.org/fesco/ticket/1294 #topic #1295 F21 System Wide Change: SCL - https://fedoraproject.org/wiki/Changes/SCL .fesco 1295 https://fedorahosted.org/fesco/ticket/1295 #topic #1296 F21 System Wide Change: Ruby193 in SCL - https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL .fesco 1296 https://fedorahosted.org/fesco/ticket/1296 #topic #1297 F21 System Wide Change: Workstation: Enable Software Collections - https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections .fesco 1297 https://fedorahosted.org/fesco/ticket/1297 #topic #1298 F21 System Wide Change: The securetty file is empty by default - https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default .fesco 1298 https://fedorahosted.org/fesco/ticket/1298 #topic #1299 F21 System Wide Change: Smaller Cloud Image Footprint - https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint .fesco 1299 https://fedorahosted.org/fesco/ticket/1299 #topic #1300 F21 System Wide Change: Use license macro in RPMs for packages in Cloud Image - https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image .fesco 1300 https://fedorahosted.org/fesco/ticket/1300 #topic #1301 F21 System Wide Change: Workstation: Disable firewall - https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall .fesco 1301 https://fedorahosted.org/fesco/ticket/1301 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug proposal: packages that auto-enable systemd units
On Tue, Apr 22, 2014 at 12:17:10PM -0700, Andrew Lutomirski wrote: Examples of runs once then goes away services include iptables and udev. I removed udev from this paragraph on the wiki, since it's persistent and is a bad example. 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: F21 Self Contained Change: Remote Journal Logging
On Tue, Apr 22, 2014 at 06:34:48AM +0200, Lennart Poettering wrote: On Wed, 16.04.14 12:46, Bill Nottingham (nott...@splat.cc) wrote: Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) said: On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. What's the future of gatewayd if this becomes more widely used? gatewayd works in pull mode. Here I'm proposing a push model, where the client (i.e. machine generating the logs) pushes logs to the server at the time of its own chosing. gatewayd is probably better for some use cases, this for others. I understand the pull vs push distinction ... I'm just not clear why pull would ever be a model you'd want to use. (vs something like a local cockpit agent.) Pull is the only model that scales, since the centralized log infrastructure can schedule when it pulls from where and thus do this according to available resources. THe push model is prone to logging bursts overwhelming log servers if you scale your network up. How many clients would need to connect simultaneously to overwhelm the server? And overwhelm here would have to mean something like overflowing the incoming connection queue. The receiver binary doesn't have to actually read the data from the connections immedately, and things should function just fine if it takes a minute or two to process data. A typical overwhelm scenario that we might be talking about would be a massive machine restart after a power failure. A typical amount of log messages generating during boot is rather small: less than 1MB on F21. The receiver should be able to process data at around disk speed, so it should be able to handle *hundreds* of boot machines without actually developing a delay of more than a few seconds. In addition, it would be great to add jitter to starting of the uploader, which would lessen the load on the server anyway. I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. My biggest gripe with the pull model is the configuration issue mentioned by mattdm elsewhere in the thread. If I have a few machines on my home network, some VMs, a notebook or two, it is much easier to keep the configuration of the receiver stable and configure all hosts identically to push to it, then the other way around. Especially that both network addresses and host names change, so it's really hard to even to tell the receiver where to pull from. A list of hosts to pull from residing on the server is bound to become out of date. I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. It's a problem, but mostly because there's very little buffering and things are mostly synchronous. But anyway, let's get both models working... I wouldn't be surprised if both find their niches. 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: F21 Self Contained Change: Remote Journal Logging
On Tue, Apr 22, 2014 at 03:32:26PM -0400, Simo Sorce wrote: On Tue, 2014-04-22 at 20:58 +0200, Miloslav Trmač wrote: 2014-04-22 20:19 GMT+02:00 Simo Sorce s...@redhat.com: On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote: 2014-04-22 15:10 GMT+02:00 Simo Sorce s...@redhat.com: A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Isn't that an inherent capability of TCP? Sure, that's one way when bandwidth is the issue. There are other issues though, and just closing the connection on the client if you do not want any traffic is a bit blunt. It also does not give the client any idea when it is ok to retry. Not like that—just stop reading from the socket, causing the server to advertise a zero-length window to the client. The client will then know that writes are blocking / not being processed. And when the server has more capacity, free up the buffers and the kernel will send a window update to the client automatically. And you keep resources tied this way, it is better to tell the client to come back later, maybe give it a time when it is ok to come back. The amount of resources should be rather insignificant... A few hundred kilobytes of RSS on the uploader side, and an open socket and few hundred bytes of local state on the receiver side. Since it's just one uploader per client, and let's say 1kb per client on the receiver side, this shouldn't be an issue. The advantage is the simplicify of this solution. 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: F21 Self Contained Change: Remote Journal Logging
On Tue, 22.04.14 09:10, Simo Sorce (s...@redhat.com) wrote: I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. Except that the server may not need direct access to the clients (in NATted LANs for examples), so sometimes push is all you can count on, make sure you can think how to properly rate limit, give feedback to clients if necessary. A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Well, you can always turn the NAT problem around. Sometimes it's the log server behind the NAT that is the problem, sometimes it it is the log client behind the NAT that is the pronlem. If you consider push vs. pull then you simply reverse which one is the bigger issue. Note that the journal protocol is HTTP, so it's probably as proxy and NAT-friendly as it gets. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Remote Journal Logging
On Wed, 2014-04-23 at 05:36 +0200, Lennart Poettering wrote: On Tue, 22.04.14 09:10, Simo Sorce (s...@redhat.com) wrote: I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. Except that the server may not need direct access to the clients (in NATted LANs for examples), so sometimes push is all you can count on, make sure you can think how to properly rate limit, give feedback to clients if necessary. A good protocol would allow to send a first small packet that establish a connection and a reply that can push back on the client w/o requiring huge bandwidth to be spent. Well, you can always turn the NAT problem around. Sometimes it's the log server behind the NAT that is the problem, sometimes it it is the log client behind the NAT that is the pronlem. If you consider push vs. pull then you simply reverse which one is the bigger issue. Nope, 1 server means you can do port forwarding on the NAT to the specific server, all clients connect to the same NAT address port and their connection is forwarded to the server, because it is 1. The reverse would require to manually map 1 port per client. Big difference. Note that the journal protocol is HTTP, so it's probably as proxy and NAT-friendly as it gets. I already commented how bad an idea it is to use HTTP in the other thread. 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
Tuned: Restoring saved settings not working
Hi everyone, I am using Fedora20. I wanted to add a new tuned profile and used the script plugin for the same. This essentially tweaks the cpu frequency governor and min/max frequency settings. When I opt out of this profile, I want the settings to be restored. I have included the restoration functions in the file 'functions' and call the same from my script in the stop() function. However the settings are not getting restored. My observation is that the sysctl settings get restored on switching off tuned or switching to another profile but settings other than the sysctl ones like cpufreq governor or the ones set from the start() function of the shell script never get restored with a subsequent call to stop() function in the shell script in the latter case. Can someone throw some more light on this issue? Does tuned require a patch here? Regards Preeti U Murthy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Disable firewall
On Apr 22, 2014 5:09 AM, Christian Schaller cscha...@redhat.com wrote: - Original Message - From: Liam l...@fightingcrane.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, April 21, 2014 10:10:13 PM Subject: Re: F21 System Wide Change: Workstation: Disable firewall On Apr 21, 2014 4:32 AM, drago01 drag...@gmail.com wrote: On Mon, Apr 21, 2014 at 3:49 AM, Liam l...@fightingcrane.com wrote: Sent from mYphone On Apr 20, 2014 7:02 PM, drago01 drag...@gmail.com wrote: On Mon, Apr 21, 2014 at 12:39 AM, Reindl Harald h.rei...@thelounge.net wrote: There have been other suggestions in this thread that are helpful like the network zones thing (but we still have too many zones) or enabling services should make them work i.e just enable the firewall rules. which make sense Oh finally you seem to understand what this is all about (a few mails ago this was supposed to be strongly prohibited ...) Now please goolge for Psychological Acceptability and Security you will find tons of scientific papers (read them) explaining about why it is wrong to silently break stuff or ask yes / no question or arguing with this is not a blackbox the user should learn nonsense. There is difference between a software developer, a sysadmin and a user that simply wants to share his music with his family. The latter should not have to learn about computer security to do it, while for the former it does not matter that much as you said because they ought to know what to do or where to get that information from. The later isn't the target for Workstation, I don't believe. Not the *primary* target but still one see the Other users section in the PRD. -- That's fine, but that's not who we need to be optimizing the experience for. We need to be focusing on our primary target. After that others can be considered. A developer can handle this if it is presented well, but we shouldn't let secondary users harm, at all, the experience of the primary user. If we do, then this reorganization isn't working, IMHO. I think this is a misunderstanding of who a developer might be and why they choose a system. Those of my friends and acquaintances, who are developers and who over the years have decided to switch their development laptops from Linux to predominantly MacOS X, has not done so because they had things they wanted to do that was 'impossible' to do with Linux or that they thought they could not figure out how to do with linux. Instead they moved because they got tired of spending time trying to make their system 'work'. This is in no way limited to dealing with the challenges of a firewall, but if we want to attract developers or any kind of user to our system we need to make it usable without needing daily google searches to figure out how you can do something and make parts of your system work. The fact of the matter is that there's really no compelling reason for the average web developer, for instance, to move to Linux. Osx is already more powerful than any linux de (automator is something that is used often and it represents a considerably more powerful, and friendly, alternative to scripting in many instances). I'm honestly not sure how to get those folks unless osx makes it harder for professionals to do their work (supposedly their multimonitor support has worsened, but I can't confirm that). Making sane defaults, which is what we are talking about, isn't antithetical to providing an easy way for people to make changes (say, to fonts, or power settings with better granularity since, sometimes, the heuristic simply doesn't work). Specifically with regards to the current issue, others have already brought up the solution (carefully constructed zones). Along with that the firewalld gui needs to be refactored a bit, both to make it easier to diagnose problems and implement solutions. That's a decent amount of work, and perhaps no one will do it, but simply disabling functionality isn't the path to grabbing the users/contributors we want, imho. Best/Liam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[pkgdb] perl-Module-Install-Repository ownership changed
Package perl-Module-Install-Repository in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-Repository -- 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
[pkgdb] perl-Module-Install-ReadmeMarkdownFromPod ownership changed
Package perl-Module-Install-ReadmeMarkdownFromPod in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-ReadmeMarkdownFromPod -- 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
[pkgdb] perl-Module-Install-AuthorTests ownership changed
Package perl-Module-Install-AuthorTests in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Install-AuthorTests -- 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
[pkgdb] perl-Pod-Markdown ownership changed
Package perl-Pod-Markdown in Fedora EPEL 7 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Pod-Markdown -- 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 1087903] perl-CSS-Minifier for EPEL 6 and 7
https://bugzilla.redhat.com/show_bug.cgi?id=1087903 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-CSS-Minifier-0.01-15.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-CSS-Minifier-0.01-15.el6 -- 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=G81xPmfoMCa=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 1087904] perl-Text-Patch for EPEL 6 and 7
https://bugzilla.redhat.com/show_bug.cgi?id=1087904 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Text-Patch-1.8-7.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Text-Patch-1.8-7.el6 -- 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=QVZoEW693Va=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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- 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 1089994] New: perl-Email-Address-1.903 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1089994 Bug ID: 1089994 Summary: perl-Email-Address-1.903 is available Product: Fedora Version: rawhide Component: perl-Email-Address Keywords: FutureFeature, Triaged Assignee: tcall...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Latest upstream release: 1.903 Current version/release in Fedora Rawhide: 1.901-1.fc21 URL: http://search.cpan.org/dist/Email-Address/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nOu1CTG38qa=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 1089998] New: perl-libwww-perl-6.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1089998 Bug ID: 1089998 Summary: perl-libwww-perl-6.06 is available Product: Fedora Version: rawhide Component: perl-libwww-perl 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 Latest upstream release: 6.06 Current version/release in Fedora Rawhide: 6.05-3.fc20 URL: http://search.cpan.org/dist/libwww-perl/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Vdz7KKHgNMa=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
