Fedora 2014 GSoC idea list

Hello, The Google Summer of Code 2014 is approaching, When will Fedora publish the new idea list? -- devel 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 Sat, Jan 25, 2014 at 7:41 AM, Adam Williamson wrote: > drago01 wrote: >>On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson >>wrote: >>> On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote: >>> > As a side note, it also needs to be discussed how such a key >>feature of > the blu

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On 24 January 2014 19:15, Przemek Klosowski wrote: > The term 'hiding' conveys a wrong implication that abandonware is > necessarily an embarrassment to be kept locked up in the attic. I think that's the right implication. > I can think > of several programs that I use daily that are simple enou

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi! On 23.01.2014 19:26, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis > wrote: > > […] Thx for your answer, just replying to some parts of it where I feel that making additional statements bring the discussion forward. >> What really gives me the creeps on those page

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, Jan 24, 2014 at 11:14:50AM -0800, Adam Williamson wrote: > On Fri, 2014-01-24 at 19:26 +0100, Michael Schwendt wrote: > > > > * That update made it out to the stable updates! In other words, the > > > draconian Update Policies that were enacted in a vain attempt to prevent > > > such iss

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, Jan 25, 2014 at 11:20 AM, Thorsten Leemhuis wrote: > [cut] > > The Fedoraproject once again chose to leave non-free out of Fedora. I > appreciate that. I even think a lot of users understand why the > Fedoraproject acts like this (now and earlier, too). But: it utterly > hard to get non-fr

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi! On 23.01.2014 20:57, Matthew Miller wrote: > 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. Thx for your answer – yes, I think it was worth it.

Re: Fedora.next in 2014 -- Big Picture and Themes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 23.01.2014 22:33, Kevin Fenzi wrote: > On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis > wrote: >> On 03.01.2014 19:14, Matthew Miller wrote: >>> […] So those are my things. What do you think about them? What >>> else should be include

Re: Fedora.next in 2014 -- Big Picture and Themes

Hi! On 23.01.2014 22:45, Adam Williamson wrote: > 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

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, Jan 24, 2014 at 20:40:28 -0800, Josh Stone wrote: My point was not about what root can do. Suppose there's a vulnerable 'sudo' binary that gives everyone a root shell. If that binary is available on any executable path, even readonly, that's trouble. That isn't true. File systems

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

Paolo Bonzini wrote: > From the BlueZ 5.0 release notes: > > "Remove internal support for telephony (HFP and HSP) profiles. They > should be implemented using the new Profile interface preferably by the > telephony subsystem of choice (e.g. oFono which already supports this)" > > For Fedora this

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote: > Debian, who has a similar stance on > non-free Software, does a way better job in that area than Fedora does. Well, not really - they don't have a 'similar stance', they have an official non-free repository. That's kind of a significan

Re: Drawing lessons from fatal SELinux bug #1054350

Ralf, Harald, you both actually mean the same thing, you're just misunderstanding each other due to inexact wording! Yes, distro-sync will not remove packages which are not in the default- enabled repositories at all (in any version) (nor will it downgrade them, obviously, because there is no ve

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 2014-01-25 at 10:43 +, Richard W.M. Jones wrote: > > I think that's being unnecessarily harsh on the testers. It's not at all > > obvious to anyone that you ought to test update/install of another > > package in order to validate an update to selinux-policy-targeted . > > Hell, I don't

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote: > David Sommerseth wrote: > > So, I wonder if it can be considered to enable a "downgrade path" for > > bluez and depending packages, as described in the "Contingency Plan": > > > > Offici

Re: Drawing lessons from fatal SELinux bug #1054350

Chris Murphy wrote: > If there is a directory that contains update and non-update related file > changes, that's a problem. If there's segmentation, then this can be done. > > Clearly /home needs to be separate (it's OK to take a snapshot but just > don't use it by default in a rollback) or we los

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

