Re: Fedora 18 Release name voting and Poll for whether to continue naming releases
On Apr 20, 2012 5:34 PM, Matej Cepl mc...@redhat.com wrote: On 20.4.2012 18:09, Ralf Corsepius wrote: Never. Nobody uses the code names. It's a waste of time and choosing names like Beefy Miracle is a good way of making the distro look a whole lot less professional. Well, as far as I can tell, many Ubuntu and Debian users prefer to call their release by name. Yes, and I wonder why Fedora users just don't it. Nobody knows why, either we have too stupid names, or we are too geeky, or something. And I have to admit, that although my first Debian was potato and I have switched to Fedora just before etch (and I have no idea, what was the number of these releases), I have never felt the smallest inclination to call my first Fedora distro anything else than Fedora Core 6. No one knows why? There is the obvious effect of inertia from the fact that there is a LONG history of referring to releases by version number going all the way back to Red Hat Linux 2.0 in 1995. (Before that, nearby holidays were used...) And so far there has been zero PR effort to change this well established practice. As I remember it, the fact that there even was a code name was not widely advertised until well into the Fedora releases. I'm pretty sure that's the reason. (User since RHL 5.2, on an Alpha Multia) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Eliminating automatic provides on private libs
I started once again looking at ways to eliminate the unwanted provides on private libs such as dlopen()'ed modules with minimal fuss and breakage. Been down this route more than once but I suspect the last time was before the major dependency generator changes in rpm-4.9.x, which made tweaking these things a good deal easier, so time for another round: The short background is that for libraries which dont have a SONAME, rpmbuild fakes one based on the file name. The rationale for this has been that since the linker permits linking to libraries without sonames, rpm must permit this too. The downside is that for the 1% corner cases that need this, we end up polluting the provides namespace with thousands of unnecessary and unwanted names, names that have not been picked up with a global namespace in mind. To get a rough idea just how much of this unwanted junk exists, using a slightly modified elfdeps generator on my system: This is how we currently generate the provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only --fake-soname|wc -l 3875 And this is without faked soname provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only |wc -l 2816 So... about a third of the soname provides are faked by using library basename for its provide name, and almost all of them are for no good reason. The three general cases that something actually depends on are 1) libreoffice sub-packages depending on its internal libraries from libreoffice-core 2) a handful of packages depending on llvm libraries 3) bigger pile of packages depending on libperl.so Of these at least 2) does look like a bug really, and in fact has been fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about 3), perl is... what it is. 1) might well classify as an inevitable special case (there will always be those), dunno. Obviously this is just a fairly small sample of the entire Fedora package set, there are bound to be many more special cases, buggy libraries which do not have SONAME when they should and stuff that falls into gray areas. I can try to provide more comprehensive stats based on current rawhide if needed. I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Oh and of course eliminating the faked soname provides does not eliminate all unwanted provides, eg libtool adds a soname even when -module is used. But ... you need to start someplace. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Eliminating automatic provides on private libs
On 04/27/2012 09:13 AM, Panu Matilainen wrote: I started once again looking at ways to eliminate the unwanted provides on private libs such as dlopen()'ed modules with minimal fuss and breakage. Been down this route more than once but I suspect the last time was before the major dependency generator changes in rpm-4.9.x, which made tweaking these things a good deal easier, so time for another round: The short background is that for libraries which dont have a SONAME, rpmbuild fakes one based on the file name. The rationale for this has been that since the linker permits linking to libraries without sonames, rpm must permit this too. The downside is that for the 1% corner cases that need this, we end up polluting the provides namespace with thousands of unnecessary and unwanted names, names that have not been picked up with a global namespace in mind. To get a rough idea just how much of this unwanted junk exists, using a slightly modified elfdeps generator on my system: This is how we currently generate the provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only --fake-soname|wc -l 3875 And this is without faked soname provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only |wc -l 2816 So... about a third of the soname provides are faked by using library basename for its provide name, and almost all of them are for no good reason. The three general cases that something actually depends on are 1) libreoffice sub-packages depending on its internal libraries from libreoffice-core 2) a handful of packages depending on llvm libraries 3) bigger pile of packages depending on libperl.so Of these at least 2) does look like a bug really, and in fact has been fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about 3), perl is... what it is. 1) might well classify as an inevitable special case (there will always be those), dunno. Obviously this is just a fairly small sample of the entire Fedora package set, there are bound to be many more special cases, buggy libraries which do not have SONAME when they should and stuff that falls into gray areas. I can try to provide more comprehensive stats based on current rawhide if needed. I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Oh and of course eliminating the faked soname provides does not eliminate all unwanted provides, eg libtool adds a soname even when -module is used. But ... you need to start someplace. Regarding perl, of the 48 packages that require libperl.so in Rawhide, only 13 of them don't also require perl(:MODULE_COMPAT_5.14.2), which will also pull in the perl-libs package, so I don't think perl is a big issue. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Eliminating automatic provides on private libs
On 04/27/2012 11:25 AM, Paul Howarth wrote: On 04/27/2012 09:13 AM, Panu Matilainen wrote: I started once again looking at ways to eliminate the unwanted provides on private libs such as dlopen()'ed modules with minimal fuss and breakage. Been down this route more than once but I suspect the last time was before the major dependency generator changes in rpm-4.9.x, which made tweaking these things a good deal easier, so time for another round: The short background is that for libraries which dont have a SONAME, rpmbuild fakes one based on the file name. The rationale for this has been that since the linker permits linking to libraries without sonames, rpm must permit this too. The downside is that for the 1% corner cases that need this, we end up polluting the provides namespace with thousands of unnecessary and unwanted names, names that have not been picked up with a global namespace in mind. To get a rough idea just how much of this unwanted junk exists, using a slightly modified elfdeps generator on my system: This is how we currently generate the provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only --fake-soname|wc -l 3875 And this is without faked soname provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only |wc -l 2816 So... about a third of the soname provides are faked by using library basename for its provide name, and almost all of them are for no good reason. The three general cases that something actually depends on are 1) libreoffice sub-packages depending on its internal libraries from libreoffice-core 2) a handful of packages depending on llvm libraries 3) bigger pile of packages depending on libperl.so Of these at least 2) does look like a bug really, and in fact has been fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about 3), perl is... what it is. 1) might well classify as an inevitable special case (there will always be those), dunno. Obviously this is just a fairly small sample of the entire Fedora package set, there are bound to be many more special cases, buggy libraries which do not have SONAME when they should and stuff that falls into gray areas. I can try to provide more comprehensive stats based on current rawhide if needed. I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Oh and of course eliminating the faked soname provides does not eliminate all unwanted provides, eg libtool adds a soname even when -module is used. But ... you need to start someplace. Regarding perl, of the 48 packages that require libperl.so in Rawhide, only 13 of them don't also require perl(:MODULE_COMPAT_5.14.2), which will also pull in the perl-libs package, so I don't think perl is a big issue. In these cases, it's not a question of what other requires they might have. If something links against a library (in this case libperl.so), causing a require to be generated, something needs to provide that dependency. So in the case of libperl.so, the choices would basically be either: a) Add an actual soname to libperl.so (since it's something that other packages do link against, this would seem reasonable but then I dont know the perl world pecularities at all...) b) Enable the switch (whatever it will be) to generate these fake soname provides in the main perl package (or add the provide manually in the spec, but that gets ugly real fast) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Private-libraries in /usr/lib* - invalid soname.
On Mon, 23 Apr 2012 16:01:16 +0200, AL (Alec) wrote: I am am a newbie, and although the overall wiki rule is Be Bold this is not really the place for me to be that IMHO. So, I have prepared a draft in https://fedoraproject.org/wiki/Talk:Common_Rpmlint_issues (the Discussion tab). My plan is to become bold and move that into the wiki page later on. Would really need som input before doing that, though. https://fedoraproject.org/wiki/Talk:Common_Rpmlint_issues loads an error page that reads: | Talk:Common Rpmlint issues | | The following metadata was found in MoinMoin that could not be converted | to a useful value in MediaWiki: | | * : hack to omit unused-direct-shlib-dependencies | * acl: Known:read,write All:read -- Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64 loadavg: 0.10 0.04 0.05 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 slow keys keeps activating (maybe xfce?)
I filed a bug about this, but I've no idea what component to file it against, so it's against something fairly random: https://bugzilla.redhat.com/show_bug.cgi?id=816764 After updating Fedora 17 to latest a couple of days ago, my keyboard keeps dying. In fact I found out that what's happening is an accessibility feature called slow keys is getting activated. Unfortunately this is activated silently, so there is no indication what has happened, nor how to revert it. This is going to cause a lot of problems for less technical users, since the only way out for them is to reboot. Also, in the Accessibility menu, it shows that slow keys is disabled. You have to enable and disable it (using the mouse) in order to fix the bug. And it keeps happening too ... It's happened twice already this morning. I don't know what I am doing/pressing which starts this off. Some usability lessons: * Never activate a feature without visual feedback. * Make it easy and obvious to revert. * Provide a way to permanently disable accessibility features for those who don't need them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 slow keys keeps activating (maybe xfce?)
On 27/04/12 11:16, Richard W.M. Jones wrote: * Provide a way to permanently disable accessibility features for those who don't need them. Rich. I don't have an accessibility menu on Xfce F17 or Rawhide. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: iwlwifi still hangs, clunky workaround
On Thu, Apr 26, 2012 at 09:27:23PM -0400, Paul Wouters wrote: A workaround that makes the wifi bearable (but not pleasant) is: modprobe iwlwifi wd_disable=1 Thanks. This is an improvement over what I was doing which was: * Disable wireless in NetworkMangler. * modprobe -r iwlwifi * modprobe iwlwifi * Enable wireless. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Private-libraries in /usr/lib* - invalid soname.
On 04/27/2012 11:32 AM, Michael Schwendt wrote: On Mon, 23 Apr 2012 16:01:16 +0200, AL (Alec) wrote: You I am am a newbie, and although the overall wiki rule is Be Bold this is not really the place for me to be that IMHO. So, I have prepared a draft in https://fedoraproject.org/wiki/Talk:Common_Rpmlint_issues (the Discussion tab). My plan is to become bold and move that into the wiki page later on. Would really need som input before doing that, though. https://fedoraproject.org/wiki/Talk:Common_Rpmlint_issues loads an error page that reads: | Talk:Common Rpmlint issues | | The following metadata was found in MoinMoin that could not be converted | to a useful value in MediaWiki: | | * : hack to omit unused-direct-shlib-dependencies | * acl: Known:read,write All:read Yup, I became bold and the draft is now in the real page after waiting for input both here and in IRC. Look at the history tab. --a -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Eliminating automatic provides on private libs
Hi, On 04/27/2012 10:13 AM, Panu Matilainen wrote: I started once again looking at ways to eliminate the unwanted provides on private libs such as dlopen()'ed modules with minimal fuss and breakage. Been down this route more than once but I suspect the last time was before the major dependency generator changes in rpm-4.9.x, which made tweaking these things a good deal easier, so time for another round: The short background is that for libraries which dont have a SONAME, rpmbuild fakes one based on the file name. The rationale for this has been that since the linker permits linking to libraries without sonames, rpm must permit this too. The downside is that for the 1% corner cases that need this, we end up polluting the provides namespace with thousands of unnecessary and unwanted names, names that have not been picked up with a global namespace in mind. To get a rough idea just how much of this unwanted junk exists, using a slightly modified elfdeps generator on my system: This is how we currently generate the provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only --fake-soname|wc -l 3875 And this is without faked soname provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only |wc -l 2816 So... about a third of the soname provides are faked by using library basename for its provide name, and almost all of them are for no good reason. The three general cases that something actually depends on are 1) libreoffice sub-packages depending on its internal libraries from libreoffice-core 2) a handful of packages depending on llvm libraries 3) bigger pile of packages depending on libperl.so Of these at least 2) does look like a bug really, and in fact has been fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about 3), perl is... what it is. 1) might well classify as an inevitable special case (there will always be those), dunno. Obviously this is just a fairly small sample of the entire Fedora package set, there are bound to be many more special cases, buggy libraries which do not have SONAME when they should and stuff that falls into gray areas. I can try to provide more comprehensive stats based on current rawhide if needed. I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Great! Can we disable these bogus provides starting tomorrow please? :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fest Swing: Package review and sponsoring required. Was: Self Introduction
Il giorno mer, 25/04/2012 alle 18.36 +0200, Mario Torre ha scritto: Hello all! I'm trying to package Fest for Fedora, and I need a sponsor for this first package: https://bugzilla.redhat.com/show_bug.cgi?id=816264 This is my first package, but I'm not new to Fedora, I recently joined Red Hat, after many year of Free Software work with other companies, I've been using Fedora since Fedora Core 1, and before that I was a Red Hat Linux user (since 6.0!). During the years, I've contribute some fixes here and there in Fedora packages (although mostly upstream), but this is my first attempt at packaging a full rpm set of packages. Cheers, Mario Hello all! I added few more packages, they are all needed for Fest Swing: https://bugzilla.redhat.com/show_bug.cgi?id=816264 https://bugzilla.redhat.com/show_bug.cgi?id=816926 https://bugzilla.redhat.com/show_bug.cgi?id=816927 https://bugzilla.redhat.com/show_bug.cgi?id=816957 https://bugzilla.redhat.com/show_bug.cgi?id=816962 https://bugzilla.redhat.com/show_bug.cgi?id=816967 Can somebody please give a look at them? Thanks, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Elections: General information, and questionnaire opening.
GREETINGS! It is once again time for election season to begin. As noted in the elections schedule[1], the elections questionnaire is now open to populate with questions for candidates, and will close on May 8th. The elections nomination period will begin AFTER the questionnaire period has closed. You may add your burning questions for candidates to answer here: http://fedoraproject.org/wiki/F18_elections_questionnaire The following seats are available in this election: * Fedora Project Board: 3 seats * FESCo (Fedora Engineering Steering Committee): 5 seats * FAmSCo (Fedora Ambassadors Steering Committee): 7 seats Please take note of the following changes for this election: * All questions for the questionnaire must be submitted by May 8th, prior to the beginning of nominations. As seen in the schedule above, the nomination period does not start until May 9th. * As noted on announce-list[2], FAmSCo is electing all 7 seats this cycle, with the goal of having staggered elections similar to the Board and FESCo. Additionally, voting eligibility has been widened to allow anyone who has signed the FPCA AND is a member of at least one additional non-FPCA/CLA group. (In other words: No longer just ambassadors, but those part of other teams as well.) Full election information may be seen here: http://fedoraproject.org/wiki/Elections Participating in these bodies are one of many ways to contribute to Fedora; I encourage you to consider running, or to urge those you believe are excellent candidates to run. Additionally, your contributions are welcomed in helping to keep the elections running smoothly; volunteers are needed to help collect questionnaire answers from candidates, as well as for scheduling and moderating town halls. If you are interested in helping with those efforts, please contact John Rose[3]. And a big thank you! to John for coordinating the elections thus far, your efforts are very much appreciated. -Robyn [1]http://fedoraproject.org/wiki/Elections#Committee_Elections_Schedule [2]http://lists.fedoraproject.org/pipermail/announce/2012-April/003063.html [3]http://fedoraproject.org/wiki/User:Inode0 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
Dne 26.4.2012 18:13, Alec Leamas napsal(a): On 04/26/2012 05:49 PM, Michael Schwendt wrote: On Thu, 26 Apr 2012 17:32:17 +0200, AL (Alec) wrote: OT? The question here isn't really what submitters do or don't, isn't it what we could do to improve the process?. The point is that not all submitters are collaborative, and others don't seek for sponsors actively. In the needsponsor queue are lots of tickets where packages are not ready or where a reviewer is simply waiting for the submitter to respond. It isn't so easy to find submitters who are willing for compromise and adapt the Fedora's requirements. People are note always nice, agreed. But isn't part of the problem that current process forces people which just are interested in a package to suddenly discover that they are applying to be packagers? Shouldn't some of these cases be better off if they could drop their package in some kind of wishlist 2.0, and try to get in contact with a packager instead? I am thinking about some dumping repository, where people would dump their packages and they would need almost no qualification. Of course using such packages would be without any warranty. The packages would not be owned by anybody, so everybody would improve them (or eventually corrupt them ;)). Once somebody would be interested enough to become official maintainer, he would apply to official review and the package would get into official Fedora repo. Actually it shouldn't be that hard to achieve it with tiny changes to current infrastructure IMO. It seems to be still better option then to trust to 3rd party repo or OBS. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Public thanks
I want to publicly thank Jon Ciesla for helping me out and saving me lots of time here. I had been requesting EPEL builds of rabbitvcs and nautilus-python for many many months, but no one was responding to me. And it was definitely not worth the effort to become a co-maintainer and learning the ropes, just for a couple of packages. Jon voluntarily took over the EPEL versions and got them through the door in a very short time, although he had no responsibility on the packages. So the least I can do is to thank him! :) rabbitvcs finally can be installed smoothly on RHEL CentOS! -Caghan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
On Fri, 2012-04-27 at 15:10 +0200, Antonio Trande wrote: The poll about Fedora release names keeping is terminated [1]https://admin.fedoraproject.org/voting/results/poll-rel-names?_csrf_token=ed7209dc06f5c8c58528ac55251f52c8ffacdc40. Just for reference for the future, the last part of your url is not necessary (all the part after the ?_csrf). So you can provide a short url by just kicking it out: https://admin.fedoraproject.org/voting/results/poll-rel-names Thus avoiding to spread an obfuscated url. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
- Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, 2012-04-27 at 15:10 +0200, Antonio Trande wrote: The poll about Fedora release names keeping is terminated [1]https://admin.fedoraproject.org/voting/results/poll-rel-names?_csrf_token=ed7209dc06f5c8c58528ac55251f52c8ffacdc40. Just for reference for the future, the last part of your url is not necessary (all the part after the ?_csrf). So you can provide a short url by just kicking it out: https://admin.fedoraproject.org/voting/results/poll-rel-names Thus avoiding to spread an obfuscated url. The poll should really have run through the regular elections to reach a wider user base. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
On Fri, 27 Apr 2012 15:10:45 +0200, AT (Antonio) wrote: The poll about Fedora release names keeping is terminated [1]https://admin.fedoraproject.org/voting/results/poll-rel-names?_csrf_token=ed7209dc06f5c8c58528ac55251f52c8ffacdc40. And now ? Well, I've missed the announcement of this poll. Where has it been announced? -- Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64 loadavg: 0.12 0.08 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Net-SSH2-0.44.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-SSH2: 0d18993d7783357b38e47212e64a1d96 Net-SSH2-0.44.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Install Fedora Button for LiveCD
There seems to be at least some consensus that: * The notification, unless permanent, is not an ideal solution here because once it goes away, the user is in the same situation of confusion as to how to install the Live Image to disk. * The extension as proposed is not an ideal solution because it is too intrusive a change on the GNOME Shell design that the Live Image is demonstrating. * Autostarting anaconda at startup is not an ideal solution because there are many valid use-cases for the Live Image where this would not be wanted, and also, if the new user closes it, they will have the same difficulty launching it again later when they are ready. * Launching a install or try it uninstalled merely masks the issue, because when the user selects try it uninstalled, they have the same difficulty finding the installer again later when they are ready. Would it be possible to design an extension that has a minimal impact on the GNOME Shell design and still provides a clear, persistent, and obvious way to install the Live Image to disk? ~tom The discussion has died. I have lost any hope that it could lead to a positive output, so I'll not push any more. The desktop SIG expressed clear and utter NO. For the last two Fedora releases new Fedora users have been having a hard time to locate the installer. It seems to be clear that nothing will change in Fedora 17. I find it sad how desktop guys try to veto solutions they don't like, but they don't push on any other solutions. I also find it sad how strong their rejection is even though the overwhelming majority of other respondents like it. I'll keep the source code on github [1]. Maybe it will be useful for someone else, some time, e.g. for some Fedora spin or for a different Linux distribution. If anybody wants to continue in pushing this, and explaining better to desktop SIG, you're welcome. [1] https://github.com/kparal/InstallFedoraButton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-SSH2] 0.44 bump
commit b7fd0588c35ccedfab9c1b7d864a61a1b1287373
Author: Petr Šabata con...@redhat.com
Date: Fri Apr 27 15:22:41 2012 +0200
0.44 bump
.gitignore |1 +
perl-Net-SSH2.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 25b2a30..cd9b06e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Net-SSH2-0.28.tar.gz
/Net-SSH2-0.41.tar.gz
/Net-SSH2-0.42.tar.gz
/Net-SSH2-0.43.tar.gz
+/Net-SSH2-0.44.tar.gz
diff --git a/perl-Net-SSH2.spec b/perl-Net-SSH2.spec
index f408602..911f170 100644
--- a/perl-Net-SSH2.spec
+++ b/perl-Net-SSH2.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSH2
-Version:0.43
+Version:0.44
Release:1%{?dist}
Summary:Support for the SSH 2 protocol via libSSH2
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Apr 27 2012 Petr Šabata con...@redhat.com - 0.44-1
+- 0.44 bump
+
* Tue Apr 24 2012 Petr Šabata con...@redhat.com - 0.43-1
- 0.43 bump
diff --git a/sources b/sources
index 08c9f30..dd5e960 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f1d62af340e05e0aba33c4ec1c342f2 Net-SSH2-0.43.tar.gz
+0d18993d7783357b38e47212e64a1d96 Net-SSH2-0.44.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora release name in the future
The poll should really have run through the regular elections to reach a wider user base. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel What do you mean with regular elections ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
http://lists.fedoraproject.org/pipermail/devel/2012-April/166087.html On Fri, Apr 27, 2012 at 2:22 PM, Michael Schwendt mschwe...@gmail.comwrote: On Fri, 27 Apr 2012 15:10:45 +0200, AT (Antonio) wrote: The poll about Fedora release names keeping is terminated [1] https://admin.fedoraproject.org/voting/results/poll-rel-names?_csrf_token=ed7209dc06f5c8c58528ac55251f52c8ffacdc40 . And now ? Well, I've missed the announcement of this poll. Where has it been announced? -- Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64 loadavg: 0.12 0.08 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
I have seen way too many problems caused by people installing such *nonmaintained* packages to even think this will cause more troubles than it will solve. Alex - Original Message - From: Vít Ondruch vondr...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, April 27, 2012 3:32:33 PM Subject: Re: Proposal for revitalizing the sponsorship process for packaging Dne 26.4.2012 18:13, Alec Leamas napsal(a): On 04/26/2012 05:49 PM, Michael Schwendt wrote: On Thu, 26 Apr 2012 17:32:17 +0200, AL (Alec) wrote: OT? The question here isn't really what submitters do or don't, isn't it what we could do to improve the process?. The point is that not all submitters are collaborative, and others don't seek for sponsors actively. In the needsponsor queue are lots of tickets where packages are not ready or where a reviewer is simply waiting for the submitter to respond. It isn't so easy to find submitters who are willing for compromise and adapt the Fedora's requirements. People are note always nice, agreed. But isn't part of the problem that current process forces people which just are interested in a package to suddenly discover that they are applying to be packagers? Shouldn't some of these cases be better off if they could drop their package in some kind of wishlist 2.0, and try to get in contact with a packager instead? I am thinking about some dumping repository, where people would dump their packages and they would need almost no qualification. Of course using such packages would be without any warranty. The packages would not be owned by anybody, so everybody would improve them (or eventually corrupt them ;)). Once somebody would be interested enough to become official maintainer, he would apply to official review and the package would get into official Fedora repo. Actually it shouldn't be that hard to achieve it with tiny changes to current infrastructure IMO. It seems to be still better option then to trust to 3rd party repo or OBS. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
On Fri, 27 Apr 2012 14:23:31 +0100, JL (Johannes) wrote: Well, I've missed the announcement of this poll. Where has it been announced? http://lists.fedoraproject.org/pipermail/devel/2012-April/166087.html I haven't received that mail. I've tracked down the announcement in the list [web]archives of announce and devel-announce list, also found a huge thread of replies in my devel list folder, but not the original message. No Fedora Planet post about it either. Strange. Something has gone wrong here. And one week has not been enough time for me to notice that. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64 loadavg: 0.17 0.07 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
* Michael Schwendt [27/04/2012 15:31] : Well, I've missed the announcement of this poll. Where has it been announced? http://lists.fedoraproject.org/pipermail/announce/2012-April/003060.html http://lists.fedoraproject.org/pipermail/devel-announce/2012-April/000919.html Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
- Antonio Trande anto.tra...@gmail.com wrote: The poll should really have run through the regular elections to reach a wider user base. What do you mean with regular elections ? The board, FESCo and FAMSCo elections that happen regularly with every release. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Hi Kamil, On Fri, 2012-04-27 at 09:22 -0400, Kamil Paral wrote: but they don't push on any other solutions. A link from the http://fedoraproject.org/get-fedora page directly to http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Quick_Start_Guide/Fedora_Live_Desktop.html ? To be honest I'm torn myself because I do sometimes use live images for their try before you buy ability, not necessarily to install to disk right at that second. But having an extension installed by default has a lot of technical ramifications; for example, it'll also get copied to the hard disk after you install. Also, while I'm not an artist or designer, I think it looks pretty ugly... The whole thing is clearly a mess that needs some high level streamlining, from the entire process of download from web page (or receive CD from friend) to the on-disk install first boot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File DBI-1.620.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBI: 2dfcff5b3b7afc53be402ef5f133da00 DBI-1.620.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBI] 1.620 bump
commit 687a29a9c26d3ea0b9704b6c5cf9e03d2373904b
Author: Petr Šabata con...@redhat.com
Date: Fri Apr 27 15:57:31 2012 +0200
1.620 bump
.gitignore|1 +
perl-DBI.spec | 12 ++--
sources |2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f9dd924..35603c3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ DBI-1.613.tar.gz
/DBI-1.616.tar.gz
/DBI-1.617.tar.gz
/DBI-1.618.tar.gz
+/DBI-1.620.tar.gz
diff --git a/perl-DBI.spec b/perl-DBI.spec
index a0f90c7..2bb8210 100644
--- a/perl-DBI.spec
+++ b/perl-DBI.spec
@@ -1,6 +1,6 @@
Name: perl-DBI
-Version:1.618
-Release:3%{?dist}
+Version:1.620
+Release:1%{?dist}
Summary:A database access API for perl
Group: Development/Libraries
License:GPL+ or Artistic
@@ -24,12 +24,10 @@ BuildRequires: perl(DynaLoader)
BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
BuildRequires: perl(Fcntl)
-BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Select)
-BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Math::BigInt)
# MLDBM is optional
BuildRequires: perl(MLDBM)
@@ -43,10 +41,8 @@ BuildRequires: perl(Scalar::Util)
BuildRequires: perl(SQL::Statement) = 1.28
%endif
BuildRequires: perl(Storable)
-BuildRequires: perl(Symbol)
BuildRequires: perl(threads)
BuildRequires: perl(Tie::Hash)
-BuildRequires: perl(UNIVERSAL)
# Tests
BuildRequires: perl(Encode)
BuildRequires: perl(File::Path)
@@ -111,6 +107,10 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Apr 27 2012 Petr Šabata con...@redhat.com - 1.620-1
+- 1.620 bump
+- Removing some perl-provided explicit dependencies
+
* Fri Apr 6 2012 Marcela Mašláňová mmasl...@redhat.com - 1.618-3
- 810370 apply Paul's bootstrap macro
diff --git a/sources b/sources
index 9af83ef..a0d1f73 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5ad29b56f7457f22bd1ca1c871b30719 DBI-1.618.tar.gz
+2dfcff5b3b7afc53be402ef5f133da00 DBI-1.620.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Install Fedora Button for LiveCD
On Fri, Apr 27, 2012 at 9:50 AM, Colin Walters walt...@verbum.org wrote: The whole thing is clearly a mess that needs some high level streamlining, from the entire process of download from web page (or receive CD from friend) to the on-disk install first boot. While I certainly wouldn't disagree with this statement, let's not let perfect get in the way of better here. What can we do in the *near* term to make it easier for people to find the Install to Hard Drive option from the LiveCD? I understand that there are technical reasons why the extension is frowned upon -- but that shouldn't mean that we do nothing to try to improve the situation. I tried not to complain too loudly while I was the FPL, especially because GNOME Shell was new and had plenty of other things to focus on. Now that it's a bit more mature, I'd really like to come up with a better solution here. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
Quoting Michael Schwendt (2012-04-26 18:36:51) So, what has been proposed before (years ago even) is for advanced packagers (aka provenpackagers or experienced packagers) to lower the hurdle and trust them more in that they know their stuff. They would not need to wait for somebody else (possibly a fresh packager) to review'n'approve a package or just its licensing. It's considered ridiculous by some that senior packagers still need approval for even simple new packages or package renames. I am a provenpackager and I would be *extremely* dissapointed if this came to become a reality. Package review is a good thing, no matter how skilled the packager is. I have packaged quite a few packages, mostly Java ones (65 to be exact) and I still make mistakes! Guidelines change, people miss things (such as bundling, licensing issues, wrong permissions, etc.). I will put it bluntly: getting rid of package reviews would be an incredibly stupid thing to do. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Public thanks
On Fri, Apr 27, 2012 at 7:45 AM, Caghan Demirci cagh...@gmail.com wrote: I want to publicly thank Jon Ciesla for helping me out and saving me lots of time here. I had been requesting EPEL builds of rabbitvcs and nautilus-python for many many months, but no one was responding to me. And it was definitely not worth the effort to become a co-maintainer and learning the ropes, just for a couple of packages. Jon voluntarily took over the EPEL versions and got them through the door in a very short time, although he had no responsibility on the packages. So the least I can do is to thank him! :) Very welcome, anytime. blush rabbitvcs finally can be installed smoothly on RHEL CentOS! Modulo the availablity in EL-6 stable of thunarx-python. -J -Caghan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
but they don't push on any other solutions. A link from the http://fedoraproject.org/get-fedora page directly to http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Quick_Start_Guide/Fedora_Live_Desktop.html ? I've spent 5 minutes looking for that direct link and I haven't found it. Maybe I'm just blind. There's a small link for full installation guide, but I see no link for quick start guide, and no link for the page you posted. Something tells me that if I have never seen it, and couldn't find it even when looking for it, that 99% of new users won't see it as well. But having an extension installed by default has a lot of technical ramifications; for example, it'll also get copied to the hard disk after you install. Also, while I'm not an artist or designer, I think it looks pretty ugly... No, it will not get installed, I described that before (maybe just on anaconda-devel). I don't mean to haggle about it anymore. Just clearing up misconceptions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
On Fri, 27 Apr 2012 16:10:53 +0200, SO (Stanislav) wrote: Quoting Michael Schwendt (2012-04-26 18:36:51) So, what has been proposed before (years ago even) is for advanced packagers (aka provenpackagers or experienced packagers) to lower the hurdle and trust them more in that they know their stuff. They would not need to wait for somebody else (possibly a fresh packager) to review'n'approve a package or just its licensing. It's considered ridiculous by some that senior packagers still need approval for even simple new packages or package renames. I am a provenpackager and I would be *extremely* dissapointed if this came to become a reality. Package review is a good thing, no matter how skilled the packager is. I have packaged quite a few packages, mostly Java ones (65 to be exact) and I still make mistakes! Guidelines change, people miss things (such as bundling, licensing issues, wrong permissions, etc.). I will put it bluntly: getting rid of package reviews would be an incredibly stupid thing to do. Package reviews would be _optional_ for provenpackagers, not mandatory anymore. You could still open a review request and wait for a reviewer. Especially for non-trivial packages. The bottom half of your paragraph misses the point completely, btw. We don't have a review process for packages _after_ package approval. Mistakes happen, and it's possible that with any unattended version- upgrade you would introduce mistakes. Does that imply you would want mandatory reviews for every commit in git? No. Hopefully not. ;) -- Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64 loadavg: 0.00 0.01 0.05 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Fri, 2012-04-27 at 10:26 -0400, Kamil Paral wrote: but they don't push on any other solutions. A link from the http://fedoraproject.org/get-fedora page directly to http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Quick_Start_Guide/Fedora_Live_Desktop.html ? I've spent 5 minutes looking for that direct link and I haven't found it. That was my point - it doesn't exist yet as far as I know, but is an option to improve the situation. No, it will not get installed, I described that before (maybe just on anaconda-devel). OK. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: iwlwifi still hangs, clunky workaround
On Thu, 2012-04-26 at 21:27 -0400, Paul Wouters wrote: I'm still seeing the wifi lockup issues on 3.3.2-1.fc17.x86_64. The logs show: Apr 26 21:02:53 thinkpad kernel: [262822.181984] iwlwifi :02:00.0: Queue 2 stuck for 2000 ms. Apr 26 21:02:53 thinkpad kernel: [262822.181992] iwlwifi :02:00.0: Current S W read_ptr 214 write_ptr 218 Apr 26 21:02:53 thinkpad kernel: [262822.182046] iwlwifi :02:00.0: Current H W read_ptr 214 write_ptr 218 Apr 26 21:02:53 thinkpad kernel: [262822.182051] iwlwifi :02:00.0: On demand firmware reload Apr 26 21:02:53 thinkpad kernel: [262822.182826] ieee80211 phy0: Hardware restar t was requested Apr 26 21:02:53 thinkpad kernel: [262822.182908] iwlwifi :02:00.0: L1 Enable d; Disabling L0S Apr 26 21:02:53 thinkpad kernel: [262822.183495] iwlwifi :02:00.0: Radio typ e=0x0-0x3-0x1 This is a firmware failure/crash on the wireless device. Unfortunately, we don't have a lot of visibility into that. The Intel folks will need to be involved. I'll copy Wey-yi and Johannes. Hopefully they can give this some attention. You might also open a bug at bugzilla.intellinuxwireless.org for their convenience. We've been getting a lot of complaints about iwlwifi stability in general lately. We may need to flood their inboxes until they can spare us some cycles... :-) A workaround that makes the wifi bearable (but not pleasant) is: modprobe iwlwifi wd_disable=1 I can still see the failures, but at least it recovers: 64 bytes from 8.8.8.8: icmp_req=617 ttl=54 time=42.9 ms 64 bytes from 8.8.8.8: icmp_req=618 ttl=54 time=46.1 ms 64 bytes from 8.8.8.8: icmp_req=619 ttl=54 time=50.9 ms 64 bytes from 8.8.8.8: icmp_req=620 ttl=54 time=46.3 ms 64 bytes from 8.8.8.8: icmp_req=621 ttl=54 time=48.1 ms 64 bytes from 8.8.8.8: icmp_req=622 ttl=54 time=41.4 ms 64 bytes from 8.8.8.8: icmp_req=623 ttl=54 time=46.3 ms 64 bytes from 8.8.8.8: icmp_req=625 ttl=54 time=2209 ms 64 bytes from 8.8.8.8: icmp_req=626 ttl=54 time=1213 ms 64 bytes from 8.8.8.8: icmp_req=627 ttl=54 time=213 ms 64 bytes from 8.8.8.8: icmp_req=628 ttl=54 time=44.2 ms 64 bytes from 8.8.8.8: icmp_req=629 ttl=54 time=43.3 ms 64 bytes from 8.8.8.8: icmp_req=630 ttl=54 time=44.6 ms 64 bytes from 8.8.8.8: icmp_req=631 ttl=54 time=45.0 ms 64 bytes from 8.8.8.8: icmp_req=632 ttl=54 time=44.3 ms 64 bytes from 8.8.8.8: icmp_req=633 ttl=54 time=44.0 ms I still get one of these lock ups every 10 to 30 seconds, but at least I dont have to throw the hardware switch back and forth on the laptop to recover. If there is more debug info I can get someone, let me know Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- John W. LinvilleThe water won't run clean until you get linvi...@redhat.comthe pigs out of the creek. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 slow keys keeps activating (maybe xfce?)
On Fri, 27 Apr 2012 11:16:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I filed a bug about this, but I've no idea what component to file it against, so it's against something fairly random: https://bugzilla.redhat.com/show_bug.cgi?id=816764 After updating Fedora 17 to latest a couple of days ago, my keyboard keeps dying. In fact I found out that what's happening is an accessibility feature called slow keys is getting activated. Unfortunately this is activated silently, so there is no indication what has happened, nor how to revert it. This is going to cause a lot of problems for less technical users, since the only way out for them is to reboot. Also, in the Accessibility menu, it shows that slow keys is disabled. You have to enable and disable it (using the mouse) in order to fix the bug. And it keeps happening too ... It's happened twice already this morning. I don't know what I am doing/pressing which starts this off. I've also run into this, but been unsure whats causing it. I'm running Xfce here, but it might be a gnome component thats causing it. Slow keys is off in all the Xfce prefs and in Accessablity prefs... but yet it's still turning on. ;( It does pop up a notification, but it's still anoying. I would be VERY happy to have a fix for this. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
On Fri, Apr 27, 2012 at 03:10:45PM +0200, Antonio Trande wrote: The poll about Fedora release names keeping is terminated [1]. And now ? The Board will look at the results and decide whether to stop having release namees for Fedora 19 or to start the process of revising how they are chosen. If the latter, I'm hoping we'll organize that as a working group outside of the Board (a Board member(s) may organize it but it won't be something that occurs at the Board meetings where things are only public half of the time) -Toshio pgpic1YOAd3EX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
- Toshio Kuratomi a.bad...@gmail.com wrote: The Board will look at the results and decide whether to stop having release namees for Fedora 19 or to start the process of revising how they are chosen. If the latter, I'm hoping we'll organize that as a working group outside of the Board (a Board member(s) may organize it but it won't be something that occurs at the Board meetings where things are only public half of the time) Will the poll results be made public? If so when, if not why? -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
On Fri, Apr 27, 2012 at 11:13 AM, Robert 'Bob' Jensen b...@fedoraunity.org wrote: - Toshio Kuratomi a.bad...@gmail.com wrote: The Board will look at the results and decide whether to stop having release namees for Fedora 19 or to start the process of revising how they are chosen. If the latter, I'm hoping we'll organize that as a working group outside of the Board (a Board member(s) may organize it but it won't be something that occurs at the Board meetings where things are only public half of the time) Will the poll results be made public? If so when, if not why? A link to the results was in the first message in this thread. Here it is again, just in case: https://admin.fedoraproject.org/voting/results/poll-rel-names josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BZ718430 - Unknown Horizons
Dear all, Following a previous thread debate about Unknown Horizons: 1) I'm available to maintain unknown-horizons (UH) in Fedora and EPEL (RHEL6); 2) For 1) to happen I would like to maintain also FIFE, which doesn't seem to see much love for quite some time; I ask this because FIFE flagship product is UH itself and the development of both is very close... A FIFE release always preceeds a UH release; 3) If 1) and 2) happen, then I need to maintain also python-enet, which provides the python bindings for ENet. In case ENet needs some love, then I don't mind taking it also. For this to happen, I could use information on the following: 1) How to check who currently maintains those packages; 2) The correct 'modus operandi' to take ownership of those packages; Consider that: 1) I already provide packages for Fedora and RHEL for at least 1 year through OBS. This packages are the ones supported by upstream; Providing them on Fedora means I would remove them from OBS and replace the current information for Fedora users on UH main website; 2) I have been sharing jokes and enjoying UH experience with upstream, so any issues found can properly be addressed to upstream and a rapid response is expected; 3) In extreme situations I can take ownership of all dependencies required (ex: guichan, scons, etc); 4) I don't know the Fedora way, so I would rather stick with FIFE and UH at the start and when I'm more confortable I can take ownership of the rest of the dependencies; Is this OK? Should I re-open BZ718430? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=718430 NM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora release name in the future
- Josh Boyer jwbo...@gmail.com wrote: A link to the results was in the first message in this thread. Here it is again, just in case: https://admin.fedoraproject.org/voting/results/poll-rel-names Thanks Josh, I overlooked it. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mounted external ext4 causes high kworker cpu
Chris Murphy li...@colorremedies.com writes: Normally top reports CPU line, sy at 0.4% when idle. If I format an external Firewire disk as btrfs and mount it, it remains at 0.4%. If I reformat as XFS and mount it, again top reports sy at 0.4%. However, if I reformat as ext4 and mount it, sy runs at 3.5%. These two processes are now at the top of top's results: kworker/1:2 kworker/0:4 Each uses on average 1.9% CPU. The light on the external drive flashes 4x per second. There are no processes using the disk at all while this is going on. If I umount it, the pulsing stops. If I remount it, the pulsing resumes as does the slightly higher CPU consumption. This doesn't happen with the same hardware mounted XFS or btrfs or HFS+. Odd? Sounds like lazy itable init. Try mkfs -t ext4 -E lazy_itable_init=0. Cheers, Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On 04/27/2012 10:50 AM, Colin Walters wrote: Hi Kamil, On Fri, 2012-04-27 at 09:22 -0400, Kamil Paral wrote: but they don't push on any other solutions. A link from the http://fedoraproject.org/get-fedora page directly to http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Quick_Start_Guide/Fedora_Live_Desktop.html ? +1 It would be nice if this links is in the get-fedora page. All the best, Germán. To be honest I'm torn myself because I do sometimes use live images for their try before you buy ability, not necessarily to install to disk right at that second. But having an extension installed by default has a lot of technical ramifications; for example, it'll also get copied to the hard disk after you install. Also, while I'm not an artist or designer, I think it looks pretty ugly... The whole thing is clearly a mess that needs some high level streamlining, from the entire process of download from web page (or receive CD from friend) to the on-disk install first boot. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Thu, 2012-04-26 at 13:34 +0100, Bastien Nocera wrote: On Tue, 2012-04-24 at 22:31 +0100, Matthew Garrett wrote: (Note: *DO NOT* run the installer that is on this image. You'll probably end up with a broken grub. Should be fixed soon) I've put a test image up at http://mjg59.fedorapeople.org/Fedora-Mac-EFI-test.iso - this should work if burned to a CD or dded to a USB stick. Insert, hold down alt, select the Fedora logo. Possible outcomes: I cannot see the Fedora logo at all. I see 2 additional EFI Boot options (I would usually only see rEFIt and Windows, as the firmware calls my Linux booting through MBR), and both of them take me to a grub prompt that asks me for a kernel to be loaded. MacBookAir4,1 (2011 11 one) Did you have a newer version to test? TC1 is the current state of the art: http://dl.fedoraproject.org/pub/alt/stage/17.TC1/ with TC1, we think, the live images written to USB with l-i-t-d (use the very latest livecd-tools you can find) or dd should boot on at least most Mactels. The DVD / netinst image written to USB apparently doesn't work (though the new livecd-tools might change that). There will be a TC2 shortly incorporating a new anaconda and built with a new livecd-tools; TC2 written with the very latest livecd-tools (updates are submitted for 16 and 17) should be the best we can do, and a significant improvement for EFI / Mac booting, lots of bugs have been squished. Additionally, it makes dd of the DVD ISO to USB 'just work' - it will pick up the packages on the USB stick without any manual kernel parameter addition being needed. Which is cool. So, long story short - we'll be very interested in reports of success/failure with TC2 (which should show up tonight or tomorrow) written with dd or the very latest livecd-tools builds for F16/F17: livecd-tools-16.14-1.fc16 and livecd-tools-17.10-1.fc17 . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] ** RE-SCHEDULED ** 2012-05-02 @ 17:00 UTC - F17 Final Blocker Bug Review #2
# F17 Final Blocker Review meeting #2 # Date: 2012-05-02 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net The second F17 final blocker bug review meeting will be re-scheduled to Tuesday 2012-05-02 at 17:00 UTC in #fedora-bugzappers, as most regular attendees are unavailable at the regular time. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at: https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
On Thu, Apr 26, 2012 at 10:08:20PM +0100, Nelson Marques wrote: No dia 26 de Abril de 2012 21:35, Toshio Kuratomi a.bad...@gmail.com escreveu: 1) That there was no reason for you to stop your efforts at packaging the software for Fedora. Toshio, I've dropped that package in particular because and moved to other stuff, I've got a few active reviews going on for EPEL. See it this way, if it was covered, it's more free time to invest in other stuff. nod I don't want to go much further without having input from Simon but in general, this applies to everyone. Simon's already maintaining 19 packages. It makes sense to let someone new take on a package if they've already submitted a review request and use the knowledge from trying to build your own package to review and mentor the new person. It distributes your time better in the long run. -Toshio pgpl6T41RkndV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket 207 - RFE - enable attribute that tracks when a password was last set
https://fedorahosted.org/389/ticket/207 https://fedorahosted.org/389/attachment/ticket/207/0001-Ticket-207-RFE-enable-attribute-that-tracks-when-a-p.patch Thanks, Mark -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Eliminating automatic provides on private libs
On Fri, Apr 27, 2012 at 11:13:47AM +0300, Panu Matilainen wrote: I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Oh and of course eliminating the faked soname provides does not eliminate all unwanted provides, eg libtool adds a soname even when -module is used. But ... you need to start someplace. Will the toggle to turn it on and off work for those libtool generated modules (as long as there's not public libraries in the same package)? Is it possible to turn this on and off per subpackage or is that along the lines of asking for pretty pink ponies with wings? Overall seems like a positive change to me. Let us know the details when it's changed and we'll add those to the Packaging Guidelines. -Toshio pgpnQWRm9AJ5B.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BZ718430 - Unknown Horizons
On Fri, Apr 27, 2012 at 11:47 AM, Nelson Marques nmo.marq...@gmail.comwrote: Dear all, Following a previous thread debate about Unknown Horizons: 1) I'm available to maintain unknown-horizons (UH) in Fedora and EPEL (RHEL6); 2) For 1) to happen I would like to maintain also FIFE, which doesn't seem to see much love for quite some time; I ask this because FIFE flagship product is UH itself and the development of both is very close... A FIFE release always preceeds a UH release; 3) If 1) and 2) happen, then I need to maintain also python-enet, which provides the python bindings for ENet. In case ENet needs some love, then I don't mind taking it also. For this to happen, I could use information on the following: 1) How to check who currently maintains those packages; You can use the fedora pkgdb at https://admin.fedoraproject.org/pkgdb. To get into contact with the owners of the packages you can either file bugs against the packages, or email packagename-owner@fedoraproject dot org. 2) The correct 'modus operandi' to take ownership of those packages; You generally don't take ownership of a package that someone else owns in Fedora, except for when the owner expresses an interest in orphaning the package and passing ownership along or the owner is non-responsive. You can, however, apply to _co-maintain_ the package. In this case, you gain rights to commit to the git branch and can submit updates for a package. Co-maintainership is up to the discretion of the package owner, you can apply to co-maintain in the pkgdb (if you are sponsored into the packaging group,) but you should speak with the package owner first. Consider that: 1) I already provide packages for Fedora and RHEL for at least 1 year through OBS. This packages are the ones supported by upstream; Providing them on Fedora means I would remove them from OBS and replace the current information for Fedora users on UH main website; That's nice, but Fedora has a much different workflow, especially if you're working with other package owners to coordinate dependencies and avoid breakages in the package collection. 2) I have been sharing jokes and enjoying UH experience with upstream, so any issues found can properly be addressed to upstream and a rapid response is expected; Great! A good relationship with the project upstream is a plus for reports and fixes/contributions. 3) In extreme situations I can take ownership of all dependencies required (ex: guichan, scons, etc); This is not necessary. You can work with the current maintainers if there are any incompatibilities. 4) I don't know the Fedora way, so I would rather stick with FIFE and UH at the start and when I'm more confortable I can take ownership of the rest of the dependencies; May I suggest: https://fedoraproject.org/wiki/Package_maintainer_responsibilities https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group https://fedoraproject.org/wiki/PackageMaintainers/Join https://fedoraproject.org/wiki/SIGs/Games Lurking on the -devel and -packaging lists and/or the fedora-devel IRC channel are also good things to do if you have the time. Is this OK? Should I re-open BZ718430? You should be ok re-opening your review request and continuing the review. You should also reach out to the FIFE maintainer as was suggested in the previous thread, especially if you want to co-maintain FIFE (and perhaps he can help you maintain UH as well) Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BZ718430 - Unknown Horizons
On Fri, Apr 27, 2012 at 12:44:01PM -0400, Rich Mattes wrote: On Fri, Apr 27, 2012 at 11:47 AM, Nelson Marques nmo.marq...@gmail.com wrote: 1) How to check who currently maintains those packages; You can use the fedora pkgdb at https://admin.fedoraproject.org/pkgdb. To get into contact with the owners of the packages you can either file bugs against the packages, or email packagename-owner@fedoraproject dot org. https://admin.fedoraproject.org/pkgdb/acls/name/fife https://admin.fedoraproject.org/pkgdb/acls/name/enet PackageDB keeps ownership information per branch (several reasons for this: the owner may be different between EPEL and Fedora; the owner may want to orphan a package in Fedora devel but be willing to continue maintaining on older Fedora releases until they go EOL). The only difference between an owner and a comaintainer (someone who has all of the acls on the package) is that the owner is assigned to be the owner in bugzilla. 2) The correct 'modus operandi' to take ownership of those packages; You generally don't take ownership of a package that someone else owns in Fedora, except for when the owner expresses an interest in orphaning the package and passing ownership along or the owner is non-responsive. You can, however, apply to _co-maintain_ the package. In this case, you gain rights to commit to the git branch and can submit updates for a package. Co-maintainership is up to the discretion of the package owner, you can apply to co-maintain in the pkgdb (if you are sponsored into the packaging group,) but you should speak with the package owner first. Just one thing to add here. Comaintainership responsibility can vary depending on the circumstances. I have a few packages where a comaintainer and I talked and he's pretty much doing all the work. I only work on the package if there's something time critical or I can contribute a patch to the code that the comaintainer can't. Communication is the key to deciding what each person is going to do. An additional plus to comaintainership is that FESCo can sponsor you into the packager group if the package owner is willing to mentor you. That allows more people to do package reviews for you. Is this OK? Should I re-open BZ718430? You should be ok re-opening your review request and continuing the review. You should also reach out to the FIFE maintainer as was suggested in the previous thread, especially if you want to co-maintain FIFE (and perhaps he can help you maintain UH as well) A hearty +1 to this. -Toshio pgpA5uAAYdSzH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-Twitter/f16] Upgrade to 3.18002
Summary of changes: 387342c... Upgrade to 3.18002 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Eliminating automatic provides on private libs
[resent another time because the list automatically rejected my mail]
On 27/04/12 10:13, Panu Matilainen wrote:
[...]
The short background is that for libraries which dont have a SONAME,
rpmbuild fakes one based on the file name. The rationale for this has
been that since the linker permits linking to libraries without sonames,
rpm must permit this too. The downside is that for the 1% corner cases
that need this, we end up polluting the provides namespace with
thousands of unnecessary and unwanted names, names that have not been
picked up with a global namespace in mind.
[...]
So... about a third of the soname provides are faked by using library
basename for its provide name, and almost all of them are for no good
reason. The three general cases that something actually depends on are
1) libreoffice sub-packages depending on its internal libraries from
libreoffice-core
while i'm still quite unfamiliar with RPM or the libreoffice.spec file,
i'm very familiar with LibreOffice upstream; generally with the
exception of the -ure sub-package there are no stable ABIs provided by
the various libraries, so the sub-packages need to depend on the exact
same version of the core package anyway (and no code outside of the
libreoffice source package should have dependencies) which is probably
why the spec file contains this:
Requires: %{name}-core = %{epoch}:%{version}-%{release}
now the URE (UNO runtime environment) subpackage actually provides a
stable ABI and libraries with SONAMEs (in addition to some private
libraries without SONAME for dlopen), all installed in a sub-directory
of /usr/lib/libreoffice, but other than the other libreoffice
sub-packages, which again depend on it with exact version
Requires: %{name}-ure = %{epoch}:%{version}-%{release}
using repoquery i could find only 3 non-libreoffice packages with a
dependency on ure or its libraries in Fedora 16, all of which
LibreOffice extensions (actually 2 of the 3 are the same, once with the
old openoffice.org name), and depending only on the public libraries
with SONAME:
repoquery --requires openoffice.org-voikko-0:3.1.2-5.fc16.x86_64
openoffice.org-diafilter-0:1.7.0-6.fc15.x86_64
libreoffice-voikko-0:3.2-4.fc16.x86_64
[...]
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BZ718430 - Unknown Horizons
No dia 27 de Abril de 2012 18:44, Toshio Kuratomi a.bad...@gmail.com escreveu: On Fri, Apr 27, 2012 at 12:44:01PM -0400, Rich Mattes wrote: On Fri, Apr 27, 2012 at 11:47 AM, Nelson Marques nmo.marq...@gmail.com wrote: 1) How to check who currently maintains those packages; You can use the fedora pkgdb at https://admin.fedoraproject.org/pkgdb. To get into contact with the owners of the packages you can either file bugs against the packages, or email packagename-owner@fedoraproject dot org. https://admin.fedoraproject.org/pkgdb/acls/name/fife https://admin.fedoraproject.org/pkgdb/acls/name/enet PackageDB keeps ownership information per branch (several reasons for this: the owner may be different between EPEL and Fedora; the owner may want to orphan a package in Fedora devel but be willing to continue maintaining on older Fedora releases until they go EOL). The only difference between an owner and a comaintainer (someone who has all of the acls on the package) is that the owner is assigned to be the owner in bugzilla. 2) The correct 'modus operandi' to take ownership of those packages; You generally don't take ownership of a package that someone else owns in Fedora, except for when the owner expresses an interest in orphaning the package and passing ownership along or the owner is non-responsive. You can, however, apply to _co-maintain_ the package. In this case, you gain rights to commit to the git branch and can submit updates for a package. Co-maintainership is up to the discretion of the package owner, you can apply to co-maintain in the pkgdb (if you are sponsored into the packaging group,) but you should speak with the package owner first. Just one thing to add here. Comaintainership responsibility can vary depending on the circumstances. I have a few packages where a comaintainer and I talked and he's pretty much doing all the work. I only work on the package if there's something time critical or I can contribute a patch to the code that the comaintainer can't. Communication is the key to deciding what each person is going to do. An additional plus to comaintainership is that FESCo can sponsor you into the packager group if the package owner is willing to mentor you. That allows more people to do package reviews for you. Is this OK? Should I re-open BZ718430? You should be ok re-opening your review request and continuing the review. You should also reach out to the FIFE maintainer as was suggested in the previous thread, especially if you want to co-maintain FIFE (and perhaps he can help you maintain UH as well) A hearty +1 to this. https://bugzilla.redhat.com/show_bug.cgi?id=757352 Once this has been fixed :) -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Nelson Marques // I've stopped trying to understand sandwiches with a third piece of bread in the middle... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
On Thu, Apr 26, 2012 at 22:08:20 +0100, Nelson Marques nmo.marq...@gmail.com wrote: FIFE wasn't maintained for quite some time when that request was filed. Not pointing fingers, but from the packages I've maintained on other waters I've always kept my stuff updated and in the shape possible. You could also volunteer to co-maintain FIFE. While I'd like to be able to work on that update, I have other games related packaging work that is more important to get done right now. If you have time, you could probably get it done pretty soon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for revitalizing the sponsorship process for packaging
On Thu, Apr 26, 2012 at 11:49:58 -0700, Toshio Kuratomi a.bad...@gmail.com wrote: So the big question is -- where did this break down? How can we update our documentation to guide people in this direction? One thing people can do for things obviously covered by a SIG (games in this case) is to let the SIG know you are planning to package something of interest. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Kernel Meeting 04-27-2012 Minutes
== #fedora-meeting: Fedora Kernel meeting == Meeting started by jwb at 17:59:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-04-27/fedora-kernel.2012-04-27-17.59.log.html . Meeting summary --- * init (jwb, 18:00:06) * rawhide (jwb, 18:02:51) * Rawhide is at 3.4-rc4-git3. RCs are coming fairly regularly (jwb, 18:08:17) * F17 (jwb, 18:09:37) * F17 at 3.3.2. 3.3.4 being built for TC2 (jwb, 18:12:29) * F16 (jwb, 18:13:56) * F16 is on 3.3.2. 3.3.4 will be built and submitted to updates-testing (jwb, 18:15:01) * LINK: http://codemonkey.org.uk/2012/04/27/weekly-fedora-kernel-bug-statistics-april-27-2012/ weekly bug statistics (jwb, 18:19:33) * Progress on F16 bug count is being made. This also helps F15/F17 by either closing out duplicates or preventing those bugs from being hit there as all 3 releases are on the same kernel version (jwb, 18:20:17) * F15 (jwb, 18:47:05) * F15 is at 2.6.43.2 (3.3.2) (jwb, 18:48:25) * open floor (jwb, 18:49:29) * open floor - darkserver (jwb, 18:50:06) * ACTION: jwb to open bug against darkserver for additional build time issue (jwb, 18:52:35) * open floor (jwb, 18:53:39) Meeting ended at 19:00:33 UTC. Action Items * jwb to open bug against darkserver for additional build time issue Action Items, by person --- * jwb * jwb to open bug against darkserver for additional build time issue * **UNASSIGNED** * (none) People Present (lines said) --- * jwb (117) * VICODAN_ (63) * jforbes (31) * davej (21) * nirik (14) * dgilmore (8) * linville (6) * zodbot (3) * misc (2) * brunowolff (2) * jsmith (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Kamil Paral (kpa...@redhat.com) said: I find it sad how desktop guys try to veto solutions they don't like, but they don't push on any other solutions. I don't know how proposing and implementing a notification method of doing the same isn't providing a solution, but you're welcome to your own cross. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16-F17 preupgrade (Re: F17 Beta to slip by an additional week.)
On Thu, Apr 26, 2012 at 20:05:50 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Are there any serious known problems with apache, python, php, mysql, postgresql? I am using F17 on a machine that use postgres and perl scripts (not mod_perl though) to generate web pages using apache. Things seem to be working fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16-F17 preupgrade (Re: F17 Beta to slip by an additional week.)
On Thu, 2012-04-26 at 19:50 +0200, Michał Piotrowski wrote: Has anyone tried to preupgrade from F16 to F17? Are there any problems related to UsrMove (or anything else)? I made the jump via preupgrade and had quite a bit of trouble. A number of packages didn't get upgraded while some of their dependencies did, including several that had strict version deps which should have prevented this. I ended up with a system that was effectively unusable until I followed it with a 'yum distro-sync'. For those wondering where are the BZs, there was too much wrong in my system for me to be able to get a graphical environment to log into Bugzilla until after the distro-sync, at which point I no longer had access to the data I would need to file meaningful bug reports. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Fri, Apr 27, 2012 at 3:02 PM, Bill Nottingham nott...@redhat.com wrote: I don't know how proposing and implementing a notification method of doing the same isn't providing a solution, but you're welcome to your own cross. Sorry Bill -- I'm confused here. Was a notification method actually implemented? Was it enabled in F17.TC1? If so, I didn't see it. Or was it implemented only for rawhide? -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 17 Final Test Compose 2 (TC2) Available Now!
As per the Fedora 17 schedule [1], Fedora 17 Final Test Compose 2 (TC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5163 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha, Beta, and Final priority test cases for Installation [2], Base [3], Desktop [4], and Security Lab [5] should pass in order to meet the Final Release Criteria [6]. Help is available on #fedora-qa on irc.freenode.net [7], or on the test list [8]. Create Fedora 17 Final test compose (TC) - live and traditional https://fedorahosted.org/rel-eng/ticket/5163 Fedora 17 Final Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752650 Fedora 17 Final Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752653 [1] http://rbergero.fedorapeople.org/schedules/f-17/f-17-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing [6] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria [7] irc://irc.freenode.net/fedora-qa [8] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Devel-GlobalDestruction-0.05.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Devel-GlobalDestruction: e99ef189e9f85549e42c32b5168f7f47 Devel-GlobalDestruction-0.05.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction] Update to 0.05
commit 99282210101eab75400937c9514dbc79efd45249
Author: Paul Howarth p...@city-fan.org
Date: Fri Apr 27 11:38:02 2012 +0100
Update to 0.05
- New upstream release 0.05
- Add pure-perl implementation for situations where neither
${^GLOBAL_PHASE}
nor XS are available
- This release by DOY - update source URL
- BR: perl(XSLoader) only if we're doing an XS build, and in that case add a
runtime dependency on it and BR: perl(ExtUtils::CBuilder) ≥ 0.27 too
- Add runtime dependency on perl(Carp)
- Drop %defattr, redundant since rpm 4.4
perl-Devel-GlobalDestruction.spec | 24 ++--
sources |2 +-
2 files changed, 19 insertions(+), 7 deletions(-)
---
diff --git a/perl-Devel-GlobalDestruction.spec
b/perl-Devel-GlobalDestruction.spec
index 73f72cb..182932f 100644
--- a/perl-Devel-GlobalDestruction.spec
+++ b/perl-Devel-GlobalDestruction.spec
@@ -2,21 +2,25 @@
%global noarch_package %(perl -e 'print (($] = 5.013007) ? 1 : 0);')
Name: perl-Devel-GlobalDestruction
-Version: 0.04
+Version: 0.05
Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Summary: Expose PL_dirty, the flag that marks global destruction
Url: http://search.cpan.org/dist/Devel-GlobalDestruction
-Source:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Devel-GlobalDestruction-%{version}.tar.gz
+Source:
http://search.cpan.org/CPAN/authors/id/D/DO/DOY/Devel-GlobalDestruction-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
%if %{noarch_package}
BuildArch: noarch
+%else
+BuildRequires: perl(ExtUtils::CBuilder) = 0.27
+BuildRequires: perl(XSLoader)
+Requires: perl(XSLoader)
%endif
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Sub::Exporter)
-BuildRequires: perl(XSLoader)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Carp)
# Don't provide private Perl libs
%{?perl_default_filter}
@@ -44,7 +48,6 @@ rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -54,7 +57,6 @@ make test
rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes t/
%if %{noarch_package}
%{perl_vendorlib}/Devel/
@@ -65,6 +67,16 @@ rm -rf %{buildroot}
%{_mandir}/man3/Devel::GlobalDestruction.3pm*
%changelog
+* Fri Apr 27 2012 Paul Howarth p...@city-fan.org - 0.05-1
+- Update to 0.05
+ - Add pure-perl implementation for situations where neither ${^GLOBAL_PHASE}
+nor XS are available
+- This release by DOY - update source URL
+- BR: perl(XSLoader) only if we're doing an XS build, and in that case add a
+ runtime dependency on it and BR: perl(ExtUtils::CBuilder) ≥ 0.27 too
+- Add runtime dependency on perl(Carp)
+- Drop %%defattr, redundant since rpm 4.4
+
* Fri Jan 13 2012 Paul Howarth p...@city-fan.org - 0.04-1
- Update to 0.04
- To detect a perl with ${^GLOBAL_PHASE}, check for the feature itself
diff --git a/sources b/sources
index 23f804b..c3f435c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-823ee705f0c1c59cbf73cbab5bdf08f7 Devel-GlobalDestruction-0.04.tar.gz
+e99ef189e9f85549e42c32b5168f7f47 Devel-GlobalDestruction-0.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction/f17] Update to 0.05
Summary of changes: 9928221... Update to 0.05 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction] Created tag perl-Devel-GlobalDestruction-0.05-1.fc17
The lightweight tag 'perl-Devel-GlobalDestruction-0.05-1.fc17' was created pointing to: 9928221... Update to 0.05 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction] Created tag perl-Devel-GlobalDestruction-0.05-1.fc18
The lightweight tag 'perl-Devel-GlobalDestruction-0.05-1.fc18' was created pointing to: 9928221... Update to 0.05 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Debug-Client-0.20.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Debug-Client: d5250a44e0753bc975e9afba7a63e8b6 Debug-Client-0.20.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Moose-More-0.009.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Moose-More: 1545212890dd575341e03b6317f41c6e Test-Moose-More-0.009.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Moose-More] 0.009 bump
commit 7ff1451642f52720101191265750d6599cc652ba
Author: Petr Písař ppi...@redhat.com
Date: Fri Apr 27 13:09:37 2012 +0200
0.009 bump
.gitignore|1 +
perl-Test-Moose-More.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aceddd1..46817bd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/Test-Moose-More-0.006.tar.gz
/Test-Moose-More-0.007.tar.gz
/Test-Moose-More-0.008.tar.gz
+/Test-Moose-More-0.009.tar.gz
diff --git a/perl-Test-Moose-More.spec b/perl-Test-Moose-More.spec
index 883f57c..6f8ff25 100644
--- a/perl-Test-Moose-More.spec
+++ b/perl-Test-Moose-More.spec
@@ -1,5 +1,5 @@
Name: perl-Test-Moose-More
-Version:0.008
+Version:0.009
Release:1%{?dist}
Summary:More tools for testing Moose packages
License:LGPLv2+
@@ -9,6 +9,7 @@ Source0:
http://www.cpan.org/authors/id/R/RS/RSRCHBOY/Test-Moose-More-%{v
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
# Runt-time:
+BuildRequires: perl(Data::OptList)
BuildRequires: perl(Moose::Util)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Sub::Exporter)
@@ -23,7 +24,6 @@ BuildRequires: perl(Moose::Role)
BuildRequires: perl(MooseX::AttributeShortcuts)
BuildRequires: perl(Test::Builder::Tester)
# Optional tests:
-# Test::Requires is needed only for author tests which we do not run
BuildRequires: perl(Test::Script) = 1.05
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Test::More) = 0.88
@@ -58,6 +58,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Apr 27 2012 Petr Pisar ppi...@redhat.com - 0.009-1
+- 0.009 bump
+
* Mon Apr 16 2012 Petr Pisar ppi...@redhat.com - 0.008-1
- 0.008 bump
diff --git a/sources b/sources
index 80d467f..b5189de 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-db5052fcdaa2238220dcd148b66ef68f Test-Moose-More-0.008.tar.gz
+1545212890dd575341e03b6317f41c6e Test-Moose-More-0.009.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Debug-Client] 0.20 bump - apply changed patch for tests
commit 7b0f0f525a6628fd1b19be9dfc1636153715e8b5
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Apr 27 13:19:24 2012 +0200
0.20 bump
- apply changed patch for tests
.gitignore |1 +
...Client-0.18-Do-not-use-Term-ReadLine-Perl.patch | 32
...Client-0.20-Do-not-use-Term-ReadLine-Perl.patch | 18 +++
perl-Debug-Client.spec |7 +++-
sources|2 +-
5 files changed, 25 insertions(+), 35 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fa25dab..cb87778 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Debug-Client-0.11.tar.gz
/Debug-Client-0.16.tar.gz
/Debug-Client-0.18.tar.gz
+/Debug-Client-0.20.tar.gz
diff --git a/Debug-Client-0.20-Do-not-use-Term-ReadLine-Perl.patch
b/Debug-Client-0.20-Do-not-use-Term-ReadLine-Perl.patch
new file mode 100644
index 000..a584560
--- /dev/null
+++ b/Debug-Client-0.20-Do-not-use-Term-ReadLine-Perl.patch
@@ -0,0 +1,18 @@
+diff -up Debug-Client-0.20/t/01-Debug-Client.t.old
Debug-Client-0.20/t/01-Debug-Client.t
+--- Debug-Client-0.20/t/01-Debug-Client.t.old 2012-04-09 11:00:53.0
+0200
Debug-Client-0.20/t/01-Debug-Client.t 2012-04-27 13:17:18.710857838
+0200
+@@ -1,13 +1,12 @@
+ use 5.008006;
+ use Test::More;
+-plan( tests = 42 );
++plan( tests = 41 );
+
+ use_ok( 'Carp', '1.20' );
+ use_ok( 'IO::Socket', '1.31' );
+ use_ok( 'IO::Socket::INET', '1.31' );
+ use_ok( 'PadWalker','1.92' );
+ use_ok( 'Term::ReadLine', '1.07' );
+-use_ok( 'Term::ReadLine::Perl', '1.0303' );
+
+ use_ok( 'Test::More','0.98' );
+ use_ok( 'Test::Deep','0.108' );
diff --git a/perl-Debug-Client.spec b/perl-Debug-Client.spec
index 2b5d9f0..306922b 100644
--- a/perl-Debug-Client.spec
+++ b/perl-Debug-Client.spec
@@ -1,5 +1,5 @@
Name: perl-Debug-Client
-Version:0.18
+Version:0.20
Release:1%{?dist}
Summary:Client side code for perl debugger
License:GPL+ or Artistic
@@ -7,7 +7,7 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Debug-Client/
Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOWTIE/Debug-Client-%{version}.tar.gz
# Tests fail with Term::ReadLine::Perl
-Patch0: Debug-Client-0.18-Do-not-use-Term-ReadLine-Perl.patch
+Patch0: Debug-Client-0.20-Do-not-use-Term-ReadLine-Perl.patch
BuildArch: noarch
BuildRequires: perl(inc::Module::Install::DSL) = 1.04
# Run-time
@@ -56,6 +56,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Apr 10 2012 Marcela Mašláňová mmasl...@redhat.com - 0.20-1
+- 0.20 bump
+
* Thu Mar 15 2012 Petr Pisar ppi...@redhat.com - 0.18-1
- 0.18 bump
- Correct dependencies
diff --git a/sources b/sources
index c3a60a7..17a94b0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a4391fb6e3a837fc6441d819e67a7ac5 Debug-Client-0.18.tar.gz
+d5250a44e0753bc975e9afba7a63e8b6 Debug-Client-0.20.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-CPAN-Meta-0.21.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-CPAN-Meta: 949b5867708c1fe5a3ac51cdcb25eaea Test-CPAN-Meta-0.21.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-File-DesktopEntry] apply patch from MozBug for fixing encoding of utf-8 files 816809, cpan#76843
commit 56d74b890c2b142305445081693d7245ba01d216
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Apr 27 13:32:44 2012 +0200
apply patch from MozBug for fixing encoding of utf-8 files 816809,
cpan#76843
File-DesktopEntry-encode.patch | 19 +++
perl-File-DesktopEntry.spec|8 +++-
2 files changed, 26 insertions(+), 1 deletions(-)
---
diff --git a/File-DesktopEntry-encode.patch b/File-DesktopEntry-encode.patch
new file mode 100644
index 000..8cf08c6
--- /dev/null
+++ b/File-DesktopEntry-encode.patch
@@ -0,0 +1,19 @@
+diff -up File-DesktopEntry-0.04/lib/File/DesktopEntry.pm.old
File-DesktopEntry-0.04/lib/File/DesktopEntry.pm
+--- File-DesktopEntry-0.04/lib/File/DesktopEntry.pm.old2007-11-04
21:34:20.0 +0100
File-DesktopEntry-0.04/lib/File/DesktopEntry.pm2012-04-27
13:28:58.403493320 +0200
+@@ -3,6 +3,7 @@ package File::DesktopEntry;
+ use strict;
+ use vars qw/$AUTOLOAD/;
+ use Carp;
++use Encode;
+ use File::Spec;
+ use File::BaseDir 0.03 qw/data_files data_home/;
+
+@@ -333,6 +334,7 @@ sub parse_Exec {
+ push @exec, '--icon', $icon if defined($icon);
+ }
+ else { # expand with word ( e.g. --input=%f )
++ $_ = encode_utf8($_);
+ my $bad;
+ s/\%(.)/
+ ($1 eq '%') ? '%':
diff --git a/perl-File-DesktopEntry.spec b/perl-File-DesktopEntry.spec
index 2b022aa..96e3909 100644
--- a/perl-File-DesktopEntry.spec
+++ b/perl-File-DesktopEntry.spec
@@ -1,12 +1,14 @@
Name: perl-File-DesktopEntry
Version:0.04
-Release:15%{?dist}
+Release:16%{?dist}
Summary:Object to handle .desktop files
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/File-DesktopEntry/
Source0:
http://www.cpan.org/authors/id/P/PA/PARDUS/File-DesktopEntry/File-DesktopEntry-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+#http://rt.cpan.org/Public/Bug/Display.html?id=76843
+Patch0: File-DesktopEntry-encode.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) perl(Module::Build)
BuildRequires: perl(Test::More) perl(Test::Pod) perl(Test::Pod::Coverage)
@@ -21,6 +23,7 @@ module version 0.9.4 of the specification was used.
%prep
%setup -q -n File-DesktopEntry-%{version}
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -49,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Apr 27 2012 Marcela Mašláňová mmasl...@redhat.com - 0.04-15
+- apply patch from MozBug for fixing encoding of utf-8 files 816809, cpan#76843
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.04-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Role-Tiny-1.001001.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Role-Tiny: a496d29d811ad19640f504aeca3d348c Role-Tiny-1.001001.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Twitter/f17] Upgrade to 3.18002
Summary of changes: 387342c... Upgrade to 3.18002 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Twitter/f15] Upgrade to 3.18002
Summary of changes: 387342c... Upgrade to 3.18002 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Role-Tiny] update to 1.001001
commit 1019d3ed2d094b29b7479250cdde97bbcc36febe
Author: Iain Arnell iarn...@gmail.com
Date: Fri Apr 27 18:32:23 2012 -0600
update to 1.001001
.gitignore |1 +
perl-Role-Tiny.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aa1e1d2..e3ff09b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Role-Tiny-1.00.tar.gz
/Role-Tiny-1.01.tar.gz
+/Role-Tiny-1.001001.tar.gz
diff --git a/perl-Role-Tiny.spec b/perl-Role-Tiny.spec
index 8595150..ffc8cdb 100644
--- a/perl-Role-Tiny.spec
+++ b/perl-Role-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-Role-Tiny
-Version:1.01
+Version:1.001001
Release:1%{?dist}
Summary:A nouvelle cuisine portion size slice of Moose
License:GPL+ or Artistic
@@ -9,11 +9,11 @@ Source0:
http://www.cpan.org/authors/id/M/MS/MSTROUT/Role-Tiny-%{version}
BuildArch: noarch
BuildRequires: perl(constant)
BuildRequires: perl(Class::Method::Modifiers)
+BuildRequires: perl(Data::Dumper)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Fatal) = 0.003
BuildRequires: perl(Test::More) = 0.96
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Class::Method::Modifiers)
# perl-Role-Tiny was split from perl-Moo
Conflicts: perl-Moo 0.009014
@@ -34,7 +34,6 @@ make %{?_smp_mflags}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
@@ -47,6 +46,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Apr 27 2012 Iain Arnell iarn...@gmail.com 1.001001-1
+- update to latest upstream version
+- don't explicity require Class::Method::Modifiers
+
* Wed Apr 04 2012 Iain Arnell iarn...@gmail.com 1.01-1
- update to latest upstream version
@@ -55,7 +58,7 @@ make test
distributed as part of Moo
* Mon Apr 02 2012 Iain Arnell iarn...@gmail.com 1.00-2
-- fix spelling of cuisinse in summary
+- fix spelling of cuisine in summary
* Sun Apr 01 2012 Iain Arnell iarn...@gmail.com 1.00-1
- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index 6b9a6ed..8f8e307 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f563b6f0c9fea55349aa0ff23240268c Role-Tiny-1.01.tar.gz
+a496d29d811ad19640f504aeca3d348c Role-Tiny-1.001001.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora Elections: General information, and questionnaire opening.
GREETINGS! It is once again time for election season to begin. As noted in the elections schedule[1], the elections questionnaire is now open to populate with questions for candidates, and will close on May 8th. The elections nomination period will begin AFTER the questionnaire period has closed. You may add your burning questions for candidates to answer here: http://fedoraproject.org/wiki/F18_elections_questionnaire The following seats are available in this election: * Fedora Project Board: 3 seats * FESCo (Fedora Engineering Steering Committee): 5 seats * FAmSCo (Fedora Ambassadors Steering Committee): 7 seats Please take note of the following changes for this election: * All questions for the questionnaire must be submitted by May 8th, prior to the beginning of nominations. As seen in the schedule above, the nomination period does not start until May 9th. * As noted on announce-list[2], FAmSCo is electing all 7 seats this cycle, with the goal of having staggered elections similar to the Board and FESCo. Additionally, voting eligibility has been widened to allow anyone who has signed the FPCA AND is a member of at least one additional non-FPCA/CLA group. (In other words: No longer just ambassadors, but those part of other teams as well.) Full election information may be seen here: http://fedoraproject.org/wiki/Elections Participating in these bodies are one of many ways to contribute to Fedora; I encourage you to consider running, or to urge those you believe are excellent candidates to run. Additionally, your contributions are welcomed in helping to keep the elections running smoothly; volunteers are needed to help collect questionnaire answers from candidates, as well as for scheduling and moderating town halls. If you are interested in helping with those efforts, please contact John Rose[3]. And a big thank you! to John for coordinating the elections thus far, your efforts are very much appreciated. -Robyn [1]http://fedoraproject.org/wiki/Elections#Committee_Elections_Schedule [2]http://lists.fedoraproject.org/pipermail/announce/2012-April/003063.html [3]http://fedoraproject.org/wiki/User:Inode0 ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
