Re: Stop the git abuse
On 05/21/2012 01:56 PM, Ralf Corsepius wrote: Technically, the major difference is git recording each and every detail, which an rpm's user hardly is interested in. The latter audience is not interested in seeing these details, they are interesting in summaries. E.g. they are not interested in seeing ABC-3 ... Fix memory leak (PR XYZ). ... merge from HEAD. ... merge cleanup. ... fix typo in previous commit. ... fix yet another typo. ABC-2 ... Upstream update. They are interested in reading ABC-3 ... Fix memory leak (PR XYZ). ABC-2 ... Upstream update. Ralf Could one of these help? A) Generate RPM changelog automatically from git, but only process commit messages with some token, like %changelog B) Have package maintainers use git commit editing tools to make a 'clean history' - squash typo commits, for example, and replace merge messages with something more informative. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On 05/14/2012 03:02 PM, Tomas Radej wrote: Hi, I was wondering if Packaging Guidelines could be amended so that even when creating tarball from VCS, using a standalone shell script would be mandatory (see http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control ). I believe this could allow easier reviews and package updates as there would be no need to copypaste code from comments, and checking for package's checksum could be (at least partially) automated for the fedora-review tool. What do you think? Regards, I think this is a very good idea, and I'm going to do this for my next package. Thank you for suggesting it. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This karma stuff is a pain!
On 03/15/2012 08:24 PM, Kevin Kofler wrote: Adam Williamson wrote: Luke Macken does Bodhi. It certainly sounds non-trivial to me, for a start, Bodhi uses FAS and Bugzilla does not. It would be trivial if these decisions would be made by a human who is CCed on both (i.e. the maintainer of the package) rather than by software. Kevin Kofler Policy always hinders the most talented workers (in this case, the best package maintainers). The purpose of policy is to limit the damage a less experienced package maintainer can do. How do we prevent an inexperienced package maintainer from prematurely pushing updates to stable? Perhaps you could allow package maintainers to add karma, but only on a special page. The page has a short blurb explaining karma policy, and if the maintainer wants to add karma himself, they have to click the reason they're adding karma. ( ) Works for me Comment in bugzilla ( ) etc.. (other acceptable reasons) This is probably only worth the effort if there is more than one acceptable reason, and they are sufficiently common. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On 02/29/2012 01:15 PM, drago01 wrote: On Wed, Feb 29, 2012 at 1:02 PM, Neal Beckerndbeck...@gmail.com wrote: I think he's got a point http://www.osnews.com/story/25659/Torvalds_requiring_root_password_for_mundane_things_is_quot_moronic_quot_ Yeah but last time we tried this in fedora it got flamefested so we had to revert. Perhaps a solution is adding a group with the needed permissions and make it really easy to add an account to that group. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
service iptables save, systemctl, and unhelpful error messages
Currently, on Fedora 16, service iptables save prints the following: # service iptables save Redirecting to /bin/systemctl save iptables.service Unknown operation save The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) From a technical perspective, that would mean the /sbin/service wrapper would need to be rewritten check a file for the command that is being asked to do, and print different error messages depending on the situation. Of course that makes the currently simple wrapper script more complex, but if we want to keep moving forward as fast as Fedora is, we should make the extra effort to stay friendly to our users too. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 03:45 PM, Jóhann B. Guðmundsson wrote: snip The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) snip Somehow I doubt that any bugs will be fixed for this in either systemd ( since this is not systemd bug ) or iptables ( since Thomas is working on the new stuff and this does probably not climb high enough in his priority list anyway he probably would not fix this until all the bits for that are in place). So if you or others want this fixed I'm pretty sure either side ( most notably iptables ) would gladly review and accept patches should they be submitted. JBG I propose the following script in /etc/init.d/iptables #!/bin/sh # Please use systemctl to manage the iptables service # The old initscript is in /usr/libexec/iptables.init case $1 in panic|save) [ -c /dev/stderr ] \ echo This is no longer supported with systemd. \ Please use /usr/libexec/iptables.init $1 /dev/stderr exit 2 ;; *) [ -c /dev/stderr ] echo $Redirecting to \ /bin/systemctl $@ iptables.service /dev/stderr exec /bin/systemctl $@ iptables.service ;; esac The behavior of this script is the exactly the same as the current situation, except that the error message is much more userfriendly. The packaging guidelines say this If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins at http://fedoraproject.org/wiki/Packaging:Systemd Can wrapper scripts such as the above be made into an exception for this rule? I am happy Fedora can move forward as fast as it does, but the users have to move forward with us. Providing helpful error messages for deprecated behavior, that point in the right direction, could be a big help to make the transitions as easy as possible for our users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/16/2012 02:06 AM, Jóhann B. Guðmundsson wrote: On 02/15/2012 11:09 PM, Emanuel Rietveld wrote: I propose the following script in /etc/init.d/iptables I propose you file a BUG against IPTABLES and put your proposal into that bug report then wait and see what Thomas has to say. JBG I did so. Thomas pointed out that complying with my request would be against the packaging guidelines and suggested this needs to be discussed at best on Fedora-devel. The addition of 'at best' in there leads me to believe that he is not especially interested in my proposal, but may be willing to add the wrapper script if I get wider support for it and/or get the packaging guidelines changed. Presumably, getting the packaging guidelines changed involves a lot of people's attention - people who are generally already very busy, and do not really want to spend precious brain cycles and time on what is ultimately a minor improvement visible to only a small number of people. Oh well, at least I tried. Thanks Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 01:32 PM, Panu Matilainen wrote: To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those fake compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - Would it be possible to leave out these provides and fix each individual package to require in the new path instead? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Usr Move - More, Please
On 01/30/2012 03:38 PM, Mike Pinkerton wrote: You might not want to encourage the app model, but that boat already left the dock. For Linux distros to be players on portables and desktops, they need to recognize that there is an appetite among the user base for app type programs that are easy to install (drag-and-drop). By bundling most of their dependencies, app type programs become one way to create a cross-distro app marketplace. If we end up with separate app marketplaces for Fedora, SUSE, Debian, Ubuntu, et alios, they are all going to languish. On the other hand, a single app marketplace for mainstream Linux distros might well prosper. Unifying package management across distros would a Good Thing (tm). Once there's a unified interface to the package management system, you can envision things like app marketplaces that simply instruct the distribution to install that distribution's package of a particular app. Clicking Firefox would do yum install firefox on fedora and apt-get install firefox on Ubuntu. Let us do everything in our power to make this happen! Two things that are not a good thing - Installing software outside of the package management system (instead, get the package included in fedora or rpmfusion) - Statically linked libraries or 'bundled' libraries (See: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ) As for propietary software, there's nothing the open source community can do to influence the design decisions of proprietary software vendors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service and user-agent disclosure - please consider privacy
On 01/11/2012 12:43 PM, Richard wrote: On Tue, Jan 10, 2012 at 10:53:52PM +0100, nodata wrote: Fonts are a bigger threat to privacy, see here: http://panopticlick.eff.org/ Maybe I am missing something, but isn't this only relevant if your IP is not visible to the web server? Otherwise, you can trivially be tracked by your IP address. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
Hi. I'm interested in helping out (comaintainer?), but I'm a little scared - I don't know much about java yet, nor java packaging guidelines, or whatever relevant guidelines, and I might need a little handholding. Maybe you can give me something useful but not urgent that you need done, that is easy for you to check if I did it right, and I can work on it? Emanuel On 11/22/2011 09:51 AM, Aleksandar Kurtakov wrote: Can I be added to the list of maintainers that need help very badly from the beginning? I maintain a number of packages that are very low in the Java stack and would force the whole Java stack to be removed if they are removed but noone wants to maintain them. That's how I gained them! If such a policy is adopted it would be very bad decision if there isn't a mechanism prior to that for maintainers to list packages that they maintain to keep the distro integrity but don't care about them personally. I bet that there would be a very big list of maintainers that would list a number of there packages in this list. To give a better estimate - I'm owner of 69 packages(139 comaintainer) of these I would like to maintain only 11 (eclipse*) packages but the rest is crucial to something. The problem should be obvious now - I would like to list this 58 packages as something I need help with. And to explain things better - yes I do fix bugs when they arrive in this packages- but just a real bugs (broken functionality, crashers, etc.) and let aside bugs asking for new version update, new functionality, pony:) until I need them. It's volunteer based effort and NOONE has the right to put more burden on packagers or you will lose them. And everyone stop telling the story about disappointed bug reporters, why noone is saying about disappointed maintainers? My experience is quite the opposite at least 7 out of 10 bug reports are from people that don't want to help. I'm speaking for bug reports that stay needing info from reporters for weeks and months before I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar decision should be made to ban bugzilla accounts that don't respond to information requests from maintainers. If a packager is losing time for reporters if he doesn't respond, there are for sure reporters that lose time of the packagers. In my case they lose me so much time that I would have probably fixed some of the bugs that I haven't responded to!!! Does the previous paragraph sounds right? HELL NO!! There should be an effort to make more people help as much as they can (even if it's one day per year), not an effort to put more burden on people that are already doing work. Pissed by the constant efforts to draw maintainers as lazy and non-responsive, Alexander Kurtakov - Original Message - From: Kevin Fenzi ke...@scrye.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 12:36:39 AM Subject: Re: Fedora clean up process seems to be seriously broken... On Mon, 21 Nov 2011 14:03:43 -0800 Jesse Keating jkeat...@j2solutions.net wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I don't think anybody disagrees (well maybe KKoffler) that unmaintained software should be discovered and ejected from the distro, the entirety of the problem lies how to discover (as well as side issues about what to do about maintainers that are active for one package, but completely ignore 3 others, etc…) So if you are serious about wanting this fixed, draft a proposal, figure out who's going to do the coding work, and bring it to FESCo. To quote Ajax: +! I think the current policy is not very ideal either, but haven't had time/energy to work out a new one. ;) My last thought was to come up with a automated/script way to gather info from: bugzilla, pkgdb, koji, git, mailing lists, etc and output a list of 'likely inactive people'. Then, have a group of humans look at the list, and try and contact/ping people. With no reply after a timeperiod, orphan their packages. Note that we need to balance here cases like: * maintainer is very active, just ignoring $leafpackage right now. * maintainer is on vacation/sick/etc * maintainer needs help, we should try and help them out. * maintainer doesn't use our bugzilla as their primary bug zone. * maintainer maintains a software that has a vast number of bugs and they can't deal with them all. * maintainer is working on higher priority bug, so ignoring feature requests/etc. Anyhow, I for one would welcome written up, concrete proposals here. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 750566 - qtparted won't install because it is from F15 and requires libparted.so.0, and F16 has libparted.so.1
On 11/03/2011 07:34 AM, Kevin Kofler wrote: Tom Callaway wrote: I took a quick look at qtparted a few days ago, the problem is that qtparted depended on functionality (move, copy, resize) in parted that no longer exists in parted-3.0. snip Removing features like this, without providing any kind of a replacement, is a very unhelpful move from upstream. Kevin Kofler If I recall correctly, the code was removed because it was unmaintained. Upstream may be willing to support these features again if somebody steps up to maintain it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Request Need Sponsor: Ruby 2.3.12 in Fedora 15+
See https://bugzilla.redhat.com/show_bug.cgi?id=726690 Although Rails 3 was released, there are still rails projects working with rails 2.3 series. Rails 3 is not backwards compatible and some key features are not yet working in Rails 3. One notable project still on rails 2.3 is the issue tracker redmine http://www.redmine.org Since rails 2 and rails 3 are perfectly parallel installable, I would like to maintain rails 2.3 series in Fedora until it really becomes obsolete. Therefore I have packaged Ruby 2.3.12 for F15/F16, basing them on the Rails 2.3.8 packages already in F14. This is my first package for Fedora and I welcome any feedback. Thank you for your time. -Emanuel -- Forwarded message -- From: Mo Morsi m...@morsi.org Date: Tue, Aug 2, 2011 at 9:24 PM Subject: Re: Rails 2 in F16 To: Emanuel Rietveld codehot...@gmail.com Hey Emanuel, appreciate the effort. Will look at it if I get the chance, but time is short nowadays so not sure when that is going to be. Most likely you will have luck if you email the ruby sig directly. http://lists.fedoraproject.org/pipermail/ruby-sig/ Since you are a new packager though, you will have to go through the sponsorship process. Not hard, but it could take longer. Take care, -Mo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
