The licensing guidelines say that license changes should be announced on
this list. In version 4.0 libreoffice-voikko changed from GPLv3+ to dual
licensing, GPLv3+ or MPLv2.0.
Libreoffice-voikko 4.0 requires libvoikko 3.7 which I built today, so it
should be in tomorrow Rawhide compose. I will build libreoffice-voikko
4.0 some time next week.
Since updates don't automatically fix the issue created by
https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required
to run a set of steps as a workaround, shouldn't this be announced via the
fedora announce list and posted in the Fedora website prominently as well?
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 :
French speaking only (sorry for others...)
Le « crabe » n'épargne personne, surtout les meilleurs d'entre nous...
Tu as été un formidable contribueur au logiciel libre, particulièrement sdcc et gputils, tu mérites beaucoup de respect et de reconnaisance pour cette contribution,..
J'adresse à ta femme, tes enfants et tes amis, mes plus sincères condoléances...
Tu étais quelqu'un de bien, contrairement à d'autres qui, sous couvert de licence libre, ne pensent qu'à leur gueule ! (Hello Dick, I'm still here...).
Tu étais quelqu'un de bien, et ce n'est pas souvent que je tiens de tels propos...
Tu as beaucoup donné, j'espère que quelqu'un te le rendra (Si j'avais été croyant, j'aurais dit « Dieu te le rendra »), à toi ou ta famille.
Parce que tu le mérites.
Et nous, il faudra qu'on continue sans toi, et comme disent ces cons d'américains : « The show must go on »
Reposes en paix Borut !
On Sat, Jan 25, 2014 at 7:41 AM, Adam Williamson
> drago01 <drago01(a)gmail.com> wrote:
>>On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson <awilliam(a)redhat.com>
>>> 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
>>>> > the bluetooth stack could go unnoticed through QA, and how to
>>>> > from happening again.
>>>> Indeed. I wondered the same myself.
>>> I'm somewhat cheered that our product has apparently reached the
>>> level where people consider a Bluetooth audio profile to be a 'key
>>> feature', but so far as our QA standards are concerned, it ain't.
>>> This didn't really 'pass unnoticed' through QA. I noticed it, and was
>>> supremely unconcerned.
>>We should stop this "its crap anyway" attitude. That's the reason why
>>people perceive fedora
>>as beta / unstable / breaks often etc.
>>Did you at least file a bug?
>>devel mailing list
>>Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> It's not about "it's crap anyway", it's about our trade off between completeness and getting new stuff done. Fedora has *always* accepted major changes before they reach full feature parity with the thing they're replacing, and I don't see any indication anyone's expecting that to change.
There is a difference between a minor inconvenience (I have to do x, y
and z instead of just a or have to use a different tool to do task x)
and hardware that suddenly stops working after an upgrade. This thread
is clearly an indicator that at least some people have different
> Having said that I may have to go back and check things, because my memory is that this is something everyone involved (including the devs and fesco) knew about at the time, but it's being discussed as if it were a big surprise.
I'm after some advice / ideas. When you install Fedora 20/21 and then
launch gnome-software it has to go and download some metadata before
it can show anything. This is a pretty bad first experience,
considering subsequent runs of gnome-software just open straight away.
GNOME Software operates on the logic that *any* version of the
metadata is better than nothing, and only refreshes once a week when
the user is idle.
There are two ways to fix the jarring UX. We could either ship the
fedora package metadata pre-prepared in PackageKit, maybe using
something like %ghost so the new metadata is ignored. The other way is
to start the metadata downloading in the initial-start wizard thing,
although in practice the download takes a couple of minutes to
complete, and the wizard typically takes much less than that before
the user has configured everything. The downside to shipping prepared
metadata is that the package size is larger, and that the metadata
would be *very* out of date after a year or so.
I'm open to ideas, thanks.