EPEL epel beta report: 20140124 changes
Compose started at Fri Jan 24 08:15:03 UTC 2014 Broken deps for x86_64 -- ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) docker-io-0.7.6-4.el7.x86_64 requires lxc globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires hiera = 0:1.0.0 pyhoca-gui-0.4.0.9-2.el7.noarch requires wxPython python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 python-x2go-0.4.0.9-1.el7.noarch requires nxproxy snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.9.beta2.el7.noarch requires perl(Config::IniFiles) spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 wxGTK-devel-2.8.12-8.el7.x86_64 requires bakefile Broken deps for ppc64 -- TurboGears-1.1.3-8.el7.noarch requires python-simplejson = 0:1.9.1 ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-client-0.9.7-1.el7.noarch requires python-simplejson bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) fedmsg-0.7.2-1.el7.noarch requires python-simplejson fedmsg-0.7.2-1.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires hiera = 0:1.0.0 pyhoca-gui-0.4.0.9-2.el7.noarch requires wxPython python-django-1.5.4-2.el7.noarch requires python-simplejson python-fedora-0.3.33-1.el7.noarch requires python-simplejson python-fedora-0.3.33-1.el7.noarch requires python-requests python-requests-kerberos-0.3-2.el7.noarch requires python-requests = 0:1.0 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 python-toscawidgets-0.9.12-4.el7.noarch requires python-simplejson python-turboflot-0.7.0-4.el7.noarch requires python-simplejson python-turbojson-1.3.2-5.el7.noarch requires python-simplejson = 0:1.9.1 python-tw2-core-2.1.5-4.el7.noarch requires python-simplejson = 0:2.0 python-webflash-0.1-0.8.a9.el7.noarch requires python-simplejson python-x2go-0.4.0.9-1.el7.noarch requires nxproxy skeinforge-12.03.14-16.el7.noarch requires pypy snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.9.beta2.el7.noarch requires perl(Config::IniFiles) spectrwm-2.4.0-2.el7.ppc64 requires xlockmore spectrwm-2.4.0-2.el7.ppc64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 wxGTK-devel-2.8.12-8.el7.ppc64 requires bakefile New package: Xaw3d-1.6.2-4.el7 A version of the MIT Athena widget set for X New package: aalib-1.4.0-0.22.rc5.el7 ASCII art library New package: activemq-cpp-3.8.2-1.el7 C++ implementation of JMS-like messaging client New package: ascii-design-1.0.2-1.el7 A tool to create ascii arts New package: ast-7.3.3-1.el7 A Library for Handling World Coordinate Systems in Astronomy New package: cacti-0.8.8b-3.el7 An rrd based graphing tool New package: cdk-5.0.20140118-1.el7 Curses Development Kit New package: cptutils-1.48-1.el7 Utilities to manipulate and translate color gradients New package: cronolog-1.6.2-14.el7 Web log rotation program for Apache New package: freexl-1.0.0f-1.el7 Library to extract data from within an Excel spreadsheet New package: gv-3.7.4-5.el7 A X front-end for the Ghostscript PostScript(TM) interpreter New package: itstool-1.2.0-3.el7 ITS-based XML translation tool New package: libev-4.15-3.el7 High-performance event loop/event model with lots of features New package: libgta-1.0.4-1.el7 Library that implements the
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Fri, Jan 24, 2014 at 01:00:29AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 23, 2014 at 04:53:47PM -0700, Kevin Fenzi wrote: On Thu, 23 Jan 2014 15:26:24 -0800 Adam Williamson awill...@redhat.com wrote: I think ideally any process around this should have at least two parts: a) an automated/scriptable part. In this part the script uses cold hard facts to look for possible packages that are unloved or package maintainers that are not active. There's tons of data we have now with fedmsg. Sadly, we don't have bugzilla in fedmsg, but we could scrape it directly. it generates a list that feeds to the next part. b) The generated list is examined by humans and action taken. Some things that are the list will be false positives. Try and adjust the script to not generate them. As a bonus, the script could also possibly try and figure out components that 'need help'...ie, lots of unanswered bugs or something. Even a simple list of packages ordered by the time from last non-mass-rebuild release multiplied by the number of currently open bugs would be quite useful. Packages with bug-years above 50 or so would be good candidates for inspection. I looked into the build history of our package collection recently, more specially trying to find the date of the last successful build of all our packages using datagrepper. I presented the output in: http://blog.pingoured.fr/index.php?post/2013/12/17/Fedora-build-history There is a rather small list that might be something to look into first: 66 packages have not been sucessfully re-built for 200 days or more 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: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/24/2014 05:50 AM, Christopher Meng wrote: But, never deem that 5k components is the best number, comparing to other Linux, we are far away behind. They can be used still at the moment, why do we burden ourselves by the insignificant numbers? Quantity vs quality 5k - 7k was the number we peeked in contribution and innovation. We should be able to calculate the number of components we as in distribution actually can manage. We just need to agree on average contribute time which could be 2.5 hours a day 5 days of the week or something and how long each component distribution task takes, and how many packagers we have and reduce ourselves to exactly that size or there about. 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: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/24/2014 05:05 AM, Rahul Sundaram wrote: Agreed. It is atleast a metric that can be tweaked as opposed to pretending that all packages with inactive upstreams is a deep resource drain on Fedora. It's not pretending anything if you question what I suggest you get input from the arm team they are the once that most recently went through all the packages right. Let's hear from them how well much time they spent fixing unmaintained or badly maintained packages for nothing. I would suggest that when we identify such packages, we take steps to try and get more maintainers for those packages first before trying to cull them off. For instance, sending a note to fedora announce list and here with the list of problematic packages. That way, everyone will have a fair chance to try and rescue the packages they care about. What you are proposing is what has been tried to be achieved for the past ten years and utterly failed hence we need a different approach. I say we remove those unmaintained components and if and when interest comes back to maintain those components then they will just have to pass through package review again. 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: Heads up; F22 will require applications to ship appdata to be listed in software center
Hi, On Fri, Jan 24, 2014 at 01:00:29AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 23, 2014 at 04:53:47PM -0700, Kevin Fenzi wrote: On Thu, 23 Jan 2014 15:26:24 -0800 Adam Williamson awill...@redhat.com wrote: I think ideally any process around this should have at least two parts: a) an automated/scriptable part. In this part the script uses cold hard facts to look for possible packages that are unloved or package maintainers that are not active. There's tons of data we have now with fedmsg. Sadly, we don't have bugzilla in fedmsg, but we could scrape it directly. it generates a list that feeds to the next part. b) The generated list is examined by humans and action taken. Some things that are the list will be false positives. Try and adjust the script to not generate them. As a bonus, the script could also possibly try and figure out components that 'need help'...ie, lots of unanswered bugs or something. Even a simple list of packages ordered by the time from last non-mass-rebuild release multiplied by the number of currently open bugs would be quite useful. Packages with bug-years above 50 or so would be good candidates for inspection. Sounds reasonable to me. D. -- 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; F22 will require applications to ship appdata to be listed in software center
Am 24.01.2014 09:18, schrieb Jóhann B. Guðmundsson: On 01/24/2014 05:50 AM, Christopher Meng wrote: But, never deem that 5k components is the best number, comparing to other Linux, we are far away behind. They can be used still at the moment, why do we burden ourselves by the insignificant numbers? Quantity vs quality 5k - 7k was the number we peeked in contribution and innovation. We should be able to calculate the number of components we as in distribution actually can manage. We just need to agree on average contribute time which could be 2.5 hours a day 5 days of the week or something and how long each component distribution task takes, and how many packagers we have and reduce ourselves to exactly that size or there about. please come back to reality you can't seriously not count things that way because in that average you have self-made problems like drop-in-replacements of important components which are not ready and waste *a lot* of time, large packages which need *a lot* of time and small packages a trained monkey can build and maintain and what you also don't see is that one of the big time wasters most likely is maintained by completly different people than the packages where nothing more than download the tarball and rebuild it ever was needed (postfix as example needs *zero* maintainance and has nothing to do with the KDE maintainers) as i went in school i learned that such math will not work 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: Heads up; F22 will require applications to ship appdata to be listed in software center
On Fri, Jan 24, 2014 at 08:18:16AM +, Jóhann B. Guðmundsson wrote: On 01/24/2014 05:50 AM, Christopher Meng wrote: But, never deem that 5k components is the best number, comparing to other Linux, we are far away behind. They can be used still at the moment, why do we burden ourselves by the insignificant numbers? Quantity vs quality 5k - 7k was the number we peeked in contribution and innovation. Says who? We should be able to calculate the number of components we as in distribution actually can manage. We can't, because it is not possible. All packages are not equal, whatever you might think. We just need to agree on average contribute time which could be 2.5 hours a day 5 days of the week or something and how long each component distribution task takes, Oh, great... So I have two examples for you to ponder over, which might help you to determine that... An update to new release of, say, libcdr can be done and smoketested in 10-15 minutes. An update to new version of libreoffice takes days, possibly more than a week. and how many packagers we have and reduce ourselves to exactly that size or there about. Great way to make many packagers and users angry and move away. If your quest is to destroy Fedora, just say it aloud... Anyway, the main flaw in this scheme of yours is that you expect that packagers will split the remaining packages among themselves. THIS. IS. NOT. GOING. TO. HAPPEN. Ever. Fedora is not a dictature; you cannot order packagers around to start maintaining something, if they do not want to. So, can we finally abandon this crazy idea? D. -- 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; F22 will require applications to ship appdata to be listed in software center
Am 24.01.2014 09:27, schrieb Jóhann B. Guðmundsson: I say we remove those unmaintained components and if and when interest comes back to maintain those components then they will just have to pass through package review again. i say you remove *nothing* before you have asked for every single package you consider to remove because there are people only installed the really used ones and if you list one of the packages on my machines you can stop the whole idea who do you think you are that you believe you can remove others packages? 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: Fedora.next in 2014 -- Big Picture and Themes
On 23/01/14 18:48, Josh Boyer wrote: On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote: Even the formation of the working groups was odd - the original decision to form them, as I read it, was that they were to explore the idea of doing these three streams but within days it seemed that the question was no longer whether to do them but rather how to do them. I can see how that would be confusing. I always understood it to be these WGs will be formed and they will be tasked with figuring out how to create their respective products. Perhaps some lack of clarity in the proposal? I've been digging back through the list archives and various other sources trying to determine where my view of this was founded, but not with a hug amount of success so far. The best I have come up with is your report to the list of the board's decision: https://lists.fedoraproject.org/pipermail/devel/2013-August/187784.html Where we are told that the board agree with the development of a working group to describe an implementation proposal for the future of Fedora which sounds like the idea is to make a proposal for how to do things in the future, which might then be accepted or rejected. By the time Fesco is discussing the creation of those groups (for it has now become multiple groups) a week or two later the proposal the groups are being asked to create is not a proposal as to whether to change but rather a proposal for the specific way to do the change. In other words the question seems to have changed from whether to do it to how to do it. Of course this is all reading a lot into that one initial sentence in your email. I think there were probably other things that helped build that view in my mind at the time but I can't find them right now. That's why I got the feeing a lot of contributors are simply waiting for more concrete details to emerge before deciding what to make of Fedora.next; or they simply at all don't care to much what the higher ups do, as getting involved on that level can cost quite a lot of time and can be frustrating (that's not a complaint, that's simply how it is often; wasn't much different in my days, but noticed that more when I wasn't that active an more myself). If they are waiting, what are they waiting for? If they don't care, and they just want to maintain a package or 30 packages, is there anything that you see in Fedora.next that would prevent them from doing that? There will always be varied level of participation, and I think we need to have a development model that encourages that and allows for growth. I don't think Fedora.next gets in the way of that, but I would love to have other opinions. To be honest my concerns are more with my user hat on than my contributor hat - that we will lose the gold standard unified packaging standards and single source and mechanism for installing packages. I haven't seen anything from any WG that would suggest a deviation from RPM packaging guidelines or using separate repositories. It is a valid concern and one we need to keep an eye on. Once again the facts don't entirely seem to chime with my memory... My memory was that each WG had been explicitly told that they could propose alternative packaging guidelines for their products. In fact a review of the original call for WG nominations suggests that only the end and stacks group were given that freedom, specifically they were tasked: to work on policies and practices for software operating outside of Fedora's traditional packaging model Of course if you see env and stacks as sitting between base and the three product groups then that effectively impacts on all the products because if they start encouraging alternative packaging and policies then the product groups may use that and render it effectively impossible to run anything beyond a barebones system using the traditional Fedora model. A lot of the time I will have been reading all of these things coloured by knowing that they derive from the original Fedora.next proposal which appeared to be all about weakening packing guidelines and making it easier to shove stuff in and to encourage use of various upstream packaging systems in place of Fedora packaging. So there will have been an assumption in my mind that the real agenda all the time is to do that. Certainly that is still pretty much how I see the env and stacks group and that is certainly where my major concerns lie. The actual spins (or whatever you want to call them) aren't something that bother me at all, as they are to my mind largely irrelevant for anybody other than a new user. When I bring a new machine up I just want to get a base OS on and access to the package repository and what packages are installed by default doesn't really bother me. So... Fedora.next is essentially irrelevant to you? That's OK, it doesn't have to be relevant to everyone. And meeting the needs of existing users is
Re: Drawing lessons from fatal SELinux bug #1054350
2014/1/24 Ralf Corsepius rc040...@freenet.de Certainly, downgrading installations which already upgraded to faulty packages would not work. Ralf The situation (a broken system that cannot be upgraded) could be mitigated a little bit by using yum + system snapshots. You can rollback to a previous sane system. There is a plugin yum-plugin-fs-snapshot, but it requires better documentation and system integration. Currently (I don't know how current is F16 documentation) it requires running lvm by hand http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/sec-Plugin_Descriptions.html Sergio -- 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
Shipping package metadata in a package
Hi all, I'm after some advice / ideas. When you install Fedora 20/21 and then launch gnome-software it has to go and download some metadata before it can show anything. This is a pretty bad first experience, considering subsequent runs of gnome-software just open straight away. GNOME Software operates on the logic that *any* version of the metadata is better than nothing, and only refreshes once a week when the user is idle. There are two ways to fix the jarring UX. We could either ship the fedora package metadata pre-prepared in PackageKit, maybe using something like %ghost so the new metadata is ignored. The other way is to start the metadata downloading in the initial-start wizard thing, although in practice the download takes a couple of minutes to complete, and the wizard typically takes much less than that before the user has configured everything. The downside to shipping prepared metadata is that the package size is larger, and that the metadata would be *very* out of date after a year or so. I'm open to ideas, 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: Shipping package metadata in a package
Hi, On Fri, 2014-01-24 at 10:01 +, Richard Hughes wrote: There are two ways to fix the jarring UX. We could either ship the fedora package metadata pre-prepared in PackageKit, maybe using something like %ghost so the new metadata is ignored. The other way is to start the metadata downloading in the initial-start wizard thing, although in practice the download takes a couple of minutes to complete, and the wizard typically takes much less than that before the user has configured everything. The downside to shipping prepared metadata is that the package size is larger, and that the metadata would be *very* out of date after a year or so. Rather than during the initial setup thing, why not start it at first boot, much earlier? Another option would be to have it done as the last step of the installer. -- Mathieu -- 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: Shipping package metadata in a package
On 24 January 2014 10:03, Mathieu Bridon boche...@fedoraproject.org wrote: Rather than during the initial setup thing, why not start it at first boot, much earlier? We need to wait until the user has setup a network connection. Another option would be to have it done as the last step of the installer. Won't that download the metadata onto the live image, not the fresh install? 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: Heads up; F22 will require applications to ship appdata to be listed in software center
Kevin Fenzi wrote: I mean, I'm a maintainer for the Fedora apg package. Last upstream release was 2003. I very rarely touch it. Yet, from time to time I still use it here, I suspect, but do not know that others install and use it. It has no bugs currently opened against it. It's not failed a mass rebuild. The last time I touched it was to move it to use systemd unit files (it can optionally run a network service to return it's data). Is this a package that should be removed for being abandoned? I'm not familiar with APG but from your description it sounds like a perfect example of stable and reliable software – the best kind there is. So what if it's abandoned, if no one has found any bugs? Björn Persson 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: Heads up; F22 will require applications to ship appdata to be listed in software center
On 24 January 2014 10:32, Björn Persson bj...@xn--rombobjrn-67a.se wrote: I'm not familiar with APG but from your description it sounds like a perfect example of stable and reliable software – the best kind there is. Right, so it belongs in Fedora; I don't think anyone is arguing against that. There is a metric ton of packages that are dead upstream with very few (if any users). I feel that a lot of these types of package are getting auto-cleansed from the distro when they fail the automated rebuilds a few releases in a row, or when the original fedora maintainer gets sick of the bug-mails and simply orphans it. My mail was about crappy GUI applications that users install and then the application crashes, they report a bug or feature request, wait, and nothing happens as the upstream is long dead and there are going to be no more releases. We can include those in the distribution for very little cost, but we shouldn't be advertising them in the software center among all the other awesome applications we have. 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: Fedora.next in 2014 -- Big Picture and Themes
Colin Walters wrote: People have been constantly confused by whether Fedora does DHCP by default over the years, because we've flipped it several times. When we introduced it for clients/workstations, I consider it to have been a *massive* win to be able to plug in an ethernet cable and have it Just Work. Absolutely. That's the whole point of DHCP. But it's very much the wrong thing to do for traditional servers where you have 4 or more physical NICs. I don't see why. Either DHCP is the right thing, or else the admin is going to configure the NICs immediately and then it doesn't matter what the default is. Björn Persson 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: Drawing lessons from fatal SELinux bug #1054350
On Fri, Jan 24, 2014 at 12:55 AM, Kevin Kofler kevin.kof...@chello.at wrote: So, what happened: * We are enabling SELinux enabled (enforcing) by default, a tool designed to prevent anything it does not like from happening. (Reread this carefully: The ONLY thing that tool is designed to do at all is PREVENT things. It does not have a SINGLE feature other than being a roadblock and an annoyance.) The feature is called security. By your logic everyone should be root, we should disable other security features like ASLR and NX (both PREVENT me from running malicious code but do not add a SINGLE feature). So please read on how security is implemented and why. * SELinux works by shipping a policy that effectively tries to specify in one single place (read: single point of failure!) everything any program in Fedora (scalability disaster!) ever wants to do (second-guessing its actual code, i.e., duplication of all logic!). That's not how it works not how it supposed to work. Please read on MAC. (Note the 3 (!) major antipatterns in a single-sentence (!) description of how SELinux works!) Not a description on how it works but your misunderstand. * An update to that SELinux policy was shipped that BREAKS the most critical tools in Fedora, the ones required to update the system and thus install the fixes for any regressions, including the very regression that caused the breakage. And also any automated workarounds are blocked by design. No idea what automated workaround means but there are other ways to deal with it see Colin's post. * That update made it out to the stable updates! In other words, the draconian Update Policies that were enacted in a vain attempt to prevent such issues from happening utterly failed at catching this bug. Yeah so we should find out why this happened and improve the testing procedures to not let it happen in the feature (again see Colin's mail). So, what needs to happen: * SELinux must be disabled (or preferably, not installed in the first place, to avoid wasting space for nothing) by default! Just consider the benefits (none!) As stated above that's not true. * The Update Policies must be repealed. This regression has shown us that not only they totally failed at preventing it, but they are actively contributing to exposing MORE users to broken updates by delaying regression fixes. (This kind of regression fixes needs to go out DIRECTLY to stable!) This is a contradiction our current testing didn't find the bug so how about we do no testing at all. -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 21:19, Dan Williams wrote: On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 [...snip...] Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. NM only uses bluez via the D-Bus interface, so if you force install bluez4, NM will still work and should even handle the change at runtime. And then you'll get DUN back too :) Clarification: I actually don't mean runtime. NM must be restarted to notice the change from bluez4 - bluez5, but it does not need to be recompiled. The DBus interface with bluez5 have changed too. http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Does NM support both bluez NM APIs? -- kind regards, David SOmmerseth -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 23:59, Dan Williams wrote: On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: Nope, several packages depends on the bluez-5.13-1 package. Indeed. However I could probably live without gnome-bluetooth if blueman were still available. pulseaudio-module-bluetooth though. Would it work with Bluez4? Would it need a compile to do so? I wonder how you make that a functional downgrade that users can select if they still need Bluez4. --- -- Finished Dependency Resolution Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64 (@updates/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20) Requires: bluez = 5.0 Removing: bluez-5.13-1.fc20.x86_64 (@updates/20) bluez = 5.13-1.fc20 Downgraded By: bluez-4.101-9.fc19.x86_64 (updates) bluez = 4.101-9.fc19 Available: bluez-4.101-6.fc19.x86_64 (fedora) bluez = 4.101-6.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. Indeed. I suspect the same. Perhaps gnome-bluetooth could be uninstalled and replace with blueman without too much heartburn. It's the other packages that get troublesome. A pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA? Something similar for NM? It's starting to get ugly and perhaps the effort spent doing that would be better put towards: https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5 But either way, it does seem a pretty serious regression. Although maybe you and me, David, are the only F20 users using HSP bluetooth headsets. :-/ Out of curiosity, what do people use Blueman for? I used it in far earlier versions of Fedora, because gnome-bluetooth was just lacking basic features. I used it to setup GPRS/3G connections using PAN and not rfcomm (as that was the only thing working with my cell phones at that time), browsing files via OBEX over bluetooth plus it gave more informative information on signal strengths of connected devices - useful for some debugging. But as GNOME got far better Bluetooth support (F14 and F19 were quite good, even though file browsing seemed somewhat cripled in F19), I used what was there instead of using blueman additionally. I actually think Cinnamon used blueman in F19 for Bluetooth management, iirc. -- kind regards, David Sommerseth -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
- Original Message - snip I actually think Cinnamon used blueman in F19 for Bluetooth management, iirc. Nope. Which is why it broke when I bumped the soname of the gnome-bluetooth libraries. -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 23:16, Chris Murphy wrote: On Jan 23, 2014, at 2:56 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote: As a side note, it also needs to be discussed how such a key feature of the bluetooth stack could go unnoticed through QA, and how to avoid this from happening again. Indeed. I wondered the same myself. As far as I know there isn't an explicit test case or release criteria that covers this functionality, or it would have been discovered. Why it's not a test case is a valid question, but simply put there are only so many QA people, much of it is voluntary so not everything important gets tested. Fair enough. However, in this case it seems this was even noticed. Why that was never looked into more thoroughly is a mystery for me. By all means, software does and needs to evolve, and it can break. I have full understanding for this. But not alerting that basic functionality of things you would expect breaks, that's the key point here. That puts users into a difficult situation, especially when the dependencies are so tricky. Seemingly critical features that shouldn't have major regressions are exactly where testing should be done in advance of release. People who care about such functionality need to alpha and beta test, and review feature proposals that affect things they care about. You don't have to test for a week or month or the whole cycle. But had there been more discovery, and criticism of the loss of features at the right time, then it seems plausible the change would have been pushed back to F21. https://fedoraproject.org/wiki/Changes/Bluez5 I'll admit I noticed the Bluez5 threads on this list, and thought this was fairly straight forward. Packages needed to be adopted to a new API is kind of normal. And I took it for granted that the HSP/HFP functionality would be tested. I cannot understand this functionality is not considered an important feature. I mean, does people only use bluetooth for the A2DP profile? Major functionality should keep working without regressions, compared to BlueZ 4 in Fedora 19. And… If the release blocking desktops have major bluetooth related regressions by the time of the Fedora 20 Beta Change Deadline, then FESCo and the proposal owners may enact a contingency plan to revert the BlueZ 5 related changes and go back to BlueZ 4. This thread is suggesting a major regression, and if that's the case then the contingency should have been employed. But the first red flag for that should have been at the latest prior to beta freeze. During the F20 beta, I was soaked into other work to be able to test this. But knowing we have a Fedora QA group and a plan for rolling things back, I had a trust that the Fedora community wouldn't allow this to happen. But trust me, I will check things far more closely in the coming releases ... unless I simply switch to RHEL instead to have some better predictability. -- kind regards, David Sommerseth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Source string contextualization
Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. We welcome feedback and suggestions. Regards, Nilamdyuti Goswami [1]: https://fedoraproject.org/wiki/SSCG -- 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: Shipping package metadata in a package
Dne 24.1.2014 11:03, Mathieu Bridon napsal(a): Hi, On Fri, 2014-01-24 at 10:01 +, Richard Hughes wrote: There are two ways to fix the jarring UX. We could either ship the fedora package metadata pre-prepared in PackageKit, maybe using something like %ghost so the new metadata is ignored. The other way is to start the metadata downloading in the initial-start wizard thing, although in practice the download takes a couple of minutes to complete, and the wizard typically takes much less than that before the user has configured everything. The downside to shipping prepared metadata is that the package size is larger, and that the metadata would be *very* out of date after a year or so. Rather than during the initial setup thing, why not start it at first boot, much earlier? Not sure I like the idea. I install the system, eager to start using it, but in background will run some service downloading some data, which will make my system sluggish. That would be user experience far from ideal ... Vít Another option would be to have it done as the last step of the installer. -- 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: Security update process without CVEs
Christopher Meng wrote: Which poor sod will be the victim in 7 days at least before pushing to stable? ;) Then comes another question, does security updates need to be treat as special? It's just an original update with a tag security alert, but users still need to wait 7 days unless they enable updates-testing. Indeed, critical security updates really need to go directly to stable. We need direct stable pushes back! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: boot.fedoraproject.org (BFO)
Pierre-Yves Chibon wrote: I'm confused, are you talking about: https://fedorahosted.org/pkgdb2/ ? If this is now on Fedora Hosted, that's a good thing. :-) Thank you for that! So you don't have to feel targeted (anymore), you already did the right thing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Security update process without CVEs
On Fri, Jan 24, 2014 at 1:25 PM, Kevin Kofler kevin.kof...@chello.at wrote: We need direct stable pushes back! No. -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
Orcan Ogetbil wrote: Right. But is it possible to ship a bluez4 package and rebuild the dependencies against that after the release? No, because the maintainers said the 2 versions are not parallel- installable. (The original plan was to make the packages Conflict, which is why we ended up with getting everything ported to BlueZ 5 instead, to avoid having desktop environments being mutually exclusive.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Drawing lessons from fatal SELinux bug #1054350
Adam Williamson wrote: Even if we can do it on the mirrors, we have no way to 'recall' a package from systems where it's already been installed (of course in the current case that wouldn't have worked anyway, but we're discussing the generic case here). Crazy idea of the day: Maybe our update tools should default to distro-sync rather than update? Together with ensuring timestamp monotonicity on the metadata (don't accept older metadata if you already have newer one), it would allow easily pulling faulty updates (except when RPM is broken as in this case, of course) and could even render the dreaded Epoch hack obsolete. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Drawing lessons from fatal SELinux bug #1054350
Adam Williamson wrote: TBH this has always been the one of Kevin's Big Book Of Update Policy Complaints I find the most baffling. If we know you managed to screw up your update once, why exactly would we just trust you to get it right the *second* time without any testing? * If the package is already so screwed that it breaks the whole system, it cannot realistically get any worse. * A regression fix is usually a trivial change, often reverting something to a previous, already well-tested, state. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Drawing lessons from fatal SELinux bug #1054350
drago01 wrote: The feature is called security. By your logic everyone should be root, For home user machines, that wouldn't necessarily be a bad thing (but it would mean fixing the software that special-cases the root user improperly for no good reason). Alternatively, the kernel could be patched to give admin users (either defined as members of the wheel group as now, or by some additional property that would be set for the same users by default) some strategic capabilities such as dac_override. That would also put an end to the endless annoyance of having to sudo all the time. (And by the way, sudo and PolicyKit actions should be allowed with no password (rather than the user password as now) for wheel group members by default.) That way, you still get the benefits from different accounts, e.g., different preferences per family member, without the current restrictions imposed to normal users. The endless password prompts make a lot of sense in controlled corporate environments with dedicated system administrators, but on home machines, they are just an unnecessary annoyance. * SELinux works by shipping a policy that effectively tries to specify in one single place (read: single point of failure!) everything any program in Fedora (scalability disaster!) ever wants to do (second-guessing its actual code, i.e., duplication of all logic!). That's not how it works not how it supposed to work. Please read on MAC. Uh, I know how it works. The above is how I summarize it. If you think that is incorrect, please explain HOW. * An update to that SELinux policy was shipped that BREAKS the most critical tools in Fedora, the ones required to update the system and thus install the fixes for any regressions, including the very regression that caused the breakage. And also any automated workarounds are blocked by design. No idea what automated workaround means but there are other ways to deal with it see Colin's post. A %pretrans scriptlet that fixes the problem without manual user intervention (other than OKing the update). But SELinux won't allow RPMs to mess with it that way (especially without invoking an external executable, which is blocked by the faulty policy) because it would defeat its flawed security model. Yeah so we should find out why this happened and improve the testing procedures to not let it happen in the feature (again see Colin's mail). NO amount of testing is going to prevent regressions from happening occasionally. This means: * we need to eliminate common sources of regressions such as SELinux, to prevent whole classes of regressions from occurring in the first place (prevention is better than duct tape!) and * we have to accept that regressions can always happen and allow for fast fixes to those regressions (direct stable pushes). So, what needs to happen: * SELinux must be disabled (or preferably, not installed in the first place, to avoid wasting space for nothing) by default! Just consider the benefits (none!) As stated above that's not true. As stated above, that IS true. :-) * The Update Policies must be repealed. This regression has shown us that not only they totally failed at preventing it, but they are actively contributing to exposing MORE users to broken updates by delaying regression fixes. (This kind of regression fixes needs to go out DIRECTLY to stable!) This is a contradiction our current testing didn't find the bug so how about we do no testing at all. There is no contradiction. Doing away with policies that do not work is perfectly logical, as is allowing quick regression fixes because regressions do happen no matter how much you test. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 24/01/14 08:31, Bastien Nocera wrote: FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20. Can you please shed some more light on this. From what I could grasp out of the freedesktop bug, it was a bluez bug. And PulseAudio says bluez4 is needed to get the handsfree profile working. Anyhow, I'm past this discussion and have started to figure out how to recompile the needed packages. So anything which can simplify this job is appreciated. -- kind regards, David Sommerseth -- 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: .spec file Source0 magic for github release source tarballs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 05:49 PM, Adam Williamson wrote: On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. And it's still possible to 'ninja' a github repository with a history rewrite (for example if the upstream discovers that they have content that was impermissible to distribute, they might retroactively delete if from the history). This would change all git hashes that occur after this time. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX GvsAni3A4//1e5s+hXhbUlh75gtpqazp =fSzG -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: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/24/2014 10:39 AM, Richard Hughes wrote: On 24 January 2014 10:32, Björn Persson bj...@xn--rombobjrn-67a.se wrote: I'm not familiar with APG but from your description it sounds like a perfect example of stable and reliable software – the best kind there is. Right, so it belongs in Fedora; I don't think anyone is arguing against that. There is a metric ton of packages that are dead upstream with very few (if any users). I feel that a lot of these types of package are getting auto-cleansed from the distro when they fail the automated rebuilds a few releases in a row, or when the original fedora maintainer gets sick of the bug-mails and simply orphans it. My mail was about crappy GUI applications that users install and then the application crashes, they report a bug or feature request, wait, and nothing happens as the upstream is long dead and there are going to be no more releases. We can include those in the distribution for very little cost, but we shouldn't be advertising them in the software center among all the other awesome applications we have. If there exist and centralized software application center I as an end user would just go to my Gnome Application Center scroll or search through application list, double click or double tap the application that I would find interesting and install it which if I understand correctly would be installed into application container outline by Alexander and Lennart. If I lack proprietary driver of any kind to run chosen application I would think the application center would point that out to me as well and where to get that driver if it could not install it for me or be told that the application I have chosen would be incompatible with all of my device if it did not find it. So this may come as completely stupid question but what has centralized software application center for Gnome have to do with distribution since I as an end user would never install application in Gnome in any other way then to use Gnome Application Center thus I as an application developer would never develop my application to be used outside Gnome and polices around the application center like Android has [1][2] and quite frankly would be glad not having to deal with distribution package management systems like... DPKG APT - aptitude - dselect - Ubuntu Software Center RPM Package Manager YUM - APT-RPM - poldek - up2date - urpmi - ZYpp Classic Tar ball slapt-get - slackpkg - zendo - netpkg - swaret Bunch of others appbrowser - Conary - Equo - pkgutils - pacman - PETget - PISI - Portage - Smart Package Manager - Steam - Tazpkg - Upkg Which brings up another question if the intent is to aim for Gnome Application Center dont you need to control and release your own OS on a rebase-able release schedule since for example here in Iceland they have already replaced pc with tablets in several school so the next generation of end users is *used* to get a rebase-able update for their device. We cannot clean up the distribution which I consider the nr.1 priority we need to do just so it becomes agile enough for anykind of future proposal because the policy and the community will ,seems to be hey if it automated rebuilds we ship it! ( and this is just one distribution policy's then there is Debian,Arch,Suse etc.. ) So I get to the point I'm trying to see and understand what role do distribution play in that future for Gnome and why is Gnome contributors wasting so much time and energy in distribution politics and compatability as opposed to fully commit to the next step of the evolution and move beyond distribution in become a distribution of it's own? JBG 1. http://play.google.com/about/developer-content-policy.html 2. http://play.google.com/about/developer-distribution-agreement.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
[Base] Base Design WG agenda meeting 24. Jan 2014 15:00 UTC on #fedora-meeting
Agenda: - Discussion of WG PRDs and impact on Base https://fedoraproject.org/wiki/Cloud_PRD https://fedoraproject.org/wiki/Workstation/Workstation_PRD https://fedoraproject.org/wiki/Server/Product_Requirements_Document https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document - Status update BR cleanup - Open floor Thanks regards, Phil Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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; F22 will require applications to ship appdata to be listed in software center
On 24 January 2014 13:18, Jóhann B. Guðmundsson johan...@gmail.com wrote: So I get to the point I'm trying to see and understand what role do distribution play in that future for Gnome and why is Gnome contributors wasting so much time and energy in distribution politics and compatability as opposed to fully commit to the next step of the evolution and move beyond distribution in become a distribution of it's own? GNOME Software supports more than just installing packages using PackageKit. It's designed as an abstraction with plugins so you can install web-apps, and in the future we'll be supporting static binaries like click and glick2 packages I'm sure. If you're interested we're designing all this in the open. 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: Shipping package metadata in a package
On 24 January 2014 12:20, Vít Ondruch vondr...@redhat.com wrote: Not sure I like the idea. I install the system, eager to start using it, but in background will run some service downloading some data, which will make my system sluggish. That would be user experience far from ideal ... In this instance, when run with background attribues, PackageKit uses idle bandwidth and with a lower priority than if the transaction was a foreground task. 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: Drawing lessons from fatal SELinux bug #1054350
Am 24.01.2014 13:56, schrieb Kevin Kofler: Alternatively, the kernel could be patched to give admin users (either defined as members of the wheel group as now, or by some additional property that would be set for the same users by default) some strategic capabilities such as dac_override. That would also put an end to the endless annoyance of having to sudo all the time. (And by the way, sudo and PolicyKit actions should be allowed with no password (rather than the user password as now) for wheel group members by default.) That way, you still get the benefits from different accounts, e.g., different preferences per family member, without the current restrictions imposed to normal users. The endless password prompts make a lot of sense in controlled corporate environments with dedicated system administrators, but on home machines, they are just an unnecessary annoyance no, they are not, they have the same reason as firefox asks for the master-password before display stored passwords even after you already entered it to login somewhere they prevent that if you are not alone that while you go to the toilet and forget to lock your screen unauthorized people not doing things nobody wants on the machine what you propose is the Apple way - not on a linux system please 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: Source string contextualization
On Fri, Jan 24, 2014 at 1:22 PM, Nilamdyuti Goswami ngosw...@redhat.com wrote: Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. It is *just* about improving the source code? There is already a Transifex feature which can help provide context without having to edit the source code. Best would be able to proofread on the app itself.. See what is going on with GTK: http://gil.badall.net/2013/01/23/i18n-dreams-eventually-come-true/ http://deckard.malizor.org/ that's amazing. We welcome feedback and suggestions. Regards, Nilamdyuti Goswami [1]: https://fedoraproject.org/wiki/SSCG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Kévin Raymond (shaiton) GPG-Key: A5BCB3A2 -- 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: Shipping package metadata in a package
On Fri, 2014-01-24 at 10:01 +, Richard Hughes wrote: Hi all, I'm after some advice / ideas. When you install Fedora 20/21 and then launch gnome-software it has to go and download some metadata before it can show anything. This is a pretty bad first experience, considering subsequent runs of gnome-software just open straight away. GNOME Software operates on the logic that *any* version of the metadata is better than nothing, and only refreshes once a week when the user is idle. There are two ways to fix the jarring UX. We could either ship the fedora package metadata pre-prepared in PackageKit, maybe using something like %ghost so the new metadata is ignored. The other way is to start the metadata downloading in the initial-start wizard thing, although in practice the download takes a couple of minutes to complete, and the wizard typically takes much less than that before the user has configured everything. The downside to shipping prepared metadata is that the package size is larger, and that the metadata would be *very* out of date after a year or so. I'm open to ideas, thanks. Does it need all the data upfront ? Maybe you can have a small place with initial metadata that contains a subset of the packages and is quick to download so you can show something then in the background start downloading the real full metadata and update the UI as data comes in ? 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
[perl-Test-CheckManifest] Upstream update.
commit df410518ce626eb5032933ebe831a7c585336347
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Fri Jan 24 15:12:19 2014 +0100
Upstream update.
perl-Test-CheckManifest.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-CheckManifest.spec b/perl-Test-CheckManifest.spec
index b331722..64be814 100644
--- a/perl-Test-CheckManifest.spec
+++ b/perl-Test-CheckManifest.spec
@@ -1,6 +1,6 @@
Name: perl-Test-CheckManifest
-Version:1.26
-Release:4%{?dist}
+Version:1.28
+Release:1%{?dist}
Summary:Check if your Manifest matches your distro
License:Artistic 2.0
Group: Development/Libraries
@@ -52,6 +52,9 @@ cd ..
%{_mandir}/man3/*
%changelog
+* Fri Jan 24 2014 Ralf Corsépius corse...@fedoraproject.org - 1.28-1
+- Upstream update.
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.26-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-LexAlias] Created tag perl-Devel-LexAlias-0.05-1.el7
The lightweight tag 'perl-Devel-LexAlias-0.05-1.el7' was created pointing to: 6499918... update to 0.05 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-CheckManifest-1.28.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Test-CheckManifest: 5d26d71cede4310f7c8463cac283f5c9 Test-CheckManifest-1.28.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Shipping package metadata in a package
On 24 January 2014 14:10, Simo Sorce s...@redhat.com wrote: Does it need all the data upfront ? That's a good question. Not much at all just to show the overview page. Maybe you can have a small place with initial metadata that contains a subset of the packages and is quick to download so you can show something then in the background start downloading the real full metadata and update the UI as data comes in ? I'll have a play with this and see how complicated it is. All the UI elements can update when the data is changed, so it certainly should be possible. 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
[perl-Digest-BubbleBabble] Created tag perl-Digest-BubbleBabble-0.02-6.el7
The lightweight tag 'perl-Digest-BubbleBabble-0.02-6.el7' was created pointing to: 46f5bc3... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Drawing lessons from fatal SELinux bug #1054350
On Fri, 2014-01-24 at 14:40 +0100, Reindl Harald wrote: Am 24.01.2014 13:56, schrieb Kevin Kofler: Alternatively, the kernel could be patched to give admin users (either defined as members of the wheel group as now, or by some additional property that would be set for the same users by default) some strategic capabilities such as dac_override. That would also put an end to the endless annoyance of having to sudo all the time. (And by the way, sudo and PolicyKit actions should be allowed with no password (rather than the user password as now) for wheel group members by default.) That way, you still get the benefits from different accounts, e.g., different preferences per family member, without the current restrictions imposed to normal users. The endless password prompts make a lot of sense in controlled corporate environments with dedicated system administrators, but on home machines, they are just an unnecessary annoyance no, they are not, they have the same reason as firefox asks for the master-password before display stored passwords even after you already entered it to login somewhere they prevent that if you are not alone that while you go to the toilet and forget to lock your screen unauthorized people not doing things nobody wants on the machine Worse than that, they prevent automated attacks via very vulnerable applications like browsers. [which of course in Kevin's world are never run in a SELinux sandbox] So you if you get some malware to jailbreak out of the browser sandbox all it needs to do is sudo pwnme if there is no password request. Of course you need to understand at least a smidget of security to avoid proposing ludicrous 'defaults'. what you propose is the Apple way - not on a linux system please It is just 'the pwn me' way, nothing more, nothing less. -- 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
[perl-Test-CheckManifest/f20] (2 commits) ...Upstream update.
Summary of changes: df41051... Upstream update. (*) e790bea... Upstream update. (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] 389-ds-base: /bin/sh scripts should use . instead of source
On 01/24/2014 04:13 AM, Roberto Polli wrote: Hi @all, iirc /bin/sh scripts should use . instead of source (see http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot ) To use source you should change the interpreter to be /bin/bash lib389@rpolli:~/workspaces/389-ds-base/ds/ldap/admin/src/scripts$ git diff . diff --git a/ldap/admin/src/scripts/ldif2db.in b/ldap/admin/src/scripts/ldif2db.in index ce15349..fb24863 100755 --- a/ldap/admin/src/scripts/ldif2db.in +++ b/ldap/admin/src/scripts/ldif2db.in @@ -1,6 +1,6 @@ #!/bin/sh -source @datadir@/@package_name@/data/DSSharedLib +. @datadir@/@package_name@/data/DSSharedLib libpath_add @libdir@/@package_name@/ libpath_add @nss_libdir@ https://fedorahosted.org/389/ticket/47511 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[perl-Digest-MD2] Created tag perl-Digest-MD2-2.03-21.el7
The lightweight tag 'perl-Digest-MD2-2.03-21.el7' was created pointing to: 06fa598... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Shipping package metadata in a package
Dne 24.1.2014 15:05, Richard Hughes napsal(a): On 24 January 2014 12:20, Vít Ondruch vondr...@redhat.com wrote: Not sure I like the idea. I install the system, eager to start using it, but in background will run some service downloading some data, which will make my system sluggish. That would be user experience far from ideal ... In this instance, when run with background attribues, PackageKit uses idle bandwidth and with a lower priority than if the transaction was a foreground task. Richard. Well, if there is more of such tasks I wish there is system which would allow to queue such unwanted tasks, and execute them later after start one by one. Vít -- 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: Source string contextualization
On 24-01-2014 07:37 অপৰাহ্ন, Kévin Raymond wrote: On Fri, Jan 24, 2014 at 1:22 PM, Nilamdyuti Goswami ngosw...@redhat.com wrote: Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. It is *just* about improving the source code? It is about providing Translators' comment or precise context to the confusing source strings in the source code of the application so that the resultant pot/po files have that context and it becomes easy for the translators to translate the confusing strings. There is already a Transifex feature which can help provide context without having to edit the source code. If Transifex has this feature, we would like to know more about it because this can be a more direct solution to the problem. :-) Best would be able to proofread on the app itself.. See what is going on with GTK: http://gil.badall.net/2013/01/23/i18n-dreams-eventually-come-true/ http://deckard.malizor.org/ that's amazing. Yeah, we have tried *deckard* before and indeed it is amazing but it is something which is used for proofreading. If a translator wasn't sure of a particular source string's meaning, did a wrong translation and eventually finds the mistake when he proofreads the actual UI in deckard, he has to do an extra work and make the correction in the respective po file whereas providing a proper context will ensure a correct translation in the first place. Proofreading the app, detecting the mistake, and then making the correction won't be required. :-) We welcome feedback and suggestions. Regards, Nilamdyuti Goswami [1]: https://fedoraproject.org/wiki/SSCG -- 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: Drawing lessons from fatal SELinux bug #1054350
On 01/24/2014 01:39 PM, Kevin Kofler wrote: Adam Williamson wrote: Even if we can do it on the mirrors, we have no way to 'recall' a package from systems where it's already been installed (of course in the current case that wouldn't have worked anyway, but we're discussing the generic case here). Crazy idea of the day: Maybe our update tools should default to distro-sync rather than update? No, for 2 reasons: a) This would blow away all installed packages, which aren't available in permanently enabled repos. Most common such case is having selectively installed packages from updates-testing, because users are facing problems with these packages' nominal versions. b) A much more common packaging bug class than the SELinux-case are packages, which can not be uninstalled or downgraded or not be downgraded properly. Classic such cases are packages with defective rpm-scriptlets or with scriptlet which perform persistent changes. Ralf -- 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: [389-devel] 389-ds-base: /bin/sh scripts should use . instead of source
Roberto Polli wrote: On Friday 24 January 2014 07:28:51 Rich Megginson wrote: https://fedorahosted.org/389/ticket/47511 sorry for the double posting :( I just cloned the master repository and it's not fixed. This is just the tracking ticket for the work. Looks like a candidate patch has been attached but they need to prioritize this amongst other work, have someone review the patch, do regression testing, etc. rob -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Drawing lessons from fatal SELinux bug #1054350
Am 24.01.2014 15:55, schrieb Ralf Corsepius: On 01/24/2014 01:39 PM, Kevin Kofler wrote: Adam Williamson wrote: Even if we can do it on the mirrors, we have no way to 'recall' a package from systems where it's already been installed (of course in the current case that wouldn't have worked anyway, but we're discussing the generic case here). Crazy idea of the day: Maybe our update tools should default to distro-sync rather than update? No, for 2 reasons: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out otherwise some packages would be not installed on my machines after a dist-upgrade namely the ones never came from any repo and installed locally Most common such case is having selectively installed packages from updates-testing, because users are facing problems with these packages' nominal versions *that* is the reason not to do so because it would downgrade anything updated explicitly from updates-testing,kde-testing,koji which would be a bad default 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
gitflow and branch naming conventions
So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit. I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual? Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do). So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits. If you have installed the gitflow RPM package (it adds the git flow subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning. [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/24/2014 01:51 PM, Richard Hughes wrote: On 24 January 2014 13:18, Jóhann B. Guðmundssonjohan...@gmail.com wrote: So I get to the point I'm trying to see and understand what role do distribution play in that future for Gnome and why is Gnome contributors wasting so much time and energy in distribution politics and compatability as opposed to fully commit to the next step of the evolution and move beyond distribution in become a distribution of it's own? GNOME Software supports more than just installing packages using PackageKit. It's designed as an abstraction with plugins so you can install web-apps, and in the future we'll be supporting static binaries like click and glick2 packages I'm sure. If you're interested we're designing all this in the open. If you got some link to the design(s) that would be fine since all I'm aware of is what Alexander and Lennart talked about in a bof in guadec last year but bottom line what I'm interested in to know the direction Gnome is heading in as well as ultimately what role distribution play in that direction. Basically Is Gnome preparing themselves for the tablet generation that will be stepping out of schools in the next years? 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: [389-devel] 389-ds-base: /bin/sh scripts should use . instead of source
On Friday 24 January 2014 10:02:02 Rob Crittenden wrote: Roberto Polli wrote: On Friday 24 January 2014 07:28:51 Rich Megginson wrote: https://fedorahosted.org/389/ticket/47511 This is just the tracking ticket for the work. Ok. Hope won't take too much (for now I'm fine as I've fixed my local installation :P) I will eventually trace the issue in lib389 README. Thx + Peace, R. -- Roberto Polli Community Manager Babel - a business unit of Par-Tec S.p.A. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wrote a systemd unit file to enable it, and to allow a user to disable the feature if he wants. # cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit] Description=SELinux check actual protection flags applied by kernel, rather than checking what application requested. [Service] Type=oneshot RemainAfterExit=yes Environment=CHECKREQPROT=0 EnvironmentFile=-/etc/selinux/config ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot' I would like to enable this service on the post install of a initial install of libselinux. But I believe this will not happen with %systemd_post_enable selinux-checkreqprot.service How would I go about doing this? I know there is one problem in the unit file, it will fail if /sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to just exit if this file does not exist? Also is using a unit file for this, the best way to handle this? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLihVAACgkQrlYvE4MpobNpZACfbC5WmT7GUirmcBIri1BJOs33 DcMAnA24d4xumzT4vBPWbLSeEnQwj1VU =Kswu -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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, 24.01.14 10:22, Daniel J Walsh (dwa...@redhat.com) wrote:
Heya,
Do we really need a service for this? Can't this be done instead via a
tmpfiles snippet that uses f and the extra argument at the end?
I mean I am not convinced it's worth involving shell here. Also the
canonical way to write things to /proc or /sys is
{/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's
simple and static. And I don't see why we shouldn't do this differently
in this case than in all others...
If you would ship a simple tmpfiles snippet in /usr/lib/tmpfiles.d/,
then users who want to opt out of this could simply symlink the file to
/dev/null in /etc/tmpfiles.d/.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote a systemd unit file to enable it, and to allow a user to disable the
feature if he wants.
# cat /usr/lib/systemd/system/selinux-checkreqprot.service
[Unit]
Description=SELinux check actual protection flags applied by kernel, rather
than checking what application requested.
[Service]
Type=oneshot
RemainAfterExit=yes
Environment=CHECKREQPROT=0
EnvironmentFile=-/etc/selinux/config
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
I would like to enable this service on the post install of a initial install
of libselinux. But I believe this will not happen with
%systemd_post_enable selinux-checkreqprot.service
How would I go about doing this?
I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to just
exit if this file does not exist?
Also is using a unit file for this, the best way to handle this?
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, 24 Jan 2014, Daniel J Walsh wrote: I wrote a systemd unit file to enable it, and to allow a user to disable the feature if he wants. # cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit] Description=SELinux check actual protection flags applied by kernel, rather than checking what application requested. What does this actually do/mean? (Sorry if it's obvious, it isn't to me!) -- Benjamin Lewis -- 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: Shipping package metadata in a package
On Fri, Jan 24, 2014 at 10:01:09AM +, Richard Hughes wrote: The downside to shipping prepared metadata is that the package size is larger, and that the metadata would be *very* out of date after a year or so. I don't see the problem with stale metadata of this kind. It's not like a description or screenshots of a GUI application are completely outdated after a year. There are exceptions, but most of the time, Fedora wouldn't even update the package in a certain release if the underlying toolkit changes or significant new functionality is added. So for packages which were in the initial release of given Fedora version, slightly stale metadata shouldn't be an issue. For packages which were added during the release, the metadata might be missing. But then they would be downloaded during the update... Of course this is all true in the stable limit, where packages have their appdata. This might take a release or two to reach this point. If you're trying to solve the problem for the *next* release, that might be different. But probably improving the metadata files and adding screenshots so everything is there is a better use of time in the long run than adding a way to download updates faster. BTW. Reminded by this thread, I've added appdata files for the calibre package. In the appdata file I have a screenshot: screenshot type=default width=1200 height=675http://in.waw.pl/~zbyszek/calibre/calibre-main-window.png/screenshot but gnome-software doesn't display it, despite displaying the textual content of the appdata file just fine. appdata-validate also doesn't complain. AFAICT, there's nothing wrong with this picture, the download works, etc. Any pointers? 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: Drawing lessons from fatal SELinux bug #1054350
On 01/24/2014 04:06 PM, Reindl Harald wrote: Am 24.01.2014 15:55, schrieb Ralf Corsepius: On 01/24/2014 01:39 PM, Kevin Kofler wrote: Adam Williamson wrote: Even if we can do it on the mirrors, we have no way to 'recall' a package from systems where it's already been installed (of course in the current case that wouldn't have worked anyway, but we're discussing the generic case here). Crazy idea of the day: Maybe our update tools should default to distro-sync rather than update? No, for 2 reasons: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out Been there many times. Real world example with a package I maintain, which currently has an update pending in updates-testing: # yum install gumbo-parser ... Installing : gumbo-parser-1.0-0.2.20131001gitd90ea2b.fc20.x86_64 ... [Note: updates-testing is disabled in /etc/yum.repo.d/fedora-updates-testing.repo] Now temporarily enable updates-testing to pull in the package from updates-testing for testing: # yum update --enablerepo=updates-testing gumbo-parser ... Updating : gumbo-parser-1.0-0.2.20131204git87b99f2.fc20.x86_64 ... # yum distro-sync ... Downgrading: gumbo-parser x86_64 1.0-0.2.20131001gitd90ea2b.fc20 fedora ... Removed: gumbo-parser.x86_64 0:1.0-0.2.20131204git87b99f2.fc20 Installed: gumbo-parser.x86_64 0:1.0-0.2.20131001gitd90ea2b.fc20 ... = qed Ralf -- 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: Shipping package metadata in a package
On 24 January 2014 15:39, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: BTW. Reminded by this thread, I've added appdata files for the calibre package. In the appdata file I have a screenshot: screenshot type=default width=1200 height=675http://in.waw.pl/~zbyszek/calibre/calibre-main-window.png/screenshot but gnome-software doesn't display it, despite displaying the textual content of the appdata file just fine. appdata-validate also doesn't complain. AFAICT, there's nothing wrong with this picture, the download works, etc. Any pointers? GNOME in Fedora 20 only displays the description, the UI for downloading screenshots and thumbnails only came in 3.11 -- if you use rawhide it should work perfectly. I opened an upstream bug before I knew you did this; perhaps you could submit the file upstream? https://bugs.launchpad.net/calibre/+bug/1271974 I really appreciate the help, 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, Jan 24, 2014 at 10:22:56AM -0500, Daniel J Walsh wrote:
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
ExecStart=/bin/sh -c '/bin/echo ${CHECKREQPROT} /sys/fs/selinux/checkreqprot'
I think we really need an echo command with sudo syntax. I keep a local
script which does that, called fecho. The syntax is 'fecho [-a] arg... file',
where -a means append. Maybe something like this could be added to util-linux
or somewhere.
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On 01/24/2014 03:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 24, 2014 at 10:22:56AM -0500, Daniel J Walsh wrote:
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
ExecStart=/bin/sh -c '/bin/echo ${CHECKREQPROT} /sys/fs/selinux/checkreqprot'
I think we really need an echo command with sudo syntax. I keep a local
script which does that, called fecho. The syntax is 'fecho [-a] arg... file',
where -a means append. Maybe something like this could be added to util-linux
or somewhere.
Zbyszek
When we started the migration of units, using ExecStart=/bin/sh -c was
generally frown upon since unit files aren't shell scripts and weren't
supposed to be used as such, has this changed?
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
Daniel J Walsh (dwa...@redhat.com) said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wrote a systemd unit file to enable it, and to allow a user to disable the feature if he wants. ... why is this not a sysctl? 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2014 10:32 AM, Lennart Poettering wrote:
On Fri, 24.01.14 10:22, Daniel J Walsh (dwa...@redhat.com) wrote:
Heya,
Do we really need a service for this? Can't this be done instead via a
tmpfiles snippet that uses f and the extra argument at the end?
No I did not know that tmpfiles.d did this. I will look into using that.
I mean I am not convinced it's worth involving shell here. Also the
canonical way to write things to /proc or /sys is
{/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's simple
and static. And I don't see why we shouldn't do this differently in this
case than in all others...
If you would ship a simple tmpfiles snippet in /usr/lib/tmpfiles.d/, then
users who want to opt out of this could simply symlink the file to
/dev/null in /etc/tmpfiles.d/.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
I wrote a systemd unit file to enable it, and to allow a user to disable
the feature if he wants.
# cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit]
Description=SELinux check actual protection flags applied by kernel,
rather than checking what application requested.
[Service] Type=oneshot RemainAfterExit=yes Environment=CHECKREQPROT=0
EnvironmentFile=-/etc/selinux/config ExecStart=/bin/sh -c '/bin/echo
$CHECKREQPROT /sys/fs/selinux/checkreqprot'
I would like to enable this service on the post install of a initial
install of libselinux. But I believe this will not happen with
%systemd_post_enable selinux-checkreqprot.service
How would I go about doing this?
I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to
just exit if this file does not exist?
Also is using a unit file for this, the best way to handle this?
Lennart
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLijEAACgkQrlYvE4MpobMm5gCfebHFEnypgZbZy0fVSR1Omz0I
0N8An3c4B9rP8hpV0Jkla8bQIXATzpT4
=KUxo
-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: Drawing lessons from fatal SELinux bug #1054350
Am 24.01.2014 16:40, schrieb Ralf Corsepius: On 01/24/2014 04:06 PM, Reindl Harald wrote: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out Been there many times no, you did not and you did also not in your example below Real world example with a package I maintain, which currently has an update pending in updates-testing: # yum distro-sync ... Downgrading: gumbo-parser x86_64 1.0-0.2.20131001gitd90ea2b.fc20 fedora ... Removed: gumbo-parser.x86_64 0:1.0-0.2.20131204git87b99f2.fc20 Installed: gumbo-parser.x86_64 0:1.0-0.2.20131001gitd90ea2b.fc20 nothing is blown away, you only did not read the output because it was *downgraded* and *not* removed this is *completly* different than blown away this is what distro-sync *is supposed to do* upgrade or downgrade any package which is in whatever current repo but it *does not* blow away packages not in any repo at all and if you would not have stripped this paragraph of my original reply you maybe had looked twice *that* is the reason not to do so because it would downgrade anything updated explicitly from updates-testing,kde-testing,koji which would be a bad default 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the request from upstream to enable this feature in Rawhide, with an explanation of what it does. Android is starting to apply execmem and friends to the non-Dalvik components (i.e. non-Java components, primarily the native system daemons). As part of that, I uploaded a change to effectively echo 0 /sys/fs/selinux/checkreqprot so that we always check the actual protection flags applied by the kernel rather than only checking what the application requested. Originally checkreqprot was to support legacy applications that had no PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we wouldn't have to add execute permission pervasively to policy for such applications. But it effectively provides a way to bypass policy by creating such an application, and as I later discovered, just by calling personality(READ_IMPLIES_EXEC) from an application at any time. The simplest way to eliminate that bypass comprehensively is to change the defaults for checkreqprot. I think this is likely safe in Fedora since you now allow execmem by default to most domains. Can we get the same change applied in Fedora, either by changing the default kernel configuration (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in an init script to set the /sys/fs/selinux/checkreqprot value? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLijmYACgkQrlYvE4MpobP3GgCg0sGEjAuD7tKM+4aH3HkGOnJP wuYAoJOfrvEjYm90uwUMpDIW0p7NfSel =DOlV -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: Shipping package metadata in a package
On Fri, Jan 24, 2014 at 03:44:07PM +, Richard Hughes wrote: On 24 January 2014 15:39, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: BTW. Reminded by this thread, I've added appdata files for the calibre package. In the appdata file I have a screenshot: screenshot type=default width=1200 height=675http://in.waw.pl/~zbyszek/calibre/calibre-main-window.png/screenshot but gnome-software doesn't display it, despite displaying the textual content of the appdata file just fine. appdata-validate also doesn't complain. AFAICT, there's nothing wrong with this picture, the download works, etc. Any pointers? GNOME in Fedora 20 only displays the description, the UI for downloading screenshots and thumbnails only came in 3.11 -- if you use rawhide it should work perfectly. I opened an upstream bug before I knew you did this; perhaps you could submit the file upstream? Done. https://bugs.launchpad.net/calibre/+bug/1271974 I really appreciate the help, thanks. I was running the rawhide version... Before I had gnome-software-3.11.1-1.fc21.x86_64, and now I upgraded to 3.11.4-2.fc21.x86_64. Unfortunately 3.11.4-2.fc21.x86_64 crashes all the time for me. At least I think it crashed when I first started it, because the window disappeared when I was looking for the screenshots. But now, it doesn't actually *crash*, the window just disappears after a few seconds. In the logs: Jan 24 10:56:13 bupkis gnome-session[1958]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3e8 (Software) Jan 24 10:56:13 bupkis gnome-session[1958]: Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Jan 24 10:56:13 bupkis PackageKit[26841]: get-packages transaction /11744_bddbeadd from uid 1001 finished with success after 45ms Jan 24 10:56:14 bupkis gnome-session[1958]: Window manager warning: last_focus_time (861528554) is greater than comparison timestamp (861528547). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... That is all. 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: Shipping package metadata in a package
On 24 January 2014 16:08, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I was running the rawhide version... Before I had gnome-software-3.11.1-1.fc21.x86_64, and now I upgraded to 3.11.4-2.fc21.x86_64. Unfortunately 3.11.4-2.fc21.x86_64 crashes all the time for me. Yup, sorry about that, there are a couple of threading fixes in git. I'll do a new release on Monday. jhbuild is working flawlessly for me, but that's obviously much harder to set up. 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
[perl-Test-Warnings] Created tag perl-Test-Warnings-0.010-1.el7
The lightweight tag 'perl-Test-Warnings-0.010-1.el7' was created pointing to: 3c29020... Update to 0.010 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Source string contextualization
It is *just* about improving the source code? It is about providing Translators' comment or precise context to the confusing source strings in the source code of the application so that the resultant pot/po files have that context and it becomes easy for the translators to translate the confusing strings. By doing that, I think you go to improve the way strings are defined also. For example a string could be spread in many which result on something not translatable is some languages. There is already a Transifex feature which can help provide context without having to edit the source code. If Transifex has this feature, we would like to know more about it because this can be a more direct solution to the problem. :-) What seems to do the trick is http://support.transifex.com/customer/portal/articles/1188235-comments-on-source-strings one can comment a string (to all translators, but in the language he choose), and event report an issue for his team or the developer (I don't know if they listen to us...) Of course, there is no perfect solution, but checking every project sources might be a huge work. (with no end) -- 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: Drawing lessons from fatal SELinux bug #1054350
On 01/24/2014 04:57 PM, Reindl Harald wrote: Am 24.01.2014 16:40, schrieb Ralf Corsepius: On 01/24/2014 04:06 PM, Reindl Harald wrote: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out Been there many times no, you did not and you did also not in your example below Real world example with a package I maintain, which currently has an update pending in updates-testing: # yum distro-sync ... Downgrading: gumbo-parser x86_64 1.0-0.2.20131001gitd90ea2b.fc20 fedora ... Removed: gumbo-parser.x86_64 0:1.0-0.2.20131204git87b99f2.fc20 Installed: gumbo-parser.x86_64 0:1.0-0.2.20131001gitd90ea2b.fc20 nothing is blown away, you only did not read the output because it was *downgraded* and *not* removed Rubbish - Stop being childish. this is *completly* different than blown away this is what distro-sync *is supposed to do* upgrade or downgrade any package which is in whatever current repo but it *does not* blow away packages not in any repo at all It if the package from updates-testing was fixing a critical bug on your system, your system would be malfunctioning afterwards. -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-1.el7
The lightweight tag 'perl-YAML-LibYAML-0.41-1.el7' was created pointing to: 0c4fe66... Update to 0.41 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Drawing lessons from fatal SELinux bug #1054350
Am 24.01.2014 17:12, schrieb Ralf Corsepius: On 01/24/2014 04:57 PM, Reindl Harald wrote: Am 24.01.2014 16:40, schrieb Ralf Corsepius: On 01/24/2014 04:06 PM, Reindl Harald wrote: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out Been there many times no, you did not and you did also not in your example below Real world example with a package I maintain, which currently has an update pending in updates-testing: # yum distro-sync ... Downgrading: gumbo-parser x86_64 1.0-0.2.20131001gitd90ea2b.fc20 fedora ... Removed: gumbo-parser.x86_64 0:1.0-0.2.20131204git87b99f2.fc20 Installed: gumbo-parser.x86_64 0:1.0-0.2.20131001gitd90ea2b.fc20 nothing is blown away, you only did not read the output because it was *downgraded* and *not* removed Rubbish - Stop being childish. nobody here is childish, except maybe you this is *completly* different than blown away this is what distro-sync *is supposed to do* upgrade or downgrade any package which is in whatever current repo but it *does not* blow away packages not in any repo at all It if the package from updates-testing was fixing a critical bug on your system, your system would be malfunctioning afterwards and exactly *that* was what i said in my first reply while you stripped *exactly* that part out from your quote, most likely because you replied with a reflex without read exactly 5 lines completly but that is *not* a) This would blow away all installed packages, which aren't available in permanently enabled repos because that would mean *uninstall* any package which is currently not in a enabled repo - and that is *not* what distro-sync does below *again* my complete reply which is and was technical correct while your would blow away is not so before call others childish the next time before you reply to a message read also the second pararaph to avoid useless discussions Original-Nachricht Betreff: Re: Drawing lessons from fatal SELinux bug #1054350 Datum: Fri, 24 Jan 2014 16:06:21 +0100 Von: Reindl Harald h.rei...@thelounge.net An: devel@lists.fedoraproject.org Am 24.01.2014 15:55, schrieb Ralf Corsepius: On 01/24/2014 01:39 PM, Kevin Kofler wrote: Adam Williamson wrote: Even if we can do it on the mirrors, we have no way to 'recall' a package from systems where it's already been installed (of course in the current case that wouldn't have worked anyway, but we're discussing the generic case here). Crazy idea of the day: Maybe our update tools should default to distro-sync rather than update? No, for 2 reasons: a) This would blow away all installed packages, which aren't available in permanently enabled repos that is not true, try it out otherwise some packages would be not installed on my machines after a dist-upgrade namely the ones never came from any repo and installed locally Most common such case is having selectively installed packages from updates-testing, because users are facing problems with these packages' nominal versions *that* is the reason not to do so because it would downgrade anything updated explicitly from updates-testing,kde-testing,koji which would be a bad default 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: SELinux RPM scriplet issue annoucement
One note on that topic: I found myself giving karma to an update, while I tested different version (actually a completely different build). It would be good if giving karma would require to insert a hash or something generated from the package itself (rpm -q -qf something package), header or signature. Portal could check the hash and only accept karma for those users, who obviously installed the package. It could be optional as well. This could prevent mis-giving karma while testing different version of a package. The portal could instruct user to run specific one (short) command to get the hash and to put it in the form. This is just an idea. Question arises when the package consist of multiple subpackage (only to test the base one?) and also how much intrusive this would be for folks. -- 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
[perl-Test-Unit-Lite] Created tag perl-Test-Unit-Lite-0.12-16.el7
The lightweight tag 'perl-Test-Unit-Lite-0.12-16.el7' was created pointing to: 6b5b806... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1051598] Perl scripts misidentified as perl modules
https://bugzilla.redhat.com/show_bug.cgi?id=1051598 Jeff Makey j...@makey.net changed: What|Removed |Added Blocks||1057718 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1057718 [Bug 1057718] F20 w3c-markup-validator RPM missing Perl dependencies -- 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=3jVVRqzBjna=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: SELinux RPM scriplet issue annoucement
Am 24.01.2014 17:34, schrieb Lukas Zapletal: One note on that topic: I found myself giving karma to an update, while I tested different version (actually a completely different build). It would be good if giving karma would require to insert a hash or something generated from the package itself (rpm -q -qf something package), header or signature. Portal could check the hash and only accept karma for those users, who obviously installed the package. It could be optional as well. This could prevent mis-giving karma while testing different version of a package. The portal could instruct user to run specific one (short) command to get the hash and to put it in the form. This is just an idea. Question arises when the package consist of multiple subpackage (only to test the base one?) and also how much intrusive this would be for folks that could be easier solved by force anybody to use easy-karma instead the webinterface because that only asks for the current installed packages the only thing i wish is that fedora-easy-karma would support a param with a textfile containing the password because i hardly remember a 35 chars random password and so do it like below for CP from the terminal [root@srv-rhsoft:~]$ cat /scripts/easy-karma.sh #!/usr/bin/bash echo PASSWORT: ** fedora-easy-karma --fas-username=hreindl --default-comment=works for me 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: Source string contextualization
On Fri, Jan 24, 2014 at 3:07 PM, Kévin Raymond shai...@fedoraproject.orgwrote: On Fri, Jan 24, 2014 at 1:22 PM, Nilamdyuti Goswami ngosw...@redhat.com wrote: To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. It is *just* about improving the source code? There is already a Transifex feature which can help provide context without having to edit the source code. Having translation context comments together with the source code is beneficial for the same reason having API documentation together with the source code is beneficial: they don't get out of sync. Especially note that merely the English string is not always a sufficient identifier of the context, unlike a function/method name in an API. An infamous case is the string May which may either be a month name or a verb (in a software that is splicing sentences), and there already was an application that used both. Attaching a context within the translation tool just wouldn't have worked. 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: Shipping package metadata in a package
On Fri, Jan 24, 2014 at 3:05 PM, Richard Hughes hughsi...@gmail.com wrote: In this instance, when run with background attribues, PackageKit uses idle bandwidth and with a lower priority than if the transaction was a foreground task. Huh, we have a concept of idle bandwidth? Who/how manages this? 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: .spec file Source0 magic for github release source tarballs?
Agreed. But the difference is that using full commits a history rewrite will always be detected. Using a tag is making it possible for upstream to bind the same tag to a different commit. And since it's possible, it will happen. It's a shame there is no way to block forced updates on github. It's a little bit to easy to make a history rewrite there. On Fri, Jan 24, 2014 at 2:13 PM, Stephen Gallagher sgall...@redhat.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 05:49 PM, Adam Williamson wrote: On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý msu...@redhat.com wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? https://fedoraproject.org/wiki/Packaging:SourceURL#Github Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. And it's still possible to 'ninja' a github repository with a history rewrite (for example if the upstream discovers that they have content that was impermissible to distribute, they might retroactively delete if from the history). This would change all git hashes that occur after this time. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX GvsAni3A4//1e5s+hXhbUlh75gtpqazp =fSzG -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 -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
On Jan 24, 2014, at 4:47 AM, David Sommerseth dav...@redhat.com wrote: On 23/01/14 23:16, Chris Murphy wrote: As far as I know there isn't an explicit test case or release criteria that covers this functionality, or it would have been discovered. Why it's not a test case is a valid question, but simply put there are only so many QA people, much of it is voluntary so not everything important gets tested. Fair enough. However, in this case it seems this was even noticed. Why that was never looked into more thoroughly is a mystery for me. QA volunteers don't get assignments. Most work and reports are on what's personally important or interesting to them. If XYZ breakage isn't in the matrix or test cases, then it must be personally important to someone and they have to rock the boat somehow. And because testing weeks prior to alpha, or beta, let alone final, already involve a ship at high seas… By all means, software does and needs to evolve, and it can break. I have full understanding for this. But not alerting that basic functionality of things you would expect breaks, that's the key point here. That puts users into a difficult situation, especially when the dependencies are so tricky. First, I refuse the premise that it's QA's job to audit every feature or change, to determine whether its contingency plan needs to be activated. That would be nice if it had the resources to do that. QA is well over its eyeballs with the test matrices and test cases it has. But the feature page explicitly said no major regressions. So either the feature owner disagrees with the assessment in this thread that the breakage is a major regression; or major breakage occurred and even slipped by the feature owner. So? I'm not sure how you expect this to work better. One of QA ideas is actually expanding the test matrix, and prioritizing it. I'd guess that a set of blue tooth tests could be written up (hopefully you'd volunteer to do this since it seems important enough to you), and put into the bonus matrix. That means, if not tested, it's not release blocking, but at least people can more visibly see what QA has/hasn't tested. If QA can even get more one off involvement from volunteers who otherwise don't participate that much, it's still very helpful. During the F20 beta, I was soaked into other work to be able to test this. But knowing we have a Fedora QA group and a plan for rolling things back, I had a trust that the Fedora community wouldn't allow this to happen. In my estimation, you significantly overestimate QA's scope and resources. And that is an understatement. And I think this misunderstanding in the Fedora community is widespread. QA maybe needs to do a recruitment drive or bake sale or something. There are likely quite a number of basic things that aren't being touched by QA first. QA is a community task. If you think it's important, you need to test it and report on it and waive your hands if you even remotely think a feature contingency plan should be activated. Otherwise, the result is exactly what has happened here. But trust me, I will check things far more closely in the coming releases ... unless I simply switch to RHEL instead to have some better predictability. Very, very different contexts. Fedora is made to be worked on. RHEL is made to work. 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: SELinux RPM scriplet issue annoucement
that could be easier solved by force anybody to use easy-karma instead the webinterface because that only asks for the current installed packages Oh, I did not know fedora-easy-karma. We should advertise with the update tickets on Bodhi perhaps. Actually this could improve things. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis fed...@leemhuis.info wrote: I'm still undecided if I overall like Fedora.next or fear it. But more and more I tend to the latter position and wonder if it might be wise to slow things down: Do one more Fedora release the old style in round about June; that would give us more time to better discuss and work out Fedora.next and get contributors involved better in the planing. This is not practical. Lots of people are thinking about a fedora.next, qa folks are coding away, lots of people who normally would be working on the next release are not. If we tell them to stop all that and go back to normal, we could, but then fedora.next will likely never ever happen. [...] The current problem I have with Fedora.next is that it's so abstract. How are QA folks coding away for Fedora.next, rather than traditional Fedora QA processes, if Fedora.next is so abstract? I still don't understand what the Fedora.next Products accomplish that Spins don't/can't. Eric -- 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-Distribution] Created tag perl-Test-Distribution-2.00-14.el7
The lightweight tag 'perl-Test-Distribution-2.00-14.el7' was created pointing to: 2f42a73... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl-Readonly in EL 7
Hi Ken, On 24/01/14 16:29, Ken Dreyer wrote: Hi folks, RHEL 7 does not ship perl-Readonly. This package is a dependency for perl-boolean, which is a dependency for perl-MongoDB, so I'd like to have it in EPEL 7. Would one of you mind branching and building it for EPEL 7? Both perl-Readonly and perl-Readonly-XS are included in RHEL-7 beta - see: https://fedoraproject.org/wiki/EPEL/epel7 http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/Packages/ What made you think they weren't there? Cheers, Paul. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Fri, Jan 24, 2014 at 5:51 PM, Chris Murphy li...@colorremedies.comwrote: On Jan 24, 2014, at 4:47 AM, David Sommerseth dav...@redhat.com wrote: On 23/01/14 23:16, Chris Murphy wrote: By all means, software does and needs to evolve, and it can break. I have full understanding for this. But not alerting that basic functionality of things you would expect breaks, that's the key point here. That puts users into a difficult situation, especially when the dependencies are so tricky. snip But the feature page explicitly said no major regressions. So either the feature owner disagrees with the assessment in this thread that the breakage is a major regression; or major breakage occurred and even slipped by the feature owner. So? I'm not sure how you expect this to work better. Yeah. Looking back, https://fedoraproject.org/wiki/Changes/Bluez5explicitly says User experience should change minimally., while http://www.bluez.org/release-of-bluez-5-0/ explicitly includes Remove internal support for telephony (HFP and HSP) profiles. It's not obvious to me how the two are consistent Generally FESCo trusts the Change owners to provide accurate information, and we'd rather keep trusting everyone rather than second-guessing every word. 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: Shipping package metadata in a package
On Fri, Jan 24, 2014 at 05:50:02PM +0100, Miloslav Trmač wrote: On Fri, Jan 24, 2014 at 3:05 PM, Richard Hughes hughsi...@gmail.com wrote: In this instance, when run with background attribues, PackageKit uses idle bandwidth and with a lower priority than if the transaction was a foreground task. Huh, we have a concept of idle bandwidth? Who/how manages this? TCP/IP manages. There is Low Priority congestion algorithm implemented by Linux. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- 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; F22 will require applications to ship appdata to be listed in software center
On Fri, Jan 24, 2014 at 08:18:16 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: We should be able to calculate the number of components we as in distribution actually can manage. We just need to agree on average contribute time which could be 2.5 hours a day 5 days of the week or something and how long each component distribution task takes, and how many packagers we have and reduce ourselves to exactly that size or there about. Note that packager time isn't fungible between packages. If you ban a package a packager isn't necessarily going to use their freed up time to work on another 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
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote: On 23/01/14 21:19, Dan Williams wrote: On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 [...snip...] Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. NM only uses bluez via the D-Bus interface, so if you force install bluez4, NM will still work and should even handle the change at runtime. And then you'll get DUN back too :) Clarification: I actually don't mean runtime. NM must be restarted to notice the change from bluez4 - bluez5, but it does not need to be recompiled. The DBus interface with bluez5 have changed too. http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Does NM support both bluez NM APIs? Correct. It determines which one to use when it starts up, based on what version of bluez is running at that time. However, because of a significant change in how DUN works with Bluez5, NetworkManager does not (yet!) support DUN when Bluez5 is running. We are working on that. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Fri, 24 Jan 2014 09:58:07 -0700 Eric Smith space...@gmail.com wrote: On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote: This is not practical. Lots of people are thinking about a fedora.next, qa folks are coding away, lots of people who normally would be working on the next release are not. If we tell them to stop all that and go back to normal, we could, but then fedora.next will likely never ever happen. [...] The current problem I have with Fedora.next is that it's so abstract. How are QA folks coding away for Fedora.next, rather than traditional Fedora QA processes, if Fedora.next is so abstract? The things they are working on have been known for years, but our 6 month release cycle with no hope of being able to work on tooling hasn't allowed them to do so. So, things like replacing autoqa with taskotron, investigating beaker and other items are likely to be very helpful in both a fedora.next and a 'traditional' fedora world. I'll stop talking for them, feel free to join them on the qa-devel list and offer your help. 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: Drawing lessons from fatal SELinux bug #1054350
On Fri, 2014-01-24 at 10:58 +0100, Sergio Pascual wrote: 2014/1/24 Ralf Corsepius rc040...@freenet.de Certainly, downgrading installations which already upgraded to faulty packages would not work. Ralf The situation (a broken system that cannot be upgraded) could be mitigated a little bit by using yum + system snapshots. You can rollback to a previous sane system. There is a plugin yum-plugin-fs-snapshot, but it requires better documentation and system integration. Currently (I don't know how current is F16 documentation) it requires running lvm by hand http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/sec-Plugin_Descriptions.html AIUI there is/was a long-term plan to integrate this as core functionality using btrfs snapshots - in fact that was one of the major attractions of the idea of switching to btrfs-by-default in the first place. I believe those involved didn't think the LVM-based implementation was clean/robust enough to use by default, but a btrfs-based implementation would be. Do correct me if I'm wrong. -- 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: Drawing lessons from fatal SELinux bug #1054350
On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote: Adam Williamson wrote: TBH this has always been the one of Kevin's Big Book Of Update Policy Complaints I find the most baffling. If we know you managed to screw up your update once, why exactly would we just trust you to get it right the *second* time without any testing? * If the package is already so screwed that it breaks the whole system, it cannot realistically get any worse. Sure it can. It can wipe all your data, or mail it to the NSA... Breaks the whole system is high on the Pantscon Scale, sure, but it's not the highest. Data loss and security compromise both come higher. * A regression fix is usually a trivial change, often reverting something to a previous, already well-tested, state. Sure. And what could possibly go wrong. -- 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: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 24/01/14 18:30, Dan Williams wrote: On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote: On 23/01/14 21:19, Dan Williams wrote: On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 [...snip...] Might even be a worse conflict for other users, depending on installed packages. I believe there's no way around re-compiling NetworkManager, pulseaudio and other GNOME and KDE packages depending on bluez. NM only uses bluez via the D-Bus interface, so if you force install bluez4, NM will still work and should even handle the change at runtime. And then you'll get DUN back too :) Clarification: I actually don't mean runtime. NM must be restarted to notice the change from bluez4 - bluez5, but it does not need to be recompiled. The DBus interface with bluez5 have changed too. http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Does NM support both bluez NM APIs? Correct. It determines which one to use when it starts up, based on what version of bluez is running at that time. Perfect! However, because of a significant change in how DUN works with Bluez5, NetworkManager does not (yet!) support DUN when Bluez5 is running. We are working on that. Thanks a lot! It makes more sense after having poked at this today. I've been doing some local mockbuilds today, and noticed I could enable bluez4 in the NM spec file (it was set to --enable-bluez4=no, afaics), and I seems to produce some nm-bluez4 files. Now I just need to get the proper version built, I built the fedpkg NM master by mistake. -- kind regards, David Sommerseth -- 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.next in 2014 -- Big Picture and Themes
On Jan 24, 2014 10:29 AM, Kevin Fenzi ke...@scrye.com wrote: The things they are working on have been known for years, but our 6 month release cycle with no hope of being able to work on tooling hasn't allowed them to do so. Thanks for the clarification. I'm certainly on board with lengthening a release cycle to give them opportunity to improve the QA infrastructure, irrespective of Fedora.next. -- 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: Announce: fedostree/rpm-ostree v2014.3
From the website: Although yum is installed, it will operate in read-only mode. Do not attempt to use it at the moment. See Seems like the part talking about it is somehow missing i.e see what? ;) -- 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 - Downgrade BlueZ to v4.101 in Fedora 20
Il 24/01/2014 14:05, David Sommerseth ha scritto: FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20. Can you please shed some more light on this. From what I could grasp out of the freedesktop bug, it was a bluez bug. And PulseAudio says bluez4 is needed to get the handsfree profile working. From the BlueZ 5.0 release notes: Remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice (e.g. oFono which already supports this) For Fedora this means PulseAudio. Paolo -- 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: Drawing lessons from fatal SELinux bug #1054350
Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler: it is time to analyze the fallout from the following catastrophic Fedora 20 regression: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 rpm scriptlets are exiting with status 127 Hey, can't we add a default boot entry which starts the system in permissive mode? - fabian -- 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: Drawing lessons from fatal SELinux bug #1054350
On Fri, Jan 24, 2014 at 7:12 PM, Fabian Deutsch fabian.deut...@gmx.de wrote: Am Freitag, den 24.01.2014, 00:55 +0100 schrieb Kevin Kofler: it is time to analyze the fallout from the following catastrophic Fedora 20 regression: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 rpm scriptlets are exiting with status 127 Hey, can't we add a default boot entry which starts the system in permissive mode? How would that help? If a user knows enough about the issue to try it he/she could just switch to permissive mode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
