Re: Come back
On Friday 08 January 2010 15:51:28 Alain Portal wrote: > Hi, > > I just took ownership of kbackup as it was orphan. > As there is a long time that I didn´t contribute to the Fedora Project, can > somebody tell me how to update the package and ask for F-10 and F-11 > branches? F-10 branch is EOL (you probably thought F-11, F-12), for F-11/F-12 branches see [1]. Nice to have you back! > An uptodate srpm successfully build in mock on my laptop (F-12) and in koji > -- scratch for f11, f12 and f13. > > Regards > Jaroslav [1] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt issue
On Wednesday 09 December 2009 14:23:47 Neal Becker wrote: > Jiri Moskovcak wrote: > > On 12/09/2009 02:05 PM, Neal Becker wrote: > >> Jiri Moskovcak wrote: > >>> On 12/09/2009 01:47 PM, Neal Becker wrote: > I just got a crash in kde plasma. Traceback is not useful, because of > missing debug pacakges. > > I'm told I can reload after 'installing the needed packages', but > there is no clue what packages are needed. > > A bit of a mystery. It seems sometimes abrt will go ahead and > download needed debuginfo packages, but other times (like today), it > doesn't, and doesn't offer any clue what packages are missing. > >>> > >>> Weird, ABRT should tell you the exact package you should install > >>> debuginfo for. I just tried that and abrt says this: > >>> > >>> Reporting disabled because the backtrace is unusable. > >>> Please try to install debuginfo manually by using command: > >>> *debuginfo-install python* > >>> the use the Refresh button to regenerate the backtrace. > >>> > >>> Jirka > >> > >> Yes, I've gotten messages like this sometimes, and that's what I was > >> looking > >> for. But not today. > >> > >> Maybe related? > >> Dec 9 07:50:11 localhost abrtd: New crash, saving > >> Dec 9 07:50:11 localhost abrtd: Activation of plugin 'RunApp' was not > >> successful: Plugin 'RunApp' is not registered > > > > This shouldn't be related, but I'm wondering where did you get the line > > "reload after 'installing the needed packages'" it doesn't come from > > ABRT. > > This is not an exact quote, but it's what I got from abrt when I clicked on > 'next'. You probably mean Dr. Konqui and not Abrt ;-) KDE is still using Dr. Konqui! There's some sort of debuginfo packages auto downloading but we're considering Abrt usage in Fedora KDE too as it better integrates to Fedora. The plan is even for native KDE/Qt Abrt GUI! Ping Abrt people - do you need a help? What's the status? Jaroslav > I don't know what debuginfo package is needed. rpm -qa '*plasma*' doesn't > give a good answer. Why isn't abrt telling me? > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Thursday 26 November 2009 23:14:09 Dave Airlie wrote: > On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote: > > On Thu, 2009-11-26 at 20:16 +, Terry Barnaby wrote: > > > On 11/26/2009 07:46 PM, Bruno Wolff III wrote: > > > > On Thu, Nov 26, 2009 at 17:09:14 +, > > > > > > > >Terry Barnaby wrote: > > > >> I really want to help and get a stable release and present bug > > > >> reports and even fix them if I can. But, the current short term > > > >> release schedule, and no focus on testing and fixing graphics > > > >> issues, does not inspire me with confidence that a stable usable > > > >> release will emerge. This makes it difficult > > > >> for me to justify the effort. Convince me :) > > > > > > > > I follow the radeon updates pretty closely and my 9200 finally > > > > starting working with 3d again a few weeks before the release. Airlie > > > > has continued development in the f12 branch and there have been > > > > several updates over the last couple of weeks. > > > > If you have just tried F11 and not F12 you should consider doing so. > > > > For r5xx and below, grab a live image and install one of the smaller > > > > 3d apps and try it out. For r6xx and above you'll want to install > > > > mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get > > > > you the kernel updates related to graphics since the release, but > > > > should give you a good look at where things are at so that you can > > > > decide if you want install F12 on the machine. > > > > > > Hi, > > > > > > I have tried out F12 on 4 different systems, 2 with different ATI > > > graphics and two with different Intel based boards. Only the last one > > > appears to be able to run Blender. You mention "Airlie has continued > > > development in the f12 branch". If that means there are people working > > > on the bugs and producing new driver updates for F12 (DRM,MESA,X11), > > > especially for ATI then I certainly will give it some time. > > > > So is blender working the only thing you consider as working? > > > > The current focus is on making graphics work for as many ppl as possible > > first, then 3D is always further down the list, this is just common > > sense. > > > > Current priorities are: > > 0) you aren't running a binary driver - if so no priority for you. > > > > a) Can you see stuff on the screen at install/boot? > > b) can you run GNOME desktop in reasonably useful manner? i.e. firefox > > runs okay, no glitches, major slowdowns etc. > > c) can you suspend/resume? > > d) can you run compiz/gnome-shell? > > e) can you run non-Gnome desktops at reasonable speed? (yes we have to > > prioritise gnome over KDE, it sucks but thats life) > > f) does misc 3D application run? > > I should follow up just as far as the Red Hat X team goes a-d are what > we are paid to do, e/f and nice to haves, so really if some community > effort was to be brought up around this, e/f are where it would make > sense to focus it. Hi, how could we (we = KDE SIG people) help with e) - serious question - not KDE over Gnome flame or blaming ;-) - to make it better? >From Red Hat's POV, KDE should be at least partially supported by X team as it's official and supported component of RHEL - but this goes together with Fedora. Thanks for your work on freeing me from fglrx! Jaroslav > Having some sort of repos where we can publish a new > kernel/libdrm/mesa/intel/ati/nouveau package in one block for > people to test and find regression that isn't rawhide and isn't > updates-testing (since it would be abusing that) would be an > excellent place to start. > > Dave. > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (48/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 48/2009 Time: 2009-11-24 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-24 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-24/fedora-meeting.2009-11-24-13.59.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-24/fedora-meeting.2009-11-24-13.59.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * StevenParrish * ThanNgo * MaryEllenFoster -- = Agenda = * Shaman 2 for Fedora? It's plugable package management tool by Dario Freddi, he asks for comments and what we want for Fedora (if we want to ship it, at least as optional package - he's working on PackageKit support right now) * soprano/sesame2 status report [1] * KDE 4.3.3 : in updates-testing, ready for stable updates ? * KDE 4.3.75 Builds almost done (kdebindings, kdepim, extragear left) Issues: kdelibs -- Konsole menu item patch is obsolete (kde-settings may be able to fix this) kdebindings -- Build failure; fails to find its own built libs (??) kdepim -- one .desktop file of unknown usefulnes getting caught in the validator = Summary = Shaman 2 for Fedora * jreznik to work on shaman2 packaging soprano/sesame2 status report * mefoster will submit package reviews soon and keep [2] updated KDE 4.3.3 : in updates-testing, ready for stable updates? * rdieter will queue kde-4.3.3 bits for stable updates KDE 4.3.75 * mathstuff to merge 4.3.75 into rawhide asap (tue or wed) to be ready for kde-4.4-beta1 -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-01 -- = Links = [1] http://lists.fedoraproject.org/pipermail/fedora-kde/2009- November/004709.html [2] https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Friday 20 November 2009 13:11:49 Jiri Moskovcak wrote: > On 11/20/2009 01:08 PM, Neal Becker wrote: > > Jiri Moskovcak wrote: > >> On 11/20/2009 12:54 PM, Neal Becker wrote: > >>> Jaroslav Reznik wrote: > >>>> On Friday 20 November 2009 12:29:34 Neal Becker wrote: > >>>>> I can't seem to get abrt to work at all. I suspect it's stuck on > >>>>> trying to > >>>>> get bz username password. I suspect it doesn't work correctly with > >>>>> kde. > >>>>> > >>>>> > >>>>> From what I know it works correctly in KDE, even we have several KDE > >>>>> related > >>>> > >>>> bugreports reported by Abrt. > >>>> > >>>> There are even plans for full KDE support and replacing Dr. Konqui. > >>>> > >>>> Jaroslav > >>> > >>> Doesn't work here at all. When I just tried to send a kernel bug > >>> report, it told me some settings weren't correct, and when I clicked on > >>> bugzilla and filled in username and password, I got: > >>> > >>>abrt-gui > >>> Our job for UUID 725650339 is done. > >>> Traceback (most recent call last): > >>> File "/usr/share/abrt/CCReporterDialog.py", line 113, in > >>> on_config_plugin_clicked > >>> plugin.save_settings() > >>> File "/usr/share/abrt/ABRTPlugin.py", line 100, in save_settings > >>> self.Settings.save(str(self.Name)) > >>> File "/usr/share/abrt/ABRTPlugin.py", line 51, in save > >>> self.conf.save(name, self) > >>> File "/usr/share/abrt/ConfBackend.py", line 68, in save > >>> True) > >>> gnomekeyring.DeniedError > >> > >> ABRt dies trying to save/load you stored password if you gnome-keyring > >> authentication fails, this should be fixed in next update (abrt will > >> survive the g-k denial, but forget the password when you close it) which > >> I'm about to do right now. > >> > >> Jirka > > > > On kde, we shouldn't be using gnomekeyring, I would think. > > Yes, I'm planning to write another config backend for kwalet, but didn't > find any usable API reference so far :( Have you tried that Python keyring library I sent you? It looks like there's support for both G-K and KWallet with same API. But in any case, feel free to ask anyone of us (KDE team) for help... > J. > > p.s: but according to the error you're seeing you have g-k running, just > the authentication failed. > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Friday 20 November 2009 12:29:34 Neal Becker wrote: > I can't seem to get abrt to work at all. I suspect it's stuck on trying to > get bz username password. I suspect it doesn't work correctly with kde. > >From what I know it works correctly in KDE, even we have several KDE related bugreports reported by Abrt. There are even plans for full KDE support and replacing Dr. Konqui. Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thursday 19 November 2009 14:05:01 Richard Hughes wrote: > 2009/11/19 Jeff Garzik : > > 1) We should recognize this new policy departs from decades of Unix and > > Linux sysadmin experience. > > Sure, it's different. It doesn't make it wrong. > > > 2) F12 policy should be reverted to F11, ASAP. Possibly with a CVE. > > PolicyKit in F12 doesn't have the auth_admin (and save forever to > disk) functionality that F11 did. I think what we have in F12 is much > more usable, perhaps trading off with the perceived loss of control. I > say perceived as actually typing in a root password doesn't actually > make the system any more secure at all, less if anything. > > > 3) Due to #1, F13+ should not deviate from the decades-old default. > > Using that argument, we can just keep using GTK tools written in > python, that use consolehelper to run 2 million lines of code as the > root user on the users session. How wonderful. > > > 4) Release notes should explain new [and after step #2, optional] policy > > in detail, including how to turn it off again. Seth's laudable write-up > > efforts should not have been necessary -- that info should be prepared. > > Sure, in retrospect I should have made a lot more noise in the release > notes, which I apologise for. The reason people didn't notice earlier > was because rawhide is unsigned, and hence all PackageKit operations > required the root password, even updating. > > > 5) The people who want this new security policy should add an opt-in > > checkbox in Anaconda or firstboot. > > Err, I don't think this is how we want to brand the desktop spin. > Other spins just need to ship different defaults for all the other > PolicyKit daemons too. I completely agree - other spins should select own defaults - but then you can't hide other spins but let users actual choose the right one. Instead saying - this is default spin, you should download this one, we have to state that this spin is for home desktop users, then we should have workstation spin on the same page, server spin, advanced kde desktop spin so users actually could select the correct one for their task. With website redesign - to match needs of home users - we are promoting Desktop spin as default Fedora - that's not true anymore. Jaroslav > Also, we've not made this change upstream lightly. We've got upstream > review and policy documents which you might find useful: > > http://cgit.freedesktop.org/packagekit/plain/docs/security.txt > http://cgit.freedesktop.org/packagekit/plain/docs/setting-the-proxy.txt > http://cgit.freedesktop.org/packagekit/plain/policy/org.freedesktop.package > kit.policy.in > > Richard. > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (45/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 45/2009 Time: 2009-11-03 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.txt Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.log.html -- = Participants = BenBoeckel JaroslavReznik KevinKofler RexDieter StevenParrish ThanNgo ThomasJanssen Ryan Rix -- = Agenda = * topics to discuss: o KDE-4.3.3 state o Fedora 12 looming soon, remaining issues/blockers? o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? o VOIP meetings = Summary = o KDE-4.3.3 state * 4.3.3 is imported into devel/ branch * some remaining issues - kdebindings & kde-l10n doesn't build ** Kevin_Kofler suggest mathstuff hint how to fix kdebindings ** rdieter will fix kde-l10n issues o Fedora 12 looming soon, remaining issues/blockers? * a lot of KDE SIG members are using Fedora 12 already * beta still had the "install to hd link on desktop lacking execute permission" problem * "SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents)." bug [1] added to Fedora 12 blockers tracker o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? * we agreed we don't want it, if someone is willing to fix issues, we're not blocking it * issues: ** KDM colors do not match latest wallpaper ** KSplash rectangles have bad looking shaddows * jreznik will import old Constantine to SVN o VOIP meetings * not for regular meetings (at least for now) * we try to set conference call from FUDCon -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10 -- = Links = [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=529951 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fwd: Junior Jobs]
On Monday 19 October 2009 08:47:38 Orcan Ogetbil wrote: > 2009/10/19 Miroslav Suchý > > > May be good idea for Fedora as well... > > Mirek > > > > > > Původní zpráva > > Předmět: [opensuse-packaging] Junior Jobs > > Datum: Tue, 13 Oct 2009 14:46:58 +0200 > > Od: Michal Hrusecky > > > > Hi, > > > > lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of > > openSUSE packages can choose some of theirs easy bugs and mark them as > > Junior Jobs. Then anybody from community can volunteer and fix these > > issues. These tasks will be easily fixable and their purpose is to let > > people learn how to contribute and to create some easy task so anybody > > can join and start participating. > > > > [1] http://en.opensuse.org/Junior_Jobs > > Not a bad idea. I think at least the KDE project does a similar thing. > Maybe other projects do this too. > > Implementation of this brings back the question: Shall the packagers > have an option to give commit access to every other packager and not > just to provenpackagers? This question arises because provenpackagers > are by definition not "junior"s. For juniors jobs it's better to send patch and maintainers can review it. And if you're interested in one package (or group of packages like KDE), you can then ask for CVS commit... Jaroslav > The last time I talked to cvs folks, they told me that the code is > there for this option but it needs some testing. Any progress there? > > Orcan > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (42/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 42/2009 Time: 2009-10-13 14:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-13 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-13/fedora-meeting.2009-10-13-14.04.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-13/fedora-meeting.2009-10-13-14.04.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * SebastianVahl * ThanNgo * ThomasJanssen -- = Agenda = * topics to discuss o a generic, F12 kde spin status o the KDE spin website status o FUDCon Toronto o prelink issues * recent bugs: o #528283 - In Amarok the Browsers column is not selectable, meaning no music can be played = Summary = o a generic, F12 kde spin status * the size is the same as last week (704M/x86_64) ** it should fit CD ** svahl is still testing some removals ** kickstarts are not branched for beta yet o the KDE spin website status * we need content for KDE spin page * currently only mockups, pre-HTML at [1] (see intructions [2]) * jreznik is going to coordinate effort ** but needs help from all members ;-) (thomasj) * we need Fedora KDE description, more detailed info and screenshots * depending on license we can use upstream bits as base o FUDCon Toronto * confirmed people - rdieter, SMParrish, mathstuf, aseigo! * waiting for jreznik (pending passport, funding) o prelink issues * svahl asked if prelink issues are fixed and if it's ok to re-enable it on live CD * all known issues are fixed * we agreed we don't want prelink on live system but we'd like to have it on installed system ** enabled in livecd script = Recent bugs = #528283 * bug in qgtkstyle ** has to be fixed -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-20 -- = Links = [1] git://git.fedorahosted.org/git/fedora-web.git [2] http://mairin.wordpress.com/2009/10/09/let-me-bling-your- spin/#comment-3324 = Buglist = https://bugzilla.redhat.com/show_bug.cgi?id=528283 -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
Hi Ray, I have to disagree. And why? Becuase of my experience. Few days ago one colleague came to my cubicle and asked me - KDE wants something and I don't know what they want. So I took a look and saw Plymouth with something that looks like password dialog. He was really surprised that it's asking for password. At first - really, I think it's dracut bug as I think it was password for encrypted device he uses on demand (I can ask him). But you can imagine - he's very experienced user and still he failed. I'm not sure how difficult would be implementing font support (kernel's fonts?) and a few lines of translation wouldn't be such a problem. Jaroslav On Monday 05 October 2009 00:44:47 Ray Strode wrote: > Hi, > > > What do others think? Should the LiveCD by default access and > > activate storage volumes, including encrypted partitions, on the hard > > disks? Should the LUKS prompts better identify the volume so that > > users know what passphrase to enter? > > This seems like a misfeature in dracut for LiveCD or otherwise. > > The initrd should be about getting / mounted read-only and nothing else. > > There's a reason why plymouth doesn't identify the volume in the initrd. > Plymouth is graphical and so would need to ship fonts, font > renderering libraries, > and translations in the initrd to display text. That's a non-starter. > > It's okay though, because in most cases the user should only ever get > asked for one passphrase from the initrd, > so we don't need to show anything but a lock icon and an entry box. > > If that's no longer the case in a dracut world, we probably need to fix > dracut. > > The alternative would be to drop to the console when unlocking and > show untranslated messages. > > --Ray > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE-SIG weekly report (40/2009)
On Thursday 01 October 2009 20:38:30 Sebastian Vahl wrote: > Am Mittwoch 30 September 2009 schrieb Jaroslav Reznik: > > o future of Phonon > > * Upstream (sandsmark) recommends building/packaging phonon from qt, and > > building/packaging backends separately. > > * Mandriva developments integrating pulseaudio support (and improving > > gstreamer backend). [1] > > * We will move back to building a standalone phonon SRPM. > > * The vote for the default backend is split 3:3, needs the 7th vote from > > svahl. > > Sorry for the delay. Was a bit busy and not at home. > > I tend to xine as default backend for several reasons: > - It worked fine for me for several releases (and according to bugs for > other too) > - It is recommend by upstream. > - We won't get trouble with the amarok guys. :) > - At least on one system I have no sound with gstreamer (maybe caused by > other issues, have to re-check that). > > So I'm a bit conservative here, but +1 for xine. Hi Svahl, thanks for your vote. So it's now 4:3 for Xine backend. So what are the required steps now? As we already missed freeze but we can work it out with rel engs. I like idea of shipping both backends as proposed rdieter but set the Xine one as default one. But first we should fix bug with switching backends... Distant future: I'll try to look at GStreamer backend more deeply later as I think it's the future - not only for Fedora but for upstream too and I hope we can get it at least to the the point to be comparable with Xine one. Then we can reconsider this decision. > Sebastian > Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Thursday 01 October 2009 03:02:04 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > That's not about "standardize on GTK+" > > That was just an example of how "one size fits it all" doesn't always work > when it comes to libraries, there will always be more than one library for > some purposes. > > > We should choose better technology over politics. > > That's exactly why I voted for Phonon-Xine in the meeting. ;-) > > "All the world must use GStreamer" == politics > Phonon-Xine is considered by Phonon upstream to be the better technology. By one developer who admits that Phonon is dying slowly and not developed anymore ;-) No, I don't want one multimedia framework rule them all but currently it's the best what we have (I'm not talking about Phonon backend - just GStreamer). In case of better framework in the future I believe I'd be one of first supporters (even it could bring troubles to Fedora). Jaroslav > Kevin Kofler > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 19:32:02 Kevin Kofler wrote: > Lennart Poettering wrote: > > An abstraction layer's main purpose it to abstract differences of what > > is below, and as hence usually is a least common denominator of what is > > below, but certainly nothing that adds features. PA OTOH extends what > > is below, it adds features. > > Phonon also adds features compared to the underlying GStreamer or xine-lib > library. In particular, it can be set up to send different types of sounds > to different outputs, kinda like PulseAudio (but it's implemented at a > different layer, and of course it only affects applications using Phonon). > > There's also work ongoing (that branch by Colin Guthrie) on making > PulseAudio sinks show up as Phonon devices, and even reproducing the per- > sound-type preferences set in PulseAudio (so Phonon still matches them by > default, while showing the list of devices within Phonon as opposed to one > "PulseAudio" device). There too, this is a feature not offered by GStreamer > or xine-lib, but implemented by calling PulseAudio directly. See > http://colin.guthr.ie/git/phonon/log/?h=pulse for this work. This was what I thought but I was unable to write it clearly :D Jaroslav > Kevin Kofler > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 19:11:36 Kevin Kofler wrote: > Lennart Poettering wrote: > > So I think it would make a lot of sense to switch to make our distro > > Gst-only asap. Eventually this move will have to happen anyway. > > Uh, I have to disagree there. It is not our job as distribution packagers > to dictate to upstream developers what multimedia library they use. If an > upstream project XYZ requires e.g. libnobody-else-uses-me (fictional name) > for multimedia and XYZ is worth packaging, we'll want > libnobody-else-uses-me packaged too. At best we can try to get mainstream > applications ported to a common framework (like we did for spellchecking > (hunspell), in fact I set up KDE to use hunspell everywhere, but there are > still quite some niche apps outside of GNOME and KDE using aspell), but > even that doesn't always make sense: for example, the crypto consolidation > (NSS) is just not working (OpenSSL is the de-facto standard upstream > projects are used to work with and many still support only that) and > suggesting all GUI apps to > "standardize on GTK+" would be a complete no-go. That's not about "standardize on GTK+" (yes, it would be nice world with Qt Everywhere :D) but support best supported framework. There's no problem with not supported GStreamer - it's supported in Phonon, with some question marks. So now once we have lot of stuff on Phonon, we can make Xine lib optional. Some time ago it was much more better than GStreamer, now GStreamer is better and more supported. We should choose better technology over politics. Jaroslav > Kevin Kofler > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 15:33:43 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > Another interesting thing is PA & Phonon integration work by Colin > > Guthrie (see the link in my first message). Phonon just as wrapper/thin > > client for PA with nicer Qt like API. I like this idea. > > That's not what his current work does, and it's not really possible as PA > doesn't do decoding, so you'd still need some decoding library. Of course, I know! > Colin Guthrie's branch still uses GStreamer or xine-lib (he's currently > working with both backends because he knows both are used). What it adds is > that PA sinks show up as Phonon devices so you can choose where to direct > your output to, as opposed to the one big "PulseAudio" device we currently Yes, he does. > have (where it just uses the sink set as default in PA). I suppose he's > also going to tag the streams with the PA stream type matching the Phonon > stream type the application sets, if he doesn't already. > > So this lets you use Phonon's flexibility (directing specific types of > streams to specific outputs) while still using PulseAudio, you don't have > to choose one or the other anymore. And that's what I have been talking - it does not duplicate PA, but just wraps PA. Jaroslav > Kevin Kofler > -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (40/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 40/2009 Time: 2009-09-29 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-29 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * StevenParrish * ThanNgo * ThomasJanssen * Mary Ellen Foster -- = Agenda = o Topics to discuss: * kde-sig steering committee * k3b/koffice reverts, recommended by upstreams * future of Phonon * upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately * mandriva developments integrating pulseaudio support (and improving gstreamer backend) [1] = Summary = o kde-sig steering committee * The KDE SIG Steering Committee will be formed by (in alphabetical order): jreznik, Kevin_Kofler, ltinkl, rdieter, SMParrish, svahl, than. * 4 votes will be required to pass decisions where a vote is called for. * rdieter will summarize the exact rules. o k3b/koffice reverts, recommended by upstreams [2] * F12 will revert to (kde3) k3b-1.0.x and koffice-1.6.x for F-12 (passed 4:2). o future of Phonon * Upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately. * Mandriva developments integrating pulseaudio support (and improving gstreamer backend). [1] * We will move back to building a standalone phonon SRPM. * The vote for the default backend is split 3:3, needs the 7th vote from svahl. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-06 = Links = [1] http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html [2] http://rdieter.livejournal.com/15770.html Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wednesday 30 September 2009 00:11:21 Lennart Poettering wrote: > On Tue, 29.09.09 22:46, Kevin Kofler (kevin.kof...@chello.at) wrote: > > Lennart Poettering wrote: > > > Uh. Nokia stands pretty firmly behind gst. As do most embedded folks. > > > > Behind GStreamer, sure. Behind Phonon (and thus also Phonon-GStreamer), > > not so much. They're currently using it, but there are people working on > > the Qt Mobility project talking about replacing Phonon with something > > else (another abstraction layer, again around native backends (GStreamer > > in the GNU/Linux case), I really don't see what the advantage would be > > over Phonon). > > Haha. So the major 'advantage' of Phonon that it would allow replacing > the backends as time progresses without breaking the KDE apps using > them now officially is proven to be bogus. The KDE/Qt folks were so > afraid of a media engine breaking API so that they created their > abstraction thing and now break API of that one more often then the > media engines themselves do. The problem is not with abstraction layer - you don't have other option than some layers if you want to write multiplatform application. It's just one level lower - not in application but in library. That means - all Qt/KDE applications can use multimedia without writing lot of code, buggy, not maintainable etc. So where's the problem? There are two Phonons - one in Qt, one in KDE. I don't like this schizophrenia. This should be solved but now we have to live with one or another - that's why we brought this issue to the world. But I'm happy you have joined this discussion as PA developer. How do you see PA support in GStreamer and Xine? Functionality, features, support - regarding to Fedora development as this could influence our final decision. Another interesting thing is PA & Phonon integration work by Colin Guthrie (see the link in my first message). Phonon just as wrapper/thin client for PA with nicer Qt like API. I like this idea. > Do I hear an "I told you so!"? > > Abstractionitis is an illness, not a remedy. > > Lennart > Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Hi! We, KDE SIG, are considering which backend should be default for Phonon in Fedora. Seems like it's not easy to agree on final decision @ KDE SIG meetings, we'd like to summarize what's the problem, some backends facts (please correct me, comment, add, etc.) and we'd like to hear comments from outer KDE SIG universe, from you, Fedora developers & users, too. First question is which Phonon use - there are two actually - one is part of Qt, one is part of KDE. Upstream recommends building/packaging phonon from qt, and building/packaging backends separately. Some backends facts... GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality * Maybe more support from upstream developers in the future? [1] * Nokia is upstream Xine backend facts: * default in F10 & F11 * recommended by sandsmark (upstream developer) and Amarok team * Xine is not as well supported as GStreamer in Fedora - but currently nearly bug free * KDE is upstream We prepared test plan but still we don't have any response from our users. For some users Xine one works better, for others GStreamer backend works better. Seems like it depends on sound HW, ALSA support, PA, engine, backend -> lots of possibilities. So there are two questions: 1. which Phonon 2. which backend fits better to Fedora... [1] http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html Jaroslav & KDE SIG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (39/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 39/2009 Time: 2009-09-22 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-22 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-22/fedora-meeting.2009-09-22-14.03.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-22/fedora-meeting.2009-09-22-14.03.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen -- = Agenda = o Topics to discuss: * qt4/kde4 based alternative for pinentry-qt? ** currently pinentry-qt4 seems broken [1] * package list for KDE live images * future of Phonon ** upstream recommends building/packaging phonon from qt, and building/packaging backends separately * KDM fingerprint support update = Summary = o pinentry-qt4 * pinentry-qt4 is currently broken in rawhide atm. * The latest rawhide builds requires pinentry-qt (the qt3 version). * This drags qt3 onto the live images. * RexDieter is debugging it with upstream but this is a slow process. * This issue also affects latest pinentry for F-11. * Until the bug is resolved kdepim will require the qt3 based pinentry-qt. * On the live images pinentry-gtk will be used to avoid qt3 on them. o live image package list * Without qt3 on the live images there is some space for additional packages. * pavucontrol and digikam will be added to the live images. o future of Phonon * upstream recommends building/packaging phonon from qt, and building/packaging backends separately * xine as default backend? * final decision postponed for next week o KDM fingerprint support update * needed patch commited to upstream * djaara can start working on it again * jreznik is preparing scratch build with patch to test it * not a F12 stuff, probably updates -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-29 = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=523488 Jaroslav & Sebastian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (37/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 37/2009 Time: 2009-09-08 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-08 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-08/fedora-meeting.2009-09-08-14.07.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-08/fedora-meeting.2009-09-08-14.07.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * ThanNgo * EikeHein * RexDieter -- = Agenda = * topics to discuss: o switching back to standalone Phonon and Phonon-xine, as Qt's Phonon and its backends will not be updated anymore [1] [2] [3] o KDE-4.3.1 state o constantine-kde-theme o Red Hat Developer Conference 2009 Brno [4] = Summary = o switching back to standalone Phonon and Phonon-xine * we didn't agreed on, decision postponed now, waiting for KDE e.V. and Nokia solution * we have to retest both -gstreamer and -xine backends according to our test plan o KDE-4.3.1 state * pushed to updates-testing o constantine-kde-theme * near to final, please test * widescreen is still broken (fixed with latest build, jreznik) o Red Hat Developer Conference 2009 Brno * invitation to Brno (and reminder for Kevin Kofler) -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-15 = Links = [1] http://doc.trolltech.com/4.6-snapshot/phonon-module.html [2] http://doc.trolltech.com/4.7-snapshot/phonon-module.html [3] http://labs.trolltech.com/blogs/2009/09/03/multimedia/ [4] https://fedoraproject.org/wiki/DeveloperConference2009 -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Saturday 29 August 2009 22:43:46 Kevin Kofler wrote: > Matthias Clasen wrote: > > Anyway, this all seems to be a somewhat moot discussion, trying to nail > > us down on a 'promise to keep the old stuff around', when there already > > is a patch that can solve the whole dilemma. > > Looks like this is actually moot. I checked for how much of KDE really uses > PolicyKit as of KDE 4.3. It turns out that the only user is PolicyKit-KDE > itself. And it's kinda moot to keep the old framework around just to have > an authentication agent no program will ever call into or an authorization > editor for a database no other program will ever look into. ;-) I told you that it's not used (nearly) anywhere ;-) I proposed removal of Polkit-qt and PolicyKit-KDE - we don't need it (for now). It's maybe better solution than shipping incompatible library with the upstream one. API & ABI compatibility is broken by my patch. But the patch is working, need some polishing. That's not problem, compatibility is. > So I'm retracting both my offer to maintain a compat package for PolicyKit > 0.9 and my request to not retire it, it looks like we really don't need it > anymore. (Well, it's pretty bad that we get PK1 forced on us before the KDE > auth agent is ready, but that's not something a compat package could fix, > only reverting the whole thing could.) Kauth actually uses old Polkit-qt but it's KDE 4.4 stuff. It should be ported to use PK1 - question is - port it directly to KAuth - so we don't need PolicyKit-Qt but Qt based library should be nice to have. I think best way to avoid this problems is to do the same as in PackageKit - PolicyKit-qt should be part of PolicyKit GIT/package. David, Matthias what do you think? Could I ask you to join you there? > Hopefully, by KDE 4.4, when more KDE > stuff will actually use PolicyKit, we'll have a solution for PolicyKit 1 > support. I also hope we'll be able to provide a KDE auth agent soon (but > for now please see our request to enable the GNOME one in KDE – we need > SOME auth agent running in KDE ASAP to make KPackageKit work properly). +1 > Kevin Kofler Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 16:14:51 Jaroslav Reznik wrote: > On Friday 28 August 2009 15:36:19 Matthias Clasen wrote: > > On Fri, 2009-08-28 at 06:47 -0500, Rex Dieter wrote: > > > Matthias Clasen wrote: > > > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 > > > > in a matter of a few days. The KDE sig should really be able to get > > > > this port done. We really don't want to ship multiple authorization > > > > databases, that way lies confusion and madness. > > > > > > The PolicyKitOne feature page does include in its contingency plan: > > > "If not all ports listed above can be completed in time, keep PolicyKit > > > 0.9 around..." > > > > Right. But from what I've heard that is not the case. Jreznik just said: > > > > > > I have initial port [...] seems like it's working now and usable. > > Yes, I have port but I'm not sure how to combine it into current KDE as it > breaks polkit-qt API and I don't like shipping big patches that actually > forks project. I'd like to see it from upstream. And this apply only to polkit-qt-core, I'm not even sure it's easily possible to port polkit-qt-gui without mayor rewrite. Jaroslav > I'm working on this, we have topic for our next KDE SIG meeting. If you > could join, it would be great - > http://fedoraproject.org/wiki/SIGs/KDE/Meetings. > > Matthias, could you please look at > https://bugzilla.redhat.com/show_bug.cgi?id=519674 > > Thanks > Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 16:23:07 David Zeuthen wrote: > On Thu, 2009-08-27 at 12:45 -0400, Matthias Clasen wrote: > > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > > packages (though renaming should not be needed as they already have > > > distinct names), to be used by KDE) for F12. It is my understanding > > > that those will not conflict with PolicyKit 1 and can coexist just > > > fine, if that's not the case, please correct me. So please don't > > > obsolete PolicyKit 0.9! > > We announced that this would happen long ago. And, FWIW, it was approved > long ago by FESCO too. And you've been aware of this long ago as well. > So, sorry, but we will obsolete the old packages and I'm afraid you will > need to deal with it. Just like everyone else. As I said - patches are mostly ready, only polishing is needed. What I don't like is that it is our fork of polkit-qt. I think we should discuss it at KDE SIG meeting, how to do it carefully. You can join us. It's Freedesktop.org hosted, so it should match releases of major desktop environments, not one distribution. Upstream is not using Fedora, they can't get it running (I'm not blaming anyone), so it looks I'm now upstream ;-) I know why are you pushing on this and I don't have objections. For Authentication Agent we'd like to use Gnome as I'm fighting with it. BeginAuthentication method should be OK, but daemon does not accept it's signature... Could I ping you sometime next week? I'm leaving soon today... Thanks Jaroslav > > We really don't want to ship multiple authorization > > databases, that way lies confusion and madness. > > Indeed. And in this transition period where we've been shipping both set > of packages, there has been a lot of confusion. I've witnessed that > myself. We just don't want that to happen in a released OS. > > David -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Friday 28 August 2009 15:36:19 Matthias Clasen wrote: > On Fri, 2009-08-28 at 06:47 -0500, Rex Dieter wrote: > > Matthias Clasen wrote: > > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > > > a matter of a few days. The KDE sig should really be able to get this > > > port done. We really don't want to ship multiple authorization > > > databases, that way lies confusion and madness. > > > > The PolicyKitOne feature page does include in its contingency plan: > > "If not all ports listed above can be completed in time, keep PolicyKit > > 0.9 around..." > > Right. But from what I've heard that is not the case. Jreznik just said: > > > I have initial port [...] seems like it's working now and usable. Yes, I have port but I'm not sure how to combine it into current KDE as it breaks polkit-qt API and I don't like shipping big patches that actually forks project. I'd like to see it from upstream. I'm working on this, we have topic for our next KDE SIG meeting. If you could join, it would be great - http://fedoraproject.org/wiki/SIGs/KDE/Meetings. Matthias, could you please look at https://bugzilla.redhat.com/show_bug.cgi?id=519674 Thanks Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ktorrent adds kdm - Re: Orphaning packages
On Thursday 27 August 2009 18:34:38 Michael Schwendt wrote: > On Thu, 27 Aug 2009 12:14:43 -0400, Ben wrote: > > [KDE X session file] > > > So your issue is that kdebase-workspace puts it there, but it's > > not complete, so it shouldn't? > > Well, in case installing ktorrent shall drag in the packages > for a complete KDE desktop, the current dependencies are incomplete. > Some packages are missing. > > Alternatively, ktorrent shall drag in only what's really needed. > Would be tons better for the "Install KDE app on GNOME desktop" > scenario. That's what we are fighting on the other side of barricade - sometimes Gnome stuff brings so many strange dependencies. There's only one solution - report bug, defend it with arguments, it's not only about splitting but provides, etc... But sometimes status quo wins ;-) Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
On Thursday 27 August 2009 19:54:19 Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 25.08.2009 02:07, Kevin Kofler wrote: > > Rahul Sundaram wrote: > >> A quick way to actually check for such dependencies is to switch to > >> another desktop environment, say Xfce, remove all the KDE packages and > >> install one of the KDE apps. It usually reveals dependencies which > >> are rather silly. I have seen kde-settings, background packages and > >> kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus > >> et all are often used outside KDE. > > > > It's not like those dependencies bite. ;-) HDD space is cheap. > > This is incorrect question setup. HDD space not always cheap. This may > be very expensive, f.e. on embedded systems, on USB-stick, Live-CD > images... Additionally it additional bandwidth on updates, which cost > often is more significant. But at end, main point for me what it is > "incorrect". This is very monolithic, small user chose to manipulation, > big and, as showed before, often produce additional errors (dependency > and others). > > So, I do not call fanatic split all what we can find, but if we can > reasonably (ok, I do not want question and define it as at least > anything see in that sense) provide program separately - why you argue > with that? Hi Pavel, as Kevin has already pointed out - we already did some splits, we discuss it on our meeting, counting pros and cons. If you find something to be split, feel free to report the bug, join our meeting, defend it. With good arguments we can do it. But sometimes even one good reason is not enough to do it and there could be another reason why we shouldn't do it. Jaroslav > At and, we see there discussion about big packages, and some arguments > why it is not problem. But what main arguments to do NOT split some thus > packages on few? -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Thursday 27 August 2009 18:45:44 Matthias Clasen wrote: > On Thu, 2009-08-27 at 17:35 +0200, Kevin Kofler wrote: > > Jaroslav Reznik wrote: > > > PolicyKit-KDE is now integral part of kdebase-workspace, it is a KDE > > > 4.3 feature, we should disable it for now (untill we have new ported > > > version). Same problem is with PolicyKit-Qt as my quick port breaks > > > API. I'd like to prepare new PolicyKit-Qt, more powerful that actually > > > matches PolicyKit Authority DBUS interface. It's quite a bad timing > > > with switching to new PolicyKit. I'm not sure I'll have releasable > > > version in time of beta, I'll try it but there's still question with > > > API compatibility for KDE 4.3. There are no KDE apps utilizing PK-Qt > > > now so I think it's not problem to do not ship it now. What do you > > > think? > > > > System Settings uses it (well, 1 or 2 modules do). And PolicyKit > > integration is advertised as a KDE 4.3 feature by upstream and even our > > feature page. So I think just dropping it is not an option. > > > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > packages (though renaming should not be needed as they already have > > distinct names), to be used by KDE) for F12. It is my understanding that > > those will not conflict with PolicyKit 1 and can coexist just fine, if > > that's not the case, please correct me. So please don't obsolete > > PolicyKit 0.9! > > I have been able to port some 10-12 PolicyKit users from 0.9 to 0.90 in > a matter of a few days. The KDE sig should really be able to get this > port done. We really don't want to ship multiple authorization > databases, that way lies confusion and madness. I have initial port - it really took two days. It's not finished as I'm not sure about shipping such big change in KDE, practically our own fork of PolicyKitQt library. With 0.92 it wasn't even possible to use this library as it was intended! I can give a shot with 0.94, seems like it's working now and usable. I'll try to finish it but really I really don't want to ship this hack/fork. I'd like to have proper PolicyKit 1 support, based on library from scratch, using DBUS interface (I don't know how to combine C++ with Glib callbacks, any help?) and offering same API as Glib version. But this is more KDE 4.4. stuff. Next time please try to synchronize/coordinate with upstreams you are targeting ;-) I'd like to help upstream as it comes from Fedora. We're trying to be more proactive in this area but you know, we're few people right now (but growing!). Another problem as I've already described is that new Policy Kit does not run nearly anywhere, even I had to update to Rawhide (btw X server is really very broken by now). Jaroslav > > Matthias -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Thursday 27 August 2009 17:35:36 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > PolicyKit-KDE is now integral part of kdebase-workspace, it is a KDE 4.3 > > feature, we should disable it for now (untill we have new ported > > version). Same problem is with PolicyKit-Qt as my quick port breaks API. > > I'd like to prepare new PolicyKit-Qt, more powerful that actually matches > > PolicyKit Authority DBUS interface. It's quite a bad timing with > > switching to new PolicyKit. I'm not sure I'll have releasable version in > > time of beta, I'll try it but there's still question with API > > compatibility for KDE 4.3. There are no KDE apps utilizing PK-Qt now so I > > think it's not problem to do not ship it now. What do you think? > > System Settings uses it (well, 1 or 2 modules do). And PolicyKit > integration is advertised as a KDE 4.3 feature by upstream and even our > feature page. So I think just dropping it is not an option. > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > packages (though renaming should not be needed as they already have > distinct names), to be used by KDE) for F12. It is my understanding that > those will not conflict with PolicyKit 1 and can coexist just fine, if > that's not the case, please correct me. So please don't obsolete PolicyKit > 0.9! +1 for compat package! > Kevin Kofler -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
Hi Matthias! For KDE we'd like to use Gnome Authentication Agent as we don't have our own, I've already reported it to polkit-gnome bugzilla [1]. PolicyKit-KDE is now integral part of kdebase-workspace, it is a KDE 4.3 feature, we should disable it for now (untill we have new ported version). Same problem is with PolicyKit-Qt as my quick port breaks API. I'd like to prepare new PolicyKit-Qt, more powerful that actually matches PolicyKit Authority DBUS interface. It's quite a bad timing with switching to new PolicyKit. I'm not sure I'll have releasable version in time of beta, I'll try it but there's still question with API compatibility for KDE 4.3. There are no KDE apps utilizing PK-Qt now so I think it's not problem to do not ship it now. What do you think? In the future KDE is going to use own authentication framework kauth as KDE is multiplatform desktop. On Linux we will use PolicyKit as backend for kauth, probably directly talking to PK, so not using PK-Qt at all. I'm sorry we're late but upstream developers do not use Fedora and PK-1 doesn't work on their distributions. So practically I become upstream, fighting with QtDBus and PK-1 types ;-) [1] https://bugzilla.redhat.com/show_bug.cgi?id=519674 Jaroslav On Thursday 27 August 2009 00:37:49 Matthias Clasen wrote: > As part of the move to PolicyKit 1.0, the old PolicyKit 0.9 and > PolicyKit-gnome 0.9 packages are going to be obsoleted. Our plan is to > have the Obsoletes in place before the beta. > > Most users of PolicyKit have been ported over by now, but there are a > few stragglers. If your package is using PolicyKit, now is the right > time to look at porting it to PolicyKit 1.0. If you need help with that, > feel free to ask on fedora-desktop-l...@redhat.com or > polkit-de...@lists.freedesktop.org. > > For details, see http://www.fedoraproject.org/wiki/Features/PolicyKitOne > > > Matthias -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (33/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 33/2009 Time: 2009-08-011 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-08-11 Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-11/fedora- meeting.2009-08-11-14.07.html Full log: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-11/fedora- meeting.2009-08-11-14.07.log.html -- = Participants = * Jaroslav Reznik * Kevin Kofler * Rex Dieter * Sebastian Vahl * Steven Parrish * Lukas Tinkl * Thomas Janssen -- = Agenda = topics to discuss: * KDE 4.3.0 blockers (for F11/F10) * Extragear for KDE 4.3.0 (status) * KDE live images - status = Summary = o KDE 4.3.0 blockers (for F11/F10) * fish:/// problem [1] ** regression, suspicious commits #946444, #933202 ** ltinkl to try reverting suspect upstream commit(s), and test things out * ctrl+f12 problem [2] ** probably plasma to plasma-desktop rename problem ** reported upstream o Extragear for KDE 4.3.0 (status) * assigned to svahl while than is away * there are no group acls... o KDE live images - status * i686 and x86_64 images ready by svahl [3] * prelink issues ** kio slaves are segfaulting ** prelink bug should be reopened as we thought it's fixed already * image contains newer PyKDE4 and kde-settings from koji to get printer configuration and wallpaper back * firstboot is not working [4] * x86_64 image is much more bigger than i686 -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-08-18 -- = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=516416 [2] https://bugzilla.redhat.com/show_bug.cgi?id=516445 [3] http://lists.fedoraproject.org/pipermail/fedora-kde/2009- August/003555.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=515419 -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Requires question in SPEC
On Tuesday 11 August 2009 10:02:23 Steven Moix wrote: > Hello all, > > I'm facing a problem with one of my SPEC files...I'm packaging a program > (motion, in RPM Fusion) that has a startup script. In the start() > section of this startup script, I have added an > "LD_PRELOAD=/usr/lib64/libv4l/v4l2convert.so daemon $motion" to support > more cameras. You can patch your package to use libv4l directly. Usually it's easy - there are some issues but... Check some packages using v4l to check what you have to do to port it. Also check this blogpost by Hans de Goede (libv4l author) [1]. [1] http://hansdegoede.livejournal.com/3636.html Jaroslav > So I naturally added a "Requires: libv4l" in my SPEC file, but of course > rpmlint complains with "E: explicit-lib-dependency libv4l". > > The problem here is that I can't see how RPM could automatically add > libv4l as a dependency when I build the package...it's not in the code, > only a call in the startup script. So... > > * Should I consider that libv4l is installed by default on F10/11 and > not put the require. > * Put the require and let rpmlint complain. > > Any advice on that? > Note that if you launch the startup script on a system that doesn't have > libv4l, it simply doesn't do the LD_PRELOAD, but still works "as usual". > > Thanks > Steven -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Friday 07 August 2009 10:42:35 Rahul Sundaram wrote: > On 08/07/2009 01:35 PM, Jaroslav Reznik wrote: > >> The other problem is if you'd like stable updates but you prefer KDE, or > >> vice versa =) > > > > Why do you expect that updating to the latest KDE means unstable system? > > ;-) > > As already explained, stable in the sense of things that work the same > (No big UI changes etc). We are not talking about robustness here > although new updates has the potential to cause issues there as well. But that means Fedora is totally unstable - as we're forcing users every year to survive much more bigger changes. Fedora is really very inconsistent between releases. This is case where continual updates can avoid it. Maybe we're lacking some vision farther then +1 release, not only in Fedora, but in all OSS projects... Jaroslav > Rahul -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Friday 07 August 2009 04:21:56 Adam Williamson wrote: > On Thu, 2009-08-06 at 12:30 -0700, Jesse Keating wrote: > > On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote: > > > OK, bad example, but you know what I mean. > > > > Yes, I do, and I think there is room for a Fedora offering that is > > released frequently (every 6 months), supported for about a year, with > > conservative updates to the platform. That's nearly exactly what we > > have in Fedora Desktop. There is also room for a Fedora offering that > > is released frequently (every 6 months), supported for about a year, > > with aggressive updates to the latest and greatest for the platform. > > That's nearly exactly what we have in Fedora KDE. > > > > The real problem is going to be when somebody wants to make an offering > > that features GNOME but has aggressive updates to latest and greatest > > GNOME on every update stream, as that cannot coexist with the > > conservative Fedora Desktop. > > The other problem is if you'd like stable updates but you prefer KDE, or > vice versa =) Why do you expect that updating to the latest KDE means unstable system? ;-) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thursday 06 August 2009 01:59:02 Bastien Nocera wrote: > On Thu, 2009-08-06 at 00:56 +0100, Bastien Nocera wrote: > > On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: > > > Hi FESCo, > > > > > > After requesting status updates, including direct email to the feature > > > owners, the following feature pages do not have a current status or > > > their ability to tested during the Alpha is unclear based on the lack > > > of information provided or percentage of completion. > > > > > > > > > https://fedoraproject.org/wiki/Features/Gnome2.28 > > > > > > > > Feature will obviously be done on time. The feature process doesn't seem > > so forgiving about things happening upstream rather than downstream... > > > > > In accordance with our recorded process about providing status, I am > > > proposing that they reviewed and dropped from the Fedora 12 feature > > > list at Friday's FESCo meeting. > > > https://fedoraproject.org/wiki/Features/Policy/Dropping > > > > I'll make sure one of the Desktop-y guys updates this (presumably > > Matthias). > > I actually looked at this, and the feature process just isn't good > enough for this. We can't really say we're at 100% for GNOME 2.28 when > it hasn't been released, now can we? It's same for us - KDE SIG. Percentage completion is not the only one criterion for completeness, if we have everything prepared, we have betas/RC already imported and we're just waiting for final release (and as KDE has time based releases we know we can do it for Fedora release). And same for artwork - it's part of feauture but we have to wait for design team etc... The criteria should be - is it 100% ready? If not and it's waiting for upstream release (probably few more exceptions can be found) - is it possible to deliver this feauture 100% ready in time of release? Yes, we have schedule. Then OK. Jaroslav > > So what's expected of such features when the feature process seems > inappropriate? > > Cheers -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kde-4.3.0 coming to F-10, F-11
On Wednesday 05 August 2009 12:04:21 Till Maas wrote: > On Tue, Aug 04, 2009 at 01:55:11PM -0500, Rex Dieter wrote: > > The KDE SIG is now working on KDE-4.3.0-related builds for Fedora 10 and > > 11 candidate updates. As this requires some buildroot overrides, if your > > package uses KDE libraries, it may inadvertently build against KDE 4.3.0 > > libraries and may, at least in some cases, NOT work with 4.2.4. > > > > So please either hold off on update builds for packages using KDE > > libraries or contact us (on the #fedora-kde IRC chan or the fedora-kde > > mailing list). > > Can't you use a temporary build-tag-something to stage the 4.3 updates > seperated from the remaining packages to avoid breakge like this? This > happend also e.g. when everything was rebuild for Python 2.5 or > similiar. +1 as it can cause (and it's causing) lot of problems... Jaroslav > Regards > Till -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (30/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 30/2009 Time: 2009-07-21 14:00 UTC NEW MEETING TIME! Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-21 Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora- meeting.2009-07-21-14.10.html Full log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora- meeting.2009-07-21-14.10.log.html -- = Participants = * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * ThanNgo * StevenParrish * Thomas Janssen -- = Agenda = topics to discuss: * should we support old artwork + fedora system logo * defining @critical-path-kde group (task delegated to the SIG for each spin by FESCo) = Summary = should we support old artwork + fedora system logo * should we ship old artwork? o most of KDE SIG members voted yes if it's not broken o we need testers * problem with fedora system logo o should we use system-logo-white or our own system-logo-kde? o install it to /usr/share/pixmaps o what about generic logo? * jreznik will ask design team and start mailing list thread (this one? :D) defining @critical-path-kde group (task delegated to the SIG for each spin by FESCo) * KDM into @critical-path-kde * do we want to be involved? o or we want our own testing? * who will be responsible for QA? * KevinKofler will check it... = Tasks = 1. jreznik checks logos with Design team 2. KevinKofler asks on fedora-devel about critical paths = Links = -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-28 -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Needing Updates
On Wednesday 15 July 2009 02:28:07 Ben Boeckel wrote: > John Poelstra wrote: > > https://fedoraproject.org/wiki/Features/KDE43 > > I updated this since both Rex is on vacation and Kevin is most > likely as well. Hi Ben, don't forget to update "Updated" column on Feature List page [1]. I often forget either :D It's updated now. [1] https://fedoraproject.org/wiki/Releases/12/FeatureList Jaroslav > --Ben -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tuesday 14 July 2009 10:21:13 Daniel Mach wrote: > I found 375 possibly wrong NVRs in rawhide. > Can you check it an fix it, please? > I'd like to file bugs for those which won't get fixed in couple weeks. kde-settings-4.2-10.20090430svn.fc11.src.rpm - Pre-release build's release should start with '0.'. It's not a pre-release but regular snapshot from our SVN repository. We don't have releases. Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Raising the bar
On Monday 29 June 2009 21:27:27 Matthias Clasen wrote: > Hey all, > > we'd like to announce the 'Fit and Finish' initiative for Fedora, > > http://fedoraproject.org/wiki/Fit_and_Finish > > with the goal to improve the user experience of the Fedora desktop. We > want to identify the small (and sometimes large) roadblocks that make > everyday computer use harder than it needs to be, and try to fix them. Does this apply only to so called "Fedora desktop" = Gnome or to Fedora Desktop - as desktop environments (KDE, LXDE, XFCE4)? If only for Gnome, can we attend this effort either? Speaking in name of KDE SIG? It looks really interesting for me - avoid small bad user experience. Jaroslav > 'Fit and Finish' is meant to be complementary to the work of the Fedora > QA team. They do a great job of ensuring the quality of all the new > features that land in Fedora each cycle. But when features are developed > and tested on their own, the overall experience of the system as a whole > can sometimes end up a bit uneven and rough. 'Fit and Finish' will focus > on improving the way our users experience Fedora. > > To achieve this, we will hold regular test days, each of which will > focus on use cases in a certain area. A few ideas for test day topics > can be found on the 'Fit and Finish' page already. If you have ideas for > other areas that could benefit from this kind of attention, please let > us know. > > Our first test day will focus on display configuration, and will be held > on Tuesday, July 7, from 12:00 to 21:00 UTC (8am -> 5pm EDT), in the > fedora-fit-and-finish irc channel on FreeNode. Please come and join us > there ! > > > Matthias Clasen for the Desktop team -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Monday 29 June 2009 17:02:36 Michael Cronenworth wrote: > Dariusz J. Garbowski on 06/29/2009 09:56 AM wrote: > > Maybe call it "Default" then? > > No, because that's offensive to some people apparently. No, "default" is not offensive! "Gnome Desktop Live Edition (default)" is OK for me... -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Monday 29 June 2009 17:12:42 Bastien Nocera wrote: > On Mon, 2009-06-29 at 15:15 +0200, Kevin Kofler wrote: > > Bastien Nocera wrote: > > > I'm sure that a KDE hacker with access to a supported fingerprint > > > reader could implement the enrollment facility within an afternoon. > > > > There's already an implementation: > > http://blog.djaara.net/wordpress/2009/ > > > > That's a student from Brno, ltinkl and jreznik know him personally, so > > I'm sure they'll package it (or get the author to package it) as soon as > > they feel it's ready. > > Nice, though he didn't contact either myself, or the upstream fprintd > list about it, which is why I didn't know about it. I asked him to be more in touch with upstream - both KDM and fprint. From what I know he asked for some advise and proposals on mailing list but he wasn't specific about why he need it. But we're again in lack of communication (now from his side)... :( > Neat. -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Monday 29 June 2009 16:08:02 Rahul Sundaram wrote: > On 06/29/2009 07:20 PM, Jaroslav Reznik wrote: > > The biggest issue is lack of communication from "the only right Desktop" > > - we can't catch changes if these changes are communicated to community > > too late. Lot of new free desktop techs come from Fedora and we know it > > and we're working really hard with upstream to solve it and catch current > > state. But we're unfortunately out of sync with KDE upstream releases and > > so it's harder sometimes. > > It helps to drop the foo vs bar fight, finger pointing and get on the > irc channel or in mailing lists if necessary and ask questions. That's what I'm constantly doing, it's not easy sometimes but actually it helps a lot and it's worth my heart attacks ;-)! Jaroslav > Rahul -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Monday 29 June 2009 06:47:32 Rahul Sundaram wrote: > On 06/28/2009 06:51 PM, Kevin Kofler wrote: > > Rahul Sundaram wrote: > >> The difference between features like a desktop globe and things like > >> NetworkManager is obvious. > > > > I know NM is important, and in fact that's why we have been shipping the > > mature NM-gnome in KDE spins so far, and it does work fine in KDE. And > > chances are good for the native NM plasmoid to be ready to be the default > > for F12. It's already available as an option. > > nm-applet doesn't work the KDE Wallet for example. This is exactly what > I mean by lack of integration. Yes, it's lack in free desktops integration! But these comment sound like a hope for a bright future: https://bugs.freedesktop.org/show_bug.cgi?id=16581#c9. It's important even for non Gnome/KDE applications like Arora. I don't think "free desktop" should be about competition (yes, we need some competition to move development forward) but about collaboration! Freedesktop.org is a great place for it. Jaroslav > > > And how is this relevant to the user? The user cares about what features > > they're getting, not who has written the code for them. > > It is relevant from the Fedora perspective. > > >> KDE does lack integration with them. > > > > That word doesn't mean what you seem to think it means. > > I understand perfectly well what it means. It's just that you aren't > willing to accept that they are integration gaps. > > Rahul > > Rahul -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Monday 29 June 2009 10:56:24 Rahul Sundaram wrote: > On 06/29/2009 12:54 PM, Kevin Kofler wrote: > > The user does not care, so why present things to the user as if they > > should? > > I said nothing about users. You should as a Fedora developer care about > integration with leading edge features that makes Fedora stand out. > > > You're calling things "integration" which are just features, e.g. > > fingerprint reading. > > I guess that is a just a different perspective. My point of view is > that, finger print functionality already exists for quite sometime. > What is new is the integration with desktop environment and display > manager. I find it amusing that you won't even agree that shipping > nm-applet in KDE results is a gap in integration. Yes, shipping nm-applet is really big issue as it has a lot of usability problems (and from what I know authors finally realized it) but it's better to have something than nothing of course... The biggest issue is lack of communication from "the only right Desktop" - we can't catch changes if these changes are communicated to community too late. Lot of new free desktop techs come from Fedora and we know it and we're working really hard with upstream to solve it and catch current state. But we're unfortunately out of sync with KDE upstream releases and so it's harder sometimes. Jaroslav > This was a result of > the KDE 3 -> KDE 4 migration. Let's just agree to disagree. > > Rahul -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Monday 29 June 2009 15:15:12 Kevin Kofler wrote: > Bastien Nocera wrote: > > I'm sure that a KDE hacker with access to a supported fingerprint reader > > could implement the enrollment facility within an afternoon. > > There's already an implementation: > http://blog.djaara.net/wordpress/2009/ > > That's a student from Brno, ltinkl and jreznik know him personally, so I'm > sure they'll package it (or get the author to package it) as soon as they > feel it's ready. I'll ping him to check the current state but I'm afraid he has final state exams right now so he's quite busy. Jaroslav > Kevin Kofler -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Monday 29 June 2009 13:22:05 Naheem Zaffar wrote: > The "I don't care" looks like "get me out of here!". "I don't care" really scares me. If you don't care then system installation or using with live CD is not a job for you! Jaroslav > > Not presenting a default choice is just bad usability. Those that know > about the different desktop environments should be offered an easy and > accessible way to get to them (I am not suggesting that the current page > does that - but presenting a false choice to many people already out of > their element trying this linux thingymajig may be enough to scare them > away.). Those that don't should not have to worry to much over such a page. -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Saturday 27 June 2009 04:02:37 Adam Miller wrote: > On 6/26/09, Matthew Woehlke wrote: > > Also, I want to pick at your use of "blindly"; who says it has to be > > blind? Why not work to educate users about the difference? A "Take a > > Tour" would probably be good publicity anyway. (You know, take the edge > > off that "no clue what they're doing" thing...) > > I was simply quoting on the blind part, but I actually do agree that a > "Welcome to the world of Fedora" thing would be an awesome idea. > > As I have brought up to Kevin Kofler in IRC, I think before we did > something like that we would need to first look into having the KDE > SIG spawn up documentation that matches the gnome-centric docs as well > as working a little more with upstream to try and get some of the > "kinks" worked out with things like the network manager plasma widget. > As the Special Interest Group of KDE within Fedora I think it should > be our responsibility to be the driving force behind providing > equivalent support for KDE as Gnome currently receives and once the > situation is such that KDE truly is getting equivalent back end > support that it needs to be able to go "prime time" as a "First Class > Citizen" (as it seems to be referred to) then this topic could be > revisited. Even with less manpower than "official desktop team" we're trying to contribute back to upstream as much as we can, especially technologies which are coming from us, from Fedora. Eating our own dogfood. So for example we're helping upstream with our Kits (Console/Policy/Device), our patches (for example we were first GCC 4.4 distro) etc... We're trying to build bridge between Fedora and KDE upstream. But unfortunately we can't help with everything. And believe us, we really want functional KDE network manager applet! As nm-applet is really bad and I hope they redesign it soon. It's all about - what is Fedora? What we expect from Fedora? Is it one monolitic piece of software - so Gnome should be default, then it's OK to call it Desktop, or is it modular system? Then you can have bare OS without any desktop at all (is Server SIG still alive?), you can have spins working on providing/improving specific areas in Fedora, all teams working together building Fedora... We need answer before these wars without winners. Both options have some pros and cons but we have to choose... "You take the blue pill and the story ends. You wake in your bed and believe whatever you want to believe. You take the red pill and you stay in Wonderland and I show you how deep the rabbit-hole goes." Jaroslav > Disclaimer: I am a member of both the KDE SIG and Xfce SIG but I have > no distaste or hatred for Gnome or the stance of its current status as > the "default" I run both KDE and Xfce on different machines and have > no Gnome installations anywhere on hardware I own, its purely a matter > of personal choice. > > -Adam > > -- > http://maxamillion.googlepages.com > - > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (26/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 26/2009 Time: 2009-06-23 16:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-23 Meeting minutes: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora- meeting.2009-06-23-16.04.html Full log: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora- meeting.2009-06-23-16.04.log.html Full log -- = Participants = * Jaroslav Reznik * Kevin Kofler * Lukas Tinkl * Rex Dieter * Steven Parrish * Than Ngo -- = Agenda = topics to discuss: * RPM Macros [1] for packaging * critical path packages [2] - does it affect us? should it? how? * any issues to bring up in the FESCo meeting? * sharing brand with upstream * Fedora 12 KDE 4.3 feature page = Summary = Kevin_Kofler elected to FESCo, any issues to bring up in the FESCo meeting? * congratulations Kevin! * next FESCo meeting is on Friday, if you have any issues to bring up in the FESCo meeting, contact Kevin RPM Macros for packaging * MathStuf to take it to mailing list for further discussion * we should have macros for the common directories, any advantage to have macros for all stuff? * it can help cleanup SPEC files * do we need all KDE 3 macros? critical path packages - does it affect us? should it? how? * do we want to be on the list of critical packages? o if yes - which packages should be on the list? o if not - are we going to be treated as second citizens? * rdieter is releng -> signoff group, so he could be our insider to check critical updates affecting KDEs * we don't have QA o SMParrish is triager o we need QA volunteer o we have to define QA process + we need testing plan + basic QA is "try to use the desktop and report any breakage you notice" + we need some targets like "does WPA in kde-plasma-nm work?" for a kde- plasma-nm update etc. o rdieter will prepare concept sharing brand with upstream * jreznik contacted pinheiro (upstream) for his idea * fedora design team feels more negative on this * we'd like to try, we need more communication between upstream and our design team * jreznik to continue as liason between fedora-art team and upsream kde art folks in "sharing branding" Fedora 12 KDE 4.3 feature page * helps the marketing/qa machine * what we should promote for F12 o ltinkl is working on Device Kit Solid Backend o jreznik is working on Policy Kit 1 * Kevin_Kofler pointed out concerns about Device Kit state Gran Canaria Desktop Summit [3] * jreznik is attending GCDS, if you have something for upstream, contact him Meeting bot * was it useful? ;-) = Tasks = 1. MathStuf to take macros proposal to mailing lists for further discussion 2. rdieter prepare concept for KDE QA 3. jreznik to continue as liason between fedora-art team and upsream kde art folks in "sharing branding" = Links = [1] https://fedoraproject.org/wiki/SIGs/KDE/PackagingCleanup#Macros [2] http://skvidal.wordpress.com/2009/06/22/critical-path-packages/ [3] http://www.grancanariadesktopsummit.org -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-30 -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Qt 4.5.1
On Tuesday 09 June 2009 18:11:37 Jeremy Sanders wrote: > Hi - Are we likely to see a qt 4.5.1 update at some point for F10? There's > a bug fixed which makes my application very slow. Qt <4.5.1 draws long > clipped lines extremely slowly. Hi, it's waiting in Bodhi... https://admin.fedoraproject.org/updates/F10/FEDORA-2009-4844 Jaroslav > Thanks > > Jeremy > > -- > http://jeremysanders.net/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Martes 09 Junio 2009 17:05:04 Kevin Kofler escribió: > drago01 wrote: > > Or you can simply ship provide multiple video streams and switch them > > based on the useragent. (this is very likely to be the end result, > > even thought it sucks). > > The user agent is the wrong way to check for support. Arora supports > different codecs based on the platform. (It uses QtWebKit which uses Phonon > which uses the platform's multimedia support. On Fedora, it will only > support Ogg and other patent/royalty-free codecs out of the box, on O$ X, > only MPEG4 and QuickTime stuff, on Window$, whatever M$ ships. Any other > codecs have to be installed by the user.) For me - OGG fallback is essential... There can be a list of priorities like: 1. play H264 HD HQ video 2. play LQ video 4. 5. 6. 7. play OGG (the must) and then browser can choose best suitable one or fallback to OGG. Jaroslav > Kevin Kofler -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Viernes 05 Junio 2009 10:47:06 Matej Cepl escribió: > Christof Damian, Fri, 05 Jun 2009 09:55:08 +0200: > > youtube is testing html5 too: http://www.youtube.com/html5 > > Except they don't use OGG, but MPEG4, so Firefox is not able to handle it > (midori, epiphany/WebKit are). In Arora I can hear only audio... So it's not OK - OGG has to be THE MUST - basic codec supported on all platforms/browsers. I'm not against proprietary codecs (I don't want to use them). Jaroslav > Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 20:23:01 Adam Williamson escribió: > On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: > > I'll happily raise upstream bugs myself but it irks me when maintainers > > close Fedora bugs with the UPSTREAM resolution without actually taking > > the upstream fix and bringing it into Fedora. > > > > If I've reported a bug in Fedora bugzilla it's because the bug is > > present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a > > bug closed UPSTREAM doesn't help at all if I have a real problem with a > > Fedora package. > > In Mandriva I had it set up so Bugzilla has both an UPSTREAM > *resolution* and an UPSTREAM *keyword*. This handles this situation. > > If, say, the bug is in a package that gets frequent releases, and was > filed on the development release, you can just use CLOSED UPSTREAM, > because you can rely on the fact that there'll be a new upstream release > of the package soon after the upstream report is fixed, you (the > maintainer) will then naturally package the new release, and the fix for > the bug will have been rolled into the distribution package without you > having to do anything besides your normal packaging work. > > In other situations, you can set the UPSTREAM keyword, so the bug > remains open but you know it's being handled upstream and you need to > bring the fix downstream once it's available upstream. I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and CLOSED bugs are not as easy to search for duplicates when you are reporting bug. Jaroslav > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Jueves 04 Junio 2009 23:47:21 Kevin Kofler escribió: > Itamar Reis Peixoto wrote: > > the end of life for flash player (HTML5) > > Unfortunately, as much as I'd like that to be true, at this point it's > mostly just wishful thinking. :-( (It's good that Dailymotion is leading > the way there though. It's NOT good that they're hardcoding a browser check > for only Firefox though, the latest Arora which does support HTML 5 video > is not recognized, that's broken!) I was really surprised - hardcoded download of FF 3.5 :( > Now we just need HTML 5 video support in Konqueror! :-) (And an entry for > Firefox 3.5 in the list of fake browser IDs for crappy sites which still > don't understand that sniffing user agents is broken!) > > That said, unfortunately, I think we'll be stuck with some sites using > Flash crap for years to come. :-( Projects like Gnash and Swfdec will > remain important. I agree that people should NOT install the proprietary > Flash. Mostly it depends on YouTube - it's 90% of all Flash content for me. So if YouTube (and p0rn variants :D) adopts tag, battle is nearly won. For games - with JS is nice way. But it's missing IDE as Adobe has - my roommate is using some and I have to admit - it's really great tool - if you are more designer than coder. For now - we have technology, now we need tools. > > I am very happy to watch a video without macromedia flash. > > FYI, YouTube works with Gnash if you have the required codecs (but embedded > YouTube videos elsewhere don't work). There's also the solution to download > the videos from most of those sites using various downloaders or > servicemenus, then watch them with any video player. > > But HTML 5 with patent-free codecs is clearly the solution we should all > fight for! (But hardcoded checks for only Firefox aren't!) That's the problem - there must be at least fallback to patent-free open codec. It's OK for me to encode video to hypermegacool patent obfuscated "high" quality (marketing stuff) codec but there has to be Theora encoded video server as base to support all browsers! PS: There is nice progress on Theora field! Jaroslav > Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 11:01:56 Tim Waugh escribió: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. > > One reason for my belief is that I've seen the situation from the other > side: as an upstream maintainer for a package, getting bug reports > directly from users of a packaged version in another operating system. > > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. As I said - I don't want to left user in upstream jungle :-) It's more like moving bug closer to developer - user which report it is in contact with developer (that real upstream developer) and we can provide for upstream more details from Fedora side + prepare package for user to test it etc. Simple - collaboration - open source :-) Aim is fix the bug - then user is happy, we are happy and upstream is happy! > My point is that it isn't only the people reporting bugs that get > frustrated by "go report it upstream", it is also the larger free > software community. > > Another reason for maintainers to give bug reports due diligence is that > it is hard to report bugs. Package maintainers may not always > appreciate this, since they do it all the time, but look at bugzilla as > though you've never seen it before (or just remember back to when you > first saw it) -- it is hard to fill out a huge form, and if the problem > is not severe enough to warrant your time on it (or you aren't even sure > if it's a bug) you may just not bother. But this is another problem - BZ is really big monster (every time I'm reporting bug I'm scared :D). I have small PyGtk RHBZ reporter, maybe I'll release it some day (there are hardcoded passwords etc...). > Bug reporters are absolutely essential to healthy free software and > should be treated with respect. They are our eyes. > > Roll on ABRT. And new Dr. Konqui with nice guide to report crash - directly upstream. I talked with ABRT developers about closer collaboration, we'll see. Jaroslav > > Tim. > */ -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 23:35:07 Adam Williamson escribió: > On Wed, 2009-06-03 at 22:57 +0200, Kevin Kofler wrote: > > Steve Grubb wrote: > > > And then should the bug be closed hoping that one day you pull in a > > > package that solves the user's problem? > > > > If the bug is fixed upstream, the Fedora report can be reopened with a > > request to backport the fix (but that should only be done if it's > > important enough that it cannot wait for the next bugfix update getting > > pushed anyway). > > > > Until then, why do we need to have the bug open in 2 places? > > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. Yes, there's the way to do it - we always have tracker bug for most important issues we have found! And not only for new releases like Fedora 12, but for even for new versions in older releases (like current Qt 4.5.1 tracker [1] which blocks this release nearly about one month). If you think your bug is so important and it's blocker, talk to us, we add it to our tracker and then we are discussing progress on every KDE SIG meeting - you can join, you're welcome! If you join us, you can drive Fedora/KDE development even as users and only users... These important blocking bugs are never closed without working solution. [1] https://bugzilla.redhat.com/show_bug.cgi?id=497658 Jaroslav > (longer email on the whole thread coming.) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 22:27:13 Kevin Kofler escribió: > Jaroslav Reznik wrote: > > Most bugs are filled by quite technically skilled users. For average > > users it doesn't depend if it is RH bugzilla or upstream's bugzilla - > > it's too complicated for them. I know - it's another story... For these > > people forums are much more better. > > Uh, forums are a horrible place for bug reports. For one because developers > usually won't read them. It's no use complaining about bugs in front of an > audience of other newbies, the bugs must be reported to the people who > actually care, and that's what bug trackers are for. Another issue is that > forums are freeform, they don't have any sort of form which tells users > what information is required. For bug reports - indeed. But to help users - forums/mailing list are great. > > I hate lazy idiots whining about bugs in forums when they never bothered > reporting them to the developers. Yes, some users are lazy, asking stupid questions and fighting in forum. But for users it's not easy to report bug, power users should help them (and I'm trying as much I can) > > And I don't think we can make bug reports any easier, the point is that the > information is required, those "complicated" forms are there to request the > information we need. Bug report can't be easier ever but it's responsible of us to help people but first they have to know about BZ at least :D I'm helping people on some Czech forums everyday, often they PM to contact me directly and 99% of the problems (they think it's a bug) are not actually bugs... > Kevin Kofler Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 08:59:23 Ralf Corsepius escribió: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> Not if its closed. How would I be notified that the fix is in Fedora? If > >> the bug is severe enough, shouldn't the upstream commit be applied to > >> Fedora's package and the package pushed out for testing? Is all this > >> going to happen if the bug is closed? > > > > You're supposed to be the reporter of or CCed on the upstream bug, then > > you'll get notified of the fix and can reopen our bug asking for a > > backport of the fix if it's really that important (but keep in mind that > > Fedora packages often get upgraded to a bugfix release anyway, for > > example our KDE gets upgraded to a bugfix release about once a month). > > You are still presuming your users to be interested in developing and > working on your package. Yes and no - most of our bugs come from well known contributors - it's safe to them to say - please, report it upstream. They just ask as - is it downstream or upstream issue? Are you aware of this issue? If we know/we can see that bugreporter is ordinary user, we're trying to help him report this issue or we simply do it. It's not - upstream, close, shut your mouth, don't bother us! My final conclussion - there are power users, there are ordinary users, some of them of better knowledge, some worst - and we should help them, guide them - it's our work and we have to take care about them individually... There can't be one policy to match all cases... > This simply does not apply - They want to use your package. > > > As maintainers, we will also try to CC ourselves on those upstream bugs > > to track their status, but utilimately it's the reporter who cares the > > most about seeing his/her bug fixed. > > I could not disagree more. People with this kind of attude should lable > themselves maintainer and stop packaging packages in Fedora. You can ask our users if they are satisfied or not. From comments and posts I think they ARE! Check our fedora-kde list, IRC channel #fedora-kde as most of bugs are solved there even before they hit BZ... Jaroslav > Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 11:52:37 Juha Tuomala escribió: > On Wednesday 03 June 2009 11:47:26 Jaroslav Reznik wrote: > > PS: I'm not saying to not report bugs to RH bugzilla, we can help then > > but lack of direct communication between user and developer is issue, > > You're assuming that all those users are engineers and technical > people. That might be true atm but at least I also would like to get > the 'normal people' which are now ubuntu users. Most bugs are filled by quite technically skilled users. For average users it doesn't depend if it is RH bugzilla or upstream's bugzilla - it's too complicated for them. I know - it's another story... For these people forums are much more better. Maybe we lack some tool for users - without technical details, more collecting only tool... Some easy GUI for Abrt? New Dr. Konqui is nice but still too complicated for average users. They don't click on "send bug" button but "OK" buttons and accepting the fact of crash... > > back to propritetary software > > which is the reason why most 'normal people' use windows and > among the numbers, they have the control of everything (hw support etc). But if you observe bug or have some wish - there's no chance to talk to developer... > I'd like to see a day that my new display adapter works out of the > box. I'd like to see that day as a Fedora user/community member. I hope that day is close because I think it's worst problem of whole OSS Desktop :( > > Tuju > > -- > Better to have one, and not need it, than to need one and not have it. Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 05:09:49 Ralf Corsepius escribió: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is > >> _broken code_ do they need to do something about it or is it acceptable > >> for them to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. We are not forcing anyone to do anything but we think direct communication between user and developer is much more better - our "users/customers" are upstream's "users/customers" either, we are more reseller - distributor. But this doesn't mean we LEFT our users in such cases - we are still tracking this bug, we are communicating with upstream, helping our users to report it and if upstream have solution, we are trying to use it (in form of patches, suggestions etc.). To satisfy our needs, users needs, upstream needs... Jaroslav PS: I'm not saying to not report bugs to RH bugzilla, we can help then but lack of direct communication between user and developer is issue, back to propritetary software > > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". > > Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 01:34:17 Kevin Kofler escribió: > Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions > > for my own clarification. Does a maintainer's responsibilities end with > > packaging bugs? IOW, if there is a problem in the package that is _broken > > code_ do they need to do something about it or is it acceptable for them > > to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. We're not carrier > pigeons. We can't even CC the reporter on the upstream bug unless they > register an account there, and at that point they can just as well file the > bug themselves. +1! Jaroslav > Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Viernes 29 Mayo 2009 13:40:36 Chitlesh GOORAH escribió: > On Fri, May 29, 2009 at 1:30 PM, Nicu Buculei wrote: > > Movies in proprietary formats can be downloaded also with Firefox, > > Transmission, wget, etc. > > From the description of gnaughty I understand it can also download > > images, which are in free formats, so the content is in both free and > > proprietary formats. > > Here is the purpose of the application is important. A browser is not > only intended for free and proprietary > formats downloader. It serves other purposes as well. > > But gNaughty serves only purpose is "download porn". If we allow this > package, in other words it says Fedora tolerates proprietary formats. > It is not something we are comfortable with. Internet is for porn... Sorry I don't know this software but as someone already pointed - it's opensource, it can be used to download other content. It's same like Adobe banned rtmpdump as it can be used to download restricted content but Flash Player is used everyday to watch unlegal content! One interesting thing - does it download free content? Are there some porn sites under CC licence? Free culture, by community for community... Jaroslav > On Fri, May 29, 2009 at 1:35 PM, drago01 wrote: > > Sorry but this is just bullshit with this logic we should ban > > everything which can download files. > > In case of OVM you wanted to add the "unviewable" content into fedora, > > while this packages do not add the movies to fedora they just provide > > a way to download them. > > OVM is just a bunch for text files, viewable with any editor. I didn't > say "unviewable" content. > > > Chitlesh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Viernes 29 Mayo 2009 11:38:21 Rahul Sundaram escribió: > On 05/29/2009 03:00 PM, Muayyad AlSadi wrote: > >> IMHO it is not Fedora's job to define family values & moralities. Such > >> morals/values will vary all around the world > > > > I don't want fedora to define such things, we have our own values > > predefined. > > > > it should not make my job finding suck packages difficult > > we have more than 10,000 packages in the repos so don't expect me to > > test them all > > > > the package maintainers already classify their packages using Group: > > in the spec file > > > > and they already classify them in yum comps files > > > > I demand a systematic way, a policy that tells a package maintainer > > how to categories their packages in a unified proper way to warn > > people like us from their packages. > > The problem, how do we determine what is offensive to any particular > group? Some people consider 3D shooter games offensive. This is slippery > slope. Unless there is a legal issue, I believe Fedora is going to end > up with that package. For a derivative, you have to pick and choose what > you want. +1 I don't like people who wants regulate everything because they think they are gods and they know what's good/bad for people. You, as administrator with root priviliges, you're the one who should say - this package is OK for my family, this is not... Same for TV regulations - you have remote, you're the best regulator!!! When I was young, my parents locked living room if they thought I have enough TV or there's something wrong they don't want to let me see. One month ago I've read interview with Czech broadcast regulation office boss and it was wonderful - he said - Internet never was intended as free/open medium, we have to regulate it (we is Europe Union) as companies broadcasting over Internet have advantage over that regulated. Isn't better to not regulate them instead of regulating Internet??? So please, prepare these packages, put them to the repository (not default in comps) - if there's good summary/description, it's admin/parent responsibility! Jaroslav > Rahul -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Martes 26 Mayo 2009 15:44:56 Matthias Clasen escribió: > On Tue, 2009-05-26 at 15:37 +0200, Jaroslav Reznik wrote: > > Seems like direct DBus communication is the only way to do it from Qt/KDE > > apps as PolKit library requires gtk_init() somewhere in code... I've > > prepared patch for polkit-qt to the new PK1 Core API but... Or is there > > any other way to initialize glib without need for it? I'm not familiar > > with GTK app development... But library that expects gtk_init somewhere > > in application to be correctly intialized... > > Calling g_type_init() should be enough; there is no direct GTK+ > dependency in polkit-gobject. Even g_type_init() may be too much for KDE > apps to swallow though, so going directly to the bus is still a good > idea. Thanks, I'll try it. Shouldn't library do the proper initialization? Then it's OK for us and it's better for other nongtk projects (not only KDE) - I think once we have library it's useless to duplicate work. But we agreed with upstream that directly using dbus is best for us but first I tried to do port line by line according to your patches/docs/porting guide... > > PK1 should be split into parts - cross-desktop backends should be on > > freedesktop, gnome specific libraries should be in gnome repository. This > > should stop confusion. > > You mean like > > http://cgit.freedesktop.org/PolicyKit > http://git.gnome.org/cgit/PolicyKit-gnome > I thought polkit library which depends on glib initialization is not right cross desktop solution... Jaroslav -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Martes 26 Mayo 2009 11:16:14 Daniel P. Berrange escribió: > On Mon, May 25, 2009 at 02:22:02PM -0400, D. Hugh Redelmeier wrote: > > | From: Rex Dieter > > | > > | Seems frustrations are mounting: > > | "On policykit and standards" > > | http://lists.freedesktop.org/archives/polkit-devel/2009-May/000119.html > > > > [I'm an outsider. This thread is my introduction to the whole area. > > I'm not even a KDE user.] > > > > This certainly does not look like a healthy approach to standardization > > and cooperation. > > > > - the http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE > > appears clearly biased towards GNOME, even though its URL and title > > suggest universality: the first substantial line talks about > > polkit-gobject-1 (I *think* that gobject means GNOME object) > > > > - in a well-constituted standards process (not a de facto standard), > > stakeholders are consulted before changes are made. It looks > > as if KDE folks have been stakeholders and have not been allowed to > > even sign-off on the design, let alone participate in it. > > > > - for good reason, the normal output of a standardization process is a > > document, not code. There appears to be no complete documentation. > > > > - all stakeholders ought to be treated respectfully and equitably. > > That means, for example, KDE ought not the be second to GNOME. > > More particularly, the architectures should be open-ended, allowing > > for more than KDE and GNOME. See, for example, > > http://c2.com/cgi/wiki?ZeroOneInfinityRule > > > > I admit that my reactions may be ill-founded. Perhaps this is meant > > You are attempting to create problems here which don't exist. David > has already pointed out in another mail that if apps don't want to use > the glib based library, they can talk to DBus directly. There are native > QT bindings for DBus, and pretty much any other language can talk to > DBus too with no deps on glib / gobject. Seems like direct DBus communication is the only way to do it from Qt/KDE apps as PolKit library requires gtk_init() somewhere in code... I've prepared patch for polkit-qt to the new PK1 Core API but... Or is there any other way to initialize glib without need for it? I'm not familiar with GTK app development... But library that expects gtk_init somewhere in application to be correctly intialized... PK1 should be split into parts - cross-desktop backends should be on freedesktop, gnome specific libraries should be in gnome repository. This should stop confusion. Jaroslav > Daniel > -- > > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ > |: :| http://libvirt.org -o- http://virt-manager.org -o- > |: http://ovirt.org :| http://autobuild.org -o- > |: http://search.cpan.org/~danberr/ :| GnuPG: 7D3B9505 -o- F3C9 553F A1DA > |: 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Sunday 24 May 2009 00:33:09 Kevin Kofler wrote: > Jaroslav Reznik wrote: > > How long old PK will be shipped in Fedora? > > Shipping old PolicyKit won't really help, as PackageKit etc. are all going > to get ported to the new one. The only reasonable thing to do is to BLOCK > the upgrade until it can be supported cross desktop. Kevin, I know but it can add some time for us. Jaroslav > I'm really fed up of > having to play catch up with supposedly "shared" technologies getting > upgraded under us without anybody talking to KDE upstream or to us > (Fedora's KDE SIG) about the schedule. The PolicyKit-kde developer even > WANTS to support the new version, but he didn't get the documentation he > needs for that (and asked for weeks ago)! (Lack of documentation is a real > issue for this stuff. When I did the KDM ConsoleKit patch, I had to look at > source code, both of ConsoleKit and of GDM, to figure out what the heck was > going on.) > > Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit changes in F12
On Sunday 24 May 2009 04:26:10 Matthias Clasen wrote: > On Sun, 2009-05-24 at 00:33 +0200, Kevin Kofler wrote: > > Jaroslav Reznik wrote: > > > How long old PK will be shipped in Fedora? > > > > Shipping old PolicyKit won't really help, as PackageKit etc. are all > > going to get ported to the new one. The only reasonable thing to do is to > > BLOCK the upgrade until it can be supported cross desktop. I'm really fed > > up of having to play catch up with supposedly "shared" technologies > > getting upgraded under us without anybody talking to KDE upstream or to > > us (Fedora's KDE SIG) about the schedule. > > The feature page has been out there for all to read for months. Yes, it was - but this is first visible activity with actual results - existing code etc. as I know (sorry if it's not true). > It took me a couple of evenings to write patches for the majority of > polkit users in gnome, so I assume it should be possible to do the same > for KDE. It is probably even easier, since you have those fabulous > abstraction layers on top of all the 'shared' technologies... Currently it's using polkit-grant and that seems it's not ported to new API yet. Could you take a look to code and suggest us right way to port it? Every help/ideas are appreciate. I'll try to look into deeper and I hope we can do it until Fedora 12 is released. It lies in http://websvn.kde.org/trunk/kdesupport/polkit-qt/ and http://websvn.kde.org/trunk/KDE/kdebase/workspace/PolicyKit-kde/ Upstream is currently considering writing on pure DBUS implementation even own backend. I hope I can join it and try to help. Main problem is it took some time for PolKit to be accepted by KDE and it's 4.3 feature and it's now beta (and as KDE has very strict freezes). Now there are big API changes and it misses KDE release - it's a work for 4.4 - so next year :( > > The PolicyKit-kde developer even > > WANTS to support the new version, but he didn't get the documentation he > > needs for that (and asked for weeks ago)! > > I see a single mail by Dario on the PolicyKit mailing list before the > one that you consider as 'mounting frustration'. Admittedly, it didn't > get a reply, but it was a very general 'lets work together' mail, not > asking concrete questions about missing documentation. > > As we all know, writing documentation is hard. The current 'porting > guide' is the result of Richard and me writing patches to port a bunch > of apps to the new PolicyKit, and is really just a collection of notes > taken while hacking. > > I propose that the best way to improve the docs is to ask concrete > questions on the mailing list. I've pointed Dario to this thread. We're in close contact, so I can try to cooperate this efforts as it should be cross desktop one. Feel free to contact me. Complaining don't help - actual code yes ;-) > > > Matthias Thanks Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
