Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Wed, Jan 22, 2014 at 04:37:07PM +, Jóhann B. Guðmundsson wrote: On 01/22/2014 03:47 PM, Richard Hughes wrote: On 22 January 2014 12:09, Richard Hugheshughsi...@gmail.com wrote: That's a long way from what I'd like to see, but it's going up at about 1% per month, which is encouraging. Replying to my own email, apologies. I've now gone through the entire list of applications-in-fedora-without-appdata. A*lot* of those applications haven't seen an upstream release in half a decade, some over a decade. I would estimate that 40% of all the apps in Fedora are dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications, I'd say we had a 70% completion of the applications I'd like to see in the software center. I've filed a lot of upstream bugs in the last two hours, so hopefully that's another few percent sorted. I wished we could simply just clean those bits out of our distribution because quite frankly we have 14+k components in the distribution and not nearly enough manpower to cover that all. You seem to be operating under a delusion that, if someone's package is forcibly dropped, (s)he will automatically seek comaintainership of another package to fill the vacuum. That is not very likely. What is likely, however, is that (s)he will become angered, orphan the rest of his/her packages and disappear. 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
On 22 January 2014 21:44, Matthew Miller mat...@fedoraproject.org wrote: Richard already wrote a plugin :) https://github.com/GNOME/gnome-software/blob/e80d751ae0768a8969ff52e1cfc29a692a79bda0/src/plugins/gs-plugin-fedora-tagger.c Clearly, an excellent idea, then. :) Yes, it's all wired up and working in Fedora rawhide. The ratings flow both ways, so that if the user clicks on the star rating widget then it gets pushed back to fedora-tagger, and if the user hasn't got the app installed then the fedora-tagger rating is shown. It works pretty well now, but when the masses start (hopefully) using it in F21 it'll be more statistically sound. But actually what I meant was whether it would be valuable for the tagger app to _also_ let you add descriptions to applications which should have appdata but don't. This is probably a less-good idea... I was just thinking that since we have a program for user-created package metadata of one sort, maybe it could also help here. I don't think that works, as there's often an n:1 ratio of applications to packages. 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
On 23 January 2014 08:07, David Tardon dtar...@redhat.com wrote: You seem to be operating under a delusion that, if someone's package is forcibly dropped, (s)he will automatically seek comaintainership of another package to fill the vacuum. That is not very likely. What is likely, however, is that (s)he will become angered, orphan the rest of his/her packages and disappear. I don't think we need to drop any packages, unless keeping that package is actually making our life harder in a significant way. What I think it's makes a lot of sense doing is -hiding- the applications that are abandonware. Users that really want some low level tool using GTK-1 already know the package name, and are likely very familiar with the command line. 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
Hi, On Wed, Jan 22, 2014 at 12:09:25PM +, Richard Hughes wrote: Hi, As the subject suggests, Fedora 22 will require applications to have a long description to be shown in the software center. We're introducing this change so that we can show a powerful application full of high-quality content, rather than what we have now which is a equal mixture of awesome and sadness. If you're interested you can see the number of applications with appdata without installing gnome-software from rawhide here: http://alt.fedoraproject.org/pub/alt/screenshots/f21/status.html (warning; huge generated HTML file). I have noticed that there are applications on the list that have NoDisplay=true in their desktop file, e.g., libreoffice-startcenter. Should these be skipped? 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
On 23 January 2014 08:34, David Tardon dtar...@redhat.com wrote: I have noticed that there are applications on the list that have NoDisplay=true in their desktop file, e.g., libreoffice-startcenter. I've just downloaded libreoffice-4.2.0.2-2.fc21 and it has: [Desktop Entry] Version=1.0 Terminal=false NoDisplay=false Icon=libreoffice-startcenter ... 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
On 01/23/2014 08:07 AM, David Tardon wrote: On Wed, Jan 22, 2014 at 04:37:07PM +, Jóhann B. Guðmundsson wrote: On 01/22/2014 03:47 PM, Richard Hughes wrote: On 22 January 2014 12:09, Richard Hugheshughsi...@gmail.com wrote: That's a long way from what I'd like to see, but it's going up at about 1% per month, which is encouraging. Replying to my own email, apologies. I've now gone through the entire list of applications-in-fedora-without-appdata. A*lot* of those applications haven't seen an upstream release in half a decade, some over a decade. I would estimate that 40% of all the apps in Fedora are dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications, I'd say we had a 70% completion of the applications I'd like to see in the software center. I've filed a lot of upstream bugs in the last two hours, so hopefully that's another few percent sorted. I wished we could simply just clean those bits out of our distribution because quite frankly we have 14+k components in the distribution and not nearly enough manpower to cover that all. You seem to be operating under a delusion that, if someone's package is forcibly dropped, (s)he will automatically seek comaintainership of another package to fill the vacuum. That is not very likely. What is likely, however, is that (s)he will become angered, orphan the rest of his/her packages and disappear. I was operating under the *assumption* that the package was not being maintained as Richard said here... A*lot* of those applications haven't seen an upstream release in half a decade Which poses security risk and bugs not being dealt and bad end user experience if our end user base chooses to install it. ( because if they were actually being maintained here with us those fixes would have found it's way upstream and new releases been made right ). But clearly you dont understand that. 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
Am 23.01.2014 10:23, schrieb Jóhann B. Guðmundsson: A*lot* of those applications haven't seen an upstream release in half a decade Which poses security risk and bugs not being dealt and bad end user experience if our end user base chooses to install it have you ever considered software as done and no known bugs? ( because if they were actually being maintained here with us those fixes would have found it's way upstream and new releases been made right ). But clearly you dont understand that maybe you do not understand that there is no golden rule to fix bugs and release updates for no reason ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/ upstream may dead, upstream my be alive but nothing to do the software does what it is expected to do so why should there be a new release? not every software developer makes changes for the sake of the change 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 23 January 2014 10:12, Reindl Harald h.rei...@thelounge.net wrote: have you ever considered software as done and no known bugs? Okay, I'll bite. ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/ upstream may dead, upstream my be alive but nothing to do the software does what it is expected to do so why should there be a new release? From the README of mp3info-0.8.5a.tgz: --- TO DO = * ID3v2 support is the most often-requested feature and is badly needed, however this will entail an almost complete rewrite and I'm a lazy SOB, so it's going to be a while yet... Anybody wanna volunteer? --- So, a command line program for getting info from an MP3 that doesn't support ID3v2, which is a 16 year old protocol that basically every CD ripping program defaults to? I'm not sure that supports your argument much. 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
Am 23.01.2014 12:13, schrieb Richard Hughes: On 23 January 2014 10:12, Reindl Harald h.rei...@thelounge.net wrote: have you ever considered software as done and no known bugs? Okay, I'll bite. ftp://ftp.ibiblio.org/pub/linux/apps/sound/mp3-utils/mp3info/ upstream may dead, upstream my be alive but nothing to do the software does what it is expected to do so why should there be a new release? From the README of mp3info-0.8.5a.tgz: --- TO DO = * ID3v2 support is the most often-requested feature and is badly needed, however this will entail an almost complete rewrite and I'm a lazy SOB, so it's going to be a while yet... Anybody wanna volunteer? --- So, a command line program for getting info from an MP3 that doesn't support ID3v2, which is a 16 year old protocol that basically every CD ripping program defaults to? I'm not sure that supports your argument much well, my usage of that tool is simply to get the duration from files with a PHP script indexing my music archive, that call is unchanged the last 7 years and so i continue to refuse the benefit of throw a package out of the distribution because there is no new upstream release $handle = popen($GLOBALS['music_bin_mp3info'] . ' -p %S ' . escapeshellarg($path), 'r'); yes, i know that it is not a fedora package mp3info-0.8.5a-20.fc20.20131231.rh.x86_64 but it is a good example of something used and just works with our witout new upstream releases 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
[389-devel] Running lib389 tests
Hi Thierry + @all,
I'd like to play with the new lib389 and try to split DirSrv in two layers:
- the old approach DSAdmin for TCP communication
- DirSrv implementing your interface
essentially I would put
class DirSrv(DSAdmin):
# ...new stuff go here ...
class DSAdmin(SimpleLDAPObject):
# TCP stuff goes here
Can you please tell me:
1- how to run tests
2- which tests should work
3- which is the test environment.
Thx+Peace,
R.
On Thursday 09 January 2014 10:29:10 thierry bordaz wrote:
On 01/08/2014 12:54 PM, Roberto Polli wrote:
Hi Thierry,
before all sorry if in the rest of the answer I may seem too direct. All I
say is obviously imh(opinion|experience) Time is a tyrant :(
On Friday 03 January 2014 16:36:17 thierry bordaz wrote:
Thanks, I also wish you an happy new year and you recover well. It
is great to talk to you again :-) .
Thx++!
I am quite novice with python and my first approach was to use it as
a real object oriented language,
It *is* a real OOL ;)
it is a
common use to wrap methods of class and rather use python as a
functional language (e.g. self.backend.setProperties(...) rather
than 'backend=Backend(); backend.setProperties(..) ')
I'm not indepth with functional programming. Why do you think that's a
functional approach?
...the 'object'...are... the configuration object stored in
'cn=config'. So it prevents the problem of synchronizing the python
object with the 'cn=config' object.
To me that's mostly an ORM approach: in any case that's ok
Hi Roberto,
I will try to answer your concerns but as all of them are valid I
will only give some reasons for the approach I choose.
About OOL vs. functional programing this is not IMH that important.
For example for an instance with N replicas, we can imagine DSAdmin
having N Replica/Backend/Suffix/MappingTree... objects. Instead we
have only one, let's say Replica object, allocated in
__add_brookers__ but this object is not a real object but just gives
access all methods of Replica class.
As I said, having N Replica objects brings a big drawback to
synchronize the objects with what is in the server config. So I
think the __add_brookers__ approach is better.
So the only remaining object is
the DS instance (dirsrv/dsadmin) and methods to access its config.
Does it prevent to use fake directory ? I am not enough familiar
with fakeldap, would you give me an example of why the current
implement would not work with fakeldap ?
Let's see how do we setup the client now:
args = {SER_HOST: LOCALHOST,
SER_PORT: INSTANCE_PORT,
SER_DEPLOYED_DIR: INSTANCE_PREFIX,
SER_SERVERID_PROP: INSTANCE_SERVERID
}
1- instance = DirSrv(verbose=False)
2- instance.allocate(args)
3- if instance.exists(): instance.delete()
4- instance.create()
5- instance.open()
That's quite different from the (imho cleaner) old approach - similar to
the
SimpleLDAPObject superclass:
args = {'host': LOCALHOST, 'sslport': 10636}
1- instance = DSAdmin(**args)
I agree with you DSAdmin approach looks definitely simpler. Now
there is some magic behind DSAdmin().
It actually checks if the instance exists, if not it creates it,
then it opens a connection to it.
What I wanted to do in a lib is to give an interface to each
individual action. We may want to create an instance without
establishing a connection to it, or (re)create an instance even if
one already exists.
Your point is valid, we need something simple. So what about adding
a new interface to DirSrv (e.g. NewAndConnect) that would do all the
steps 1-5 ?
Obviously there are plenty of functionalities DSAdmin didn't implement: I
would have put those functionalities (eg. filesystem related, instance
creation removal) in the DSAdminTool class.
You may ask: why having two class DSAdminTool and DSAdmin instead of just
one? 1- clear design: as DSAdmin extends SimpleLDAPObject, it should
require just a tcp connection (like SimpleLDAPObject). In this way I can
use a mock ldap implementation to test the LDAP behavior of DSAdmin.
DirSrv also extends SimpleLDAPObject and wrap all its methods
(search/add...) what would prevent it to be use as mock ldap ?
2- all the functionalities requiring filesystem access and instance
management (eg. outside LDAP scope) couldn't be tested by a mock ldap
implementation, so we can just extend the mock for those functionalities.
ok
3- As extending classes (or using mix-ins) in python is really smooth,
this
approach would lead to the same usage patterns we have now, but
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Thu, Jan 23, 2014 at 09:23:49AM +, Jóhann B. Guðmundsson wrote: On 01/23/2014 08:07 AM, David Tardon wrote: On Wed, Jan 22, 2014 at 04:37:07PM +, Jóhann B. Guðmundsson wrote: On 01/22/2014 03:47 PM, Richard Hughes wrote: On 22 January 2014 12:09, Richard Hugheshughsi...@gmail.com wrote: That's a long way from what I'd like to see, but it's going up at about 1% per month, which is encouraging. Replying to my own email, apologies. I've now gone through the entire list of applications-in-fedora-without-appdata. A*lot* of those applications haven't seen an upstream release in half a decade, some over a decade. I would estimate that 40% of all the apps in Fedora are dead or semi-dead upstream. Excluding the KDE/XFCE/LXDE applications, I'd say we had a 70% completion of the applications I'd like to see in the software center. I've filed a lot of upstream bugs in the last two hours, so hopefully that's another few percent sorted. I wished we could simply just clean those bits out of our distribution because quite frankly we have 14+k components in the distribution and not nearly enough manpower to cover that all. You seem to be operating under a delusion that, if someone's package is forcibly dropped, (s)he will automatically seek comaintainership of another package to fill the vacuum. That is not very likely. What is likely, however, is that (s)he will become angered, orphan the rest of his/her packages and disappear. I was operating under the *assumption* that the package was not being maintained as Richard said here... But he did not said that. There have been any upstream release and the package is not maintained in _the distribution_ are two completely different statements. A*lot* of those applications haven't seen an upstream release in half a decade So? Maybe there have not been any bugs for half a decade that would justify a new release? Or maybe the maintainer just keeps a lot of patches in the package? Which poses security risk and bugs not being dealt Says you. Again, what if there are not any bugs? Hard to tell, because Richard did not list any names. And at what point does package become unmaintained? If I look at a couple of not-so-randomly selected packages, I see libreoffice has got 66 unresolved bugs, evolution 126 and gnome-shell 903... So which of these (if any) are not being maintained? and bad end user experience if our end user base chooses to install it. ( because if they were actually being maintained here with us those fixes would have found it's way upstream and new releases been made right ). Which fixes again? But clearly you dont understand that. No, I think your reasoning is faulty and your attempts to see everything in just black and white is fundamentally flawed. Anyway, that _was not_ the point of my mail. What I wanted to point out is that forced removal of packages _is not_ going to guarantee more packager's attention to the rest of the distribution. And it can in fact have the opposite effect, by alienating and losing existing packagers. 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
Hi, On Thu, Jan 23, 2014 at 08:51:53AM +, Richard Hughes wrote: On 23 January 2014 08:34, David Tardon dtar...@redhat.com wrote: I have noticed that there are applications on the list that have NoDisplay=true in their desktop file, e.g., libreoffice-startcenter. I've just downloaded libreoffice-4.2.0.2-2.fc21 and it has: [Desktop Entry] Version=1.0 Terminal=false NoDisplay=false Icon=libreoffice-startcenter ... Sigh, it was changed by commit 78e4c8a925f4735a7e9a4c32a29b19fd2b77670d fdo#70553: Fix Unity Quicklists. So back to changing it in the spec... 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
Richard Hughes hughsi...@gmail.com wrote: As the subject suggests, Fedora 22 will require applications to have a long description to be shown in the software center. What constitutes an 'application' in this sense? Does 'gcc' count for instance? How about 'find'? David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LibRaw soname bump
It doesn't build anyway. I've found that the latest release, 0.9.4, does, but I see you've discovered that as well. :) -J On Wed, Jan 22, 2014 at 6:06 PM, Christopher Meng cicku...@gmail.comwrote: Jon please don't rebuild oyranos, I'm working on this now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel 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 23 January 2014 12:37, David Howells dhowe...@redhat.com wrote: What constitutes an 'application' in this sense? Does 'gcc' count for instance? How about 'find'? No. In the AppStream and AppData definitions, a program is an application if it has a .desktop file that is visible in the menu. i.e. not NoDisplay=true and that has at least one valid category. 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
On 01/23/2014 12:09 PM, David Tardon wrote: No, I think your reasoning is faulty and your attempts to see everything in just black and white is fundamentally flawed. Anyway, that_was not_ the point of my mail. What I wanted to point out is that forced removal of packages_is not_ going to guarantee more packager's attention to the rest of the distribution. And it can in fact have the opposite effect, by alienating and losing existing packagers. I never implied that it would guarantee any more package attention that's an assumption you made. 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: LibRaw soname bump
It built very well(I did it this afternoon), you can check it out from Koji. Hmm...Only some tiny issues need to be solved. -- devel 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 23.01.2014 14:06, schrieb Jóhann B. Guðmundsson: On 01/23/2014 12:09 PM, David Tardon wrote: No, I think your reasoning is faulty and your attempts to see everything in just black and white is fundamentally flawed. Anyway, that_was not_ the point of my mail. What I wanted to point out is that forced removal of packages_is not_ going to guarantee more packager's attention to the rest of the distribution. And it can in fact have the opposite effect, by alienating and losing existing packagers. I never implied that it would guarantee any more package attention that's an assumption you made so what is the benefit then in propose drop packages where *upstream not* every 2-3 years starts a complete rewrite with only half of the features, a lot of bugs and regressions to qualify the next 3 years updates and after all the mess is fixed start the next rewrite to qualify ongoing development for a lifetime? if it ain't broken don't fix it! 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 Thu, Jan 23, 2014 at 09:23:49AM +, Jóhann B. Guðmundsson wrote: A*lot* of those applications haven't seen an upstream release in half a decade Which poses security risk and bugs not being dealt and bad end user experience if our end user base chooses to install it. ( because if they were actually being maintained here with us those fixes would have found it's way upstream and new releases been made right ). So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default (but maybe removed from any references in comps). That could serve as a signal to both users (who could see that the package comes from a different place) and maintainers (who wouldn't have their package just _dropped_). And it would make it more obvious when packages that are maintained have possibly-dangerous dependencies on unmaintained ones. I'm not sure the benefits of that are worth the effort, but if someone is interested in working on it, it could be worth exploring. But clearly you dont understand that. Jóhann, please review Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct. Let's keep this conversation both civil and focused on the issue itself. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unannounced soname bump: libdbi?
Hi, that was my mistake. Now both libdbi and libdbi-drivers are in new version in rawhide. -- Jan Pacner On 01/21/2014 09:53 PM, Ville Skyttä wrote: Hi, Looks like yet another unannounced soname bump has occurred in Rawhide, this time libdbi. If there was an announcement, I haven't noticed it, and neither apparently have maintainers of dependent packages, and they haven't been addressed by anyone else either except for rrdtool which is currently being rebuilt. libdbi owners, comments? Please observe https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages Affected packages include at least: Io-language collectd-dbi gammu-libs gnucash python-gammu rrdtool rrdtool-lua rsyslog-libdbi syslog-ng-libdbi ulogd-libdbi -- 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-Lucy: 9/28] - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
commit 588c2846f5dd6cc34ee19c4f5d48c16a77bfab6e
Author: Jesse Keating jkeat...@fedoraproject.org
Date: Sun Jul 26 08:52:26 2009 +
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
perl-KinoSearch.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 60227d1..581fa19 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -1,6 +1,6 @@
Name: perl-KinoSearch
Version:0.165
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Search engine library
# ApacheLicense2.0.txt included is included just becuase the upstream
# author decided to include it and is only for informative purposes.
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.165-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
* Mon Apr 13 2009 Lubomir Rintel lkund...@v3.sk - 0.165-1
- Upstream applied our PowerPC patch
--
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-Lucy: 10/28] Fix typo that causes a failure to update the common directory. (releng #2781)
commit a3b0855529b189fa3fce927e44b26d51317b5083 Author: Bill Nottingham nott...@fedoraproject.org Date: Wed Nov 25 23:30:57 2009 + Fix typo that causes a failure to update the common directory. (releng #2781) Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/Makefile b/Makefile index 6d8bb0d..b8d4037 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,7 @@ NAME := perl-KinoSearch SPECFILE = $(firstword $(wildcard *.spec)) define find-makefile-common -for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo $$d/Makefile.common ; break ; fi ; done +for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo $$d/Makefile.common ; break ; fi ; done endef MAKEFILE_COMMON := $(shell $(find-makefile-common)) -- 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-Lucy: 8/28] - Upstream applied our PowerPC patch
commit 2ad1e209c36e91a10656f7df9ced468e330bdb0a
Author: Lubomir Rintel lkund...@fedoraproject.org
Date: Mon Apr 13 16:17:04 2009 +
- Upstream applied our PowerPC patch
.cvsignore |2 +-
perl-KinoSearch.spec |7 ---
sources |2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
---
diff --git a/.cvsignore b/.cvsignore
index 311dd9f..691c164 100644
--- a/.cvsignore
+++ b/.cvsignore
@@ -1 +1 @@
-KinoSearch-0.164.tar.gz
+KinoSearch-0.165.tar.gz
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 2fb8e2f..60227d1 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -1,5 +1,5 @@
Name: perl-KinoSearch
-Version:0.164
+Version:0.165
Release:1%{?dist}
Summary:Search engine library
# ApacheLicense2.0.txt included is included just becuase the upstream
@@ -11,7 +11,6 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/KinoSearch/
Source0:
http://www.cpan.org/authors/id/C/CR/CREAMYG/KinoSearch-%{version}.tar.gz
Source1:LICENSING.mbox
-Patch0: KinoSearch-0.164-ppc.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(ExtUtils::CBuilder)
@@ -33,7 +32,6 @@ can be put to many different uses.
%prep
%setup -q -n KinoSearch-%{version}
-%patch0 -p1 -b .ppc
cp %{SOURCE1} LICENSING.mbox
%build
@@ -64,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Apr 13 2009 Lubomir Rintel lkund...@v3.sk - 0.165-1
+- Upstream applied our PowerPC patch
+
* Sun Mar 29 2009 Lubomir Rintel lkund...@v3.sk - 0.164-1
- Update to 0.164
- Add missing Pod::Coverage BRs (Robert Scheck)
diff --git a/sources b/sources
index 3f3b18a..8cf29cc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9fd011170455974544af83005f0cb350 KinoSearch-0.164.tar.gz
+c191fd096aaf4d6219bbb36812551693 KinoSearch-0.165.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
[perl-Lucy: 13/28] dist-git conversion
commit 2fe799fe2f02ad50608729f96dcb12df0301a34f Author: Fedora Release Engineering rel-...@lists.fedoraproject.org Date: Thu Jul 29 07:06:02 2010 + dist-git conversion .cvsignore = .gitignore |0 Makefile | 21 - import.log |1 - 3 files changed, 0 insertions(+), 22 deletions(-) --- diff --git a/.cvsignore b/.gitignore similarity index 100% rename from .cvsignore rename to .gitignore -- 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-Lucy: 17/28] add BR
commit eff1b259ab55eb1b6970f90613ae13d9d71f2733
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 21 10:28:51 2010 +0100
add BR
perl-KinoSearch.spec |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 3287f1f..d0bdcdd 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -12,7 +12,6 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/KinoSearch/
Source0:
http://www.cpan.org/authors/id/C/CR/CREAMYG/KinoSearch-%{version}.tar.gz
Source1:LICENSING.mbox
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::ParseXS)
@@ -22,6 +21,8 @@ BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::Pod::Coverage) = 1.04
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Time::HiRes)
+BuildRequires: perl(JSON::XS)
+BuildRequires: perl(Parse::RecDescent)
Requires: perl(Compress::Zlib)
Requires: perl(Lingua::Stem::Snowball) = 0.94
Requires: perl(Lingua::StopWords) = 0.02
@@ -69,6 +70,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Mon Dec 20 2010 Marcela Maslanova mmasl...@redhat.com - 1:0.31-2
- 661697 rebuild for fixing problems with vendorach/lib
+- add BR
* Sun Dec 12 2010 Lubomir Rintel lkund...@v3.sk - 1:0.31-1
- BR Time::HiRes to fix el6 build
--
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-Lucy: 15/28] Filter useless provide
commit 7e278932d2872263ac7a25f122b4533ee6491e87
Author: Lubomir Rintel lkund...@v3.sk
Date: Sun Dec 12 16:11:03 2010 +0100
Filter useless provide
perl-KinoSearch.spec |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index f6c8f12..b7e8e5c 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -28,6 +28,8 @@ Requires: perl(Lingua::StopWords) = 0.02
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Time::HiRes)
+%{?perl_default_filter}
+
%description
KinoSearch is a loose port of the Java search engine library Apache Lucene,
written in Perl and C. The archetypal application is website search, but it
--
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-Lucy: 22/28] Perl 5.16 rebuild
commit be9ced862029eaa246aab0beaedbda820859d2a2
Author: Petr Písař ppi...@redhat.com
Date: Wed Jun 20 22:55:14 2012 +0200
Perl 5.16 rebuild
perl-KinoSearch.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index d8b7049..9419d6e 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -5,7 +5,7 @@
Name: perl-KinoSearch
Version:
%{cpan_version_major}%{?cpan_version_minor:.}%{cpan_version_minor}
-Release:1%{?dist}
+Release:2%{?dist}
Epoch: 1
Summary:Search engine library
# ApacheLicense2.0.txt included is included just becuase the upstream
@@ -94,6 +94,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1:0.31.5-2
+- Perl 5.16 rebuild
+
* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1:0.31.5-1
- 0.315 bump
--
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-Lucy: 23/28] - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
commit 0c79fffcb9e01e3989f5b4364ef9602276f8f09a
Author: Dennis Gilmore den...@ausil.us
Date: Fri Jul 20 11:26:26 2012 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
perl-KinoSearch.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-KinoSearch.spec b/perl-KinoSearch.spec
index 9419d6e..2ba49f5 100644
--- a/perl-KinoSearch.spec
+++ b/perl-KinoSearch.spec
@@ -5,7 +5,7 @@
Name: perl-KinoSearch
Version:
%{cpan_version_major}%{?cpan_version_minor:.}%{cpan_version_minor}
-Release:2%{?dist}
+Release:3%{?dist}
Epoch: 1
Summary:Search engine library
# ApacheLicense2.0.txt included is included just becuase the upstream
@@ -94,6 +94,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:0.31.5-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
+
* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 1:0.31.5-2
- Perl 5.16 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Am 23.01.2014 16:49, schrieb Jóhann B. Guðmundsson: On 01/23/2014 01:48 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... well, why not remove all packages so no bugs get reported at all? consider packages for removal because upstream does not jump around and release at least once per year a new version is hmmm... i must not say the words in public 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 01/23/2014 01:48 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1057063] perl-Test-Moose-More-0.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1057063 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Moose-More-0.023- ||1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-23 10:53:43 -- 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=Yy05BosgApa=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: Heads up; F22 will require applications to ship appdata to be listed in software center
On Thu, Jan 23, 2014 at 03:49:17PM +, Jóhann B. Guðmundsson wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... That's not necessarily bad. And by categorizing those bugs separately, it would be easier to treat them differently. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/23/2014 03:55 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... That's not necessarily bad. And by categorizing those bugs separately, it would be easier to treat them differently. We dont want QA community members testers/reporters/triagers ( and general end users ) wasting their contributed time reporting bugs that wont get fixed. ( I assume infra/releng dont want to spent resources in those either ) Or to put this differently if the WG's expect QA to spend *any* resources in the output they deliver, we in QA need to free up contributed time time in the QA community to do so and one way to achive that is for us to plug resources leakage like this one. So do you want us being able to help you with your cloud effort or do you want us to waste time on dead components? 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 Thu, Jan 23, 2014 at 11:08 AM, Jóhann B. Guðmundsson wrote: On 01/23/2014 03:55 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... That's not necessarily bad. And by categorizing those bugs separately, it would be easier to treat them differently. We dont want QA community members testers/reporters/triagers ( and general end users ) wasting their contributed time reporting bugs that wont get fixed. Who is we? Just because upstream is inactive doesn't mean that there are bugs and just because upstream is inactive doesn't mean package maintainers won't fix bug reports. Most such components don't receive any bug reports whatsoever because they are stable and work just fine for the niche users who need them. They don't add any real overhead to Fedora and cutting them will just piss off users without any benefits. As long as package maintainers are willing to maintain them, there is no reason to mess with the process. If we want to have a way to show that upstream is inactive, that is pretty reasonable thing to do. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 23 January 2014 15:55, Reindl Harald h.rei...@thelounge.net wrote: consider packages for removal because upstream does not jump around and release at least once per year a new version is hmmm... i must not say the words in public Please stop posting to this thread. 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
On 01/23/2014 04:27 PM, Rahul Sundaram wrote: Hi On Thu, Jan 23, 2014 at 11:08 AM, Jóhann B. Guðmundsson wrote: On 01/23/2014 03:55 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... That's not necessarily bad. And by categorizing those bugs separately, it would be easier to treat them differently. We dont want QA community members testers/reporters/triagers ( and general end users ) wasting their contributed time reporting bugs that wont get fixed. Who is we? Obviously not you... Just because upstream is inactive doesn't mean that there are bugs and just because upstream is inactive doesn't mean package maintainers won't fix bug reports. If a package maintainer fixes bug the package is no longer inactive since it's being actively maintained which is what matters regardless if upstream or just downstream with us... Quite frankly it amazes me how much people put themselves on a pedestole for maintaining a component in a distribution and at the same time either fail to understand or simply disregard the time,resources and scope the service sub-community as well as feature owners have to put into that component. QA/Releng/Infra/Doc all have to spend contributed time and resources into that same component for the duration of the lifetime of the component in the distribution which more often than not, is long time after it's maintainer has vanished or the component simply is no longer being maintained downstream/upstream... And all of the above is *beside* the negative effect such components have on end users that expect it to work since it's available to them through an application installer of any kind. How much time would it have saved Richard not having to go through those dead or semi-dead components and how willing do you think people are jumping to assist him when they know there is 40% that the time they are contribute to that work will be for nothing since those app apps are dead or semi-dead upstream? To me this is pure community resources leakage due to distribution litterers with the mentality of packaging *everything* regardless if upstream is dead or not because it works for *them*. 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/23/2014 05:06 PM, Rahul Sundaram wrote: That doesn't answer the question. You keep using the word we. Who is we? We in quality assurance if you want us to come up with an official respond regarding inactively maintained packages I can put it on the meeting agenda. 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 Thu, Jan 23, 2014 at 11:56 AM, Jóhann B. Guðmundsson wrote: Obviously not you... That doesn't answer the question. You keep using the word we. Who is we? To me this is pure community resources leakage due to distribution litterers with the mentality of packaging *everything* regardless if upstream is dead or not because it works for *them*. It is not packaging everything. It is packaging things that someone cares enough to volunteer to maintain and there is no reason to cut them off. If you have specific problems in any packages, feel free to point them out. Otherwise, just presuming that they are somehow a problem is unconvincing. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Hi On Thu, Jan 23, 2014 at 12:08 PM, Jóhann B. Guðmundsson wrote: On 01/23/2014 05:06 PM, Rahul Sundaram wrote: That doesn't answer the question. You keep using the word we. Who is we? We in quality assurance if you want us to come up with an official respond regarding inactively maintained packages I can put it on the meeting agenda. Sure. Feel free to do that. As I have noted before, if you are just expressing your own opinion, you need to differentiate between that and the QA team. To speak on behalf of the entire team. you need to make sure there is consensus within that team that your opinion is shared by them. Bringing it up in a meeting is an excellent way to ensure that. If the QA team on the whole believes that packages without an active upstream are a significant resource drain on them and especially if they have any kind of metrics confirming this, we can and should look into ways to mitigating that problem. Thanks! Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/23/2014 05:06 PM, Rahul Sundaram wrote: If you have specific problems in any packages, feel free to point them out. Tracker bug [1] which fixes requirements on crontab as got approved by the FPC [2]. Each of those ca 50 components contains a patch submitted by myself in last July which updates those components to be in compliance with FPG. By going through those reports you will notice how long it took for those patches to be applied as well as see all those that have yet to be applied. I myself spent several hours of my contributing time patching, rebuilding and test installing packages with those changes with this end result. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=947037 2. https://fedorahosted.org/fpc/ticket/261 -- devel 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 Thu, Jan 23, 2014 at 12:20 PM, Jóhann B. Guðmundsson wrote: On 01/23/2014 05:06 PM, Rahul Sundaram wrote: By going through those reports you will notice how long it took for those patches to be applied as well as see all those that have yet to be applied. Yep but these are not unique to components with an inactive upstream. All such enhancements take time to get through. Any changes in the packages guidelines unless they break packages from building take a significant amount of time to work through. I still see packages that are just now adopting to using systemd macros for instance or guidelines from years back and sometimes they are deliberately doing so to maintain compatibility with older releases but in many cases, it has just not been urgent enough to look into them until now. I have been working on a package (quassel) where upstream is very active but the Fedora package maintainer has been AWOL for a long time. You have identified a problem but you are misattributing it. Even my own packages there are times where I haven't touched them for a while because I have been busy with other things. I would love to get more co-maintainers and I have requested that from time to time. What we have in Fedora is a general resource shortage and that is not particularly uncommon in any open source project. The question we need to be asking ourselves is not whether upstream is active but whether those package maintainers are active on those specific packages and if they are not, how can we identify those unattended packages and how can we help them get more attention? Cutting of random packages off the distribution is the wrong way to solve that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On 01/23/2014 05:41 PM, Rahul Sundaram wrote: Hi On Thu, Jan 23, 2014 at 12:20 PM, Jóhann B. Guðmundsson wrote: On 01/23/2014 05:06 PM, Rahul Sundaram wrote: By going through those reports you will notice how long it took for those patches to be applied as well as see all those that have yet to be applied. Yep but these are not unique to components with an inactive upstream. All such enhancements take time to get through. Any changes in the packages guidelines unless they break packages from building take a significant amount of time to work through. I still see packages that are just now adopting to using systemd macros for instance or guidelines from years back and sometimes they are deliberately doing so to maintain compatibility with older releases but in many cases, it has just not been urgent enough to look into them until now. I have been working on a package (quassel) where upstream is very active but the Fedora package maintainer has been AWOL for a long time. You have identified a problem but you are misattributing it. No I'm not in-activity is still in-activity,, In both these cases it falls on the hands of the packager/maintainer ( or none if he no longer is with us ). Now A) You cannot help those packages to get more attention. B) Even if you did our current package maintenance framework does not allow for drive by patching/helping C) Even if that was not the case as you correctly pointed out Fedora suffers from general resource shortage. all leading up to... Cutting off inactively maintained packages being the only way we can deal with that which in turn will reduce the size of the distribution to something we actually can maintain or cover ( which probably is around 5k components ) 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: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 03.01.2014 19:14, Matthew Miller wrote: […] So those are my things. What do you think about them? What else should be included? What different directions should we consider? How will we make Fedora more awesome than ever in the coming year? Okay, I'll bite (after thinking whether writing this mail is worth it): 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. The main reason for that: Fedora.next is a huge effort that seems to make everything even more complicated. It imho is also sold pretty badly right now, as you have to invest quite a lot of time to understand what Fedora.next actually is. And Fedora.next to me seems like something the core contributors push forward without having really abort those Fedora contributors who don't have Fedora as one of their top priorities in life. Verbose: Yes, I really think the Fedora needs changes -- at some point a few years ago we mostly continued to do things as they have always been done (read: since Core and Extras merged), without thinking if those ways are still the best. So I welcomed Fedora.next in the beginning. But I, as someone that is not involved very much in Fedora any more, still fail to fully grasp it. Yes, there are many mailing list or blog posts and some docs in the wiki. But most of them are really way too long for people that have busy days; a lot of those docs are also quite meta, nevertheless afaics failing to give a goal. Take https://fedoraproject.org/wiki/Fedora.next for example. It more a description of a vague idea without saying much concrete besides design, build, and market three distinct Fedora products (what is a Fedora product?). There are a few links there, but even https://fedoraproject.org/wiki/Fedora.next/boardproposal is still quite meta for something which is supposed to be the base for a release that is eight months or so away. It doesn't explain what problems are being solved or what happens to spins (KDE and such) or how often (according to current plans) Fedora will be released in the future. What really gives me the creeps on those pages: sub-committees of FESCo, with individual governance structures. Those afaics are three Product Working Groups Workgroups, two Fedora Rings Working Groups and the Inter-WG for coordination. That sounds like a awful lot of overhead an even more bureaucracy than we already have. And we imho have way to much already (part of it is my fault!) – something I had hoped Fedora.next would try to fix. I these days wouldn't start contributing to Fedora, as all those rules and guidelines that the wiki provides would scare me off. That's what Fedora.next should fix imo, as we afaics need more contributors: I more often than a few years ago find packages in Fedora that are badly maintained or outdated. Contributing must be as easy as editing a wikipedia page. Further: kororaproject.org, fedorautils-installer and similar project show that there are people that want to make Fedora better. But they do their work outside of Fedora and RPM Fusion; fixing the issues directly at the root would be better for all of us. And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for that: Fedora.next mails like the one I'm replying to seem to get very few responses -- especially considering the fact that Fedora.next is something really important and brought to a list where small details quite often spawn very long discussions. Sometimes it's different -- like the ongoing and long 3rd party and non-free software discussion. That shows that a lot of people still care, but don't bother follow to closely what the workgroups discuss before it someone gets to a point where it's more visible. 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). I have many more thoughts in my head, but I'll stop here, as those are basically the most important things that bother me right now when looking at Fedora and Fedora.next. CU knurd P.S.: Fixed subject (s/2013/2014/) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS4VlWAAoJEHK25u9MWD0tjR0QAJAe7Z35vN90Moq1mXGRpiMJ
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Jan 23, 2014, at 5:09 AM, David Tardon dtar...@redhat.com wrote: And at what point does package become unmaintained? It seems self evident that it's at least insufficiently maintained, if it doesn't meet the long description requirement to appear in software center. I don't know how else you expect this to work. What I wanted to point out is that forced removal of packages _is not_ going to guarantee more packager's attention to the rest of the distribution. Is there a reading comprehension problem in this thread? I don't recall seeing any suggestion that packages will be removed, let alone with force. They simply won't appear in software center if they don't meet the requirements for appearing in software center. 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: Heads up; F22 will require applications to ship appdata to be listed in software center
Hi Cutting off inactively maintained packages being the only way we can deal with that which in turn will reduce the size of the distribution to something we actually can maintain or cover ( which probably is around 5k components ) I don't agree with the premise at all and therefore unsurprising I don't agree with this conclusion. In any case, I sincerely doubt you will get even a single person other than yourself to agree with this proposal but feel free to try filing a ticket with the QA team. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Set-Infinite] Created tag perl-Set-Infinite-0.65-9.el7
The lightweight tag 'perl-Set-Infinite-0.65-9.el7' was created pointing to: 47a8651... - 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: Heads up; F22 will require applications to ship appdata to be listed in software center
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 22 Jan 2014 12:09:25 + Richard Hughes hughsi...@gmail.com escribió: Hi, As the subject suggests, Fedora 22 will require applications to have a long description to be shown in the software center. We're introducing this change so that we can show a powerful application full of high-quality content, rather than what we have now which is a equal mixture of awesome and sadness. Its a fine idea but not feasible if we can not work out how to pull the data together and make it available. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS4VsLAAoJEH7ltONmPFDR8KMP/3Lvx0tvrR/sOvWSgwiMmmX3 QVVPtHxgjM8X1C2o8GFZ685BjfOrqGYT4Iu7cFeyHaojFENG3mDw5nbbfhbEBQ1s 5CP/v/z4ZK3gaUfSdcYTX4DXdUX1pct6nEatBqon32aqcm+hn2dw2CYqx/aoV0uU akqEOh0TPbpsKNuqn4EIu7Hcv8FV4rcyscOVMu78IBIVDYhvrU7fJU1yQs2qfc88 /g0E8gNZzoj8+lTdnKljrPnEijoio0PCPKoMv5ZLnko8ZY2m6Fd/cbVZiBxK/LlJ VvapJyxHGv99iClVULV6LHitFUdxtK+nOOhTtCY4xpHFEgZK7XUBbSC6iCFszax3 4/nwQ1qos51Dp9F5k9oUn7dBR3Lw+bBRjwxgMJTWZ00JoSswWHZwobWOpJQplGwO en4t2gATraoDUFPlHcSCpRljK2WuHFQCd+7+SldayKmLdCOpluRzCXk1bksvQ7d/ zGIPcg9RbmJdBFdEFCTInGsl49iHrNRb5LtRccsY8jD7cNdPkduMZEgcmh8wzkHD n7z6t6VLQoWAy54gcVzy5JW+1ZAVtK92oFA8WRE5ea6ZbnElhHxFbT0QXH/i91U8 j3uUGUWbDFnDyV1zcs2RIlknd5D2rr1wd6EV6g546XAM/TIqsRf19t0Jis8Uzo06 tPluJ3Gn69GRntB+bIia =Kd7Z -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/23/2014 06:09 PM, Rahul Sundaram wrote: I don't agree with the premise at all and therefore unsurprising I don't agree with this conclusion. In any case, I sincerely doubt you will get even a single person other than yourself to agree with this proposal but feel free to try filing a ticket with the QA team. Oh I see you apparently have no idea what we in the QA community do but since you dont we dont handle this matters so there is no point for me to file a ticket it would not lead anywhere , however FESCO does and last time I knew they where trying to deal with this effectively with infra ( I have filed ticket about this before as have others ) but as you can see they are not doing very god job of dealing with it ( last result lead to them trying to find co-maintainers before removing a package as you have proposed but as you can see it has lead nowhere ) And this is a manually run process ( which Bill usually runs I think ) which they have in place which must have fallen through the cracks due the whole .next or wg stuff. ( which is not surprising ) 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: Verbose: Yes, I really think the Fedora needs changes -- at some point a few years ago we mostly continued to do things as they have always been done (read: since Core and Extras merged), without thinking if those ways are still the best. So I welcomed Fedora.next in the beginning. But I, as someone that is not involved very much in Fedora any more, still fail to fully grasp it. Yes, there are many mailing list or blog posts and some docs in the wiki. But most of them are really way too long for people that have busy days; a lot of those docs are also quite meta, nevertheless afaics failing to give a goal. Take https://fedoraproject.org/wiki/Fedora.next for example. It more a description of a vague idea without saying much concrete besides design, build, and market three distinct Fedora products (what is a Fedora product?). There are a few links there, but even https://fedoraproject.org/wiki/Fedora.next/boardproposal is still quite meta for something which is supposed to be the base for a release that is eight months or so away. It doesn't explain what problems are being solved or what happens to spins (KDE and such) or how often (according to current plans) Fedora will be released in the future. You make a fair point. There are many unanswered questions around Fedora.next (like spins?). Asking those questions or pointing out inconsistencies does help though :). What really gives me the creeps on those pages: sub-committees of FESCo, with individual governance structures. Those afaics are three Product Working Groups Workgroups, two Fedora Rings Working Groups and the Inter-WG for coordination. That sounds like a awful lot of overhead an even more bureaucracy than we already have. And we imho have way to much already (part of it is my fault!) – something I had hoped Fedora.next would try to fix. It is more overhead to a degree. On the other hand, the idea is to enable people that are interested in specific areas to go forth and create a Fedora deliverable that they think meets the needs of those areas best, without having to pass everything through FESCo. FESCo just doesn't scale like that. I these days wouldn't start contributing to Fedora, as all those rules and guidelines that the wiki provides would scare me off. That's what Fedora.next should fix imo, as we afaics need more contributors: I more often than a few years ago find packages in Fedora that are badly maintained or outdated. Contributing must be as easy as editing a The packaging guidelines are very daunting. Automating as much of that as possible, either through spec creation tooling or package review tooling would help. wikipedia page. Further: kororaproject.org, fedorautils-installer and similar project show that there are people that want to make Fedora better. But they do their work outside of Fedora and RPM Fusion; fixing the issues directly at the root would be better for all of us. Small note: The two projects you use as an example are required to do what they're doing (in part) outside of Fedora for legal reasons. I don't believe Fedora.next will change how US law works, so it might not be the best of examples. (And we have a Board meeting to discuss related things that are not legally prohibited.) And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for I wonder the same. However, I don't think it's because we haven't necessarily asked in all of the usual places, or haven't tried to reach as many people as possible. There has been very little response from anyone and I can't tell if it's from indifference or from a lack of them even being aware. It's really hard to tell. that: Fedora.next mails like the one I'm replying to seem to get very few responses -- especially considering the fact that Fedora.next is something really important and brought to a list where small details quite often spawn very long discussions. Sometimes it's different -- like the ongoing and long 3rd party and non-free software discussion. That shows that a lot of people still care, but don't bother follow to closely what the workgroups discuss before it someone gets to a point where it's more visible. Yes, that thread shows a lot of people caring. However, those people are still people that I consider core contributors. 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
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Hi On Thu, Jan 23, 2014 at 1:18 PM, Jóhann B. Guðmundsson wrote: Oh I see you apparently have no idea what we in the QA community do but since you dont we dont handle this matters so there is no point for me to file a ticket it would not lead anywhere This seems pretty incoherent and I cannot parse it. I don't know you define QA community but I have participated in QA activities before and understand the process just fine. In any case, you were the one proposing to file a ticket yourself to bring up your ideas to the QA team just a few mails back and I suggested you follow up on it. If you think you will fail to build any kind of consensus even before trying, I guess we can drop your idea and move on Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Date-Simple] Created tag perl-Date-Simple-3.03-13.el7
The lightweight tag 'perl-Date-Simple-3.03-13.el7' was created pointing to: 138c886... - 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: Git repos location
On Thu, 23 Jan 2014 05:48:00 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: https://phab.qadevel-stg.cloud.fedoraproject.org/ The hosting does work over ssh, but I'm noticing some quirks - the ssh urls are displayed incorrectly. This may be fixed in the latest upstream (the version we're using is several weeks old) but I haven't checked yet. For the dummy repo I created: * shown: ssh://phab.qadevel-stg.cloud.fedoraproject.org/diffusion/PON/ * actual thing to clone if you want it to succeed: g...@phab.qadevel-stg.cloud.fedoraproject.org:diffusion/PON - http hosting doesn't work yet. I have some more tweaking to do in order to get that functional but it's do-able Does this mean that phab repos can't be accessed publicly at this moment? What about public git:// access, is that supported/working? There is no public access at the moment - just ssh based cloning. There is no git:// access, just http(s) and ssh. Does the http hosting require fixing some bugs, or is it purely a configuration issue? It's a configuration issue - phabricator can't find the git tool used to html-ize repo interactions and I don't think it'll be a huge problem to fix. It would need to be fixed before deploying anything to production, though. I'm not willing to lose anonymous access, even if we did have mirrors on gh/bb - The repo names are ... weird. I understand why they end up like they do, but I was hoping the uris would contain the repo name, not the callsign. That's a bit unfortunate. Does it mean that we need to differentiate all our repos by 4-letter access codes? Yep, that's what it means. That would also mean that people cloning the repos need either provide a reasonable name to the git clone command, or they'll end up with cryptic directory names for our projects. Yeah. I can see if that's what upstream's intention was - code hosting is a relatively new feature and something may have changed but I doubt it. The setup is pretty straightforward and doesn't really mess with the git hosting itself - just injects phabricator into the ssh auth mechanism in a similar way to how gitolite works. If we did decide to go this route for code hosting and something did go horribly wrong, we have backups of the raw repos and it would be pretty easy to resurrect them outside of phabricator. Another feature that I haven't looked at much is mirroring - you can configure repos to push commits to a remote repository. The advantage here is that we could have the canonical upstream under our control and have bitbucket/github mirrors that other folks could use to create diffs from. This might be a very good idea. We can use our system while the public can easily find and access our code, fork it, send a pull request. I'm not sure how pull requests would work with reviews in phabricator but that would be the general idea, yeah. If we're thinking it's a good idea to host repos in phabricator, I'll try to get the last config stuff done in the next day or so. I still want to test everything thoroughly in stg first but assuming that we don't hit any big problems, we can look at migrating next weekend. Or, if we find git hosting in Phab unsatisfactory, we can do it the other way round - host code on Github/Bitbucket and clone to Phab (if it helps something, for example reviews). Yeah, the libtaskotron repo that's currently on production is a mirror of bitbucket. Either way will work well enough for code reviews. When it comes to Github/Bitbucket choice, I played with them a bit and both seem pretty equal. They are closed-source, they support teams, and because we won't need issue tracking there's not many other differences. Only Github is more popular and more people have an account there, so I think that would be the only reason to pick Github over Bitbucket. I agree that the two systems are pretty much equivalent for what we're using. The one bit that's relevant to how we'd use either one is team management. I really don't like how github does team/group management and bitbucket's interface is easier to use. I don't see how the benefit of switching to github outweighs the cost of doing so. The last time I talked to infra, they hadn't really seen an increase in contributions since they moved to github and I sincerely doubt that we would either. Their workflow has improved with the switch but almost all new contributors were already interested and involved in fedora. I'd really like to put this discussion to bed - it keeps coming up and to be quite frank, we have more important things to do than talking about which site we're using to host code when there's so little difference between the two. I'm a big believer of choosing your battles and I'm not going to fight a migration to github but I'm not going to do the migration work, either. If there's enough support here and you want to do the migration, update all the
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23/01/14 18:26, Josh Boyer wrote: On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for I wonder the same. However, I don't think it's because we haven't necessarily asked in all of the usual places, or haven't tried to reach as many people as possible. There has been very little response from anyone and I can't tell if it's from indifference or from a lack of them even being aware. It's really hard to tell. Personally I think a lot of it has to do with the way the whole thing seemed to be a fait accompli such that there seemed to be little point doing anything other than sitting back and seeing what happened. You know, the way one minute it was just a suggestion from one member of the community and the next minute it was all decided and people were busy forming working groups to sort out the details. Apparently that miraculous transition happened at Flock, but for anybody that wasn't there it was as if it was a god given edict that had been handed down on tablets of stone that Fedora.next was happening and we should all just be good little children and get on with it. 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. 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. 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. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
Christopher Meng wrote: But you can do this on copr IMO. Also update-testing is not just a place for updates to have a break, you can let it satisfy the needs of testing for unstable. Well, that's kinda abusing updates-testing. IMHO, COPR is the much better option until you have something reasonably close to going stable. 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
[Bug 1056804] (possibly) branch for EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1056804 Bill Nottingham nott...@redhat.com changed: What|Removed |Added Status|CLOSED |NEW Resolution|NOTABUG |--- Flags||fedora-cvs? Keywords||Reopened --- Comment #5 from Bill Nottingham nott...@redhat.com --- Package Change Request == Package Name: perl-HTML-Element-Extended New Branches: epel7 Owners: notting -- 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=wpg41UF0Zxa=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: boot.fedoraproject.org (BFO)
Kevin Fenzi wrote: While github is nice for pulls and patches, it's not so great for tickets and support needs. github issues are very primitive last I looked and wouldn't meet Fedora Infrastructures needs, IMHO. I also object to the idea of hosting critical parts of our infrastructure on third-party proprietary web services completely out of our control, as I already pointed out in the pkgdb2 thread. IMHO, projects where Fedora is upstream MUST be on fedorahosted.org, we should enforce that at least for our infrastructure. 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
[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-2.el7
The lightweight tag 'perl-DateTime-Set-0.33-2.el7' was created pointing to: 271802c... Bootstrap epel7 build -- 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 Thu, 23 Jan 2014 19:53:19 +0100 David Sommerseth dav...@redhat.com wrote: Hi all, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. It's already tracked in this BZ: is just downgrading bluez any help? yum downgrade bluez* --releasever=19 ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 David Sommerseth dav...@redhat.com wrote: Hi all, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. It's already tracked in this BZ: is just downgrading bluez any help? yum downgrade bluez* --releasever=19 Nope, several packages depends on the bluez-5.13-1 package. --- -- 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. -- 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
[Bug 1056804] (possibly) branch for EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1056804 Bill Nottingham nott...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE Last Closed|2014-01-23 11:20:45 |2014-01-23 14:27:44 -- 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=D9lbhDDNgna=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
[perl-HTML-TableExtract/epel7] (3 commits) ...Fix requires.
Summary of changes: 51dda63... Perl 5.18 rebuild (*) 567181b... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) f5efb4b... Fix requires. (*) 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
[perl-HTML-TableExtract] Fix requires.
Summary of changes: f5efb4b... Fix requires. (*) (*) 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: SELinux RPM scriplet issue annoucement
On Tue, 2014-01-21 at 09:54 -0500, Matthias Clasen wrote: On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote: On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: On 01/20/2014 11:48 AM, Adam Williamson wrote: The bug currently under discussion was caused by a change that came in inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ Exactly. And because everybody makes mistakes, we have processes to catch and prevent those inevitable mistakes from going out. I think it would be great to make adjustments to the process / policy so that we get better at preventing this... In context, the question as I understood it was about the SELinux developers'/packagers' workflow, not the update workflow. -- 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
[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-3.el7
The lightweight tag 'perl-DateTime-Set-0.33-3.el7' was created pointing to: 5a29747... Bootstrap of epel7 done -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote: Okay, I'll bite (after thinking whether writing this mail is worth it): Thanks. I hope that I can make you feel that it was. The main reason for that: Fedora.next is a huge effort that seems to make everything even more complicated. It imho is also sold pretty badly right now, as you have to invest quite a lot of time to understand what Fedora.next actually is. And Fedora.next to me seems like something the core contributors push forward without having really abort those Fedora contributors who don't have Fedora as one of their top priorities in life. I've been in both of those positions over the years, and I certainly don't want to leave out the more-casual contributor (or, highly committed contributors who are just really busy right now). I understand your feeling that it hasn't been documented in a way that's as helpful as could be -- I'm trying to increase what I'm doing there, and could certainly use more help from others who are good at explaining and visualizing things. I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ, and I'll post slides from that (probably here as text as well), and I assume there will be video. For many things, there hasn't been a whole lot to say because it's been in planning -- the product descriptions are not completely approved yet even, and we haven't started collectively talking about the big changes. (And we will!) I these days wouldn't start contributing to Fedora, as all those rules and guidelines that the wiki provides would scare me off. That's what Fedora.next should fix imo, as we afaics need more contributors: I more often than a few years ago find packages in Fedora that are badly maintained or outdated. Contributing must be as easy as editing a wikipedia page. Further: kororaproject.org, fedorautils-installer and similar project show that there are people that want to make Fedora better. But they do their work outside of Fedora and RPM Fusion; fixing the issues directly at the root would be better for all of us. I don't disagree with this, but I don't think they're directly related. Because we started with the governance and somewhat formal product descriptions, those are the primary visible artifacts. As we start working with the website, documentation, and design teams, more naturally-accessible starting points will take over in prominence. And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for that: Fedora.next mails like the one I'm replying to seem to get very few responses -- especially considering the fact that Fedora.next is [...] 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). I think that'll naturally solve itself as we get more concrete. But also, just looking anecdotally at the Cloud SIG, this process has helped draw in community contribution where we didn't have so much before. It gives a framework to plug in, and as more details are worked out, I expect that to snowball. So, I guess I kind of disagree with the basic premise. But also, I want to go back to the first part of my message that you're responding to. I don't think our current online communication structure really works very well for the kind of contributor you're concerned about. (Let alone working very well for more active contributors who still don't have time to read every list or hang out on IRC 24/7.) I think we need to fix that, whether we consider that part of Fedora.next or a separate big initiative. I have many more thoughts in my head, but I'll stop here, as those are basically the most important things that bother me right now when looking at Fedora and Fedora.next. I appreciate it. Does anything I've said help you feel better about it? I know I glossed over the put it off for another release part. :) And what we do with spins is still up in the air -- I have a suggestion which parallels the primary arch / secondary arch mechanism (although probably less strictly), and I need to finish fleshing that out for FESCo -- it will be on a meeting agenda after FOSDEM/DevConf. I would like to hear more of your thoughts, too. P.S.: Fixed subject (s/2013/2014/) :) Thanks. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What to do about packaging beta, or rc as alternate installable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 01:43 PM, Kevin Kofler wrote: Christopher Meng wrote: But you can do this on copr IMO. Also update-testing is not just a place for updates to have a break, you can let it satisfy the needs of testing for unstable. Well, that's kinda abusing updates-testing. IMHO, COPR is the much better option until you have something reasonably close to going stable. The other problem with using updates-testing in this way is that it makes it more difficult if you have to deliver a real bug or security fix to stable. Now you have to unpush your testing version, mangle your git history, file a new update ... I agree with Kevin that this is pretty much exactly what COPR is good at (and what I'm using it for myself[1]). 1) http://copr.fedoraproject.org/coprs/sgallagh/ReviewBoard2/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLhd8QACgkQeiVVYja6o6N1WgCgqGU51RjTv4/uizYPOV5HSBhE WFkAoLAl4Twg3iHIBgEx1O5++juLlaXH =rNyt -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: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 David Sommerseth dav...@redhat.com wrote: Hi all, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. It's already tracked in this BZ: is just downgrading bluez any help? yum downgrade bluez* --releasever=19 Nope, several packages depends on the bluez-5.13-1 package. --- -- 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. 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 :) 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: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 David Sommerseth dav...@redhat.com wrote: Hi all, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. It's already tracked in this BZ: is just downgrading bluez any help? yum downgrade bluez* --releasever=19 Nope, several packages depends on the bluez-5.13-1 package. --- -- 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. 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. 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 23 January 2014 11:48, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote: Personally I think a lot of it has to do with the way the whole thing seemed to be a fait accompli such that there seemed to be little point doing anything other than sitting back and seeing what happened. You know, the way one minute it was just a suggestion from one member of the community and the next minute it was all decided and people were busy forming working groups to sort out the details. Apparently that miraculous transition happened at Flock, but for anybody that wasn't there it was as if it was a god given edict that had been handed down on tablets of stone that Fedora.next was happening and we should all just be good little children and get on with it. There _was_ a lot that was discussed and presented at Flock. It's kind of the purpose of Flock (and FUDCon before that). Get people together to have big discussions in a high bandwith fashion. And yes, that can mean that those not in attendance are left to catch up a bit (though at least with Flock we tried to stream all the sessions to help with that). However, it wasn't decided at Flock. It was presented after Flock to FESCo, in the normal, online FESCo meetings. It went further from there to the Board via the usual channels. All of this was done as any other proposal would normally be handled. Perhaps the only unusual thing was the relative lack of debate and delay. My view of the matter was pretty much the same as Tom's and I was at FLOCK. The language at the sessions I attended was not one of We would like to do this but that it was a done thing. I realize a lot of that is the 'get shit done because we are all together' mentality which comes from conferences but by the time I left FLOCK I was pretty sure this was all done and either get in the boat or get out. I wasn't even aware of the FESCO items until this email as I figured it had been done and decided at FLOCK. Fedora.NEXT became irrelevant to me when I realized the committees were mostly hand-chosen versus elected like FESCO. I realize that was to get stuff done versus having a bunch of bureaucratci elections, but it snuffed whatever 'joy' I was going to have to participate in as a 'non-voting' member of a committee. The best way for me to allow the people to get work they wanted to get done was to get out of the way, and so I have. Now that I am asked why I am not enthused, I am explaining. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen smo...@gmail.com wrote: On 23 January 2014 11:48, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes t...@compton.nu wrote: Personally I think a lot of it has to do with the way the whole thing seemed to be a fait accompli such that there seemed to be little point doing anything other than sitting back and seeing what happened. You know, the way one minute it was just a suggestion from one member of the community and the next minute it was all decided and people were busy forming working groups to sort out the details. Apparently that miraculous transition happened at Flock, but for anybody that wasn't there it was as if it was a god given edict that had been handed down on tablets of stone that Fedora.next was happening and we should all just be good little children and get on with it. There _was_ a lot that was discussed and presented at Flock. It's kind of the purpose of Flock (and FUDCon before that). Get people together to have big discussions in a high bandwith fashion. And yes, that can mean that those not in attendance are left to catch up a bit (though at least with Flock we tried to stream all the sessions to help with that). However, it wasn't decided at Flock. It was presented after Flock to FESCo, in the normal, online FESCo meetings. It went further from there to the Board via the usual channels. All of this was done as any other proposal would normally be handled. Perhaps the only unusual thing was the relative lack of debate and delay. My view of the matter was pretty much the same as Tom's and I was at FLOCK. The language at the sessions I attended was not one of We would like to do this but that it was a done thing. I realize a lot of that is the 'get shit done because we are all together' mentality which comes from conferences but by the time I left FLOCK I was pretty sure this was all done and either get in the boat or get out. I wasn't even aware of the FESCO items until this email as I figured it had been done and decided at FLOCK. If one is advocating for something they strongly believe in, they definitely are not going to say I think maybe we should do this kinda but it might be a crazy idea. They advocate by saying I am going to do this and I am going to drive it forward until I am told no. That doesn't mean they can just skip all the processes and steps required to get their idea approved. So yes, I think for this specific item it was the get stuff done mentality that might have been misleading. The ideas were still carried forward per process though. Fedora.NEXT became irrelevant to me when I realized the committees were mostly hand-chosen versus elected like FESCO. I realize that was to get stuff done versus having a bunch of bureaucratci elections, but it snuffed whatever 'joy' I was going to have to participate in as a 'non-voting' member of a committee. The best way for me to allow the people to get work they wanted to get done was to get out of the way, and so I have. Now that I am asked why I am not enthused, I am explaining. Boostrapping is hard. I didn't come up with the idea and this might not have been the best way to do it, but hindsight is 20/20. I do hope that if you are interested in a WG/Product that you do participate because the governance for them is set up and will allow different WG members going forward. I've also seen lots of non-member participation be really fruitful already. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 7:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 03.01.2014 19:14, Matthew Miller wrote: […] So those are my things. What do you think about them? What else should be included? What different directions should we consider? How will we make Fedora more awesome than ever in the coming year? Okay, I'll bite (after thinking whether writing this mail is worth it): 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. Actually this makes sense we are currently do not even have a schedule because to many stuff is just undefined. Maybe this should be a formal proposal for FESCo to consider. -- devel 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 Thu, Jan 23, 2014 at 11:06:16AM -0700, Chris Murphy wrote: What I wanted to point out is that forced removal of packages _is not_ going to guarantee more packager's attention to the rest of the distribution. Is there a reading comprehension problem in this thread? I don't recall seeing any suggestion that packages will be removed, let alone with force. JBG suggested that. Please re-read the email that started this whole sub-thread. 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis fed...@leemhuis.info wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 03.01.2014 19:14, Matthew Miller wrote: […] So those are my things. What do you think about them? What else should be included? What different directions should we consider? How will we make Fedora more awesome than ever in the coming year? Okay, I'll bite (after thinking whether writing this mail is worth it): Hey Thorsten! Glad you did. ;) 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 main reason for that: Fedora.next is a huge effort that seems to make everything even more complicated. It imho is also sold pretty badly right now, as you have to invest quite a lot of time to understand what Fedora.next actually is. And Fedora.next to me seems like something the core contributors push forward without having really abort those Fedora contributors who don't have Fedora as one of their top priorities in life. ...snip... So, I'll share my thoughts on it here, seems like a good place. :) The current problem I have with Fedora.next is that it's so abstract. I understand that people who like PRD's and TPS want high level descriptions of what we want to do with goals and visions and such, and thats great. However, I'm a technical person. I like concrete plans and pushing what we can do with the technology we have at hand, or helping to make new technology to do what we want. We are now down to the point where groups have written up their PRD documents, and can get down to details. So, I am hopeful in the next month or so we will gain a lot more interest in fedora.next and more feedback as concrete deliverables are discussed, etc. That is my hope at least... we will see. :) 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: Hi! On 03.01.2014 19:14, Matthew Miller wrote: […] So those are my things. What do you think about them? What else should be included? What different directions should we consider? How will we make Fedora more awesome than ever in the coming year? Okay, I'll bite (after thinking whether writing this mail is worth it): 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; NO NO NO NO NO NO OH CHRIST NO. Actually, I agree with quite a lot of what you're saying; I think 21 is too early for this .next stuff and have done for a while. But that doesn't mean that if we punt .next we can release in June. Several teams have been working on the explicit understanding - as agreed by FESCo at an earlier meeting - that F21 will not be released until, at the earliest, late August *no matter what happens*. We cannot change that to June now. It would cause extreme inconvenience for QA and other teams, which in turn would result in a bad release. I'm fine with punting on .next, but I am absolutely not fine with releasing in June. Even if F21 is an old-school release, it needs to be in late August or later, as has already explicitly been stated. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: wikipedia page. Further: kororaproject.org, fedorautils-installer and similar project show that there are people that want to make Fedora better. But they do their work outside of Fedora and RPM Fusion; fixing the issues directly at the root would be better for all of us. Those particular examples are very bad examples because they are doing things Fedora explicitly chooses not to do, for *philosophical* not *practical* reasons (a choice the Board has re-affirmed this morning). Korora is hardly a 'Fedora is doing silly stuff, let's fork it' project - as per this statement on their site: Ultimately, we want people just like you to become useful members of the Fedora community and we hope that trying Korora will be a catalyst for this. And the lead Korora dev is an active Fedora contributor. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: 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. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: 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. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. Secondary being the key word. None of them are proposing alternate RPM repositories or changing the Fedora packaging guidelines. Tom was expressing that he is concerned the Fedora repos would go away or be of decreased quality. None of the WG proposals are altering those repos. They will still exist, much as they do today. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote: Hi all, Hi, This might be a viewed as a fire torch, but there is, IMO, a major regression in BlueZ 5 which is shipped in Fedora 20. I agree. But everyone probably already knows that. It doesn't support HSP/HFP headset profiles, which enables the microphone on many bluetooth headsets. Indeed -- which is a showstopper for anyone that uses a bluetooth headset as their primary means of VOX communications. Anyhow, not supporting HSP/HSP profiles is at least hitting my work ability, and I doubt I'm alone in this situation. No, you are definitely not alone. I abandoned F20 because of it. Now, if I had known this before I started upgrading to F20, I wouldn't have upgraded yet but stayed on F19 a bit longer. This is a perfect example of why I always (LVM) snapshot my existing (F19 at the time) OS before I start an upgrade. Rolling back is really as simple as updating the /etc/fstab on the snapshot-/ and creating a grub entry to boot from the snapshot-/. I've had to roll back to F19 on both my corporate laptop due to this particular issue and my personal workstation due to other issues, so I am very grateful for my cautiousness. So, I wonder if it can be considered to enable a downgrade path for bluez and depending packages, as described in the Contingency Plan: https://fedoraproject.org/wiki/Changes/Bluez5 As I understand it's really not quite that simple. The problem is that the GNOME that's in F20 depends on Bluez5 and won't work with Bluez4 so downgrading Bluez to 4 also means downgrading GNOME. IIRC there was a third dependency in all of that but I forget what it is. 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. Cheers, b. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: 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. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. Secondary being the key word. None of them are proposing alternate RPM repositories or changing the Fedora packaging guidelines. Tom was expressing that he is concerned the Fedora repos would go away or be of decreased quality. None of the WG proposals are altering those repos. They will still exist, much as they do today. The repos will still exist, but things will be different. At present, the Fedora repos are the single unified official Fedora method for deploying software on Fedora products. Any other method you can use to deploy software is not an 'official Fedora' thing. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. -- 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 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. :-/ b. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 23 Jan 2014 13:57:38 -0800 Adam Williamson awill...@redhat.com wrote: The repos will still exist, but things will be different. At present, the Fedora repos are the single unified official Fedora method for deploying software on Fedora products. Any other method you can use to deploy software is not an 'official Fedora' thing. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. Well, there's no details to see that yet. There's lots of ideas around those things, but any detailed discussion I have seen has resulted in thats implementation details, lets keep the PRD high level. Or we could use docker or SCLs or just rpms for this with no proposal. So, perhaps in the coming month we will actually see concrete proposals around how to use these methods and can actually discuss them. ;) 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 01:57:38PM -0800, Adam Williamson wrote: If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. I think this is possible -- even hopeful -- but I also don't think it's in the immediate future, because there's nothing in place to make it actually really work, let alone work well. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 4:57 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: 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. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. Secondary being the key word. None of them are proposing alternate RPM repositories or changing the Fedora packaging guidelines. Tom was expressing that he is concerned the Fedora repos would go away or be of decreased quality. None of the WG proposals are altering those repos. They will still exist, much as they do today. The repos will still exist, but things will be different. At present, the Fedora repos are the single unified official Fedora method for deploying software on Fedora products. Any other method you can use to deploy software is not an 'official Fedora' thing. Correct. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. Also possibly correct. However, that doesn't preclude the repos as we know them today from still existing, with still the same quality. As far as I'm aware, the products are still planning on being built from packages provided by the Fedora project, from the Fedora buildsystem. So yes, there may very well be different options. That doesn't mean they can't also be the same if you choose not to use those different things. I understand your concern and it's something worth watching, but I don't think it's a foregone conclusion that things will be horrible or users will be forced to give up RPMs and repos. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23 January 2014 14:14, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen smo...@gmail.com wrote: My view of the matter was pretty much the same as Tom's and I was at FLOCK. The language at the sessions I attended was not one of We would like to do this but that it was a done thing. I realize a lot of that is the 'get shit done because we are all together' mentality which comes from conferences but by the time I left FLOCK I was pretty sure this was all done and either get in the boat or get out. I wasn't even aware of the FESCO items until this email as I figured it had been done and decided at FLOCK. If one is advocating for something they strongly believe in, they definitely are not going to say I think maybe we should do this kinda but it might be a crazy idea. They advocate by saying I am going to do this and I am going to drive it forward until I am told no. That doesn't mean they can just skip all the processes and steps required to get their idea approved. I would be a lot happier if people actually did have some humility and at least went with 'this might be a crazy idea but I am doing the following and I would like people to try it out' and actually listening to the people who did try it out. Instead we have a lot of 'I have written X and it is what we will be using in the next release'. and then wonder why the hell we cut our install and contributor base after that next release. Boostrapping is hard. I didn't come up with the idea and this might not have been the best way to do it, but hindsight is 20/20. I do hope that if you are interested in a WG/Product that you do participate because the governance for them is set up and will allow different WG members going forward. I've also seen lots of non-member participation be really fruitful already. I do not doubt that non-member participation has been fruitful. At this point of the proceedings most of my time is spent hitting the 'd' key because my responses would not be fruitful and in a couple of cases, career limiting. You people don't need any more of that negativity, you already have enough. Once people get to the the technical side of how to accomplish possibly 4 times the work with RPMS and alternate packages on the same or less hardware and disk space.. then it becomes an interesting problem to me where I can contribute. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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. 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 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. 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: Fedora.next in 2014 -- Big Picture and Themes
quoting simplified: is Tom Hughes, is me, is Josh. Restored part of Tom's original context. 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. 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. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. Also possibly correct. However, that doesn't preclude the repos as we know them today from still existing, with still the same quality. Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) As far as I'm aware, the products are still planning on being built from packages provided by the Fedora project, from the Fedora buildsystem. So yes, there may very well be different options. That doesn't mean they can't also be the same if you choose not to use those different things. Is that going to be a reasonably sustainable approach, though? It's at least possible that it won't. What if the Desktop 'product' starts caring much about shipping commonly-used desktop applications as 'app bundles' rather than packages? What if the Server 'product' implements Wordpress as a container image rather than a package? I understand your concern and it's something worth watching, but I don't think it's a foregone conclusion that things will be horrible or users will be forced to give up RPMs and repos. josh I certainly agree that it's not a foregone conclusion, and I don't think I suggested it was, but your initial email seemed to more or less entirely dismiss the possibility, and I don't think that's warranted. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 5:16 PM, Adam Williamson awill...@redhat.com wrote: quoting simplified: is Tom Hughes, is me, is Josh. Restored part of Tom's original context. 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. 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. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. Also possibly correct. However, that doesn't preclude the repos as we know them today from still existing, with still the same quality. Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) I don't see how you come to that conclusion, at least not without making some large assumptions. The addition of alternate solutions for package installation and deployment doesn't preclude people from being able to install Fedora and use the underlying tools to point to the existing repos. As far as I'm aware, the products are still planning on being built from packages provided by the Fedora project, from the Fedora buildsystem. So yes, there may very well be different options. That doesn't mean they can't also be the same if you choose not to use those different things. Is that going to be a reasonably sustainable approach, though? It's at least possible that it won't. What if the Desktop 'product' starts caring much about shipping commonly-used desktop applications as 'app bundles' rather than packages? What if the Server 'product' implements Wordpress as a container image rather than a package? What if, what if, what if. Yes, all possible. Also possible is that we punt on the whole idea. This is the point where we diverge. I do not see value in somehow saying things will be different and one _cannot_ still do things they do today with no indication that such a world is even planned. You seem to be very cautionary of the whole thing. Neither view is wrong. I understand your concern and it's something worth watching, but I don't think it's a foregone conclusion that things will be horrible or users will be forced to give up RPMs and repos. josh I certainly agree that it's not a foregone conclusion, and I don't think I suggested it was, but your initial email seemed to more or less entirely dismiss the possibility, and I don't think that's warranted. I wasn't being dismissive. I have seen no plans to alter the core of how Fedora, at a package level, is built. In fact, if I did see a proposal that said we're not going to ship repositories or RPMs I'd be pretty damned upset, and I wouldn't support that. At this point I think our conversation is going to cease being productive, but I do believe it's been productive thus far. Thanks! josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) I don't see how you come to that conclusion, at least not without making some large assumptions. The addition of alternate solutions for package installation and deployment doesn't preclude people from being able to install Fedora and use the underlying tools to point to the existing repos. No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. All I'm saying is that the .next proposals at least seem to be introducing the possibility that that will no longer be the case. i.e., the possibility that there will be software within the Fedora (distribution, not project) ecosystem that you cannot deploy using our package tools and package repositories. It would of course be *possible* for someone to duplicate any work done by any of the WGs in the repositories, but it is not *guaranteed* that this happens. If the desktop WG decides to start shipping some apps as bundles not packages, and no-one takes up the work of duplicating that effort in the repositories, then the situation is different to how it is now: you can no longer rely on the idea that all 'Fedora provided software' is in the repository system. You must choose between doing whatever it is you have to do to access the alternative/secondary distribution methods - which I agree it's not worth speculating about yet - or not having access to all 'Fedora provided software'. That's all I'm saying. I'm not drawing any kinds of conclusions from this: my goal is only to ensure that all implications of possible choices here are considered. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) I don't see how you come to that conclusion, at least not without making some large assumptions. The addition of alternate solutions for package installation and deployment doesn't preclude people from being able to install Fedora and use the underlying tools to point to the existing repos. No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. I can do gem install foo or pip install foo on current (and past) fedora releases. So no the story does not quite end here ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. I can do gem install foo or pip install foo on current (and past) fedora releases. So no the story does not quite end here ;) Those are not Fedora-provided software. At the point you install and invoke gem or pip, you are making an explicit decision to use non-Fedora software. Which is, of course, perfectly fine: but it's not an analogous situation to there being alternative distribution methods *within the Fedora distribution*. -- 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: .spec file Source0 magic for github release source tarballs?
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. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. I can do gem install foo or pip install foo on current (and past) fedora releases. So no the story does not quite end here ;) Those are not Fedora-provided software. At the point you install and invoke gem or pip, you are making an explicit decision to use non-Fedora software. Which is, of course, perfectly fine: but it's not an analogous situation to there being alternative distribution methods *within the Fedora distribution*. Sure but people do that. We can either pretend they don't or try to somehow deal with it. Currently we are exploring ways to deal with it. -- devel 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 Tue, 2014-01-21 at 14:32 -0700, Kevin Fenzi wrote: On Tue, 21 Jan 2014 16:26:19 -0500 Dan Scott deni...@gmail.com wrote: Hi: A few hours ago I submitted requests to push perl-MARC-XML directly to stable (by filling out the fedpkg update request with type=security and request=stable) You cannot push any update directly to stable. Security updates have to go though the same process as any other update. This seems like a good point to ask, actually: what the hell does that field actually *mean*? I just toss a coin to fill it in, usually. -- 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: Fedora.next in 2014 -- Big Picture and Themes
Am 23.01.2014 23:49, schrieb drago01: On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 23.01.2014 23:37, schrieb drago01: On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson awill...@redhat.com wrote: No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. I can do gem install foo or pip install foo on current (and past) fedora releases. So no the story does not quite end here ;) there is a difference if you *want* do so or *forced* to do so because there is no longer a *single* and consistent package source what is over years and still *THE* greath strength of a linux *distribution* No one is proposing to force anyone to do anything so stop the FUD please where in the world do you see FUD? if a software is packed the new way and no longer available in the classical repos as RPM you are forced to use whatever to install the package this way instead of a single source like YUM what about consider the result of changes over the long instead insinuate someone is spreading FUD with no reason to do so 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: boot.fedoraproject.org (BFO)
On Wed, 2014-01-22 at 17:02 -0700, Kevin Fenzi wrote: On Thu, 23 Jan 2014 00:41:52 +0400 Peter Lemenkov lemen...@gmail.com wrote: 2014/1/23 Kevin Fenzi ke...@scrye.com: Can you please file a infrastructure ticket on this and I will get it updated. Don't know what others think, but I personally prefer GitHub pull requests because they are much simpler and don't involve any interaction with stone age software like trac or various MTAs. Just out of the curiosity why don't we mirror anything related to Fedora-Infra at GitHub? We actually have a working Fedora-Infra organisation here: https://github.com/fedora-infra While github is nice for pulls and patches, it's not so great for tickets and support needs. And you can, of course, just mail patches to mailing lists. That's what git was designed for in the first place, and it appears to work perfectly well for kernel and anaconda devs... (though the github workflow works fine too, and I've been using it quite a lot lately). has anyone yet publicly noted the irony of someone building a wildly successful proprietary SCM platform on top of a project that was written to rescue the kernel from a proprietary SCM platform, btw? :P -- 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 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? 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: Heads up; F22 will require applications to ship appdata to be listed in software center
On Thu, 2014-01-23 at 16:55 +0100, Reindl Harald wrote: Am 23.01.2014 16:49, schrieb Jóhann B. Guðmundsson: On 01/23/2014 01:48 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate repository tree still included as Fedora and enabled by default That wont reduce the bugs reported against it... well, why not remove all packages so no bugs get reported at all? consider packages for removal because upstream does not jump around and release at least once per year a new version is hmmm... i must not say the words in public I think this discussion is going down a needlessly divisive path that it doesn't need to at all. The discussion is assuming we have precisely two choices: * Rigidly and with no exceptions throw out software which meets some arbitrary approximations for determining 'maintained or abandoned' * Change nothing I don't think that's true at all. Would anyone on either side of the debate object to an approach which tried to identify software that was truly abandoned either up- or down-stream - not just 'software that no longer required changing' - and throw that out? I'm sure there's at least a certain amount of low-hanging fruit that no-one would really mind getting rid of. -- 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: What to do about packaging beta, or rc as alternate installable
On Thu, 2014-01-23 at 19:43 +0100, Kevin Kofler wrote: Christopher Meng wrote: But you can do this on copr IMO. Also update-testing is not just a place for updates to have a break, you can let it satisfy the needs of testing for unstable. Well, that's kinda abusing updates-testing. IMHO, COPR is the much better option until you have something reasonably close to going stable. It's not just kinda abusing updates-testing, *it is abusing updates-testing*. updates-testing has a specific and explicitly specified purpose: to test updates before they go to -stable. That is all that it is for. Anything in updates-testing must be something that the maintainer expects to submit to stable once testing has indicated that it works correctly. -- 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: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: Also possibly correct. However, that doesn't preclude the repos as we know them today from still existing, with still the same quality. Server, desktop or embedded board, in today's Fedora it's all the same, just with a different package set installed. People (not all, obviously) consider this a good thing. I just have to put a minimal Fedora install on some machine and then build it from there. That's what Tom was getting at, I think. The discussions in the WGs so far have hinted that it's not necessarily a reasonable expectation that this will continue to be the case. An oft-cited reason was that RPMs apparently can't provide the 'integration' that is somehow wanted. I always considered it nice that there's only a single Fedora. I thought that split products were mostly an artefact of commercial differentiation and so Fedora users don't have to deal with you can't use this filesystem unless you have the Ultra Enterprise Storage Edition or stuff like that. ☺ -- devel 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 Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote: Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) Well, maybe. It really is the case that nothing is finalized and it's a legitimate concern. This is why we (and here I'm using we not in the royal sense but because it really wasn't just _me_) have the Base Design, not just three separate product working groups. I share the trepidation about adding more bureaucracy, but also seems pretty important to keep a coherent shared base. It's possible that eventually it'll be kind of hard to go from Fedora Workstation to Fedora Cloud, or from Fedora Cloud to Fedora Workstation -- but that's not _really_ so different from how it is now, where if you start from one of those and try to go to the other, you're going to have to tear down a bunch of things first. On the other hand, the Cloud WG made the ability to go from Fedora Cloud to Fedora Server an explicit goal. Either way, I think it's pretty likely that someone who wants to start with the base and build up will be able to with, with varying possible degrees of difficulty. It may also end up that it's easier to make and share specific, lightweight remixes, so that while you don't necessarily build up in an install, you do it in a tool of some sort -- that was part of Stephen Gallagher's original products idea, if I'm remembering right. So yes, there may very well be different options. That doesn't mean they can't also be the same if you choose not to use those different things. Is that going to be a reasonably sustainable approach, though? It's at least possible that it won't. What if the Desktop 'product' starts caring much about shipping commonly-used desktop applications as 'app bundles' rather than packages? What if the Server 'product' implements Wordpress as a container image rather than a package? That might happen, although I would be shocked if anyone has anything near workable for F21 timeframe. Or F22. But, would it be so bad? People who are interested in packaging it in the traditional way still could... or, at least _I_ hope so -- that's been part of my version of the proposal since the beginning. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
