Orphaned packages
Hello, the following packages have been orphaned and require a primary maintainer. Feel free to take them over Add64 aj-snapshot ambdec dssi dssi-vst gluidsynth fluidsynth-dssi freq-tweak fst giada gnome-guitar harmony-seq hexter-dssi jackctlmmc jmeters ladish libinstpatch lv2-artyfx-plugins lv2-avw-plugins lv2-c++-tools lv2-fabla lv2-fomp-plugins lv2-mdaEPiano lv2-mdala-plugins lv2-newtonator lv2-sorcer lv2-swh-plugins lv2-triceratops lv2-vocoder-plugins lv2-x42-plugins meterbridge mxml nekobee-dssi non-daw non-session-manager portmidi radium-compressor realTimeConfigQuickScan seq24 soundtracker whysynth-dssi xsynth-dssi regards Brendan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: orphaning all my packages
On 26/04/16 13:16, François Cami wrote: > Hi, > > I've ack'ed all the requests and orphaned the rest of my packages. > > Please note that this is due to a chronic lack of free time and has > nothing to do with Fedora itself. You are a wonderful community :) > > All the best, > François > Thanks for your contributions! It is well appreciated -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
On 15/02/16 07:46, Orcan Ogetbil wrote: The new version of qjackctl, which now depends on qt5. We cannot do the update without fixing this. As far as I can tell, the qjackctl does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags come through qmake. Other than this the new qsynth also has the same issue when built with autotools. Fortunately, qsynth provides an alternative cmake build system which doesn't call qmake. We were able to build qsynth with that one. I don't know any other examples but I suspect any package using qmake-qt5 could have this problem. This also affects qtractor B -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Staled build
On 25/11/15 04:25, Dmitrij S. Kryzhevich wrote: Hi! I have an issue with building a package under arm arch [1]. i686 and x86_64 builds completed with no errors but not arm. It is running (or staled) already more then for 10 hours. The question: could I somehow investigate what going on there? And how (if yes)? I have no arm machine to run this build directly. Dmitrij [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=701204 I experienced the same thing yesterday. Looks like the stall happens after the build phase (which only took half an hour). It actually completed after 14 hours after that. https://koji.fedoraproject.org/koji/taskinfo?taskID=11962048 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Comps group for Fedora Audio Spin packages
Hi all, does anyone have any objection to a new comps group containing packages currently present in the Fedora Jam audio spin? We will be discussing names further within the music creation SIG / fedora-music mailing list soon, but Audio Production or Music Creation are two that immediately spring to mind. Suggestions welcome. regards Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 01/31/2014 12:28 PM, Ian Malone wrote: On 30 January 2014 23:07, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/29/2014 07:10 PM, Ian Malone wrote: On 29 January 2014 23:58, Josh Boyer jwbo...@fedoraproject.org wrote: I consider myself squarely in the middle of those two camps. I think they have value to people. I think they fill a niche, however large or small it might be. I also think they can be done by the people wishing to provide them without relying on Fedora resources for hosting and creation (outside of leveraging existing packages and repositories). I don't consider that getting rid of them at all. On the contrary, I think it lets people have more control over their spins, allows them to refresh them as they see fit throughout the release, and allows them to market and promote them beyond a token mention on a Fedora website. Some care is needed, if there are things getting packaged to fill a role in a spin they may disappear from Fedora if the spin in question does. On one hand, I am impressed by many spins as an excellent technology demonstration. On the other hand, what should existing users of a base Fedora do if they find an useful spin with a superior functionality? If its function is not integrated and easily accessible from the base system, they must either dual-boot or re-install from the spin. Therefore I prefer that the spins ultimate goal is to include the functionality into generic Fedora. The same goes for other bundling schemes discussed here. It's not that I object to them per se, but I do think that there's an opportunity cost involved: the person caring about the spin has to chose between working on integrating the spin functionality in generic Fedora, and developing the spin separately. I do recognize that the former is harder, but the opposite tack has a potential to fragment Fedora. Spins should be like branches in a VCS: let's not turn them into forks. I think the strength of Fedora comes from it being an excellent platform for all kinds of FOSS software, and the associated network effect---the better the platform is, the faster it gets better. Spins is a loaded term in Fedora that means exactly what you suggest. An approved Spin, by definition, must only include packages (and functionality) that is contained in the generic Fedora repositories. So the project seems to very much agree with you. Remixes can contain external packages and have the pluses and minuses that you highlight. Some of the discussion to date has been suggesting or implying that Spins become Remixes, but I think that things that are already Spins would likely retain the qualities you desire. The discussion has a lot of tribal knowledge behind it, so if you aren't overly familiar with the history behind these concepts I can see how it would be confusing. Indeed what Przemek Klosowski described (forking fedora) is what making all spins remixes might do. Concrete example: real-time audio. If left to its own devices a music production spin would probably do a realtime kernel and set priorites for jack on its own. However since whatever change was made had to apply to all fedora the result was that the default RT priority for jack was changed in the package (a realtime kernel not being necessarily required http://jackaudio.org/realtime_vs_realtime_kernel), so all Fedora JACK users get a better chosen default (though they still need to make manual changes to groups to benefit from it). I can certainly see the benefits of forking in the domain of audio. However I would also be a little concerned that maintainers of said spins, might just stop bothering to package new audio software in upstream Fedora repositories at all. If they are going to the trouble of of hosting there spins, I can't see why they wouldn't just host there own packages as well (with custom compiler flags and whatever). I'd worry that this is going to result in a poorer quality audio experience in Fedora (for example have those nice arch guys come along and provide patches to audio software that doesn't build). Who's going to do that on 3rd party repos? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Disabling ABRT?
On 12/28/2013 10:48 PM, Richard Fearn wrote: Hi, On 28 December 2013 21:29, Brendan Jones brendan.jones...@gmail.com wrote: I'm doing some development at the moment and I want the coredumps to be dropped somewhere sane (like the executing directory). How do I do it? I think you want to do: $ sudo systemctl stop abrt-ccpp Before: $ cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e i.e. send core dumps to abrt. After: $ cat /proc/sys/kernel/core_pattern core $ cat /proc/sys/kernel/core_uses_pid 1 i.e. write core dumps to files named core.xxx. Regards, Rich Thanks. I had tried this but still no core in the executing directory. Now I'm not sure where they are going - certainly nowhere in $HOME. Its a difficult program to debug (an audio plugin kicked off by a host program) but I seem to have fixed the problem so it's no longer gracelessly crashing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Disabling ABRT?
On 12/29/2013 05:37 PM, Jan Kratochvil wrote: On Sun, 29 Dec 2013 13:17:49 +0100, Richard Fearn wrote: On 29 December 2013 11:29, Brendan Jones brendan.jones...@gmail.com wrote: Thanks. I had tried this but still no core in the executing directory. Now I'm not sure where they are going - certainly nowhere in $HOME. Could be a couple of things: 1. The core dump limit for the process could be 0 (i.e. don't write core dumps). 2. The core dumps are written to the cwd of the process at the point where it dies - not necessarily where you run it from. (If you know the PID you could check /proc/pid/cwd.) That is ABRT running/not-running should not have any effect on the normal 'ulimit -c' behavior. It was filed for ABRT and fixed in 2009: https://bugzilla.redhat.com/show_bug.cgi?id=530637 If stopping/starting ABRT changes anything - that is ABRT behavior is not fully transparent - it is a new ABRT bug. Jan Yup. Thanks guys. ulimit -c was 0 ulimit -c unlimited Fixes my problem. Cores created in the cwd. I would have thought that this should be enabled by default in /etc/security/limits.conf in the absence of abrt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Disabling ABRT?
I'm doing some development at the moment and I want the coredumps to be dropped somewhere sane (like the executing directory). How do I do it? Cheers B -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/11/2013 11:00 PM, Kevin Kofler wrote: Brendan Jones wrote: What is the best way to handle this case: qWarning(QObject::tr(Client name '%1' occupied.).arg(name).toUtf8()); something like, or can I make it simpler: qWarning(%s,qPrintable(QObject::tr(Client name '%1' occupied.).arg(name).toUtf8())); Use one of: qWarning() QObject::tr(Client name '%1' occupied.).arg(name); or: qWarning(%s, QObject::tr(Client name '%1' occupied.).arg(name).toLocal8Bit().data()); Note that hardcoding toUtf8() is also a bad idea here, the right encoding to use is toLocal8Bit(), or this will print junk in non-UTF-8 locales. (In our default UTF-8 locales, it will make no difference.) Kevin Kofler Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 08:11 PM, Kevin Kofler wrote: Adam Jackson wrote: On Fri, 2013-12-06 at 02:21 +0100, Kevin Kofler wrote: QString line; line.fill( '-', 60 ); qDebug( line.ascii() ); As you can see, the format string being passed here is provably constant. So fix the compiler. I don't think GCC will ever be able to prove that it is a constant. It would at least have to do intermodule inlining on the linked qstring.o to do that, which means qt3 would have to use the LTO support. Even then, I wouldn't count on it. Plus, if this construct were found in application code rather than in qt3 itself, GCC would even have to do the intermodule inlining on libqt-mt, which would also have negative consequences on binary compatibility. But knowing the contract of QString (Qt 3's in this case, but it's the same in Qt 4 and Qt 5), it's trivial for a human to prove it. Kevin Kofler What is the best way to handle this case: qWarning(QObject::tr(Client name '%1' occupied.).arg(name).toUtf8()); something like, or can I make it simpler: qWarning(%s,qPrintable(QObject::tr(Client name '%1' occupied.).arg(name).toUtf8())); regards Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 11:30 AM, Adam Williamson wrote: On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there. What world are you living in? gcc fixes have always been fixed in Fedora first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:25 PM, Brendan Jones wrote: On 12/06/2013 11:30 AM, Adam Williamson wrote: On Fri, 2013-12-06 at 10:37 +0100, Ralf Corsepius wrote: On 12/05/2013 07:43 PM, Jan Lieskovsky wrote: From: Ralf Corsepius Would you mind to explain why you guys are putting such an emphasize on -Wformat-security? Some possible ways how to look at it: * because when all reported packages are patched, it would remove one whole class of security flaws, Iff the tools being utilized were reliable and if the findings are fixed by skilled people, who really understand what they are doing. Both does NOT APPLY in Fedora. Fedora/RH's GCC produces false diagnoses and the average Fedora packager is not an experienced C-developer. The intent is not for Fedora packagers to patch problems downstream, it is for them to report bugs upstream and have the problems fixed there. What world are you living in? gcc fixes have always been fixed in Fedora first. Please ignore all my replies in this thread. I am just busy and annoyed. This came at the wrong time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/06/2013 12:59 PM, Dhiru Kholia wrote: On 12/04/13 at 07:10pm, Brendan Jones wrote: This is just a pain. Can someone explain to me why this is good? Original Message Subject: [Bug 1037125] hydrogen FTBFS if -Werror=format-security flag is https://bugzilla.redhat.com/show_bug.cgi?id=1037125 Hi Brendan, Can you *really* pass a QByteArray object directly to printf (and similar functions)? I have attached a patch to fix this FTBFS bug. I can't say if the fix is right (I don't know the code in question). Please give it a thought. ... I had originally planned on submitting patches too but I got caught up in a new project of mine. -- Dhiru Point taken. 10 FTBS's just makes my brain explode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/05/2013 03:25 AM, mrnuke wrote: On 12/04/2013 12:10 PM, Brendan Jones wrote: This is just a pain. Can someone explain to me why this is good? Good or not, this is not the right question to ask. * Is this necessarry, and are the benefits worth the pains? * This change is Sofa King stupid. Why couldn't we have just enabled the warning without turning it into an error, THEN let packagers work with upstream in fixing those warnings? Regulate, not ban. Alex Agree. Failing on this warning IS stupid. We are trying to exclude developers from Fedora? Trivial to fix sure, but surely there is better use of our time. I would much rather spend time on fixing real bugs with upstream than this -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FTBFS if -Werror=format-security flag is used
This is just a pain. Can someone explain to me why this is good? Original Message Subject: [Bug 1037125] hydrogen FTBFS if -Werror=format-security flag is used Date: Wed, 04 Dec 2013 11:33:47 + From: bugzi...@redhat.com To: brendan.jones...@gmail.com https://bugzilla.redhat.com/show_bug.cgi?id=1037125 Dhiru Kholia dkho...@redhat.com changed: What|Removed |Added Blocks||1038083 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1038083 [Bug 1038083] tracker bug for -Werror=format-security change -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/04/2013 07:29 PM, Daniel P. Berrange wrote: On Wed, Dec 04, 2013 at 07:10:39PM +0100, Brendan Jones wrote: This is just a pain. Can someone explain to me why this is good? If you read the bug description you'll see the link which answers your question. https://fedoraproject.org/wiki/Format-Security-FAQ Daniel I'm sorry, but I can't see why any of my packages (10+) are at risk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/04/2013 07:59 PM, Rahul Sundaram wrote: Hi On Wed, Dec 4, 2013 at 1:45 PM, Brendan Jones wrote: I'm sorry, but I can't see why any of my packages (10+) are at risk This is just a best practice to mitigate any risks that might exist just like any of the other security improvements we make from time to time. Even if you don't see any immediate benefits, there is no harm in following the appropriate guidelines here. Coordinate with upstream Rahul Overkill if you ask me, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/04/2013 09:39 PM, Rahul Sundaram wrote: Hi On Wed, Dec 4, 2013 at 3:05 PM, Brendan Jones wrote: Overkill if you ask me, It might be appear to be one till it ends up avoiding or mitigating a security issue. It is just a bunch of trivial changes and I am sure you can ask for help for patches if needed. Rahul Patching is not a problem. Unnecessary is the question. Explain to me (not you in particular Rahul) how these printf's can possibly be exploited? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/05/2013 12:11 AM, Ian Pilcher wrote: On 12/04/2013 04:56 PM, Brendan Jones wrote: Patching is not a problem. Unnecessary is the question. Explain to me (not you in particular Rahul) how these printf's can possibly be exploited? char *output; output = get_user_input(...); printf(output); What happens when the user enters %n? I remain unconvinced. Exploit my system with one of ams, aubio, hydrogen, jack-keyboard, phasex, portmidi or yoshimi. I just can't see it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On 12/05/2013 12:28 AM, Miloslav Trmač wrote: On Thu, Dec 5, 2013 at 12:11 AM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/05/2013 12:11 AM, Ian Pilcher wrote: On 12/04/2013 04:56 PM, Brendan Jones wrote: Patching is not a problem. Unnecessary is the question. Explain to me (not you in particular Rahul) how these printf's can possibly be exploited? char *output; output = get_user_input(...); printf(output); What happens when the user enters %n? I remain unconvinced. Exploit my system with one of ams, aubio, hydrogen, jack-keyboard, phasex, portmidi or yoshimi. I just can't see it Suppose I create a malicious drumkit and either get it uploaded to one of the officially recommended links at http://www.hydrogen-music.org/hcms/node/16 , or even just attach it in bugzilla to a bug report saying that the Fedora hydrogen package crashes or otherwise mishandles that file (causing _you_ personally to open that file, even if in a debugger)? Note that I _don't really know_ whether this is exploitable with hydrogen; though the incorrect format strings being in a class named Object does suggest that the affected input paths may be pretty widespread. Probably a bad example. I guess its another case of educating upstream. They love that -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: hardlink command
On 11/10/2013 09:07 PM, Sergio Belkin wrote: hardlink -n -v -v I would look at the modification datetime. studiodesktop:/tmp $ echo test test1 (wait at least a second) studiodesktop:/tmp $ echo test test2 studiodesktop:/tmp $ hardlink -n -v -v tes* Directories 0 Objects 2 IFREG 2 Comparisons 0 Would link 0 Would save 0 studiodesktop:/tmp $ cp -rp test1 test2 studiodesktop:/tmp $ hardlink -n -v -v tes* Would link test1 to test2, would save 5 Directories 0 Objects 2 IFREG 2 Comparisons 1 Would link 1 Would save 4096 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap
On 10/25/2013 04:12 PM, Darryl L. Pierce wrote: On Thu, Oct 24, 2013 at 07:40:59AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 23, 2013 at 11:34:23AM -0400, Darryl L. Pierce wrote: I have a package review (BZ#1022584:Review Request: qpid-qmf - The QPID Management Framework). I pulled the subpackages from qpid-cpp relating to QMF so they can built completely separate from Qpid. I'll take this one. I'm looking for reviewers for Bug 1016677 - Review Request: mathjax - JavaScript library to render math in the browser Bug 1021164 - Review Request: general-purpose-preprocessor - Customizable language-agnostic preprocessor Danga, you and Brandon beat me to the punch for swapping reviews! Sorry, Darryl. Didn't mean to hijack your request! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap
On 10/24/2013 07:40 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 23, 2013 at 11:34:23AM -0400, Darryl L. Pierce wrote: I have a package review (BZ#1022584:Review Request: qpid-qmf - The QPID Management Framework). I pulled the subpackages from qpid-cpp relating to QMF so they can built completely separate from Qpid. I'll take this one. I'm looking for reviewers for Bug 1016677 - Review Request: mathjax - JavaScript library to render math in the browser Bug 1021164 - Review Request: general-purpose-preprocessor - Customizable language-agnostic preprocessor Zbyszek I'll take these for: https://bugzilla.redhat.com/show_bug.cgi?id=1006187 and https://bugzilla.redhat.com/show_bug.cgi?id=1015958 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
On 09/27/2013 12:24 PM, Richard Hughes wrote: In GNOME Software, we show a list of applications for each category that we think are frikin’ awesome. Some have AppData[1], and some don’t. For the ones that don’t yet have AppData it leaves the responsibility of writing the long description to the Linux community, where we can push the data back to upstream so that all the distributions can benefit. So far we’ve had a superb reaction from lots of upstream projects and a lot of descriptions have been merged. For Fedora 20 we want all the awesome apps to have AppData, so users can evaluate the application before installing it. It would add a really nice bit of polish to the whole experience. If you can spare 5 minutes and want to help. I’ve got another shared document that just needs a few details for each application: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdElaYUoxcXRxeVRVS05Femg4Zzk2NWc#gid=0 The list of awesome-but-unloved apps is: audacity, ardour2, gnome-banshee, rosegarden, sound-juicer, doom, openarena, xonotic, tremulous, btanks, frozen-bubble, quadrapassel, neverball, gnomine, wesnoth, supertuxkart, redeclipse, lyx, gparted, virt-manager, eclipse, gitg, monodevelop, blender, shotwell, octave, saoimage, workrave, celestia, polari, pidgin, chromium, pitivi, vlc and openshot. I've submitted a patch for rosegarden submitted upstream. regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The final push for the application installer in Fedora 20
On 09/30/2013 08:42 AM, tim.laurid...@gmail.com wrote:
vlc is not part of fedora, cause of patent related stuff, not a legal
expert, but I dont think fedora cant contain somethng there links to
these kind of applications
If you create a new kind of application metadata, would it not be a good
idea to start using the information we allready have in the .spec files
and build from that
instead of starting from scratch, it is better than no information at all
Tim
The following query will build a template (it assumes the package name
is the same as the desktop file name).
#!/bin/bash
echo `rpmquery $1 --qf ?xml version=1.0 encoding=UTF-8?\
applicationid type=desktop$1.desktop/id\
licenceCC0/licencename$1/namesummary%{SUMMARY}/summary\
description%{DESCRIPTION}/description\
url type=homepage%{URL}/url\
screenshotsscreenshot type=default width=800
height=600/screenshot\
/screenshots/application`
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swaps
Hey all, some more lv2 audio plugins up for review: https://bugzilla.redhat.com/show_bug.cgi?id=1006187 https://bugzilla.redhat.com/show_bug.cgi?id=1004231 thank you Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swaps: xfoil, xrotor, avl
On 09/12/2013 09:36 PM, Sandro Mani wrote: Okay. So I'll take those newly updated: avl and xrotor. Thanks Antonio, let me know if I can review anything in exchange. Btw, you will notice that they are all very similar, so if you manage those two, xfoil should be just as easy ;) Sandro I can take it now for: https://bugzilla.redhat.com/show_bug.cgi?id=1003768 Let me know. cheers bsjones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
snip On the other hand some projects might benefit from stable Ring0, 1, which wouldn't change unexpectedly. No one said that stuff should change unexpectedly (and that's not what currently happens either). Beg to differ. There are lots of asynchronous dep changes (typically version upgrades) in the current monolithic ring of Fedora that can wreak havoc in dependent projects. At least in the Java space. Actually its the opposite you want to consider the whole picture when doing changes and not think of independent pieces stuck together. The whole picture is *really* big and often internally has competing interests. I can envision oversight and policy implementation in the Ring/SIG model however. That's why the lets build some core platform and put stuff on top of it is flawed. I'm sorry but I can't agree that software layering is somehow inherently flawed. It's not flawed by design, but it's flawed by implementations. At least in the Java stack (you mentioned) as is currently this is entirely impossible. The Java stack is all or nothing - e.g. let's assume that ant is part of the ring1 as critical build infrastructure, but it depends on apache-commons-*, which build via maven, which depends on many (just to list a few - jetty, tomcat, plexus, aether, sisu), plexus brings jdt.core , aether brings tycho, tycho depends on eclipse platform and few other plugins, eclipse itself has a number of dependencies and so on so on. In short all or nothing :). I would love to see things layered but unless someone throws in enormous resources to cut all the circular dependencies this can't happen. Alexander Kurtakov Red Hat Eclipse team Is it even feasible to use the Fedora Java/JBOSS stack unless you are an existing customer? I gave up on Fedora java packages a long time ago. That's not to say Fedora is bad in this respect, but more that you can't please everyone -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
On 07/23/2013 08:38 PM, Matthias Clasen wrote: I've found it very hard to find the right place to jump into this discussion. So, I'll just put out some of my own thoughts about what I want to see out of Fedora, and then point out how I think this matches or contrasts with Matts proposal. Fedora should be an *OS*. Here are some of the qualities that I associated with that term: - It has a clearly defined boundary, with stable APIs. Some things are not going to be part of the OS, even though they are part of the Fedora universe: for example, applications. Stable is important; if you can't upgrade from version x to version x+1 and keep installed applications working, it is not an OS, imo. And it will never be attractive to anybody outside the Fedora packager community to do something with Fedora or build something on it, if there is no assurance that it continue working beyond the 6 month (or 13 month) horizon of the Fedora schedule. - The purpose of the OS is to run applications. So, it needs to be provide a way to install, update and run applications. We obviously support this now, in a way. But we need to get a lot better (see the AppInstaller proposal). The big is that many apps are simply not available on Fedora, because packaging is not something that is interesting for many people, and mostly a wasted effort from the perspective of the app developer (see the previous point). - There need to be defined extension points for how you add new stuff to it that does not fit int the 'application' category. Things like codecs, translations, fonts, runtime environments. - It should provide a defined (or designed) user experience. It can of course provide more than one, depending on the context it is used in: client, server, cloud, etc. Also worth mentioning here is the runtime vs devel split. Ideally, there will also be a defined experience for developers, an SDK if you will. Thats enough blue sky vision for now. How does this match up with Matt's proposal ? The 'Base OS / ring 0 + 1' in the proposal could possibly match my idea of an OS as having clearly defined boundaries (core + standard is pretty clear as to whats in and whats out), but as far as API is concerned, it seems a little weak - I would expect most of the system services that we are relying on to be part of the core that needs to have a stable API: policykit, pam, logind, udisks, sssd, realmd, etc. Many of these probably get pulled in via dependencies. It would be better to list them explicitly, imo. There is a tension between defining a complete enough API, and going for a minimal platform that can accomodate the needs of e.g. cloud images. The question we should be asking is how Fedora being used in the wild? I am also hesitant to lax standards and to even consider bundled libs. If someone has a use case for it they will do it anyway. Packaging software in /opt is an alternative. Being a developer it happens to me time and time again and is always dependant on the client. What I love about Fedora is that it forces me to consider latest developments whereas a client may not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)
On 07/27/2013 12:36 PM, Michael Scherer wrote: Le samedi 27 juillet 2013 à 11:31 +0200, Brendan Jones a écrit : Is it even feasible to use the Fedora Java/JBOSS stack unless you are an existing customer? There is no customer for Fedora, so I am not sure to fully follow you. And last time I tested, ovirt was working on fedora, so jboss do work. Sorry if I was unclear. I pretty much never use fedora java packages when working on a solution for a client. I'd be glad to hear if it is easier these days. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/26/2013 01:47 AM, Lennart Poettering wrote: [1] Onsen, in Berlin-Friedrichshain (recommended) Hmmm I must try it. Hard to find real Japanese in this city. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/25/2013 10:36 PM, Bastien Nocera wrote: - Original Message - On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: Partially accepted Changes * No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html Sendmail will be removed from @core. Removal of sendmail from @standard didn't pass. Note: About @standard group might be decided in next release of Fedora. * No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html Remove rsyslog from @core, move to @standard pending revaluation in future. Note that this is not the decision I was interested in. I will hence not work on the implemetation of either of these features. Unless Matthew takes them over alone I will will mark these feature pages as obsolete as they didn't get agreed on. Taking rsyslog out of @core is a one-line commit to comps which someone could do in 30 seconds. It hardly needs 'working on'. Given the amount of time that he spent on the mailing-list fighting for those features, then it looks like a waste of time, that work has been done. Thankfully, it's been removed from the default Desktop spin. It all becomes moot when a FESCO decision can be completely ignored. My own opinions aside (I have a sendmail requirement but would not force it on anyone). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
On 07/25/2013 12:11 AM, Adam Williamson wrote: On Wed, 2013-07-24 at 16:50 +, Jóhann B. Guðmundsson wrote: On 07/24/2013 04:40 PM, inode0 wrote: On Wed, Jul 24, 2013 at 11:07 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: The entire budget is not public so you won't get a definitive answer for a large portion of the budget. Why is it not public any reason why we the community cannot know how much we cost? I don't think there's any particular reason, but one thing is that it's not particularly obvious even within Red Hat: there isn't a single nice clear Fedora Budget, money gets spent on Fedora out of all sorts of other budgets. It may well be the case that *Red Hat* does not know precisely how much money Red Hat spends on Fedora. :) I contribute regularly to opensource projects (monetarily) with no issue. While I take JBG's anti-RH implications with a grain of salt, he has highlighted a lacking there. It *should* be easier to contribute, although I cannot see this happening if Fedora is a legal entity resides state-side. To clarify, I think RH is an awesome sponsor, and the resources they provide do separate us from other distros, and for that I am grateful, BUT there needs to be another way to contribute -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
On 07/24/2013 03:50 AM, Jóhann B. Guðmundsson wrote: Earlier this evening I was asked how I expected Fedora to function in any way similarly to how it does now without the backing of one or more organizations like Red Hat. I gave the quick answer through donations since I was not in mood to give the detailed answers ( and taint that thread even further ) however I'm about do it here to certain extent since the questioner probably did not expect me to have actually given this any thought which I actually have although I have not chiselled it into stone, making it the concrete proposal the community demands since it's just a small fraction of a larger idea or rather vision I have but I have decide it be the correct time to share that part of that vision of mine with the rest of the community to gather feedback. Under the current model I thought it is not possible to make monetary donations to Fedora (I remember Jared Smith saying something about this at a linuxconf.au a while back) Hardware, physical items, consumable media etc is OK though. Something to do with US taxes, correct me if I'm wrong. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LXDE and Razor-qt
On 07/24/2013 04:53 AM, Christopher Meng wrote: Hi list, FYI, as this link[1] announced, 2 desktops have been merged into one. Razor-qt just got in Fedora in April, what shall we do next? Early days yet (nothing has been released as yet?), but I imagine it will be up to the current razorqt maintainer(s) to coordinate. Good news all in all I think. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
On 06/28/2013 03:32 PM, Philip Rhoades wrote: People, This command: yum groupinstall development-tools fails with these errors: Transaction Check Error: file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 Are there workarounds or fixes? Thanks, Phil. There's this bug https://bugzilla.redhat.com/show_bug.cgi?id=915247 You could --exclude=systemtap-sdt-devel* to get past it if you don't need this package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: audacity
On 04/30/2013 03:07 AM, Sérgio Basto wrote: On Dom, 2013-04-28 at 07:09 -0700, Richard Vickery wrote: For F18, it appears that the Audacity mp3 build is broken - it won't install - and mp3 support is rather important to me; is it possible to get this particular build working? What do you mean with Audacity mp3 build is broken , rpmfusion build are working , I think. At least is working Installed Packages audacious.x86_643.3.4-2.fc18 @updates audacious-devel.x86_64 3.3.4-2.fc18 @updates audacious-libs.x86_64 3.3.4-2.fc18 @updates audacious-plugin-fc.x86_64 0.6-19.fc18installed audacious-plugin-xmp.x86_64 3.4.0-12.fc18 installed audacious-plugins.x86_643.3.4-2.fc18 @updates audacious-plugins-amidi.x86_64 3.3.4-2.fc18 @updates audacious-plugins-freeworld.x86_64 3.3.4-1.fc18 @rpmfusion-free-updates-testing audacious-plugins-freeworld-aac.x86_64 3.3.4-1.fc18 @rpmfusion-free-updates-testing audacious-plugins-freeworld-ffaudio.x86_64 3.3.4-1.fc18 @rpmfusion-free-updates-testing audacious-plugins-freeworld-mms.x86_64 3.3.4-1.fc18 @rpmfusion-free-updates-testing audacious-plugins-freeworld-mp3.x86_64 3.3.4-1.fc18 @rpmfusion-free-updates-testing audacious-plugins-jack.x86_64 3.3.4-2.fc18 @updates Thats audacious rather than audacity -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: audacity
On 04/29/2013 08:39 PM, Richard Shaw wrote: I just packaged soxr... Anyone willing to review if I submit a review request? Thanks, Richard Sure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rewiew swaps: 4 packages
On 04/21/2013 01:43 PM, Eugene Pivnev wrote: Still looking for 3 review swaps: https://bugzilla.redhat.com/show_bug.cgi?id=947049 - qxkb (keyboard switcher; trivial review) https://bugzilla.redhat.com/show_bug.cgi?id=952632 - qtermwidget (terminal widget; trivial review) https://bugzilla.redhat.com/show_bug.cgi?id=953101 - RazorQt (new fast gtk- and kdelibs-independent DE) All of them are qt-based and C++. I'll take these. I'll let you know when I have something to review. regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On 02/14/2013 04:26 AM, Bruno Wolff III wrote:
On Wed, Feb 13, 2013 at 21:21:41 -0500,
Orcan Ogetbil oget.fed...@gmail.com wrote:
If the esound or pulseaudio plugins are problematic, let us retire
them. I don't think xmms will be used by other people than us fanboys,
and I feel that we are fine with the ALSA output.
Anyhow it looks like spot was kind enough to pick it up, so no worries :)
I was still planning on retiring xmms. It has no upstream support. The
volume control has issues that I don't have time to figure out.
esound can be disabled at build time - please do not retire it just yet.
I can take it on if need be.
Orcan, can you confirm that it still works? This is not working for me here.
http://koji.fedoraproject.org/koji/taskinfo?taskID=4971729
--- xmms.spec 2013-02-14 11:40:18.021243517 +0100
+++ /home/bsjones/rpmbuild/SPECS/xmms.spec 2013-02-14 11:39:42.377244852
+0100
@@ -1,6 +1,6 @@
Name: xmms
Version:1.2.11
-Release:17.20071117cvs%{?dist}
+Release:18.20071117cvs%{?dist}
Epoch: 1
Summary:The X MultiMedia System, a media player
@@ -70,14 +70,6 @@ Group: System Environment/Libra
%descriptionlibs
The X MultiMedia System player engine and core plugins.
-%packageesd
-Summary:EsounD output plugin for XMMS
-Group: System Environment/Libraries
-Requires: %{name}-libs = %{epoch}:%{version}-%{release}
-
-%descriptionesd
-EsounD output plugin for the X MultiMedia System.
-
%packagedevel
Summary:Files required for XMMS plug-in development
Group: Development/Libraries
@@ -130,7 +122,8 @@ done
--enable-texthack \
--enable-ipv6 \
--with-pic \
---disable-static
+--disable-static \
+--disable-esd
# causes problems with dso linking
#find . -name Makefile | xargs sed -i -e s/-lpthread//g # old libtool,
x86_64
make
@@ -212,10 +205,6 @@ update-desktop-database /dev/null || :
%{_libdir}/xmms/Output/libdisk_writer.so
%{_libdir}/xmms/Visualization/
-%files esd
-%defattr(-,root,root,-)
-%{_libdir}/xmms/Output/libesdout.so
-
%files devel
%defattr(-,root,root,-)
%{_bindir}/xmms-config
@@ -226,6 +215,9 @@ update-desktop-database /dev/null || :
%changelog
+* Thu Feb 14 2013 Brendan Jones brendan.jones...@gmail.com
1.2.11-18.20071117cvs
+- Disable esound plugin
+
* Sun Jul 22 2012 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 1:1.2.11-17.20071117cvs
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On 02/14/2013 06:16 PM, Lennart Poettering wrote: On Thu, 14.02.13 03:26, Dan Mashal (dan.mas...@gmail.com) wrote: Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility. That's the spirit! I don't know too much about it, but I want to maintain it... Your arrogance never ceases to amaze. But anyway, if that is indeed your wish, then I can hand it over. But please, don't let this stuff bitrot forever. That would help nobody. If you want to take care of it, fine, but please make sure the remaining packages using it get their stuff updated and fixed... I'm sure the new maintainer can handle the dependencies -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [soundtracker/f18] (2 commits) ...Correct desktop file install error
On 02/11/2013 10:16 AM, Mamoru TASAKA wrote: Brendan Jones wrote, at 02/11/2013 05:22 PM +9:00: Summary of changes: faf3146... Remove vendor from desktop file (*) 330426b... Correct desktop file install error (*) (*) This commit already existed in another branch; no separate mail sent No, removing vendor prefix from desktop file must only on F-19, not on stable release (on F-18, F-17). Please revert this, thank you. Regards, Mamoru Why is that, it can't hurt can it? I didn't think the vendor was in use at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: review swap: rubygems related packages
On 01/31/2013 01:32 PM, Mamoru TASAKA wrote: Hello, all: I have some packages related to rubygems ready for review and I would like to swap reviews. Each package is small and should not take so much time. rubygem-levenshtein https://bugzilla.redhat.com/show_bug.cgi?id=891970 rubygem-gobject-introspection https://bugzilla.redhat.com/show_bug.cgi?id=892163 rubygem-net-http-digest_auth https://bugzilla.redhat.com/show_bug.cgi?id=892313 rubygem-unf_ext https://bugzilla.redhat.com/show_bug.cgi?id=892314 rubygem-webrobots https://bugzilla.redhat.com/show_bug.cgi?id=892315 rubygem-unf - depends on rubygem-unf_ext https://bugzilla.redhat.com/show_bug.cgi?id=904639 rubygem-domain_name - depends on ruby-unf, so also depends on rubygem-unf_ext https://bugzilla.redhat.com/show_bug.cgi?id=904640 rubygem-ruby-ntlm https://bugzilla.redhat.com/show_bug.cgi?id=904707 Regards, Mamoru I also have a number up for review. I am familiar with ruby, so pick from this list. The weekend is out for me, so will action most on Monday if that is OK. http://lists.fedoraproject.org/pipermail/devel/2013-January/177115.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
On 01/29/2013 07:59 AM, lakshminaras2...@gmail.com wrote: I am releasing ownership of the following packages due to lack of time gnome-guitar -- A small suite of applications for the guitarist I have taken this one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Audio plugins / utilities up for review swap
Hi all, I have the following outstanding packages ready to be reviewed. All are small and shouldn't be too taxing. radium-compressor - A Qt compressor with an intuitive GUI https://bugzilla.redhat.com/show_bug.cgi?id=904658 lv2-newtonator - an LV2 synth plugin that uses the physical principles of velocity and acceleration https://bugzilla.redhat.com/show_bug.cgi?id=887769 lv2-fomp-plugins - a colletion of LV2 plugins ported from LADSPA oscpack - A set of c++ classes https://bugzilla.redhat.com/show_bug.cgi?id=887750 python-mididings - a MIDI router and processor with python3 support https://bugzilla.redhat.com/show_bug.cgi?id=866183 regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help
On 01/19/2013 10:23 AM, ABHINAV MISRA wrote: i am Abhinav , an undergraduate from India i was going through GSoC 2012 idea list i want to take integrate proxy setting and network manager as my project for GSoC 2013. i know C, python and currently learning java and i am most wiling to learn anything that is required for this project. I wanted to take up this project in GSoC 2012. The main reason why I want to do this project is that it takes me hours of effort to get anything or change anything in Fedora 16 which requires Internet. As I have a proxy server at my college which requires authentication. Something like apply system wide option (available in Ubuntu) should be there in Fedora also. thanking you , Abhinav Misra Fedora has an ideas page that anyone can contribute to for consideration in the next GSOC program. Details here [1]. [1] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2013 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
On 01/09/2013 01:27 PM, Ian Malone wrote: On 9 January 2013 12:23, Ian Malone ibmal...@gmail.com wrote: Down-sides, there'd no longer be a live-cd/dvd as a 'demo' system. You could only try out the formula on an installed system. It looks though like people are already suggesting overlaying a formula somehow to create traditional live images (presumably still with the advantages of being able to tweak configuration). P.S. that downside also may translate to more difficult testing and development. With spin development I've been able to make a live cd and then run it live or run it live/install it within a VM. With a formula you have to have an already-installed image in a VM and then make the formula available for install within it. (Advantage though, compiling a formula *must* be quicker than rebuilding a live image.) Agreed to both your downsides. The goal of the spin was to have as much configured 'out of the box' in a live environment firstly then as the installed user. I can't see this as being a replacement but perhaps it could be used in this context as well (post install). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
On 01/08/2013 08:16 PM, Yannick Brosseau wrote: Hi, I have one pending package review that I would like to swap: babeltrace - Trace Viewer and Converter, mainly for the Common Trace Format (LTTng) https://bugzilla.redhat.com/show_bug.cgi?id=846488 Thanks, Yannick I'll take this if you can take this simple one on: https://bugzilla.redhat.com/show_bug.cgi?id=887756 Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
On 01/08/2013 09:15 PM, Kevin Fenzi wrote: Greetings. I've whipped up the early ideas of a way to replace (most) spins with something that is more generic and useful. I have signed up for a fudcon session to brainstorm on this idea and see if it can be beaten into a plan/schedule/feature, or if it's not going to work for whatever reason. I have a very brainstormy/draft wiki page outlining the idea at: https://fedoraproject.org/wiki/Fedora_formulas The short version: Setup a infrastructure/framework around a collection of ansible playbooks to allow our users to simply download a formula for what they want to do and have a curated setup made for them using Fedora packages. Want a electionics lab setup? download. review. answer some questions. click. Want a LAMP stack? download. review. answer some questions. click. Want a openstack demo cluster? ditto. Want a graphics designer workstation? ditto. Note that this assumes you have already installed Fedora, it's a post install setup. This would mean that we should continue to do spins for various desktops as people may way to install their desktop as a base before adding on formulas. Of course there's tons of details/questions to work out (many listed on the wiki page, but I'm sure there are more details too). So, what do folks think? Workable? Crazy? Crazy enough to work? :) kevin Most spins don't do anything really special apart from install a default set of packages. Maybe this is because of the limitations of kickstart, I don't know. Coming from the Fedora Audio spin here's a few things that we would like to achieve that we can (mostly) from a kickstart: - add default groups for the liveuser and logged in user - add extra kernel boot parameters (threadirqs) - custom desktop themes, favourites, and desktop settings (turning off desktop effects for example) - default autostart apps The main problem we have with kickstarts at the moment is that there is no way (according to current packaging guidelines) to alter files owned by other packages. In the future we might like to choose different pulseaudio modules to load, ALSA config based on hardware etc. I don't see how this solution could do this if it were RPM based. If is based as some kind of overlay that alters files owned by other packages post install then there needs to be an obvious indication that this has occurred. I'd expect that whoever writes such a formula would have to get sign off from the owner of the package whose files it modifies. We are working around this by developing an application which the user has to run and is prompted to confirm such changes. Such a program could be configured to run once at startup I guess. This is a work in progress and not in production yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
On 01/09/2013 05:10 AM, Brendan Jones wrote: On 01/08/2013 09:15 PM, Kevin Fenzi wrote: Greetings. I've whipped up the early ideas of a way to replace (most) spins with something that is more generic and useful. I have signed up for a fudcon session to brainstorm on this idea and see if it can be beaten into a plan/schedule/feature, or if it's not going to work for whatever reason. I have a very brainstormy/draft wiki page outlining the idea at: https://fedoraproject.org/wiki/Fedora_formulas The short version: Setup a infrastructure/framework around a collection of ansible playbooks to allow our users to simply download a formula for what they want to do and have a curated setup made for them using Fedora packages. Want a electionics lab setup? download. review. answer some questions. click. Want a LAMP stack? download. review. answer some questions. click. Want a openstack demo cluster? ditto. Want a graphics designer workstation? ditto. Note that this assumes you have already installed Fedora, it's a post install setup. This would mean that we should continue to do spins for various desktops as people may way to install their desktop as a base before adding on formulas. Of course there's tons of details/questions to work out (many listed on the wiki page, but I'm sure there are more details too). So, what do folks think? Workable? Crazy? Crazy enough to work? :) kevin Most spins don't do anything really special apart from install a default set of packages. Maybe this is because of the limitations of kickstart, I don't know. Coming from the Fedora Audio spin here's a few things that we would like to achieve that we can (mostly) from a kickstart: - add default groups for the liveuser and logged in user - add extra kernel boot parameters (threadirqs) - custom desktop themes, favourites, and desktop settings (turning off desktop effects for example) - default autostart apps The main problem we have with kickstarts at the moment is that there is no way (according to current packaging guidelines) to alter files owned by other packages. In the future we might like to choose different pulseaudio modules to load, ALSA config based on hardware etc. I don't This is probably not a good example as we could drop such config files in /etc/skel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/28/2012 08:25 PM, Peter Robinson wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. I know upstream is moving really fast these days, but I thinbk any risk is alleviated by Rex's backport - we can safely identify any showstoppers within a fedora release cycle. There's a working backport patch for a platform that isn't really supported in Fedora and it works on other virtual platforms without issue. While I would love to see 3.0 in Fedora 18 due to it's support for UCM which is used extensively in ARM I'm not even pushing it because I know it could break more than it might well fix. 1.1 for F17 is way to far behind IMHO given that upstream is now at 3.0. Why? it works and is relatively stable, there's a lot of change between 1.1, 2.0, 2.1 and 3.0 which could introduce any number of other bugs and regressions in a release that is suppose to be stable. Why? Upstream is now really active - insisting that they support software 2 major releases old is a bit much. If enough people are using rawhide and/or Rex's backport we should be able to keep close to upstream without risk. I think restricting ourselves to upstream major releases within the Fedora release cycle _becomes_ risky when we are so behind. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/28/2012 08:25 PM, Peter Robinson wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. I'm not suggesting we upgrade F18 now, but I think we should be open to the idea post release, and even for F17. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I know upstream is moving really fast these days, but I thinbk any risk is alleviated by Rex's backport - we can safely identify any showstoppers within a fedora release cycle. 1.1 for F17 is way to far behind IMHO given that upstream is now at 3.0. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/25/2012 10:50 AM, Julian Sikorski wrote: Dear list, Dear Lennart, a week ago I have submitted a pulseaudio bug alongside with the patch [1]. There was no response so far. Knowing that Lennart is busy with systemd these days, I proceeded to check the pkgdb status of pulseaudio. The only other maintainer with commit access is lkundrak, who has been declared non-responsive a while ago himself, plus 3 request pending. To have such a critical subsystem barely maintained does not seem sustainable. I have already stepped up to co-maintain pavucontrol and paprefs, but PA proper is a whole other level. I have joined the waiting list and am willing communicate the issues between Fedora and upstream, but someone with an ability to fix bugs on their own would be welcome too. Lennart, could you please look at the pending ACL requests? Thank you. Merry Christmas everyone, Julian [1] https://bugzilla.redhat.com/show_bug.cgi?id=888422 If you look at the build status you can see pulseaudio is hardly unmaintained. Rex Dieter has also provided a backport of the latest pulseaudio to use with early releases. I'm sure he is very amenable to cherry picking patches from a later release if it fixes a specific issue people may be having. http://repos.fedorapeople.org/repos/rdieter/pulseaudio-backport/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Oldest package review resolved
On 12/18/2012 01:21 PM, Mario Ceresa wrote: I deeply admire Lee's perseverance! My oldest was 3 years and I felt trapped in the Neverending Story :) Out of curiosity, could you post a link to the oldest one? Best, Mario What is truly amazing is that the submitter was FE-NEEDSPONSOR the whole time. Kudos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sound issues (Intel HD Audio) -- anyone else see these?
On 12/05/2012 10:56 AM, Mary Ellen Foster wrote: Hello all, I was just wondering if anyone else is seeing the problems I have on my laptop with system sounds being very delayed: https://bugzilla.redhat.com/show_bug.cgi?id=882506 Note that F17 on an identical laptop doesn't have these issues, so it definitely seems to be something F18-ish. The above bug is filed against pulseaudio, but I realise it could also be alsa or something else ... suggestions on debugging strategies are very welcome. We could try and find out if pulseaudio is the culprit by catching your logs. You can stop and start pulseaudio by hand: pulseaudio --kill pulseaudio --log-level=debug --log-target=file:/tmp/pa.log Alternatively you could add the same options to /usr/bin/start-pulseaudio-kde Attach the output to the bug. It does sound phonon related. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default grou membership for new users
On 12/05/2012 04:31 PM, Matthew Miller wrote: On Wed, Dec 05, 2012 at 03:55:17PM +0100, Christoph Wickert wrote: I am looking for a way how to add new users to a certain group upon creation. Do we have such a mechanism? [...] /etc/default/useradd only is for useradd and can set a default group, but no additional default groups. I was thinking one could extend shadow-utils so that supplementary groups are read from that file, but the problem is that you don't _really_ want the group added to every new user, just to actual human users, and figuring that out (even by something simple like when UID n) adds a layer of complication and fiddlyness that's probably not welcome. The spin owner had a dirty hack that modified /usr/share/firstboot/modules/create_user.py, but as the spins wrangler I told him this is a no-go. What about dropping a new module for audio configuration into firstboot? How would this work? (apologies if I don't know enough about firstboot here). I was thinking of parsing a simple parameter from the config file. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: review swap: SVNKit
On 11/25/2012 05:37 PM, Ismael Olea wrote: Anyone interested in a review swaping? Here is mine: https://bugzilla.redhat.com/show_bug.cgi?id=877403 -- Ismael Olea http://olea.org/diario/ I can take this on for giada - https://bugzilla.redhat.com/show_bug.cgi?id=866156 cheers Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with jack update
On 11/17/2012 09:42 AM, Ian Malone wrote: On 17 November 2012 03:09, Orcan Ogetbil oget.fed...@gmail.com wrote: On Fri, Nov 16, 2012 at 5:24 PM, Ian Malone wrote: On 15 November 2012 23:20, Ian Malone wrote: On 15 November 2012 04:40, Orcan Ogetbil wrote: Hi all, A few months ago earlier in the F-17 release cycle, we had a problem with jackd turning verbose, flooding the stdout, even when its verbosity was turned off. This was a bug [1] in the compiler, specifically in the optimized builds, for which we filed a bug against upstream gcc [2]. As a workaround we rebuilt jack unoptimized, and we have been using the unoptimized build since. Late in September the issue got resolved in upstream gcc (see [2]). [1] https://bugzilla.redhat.com/show_bug.cgi?id=827748 [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=362840 [4] http://oget.fedorapeople.org/jack/ Further the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663#c3 still fails on gcc-4.7.2-8.fc18.x86_64 for me (at -O1). You weren't running a patched gcc or something? No, it is the official gcc-4.7.2-2.fc17. You can see tho root.log in the above link [4] for my buildroot. One build is -9.1 and the other is -10, jack-realtime-compat.patch differs between the two. If its a compiler optimisation problem then the difference in initial variables may be causing a difference in behaviour? Just random speculation, on the basis that if the build systems are the same then something else must be the cause. Preferable to get the gcc fix though. Hi Ian, are you getting verbose output in the F18 builds of jack or not? regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps for Audio spin
Hi all I have a number of outstanding reviews that we are hoping to inlcude on the audio spin media. All are fairly trivial so shouldn't take too much time. giada - an audio looper for jack https://bugzilla.redhat.com/show_bug.cgi?id=866156 python-mididings - a MIDI router and processor in python/python3 https://bugzilla.redhat.com/show_bug.cgi?id=866183 drumkv1 - an LV2 / standalone sampler https://bugzilla.redhat.com/show_bug.cgi?id=870184 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps (on the road to scilab 5.4.0): scirenderer
On 10/29/2012 02:18 PM, Clément David wrote: Hi folks, Would anyone want to swap reviews? I need scirenderer[1] reviewed in order to update scilab to the latest (5.4.0) version. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=811661 Thanks, I can take this if you'd like to take on https://bugzilla.redhat.com/show_bug.cgi?id=865303 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi all I have a number of outstanding reviews that are available for swap. All are fairly trivial so shouldn't take too much time: ams - ALSA Modular Synth - a port from the CCRMA repo https://bugzilla.redhat.com/show_bug.cgi?id=866358 giada - an audio looper for jack https://bugzilla.redhat.com/show_bug.cgi?id=866156 rtaudio - a realtime audio library. Required by giada and chuck https://bugzilla.redhat.com/show_bug.cgi?id=866154 realTimeConfigQuickScan - an application to assess the realtime audio capabilities of a system https://bugzilla.redhat.com/show_bug.cgi?id=865303 python-mididings - a MIDI router and processor in python/python3 https://bugzilla.redhat.com/show_bug.cgi?id=866183 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help with review
On 10/08/2012 08:44 AM, Gianluca Sforna wrote: Hi, I have a package sitting in the review queue for a while: rdkit - A toolkit for cheminformatics and machine learning https://bugzilla.redhat.com/show_bug.cgi?id=804125 From a packaging standpoint it's an interesting piece, with different subpackages including a postgresql cartridge and python bindings. However, I believe it is fairly good already, so if you can help me getting it into Fedora I would really appreciate that, and of course can return the favor with one or more reviews. Thanks in advance Gianluca Hi Gain, do you still need this reviewed? If so , could you please take https://bugzilla.redhat.com/show_bug.cgi?id=866358 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers
On 10/03/2012 08:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis. The current list: I'm happy to (co)maintain the following. Where's there's a comaintainer I'll take it if they don't want ownership: fop -- XSL-driven print formatter comaintained by: sparks ladspa -- Linux Audio Developer's Simple Plug-in API, examples and tools libsamplerate -- Sample rate conversion library for audio data comaintained by: jwrdegoede lkundrak (peter?) meld -- Visual diff and merge tool comaintained by: cwickert padevchooser -- Control applet for PulseAudio pavumeter -- Volume meter for PulseAudio Username: bsjones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive pytrainer maintainer; anyone interested in the package?
On 09/18/2012 01:59 AM, Kevin Fenzi wrote: On Mon, 17 Sep 2012 11:28:07 +0200 Brendan Jones brendan.jones...@gmail.com wrote: On 09/17/2012 11:18 AM, Kalev Lember wrote: On 09/05/2012 07:02 PM, Kalev Lember wrote: The ticket for its non-responsive maintainer Douglas E. Warner is: https://bugzilla.redhat.com/show_bug.cgi?id=842894 All reasonable attempts to resolve this have failed. Douglas E. Warner confirmed in https://bugzilla.redhat.com/show_bug.cgi?id=842894#c2 that he currently doesn't have time for Fedora package maintenance. Can some FESCo member please look over this issue and orphan pytrainer, and possibly other Douglas E. Warner's packages as well? I've requested ACL's - if I can't fix it I'll orphan it I've approved your acls. kevin 1.9.1 pushed to rawhide,f18,f17 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive pytrainer maintainer; anyone interested in the package?
On 09/17/2012 11:18 AM, Kalev Lember wrote: On 09/05/2012 07:02 PM, Kalev Lember wrote: The ticket for its non-responsive maintainer Douglas E. Warner is: https://bugzilla.redhat.com/show_bug.cgi?id=842894 All reasonable attempts to resolve this have failed. Douglas E. Warner confirmed in https://bugzilla.redhat.com/show_bug.cgi?id=842894#c2 that he currently doesn't have time for Fedora package maintenance. Can some FESCo member please look over this issue and orphan pytrainer, and possibly other Douglas E. Warner's packages as well? I've requested ACL's - if I can't fix it I'll orphan it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Trade event] Swapping review
On 09/16/2012 08:38 PM, jonathan wrote: Dear, Mine review request list grow without get at anytime a review, i am looking a reviewer to push these packages into fedora. Thanks for your help: - Bug 813842 - Review Request: glfw , A cross-platform multimedia library - Bug 847794 - Review Request: gl3n An OpenGL Mathematics library for D - Bug 832953 - Review Request: Syntastic - A syntax checker for programming language in vim - Bug 848144 - Review Request: SDL2 A cross-platform multimedia library If you are interested to swap a review contact me. Thanks regards Hi I'll swap you 813842 for https://bugzilla.redhat.com/show_bug.cgi?id=857730! thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: guayadeque package review and bundled libraries
On 09/15/2012 08:00 PM, Martin Gansser wrote: I am working on a package preview for guayadeque https://bugzilla.redhat.com/show_bug.cgi?id=853553#c9 Brandon told me that i have to alk the devel list regarding 'bundled libraries' It seems that the guayadeque sources contains some bundled libraries, wxsqlite and wxcurl (wxMD5?). has the code submitted as a separate package ? [1] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries The packaging list is more appropriate, packag...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review requests for guayadeque-0.3.6-svn1830
On 09/03/2012 01:05 PM, Matthias Runge wrote: Martin Gansser linux4mar...@web.de schrieb: Hi all, I've just packaged guayadeque - A Audio player and organizer. https://bugzilla.redhat.com/show_bug.cgi?id=853553 Descripition : Guayadeque is a music management program designed for all music enthusiasts. It is Full Featured Linux media player that can easily manage large collections and uses the Gstreamer media framework. More information? http://guayadeque.org can someone review this package ? Thanks, Martin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Martin, you might want to review other packages, as this normally speeds up the review of your own packages. I can take this on and add to the FedoraAudio tracker. I have a feeling of deja-vu here though -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mate-Desktop
On 08/23/2012 04:53 PM, Rex Dieter wrote: Rave it wrote: For your information. I stoped working for the Mate-Desktop project for f18 because I can understand your frustration, and that you and Dan had trouble communicating and working together. I do wish to thank you for the positive contributions you made, and in your future endeavors. -- rex I agree, please do not stop contributing because of one foul-mouthed asshole. The good ones outnumber him grossly! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mate-Desktop
On 08/21/2012 11:50 PM, Matthew Garrett wrote: As a reminder, everyone working within the Fedora project is expected to abide by the code of conduct (http://fedoraproject.org/code-of-conduct). If there's an interpersonal conflict that can't be resolved by the individuals or the specific subset of the project involved, please feel free to raise it with the Community Working Group at c...@lists.fedoraproject.org, or cwg-priv...@lists.fedoraproject.org if you'd prefer the discussion to be private. I understand Dan's fairly new to Fedora - perhaps his sponsor should have a word with him. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: building compose, selinux problems
On 08/14/2012 12:45 PM, Ian Malone wrote: On 14 August 2012 08:49, Ian Malone ibmal...@gmail.com wrote: Ian, have you go the latest version? There was an missing EOF tag in one of the cat statements which could be causing problems. regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap - qtractor-freeworld
Hi all I have a review request for qtractor-freeworld in rpmfusion. It implements a patch that allows the dynamic loading of the libmad MP3 decoder for qtractor. https://bugzilla.rpmfusion.org/show_bug.cgi?id=2414 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Macro L_cuserid missing in /usr/include/stdio.h in F17 ?
On 07/23/2012 07:56 AM, Joachim Backes wrote:
#include unistd.h
#include stdio.h
main () {
fprintf (stderr,L_cuserid = %d,L_cuserid);
}
Do you need to add -D_GNU_SOURCE to your compile line?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On 07/23/2012 03:47 AM, Orcan Ogetbil wrote: On Sun, Jul 22, 2012 at 4:21 PM, Kevin Fenzi wrote: Please fix any packages you maintain that failed to rebuild. These are fixed: - hydrogen - lash This one did not have any problems. Just a plain rebuild fixed it: - clementine This one seems like a bug in doxygen, rather than a bug in the package: - slv2 [1] Apparently doxygen-1.8.1.1 generates a manpage file with a weird filename: /usr/share/man/man3/_builddir_build_BUILD_slv2-0.6.6_slv2_.3.gz I also see that the same problem exists in a few other packages, e.g. sord [2], suil [3]. I imagine there are other ones suffering the same issue. Downgrading to doxygen-1.8.0-1.fc18 eliminates the problem. Does anyone have a solution/workaround for this bug? Hmmm, it seems to be generating a (new) index file which contains a reference to the header file and nothing else. Removing prior to the install step seems to be enough an easy enough fix, but there is probably a better way that we can send upstream Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap needed for rtirq
Hi all, this package is required for the forthcoming Fedora audio spin. Would be great to get this reviewed before the Spin review. rtirq - realtime IRQ threading https://bugzilla.redhat.com/show_bug.cgi?id=839527 regards, Brendan bsjones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap needed for rtirq
On 07/19/2012 02:50 PM, Peter Lemenkov wrote: Hello! 2012/7/19 Patrick Uiterwijk puiterw...@gmail.com: Hey, I will take this. I'm faster than you! :) Could you take devtodo2 or prey? I'll take a look. Thanks Peter! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/20/2012 12:57 AM, Sam Varshavchik wrote: Chris Adams writes: Once upon a time, Sam Varshavchik mr...@courier-mta.com said: If what prelink is doing is perfectly fine, then there's no reason to have the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of course, would be either true or false irrespective of what I'm doing, which is completely irrelevant. As others have pointed out, that's because init is NOT a standard daemon (if you don't understand why PID 1 is special, I can't help you). No, it's not because init is not a standard daemon. prelink did not single out init for special treatment just because of its special status. prelink does this to every binary, not just init. It's just that the results of prelink's frak-up are critical in init's case. The argument that prelink can only be an issue to daemons that continue to run past the shutdown system state is, of course, a specious argument. Just because other daemons get impacted by prelink's frak-up at other times, other than the system shut down, does not make the frak-up magically disappear with no side-effects, unfortunately. You are saying that the special-casing of init in prelink's wrapper is justified because without it, what prelink ends up doing to init will result in a crash. But, since there's no crash with anyone else, even though prelink does the exact same thing, that makes it ok. Which is, of course, an intellectually-bankrupt position to take. Either what prelink is doing is damaging and/or improper, or it's not. If what it does is hunky-dory, and has no ill effects, then there would be no need whatsoever for any special hacks, for any special executables, not-withstanding some other standard or special status they have. You seem to be putting a lot of weight on the executable somebody ran to access your program, over and above all the kernel facilities for handling that (that are sufficient for everybody else, including heavily The only facilities that I'm aware of, and have been mentioned here, is inotify. I already said that I find the notion of having to inotify yourself, in order to mitigate prelink's bull-in-the-china shop behavior – and only prelink's – to be utterly preposterous. If inotify's the way to go here, then let's remove prelink's hack for init, and patch init to inotify itself, then. Sounds good to you? The inotify proposition reminds of Dan Bernstein's famous suggestion for distributing the officially blessed, binary-only qmail builds that have compiled-in userids, in a userid-independent way: if you want to distribute the officially blessed qmail build without a dependency on particular numeric uid values of qmail's reserved usernames, just provide a post-install hook that patches qmail's binaries with the uids in use on that particular server. Up to now, I never thought I'd ever come across another proposition that's just as mind-bending as that one. Well, looks like I was wrong. security-minded folk like OpenBSD devs). Aside from how a pathname is not really a good indicator (see SELinux vs. AppArmor), Until someone explains how exec($pathname) results in two completely different binaries getting started (excepting prelink's brain damage, and, again, excluding other events that replace the binary, but which have easy ways to control, and mitigate), it looks like a pretty good indicator to me; except for, again, the breakage that results from prelink's unsolicited buggering. how do you know the binary hasn't been modified in place? What good is your super-special pathname security then? You are again trying to change the topic. How good or not good it is, this has no merits on prelink's behavior, and the fact that there's no way – aside from silly hacks involving inotify – to make prelink do what it does in a more organized, well-behaved, civilized fashion. And because you have no answer to that (and because once someone has root and can overwrite stuff in /usr/bin, all bets are off anyway, which you also ignore), you must then start attacking the dependency that brings it out, as a factor, instead of addressing it directly. There may or may not be an argument about the merits of using a pathname for authentication. This is fine, and that subject can be debated elsewhere. But, now you have a situation where prelink's design results in a binary whose raw content is different, but it's, for all practical purposes, is the same binary. But, because of the way that happens, it breaks daemons that rely on comparing /proc/[pid]/exe, which I assert is a valid mechanism for making that comparison. Now, that's not the end of the world, of course, and I found a very obvious way to work around it (without doing stupid things with inotify) a while ago, but just thought that it was worthwhile to discuss if what prelink is doing can be improved. But, apparently, this is impossible. Since it's not possible,
Re: [ACTION REQUIRED v2] Retiring packages for Fedora 18
On 07/17/2012 10:19 PM, Michael Schwendt wrote: gtick -- A graphical metronome software I have added myself to this package. regards Brendan (bsjones) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Once again I've a number of small audio packages up for review that I'm willing to swap. They are: rtirq - realtime IRQ threading https://bugzilla.redhat.com/show_bug.cgi?id=839527 Add64 - an additive synthesizer for JACK https://bugzilla.redhat.com/show_bug.cgi?id=830664 samplv1 -A polyphonic sampler synthesizer with stereo fx https://bugzilla.redhat.com/show_bug.cgi?id=829971 synthv1 - a 4 oscillator subtractive polyphonic synthesizer https://bugzilla.redhat.com/show_bug.cgi?id=829970 Thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 07/10/2012 03:20 AM, Orcan Ogetbil wrote: On Mon, Jul 9, 2012 at 3:21 PM, Cosimo Cecchi wrote: On Fri, 2012-07-06 at 16:55 -0400, Bill Nottingham wrote: Removing: raptor flickcurl requires libraptor.so.1 flickcurl requires raptor-devel = 1.4.21-11.fc17 flickcurl-devel requires raptor-devel = 1.4.21-11.fc17 flickcurl-devel requires pkgconfig(raptor) = 1.4.21 liblrdf-devel requires raptor-devel = 1.4.21-11.fc17 librawstudio requires libraptor.so.1 rawstudio requires libraptor.so.1 tracker requires raptor-devel = 1.4.21-11.fc17 Tracker currently has a BuildRequires on raptor-devel, but it's actually an obsolete check, since it dropped the require a couple of years ago. The BR should just be removed from the spec file in this case. Similar situation for liblrdf. It was built against raptor2 but the liblrdf-devel erroneously required raptor-devel. Now I got this fixed. Orcan Orcan, did you want to take on those that you are co-maintaining? If not I'll take them Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
zita-resampler license change
This is moving from version 0.1.1 to 1.1.0 with a license change from GPLv2+ to GPLV3+ A build will be hitting rawhide soon. regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On 06/05/2012 06:53 PM, Anthony Green wrote: liblo -- Open Sound Control library lv2core -- Audio Plugin Standard mxml -- Miniature XML development library phasex -- PHASEX -- Phase Harmonic Advanced Synthesis EXperiment seq24 -- Real-time midi sequencer whysynth-dssi -- DSSI software synthesizer plugin vkeybd -- Virtual MIDI keyboard zynaddsubfx -- Real-time software synthesizer I'll take these, co-maintainers welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: projectM
On 06/01/2012 03:24 PM, Jameson wrote: Unfortunately, I'm no longer in a position to maintain the projectM packages (libprojectM, libprojectM-qt, projectM-jack, projectM-libvisual, and projectM-pulseaudio), so I will need to orphan these. If anyone would like to pick these up, feel free to come to me with questions, or help. Thanks, =-Jameson I'll take these on. Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Will review your package for FOOD!
On 05/15/2012 08:23 PM, Peter Lemenkov wrote: * https://bugzilla.redhat.com/739016 - erlang-poolboy - A hunky Erlang worker pool factory * https://bugzilla.redhat.com/821771 - erlang-edown - EDoc extension for generating Github-flavored Markdown * https://bugzilla.redhat.com/821802 - erlang-erlando - A set of Hey Peter, I'll take these two for https://bugzilla.redhat.com/show_bug.cgi?id=789059 and https://bugzilla.redhat.com/show_bug.cgi?id=789385 I have some others in the pipeline, so may be able to take more. Stay tuned regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
On 04/24/2012 02:37 PM, Juan Orti Alcaine wrote: Hello, I have a pending review request of arm, a utility to monitor the status of Tor routers. It's almost finished, as Spot has helped me with this package. I will take one of yours for this one. https://bugzilla.redhat.com/show_bug.cgi?id=756445 Thanks! Sure, if you could take : https://bugzilla.redhat.com/show_bug.cgi?id=789240 Brendan bsjones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
On 04/20/2012 05:00 AM, Michael Cronenworth wrote: On 04/19/2012 07:04 PM, Toshio Kuratomi wrote: This cycle, the Board is also asking contributors to let us know if we should continue to have release names for future Fedora releases. Even though the interface is the same, this portion is intended to be a poll rather than a straight up vote. The Fedora Board will look at the answers to determine if enough contributors value continuing to create release names to make it worthwhile in the future. If it does seem desirable, the Board will likely look into forming a working group to come up with a new method for creating release names for future releases. It would be nice to have a third option: -Change release names to release theme. We don't really need a name (IMO), but the theme adds a nice touch. I fully agree. We need to help the design team out, and trying to tie it to the previous release is a bit overbearing in my opinion. What do you do with a beefy miracle, there's not much room to move. Drop the name but lets vote on a theme -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
Hi, I'll take the following if you could take: https://bugzilla.redhat.com/show_bug.cgi?id=814924 https://bugzilla.redhat.com/show_bug.cgi?id=814916 Thanks Brendan On 04/21/2012 04:14 PM, Mattias Ellert wrote: One package split: voms-api-java: https://bugzilla.redhat.com/show_bug.cgi?id=806066 One new package: jglobus: https://bugzilla.redhat.com/show_bug.cgi?id=812751 Mattias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review (rename) swap
Hi I've got a package rename that needs reviewing. I've got 4 updates and 2 new packages that I'd like to build against the renamed package: If anyone would like to do a review swap: https://bugzilla.redhat.com/show_bug.cgi?id=814542 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 03:31 PM, Jared K. Smith wrote: I, for one, would *love* to find a way for Fedora to be able to accept funds from outside groups. I'm not complaining about Red Hat here -- I think they've been a great corporate sponsor of the Fedora Project, and I don't personally see the need for the Fedora Project to distance itself from them. They continue to put a lot of resources (money, salaried positions, legal support -- and most importantly -- trust) in Fedora, and I'd never suggest doing anything that might jeopardize that. I would like other organizations to be able to donate money to Fedora too, and in an ideal world we could sell Fedora-branded items and have a portion of the proceeds directly benefit the project. I investigated and pushed for the ability to make this happen while I was FPL, but the stark reality is that there's no feasible way to do this at the present time. The easiest way for outside organizations to help Fedora is to directly provide support at FUDCons (such as directly paying for the catering or the internet access), or donating hardware to the Infrastructure team (and there are certain guidelines that the Infra team can share with you, if you're interested). It's not an ideal situation by any stretch of the imagination, but it's the situation we live in right now. -- Jared Smith Does that mean the only cold hard cash Fedora receives is from Redhat? Ie. all travel allownaces etc cmoe from that support? I was recently asked in an interview what funds we (the current Fedora project I'm working on) was looking for. And all I could say was peoples time and knowledge :( -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 09:45 PM, Jared K. Smith wrote: On Wed, Apr 4, 2012 at 2:40 PM, DJ Deloried...@redhat.com wrote: So between sponsoring cons, travel, hardware, etc... what can *only* be done with Red Hat Cash? Is there anything that an individual cannot say I'll pay for that (and/or buy that) for you ? Absolutely. An individual or organization can say We'll pay for Joe's travel or We'll pay for lunch on Saturday or We'll pay for the internet connection or a myriad of other things like that. They just need to pay for those things directly -- they can't just hand Fedora a pile of cash. Does Fedora exist outside of the US (on the books)? Surely there must be a way to dissociate Redhat US sponsorship to an international non-profit that represents Fedora? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-free tarball checked in
On 03/12/2012 03:46 AM, Bruno Wolff III wrote: I checked in a tarball for egoboo that turned out to have a non-free (noncommercial restriction) font file in it. The tarball has only been used for local builds (no scratch-builds). Do I need to remove this tarball from the lookaside cache? If so how do I do it? The hash is e6f3130695d297dcd9fe74e50bd59b68. Does that mean any source tarballs containing non-free content should be repacked by the maintainer even if the source rpm doesn't install/use any of the non-free content? I've been recently commenting on a review where this might apply. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap: Summoning Wars
On 03/12/2012 04:22 PM, Martin Preisler wrote: Hi, I would appreciate a review of this hack n slash RPG game. Everything FOSS: GPLv3+ code and CC-BY-SA assets. sumwars.org for more info. https://bugzilla.redhat.com/show_bug.cgi?id=801092 I am not a sponsor so I can only swap with you if you already are a Fedora packager. I'd be happy to if you could take https://bugzilla.redhat.com/show_bug.cgi?id=784605 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap: logkeys - Linux keylogger
On 03/04/2012 02:04 PM, Ankur Sinha wrote: Hey folks, A package that we'd like to use for fedora videos requires review: Review Request: logkeys - Linux keylogger [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=799701 I'll be happy to review a package in return. I'll take it if you can pick up https://bugzilla.redhat.com/show_bug.cgi?id=784605 thanks Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 10:47 AM, Reindl Harald wrote:
Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson:
On 02/14/2012 10:23 AM, Alfredo Ferrari wrote:
Do the systemd maintainers ever read bug reports BTW?
Why do you think otherwise?
Not only read them but fix them as well.
To give you some stats
There are currently 96 Open bugs against systemd and 536 that have been closed
at the time of this writing...
In F15 which should be the most buggied release since it was the initial
release into the distribution only has 11
bugs
will systemctl restart ever has working autocompletion for RUNNING services?
it is a littl ebit odd the it does show STOPPED services because
restart makes ususally more sense for running ones...
You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do
this for you.
Replace the $( __get_all_units | grep ...)) with $( __get_active_units ) )
.
.
.
elif __contains_word $verb ${VERBS[RESTARTABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStart yes \
$( __get_all_units | grep -Ev
'\.(device|snapshot|socket|timer)$' ))
.
.
.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi all, still require a few takers required for swaps. Ports from CCRMA and latest additions to the new LV2 audio stack. All very small packages CCRMA 788718 clalsadrv - An ALSA driver C++ library (most of the following depend on this one) 789255 ebumeter - Loudness measurement according to EBU-R128 789249 jkmeter - Horizontal or vertical bar-graph audio levels meter 789240 freqtweak - Realtime audio frequency spectral manipulation 789059 jaaa - JACK and ALSA Audio Analyzer 789055 japa - JACK and ALSA Perceptual Analyser 789385 ambdec- an ambiosonics decoder 789390 aeolus- aeolus organ synthesizer LV2 788717 lv2-ir- An LV2 impulse response reverb plugin 784605 lv2-instance-access - An LV2 audio plug-in extension (part of the spec) 783825 suil - A lightweight C library for loading and wrapping LV2 plugin UIs 789386 lilv - An LV2 Resource Description Framework Library My packages awaiting review can be found here [1] cheers Brendan [1] https://bugzilla.redhat.com/buglist.cgi?query_format=advancedclassification=Fedoraproduct=Fedoracomponent=Package%20Reviewbug_status=NEWemailreporter1=1emailtype1=substringemail1=brendan.jones.it%40gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Studio
Hi all, I have a dream ... that one day we will have a Fedora Audio spin. At the moment most Fedora audio users rely heavily on the Planet CCRMA repository for many of their audio packages. Fernando has has spent countless hours maintaining this repository (thanks!) but If any kind of Studio/audio spin is going to be realized we need to move the bulk of these packages into mainline Fedora. There is no proposal as yet for this spin, as there is still so much work to be done. I would be very surprised if this could be completed by F18 - however there are also some really exciting developments in the Linux audio world, whose releases should really coincide with this effort here (Ardour3/Ingen/SuperCollider). Below is a list of some of the packages that I've submitted for review and would be more than happy to swap - this is just a beginning there are many more to come. Maintainers/co-maintainers are more than welcome / actively encouraged. Also listed are packages pertaining to the new LV2 stack - an exciting opensource audio framework that is proving to be a shining light in the future of Linux audio. CCRMA 788718 clalsadrv - An ALSA driver C++ library (most of the following depend on this one) 789255 ebumeter - Loudness measurement according to EBU-R128 789251 jmeters - Multichannel audio level meter 789249 jkmeter - Horizontal or vertical bar-graph audio levels meter 789240 freqtweak - Realtime audio frequency spectral manipulation 789059 jaaa - JACK and ALSA Audio Analyzer 789055 japa - JACK and ALSA Perceptual Analyser 789385 ambdec- an ambiosonics decoder 789390 aeolus- aeolus organ synthesizer 789391 aeolus-stops - aeolus presets LV2 788717 lv2-ir- An LV2 impulse response reverb plugin 784605 lv2-instance-access - An LV2 audio plug-in extension (part of the spec) 783825 suil - A lightweight C library for loading and wrapping LV2 plugin UIs 789386 lilv - An LV2 Resource Description Framework Library My packages awaiting review can be found here [1] cheers Brendan [1] https://bugzilla.redhat.com/buglist.cgi?query_format=advancedclassification=Fedoraproduct=Fedoracomponent=Package%20Reviewbug_status=NEWemailreporter1=1emailtype1=substringemail1=brendan.jones.it%40gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt Package Build fails in rawhide and f17 and builds in f16
On 02/10/2012 11:19 AM, Johannes Lips wrote: Hey, I just seem to run into an error that a package builds just fine in f16 (unpackaged file is another thing) but it won't build on f17 and f18. Is there an incompatibility of the source code with newer Qt versions or is it just a temporary koji hickup? f16 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=313 f17 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=315 f18 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=309 Thanks for any help, Johannes You need to #include stdint.h . This is due to GCC 4.7 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with latest automake 1.11.3 in rawhide
On 02/04/2012 05:20 PM, Remi Collet wrote: mysql-workbench don't build anymore, seems to be a automake 1.11.3 issue (build ok with previous version) Here is the build.log http://koji.fedoraproject.org/koji/getfile?taskID=3762316name=build.log Help will be really appreciated... Remi Not sure if you are aware but there's a bug posted upstream with a suggested fix [1]. [1] http://bugs.mysql.com/bug.php?id=63898 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
