On Friday, 14 May 2021 14:25:26 EEST PGNet Dev wrote:
> On 5/14/21 2:05 AM, Juha Tuomala wrote:
> > Sure. But this is devel list. Are developers themselves the target
> > audience?
>
> > :) Hopefully not. Is it defined somewhere?
> and, yes, 'developers
On Thursday, 13 May 2021 18:50:33 EEST PGNet Dev wrote:
> On 5/13/21 10:48 AM, Juha Tuomala wrote:
> > Virtual machine installation is hopefully a special use case and majority
> > of installations are bare metal end users.
>
> hardly.
>
> here,
Sure. But this is
On Thursday, 13 May 2021 15:11:19 EEST Roberto Ragusa wrote:
> > Make a plugin interface for adding additional methods to obtain public
> > keys as there are a lot different sources for those. Fedora itself has
> > tools for PKI and public key based security and it would be quite low
> > hanging
On Wednesday, 12 May 2021 23:35:44 EEST Ben Cotton wrote:
> * it has been suggested that making it easier to import SSH keys from
> popular code hosting platforms (Pagure, GitHub, GitLab, etc.) could
> provide a nice alternative to the dropped option -
Make a plugin interface for adding
Has it been disabled recently?
Tuju
--
I couldn't repair your brakes, so I made your horn louder.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 30 Aug 2010, Alexander Kurtakov wrote:
* AutoQA - QA guys are struggling with their effort to get their stuff running
from Fedora packages (shame on us if we can't make our own stuff run from our
packages)
* Name it :)
At my work, first thing that happens with Java is that Openjdk
On Wed, 14 Apr 2010, Rex Dieter wrote:
are a lot of other packages and issues and bugs involved here. Reverting
even part or all as you suggest would have far bigger bad consequences than
helping
That's what I thought, it's not just a matter of yumming older
stuff back. Secondly,
On Mon, 12 Apr 2010, Ryan Rix wrote:
On Mon 12 April 2010 6:40:59 am Juha Tuomala wrote:
I recall, that the earlier version had some level of Akonadi support
as well, so in theory, would it be possible to revert the codebase
back to the one that can actually be used?
Sure, try `man yum
On Tue, 30 Mar 2010, Linuxguy123 wrote:
On Mon, 2010-03-29 at 13:09 +0200, Christoph Wickert wrote:
I am irritated by the way the KDE SIG and the KDE bugzappers handle
bugs. For most bugs that are reported they demand the reporter to file
an upstream bug report at bugs.kde.org and set the
On Wed, 31 Mar 2010, Jeff Spaleta wrote:
Unfortunately our ticketing tool doesn't do a great job at this, as we
can't take one ticket and mark multiple release branches it affects
and which of those release branches the fix is provided.
that's why there is 'clone' functionality. Use it.
On Wed, 31 Mar 2010, Jeff Spaleta wrote:
Are you saying that we should all clone every report that we all would
normally close as fixed rawhide?
Are you saying, that everyone facing that bug, should search from
every release if that has been handled somewhere else other than the
product in
On Wed, 31 Mar 2010, Michael Schwendt wrote:
Why would I want to clone a bz ticket if I did not want to fix the
bug in anything other than Rawhide?
Because it's a database of release's bugs, not a todo list?
I could be wrong of course, please correct me if I am. Considering
that existing
On Tue, 16 Mar 2010, Rex Dieter wrote:
How about setting that as default, away from $HOME that can be a NFS
filesystem?
Indeed, a solution similar to kde's
~/.kde/socket-hostname = /tmp/ksocket-username
symlink is likely needed here too.
Symlinks are duct-tape, why not just set it to
On Tue, 16 Mar 2010, Rex Dieter wrote:
Symlinks are duct-tape, why not just set it to /tmp with
global rc file?
Sure, but still need to encode username into the filename (or randomize/uniq
it) somehow.
Could that be it:
On Fri, 12 Mar 2010, Matthew Garrett wrote:
RHEL has the resources to backport. Centos uses those backpotrs for
free, but does not generate them (unless again the party supporting a
component for Centos happens to be upstream in RHEL).
Debian has historically managed this. I really
Ironically it happened again, just now when these FESCO threads
are still warm.
My desktop gui processes leak enough mem that I need to restart
couple times a week or system will run out of memory. Today
I started with updating the F11 with yum. During the update,
I noticed that it's pulling
On Thu, 4 Mar 2010, Juha Tuomala wrote:
Then I tried to start kmail to start working. It starts, asks
passwords, whines something about Akonadi which i don't use and
then crashes/exists.
Not to mention that kaddressbook which contains all my business
contacts, is broken too:
http
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
http://tuju.fi/fedora/11/kab-20100304.png
looks like that some icons are also missing, but hard to judge
as it wont start properly to interact with user.
That's the problem of not running Akonadi - it's central PIM part of KDE.
The funny part
On Thu, 4 Mar 2010, Kevin Kofler wrote:
You mean the KDE stability proposal? As this is F11, i.e. previous stable,
KDE 4.4 would actually not have been pushed to F11 under that proposal.
How i read it, you would still push *one* feature release in the
middle of stable release lifespan,
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
Go ahead, make that to your kde-hardcore-followers-repo. In my
understanding, that's what it has been for past years already
anyway.
Third party repos are highway to hell unfortunately.
Quite interesting statement from the KDE SIG who runs that
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
will pick up that role (for KDE, kde-redhat stable would probably be
revived, currently it's mostly empty for Fedora as the kind of stuff
which would be in there is usually just pushed as official Fedora
updates).
Go ahead, make that to your
On Thu, 4 Mar 2010, Kevin Kofler wrote:
Upstream has no policy about what kind of releases are to be provided as
updates, this is a distribution decision.
They add features to own releases just for that reason, so
downstreams and users could avoid such mess that has just happened.
If you
On Thu, 4 Mar 2010, Kevin Kofler wrote:
That's why nobody can't enjoy the upstream's intended stability in bugfix
releases and plan major upgrades.
You keep saying that, yet you have provided no evidence of such a stance
from upstream. KDE upstream actually has no policy on what versions
On Thu, 4 Mar 2010, Kevin Kofler wrote:
What bugfix releases would we be supposed to push? There are no further
4.3.x releases.
Nothing, if that's the case.
In case there is a major security hole and they only fix it in SCM
and notify about it without making a release - I expect you to add
On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
Could you try to run it manually and paste log/output somewhere?
akonadictl start
Was it so that mysqld wants to communicate through fs sockets
which does not work on NFS $HOME?
[akonadiserver] Failed to use database akonadi
[akonadiserver]
On Wed, 3 Mar 2010, Chris Adams wrote:
By the same token, if you want rolling update releases, feel free to do
it in your own private repo. See how well that argument works?
No i don't. I'm using a mainstream distribution and thus I expect to
get them. Just like the upstream has intended
On Wed, 3 Mar 2010, Kevin Kofler wrote:
The strong argument is that KDE and Fedora release cycles are not in sync
and our users would thus have to wait months for the new KDE.
As many have stated, not all people *want* those feature updates
to stable release. By pushing them by force, you
On Tue, 2 Feb 2010, Mike McGrath wrote:
Specifically: Individuals using multiple accounts without prior written
approval will have all but one account terminated.
And what does that matter when everyone can create enough nick
names and free email addresses to join Fedora? :)
In security
On Tue, 2 Feb 2010, Seth Vidal wrote:
And I'd suspect that intentionally entering into an agreement with knowingly
false information is a kind of Fraud in just about every country.
Feel free to sue that 0 euros email-address, which provider doesn't
know who uses it.
Tuju
--
Ajatteleva
29 matches
Mail list logo