Am 25.01.2014 17:40, schrieb Tomasz Torcz: > On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote: >> David Sommerseth wrote: >>> So, I wonder if it can be considered to enable a "downgrade path" for >>> bluez and depending packages, as described in the "Contingency Plan": >>>

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote: > After hacking a simple tool which provides a GUI for a repository file > it's possible to create repository packages complete with desktop and > appdata file. I have some 5-10 such repository packages under way, my > plan is to push them in

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote: > > On Jan 24, 2014, at 11:19 AM, Kevin Fenzi wrote: > > > On Fri, 24 Jan 2014 09:41:13 -0800 > > Adam Williamson wrote: > > > >> AIUI there is/was a long-term plan to integrate this as core > >> functionality using btrfs snapshots

Re: Upgrade ICU to 52.1 with soname bump

On Fri, 24 Jan 2014 20:25:04 +0100 Eike Rathke wrote: > Hi, > > If time permits I'd like to do an upgrade of ICU to 52.1 next week, > which leads to the usual soname bump. > > As quite a lot of packages are affected by this, is anyone objecting > and can point out a better time for the upgrade?

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, 2014-01-25 at 08:43 -0800, Adam Williamson wrote: > "Guidelines" is a link to > https://fedoraproject.org/wiki/Packaging:Guidelines : > > "Configuration for package managers in Fedora MUST ONLY reference the > official Fedora repositories in their default enabled and disabled state > (see

Re: Drawing lessons from fatal SELinux bug #1054350

Am 25.01.2014 17:46, schrieb Tomasz Torcz: > Note that this situation is perfectly handled by Offline Updates. > After reboot, there aren't collateral changes to filesystem, only > upgrade-related > ones. So if there's a need for revert, the previous state is clearly defined says who? UsrMove

Re: Drawing lessons from fatal SELinux bug #1054350

Sergio Pascual wrote: > The situation (a broken system that cannot be upgraded) could be > mitigated a little bit by using yum + system snapshots. You can rollback > to a previous sane system. The big problem with that approach (other than the granularity issue already pointed out) is disk space

Re: Drawing lessons from fatal SELinux bug #1054350

Adam Williamson wrote: > On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote: >> * If the package is already so screwed that it breaks the whole system, >> it cannot realistically get any worse. > > Sure it can. It can wipe all your data, or mail it to the NSA... That's why I said "realistical

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, 25 Jan 2014 12:16:40 +0100 Thorsten Leemhuis wrote: ...snip... > Agreed. For example, "+1/like"-Buttons for a mailing list would be > good afaics, to get a rough impression how people think (just > wondering: will hyperkitty or something from that camp of developers > have this?). But t

Re: Fedora.next in 2014 -- Big Picture and Themes

