Accessing/Logging into the pkgdb
Hi, for unknown reasons, I can't login to the pkgdb anymore. What am I supposed to do? There is no "request reset password" button nor other helpful information available on the login screen. 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: Abotu setting 'PermitRootLogin=no' in sshd_config
On 11/21/2014 08:34 AM, Jan Kratochvil wrote: On Fri, 21 Nov 2014 08:11:27 +0100, P J P wrote: Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature? Almost all of my Fedora installations are test VMs where any security is irrelevant. Just my use case, not saying if it is good or bad in general. I think it's a valid use case, but rather poorly supported at the moment. For example, there should be completely seemless SSH login from virt-manager for user-manageable virtual machines (both as root and the user). My point is that once we address this (most likely through some configuration generation during VM setup), we can also switch PermitRootLogin on. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
2014-11-21 8:11 GMT+01:00 P J P : > Sshd(8) daemon by default allows remote users to login as root. > > 1. Is that really necessary? > 2. Lot of users use their systems as root, without even creating a > non-root user. > Such practices need to be discouraged, not allowing remote root login > could be > useful in that. > > Does it make sense to disable remote root login by default? If so, do we > need to just report it to the maintainer or it would be treated as a > feature? > IIRC, the main reason for PermitRootLogin being enabled by default was to prevent a remote server from becoming inaccessible in cases such as a network mounted /home suddenly becoming unavailable. Regards Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On Fri, 21 Nov 2014 08:11:27 +0100, P J P wrote: > Does it make sense to disable remote root login by default? If so, do we > need to just report it to the maintainer or it would be treated as > a feature? Almost all of my Fedora installations are test VMs where any security is irrelevant. Just my use case, not saying if it is good or bad in general. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On Fri, Nov 21, 2014 at 12:41 PM, P J P wrote: > Hello, > > Sshd(8) daemon by default allows remote users to login as root. > > 1. Is that really necessary? > 2. Lot of users use their systems as root, without even creating a non-root > user. > Such practices need to be discouraged, not allowing remote root login > could be > useful in that. > > Does it make sense to disable remote root login by default? If so, do we need > to just report it to the maintainer or it would be treated as a feature? Being a Fedora user on my personal machine as well as maintainer of a few Fedora machines in production environment, I would gladly welcome this. Many people do disable root login anyway. Having it default would be a positive step from security stand point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Abotu setting 'PermitRootLogin=no' in sshd_config
Hello, Sshd(8) daemon by default allows remote users to login as root. 1. Is that really necessary? 2. Lot of users use their systems as root, without even creating a non-root user. Such practices need to be discouraged, not allowing remote root login could be useful in that. Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned Packages in branched (2014-11-20)
On Nov 20, 2014 2:25 PM, wrote: > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Package(co)maintainersStatus Change > === ... > create-tx-configuration orphan, sparks 5 weeks ago ... Taking this one; I used it just recently and don't want to be surprised if I need it again. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned Packages in rawhide (2014-11-20)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package (co)maintainers Status Change == clc-intercal orphan, iarnell1 weeks ago cone orphan, steve 1 weeks ago create-tx-configuration orphan, sparks 5 weeks ago dbus-toolsorphan, miminar2 weeks ago fldigi-docorphan, dp67 0 weeks ago gimp-dbp orphan, paller 0 weeks ago gimp-elsamuko orphan, paller 0 weeks ago gimp-high-pass-filter orphan, paller 0 weeks ago mojomojo orphan, iarnell, perl-sig 1 weeks ago nmon orphan, paller 0 weeks ago perl-Lingua-EN-Numbers-Easy orphan, churchyard, perl-sig 3 weeks ago The following packages require above mentioned packages: Affected (co)maintainers churchyard: perl-Lingua-EN-Numbers-Easy dp67: fldigi-doc iarnell: mojomojo, clc-intercal miminar: dbus-tools paller: gimp-high-pass-filter, gimp-elsamuko, nmon, gimp-dbp perl-sig: mojomojo, perl-Lingua-EN-Numbers-Easy sparks: create-tx-configuration steve: cone Orphans (11): clc-intercal cone create-tx-configuration dbus-tools fldigi-doc gimp-dbp gimp-elsamuko gimp-high-pass-filter mojomojo nmon perl-Lingua-EN-Numbers-Easy Orphans (dependend on) (0): Orphans for at least 6 weeks (dependend on) (0): Orphans (not depended on) (11): clc-intercal cone create-tx-configuration dbus-tools fldigi-doc gimp-dbp gimp-elsamuko gimp-high-pass-filter mojomojo nmon perl-Lingua-EN-Numbers-Easy Orphans for at least 6 weeks (not dependend on) (0): -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its trac instance: https://fedorahosted.org/rel-eng/ The sources of this script can be found at: https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned Packages in branched (2014-11-20)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainersStatus Change === clc-intercal orphan, iarnell 1 weeks ago cone orphan, steve 1 weeks ago create-tx-configuration orphan, sparks 5 weeks ago dbus-toolsorphan, miminar 2 weeks ago fldigi-docorphan, dp670 weeks ago gimp-dbp orphan, paller 0 weeks ago gimp-elsamuko orphan, paller 0 weeks ago gimp-high-pass-filter orphan, paller 0 weeks ago mojomojo orphan, iarnell, perl-sig 1 weeks ago nmon orphan, paller 0 weeks ago The following packages require above mentioned packages: Affected (co)maintainers dp67: fldigi-doc iarnell: mojomojo, clc-intercal miminar: dbus-tools paller: gimp-high-pass-filter, gimp-elsamuko, nmon, gimp-dbp perl-sig: mojomojo sparks: create-tx-configuration steve: cone Orphans (10): clc-intercal cone create-tx-configuration dbus-tools fldigi-doc gimp-dbp gimp-elsamuko gimp-high-pass-filter mojomojo nmon Orphans (dependend on) (0): Orphans for at least 6 weeks (dependend on) (0): Orphans (not depended on) (10): clc-intercal cone create-tx-configuration dbus-tools fldigi-doc gimp-dbp gimp-elsamuko gimp-high-pass-filter mojomojo nmon Orphans for at least 6 weeks (not dependend on) (0): -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its trac instance: https://fedorahosted.org/rel-eng/ The sources of this script can be found at: https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Abandoning boinc-client
Hi all, despite my efforts and many wasted hours I'm unable to build recent versions of boinc-client (I'm stuck with errors about gtk-2.0 and gtk-3.0 co-existence). I'm only a co-maintainer, but the primary maintainer has abandoned the package to its fate long time ago (but he never orphaned it) and there are a lot of bugs that he never cared about. So, despite the fact that the package will not be orphaned, it will be de facto when I will abandon it. It would be nice if someone more skilled can take some care to it. Apart from problems due to gtk-3.0, I think the way boinc-client works should be rethought: the daemon mode leads to many problems accessing GPU computing capabilities and detection of user activity in X. In my opinion boinc should be started by user and not by a system process and it must run project files into user home directory to allow more users on the same workstation. Today I've made the last changes to clean up some stuff. I hope someone other has interest to take care of it. Thank you Mattia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Thu, Nov 20, 2014 at 7:44 AM, Martin Stransky wrote: > That's still much better than Chrome where the price (user tracking) is > hidden and you can't disable it. Well, Chrome isn't an option for Fedora due to proprietary portions... however, there is the Chromium project and there is an effort ongoing to get it included in the Fedora repositories. I don't think Mozilla has done anything inherently evil by including these ads in Firefox. It was done in a very unobtrusive way and they made it ridiculously easy to disable. One other point about Google, Chrome and the Chromium project. Many people have alluded to the evil empire of Google and it's nefarious tracking and hording of user information. It isn't nefarious if you explain to people exactly what you are doing. Google has gone to extreme lengths to make it's data collection policies as transparent as possible. You can learn about what Chrome collects and how by reading the privacy policy which is easily found. If you take the time to read it, you'll find there is nothing sinister at all going on. What is going on however is the fact that Google competitors are spreading FUD much like Microsoft had done about Linux. -- 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-ExtUtils-Manifest] 1.69 bump
commit e449928a2af8d594253388145edee1367d60e5ad
Author: Petr Písař
Date: Thu Nov 20 17:59:20 2014 +0100
1.69 bump
.gitignore |1 +
perl-ExtUtils-Manifest.spec | 12 ++--
sources |2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 82eadf6..417669a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/ExtUtils-Manifest-1.65.tar.gz
/ExtUtils-Manifest-1.66.tar.gz
/ExtUtils-Manifest-1.68.tar.gz
+/ExtUtils-Manifest-1.69.tar.gz
diff --git a/perl-ExtUtils-Manifest.spec b/perl-ExtUtils-Manifest.spec
index 80f34a3..1b0bb2b 100644
--- a/perl-ExtUtils-Manifest.spec
+++ b/perl-ExtUtils-Manifest.spec
@@ -1,11 +1,11 @@
Name: perl-ExtUtils-Manifest
-Version:1.68
+Version:1.69
Release:1%{?dist}
Summary:Utilities to write and check a MANIFEST file
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/ExtUtils-Manifest/
-Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/ExtUtils-Manifest-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/E/ET/ETHER/ExtUtils-Manifest-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -26,12 +26,9 @@ BuildRequires: perl(File::Spec) >= 0.8
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Test::More)
+# CPAN::Meta not needed
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
Requires: perl(File::Path)
-Requires: perl(File::Spec) >= 0.8
-
-# Remove underspecified dependencies
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Spec\\)\\s*$
%description
%{summary}.
@@ -57,6 +54,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Nov 20 2014 Petr Pisar - 1.69-1
+- 1.69 bump
+
* Wed Sep 17 2014 Petr Pisar - 1.68-1
- 1.68 bump
diff --git a/sources b/sources
index 19fde82..a8c2857 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0284039fc5aa81bf2d77df6f3a4bf95c ExtUtils-Manifest-1.68.tar.gz
+cb001f834cc0f0e992d8c780eace6f2f ExtUtils-Manifest-1.69.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: Mozilla enabled ads in Firefox and they're active in Fedora
On 2014-11-20, 14:28 GMT, Petr Viktorin wrote: > Ads are a feature that only benefits the upstream and the companies that > pay for the ads. From my (user's) perspective, there is no reason to > have them on my system. There is no benefit to me from this feature. Sorry, I have to ask here the obvious question: how much did you pay for Firefox? How much do you think it costs to develop Firefox and to keep up with the Google’s endless pockets? Do you have some better solution for Mozilla to resolve this difference? I am quite sure your genial idea making couple of hundred million USD per year for them without any ads would be very welcome. Unfortunately, that communism thing somehow didn’t work ... it would be lovely if it did. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On 11/20/2014 04:44 PM, Martin Stransky wrote: On 11/20/2014 03:28 PM, Petr Viktorin wrote: It's not about tracking per se – I'm fine with e.g. opt-in usage reports that feed into research for making a better browser – that benefits me (in a very indirect and miniscule way, but in the end the purpose is for the *user's* benefit). Ads are a feature that only benefits the upstream and the companies that pay for the ads. From my (user's) perspective, there is no reason to have them on my system. There is no benefit to me from this feature. None at all. This is a major difference from Gnome search providers, which I personally don't like either, but I can see how they might be good for someone. From the user perspective Mozilla provides you a high-quality browser for free (free as a beer). But they have to pay engineers for the work. Every piece of Fedora is like that, and yet I don't see any other software doing useless-for-me opt-out tracking. (Also, who am I paying? All authors of Firefox, or only the Mozilla employees?) There are some other options there. To have free (basic) and paid (extended) Firefox versions - Red Hat goes this way. Or direct donation from users like Wikipedia. Mozilla chose the Ads way and you may or may not accept it and you exactly know what's the (asked) price. The question is, will *Fedora* accept it on my behalf? Will Fedora no longer shield me from the ways of the Android developer? That's still much better than Chrome where the price (user tracking) is hidden and you can't disable it. Well, you can – the Chromium source is out there. The only catch is that Chromium is not built primarily for users, but for the developers' benefit. You can remove the Ads from Firefox by one click so no big deal here. The same case is using Addblock to block Ads on Web. But you're giving nothing back then. Is there now an *obligation* to give back? Because there never has been such a thing. I personally give quite a lot back, not to Mozilla specifically but to open-source community as a whole – but it's not because I have an obligation to do it nor because I'm forced to do it. The recend trend of "open source" guiding me to become part of some monetization scheme saddens me. Every user likes the best software for free (as a beer), but there isn't any magic wand which makes it up for you. The process which gave us Firefox so far seemed quite fine. I'm sure it was no easy wand-waving, but so far it has been for the user first. Sure, Mozilla did not organize as many events or hire so many employees or get to dabble in the phone business. But the result is, so far, great. I want my software to work for *me*; the free as in beer part is secondary. -- Petr³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
> Being bombarded with questions when you just want to get to using > something isn't the best user experience, and I think in general > something we've been trying to reduce. This doesn't need to be must-choice. A checkbox won't hurt, but I am not UX expert. Having that said, this is not a valid point when I suggest not to do the decision for the user. > How would that be implemented? What would it apply to? The firstboot script would drop a config value to the user home directory (touch ~/.no-ads) and call some kind of script distributed in a separate package that would re-configure all the programs to opt-out according to this setting. The first one would be Firefox. I am not aware of any other package in Fedora that have ads, but this way we could have a policy how to deal with those. Each package could drop a script that would do the work into let's say /etc/ads-opt-out.d/ or similar. But if you'd ask me to do the decision for the user, I'd definitely respond with "no ads". -- Later, Lukas #lzap Zapletal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On 11/20/2014 03:28 PM, Petr Viktorin wrote: It's not about tracking per se – I'm fine with e.g. opt-in usage reports that feed into research for making a better browser – that benefits me (in a very indirect and miniscule way, but in the end the purpose is for the *user's* benefit). Ads are a feature that only benefits the upstream and the companies that pay for the ads. From my (user's) perspective, there is no reason to have them on my system. There is no benefit to me from this feature. None at all. This is a major difference from Gnome search providers, which I personally don't like either, but I can see how they might be good for someone. From the user perspective Mozilla provides you a high-quality browser for free (free as a beer). But they have to pay engineers for the work. There are some other options there. To have free (basic) and paid (extended) Firefox versions - Red Hat goes this way. Or direct donation from users like Wikipedia. Mozilla chose the Ads way and you may or may not accept it and you exactly know what's the (asked) price. That's still much better than Chrome where the price (user tracking) is hidden and you can't disable it. You can remove the Ads from Firefox by one click so no big deal here. The same case is using Addblock to block Ads on Web. But you're giving nothing back then. Every user likes the best software for free (as a beer), but there isn't any magic wand which makes it up for you. ma. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On 11/20/2014 04:02 PM, Matthew Miller wrote: On Thu, Nov 20, 2014 at 03:28:11PM +0100, Petr Viktorin wrote: tl;dr: I think the line we should not cross is: including features that don't benefit the user and may be considered harmful. I don't think this is a very clear line. Should we drop all spreadsheet applications? http://www.velocityreviews.com/threads/spreadsheets-considered-harmful.717849/ Spreadsheet applications exist to benefit the user, so they don't cross this line. (With a short-circuiting "and"¹, you won't even get to the "may be considered harmful" part in this case...) -- Petr³ ¹ http://en.wikipedia.org/wiki/Short-circuit_evaluation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Thu, Nov 20, 2014 at 03:28:11PM +0100, Petr Viktorin wrote: > tl;dr: I think the line we should not cross is: including features > that don't benefit the user and may be considered harmful. I don't think this is a very clear line. Should we drop all spreadsheet applications? http://www.velocityreviews.com/threads/spreadsheets-considered-harmful.717849/ -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On 11/19/2014 09:11 AM, Benjamin Kerensa wrote: Hello Free Software Friends, I want to encourage the Fedora Community to think carefully about making a switch to another browser as the default in Fedora. I would not get hung up on these tiles (Ads) too much and remember they are necessary in order for Mozilla to continue building Firefox, Thunderbird, Seamonkey, Firefox OS and supporting the very literally hundreds of movements and thousands of events it does each year. But that all aside I hope you will weigh whether the alternatives will provider your users any better of an experience in terms of Stability, Performance, Privacy or Trust. I think it will be difficult to find an alternative that offers what Firefox does to your users and frankly I think you will have a fair amount of users that will be upset that you switched the default on them. Sure they can still install Firefox but the fact is Fedora users come to expect Firefox to be the default much like they expect Gnome to be the default. (Also remember there are very likely thousands of Mozilla Contributors that use Fedora) In other words: you have achieved have vendor lock-in. Congratulations! Good for you. Not so good for me. Whatever your decision have a good release cycle and keep on building that awesome free software! Free software is, and always has been, about users. If something does not benefit the users should be able to switch away – where "something" is not whole applications, but individual *features* of applications. Compare, for example, to the ad-ridden, spy-heavy, vendor-locked-in Android ecosystem, where users can't turn off unwanted features. Most software there is written to benefit the *developers*, not the *users*. Sure, it is more profitable for them that way, and the terms of some of those apps are even acceptable. But the fact that this model is finding its way into free software is worrying at best. I think the line we should not cross is: including features that don't benefit the user and may be considered harmful. If I opt-in to ads – if you politely ask, and I, with mutual respect and understanding, agree to help your cause – then it's perfectly fine. (See vim's "Help kids in Uganda" message.) If you just quietly make money off me, or distract and annoy me until I have paid, then I can't and will not respect you. It's not about tracking per se – I'm fine with e.g. opt-in usage reports that feed into research for making a better browser – that benefits me (in a very indirect and miniscule way, but in the end the purpose is for the *user's* benefit). Ads are a feature that only benefits the upstream and the companies that pay for the ads. From my (user's) perspective, there is no reason to have them on my system. There is no benefit to me from this feature. None at all. This is a major difference from Gnome search providers, which I personally don't like either, but I can see how they might be good for someone. If I wanted software that works and is adequately funded, I'd use Chrome. If Mozilla slides into forcing ads on people, the difference between Chrome and Firefox becomes quantitative, not qualitative – Google does the same bad stuff, but worse. Personally, I sadly no longer trust Mozilla to do what's best for me. (Please don't become the next Google. Yes, I'm aware Google makes lots of money and can easily fund development and thousands of events each year. That does not make them an example I think Mozilla should follow.) If Fedora starts including, as soldiers in a Trojan horse of default software, upstreams' features that don't benefit me and may be considered harmful, then Fedora will lose my trust as well. tl;dr: I think the line we should not cross is: including features that don't benefit the user and may be considered harmful. -- Petr³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap
Once again, thank you Michael. I have corrected version number to reflect executable version and patched shebang line. 2014-11-20 12:11 GMT+01:00 Michael Schwendt : > On Wed, 19 Nov 2014 21:13:29 +0100, Lorenzo Dalrio wrote: > >> In my hurry I have swapped Version and Release following exactly the >> guidelines you have linked. :-/ > > Well, a package being tiny does not imply there's nothing to be reviewed. > > The top of the executable says > > __version__ = '1.2.0' > > which it displays somewhere in the tools Help system. The CHANGELOG file > says "Version 1.2". > > The script contains a shebang that can become problematic, unless > it really works with both Python 2 and Python 3: > > #!/usr/bin/env python > > https://fedorahosted.org/fpc/ticket/327 > Older topic: > http://fedoraproject.org/wiki/Script_Interpreters_%28draft%29 > https://www.redhat.com/archives/fedora-packaging/2009-July/msg00056.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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: remove git-bzr from rawhide?
On Thu, Nov 20, 2014 at 10:57:36AM +0100, Petr Stodulka wrote: > I think about removal of git-bzr package in rawhide, which is actualy > non-functional - contains only file with warning message > about replacement by git-remote-bzr package - which actualy replace git-bzr > in f21 too. Are you OK with it? I didn't remove any > package earlier, but after short discussion I want to remove it from > specfile of git only and add Provides/Obsoletes > into the git-remote-bzr. Is there anything else what should I do? Or do you > think someone that should be still kept? I was surprised (in a bad way), when git remote update instead showed me big warning and did nothing. Doing dnf upgrade did nothing, executing commands from git-bzr warning also did nothing (because /usr/libexec/git-core have preference over $PATH). And only after that I've found git-remote-bzr package... So, I think non-functional git-bzr must be removed and appropriate Provides/Obsoletes must be add in all branches. If someone thinks, that git-bzr must be present for some reason, better make it empty and require git-remote-bzr. -- Regards,-- Sir Raorn. --- https://plus.google.com/+AlexeyFroloff pgpp_i3lxOOj2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the release of Fedora 21 Beta for the POWER architecture!
The Fedora 21 beta release for the POWER platform, in Big and Little Endian flavours, is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. What is the Beta Release? = The beta release is the last important milestone before the release of Fedora 21. A Beta release is code-complete and bears a very strong resemblance to the third and final release. Only critical bug fixes will be pushed as updates up to the general release of Fedora 21. The final release of Fedora 21 is [https://fedoraproject.org/wiki/Releases/21/Schedule] expected in early December. Meanwhile, download the beta of Fedora 21 and help us make it even better: https://fedoraproject.org/wiki/How_to_file_a_bug_report Every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora 21 a rock-solid distribution. We have a culture of coordinating new features and pushing fixes upstream as much as feasible and your feedback will help improve not only Fedora but Linux and free software on the whole. https://fedoraproject.org/wiki/Staying_close_to_upstream_projects (See the end of this announcement for more information on how to help.) Fedora 21 Base -- Each of the products will build on the "base" set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, Yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. The Base set of packages is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. Highlights in the Beta Release == In this section, we'll look at some of the things that are new or interesting in the Beta release. A Note on Shellshocked -- You've probably read all about the "Shellshocked" vulnerability in GNU Bash, which affected Fedora 19, 20, and 21 Alpha. Rest assured that Fedora 21 beta has been patched to close this vulnerability. Fedora 21 Server The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. Fedora Server Management Features = The Fedora Server product introduces new Server management features aimed at making it easier to install discrete infrastructure services. The Fedora Server will introduce three new technologies in Fedora to handle this task, rolekit, Cockpit and OpenLMI. Rolekit (https://fedorahosted.org/rolekit) is a Role deployment and management toolkit that provides a consistent interface to administrators to install and configure all the packages needed to implement a specific server role. Rolekit is at an early stage of development in Fedora 21 Beta. Cockpit (http://cockpit-project.org/) is a user interface for configuring and monitoring your server or servers. It is accessible remotely via a web browser. OpenLMI (http://www.openlmi.org/) is a remote management system built atop DMTF-CIM. It can be used for scripting management functions across many machines as well as querying for capabilities and monitoring for system events. *** Release Schedule *** The full release schedule is available on the Fedora wiki. The current schedule currently calls for the final release to come out on December 9th: https://fedoraproject.org/wiki/Releases/21/Schedule Dates are subject to change, pending any major bugs or issues found during the development process. Issues and Details --- This is an Beta release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the QA mailing list (test at lists.fedoraproject.org) or in #fedora-qa on freenode. For tips on reporting a bug effectively, read "How to file a bug report:" https://fedoraproject.org/wiki/How_to_file_a_bug_report Thanks much to all the contributors who've helped bring Fedora 21 this far! We're very excited about this release, and we hope that you'll enjoy it too. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the release of Fedora 21 Beta for ARM aarch64!
The Fedora 21 beta release for the ARM aarch64 platform is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. What is the Beta Release? = The beta release is the last important milestone before the release of Fedora 21. A Beta release is code-complete and bears a very strong resemblance to the third and final release. Only critical bug fixes will be pushed as updates up to the general release of Fedora 21. The final release of Fedora 21 is [https://fedoraproject.org/wiki/Releases/21/Schedule] expected in early December. Meanwhile, download the beta of Fedora 21 and help us make it even better: https://fedoraproject.org/wiki/How_to_file_a_bug_report Every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora 21 a rock-solid distribution. We have a culture of coordinating new features and pushing fixes upstream as much as feasible and your feedback will help improve not only Fedora but Linux and free software on the whole. https://fedoraproject.org/wiki/Staying_close_to_upstream_projects (See the end of this announcement for more information on how to help.) Fedora 21 Base -- Each of the products will build on the "base" set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, Yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. The Base set of packages is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. Highlights in the Beta Release == In this section, we'll look at some of the things that are new or interesting in the Beta release. A Note on Shellshocked -- You've probably read all about the "Shellshocked" vulnerability in GNU Bash, which affected Fedora 19, 20, and 21 Alpha. Rest assured that Fedora 21 beta has been patched to close this vulnerability. Fedora 21 Server The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. Fedora Server Management Features = The Fedora Server product introduces new Server management features aimed at making it easier to install discrete infrastructure services. The Fedora Server will introduce three new technologies in Fedora to handle this task, rolekit, Cockpit and OpenLMI. Rolekit (https://fedorahosted.org/rolekit) is a Role deployment and management toolkit that provides a consistent interface to administrators to install and configure all the packages needed to implement a specific server role. Rolekit is at an early stage of development in Fedora 21 Beta. Cockpit (http://cockpit-project.org/) is a user interface for configuring and monitoring your server or servers. It is accessible remotely via a web browser. OpenLMI (http://www.openlmi.org/) is a remote management system built atop DMTF-CIM. It can be used for scripting management functions across many machines as well as querying for capabilities and monitoring for system events. *** Release Schedule *** The full release schedule is available on the Fedora wiki. The current schedule currently calls for the final release to come out on December 9th: https://fedoraproject.org/wiki/Releases/21/Schedule Dates are subject to change, pending any major bugs or issues found during the development process. Issues and Details --- This is an Beta release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the QA mailing list (test at lists.fedoraproject.org) or in #fedora-qa on freenode. For tips on reporting a bug effectively, read "How to file a bug report:" https://fedoraproject.org/wiki/How_to_file_a_bug_report Thanks much to all the contributors who've helped bring Fedora 21 this far! We're very excited about this release, and we hope that you'll enjoy it too. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141120 changes
Compose started at Thu Nov 20 05:15:06 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.i686 requires libmongoclient.so [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [perl-MooseX-Declare] perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Syntax::MethodDeclaration::Parameterized) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::StackItem) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Context::WithOptions) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-newgem] rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) >= 0:1.5.3 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [authhub] authhub-0.1.2-3.fc19.x86_64 requires libjson.so.0()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.x86_64 requires libmongoclient.so()(64bit) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 1:fatrat-1.2.0-0.21.beta2.fc22.x86_64 requires libtorrent-rasterbar.so.7()(64bit) [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.x86_64 requires libmongoclient.so()(64bit) [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.x86_64 requires libopenobex.so.1()(64bit) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [perl-MooseX-Declare] perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Syntax::MethodDeclaration::Parameterized) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::StackItem) perl-MooseX-Declare-0.40-1.fc22.noarch requires perl(MooseX::Declare::Context::WithOptions) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-newgem] rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) >= 0:1.5.3 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [authhub] authhub-0.1.2-3.fc19.armv
F-21 Branched report: 20141120 changes
Compose started at Thu Nov 20 07:15:30 UTC 2014 Broken deps for armhfp -- [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [gearbox] gearbox-10.11-8.fc21.armv7hl requires libIceUtil.so.35 gearbox-10.11-8.fc21.armv7hl requires ice gearbox-devel-10.11-8.fc21.armv7hl requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [ostree] ostree-grub2-2014.11-1.fc21.armv7hl requires grub2 [rubygem-newgem] rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) >= 0:1.5.3 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc21.noarch requires ldc Broken deps for i386 -- [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.i686 requires libtorrent-rasterbar.so.7 [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [rubygem-newgem] rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) >= 0:1.5.3 Broken deps for x86_64 -- [authhub] authhub-0.1.2-3.fc19.x86_64 requires libjson.so.0()(64bit) [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.i686 requires libtorrent-rasterbar.so.7 1:fatrat-1.2.0-0.21.beta2.fc21.x86_64 requires libtorrent-rasterbar.so.7()(64bit) [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-10.11-8.fc21.x86_64 requires libIceUtil.so.35()(64bit) gearbox-10.11-8.fc21.x86_64 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel gearbox-devel-10.11-8.fc21.x86_64 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.x86_64 requires libopenobex.so.1()(64bit) [rubygem-newgem] rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) >= 0:1.5.3 Removed package: audtty-0.1.12-9.fc20 Removed package: condor-cloud-0.1-8.fc21 Removed package: deltacloud-core-1.1.3-1.fc20 Removed package: django-recaptcha-0.1-7.20091212svn6.fc21 Removed package: dragonegg-3.4-0.3.rc0.fc21 Removed package: edelib-2.1-5.fc21 Removed package: flush-0.9.12-10.fc21 Removed package: gdesklet-SlideShow-0.9-16.fc21 Removed package: gdesklets-citation-2.0-3.20120702git355e2ee.fc19 Removed package: gedit-valencia-0.4.0-1.20131223git94442bf.fc21 Removed package: ltsp-5.4.5-8.fc21 Removed package: monodevelop-vala-2.8.8.1-6.fc21 Removed package: netdisco-1.1-7.fc21 Removed package: ocaml-pa-do-0.8.16-3.fc21 Removed package: openslides-1.3.1-3.fc21 Removed package: openvas-client-3.0.3-8.fc20 Removed package: pootle-2.1.6-8.fc21 Removed package: python-askbot-fedmsg-0.1.0-2.fc21 Removed package: python-coffin-0.3.7-3.fc21 Removed package: python-django-addons-0.6.6-2.fc21 Removed package: python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21 Removed package: rubygem-rubigen-1.5.8-3.fc21 Removed package: sugar-tamtam-0-0.14.20100201git.fc21 Removed package: transifex-1.2.1-12.fc21 Removed package: valabind-0.7.4-4.fc21 Removed package: zyGrib-6.1.4-3.fc20 Summary: Added Packages: 0 Removed Packages: 26 Modified Packages: 0 Size of added packages: 0 (0 ) Size change of modified packages: 0 (0 ) Size of removed packages: 46784400 (45 M) Size change: -46784400 (-45 M) Compose finished at Thu Nov 20 11:32:16 UTC 2014 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap
On Wed, 19 Nov 2014 21:13:29 +0100, Lorenzo Dalrio wrote: > In my hurry I have swapped Version and Release following exactly the > guidelines you have linked. :-/ Well, a package being tiny does not imply there's nothing to be reviewed. The top of the executable says __version__ = '1.2.0' which it displays somewhere in the tools Help system. The CHANGELOG file says "Version 1.2". The script contains a shebang that can become problematic, unless it really works with both Python 2 and Python 3: #!/usr/bin/env python https://fedorahosted.org/fpc/ticket/327 Older topic: http://fedoraproject.org/wiki/Script_Interpreters_%28draft%29 https://www.redhat.com/archives/fedora-packaging/2009-July/msg00056.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
remove git-bzr from rawhide?
Hi folks, I think about removal of git-bzr package in rawhide, which is actualy non-functional - contains only file with warning message about replacement by git-remote-bzr package - which actualy replace git-bzr in f21 too. Are you OK with it? I didn't remove any package earlier, but after short discussion I want to remove it from specfile of git only and add Provides/Obsoletes into the git-remote-bzr. Is there anything else what should I do? Or do you think someone that should be still kept? And probably Obsoletes/Provides could be set in f21 too - https://bugzilla.redhat.com/show_bug.cgi?id=1164212. Disagree anyone with it? Thanks Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-11-19)
On 11/20/2014 08:05 AM, Till Maas wrote: > On Wed, Nov 19, 2014 at 03:06:11PM -0500, Tomas Mraz wrote: > > > * #1368 How to deal with F21 broken dependencies (t8m, 19:08:56) > > * AGREED: FESCo agrees to dropping the packages with broken > > dependencies listed in #1368 from both F21 and rawhide (+7, -0, 0:0) > > (t8m, 19:25:56) > > I retired the packages now. To make sure the final repo does not > contain any packages with broken dependencies, the Freeze Exception > process needs to be used to get packages from updates-testing that do > not contain broken dependencies into the stable repo: > https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process > > > * AGREED: We will do the broken deps cleanup on Final Freeze from now > > on in the future Fedora releases (+8, -0, 0:0) (t8m, 19:30:41) > > * There will be warning sent to the affected maintainers at least 3 > > weeks in advance (t8m, 19:31:36) > > What happens with packages that get broken after the warning but before > the Final Freeze? > > Regards > Till > Please someone correct me if I'm wrong, but all broken packages should be cleaned up after the Final Freeze. However we could send one more "up-to-date" reminder after the Freeze. Regards, Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
