Re: Improving our processes for new contributors.
On Mon, 20 Jul 2015 17:34:09 +1000, Nick Coghlan wrote: Don't underestimate the explanatory power of worked examples -snip- Don't underestimate them how? I fail to see what your response has to do with the paragraph from my mail you've quoted. Some of the current (and past) problems with the review queue: - There are more new contributors waiting for a sponsor than sponsors working with those people to turn them into Fedora packagers. - There are poorly made packages in the queue. Sometimes even submitted by approved packagers. Even in dist git there are packages, which would not pass review anymore. In other cases, reviewers have made mistakes, too. - A growing number of new contributors submit only a single package, which is very limited input for a sponsor to review, especially if the single package is flawed. Sometimes it's a library API, and a year later there's still no package using that API = adding a package to Fedora's package collection won't make new API users pop up like mushrooms. - A growing number of new contributors prefers waiting for something to happen instead of following the recommendations and attempting at doing a few reviews. - A growing number of [new] contributors do something completely different than how it has been done for many years, ignoring common practice. This is problematic for potential sponsors and/or reviewers as the packaging guidelines are complex but never complete. You cannot fix this with more detailed guides, worked examples. The opposite might happen: It could be that more beginners would manage to submit a package following examples in trial-and-error fashion, but the real fun starts as soon as the first bug reports are submitted. Handling bug reports and releasing updates cannot be simulated well with Copr. [...] aimed at the relatively common cases like I want to take an existing PyPI package with no dependencies other than Python itself, propose adding it to Fedora, and keep it up to date as upstream make new releases. An attempt at creating package-monkeys? Turning upstream releases into RPM packages is something that literally asks for automation. On the contrary, maintained packages is what adds value to a package collection: responding to bug reports, debugging, bug-fixing, forwarding [enhanced] bug reports to upstream, observing upstream activity/commits/communication, integration testing, ABI/API stability, handling FTBFS issues. That involves a lot of stuff you cannot cover in documentation specific to Fedora. Or you can try to, but it will reach the size of a book. Don't hope for more contributors then. Unfortunately, the presentation of information at the moment tends to focus on the individual steps (e.g. the packaging review guidelines), without first providing that larger context of how software flows from an upstream project *through* Fedora and into the hands of end users. ??? With all due respect, replies like that are reason to stay away from this topic. Which target group do you have in mind? There are various howtos ranging from building a package to submitting an update, or a page covering maintainer responsibilities and update policies. Once a person can access Fedora's infrastructure, only few of the approved packagers run into major problems trying to release an update -- unless a service is down or is affected by bugs. What Fedora must be careful with, however, is not to flood existing contributors with new services that are too experimental. For example, AutoQA reports in bodhi that are false positives and manage to confuse the update submitters. Or, for some time I receive ABRT notifications of the class ABRT report for package XYZ has reached N occurrences, and a bugzilla ticket is missing, and there is no way to ask the reporter to submit a full report. -- 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: COPR fail to build on F20
On Sun, 19 Jul 2015 04:56:17 +0200, مصعب الزعبي wrote: It may be necessary to inform the Copr admins: https://copr.fedoraproject.org/ No contact info or bug tracker ! Don't rush! Notice the footer of the page: https://fedorahosted.org/copr/ and even the FAQ mentioned there: https://fedorahosted.org/copr/wiki/UserDocs#FAQ | | I have a problem. I need to talk to a human | We do not provide support per se, but try your luck here: | https://fedorahosted.org/copr/wiki#Communications - https://fedorahosted.org/copr/wiki#Communications | Want to File a Bug/RFE? | | […instructions here…] -- 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: Non-responsive Maintainer - itamarjp
On the topic of joining the packager group as a co-maintainer, I guess there are enough packages that could benefit from co-maintainers doing an update/commit from time to time. Just been cleaning up crowded mail folders and noticed that Sylpheed 3.4.3 has been released but is not in Fedora dist git or Rawhide yet. And a ticket about a missing appdata file in the package has not been responded to either. The package maintainer(s) may have missed the fact that GNOME Software does not find Sylpheed due to 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: COPR fail to build on F20
On Sat, 18 Jul 2015 14:44:03 +0200, مصعب الزعبي wrote: It fails just since 2 days ago .. not related to EOL .. How do you know it's not related to EOL? How can you tell it's not related to deleting the repos from the servers? Perhaps that has been done just recently? - http://dl.fedoraproject.org/pub/fedora/linux/updates/20/README http://infrastructure.fedoraproject.org/pub/fedora/linux/updates/20/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found F20 has reached end of life: https://fedoraproject.org/wiki/End_of_life -- 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: COPR fail to build on F20
On Sat, 18 Jul 2015 15:42:59 +0200, مصعب الزعبي wrote: Why COPR still allow that .. !!! If COPR wants to keep F20 , it must use new repo URLs .. and fix this issue or remove it from available options .. It may be necessary to inform the Copr admins: https://copr.fedoraproject.org/ -- 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: Improving our processes for new contributors.
On Thu, 16 Jul 2015 23:13:20 +, Zbigniew Jędrzejewski-Szmek wrote: So multiple people arrive at the similar workflow independently... I really think that something like this should be available out of the box for new fedora packagers. Probably as part of fedpkg, but can be somewhere else. Consider filing a RFE about rpm to modify the default rpmbuild tree structure. It may be rejected, because it could be that there are users who like the default. Or a RFE for rpmdevtools' rpmdev-setuptree command, which creates a ~/.rpmmacros setting %_topdir. It could easily redefine other path macros, too. But else, I don't think this would improve the process for new contributors significantly. As one can see, the new contributors manage to submit packages into the queue, and they even point at koji test-builds. One problem is that a growing number of package submitters stop at that point instead of trying to follow the process guidelines -- which recommends providing some more things ahead of 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: Improving our processes for new contributors.
On Thu, 16 Jul 2015 17:53:31 +, Zbigniew Jędrzejewski-Szmek wrote:
One thing which I find very annoying when creating new packages is the
need to use bare rpmbuild commands. I find the split between
~/rpmbuild/{SPECS,SOURCES} anachronistic (*), and much prefer the
fedpkg / distgit approach of having everything in one directory.
I now usually use the single directory approach from the beginning:
- git init new-package cd new-pagkage
- emacs new-package.spec
- spectool -g *spec
- md5sum ... | tee sources
- git add new-package.spec sources git commit -m 'Initial version'
- git remote add ssh://pkgs.fedoraproject.org/new-package.git
- fedpkg --dist master {srpm,mockbuild,etc}
You can redefine %_topdir, %_sourcedir and %_specdir in ~/.rpmmacros,
as well as various other macros, to modify the tree as you like.
--
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: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-13)
On Wed, 15 Jul 2015 21:53:46 +0200, Till Maas wrote: The email is hard to understand. It seems it looks at a dependency tree and somehow lists any leaf package maintainers in an unsorted list of dependencies. What is your proposal to display the information? To display the known dependency-chain (src.rpm names or binary rpm names) as in my reply to twoerner: twoerner: tuned - systemtap - prelink -- 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: Improving our processes for new contributors.
On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote: I do understand where you're coming from: the Fedora workflow is quite complicated What exactly do you find quite complicated? https://fedoraproject.org/wiki/Package_Review_Process ... and learning it sometimes feels like drinking from a firehose. Moreover, the setup evolves and sometimes one ends up drinking from the wrong firehose :). Which is not specific to the review process or the How To Get Sponsored procedure. When I looked into packaging, I found extensive documentation but very few tutorial-style materials. I like the hands-on approach so I wrote a 'user story' about packaging a simple project: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package I think this is a good approach, and could be extended to describe a complete submission process (adding the package in COPR, applying for maintainership, reviewing, etc). Anyone wants to collaborate on that? Well, watching all the people that somehow manage to submit new packages into the review queue, the process up to that point can't be too bad, and one can safely assume they would be perfectly capable of submitting them into Copr, too. But do they want that? Do they want to create a personal repository where users likely don't find the packages? Or do they prefer inclusion of the packages in the official Fedora package collection? -- 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: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-13)
mschwendt: rubygem-rgen First time I hear about that package as I have nothing to do with it. Pkgdb says skottler is the maintainer. The email is hard to understand. It seems it looks at a dependency tree and somehow lists any leaf package maintainers in an unsorted list of dependencies. Let's see: Depending on: rubygem-rgen (31), status change: 2014-05-14 (60 weeks ago) plague (maintained by: dcbw, mschwendt) plague-builder-0.4.5.8-26.fc23.noarch requires mock = 1.2.10-2.fc23 Mock is affected? News to me that it would be based on Ruby modules. mock (maintained by: jcwillia, mebrown, msimacek, msuchy, parasense, praiskup) mock-1.2.10-2.fc23.noarch requires yum-utils = 1.1.31-506.fc23 Ah, Yum utils are affected now? That's Python based. yum-utils (maintained by: packaging-team, agk, james, maxamillion, timlau, vmukhame, zpavlas) yum-plugin-puppetverify-1.1.31-506.fc23.noarch requires puppet = 4.1.0-2.fc23 Oh, an optional Yum plugin is affected only, which indirectly depends on rubygem-rgen. puppet (maintained by: kanarip, domcleal, gchamoul, georgiou, jehane, jpo, lzap, mmagr, moses, rharrison, skottler, stahnma, tmz) puppet-4.1.0-2.fc23.noarch requires rubygem(rgen) = 0.6.6 -- 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: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-13)
On Tue, 14 Jul 2015 12:04:13 +0200, Thomas Woerner wrote: On 07/14/2015 12:40 AM, opensou...@till.name wrote: prelink jakub, mjw60 weeks ago ... twoerner: prelink There seems to be a bug in your script ... No, what it tries to tell you is that you depend on prelink indirectly via tuned - systemtap - prelink. It just doesn't make that clear. -- 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: Sponsor shortage
On Sun, 12 Jul 2015 08:58:37 -0500, Rex Dieter wrote: I like to think of being a sponsor as an exciting opportunity to shepherd new contributors to fedora. Quick approval of an account based on reviewing a single tiny package is not an option for me anymore. I've done that before. I've been burnt before. I patiently explain things in private mail, sometimes for a long time. But some people are pissed off too easily by something, such as a new version of Fedora breaking something, or are distracted by something more interesting and are not nice enough to notify the project. Once more, it is too frustrating to see somebody leave the project silently because of various factors (sometimes not even related to Fedora). A single package (and lack of activity) is not enough for me anymore to decide whether to approve an account. So, I'm still active in the queue, but I watch out for active contributors, who don't want to push a single tiny package into the dist only without doing anything beyond that. Sometimes it's years old code (such as a Python module) with no dependency. And after several months there's still no dependency in the queue. To me that doesn't make much sense. Taking the attitude of It's too hard... (mostly) because it will be a lot of work to turn them into good packagers, is... less than constructive here, imo. Those are your words, and they don't sum up what I've pointed out in this thread. My blunt suggestion: if that bothers you, then help clean out the queue. No. That tiresome with NEEDINFO, urging submitters to respond, waiting several weeks before closing the ticket. And later getting blamed somewhere in the comments of some blog post when some Fedora politician talks about how to simplify the process (as in this thread). Further, I think it's more than just a sponsor shortage, but a *reviewer* shortage too. And a shortage of motivated new contributors. If only all packagers would strive to do at least as many reviews as packages they've submitted, I think we wouldn't be having this conversation. Hrm, an interesting metric I'd love to see: for all packagers, calculate ratio of pkg-reviews / pkg-submissions-approved, and give big kudos to anyone near 1 or higher (probably with some minimal numbers to be fair here, ie for anyone with pkg-reviews and/or pkg- submissions greater than, say, 5) -- Rex p.s. Heck, for the amount of effort put into this thread so far, I'd venture at least another few reviews could have been done You can find plenty of reviews and reviews related comments from me in the queue(s). -- 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: Improving our processes for new contributors.
On Sat, 11 Jul 2015 17:40:11 -0700, Les Howell wrote: I talk about all this because when you have someone who is interested, and even motivated enough to get involved, where does one go to learn the accepted techniques and support systems as a total newbie to the process? Do you have a link to an educational process? Are people greeted and provided links and encouragement? Where and who knows the requisite information to get started? It would have been much better, if you had given it a try with a comment on what you would had found out. The default home page in Fedora's Firefox: - http://start.fedoraproject.org/ Want to contribute to Fedora? Join us: - https://join.fedoraproject.org/ - http://fedoraproject.org/wiki/Join - http://fedoraproject.org/wiki/Join#OS_Developer - http://fedoraproject.org/wiki/PackageMaintainers/Join I have personally given up on the idea of contributing directly, Saying that without giving a rationale is a useless comment. but there are others out there that you might capture if the tools and introduction are good. True. And still one can meet least effort new packagers, who avoid playing with Mock and koji (Fedora's build system) although the process documentation explicitly points at it and the instructions to do so-called scratch-builds for testing. Eventually, a reviewer will ask for koji builds, and then there's silence for a long time, because it's the time to start looking into tools that are relevant to Fedora packagers. -- 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: Sponsor shortage
On Sun, 12 Jul 2015 09:53:23 +0100, Jonathan Underwood wrote: What I'm getting here is that you have a very clear aspirations and expectations of what activities a new contributor should be engaging in. The questions I think are interesting are: a) Are we making these expectations clear enough to new contributors? b) Are we using our available tools and mechanisms optimally to facilitate and encourage those activities? I would welcome your thoughts on those two points (and anyone else who wants to contribute, of course). Nowadays, I would likely shift the prerequisites to highlight the importance of - the fedora-review tool - Mock, as needed by fedora-review and used by koji - koji, the Fedora Build System New packagers MUST attempt at doing a self-review with the help of the fedora-review tool, i.e. honestly try to fill in the '[ ]' items. New packagers MUST become familiar with Mock at the level of being able to do local test-builds. New packagers MUST become familiar with koji at the level of being able to do scratch-builds and handle errors in build.log and root.log. Add to that familiarity with bodhi web, Fedora's Update System web page, i.e. where to find it and leaving karma points on updates. Bodhi CLI as a bonus. -- 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: Sponsor shortage
On Sun, 12 Jul 2015 11:54:47 -0600, Stephen John Smoogen wrote: On 11 July 2015 at 16:09, Michael Schwendt wrote: On Sat, 11 Jul 2015 11:45:13 -0600, Stephen John Smoogen wrote: and I will probably also find that those packages have 'accepted' differentiation because no one wants to get into a political fight over XYZ package ever again. And how would you like to fix that? By making packaging guidelines more lax? By removing the review process, so _every_ packager may decide whether not to adhere to the guidelines? Wow do you have any more words you want to stuff in my mouth that I supposedly want? Thank you for reminding me why I don't want anything to do with packaging anymore. I am done here. I've asked questions, not stuffed words into your mouth. But great, running away is easy. -- 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: Sponsor shortage
On Fri, 10 Jul 2015 17:24:26 -0600, Stephen John Smoogen wrote: This is a vicious cycle. A lot of sponsors are burnt out on trying to deal with new people who don't seem to have a clue. Laziness, lack of activity, lack of interest, sloppy packaging, dumping-ground/fire'n'forget mentality, there are various factors. Sometimes it's cluelessness, yes. Paired with no interest in reading guidelines, since the self-made package builds. And lots of people think why create an RPM package, if compiling from scratch in trial-and-error fashion seems to produce something? Over the last years I've talked to quite some people. Some simply find the package review process too embarrassing, because the tickets are world-readable. Once they learn that the package they offer is full of mistakes, they consider it public shaming and would like to delete the embarrassing ticket and restart from scratch. In some cases this has lead to doing early reviewing and guiding in private email, but with mixed results, such as people starting to argue about guidelines or how to do something. Sponsoring someone based on a single package only to find out the person leaves the project again before handling the first few bug reports is very disappointing for sponsors. And a lot of potential new people feel burnt to the crisp by reviews and expectations of being wed to a package for life when all they wanted to do was help someone else use some software. That's painted in too dark colours. The review process turns up too many mispackaged pieces of software, where the packages have not been tested at all. Offering such packages would be a poor choice. You can hope for random volunteers to take care of thousands of packages in a dumping ground whenever they feel like spending time on arbitrary packages, but that won't work. It is doomed to fail. Once a package is included in the distribution, there is much more work to do compared with the review process. And wanting to help? Lots of packages would benefit from better bug reports (more responsive reporters) and communication between upstream and downstream. A dumping ground won't help here. All you achieve by talking about lowering the hurdles it that the current new contributors prefer waiting for the Fedora Project to announce something, such as getting rid of the review process, a dumping repo for unreviewed packages, or automatic blanket-approval of new packagers. -- 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: Sponsor shortage
On Sat, 11 Jul 2015 19:44:39 +0200, Haïkel wrote: @Stephan: this is hardly readable, I don't what is quoted and what's your answer. Claws Mail has no trouble displaying the message. It's a multipart/mixed encoded message with several parts. One is text/plain and well-formatted. Hint, hint. ;-) -- 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: Sponsor shortage
On Sat, 11 Jul 2015 11:45:13 -0600, Stephen John Smoogen wrote: I agree that lowering hurdles is not good and I don't want to lower hurdles, I want to fix broken ones. 1) Parts of reviews come across as arbitrary nitpicks. You put a package into 3 different reviewers.. you will get 3 different sets of fixes that seem to need to be made. And if you re-review packages, which are included in the distribution already, you run into bad examples. It happens occasionally that new packagers copy from an existing Fedora spec file in good hope that it would meet the packaging guidelines, but it doesn't. For a more serious response: I don't know how to fix the reviewers, who still request packagers to apply special indentation or other cosmetic changes to a spec file. However, it is good that some reviewers are experienced and point out pitfalls and mistakes not covered by the guideslines [yet]. These are cases that may develop into somebody asking the FPC to extend/enhance/improve the guidelines. 2) Reviews and fixes against existing packages aren't done. So if I base my package off of various high profile packages in Fedora already I won't pass review.. That's sounds like what I've pointed out above. Some people like convoluted spec files and strange packaging, and there's not much ordinary packagers can do about that. Some people love argueing about the guidelines, such as where to place .so symlinks. Some love coming up with reasons to violate the guidelines. It's the FPC's and FESCo's job to fix that, if necessary. and I will probably also find that those packages have 'accepted' differentiation because no one wants to get into a political fight over XYZ package ever again. And how would you like to fix that? By making packaging guidelines more lax? By removing the review process, so _every_ packager may decide whether not to adhere to the guidelines? Or is it time after several years to revisit the Review Guidelines and reduce them to a fresh list of most important items packages MUST/SHOULD do properly? 3) Reviews get lost in limbo for some percentage of people with no way of getting them back on track. Then when someone searches for reviews to get an idea of how to do them.. those are the open ones that show up. Again, what do you want to fix here? Encourage new packagers to follow the How To Get Sponsored guidelines? Encourage existing packagers to swap reviews with eachother? A primary problem here also is that people offer extremely niche market packages, i.e. with a very limited target group. That could mean nobody else is interested in such packages. Not even users to take notice of the review request and contribute testing results. Spending time on such packages would be a hard decision, too. For example, and not limited to that, I've seen an unfinished remake of a Bard's Tale Construction Set in the review queue. It may be fun for the submitter to get it included in the dist, but many a reviewer simply does not consider it worthwhile to work towards that goal. 4) Teaching of how to do basic reviews is RTFM with a Good Luck to Find the Right FM as an unspoken corollary on our mountain of dead wiki pages. I have seen more than enough IRC conversations of A: I would like to do something, what can I do? B:Review a package. A:OK how do I review a package? B: Read through these docs ... url1, url2, url3 C: Oh don't use those URLs they are out of date. With all due respect, such an example is plain silly and hard to believe. https://fedoraproject.org/wiki/Category:Package_Maintainers - https://fedoraproject.org/wiki/Package_Review_Process B: Oh when did that happen C: Oh we decided to drop that part and went to this new system... hmmm it says that is obsolete. Oh well someone will know. A:... two days later D: Why didn't anyone tell A to talk to me. B,C: Who are you and why would we... Is it really that bad on IRC these days? Why don't people mail devel@ anymore these days? Or the person goes over to the SIG mailing list or irc group asks a question and doesn't get a reply at any time.. then it is usually.. Why do we even have this SIG if no one is working on things. Someone should do something about that! I've never understood the rules about when to create a new mailing-list and when not. A good rule of thumb is to create a new list only if there's enough traffic for it. Empty/silent/abandoned lists are scary. Same for lists with poor/missing descriptions and nobody who fixes it - https://lists.fedoraproject.org/mailman/listinfo So enough whinging. How can we fix this. How do we make it clear which pages are to be used to learn how to review a package because Google seems to show me different pages depending where I physically search from versus the same list every time. Examples, please. Which pages do you refer to? How do we deal with our existing mountain of packages to see if they are still in line with reviews? What does
Re: Sponsor shortage
On Sat, 11 Jul 2015 14:37:05 -0400, Ben Rosser wrote: I don't really want to turn this thread into a why didn't I get sponsored sooner? thread (and in fact, looking back, I'd guess not linking the two informal reviews I did wasn't a good thing). But since I brought it up... https://bugzilla.redhat.com/show_bug.cgi?id=823679 In fact, you yourself were the first reviewer. I guess I could have emailed you privately, but... More interesting is: What has happened between 2012-09-20 and 2014-07-28? No comments, no version updates. == A lost opportunity to practice maintaining the package, and a lost opportunity to demonstrate your interest in the package. I mean, if you've packaged it and use it, why would you ignore the several new releases and not even comment on them? And almost two years are a lot of time to attempt at doing a few reviews (even if only other Python based packages). And no questions about the process in two years? == That's the classical sit-and-wait passively scenario I've pointed out. Of course, some packagers only show impatience and repeatedly post one-line ping-like comments, such as So, is the package ready to be included? instead of referring to the process howtos and specific steps to be done. A lost opportunity to show that you're aware of the documentation and familiar with where to find it. I assumed that eventually someone who was a sponsor would review my package and tell me what they thought of it. Then maybe ask me to do a few more things, maybe a few more reviews. Tell me what they thought I needed to work on, etc. And, I mean, that eventually did happen. So I guess the system worked. It just took a long time to work longer than I would have expected from only reading the documentation on the wiki. What's extremely broken here is that in two years nobody else has shown interest in this package. No users, no other packagers. When somebody has not submitted a single ticket in bugzilla, not even via ABRT, one can not even be sure the person is using Fedora. So you're saying that reporting bugs against other components in the distribution that aren't necessarily packages is a thing that we are looking for in potential new packagers? That seems reasonable. But this is not indicated on the How To Get Sponsored page. Hiding somewhere (or hiding behind a pseudonym/nickname on IRC) doesn't lead to anything at all. I see a real name in the review queue, I don't know it yet, and I don't see the same name anywhere else related to Fedora either. Putting the person's email address into bugzilla's monitoring list, I see no activity. No comments on other packages in the review queue. No bug reports. No activity at all. No way to get to know that person. That's even problematic when somebody is using a different dist and is only trying to push a package into the collection without interest in maintaining it later. I thought the point of the sponsorship system was to help mentor potential new contributors until they reached the point where someone thought they were competent enough and sufficiently well-versed in our guidelines. While simultaneously providing a hurdle from preventing just anyone from contributing low-quality packages into the distribution. Based on a single tiny package it's not possible to tell whether somebody is competent enough. So, activity and creativity can make a difference. There are sponsors and new packagers, who work on reviews [of other packages] in private email rather than in bugzilla. Nobody is forced to perform possibly wrong (and embarrasing) reviews in bugzilla to get sponsored. Sometimes you can also negotiate with a potential sponsor, which doesn't mean to bribe him, but perhaps tell a few things about your packaging background, such as a personal repo you offer somewhere. Activity is the key in many cases. -- 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: Sponsor shortage
On Fri, 10 Jul 2015 14:31:52 +0100, Jonathan Underwood wrote: Hi, Today I happened to look at this page: http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html from which I can see we have potentially on the order of 100 new potential contributors to Fedora whose efforts we're missing out on due to a lack of sponsors. Some people seem to have been waiting to be sponsored for a couple of years. This is quite an unfortunate situation - what can we do to improve that situation? How many *active* packaging sponsors do we currently have? How many *active* NEEDSPONSOR contributors do we have? There are many in the queue, who submit a single package with lots of mistakes -- or the package not building at all -- and slow response times in bugzilla, or no response, and who don't follow the How To Get Sponsored guidelines either. With a bit more activity, it would be easier to get sponsored. But sponsoring someone based on a single package is a hard decision. I'd like to see more motivation from new packagers, as pushing packages through review often is much easier than maintaining the package in the Fedora dist for some 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: Sponsor shortage
On Fri, 10 Jul 2015 15:25:05 -0400, Ben Rosser wrote: Speaking as someone who relatively recently went through the process though (and whose package(s) sat in the review tracker for two years): motivation is hard to come by when it looks like you're not going to get sponsored because (you think) nobody cares about your package. ??? When exactly in the process does it look like you're not going to get sponsored? After a week? After a month? After having done 2-3 reviews and linked those reviews in the needsponsor ticket(s)? After having pointed at that work in a post to devel@ list? I would need to see your initial review requests to comment on this issue further. Nowadays, I consider the review queue as very tiresome. I've commented on many tickets, I even have made clear behind my name in bugzilla that I'm in the packager sponsors group, but nobody has taken that as opportunity to email me privately. The time when new contributors did that is gone. There are too many in the queue, who sit and wait passively, sometimes even without keeping a single package up-to-date. They do not take the opportunity to practice maintaining the package. And they do not demonstrate high interest in the package either. It doesn't count if there's some private [hidden/secret] repo somewhere where updates may be published. All that matters is what the volunteer offers in the review queue and/or visible to the sponsor. When somebody has not submitted a single ticket in bugzilla, not even via ABRT, one can not even be sure the person is using Fedora. And yes, I did read the guidelines, and yes, I did review other packages in an informal capacity (at least initially). I think (although it's been a long time, so I may have forgotten) I even poked the devel list a couple of times early on, but the guidelines ( https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group ) stress that sponsorship is kind of a passive process. While there are things you can do to increase your visibility, you wait for someone to notice your package, you shouldn't mass mail people asking for a sponsor, etc. A don't call us, we'll call you sort of process. And yet there are too many, who dump a first src.rpm into the queue without doing anything beyond that. No self-review, no review of other packages, no questions, not even mailing a potential sponsor who is active in other tickets. This is extremely disappointing for the sponsors, too. Then, once someone *does* notice your package, maybe they work with you on improving it, ask you to do a few other things, etc. And it becomes a more active process on both sides. At least, that's been my understanding of the process based on what I've read in those guidelines. That's one way how to do it. Unfortunately, some of the needsponsor people don't respond. Some respond after months, saying they have been busy. No notification of that in the ticket. No response! What would happen if the package were in the distribution? Somebody would start the non-responsive maintainer procedure. It doesn't work, if new contributors prefer a dumping ground for packages, because they read about such things somewhere (such as plans on additional pre-approval package repos, or Copr, or even other plans). But there are tickets in the queue that have sat there for at least a year with no subsequent comment by another other than their author-- which likely means their author is waiting for someone to take a look at the most recent set of changes to their package. In some cases, there is no comment at all by anyone other than the author. Why is that? A year is a lot of time for studying the Wiki, the guidelines, the review process, the review guidelines and attempting at doing at least one or two reviews. A year is also a lot of time for a bit of activity in bugzilla or on mailing-lists. So, when a potential sponsor searches bugzilla for the person's email address, the results would show that the person has reported a bug before or has left comments in tickets. No activity beyond a src.rpm (in enough cases fetched from openSUSE or other dists) is not good. It wouldn't be a bad thing, IMO, to (automatically?) ping sufficiently old tickets with a sort of what's the status on this and maybe a link to the sponsorship guidelines reminding them that there are other things they can do if they still want to become a packager. It's too tiresome IMO. Pinging is frowned upon in other tickets, too. Just be responsive, keep track of a single ticket that is important to you because you need it for the sponsorship process. It is severely demotivating for reviewers as well as sponsors to get no response to reviews they post in the tickets. Here are some examples of tickets that have been left languishing with no word for quite some time. Some of the Spec/SRPM URLs in these no longer work anymore, which tells me it's definitely been a long time since anyone even looked at them.
Re: DNF and regular expressions
On Mon, 29 Jun 2015 20:32:46 +0200, Reindl Harald wrote: I've read the rest of the thread, but note that rpm -qa based queries piped to xargs rpm -e still work fine for a package removal task like this that may be true but you hardly can sell DNF as improvement if you need such workarounds while YUM worked perfectly for many years while working around the package manager in general should be avoided because no longs, no dependency solving and no useful confirmation Well, it's not me who's trying to sell DNF as improvement. Rather the opposite. I'm not a fan of it yet. Examples found in various places on the Internet: # dnf whatprovides libtoolize Using metadata from Sun Mar 22 23:13:16 2015 Error: No Matches found # yum whatprovides libtoolize libtool-2.4.2-32.fc22.x86_64 : The GNU Portable Library Tool Repo: fedora Matched from: Filename: /usr/bin/libtoolize Or this: # dnf search pkg-config Last metadata expiration check performed 1:21:31 ago on Tue Jun 30 09:51:23 2015. === N/S Matched: pkg-config rubygem-pkg-config.noarch : A pkg-config implementation by Ruby rubygem-pkg-config-doc.noarch : Documentation for rubygem-pkg-config mingw32-pkg-config.x86_64 : A tool for determining compilation options for the : win32 target mingw64-pkg-config.x86_64 : A tool for determining compilation options for the : win64 target perl-ExtUtils-PkgConfig.noarch : Simplistic interface to pkg-config python-pkgconfig.noarch : A Python interface to the pkg-config command line tool python3-pkgconfig.noarch : A Python3 interface to the pkg-config command line : tool D'oh! It only examined package name and summary, but the package name is pkgconfig, and hence it only found irrelevant packages and cannot be told to search files inside packages. No, dnf search all … only adds package description and URL to search within. given that the dnf autocompletion is also horrible slow comapared with YUM i see still no advantages from the change, try yum clTAB versus dnf clTAB, in case of DNF it feels like a network request Completion is one of the first things I disable, since it has crept into tools like a disease and is completely broken for me. Various bug reports have not been responded to. Completion with yum-builddep always looks at the repos. Painful. -- 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 regular expressions
On Mon, 29 Jun 2015 12:12:57 +0200, Germano Massullo wrote: What is wrong with DNF's regular expression # dnf remove *debuginfo*.fc20.x86_64 ? I am on F22 but I have a lot packets that should match that regular expression, but dnf does not find them. I also tried to add some escape chars like dnf remove *\-debuginfo\-*.fc20.x86_64 but the result is the same I've read the rest of the thread, but note that rpm -qa based queries piped to xargs rpm -e still work fine for a package removal task like 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
Re: mate-dialogs obsolete in F22
On Tue, 09 Jun 2015 11:18:06 +0200, Jakob Hirsch wrote: Hi, I just upgraded to F22 and noticed, that mate-dialogs was uninstalled and cannot be reinstalled due to mate-desktop having an Obsoletes entry for it. The corresponding changelog entry is quite short: * Sat Jul 12 2014 Wolfgang Ulbrich chat-to...@raveit.de - 1.9.1.1 ... - obsolete mate-dialogs for f22 What was the reason for this? matedialog works quite well on F22 ( installed the rpm with --nodeps) and I could not find a replacement for this tool, so I'm left a little puzzled... Answering that in the %changelog comment would have been a great idea. Pkgdb does not reflect the obsolete state of that package: https://admin.fedoraproject.org/pkgdb/package/mate-dialogs/ It is not retired in dist git either: http://bugz.fedoraproject.org/mate-dialogs - http://pkgs.fedoraproject.org/cgit/mate-dialogs.git - http://pkgs.fedoraproject.org/cgit/mate-dialogs.git/tree/ Plenty of Obsoletes tags that are non-versioned, which is a packaging mistake, because non-versioned Obsoletes names cannot be reintroduced: http://pkgs.fedoraproject.org/cgit/mate-desktop.git/plain/mate-desktop.spec https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages -- 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: HTTP request sent, awaiting response... 404 Not Found
On Thu, 04 Jun 2015 12:27:52 +0200, Antonio Trande wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
is there something wrong with my commit or with koji?
https://koji.fedoraproject.org/koji/getfile?taskID=9943933name=root.logoffset=-4000
DEBUG util.py:452: Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
'PROMPT_COMMAND': 'printf \x1b]0;mock-chroot\x07mock-chroot',
'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir',
'HOSTNAME': 'mock'} and shell False
DEBUG util.py:388: --2015-06-04 10:23:44--
http://pkgs.fedoraproject.org/repo/pkgs/sundials/sundials-2.6.1.tar.gz/9be03633999884f53b224fd152fb919f/sundials-2.6.1.tar.gz
DEBUG util.py:388: Resolving pkgs.fedoraproject.org
(pkgs.fedoraproject.org)... 10.5.125.44
DEBUG util.py:388: Connecting to pkgs.fedoraproject.org
(pkgs.fedoraproject.org)|10.5.125.44|:80... connected.
DEBUG util.py:388: HTTP request sent, awaiting response... 404 Not Found
DEBUG util.py:388: 2015-06-04 10:23:44 ERROR 404: Not Found.
DEBUG util.py:388: --2015-06-04 10:23:44--
http://pkgs.fedoraproject.org/repo/pkgs/sundials/sundials-pkgconfig_files.tar.gz/8e713e81e47e4cc0ebb98b1aaf4465b5/sundials-pkgconfig_files.tar.gz
DEBUG util.py:388: Resolving pkgs.fedoraproject.org
(pkgs.fedoraproject.org)... 10.5.125.44
DEBUG util.py:388: Connecting to pkgs.fedoraproject.org
(pkgs.fedoraproject.org)|10.5.125.44|:80... connected.
DEBUG util.py:388: HTTP request sent, awaiting response... 404 Not Found
DEBUG util.py:388: 2015-06-04 10:23:44 ERROR 404: Not Found.
Both files specified in the sources list give 404 not found.
Have you tried uploading them again?
--
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 22 and missing applications
On Tue, 26 May 2015 16:33:19 +0100, Richard Hughes wrote: http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html It kinda sucks that you list a No keywords in .desktop file warning for almost all packages even if they meet the packaging guidelines and the specific requirements of the F22 development cycle, i.e. running appstream-util validate-relax on the appdata file and desktop-file-install on the .desktop file. Normally one uses the development period to fix such issues. What is that warning about? There is no such warning in the build.log output: + desktop-file-install --dir /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/applications /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/applications/audacious.desktop + install -D -m0644 contrib/audacious.appdata.xml /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml + appstream-util validate-relax --nonet /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml /builddir/build/BUILDROOT/audacious-3.6.1-3.fc22.x86_64/usr/share/appdata/audacious.appdata.xml: GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. OK -- 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 22 and missing applications
On Wed, 27 May 2015 12:47:04 +0100, Richard Hughes wrote: It's not only the green applications that make the cut, the amber ones go in too. Okay. Glad to hear we're not supposed to fix something like that post release. Having keywords makes the search functionality much better, but isn't actually required for your application to be shown in the software center. What would they add that's not found within the RPM package %description and %summary already? It would be disingenuous at best to show OK and use a green line when we're missing this extra data. I'll probably start nagging people about missing keywords in F23, i.e. real soon now. There is no such warning in the build.log output: I guess we should make desktop-file-validate check for keywords too, although they're not actually *required* to be a valid .desktop file. Anything that *upstream* would see, too, would be the best solution. Else it becomes a continuous race of upstream releasing files that follow the specs, and Fedora asking for extra optional (!) things to be added just to get rid of some warnings. Not even considering the translations of such keywords. -- 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: libvpx got soname bump and no one noticed?
On Wed, 27 May 2015 22:39:30 +0200, Marcin Juszkiewicz wrote: F22 got released so I upgraded my machine from F22 to rawhide. But as usual it meant rebuilding rpmfusion packages (as they do not support rawhide). All went quite good. Except installing: Error: package ffmpeg-libs-2.6.2-3.fc23.x86_64 requires libvpx.so.2()(64bit), but none of the providers can be installed. Why's that? libvpx 1.4.0 bumped libvpx.so.1 - libvpx.so.2 and I did not found any mail about it on fedora-devel ML (maybe such mails are not required, no idea - many such were sent). Most of rawhide is built against libvpx 1.3.0 so old soname is required. spot did the upgrade and rebuilds. See e.g. the %changelog entry in package pcb from early April. Simple 'dnf remove libvpx.so.1()(64bit)' on my rawhide shows 512 packages including wine, kde, gstreamer plugins and lot of other stuff. A lot less than 512: $ repoquery --whatrequires libvpx|grep -v i686|wc -l 54 And that's with the default --alldeps already. Yet the daily rawhide report does not list any broken dep related to libvpx. It seems to me all deps have been rebuilt. How to solve it? I am afraid that answer would be wait 2 months, we will slowly solve it by new uploads ;( Get rpmfusion to rebuild, too. http://bugzilla.rpmfusion.org if necessary. -- 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: ABRT report for package soundconverter has reached 10 occurrences
On Wed, 20 May 2015 20:50:10 + (UTC), notifications fedoraproject org wrote: Packages: soundconverter Function: change_mime_type Firtst occurrence: 2015-05-20 Type: python Count:10 URL: http://retrace.fedoraproject.org/faf/reports/bthash/904ea88a8ddd561298140d2978da9d25c89fb915/ It could be more productive to submit a bug report in bugzilla. Based on only the source line numbers in this shortened report, it seems somebody either has been using a damaged installation, where GStreamer has been damaged, or has tried to hack additional encoder MIME types into the 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
Re: fedora-review karma.
On Mon, 04 May 2015 18:55:50 +0200, Reindl Harald wrote: fixing the reasons for fedora-easy-karma timeouts most of the time would in general help for karma - i guess i am not the only one having updates-testing and sometimes koji-repos enabled and refuse to seek for the installed packages on a website That timeout can be increased with a one-line patch: https://bugzilla.redhat.com/1216098 -- 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't give package to another developer
On Wed, 29 Apr 2015 10:52:09 +0200, Jan Synacek wrote: I'm trying to give one of my packages (openldap) to another developer, but the online tool keeps saying that User is not in the packager group, which I believe is not true, because he is in the same Fedora groups as I am. Where can I report this? Cheers, Look up his account group membership at the following URL: https://admin.fedoraproject.org/accounts/user/view/USERNAME Replace USERNAME with his FAS username. Some packagers use multiple email addresses in bugzilla and multiple usernames for different places and don't remember the FAS username correctly in some cases. -- 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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again
On Fri, 24 Apr 2015 05:14:27 -0400, Felix Miata wrote: Why does this bug exist only in Fedora, not in openSUSE or Mageia or *buntu? All my systems are multiboot, so only a select very few are on UTC. None that are on UTC have Fedora installed. This means every Fedora boot takes about twice as long or longer than anything else takes, waiting on all the unnecessary FS checks. Me too. It's on my growing list of breakage to observe. Haven't spent any time on it yet. Logical volumes getting checked nearly at every reboot. journalctl shows entries which are two hours in the future at boot time, then it returns to the correct time afterwards. I remember there have been issues like that years ago - I don't think I've had to do anything special to work around it, but perhaps I'm wrong and need to search in my notes. Currently, it's broken again. -- 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: Making 3rd party gstreamer codecs work in F22
On Sun, 26 Apr 2015 20:53:12 +0200, Andreas Tunek wrote: I of course do not want to tell anyone what to spend their time on, but do you not think that this effort would be better spent helping the 3rd party repos (rpmfusion) getting ready for F22 than building compatibility layers? Well, they could simply configure their buildsys to add a build target for F22. The same buildsys that's still being used to build for F21 and older. Based on Plague and Fedora Extra pushscripts. Instead, everything has been put on ice. Info on their mailing-lists is sparse. Not even packagers and users are informed. There are a few tickets in bugzilla that don't give a hint either. Years ago it has been planned already to migrate to git, koji, bodhi, pkgdb and other infrastructure pieces as known from Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bodhi buildroot override takes how long?
It's some time since I've had to submit a koji buildroot override via the bodhi web interface. It has become much more slower. First of all, the admin.fedoraproject.org server answers slower. And the koji wait-repo command has yet to end. What is the current estimate on how long it takes for bodhi to process a buildroot override request? koji lists a tag f22-override for the build, but that's not the tag I need to query. bodhi says f22-build. I see other requests that have not been processed yet with the same symptoms. How long does it take nowadays? -- 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 search as braindead as yum search
On Tue, 24 Mar 2015 06:15:41 -0400 (EDT), Jan Silhan wrote: I get the same result from dnf search and yum search. It wasn't found in package name nor summary so it's searched in description. IMO, it ought to search in filelists either by default or when specifying the all argument (which is misleading since all != everything anyway). DNF doesn't match substrings by default in (what)provides command. You have to use '*': e.g. `dnf whatprovides *libtoolize` [1]. There are other counter-examples: # dnf search mouse dpi tool|wc -l 3144 Too much lines of output for a human-being to parse, especially since the top of the list doesn't ring a bell: kmousetool.x86_64 : A program that clicks the mouse for you xdotool.x86_64 : Fake keyboard/mouse input # dnf search mouse dpi tool|grep -i matched === N/S Matched: mouse, tool === == N/S Matched: tool === == N/S Matched: mouse == === N/S Matched: dpi === == N/S Matched: tool === == N/S Matched: mouse == == N/S Matched: tool === == N/S Matched: mouse == Conclusively, it didn't find a mouse dpi tool anywhere, but just the individual words. It *would* be successful, if it searched filelists. However, doing that via dnf whatprovides … involves a lot of creativity regarding wildcards, or else I could never come up with the actual spelling of the tool's file name. Btw fedora devel list doesn't serve for reporting DNF bugs. Meanwhile I've already added a comment to a related RFE. I prefer filing bugs only if there is agreement/confirmation that it is considered a bug to fix eventually. It is entirely non-productive to open a ticket and have developers disagree or not respond to a ticket. That's why I posted my thoughts here. When I search, I do it with repoquery and grep, because yum/dnf search isn't powerful enough and hence not helpful. -- 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 search as braindead as yum search
On Sun, 22 Mar 2015 21:10:05 +0100, Michael Schwendt wrote: # dnf search libtoolize Using metadata from Sat Mar 21 15:38:26 2015 = Matched: libtoolize == libedit.x86_64 : The NetBSD Editline library libedit.i686 : The NetBSD Editline library D'oh! It's a false positive, because the word libtoolized is found in the package description of libedit. The package libtool is not found, because dnf search doesn't search filelists by default. A highly questionable decision. Yum manual page claims that yum search only searches package names and summaries. However, the word libtoolize only appears in the package _description_ of libedit, _not_ in its package name or %summary. Manual page claims that yum search all … should search in description and URL. Something's wrong here. Further differences: # dnf whatprovides libtoolize Using metadata from Sun Mar 22 23:13:16 2015 Error: No Matches found Compare with: # yum whatprovides libtoolize libtool-2.4.2-32.fc22.x86_64 : The GNU Portable Library Tool Repo: fedora Matched from: Filename: /usr/bin/libtoolize -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf search as braindead as yum search
# dnf search libtoolize Using metadata from Sat Mar 21 15:38:26 2015 = Matched: libtoolize == libedit.x86_64 : The NetBSD Editline library libedit.i686 : The NetBSD Editline library D'oh! It's a false positive, because the word libtoolized is found in the package description of libedit. The package libtool is not found, because dnf search doesn't search filelists by default. A highly questionable decision. -- 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 mock
On Mon, 16 Mar 2015 12:32:41 +0100, Michael Šimáček wrote: Configurations shipped with current mock have keepcache=1 by default, so the redownloading shouldn't happen if you have yum_cache enabled. But if you use different configs than the default ones, you'll need to adjust the config manually. It's the default with a local buildroot override repo added (cost=0 and metadata_expire=0). That has worked flawlessly for several years. I've tried to take a look at it a few times with extra Mock runs. The dnf update step for the Rawhide build target has been choking while downloading metadata from very slow mirrors as well as downloading up to 176 packages before the builddeps step. For every build job. When I interrupted everything and restarted from scratch, it repopulated the buildroot cache and did not download any updates anymore for subsequent build jobs. I'm puzzled. Could it be that we've been assigned to a semi-broken set of rawhide mirrors for some 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: DNF and mock
On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote: I just spoke with two members of DNF team about default usage of DNF in mock. I would like to share outcomes of this meeting. First I would like to state that you can already optionally use DNF in your mock by setting: config_opts['package_manager'] = 'dnf' I've switched back to Yum for now. I expect that we will be building Fedora 22- always by yum due to short Fedora life cycle. Yum will be still present in Fedora 24 for sure. Is DNF within Mock a fully compatible replacement for Yum yet? It seems builds take much longer now since something's downloading (or redownloading?) lots of data for each build job before setting up the buildroot. I don't have much time to look into it, bug shouldn't Mock's buildroot cache files be fresh enough to avoid redownloading packages, for example? -- 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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Tue, 10 Mar 2015 14:49:28 +0100, Ralf Corsepius wrote: Right now, many issues/problems are interacting and affecting packages simultanously, which occasionally render fixing these issues quite complicated. So far I've hit: - GCC-5.0 - Hardening - boost upgrade - ImageMagick - autotool upgrade. Openly said, the situation on f23 is a mess. Agreed. People run into failed builds, find out that a lib needs a rebuild because of GCC C++ ABI issues. After the rebuild, runtime linking fails for other dependencies, and they need a rebuild, too. This is non-trivial (and dangerous) for larger dep-chains in the distribution. I'm also not sure how many packagers even run Rawhide instead of F22 testing. -- 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: some differences between doc stuff and license stuff
On Sun, 08 Mar 2015 13:44:26 -0500, Michael Cronenworth wrote: On 03/08/2015 07:48 AM, Björn Persson wrote: · Files under /usr/share/doc are automatically tagged as documentation files even if %doc isn't used. Files under /usr/share/licenses are not automatically tagged as license files, so they need to be preceded by %license in file lists. I noticed the change to %doc files just a few days ago. Was this announced? %doc hasn't changed. %__docdir_path is the list of paths where included files are marked as documentation automatically. %license macro usage is covered by: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text Such changes to the packaging guidelines usually are announced by the FPC in their summary mails of what has changed. -- 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: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. -- 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: Audacious 3.6 build options
On Sun, 1 Mar 2015 23:28:48 +0100, Dominik 'Rathann' Mierzejewski wrote: I do use it from time to time, but I'm currently on F21. Me too, but the Copr builds of 3.6 feature a repo for F21, too. The Qt UI is not a port, but more of a rewrite/redesign. Various dialogs look very different. I'd say: follow upstream and build with GTK2. You are allowed to change application behaviour or appearance between distribution releases. Ah, a good idea for F22. I'll also consult upstream about their preferences. I'd wait with building against Qt5 in F22 until there is no dependency on both Qt and GTK anymore. Agreed. -- 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: Audacious 3.6 build options
On Mon, 2 Mar 2015 09:20:07 +1100, Dan Fruehauf wrote: Is it possible to compile audacious on its own and then supply gtk3 and qt packages on top of it? No. First of all, Qt has always been more than a GUI-library. It's a C++ development framework, and Audacious' core libs will likely use it where they have used GLib before. I doubt the devs will limit themselves to the C++ standard libs, so all GUIs and their dependencies could be put into plugins. That's these, so one could change the different UIs at run-time, $ rpm -ql audacious-plugins|grep -i ui /usr/lib64/audacious/General/gtkui.so /usr/lib64/audacious/General/qtui.so but libaudgui depends on both Qt and GTK, for example. And if both GUIs are enabled, one needs to run audacious --qt to start the Qt UI. Hmmm... -- 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: New Upstream Release Monitoring Systems
On Fri, 20 Feb 2015 15:36:11 -0500, Ralph Bean wrote: If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8].. Done. Thanks for a premature April Fool's prank. ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RFC: Audacious 3.6 build options
Audacious 3.6 has been released. This is another chance for interested people to join and help deciding how to proceed with the Fedora packages. I'm still looking for co-maintainers, too, especially some who have an opinion on how to package it. I've been building pre-releases for it via Fedora Copr ( https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/ ) but don't know whether anyone else has played with those yet (minus the MP3'n'similar plugins, of course, which are not available). Audacious 3.6 has changed the used programming language from C to C++. This also affects the Plugin API again, of course. It offers new GUI options for us to choose from: 1) The developers have introduced a Qt 5 based GUI that can coexist with the GTK+ GUI. It's called experimental, since it's not as feature-rich as the GTK+ GUI yet. It's a long-time goal to switch to Qt, however: http://redmine.audacious-media-player.org/boards/1/topics/1269 2) The developers are unhappy with gtk3 and have returned to gtk2. Currently, they offer _two_ different source tarballs, as they still support gtk3, too, and some of the changes are not done conditionally in the source code. They write: | Audacious can still be built with GTK3 if desired, | but we recommend the GTK2 variant for any desktop environment | other than GNOME 3. Which _would_ open the possibility to build both, but I don't think that would be worth the trouble (implicit conflicts in libs and packaged files - the necessity to work around the conflicts somehow, since they are forbidden if following Fedora's guidelines - the necessity to add explicit inter-dependencies between packages, and most users would still only install audacious and not an optional audacious-gtk2 or such). Enabling the Qt GUI would link Audacious core libraries with Qt by default in addition to GTK+ and GLib. That has the potential to annoy Qt haters, and Qt fans might be upset about the gtk3 dependency, too. Comments, anyone? -- 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: [Proposal] Ring-based Packaging Policies
On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Is there another place where those ideas get discussed? | https://twitter.com/Worldcleaver/status/565957125600321538 | | Stephen Gallagher @Worldcleaver | | Wherein I kick the hornets' nest again: | https://lists.fedoraproject.org/pipermail/devel/2015-February/207657.html | … (Proposal to relax Fedora packaging requirements in some cases) -- 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: Error with fedora review 0.5.2-2
On Tue, 24 Feb 2015 20:22:37 +, Sérgio Basto wrote: Correction: Bug 1085761 looks like the main bug, should we marked bug 1185565 was duplicated of 1085761 ? The answer is found in: https://bugzilla.redhat.com/1185565#c2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken already (was: Re: How to install Rawhide?)
Also the -02-18 one for Rawhide x86_64 Live Workstation, which started fine and managed to install, too. Haven't rebooted yet, though. It has been broken already by the first bunch of updates (62 or 63 pkgs). Oh no! Something has gone wrong [Logout] prior to GDM greeting screen coming up. -- 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 install Rawhide?
On Wed, 18 Feb 2015 22:24:47 -0800, Adam Williamson wrote: Today's - 2015-02-18 - F22 nightlies seem not to have any anaconda showstoppers, so for now probably using one of them is the best way to install F22. Thanks! Fetched it. Also the -02-18 one for Rawhide x86_64 Live Workstation, which started fine and managed to install, too. Haven't rebooted yet, though. Somewhat odd, something was causing lots of CPU+fan usage during install, and whenever I switched to vc and fired up top, polkitd was at the top and disappeared quickly, and the fans slowed down again. The check for weak passwords was a pain, btw. ;-) Oh, the irony, that I had to download ISO images multiple times before I could manage to install something - instead of being able to use fedup. -- 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 install Rawhide?
fedup --network rawhide --nogpgcheck - a bit of progress - it downloads ~1500 packages - it lists a screen full of packages without update - I reboot with the added boot menu entry upgrade prep complete, switching root failed to log coredump - connection refused An early end. Nothing happens. Can't even enter anything on any virtual console. Same for fedup --network 22 --nogpgcheck. -- 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 install Rawhide?
1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? 2. yum distro-sync with rawhide repo enabled : first encountered upgrade path violation problems, unresolved deps. Then after enabling only the rawhide repo, it locked up hard after updating ~900 packages. 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images to download. Which one to take? No idea. Fedora-Live-Workstation-x86_64-22-20150216.iso crashes early with a Python traceback failing to import storage-something. So, where is the safe guide on how to install (or upgrade to) Rawhide any day? Impossible? -- 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 install Rawhide?
On Tue, 17 Feb 2015 09:55:37 -0700, Kevin Fenzi wrote: 1. fedup --network rawhide : failed with a missing image? Why doesn't it work by default? Strange. The mirrormanager mirrorlist for images looks good here, and the images look fine. Ah... it's because they are not signed. | Downloading failed: couldn't get boot images: No more mirrors to try. | Last error was: [Errno 14] HTTP Error 404 - Not Found Re-run with --nogpgcheck? D'oh! That seems to lead to something. A Fedora-specific tool could really know about rawhide and tell about --nogpgcheck being needed. fedup could emit a better error here. https://bugzilla.redhat.com/show_bug.cgi?id=1193599 Brand-new ticket, yes, that seems to be the issue. One can never be sure due to mirror servers that may or may not carry the stuff that's needed. 3. Search Google. Find a Fedora Wiki page. Wait many minutes for an app to respond. Scroll down on a hardly readable list of ISO images Which wiki page? which 'app' ? https://fedoraproject.org/wiki/Releases/Rawhide/de - English (because the translation could be out-of-date, it doesn't mention fedup at all, and the links to koji aren't fast either when showing the list of images to download - a slow koji query!) - https://fedoraproject.org/wiki/Releases/Rawhide (it mentions --nogpg and an --instrepo somewhere in the details, it could be even easier!) - https://apps.fedoraproject.org/releng-dash/ - LiveCD Builds (rawhide) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
npth (was: Re: Orphaning and seeking comaintainers of some packages)
On Tue, 17 Feb 2015 17:19:38 +0800, Christopher Meng wrote: These below are packages I seldom use, feel free to comaintain them: NetPIPE PyMca roxterm autoconf-archive freetalk unhide firehol npth nPth - The New Pth library : isn't that one of the forks of pth to be developed more actively? It isn't used by any package yet according to repoquery. It has been imported just 23 months ago. Are you aware of any anything that uses it? exaile flickcurl jwm elektra dmenu profile-sync-daemon python-eyed3 oyranos 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: npth (was: Re: Orphaning and seeking comaintainers of some packages)
On Tue, 17 Feb 2015 18:13:29 +0800, Christopher Meng wrote: nPth - The New Pth library : isn't that one of the forks of pth to be developed more actively? It isn't used by any package yet according to repoquery. It has been imported just 23 months ago. Are you aware of any anything that uses it? Maybe you don't use rawhide? True. It breaks my installations too often (and when I retry fedup, it gives a 404 not found error, and I always forget the special invocation or Wiki pages that may make it work). But I could have pointed repoquery at rawhide. gnupg2 uses it for a long time. Same author. ;-) You can query the dep info on rawhide machine, 3 packages need it: gnupg2, gnupg2-smime and npth-devel. So, just gnupg2 so far, since gnupg2-smime is a subpkg, and npth-devel belongs to npth (obviously). Okay. One should give it more time and see whether any issues will come up during the F22 test cycle then. I still maintain it, but other maintainers especially of gnupg2 are welcome. -- 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: [Proposal] Ring-based Packaging Policies
On Mon, 16 Feb 2015 17:03:51 +0100, Kevin Kofler wrote: So, for my counterproposal: I propose that packagers with a sufficient level of trust (packager sponsors, provenpackagers, or a new, yet-to-be-defined group (maybe packagers with at least N packages)) be allowed to import new packages with a self-review. We trust those people for so many things, and we know that they understand the packaging guidelines, so why can we not trust them to import their own packages without blocking on somebody else? In case your suggestion includes a form of explicit self-approval, there ought to be a few requirements for the packager to document what has been reviewed. And possibly a short window when somebody may jump in and contribute a real review or to block the package. New packages often contain fundamental packaging mistakes, because a packager may have stopped as soon as a build had succeeded. A second pair of eyes can make a difference. Not all submitters of new packages perform self-reviews. They don't run fedora-review. They don't even do test-builds and test-installs for all target dists. The guidelines read much more as if only the reviewers is the one to perform the review (and be the one to blame in case something slips through). = Every package submitter should attempt at doing a self-review. Here are just 2 examples of packages that have been sitting in the queue for months and would have gone in instantly with my proposed policy: https://bugzilla.redhat.com/show_bug.cgi?id=922781 It blocks the kde-reviews tracker ticket. So, is it correct to assume that the KDE Sig has not found time to approve this quickly despite your claims that it would be safe to give blanket approval? There hasn't been an answer to the last comment, btw. No responding is #1 reason for stalled reviews. https://bugzilla.redhat.com/show_bug.cgi?id=1125952 Assigned to a reviewer since Aug 2014, and it has taken many months for an update to appear in Jan 2015. That's progress! The submitter has been a packager sponsor and provenpackager for years (and even several of the people he sponsored are now also packager sponsors and/or provenpackagers), so why do we need to waste our time reviewing his packages when it's clear that he knows what he's doing? And still there are counter-examples. Now I don't keep a log of what really broken packages I run into (including ones that misplace files or don't work at runtime), but cases like the following are packaged to death and highly questionable: https://bugzilla.redhat.com/1175952 Hint: also compare with the duplicate that's packaged differently. Plus, no progress if not even two people team up. -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, 15 Feb 2015 23:14:33 +0100, Jakub Jelinek wrote: On Sun, Feb 15, 2015 at 11:08:55PM +0100, Michael Schwendt wrote: On Sun, 8 Feb 2015 18:17:56 +0100, Marek Polacek wrote: either package bugs, or GCC bugs. As things stand, just about 19 packages did not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed at this time, and I promise I will fix the remaining one before long. gcc-5.0.0-0.13.fc23 fails for Audacious 3.6-beta1 as tried in Copr: https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/ As I haven't had a chance to look into it, Audacious upstream believes it to be a C++ bug in GCC. File a bugreport with preprocessed source? For that I would need a Rawhide installation and time to look into it and the constexpr C++14 changes in GCC 5. The same src.rpm builds fine on Fedora 21 (and also with Clang), so for a constexpr expert it would be much easier to draw conclusions. -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 13:54:59 +0100, Ralf Corsepius wrote: Meanwhile, we've had much more critical vulnerablities in widely used libs (Remember heartbleed), which all have been quite easy to fix packaging-wise. IMO, to a great portion, thanks to having mostly banned static linkage and bundling. There's more to it, too. Static linking is not only a risk with regard to security vulnerabilites. You cannot retest against an updated static lib without relinking the dependencies. You don't learn about new runtime breakage (or regressions) caused by the changed static lib, because the programs still use an old lib linked into them. The changed lib may have been out for many weeks as an update, but nothing test-drives it. What a surprise, if the lib were found to cause a sudden problem for a minor rebuild of a program. Or worse, if the rebuild were released quickly because of expecting it to be harmless, but the static lib under the hood has changed and breaks runtime for users. -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 17:45:23 -0700, Ken Dreyer wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Here's one review where the submitter worked very hard to jump through all the hoops until it came to the FPC bundling exception process. It's my opinion that Carlos would be a Fedora package maintainer today if that FPC process hadn't taken so long. https://bugzilla.redhat.com/682544 So, everybody's grief is just the unbundling policy? Is that the only thing that scares away people? Everything related to this proposal is only because of bundling? Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. Isn't the combination of 2) and 3) a potential threat that will scare away the maintainer again? (especially if upstream doesn't accept the patch) -- 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: Orphaned Packages in rawhide (2015-02-10)
audiofileorphan, ajax, alexl, caillon, caolanm, 1 weeks ago group::gnome-sig, johnp, mbarnes, rhughes, rstrode, ssp, xiphmont I've added myself there, since there are tons of deps on it down to even audacious-plugins and dozens of packagers are affected either directly or indirectly. Though I'm not familiar with this lib [yet]. There are no open tickets in bugzilla currently. Not much activity in the package %changelog. -- 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: Advice on naming a new library package - libunicode or courier-unicode?
On Mon, 9 Feb 2015 10:17:12 -0800, Brian C. Lane wrote: I'm trying to get the new version of maildrop ready and they split out unicode support into a new library. The name of their archive is courier-unicode, but the actual name of the library installed is libunicode. That's what I picked after looking at a few other libs. I don't see any specific naming guidelines on this and I can see it going either way. At Fedora there are no special naming guidelines for library packages. For example, we don't apply a lib prefix to the package name just because it's a library package. There are only the general naming guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Naming https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming courier-unicode would be a first choice, since it's the upstream archive name. They call the project Courier Unicode Library not libunicode: http://www.courier-mta.org/download.html#unicode That would meet the requirements of the naming guidelines. A libunicode package has been in other distributions before: http://rpmfind.net/linux/rpm2html/search.php?query=unicodesubmit=Search+... Another (old?) one with Pango as home. Naming the package libunicode could be safer with regard to avoiding a clash with another future project with the same name. But if following the guidelines, I would name it courier-unicode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
zeitgeist
Somebody please explain to me the zeitgeist package management model that is being applied at Fedora. From all the open bugs in bugzilla, http://bugz.fedoraproject.org/zeitgeist in none of them there is any activity by those people, who have done the last builds in the build system. Are these tickets handled by anyone? And if so, how? What am I missing? https://fedoraproject.org/wiki/Package_maintainer_responsibilities -- 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: zeitgeist
On Sat, 07 Feb 2015 02:50:05 +0900, Mamoru TASAKA wrote: Just info: - Actually even zeitgeist upstream has no or little active development, so even if Fedora downstream maintainers tries to do something it can be little expected that these bugs can be fixed: https://launchpad.net/zeitgeist/+download | 0.9.14 (Diamond) release from the 0.9 series released 2013-06-18 http://koji.fedoraproject.org/koji/packageinfo?packageID=9822 | zeitgeist-0.9.16-0.2.20140808.git.ce9affa How does that snapshot fit into the activity scheme then? Simply rebuilding 0.9.14 for Fedora made it crash for multiple users after hitting stable updates repo too quickly. Building the snapshot may have fixed the crash due to upstream changes, but a crash in sqlite3 in Oct 2014 could be a new problem, couldn't it? Bugzilla doesn't give any hint about whether such issues are forwarded or compared with upstream changelogs. Users trying to delete local sqlite db files is kinda a brute-force way to fight such problems. http://bazaar.launchpad.net/~zeitgeist/zeitgeist/trunk-freedesktop/changes/ https://answers.launchpad.net/zeitgeist/+question/260500 Odd. They consider it mature. Even more reason to communicate with them about the stability problems at Fedora. IOW, their mature product somehow fails here. And there's one fix that has been applied after creating the snapshot, too. - As far as I quickly glanced at those bugs, some (many?) bugs don't seem to have happened on direct zeitgeist side, and some (many?) bugs seem to require GLib knowledge or so, and I doubt reassigning them (to glib2 or so) make progress... Well, just because it crashed within glib2 does not imply that glib2 is the culprit. The rushed out broken build of zeitgeist resulted in users seeing assertion aborts such as $2 = 0x1127cd0 GLib:ERROR:gvarianttypeinfo.c:165:g_variant_type_info_check: assertion failed: (info-alignment == 0 || info-alignment == 1 || info-alignment == 3 || info-alignment == 7) $2 = 0x1ab8ca0 GLib:ERROR:gvarianttypeinfo.c:186:g_variant_type_info_check: assertion failed: (0 = index index 24) and the snapshot made those go away. (Verified? Expected?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packagers: incomplete Obsoletes and undead packages
This is about Rawhide. The list for F21 is similar, which is especially strange with regard to any packages that should be marked as dead in dist git already then. Dead = a dead.package file in dist git exists, but builds of the package are still found in the repo(s). Package has not been retired fully yet. Undead = no dead.package file in dist git found. Only obsolete subpackages = non-trivial, but for some of those cases there are really some missing Obsoletes tags and an incomplete set of builds is left in the repo (e.g. a -devel subpkg but its base pkg is obsoleted). [...] Dead and all builds obsoleted: -- drwright obsoleted by: gnome-settings-daemon python-twisted-conch obsoleted by: python-twisted python-twisted-lore obsoleted by: python-twisted python-twisted-mail obsoleted by: python-twisted python-twisted-names obsoleted by: python-twisted python-twisted-news obsoleted by: python-twisted python-twisted-runner obsoleted by: python-twisted python-twisted-web2 obsoleted by: python-twisted python-twisted-words obsoleted by: python-twisted qca2 obsoleted by: qca Undead and all builds obsoleted: golang-launchpad-gocheck obsoleted by: golang-gopkg-check kopete-cryptography obsoleted by: kopete kwallet obsoleted by: kwalletmanager lxshortcut obsoleted by: libfm mate-dialogs obsoleted by: mate-desktop min-metadata-service obsoleted by: min-cloud-agent openstack-marconi obsoleted by: openstack-zaqar php-channel-deepend obsoleted by: php-deepend-Mockery php-channel-symfony2 obsoleted by: php-symfony php-symfony-icu obsoleted by: php-symfony python-XStatic-Angular-Cookies obsoleted by: python-XStatic-Angular superiotool obsoleted by: coreboot-utils xorg-x11-glamor obsoleted by: xorg-x11-server zeroinstall-injector obsoleted by: 0install Only obsolete subpackage(s): kactivities ['kactivities'] 4 left obsoleted by: kf5-kactivities left: kactivities-devel left: kactivities-libs left: kactivities-nepomuk left: kactivities-nepomuk-devel mmdb ['mmdb'] 1 left obsoleted by: mmdb2 left: mmdb-devel python-twisted-core ['python-twisted-core'] 1 left obsoleted by: python-twisted left: python-twisted-core-doc razorqt ['razorqt-notifications'] 22 left obsoleted by: lxqt-notificationd left: lightdm-razorqt left: razorqt left: razorqt-about left: razorqt-appswitcher left: razorqt-autosuspend left: razorqt-config left: razorqt-data left: razorqt-desktop left: razorqt-globalkeyshortcuts left: razorqt-libs left: razorqt-libs-devel left: razorqt-openssh-askpass left: razorqt-panel left: razorqt-policykit-agent left: razorqt-power left: razorqt-runner left: razorqt-session left: razorqt-theme-ambiance left: razorqt-theme-amego left: razorqt-theme-green left: razorqt-theme-light left: razorqt-themes ruby-gnome2 ['ruby-gtksourceview2', 'ruby-gtksourceview2-devel'] 24 left obsoleted by: rubygem-gtksourceview2 left: ruby-bonobo2 left: ruby-bonobo2-devel left: ruby-bonoboui2 left: ruby-bonoboui2-devel left: ruby-gconf2 left: ruby-gconf2-devel left: ruby-gnome2 left: ruby-gnome2-devel left: ruby-gnomecanvas2 left: ruby-gnomecanvas2-devel left: ruby-gnomeprint2 left: ruby-gnomeprint2-devel left: ruby-gnomeprintui2 left: ruby-gnomeprintui2-devel left: ruby-gnomevfs left: ruby-gnomevfs-devel left: ruby-gtkglext left: ruby-gtkglext-devel left: ruby-gtksourceview left: ruby-gtksourceview-devel left: ruby-libart2 left: ruby-libart2-devel left: ruby-libglade2 left: ruby-libglade2-devel -- 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: Introducing abidiff (was Re: [Guielines Change] Changes to the packaging guidelines)
On Thu, 29 Jan 2015 09:54:40 +0100, Dodji Seketeli wrote: Indeed. And while we are in the Shameless Plug department, I'd like to mention the presence of a new tool called 'abidiff'. You can learn about it at https://sourceware.org/libabigail/manual/abidiff.html. It's a command line tool that compares the ABIs of two shared libraries by looking *only* at the binaries and their debug info. Unlike abi-compliance-checker, it doesn't need to look at the associated header files. It can also do things that abi-compliance-checker cannot do, like, *recursively* compare the types of the exported functions and variables of the binaries. Sounds good. I'll certainly start evaluating it as a replacement for abicheck, which has been retired at Fedora some years ago. -- 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: Mock return error code 127
On Thu, 29 Jan 2015 12:50:03 -0300, Carlos Morel-Riquelme wrote: Hi folks, i've packed a new font, also i've create the rpm and srpm, also i 've installed in my laptop and looks fine, i've read the guidelines for create the package, but when i run fedora-review i have the error 127 in mock. here is the output WARNING: Illegal return from /usr/share/fedora-review/scripts/fonts-disable.sh, code 83, output: stdout:None stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier ./review-env.sh: line 7: unset: `BASH_FUNC_scl()': not a valid identifier ./review-env.sh: line 7: unset: `[': not a valid identifier ./review-env.sh: line 7: unset: `$CMD': not a valid identifier I filed https://bugzilla.redhat.com/1185565 about those review-env.sh errors some days ago. -- 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: Mock return error code 127
On Thu, 29 Jan 2015 14:01:56 -0300, Carlos Morel-Riquelme wrote: Thanks guys, Michael a have a question, can i submit the package review or i need wait that this issues is fixed ? Using fedora-review is not mandatory but highly recommended for packaging/reviewing beginners. And it can be very helpful due to some of the checks it performs (e.g. license headers in source files). A bug in fedora-review could lead to false '[x]' in review.txt. If it's just another '[ ]' in the report, the fedora-review user is supposed to check those manually anyway. ;-) -- 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: Taskotron misses dropped subpackages
On Wed, 21 Jan 2015 11:48:55 -0700, Tim Flink wrote: Taskotron doesn't notice if subpackages have been dropped and cause unresolvable dependencies because they are not obsoleted anywhere. This isn't so much something that taskotron's checks missed as it's something we're not even checking for. Examples: jogl2-javadoc, miglayout-examples, glusterfs-regression-tests rubygem-json-doc, rubygem-rake-doc, and more I don't really see the unresolvable deps here. When I run all of your examples though 'repoquery --whatrequires', they all return nothing which implies that nothing requires them and there are no broken dep chains as a result of those dropped subpackages (which I suspect is not what you'd like to see checked). The problem is a different one: A dropped subpackage, if installed already, may depend on other packages that are installed. If there's a strict dependency, e.g. on a specific %version-%release of something, an upgrade would be impossible. Unless the dropped subpackage were obsoleted properly. Yum is broken in the same way. And by design. When installing a discontinued subpackage, it happily installs any old packages it still finds in the repos to satisfy dependencies, but it cannot upgrade the installation afterwards because of unsatisfied deps. If I'm understanding correctly, your concern is about what happens at upgrade time when those improperly obsoleted subpackages are still installed on a system. Since they don't exist in the repos anymore, upgrading them is impossible. Upgrading the requirements is what leads to unresolvable deps. One can only upgrade, if one removes the dropped subpackage manually. While I'm certainly not arguing that this isn't something that we should check for, it's not really covered by any existing checks. I'm certainly game for adding a new check for this but unless it's a bigger problem than I think it is, I'd rather put it off until after we've been able to land the new features we're currently working on. That's up to you, of course. Once you understand _the problem_, your point of view may change. -- 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: Taskotron misses dropped subpackages
On Wed, 21 Jan 2015 05:50:35 -0500 (EST), Kamil Paral wrote: Taskotron doesn't notice if subpackages have been dropped and cause unresolvable dependencies because they are not obsoleted anywhere. Yes, depcheck doesn't currently handle that. I've created: https://phab.qadevel.cloud.fedoraproject.org/T384 An example for disbeliever Tim: ;-) jogl2-javadoc-2.0.2-1.fc21.noarch.rpm Requires: jogl2 = 2.0.2-1.fc21 = You cannot upgrade to the newer jogl2, if jogl2-javadoc is installed already. $ yum list jogl2\* [...] Available Packages jogl2.x86_642.2.4-3.fc21 updates jogl2-doc.noarch2.2.4-3.fc21 updates jogl2-javadoc.noarch2.0.2-1.fc21 fedora Note that there are worse examples (e.g. plugins/extensions packages with the strict dependency being an automatic one on a lib soname). -- 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: autoreconf on build
On Sat, 24 Jan 2015 19:42:20 +0100, Ralf Corsepius wrote: In many other cases autoreconf can cause subtile and hard to find issues. In complex cases, it doesn't work at all. Especially the former can be troublesome if they don't cause a build to fail. For example, it can lead to issues such as undefined/unsubstituted macros, dropped lines from Makefile*.in templates, files like config.h.in or even m4 files. Packaging guidelines that ask packagers to run autoreconf always will lead to packagers adding something to a spec file without spending extra time on carefully examining the results. -- 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 as default package manager
On Wed, 21 Jan 2015 09:33:31 +0100, Vít Ondruch wrote: Dne 20.1.2015 v 14:22 Bohuslav Kabrda napsal(a): 1) DNF will be the default package manager for F22 [2], so everything is ok here. I really wonder what is the state here. This is on my rawhide: # dnf remove yum python3-chardet noarch 2.2.1-2.fc22 @System 1.1 M python3-requestsnoarch 2.5.0-3.fc22 @System 318 k python3-urllib3 noarch 1.10-1.fc22 @System 341 k Is dnf remove ... any special and also removes requirements in addition to yum? python3-chardet certainly does not depend on yum in any way. Same for the other Python 3 based packages in your list. I can only imagine they are on the list because they are dependencies by something else on that list. Not yum which is Python 2 based anyway. -- 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: another dnf problem
On Wed, 21 Jan 2015 19:25:40 -0500, Neal Becker wrote: I installed kernel* from updates-testing. Now I want to go back to distro-sync. Let's try it: sudo dnf distro-sync kernel* Error: problem with installed package kernel-3.17.7-300.local.fc21.x86_64. problem with installed package kernel-core-3.17.7-300.local.fc21.x86_64. problem with installed package kernel-doc-3.17.4-200.fc20.noarch. problem with installed package kernel-modules-3.17.7-300.local.fc21.x86_64. problem with installed package kernel-modules-extra-3.17.7-300.local.fc21.x86_64 that didn't work, and not very informative. How about? [nbecker@nbecker1 ~]$ sudo dnf downgrade kernel* Error: conflicting requests Another loser. OK, yum? sudo yum distro-sync kernel* Dependencies Resolved Did you make sure that both dnf and yum work on exactly the same repo metadata? dnf doesn't refresh it as often as yum does. You may need to force it to do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned: python-html2text and rss2email
Eventually I had taken over python-html2text rss2mail (depends on python-feedparser) and have used them for a long time. Now it's time to move on. The author of html2text has died two years ago. There are various forks with different versioning schemes. There's also a new upstream for rss2email. It has changed to use Python 3 and is incompatible with the config and data files from the older release as packaged in Fedora. From time to time I've had a look at upgrading. With mixed results. My latest attempt has been today in reply to a new bz ticket RFE. https://mschwendt.fedorapeople.org/rss2email-3.9-1.fc21.src.rpm https://mschwendt.fedorapeople.org/python-html2text-3.200.3.2014.12.29-1.fc21.src.rpm Upon evaluating the builds, my old feed setup has been broken, and I've reconfigured for another try and using Debian's r2e-migrate script. Doing that I also spent some time on cleaning up procmail folders for several feeds. That's when I decided I don't want to use rss2email anymore. I'll probably evaluate claws-mail-plugins-rssyl for sporadic usage. There may or may not be any active co-maintainers. Please visit Fedora pkgdb if you're interested in these packages. Signing up for python-feedparser would be an idea, too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Taskotron misses dropped subpackages
Taskotron doesn't notice if subpackages have been dropped and cause unresolvable dependencies because they are not obsoleted anywhere. Examples: jogl2-javadoc, miglayout-examples, glusterfs-regression-tests rubygem-json-doc, rubygem-rake-doc, and more Yum is broken in the same way. And by design. When installing a discontinued subpackage, it happily installs any old packages it still finds in the repos to satisfy dependencies, but it cannot upgrade the installation afterwards because of unsatisfied deps. [...] Also a reminder for packagers: Adhere to Fedora's Packaging Guidelines when removing subpackages! Add proper Obsoletes tags to your package. http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages -- 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: echoping - Re: Hundreds of bugzilla mails on one day
On Thu, 15 Jan 2015 13:23:06 +0100, Tomas Mraz wrote: I would just open a FESCo ticket to get the package removed from Fedora. https://fedorahosted.org/fesco/ticket/1388 Much more interesting would be to learn whether anyone has any ideas on how to prevent such issues in the future. The EOL-close-tickets procedure has failed for this package multiple times. And it's not even possible to rely on actual users of the package, if there isn't any response in bugzilla ever. -- 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: Hundreds of bugzilla mails on one day
On Fri, 16 Jan 2015 05:59:18 +0100, Ralf Corsepius wrote: On 01/14/2015 05:06 PM, Matthew Miller wrote: On Sat, Jan 10, 2015 at 12:43:46PM +0100, drago01 wrote: Yeah I just delete those mails now days. Its just spam F19 is EOL is not news that I need to get 1000 times. Right, clearly, that message is not really for _you_. Really? Of course not. Matthew is mistaken. The comment added to bugzilla addresses both, the reporter and the assignee, but specifically the package maintainer: | Package Maintainer: If you wish for this bug to remain open because | you plan to fix it in a currently maintained version, simply change the | 'version' to a later Fedora version. However, the mails sent by bugzilla don't give any hint about whether the recipient is the reporter in a ticket or the assignee. The tickets also are not set to NEEDINFO-reporter either. As the assignee, I cannot tell whether I want such a ticket to remain open after receiving the mail. I need to establish other ways of keeping track of tickets in bugzilla. -- 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: echoping - Re: Hundreds of bugzilla mails on one day
On Tue, 13 Jan 2015 01:23:36 +0100, Kevin Kofler wrote: * Last upstream release is from 2007 and the same as offered by Fedora. Then it's not the Fedora maintainer who is not doing his/her job. At Fedora, it is _mispackaged_ and untested to begin with. The plugin packages likely have never been packaged properly before. The bugzilla ticket is still without a response after years. The ticket I mentioned was opened in 2008. In 2008 you could not predict that upstream would search for a new maintainer in 2011. -- 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: Un-retiring ice and mumble?
On Mon, 12 Jan 2015 20:41:30 -0500, Carlos O'Donell wrote: Devel, I would like to un-retire mumble, but that requires ice. I've just fixed ice to compile on f21 without much effort. So I think I'll un-retire ice and mumble and maintain them unless anyone objects. Is there any reason ice was orphaned and retired other than lack of interest? Have you examined existing tickets for it yet? http://bugz.fedoraproject.org/ice plus any that may have been closed recently because of no response from the previous maintainers. -- 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: Unpackaged files checking - oddities
On Sun, 11 Jan 2015 12:32:04 +0100, Thomas Moschny wrote: 2015-01-10 13:04 GMT+01:00 Michael Schwendt: %exclude is global per spec file, or else you would need to %exclude a file in _all_ subpackages (in the case when deleting it in %install would be more convenient anyway). That would cause some pain in some packages. Is that really true? But a file %excluded in the main package can be explicitly named and thus included in a subpackage, right? At least I am doing that in one of my packages... You've read too much between the lines. ;) A file %excluded in the main package * _need not_ be included in any subpackage, * does not raise an unpackaged file found in buildroot error, * may be included in subpackages accidentally (like ordinary duplicates). IOW, with global I did _not_ mean it would be hidden completely and could not be included within subpackage %files sections anymore. -- 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: Unpackaged files checking - oddities
On Sat, 10 Jan 2015 00:27:15 -0600, Bruno Wolff III wrote: While working on a spec file to cause build failure if new fonts showed up in a package, I noticed two oddities with the checking for unpackaged files. An unpackaged empty directory will not trigger a build failure. That's an ordinary unowned directory, which has never before triggered a build failure. Else there would not have been hundreds of such issues in packages. ;-) It's not considered fatal, because if it's a directory with special ownership/permissions, you would have an %attr entry for it for sure. If a file is covered by %exclude in the main package, but is not included in any subpackage, it will not trigger a build failure. %exclude is global per spec file, or else you would need to %exclude a file in _all_ subpackages (in the case when deleting it in %install would be more convenient anyway). That would cause some pain in some packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
echoping - Re: Hundreds of bugzilla mails on one day
Big *sigh*. Guys, this is not funny anymore. Almost as if some people at Fedora try to test how long one can keep one's temper. Well, this is embarrasing and not casting a positive light on the Fedora Project package collection: https://bugzilla.redhat.com/460557 Package and software are in a desolate state Reported: 2008-08-28 11:58:50 EDT No response in bugzilla. http://koji.fedoraproject.org/koji/buildinfo?buildID=555956 Not updated since F14. -- 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: echoping - Re: Hundreds of bugzilla mails on one day
On Sat, 10 Jan 2015 14:44:39 +0100, Matěj Cepl wrote: I would just go ahead with https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers As much sense as this procedure may make in _some_ cases, it has been a failure for other packagers before. They emerge only to end the procedure and hide again afterwards (only a matter of days/weeks/months) without taking care of the packages. * Last upstream release is from 2007 and the same as offered by Fedora. * Package has not been worked on since the showstopper bug report for F10. * Upstream is seeking for a new maintainer since 2011. I don't want to take over the package either, so it simply doesn't make sense to start a tedious procedure, which could be started for other similarly non-responsive packagers, too. Someone hides, and others take a lot of effort to get rid of the crap. Just like packagers, who acquire ownership of multiple hundred packages, this is one of the non-shiny sides of Fedora, unfortunately. -- 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: Unpackaged files checking - oddities
On Sat, 10 Jan 2015 09:51:19 -0600, Bruno Wolff III wrote: My guess would have been that %excludes would have been developed specifically for making it convenient to exclude a directory in the main package that needs to be owned by a subpackage. Rather: a quick way to not package a file. Especially helpful as the %files section becomes really clear about that file (which you maybe want to exclude only temporarily). Deleting files in %install is considered cleaner by many, because it ensures that a file is not found inside the %buildroot anymore and cannot be included accidentally either. The drawback is obvious: There ought to be a comment explaining why a file is deleted. When distributing the buildroot contents to subpackages, I would recommend using less wildcards and carefully listing which files/dirs to include where. Some packages play with %files option -f with generated lists of files, and it can get really ugly then and less readable (and more risky when even inserting %exclude in the generated Files Lists). -- Personally, I would like %exclude more if there were an explicit %include to include an excluded file in another subpackage. But %include is for spec file fragments not %files sections. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hundreds of bugzilla mails on one day
It has happened again. :-/ | This message is a notice that Fedora 19 is now at end of life. Fedora | has stopped maintaining and issuing updates for Fedora 19. It is | Fedora's policy to close all bug reports from releases that are no | longer maintained. | | [...] As I found it odd, that again I would receive so many bz mails for old tickets, initially I had started taking a look at some, but there are too many packaging issues where the packagers don't respond because they dislike Fedora's packaging guidelines. It's not managable for me to revisit them all. I also cannot jump in and take over work, such as resolving implicit conflicts between packages. Especially for implicit conflicts, a reminder: Implicit conflicts are _nasty_ and so far are not detected by package tools prior to the transaction check. What does that mean? Dependency solving and downloading of possibly huge packages will be done without indicating a problem, only to fail before installing the packages. All the user then can do is to try excluding a package somehow, which may be difficult if it's pulled in as a dependency. I've also noticed a few version upgrade requests with no response from the package maintainer - potentially unmaintained Fedora packages. This is not encouraging. -- 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: Unpackaged files checking - oddities
On Sat, 10 Jan 2015 12:06:10 -0600, Bruno Wolff III wrote:
In this particular case some stuff gets added depending on whether or
not the build process finds all of the fonts that are needed. I wanted
this to fail during build if any were not found,
%check
[ -f %{buildroot}%{_datadir}/fonts/name/some/file3 ]
[ -f %{buildroot}%{_datadir}/fonts/name/some/file7 ]
%files
%{_datadir}/fonts/name/
is a trick to include an entire tree in %files section and still check
for individual files to be found in %buildroot after %install.
--
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: Unresponsive maintainer : kanarip
On Fri, 09 Jan 2015 09:40:17 +0200, Yanko Kaneti wrote: Policy does require you to contact the maintainer http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL It is quite inappropriate to not have the courtesy to contact the fedora maintainer first. I have't seen that policy, but now that I've read it it seem misguided. My thinking is: - If the Fedora maintainer cared and there was no technical reason the branches would already be there. Cared? This is the fundamental problem. Care about what? About making available a package _also_ for EPEL? Or about maintaining it properly and as appropriate for the long life-cycle of the mother product RHEL? EPEL should not be treated as just another dist target to build for. Don't take it lightly. Don't dump builds into EPEL without considering what may become necessary for future bug-fixes, security-fixes or even back-ports when the build requirements of an upgrade are not met by RHEL. It is perfectly fine, if someone with special interest in EPEL volunteers as the EPEL package maintainer when the Fedora package maintainer has not created the branches for EPEL before. Be aware of the consequences of offering something for EPEL. It is not easy to make RHEL/EPEL users happy. Those, who are not affected by bugs, don't want version upgrades which may cause regression and new issues. Those, who are affected by bugs, want bug-fixes (which may make version upgrades necessary!). And there are also those, who want always new versions as if it's a drug. Finding existing packages saves them some work, but they don't care much, because they build things themselves once the existing packages are out-of-date, and they don't care either whether that may break the dist. - Most Fedora maintainers know well enough if there is or isn't any technical reason. Not sure about that. The type of maintenance which is appropriate for EPEL is underestimated. When you offer something for EPEL, you somehow need to predict whether you will be able to handle security fixes, backports and/or upgrades in the future for a long time. - I am too busy and I'll get to it later - is no good excuse for blocking people willing to do the work. True. Not responding in bugzilla in time is no good excuse either. - I beleive this package is not suitable for an LTS release, so I'll block it - is just hubris. True, too. Is there an EPEL project leadership which could review such decisions? The opposite, offering something for EPEL only to orphan it some time later, can be considered damaging, too. - Lets not put red tape for more people to do the work in a place where good sense should be more than enough to prevent conflict. Still it's too easy to release packages in the Fedora and EPEL dists and then abandon them without any notification. -- 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: iax - iaxclient-libiax
On Wed, 07 Jan 2015 19:14:00 +0100, Sandro Mani wrote:
So what I'm planning to do is to retire the iax package in Fedora, and
have add to the iaxclient package the subpackages -libiax and
-libiax-devel, containing the iaxclient bundled libiax2, with appropriate
Obsoletes: iax 0.2.3
Provides:iax = 0.2.3
Obsoletes:iax-devel 0.2.3
Provides: iax-devel = 0.2.3
(Question at this point: is it legal to provide a version which is not
the package version?)
Yes.
Especially for virtual packages. That version could be anything, even
an API version different from the software release version.
Note, though, that the Provides won't meet the requirement of any
arch-specific deps, such as Requires: iax-devel%{?_isa} = 0.2.3
You probably want anyone to Requires: iaxclient-libiax-devel%{?_isa} ...
instead in the future. Keeping alife the iax-devel name is not a good
idea if there is no arch-specific counter-part.
Whether splitting of subpackages for libiax makes sense depends on the
dependencies within iaxclient. It would not be the first package where
somebody splits off things into subpackage-madness without the extra
packages not being optional.
--
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: Surprise in texlive-base %preinstall script
On Sat, 27 Dec 2014 13:03:12 -0500, Sam Varshavchik wrote: Who else thinks that this part of texlive-base's %preinstall is not really such a hot idea: for i in `find /home/*/.texlive* -type d -prune`; do find $i -name *.fmt -type f | xargs rm -f /dev/null 21 done This is a violation of the packaging guidelines. At least some packager sponsors have been teaching don't mess within /home during review. Though, it seems, it has not been added to the Wiki except for this: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER | In addition, no Fedora package can contain files or directories or | modify files under: | | [...] | | /home/$USER as users can arbitrarily modify the files in their home | directories and rpm packages that modify those files run the risk of | destroying user data. Additionally, sites may be nfs mounting /home on | many different types of systems or even network automounting them on | demand. Modifying files in home directories that are thus configured | will have negative effects in both of these situations. https://www.redhat.com/archives/fedora-packaging/2008-February/msg00106.html | On Wed, 2008-02-27 at 11:17 -0600, Jason L Tibbitts III wrote: | /home is mine; packages cannot ever safely touch anything there. | | This seems like a succinct point to add to the Guidelines. | | ~spot -- 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 take ownership of orphaned package: ddclient
On Tue, 23 Dec 2014 10:57:14 -0700, Kevin Fenzi wrote: You will need to convince a sponsor to sponsor you. https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group?rd=Extras/HowToGetSponsored Many sponsors like to see you put together a package for review or 'pre' review existing packages in the review queue to show that you know what you are doing. Btw, several sponsors have been burnt by someone new wanting to take over a single orphaned (or even deprecated) package, only to give up shortly afterwards without any notification. :( So, a positive attitude in general and not getting upset too easily by other changes in the dist is a plus if you are serious about becoming a contributor. -- 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: Where should a package place facter facts?
On Tue, 23 Dec 2014 20:10:08 +0100, Reindl Harald wrote: Are packages really supposed to put files in /local/? no - /usr/local/ is admin area - period True - ignoring the 'period' ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
xcf-pixbuf-loader unmaintained
A package with Fedora packaging bugs that are unhandled for years, e.g. https://bugzilla.redhat.com/668159 Upstream development has stopped, too. As one can see in the %changelog, it's still the same software since 2009/2010. In Fedora bugzilla, there is no response. The upstream developer has replied to me about two recent bug reports and might accept patches, too, but without contributing anything to the code base anymore, that basically means somebody else would need to take over development. For example, one can avoid some crashes easily, but it would not make the code more complete with regard to the XCF specs. https://apps.fedoraproject.org/packages/xcf-pixbuf-loader/bugs/all * Mon Aug 18 2014 Fedora Release Engineering - 0.0.1-13.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sun Jun 08 2014 Fedora Release Engineering - 0.0.1-12.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Sun Aug 04 2013 Fedora Release Engineering - 0.0.1-11.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Fri Feb 15 2013 Fedora Release Engineering - 0.0.1-10.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Sun Jul 22 2012 Fedora Release Engineering - 0.0.1-9.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Sat Jan 14 2012 Fedora Release Engineering - 0.0.1-8.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild [...] * Wed Feb 17 2010 Bastien Nocera 0.0.1-2.8af913d1 - Update to 8af913d1 commit - Update with review comments -- 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 Wed, 19 Nov 2014 21:13:29 +0100, Lorenzo Dalrio wrote: In my hurry I have swapped Version and Release following exactly the guidelines you have linked. :-/ Well, a package being tiny does not imply there's nothing to be reviewed. The top of the executable says __version__ = '1.2.0' which it displays somewhere in the tools Help system. The CHANGELOG file says Version 1.2. The script contains a shebang that can become problematic, unless it really works with both Python 2 and Python 3: #!/usr/bin/env python https://fedorahosted.org/fpc/ticket/327 Older topic: http://fedoraproject.org/wiki/Script_Interpreters_%28draft%29 https://www.redhat.com/archives/fedora-packaging/2009-July/msg00056.html -- 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 Wed, 19 Nov 2014 11:47:30 +0100, Lorenzo Dalrio wrote:
Hello,
I have this trivial package ready to be reviewed
https://bugzilla.redhat.com/show_bug.cgi?id=1165584
I'd be happy to review one in exchange.
We may need to redefine trivial for this one. ;-)
Look:
| Version:20141118git%{shortcommit}
| Release:1%{?dist}
You would be better off if you followed Fedora's versioning guidelines
for snapshots,
https://fedoraproject.org/wiki/Packaging:Guidelines#Version_and_Release
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag
where you include the date of the checkout in the Release tag instead
of the Version tag. If there hasn't been an official _version_ yet,
choose Version: 0. This gives you much more flexibility when dealing
with future updates (not limited to upgrades/downgrades).
--
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/Minutes for today's FESCo meeting (2014-11-12 at 18UTC)
On Wed, 12 Nov 2014 11:53:32 -0700, Kevin Fenzi wrote: 18:03:04 nirik firefox folks removed their hack... 18:03:31 nirik so they use /tmp again in rawhide. 18:04:14 kalev that sounds like a regression 18:04:35 nirik regression? 18:04:46 kalev downloading multi gigabyte files into /tmp would probably easily fill it up 18:04:48 mattdm well, that's going to fill up with big downloads 18:04:59 nirik well, only if people don't say where to download them too... 18:05:05 dgilmore hola 18:05:07 t8m hi, sorry for being late 18:05:15 nirik it only uses that until the save dialog not answered. 18:05:46 nirik so I guess somone could save an iso and not answer the dialog and fill up space. That would be a silly reason. Not answering the SaveAs ialog (which is only displayed after changing the Preferences) it won't disappear, not even when closing Firefox. You have to answer it, since closing it is the same as clicking Cancel to delete the download. IOW, you don't get the downloaded file, not even if the background download completes. The file will still have its random temporary file name that doesn't have anything in common with the final file name. 18:06:38 kalev [...], but the problem was the way they achieved it, by overriding the TMPDIR variable which incidentally then also override it in the env passed to other programs Exactly. Originally, they did not respect an already set $TMPDIR, so you could not even set $TMPDIR for all users and point it at quota-enabled Temp storage, because /usr/bin/firefox would have started the download in /var/tmp nevertheless. The other problem, a $TMPDIR changing throughout the lifetime of a session, also defeats the purpose of a system-wide configuration. Hopefully gnome-terminal will be fixed eventually (and the same for any other program that would not see a set env var). -- 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: Does Fedora have a technical expertise oriented SIG?
On Sun, 2 Nov 2014 10:13:10 -0500, Matthew Miller wrote: Is there any authoritative group at Fedora who wants the product to not suck like that? Authoritative? Probably FESCo. https://fedorahosted.org/fesco/ticket/1365 Basically, we need to tell every Fedora User that Firefox and Claws Mail don't play well together because of what Fedora's /usr/bin/firefox does whereas RHEL doesn't. Bad publicity already. And if those users follow /usr/share/doc/claws-mail/README.Fedora or are accustomed to setting various environment variables already, even that doesn't work everywhere with Fedora, e.g. gnome-terminal where NOTABUG has been today's response after nine months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Does Fedora have a technical expertise oriented SIG?
Hello everyone! See subject line. I wonder whether there is a group of people at Fedora that could examine issues that let the entire product look bad? As for the background, it had started with Firefox hardcoding /var/tmp as its temporary directory. Obviously, starting applications from within Firefox made them run in an environment different than when started on the desktop. It has taken some time for the Fedora maintainers of Firefox to confirm it's an issue and to implement a work-around. Fedora's /usr/bin/firefox startup script evaluates exports $TMPDIR with a default of /var/tmp. Again, and obviously, a user, who wants a single _unique_ directory for temporary files for _all_ applications, needs to define that directory somewhere. Or else, Fedora would just be broken by default. When I wanted to discuss that topic on devel list, I asked how many other applications either hardcode a tmp dir or rely on evaluating env variables. Meanwhile, another issue has been found. Some months ago already. It affects GNOME Shell and email programs started via gnome-terminal's mailto handler: https://bugzilla.redhat.com/1060540 It just doesn't work, because $TMPDIR is not passed on to the launched application. And the application cannot work around it. Is there any authoritative group at Fedora who wants the product to not suck like 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: Does Fedora have a technical expertise oriented SIG?
[replies to the list please!] On Sun, 2 Nov 2014 10:10:57 -0500, you wrote: As for the background, it had started with Firefox hardcoding /var/tmp as its temporary directory. Obviously, starting applications from within Firefox made them run in an environment different than when started on the desktop. This refers to: https://bugzilla.redhat.com/956380 To sum up, with a default install of Fedora, if one configures Claws Mail as email program, runs Firefox and clicks on a mailto:; link, Claws Mail gets a different temporary directory than when starting it within the GNOME Shell directly. -- 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: Broken deps in rawhide (coreutils)
On Wed, 22 Oct 2014 09:51:36 +0200, Ralf Corsepius wrote: On 10/21/2014 08:41 PM, Kevin Fenzi wrote: I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? Well, koji buildroots also seem to be affected E.g. https://kojipkgs.fedoraproject.org//packages/perl-Mail-Sender/0.8.23/1.fc22/data/logs/noarch/root.log Actually, I don't understand why they don't abort ;) There's something else I don't understand: fontconfig requires font(:lang=en) and this pulls in an arbitrary font package, lyx-fonts (A collection of Math symbol fonts for lyx). As why this is done, the %changelog points at early 2014: Add Requires: font(:lang=en) (#1025331, #845712) Let's see: Bug 1025331 - Firefox segfaults on headless systems Huh? Installing any font (whether used or not) may fix that indeed if it crashes because of missing fonts, but it still sounds like an ugly hack. Why not install a basic/useful font? And the other ticket? Bug 845712 - missing base fonts if no DE is installed Well, it has been reopened in April, because it is a display problem and is still reproducible. Obviously, Math symbol fonts are not really helpful in that case. -- 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 21 lets me install packages without root
On Mon, 20 Oct 2014 10:10:48 -0600, Stephen John Smoogen wrote: So if I mistype 'rm' as rn or rb will lrzsz or rn be installed so that it does the wrong thing next time? Or is this only some commands? And beyond removing someone from the wheel group what is the way to turn this off? Is this referring to PackageKit-command-not-found? If so, uninstall that package. It's considered highly annoying by many Fedora users anyway. -- 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: Tripwire fails to build for F21 and Rawhide
On Thu, 16 Oct 2014 02:32:49 -0700, Moez Roy wrote: Tripwire fails to build for F21 and Rawhide. Is there a proven packager out there who has some spare time to submit a fix for this? Where is the package maintainer? The non-responsive maintainer procedure ought to get restarted for him, if the package is semi-orphaned apparently. And why did you quote 143 KB of build.log output instead of cutting off the irrelevant output? archive.cpp: In member function 'virtual void cLockedTemporaryFileArchive::OpenReadWrite(const char*, uint32)': archive.cpp:889:28: error: redeclaration of 'eArchiveOpen e' [-fpermissive] eArchiveOpen e(strTempFile, errStr); ^ archive.cpp:886:29: note: 'eFSServices e' previously declared here catch( eFSServices e) Rename e in line 886 to something else, e.g. eFSServices es and see how far it compiles then. Perhaps it's not the only file that causes trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