On Sat, 25 Jan 2014 09:59:12 -0700 Kevin Fenzi wrote: > On Sat, 25 Jan 2014 12:16:40 +0100 > Thorsten Leemhuis wrote: > > ...snip... > > > Agreed. For example, "+1/like"-Buttons for a mailing list would be > > good afaics, to get a rough impression how people think (just > > wondering: will h

Re: Drawing lessons from fatal SELinux bug #1054350

Adam Williamson wrote: > The 'comment' field exists to allow people to express all these things, > but as it's just a completely free-form text field, it's intrinsically > impossible to really base any programmatic stuff or even policy on it. > In theory maintainers could submit updates without usi

Re: Drawing lessons from fatal SELinux bug #1054350

Dominick Grift wrote: > Sure, what i am saying is that this could have been prevented if the > team just put a little more passion into it and also did some proof > reading/coordination. The team knows whats going on. They know the > issues and they can quickly and effortlessly identify issues like

Re: Drawing lessons from fatal SELinux bug #1054350

Michael Schwendt wrote: > By the time the first testers noticed the scriptlet errors it was too > late, since stable updates cannot be withdrawn. That is also not a law of Physics. In the early days of Bodhi, one could actually unpush stuff from stable. Having stable updates become immutable is

Re: Drawing lessons from fatal SELinux bug #1054350

Adam Williamson wrote: > Yup, indeed. Of course, this is another area where we could improve the > tooling: it doesn't seem like it'd be difficult for maintainers to be > allowed to set a minimum timeframe before their update goes stable, but > at present this isn't possible. Why do we need to kee

Re: Drawing lessons from fatal SELinux bug #1054350

Michael Schwendt wrote: > More lessons to learn: > > https://admin.fedoraproject.org/updates/FEDORA-2013-23627 > Karma: 17 > Stable karma: 16 (!) > > It has reached the karma threshold 16 after ~5 days. > And those have not been all testers. That can work for yum, but if I set the

Re: I want to turn on a part of the kernel to make SELinux checking more stringent.

Just replying to the subject, without going into the implementation details: We've just hit two critical regressions, one in Fedora 20 (see the 2+ threads about it) and one in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1052317, still open!), as a result of SELinux checking being TOO s

Re: Drawing lessons from fatal SELinux bug #1054350

On 01/25/2014 06:03 AM, Bruno Wolff III wrote: > On Fri, Jan 24, 2014 at 20:40:28 -0800, >Josh Stone wrote: >> >> My point was not about what root can do. Suppose there's a vulnerable >> 'sudo' binary that gives everyone a root shell. If that binary is >> available on any executable path, ev

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 2014-01-25 at 19:10 +0100, Kevin Kofler wrote: > > Never the less, I think this issue could have been prevented even before > > a package was spun. > > Yes, by disabling SELinux by default. :-) > No, that is a different discussion. Disabling SELinux does nothing to solve this. If anythi

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 25 Jan 2014 19:29:12 +0100, Kevin Kofler wrote: > > https://admin.fedoraproject.org/updates/FEDORA-2013-23627 > > Karma:17 > > Stable karma: 16 (!) > > > > It has reached the karma threshold 16 after ~5 days. > > And those have not been all testers. > > That can work for yum,

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 25 Jan 2014 19:17:14 +0100, Kevin Kofler wrote: > > By the time the first testers noticed the scriptlet errors it was too > > late, since stable updates cannot be withdrawn. > > That is also not a law of Physics. In the early days of Bodhi, one could > actually unpush stuff from stable.

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 2014-01-25 at 10:37 -0800, Josh Stone wrote: > Ok, sure, you can mount -o nosuid,noexec,nodev ... but this isn't the > default for btrfs subvolume paths AFAIK. It needs to be a conscious > decision in whatever snapshot design we choose. This is definitely an issue with the OSTree design,

general compliment for F19/F20

i think sometimes some nice words are worth F19/F20 so far are great releases with nearly zero regressions possibly because RHEL7 is cooked based on F19/F20 and partyl Rawhide the only downside currently are some systemd mis-behaviors hopefully resolved before F19 is EOL and F20 becomes mandatory

Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote: > On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote: > > > > On Jan 24, 2014, at 11:19 AM, Kevin Fenzi wrote: > > > > > On Fri, 24 Jan 2014 09:41:13 -0800 > > > Adam Williamson wrote: > > > > > >> AIUI there is/was a long-term p

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Hi Simo, On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote: > The reason is simple: lot's of software *changes* data as part of its > normal functioning, including and often in rollback-incompatible ways. I wrote and maintain a system that has been doing continuous deployment of GNOME. It's b

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 2014-01-25 at 14:32 -0500, Colin Walters wrote: > On Sat, 2014-01-25 at 10:37 -0800, Josh Stone wrote: > > > Ok, sure, you can mount -o nosuid,noexec,nodev ... but this isn't the > > default for btrfs subvolume paths AFAIK. It needs to be a conscious > > decision in whatever snapshot desi

Re: Drawing lessons from fatal SELinux bug #1054350

On Jan 24, 2014, at 9:40 PM, Josh Stone wrote: > On 01/24/2014 05:27 PM, Chris Murphy wrote: >> On Jan 24, 2014, at 4:16 PM, Josh Stone wrote: >>> This concerns me especially in the case of security updates -- for >>> example, a vulnerable setuid-root binary should be locked up tight! >> >> T

Re: general compliment for F19/F20

Le 25/01/2014 20:40, Reindl Harald a écrit : i think sometimes some nice words are worth F19/F20 so far are great releases with nearly zero regressions possibly because RHEL7 is cooked based on F19/F20 and partyl Rawhide No, all the merit is due to Fedora contributors and our efforts to impro

Re: general compliment for F19/F20

