On 04/08/2014 09:48 AM, Markus Slopianka wrote:
>> Would you be interested in helping maintain this in fedora formally?
>> Sounds like you have a good vested interest at least. I'd welcome any help.
> Yeah, sure. I'm still not used to Fedora packaging specifics (which is why I
> currently use OBS). So when you guys don't mind the occasional stupid
> packaging question, I can start.
here's the general procedure, though you can skip the part about your
first package review, we'll be adding you as a maintainer of an existing
and I will sponsor you, then can add ACLs for commit access to cantata.
On 04/08/2014 09:16 AM, Markus Slopianka wrote:
> as I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1070503 that version
> 1.3 of the MPD client Cantata has been released and that it fixes some crucial
> I packaged it in my own repo and tested it (no problems so far).
> What's needed to push it into the regular repos -- either as update for
> everyone or at least into Rawhide?
Personally, I've been quite busy with other tasks lately sorry.
Would you be interested in helping maintain this in fedora formally?
Sounds like you have a good vested interest at least. I'd welcome any help.
as I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1070503 that version
1.3 of the MPD client Cantata has been released and that it fixes some crucial
I packaged it in my own repo and tested it (no problems so far).
What's needed to push it into the regular repos -- either as update for
everyone or at least into Rawhide?
On 04/07/2014 03:23 AM, Eli Wapniarski wrote:
> Wouldn't it be better to have a live DVD, instead of a live CD.
Already the case, the current fedora kde live image is ~1gb size.
> And you
> can then give the users of kde / plasma live a choice: Libreoffice or
> Calligra; Konqueror or Rekonq or Firefox. Maybe through in a few
> multimedia players for good measure.
Give a choice, as in installing all of these by default? We could, but
that is yet another decision you're asking to reconsider, generally
shipping only 1 tool for each job/task. And, doing this still doesn't
answer the question of which one is used *by default*.
On 04/06/2014 11:33 PM, Frédéric Bron wrote:
>> 2 things to consider/try
>> * disable prelinking ( edit /etc/sysconfig/prelink to include
>> PRELINKING=no), and re-run, /etc/cron.daily/prelink
> This works. Thanks. Any disadvantage keeping that to "no" for a long time?
>> * is nvidia binary driver involved?
> Yes I use the nvidia driver (akmod-nvidia). If I were alone, I would
> use nouveau but my children find it really too slow to play minecraft!
OK, confirms with our earlier findings that nvidia + glibc prelink =
wierdness from time to time.
On 04/06/2014 05:23 PM, Ed Greshko wrote:
> On 04/07/14 00:19, Frédéric Bron wrote:
>>> If, when your desktop comes up empty, you change
>>> the "Location" to "Specify a folder" and choose your
>>> "home/Desktop" do your icons reappear when you click "Apply"?
>> It does not work. But the icons come back if I change the view to
>> "Default" and back again to "Folder". But I do not want to have to do
>> this each time!
> Of course you don't want to do it each time. I was just thinking that it may lead to clue as to what is going on, or not going on.
> Nothing pops out at me. Maybe a permissions problem of some sort....stab in the dark.
2 things to consider/try
* disable prelinking ( edit /etc/sysconfig/prelink to include
PRELINKING=no), and re-run, /etc/cron.daily/prelink
* is nvidia binary driver involved?
both of these items have been involved in kio_file problems in the past.
I am going to summarize what I wrote yesterday on IRC so everyone can read
The discussion of what should be the default browser on the Plasma Product
has come up yesterday, and I strongly believe that Firefox is NOT the answer
(but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
* We do not control the packaging of Firefox. It is not even open to
provenpackager! We'd be completely at the mercy of the Firefox
* In particular, the Fedora Firefox package will most likely NOT include the
KDE integration developed by openSUSE, ever. That means the package will
integrate extremely poorly into our Plasma setup (e.g., no KDE file
* Firefox also has unwanted GNOME dependencies such as
* Shipping Firefox means we have to ship a third HTML engine just for
Firefox! We already have to ship KHTML and QtWebKit because KDE software
requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses
QtWebKit. Shipping Firefox means adding Gecko and thus pointless code
duplication and more security updates for users to worry about.
* Users who absolutely want Firefox can simply install it from the
repository. Or they could use one of the other spins, which (last I
checked) all included Firefox (either as the one default or next to
Midori). Users who do NOT want Firefox forced on them will have no option
to choose from anymore if we join the monopoly.
* I don't buy the argument that there is "no alternative" to Firefox. There
are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
and Konqueror+KWebKitPart just work on almost all websites out there. (And
even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE
applications wherever possible. Here, it is clearly possible. Shipping
non-KDE applications is acceptable if those are specialized applications
with no KDE alternative (think, e.g., Blender). A browser is not
specialized, it's a core part of the desktop. And the KDE alternatives
exist and work.
* I also don't share the worries about Rekonq's future. The port to Qt 5 +
QtWebKitWidget is proceeding well. A switch to QWebEngine will be done
only when QWebEngine will be ready, a sound decision. And if this really
should become a problem in the future (i.e. AFTER F21), we can always
reevaluate the default browser decision at that point.
* Firefox does not use kioslaves. As such its URL support is inconsistent
with the other applications we will ship. In particular, Firefox does NOT
support man:foo and info:foo URLs. IMHO, those are by far the most
comfortable way to read man and info pages. It also cannot reuse things
like kio_gopher, requiring a separate extension (for Gopher, that would be
OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the
other kioslave-handled protocols just work.
* Firefox also has some "features" that are worrisome for Fedora as a whole:
- The anti-malware and anti-phishing protection (enabled by default!)
sends a hash of every URL you visit to Google (yes, Google!).
- Firefox Health Report sends some additional data to Mozilla. It is also
enabled by default!
- Mozilla also intends to show client-side advertisements (i.e. ones that
are NOT part of a web page you are visiting) by default. This is both an
added annoyance (as if the ads on the web weren't bad enough!) and a
privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq
support ad blocking out of the box, Firefox doesn't.)
And the Firefox trademark and packaging situation are such that we have no
control over these "features", nor any future ones that get added.
So please consider these points before voting here:
(votes please ONLY from Plasma working group members, 4 voting members have
not voted yet). If you voted for Firefox and these arguments convinced you
otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another
Every second time or so I run KDE, the icons on the desktop are not there
and the desktop is empty. Why? I am speaking of icons that are
shortcuts to launch applications. KDE graphical components are still
Greetings, KDE lovers.
Traditionally I've been subscribed to the kde-unstable repository, but, on
this cycle, there has been no activity related to KDE 4.13, the soon to be
included Baloo, or with the CPU load decrease associated to it. Also, there
are several unrelated efforts to bring an update to the Mesa stack, including
libxcb 1.10, an update that makes impossible to use KDE without a recompile of
both Qt 4 and Qt 5. This needs further testing, because there seems to be a
consensus to upgrade Fedora 20 to Mesa 10.1, LLVM 3.4, and the required libxcb
So, my questions are.
1. Will KDE 4.13 be included in Fedora 20, starting with the kde-unstable
repositories? Any ETA? Or will an upgrade to Fedora 21 (Rawhide, technically)
2. Will a rebuild of Qt 4 and Qt 5 against libxcb 1.10 be provided? The
"libxcb0-compat" solution provided in the fschwarz Copr repository doesn't
work, because it crashes every program using Qt 5 (I rely on Sigil, so, it's
not an option for me).
Please, keep doing such an amazing work. Thanks in advance.
(Sorry for the wrong threading, Gmane is still out of order and not syncing in
either direction. :-( )
> whoa, horse.
> so, are you saying people should be against firefox because the author
> is a faggot?
No, because he is AGAINST gay marriage, i.e. HE's the homophobic asshole, not
That wouldn't be a bad thing either. ;-)
> i am not saying that 'lgbt' is ok,
And is THIS:
the user experience we want to achieve? What impression do you think it will
make on our users if they get that kind of message on a website they visit?
What if more sites follow suit?