Re: *countable infinities only
On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote: El Sat, 2 Jun 2012 12:18:17 -0400 Orcan Ogetbil oget.fed...@gmail.com escribió: On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote: The only Freedom you've lost is that now, in addition to the person-hours to do the work and monetary cost to host your bits or generate physical media, you have an additional cost if you wish to have your own cert that will be accepted out of the box by the next generation of PC hardware. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. That's a better deal than Fedora's gpg signing setup. Hmm, will the package maintainers have the freedom to not support users who have the secureboot enabled? How are we going to detect this? i look at it this way. if you patch your software to only run on machines with secureboot disabled your software then becomes non free and has to be removed from fedora. this is becasuse you are placing usage restrictions on it. depending on the license of the software adding such a restriction would violate the license. I am not a lawyer at all and never pretend to play one, but i do not think you as a package maintainer can do that. an upstream could, but i imagine it would be viewed in the same light as a commercial use restriction and become non-free. That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: Retiring vbetool in F18
On 2012-06-04, Adam Jackson a...@redhat.com wrote: Historically the only thing requiring vbetool was pm-utils, but that's not been true in a nice long time: * Fri Oct 08 2010 Adam Jackson a...@redhat.com 1.3.1-2 - Drop the vbetool dependency, suspend is only supported on KMS drivers. That was F14 gold: % koji -q latest-pkg dist-f14 pm-utils pm-utils-1.3.1-2.fc14 dist-f14 ajax In lieu of flowers, please send patches for KMS drivers to dri-de...@lists.freedesktop.org. How can I reset the graphics card using KMS (vbetool post)? -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Guacamole Java Web Application
Hello, sorry for double posting to devel and java-devel but the last seems not so crowded. On 24 May 2012 12:04, Simone Caronni negativ...@gmail.com wrote: following the mail in fedora-devel, I'm posting here some progress in packaging the Guacamole stack for Fedora. I hope to get some advice from Fedora Java gurus... guacamole-common and guacamole-common-ext are now into rawhide and I've been struggling a couple of days for the next parts. I need some help with the guacamole-common-js [1][2]; the last step before packaging the web application itself [3]. The build itself is normally generated with the command maven package; so replacing it with mvn-rpmbuild package generates the following file. How's the supposed guideline for packaging it? Where should I put the zip file and how should the spec file be structured? All the other java classes for Guacamole are into jars in /usr/share/java/guacamole/. I can't find any useful information for it in the Java packaging pages [4]. I tried to look at at least 20 java packages in fedora and could not find one that was not packaging a jar file. $ unzip -l ./target/guacamole-common-js- 0.6.0-guacamole-common-js.zip Archive: ./target/guacamole-common-js-0.6.0-guacamole-common-js.zip Length DateTimeName - -- - 0 05-05-2012 04:32 guacamole-common-js/ 17214 05-05-2012 04:32 guacamole-common-js/mouse.js 31710 05-05-2012 04:32 guacamole-common-js/guacamole.js 17640 05-05-2012 04:32 guacamole-common-js/oskeyboard.js 12621 05-05-2012 04:32 guacamole-common-js/keyboard.js 24977 05-05-2012 04:32 guacamole-common-js/tunnel.js 37152 05-05-2012 04:32 guacamole-common-js/layer.js - --- 141314 7 files [1] http://guac-dev.org/guacamole-common-js [2] http://slaanesh.fedorapeople.org/guacamole-common-js-0.6.0-1.fc17.src.rpm [3] http://guac-dev.org/guacamole [4] https://fedoraproject.org/wiki/Packaging:Java Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: supercat anybody working on it?
On Sat, 02 Jun 2012 20:16:49 -0700, Garrett Holmstrom wrote: On 6/2/2012 7:03 PM, Adrian Alves wrote: am not following what u mean? Please don't top-post, Adrian. Top-posting makes it much more difficult to understand what you refer to, especially since you've asked a question. On Sat, Jun 2, 2012 at 5:30 AM, Michael Schwendt wrote: On Fri, 1 Jun 2012 23:00:29 -0300, Adrian Alves wrote: done I built it, check this out: Spec URL: http://alvesadrian.fedorapeople.org/supercat.spec Check this out: This means to read the following link because it describes a mistake that your spec file makes: Exactly. After reading the following page, you should be able to find the unowned directory in your package. At least try to find it. And if you don't find it or if you think there is no unowned directory in your spec file, mention that and it could be discussed further. https://fedoraproject.org/wiki/Packaging:UnownedDirectories And the following page is _not_ just for reviewers: ;-) This means to read the following link because it is wise to follow the packaging guidelines even before formally submitting a package for review: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines A sponsored packager should be capable of reviewing others' packages, for example to offer trading reviews. With the help of the ReviewGuidelines page -- and particularly, the first MUST item on that list -- you should find more mistakes in your supercat.spec file. It is good habit to not just wait for a reviewer to do all the work, but perform a self-review and declare whether a spec file is supposed to meet the guidelines or whether there is something questionable you would like to discuss with a reviewer. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64 loadavg: 0.09 0.28 0.29 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Andreas wrote: Hi, first I would like to point out that I am totally open for a discussion about this. IMO bugzilla is just not the right place for it. Thanks, that's great. Chris wrote: Well, no they don't. They are requesting the font Microsoft calls Tahoma, not a Wine-provided imitation of Tahoma. I didn't know that wine-provided Tahoma is not exactly the same as Microsoft Tahoma. I just knew it looked horrible. That is an important information, thank you. From now on I'll write wine-Tahoma when talking about wine-provided Tahoma to make it clear. Chris wrote: Providing a font called Tahoma that isn't Tahoma is a bad idea. In general, the fonts that are designed to copy other fonts get a different name. In many cases, this is required because some font names are trademarked (IIRC Helvetica is an example). Wine should not call their font Tahoma. They should call it something else and then map requests for Tahoma to their imitation font. Is someone knowledgeable enough to put all the details and information together and open a ticket in wine bug-tracker? I can do it, but since I know nothing about fonts, my bug description might not explain the issue properly. Felix wrote: It happens because: 1-Microsoft's TTF fonts are not in the browser's font path 2-a poor imitation of Tahoma named Tahoma is in the browser's font path 3-Clueless web authors include Tahoma as a fallback to Verdana, which is not part of a standard Wine install, while the Tahoma impostor is This is a nice summary. Now, are we able to circumvent other people's mistakes and obstacles? I have to stress out one very important thing in case someone missed it: It is extremely easy to make a font available only to wine itself, it has a special directory for that. No other applications would see it. Andreas wrote: As a packager I, however, find it important that for the use-case of wine the best available user experience is provided. Hence this font needs to be included an pulled in by wine like it is today. Let's assume we have moved wine-Tahoma to wine-specific font directory: 1. Wine users experience stays the same - all wine applications are still rendered correctly 2. General users experience improves - web browser doesn't display a lot of favorite web pages (like Facebook) with an ugly-looking font Now, what is wrong about that? Andreas, if there are packaging guidelines that would be broken, I'm sure we can receive an exception. I can find out the correct approach and I will gladly help you discuss that with relevant people. If you are afraid there might be people out there who want wine-Tahoma as a system font, it is important to realize that those people are probably just a tiny fraction of the other side of the argument (users who prefer good-looking websites) and we can easily adjust the README to explain how to make the font user-wide or system-wide if required (together with a note that this is *not* Microsoft Tahoma and final appearance will differ). Or is there any other reason why you feel reluctant to make wine-Tahoma available only to wine by default? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Tue, 2012-05-29 at 21:49 +0200, Lennart Poettering wrote: On Thu, 24.05.12 09:28, Alexander Larsson (al...@redhat.com) wrote: I'm at a loss to how to proceed with the MiniDebugInfo work. I have patches to rpmbuild that creates the compressed minidebuginfo putting them in the main binaries, and I have patches to gdb that reads the compressed debuginfo on demand. However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? The right way is probably to write a feature page for F18 for it, and then get it through Fedora 18 feature process. With FESCO accepting the feature you should have all you need to get your work accepted by the various stakeholders. I did write a feature page for it. Thats how these threads started. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
octave-struct and octave-optim: license change from GPLv2+ to GPLv3+
I'd like to push octave-struct v1.0.10 and octave-optim v1.1.0 to rawhide; octave-struct and octave-optim change, like the rest of the octave forge repository, the license from GPLv2+ to GPLv3+. The only package that depends on octave-struct in the repository that I am aware of is octave-optim, and octave-optim is only required by octave-signal, which is already GPLv3+. Are there any objections? Thanks, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Le Mar 5 juin 2012 10:59, Kamil Paral a écrit : If you are afraid there might be people out there who want wine-Tahoma as a system font, it is important to realize that those people are probably just a tiny fraction of the other side of the argument That's a dangerous argument, looks are subjective and every time someone touches a font it deems ugly others disagree. It'd be much better if 1. the wine font didn't declare a name too heavy for it 2. the font package was made technically optionnal so people who love the font (I'm sure there are some like all the other times) can still use it -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 21:11, Pete Walter написал: Pavel Alexeevforumat hubbitus.com.ru writes: May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? No, I did not test this. And here's a few reasons why I think this shouldn't be pushed: - You are forcing others to do work they otherwise wouldn't need to do. Why do you want me to test ImageMagick functionality in 57 dependant packages? Fix your security bugs and leave other packages alone. F16 is supposed to be stable. - A major ImageMagick update that introduces new features and new code invalidates the QA that has gone into the packages that use ImageMagick. - Needless update churn. We have the Stable Updates Policy for a reason. Do you development on rawhide and let stable Fedora release be stable. - The soname bump breaks third party packages that use ImageMagick libraries. An example is 'transcode' from rpmfusion. http://fedoraproject.org/wiki/Updates_Policy explicitly says that such ABI bumps are left to the discretion of FESCO and the packager. Have you already asked FESCO for their blessing? Note that you should open this dialog _BEFORE_ you build or push updates. Pete Ok. I understand you point. I do not share your point of view, but the respect among others to speak out. But as I mention and thankfully also Johannes Lips (thanks for some positive words) such argue was much more appreciated before all work had been done. For that I announce my intentions for the week ago. I'll plan unpush that update and work on patching ImageMagick to handle these issues locally. But I'm not security expert and can't guarantee something except mentioned patch apply (contrary leave it on upstream authors, as I was want do first). Only one other think before I do that. Is it will be needed then introduce epoch in Fedora 16 IM build to push less version in stable branch? Is it normal introduce epoch tag only in that branch, and not on all others? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 22:26, Michael Schwendt написал: On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote: Additionally have worth I try read carefully all docs about provenpackager and such updates and have not found how deal with such versions. It's not provenpackager specific stuff, but found in the basic packaging guidelines: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag I had look in my packages and few others and found it was updated many times in that way. Just read the page linked above. There is no strict requirement to apply this release versioning scheme for old branches. If newer branches would always win RPM Version Comparison because their %version field is _higher_, you can bump %release in older branches without risk. In packages were was present subrelease after %{?dist} - I increase it. Should or must in next time I add it in any package even it does not have it?? As the guidelines say: Be careful with this! Thank you very much Michael. It's helpful. But what still is not clear to me - if it secure, may it be applied to all packages on update in stable releases? Or instead I should check if increasing release do not break version sequence in branches - do that. And only if it false, introduce subrelease like %{?dist}.1? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Tue, 05 Jun 2012 13:55:21 +0400, Pavel Alexeev wrote: Only one other think before I do that. Is it will be needed then introduce epoch in Fedora 16 IM build to push less version in stable branch? Could you explain _why_ you think you need to increase the Epoch? Last package in F-16 updates: ImageMagick-6.7.0.10-4.fc16 Is it normal introduce epoch tag only in that branch, and not on all others? No. That sounds as if you've misunderstood something completely. :-( -- Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64 loadavg: 0.80 0.65 0.53 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On Mon, 04 Jun 2012 20:01:15 -0400 Gerry Reno gr...@verizon.net wrote: On 06/04/2012 07:44 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 19:37:07 -0400 Gerry Reno gr...@verizon.net wrote: Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( The install guide might be of help... http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Installation_Guide/index.html#encrypt-x86 And this is really the sort of question best suited to the users list: http://lists.fedoraproject.org/mailman/listinfo/users not the devel list. ;) kevin Hey Kevin, I've been custom partitioning Fedora installs since the beginning of anaconda. Look back several years and you'll find still unaddressed installation bugs for anaconda/preupgrade. For example /boot on RAID. Hmm, I did a fresh F17 install two days ago with /boot on (MD) RAID1 and it worked just fine, with none of the grub issues F16 had with that. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 05/06/12 11:15, Paul Howarth wrote: On Mon, 04 Jun 2012 20:01:15 -0400 Gerry Renogr...@verizon.net wrote: Look back several years and you'll find still unaddressed installation bugs for anaconda/preupgrade. For example /boot on RAID. Hmm, I did a fresh F17 install two days ago with /boot on (MD) RAID1 and it worked just fine, with none of the grub issues F16 had with that. Yes you can install (or upgrade with anaconda I think) but what you can't do is upgrade using preupgrade if you have a mirrored system disk. Which is just one of the reasons I do all my upgrades with yum... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote: 04.06.2012 22:26, Michael Schwendt написал: On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote: Additionally have worth I try read carefully all docs about provenpackager and such updates and have not found how deal with such versions. It's not provenpackager specific stuff, but found in the basic packaging guidelines: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag I had look in my packages and few others and found it was updated many times in that way. Just read the page linked above. There is no strict requirement to apply this release versioning scheme for old branches. If newer branches would always win RPM Version Comparison because their %version field is _higher_, you can bump %release in older branches without risk. In packages were was present subrelease after %{?dist} - I increase it. Should or must in next time I add it in any package even it does not have it?? As the guidelines say: Be careful with this! Thank you very much Michael. It's helpful. But what still is not clear to me - if it secure, may it be applied to all packages on update in stable releases? Or instead I should check if increasing release do not break version sequence in branches - do that. And only if it false, introduce subrelease like %{?dist}.1? Well, if you want to spare yourself the extra check, simply use the %{?dist}.N scheme for old branches _always_. Then you're on the safe side. [That means: If you see only a %{?dist} in an old branch, introduce the %{?dist}.N scheme even if it's not strictly necessary. If you see the %{?dist}.N scheme is used already, increase N appropriately. Then it's up to the package owner, or anyone else who touches the package, to check whether the normal %{?dist} scheme would be fine when preparing another bug-fix release sometime after you.] -- Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64 loadavg: 0.57 0.65 0.61 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, Jun 5, 2012 at 1:15 AM, Tomas Mraz tm...@redhat.com wrote: On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote: El Sat, 2 Jun 2012 12:18:17 -0400 Orcan Ogetbil oget.fed...@gmail.com escribió: On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote: The only Freedom you've lost is that now, in addition to the person-hours to do the work and monetary cost to host your bits or generate physical media, you have an additional cost if you wish to have your own cert that will be accepted out of the box by the next generation of PC hardware. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. That's a better deal than Fedora's gpg signing setup. Hmm, will the package maintainers have the freedom to not support users who have the secureboot enabled? How are we going to detect this? i look at it this way. if you patch your software to only run on machines with secureboot disabled your software then becomes non free and has to be removed from fedora. this is becasuse you are placing usage restrictions on it. depending on the license of the software adding such a restriction would violate the license. I am not a lawyer at all and never pretend to play one, but i do not think you as a package maintainer can do that. an upstream could, but i imagine it would be viewed in the same light as a commercial use restriction and become non-free. That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. Aside from being distasteful it is wildly at odds with the goal of the proposed feature. If the proposal before us is accepted with the expressed purpose of making Fedora usable out of the box on this hardware I have a hard time accepting that Fedora would view requiring patching and recompiling components by the end user to remove obstructions to such use as acceptable packaging behavior. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: Retiring vbetool in F18
On 6/5/12 4:05 AM, Petr Pisar wrote: How can I reset the graphics card using KMS (vbetool post)? You've needed to? There's no direct equivalent to vbetool post. KMS drivers handle suspend/resume in the kernel. Some of them have lockup detection and have implemented GPU resets internally (which is far more complex than vbetool post); others don't and haven't. I'm curious what you think the use case is. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
05.06.2012 16:09, Michael Schwendt wrote: On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote: 04.06.2012 22:26, Michael Schwendt написал: On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote: Additionally have worth I try read carefully all docs about provenpackager and such updates and have not found how deal with such versions. It's not provenpackager specific stuff, but found in the basic packaging guidelines: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag I had look in my packages and few others and found it was updated many times in that way. Just read the page linked above. There is no strict requirement to apply this release versioning scheme for old branches. If newer branches would always win RPM Version Comparison because their %version field is _higher_, you can bump %release in older branches without risk. In packages were was present subrelease after %{?dist} - I increase it. Should or must in next time I add it in any package even it does not have it?? As the guidelines say: Be careful with this! Thank you very much Michael. It's helpful. But what still is not clear to me - if it secure, may it be applied to all packages on update in stable releases? Or instead I should check if increasing release do not break version sequence in branches - do that. And only if it false, introduce subrelease like %{?dist}.1? Well, if you want to spare yourself the extra check, simply use the %{?dist}.N scheme for old branches _always_. Then you're on the safe side. [That means: If you see only a %{?dist} in an old branch, introduce the %{?dist}.N scheme even if it's not strictly necessary. If you see the %{?dist}.N scheme is used already, increase N appropriately. Then it's up to the package owner, or anyone else who touches the package, to check whether the normal %{?dist} scheme would be fine when preparing another bug-fix release sometime after you.] Ok, thank you for the explanation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Tue, Jun 5, 2012 at 11:08 AM, Alexander Larsson al...@redhat.com wrote: On Tue, 2012-05-29 at 21:49 +0200, Lennart Poettering wrote: The right way is probably to write a feature page for F18 for it, and then get it through Fedora 18 feature process. With FESCO accepting the feature you should have all you need to get your work accepted by the various stakeholders. I did write a feature page for it. Thats how these threads started. It is in Category:FeaturePageIncomplete , which means FESCo will not see it on its agenda. Please see http://fedoraproject.org/wiki/Features/Policy/Process . Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice: Retiring vbetool in F18
On 2012-06-05, Adam Jackson a...@redhat.com wrote: On 6/5/12 4:05 AM, Petr Pisar wrote: How can I reset the graphics card using KMS (vbetool post)? You've needed to? It's long time when I used the tool. After getting my nvidia card into undefined state (X server crash, relicts after playing with video overlay or directfb console etc.). There's no direct equivalent to vbetool post. KMS drivers handle suspend/resume in the kernel. Some of them have lockup detection and have implemented GPU resets internally (which is far more complex than vbetool post); others don't and haven't. I'm curious what you think the use case is. Maybe the drivers are much better today. I just worry about removing functionality. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/05/2012 03:52 AM, Kay Sievers wrote: Systemd includes libudev.so.1, while the old libudev.rpm provided libudev.so.0. Therefore, all packages using udev need to be rebuilt. Here's a list of owners with packages that currently require libudev.so.0 in Rawhide. # repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut -f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t ajax libdrm bskeggsxorg-x11-drv-nouveau davidz udisks lennartlibatasmart lennartlibcanberra lennartpulseaudio libvirt-maint libvirt lvm-team lvm2 pgfolpc-kbdshim rdieterqt-mobility rhughesweston rrelyeapcsc-lite twaugh system-config-printer udev-maint udev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
On Tue, 2012-06-05 at 11:49 +0200, Nicolas Mailhot wrote: Le Mar 5 juin 2012 10:59, Kamil Paral a écrit : If you are afraid there might be people out there who want wine-Tahoma as a system font, it is important to realize that those people are probably just a tiny fraction of the other side of the argument That's a dangerous argument, looks are subjective and every time someone touches a font it deems ugly others disagree. That is exactly how I see this. On a side note: I personally have the package installed and don't find e. g. facebook particularly ugly or pretty. It'd be much better if 1. the wine font didn't declare a name too heavy for it I am no font expert but from my understanding it does not. Its name is WineTahoma (and WineTahomaBold respectively). Both fonts declare them to be part of the Tahoma family. From my understanding this is perfectly alright as they share some of the defining features of the MS Tahoma font (so maybe the looks differ). 2. the font package was made technically optionnal so people who love the font (I'm sure there are some like all the other times) can still use it Well this is the tricky part as I believe them essential for a standard wine setup. We could of course aim for a dual-solution: Let wine-tahoma-fonts put the fonts in the wine font dir (mandatory for wine) and add a wine-tahoma-fonts-system package (names suggestions welcome) which also puts the fonts in the system wide font path (optional). If this would be a feasible solution I would still like some opinions if this should be done for both fonts or just for the reported bugs about the bold version. -- Andreas Bierfert andreas.bierf...@lowlatency.de signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Notice: samba 4.0 beta1 and what will be available in Fedora
Hi! Samba team has released Samba 4.0 beta 1 today. This is important milestone in a more than 8 years of Samba 4 development. This mail attempts to explain what will be and will not be available in Fedora (Rawhide first, http://koji.fedoraproject.org/koji/taskinfo?taskID=4128906, we are considering to discuss with all affected maintainers if and how an update to F17 would be possible). Sorry for longer than perhaps needed write up as this topic wasn't covered before apart from discussions in Samba and FreeIPA upstreams. Samba 4 is a combined set of daemons, client utilities, and Python bindings that allow communicating using SMB1, SMB2, and soon SMB3 protocols. It also implements Active Directory domain controller (DC) functionality as an integrated Kerberos DC, LDAP server, DNS server, and SMB/CIFS server. Samba 4 AD DC functionality relies heavily on Heimdal Kerberos implementation. Samba 4 includes the embedded Heimdal, if your system misses it, like we have in Fedora. When embedded Heimdal is in use, all Samba 4 code is compiled against this Kerberos implementation, including client side libraries and tools, and traditional file serving smbd daemon we know as 'samba' package in Fedora. Fedora uses MIT Kerberos implementation, both server and client side. Heimdal and MIT Kerberos are targetting to implement the same Keberos V protocol but have their own extensions API and certain semantical differences. They also have slightly different meaning to Kerberos credential cache files format where Kerberos-aware applications store their Kerberos keys. While this is not an issue for client-server communication over a network (a Heimdal client does talk the same Kerberos V protocol that MIT Kerberos server understands and vice versa), interoperability of the client or server code using the same credential cache files on the same system is much less supported for advanced features like S4U2Proxy and S4U2Self. It is generally not advisable to load two different API implementations into the same address space either. When the rest of the system libraries is compiled against MIT Kerberos, use of them within Samba 4 code brings in MIT Kerberos as well. This happens, for example, when linking against OpenLDAP client libraries and using SASL authentication. As part of work we are doing on FreeIPA v3, we have made possible to compile Samba 4 code against MIT Kerberos implementation. Unfortunately, MIT Kerberos does not give option of embedding Kerebros KDC server within another process which is required for Samba 4 AD DC functionality. Thus, when compiled with MIT Kerberos, Samba 4 currently does not provice Active Directory Domain Controller functionality at all, only client side libraries and tools to the extent that does not involve AD DC operations. Also, smbd is compiled against MIT Kerberos and provides functionality equivalent to what is provided by Samba 3's smbd. We are intending to make possible use of AD DC functionality with MIT Kerberos but this is longer term project that requires cooperation between Samba, MIT, and FreeIPA. For GNU/Linux-based clients FreeIPA already provides functionality similar to the one of Active Directory. With FreeIPA v3 we'll have cross-realm trusts support with Active Directory that will allow seamlessly integrating GNU/Linux-based machines into existing AD-based infrastructure. You can get details about implementation from our talk at SambaXP 2012 conference (http://abbra.fedorapeople.org/freeipa.pdf) and earlier roadmap talk at Fedora Devconf in Brno in February 2012 (http://blip.tv/fedoracz/dmitripal-idenitymanagementroadmap-6071539) One consequence of Samba 4 built with MIT Kerberos is that Openchange server code will not be working in Fedora either. Openchange server code requires working Samba 4 DC server with proper AD provisioning. This only affects server side and does not affect Openchange client side support which is used in Evolution MAPI plugin, which will continue to work. Rawhide is already providing Samba 4 built with MIT Kerberos, and Openchange package was modified to include only client side support. The latter also submitted and merged to Openchange upstream. What is available in Rawhide right now? * samba4-* 4.0.0-53beta1 packages are built against system-wide MIT Kerberos libraries. These packages are made conflicting with samba-* packages in areas where they provide the same binaries and/or libraries. You don't need to install samba4-* packages unless you want to use Evolution MAPI plugin and (soon FreeIPA v3 server). * openchange is built to provide client-side libraries to allow Evolution MAPI plugin to work. * Evolution MAPI plugin is rebuilt against new openchange build. What will not be available in Rawhide in time for Fedora 18? * Samba 4 AD DC implementation What about samba and samba4 packages? As samba4 is a superset of Samba 3 packages in Fedora, we are also considering to discuss renaming samba4 back to
Re: *countable infinities only
On 06/02/2012 06:27 PM, drago01 wrote: No one is preventing anyone from providing instructions on how to disable secure boot. We should definitely do that. But those are not mutually exclusive ... i.e we can have both documentation *and* an OS that just works. Everyone, including Microsoft, agrees that the secure boot system can be disabled. Currently the only envisioned mechanism is via a firmware (UEFI) setup, therefore subject to vagaries of different firmware implementations. The firmware is beyond our control: we can't give reliable and meaningful instructions to the user on how to set it, and AFAIK there is no API that would allow the bootloader, or other software layers we control, to reach back and set it for future boots. Therefore(*), it is reasonable and fair to implement an equivalent facility in the signed bootloader, by offering the end user a choice to leave the signed environment. The bootloader might enumerate signed/secure kernels (Windows and official Fedora), but also offer an extra choice, educating the end user by warning that it not only results in booting into a non-secure environment but also opens the possibility of subverting one of the signed/secure environments. I believe(*) this is a defensible position---the choice is left to the end user, and the security implications are almost identical to doing it in firmware. A residual risk of exploits needs to be dealt with, just like vulnerabilities in the rest of the secure boot process; the only downside being that firmware implementations are diverse, and this option would present a single target for exploit attempts, so it would need a heightened level of review. Greetings przemek (*) These are my personal opinions based solely on my own judgement and experience as the technology user. As such, they express only my own personal preferences and are not to be construed in any broader sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 6/4/12 9:52 PM, Kay Sievers wrote: We merged the upstream udev repository entirely into the systemd repository. There is no standalone upstream udev project anymore. The version of systemd which includes udev has landed in rawhide a couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm and no libudev-devel.rpm. I think we can also take this to mean that an explicit: Requires: udev is now redundant? In which case the following (F17) packages can be cleaned up: % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm} --whatrequires udev | sort -u aic94xx-firmware-30-3.fc17.src.rpm alsa-firmware-1.0.25-1.fc17.src.rpm alsa-tools-1.0.25-2.fc17.src.rpm android-tools-20111220git1b251bd-2.fc17.src.rpm ar9170-firmware-2009.05.28-4.fc17.src.rpm argyllcms-1.3.6-2.fc17.src.rpm b43-openfwwf-5.2-7.fc17.src.rpm barry-0.17.1-7.fc17.src.rpm bfa-firmware-3.0.0.0-2.fc17.src.rpm biosdevname-0.3.11-6.fc17.src.rpm bluez-4.98-3.fc17.src.rpm btkbdd-1.2-1.fc17.src.rpm clamtk-4.39-1.fc17.src.rpm crda-1.1.2_2011.04.28-2.fc17.src.rpm cups-1.5.2-12.fc17.src.rpm device-mapper-multipath-0.4.9-25.fc17.src.rpm dracut-018-35.git20120510.fc17.src.rpm drbd-8.3.11-5.fc17.src.rpm em8300-0.18.0-6.fc17.src.rpm fbterm-1.6-5.fc17.src.rpm fxload-2002_04_11-11.fc17.src.rpm gpsd-3.4-1.fc17.src.rpm hplip-3.12.4-2.fc17.src.rpm i2c-tools-3.1.0-1.fc17.src.rpm initscripts-9.37-1.fc17.src.rpm iscan-firmware-2.26.4-2.fc17.src.rpm isdn4k-utils-3.2-81.fc17.src.rpm isight-firmware-tools-1.6-2.fc17.src.rpm iwl1000-firmware-39.31.5.1-2.fc17.src.rpm iwl100-firmware-39.31.5.1-3.fc17.src.rpm iwl5150-firmware-8.24.2.2-3.fc17.src.rpm iwl6000-firmware-9.221.4.1-3.fc17.src.rpm iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm iwl6050-firmware-41.28.5.1-4.fc17.src.rpm libconcord-0.23-9.fc17.src.rpm libdrm-2.4.33-1.fc17.src.rpm libertas-sd8686-firmware-9.70.20.p0-2.fc17.src.rpm libftdi-0.19-3.fc17.src.rpm libgpod-0.8.2-4.fc17.src.rpm libguestfs-1.17.36-2.fc17.src.rpm libmtp-1.1.3-2.fc17.src.rpm libnjb-2.2.7-2.fc17.src.rpm libosinfo-0.1.1-1.fc17.src.rpm libphidget-2.1.8.20120123-1.fc17.src.rpm libvirt-0.9.11.3-1.fc17.src.rpm linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm lvm2-2.02.95-6.fc17.src.rpm MAKEDEV-3.24-10.fc17.src.rpm mdadm-3.2.3-6.fc17.src.rpm media-player-info-16-1.fc17.src.rpm microcode_ctl-1.17-24.fc17.src.rpm NetworkManager-0.9.4.0-7.git20120403.fc17.src.rpm netxen-firmware-4.0.534-5.fc17.src.rpm nut-2.6.3-2.fc17.src.rpm olpc-utils-2.0.7-1.fc17.src.rpm openct-0.6.20-3.fc17.src.rpm openni-primesense-5.0.3.3-2.fc17.src.rpm os-prober-1.53-1.fc17.src.rpm ovirt-node-2.3.0-1.fc17.src.rpm pcmciautils-018-2.fc17.src.rpm pulseaudio-1.1-9.fc17.src.rpm rdma-1.0-11.fc17.src.rpm sane-backends-1.0.22-9.fc17.src.rpm svxlink-11.11.1-4.fc17.src.rpm synce-sync-engine-0.15.1-3.fc17.src.rpm systemd-44-8.fc17.src.rpm udev-182-1.fc17.src.rpm udisks-1.0.4-6.fc17.src.rpm udisks2-1.94.0-4.fc17.src.rpm upower-0.9.16-1.fc17.src.rpm usb_modeswitch-data-20111023-2.fc17.src.rpm util-linux-2.21.1-1.fc17.src.rpm v4l-utils-0.8.7-1.fc17.src.rpm vdr-1.7.27-1.fc17.src.rpm vdr-remote-0.4.0-19.fc17.src.rpm xen-4.1.2-15.fc17.src.rpm xorg-x11-drv-synaptics-1.6.0-1.fc17.src.rpm xorg-x11-drv-vmmouse-12.8.0-1.fc17.src.rpm xorg-x11-drv-wacom-0.14.0-2.fc17.src.rpm - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File SQL-Library-0.0.4.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-SQL-Library: e77199d4d71eac25cc82b2a86711052c SQL-Library-0.0.4.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-SQL-Library] 0.0.4 bump and some cleanup
commit 721bdcf49db6c40c40dda0357c545848fd39ca2b Author: Petr Šabata con...@redhat.com Date: Tue Jun 5 17:35:46 2012 +0200 0.0.4 bump and some cleanup .gitignore|1 + perl-SQL-Library.spec | 25 ++--- sources |2 +- 3 files changed, 12 insertions(+), 16 deletions(-) --- diff --git a/.gitignore b/.gitignore index 55a6d8c..195972f 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ SQL-Library-0.0.3.tar.gz +/SQL-Library-0.0.4.tar.gz diff --git a/perl-SQL-Library.spec b/perl-SQL-Library.spec index ac84578..ea57520 100644 --- a/perl-SQL-Library.spec +++ b/perl-SQL-Library.spec @@ -1,15 +1,15 @@ Name: perl-SQL-Library -Version:0.0.3 -Release:12%{?dist} +Version:0.0.4 +Release:1%{?dist} Summary:Manage libraries of SQL easily License:GPL+ or Artistic Group: Development/Libraries URL:http://search.cpan.org/dist/SQL-Library/ Source0: http://www.cpan.org/authors/id/D/DG/DGORLEY/SQL-Library-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch -BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More) -Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version)) +BuildRequires: perl(ExtUtils::MakeMaker) +BuildRequires: perl(Test::More) +Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version)) %description This is a perl module for managing simple SQL libraries stored in @@ -20,35 +20,30 @@ OUTSIDE of their perl code. %setup -q -n SQL-Library-%{version} %build -%{__perl} Makefile.PL INSTALLDIRS=vendor +perl Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} %install -rm -rf %{buildroot} - make pure_install PERL_INSTALL_ROOT=%{buildroot} - find %{buildroot} -type f -name .packlist -exec rm -f {} \; find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \; - %{_fixperms} %{buildroot}/* - # the better to doc it later... cp t/sqltest.lib example.lib %check make test -%clean -rm -rf %{buildroot} - %files -%defattr(-,root,root,-) %doc Changes LICENSE README example.lib %{perl_vendorlib}/* %{_mandir}/man3/* %changelog +* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.0.4-1 +- 0.0.4 bump +- Modernize spec (remove buildroot, defattr, and command macros) + * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.0.3-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild diff --git a/sources b/sources index e0d2188..4019cc6 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -75b80cb27775bb61f90fbd5b835032ec SQL-Library-0.0.3.tar.gz +e77199d4d71eac25cc82b2a86711052c SQL-Library-0.0.4.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
rawhide report: 20120605 changes
Compose started at Tue Jun 5 08:15:03 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [OpenGTL] OpenGTL-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) OpenGTL-devel-0.9.16-4.fc18.i686 requires libLLVM-3.0.so OpenGTL-devel-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) OpenGTL-libs-0.9.16-4.fc18.i686 requires libLLVM-3.0.so OpenGTL-libs-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) [PackageKit] PackageKit-zif-0.7.4-6.fc18.x86_64 requires libzif.so.3()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [calligra] calligra-core-2.4.90-1.fc18.x86_64 requires calligra-kexi-map-form-widget 0:2.4.90-1.fc18 [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [gdb-heap] gdb-heap-0.5-8.fc17.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [gnome-python2-desktop] gnome-python2-evolution-2.32.0-9.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [hekafs] hekafs-0.7-30.fc18.x86_64 requires glusterfs = 0:3.2.6 [inkscape] inkscape-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) inkscape-view-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) [kdeplasma-addons] kdeplasma-addons-4.8.3-1.fc18.x86_64 requires libkexiv2.so.10()(64bit) plasma-wallpaper-marble-4.8.3-1.fc18.x86_64 requires libmarblewidget.so.13()(64bit) [mail-notification] mail-notification-evolution-plugin-5.4-56.fc18.x86_64 requires libcamel-1.2.so.34()(64bit) [mapnik] mapnik-2.0.0-4.fc17.i686 requires libicuuc.so.48 mapnik-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit) mapnik-utils-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 6/5/12 10:33 AM, Michal Schmidt wrote: Here's a list of owners with packages that currently require libudev.so.0 in Rawhide. # repoquery --whatrequires libudev.so.0 --qf '%{sourcerpm}' | rev | cut -f3- -d- | rev | sort | uniq | fedoradev-pkgowners | sort | column -t ajax libdrm bskeggs xorg-x11-drv-nouveau davidz udisks rhughes weston Fixed. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Releasing ownership of many audio packages (and a little more)
Fedora developers, While I brought many of these into Fedora, I have not been an active maintainer for these packages for a very long time. Most of them have very responsible and active co-maintainers already. I am about to release ownership of the following packages: ardour -- Multichannel Digital Audio Workstation aubio -- An audio labelling library dssi -- Disposable Soft Synth Interface fluidsynth -- Real-time software synthesizer fluidsynth-dssi -- DSSI implementation of Fluidsynth hydrogen -- Advanced drum machine for GNU/Linux jack-audio-connection-kit -- The Jack Audio Connection Kit ladspa-swh-plugins -- A set of audio plugins for LADSPA lash -- LASH Audio Session Handler libfreebob -- FreeBoB firewire audio driver library liblo -- Open Sound Control library liblrdf -- Library for manipulating RDF files describing LADSPA plugins lv2core -- Audio Plugin Standard mxml -- Miniature XML development library phasex -- PHASEX -- Phase Harmonic Advanced Synthesis EXperiment raptor -- Raptor RDF Parser Toolkit for Redland seq24 -- Real-time midi sequencer vkeybd -- Virtual MIDI keyboard whysynth-dssi -- DSSI software synthesizer plugin ws-commons-util -- Common utilities from the Apache Web Services Project zynaddsubfx -- Real-time software synthesizer Anthony Green -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote: Fedora developers, While I brought many of these into Fedora, I have not been an active maintainer for these packages for a very long time. Most of them have very responsible and active co-maintainers already. I am about to release ownership of the following packages: hydrogen -- Advanced drum machine for GNU/Linux I'll take this if none of the co-maintainers steps up soon. -J Anthony Green -- 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: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On Tue, Jun 5, 2012 at 10:30 AM, Adam Jackson a...@redhat.com wrote: On 6/4/12 9:52 PM, Kay Sievers wrote: We merged the upstream udev repository entirely into the systemd repository. There is no standalone upstream udev project anymore. The version of systemd which includes udev has landed in rawhide a couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm and no libudev-devel.rpm. I think we can also take this to mean that an explicit: Requires: udev is now redundant? In which case the following (F17) packages can be cleaned up: % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm} --whatrequires udev | sort -u argyllcms-1.3.6-2.fc17.src.rpm clamtk-4.39-1.fc17.src.rpm Fixed. -J - ajax -- 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: Releasing ownership of many audio packages (and a little more)
Anthony Green wrote: raptor -- Raptor RDF Parser Toolkit for Redland I picked up this one (Fedora only, it's still up for grabs in EPEL 5). I was already a comaintainer. It's part of the Redland stack, which is required by Soprano, which is required by the Nepomuk stack, which is required by the KDE world. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
I wrote: Anthony Green wrote: raptor -- Raptor RDF Parser Toolkit for Redland I picked up this one (Fedora only, it's still up for grabs in EPEL 5). I was already a comaintainer. It's part of the Redland stack, which is required by Soprano, which is required by the Nepomuk stack, which is required by the KDE world. ;-) Hmmm, looking at it, Redland and most other stuff is using raptor2 these days. The only packages still dependent on raptor 1 in Rawhide are: raptor-devel-0:1.4.21-11.fc17.i686 (obviously) flickcurl-0:1.18-2.fc15.i686 librawstudio-0:2.0-5.fc18.i686 rawstudio-0:2.0-5.fc18.i686 So can we get flickcurl and (lib)rawstudio ported to raptor2? I think raptor 1 needs to be retired sooner or later. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Tomas Mraz wrote: That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. That doesn't mean we should ship it in that state. If Fedora decides to support Secure Boot, it needs to be distro-wide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Kamil Paral wrote: Let's assume we have moved wine-Tahoma to wine-specific font directory: 1. Wine users experience stays the same - all wine applications are still rendered correctly 2. General users experience improves - web browser doesn't display a lot of favorite web pages (like Facebook) with an ugly-looking font Now, what is wrong about that? Can we make the font available as Tahoma to WINE only and as Wine Tahoma or something like that (with font substitutions for plain Tahoma NOT configured by default) to systemwide fontconfig? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On 06/05/2012 06:53 PM, Anthony Green wrote: liblo -- Open Sound Control library lv2core -- Audio Plugin Standard mxml -- Miniature XML development library phasex -- PHASEX -- Phase Harmonic Advanced Synthesis EXperiment seq24 -- Real-time midi sequencer whysynth-dssi -- DSSI software synthesizer plugin vkeybd -- Virtual MIDI keyboard zynaddsubfx -- Real-time software synthesizer I'll take these, co-maintainers welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
svn2cl orphaned
Hello, I've released svn2cl's ownership in pkgdb as I don't use it any longer. There were no co-maintainers so it's orphaned now, go grab it if you use it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On Jun 5, 2012 12:58 PM, Jon Ciesla limburg...@gmail.com wrote: On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote: Fedora developers, While I brought many of these into Fedora, I have not been an active maintainer for these packages for a very long time. Most of them have very responsible and active co-maintainers already. I am about to release ownership of the following packages: hydrogen -- Advanced drum machine for GNU/Linux I'll take this if none of the co-maintainers steps up soon. Hi Jon, As one of the comaintainers, I have been doing the actual maintaining of Hydrogen for the last few years. Do you mind if I take the ownership? Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 2012-06-05 at 19:54 +0200, Kevin Kofler wrote: Tomas Mraz wrote: That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. That doesn't mean we should ship it in that state. And I did not say that either. I just said that such hypothetical technical obstacle by no means make the software non-free. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, Jun 5, 2012 at 10:42 PM, Tomas Mraz tm...@redhat.com wrote: On Tue, 2012-06-05 at 19:54 +0200, Kevin Kofler wrote: Tomas Mraz wrote: That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. That doesn't mean we should ship it in that state. And I did not say that either. I just said that such hypothetical technical obstacle by no means make the software non-free. Its silly though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
koji servers and the caname
Hi, When setting up a koji server, does one have to use a caname of koji? Surely one should be able to use a server's FDQN? Thanks - john -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On Tue, Jun 5, 2012 at 3:32 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: On Jun 5, 2012 12:58 PM, Jon Ciesla limburg...@gmail.com wrote: On Tue, Jun 5, 2012 at 11:53 AM, Anthony Green gr...@redhat.com wrote: Fedora developers, While I brought many of these into Fedora, I have not been an active maintainer for these packages for a very long time. Most of them have very responsible and active co-maintainers already. I am about to release ownership of the following packages: hydrogen -- Advanced drum machine for GNU/Linux I'll take this if none of the co-maintainers steps up soon. Hi Jon, As one of the comaintainers, I have been doing the actual maintaining of Hydrogen for the last few years. Do you mind if I take the ownership? Certainly not. Re-orphaned. I don't particularly care who owns it, so long as it's well cared for. :) -J Thanks, Orcan -- 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: glusterfs rename
On Wed, May 30, 2012 at 12:25 PM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, May 30, 2012 at 8:03 PM, Kaleb S. KEITHLEY kkeit...@redhat.com wrote: On 05/30/2012 02:23 PM, Peter Robinson wrote: Yes, for the Fedora side of things I think gluster 3.2 is the best strategy with a fedorapeople repo of 3.3 if it's considered worthwhile for those that wish to play. For gluster 3.3 I suggest a feature page for F-18 / rawhide. Is it feasible for the missing hekafs features to be merged into the 3.3 release train by October when F-18 is due to be released? I was under the impression that glusterfs would be automatically carried forward from f17 into f18, as it apparently was from f16 into f17. It will be carried forward but a major change of features and enhancements is worth doing a feature page to advertise the feature improvements (see the gnome feature page as an example[1] ), it's something for marketing to use and allows you to also detail things like the removal or merge of HekaFS. F18 builds (of 3.2.6) are already available in koji. Until now I haven't heard that a feature page is needed for 3.2.x (or 3.3.x) to be included in f18. (But how to deprecate HekaFS on f18 once the glusterfs-3.3.0 build is available.) See above for feature page details. For deprecate HekaFS you add the the appropriate obsoletes/provides as necessary to the gluster package and follow the process for removing/obsoleteing a package in the wiki. The features that are in HekaFS (in f16 and f17) will get merged into glusterfs-3.3.1+, as I indicated previously, but I won't promise how many of them will be there when f18 ships. We certainly hope that all of them will be, but we aren't making any promises. So that's something that can be documented in a feature page in the wiki and updated as things progress through both the gluster devel process and the fedora release process :) Okay, as a slightly more detailed version: You should follow the full feature process, to be put in the FeatureList for F18. If you want to see what that process looks like, you probably want to look at this diagram: https://fedoraproject.org/wiki/Features/Policy/Process And make your feature page according to the template noted on that wiki page, and submit it to the feature wrangler (via a wiki category change) so that they can have it approved by fesco, at which point it can be added to the actual feature list :) -robyn Peter [1] https://fedoraproject.org/wiki/Features/Gnome3.4 -- 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: Update ImageMagick in Fedora 16
On Tue, 2012-06-05 at 13:55 +0400, Pavel Alexeev wrote: I'll plan unpush that update and work on patching ImageMagick to handle these issues locally. But I'm not security expert and can't guarantee something except mentioned patch apply (contrary leave it on upstream authors, as I was want do first). Even though this means a lot of your work has been waisted, I think it's the right decision to patch ImageMagick to fix the security issues instead of doing a large-scale update of Fedora 16. With regard to the packages that depend on ImageMagick that you already updated: will you revert those commits in git and delete the corresponding builds in koji? Regards, Tadej Janež -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/05/2012 03:52 AM, Kay Sievers wrote: Systemd includes libudev.so.1, while the old libudev.rpm provided libudev.so.0. Therefore, all packages using udev need to be rebuilt. Here is what's happening on my x86_64 rawhide install which has some i686 packages (in particular, mesa) installed due to wine: #yum update mesa-libgbm [...] --- Package mesa-libgbm.i686 0:8.1-0.5.fc18 will be updated --- Package mesa-libgbm.x86_64 0:8.1-0.5.fc18 will be updated --- Package mesa-libgbm.i686 0:8.1-0.6.fc18 will be an update -- Processing Dependency: libudev.so.1(LIBUDEV_183) for package: mesa-libgbm-8.1-0.6.fc18.i686 -- Processing Dependency: libudev.so.1 for package: mesa-libgbm-8.1-0.6.fc18.i686 --- Package mesa-libgbm.x86_64 0:8.1-0.6.fc18 will be an update -- Running transaction check --- Package systemd.i686 0:185-2.fc18 will be installed After having had some funny issues in the past due to there being two systemds (x86_64, i686) installed for some reason, something tells me that it's a bad idea to proceed with the update. Or am I wrong? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote: Tomasz Torcz wrote: You can write .iso image to USB key¹ and boot from it, you know. Even the installation DVD images? What I've heard is that that only works with the live CD images. You can dd all of the iso's to USB or you can use livecd-iso-to-disk for a bit more control over things (despite its name it also works with the dvd iso). -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgp7IqEnABga7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Tue, 2012-06-05 at 16:28 -0700, Brian C. Lane wrote: On Sun, Jun 03, 2012 at 10:32:37PM +0200, Björn Persson wrote: Tomasz Torcz wrote: You can write .iso image to USB key¹ and boot from it, you know. Even the installation DVD images? What I've heard is that that only works with the live CD images. You can dd all of the iso's to USB or you can use livecd-iso-to-disk for a bit more control over things (despite its name it also works with the dvd iso). The best documentation for this at present is https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB - the installation guide is a bit out of date (through no fault of the authors, rather our fault in not notifying them of the various recent improvements to the tools). -- 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
Re: another upgrade, another disaster
On Fri, Jun 01, 2012 at 09:48:37AM -0700, Adam Williamson wrote: On Fri, 2012-06-01 at 10:37 +0200, Caterpillar wrote: I am very disappointed with that, because preupgrade is the official supported way to upgrade Fedora versions Strictly, no. It's *a* supported way. Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. That path is less complex than preupgrade and involves fewer moving parts; it's easier to test and easier to fix and more likely, in general, to be working at any given point. I'd put the possible upgrade methods in this order of likely-to-workness: 1. netinst.iso / DVD.iso with 'updates' repo enabled 2. DVD.iso without 'updates' repo 3. yum *if you follow the instructions carefully* 4. preupgrade 5. yum by the He-Man method ('instructions are for wusses') It should be possible to make preupgrade always work the best. It has the most knowledge about the running system so it can pass that on to Aanconda. We really need to work on making it more reliable for F18. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpwCBVSsgCAD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 04, 2012 at 10:03:24AM +0200, Andrea Musuruane wrote: On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 3rd attempt: Same as options as the 2nd attempt but this time I chose to enable only the F17 remote repositories and I disabled the Install repo so I presume all the packages were downloaded from the net. At about 85% of installation I got a kernel panic - this time I took care of the message unable to handle kernel NULL pointer dereference at 0088. Frankly, I wouldn't trust your hardware. ditto. Kernel panics are not normal :) The above info isn't enough to track down what caused it, we need a picture of the screen. [snip] Everything can be and I will run memtest as you advised. But I didn't had any kernel problem in the past - and I've used every Fedora release on the same PC for about 4 years. After I could bypass this problem - I could install the system, including I think all the RPMs anaconda was trying to install without any problem. Note that I don't run the same kernel used by anaconda because in fedora updates there is available a newer one. Things work, until they don't. It is interesting that a minimal install worked though. I would suspect bad ram as a possibility. Anyway, in case I hit this issue again, I would be interested to know how to get the log of this kind of error. If it isn't a kernel panic you can get all the logs from Anaconda from /tmp/*log -- switch to tty2 and you will have a shell where you can copy them off the system. File a bug and attach the files as individual text/plain attachments. Failure to read the install media usually shows up as errors in syslog. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpQDtLirHSJY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership of many audio packages (and a little more)
On Tue, Jun 5, 2012 at 12:53 PM, Anthony Green wrote: Fedora developers, While I brought many of these into Fedora, I have not been an active maintainer for these packages for a very long time. Most of them have very responsible and active co-maintainers already. I am about to release ownership of the following packages: Hi Anthony, Thank you for all your services. Good work. I hope you will continue to be a Fedora audio user. ardour -- Multichannel Digital Audio Workstation dssi -- Disposable Soft Synth Interface fluidsynth -- Real-time software synthesizer fluidsynth-dssi -- DSSI implementation of Fluidsynth hydrogen -- Advanced drum machine for GNU/Linux lash -- LASH Audio Session Handler libfreebob -- FreeBoB firewire audio driver library liblo -- Open Sound Control library liblrdf -- Library for manipulating RDF files describing LADSPA plugins whysynth-dssi -- DSSI software synthesizer plugin I took the ownership of the above, as I was the one maintaining them lately. jack-audio-connection-kit -- The Jack Audio Connection Kit I was already the primary maintainer of this. I think Anthony just dropped his comaintainership. As always, comaintainers welcome with any of these packages. Cheers, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 05 Jun 2012 08:15:57 +0200 Tomas Mraz tm...@redhat.com escribió: On Mon, 2012-06-04 at 21:30 -0500, Dennis Gilmore wrote: El Sat, 2 Jun 2012 12:18:17 -0400 Orcan Ogetbil oget.fed...@gmail.com escribió: On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote: The only Freedom you've lost is that now, in addition to the person-hours to do the work and monetary cost to host your bits or generate physical media, you have an additional cost if you wish to have your own cert that will be accepted out of the box by the next generation of PC hardware. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. That's a better deal than Fedora's gpg signing setup. Hmm, will the package maintainers have the freedom to not support users who have the secureboot enabled? How are we going to detect this? i look at it this way. if you patch your software to only run on machines with secureboot disabled your software then becomes non free and has to be removed from fedora. this is becasuse you are placing usage restrictions on it. depending on the license of the software adding such a restriction would violate the license. I am not a lawyer at all and never pretend to play one, but i do not think you as a package maintainer can do that. an upstream could, but i imagine it would be viewed in the same light as a commercial use restriction and become non-free. That's a total nonsense unless the restriction is by-license and not just technical obstacle. If it is just a technical obstacle in the code, you can remove it and run the software on any crippled machine at your will. So no, making your software not to work on particular machines does not make it non-free at all. We don't allow software in fedora that has a license that has a usage restriction that says it can not be used in a commercial environment for instance. I do not see why we would allow software that says you can use this as long as secureboot is off. it is essentially the same thing. its a usage restriction. im pretty sure that patching the GPL software to only run on a system that does not have secureboot enabled at least falls into a grey area if not plain violating the gpl http://www.gnu.org/licenses/gpl-faq.html#OrigBSD Why is the original BSD license incompatible with the GPL? (#OrigBSD) Because it imposes a specific requirement that is not in the GPL; namely, the requirement on advertisements of the program. Section 6 of GPLv2 states: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. by patching software to only work on secureboot free systems your placing additional restrictions on the user thats not covered by the GPL thats my take, i dont profess to be a lawyer or to play one on tv so there is every chance i am wrong. Dennis Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/Ow7cACgkQkSxm47BaWffpvQCdHdtHKjZhBBMrbyX7BzadREij PysAn3gdnKoe3n7K7g27NopWC5UF+s8T =4r1U -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, Jun 05, 2012 at 09:43:03PM -0500, Dennis Gilmore wrote: We don't allow software in fedora that has a license that has a usage restriction that says it can not be used in a commercial environment for instance. I do not see why we would allow software that says you can use this as long as secureboot is off. it is essentially the same thing. its a usage restriction. There's a distinction between something that's enforced by the license and something that's merely code. We may not agree with maintainer decisions, and we (as a project) may even require that they be reverted, but we have the freedom to remove that restriction and therefore it's not an issue as far as free software is concerned. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 6 Jun 2012 03:58:14 +0100 Matthew Garrett mj...@srcf.ucam.org escribió: On Tue, Jun 05, 2012 at 09:43:03PM -0500, Dennis Gilmore wrote: We don't allow software in fedora that has a license that has a usage restriction that says it can not be used in a commercial environment for instance. I do not see why we would allow software that says you can use this as long as secureboot is off. it is essentially the same thing. its a usage restriction. There's a distinction between something that's enforced by the license and something that's merely code. We may not agree with maintainer decisions, and we (as a project) may even require that they be reverted, but we have the freedom to remove that restriction and therefore it's not an issue as far as free software is concerned. im talking purely about the wording of the license in that paragraph. if someone sumbited a license that had something along the lines of software under this license can not be used on UEFI systems with secure mode enabled we would reject the license as unfree. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/OyacACgkQkSxm47BaWff8HgCfUDzTBYg/Y4tZjejbzUQASGGA QvIAnRlkViNXPyd2uHZyGdMZAmWJwpfX =IATT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/2012 08:38 AM, Dennis Gilmore wrote: im talking purely about the wording of the license in that paragraph. if someone sumbited a license that had something along the lines of software under this license can not be used on UEFI systems with secure mode enabled we would reject the license as unfree. Nobody else was talking about license restrictions. If such a license is written, then, yes it would be non-free. Rahul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPzua5AAoJELauRe7G9dGM6j8H/Aq9iETe9BpG/kPvIChaZYL+ xWUgP7b8w4p4yP7W8omV2Wl/kKI88vhy32lRr9Ax+HdQXHMn/e33DC/ZQYoGC3ZJ eBzwxB0llxrqKciVJsQFkdNdufcx/50t30T3ZjwhIPv6Rni4M1U1M5drYwUgUoOz Jm0UxjgYt7toHdjTZUh8DivhTRpcUA+/eH2zmZA/lwjzD+/yQNmNXzPIzZ2sn1pf o14akH6NeQN4BQa3Nh0GvT528iNfgUeCJPMdTIGa7f/Fur4T0RHXXQD8blgagFEz 1tPZKLsjZw7ddv+SfuLZuy2nO8h7rwLr9H1RFTLCZjk8iKQSMYlLfrO3XrR0xKQ= =xMmu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59
https://bugzilla.redhat.com/show_bug.cgi?id=823390 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #4 from Petr Pisar ppi...@redhat.com --- $ koji list-tag-history --build=perl-URI-1.60-1.fc16 Warning: the pkgurl option is obsolete, using topurl='http://koji.fedoraproject.org' Mon May 21 09:34:48 2012: perl-URI-1.60-1.fc16 tagged into f16-updates-candidate by pghmcfc Mon May 21 09:40:25 2012: perl-URI-1.60-1.fc16 tagged into f16-updates-testing-pending by bodhi Mon May 21 21:29:33 2012: perl-URI-1.60-1.fc16 untagged from f16-updates-candidate by bodhi Mon May 21 21:29:33 2012: perl-URI-1.60-1.fc16 tagged into f16-updates-testing by bodhi [still active] Mon May 21 21:36:29 2012: perl-URI-1.60-1.fc16 untagged from f16-updates-testing-pending by bodhi That's not two weeks yet. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828689] New: Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=828689 Bug ID: 828689 QA Contact: extras...@fedoraproject.org Severity: unspecified Version: el6 Priority: unspecified CC: perl-devel@lists.fedoraproject.org, steve.tray...@cern.ch Assignee: steve.tray...@cern.ch Summary: Upgrade to new upstream version Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: lionel.c...@cern.ch Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Directory-Queue Product: Fedora EPEL The latest version of Directory::Queue on CPAN is now 1.6. This is the version to use everywhere. Please upgrade in EPEL. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59
https://bugzilla.redhat.com/show_bug.cgi?id=823390 --- Comment #5 from Petr Pisar ppi...@redhat.com --- My calendar has different rules :) I've just submitted it for stable. -- You are receiving this mail because: You are on the CC list for the bug. -- 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 POE-Component-Client-HTTP-0.947.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Component-Client-HTTP: 43f600c77ccf40b44c585955d5656ae4 POE-Component-Client-HTTP-0.947.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-POE-Component-Client-HTTP] 0.947 bump
commit 59d6a8c3c451d2fe900ea62de1558938cbc52b4b Author: Petr Šabata con...@redhat.com Date: Tue Jun 5 11:00:14 2012 +0200 0.947 bump .gitignore |1 + perl-POE-Component-Client-HTTP.spec | 14 -- sources |2 +- 3 files changed, 10 insertions(+), 7 deletions(-) --- diff --git a/.gitignore b/.gitignore index 75c1ddb..c62296c 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ POE-Component-Client-HTTP-0.895.tar.gz /POE-Component-Client-HTTP-0.944.tar.gz /POE-Component-Client-HTTP-0.945.tar.gz /POE-Component-Client-HTTP-0.946.tar.gz +/POE-Component-Client-HTTP-0.947.tar.gz diff --git a/perl-POE-Component-Client-HTTP.spec b/perl-POE-Component-Client-HTTP.spec index 0b01697..be44d80 100644 --- a/perl-POE-Component-Client-HTTP.spec +++ b/perl-POE-Component-Client-HTTP.spec @@ -7,7 +7,7 @@ # define _with_network_tests 1 in your ~/.rpmmacros Name: perl-POE-Component-Client-HTTP -Version:0.946 +Version:0.947 Release:1%{?dist} Summary:A non-blocking/parallel web requests engine for POE Group: Development/Libraries @@ -30,7 +30,7 @@ BuildRequires: perl(IO::Handle) BuildRequires: perl(IO::Socket::INET) BuildRequires: perl(Net::HTTP::Methods) = 5.812 BuildRequires: perl(POE) = 1.312 -# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to +# Original perl(POE::Component::Client::Keepalive) = 0.271 rounded to # 4 digit precision BuildRequires: perl(POE::Component::Client::Keepalive) = 0.2710 BuildRequires: perl(POE::Driver::SysRW) @@ -40,8 +40,7 @@ BuildRequires: perl(POE::Filter::Stackable) BuildRequires: perl(POE::Filter::Stream) BuildRequires: perl(POE::Session) BuildRequires: perl(Scalar::Util) -BuildRequires: perl(Socket) -BuildRequires: perl(Socket::GetAddrInfo) = 0.19 +BuildRequires: perl(Socket) = 2.001 BuildRequires: perl(URI) = 1.37 BuildRequires: perl(Test::Pod) BuildRequires: perl(Test::Pod::Coverage) @@ -55,10 +54,10 @@ Requires: perl(HTTP::Response) = 5.813 Requires: perl(HTTP::Status) = 5.811 Requires: perl(Net::HTTP::Methods) = 5.812 Requires: perl(POE) = 1.312 -# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to +# Original perl(POE::Component::Client::Keepalive) = 0.271 rounded to # 4 digit precision Requires: perl(POE::Component::Client::Keepalive) = 0.2710 -Requires: perl(Socket::GetAddrInfo) = 0.19 +Requires: perl(Socket) = 2.001 Requires: perl(URI) = 1.37 Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version)) @@ -97,6 +96,9 @@ make test %{_mandir}/man3/*.3* %changelog +* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.947-1 +- 0.947 bump + * Tue May 15 2012 Petr Šabata con...@redhat.com - 0.946-1 - 0.946 bump diff --git a/sources b/sources index 1d66bd0..e1746d7 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -6fcd1d7d4a7e62d4bedf25341038c450 POE-Component-Client-HTTP-0.946.tar.gz +43f600c77ccf40b44c585955d5656ae4 POE-Component-Client-HTTP-0.947.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
[Bug 828230] perl-POE-Component-Client-HTTP-0.947 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828230 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-Component-Client-H ||TTP-0.947-1.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-05 05:35:23 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828216] perl-DBD-CSV-0.35 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828216 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- 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 DBD-CSV-0.35.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBD-CSV: 90e1635b1b2e4605f5dc6939c41e3087 DBD-CSV-0.35.tgz -- 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-DBD-CSV] 0.35 bump
commit 7ea5ec0627d12b4dbf2ddd93cc41c114ec30bae8 Author: Petr Šabata con...@redhat.com Date: Tue Jun 5 14:21:22 2012 +0200 0.35 bump .gitignore|1 + perl-DBD-CSV.spec |6 -- sources |2 +- 3 files changed, 6 insertions(+), 3 deletions(-) --- diff --git a/.gitignore b/.gitignore index d5641bc..b434b70 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ DBD-CSV-0.30.tgz /DBD-CSV-0.31.tgz /DBD-CSV-0.33.tgz /DBD-CSV-0.34.tgz +/DBD-CSV-0.35.tgz diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec index 9a3ddbc..5b5c3de 100644 --- a/perl-DBD-CSV.spec +++ b/perl-DBD-CSV.spec @@ -1,5 +1,5 @@ Name: perl-DBD-CSV -Version:0.34 +Version:0.35 Release:1%{?dist} Summary:DBI driver for CSV files Group: Development/Libraries @@ -13,7 +13,6 @@ BuildRequires: perl(ExtUtils::MakeMaker) BuildRequires: perl(SQL::Statement) = 1.33 BuildRequires: perl(Text::CSV_XS) = 0.71 BuildRequires: perl(Test::Harness) -# BuildRequires = 0.90, but 0.98 is recommended BuildRequires: perl(Test::More) = 0.98 Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version)) Requires: perl(DBD::File) = 0.40 @@ -62,6 +61,9 @@ make test %{_mandir}/man3/*.3pm* %changelog +* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 0.35-1 +- 0.35 bump (documentation changes) + * Tue May 15 2012 Petr Šabata con...@redhat.com - 0.34-1 - 0.34 bump (no code changes) - Drop commands macros diff --git a/sources b/sources index e70aaea..7a8d82f 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -03109a9f2cf52da45aa5d7635d8d2dea DBD-CSV-0.34.tgz +90e1635b1b2e4605f5dc6939c41e3087 DBD-CSV-0.35.tgz -- 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
[Bug 828216] perl-DBD-CSV-0.35 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828216 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DBD-CSV-0.35-1.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-05 08:33:26 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828819] New: annoying warning
https://bugzilla.redhat.com/show_bug.cgi?id=828819 Bug ID: 828819 QA Contact: extras...@fedoraproject.org Severity: unspecified Version: 17 Priority: unspecified CC: david.hanneq...@gmail.com, perl-devel@lists.fedoraproject.org Assignee: david.hanneq...@gmail.com Summary: annoying warning Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: abartrav...@gmail.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Curses-UI Product: Fedora Created attachment 589517 -- https://bugzilla.redhat.com/attachment.cgi?id=589517action=edit test program Description of problem: Prototype after '@' for Curses::UI::Widget::width_by_windowscrwidth : $@; at /usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 356. Prototype after '@' for Curses::UI::Widget::height_by_windowscrheight : $@; at /usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 380. Prototype after '@' for Curses::UI::Widget::set_binding : $@; at /usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 898. Prototype after '@' for Curses::UI::Widget::set_mouse_binding : $@; at /usr/share/perl5/vendor_perl/Curses/UI/Widget.pm line 924. Prototype after '@' for Curses::UI::Container::add : $@; at /usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 67. Prototype after '@' for Curses::UI::Container::set_focusorder : @; at /usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 475. Prototype after '@' for Curses::UI::Container::set_draworder : @; at /usr/share/perl5/vendor_perl/Curses/UI/Container.pm line 483. Version-Release number of selected component (if applicable): perl-Curses-UI-0.9607-8.fc17.noarch.rpm How reproducible: always Steps to Reproduce: 1.run edit.pl 2. 3. Actual results: Expected results: Additional info: solved in upstream Curses-UI-0.9609.tar.gz -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828819] annoying warning
https://bugzilla.redhat.com/show_bug.cgi?id=828819 antb52 abartrav...@gmail.com changed: What|Removed |Added Hardware|Unspecified |x86_64 OS|Unspecified |Linux -- You are receiving this mail because: You are on the CC list for the bug. -- 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 File-MMagic-1.28.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-File-MMagic: ea74f4c817229117f4e9341889430308 File-MMagic-1.28.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-MMagic] 1.28 bump and some cleanup
commit ff5cf966f0806acc0934067d52356e0d2f4fc618 Author: Petr Šabata con...@redhat.com Date: Tue Jun 5 15:11:17 2012 +0200 1.28 bump and some cleanup .gitignore|1 + perl-File-MMagic.spec | 46 -- sources |2 +- 3 files changed, 22 insertions(+), 27 deletions(-) --- diff --git a/.gitignore b/.gitignore index df53593..64ab20f 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ File-MMagic-1.22.tar.gz File-MMagic-1.25.tar.gz File-MMagic-1.26.tar.gz File-MMagic-1.27.tar.gz +/File-MMagic-1.28.tar.gz diff --git a/perl-File-MMagic.spec b/perl-File-MMagic.spec index 5932c5c..4b5768f 100644 --- a/perl-File-MMagic.spec +++ b/perl-File-MMagic.spec @@ -1,56 +1,50 @@ Name: perl-File-MMagic -Version:1.27 -Release:13%{?dist} +Version:1.28 +Release:1%{?dist} Summary:A Perl module emulating the file(1) command - Group: Development/Libraries License:ASL 1.0 and BSD URL:http://search.cpan.org/dist/File-MMagic/ Source0: http://www.cpan.org/authors/id/K/KN/KNOK/File-MMagic-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) -Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version)) +BuildRequires: perl(Scalar::Util) +BuildRequires: perl(Test) +Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version)) %description This module attempts to guess file type from its contents like file(1) command. - %prep -%setup -q -n File-MMagic-%{version} - +%setup -q -n File-MMagic-%{version} +iconv -f ISO-2022-JP -t utf8 README.ja README.ja.utf8 mv README.ja.utf8 README.ja %build -%{__perl} Makefile.PL INSTALLDIRS=vendor +perl Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} - %install -rm -rf $RPM_BUILD_ROOT -make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT -find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' -find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';' -chmod -R u+w $RPM_BUILD_ROOT/* - +make pure_install PERL_INSTALL_ROOT=%{buildroot} +find %{buildroot} -type f -name .packlist -exec rm -f {} ';' +find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';' +chmod -R u+w %{buildroot}/* %check make test - -%clean -rm -rf $RPM_BUILD_ROOT - - %files -%defattr(-,root,root,-) -%doc ChangeLog COPYING README.en +%doc ChangeLog COPYING README.en README.ja %{perl_vendorlib}/File/ %{_mandir}/man3/*.3* - %changelog +* Tue Jun 05 2012 Petr Šabata con...@redhat.com - 1.28-1 +- 1.28 bump +- Modernizing spec (removing buildroot, defattr, and command macros) +- Removing trailing whitespace +- Packaging README.ja + * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.27-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild @@ -123,4 +117,4 @@ rm -rf $RPM_BUILD_ROOT - update to 1.15 * Fri Dec 7 2001 root r...@redhat.com -- Spec file was autogenerated. +- Spec file was autogenerated. diff --git a/sources b/sources index e158e90..4302e74 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -4ffb13b6587888e6e455c22988abce5e File-MMagic-1.27.tar.gz +ea74f4c817229117f4e9341889430308 File-MMagic-1.28.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
[Bug 828232] perl-SQL-Library-0.0.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828232 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[abi-compliance-checker/el6] Drop gcc version requirement
commit 68018535d8d44bb876662c84af8928aa02b9d633 Author: Orion Poplawski or...@cora.nwra.com Date: Tue Jun 5 09:50:49 2012 -0600 Drop gcc version requirement abi-compliance-checker.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/abi-compliance-checker.spec b/abi-compliance-checker.spec index ad57d08..9119f9e 100644 --- a/abi-compliance-checker.spec +++ b/abi-compliance-checker.spec @@ -8,7 +8,7 @@ URL: http://ispras.linuxbase.org/index.php/ABI_compliance_checker Source0: https://github.com/lvc/%{name}/downloads/%{name}-%{version}.tar.gz BuildArch: noarch -Requires: gcc = 4.5 +Requires: gcc Requires: binutils %{?perl_default_filter} -- 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
[Bug 828232] perl-SQL-Library-0.0.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828232 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-SQL-Library-0.0.4-1.fc ||18 Resolution|--- |RAWHIDE Last Closed||2012-06-05 12:24:12 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 823390] Please upgrade to FC16's perl-URI to = 1.59
https://bugzilla.redhat.com/show_bug.cgi?id=823390 --- Comment #6 from Ralf Corsepius rc040...@freenet.de --- (In reply to comment #5) From comment #3: Fedora Update System 2012-05-21 22:20:32 EDT ... ... Today is June 5th ... -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 818651] Conflicts with my package apache-1.3.42-3.fc16.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=818651 Sergio Monteiro Basto ser...@serjux.com changed: What|Removed |Added Severity|high|low --- Comment #3 from Sergio Monteiro Basto ser...@serjux.com --- and also, not severity high -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828203] Locale-Codes 3.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828203 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- Package perl-Locale-Codes-3.22-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Locale-Codes-3.22-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8841/perl-Locale-Codes-3.22-1.fc16 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 828234] perl-URI-Title-1.86 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828234 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-URI-Title-1.86-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-URI-Title-1.86-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8847/perl-URI-Title-1.86-1.fc17 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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-CHI] Upstream update.
commit 32a04c1d7b7923aca6fe6d43c001c91fc96cfe1b Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Jun 6 04:29:14 2012 +0200 Upstream update. - Cleanup perl module filters. .gitignore|2 +- perl-CHI.spec | 16 +++- sources |2 +- 3 files changed, 9 insertions(+), 11 deletions(-) --- diff --git a/.gitignore b/.gitignore index 68bedbc..2dcf302 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -/CHI-0.52.tar.gz +/CHI-0.53.tar.gz diff --git a/perl-CHI.spec b/perl-CHI.spec index b7f1957..46d209c 100644 --- a/perl-CHI.spec +++ b/perl-CHI.spec @@ -1,5 +1,5 @@ Name: perl-CHI -Version:0.52 +Version:0.53 Release:1%{?dist} Summary:Unified cache handling interface License:GPL+ or Artistic @@ -28,6 +28,7 @@ BuildRequires: perl(Log::Any::Adapter::Dispatch) = 0.05 BuildRequires: perl(Module::Load::Conditional) BuildRequires: perl(Moose) = 0.66 BuildRequires: perl(Storable) +BuildRequires: perl(String::RewritePrefix) BuildRequires: perl(Task::Weaken) BuildRequires: perl(Test::Builder) BuildRequires: perl(Test::Class) @@ -52,12 +53,7 @@ BuildRequires: perl(Cache::FastMmap) %{?perl_filter_default} -# RPM 4.8 style %{?filter_setup: -%filter_from_provides /^perl(Bar)/d -%filter_from_provides /^perl(Baz)/d -%filter_from_provides /^perl(DummySerializer)/d -%filter_from_provides /^perl(Foo)/d # Replace unversioned dependencies with versioned ones. %filter_from_requires s/^perl(Carp::Assert)$/perl(Carp::Assert) = 0.20/ %filter_from_requires s/^perl(List::MoreUtils)$/perl(List::MoreUtils) = 0.13/ @@ -67,12 +63,10 @@ BuildRequires: perl(Cache::FastMmap) %filter_from_requires s/^perl(Time::Duration::Parse)$/perl(Time::Duration::Parse) = 0.03/ %filter_setup } -# RPM 4.9 style + %global __provides_exclude %{?__provides_exclude:__provides_exclude|}^perl\\(Bar\\) %global __provides_exclude %__provides_exclude|^perl\\(DummySerializer\\) %global __provides_exclude %__provides_exclude|^perl\\(Foo\\) -# Replace unversioned dependencies with versioned ones. -# Already auto-discovered. In addition, RPM 4.9 does not offer replacing. %description CHI provides a unified caching API, designed to assist a developer in @@ -131,6 +125,10 @@ make test %{?with_author_tests:AUTHOR_TESTING=1} %{?with_smoke_tests:AUTOMATED_T %{perl_vendorlib}/CHI/Test* %changelog +* Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.53-1 +- Upstream update. +- Cleanup perl module filters. + * Mon Mar 19 2012 Ralf Corsépius corse...@fedoraproject.org - 0.52-1 - Upstream update. diff --git a/sources b/sources index a160fd2..9fa1a8b 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -b608caf538c6b012f4c0ca5337771972 CHI-0.52.tar.gz +2e35d6819725e0b4decdabb00bdb23fa CHI-0.53.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-CHI/f17] Upstream update.
Summary of changes: 32a04c1... Upstream update. (*) (*) 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-CHI/f16] (2 commits) ...Merge remote-tracking branch 'origin/f17' into f16
Summary of changes: 32a04c1... Upstream update. (*) 0009b4f... Merge remote-tracking branch 'origin/f17' into f16 (*) 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-CHI/f16: 2/2] Merge remote-tracking branch 'origin/f17' into f16
commit 0009b4f03365c354520f3e7c5bde9fa2e9073d93 Merge: 4655b80 32a04c1 Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Jun 6 04:31:39 2012 +0200 Merge remote-tracking branch 'origin/f17' into f16 .gitignore|2 +- perl-CHI.spec | 16 +++- sources |2 +- 3 files changed, 9 insertions(+), 11 deletions(-) --- -- 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 CHI-0.54.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-CHI: 2b638e3887497bee4a0d3eb3e7e407ad CHI-0.54.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-CHI] Upstream update.
commit f3b910dc187ecca4b2ffb9bca2871537b8b4e428 Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Jun 6 04:44:58 2012 +0200 Upstream update. .gitignore|2 +- perl-CHI.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 3 deletions(-) --- diff --git a/.gitignore b/.gitignore index 2dcf302..c1bde9d 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -/CHI-0.53.tar.gz +/CHI-0.54.tar.gz diff --git a/perl-CHI.spec b/perl-CHI.spec index 46d209c..13c3acc 100644 --- a/perl-CHI.spec +++ b/perl-CHI.spec @@ -1,5 +1,5 @@ Name: perl-CHI -Version:0.53 +Version:0.54 Release:1%{?dist} Summary:Unified cache handling interface License:GPL+ or Artistic @@ -125,6 +125,9 @@ make test %{?with_author_tests:AUTHOR_TESTING=1} %{?with_smoke_tests:AUTOMATED_T %{perl_vendorlib}/CHI/Test* %changelog +* Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.54-1 +- Upstream update. + * Wed Jun 06 2012 Ralf Corsépius corse...@fedoraproject.org - 0.53-1 - Upstream update. - Cleanup perl module filters. diff --git a/sources b/sources index 9fa1a8b..260d71d 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -2e35d6819725e0b4decdabb00bdb23fa CHI-0.53.tar.gz +2b638e3887497bee4a0d3eb3e7e407ad CHI-0.54.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