first: be sure after the style of replies like yours i will hestitate try to make compilemts again in the public because the aggresive way you react leads nowhere else then flamewars Am 25.01.2014 21:26, schrieb Haïkel Guémar: > Le 25/01/2014 20:40, Reindl Harald a écrit : >> i think sometimes so

Re: Drawing lessons from fatal SELinux bug #1054350

Dominick Grift wrote: > No, that is a different discussion. Nonsense. That SELinux should be disabled is the whole point of this thread (I know, I have started it!), all the suggestions (in the various subthreads) of how to paper over the problem are off topic. > Disabling SELinux does nothing

Re: Drawing lessons from fatal SELinux bug #1054350

Michael Schwendt wrote: > If the update doesn't refer to any bugzilla tickets, what does that mean? In that particular case, it means that we are updating all the KDE software compilation and so there's a new release of KFloppy too, which most likely doesn't even contain any actual changes from

Re: general compliment for F19/F20

Le 25/01/2014 21:38, Reindl Harald a écrit : first: be sure after the style of replies like yours i will hestitate try to make compilemts again in the public because the aggresive way you react leads nowhere else then flamewars I'd rather have you stop starting or feeding flamewars as you acti

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 2014-01-25 at 21:51 +0100, Kevin Kofler wrote: > Dominick Grift wrote: > > No, that is a different discussion. > > Nonsense. That SELinux should be disabled is the whole point of this thread > (I know, I have started it!), all the suggestions (in the various > subthreads) of how to paper

Re: Drawing lessons from fatal SELinux bug #1054350

Am 25.01.2014 22:00, schrieb Kevin Kofler: > But then the right solution is to disable karma automatism entirely, not to > set it to some ridiculously high value. > > Those meaningless thresholds need to go away (and really, the whole concept > of Bodhi karma and the policies that depend on it)

Re: general compliment for F19/F20

Am 25.01.2014 22:05, schrieb Haïkel Guémar: > Le 25/01/2014 21:38, Reindl Harald a écrit : >> first: >> >> be sure after the style of replies like yours i will >> hestitate try to make compilemts again in the public >> because the aggresive way you react leads nowhere else >> then flamewars > >

Re: Drawing lessons from fatal SELinux bug #1054350

On Sat, 25 Jan 2014 22:00:02 +0100, Kevin Kofler wrote: > Right, but you were proposing to wait until it reaches a karma of +16. Certainly not. That Yum update is only a good example where a high karma threshold has been reached in less than a week, and even without a vote from all available/acti

Re: general compliment for F19/F20

Le 25/01/2014 22:22, Reindl Harald a écrit : "as you actively did this month" - where? As i'm not planning to go further, i'll answer this last one: The very first flame of the year here has been the "DNF vs yum" thread you started which got us coverage from phoronix. For the rest, just rev

RIP Borut Ražem

Hi all, I'm sad to announce that a great free software (open source) contibutor is dead... My english is really too bad to say what is my feeling, so, I will speak french instead of not speaking... Every one can contribute here, this isn't mandatory : https://sourceforge.net/p/sdcc/discussion/

Re: general compliment for F19/F20

Am 25.01.2014 22:34, schrieb Haïkel Guémar: > Le 25/01/2014 22:22, Reindl Harald a écrit : >> >> "as you actively did this month" - where? > > As i'm not planning to go further, i'll answer this last one: > The very first flame of the year here has been the "DNF vs yum" thread you > started >

Re: RIP Borut Ražem

Le 25/01/2014 22:35, Alain Portal a écrit : Hi all, I'm sad to announce that a great free software (open source) contibutor is dead... My english is really too bad to say what is my feeling, so, I will speak french instead of not speaking... Every one can contribute here, this isn't mandator

Re: general compliment for F19/F20

I'm also dogfooding Fedora for almost a decade and i always had updates-testing enabled since it exists. There were times when Fedora was very aggressive on updates and it had an impact (a positive one overall, i hope) There are two poles in our community: one wishing a more bleeding approach,

Re: general compliment for F19/F20

