Why there is no sync for libicu soname rebuilds?
Hi, I remember one year back also harfbuzz was attempted by 2 people on the same day for libicu rebuilds and now this time 3 builds by 2 people. http://koji.fedoraproject.org/koji/buildinfo?buildID=606443 http://koji.fedoraproject.org/koji/buildinfo?buildID=609035 http://koji.fedoraproject.org/koji/buildinfo?buildID=609067 Regards, Parag. -- 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: [Guielines Change] Changes to the packaging guidelines
Hi,
On Wed, Jan 28, 2015 at 8:33 AM, Jason L Tibbitts III ti...@math.uh.edu wrote:
%license must be used in place of %doc to designate any file containing
the license information for a package. See
https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation and
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
Guidelines for DevAssistant packages (DAP) were added:
https://fedoraproject.org/wiki/Packaging:DevAssistant
The Python guidelines relating to naming of executables in /usr/bin were
updated to account for F22's Python3 by default feature:
https://fedoraproject.org/wiki/Packaging:Python#Executables_in_.2Fusr.2Fbin
The Python Egg packaging guidelines have been cleaned up to properly
refer to egg packages and egg metadata:
https://fedoraproject.org/wiki/Packaging:Python_Eggs
Clarified the naming guidelines to indicate how language bindings are
named: lua-randomdb instead of randomdb-lua:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28General.29
Added information on dealing with unversioned shared libraries:
https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning
The systemd guidelines were revised to include a section about the use
of PrivateDevices and PrivateNetwork:
https://fedoraproject.org/wiki/Packaging:Systemd#Private_devices_and_networking
Information on when timer activation must and must not be used was
added to the Systemd guidelines:
https://fedoraproject.org/wiki/Packaging:Systemd#Timer_activation
Removed pre-Fedora 18 information from systemd section of
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets
A section has been added on log files and logrotate:
https://fedoraproject.org/wiki/Packaging:Guidelines#Log_Files
Several changes have been made to the MinGW packaging guidelines to
reflect new macros and changes to accepted practice:
https://fedoraproject.org/wiki/Packaging:MinGW
The mono guidelines were modified to mention the %{_monodir} and
%{_monogacdir} macros:
https://fedoraproject.org/wiki/Packaging:Mono
Guidelines for the application of patches have been added:
https://fedoraproject.org/wiki/Packaging:Guidelines#Applying_patches
Added information to the PHP guidelines on dealing with PSR-4
libraries:
http://fedoraproject.org/wiki/Packaging:PHP
The Ruby guidelines have been updated to account for the removal of the
testrb utility:
https://fedoraproject.org/wiki/Packaging:Ruby
Added a section to the review guidelines indicating how to handle
packages with unreviewed dependencies:
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#A_note_on_dependencies
A class of exceptions for bundling of libraries was added. This class
applies to reverse bundling, where a large upstream has had a piece
forked off into a separate library. The exception allows for reverse
bundling in cases where an API from an upstream is being forked into its
own library so that code using an older version of that upstream is able
to make use of the new API. Packagers making use of this exception need
to still apply to the FPC for a virtual provide for tracking this
usage. This exception is not applicable to all cases of reverse bundling
so please read the full guideline:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Reverse_Bundling
and open an FPC ticket if things are still unclear.
Thank you Jason for working on updating the packaging guidelines wiki pages.
Regards,
Parag.
--
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: Mail bounces: akozu...@redhat.com
Hi, On Sat, Dec 20, 2014 at 10:07 AM, Ralf Corsepius rc040...@freenet.de wrote: On 12/20/2014 02:46 AM, Chris Murphy wrote: On Fri, Dec 19, 2014 at 3:35 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, Dec 19, 2014 at 10:44:12AM +0100, Ralf Corsepius wrote: Hi, Bugzilla mails addressed at dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com seem to bounce. Shouldn't this be a temporary hickup (To my best knowledge it is not), I'd ask those who can do something about it (bugzilla, pkgdb, dnf maintainers) please take action. As far as I can see the options are: a) Contact Ales and ask him to change his email in FAS b) Remove Ales' ACLs in pkgdb One not being incompatible with the other, but I think option a would be nice to do whether or not option b is applied. Ales Kozumplik kozump...@gmail.com is no longer DNF maintainer, he handed it off to Jan Šilhan jsil...@redhat.com. http://dnf.baseurl.org/2014/09/18/new-dnf-project-leader/ OK, but then some overseer/RH-manager, bugzilla/pkgdb-maintainer or may-be the new package maintainer should reflect this to the pkgdb and/or bugzilla. At least until yesterday, dnf-ow...@fedoraproject.org seems to have pointed to akoz...@redhat.com ;) In this context, I also would suggest, RH to consider improving their quitting/employee checkout process to cover pkgdb/bugzilla. Generally I have seen sometimes when a RH employee quits, his packages gets re-assigned to some peer or its manager. This can be easily seen by bugzilla notifications where bugs gets reassigned. When Ales quit, I thought this bugzilla script will be run (not sure who triggers this script) but that did not happen. Regards, Parag. -- 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: Can you help with making fonts awesome in Fedora 21?
Hi, On Thu, Oct 16, 2014 at 3:29 PM, Richard Hughes hughsi...@gmail.com wrote: On 16 October 2014 10:51, Tim Lauridsen tim.laurid...@gmail.com wrote: Mega updates, sound a litlle wrong to me so late in the F21 cycle, Fine for rawhide (f22) I did think about creating a new update for each build, but that's so much clicking. For something as simple as this an update with ~30 packages is very easy to submit, test and push. Feel free to submit individual updates for your packages if that's preferable. I have pushed all my fedora 21 updates as an individual updates now. Regards, Parag. -- 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: dnf and yum. again.
Hi, On Tue, Oct 7, 2014 at 8:31 AM, Dmitrij S. Kryzhevich kr...@land.ru wrote: Just check this First. # dnf update Dependencies resolved. Nothing to do. Second. # yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies SKIP Transaction Summary = Upgrade 2 Packages Total download size: 15 M Is this ok [y/d/N]: Exiting on user command What wrong with dnf? Its expected result since long time from dnf and has not changed its behaviour. Just read this http://dnf.readthedocs.org/en/latest/user_faq.html?highlight=faq#why-do-i-get-different-results-with-dnf-upgrade-vs-yum-update Regards, Parag. -- 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: F-21 Branched report: 20140924 changes
Hi Richard, On Wed, Sep 24, 2014 at 6:49 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Sep 24, 2014 at 10:12:14AM +, Fedora Branched Report wrote: [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-bisect] ocaml-bisect-1.3-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-bitstring] ocaml-bitstring-2.0.4-5.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 etc etc I'm snowed under with work at the moment. These Fedora 21 packages should just need a bump release and rebuild, if any proven packager wants to give that a go. There are about 10 of them. Let me help here by just rebuilding these packages in Fedora 21. Parag. -- 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: F-21 Branched report: 20140924 changes
Hi Jerry, On Thu, Sep 25, 2014 at 9:47 PM, Jerry James loganje...@gmail.com wrote: On Wed, Sep 24, 2014 at 7:19 AM, Richard W.M. Jones rjo...@redhat.com wrote: I'm snowed under with work at the moment. These Fedora 21 packages should just need a bump release and rebuild, if any proven packager wants to give that a go. There are about 10 of them. Rich. I did ocaml-ulex last night. I'll try to get a couple more of them today. I have done first 8 broken package rebuilds in Fedora 21. You can do rest of the 6 packages :) Regards, Parag. -- 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: F21/F22 mass rebuild
Hi, On Sat, Sep 13, 2014 at 5:14 PM, Richard Fearn richardfe...@gmail.com wrote: Hi, I've got a question about the last mass rebuild: https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild For a couple of my packages: http://koji.fedoraproject.org/koji/packageinfo?packageID=6133 http://koji.fedoraproject.org/koji/packageinfo?packageID=4673 there was a rebuild for both F21 and F22. However for ncdu: http://koji.fedoraproject.org/koji/packageinfo?packageID=6127 there was only an F21 rebuild. Does that matter? It's a bit hard to tell, as the script linked from the wiki page is the one used for the F21 rebuild back in June; and the date after which maintainer builds count towards the latest rebuild is 2014-06-05, the same date as for the F21 mass rebuild (as opposed to some date in August). You can find details about that special mass rebuild in thread https://lists.fedoraproject.org/pipermail/devel/2014-August/201635.html Regards, Parag. -- 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: EPEL texlive in 7
Hi, On Tue, Apr 1, 2014 at 2:07 PM, Simone Caronni negativ...@gmail.com wrote: Hello, is there any plan to have texlive in EPEL 7? The texlive package already exists in RHEL7. See http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/Packages/ Regards, Parag. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL texlive in 7
Hi, On Tue, Apr 1, 2014 at 3:12 PM, Susi Lehtola jussileht...@fedoraproject.org wrote: On Tue, 1 Apr 2014 11:39:05 +0200 Simone Caronni negativ...@gmail.com wrote: On 1 April 2014 11:26, Parag N(पराग़) panem...@gmail.com wrote: On Tue, Apr 1, 2014 at 2:07 PM, Simone Caronni negativ...@gmail.com wrote: Hello, is there any plan to have texlive in EPEL 7? The texlive package already exists in RHEL7. See http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/Packages/ Ok, I found the issue. The texlive in EPEL 7 is too old and does not contain the sub-packages I'm using. I hope they will update it before release; texlive 2013 was released mid 2013 and we're now in 2014. You can probably forget about that hope - they're not going to do a major update, certainly not after the beta release. True. Generally there are no major updates after beta release. For the subpackages which are missing try filing a bug against texlive in RHEL7 and request to include needed packages. Regards, Parag. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Let's close the remaining merge reviews
Hi, On Wed, Mar 26, 2014 at 5:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Mar 26, 2014 at 08:13:24AM +0530, Parag N(पराग़) wrote: If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. The presence of these bugs tells you nothing about the quality of those packages. Also it doesn't tell you about other packages that might have passed the review 5+ years ago, but since then fallen out of compliance with the guidelines. This looks like a general opinion on package reviews and not about merge-reviews. Why can't we consider them like as a new reviews? and why people so against merge-review just because we got those packages already in Fedora? This is where having some sort of automated testing of all packages would be good (perhaps running fedora-review over packages, as was suggested in this thread already). That will be a welcome move but again will maintainers read those reviews and work on to fix any reported issues? FWIW, Debian does this already: http://lintian.debian.org/ Those who want to see all the automated work, keep looking into https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools Regards, Parag. -- 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: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 6:59 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Mar 25, 2014 at 9:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Mar 24, 2014 at 05:07:35PM -0700, Toshio Kuratomi wrote: Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). I like the idea of actually revisiting the list and deciding what to do, although pulling them out of the repository seems unnecessarily drastic. This always winds up being the suggestion. Nobody actually does anything about it. This is also what I have seen. We have seen many discussions on merge-review closure since last few years but no one step forward to work on it. Why to discuss such things if we all contributors can review packages and help maintainers to have their packages as per current packaging guidelines? The only problem I have seen while working on such reviews is that some maintainers find them low priority and did not respond. Sometime ago I decided to work on this and also wanted to clean spec myself and review the same package myself but our policies does not allow this. So I occasionally visit merge-reviews and try to finish them with the help of current package owner. Regards, Parag. -- 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: Let's close the remaining merge reviews
Hi, On Tue, Mar 25, 2014 at 7:13 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 03/25/2014 08:42 AM, Cole Robinson wrote: On 03/24/2014 08:07 PM, Toshio Kuratomi wrote: On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote: An alternative would be to reassign every open merge review to the component in question, and let maintainers handle it as they like. Thoughts? Alternative idea -- maybe identify all packages which are not ciritcal and have an open merge review. Take those packages out of the repository. What does that solve? How does that benefit anybody? Then revisit the list and formulate a plan on what to do with thoes (even if the plan is then, these were critical enough to leave in so we'll give them a pass on going through a formal review). The original premise of these tickets makes sense. But here we are 7+ years later. The spec we would review today is in many cases nothing like the spec when the bug was filed. Why should these packages be subject to a review _now_ when there's a thousand packages in the repo that saw an initial review, and are then left entirely alone for 6 years? Because 7 years ago we merged core and extras? I'm not convinced. The bottom line IMO is that these bugs are generating very little benefit, and are actively detrimental. They shouldn't be given any extra weight for history's sake. - Cole I concur. Let's close those bugs. If those packages are still not following current packaging guidelines then they should not be closed otherwise what is the use of FPC and their work, meetings, updating wiki pages all these efforts will be of no use then for existing packages in Fedora. FPC work will remain only for newer package submissions. Regards, Parag. -- 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: Orphaning 'shakthimaan' packages
Hi, On Mon, Feb 17, 2014 at 6:14 AM, Christopher Meng cicku...@gmail.comwrote: You only have one package? After sending email here, Shakthi Kannan has orphaned all his packages. That single package is displayed due to his co-ownership in f19 branch. Regards, Parag. -- 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: Why libicu soname bump required harfbuzz package to be built twice?
Hi all, On Fri, Feb 14, 2014 at 5:18 AM, Adam Williamson awill...@redhat.comwrote: On Thu, 2014-02-13 at 09:26 +0530, Parag N(पराग़) wrote: Hi, From the yesterday's pkgs git commit logs I see 3-4 people built few packages for libicu soname bump. I am not sure why a single person can't carry such a few package rebuilds for libicu soname bump. Whoever (people names) want to rebuild packages should announce on devel list first. Looks like harfbuzz package is picked twice for these rebuilds. Both rebuilds happened in within 30 minutes time period. It doesn't really cause any terrible pain for a double rebuild to happen. devel@ being flooded with I'm about to rebuild X! would certainly cause a lot more inconvenience. Right there is no harm. One can only bump the release and carry a rebuild without any change in spec. What I thought is that generally people whose packages gets soname bump used to carry package rebuilds for its dependent packages also. Same has already happened with libicu soname bump in the past. This time it was not clear if libicu maintainer is going for these package rebuilds or not. Anyway I assume libicu maintainer want to only push libicu update and let the dependent package owners to rebuild their packages. I have just rebuilt fontmatrix now. Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Why libicu soname bump required harfbuzz package to be built twice?
Hi, From the yesterday's pkgs git commit logs I see 3-4 people built few packages for libicu soname bump. I am not sure why a single person can't carry such a few package rebuilds for libicu soname bump. Whoever (people names) want to rebuild packages should announce on devel list first. Looks like harfbuzz package is picked twice for these rebuilds. Both rebuilds happened in within 30 minutes time period. Regards, Parag. -- 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: Source string contextualization
Hi Nilamdyuti, On Fri, Jan 24, 2014 at 5:52 PM, Nilamdyuti Goswami ngosw...@redhat.comwrote: Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. I see iok project have many locales available for translations in iok package so maybe you people can help in improving source translation strings by providing patches in bugzilla or upstream tracker. This is really helpful to let translators understand the exact context of the source string. This will help to have more accurate translations. Regards, Parag. -- 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: How to get packager sponsorship
Hi, On Sun, Jan 12, 2014 at 3:46 PM, Jochen Schmitt joc...@herr-schmitt.dewrote: On Sun, Jan 12, 2014 at 10:29:54AM +0100, Michael Schwendt wrote: There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Review your own package? New contributors can also review their own package and show what things they found in their package like how they found they have correct upstream source matching checksum, how they found license tag for their package, what rpmlint output they found etc. This applies even for other packages also waiting for review. But, here what Michael want to point out that people waiting for their package review who are also waiting for sponsorship should at least look into http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html and provide their review findings so that other people will come to know any issues in their package and they can be updated/progressed further. I think the aim of the review process is, that a second one should have a look on your package to verify, that your package mmets the package guidelines and so on. For a new contributor, if he submitted many packages then whichever package first gets reviewed should get approved by sponsor member. Most people may be blind against thier onw mistakes, so it makes sense that anonther one take a look on the package which should introduced to Fedora. Regards, Parag -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
how to fix this qt code for format-security flag FTBFS
Hi, I got a format-security flag FTBFS bug[1] for fontmatrix package which I maintain in Fedora. I am confused on how to fix line 86 qDebug() from http://fpaste.org/58952/13861663/ to fix this FTBFS. Can someone help to fix this? Regards, Parag. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1037066 -- 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: how to fix this qt code for format-security flag FTBFS
Hi, Thanks for replying to my query. I also got same help on #fedora-kde channel. Regards, Parag -- 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: Lack of response about sponsorship
Hi, On Mon, Oct 21, 2013 at 2:32 PM, Miroslav Suchý msu...@redhat.com wrote: On 10/17/2013 05:19 AM, Luya Tshimbalanga wrote: I understand each one of us is busy with their life but a simple message would suffice to let know about the status. Is there a better way to address this concern to avoid repeating it in the future? Some numbers FYI: * We have 117 sponsors right now. * This year 83 people have been sponsored. * 191 people are waiting to be sponsored. By looking into this page http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html , I see 60 people are need to be sponsored in the packager group. Are your numbers for all the available groups in FAS? Regards, Parag -- 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: Lack of response about sponsorship
Hi, On Mon, Oct 21, 2013 at 7:08 PM, Miroslav Suchý msu...@redhat.com wrote: On 10/21/2013 03:28 PM, Parag N(पराग़) wrote: Hi, On Mon, Oct 21, 2013 at 2:32 PM, Miroslav Suchý msu...@redhat.commailto: msu...@redhat.com wrote: On 10/17/2013 05:19 AM, Luya Tshimbalanga wrote: I understand each one of us is busy with their life but a simple message would suffice to let know about the status. Is there a better way to address this concern to avoid repeating it in the future? Some numbers FYI: * We have 117 sponsors right now. * This year 83 people have been sponsored. * 191 people are waiting to be sponsored. By looking into this page http://fedoraproject.org/** PackageReviewStatus/**NEEDSPONSOR.htmlhttp://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html, I see 60 people are need to be sponsored in the packager group. Are your numbers for all the available groups in FAS? I use this query: http://tinyurl.com/ndp8ae7 which is - all bugs which blocks FE-NEEDSPONSOR - which include BZ with review flag set to ?. And yes, some BZs have same reporter. I am not able to see your bugzilla query. All I see is https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamednamedcmd=reviewes%20need%20sponsorlist_id=1826234 Regards, Parag -- 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: Source file audit - 2013-09-30
Hi, Looks like working fedorahosted download links got reported as BADURL. Parag -- 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: Overall rawhide package testing.
Hi, On Mon, Aug 26, 2013 at 5:49 PM, Alec Leamas leamas.a...@gmail.com wrote: As agreed [1], we have run fedora-review on (almost) all packages in current rawhide. The results are now available at [2]. Here are reports on issues by package and packages by issue. We have discussed sending email about these results to the package owners. Is this a good idea? In any case, I think it might be good if you check your own packages, chances are that something otherwise unnoticed is discovered. Please don't forget the README. For those interested in the overall distribution, the package by issue reports perhaps also might add something as well as the 'stats' file in the top dir. I see some of my packages listed and when I look for why its listed, I can't figure out. I now need to run fedora-review on those packages. If possible provide results directory with all three log files to understand what is wrong in the package. Regards, Parag -- 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: Overall rawhide package testing.
Hi, On Mon, Aug 26, 2013 at 6:49 PM, Parag N(पराग़) panem...@gmail.com wrote: Hi, On Mon, Aug 26, 2013 at 5:49 PM, Alec Leamas leamas.a...@gmail.comwrote: As agreed [1], we have run fedora-review on (almost) all packages in current rawhide. The results are now available at [2]. Here are reports on issues by package and packages by issue. We have discussed sending email about these results to the package owners. Is this a good idea? In any case, I think it might be good if you check your own packages, chances are that something otherwise unnoticed is discovered. Please don't forget the README. For those interested in the overall distribution, the package by issue reports perhaps also might add something as well as the 'stats' file in the top dir. I see some of my packages listed and when I look for why its listed, I can't figure out. I now need to run fedora-review on those packages. If possible provide results directory with all three log files to understand what is wrong in the package. Thanks Alec for giving me some understanding on this on IRC. I found http://leamas.fedorapeople.org/fedora-review/tree/README and as written there I see my packages are clean. Regards, Parag -- 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: mass rebuild update
Hi, On Mon, Aug 5, 2013 at 2:14 PM, Tadej Janež tadej.ja...@tadej.hicsalta.siwrote: Hi! On Sun, 2013-08-04 at 21:35 -0500, Dennis Gilmore wrote: There is a large number of failures[1] that need to be addressed. I don't know if this is just a coincidence, but the links to log files in the filled FTBFS bug reports don't work. Here are two examples (from my FTBFS bugs): https://bugzilla.redhat.com/show_bug.cgi?id=992784 https://bugzilla.redhat.com/show_bug.cgi?id=992018 log files issue is reported here - https://fedorahosted.org/rel-eng/ticket/5700 Regards, Parag. -- 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: Schedule for Thursday's FPC Meeting (2013-08-01 16:00 UTC)
Hi, On Thu, Aug 1, 2013 at 10:53 AM, Parag N(पराग़) panem...@gmail.com wrote: Hi, On Thu, Aug 1, 2013 at 12:29 AM, James Antill james.ant...@redhat.comwrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-08-01 09:00 Thu US/Pacific PDT 2013-08-01 12:00 Thu US/Eastern EDT 2013-08-01 16:00 Thu UTC - 2013-08-01 17:00 Thu Europe/London BST 2013-08-01 18:00 Thu Europe/Paris CEST 2013-08-01 18:00 Thu Europe/Berlin CEST 2013-08-01 21:30 Thu Asia/Calcutta IST --new day-- 2013-08-02 00:00 Fri Asia/Singapore SGT 2013-08-02 00:00 Fri Asia/Hong_Kong HKT 2013-08-02 01:00 Fri Asia/Tokyo JST 2013-08-02 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = New business = #topic #324 Poor Packaging:CronFiles guidelines .fpc 324 https://fedorahosted.org/fpc/ticket/324 #topic #325 Temporary bundling exception of yajl library .fpc 325 https://fedorahosted.org/fpc/ticket/325 #topic #326 Bundling exception for python-kapteyn .fpc 326 https://fedorahosted.org/fpc/ticket/326 When will .fpc 321 be considered as New Business or was it discussed already in last meeting? Regards, Parag. Probably I need to open new business for my query again. Will do so in next week. Thanks, Parag -- 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: Schedule for Thursday's FPC Meeting (2013-08-01 16:00 UTC)
Hi, On Thu, Aug 1, 2013 at 12:29 AM, James Antill james.ant...@redhat.comwrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-08-01 09:00 Thu US/Pacific PDT 2013-08-01 12:00 Thu US/Eastern EDT 2013-08-01 16:00 Thu UTC - 2013-08-01 17:00 Thu Europe/London BST 2013-08-01 18:00 Thu Europe/Paris CEST 2013-08-01 18:00 Thu Europe/Berlin CEST 2013-08-01 21:30 Thu Asia/Calcutta IST --new day-- 2013-08-02 00:00 Fri Asia/Singapore SGT 2013-08-02 00:00 Fri Asia/Hong_Kong HKT 2013-08-02 01:00 Fri Asia/Tokyo JST 2013-08-02 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = New business = #topic #324 Poor Packaging:CronFiles guidelines .fpc 324 https://fedorahosted.org/fpc/ticket/324 #topic #325 Temporary bundling exception of yajl library .fpc 325 https://fedorahosted.org/fpc/ticket/325 #topic #326 Bundling exception for python-kapteyn .fpc 326 https://fedorahosted.org/fpc/ticket/326 When will .fpc 321 be considered as New Business or was it discussed already in last meeting? Regards, Parag. -- 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: Grepping through all Fedora specfiles?
Hi, On Tue, Jul 23, 2013 at 10:34 AM, Ralf Corsepius rc040...@freenet.dewrote: On 07/22/2013 11:39 AM, Ville Skyttä wrote: Hello, I'd like to grep through all specfiles (and preferably also patches and sources in git) for rawhide, this time related to the unversioned docdirs F20 feature, and sometimes for other reasons. Hopefully there's a better way than to fedpkg clone all packages one at a time... does anyone know of one? Back in CVS times there were downloadable daily checkout seed tarballs which were excellent for this purpose, but I don't think such things exist nowadays, do they? For similar purposes, I have been using the CSV table returned by https://admin.fedoraproject.**org/pkgdb/lists/bugzilla?tg_**format=plainhttps://admin.fedoraproject.org/pkgdb/lists/bugzilla?tg_format=plain I am downloading the CSV-table and then use scripts to filter the CSV into lists and subsequently to feed them into further scripts for further processing. Thanks for this link. I was not knowing this before. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still use system-config-language?
Hi Jiri, On Tue, Jun 11, 2013 at 4:12 PM, Jiri Eischmann eischm...@redhat.comwrote: Hi, I wonder if any spin is still using system-config-language. GNOME has its own graphical utility to install language support, but AFAIK there is no counterpart in other environments, right? system-config-language is a distro specific tool. It just installs required packages and set the root user language. I find this tool useful where you don't need to find particular fonts or input methods explicitly and install them. Good for novice users. GNOME language support is a different from system-config-language. The problem is that system-config-language is completely broken since F18 (see [1] because it didn't reflect changes in language groups. system-config-language is used to install language support that includes fonts, input-method engine and any other packages listed for that language group in comps file. Since comps moved to start using yum-langpacks and few language support groups have been removed, system-config-language failed to install support for those languages. If we decide to re-write this tool for yum-langpacks then other packages will not get pulled automatically which have been explicitly listed in comps for some languages. I still have not got solution on how to balance this in system-config-language. So if there is no spin using it, we should probably remove it from Fedora because in the current state, it's completely broken and useless. If there is still need for the utility, then it probably should be fixed. I am looking into fixing system-config-language but not sure how much time will it take. BTW what are recommended ways to install language support in e.g. KDE and Xfce? Is there any other graphical way other than system-config-language? Jiri [1] https://bugzilla.redhat.com/show_bug.cgi?id=901831 Regards, Parag -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130201 changes
Hi, I have fixed libicu broken dependencies for following packages 389-admin 389-ds-base 389-dsgw ibus-qt idzebra libcommuni libircclient-qt msort pam_mapi sword yaz zarafa Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
I wish such issues could have been caught earlier maybe by trying some of the rebuilds consuming libicu library. Some packages got rebuild with icu-config --cpp-flags and some are waiting for not to be used this solution. On Tue, Jan 29, 2013 at 1:46 AM, Eike Rathke er...@redhat.com wrote: Hi, On Sunday, 2013-01-27 11:30:22 +0900, Mamoru TASAKA wrote: Looks like patching against /usr/include/unicode/urename.h is more appropriate. I wrote some comments on bug 856594. Thanks for the pointer, in icu-50.1.2-2.fc19 I solved that instead with sed -e '/^#define __UCONFIG_H__/ r uconfig.h.prepend' -i common/unicode/uconfig.h as uconfig.h.prepend is created by configure and meant for this reason. Now the original submitter of that bug asked for the soname to be different from a versioned ICU library of the same version ... 1. why? 2. how? Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
I will wait for final resolution for bug 856594 till then I will not build fontmatrix. On Sun, Jan 27, 2013 at 8:19 AM, Kevin Fenzi ke...@scrye.com wrote: On Sun, 27 Jan 2013 11:30:22 +0900 Mamoru TASAKA mtas...@fedoraproject.org wrote: Looks like patching against /usr/include/unicode/urename.h is more appropriate. I wrote some comments on bug 856594. If that saves adding workarounds to a bunch of packages seems like the better solution. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha to slip by another one week
Hi, On Fri, Sep 7, 2012 at 1:36 AM, Jaroslav Reznik jrez...@redhat.com wrote: Today at Go/No-Go meeting it was decided to slip Fedora 18 Alpha release by one week due to remaining open blocker bugs [1] and incomplete test matrices for Alpha [2][3][4]. Meeting's full log is at [5]. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week. The next Go/No-Go meeting is on Thursday Sep 13, same place, same time (19:00 UTC, 3 PM EDT, 21:00 CEST #fedora-meeting-1). If you have an accepted blocker bug, please try to fix it as soon as possible to help us with Fedora 18 Alpha release! How long we are going to wait updates requested for stable? If slip continues for another several weeks, are we going to make wait newly built packages for f18 testing? Test days are going to affect by this. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120825 changes
Hi, On Tue, Aug 28, 2012 at 5:36 PM, Matthias Clasen mcla...@redhat.com wrote: On Mon, 2012-08-27 at 17:39 -0400, Adam Jackson wrote: On 8/27/12 5:38 PM, Matthias Clasen wrote: On Mon, 2012-08-27 at 15:27 -0400, Adam Jackson wrote: That said it's probably less work to grab a copy of pango-1.30.1 and just build compat-pangox from that. I would prefer if we could get a snapshot with the 2 1/2 year old gtkglext change built that removed the pangox dependency. We're talking about API that has been deprecated for three quarters of a decade... Behdad was so nice to quickly put up a pangox-compat module here: http://ftp.gnome.org/pub/GNOME/sources/pangox-compat/0.0/ Do we have a volunteer for packaging that ? I expect this to be a 'package and forget' operation... Packaged this at https://bugzilla.redhat.com/show_bug.cgi?id=852416. Can someone help with its review? Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120825 changes
Hi, On Tue, Aug 28, 2012 at 6:12 PM, Parag N(पराग़) panem...@gmail.com wrote: Hi, On Tue, Aug 28, 2012 at 5:36 PM, Matthias Clasen mcla...@redhat.com wrote: On Mon, 2012-08-27 at 17:39 -0400, Adam Jackson wrote: On 8/27/12 5:38 PM, Matthias Clasen wrote: On Mon, 2012-08-27 at 15:27 -0400, Adam Jackson wrote: That said it's probably less work to grab a copy of pango-1.30.1 and just build compat-pangox from that. I would prefer if we could get a snapshot with the 2 1/2 year old gtkglext change built that removed the pangox dependency. We're talking about API that has been deprecated for three quarters of a decade... Behdad was so nice to quickly put up a pangox-compat module here: http://ftp.gnome.org/pub/GNOME/sources/pangox-compat/0.0/ Do we have a volunteer for packaging that ? I expect this to be a 'package and forget' operation... Packaged this at https://bugzilla.redhat.com/show_bug.cgi?id=852416. Can someone help with its review? pangox-compat package is now built in f19 and for f18, update submitted to f18-testing. Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i18n translation contact
Hi, On Wed, Aug 29, 2012 at 7:47 AM, Dave Young dyo...@redhat.com wrote: Hi, I'm working on the Fedora/Rhel7 firstboot module, and I have some changes to the firstboot module pot files. I wonder who I should cantact for these translating things which are visible to end user. For translation related issues contact to l10n people on tr...@lists.fedoraproject.org list. More can be read at http://fedoraproject.org/wiki/L10N Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120825 changes
Hi Mamoru, On Sat, Aug 25, 2012 at 7:31 PM, TASAKA Mamoru mtas...@fedoraproject.org wrote: Fedora Rawhide Report wrote, at 08/25/2012 09:34 PM +9:00: Compose started at Sat Aug 25 08:15:10 UTC 2012 Broken deps for x86_64 -- [OpenSceneGraph] OpenSceneGraph-examples-gtk-3.0.1-12.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [beldi] beldi-0.9.26-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [celestia] celestia-1.6.1-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [coot] coot-0.6.2-14.20110715svn3566.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ebview] ebview-0.3.6.2-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gabedit] gabedit-2.4.0-3.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gauche-gtk] 1:gauche-gtk-0.6-0.6.20120403gitf7d3f802f3750.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ghemical] ghemical-2.99.2-22.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gliv] gliv-1.9.7-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnash] 1:python-gnash-0.8.10-4.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnubg] 1:gnubg-0.9.0.1-15.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnubik] gnubik-2.4-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gspiceui] gspiceui-0.9.98-7.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkglext] gtkglext-devel-1.2.0-18.fc18.i686 requires pkgconfig(pangox) gtkglext-devel-1.2.0-18.fc18.x86_64 requires pkgconfig(pangox) gtkglext-libs-1.2.0-18.fc18.i686 requires libpangox-1.0.so.0 gtkglext-libs-1.2.0-18.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkglextmm] gtkglextmm-1.2.0-15.fc18.i686 requires libpangox-1.0.so.0 gtkglextmm-1.2.0-15.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkmathview] gtkmathview-0.8.0-10.fc18.i686 requires libpangox-1.0.so.0 gtkmathview-0.8.0-10.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ibus-handwrite] ibus-handwrite-2.1.4-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [k3d] k3d-0.8.0.2-11.fc19.i686 requires libpangox-1.0.so.0 k3d-0.8.0.2-11.fc19.x86_64 requires libpangox-1.0.so.0()(64bit) [pcb] pcb-0.20110918-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [pygtkglext] pygtkglext-1.1.0-13.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ruby-gnome2] ruby-gtkglext-0.90.4-1.9.fc18.1.x86_64 requires libpangox-1.0.so.0()(64bit) [sawfish] sawfish-1.9.0-2.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) pango maintainer, would you explain what has happened? Also would you explain how we should cope with this? And I would appreciate it if you would announce this kind of change beforehand, thank you. (Well, it seems that this change happened 3 days ago, however it seems that I missed this). I am not a pango maintainer but I did rebuild a failed pango-1.31.0-1.fc18 build to pango-1.31.0-2.fc18 build and also rebuilt the same pango build in master branch. About libpangox library its not now provided by upstream pango tarball. Also, I see upstream changelog mentioned like this Remove pangoX been overdue I never thought this library be still in use by other packages. So, didn't informed this to devel list. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji failed build logs
Hi, On Thu, Aug 9, 2012 at 10:04 PM, Orion Poplawski or...@cora.nwra.com wrote: Would it be possible to keep the build logs for the last failed build of a package indefinitely? I will also request for this. When I tried to voluntarily fix some of F18 failed builds, I too face this problem and it takes some time to first scratch-build and then analyze the problems. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Boost and Python 3 in f18
Hi, On Mon, Aug 6, 2012 at 3:21 PM, Petr Machata pmach...@redhat.com wrote: David Malcolm dmalc...@redhat.com writes: On Sat, 2012-08-04 at 21:30 +0530, Parag N(पराग़) wrote: Thanks. But I am getting this error for xs package scratch build. DEBUG util.py:257: -- gc-devel-7.2c-3.fc18.x86_64 DEBUG util.py:257: -- readline-devel-6.2-5.fc18.x86_64 DEBUG util.py:257: Error: Package: boost-python3-1.48.0-16.fc18.x86_64 (build) DEBUG util.py:257: Requires: libpython3.2mu.so.1.0()(64bit) DEBUG util.py:257: You could try using --skip-broken to work around the problem I found this is common build error for some packages in f18 needsbuilt list. I hope those packages will get saved from getting removed from Fedora just because they are failing to build for above error. Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild cleanup
Hi, On Fri, Aug 3, 2012 at 11:28 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, With branching for f18 happening on Tuesday next week we still have quite a large number of failures and packages needing rebuilt. the list of 415 current failures can be found at http://ausil.fedorapeople.org/f18-failures.html while the total rebuild list of 545 can be found at http://ausil.fedorapeople.org/f18-needsbuilt.html please fix them before branching. anything not built will start on the process of being removed from fedora. Can you please fix the script so that it will ignore the new packages that just got their SCM request completed but package not yet built on koji from neeedsbuilt list? I am still confused over the meaning of needsbuilt list. Does that mean packages missed by mass rebuild script as well as failed builds from mass rebuild need to be only listed in needsbuilt list? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.3 (was Re: rawhide report: 20120804 changes)
Hi, On Sat, Aug 4, 2012 at 8:57 PM, David Malcolm dmalc...@redhat.com wrote: On Sat, 2012-08-04 at 12:32 +, Fedora Rawhide Report wrote: Compose started at Sat Aug 4 08:15:03 UTC 2012 Broken deps for x86_64 -- [...snip numerous missing deps of the form requires python(abi) = 0:3.2 requires libpython3.2mu.so.1.0()(64bit) ] I finally pushed python 3.3b1 into rawhide yesterday. https://fedoraproject.org/wiki/Features/Python_3.3 I've rebuilt most python3-using packages, and am slowly working through the stragglers now. Thanks. But I am getting this error for xs package scratch build. DEBUG util.py:257: -- gc-devel-7.2c-3.fc18.x86_64 DEBUG util.py:257: -- readline-devel-6.2-5.fc18.x86_64 DEBUG util.py:257: Error: Package: boost-python3-1.48.0-16.fc18.x86_64 (build) DEBUG util.py:257: Requires: libpython3.2mu.so.1.0()(64bit) DEBUG util.py:257: You could try using --skip-broken to work around the problem I am not able to find boost-python3 subpackage from boost package build. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild cleanup
Hi, On Sun, Aug 5, 2012 at 6:09 AM, Kevin Fenzi ke...@scrye.com wrote: On Sat, 4 Aug 2012 17:51:58 +0530 Parag N(पराग़) panem...@gmail.com wrote: Can you please fix the script so that it will ignore the new packages that just got their SCM request completed but package not yet built on koji from neeedsbuilt list? Why wouldn't they be built as soon as they were added? You are right but I am still finding the answer on what to do in such situations as we have no policy for that. In the past I have done some reviews where even a package SCM is done but reporter didn't import the package at all. For some packages I did it after waiting long. Can we have any solution like block the packages after some time if reporter will not import the package. That way such rel-eng scripts can avoid listing those packages. If anyone want to takeover such package ownership then he can just re-add the package SCM request or submit a fresh review request. Another thing, Its not always possible for a package owner to instantly import the package once the package SCM is done. So, if we still need to show such packages in needsbuilt then I see no solution for this case. I am still confused over the meaning of needsbuilt list. Does that mean packages missed by mass rebuild script as well as failed builds from mass rebuild need to be only listed in needsbuilt list? I think it's any package that doesn't have a successfull build in f18 since the mass rebuild was started. I see that even if I will get my new package SCM done today and this script is run, I can see my package appeared in needsbuilt list whereas it has nothing to do with f18 mass rebuild as my package is totally a new package. Isn't it a regular package process where we actually have no restrictions on when to have a new package process completed? Thanks, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
Hi, On Wed, Jul 25, 2012 at 4:41 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sun, 22 Jul 2012 14:21:10 -0600 Kevin Fenzi ke...@scrye.com escribió: On Tue, 17 Jul 2012 07:39:31 -0500 Dennis Gilmore den...@ausil.us wrote: it was requested in https://fedorahosted.org/rel-eng/ticket/5222 that we do a mass rebuild for Fedora 18 for https://fedoraproject.org/wiki/Features/DwarfCompressor and https://fedoraproject.org/wiki/Features/MiniDebugInfo due to a mix up in dates it was going to start on 2012-07-30 but since that only gives a week to do the rebuild before branching for f18 on 2012-08-07 we will be starting the mass rebuild on 2012-07-18 This is a heads up that it will be done in a side tag and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. The mass rebuild has completed and been tagged back into rawhide, they should appear in tomorrow's rawhide compose. 11057 packages were successfully rebuilt. 656 packages failed to rebuild. Please fix any packages you maintain that failed to rebuild. kevin http://ausil.fedorapeople.org/f18-failures.html http://ausil.fedorapeople.org/f18-needsbuilt.html I don't see iok ever failed to build and caribou has been already rebuilt but still above list has listed it. please update this list. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18
Hi, On Tue, Jul 24, 2012 at 9:40 PM, Bruno Wolff III br...@wolff.to wrote: I'm seeing a few downgrades after the rebuild packages were tagged into rawhide. Were some updates missed and then replaced by packages from the rebuild that shouldn't have been? Downgrading: GMT x86_64 4.5.7-4.fc18rawhide 1.7 M GMT-common noarch 4.5.7-4.fc18rawhide 4.1 M GMT-devel x86_64 4.5.7-4.fc18rawhide 83 k GMT-doc noarch 4.5.7-4.fc18rawhide 33 M GMT-static x86_64 4.5.7-4.fc18rawhide 542 k gmime x86_64 2.6.4-2.fc18rawhide 177 k gmime-devel x86_64 2.6.4-2.fc18rawhide 153 k gmime-sharp x86_64 2.6.4-2.fc18rawhide 37 k gwsmhg noarch 0.13-4.fc18 rawhide 252 k libmash x86_64 0.2.0-6.fc18rawhide 46 k m17n-contribnoarch 1.1.13-4.fc18 rawhide 339 k m17n-contrib-extras noarch 1.1.13-4.fc18 rawhide 94 k mactel-boot x86_64 0.9-2.fc18 rawhide 15 k rapidsvnx86_64 0.12.0-5.fc18 rawhide 354 k setroubleshoot-plugins noarch 3.0.25-2.fc18 rawhide 301 k svncpp x86_64 0.12.0-5.fc18 rawhide 58 k Seems I forgot to update master when updated f17 for m17n-contrib-1.1.13-4.fc17. Fixed now. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: should we install google croscore font as a default font in fedora 18?
Hi, On Thu, May 17, 2012 at 1:34 PM, Caolán McNamara caol...@redhat.com wrote: On Thu, 2012-05-17 at 11:27 +0530, Parag N(पराग़) wrote: Currently, I have marked google-croscore-fonts as a optional package in comps-f18. Considering it has got more orthography support compared to Liberation font can we install it default? But, I would also say that we have active development for Liberation font and if a bug comes for Liberation font we can fix it. The entries that exist in both Liberation fonts and Croscore are basically identical glyphs right ? Yes as I see both the fonts have glyphs developed by same vendor Ascender Corporation. Times New Roman metrics: Liberation Serif, Arimo Courier New metrics: Liberation Mono, Cousine Arial metrics: Liberation Sans, Tinos Arial Narrow metrics: Liberation Sans Narrow, no-equivalent ? So there isn't a Tinos Narrow, right ? Yes. The upstream tarball does not provide any Narrow variant. Is it, at least theoretically, possible for Red Hat to a) relicence the Liberation fonts under OFL and merge in the extra glyphs ? Or are we painted into a corner somehow on that by 3rd party contributions under LGPLv2 ? b) Just create a new font based on the Croscore fonts using the OFL and call it Liberation Fonts 2.0 If we're caught on Liberation Sans Narrow being donated through hdu from Sun/Oracle under the GPLv2, split it off as a standalone Narrow project remaining under the GPLv2 ? I will check this with Liberation font developer. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: should we install google croscore font as a default font in fedora 18?
Hi, Forwarding to devel list for more feedback on this. Regards, Parag. -- Forwarded message -- From: Parag N(पराग़) panem...@gmail.com Date: Thu, May 3, 2012 at 9:31 AM Subject: should we install google croscore font as a default in fedora 18? To: Fedora fonts fo...@lists.fedoraproject.org Cc: Fedora internationalization discussions i...@lists.fedoraproject.org Hi all, The updated package google-croscore-fonts-1.21.0-3.fc17 is now pushed to stable. I have done some comparison of Liberation vs Croscore fonts. See https://fedoraproject.org/wiki/I18N/Liberation_vs_Croscore_fonts Currently, I have marked google-croscore-fonts as a optional package in comps-f18. Considering it has got more orthography support compared to Liberation font can we install it default? But, I would also say that we have active development for Liberation font and if a bug comes for Liberation font we can fix it. I am not sure how a bug can be fixed for google croscore font. I can't find upstream URL as well as a way to fix any upcoming bugs and get its fix upstream. We can fix them in Fedora only. Any thoughts? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120422 changes
Hi, On Mon, Apr 23, 2012 at 3:25 AM, Fedora Rawhide Report rawh...@fedoraproject.org wrote: Compose started at Sun Apr 22 15:54:03 UTC 2012 [fontmatrix] fontmatrix-0.9.99-3.r1218.fc18.x86_64 requires libicuuc.so.48()(64bit) fontmatrix-0.9.99-3.r1218.fc18.x86_64 requires libiculx.so.48()(64bit) fontmatrix-0.9.99-3.r1218.fc18.x86_64 requires libicule.so.48()(64bit) Most of the broken dependencies are due to icu soname bump. I have built fontmatrix against new icu-49.1.1 Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to find out download URL for a given package through code ?
Hi, On Thu, Nov 10, 2011 at 10:11 AM, Kushal Das kushal...@gmail.com wrote: Hi all, I am trying to find the best suitable way to get download URL for any given package ? Say, someone wants to find out download URL for libreoffice-calc-3.3.3.1-1.fc15.x86_64 . The user may not be on a Fedora 15 box. I saw yumdownloader --urls option. Any pointers ? If you have package n-v-r then you can use koji rpminfo n-v-r and from that output grab the build-id and using that you can construct download URL. Also, if you want to download all the binary rpms for that package then you can use koji download-build build-id Parag -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (v3)
Hi, On Fri, Jul 15, 2011 at 1:09 AM, Bill Nottingham nott...@redhat.com wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If not claimed, the packages will be blocked on Monday, July 25. Orphan elfinfo comaintained by: paragn Orphan greadelf comaintained by: paragn For now, I have taken above packages for F15 and devel. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
Hi,
On Thu, Nov 18, 2010 at 1:20 AM, Tom spot Callaway
tcall...@redhat.com wrote:
Here are the list of this week's changes to the Fedora Packaging Guidelines:
The FPC has taken over evaluating exceptions to the Bundled Library
Guidelines. A list of standard questions to be answered to give the FPC
information on whether to grant exceptions has been added to the
Guidelines:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions
---
An exception was added to the Guidelines concerning use of
%{_sourcedir}, specifically, when there is an available list of
supplementary source files, it is permissible to use this list in
conjunction with %{sourcedir} to simplify operations on those
supplementary source files.
https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir
---
rpm %post and %postun scripts have been added for the following
important pieces of GNOME3 technology: GSettings, gdk-pixbuf loaders,
GTK3 modules, and GIO modules:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#gdk-
pixbuf_loaders
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GTK.2B_modules
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules
Thanks for this update. I have seen recently gnome packages started
using these scriptlets but their reference was not in the guidelines
page.
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Kevin Kofler, Matthias Clasen, FESCo and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!
Hi, On Sat, Oct 2, 2010 at 3:52 AM, Hedayat Vatankhah heda...@grad.com wrote: Hi, I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come across this bug[1]. I could discover the initial cause and propose a fix (which, after reporting to freedesktop bugzilla, I found that is already fixed in xkbconfig git (but still should be pushed to F14)). Then, I came across another bug (which is detailed in the end of [1], and is followed at [2] and [3]) which will affect a number of keyboard layouts in F14. In brief, this bug will cause some keyboard layouts to be broken in F14, which IMHO should not go in Fedora 14 Final. I wonder if it can be qualified as a blocker bug. Thanks, Hedayat [1] https://bugzilla.redhat.com/show_bug.cgi?id=638244 [2] https://bugs.freedesktop.org/show_bug.cgi?id=30548 [3] https://bugs.freedesktop.org/show_bug.cgi?id=30549 - I think xkeyboard-config-2.0 has already got some(or all the reported) bugs fixed. I too got some problems in 1.9 build and reported upstream [1]. I am too waiting for 2.0 to be built in F14. Its already built for F15 and working fine. I have sent a mail to xkeyboard-config package owner to build it soon in F14 so that we can have this new build go through bodhi process and reach to stable(GA) repository. Parag. [1] https://bugs.freedesktop.org/show_bug.cgi?id=30233 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: intent to orphan caribou
Hi, On Wed, Sep 8, 2010 at 2:44 PM, Ben Konrath b...@bagu.org wrote: Hi, I'm going to be orphaning caribou in a few minutes. I'm not the maintainer of the upstream project anymore and I don't have extra time to ensure that caribou is packaged properly in Fedora. I hope somebody who is interested in accessibility will pick this up so that Fedora will continue to have the full GNOME accessibility stack packaged. I would like to maintain or co-maintain this package with any other who is also interested for this. Please add me as maintainer for this package. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: krb5-auth-dialog 0.16 for F-13
Hi, On Tue, Sep 7, 2010 at 4:49 AM, Bojan Smojver bo...@rexursive.com wrote: On Thu, 2010-07-15 at 09:29 +1000, Bojan Smojver wrote: Could someone with enough karma rebuild krb5-auth-dialog 0.16 for F-13 (this is in relation to bug #597669). The 0.15 is leaking memory like there is no tomorrow and I'm not getting much traction from the assignee of the bug... Been running 0.16 from Koji for a while now. No signs of trouble. Can this be queued up for F-13 updates, so that other folks get the goodies? I just saw this new build is installing .a and .la files. If .a files are needed then -static subpackage should be created and .la files must not be packaged. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100202 changes
Hi cassmodiah, On Sun, Mar 21, 2010 at 5:00 PM, Simon Wesp cassmod...@fedoraproject.org wrote: Am Dienstag, den 02.02.2010, 16:44 + schrieb Rawhide Report: ibus-m17n-1.2.99.20100202-1.fc13 * Tue Feb 02 2010 Peng Huang shawn.p.hu...@gmail.com - 1.2.99.20100202-1 - Update to 1.2.99.20100202. - Update iok patch. Why does ibus-m17n requires iok? You can see what iok is at https://fedorahosted.org/iok. iok works with inscript m17n keymaps. ibus-m17n also allows to write using these inscript keymaps. So patch is written to add functionality to add icon on ibus panel so that whenever user selects to write using any inscript keymap he can see an iok icon and by clicking on it he can see keyboard layout UI for that keyboard. This helps new user to know which keymappings that keymap provides. Or: Why do add an patch for ibus-m17n iok was present at that time only in Fedora distribution so instead to add above explained functionality in ibus-m17n code, its added as patch. (Now iok is added to Ubuntu also). to require iok? What's the benefit for this? So as we want to see iok showing currently selected inscript keymap in UI, we added iok as Requires: to ibus-m17n.spec Do you see any problem for adding iok as Requires: to ibus-m17n.spec? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
Hi, On Tue, Feb 9, 2010 at 4:07 AM, Roland Grunberg rgrun...@redhat.com wrote: This is just an update to let maintainers know that the changes to LD outlined here : https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking will be in fedora rawhide pretty soon. The details behind what this feature will do, along with how to get failing packages to build can be found here : https://fedoraproject.org/wiki/UnderstandingDSOLinkChange Also, packages that have failed to build under these new changes can be found here : https://fedoraproject.org/wiki/DSOLinkBugs Is it ok to backport changes to F-12 for fixed packages in F-13 for this DSO feature? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
Hi, On Thu, Feb 18, 2010 at 4:26 AM, Kevin Kofler kevin.kof...@chello.at wrote: Parag N(पराग़) wrote: Is it ok to backport changes to F-12 for fixed packages in F-13 for this DSO feature? It's of course OK to apply those changes to all branches (they won't break anything for the older ld), but it doesn't make sense to push updates just for those changes! Please only push updates if you have actual user-visible changes. Thanks all. I just want to know if its possible to apply DSO change in older active branches. No plans to update those packages in older branches but to get these changes in upstream first. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-02-10 x86_64
Hi, fonts-ISO8859-2-1.0-22.fc12 (build/make) pnemade,fonts-sig,i18n-team,pnemade So why is this failed? See the successful koji scratch build = http://koji.fedoraproject.org/koji/taskinfo?taskID=1986768 and then official build for F-13 =http://koji.fedoraproject.org/koji/buildinfo?buildID=156426 Can anyone help to understand this failure report? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
Hi,
On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath rol...@redhat.com wrote:
Replace
make CFLAGS=%{optflags} -X11 %{?_smp_mflags}
with
make CFLAGS=%{optflags} LDFLAGS=-lX11 %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the
upstream package so that it passes -lX11 where it needs it. The most proper
change keeps -lX11 at the end of the link line, rather than the beginning.
But, howcome build succeed with just adding -lX11 to CFLAGS for iok package?
Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
Hi,
On Wed, Feb 10, 2010 at 5:27 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for
now.
They don't belong to CFLAGS, those are flags for compilation. You want
LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it
failed
http://koji.fedoraproject.org/koji/getfile?taskID=1970866name=build.log
This build.log says:
/usr/bin/ld: keyevent.o: undefined reference to symbol 'XKeysymToString'
/usr/bin/ld: note: 'XKeysymToString' is defined in DSO /usr/lib/libX11.so.6
so try adding it to the linker command line
/usr/lib/libX11.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
And actually src/keyevent.c reads:
275 if (key_disable_overwrite) {
276 key_event-keycode = -1;
277 key_event-keysym = 0;
278 g_print(Not allowed to overwrite KeyCode for %s,
279 XKeysymToString(keysym));
280 return;
281 }
You should add AC_CHECK_LIB(X11, XKeysymToString) to configure.in,
for example.
BTW, while you touch this package, it would be useful to fix up all the
warnings, I can't believe doing e.g. strcmp on an array of wchar_t can be
right. It seems with the exception of one wmemset only strcpy/strcmp etc.
are used on keyvalue, so probably keyvalue just should be char array instead
of wchar_t, but you'll need to figure out the right size. E.g. having
[1] sized keyname can't be right when you copy in 1 char long strings and
use strcmp on it afterwards.
Thanks Mamoru and Jakub for your feedback. I will get that code updated soon.
Regards,
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minutes/summary for 2010-02-09 FESCo meeting
Hi, On Wed, Feb 10, 2010 at 3:36 AM, Kevin Fenzi ke...@scrye.com wrote: === #fedora-meeting: FESCO (2010-02-09) === Meeting started by nirik at 20:02:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-02-09/fesco.2010-02-09-20.02.log.html Meeting summary --- * init process (nirik, 20:02:07) * #314 Wordpress bundles libraries (nirik, 20:04:12) * AGREED: will defer this topic until after FPC has discussed the rest of the issues. (nirik, 20:06:01) * #336 Fedora Packaging Committee items for ratification (2009-02-03) (nirik, 20:06:12) * Packaging: SRPM Buildtime macros - https://fedoraproject.org/wiki/SRPM_Buildtime_macros (nirik, 20:06:40) * AGREED: Packaging change is approved. (nirik, 20:08:34) * Packaging: Emphasize correct SF.net SourceURL: https://fedoraproject.org/wiki/PackagingDrafts/SourceURL_sourceforge_downloads_admonition (nirik, 20:08:41) * AGREED: Packaging change is approved. (nirik, 20:10:39) * Packaging: Updated Python Guidelines https://fedoraproject.org/wiki/PackagingDrafts/Python3 (nirik, 20:11:58) * AGREED: Packaging change is approved. (nirik, 20:19:57) * #297 Please consider the idea of a security (privilege escalation) policy (nirik, 20:20:45) * LINK: https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy (adamw, 20:21:46) * AGREED: adamw will add revisions and post to devel list. Will revisit next week (nirik, 20:38:53) * #337 Zarafa - https://fedoraproject.org/wiki/Features/Zarafa (nirik, 20:39:20) * AGREED: Feature is approved. (nirik, 20:51:07) * #275 Propose a soft-path via co-maintainer status to becoming sponsored (nirik, 20:51:27) * AGREED: abadger1999 will draft a new policy for consideration next week (nirik, 21:35:51) * #338: Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert its implementation from pre-branch Rawhide (nirik, 21:35:59) * LINK: https://fedoraproject.org/wiki/DSOLinkBugs is the list (nirik, 21:38:04) * AGREED: This proposal is rejected. The feature will stay in place. (nirik, 21:52:36) * Please announce feature changes that impact other packages on fedora-devel-announce to reach the most maintainers (nirik, 21:54:15) * devel-annou...@lists.fedoraproject.org (notting, 21:55:26) * Helpers pool (nirik, 21:58:55) * Open Floor (nirik, 22:04:00) Kevin_Kofler thanks for raising the issue to revert ChangeInImplicitDSOLinking feature. But, its unfortunate to see FESCo continue it approved. Anyway please someone take care my fontmatrix package. I will still say https://fedoraproject.org/wiki/UnderstandingDSOLinkChange contains insufficient information. Don't ask what to add as I see in my iok package case I was suggested to change configure.in which was not mentioned there. In the example on https://fedoraproject.org/wiki/UnderstandingDSOLinkChange, its written that To fix, add -lrpmio to the gcc command for any binaries that use librpmio. So What's wrong if I modify CFLAGS in iok.spec and build log can show its added to gcc command and build got successful? Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fontmatrix package
hi,
On Wed, Feb 10, 2010 at 10:16 PM, Roland Grunberg rgrun...@redhat.com wrote:
Anyway please someone take care my fontmatrix package.
I was able to get this package to build by adding the following :
--- CMakeLists.txt.old 2010-02-10 11:39:24.0 -0500
+++ CMakeLists.txt 2010-02-10 11:18:55.0 -0500
@@ -120,6 +120,7 @@
SET(PYTHONQT_LIB PythonQt)
ENDIF(WANT_PYTHONQT)
+SET(LIBICUUC icuuc)
SET(fontmatrix_MOC_HDRS
aboutwidget.h
@@ -272,6 +273,7 @@
${SHAPERS_LIBRARIES}
${PYTHON_LIBRARIES}
${LIBPODOFO_LIBRARY}
+ ${LIBICUUC}
)
INSTALL(TARGETS fontmatrix
I added this under if (UNIX and NOT APPLE), but I would assume
the ${LIBICUUC} line needs to be placed under if (APPLE) as
well as if (WIN32)
I'm not sure if this is the best way of doing things, as I
haven't really worked with cmake before, but the package was
able to build.
Thanks. Will check this patch tomorrow. Also, upstream of this is not
reachable since last 3 months. So don't expect this to be upstream
soon.
Parag.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
Hi, On Tue, Feb 9, 2010 at 9:08 PM, Kevin Kofler kevin.kof...@chello.at wrote: Richard Hughes wrote: I've been fixing upstream projects for weeks to build with --no-[add]-needed. The list of projects that fail to build should be much smaller now, especially for GNOME and Freedesktop stuff. 1. But have those fixes been applied in the Fedora packages? At least NetworkManager is now failing to build due to this feature having been rushed in just before the freeze, so that's at least one package which didn't get fixed in Fedora yet. 2. GNOME and freedesktop.org form only a small part of the Fedora package collection. I really don't see why this change can't at least wait for F14! Breaking the build of half of the distro the day of the feature freeze is completely unacceptable. The change should get reverted for F13 and put into Rawhide after F13 gets branched. (I still oppose the feature altogether, but postponing it to F14 would at least give packagers time to fix their packages.) +1. Please revert the changes. Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On Tue, Feb 9, 2010 at 9:14 PM, Roland Grunberg rgrun...@redhat.com wrote: Most of the time upstream (myself included) just forgets to add a library at the end of the LDADD line, so all I had to do was send a trivial patch upstream to add -lm or something. See here for an example: http://bugzilla-attachments.gnome.org/attachment.cgi?id=152993 In fact most of the changes will probably involve a one line addition. As an example, galculator-1.3.4-2.fc12.src.rpm was found to be failing because libm is used but not explicitly linked. RPM build errors: /usr/bin/ld.bfd: math_functions.o: undefined reference to symbol 'sin@@GLIBC_2.0' /usr/bin/ld.bfd: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line /lib/libm.so.6: could not read symbols: Invalid operation The following would fix this and allow the package to build. --- configure.in.old 2010-02-09 10:25:30.0 -0500 +++ configure.in 2010-02-09 10:26:28.0 -0500 @@ -16,6 +16,7 @@ PKG_CHECK_MODULES(PACKAGE, [$pkg_modules]) AC_SUBST(PACKAGE_CFLAGS) AC_SUBST(PACKAGE_LIBS) +AC_CHECK_LIB(m, pow) GETTEXT_PACKAGE=galculator AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, $GETTEXT_PACKAGE, [Name of gettext package]) There's an example at the bottom of the page : https://fedoraproject.org/wiki/UnderstandingDSOLinkChange demonstrating what a failed build message would look like, and how to go about fixing the issue. Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote: Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now. They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS. I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866name=build.log and then modifying CFLAGS its successful build at http://kojipkgs.fedoraproject.org/packages/iok/1.3.9/1.fc13/data/logs/i686/build.log Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Beware: Thunderbird (ver 3.0.1) CORRUPTS all email state
Hi, On Thu, Jan 28, 2010 at 6:47 PM, Steve Dickson ste...@redhat.com wrote: BEWARE! [Bug 559312] thunderbird corrupts mail indices (Old mail marked as new) https://bugzilla.redhat.com/show_bug.cgi?id=559312 For the last 24hrs all my mail state (read/unread, all tags) have been completely destroyed. DO NOT upgrade to version 3.0.1!!! Most of us really take pride in making sure what we push out to the community has been tested and will not be disruptive or destructive. Then there a small group of people that simply don't give a damn what they push out or the havoc they cause. This makes the *entire* community look like crap... Ah! I have already updated Thunderbird and observing this really strange behavior since last 2 days. My goal here is twofold. One alert everyone that your mail will be destroyed if you upgrade to 3.0.1 and to shine light on shoddy work in hopes they will take pride in one, fixing the problem ASAP and two change their process so things like stop happen... IMHO... events like this is the reason why Linux (Fedora explicitly) is having such a hard time being accepted the mainstream Anyway, thanks for this information and hope to see fix soon. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
