File CGI-Application-Plugin-ActionDispatch-0.98.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-Application-Plugin-ActionDispatch: 475d6e7aec265702e4562281a0c587ac CGI-Application-Plugin-ActionDispatch-0.98.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Thu, Jun 3, 2010 at 4:42 PM, Matt Domsch wrote: > > It also doesn't report any failing packages that have subsequently > been built and published in koji's rawhide since 06-01. That should > cut down on the "but I just fixed that!" responses from now on. One question. Is committing the fix in CVS enough or do I need to also push an update? In my case the package missed a BR that was only used to do tests in the %check section, I removed it now in CVS but the resulting binary package is basically the same as before. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Fri, 2010-06-04 at 05:04 +0200, Kevin Kofler wrote: > James Antill wrote: > > 2. There's no way to do the groupremove operation, easily. > > The groupremove operation is completely and utterly broken by design anyway: It doesn't act perfectly, in all cases, no. [...] > Try groupremoving gnome-desktop on a system with both GNOME and KDE > installed and watch it try to remove half of KDE while leaving half of GNOME > sitting there wasting space. Right, "gnome-desktop" is a typical group. Silly me. > And it just CANNOT be fixed. You mean apart from using yum from rawhide and doing: yum remove @gnome-desktop --setopt=groupremove_leaf_only=true ...or groups as objects, or... > The only (mostly) reliable way to undo a groupinstall is yum history. And > even that will only work as expected if the group was recently installed. So groupremove _has_ to do the same thing as an undo of a groupinstall to not be considered "utterly broken by design"? I guess that means plain remove is also "utterly broken by design"? Wait ... don't answer here ... if you want to troll/rant, feel free to send me personal email where I'll happily ignore it. Subjects like "yum should be faster than rpm" or "why don't we just move to apt/smart/pacman/image-packaging-system" are probably your best bang for the buck. -- James Antill - ja...@fedoraproject.org "... so the consumable rawhide is likely not to get as many updates as its users would like to have." -- Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Fri, Jun 04, 2010 at 04:50:39AM +0200, Kevin Kofler wrote: > Toshio Kuratomi wrote: > > I'm not going to oppose you on the ground that enrico has written good > > packages; I'll oppose you on the groupnd that it's not the job of Fedora > > to prevent people from providing functionality above the minimum. > > The problem is that the mandatory functionality (SysV-style initscripts > compliant to our guidelines) gets pushed to a subpackage to make room for > the optional and completely unneccessary junk, and that in some cases yum > prefers the nonstandard subpackages. > > Plus, he's also violating other guidelines, e.g. for this package: > http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 > Version contains a SVN revision tag which MUST be in Release instead > according to our guidelines. (Thanks to Chen Lei for pointing that out.) > (And look at the mess that nonstandard versioning made to the bumping tool > spot used, see the insane Release values it produced. We have versioning > rules for a reason.) > Like I say, I'm not replying to points regarding whether enrico is doing good or bad packaging. I'm replying to the quoting of a section of the Packaging Guidelines as supposed support for banning other initscripts. To reiterate, there is no such ban in the Packaging Guidelines. -Toshio pgpvvqLcKtSfX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/4 Kevin Kofler : > > The problem is that the mandatory functionality (SysV-style initscripts > compliant to our guidelines) gets pushed to a subpackage to make room for > the optional and completely unneccessary junk, and that in some cases yum > prefers the nonstandard subpackages. > > Plus, he's also violating other guidelines, e.g. for this package: > http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 > Version contains a SVN revision tag which MUST be in Release instead > according to our guidelines. (Thanks to Chen Lei for pointing that out.) > (And look at the mess that nonstandard versioning made to the bumping tool > spot used, see the insane Release values it produced. We have versioning > rules for a reason.) > > Kevin Kofler > > -- I found that spot disable building static libs in his package two days ago, but he reenable yesterday, I really don't know why. http://koji.fedoraproject.org/koji/buildinfo?buildID=176341 Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
James Antill wrote: > 2. There's no way to do the groupremove operation, easily. The groupremove operation is completely and utterly broken by design anyway: 1. It doesn't remove stuff which was independently dragged in by dependencies of the packages in the group. So you'll be removing only the end-user apps and be stuck with most or all of the libraries. (And please don't suggest remove-with-leaves as the "solution", that one is completely and utterly broken by design as well, e.g. it will happily remove a standalone program which happens to also be a dependency of a program you remove.) 2. It also removes stuff which is also in other groups. 3. It also removes stuff which the user had already installed before installing the group. Try groupremoving gnome-desktop on a system with both GNOME and KDE installed and watch it try to remove half of KDE while leaving half of GNOME sitting there wasting space. And it just CANNOT be fixed. The only (mostly) reliable way to undo a groupinstall is yum history. And even that will only work as expected if the group was recently installed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Toshio Kuratomi wrote: > I'm not going to oppose you on the ground that enrico has written good > packages; I'll oppose you on the groupnd that it's not the job of Fedora > to prevent people from providing functionality above the minimum. The problem is that the mandatory functionality (SysV-style initscripts compliant to our guidelines) gets pushed to a subpackage to make room for the optional and completely unneccessary junk, and that in some cases yum prefers the nonstandard subpackages. Plus, he's also violating other guidelines, e.g. for this package: http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 Version contains a SVN revision tag which MUST be in Release instead according to our guidelines. (Thanks to Chen Lei for pointing that out.) (And look at the mess that nonstandard versioning made to the bumping tool spot used, see the insane Release values it produced. We have versioning rules for a reason.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: VPN Work - 2010-06-04 14:00 UTC
There will be an outage starting at 2010-06-04 14:00 UTC, which will last approximately 1 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-06-04 14:00 UTC' Reason for outage: Updating some vpn settings. I hope this will be a blip lasting a few seconds. This is mostly a "just in case" notice. There's a deadline to meet to have it done by the end of the day which is why it is happening earlier in the day instead of after hours. Affected Services: Bodhi - https://admin.fedoraproject.org/updates/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora Talk - http://talk.fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: BFO - http://boot.fedoraproject.org/ Buildsystem - http://koji.fedoraproject.org/ CVS / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2201 Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On 06/04/2010 08:13 AM, Kevin Kofler wrote: > > Right, in this case the Version tag is a blatant violation of our guidelines > and shows that the maintainer either doesn't understand them at all or > doesn't care about them at all. Either way, he needs to get unsponsored. > Would you mind filing a ticket with FESCo detailing the guideline violations and any other non-standard items for all the packages? FESCo can then decide on the appropriate course correction. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Chen Lei wrote: > I found the maintainer violates fedora package/naming guideline many > times, we need a people to persuade him to obey those guideline. IMHO we need to unsponsor him and orphan his packages. There are way too many guideline violations and bizarre nonstandard stuff in his packages. > A more ridiculous release number and a wrong version number: > http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 Right, in this case the Version tag is a blatant violation of our guidelines and shows that the maintainer either doesn't understand them at all or doesn't care about them at all. Either way, he needs to get unsponsored. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
Tom "spot" Callaway wrote: > You might feel that way, but the simple fact is that French citizens can > not abandon copyright (aka put works into the Public Domain). This is > the only license that we've been given, but since it is not valid, we > can't use it. Without a license, we cannot include this in Fedora, > because we have none of the rights required for Free Software. There are plenty of projects partly or entirely written by Europeans which are supposedly "Public Domain", which all have this issue. A lot of that code is already in Fedora. Even projects under the GPL or some other copyright license may be incorporating such code, without even mentioning it, since there's no requirement to mention use of public domain code. It feels odd to single out one such project. Plus, since Red Hat is in the US, doesn't US copyright law apply? What I have read everywhere is that it's the copyright law of the distributor's country which prevails, not the one of the author's country. Have you talked to Red Hat Legal about this? They OKed distributing that code along with JBoss, didn't they? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sources file audit - 2010-05-31
On 06/04/2010 05:02 AM, Kevin Fenzi wrote: > cheeselee:BADSOURCE:kchmviewer-5.2.tar.gz:kchmviewer > Thanks! Fixed in Rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Thu, Jun 03, 2010 at 09:42:04AM -0500, Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2010-06-01 > > This run continues from the previous run, rebuilding those packages > that failed during the earlier run, or that changed between 2010-05-27 > and 06-01. I filed a ton of bugzillas, basically this list. I apologize if there are some duplicates to already-existing FTBFS bugs opened for earlier releases - that wasn't intentional, but please take this opportunity to fix the problem and close both bugs then. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Thu, Jun 03, 2010 at 02:16:56PM -0400, Jon Masters wrote: > Agreed. But it is the same problem as "what if there's an exploit in a > library Anaconda uses to download repos during install?". There would > still be a lot of media out there and I'm not sure we've ever respun the > main images post GA for that, unless I'm just very wrong. As long as > we're very clear, I think it's ok. On the one hand, I think it's a little worse than that, since one is more likely to download arbitrary things. On the other hand, it's a little better, since the whole thing should be used infrequently. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sources file audit - 2010-05-31
On Thu, Jun 3, 2010 at 11:02 PM, Kevin Fenzi wrote: > thomasj:BADURL:glob2-0.9.4.4.tar.gz:glob2 Thanks, fixed in cvs. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sources file audit - 2010-05-31
Here's another run of the sources file checker. Thats against a 2010-05-31 cvs checkout seed. This sourcecheck script takes a full checkout of all Fedora packages in the devel branch and runs 'spectool -g' on each spec file to download any sources that contain a valid URI. It then checks any downloaded source files against the 'sources' file and the checksum of the source in our lookaside cache. - There are 1007 lines in this run. Down from 1391 last run. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt 660 sourcecheck-20080501.txt 642 sourcecheck-20080603.txt 649 sourcecheck-20080705.txt 662 sourcecheck-20080801.txt 912 sourcecheck-20081114.txt 884 sourcecheck-20090215.txt 1060 sourcecheck-20090810.txt 932 sourcecheck-20091101.txt 1612 sourcecheck-20100105.txt (THIS RESULT WAS BOGUS) 1391 sourcecheck-20100106.txt 1007 sourcecheck-20100531.txt You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100531.txt And also attached to this mail. Additionally, I have the output from each packages 'spectool -g' run in: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100531/-dl.txt So you can look at what my script got for trying to download your packages source. This should allow folks to see transitory network failures and the like. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). This could also be a transitory network failure from my checking host or the project hosting. - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. Or tampering with the source package. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. You should fix your package(s) for any of the above problems. NOTE: You should check in a fixed spec file to the devel branch, but there is no need to rebuild your package simply for this change unless there was a functional change due to different sources. kevin -- abompard:BADURL:awstats-6.95.tar.gz:awstats abompard:BADURL:grisbi-0.6.0.tar.bz2:grisbi adalloz:BADURL:pan-0.133.tar.bz2:pan adrian:BADURL:ibmonitor-1.4.tar.gz:ibmonitor agoode:BADSOURCE:escape-src-200912250.tar.bz2:escape agoode:BADURL:gkrellweather-2.0.7.tgz:gkrellm-weather ajax:BADSOURCE:system-config-display-2.2.tar.bz2:system-config-display ajax:BADURL:dxpc-3.9.1.tgz:dxpc ajax:BADURL:gst-plugins-good-0.10.22.3.tar.bz2:gstreamer-plugins-good ajax:BADURL:MesaLib-6.5.1.tar.bz2:mesa-libGLw ajax:BADURL:vbetool-1.2.1.tar.bz2:vbetool akurtakov:BAD_CVS_SOURCE:doclet-5.1.pom:umlgraph akurtakov:BAD_CVS_SOURCE:jflex-1.4.3.pom:jflex akurtakov:BAD_CVS_SOURCE:kxml2-2.2.2.pom:kxml akurtakov:BADSOURCE:jflex-1.4.3.tar.gz:jflex akurtakov:BADURL:kxml2-src-2.2.2.zip:kxml akurtakov:BADURL:maven-bundle-plugin-2.0.0-project.tar.gz:maven-plugin-bundle akurtakov:BADURL:org.osgi.core-1.2.0-project.tar.gz:felix-osgi-core aleksey2005:BADURL:openscada-0.6.4.1.tar.gz:openscada alexl:BADURL:gmime-2.5.1.tar.bz2:gmime anaconda-maint:BADURL:isomd5sum-1.0.6.tar.bz2:isomd5sum anithra:BADSOURCE:com.ibm.systemtapgui.src.tar.gz:eclipse-systemtapgui ankursinha:BADURL:NAU3_4ttf.zip:apa-new-athena-unicode-fonts apevec:BADURL:Config-Augeas-0.701.tar.gz:perl-Config-Augeas arjunroy:BADSOURCE:matahari-0.0.4.tar.gz:matahari asheesh:BADURL:liblicense-0.8.1.tar.gz:liblicense athimm:BADSOURCE:smart-1.3.tar.bz2:smart athimm:BADURL:apt-0.5.15lorg3.95.git416.tar.bz2:apt athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:greylistd_0.8.7.tar.gz:greylistd athimm:BADURL:vtkdata-5.4.2.tar.gz:vtkdata atkac:BADURL:adns-1.4.tar.gz:adns ausil:BADSOURCE:elftoaout-2.3.tgz:elftoaout ausil:BADURL:mysql-gui-tools-5.0r14.tar.gz:mysql-gui-tools ausil:BADURL:snort-2.8.5.1.tar.gz:snort awjb:BADSOURCE:libpolyxmass-0.9.1.tar.gz:libpolyxmass awjb:BADURL:dosbox-0.74.tar.gz:dosbox awjb:BADURL:freealut-1.1.0.tar.gz:freealut awjb:BADURL:libetpan-1.0.tar.gz:libetpan awjb:BADURL:libytnef-1.5.tar.bz:libytnef awjb:BADURL:synce-kpm-0.15.tar.gz:synce-kpm awjb:BADURL:synce-sync-engine
[389-devel] Please Review: (599732) Root node in directory browser shows DN syntax error
https://bugzilla.redhat.com/show_bug.cgi?id=599732 https://bugzilla.redhat.com/attachment.cgi?id=419510&action=diff https://bugzilla.redhat.com/attachment.cgi?id=419510&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 03:24 PM, Alex Hudson wrote: > That's not the argument I'm putting forward. > > The "French cannot waive copyright" argument brings you to the > conclusion you stated; "[The license] is not valid, we can't use it". > > That same argument holds, as far as I can see, for every other > distributor. Yes, but what Red Hat (or every other distributor) does aside from Fedora is not my responsibility. > So effectively we're arguing that everyone else, Red Hat included, is > either oblivious to the legal risk or they looked at it and came to the > wrong conclusion. All of them. More likely is that they did not look, or they are unaware of the complexities around Public Domain. > I'm not saying that's true one way or another, but it would seem to me > that at least getting a second opinion would be worthwhile, because > Fedora's legal resource appears to be making some pretty extraordinary > claims. They're not so extraordinary, and yes, I did get second and third opinions on this. In Europe, the idea of moral rights and the inherent conflict with Public Domain declarations (where a copyright holder explicitly abandons copyright) is well known. As I have pointed out, this is one of the main reasons why the CC-0 license was drafted, to provide the same functional intended end result of a Public Domain declaration (users can do whatever they want with it) while avoiding the conflict of moral rights (except as it would conflict with the moral rights of the copyright holder). The fact that the Creative Commons created a license _explicitly_ to work around this issue provides proof that this issue is legitimate and valid. > And if it is true, I would bet there are significantly more problems > that aopalliance, since there are very few [no] licenses which deal with > EUisms like moral rights, database rights, etc... Not so much. Public Domain declarations are special. Normal FOSS licenses don't hit this, because they are a list of what rights you have for the works they cover. A Public Domain declaration is the abandonment of all copyright, and accordingly, the ability for anyone to do _ANYTHING_ with that work. It isn't even a license. The fact that Public Domain declarations are possible in some jurisdictions (including the United States) further confuses this, because if the aopalliance copyright holders were American instead of French, we would not have this problem. Arguably, someone with a limited understanding of the complexities around Public Domain declarations might see the words "in the Public Domain" and just assume everything was kosher. We know better, and we check all Public Domain declarations extra carefully. Which is how we caught it. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On Thu, 2010-06-03 at 15:09 -0400, Tom "spot" Callaway wrote: > The argument that "everyone else is doing it, so it must be fine" is > also completely false. As my mother eloquently put it to me at age 6, > "If everyone jumped off a bridge, would you?". That's not the argument I'm putting forward. The "French cannot waive copyright" argument brings you to the conclusion you stated; "[The license] is not valid, we can't use it". That same argument holds, as far as I can see, for every other distributor. So effectively we're arguing that everyone else, Red Hat included, is either oblivious to the legal risk or they looked at it and came to the wrong conclusion. All of them. I'm not saying that's true one way or another, but it would seem to me that at least getting a second opinion would be worthwhile, because Fedora's legal resource appears to be making some pretty extraordinary claims. And if it is true, I would bet there are significantly more problems that aopalliance, since there are very few [no] licenses which deal with EUisms like moral rights, database rights, etc... Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 597375] Deleting LDBM database causes backup/restore problem
https://bugzilla.redhat.com/attachment.cgi?id=419482&action=diff https://bugzilla.redhat.com/attachment.cgi?id=419482&action=edit Fix Description: 1) When a backend is removed, the db instance directory was removed as well (See also 463774 - index files for database should be deleted when db is deleted). In case DB_RECOVER_FATAL is set in the DB open after the removal (e.g., in restore), the logs in the transaction logs are replayed and compared with the contents of the DB files. At that time, if the db instance directory does not exist, libdb returns FATAL error. To prevent the problem, we have to leave the empty directory. 2) When removing index files, we don't have to open index files with CREAT flag. smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 02:31 PM, Alex Hudson wrote: > If everyone else is distributing JBoss, though, that calls into question > whether it's Fedora doing it "properly". > > Worrying about a set of rights which are unwaivable seems on the face of > it to be exhibiting an abundance of over-caution, and it seems > particularly sad that Fedora is losing out having to refrain from > distributing another Red Hat-sponsored project. You might feel that way, but the simple fact is that French citizens can not abandon copyright (aka put works into the Public Domain). This is the only license that we've been given, but since it is not valid, we can't use it. Without a license, we cannot include this in Fedora, because we have none of the rights required for Free Software. The fact that it comes from "another Red Hat-sponsored project" is wholly irrelevant. The argument that "everyone else is doing it, so it must be fine" is also completely false. As my mother eloquently put it to me at age 6, "If everyone jumped off a bridge, would you?". The bigger concern is that this code is abandonware. In an active project, this would already be resolved. It also illustrates the point of being sure that projects have valid licensing from the start. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On Thu, 2010-06-03 at 12:29 -0400, Tom "spot" Callaway wrote: > On 06/03/2010 11:54 AM, Iain Arnell wrote: > > And slightly weird that it's okay for Red Hat to distribute it > > themselves, both commercially and as open source from jboss.org, but > > it's questionable for Fedora. > > I can't speak on what Red Hat does on a larger scale. I do know that it > is important to me and Fedora that we do it properly, or not at all. If everyone else is distributing JBoss, though, that calls into question whether it's Fedora doing it "properly". Worrying about a set of rights which are unwaivable seems on the face of it to be exhibiting an abundance of over-caution, and it seems particularly sad that Fedora is losing out having to refrain from distributing another Red Hat-sponsored project. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Thu, 2010-06-03 at 11:09 -0400, seth vidal wrote: > On Thu, 2010-06-03 at 10:57 -0400, Matt McCutchen wrote: > > On Wed, 2010-06-02 at 14:46 -0400, Toshio Kuratomi wrote: > > > When the shebang is to allow running some sort of unittest I generally > > > just > > > leave it alone (the end user won't want to run it and upstream does want > > > to > > > run the code when they're testing). > > > > There is still no reason to have a shebang on a non-executable file. > > The file must have started out executable in order for upstream to run > > it. The proper solution would be to remove the shebang in the same > > place the executability gets removed. > > another option is to not flag things which impact NOT AT ALL > functionality :) Well, the test's just a test. It's not magic. It doesn't *know* whether they affect functionality. The test is obviously designed to catch the case where the packager screws up and doesn't mark a script that actually _needs_ to be executable as executable. Just because in this case it happens that these scripts don't need to be executable, doesn't mean that's always the case. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Thu, 2010-06-03 at 14:05 -0400, Matthew Miller wrote: > On Wed, Jun 02, 2010 at 04:02:21PM -0400, Jon Masters wrote: > > > Hm. I can see the use of this, but I can also see issues with how you > > > do updates for it sanely (if at all.) > > Yea. I think you don't do updates for it in general. I think I agree > > with Seth that this is something Anaconda stuffs in place when it > > installs grub. Optionally, maybe you upgrade it once per release when > > you next run Anaconda, but basically it doesn't change. It's about "get > > me booted to more than a command line to fix stuff", not latest glitz. > > This needs to be stated very clearly in the 'rules' for the feature. The > environment should be kept minimal and rescue-focused, to reduce the risk of > security vulnerabilities in the rescue tools. (What if there's an exploit in > wget or curl that can be used to execute arbitrary code when you think > you're just downloading an RPM to fix an issue?) Agreed. But it is the same problem as "what if there's an exploit in a library Anaconda uses to download repos during install?". There would still be a lot of media out there and I'm not sure we've ever respun the main images post GA for that, unless I'm just very wrong. As long as we're very clear, I think it's ok. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 09:59 PM, Tom "spot" Callaway wrote: > > I can't speak on what Red Hat does on a larger scale. I do know that it > is important to me and Fedora that we do it properly, or not at all. > Yep. Red Hat can do what is necessary for the commercial success of free software. Meanwhile, Fedora's focus on long term sustainability within a community is a breath of fresh air. You play by the well defined rules or stay out of it. The expectations are clear. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, Jun 02, 2010 at 04:02:21PM -0400, Jon Masters wrote: > > Hm. I can see the use of this, but I can also see issues with how you > > do updates for it sanely (if at all.) > Yea. I think you don't do updates for it in general. I think I agree > with Seth that this is something Anaconda stuffs in place when it > installs grub. Optionally, maybe you upgrade it once per release when > you next run Anaconda, but basically it doesn't change. It's about "get > me booted to more than a command line to fix stuff", not latest glitz. This needs to be stated very clearly in the 'rules' for the feature. The environment should be kept minimal and rescue-focused, to reduce the risk of security vulnerabilities in the rescue tools. (What if there's an exploit in wget or curl that can be used to execute arbitrary code when you think you're just downloading an RPM to fix an issue?) -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 01:01 PM, Matthew Miller wrote: > On Thu, Jun 03, 2010 at 12:29:15PM -0400, Tom spot Callaway wrote: > >> I can't speak on what Red Hat does on a larger scale. I do know that it >> is important to me and Fedora that we do it properly, or not at all. >> > Yes please. This is why I trust Fedora. > > Hear, hear. One of the thing I like best about Fedora is the staunch strictness (or strich staunchness?) where the law is concerned. I don't have to worry about going to jail for what's on my laptop. Er, the software, anyway. ;) -J -- - in your fear, speak 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: JBoss stalled (was Re: status of some packages ??)
On Thu, Jun 03, 2010 at 12:29:15PM -0400, Tom spot Callaway wrote: > I can't speak on what Red Hat does on a larger scale. I do know that it > is important to me and Fedora that we do it properly, or not at all. Yes please. This is why I trust Fedora. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Wed, Jun 02, 2010 at 02:55:53AM +0200, Kevin Kofler wrote: > FYI, FESCo decided on this particular issue that a provenpackager can fix > tor to comply with our initscripts guidelines for released Fedoras. (As far > as I know, the maintainer already fixed the Rawhide package.) It's true; it is fixed in Rawhide. Okay then. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 15:58 -0800, Jeff Spaleta wrote: > On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson wrote: > > It's a bit intangible and not entirely predicated on whether we're using > > the keyword or flag setup, I think. Currently when we're considering > > bugs we use a search that excludes closed bugs, > > In either case, I would suggest that it may be best to just exclude > certain closed resolutions but review others. wontfix and notabug may > hide some potential blockers that are worthy of calm discussion with a > maintainer from a release management pov. That sounds like a good idea to me, thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-WWW-Curl/devel perl-WWW-Curl.spec,1.13,1.14
Author: eponyme
Update of /cvs/pkgs/rpms/perl-WWW-Curl/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv11641
Modified Files:
perl-WWW-Curl.spec
Log Message:
Remove a test that requires network
Index: perl-WWW-Curl.spec
===
RCS file: /cvs/pkgs/rpms/perl-WWW-Curl/devel/perl-WWW-Curl.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-WWW-Curl.spec 3 Jun 2010 17:12:57 - 1.13
+++ perl-WWW-Curl.spec 3 Jun 2010 17:20:24 - 1.14
@@ -1,6 +1,6 @@
Name: perl-WWW-Curl
Version:4.11
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl extension interface for libcurl
License:MPLv1.1 or MIT
Group: Development/Libraries
@@ -60,8 +60,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
-* Thu Jun 3 2010 Nicoleau Fabien - 4.11-2
+* Thu Jun 3 2010 Nicoleau Fabien - 4.11-3
- Remove test 19 because it requires network
+* Fri May 07 2010 Marcela Maslanova - 4.11-2
+- Mass rebuild with perl-5.12.0
* Fri Dec 18 2009 Nicoleau Fabien - 4.11-1
- Update to 4.11
* Mon Dec 7 2009 Stepan Kasal - 4.09-3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: suggestion: rescue boot extension
On 06/03/2010 11:49 AM, Chris Lumens wrote: >> Rescue environment aside, it'd be nice to avoid failing the upgrade >> because of insufficient space in /boot. I think 200 MB default /boot >> prove to be too small---perhaps 500 MB should be the new default? > > Of course, it already is: > > http://git.fedoraproject.org/git/?p=anaconda.git;a=commit;h=3ebabfdcd9c5a61bf8afe57a7ae1e75ad6889b30 > > - Chris Thanks for fixing it back in Dec 09---it seems that I am just 7 months behind in my reading :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-WWW-Curl/devel perl-WWW-Curl.spec,1.11,1.12
Author: eponyme
Update of /cvs/pkgs/rpms/perl-WWW-Curl/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv10420
Modified Files:
perl-WWW-Curl.spec
Log Message:
Remove a test that requires network
Index: perl-WWW-Curl.spec
===
RCS file: /cvs/pkgs/rpms/perl-WWW-Curl/devel/perl-WWW-Curl.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-WWW-Curl.spec 7 May 2010 10:17:36 - 1.11
+++ perl-WWW-Curl.spec 3 Jun 2010 17:09:51 - 1.12
@@ -60,9 +60,8 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
-* Fri May 07 2010 Marcela Maslanova - 4.11-2
-- Mass rebuild with perl-5.12.0
-
+* Thu Jun 3 2010 Nicoleau Fabien - 4.11-2
+- Remove test 19 becaus it requires network
* Fri Dec 18 2009 Nicoleau Fabien - 4.11-1
- Update to 4.11
* Mon Dec 7 2009 Stepan Kasal - 4.09-3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora rawhide FTBFS status 2010-06-01 i386
On Thu, Jun 03, 2010 at 09:43:26AM -0500, Matt Domsch wrote: > libguestfs-1.3.17-1.fc14 (build/make) rjones,mdbooth,virtmaint Gnulib problem. This should be fixed in the next release. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 11:54 AM, Iain Arnell wrote: > On Thu, Jun 3, 2010 at 5:13 PM, Michel Alexandre Salim > wrote: >> On Thu, Jun 3, 2010 at 4:50 PM, Tom "spot" Callaway >> wrote: >>> >>> This is true (well, the problem is that there is no applicable and valid >>> license, not so much that it is incompatible), no matter how absurd it >>> might seem. >>> >>> In general, Java licensing is... poor at best. This is admittedly a >>> rather confusing case, but still. >>> >> This seems really dangerous. If JBoss has an unclear legal status due >> to this, perhaps aopalliance needs to be reimplemented from scratch, >> or JBoss should not depend on it? > > And slightly weird that it's okay for Red Hat to distribute it > themselves, both commercially and as open source from jboss.org, but > it's questionable for Fedora. I can't speak on what Red Hat does on a larger scale. I do know that it is important to me and Fedora that we do it properly, or not at all. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 564664] FTBFS perl-HTML-FormFu-Model-DBIC-0.05002-2.fc13
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=564664 Matt Domsch changed: What|Removed |Added Status|NEW |CLOSED CC||matt_dom...@dell.com Resolution||RAWHIDE --- Comment #8 from Matt Domsch 2010-06-03 12:05:34 EDT --- perl-HTML-FormFu-Model-DBIC-0.06000-1.fc14.src.rpm builds in rawhide. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On 3 June 2010 21:29, Rakesh Pandit wrote: > On 3 June 2010 20:12, Matt Domsch wrote: >> Fedora Fails To Build From Source Results for x86_64 >> using rawhide from 2010-06-01 >> > > Small enhancement request for your scripts: I have two packages in > list (one maintainer and another co-maintainer) and both are mentioned > at the bottom, but I get mail twice. Can you update it to send mail > once in case it is easy todo and you consider it worth. > > Thanks (specially for keeping good work going :) , > Failed to notice, these are for two separate archs, so it is ok. thanks. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On 3 June 2010 20:12, Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2010-06-01 > Small enhancement request for your scripts: I have two packages in list (one maintainer and another co-maintainer) and both are mentioned at the bottom, but I get mail twice. Can you update it to send mail once in case it is easy todo and you consider it worth. Thanks (specially for keeping good work going :) , -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On Thu, Jun 3, 2010 at 5:13 PM, Michel Alexandre Salim wrote: > On Thu, Jun 3, 2010 at 4:50 PM, Tom "spot" Callaway > wrote: >> >> This is true (well, the problem is that there is no applicable and valid >> license, not so much that it is incompatible), no matter how absurd it >> might seem. >> >> In general, Java licensing is... poor at best. This is admittedly a >> rather confusing case, but still. >> > This seems really dangerous. If JBoss has an unclear legal status due > to this, perhaps aopalliance needs to be reimplemented from scratch, > or JBoss should not depend on it? And slightly weird that it's okay for Red Hat to distribute it themselves, both commercially and as open source from jboss.org, but it's questionable for Fedora. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: status of some packages ??
On 05/30/2010 04:26 AM, Chen Lei wrote: > http://fedoraproject.org/wiki/Features/TeXLive Current status * Targeted release: Fedora 13 * Last updated: Sat Jan 9 2009 * Percentage of completion: 60% > http://fedoraproject.org/wiki/Features/Ruby_1.9.1 Current status * Targeted release: Fedora 14 * Last updated: 2009-10-22 * Percentage of completion: 60% That info is outdated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Crypt-DSA/devel perl-Crypt-DSA-1.16-meta.patch, NONE, 1.1 perl-Crypt-DSA.spec, 1.15, 1.16
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-Crypt-DSA/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3296
Modified Files:
perl-Crypt-DSA.spec
Added Files:
perl-Crypt-DSA-1.16-meta.patch
Log Message:
META.yml should specify perl >= 5.006 due to use of 3-arg open (CPAN RT#58094)
perl-Crypt-DSA-1.16-meta.patch:
META.yml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- NEW FILE perl-Crypt-DSA-1.16-meta.patch ---
--- Crypt-DSA-1.16/META.yml 2009-09-11 13:46:04.0 +0100
+++ Crypt-DSA-1.16/META.yml 2010-06-03 16:31:46.426107813 +0100
@@ -27,7 +27,7 @@
IPC::Open3: 0
MIME::Base64: 0
Math::BigInt: 1.78
- perl: 5.005
+ perl: 5.006
resources:
ChangeLog: http://fisheye2.atlassian.com/changelog/cpan/trunk/Crypt-DSA
license: http://dev.perl.org/licenses/
Index: perl-Crypt-DSA.spec
===
RCS file: /cvs/pkgs/rpms/perl-Crypt-DSA/devel/perl-Crypt-DSA.spec,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- perl-Crypt-DSA.spec 6 May 2010 07:23:55 - 1.15
+++ perl-Crypt-DSA.spec 3 Jun 2010 15:49:43 - 1.16
@@ -1,12 +1,13 @@
Summary: Perl module for DSA signatures and key generation
Name: perl-Crypt-DSA
Version: 1.16
-Release: 3%{?dist}
+Release: 4%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Url: http://search.cpan.org/dist/Crypt-DSA/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/Crypt-DSA-%{version}.tar.gz
Patch0:perl-Crypt-DSA-dsaparam.patch
+Patch1:perl-Crypt-DSA-1.16-meta.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
BuildArch: noarch
@@ -49,13 +50,14 @@ verification, and key generation.
# Patch for openssl dsaparam 1.0 compatibility (CPAN RT#49668)
%patch0 -p1
+# Fix minimum perl version in META.yml (CPAN RT#58094)
+%patch1 -p1
+
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
%{__make} %{?_smp_mflags}
%check
-# switch off until Perl::MinimumVersion is fixed
-rm -rf t/99_pmv.t
%{__make} test AUTOMATED_TESTING=1
%install
@@ -81,6 +83,9 @@ rm -rf t/99_pmv.t
%{_mandir}/man3/Crypt::DSA::Util.3pm*
%changelog
+* Thu Jun 3 2010 Paul Howarth 1.16-4
+- META.yml should specify perl >= 5.006 due to use of 3-arg open (CPAN
RT#58094)
+
* Fri Apr 30 2010 Marcela Maslanova - 1.16-3
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Package maintainers -- want test results by mail?
On Thu, Jun 3, 2010 at 5:09 PM, seth vidal wrote: > On Thu, 2010-06-03 at 10:57 -0400, Matt McCutchen wrote: >> On Wed, 2010-06-02 at 14:46 -0400, Toshio Kuratomi wrote: >> > When the shebang is to allow running some sort of unittest I generally just >> > leave it alone (the end user won't want to run it and upstream does want to >> > run the code when they're testing). >> >> There is still no reason to have a shebang on a non-executable file. >> The file must have started out executable in order for upstream to run >> it. The proper solution would be to remove the shebang in the same >> place the executability gets removed. > > another option is to not flag things which impact NOT AT ALL > functionality :) Indeed. Only warn about non-executable shebang scripts in $PATH (or non-executable anything in $PATH); otherwise it's just a comment that me be useful elsewhere for test purposes. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
> Rescue environment aside, it'd be nice to avoid failing the upgrade > because of insufficient space in /boot. I think 200 MB default /boot > prove to be too small---perhaps 500 MB should be the new default? Of course, it already is: http://git.fedoraproject.org/git/?p=anaconda.git;a=commit;h=3ebabfdcd9c5a61bf8afe57a7ae1e75ad6889b30 - Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 15:31 -0800, Jeff Spaleta wrote: > On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson wrote: > > Ah. It's a shame it wasn't put up for consideration as a release > > blocker. Obviously the rather peremptory response from Jakub didn't help > > with that... > > Would the flag concept for blocker status that Jesse was championing > recently have helped in this situation. If the bug is closed with a > non fixed resolution, but flagged with request from the reporter to be > a blocker would this have provided a mechanism to escalate this issue > into a release management discussion that would have revisited the > issue and overturned Jakub's assessment of the situation? Or would > resolution as notabug have nullified a blocker request flag mechanism? I don't see why the means to overturn a NOTABUG resolution should be coupled to the blocker status. If I were the reporter, I would first reopen the bug. If the maintainer continues to close it with unhelpful comments, I would raise the issue on the devel list to build support for my position or find out if there's a better way to address the issue. I assume the ultimate way to appeal a bad decision is to place the issue on the FESCo agenda, though I have never done that myself. Once it is established that the bug is valid and will be kept open, it can be considered as a blocker like any other bug. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On Thu, Jun 3, 2010 at 4:50 PM, Tom "spot" Callaway wrote: > On 06/03/2010 10:33 AM, Xose Vazquez Perez wrote: >> On 06/01/2010 05:09 PM, Tom spot Callaway wrote: >> >>> On 05/29/2010 07:25 PM, Xose Vazquez Perez wrote: JBoss[1] is still a *big* deficit. Potential for f14/15 ? >>> >>> I'm pretty sure JBoss is still a no-go because of poor licensing, >>> specifically: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=479598 >> >> That is a nonsense. >> >> JBoss is stalled because it depends on a package with: >> >> - incompatible license >> - six years old >> - dead upstream >> >> :-? > > This is true (well, the problem is that there is no applicable and valid > license, not so much that it is incompatible), no matter how absurd it > might seem. > > In general, Java licensing is... poor at best. This is admittedly a > rather confusing case, but still. > This seems really dangerous. If JBoss has an unclear legal status due to this, perhaps aopalliance needs to be reimplemented from scratch, or JBoss should not depend on it? -- Michel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Thu, 2010-06-03 at 10:57 -0400, Matt McCutchen wrote: > On Wed, 2010-06-02 at 14:46 -0400, Toshio Kuratomi wrote: > > When the shebang is to allow running some sort of unittest I generally just > > leave it alone (the end user won't want to run it and upstream does want to > > run the code when they're testing). > > There is still no reason to have a shebang on a non-executable file. > The file must have started out executable in order for upstream to run > it. The proper solution would be to remove the shebang in the same > place the executability gets removed. another option is to not flag things which impact NOT AT ALL functionality :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Wed, 2010-06-02 at 14:52 -0700, Adam Williamson wrote: > On Wed, 2010-06-02 at 18:31 +0200, Christof Damian wrote: > > Second question: I would love to have a meta package which brings all > > of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, > > ...) together and allows installation with one yum command. But as far > > as I could detect from the random posts it seems that meta packages > > are not really wanted on Fedora. An alternative is the comps list, but > > that doesn't allow for rapid changes and phpqa would be a bit > > specific. > > For whatever reason, We Don't Like Metapackages and the 'recommended' > way to do it is with a package group. I've never seen a particularly > coherent reason given for this, but never mind. Some packagers _have_ > done metapackages, and none of them have been shot yet. Just sayin'. Off the top of my head: 1. They are similar to groups and having two things that are similar is bad. 2. There's no way to do the groupremove operation, easily. 3. There's no way to do the groupinfo operation, easily. 4. There's no naming guideline, so grouplist operations are also not easily available. 5. You can't do: @mygroup -blah ...in a kickstart, if "mygroup" is a metapackage. 6. All the packages as part of the metapackage will be marked as "reason = dep", which isn't true. 7. The one advantage they have (you can update the metapackage and have the new members added everywhere) will go away when we get groups as objects. 8. If you want to remove part of a metapackage, you have to remove the metapackage itself ... and thus. lose the only advantage they have. 9. There's no way to make them different for different spins. 10. There's no way to extend them from other repos. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On Wed, 2010-06-02 at 23:14 -0400, Matthias Clasen wrote: > On Thu, 2010-06-03 at 08:35 +0530, Rahul Sundaram wrote: > > On 06/03/2010 03:28 AM, Matthias Clasen wrote: > > > > > > That is just making things complicated, for minimal gain. > > > > > > > > > > Yes and no. Purely as a desktop user, there isn't much of a gain but > > certainly for a more minimalistic environment it makes sense to list > > them in comps and not add a artificial dependency. It also helps Fedora > > Remixes switch defaults with minimal amount of effort. I think leaving > > things customizable is a benefit. I don't see much of a complication > > really. > > The complication was the talk about virtual provides and whatnot. I don't see what is complicated about adding a provide of "cursor-theme" to each cursor theme and changing the requires of libXcursor, etc. to "cursor-theme". The same approach is used other places in the distribution, e.g., for "desktop-notification-daemon". -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 14:46 -0400, Toshio Kuratomi wrote: > When the shebang is to allow running some sort of unittest I generally just > leave it alone (the end user won't want to run it and upstream does want to > run the code when they're testing). There is still no reason to have a shebang on a non-executable file. The file must have started out executable in order for upstream to run it. The proper solution would be to remove the shebang in the same place the executability gets removed. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
On 06/03/2010 10:33 AM, Xose Vazquez Perez wrote: > On 06/01/2010 05:09 PM, Tom spot Callaway wrote: > >> On 05/29/2010 07:25 PM, Xose Vazquez Perez wrote: >>> JBoss[1] is still a *big* deficit. Potential for f14/15 ? >> >> I'm pretty sure JBoss is still a no-go because of poor licensing, >> specifically: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=479598 > > That is a nonsense. > > JBoss is stalled because it depends on a package with: > > - incompatible license > - six years old > - dead upstream > > :-? This is true (well, the problem is that there is no applicable and valid license, not so much that it is incompatible), no matter how absurd it might seem. In general, Java licensing is... poor at best. This is admittedly a rather confusing case, but still. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2010-06-01 i386
Fedora Fails To Build From Source Results for i386 using rawhide from 2010-06-01 This run continues from the previous run, rebuilding those packages that failed during the earlier run, or that changed between 2010-05-27 and 06-01. This picks up a few fixes: * a newer pkgconfig that doesn't segfault when you look at it wrong (thanks to Matthias Clasen and Mamoru Tasaka) * a yum fix (thanks to Seth Vidal, bug 598221) * avoids running out of disk space when building using a tmpfs (thanks to Kalev Lember). It also doesn't report any failing packages that have subsequently been built and published in koji's rawhide since 06-01. That should cut down on the "but I just fixed that!" responses from now on. I manually rebuilt eclipse-emf, java-1.6.0-openjdk, qt, seamonkey, and webkitgtk which had failed due to disk space (oddly, both with and without using large tmpfs). They _may_ still appear below for you, but you can ignore them. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 61 Open Bugs which now build, and can be marked CLOSED RAWHIDE: apanov-heuristica-fonts: [u'565136'] audex: [u'555453'] btrfs-progs: [u'565112'] cachefilesd: [u'565135'] cas: [u'564700'] clisp: [u'539088'] clutter-gtk: [u'539122'] collectd: [u'564943'] comedilib: [u'555459'] cuetools: [u'538987'] dbxml-perl: [u'555452'] dbxml: [u'555494'] doodle: [u'564678'] epydoc: [u'565627'] esc: [u'555411'] fedora-security-guide-en-US: [u'538934'] fence-virt: [u'565111'] florence: [u'564675'] gdm: [u'539144'] ghostscript-fonts: [u'565206'] gnome-netstatus: [u'564852'] griv: [u'565081'] harminv: [u'565036'] hdf: [u'538896'] healpy: [u'564726'] hulahop: [u'564792'] itpp: [u'565156'] keepassx: [u'539011'] krb5-auth-dialog: [u'555498'] kst: [u'539056'] libvirt-qpid: [u'565139'] lordsawar: [u'564950'] monodevelop-debugger-mdb: [u'539051'] mpqc: [u'565030'] openwsman: [u'564916'] paperbox: [u'564997'] perl-HTML-FormFu-Model-DBIC: [u'564664'] perl-MooseX-Role-Cmd: [u'564789'] plexus-appserver: [u'564825'] plexus-bsh-factory: [u'564981'] plexus-xmlrpc: [u'564880'] pyclutter: [u'565185'] pyscript: [u'564816'] python-nss: [u'565044'] qemu: [u'564683'] razertool: [u'564813'] rpm: [u'565223'] scitools: [u'564781'] showimg: [u'539025'] springlobby: [u'564795'] subversion-api-docs: [u'538966'] synce-kde: [u'539195'] synce-trayicon: [u'564881'] tasque: [u'539146'] tex-musixtex: [u'564757'] UnihanDb: [u'538948'] virt-ctrl: [u'538891'] warzone2100: [u'565184'] xca: [u'565073'] xen: [u'565063'] zfs-fuse: [u'565076'] Total packages: 9310 Number failed to build: 339 Number expected to fail due to ExclusiveArch or ExcludeArch: 17 Leaving: 322 Of those expected to have worked... Without a bug filed: 217 -- AcetoneISO2-2.2.1-2.fc13 (build/make) spot Django-1.2.1-1.fc14 (build/make) smilner,dmalcolm,salimma,smilner E-1.0.002-4.fc11 (build/make) dwheeler GtkAda-2.14.0-4.fc13 (build/make) gemi,rombobeorn OpenGTL-0.9.13-1.fc13 (build/make) rdieter PyQt4-4.7.3-2.fc14 (build/make) rdieter,dmalcolm,than PythonCard-0.8.2-5.fc12 (build/make) mmahut R-BSgenome-1.14.2-1.fc12 (build/make) pingou R-BSgenome.Celegans.UCSC.ce2-1.3.16-1.fc13 (build/make) pingou R-Biostrings-2.14.12-1.fc14 (build/make) pingou R-IRanges-1.4.16-1.fc14 (build/make) pingou R-RScaLAPACK-0.6.1-2.fc14 (build/make) spot TnL-07-12.fc13 (build/make) jwrdegoede adonthell-0.3.5-0.8.fc12 (build/make) bochecha aimage-3.2.4-1.fc13 (build/make) kwizart amarok-2.3.0.90-1.fc14 (build/make) rdieter,kaboon,rdieter,thomasj,tuxbrewr apache-commons-exec-1.0.1-2.fc13 (build/make) melmorabity atlas-3.8.3-15.fc13 (build/make) deji,deji autofs-5.0.5-27.fc14 (build/make) jmoyer,iankent bibletime-2.5-3.fc14 (build/make) anderson,deji blokkal-0.1.2-1.fc13.1 (build/make) thomasj bsf-2.4.0-5.fc14 (build/make) pcheung buildbot-0.7.12-1.fc13 (build/make) giallu,dmalcolm,smilner cegui-0.6.2-5.fc13 (build/make) jwrdegoede,atorkhov,bruno cellwriter-1.3.4-3.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb cfdg-2.2.1-1.fc13 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb cfdg-fe-0.1-4.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb cgit-0.8.2.1-3.fc12 (build/make) tmz chipmunk-4.1.0-8.fc13 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb choqok-0.9.55-15.fc14 (build/make) tejas chromium-bsu-0.9.14-6.fc13 (build/make) jwrdegoede classpathx-jaf-1.0-15.1.fc12 (build/make) devrim,dwalluck compat-libgda-3.1.2-3.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) orphan cvc3-2.2-1.fc13 (build/make) jjames cylindrix-1.0-11.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb dates-0.4.11-3.fc14 (build/make) pbrobinson diveintopython-5.4-17.fc13 (build/make) julian eclipse-3.5.2-4.fc14
Fedora rawhide FTBFS status 2010-06-01 x86_64
Fedora Fails To Build From Source Results for x86_64 using rawhide from 2010-06-01 This run continues from the previous run, rebuilding those packages that failed during the earlier run, or that changed between 2010-05-27 and 06-01. This picks up a few fixes: * a newer pkgconfig that doesn't segfault when you look at it wrong (thanks to Matthias Clasen and Mamoru Tasaka) * a yum fix (thanks to Seth Vidal, bug 598221) * avoids running out of disk space when building using a tmpfs (thanks to Kalev Lember). It also doesn't report any failing packages that have subsequently been built and published in koji's rawhide since 06-01. That should cut down on the "but I just fixed that!" responses from now on. I manually rebuilt eclipse-emf, java-1.6.0-openjdk, qt, seamonkey, and webkitgtk which had failed due to disk space (oddly, both with and without using large tmpfs). They _may_ still appear below for you, but you can ignore them. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 61 Open Bugs which now build, and can be marked CLOSED RAWHIDE: apanov-heuristica-fonts: [u'565136'] audex: [u'555453'] btrfs-progs: [u'565112'] cachefilesd: [u'565135'] cas: [u'564700'] clisp: [u'539088'] clutter-gtk: [u'539122'] collectd: [u'564943'] comedilib: [u'555459'] cuetools: [u'538987'] dbxml-perl: [u'555452'] dbxml: [u'555494'] doodle: [u'564678'] epydoc: [u'565627'] esc: [u'555411'] fedora-security-guide-en-US: [u'538934'] fence-virt: [u'565111'] florence: [u'564675'] gdm: [u'539144'] ghostscript-fonts: [u'565206'] gnome-netstatus: [u'564852'] griv: [u'565081'] harminv: [u'565036'] hdf: [u'538896'] healpy: [u'564726'] hulahop: [u'564792'] itpp: [u'565156'] keepassx: [u'539011'] krb5-auth-dialog: [u'555498'] kst: [u'539056'] libvirt-qpid: [u'565139'] lordsawar: [u'564950'] monodevelop-debugger-mdb: [u'539051'] mpqc: [u'565030'] openwsman: [u'564916'] paperbox: [u'564997'] perl-HTML-FormFu-Model-DBIC: [u'564664'] perl-MooseX-Role-Cmd: [u'564789'] plexus-appserver: [u'564825'] plexus-bsh-factory: [u'564981'] plexus-xmlrpc: [u'564880'] pyclutter: [u'565185'] pyscript: [u'564816'] python-nss: [u'565044'] qemu: [u'564683'] razertool: [u'564813'] rpm: [u'565223'] scitools: [u'564781'] showimg: [u'539025'] springlobby: [u'564795'] subversion-api-docs: [u'538966'] synce-kde: [u'539195'] synce-trayicon: [u'564881'] tasque: [u'539146'] tex-musixtex: [u'564757'] UnihanDb: [u'538948'] virt-ctrl: [u'538891'] warzone2100: [u'565184'] xca: [u'565073'] xen: [u'565063'] zfs-fuse: [u'565076'] Total packages: 9309 Number failed to build: 353 Number expected to fail due to ExclusiveArch or ExcludeArch: 29 Leaving: 324 Of those expected to have worked... Without a bug filed: 214 -- AcetoneISO2-2.2.1-2.fc13 (build/make) spot Django-1.2.1-1.fc14 (build/make) smilner,dmalcolm,salimma,smilner GtkAda-2.14.0-4.fc13 (build/make) gemi,rombobeorn OpenGTL-0.9.13-1.fc13 (build/make) rdieter PyQt4-4.7.3-2.fc14 (build/make) rdieter,dmalcolm,than PythonCard-0.8.2-5.fc12 (build/make) mmahut R-BSgenome-1.14.2-1.fc12 (build/make) pingou R-BSgenome.Celegans.UCSC.ce2-1.3.16-1.fc13 (build/make) pingou R-Biostrings-2.14.12-1.fc14 (build/make) pingou R-IRanges-1.4.16-1.fc14 (build/make) pingou R-RScaLAPACK-0.6.1-2.fc14 (build/make) spot TnL-07-12.fc13 (build/make) jwrdegoede amarok-2.3.0.90-1.fc14 (build/make) rdieter,kaboon,rdieter,thomasj,tuxbrewr apache-commons-exec-1.0.1-2.fc13 (build/make) melmorabity atlas-3.8.3-15.fc13 (build/make) deji,deji autofs-5.0.5-27.fc14 (build/make) jmoyer,iankent bibletime-2.5-3.fc14 (build/make) anderson,deji blokkal-0.1.2-1.fc13.1 (build/make) thomasj bsf-2.4.0-5.fc14 (build/make) pcheung buildbot-0.7.12-1.fc13 (build/make) giallu,dmalcolm,smilner cegui-0.6.2-5.fc13 (build/make) jwrdegoede,atorkhov,bruno cellwriter-1.3.4-3.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb cfdg-2.2.1-1.fc13 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb cfdg-fe-0.1-4.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb chipmunk-4.1.0-8.fc13 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb choqok-0.9.55-15.fc14 (build/make) tejas chromium-bsu-0.9.14-6.fc13 (build/make) jwrdegoede classpathx-jaf-1.0-15.1.fc12 (build/make) devrim,dwalluck compat-libgda-3.1.2-3.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) orphan cvc3-2.2-1.fc13 (build/make) jjames cylindrix-1.0-11.fc12 (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) limb dates-0.4.11-3.fc14 (build/make) pbrobinson diveintopython-5.4-17.fc13 (build/make) julian eclipse-3.5.2-4.fc14 (build/make) overholt,akurtakov,oliver,overholt eclipse-mylyn-3.3.2-4.fc14 (build/make) overholt,akurtakov,mbooth eina-0.9.1-1.fc13 (build/make) sundaram emeril
Re: JBoss stalled (was Re: status of some packages ??)
On Thu, 2010-06-03 at 16:33 +0200, Xose Vazquez Perez wrote: > > JBoss is stalled because it depends on a package with: > > - incompatible license > - six years old > - dead upstream > How is this different from what is on the bug report ? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
JBoss stalled (was Re: status of some packages ??)
On 06/01/2010 05:09 PM, Tom spot Callaway wrote: > On 05/29/2010 07:25 PM, Xose Vazquez Perez wrote: >> JBoss[1] is still a *big* deficit. Potential for f14/15 ? > > I'm pretty sure JBoss is still a no-go because of poor licensing, > specifically: > > https://bugzilla.redhat.com/show_bug.cgi?id=479598 That is a nonsense. JBoss is stalled because it depends on a package with: - incompatible license - six years old - dead upstream :-? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: excluding bugzilla email when you are the assignee
On Thu, 2010-06-03 at 15:10 +0100, Richard W.M. Jones wrote: > On Thu, Jun 03, 2010 at 10:05:49AM -0400, Jon Masters wrote: > > On Thu, 2010-06-03 at 09:52 -0400, Chuck Anderson wrote: > > > Is it reasonable for a package owner to exclude themselves on bugzilla > > > email when they are the assignee of the bug? How would they know when > > > a new bug is reported, or when new comments are added? > > > > It can be reasonable-ish. I use whining alerts in Bugzilla to get daily > > summaries of bug statistics, split out between RHEL and Fedora. Every > > morning at 5am, I get about 5 different emails from BZ with a series of > > different queries showing current bugs, ones I was added to CC within 3 > > days, ones recently set NEEDINFO to me, etc. It's a lot more usable than > > wading through the 5,000 BZ emails I get each week. > > Be interesting if you could write up how you do this some time. Sure. I planned to write up something internally (because of some additional features available for RHEL development), but I can also put something on the Fedora wiki sometime too. I'm glad we do whining email support because many BZs blanketly disable "Administration" feature to non-admin users (e.g. other distributions and upstream BZs). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 3 June 2010 14:26, Daniel J Walsh wrote: > Did you the xsane call that is causing login programs (gdm) to try to > communicate with cups, causing AVC errors? This should be fixed in both f13 (via updates-testing) and now rawhide. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 3 June 2010 14:41, Przemek Klosowski wrote: > gcm-prefs SIGSEGVs for me. My system is dual-monitor DELL F12 freshly > upgraded to f13, with gnome-color-management installed after upgrade It looks like the GConf schema failed to be installed correctly. If you grab the gnome-color-manager from updates-testing it should workaround the bug. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: excluding bugzilla email when you are the assignee
On Thu, Jun 03, 2010 at 10:05:49AM -0400, Jon Masters wrote: > On Thu, 2010-06-03 at 09:52 -0400, Chuck Anderson wrote: > > Is it reasonable for a package owner to exclude themselves on bugzilla > > email when they are the assignee of the bug? How would they know when > > a new bug is reported, or when new comments are added? > > It can be reasonable-ish. I use whining alerts in Bugzilla to get daily > summaries of bug statistics, split out between RHEL and Fedora. Every > morning at 5am, I get about 5 different emails from BZ with a series of > different queries showing current bugs, ones I was added to CC within 3 > days, ones recently set NEEDINFO to me, etc. It's a lot more usable than > wading through the 5,000 BZ emails I get each week. Be interesting if you could write up how you do this some time. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: excluding bugzilla email when you are the assignee
On Thu, 2010-06-03 at 09:52 -0400, Chuck Anderson wrote: > Is it reasonable for a package owner to exclude themselves on bugzilla > email when they are the assignee of the bug? How would they know when > a new bug is reported, or when new comments are added? It can be reasonable-ish. I use whining alerts in Bugzilla to get daily summaries of bug statistics, split out between RHEL and Fedora. Every morning at 5am, I get about 5 different emails from BZ with a series of different queries showing current bugs, ones I was added to CC within 3 days, ones recently set NEEDINFO to me, etc. It's a lot more usable than wading through the 5,000 BZ emails I get each week. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
excluding bugzilla email when you are the assignee
Is it reasonable for a package owner to exclude themselves on bugzilla email when they are the assignee of the bug? How would they know when a new bug is reported, or when new comments are added? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
gcm-prefs SIGSEGVs for me. My system is dual-monitor DELL F12 freshly upgraded to f13, with gnome-color-management installed after upgrade https://bugzilla.redhat.com/show_bug.cgi?id=599543 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: timevariant GUI elements (Re: systemd (Was Re: tmpfs for strategic directories))
On Wed, Jun 02, 2010 at 11:25:56AM +0200, Roberto Ragusa wrote: > Kevin Kofler wrote: > > Roberto Ragusa wrote: > >> In recent times some stupid (IMHO) ideas have been adopted in Linux > >> just to copy what others do. Just as examples: the control of desktop > >> widgets in KDE4 (functional GUI elements modified by a mouse-over???), > > > > I only know of 2 plasmoids triggering actions on mouse-over: > > Sorry, I didn't manage to explain me well. > I'm referring to the vertical bar which popups at the left of right > of _every_ plasmoid. The thing with the close button and which you can > drag around to move the plasmoid. yes, found that also very confusing in the beginning. You realise that you can get rid of those when you lock the widgets (there is a shortcut for that). Locking the widgets has other disadvantages, like you cant drag anything onto desktop so you need to remember to unlock it. Which is the biggest problem I have with this feature. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 03/06/10 14:26, Daniel J Walsh wrote: --slim-- >>> >>> Richard. >> >> Got the expected results from: >> http://fedoraproject.org/wiki/QA:Testcase_colormanagement_apply_profile >> >> Do I need to update that anywhere? >> > Did you the xsane call that is causing login programs (gdm) to try to > communicate with cups, causing AVC errors? I'm on slim with Rawhide. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 06/03/2010 05:48 AM, Frank Murphy wrote: > On 03/06/10 10:37, Richard Hughes wrote: >> On 3 June 2010 10:26, Frank Murphy wrote: >>> Is it ok to test on an XFCE? >>> it only pulls in 4pkgs. >> >> I assume so, I've never tested. If it fails, it would be good to know >> what other runtime packages we need. >> >> Richard. > > Got the expected results from: > http://fedoraproject.org/wiki/QA:Testcase_colormanagement_apply_profile > > Do I need to update that anywhere? > Did you the xsane call that is causing login programs (gdm) to try to communicate with cups, causing AVC errors? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: new upstream tracker (linuxtesting.org)
On 06/03/2010 09:04 AM, Andrey Ponomarenko wrote: > Hello, I'm from ISPRAS and we have created an experimental system for > monitoring and analyzing of upstream libraries development. It may be > helpful for analyzing risks of library updating in the distribution. > The web page of upstream-tracker is: > > http://linuxtesting.org/upstream-tracker/ > > It now includes ABI changes analysis and "shallow"-quality API test results > for > several versions of 70 popular open source libraries. > > Any bugs or feature requests are welcome. Thanks. > Feature Request: ability to add other libraries to the system for tracking. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
new upstream tracker (linuxtesting.org)
Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of library updating in the distribution. The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and "shallow"-quality API test results for several versions of 70 popular open source libraries. Any bugs or feature requests are welcome. Thanks. -- Andrey Ponomarenko Linux Verification Center, ISPRAS web:http://www.linuxtesting.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fedora-r-devel-list] R 2.11.1 in Fedora Updates Testing
R 2.11.1 is built now for Fedora and EPEL. It is in "updates-testing" (or it will be within the next 24 hours). It will likely be the last R update for Fedora 11. In accordance with the new policies on Fedora Updates, these new packages will not be pushed as official updates until they either receive positive testing from users, or sit in updates-testing for two weeks. You can help us test these packages, and move them forward. Here's how: 1. Go to the Fedora Updates web application (its real name is "Bodhi"): https://admin.fedoraproject.org/updates/ Once you're there, click the login blue box at the top left, and login with your Fedora Account. If you don't have a Fedora Account, you can skip this step. 2. Click on the link for the Fedora R test update that matches your release: Fedora 11: https://admin.fedoraproject.org/updates/rpy-2.0.8-3.fc11,R-2.11.1-1.fc11 Fedora 12: https://admin.fedoraproject.org/updates/rpy-2.0.8-3.fc12,R-2.11.1-1.fc12 Fedora 13: https://admin.fedoraproject.org/updates/rpy-2.0.8-4.fc13,R-2.11.1-1.fc13 EPEL-4 (RHEL-4): https://admin.fedoraproject.org/updates/R-2.11.1-1.el4 EPEL-5 (RHEL-5): https://admin.fedoraproject.org/updates/R-2.11.1-1.el5 3. Now, on your Fedora (or RHEL) system, run this command (as root, or with root privs) to install the test update: yum --enablerepo=updates-testing update R That should update R to the test update (if you don't want the full R suite, you can replace "R" in that string with "R-core"). 4. Test it! Make sure it does all the things you would expect it to. 5. Go back to the web page for the R update (step 2), and at the bottom, click "Add a comment >>" (If you didn't login, it will ask you for an email address and make you complete a captcha to make sure you are a unique individual.) In that text box which opens up, write a little bit about the testing you did and if it works okay for you or not. Then (this is the important part), click the "Works for me" or "Does not work" radio button below it, and click the Add Comment button. 6. That's it! If it worked, you've given that update a +1 karma vote. (If it didn't work, you've given it a -1 karma vote). Now, if three people give a +1, and the package update gets to +3, the Fedora Update system will automatically move the update from testing to a real update, and everyone will get it. Thanks in advance, ~spot, Fedora/EPEL R maintainer ___ r-devel mailing list r-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/r-devel
[Test-Announce] Please help test 389 Directory Server 1.2.6 Alpha 4
The 389 team is pleased to announce the availability of Alpha 4 of version 1.2.6. This release contains a new replication session API, auto DN index upgrade, and several bug fixes. ***We need your help! Please help us test this software.*** It is an Alpha release, so it may have a few glitches, but it has been tested for regressions and for new feature bugs. The Fedora system strongly encourages packages to be in Testing until verified and pushed to Stable. If we don't get any feedback while the packages are in Testing, the packages will remain in limbo, or get pushed to Stable. The more testing we get, the faster we can release these packages to Stable. See the Release Notes for information about how to provide testing feedback (or just send an email to 389-us...@lists.fedoraproject.org). The packages that need testing are: * 389-ds-base-1.2.6.a4 - 389-ds-base * 389-admin-1.1.11.a4 - 389-admin There are some new console/java packages too, and there is a new version of the 389-ds "meta" package - 1.2.1 * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download === New features === * Replication Session Hooks - http://port389.org/wiki/Replication_Session_Hooks * Upgrade to new DN format - http://port389.org/wiki/Upgrade_to_New_DN_Format === Bugs Fixed === This release contains a couple of bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.6 release - https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0 ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100603 changes
Compose started at Thu Jun 3 08:15:05 UTC 2010 Broken deps for i386 -- almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Attachment::PatchReader) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search::Quicksearch) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Extension) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Keyword) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Field::Choice) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::FlagType) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Flag) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Whine::Query) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Requirements) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Mailer) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::JobQueue) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Constants) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::JobQueue::Runner) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Error) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Update) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Milestone) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Field) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Component) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Comment) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Verify::Stack) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Token) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server::JSONRPC) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Version) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Attachment) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::CPAN) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Status) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Hook) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Filesystem) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::WebService::Server::XMLRPC) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::User) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Template) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::BugMail) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Chart) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Localconfig) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Product) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Whine::Schedule) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::CGI) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Extension::Example::Util) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Install) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Migrate) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Bug) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Classification) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Login::Stack) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB::Schema::Mysql) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Group) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Config::Common) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Series) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::User::Setting) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Config) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Search::Saved) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Constants) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::Auth::Persist::Cookie) bugzilla-3.6-1.fc14.noarch requires perl(Bugzilla::DB::Schema) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::Install::Filesystem) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::Util) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::User) bugzilla-contrib-3.6-1.fc14.noarch requires perl(Bugzilla::DB) bugzilla-contrib-3.6-1.fc14.noarch
Re: suggestion: rescue boot extension
On Wed, Jun 02, 2010 at 04:04:18PM -0500, Michael Cronenworth wrote: > Eric Sandeen wrote: > > Is it better to have a separate volume for this, or to just have a sort > > of rescue initramfs ...? > > > > Seems like the latter is more flexible but then I'm no boot process wizard. > > Good suggestion. > > Another one: What about LVM snapshots? and/or btrfs snapshots? > > Either way would be less wasteful than a whole partition that would be > obsolete in a few weeks and may or may not have to deal with byte > growing pains if the initial size is too small years down the road. I would like to note here that Windows Vista and later "solves" this problem by stuffing a multi-megabyte rescue binary into the sectors before the first partition. One consequence of this is that the first partition starts at some ridiculously large offset, and another is that if you don't copy this "hidden" unpartitioned data between the boot sector and the first partition, then you can end up with an unbootable Windows system. I found this out the hard way when writing virt-resize. But at least it doesn't require a precious primary partition :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 03/06/10 10:37, Richard Hughes wrote: > On 3 June 2010 10:26, Frank Murphy wrote: >> Is it ok to test on an XFCE? >> it only pulls in 4pkgs. > > I assume so, I've never tested. If it fails, it would be good to know > what other runtime packages we need. > > Richard. Got the expected results from: http://fedoraproject.org/wiki/QA:Testcase_colormanagement_apply_profile Do I need to update that anywhere? -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 3 June 2010 10:26, Frank Murphy wrote: > Is it ok to test on an XFCE? > it only pulls in 4pkgs. I assume so, I've never tested. If it fails, it would be good to know what other runtime packages we need. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning/reassigning pcre, sharutils, html2ps
Hello, I wrote: On Thu, Jun 03, 2010 at 11:15:03AM +0200, Stepan Kasal wrote: > Hello, > I'm orphaning the following packages. > Petr Pisar (ppisar) is interested in taking them, but according to > the formal processes we are advertising this anyway. > > pcre, html2ps, sharutils, in rawhide and Fedora 12, 13 > > Petr Pisar obviously, I made a typo in the signature. I meant to sign the mail with my own name: "Stepan Kasal" Stepan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 03/06/10 10:16, Rahul Sundaram wrote: > On 06/03/2010 02:39 PM, Richard Hughes wrote: >> I've just built a new gnome-color-manager release for rawhide: > > If anyone is wondering what to test, refer to the test cases at > > http://fedoraproject.org/wiki/Test_Day:2010-02-18_Color_management > > Rahul Is it ok to test on an XFCE? it only pulls in 4pkgs. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning/reassigning pcre, sharutils, html2ps
Hello, I'm orphaning the following packages. Petr Pisar (ppisar) is interested in taking them, but according to the formal processes we are advertising this anyway. pcre, html2ps, sharutils, in rawhide and Fedora 12, 13 Petr Pisar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New gnome-color-manager release in rawhide
On 06/03/2010 02:39 PM, Richard Hughes wrote: > I've just built a new gnome-color-manager release for rawhide: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2226766 > > It's pretty different from the version in F13, as it is: > > * Ported to GSettings > * Ported to GDBus > * Now supporting multiple profiles for devices > * Now supporting virtual devices > > With all this new code, I would appreciate if people could try it out > and send me feedback. Thanks. > If anyone is wondering what to test, refer to the test cases at http://fedoraproject.org/wiki/Test_Day:2010-02-18_Color_management Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New gnome-color-manager release in rawhide
I've just built a new gnome-color-manager release for rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2226766 It's pretty different from the version in F13, as it is: * Ported to GSettings * Ported to GDBus * Now supporting multiple profiles for devices * Now supporting virtual devices With all this new code, I would appreciate if people could try it out and send me feedback. Thanks. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On 06/02/10 22:33, Jon Masters wrote: > A recovery initramfs could be used. It could just basically be the > rescue mode anaconda bits in one image shoved in place to start. That would be a good idea anyway: Zap the two-stage rescue system loading. Just have a kernel + initramfs. That would make booting a rescue system easier as the (todays) small initramfs doesn't need some way to grap the second stage from somewhere. Having a rescue system in /boot would be trivial then: just copy kernel + rescue.initramfs from the install.iso to /boot and add a grub menu entry -> done. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Wed, Jun 2, 2010 at 23:52, Adam Williamson wrote: > The obvious response here is 'so, package CruiseControl too!' If you > can't package CruiseControl, then you shouldn't package phpUnderControl; > it's frowned upon / not allowed (I can never remember which) to package > something which requires something that can't go into Fedora for some > reason. OK, that is what I thought. I might have a look at packaging CruiseControl in the future, but I can't really see having a CruiseControl and a phpUnderControlCruiseControl, because that would be frowned upon even by me :-) I also don't really want to package CruiceControl, because it is Java and I just don't understand it enough. It seems to be very specific where you place your data files. > For whatever reason, We Don't Like Metapackages and the 'recommended' > way to do it is with a package group. I've never seen a particularly > coherent reason given for this, but never mind. Some packagers _have_ > done metapackages, and none of them have been shot yet. Just sayin'. It would be good to have this in the packaging guidelines somewhere. All I could find were random threads in mailing list, none of them with an official conclusion as far as I could seen. I guess I will leave both packages for now and create my own repository with just those two and see how it is working out. Cheers, Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