Am 25.01.2014 23:01, schrieb Haïkel Guémar: > I'm also dogfooding Fedora for almost a decade and i always had > updates-testing enabled since it exists. > There were times when Fedora was very aggressive on updates and it had an > impact (a positive one overall, i hope) > > There are two poles

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote: > On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote: > > > > > > If there is a directory that contains update and non-update related file > > > changes, that's a problem. If there's segmentation, then this can be > > > done. > > >

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Am 25.01.2014 23:26, schrieb Tomasz Torcz: > On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote: >> The ONLY way to do that is if you do not care at all about user's data >> and simply accept that a rollback will also remove user data. >> >> The reason is simple: lot's of software *change

Re: RIP Borut Ražem

Le samedi 25 janvier 2014 22:43:32 Haïkel Guémar a écrit : > Le 25/01/2014 22:35, Alain Portal a écrit : > > Hi all, > > > > I'm sad to announce that a great free software (open source) contibutor is > > dead... > > > > My english is really too bad to say what is my feeling, so, I will speak > >

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Sat, 2014-01-25 at 23:26 +0100, Tomasz Torcz wrote: > On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote: > > On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote: > > > > > > > > If there is a directory that contains update and non-update related file > > > > changes, that's a problem

Re: RIP Borut Ražem

Le 26/01/2014 00:12, Alain Portal a écrit : Le samedi 25 janvier 2014 22:43:32 Haïkel Guémar a écrit : > Le 25/01/2014 22:35, Alain Portal a écrit : > > Hi all, > > > > I'm sad to announce that a great free software (open source) contibutor is dead... > > > > My english is really too bad

Re: Drawing lessons from fatal SELinux bug #1054350

On Jan 25, 2014, at 9:41 AM, Kevin Kofler wrote: > Chris Murphy wrote: >> If there is a directory that contains update and non-update related file >> changes, that's a problem. If there's segmentation, then this can be done. >> >> Clearly /home needs to be separate (it's OK to take a snapshot b

Re: Drawing lessons from fatal SELinux bug #1054350

On Jan 25, 2014, at 9:46 AM, Tomasz Torcz wrote: > On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote: >> >> Another possible case it's /etc/ where the either a package or the user could >> make changes during the update. Btrfs allows per file snapshots with cp >> --reflink so there m

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Jan 25, 2014, at 12:55 PM, Simo Sorce wrote: > The reason is simple: lot's of software *changes* data as part of its > normal functioning, including and often in rollback-incompatible ways. > > You cannot assume that upgrading a program that uses a database X from > version A to B can still

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Am 26.01.2014 01:28, schrieb Chris Murphy: >> It is basically impossible to find applications that handle the case >> where you downgrade, in any more graceful way than punting and failing >> to start in the *good* case. In the bad case they start and trash the >> database. > > But important user d

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote: > > * Do an offline update that includes Foo v2.0 > * Boot the updated system, run Foo, it migrates its configuration to > some new scheme > * Realize there was something wrong with the update, roll it back > * Run Foo again, find it doesn't wo

Re: Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

Am 26.01.2014 01:54, schrieb Chris Murphy: > On Jan 25, 2014, at 4:12 PM, Adam Williamson wrote: >> >> * Do an offline update that includes Foo v2.0 >> * Boot the updated system, run Foo, it migrates its configuration to >> some new scheme >> * Realize there was something wrong with the update,

Re: RIP Borut Ražem

Le dimanche 26 janvier 2014 00:32:32 Haïkel Guémar a écrit :> > > > > I'll translate it for you, with some alterations as i don't consider > > > > > them very fitting: > > > > Thank for the translation, but I don't agree with that... > > > > And as you said « with some alterations as i don't consid

Re: RIP Borut Ražem

This thread is closed. Please re-read the http://fedoraproject.org/code-of-conduct (linked in every post) 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://f

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Sat, Jan 25, 2014 at 4:40 PM, Tomasz Torcz wrote: > On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote: >> David Sommerseth wrote: >> > So, I wonder if it can be considered to enable a "downgrade path" for >> > bluez and depending packages, as described in the "Contingency Plan": >> >

Re: Fedora.next in 2014 -- Big Picture and Themes

On 25.01.2014 17:35, Adam Williamson wrote: > On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote: > >> Debian, who has a similar stance on >> non-free Software, does a way better job in that area than Fedora does. > Well, not really - they don't have a 'similar stance', they have an > offi