fltk blocked?
So it seems fltk has been blocked from F-21. This in and of itself is fine but there's been no bugs filed against packages that built against it, no announcement that I can see and the package itself hasn't been retired in git, nor can I see a rel-eng ticket. Is this an oversight? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Optional Javadocs
On Tue 18 Mar 2014 07:03:31 PM CET Miloslav Trmač wrote: 2014-03-18 15:31 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: Optional Javadocs = https://fedoraproject.org/wiki/Changes/OptionalJavadocs I suppose shipping API documentation for end-user applications really doesn't make sense. Any reasonably-widely-used library should contain off-line documentation, if at all possible, IMHO. Well as-of-this-moment-current guidelines actually mandate API documentation even for end-user apps so there's room for improvement :-) Release Notes Javadoc subpackages have been made optional. Made optional is true from the packaging guidelines' point of view; for the users, some subpackages have simply been *removed*, and there's nothing optional about that. You have a point, I'll rephrase that -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpB8lkBISoS3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Five Things in Fedora This Week (2014-03-18)
On Tue, Mar 18, 2014 at 06:09:09PM -0700, Adam Williamson wrote: On Tue, 2014-03-18 at 16:50 -0400, Matthew Miller wrote: Is someone going to fix the TLS certificate? https://register.flocktofedora.org is trying to use a certificate that is only valid for rhcloud.com . https://fedorahosted.org/marketing-team/ticket/149 If Red Hat and Fedora can't manage to get TLS ducks in a row when using cloud hosting, how are RH's customers and Fedora's users going to do it... +1 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
policy on pkg-config?
Hello, Is there some policy for package maintainers and pkg-config? My issue is that a package (libev) used pkg-config for some time, but later dropped it (for legitimate reasons as upstream didn't like that). However, should we really care about upstream in cases like that? I was making a package that depended on libev and was using: pkg-config --cflags libev to obtain the CFLAGS in order to compile (libev is installed in a non-standard path in Fedora). Now in rawhide that libev doesn't install the pkg-config file, I have to hard code -I/usr/include/libev in my spec. Apart from the annoyance from having to change my spec file for such a change, I find the latter sub-optimal. Now my package hard-codes another package's installation path (that may theoretically change at any point). Wouldn't in that case, where non-standard paths are being used, be better to have the pkg-config file in fedora, even if upstream doesn't adopt it? regards, Nikos -- 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: Five Things in Fedora This Week (2014-03-18)
On Tue, Mar 18, 2014 at 09:38:27PM -0500, Michael Catanzaro wrote: One benefit of posting it on devel@ rather than news@ is that people notice it. I had never even heard of Fedora Magazine before. I'm not surprised -- we have communications gaps across the whole project. This effort is my small attempt at making that better (and, hopefully, not just adding yet another thing). Not coincidentally, this is also a goal of the new community hub web site initiative I mention in the article. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Five Things in Fedora This Week (2014-03-18)
On Tue, Mar 18, 2014 at 10:12:34PM -0500, Mukundan Ragavan wrote: I like the fact that info about Fedora magazine is posted here. While I knew about Fedora magazine, I do not always remember to check it. It would be very nice if links are also included. It would make it easier to go to specific articles. I put a lot of links in the blog post, but extensive hyperlinks get messy quickly in text email. Next week, I'll format the text with footnote links markdown-style and we'll see how that looks. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Five Things in Fedora This Week (2014-03-18)
On Tue, Mar 18, 2014 at 08:31:06PM -0700, T.C. Hollingsworth wrote: Reposting from http://fedoramagazine.org/?p=1231, for those of you who prefer email to the web. :) Perhaps these should be syndicated to Planet Fedora, for those of us who don't mind the web? Actually, I swear I've seen Fedora Magazine posts there before, but this post definitely isn't there. :-( Good idea. https://fedorahosted.org/marketing-team/ticket/147 -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On Tue, Mar 18, 2014 at 11:09:31PM -0600, Orion Poplawski wrote: - Do we do this by default, because firewalld is the default firewall in Fedora? I would not want to require firewalld though because fail2ban can work perfectly fine without it, so it would be broken by default on systems without firewalld installed (or enabled). I'm not a fan of that, as it goes from default to mandatory more quickly than it should. - Stick it in a fail2ban-firewalld sub-package that requires firewalld. Downside is that people need to figure out that they really should install this for default installs. Upside is it is easier to use without firewalld (don't need to find and remove the fedora-firewalld.conf file). This gets my vote. An alternate approach would be to make fail2ban be a virtual package that requires fail2ban-firewalld and a new fail2ban-server subpackage which contains the actual thing. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next ? The Workstation WG, looks like a Gnome only thing, will there be at place of users of other DE's in Fedora.next ? Best Regards Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Wed, Mar 19, 2014 at 7:52 AM, Tim Lauridsen tim.laurid...@gmail.com wrote: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next ? They still exist. The Workstation WG, looks like a Gnome only thing, will there be at place of users of other DE's in Fedora.next ? Workstation uses GNOME as the default DE. It would like to also include KDE in some capacity and treat that as blocker. Any other DE that wants to meet the requirements for Workstation is similarly welcome. For those that choose to not participate in Workstation, the existing spins mechanisms that are used today will still be present. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2014 07:52 AM, Tim Lauridsen wrote: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next ? The Workstation WG, looks like a Gnome only thing, will there be at place of users of other DE's in Fedora.next ? Fedora Products will be effectively a set of add-on guarantees atop the software distribution that is The Fedora Project. When you say today I'm running Fedora, that really isn't a meaningful statement. About all it tells someone is that you're running the latest upstream kernel on an RPM-based distribution with mostly the newest versions of whichever packages you have installed. We're *not* taking that away. You will always be able to turn The Fedora Project into whatever custom distribution you want it to be. However, when you install a Fedora Product, what you get will be something more than that. It will define a minimum set of known packages and interfaces upon which other software can build. In the case of the Fedora Workstation, that essentially means that a third-party software application can count on having the GNOME Desktop and all its dependent libraries, plus the QT libraries available on the system. It provides a stronger guarantee about which set of APIs are official and see better testing. If you decide you don't want some of those things, you can remove them and the system will no longer self-identify as Fedora Workstation. In that case, it will just be the classic Fedora again. Or, you can choose to just install whichever desktop you want atop Fedora Workstation and use it (provided that it can be started from GDM, if I understand the Product guarantees correctly; someone from the Workstation WG can correct me here if I am mistaken). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMpiFUACgkQeiVVYja6o6OFrQCdHHR5kYuPWXHq4DII1SIePBlo /FgAoK3fTCGfU+rZOAx1VlUmbAnlYQ0p =V3AP -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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Wed, Mar 19, 2014 at 12:52:07PM +0100, Tim Lauridsen wrote: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next ? We had a big discussion about this last month. General consensus is that we don't see spins going away, at least in the near future. The Fedora products are intended to be focused more on areas of user need rather than on a particular technology, whereas the desktop spins are by their nature showcases of that specific software. We want to focus on marketing the use-focused solutions, but we also need a place for the other. The Workstation WG, looks like a Gnome only thing, will there be at place of users of other DE's in Fedora.next ? The Workstation WG has selected Gnome as the base technology for the Fedora Workstation, but it's a mistake to say that it's a Gnome-only thing. Half of the members of the WG aren't Gnome folks. There has been some talk of adding alternate desktop environments to the (Gnome-based) Software Center. That way, if the desktop spin approach isn't satisfying for you -- or if you just came to Fedora through the Workstation download -- it would be easy to add another DE to your running system. There is also a proposal for a Fedora Plasma product based around KDE. I'm personally a little skeptical but listening -- I think want a technology showcase masquerading as a product would miss the point, and I'd like to be convinced that this is more than that. We have an open question in FESCo over whether KDE should be release blocking (there's a ticket for today's meeting), and there's some debate over whether it's necessary for a desktop to be represented at the product level in order to be considered blocking. (And I think that this issue is driving the product push to some degree.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 03/19/2014 01:09 PM, Matthew Miller wrote: There is also a proposal for a Fedora Plasma product based around KDE. I'm personally a little skeptical but listening -- I think want a technology showcase masquerading as a product would miss the point, and I'd like to be convinced that this is more than that. We have an open question in FESCo over whether KDE should be release blocking (there's a ticket for today's meeting), and there's some debate over whether it's necessary for a desktop to be represented at the product level in order to be considered blocking. (And I think that this issue is driving the product push to some degree.) My take on this is: KDE should be release blocking. It's strongly represented in Fedora, both in terms of users and available developer resources. We should make sure KDE is fully functional before rolling out a Fedora release. KDE should not be a top level Product. In my opinion, Fedora should only produce the currently listed 3 Products and not more. Otherwise we get back at square 1 where we have too many offerings and nobody knows what makes a supported Fedora. KDE should stay a separate spin with its own install media. Just as it is now; nobody is taking that away. And possibly it could evolve a bit more towards a separate derivative, with it's own home page and marketing; similar to how Kubuntu is to Ubuntu now. -- Kalev, Fedora Workstation WG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Wed, Mar 19, 2014 at 01:29:24PM +0100, Kalev Lember wrote: KDE should be release blocking. It's strongly represented in Fedora, both in terms of users and available developer resources. We should make sure KDE is fully functional before rolling out a Fedora release. Should this (the release blocking part) be as part of the Workstation WG, or independent of that? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] Update to Django-1.6
devel-boun...@lists.fedoraproject.org wrote on 03/18/2014 08:11:04: From: mru...@matthias-runge.de To: devel@lists.fedoraproject.org Date: 03/18/2014 08:11 Subject: [HEADS UP] Update to Django-1.6 Sent by: devel-boun...@lists.fedoraproject.org Hey there, now that we can have python-django15 in f21, I'll upgrade python-django to Django-1.6 in a week. Any interest, to have this on F20, too? python-django15 is installable in parallel, no penguin will be harmed, but the upgrade to Django-1.6 might hurt one or the other. Matthias -- Matthias Runge mru...@matthias-runge.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I'd like to see 1.6 for F20. That would let me remove some hacks (in private code). -- 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Tue, 18.03.14 21:39, Chris Murphy (li...@colorremedies.com) wrote: Combining x-systemd.automount + noauto however is a way to establish a mount point and only lazily triggering it on access. And that's what you want to use here. That does work. It's automounted on any command I threw at it, including kernel install, update, or remove. It's a bit half-hearted of a solution for the problem, since it doesn't umount the volume. It has been on our TODO list for a while to implement expiration for .automount units. It's kinda messy however, since the protocol for that involves blocking ioctls and thus would require us to do threads for this from PID1. It's a really messy kernel API. But anyway, this is certainly on our TODO list. In fact, this is really something we want to have in place for removable media too, one day, so that the file systems are quickly unmounted after use and hence highly likely to be in a clean state when removed without manual umounting. 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Wed, 19.03.14 15:01, William Brown (will...@firstyear.id.au) wrote: Why not also extend this to /boot also? It's rarely used in day to day on a system, really only for yum updates that include a kernel. [root@strawberry ~]# lsof | grep /boot [root@strawberry ~]# To establish the automount point /boot/efi you need /boot mounted. You cannot have an automount point nested into an automount point. It's one of the reasons why I really really dislike the invention of /boot/efi as the mount point for the ESP... 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
Summary of accepted Fedora 21 Changes - week 11
Greetings! This is a summary of FESCo's accepted Fedora 21 Changes for week 11 (2014-03-12 meeting). Reminder: the Change Submission deadline for System Wide Change is due in less than three weeks! = System Wide Changes = * cron to systemd time units URL: https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196284.html Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units. * System-wide crypto policy URL: https://fedoraproject.org/wiki/Changes/CryptoPolicy Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-February/196041.html Unify the crypto policies used by different applications and libraries. That is allow setting a consistent security level for crypto on all applications in a Fedora system. The implementation approach will be to initially modify SSL libraries to respect the policy and gradually adding more libraries and applications. * Access control in PCSC URL: https://fedoraproject.org/wiki/Changes/PcscAccessControl Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-February/196038.html Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware * Remove python-setuptools-devel URL: https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-February/196036.html The python-setuptools package has carried a virtual Provide for python-setuptools-devel since 2009 for backwards compatibility. We're going to remove this virtual Provide. Packages which still BuildRequire python-setuptools-devel will need to be updated to Require: python-setuptools instead. * Ruby 2.1 URL: https://fedoraproject.org/wiki/Changes/Ruby_2.1 Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-February/196039.html Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. * Lohit Odia Gurmukhi font naming URL: https://fedoraproject.org/wiki/Changes/Lohit_Odia_Gurmukhi Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196238.html This is a change to make Lohit Oriya fonts name as per the guidelines by Odisha governement and improve Lohit Punjabi font name to avoid confusion between Arabic and Gurmukhi script fonts. It will change Lohit Oriya fonts to Lohit Odia and Lohit Punjabi to Lohit Gurmukhi. = Self Contained Changes = * OpenCL URL: https://fedoraproject.org/wiki/Changes/OpenCL Announcement: https://lists.fedoraproject.org/pipermail/devel/2013-November/191694.html This change will bring basic OpenCL support to Fedora to support the development of OpenCL enabled software and the development of OpenCL implementations itself. The change includes enabling Mesa's OpenCL state-tracker (in 10.0 with ICD support), packaging pocl - an CPU only OpenCL implementation - and the introduction of several other OpenCL related packages. --- The list of Changes to be discussed on the next FESCo meeting: https://fedoraproject.org/wiki/Category:ChangeReadyForFesco 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 03/19/2014 01:35 PM, Matthew Miller wrote: On Wed, Mar 19, 2014 at 01:29:24PM +0100, Kalev Lember wrote: KDE should be release blocking. It's strongly represented in Fedora, both in terms of users and available developer resources. We should make sure KDE is fully functional before rolling out a Fedora release. Should this (the release blocking part) be as part of the Workstation WG, or independent of that? No, I meant independently. Workstation might implement easy installation of alternative desktops in the GNOME Software app at some point. When something like this is in place, it probably makes sense to make sure it's also working before releasing. But that's a future thing. I would like to see more focus in Fedora. And to me, having these 3 core Products is a good way of doing that. Instead of saying that everything in Fedora is equal, we would now say that these 3 products are the main deliverable. But even if we say that having only 3 products is set in stone and promote them as the main offering, it doesn't mean that other, existing spins should go away. I would like them to flourish. Since KDE has the man power to fix thing, if their developers agree to that, I think it makes sense to say that KDE spin is release blocking: we wait for fixes to land, and don't release Fedora with a broken KDE. But that's of course the KDE SIG's decision to make. I am just expressing my ideas. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Wed, Mar 19, 2014 at 02:27:45PM +0100, Kalev Lember wrote: I would like to see more focus in Fedora. And to me, having these 3 core Products is a good way of doing that. Instead of saying that everything in Fedora is equal, we would now say that these 3 products are the main deliverable. But even if we say that having only 3 products is set in stone and promote them as the main offering, it doesn't mean that other, existing spins should go away. I would like them to flourish. I'm totally with you here. The argument I'm hearing, though, is that if release blocking isn't a defining characteristic of a Fedora product, it weakens what *that* means. Anyone who agrees with that (or some variant of it) care to elaborate? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On Wed, Mar 19, 2014 at 12:09 AM, Orion Poplawski or...@cora.nwra.comwrote: fail2ban doesn't work out of the box with firewalld. However, we can drop a config file at /etc/fail2ban/jail.d/fedora-firewalld.conf to enable it. Where is this configuration file available? I'd love to have a copy until this get's figured out. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fltk blocked?
On Wed, 19 Mar 2014 08:05:40 + Peter Robinson pbrobin...@gmail.com wrote: So it seems fltk has been blocked from F-21. This in and of itself is fine but there's been no bugs filed against packages that built against it, no announcement that I can see and the package itself hasn't been retired in git, nor can I see a rel-eng ticket. Is this an oversight? It was a mistake by one of the owners, they accidentally retired it. It should be all cleaned up now, if you still see it blocked anywhere, please let rel-eng know. 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: fail2ban + firewalld suggestions needed
On 03/19/2014 07:42 AM, Richard Shaw wrote: On Wed, Mar 19, 2014 at 12:09 AM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: fail2ban doesn't work out of the box with firewalld. However, we can drop a config file at /etc/fail2ban/jail.d/fedora-firewalld.conf to enable it. Where is this configuration file available? I'd love to have a copy until this get's figured out. Thanks, Richard See https://bugzilla.redhat.com/show_bug.cgi?id=1046816 You are going to need fail2ban-0.9-2 - f20 build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=6651548. More testing would be much appreciated. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Five Things in Fedora This Week (2014-03-18)
On 18 March 2014 22:50, Matthew Miller mat...@fedoraproject.org wrote: Reposting from http://fedoramagazine.org/?p=1231, for those of you who prefer email to the web. :) Fedora is big project, and it’s hard to follow it all. This new Fedora Magazine feature will highlight interesting happenings in five different areas every week. It won’t be comprehensive news coverage — just quick summaries and links to each. So, here we go for March 18th, 2014: Flock 2014 registration and talk proposals open --- In case you missed the article in Fedora Magazine a few days ago… don’t miss it. The website at http://flocktofedora.org/, and the talk proposal deadline is coming up fast: April 3rd, 2014. Fedora 21 feature planning in progress -- Looking to do something new for Fedora 21? The initial schedule is set and many changes are already accepted by FESCo. Submission deadline is April 8th, 2014. If you have something to add, find out how at http://fedoraproject.org/wiki/Changes/Policy. Ambassadors discuss inactive memberships https://lists.fedoraproject.org/pipermail/ambassadors/2014-March/022263.html Interesting discussion on Fedora Ambassadors mailing list about a process for marking the memberships of people who aren’t actively participating as inactive. Looks like there’s wide support for the low-overhead, non-punitive proposal (which allows easy reactivation). KDE talks about Fedora Products --- https://lists.fedoraproject.org/pipermail/kde/2014-March/013196.html Another interesting discussion: KDE SIG is working on a proposal for “Fedora Plasma”, a desktop product focused at educational and scientific use. FESCo and the Fedora Advisory Board have previously approved the governance and PRDs for Cloud, Server, and Workstation (the latter of which recently elected to use Gnome as the base). It will be interesting to see how this all fits together. Planning for new Fedora web design -- The Fedora Websites and Design teams are working on refreshed websites in support of Fedora.next. I’m cheating a bit because some this is more than a week old, but it’s all still in progress. This includes an ambitious plan for a new community hub, although initial work focuses on updating the Get Fedora “brochure” site. Endnote --- So that’s it for this week. If something didn’t make the list and you think it should have, that probably just means I missed it, not that it wasn’t important. Please drop me a line and we’ll make this better next time. Bonus mailing list questions! - [...] Is it helpful to post this here? Yes; for me at least as I didn't even know there was a Fedora magazine. If so, is full text important, or is posting a link to the web site fine? Full text is better, if someone doesn't click the link to the web page (maybe he/she is in a hurry, or can't be bothered :)), he can skim through the email, usually topics of interest catch one's eye. After all an email is an email, no point making it too short (nor too long of course). Would it be helpful to post it to other lists as well or instead? What about repurposing the defunct news mailing list for just this purpose? Ideally it should be to -dev and -users, some are only subscribed to one or the other. I didn't know there was a news ML; but if an ML dies, then there were reasons for that, if those reasons haven't changed then there's no point trying to revive it. Just the occasional email (1 per month/week), doesn't need a separate ML IMHO. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ahmad Samir -- 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 Present and Future: a Fedora.next 2014 Update (Part I, “Why?”)
I promised a while ago that I would provide a text version of my talk at DevConf, for people who couldn't make it and because sitting through a video of me standing up there going on and on doesn't really make for good followup discussion. Because it grew rather long, I think it works best as a web article, which you can find on Fedora Magazine at http://fedoramagazine.org/?p=1236. Also because of the length, I'm posting it installments. This part is the background, next part is some of the things we are doing, followed by the panel discussion, followed by QA. Whew; that's a lot. I can post the text here if people think it'd be really helpful to do so, (although I'm inclined to think that would be unwieldy), and in any case I will take questions, comments, complaints, in any media including replies here, on the article, on the social media, or at any bar or coffee shop within walking distance of Boston's MBTA. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
AppStream Logs and False Positives
Quite a few people have asked me how the AppStream distro metadata is actually generated for their package. Since F20 we're also doing things like supply missing AppData files for some key apps, and replacing some upstream screenshots on others. In order to make this more transparent, I'm going to be uploading the logs of each generation run to https://github.com/hughsie/createrepo_as_logs -- If you've got a few minutes I'd appreciate you finding your application there and checking for any warnings or errors, and perhaps forwarding any findings to upstream. Although over 10% of applications in rawhide ship AppData, that means a huge chunk don't and also quite a few upstreams don't even have things like translated desktop files. Also, if you maintain a GUI application that's in Fedora but not in that list then please send me email or grab me on IRC. The guidelines for inclusion are https://github.com/hughsie/createrepo_as#guidelines-for-applications -- thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fltk blocked?
On 03/19/2014 04:05 AM, Peter Robinson wrote: fltk has been blocked from F-21 Huh? What are you refering to? indeed there are no recent builds for 21 in the main koji (last one is from August) http://koji.fedoraproject.org/koji/packageinfo?buildOrder=nvrpackageID=1740tagOrder=nametagStart=0#buildlist but I see fltk-1.3.2 being built today for FC21 on ARM: http://arm.koji.fedoraproject.org/koji/packageinfo?buildOrder=owner_namepackageID=1913tagOrder=blockedtagStart=0 -- 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: fltk blocked?
On Wed, Mar 19, 2014 at 4:27 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 03/19/2014 04:05 AM, Peter Robinson wrote: fltk has been blocked from F-21 Huh? What are you refering to? indeed there are no recent builds for 21 in the main koji (last one is from August) See Kevin's response. http://koji.fedoraproject.org/koji/packageinfo?buildOrder=nvrpackageID=1740tagOrder=nametagStart=0#buildlist but I see fltk-1.3.2 being built today for FC21 on ARM: http://arm.koji.fedoraproject.org/koji/packageinfo?buildOrder=owner_namepackageID=1913tagOrder=blockedtagStart=0 Completely unrelated, the problem has since been fixed this morning. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Five Things in Fedora This Week (2014-03-18)
On Wed, 19 Mar 2014 07:34:41 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Tue, Mar 18, 2014 at 08:31:06PM -0700, T.C. Hollingsworth wrote: Reposting from http://fedoramagazine.org/?p=1231, for those of you who prefer email to the web. :) Perhaps these should be syndicated to Planet Fedora, for those of us who don't mind the web? Actually, I swear I've seen Fedora Magazine posts there before, but this post definitely isn't there. :-( Good idea. https://fedorahosted.org/marketing-team/ticket/147 It was subscribed, but the feed url changed and the change wasn't reflected in the planet config. ;) Fixed now. 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: policy on pkg-config?
2014-03-19 11:30 GMT+01:00 Nikos Mavrogiannopoulos n...@redhat.com: Hello, Is there some policy for package maintainers and pkg-config? My issue is that a package (libev) used pkg-config for some time, but later dropped it (for legitimate reasons as upstream didn't like that). However, should we really care about upstream in cases like that? Very broadly, this isn't too different from upstream making any other API-breaking change. We sometimes complain to them, sometimes help them stop doing that in the future, but typically we don't diverge from upstream to revert an API break. Specific circumstances can of course be different. Apart from the annoyance from having to change my spec file for such a change, I find the latter sub-optimal. Now my package hard-codes another package's installation path (that may theoretically change at any point). Wouldn't in that case, where non-standard paths are being used, be better to have the pkg-config file in fedora, even if upstream doesn't adopt it? We do have some precedents in this area (openssl adding a pkg-config file to record flags necessary for our Kerberos-enabled build, adding a pkg-config file to avoid a multi-lib conflict in /usr/bin/$library-config), but those I can think about are motivated by needing to solve a specific problem. We don't have a general policy to require all libraries to provide a pkg-config file, or anything similarly broad AFAIK. 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
2014-03-19 5:31 GMT+01:00 William Brown will...@firstyear.id.au: On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote: RFE: Do not persistently mount EFI System partition at /boot/efi https://bugzilla.redhat.com/show_bug.cgi?id=1077984 It's still better to remove the on-going writing of configuration files to the ESP, however. A simple one-time forwarding-configuration file pointing to the /boot volume UUID, permits configuration files to be written somewhere on /boot, which can then be md raid1 or btrfs raid1 based. Boot is made more resilient whether single or multiple disk. This works today on BIOS, but not on UEFI. Why not also extend this to /boot also? It's rarely used in day to day on a system, really only for yum updates that include a kernel. Well, why not also extend this to any rarely-used directory like perhaps /usr/share/zoneinfo, or even any top-level directory? - It doesn't make anything easier (well, it does in Chris' RFE under the assumption that the partition is frequently being corrupted, but that shouldn't be happening in the first place; unlike /boot/efi we do have the technology to minimize these occurrences for other partitions). - It makes the system more complex and more difficult to understand. - The auto-mounting also requires system resources, probably quite comparable to keeping the partition simply mounted. - Problems with the filesystem could go undetected for a long time. This is especially problematic for /boot, consider (admittedly the worst case) - The /boot metadata or journal becomes corrupted (by a disk error, or an errant write) - If the kernel used to boot isn't directly affected, the system will continue to boot - After a few weeks, the user initiates a kernel upgrade, triggering an auto mount and a journal replay that makes the metadata corruption visible and problematic, perhaps making it impossible to boot even the *old* kernel 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Wed, Mar 19, 2014 at 03:01:27PM +1030, William Brown wrote: On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote: Fedora takes a different approach though, and will mount an explicit boot partition to /boot and the ESP to /boot/efi, and do so unconditionally without involving autofs. Fedora could add x-systemd-automount to the mount options of /boot/efi, and thus turning /boot/efi into an autofs too. RFE: Do not persistently mount EFI System partition at /boot/efi https://bugzilla.redhat.com/show_bug.cgi?id=1077984 It's still better to remove the on-going writing of configuration files to the ESP, however. A simple one-time forwarding-configuration file pointing to the /boot volume UUID, permits configuration files to be written somewhere on /boot, which can then be md raid1 or btrfs raid1 based. Boot is made more resilient whether single or multiple disk. This works today on BIOS, but not on UEFI. Why not also extend this to /boot also? It's rarely used in day to day on a system, really only for yum updates that include a kernel. Speak for yourself. libguestfs uses /boot/vmlinuz, as do other packages, as does anyone wanting to see how the kernel was configured, or to look at or change grub configuration, and so on. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- 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: Ruby on Rails 4.1
Jaroslav Reznik (jrez...@redhat.com) said: * Other developers: Update Rails dependent packages to be working with Ruby on Rails 4.1 Looking at the repo, the only toplevel 'app' that this would appear to cover would be OpenShift Origin, which is already called out on the feature page? 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
Schedule for Thursday's FPC Meeting (2014-03-20 17:00 UTC) (US still on DST)
Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. NOTE: US is on DST, so it's an hour later for them than normal. Local time information (via. rktime): 2014-03-20 10:00 Thu US/Pacific PDT 2014-03-20 13:00 Thu US/Eastern EDT 2014-03-20 17:00 Thu UTC - 2014-03-20 17:00 Thu Europe/London - 2014-03-20 18:00 Thu Europe/Paris CET 2014-03-20 18:00 Thu Europe/Berlin CET 2014-03-20 22:30 Thu Asia/Calcutta IST --new day-- 2014-03-21 01:00 Fri Asia/Singapore SGT 2014-03-21 01:00 Fri Asia/Hong_Kong HKT 2014-03-21 02:00 Fri Asia/Tokyo JST 2014-03-21 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #391 Exception for bundled libraries in icecat .fpc 391 https://fedorahosted.org/fpc/ticket/391 #topic #397 Please, choose an ID number for a new group called input .fpc 397 https://fedorahosted.org/fpc/ticket/397 (remaining votes needed, concrete autodeps example needed) #topic #398 Tilde in version .fpc 398 https://fedorahosted.org/fpc/ticket/398 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (remaining votes needed) #topic #402 Promote /usr/lib/rpm/macros.d over /etc/rpm .fpc 402 https://fedorahosted.org/fpc/ticket/402 (remaining votes needed) #topic #404 Update python packaging guidelines .fpc 404 https://fedorahosted.org/fpc/ticket/404 = New business = #topic #405 Downstream versioning of shared libraries. .fpc 405 https://fedorahosted.org/fpc/ticket/405 #topic #407 Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng .fpc 407 https://fedorahosted.org/fpc/ticket/407 #topic #408 Temporary jquery bundling exception for libserialport .fpc 408 https://fedorahosted.org/fpc/ticket/408 #topic #409 Ruby guidelines: Updates for F21 .fpc 409 https://fedorahosted.org/fpc/ticket/409 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 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/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Mar 19, 2014, at 7:02 AM, Lennart Poettering mzerq...@0pointer.de wrote: It's one of the reasons why I really really dislike the invention of /boot/efi as the mount point for the ESP… I agree, although I go farther. The EFI System partition doesn't scale, isn't resilient, can neither be mirrored nor easily sync'd (multidevice boot). It should be considered a pre-boot and OS installer domain only. Are bootloader updates necessary? On BIOS this is ignored, no updates effectively happen, even if the grub package is update, grub2-install isn't invoked so no update really occurs to the bootloader. On UEFI it's the opposite. An updated grub-efi package causes grubarch.efi to be overwritten, and invoking grub2-install will break Secure Boot systems. If UEFI bootloader updates are considered necessary then we need a better way than assuming there's only one ESP, by only updating the one at /boot/efi. Because that's not necessarily the one being executed by the firmware. The bootloader RPM would need to mount all ESP's on the system, replace-existing, unmount. So whether yes/no to bootloader updates, /boot/efi either isn't needed or doesn't meet the requirements. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
Am 19.03.2014 20:14, schrieb Jonathan Underwood: On 19 March 2014 15:10, Orion Poplawski or...@cora.nwra.com wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=1046816 You are going to need fail2ban-0.9-2 - f20 build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=6651548. More testing would be much appreciated. On a default F20 install with that package I had to do the following to get a minimal ssh jail up and running (this is info for those following along, not Orion who no doubt knows this)... In /etc/fail2ban/jail.d/ajil.local [DEFAULT] bantime = 3600 banaction = firewallcmd-ipset backend = systemd [sshd] enabled = true So, it seems to me that at the very least we should set backend = systemd in the Fedora, else it's not going to work out of the box (or, more ugly, require rsyslog). As to the original question I'd favour enabling the firewalld support in Fedora by default. Anyone disabling (or chosing not to install) firewalld and installing fail2ban should know enough to configure things appropriately but with not take care of it you would end in having firewalld as mandatory dependency which is the main point of that thread - there are still way too much circular dependencies making it hard to strip down a setup 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: fail2ban + firewalld suggestions needed
Am 19.03.2014 20:21, schrieb Jonathan Underwood: On 19 March 2014 19:16, Reindl Harald h.rei...@thelounge.net wrote: but with not take care of it you would end in having firewalld as mandatory dependency which is the main point of that thread - there are still way too much circular dependencies making it hard to strip down a setup I didn't advocate having fail2ban having a hard Requires for firewalld, nor anything else creating a circular dependence. I was simply advocating having a configuration file that would work for the most common case and what installs that config file is the question and how sub-packages are done with care since there are no soft Requires 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: fail2ban + firewalld suggestions needed
On 19 March 2014 19:23, Reindl Harald h.rei...@thelounge.net wrote: Am 19.03.2014 20:21, schrieb Jonathan Underwood: On 19 March 2014 19:16, Reindl Harald h.rei...@thelounge.net wrote: but with not take care of it you would end in having firewalld as mandatory dependency which is the main point of that thread - there are still way too much circular dependencies making it hard to strip down a setup I didn't advocate having fail2ban having a hard Requires for firewalld, nor anything else creating a circular dependence. I was simply advocating having a configuration file that would work for the most common case and what installs that config file is the question and how The main package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes of today's FESCo Meeting (2014-03-19)
=== #fedora-meeting: FESCO (2014-03-19) === Meeting started by nirik at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-03-19/fesco.2014-03-19-18.00.log.html . Meeting summary --- * init process (nirik, 18:00:02) * ticket #1221 Product working group activity reports (nirik, 18:02:39) * LINK: https://fedorahosted.org/fesco/ticket/1221 (nirik, 18:02:39) * cloud is going through the list of changes we said we would file, finding owners, and filing them. (mattdm, 18:03:38) * cloud also discussing Fedora Atomic / ostree (for Docker-focused image, not general one) (mattdm, 18:04:18) * env and stacks working on proposal for playground repo (nirik, 18:05:06) * server working group is working on role d-bus api (nirik, 18:05:30) * base design has no big news but is reviewing tech specs (mattdm, 18:05:32) * #1243 Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making (nirik, 18:14:05) * LINK: https://fedorahosted.org/fesco/ticket/1243 (nirik, 18:14:05) * more discussion on this on devel list currently (nirik, 18:16:23) * AGREED: defer to next week (nirik, 18:17:32) * ticket #1250 F21 Self Contained Changes (nirik, 18:17:39) * LINK: https://fedorahosted.org/fesco/ticket/1250 (nirik, 18:17:39) * AGREED: all 3 self contained changes approved. (+8,0,0) (nirik, 18:22:50) * ticket #1253 requesting exception for linking cscppc and cswrap with glibc-static (nirik, 18:22:54) * LINK: https://fedorahosted.org/fesco/ticket/1253 (nirik, 18:22:54) * AGREED: ask submittor if they cannot just build for any branches they need support for and revisit next week. (+6,0,0) (nirik, 18:36:50) * ticket #1255 girara+zathura: update policy exception request (nirik, 18:37:01) * LINK: https://fedorahosted.org/fesco/ticket/1255 (nirik, 18:37:01) * AGREED: exception granted (+6,0,0) (nirik, 18:39:01) * ticket #1256 non responsive maintainer fast track (nirik, 18:39:11) * LINK: https://fedorahosted.org/fesco/ticket/1256 (nirik, 18:39:11) * AGREED: will orphan packages and allow other maintainers to pick things up (+7,0,0) (nirik, 18:41:10) * ticket #1257 F21 System Wide Change: u-boot syslinux by default - https://fedoraproject.org/wiki/Changes/u-boot_syslinux (nirik, 18:41:19) * LINK: https://fedorahosted.org/fesco/ticket/1257 (nirik, 18:41:20) * AGREED: change approved (+8,0,0) (nirik, 18:43:50) * ticket #1258 Coordinate FESCo at Flock 2014 (nirik, 18:44:09) * LINK: https://fedorahosted.org/fesco/ticket/1258 (nirik, 18:44:09) * ACTION: mattdm will talk to flock planners about scheduling fedora.next talk and discussion as keynote (mattdm, 18:52:35) * ACTION: mattdm will also schedule fesco panel (mattdm, 18:54:58) * ticket #1259 F21 System Wide Change: jQuery - https://fedoraproject.org/wiki/Changes/jQuery (nirik, 18:55:35) * LINK: https://fedorahosted.org/fesco/ticket/1259 (nirik, 18:55:35) * AGREED: change is approved (+7,0,0) (nirik, 18:57:36) * ticket #1260 F21 System Wide Change: Xorg without root rights - https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights (nirik, 18:57:43) * LINK: https://fedorahosted.org/fesco/ticket/1260 (nirik, 18:57:43) * AGREED: change approved (+7,0,0) (nirik, 19:08:31) * Chair next week (nirik, 19:09:05) * mitr to chair next week (nirik, 19:09:54) * sgallagh wants to chair the following week. (nirik, 19:10:13) * Open Floor (nirik, 19:10:19) Meeting ended at 19:22:23 UTC. Action Items * mattdm will talk to flock planners about scheduling fedora.next talk and discussion as keynote * mattdm will also schedule fesco panel Action Items, by person --- * mattdm * mattdm will talk to flock planners about scheduling fedora.next talk and discussion as keynote * mattdm will also schedule fesco panel * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (127) * pjones (59) * mattdm (52) * sgallagh (34) * mitr (33) * abadger1999 (31) * dgilmore (31) * notting (26) * zodbot (15) * jreznik (13) * hansg (11) * jwb (4) * Viking-Ice (1) * t8m (0) * mmaslano (0) -- 18:00:02 nirik #startmeeting FESCO (2014-03-19) 18:00:02 zodbot Meeting started Wed Mar 19 18:00:02 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:02 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 nirik #meetingname fesco 18:00:02 nirik #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:02 nirik #topic init process 18:00:02 zodbot The meeting name has been set to 'fesco' 18:00:02 zodbot Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:16 mitr Hello 18:00:29
Re: fail2ban + firewalld suggestions needed
On 19 March 2014 19:16, Reindl Harald h.rei...@thelounge.net wrote: Am 19.03.2014 20:14, schrieb Jonathan Underwood: On 19 March 2014 15:10, Orion Poplawski or...@cora.nwra.com wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=1046816 You are going to need fail2ban-0.9-2 - f20 build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=6651548. More testing would be much appreciated. On a default F20 install with that package I had to do the following to get a minimal ssh jail up and running (this is info for those following along, not Orion who no doubt knows this)... In /etc/fail2ban/jail.d/ajil.local [DEFAULT] bantime = 3600 banaction = firewallcmd-ipset backend = systemd [sshd] enabled = true So, it seems to me that at the very least we should set backend = systemd in the Fedora, else it's not going to work out of the box (or, more ugly, require rsyslog). As to the original question I'd favour enabling the firewalld support in Fedora by default. Anyone disabling (or chosing not to install) firewalld and installing fail2ban should know enough to configure things appropriately but with not take care of it you would end in having firewalld as mandatory dependency which is the main point of that thread - there are still way too much circular dependencies making it hard to strip down a setup I didn't advocate having fail2ban having a hard Requires for firewalld, nor anything else creating a circular dependence. I was simply advocating having a configuration file that would work for the most common case. Cheers, Jonathan. -- 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: fail2ban + firewalld suggestions needed
On 19 March 2014 15:10, Orion Poplawski or...@cora.nwra.com wrote: See https://bugzilla.redhat.com/show_bug.cgi?id=1046816 You are going to need fail2ban-0.9-2 - f20 build is here http://koji.fedoraproject.org/koji/taskinfo?taskID=6651548. More testing would be much appreciated. On a default F20 install with that package I had to do the following to get a minimal ssh jail up and running (this is info for those following along, not Orion who no doubt knows this)... In /etc/fail2ban/jail.d/ajil.local [DEFAULT] bantime = 3600 banaction = firewallcmd-ipset backend = systemd [sshd] enabled = true So, it seems to me that at the very least we should set backend = systemd in the Fedora, else it's not going to work out of the box (or, more ugly, require rsyslog). As to the original question I'd favour enabling the firewalld support in Fedora by default. Anyone disabling (or chosing not to install) firewalld and installing fail2ban should know enough to configure things appropriately. Cheers, Jonathan -- 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
I think dynamically mounted /boot is a separate conversation. It's only relevant here in that if x-systemd.automount,noauto behavior is desired for /boot, then for sure that means we need a better way for the EFI System partition because we can't have nested automounts. As for resources, the automount is super fast. As in, I can't tell it's not already mounted, even when fsck.fat is used at first mount time. All Fedora products use systemd, which is what implements this. So I think that's pretty minimal. The two easy changes currently on the table for /boot/efi apply only to anaconda: 1. Do run fsck on the EFI System partition. We don't now. https://bugzilla.redhat.com/show_bug.cgi?id=1077917 2. Change EFI System partition mount option to include both x-systemd.automount,noauto. https://bugzilla.redhat.com/show_bug.cgi?id=1077984 These changes significantly reduce the likelihood of accumulating ESP corruption, and hopefully fixing it in time if it does occur. But this doesn't solve all the problems, only the corruption angle. The real solution is to: 1. Anaconda always creates ESPs on each selected device for install. 2. Anaconda always installs bootloader binaries to each selected devices' ESP. 3. Anaconda writes a simple one-time static config, the only variable data are /boot volume UUID, and path prefix pointing to the updated configuration file(s), as EFI/fedora/grub.cfg. 4. Anaconda + grub2-mkconfig -o /boot/grub2/grub.cfg - grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg ** By virtue of putting grub.cfg on /boot again, if /boot is on md or Btrfs raid, we get bootloader configuration file syncing for free across all disks. The disk ESP contains only generic information so it's also much easier to restore, simple copy is all that's needed. Something one day a DE could do when we ask it to rebuild a replacement raid member device. 5. Bootloader package change to mount each ESP and update them; if bootloader updatability is considered important. 6. Now we can get rid of /boot/efi and any need for persistently mounted ESP. X. Set x-systemd.automount,noauto on /boot. This is not part of this RFC/RFE, but could be seen as making it easy to go down this road if we want since it only means making an fstab change. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On 03/19/2014 05:38 AM, Matthew Miller wrote: On Tue, Mar 18, 2014 at 11:09:31PM -0600, Orion Poplawski wrote: - Stick it in a fail2ban-firewalld sub-package that requires firewalld. Downside is that people need to figure out that they really should install this for default installs. Upside is it is easier to use without firewalld (don't need to find and remove the fedora-firewalld.conf file). This gets my vote. An alternate approach would be to make fail2ban be a virtual package that requires fail2ban-firewalld and a new fail2ban-server subpackage which contains the actual thing. Hmm, I like this alternative a lot. I'm probably taking this too far, but I'm thinking of: fail2ban-server - core components with minimal deps fail2ban-firewalld - firewalld support/configuration - requires firewalld fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires tcp_wrappers fail2ban-mail - mail actions- requires /usr/bin/mail fail2ban-sendmail - sendmail actions- requires /usr/sbin/sendmail fail2ban-shorewall - shorewall support - requires shorewall fail2ban-systemd - systemd journal configuration fail2ban - default component - installs -firewalld,-sendmail,-systemd fail2ban-all - installs everything - also requires /usr/bin/whois Comments? - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On Wed, Mar 19, 2014 at 02:32:40PM -0600, Orion Poplawski wrote: Hmm, I like this alternative a lot. I'm probably taking this too far, but I'm thinking of: fail2ban-server - core components with minimal deps fail2ban-firewalld - firewalld support/configuration - requires firewalld fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires tcp_wrappers fail2ban-mail - mail actions- requires /usr/bin/mail fail2ban-sendmail - sendmail actions- requires /usr/sbin/sendmail fail2ban-shorewall - shorewall support - requires shorewall fail2ban-systemd - systemd journal configuration fail2ban - default component - installs -firewalld,-sendmail,-systemd fail2ban-all - installs everything - also requires /usr/bin/whois Comments? That _might_ be going overboard. But it certainly does allow a lot of flexibility. Somewhere there is a balance between that flexibility and the extra packaging work and potential user confusion, and I'm not exactly sure where that line is in this case. :) (Call the last one -journald or -systemd-journald by the way -- otherwise, people will expect the unit files to be there.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote: I agree, although I go farther. The EFI System partition doesn't scale, isn't resilient, can neither be mirrored nor easily sync'd (multidevice boot). It should be considered a pre-boot and OS installer domain only. You know, the ESP is actually FAT, one of the simplest, best-understood, most used, and most stable file systems around. Sure, one can always break things, but it is simply misguided to believe that this is the part that will likely break and that we really really really need to stay away from, and not the later parts of the boot that involve grub and raid, and yuck. You know, by creating a chain of many steps where you first go for the ESP, and then follow that by another boot partition and so on, you just make things more complex. If you want things robust, make them simple. Sure, keep writing to the ESP at a minimum, but don't play games of just moving those writes to another boot partition that is a lot more fragile. You are not helping anyone with that... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Wed, Mar 19, 2014 at 3:53 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote: I agree, although I go farther. The EFI System partition doesn't scale, isn't resilient, can neither be mirrored nor easily sync'd (multidevice boot). It should be considered a pre-boot and OS installer domain only. You know, the ESP is actually FAT, one of the simplest, best-understood, most used, and most stable file systems around. Sure, one can always break things, but it is simply misguided to believe that this is the part that will likely break and that we really really really need to stay away from, and not the later parts of the boot that involve grub and raid, and yuck. You know, by creating a chain of many steps where you first go for the ESP, and then follow that by another boot partition and so on, you just make things more complex. More complex than trying to mirror a FAT ESP partition across multiple boot disks, keeping it properly synchronized, because RAID isn't supported? Grub 1 on MD RAID actually just works, once you figure out the incantation to install it. It would be a shame if that ability got lost in the name of simplicity. -- 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: GCJ [was: pdftk retired?]
- Original Message - On 03/08/2014 03:37 AM, Orcan Ogetbil wrote: On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote: Sorry I am missing something. Why can't we keep the old pdftk that works with itext2? Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation. The only things I read in the thread are GCJ is abandoned and we really want to get rid of GCJ. Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users? The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish). Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -- 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: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote: On Wed, Mar 19, 2014 at 3:53 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote: I agree, although I go farther. The EFI System partition doesn't scale, isn't resilient, can neither be mirrored nor easily sync'd (multidevice boot). It should be considered a pre-boot and OS installer domain only. You know, the ESP is actually FAT, one of the simplest, best-understood, most used, and most stable file systems around. Sure, one can always break things, but it is simply misguided to believe that this is the part that will likely break and that we really really really need to stay away from, and not the later parts of the boot that involve grub and raid, and yuck. You know, by creating a chain of many steps where you first go for the ESP, and then follow that by another boot partition and so on, you just make things more complex. More complex than trying to mirror a FAT ESP partition across multiple boot disks, keeping it properly synchronized, because RAID isn't supported? You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because of how RAID-1 works; each individual member can also be mounted as if it was just a plain old partition, which is how the firmware will mount it. The anaconda devs have thought about this, and are planning to implement it. On the UEFI side you just write entries for each of the ESPs into the EFI boot manager. If one of them fails, then the firmware will boot from the next in line. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GCJ [was: pdftk retired?]
Hi And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there. We don't orphan or retire packages based on harm. We do it when there is noone volunteering to maintain it. If you care about GCJ, step up Rahul -- 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: fail2ban + firewalld suggestions needed
Ok using Jonathan's suggestion for the settings from a clean install I'm getting an error whether I use the systemd backend or not... 2014-03-19 22:06:57,956 fail2ban.server.server[12698]: INFOChanged logging target to /var/log/fail2ban.log for Fail2ban v0.9.0 2014-03-19 22:06:57,961 fail2ban.server.database[12698]: INFOConnected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3' 2014-03-19 22:06:58,072 fail2ban.server.jail[12698]: INFOCreating new jail 'sshd' 2014-03-19 22:06:58,134 fail2ban.server.jail[12698]: INFOJail 'sshd' uses pyinotify 2014-03-19 22:06:58,175 fail2ban.server.filter[12698]: INFOSet jail log file encoding to UTF-8 2014-03-19 22:06:58,194 fail2ban.server.jail[12698]: INFOInitiated 'pyinotify' backend 2014-03-19 22:06:58,463 fail2ban.server.filter[12698]: INFOAdded logfile = /var/log/secure 2014-03-19 22:06:58,558 fail2ban.server.filter[12698]: INFOSet maxRetry = 5 2014-03-19 22:06:58,560 fail2ban.server.filter[12698]: INFOSet jail log file encoding to UTF-8 2014-03-19 22:06:58,561 fail2ban.server.actions[12698]: INFOSet banTime = 3600 2014-03-19 22:06:58,564 fail2ban.server.filter[12698]: INFOSet findtime = 600 2014-03-19 22:06:58,566 fail2ban.server.filter[12698]: INFOSet maxlines = 10 2014-03-19 22:06:58,658 fail2ban.server.server[12698]: INFOJail sshd is not a JournalFilter instance 2014-03-19 22:06:58,671 fail2ban.server.jail[12698]: INFOJail 'sshd' started 2014-03-19 22:06:58,981 fail2ban.server.action[12698]: ERROR ipset create fail2ban-sshd hash:ip timeout 600 firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- stdout: \x1b[91mError: COMMAND_FAILED: '/sbin/iptables -t filter -I INPUT_direct 1 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable' failed: iptables v1.4.19.1: Set fail2ban-sshd doesn't exist.\n\nTry `iptables -h' or 'iptables --help' for more information.\x1b[00m\n 2014-03-19 22:06:58,981 fail2ban.server.action[12698]: ERROR ipset create fail2ban-sshd hash:ip timeout 600 firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- stderr: '/bin/sh: ipset: command not found\n' 2014-03-19 22:06:58,981 fail2ban.server.action[12698]: ERROR ipset create fail2ban-sshd hash:ip timeout 600 firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- returned 13 2014-03-19 22:06:58,981 fail2ban.server.actions[12698]: ERROR Failed to start jail 'sshd' action 'firewallcmd-ipset': Error starting action What am I doing wrong? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Mar 19, 2014, at 4:53 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote: I agree, although I go farther. The EFI System partition doesn't scale, isn't resilient, can neither be mirrored nor easily sync'd (multidevice boot). It should be considered a pre-boot and OS installer domain only. You know, the ESP is actually FAT, one of the simplest, best-understood, most used, and most stable file systems around. Designed for floppies. Used today because it meets the resource requirements of camera and USB media manufacturers, not because it's good for users or their data. Otherwise it's abandoned. Windows, OS X, iOS, Android bootloaders read their kernels from more modern file systems. Apple's firmware directly reads HFS+ so they're not even reading their bootloader from a FAT fs. FAT is mainly used for write-mostly or read-mostly use cases, where resilience, permissions, extended attributes, etc. aren't needed, and a small footprint for fs code is. Sure, one can always break things, but it is simply misguided to believe that this is the part that will likely break and that we really really really need to stay away from, and not the later parts of the boot that involve grub and raid, and yuck. It actually has broken for me more times in 9 months than all other file system corruptions I've had combined. (The corruptions were caused by crashes and forced power offs, but users have crashes and unplanned power failures.) In no case did the firmware refuse to load the bootloader, but in a few cases the kernel would not mount the ESP at /boot/efi and since /boot/efi mount failed, the startup failed and I was dropped to an emergency shell. So yes, this is in fact more fragile, it's not some misguided hypothetical. Aside from the corruption concern, there are regressions in actual functionality by putting the configuration files on the ESP. You know, by creating a chain of many steps where you first go for the ESP, and then follow that by another boot partition and so on, you just make things more complex. A chain of many steps? BIOS-boot.img-core.img-/boot/grub2/i386/normal.mod-grub.cfg UEFI-grubx64.efi-grub.cfg-grub.cfg That's fewer steps, even with the second grub.cfg. There's no additional boot partition from what's previously been used either. If you want things robust, make them simple. Sure, keep writing to the ESP at a minimum, but don't play games of just moving those writes to another boot partition that is a lot more fragile. You are not helping anyone with that… Huh? Those writes have been on ext3/4 on Fedora for what, 10 years, up until UEFI? And now they're on FAT16. I'm suggesting moving those writes back to /boot on ext4. How is going back to the way it's been done on BIOS a lot more fragile? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On 03/19/2014 09:10 PM, Richard Shaw wrote: Ok using Jonathan's suggestion for the settings from a clean install I'm getting an error whether I use the systemd backend or not... [12698]: ERROR ipset create fail2ban-sshd hash:ip timeout 600 firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- stderr: '/bin/sh: ipset: command not found\n' Currently we're missing a requires on ipset. 2014-03-19 22:06:58,981 fail2ban.server.action[12698]: ERROR ipset create fail2ban-sshd hash:ip timeout 600 firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- returned 13 2014-03-19 22:06:58,981 fail2ban.server.actions[12698]: ERROR Failed to start jail 'sshd' action 'firewallcmd-ipset': Error starting action What am I doing wrong? Thanks, Richard -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fail2ban + firewalld suggestions needed
On 03/19/2014 02:56 PM, Matthew Miller wrote: On Wed, Mar 19, 2014 at 02:32:40PM -0600, Orion Poplawski wrote: Hmm, I like this alternative a lot. I'm probably taking this too far, but I'm thinking of: fail2ban-server - core components with minimal deps fail2ban-firewalld - firewalld support/configuration - requires firewalld fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires tcp_wrappers fail2ban-mail - mail actions- requires /usr/bin/mail fail2ban-sendmail - sendmail actions- requires /usr/sbin/sendmail fail2ban-shorewall - shorewall support - requires shorewall fail2ban-systemd - systemd journal configuration fail2ban - default component - installs -firewalld,-sendmail,-systemd fail2ban-all - installs everything - also requires /usr/bin/whois Comments? That _might_ be going overboard. But it certainly does allow a lot of flexibility. Somewhere there is a balance between that flexibility and the extra packaging work and potential user confusion, and I'm not exactly sure where that line is in this case. :) This seemed reasonable to me so I've gone with it in rawhide now. Testing welcome. (Call the last one -journald or -systemd-journald by the way -- otherwise, people will expect the unit files to be there.) I kept going back and forth and that, but the configuration option is named systemd in fail2ban, so I went with that. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rfc: EFI System partition, FAT32, repair and non-persistent mount
On Mar 19, 2014, at 7:51 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote: More complex than trying to mirror a FAT ESP partition across multiple boot disks, keeping it properly synchronized, because RAID isn't supported? You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because of how RAID-1 works; each individual member can also be mounted as if it was just a plain old partition, which is how the firmware will mount it. This shouldn't be done. It's a source of corruption to treat an md raid1 device as a plain volume, rather than as a degraded md device. If the plain partition volume is modified, its mdadm metadata won't be updated, so when the array is finally assembled, mdadm has no idea member devices are not sync'd, and also has no way to resolve the ambiguity. Because of this, at least one raid stack kernel maintainer wants to do away with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that permits this plain old partition treatment as a side effect. v1.2 metadata is preferred since it compels the proper treatment of individual member devices as md devices not plain partitions. The metadata is offset 4KB by the start, so only something that will treat it as an md device (normally or degraded assembly) will be able to use it. And hence not useable by UEFI firmware. Therefore I don't think software RAID is a solution. It's more complicated and problem prone than what I've suggested by obviating the on-going need to update the ESP in the first place. Instead we should treat the ESP like the MBR gap, and BIOS Boot: Write once, forget about it. (Short of some critical security update.) On the UEFI side you just write entries for each of the ESPs into the EFI boot manager. If one of them fails, then the firmware will boot from the next in line. The firmware itself will do a fallback even without specific NVRAM entries, and will eventually land on one of the ESP's /EFI/BOOT/BOOTX64.efi's. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Test-API/f20] Initial import (perl-Test-API-0.004-2)
Summary of changes: 0f48f4f... Initial import (perl-Test-API-0.004-2) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-API] Created tag perl-Test-API-0.004-2.fc21
The lightweight tag 'perl-Test-API-0.004-2.fc21' was created pointing to: 0f48f4f... Initial import (perl-Test-API-0.004-2) -- 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
Beaker 0.16 released
Folks, I just wanted to let you know that we released Beaker 0.16.0 this week. This includes the fix for password hashing, which was one of the outstanding security issues with having a public Beaker deployment. https://beaker-project.org/docs/whats-new/release-0.16.html#password-hashes-use-a-more-secure-salted-form I can upgrade the Beaker instance at dev.fedoraproject.org (Tim sponsored me into the sysadmin-qa group so that I can help with this stuff). I'll do that early next week unless there are any objections. There will be a brief outage for database upgrades but I don't think that matters given that the Beaker instance is currently not usable :-) (Tim, when you can spare a few minutes please ping me and we can sort out the remaining issues with those Beaker VMs.) -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
