Re: Help to solve a possible circular Requires:
On 12/03/2010 05:20 PM, James Antill wrote: > On Fri, 2010-12-03 at 10:24 +0100, Fabio M. Di Nitto wrote: >> Hi all, >> >> I am seeking some help here to solve a possible $subject. I have been >> trying to find a simple alternate solution, but I just can´t see it or >> it´s not obvious to me. >> >> This is the situation: >> >> srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. >> >> due to upstream split: >> >> srpm foo 1.1 now ships only bar rpm without the daemon. >> >> srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and >> baz-something that contains the bar´s daemon from 1.0. >> >> In order to avoid upgrade issues, we need to make sure that bar 1.1 will >> pull in baz-something 1.1 (to retain functionality), at the same time >> baz-something requires bar 1.1 to operate at all. >> >> There is no requirement for a strictly versioned Requires: on both >> sides. baz-something Requires: bar >= 1.1, and bar Requires: >> baz-something (no version need since it´s a new rpm). > > The above reads more complicated than I think it is. I assume you have > two problems: > > 1. When moving from foo-1.0 => foo-1.1 and baz-1.1, you have a package > split ... this implies using versioned Obsoletes (<= 1.0) on bar from > baz-something. > > 2. In baz-something-1.1 you have a normal requires on bar-1.1 ... so > just add a versioned (>= 1.1) require. > Hey guys, thanks for the hint in the right direction! Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On Wed, Dec 8, 2010 at 2:39 AM, BJ Dierkes wrote: > Hello all, > Just to be clear... PyPI has an implied "one source" requirement embedded in its repository structure and you have optimized your upstream project release structure to meet PyPI's implied requirement. Question does PyPI handle dependency tracking? If I easy_install cement.devtools does cement get installed automagically? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
Dne 7.12.2010 22:30, Richard W.M. Jones napsal(a): > The issue we face with libvirt is it needs to be able to add extra > rules to the existing firewall, and have those rules added in the > right place, and preserved across firewall restarts, reboots and so > on. There are other services which need to add rules too (see cups > mentioned previously in this thread). a) libvirt somehow manages to work just fine on my computer even with my script, so why to change it? b) I have still https://www.grc.com/unpnp/unpnp.htm on my mind. Aren't we going in the same direction, so that we will need stuff like this? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python Packages + Multiple Sources
Hello all, I've been trying to figure the best way to handle this situation for the better part of two days... and so I figured I'd bring it on list and hopefully I can clarify this all. I have several projects that relate to this question, however I will reference 'cement' as an example. Basically, cement is a CLI Application Framework for Python [1]. I am also the upstream maintainer, so I have the ability to modify upstream or downstream. Currently, cement consists of three separate sources: cement cement.devtools cement.test All three pieces follow each release meaning, when 0.8.12 (current stable) was released... new tarbals were released for all three. The reason for separate tarbals is primarily for maintaining releases via PyPi [2]. I need all three pieces to be separate so that users can 'easy_install cement', without pulling in a dozen dependencies for cement.devtools or cement.test. I don't have the luxury of creating 'subpackages' in PyPi, so I have to break up the sources. That said, in the Fedora world... it is a bit excessive to maintain three separate RPM packages (for all Fedora/EPEL releases)... when all three packages are related and could easily role up under a single package, with subpackages. I have the same issue with 'rosendale' [3] which is/will be a set of plugins for applications built on cement. The same situation exists, in PyPi I need separate source tarbals because users need to be able to 'easy_install rosendale.some_plugin'. In Fedora world, maintaining a single package set for 'rosendale' would be ideal and make more sense because I can do sub packages for each plugin and not have to maintain 20 different package sets. What I would like to see is if this type of situation would lend itself to making an exception to the FPG regarding 'one source per package'. I assume the section 'Bundling of multiple projects' [4] is relevant, though it is pretty vague. I guess what I'm looking for is for someone with more time in the community to give some advice on this situation. Ideally, I would like to be able to maintain a single package set for say 'cement', but with Source0 (cement), Source1 (cement.devtools), Source2 (cement.test). Or would it be recommended to have a separate tarbal like 'cement-all-0.8.12.tar.gz' which would include all parts of the project, and use that as Source0? Thanks for your time. References: [1] http://builtoncement.org [2] http://pypi.python.org [3]http://builtoncement.org/rosendale/1.0/doc/ [4] http://fedoraproject.org/wiki/PackagingGuidelines#Bundling_of_multiple_projects --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, Dec 06, 2010 at 11:01:20PM -0600, Matt Domsch wrote: > I would like to propose blocking packages at the F15 alpha compose > point if they have not resolved their FTBFS from F14 or earlier. The > lists may be broken down by when they last did build. With 3 > exceptions, these 110 bugs are all still in NEW state as well, so they > haven't had much maintainer love in quite some time (6-18 months). > > I trust module-init-tools will get resolved with an impending upstream > release. Not like that can go unfixed forever. :-) > > > Last built on Fedora 12 (52): And if I resolve all the packages that depend on these 52, I wind up with a few more (136, but this counts some twice, and is binary packages, not source package, so not quite as many in reality): beldi-0:0.9.25-2.fc12.x86_64 celestia-0:1.5.1-2.fc12.x86_64 chm2pdf-0:0.9.1-8.fc14.noarch classpathx-jaf-0:1.0-15.1.fc12.x86_64 classpathx-jaf-javadoc-0:1.0-15.1.fc12.x86_64 cone-0:0.78-3.fc12.x86_64 cone-devel-0:0.78-3.fc12.i686 cone-devel-0:0.78-3.fc12.x86_64 cone-doc-0:0.78-3.fc12.x86_64 coq-0:8.2pl1-1.fc12.x86_64 coq-coqide-0:8.2pl1-1.fc12.x86_64 coq-doc-0:8.2pl1-1.fc12.x86_64 coq-emacs-0:8.2pl1-1.fc12.x86_64 cpm-0:0.23-0.3.beta.fc12.x86_64 drgeo-0:1.1.0-16.fc12.x86_64 drgeo-doc-0:1.6-11.fc12.noarch dumbster-0:1.6-9.fc12.noarch gdmap-0:0.8.1-6.fc12.x86_64 genius-0:1.0.7-1.fc12.x86_64 genius-devel-0:1.0.7-1.fc12.i686 genius-devel-0:1.0.7-1.fc12.x86_64 gnokii-0:0.6.28-1.fc12.i686 gnokii-0:0.6.28-1.fc12.x86_64 gnokii-devel-0:0.6.28-1.fc12.i686 gnokii-devel-0:0.6.28-1.fc12.x86_64 gnokii-smsd-0:0.6.28-1.fc12.x86_64 gnokii-smsd-mysql-0:0.6.28-1.fc12.x86_64 gnokii-smsd-pgsql-0:0.6.28-1.fc12.x86_64 gnome-do-plugins-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-banshee-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-bibtex-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-clawsmail-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-eog-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-epiphany-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-evolution-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-firefox-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-flickr-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-pidgin-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-rhythmbox-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-tasque-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-thunderbird-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-tomboy-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-vinagre-0:0.8.2-1.fc12.x86_64 gnome-genius-0:1.0.7-1.fc12.x86_64 gnome-phone-manager-0:0.65-8.fc14.x86_64 gnome-phone-manager-telepathy-0:0.65-8.fc14.x86_64 gpsk31-0:0.5-4.fc12.x86_64 gshutdown-0:0.2-6.fc12.x86_64 gsql-0:0.2.1-4.fc12.i686 gsql-0:0.2.1-4.fc12.x86_64 gsql-devel-0:0.2.1-4.fc12.i686 gsql-devel-0:0.2.1-4.fc12.x86_64 gsql-engine-mysql-0:0.2.1-4.fc12.x86_64 gsql-plugins-0:0.2.1-4.fc12.x86_64 gtkglextmm-0:1.2.0-10.fc12.i686 gtkglextmm-0:1.2.0-10.fc12.x86_64 gtkglextmm-devel-0:1.2.0-10.fc12.i686 gtkglextmm-devel-0:1.2.0-10.fc12.x86_64 guile-gnome-platform-0:2.16.1-4.fc12.i686 guile-gnome-platform-0:2.16.1-4.fc12.x86_64 guile-gnome-platform-devel-0:2.16.1-4.fc12.i686 guile-gnome-platform-devel-0:2.16.1-4.fc12.x86_64 gwave-0:2-18.20090213snap.fc13.x86_64 htmldoc-0:1.8.27-13.fc12.x86_64 imgtarget-0:0.1.4-4.fc12.x86_64 ipa-server-0:1.2.2-4.fc15.x86_64 jack-audio-connection-kit-0:1.9.6-2.fc15.i686 jack-audio-connection-kit-0:1.9.6-2.fc15.x86_64 javatar-0:2.5-2.fc13.x86_64 kanatest-0:0.4.8-3.fc12.x86_64 kdetv-0:0.8.9-13.fc12.i686 kdetv-0:0.8.9-13.fc12.x86_64 koji-web-0:1.4.0-4.fc15.noarch kpolynome-0:0.1.2-15.fc12.x86_64 ktechlab-0:0.3.70-3.20090304svn.fc12.x86_64 libctl-0:3.0.2-10.fc12.i686 libctl-0:3.0.2-10.fc12.x86_64 libctl-devel-0:3.0.2-10.fc12.i686 libctl-devel-0:3.0.2-10.fc12.x86_64 libfreebob-0:1.0.11-6.fc12.i686 libfreebob-0:1.0.11-6.fc12.x86_64 libfreebob-devel-0:1.0.11-6.fc12.i686 libfreebob-devel-0:1.0.11-6.fc12.x86_64 libopensync-plugin-gnokii-1:0.22-4.fc12.x86_64 libopensync-plugin-kdepim-1:0.22-6.fc12.x86_64 manaworld-0:0.0.29.1-2.fc12.x86_64 manaworld-music-0:0.0.20-4.fc12.noarch maven-embedder-0:2.0.4-6.fc12.noarch maven-embedder-javadoc-0:2.0.4-6.fc12.noarch maven-plugin-cobertura-0:2.3-3.fc12.noarch maven-plugin-cobertura-javadoc-0:2.3-3.fc12.noarch mingw32-gtkmm24-0:2.19.6-1.fc14.noarch mingw32-libglademm24-0:2.6.7-8.fc12.noarch mingw32-pangomm-0:2.26.0-1.fc12.noarch mingw32-plotmm-0:0.1.2-4.fc12.noarch mod_auth_kerb-0:5.4-5.fc12.x86_64 multiget-0:1.2.0-7.fc12.x86_64 netgo-0:0.5-12.fc12.x86_64 notecase-0:1.6.1-6.fc12.x86_64 oorexx-0:4.0.0-2.4801.fc12.x86_64 oorexx-devel-0:4.0.0-2.4801.fc12.i686 oorexx-devel-0:4.0.0-2.4801.fc12.x86_64 oorexx-docs-0:4.0.0-2.4801.fc12.x86_64 oorexx-libs-0:4.0.0-2.4801.fc12.i686 oorexx-libs-0:4.0.0-2.4801.fc12.x86_64 openvas-client-0:3.0.0-8.fc14.x86_64 ovirt-server-0:0.100-5.fc15.noarch petitboot-0:0.2-4.fc12.x86_64 pigment-0:0.3.17-3.fc12.i686 pigment-0:0.3.17-3.fc12.x86_64 pigment-devel-0:0.3.17-3.fc12.i686 pigment-devel-0:0.3.17-3.fc12.x86_64 pigment-python-0:0.3.12-3.fc14.x86_64 postgresql-pgpool-ha-0:1.1.0-8.fc12.noarch python-visual-0:5.40-2.
Bug 618349 : Can I get some input please?
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=618349 The bug is blocking my ability, or at least my willingness to upgrade to F14. I would appreciate some assistance so that I can finally do the upgrade. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, 08 Dec 2010 01:05:06 + Bastien Nocera wrote: ...snip... > > The > > lists may be broken down by when they last did build. With 3 > > exceptions, these 110 bugs are all still in NEW state as well, so > > they haven't had much maintainer love in quite some time (6-18 > > months). > > All the Fedora bugzilla bugs assigned to you, ever: > http://bit.ly/dTndTs > A whole 73. > > Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me: > http://bit.ly/gBtVRP > 810 bugs. > > When you deal with as many bugs as I (or some other people) do can you > take executive decisions on blocking packages in newer revisions. How about asking for help? Co-maintainers on packages that get lots of bugs? Have you considered training up some bugzappers to help triage your components? They could at least work on de-duping abrt reports. Lets try and get you help... > I bet most of those packages are still functional, and fail to build > due to some minor changes in the build system, or breakage in > dependency libraries. The ones he's refering to have not built since f12. It's a wonder if they work at all. ;) > > > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) > > dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'63 NEW'] > > (build/make) dcbw,choeger,huzaifas,steve > > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw > > And I'm guessing this list didn't get read by humans either. You are refering to the wrong list. That was a list of all things that don't currently build right now in rawhide. The proposed block list was much smaller and contained things that have not been built since f12. > Feel free to insert here complaints about how the Red Hat bugzilla is > slow, bad at reporting, and that abrt reports with missing > attachments, poor backtraces and no support for tools like GNOME > Bugzilla's simple-dup-finedr aren't helping us keep the bug count > down. I'm intrigued. Can we modify 'simple-dup-finder' to work on our bugzilla? Any docs or pointers to what it does? ...snip... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, 2010-12-06 at 23:01 -0600, Matt Domsch wrote: > I would like to propose blocking packages at the F15 alpha compose > point if they have not resolved their FTBFS from F14 or earlier. You better not. > The > lists may be broken down by when they last did build. With 3 > exceptions, these 110 bugs are all still in NEW state as well, so they > haven't had much maintainer love in quite some time (6-18 months). All the Fedora bugzilla bugs assigned to you, ever: http://bit.ly/dTndTs A whole 73. Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me: http://bit.ly/gBtVRP 810 bugs. When you deal with as many bugs as I (or some other people) do can you take executive decisions on blocking packages in newer revisions. I bet most of those packages are still functional, and fail to build due to some minor changes in the build system, or breakage in dependency libraries. > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) dcbw > NetworkManager-openvpn-0.8.1-1.fc14 [u'63 NEW'] (build/make) > dcbw,choeger,huzaifas,steve > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw And I'm guessing this list didn't get read by humans either. Feel free to insert here complaints about how the Red Hat bugzilla is slow, bad at reporting, and that abrt reports with missing attachments, poor backtraces and no support for tools like GNOME Bugzilla's simple-dup-finedr aren't helping us keep the bug count down. And I'll go back to fixing actual bugs encountered by people instead of random bot-driven bugs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? > Somethng I jsut thought of is whether package maintainers can create new branches in git by themselves. If the answer is still no, then we'd probably want to keep that information in pkgdb. If the answer is yes, then there's already the chance htat the branches could get out of sync. Another couple of issues are: 1) Statistics. People like to get statistics relating to packages in a release from pkgdb. We'd need to switch these around to somehow extract the information from git. 2) Bodhi work on a per-branch level. Storing critpath information in pkgdb pretty much means that we have to keep separate records for separate releases. So although I'd like to simplify things, it seems like there's lots of work to implement this but not a whole lot of benefit (other than making things less complex). -Toshio pgpVbmV6iYcyB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Mon, 2010-12-06 at 14:53 -0500, Bill Nottingham wrote: > > One thing is e.g notifications to users when some service/app requests > > to open a port. First version won't have network zones yet, but he and > > Dan Williams are working on that for the next generation which will then > > basically allow it to let the user decide once for each > > interface/connection what should happen with it and never be bothered > > with it afterwards. > > ... but this seems absolutely wrong. The last thing we want is to be > pestering the user with information they may not understand, and are not > fully capable of acting on. Take the constant complaints about > SETroubleshoot, or the constant mocking of Windows Vista's security popups, > for example. Actually, this is something that Desktop people can live with, as long as the desktop has the final word on whether or not to display the questions and how to present them (but that would allow us to answer the simple questions of "are you at home" and "do you have want share your dubious music/fleshy moving pictures when at the internet cafe"). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 rawhide: No CPU frequency scaling anymore?
On Fri, 2010-11-26 at 10:16 -0300, Horst H. von Brand wrote: > > It used to say there was none; after updating gnome-settings-daemon > to > 2.91.4-1.fc15.x86_64 (which prevented Gnome fromn starting) and > downgrading back to 2.91.3-1.fc15.x86_64 it works (?!). Very highly unlikely to actually be related. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 12/03/2010 04:09 PM, Kevin Kofler wrote: > Adam Williamson wrote: >> We're working on this. It won't always be practical, however; in the >> current case, for example, you need specific hardware to test mdadm. > > Uh, this is md, not dm, you don't need very special HARDWARE (basically only > 2 HDDs, which do not even have to be identical, and you might even get away > with only 1 for testing, with absymal performance of course), you do need a > special setup though, which means repartitioning, and so isn't practical to > test on a production machine which isn't already set up that way. > > Kevin Kofler > For non-boot devices, loopback works. You only need the hardware if you are testing boot time capabilities (which, admittedly, is the far more important aspect of testing for this package). -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On 12/07/2010 02:25 PM, Till Maas wrote: > To properly display the state of the package in PackageDB. E.g. if a > package has different owners in different releases, it is more clear who > is responsible. E.g. sometimes packages are faded out from Fedora and > therefore orphaned in devel, but not in the stable releases. If there is > only one Owner for all Fedora releases, this cannot be modeled. It > might also happen that a package was orphaned for all releases but is > only unorphaned for newer ones like devel. And I guess it might also > happen that maintainership is passed for packages only for e.g. devel > but not the stable releases from one maintainer to another. > But what practical purpose does this serve? If bug is filed, the right person will be assigned or on the CC list. If email is sent to -ow...@fedoraproject.org then the right person would get the email. As for orphaning that's an interesting thing to think about. As for maintainership passing, is there any practical reason to have different maintainers per branch? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 658976] CVE-2010-2761 CVE-2010-4410 perl-CGI: multiple vulnerabilities via a crafted URL
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=658976 Vincent Danen changed: What|Removed |Added Summary|CVE-2010-2761 CVE-2010-4410 |CVE-2010-2761 CVE-2010-4410 | perl-CGI: multiple | perl-CGI: multiple |vulnerabilites via a|vulnerabilities via a |crafted URL |crafted URL -- 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
[Bug 658976] CVE-2010-2761 CVE-2010-4410 perl-CGI: multiple vulnerabilites via a crafted URL
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=658976 Vincent Danen changed: What|Removed |Added Summary|CVE-2010-2761 perl-CGI: |CVE-2010-2761 CVE-2010-4410 |CRLF injection | perl-CGI: multiple |vulnerability via a crafted |vulnerabilites via a |URL |crafted URL Alias||CVE-2010-4410 --- Comment #4 from Vincent Danen 2010-12-07 17:26:40 EST --- Ahhh... MITRE has this broken down as two issues, the second of which is here: Name: CVE-2010-4410 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4410 Assigned: 20101206 Reference: MLIST:[oss-security] 20101201 CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/1 Reference: MLIST:[oss-security] 20101201 Re: CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/3 Reference: MLIST:[oss-security] 20101201 Re: CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/2 Reference: CONFIRM: http://cpansearch.perl.org/src/LDS/CGI.pm-3.50/Changes Reference: CONFIRM: http://perl5.git.perl.org/perl.git/blobdiff/a0b94c2432b1d8c20653453a0f6970cb10f59aec..84601d63a7e34958da47dad1e61e27cb3bd467d1:/cpan/CGI/lib/CGI.pm Reference: CONFIRM: http://perl5.git.perl.org/perl.git/commit/84601d63a7e34958da47dad1e61e27cb3bd467d1 Reference: CONFIRM: http://www.nntp.perl.org/group/perl.perl5.changes/2010/11/msg28043.html Reference: BID:45145 Reference: URL: http://www.securityfocus.com/bid/45145 CRLF injection vulnerability in the header function in (1) CGI.pm before 3.50 and (2) Simple.pm in CGI::Simple 1.112 and earlier allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via vectors related to non-whitespace characters preceded by newline characters, a different vulnerability than CVE-2010-2761 and CVE-2010-3172. I'm noting both together as I believe they should have equal affects across affected products (i.e. one won't affect in a place where another doesn't). If that is incorrect, we may need to split this bug into two. -- 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: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 07, 2010 at 01:55:26PM -0800, Jesse Keating wrote: > On 12/07/2010 11:52 AM, Till Maas wrote: > > On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: > >> While I'm looking into the git setup and ACLs and all this, I have a > >> question. > >> > >> Is anybody seeing any real value of having different commit ACLs per > >> Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > >> real value in ACLs for f13, f14, devel, etc...? > > > > There should be at least a distinction between EOL releases and non EOL > > releases, e.g. someone having only commit access for F12 must not have > > commit access for F13+ currently, because usually only ownership / ACLs > > for current Fedora releases are up to date in PackageDB. > > I don't think the above really means we need different ACLs per branch, > just that if we did flatten then we need to flatten them as a union of > current active branches and not any EOL data. I agree. > > And there > > should still be a distinction in PackageDB for different > > (co)maintainer for different Fedora releases. > > For what reason? To properly display the state of the package in PackageDB. E.g. if a package has different owners in different releases, it is more clear who is responsible. E.g. sometimes packages are faded out from Fedora and therefore orphaned in devel, but not in the stable releases. If there is only one Owner for all Fedora releases, this cannot be modeled. It might also happen that a package was orphaned for all releases but is only unorphaned for newer ones like devel. And I guess it might also happen that maintainership is passed for packages only for e.g. devel but not the stable releases from one maintainer to another. Regards Till pgprYySejIsJ1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 658976] CVE-2010-2761 perl-CGI: CRLF injection vulnerability via a crafted URL
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=658976 Vincent Danen changed: What|Removed |Added Summary|perl-CGI: CRLF injection|CVE-2010-2761 perl-CGI: |vulnerability via a crafted |CRLF injection |URL |vulnerability via a crafted ||URL Alias||CVE-2010-2761 -- 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
[Bug 660960] FTBFS perl-CGI-Application-4.31-3.fc14
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=660960 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-12-07 17:18:18 --- Comment #7 from Emmanuel Seyman 2010-12-07 17:18:18 EST --- Fixed in 0:4.31-4 http://koji.fedoraproject.org/koji/taskinfo?taskID=2650204 -- 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
[Bug 658976] perl-CGI: CRLF injection vulnerability via a crafted URL
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=658976 Vincent Danen changed: What|Removed |Added CC||vda...@redhat.com Bug 658976 depends on bug 657950, which changed state. Bug 657950 Summary: perl-5.12.2/CGI-3.50 security update https://bugzilla.redhat.com/show_bug.cgi?id=657950 What|Old Value |New Value Status|MODIFIED|ON_QA Status|ON_QA |CLOSED Resolution||ERRATA --- Comment #3 from Vincent Danen 2010-12-07 17:17:01 EST --- This looks to have been assigned CVE-2010-2761: Name: CVE-2010-2761 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2761 Assigned: 20100714 Reference: MLIST:[oss-security] 20101201 CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/1 Reference: MLIST:[oss-security] 20101201 Re: CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/3 Reference: MLIST:[oss-security] 20101201 Re: CVE Request -- perl-CGI two ids, perl-CGI-Simple one id (CVE-2010-3172 already assigned for Bugzilla part) Reference: URL: http://openwall.com/lists/oss-security/2010/12/01/2 Reference: MISC: https://bugzilla.mozilla.org/show_bug.cgi?id=600464 Reference: CONFIRM: http://cpansearch.perl.org/src/LDS/CGI.pm-3.50/Changes Reference: CONFIRM: http://perl5.git.perl.org/perl.git/blobdiff/a0b94c2432b1d8c20653453a0f6970cb10f59aec..84601d63a7e34958da47dad1e61e27cb3bd467d1:/cpan/CGI/lib/CGI.pm Reference: CONFIRM: http://perl5.git.perl.org/perl.git/commit/84601d63a7e34958da47dad1e61e27cb3bd467d1 Reference: CONFIRM: http://www.nntp.perl.org/group/perl.perl5.changes/2010/11/msg28043.html Reference: CONFIRM: https://github.com/AndyA/CGI--Simple/commit/e4942b871a26c1317a175a91ebb7262eea59b380 The multipart_init function in (1) CGI.pm before 3.50 and (2) Simple.pm in CGI::Simple 1.112 and earlier uses a hardcoded value of the MIME boundary string in multipart/x-mixed-replace content, which allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via crafted input that contains this value, a different vulnerability than CVE-2010-3172. -- 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
[perl-CGI-Application] Add perl(CGI) and perl(Class::ISA) to BuildRequires Add perl default filter
commit 5220207659e6a65796b33ef02646a7b12aab5f99
Author: Emmanuel Seyman
Date: Tue Dec 7 23:07:15 2010 +0100
Add perl(CGI) and perl(Class::ISA) to BuildRequires
Add perl default filter
perl-CGI-Application.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Application.spec b/perl-CGI-Application.spec
index 3d43656..bc60b83 100644
--- a/perl-CGI-Application.spec
+++ b/perl-CGI-Application.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Application
Version:4.31
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Framework for building reusable web-applications
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,12 +8,16 @@ URL:http://search.cpan.org/dist/CGI-Application/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MARKSTOS/CGI-Application-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(CGI)
+BuildRequires: perl(Class::ISA)
BuildRequires: perl(HTML::Template)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
Requires: perl(HTML::Template)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+%{?perl_default_filter}
+
%description
CGI::Application is an Object-Oriented Perl module which implements an
Abstract Class. It is not intended that this package be instantiated
@@ -48,6 +52,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 07 2010 Emmanuel Seyman - 4.20-4
+- Add perl(CGI) and perl(Class::ISA) to BuildRequires
+- Add perl default filter
+
* Fri Apr 30 2010 Marcela Maslanova - 4.31-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
Plan for tomorrow's FESCo meeting (2010-12-08) NEW TIME
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 * Adjustments to updates policy: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container * Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at education/enforcement = New business = #topic Meeting time * Will 17:30UTC work moving forward? #topic #505 FPC guidelines for review https://fedorahosted.org/fesco/ticket/505 #topic #508 improve the general standard of packagers/maintainers in the distribution. https://fedorahosted.org/fesco/ticket/508 #topic #509 F15Feature: F15Boost146 - http://fedoraproject.org/wiki/Features/F15Boost146 https://fedorahosted.org/fesco/ticket/509 #topic #510 F15Feature: FourkBSectorBooting - http://fedoraproject.org/wiki/Features/FourkBSectorBooting https://fedorahosted.org/fesco/ticket/510 #topic #511 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3 https://fedorahosted.org/fesco/ticket/511 #topic #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice https://fedorahosted.org/fesco/ticket/512 #topic #513 F15Feature: Maven3 - http://fedoraproject.org/wiki/Features/Maven3 https://fedorahosted.org/fesco/ticket/513 #topic #514 F15Feature: Sugar 0.92 - http://fedoraproject.org/wiki/Features/Sugar_0.92 https://fedorahosted.org/fesco/ticket/514 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 660761] FTBFS perl-HTML-FillInForm-2.00-4.fc14
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=660761 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-12-07 17:00:55 --- Comment #7 from Emmanuel Seyman 2010-12-07 17:00:55 EST --- Fixed in 0:2.00-5 http://koji.fedoraproject.org/koji/taskinfo?taskID=2650174 -- 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: Is there any value to per-Fedora branch ACLs?
On 12/07/2010 11:52 AM, Till Maas wrote: > On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: >> While I'm looking into the git setup and ACLs and all this, I have a >> question. >> >> Is anybody seeing any real value of having different commit ACLs per >> Fedora branch? I've seen some argument for EPEL vs Fedora, but is there >> real value in ACLs for f13, f14, devel, etc...? > > There should be at least a distinction between EOL releases and non EOL > releases, e.g. someone having only commit access for F12 must not have > commit access for F13+ currently, because usually only ownership / ACLs > for current Fedora releases are up to date in PackageDB. I don't think the above really means we need different ACLs per branch, just that if we did flatten then we need to flatten them as a union of current active branches and not any EOL data. > And there > should still be a distinction in PackageDB for different > (co)maintainer for different Fedora releases. For what reason? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTML-FillInForm] Add perl(CGI) to BuildRequires and add perl default filter
commit 4251ea8ea7680dc3db15c010bfae00d7ebe543a5
Author: Emmanuel Seyman
Date: Tue Dec 7 22:54:01 2010 +0100
Add perl(CGI) to BuildRequires and add perl default filter
perl-HTML-FillInForm.spec |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-FillInForm.spec b/perl-HTML-FillInForm.spec
index 63ffb91..557c6dd 100644
--- a/perl-HTML-FillInForm.spec
+++ b/perl-HTML-FillInForm.spec
@@ -1,6 +1,6 @@
Name: perl-HTML-FillInForm
Version:2.00
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Populates HTML Forms with data
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,12 +8,15 @@ URL:http://search.cpan.org/dist/HTML-FillInForm/
Source0:
http://www.cpan.org/authors/id/T/TJ/TJMATHER/HTML-FillInForm-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(CGI)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::Parser) >= 3.26
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Output)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+%{?perl_default_filter}
+
%description
This module fills in an HTML form with data from a Perl data structure,
allowing you to keep the HTML and Perl separate.
@@ -48,6 +51,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 07 2010 Emmanuel Seyman - 2.00-5
+- Add perl(CGI) to BuildRequires
+- Add perl default filter
+
* Sun May 02 2010 Marcela Maslanova - 2.00-4
- 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: Is there any value to per-Fedora branch ACLs?
On 12/07/2010 11:22 AM, Mamoru Tasaka wrote: > There can be a case that F-13 package and F-14 package are completely > "different", even if the packages have the same name. > > For example there may be a case that a package of older version > shipped in F-13 is written in perl, and new version shipped in F-14 is > complete > rewritten in python (and I know one example, and for this case > re-review request for newer python version was submitted by the person > who was not the primary maintainer of perl version). In this case > for F-13 it may be reasonable that perl-sig is added in watchcommits, > however on F-14 it is perhaps meaningless. And even they may want to > change primary maintainer between these two (although for this case > the primary maintainer did not change finally). primary maintainer doesn't really matter. Bugzilla doesn't do owners per release, there is just one owner for Fedora, and one for EPEL. The matter of watchcommits is interesting, but I wonder if that really needs to be tied to pkgdb or if in the future we have a better way of "subscribing" to data regarding a particular package/branch/whatever. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Wed, Dec 01, 2010 at 02:02:48PM -0800, Adam Williamson wrote: > On Wed, 2010-12-01 at 16:54 -0500, Luke Macken wrote: > > > Yep, that happens. There are also people that add +0 comments to > > updates saying "Untested". There is an obvious need for more > > fine-grained karma types. > > I've sent out notes to the test list to ask people not to do either of > those things in future, I think the occurrence of them has gone down > significantly since those emails went out. (I also updated the proven > tester instructions page). > > More fine-grained karma is still coming in Bodhi 2.0, right? My > understanding was that we'd already agreed on the framework for it (in > those threads on this list a few months back) and we were just waiting > for the implementation now. Yes, that's the plan. I finally got the Bodhi v2.0 plans/ideas/status out of my brain and on to the wiki: https://fedoraproject.org/wiki/Bodhi/2.0 I linked to a couple of pages regarding karma improvements, but please update it with any more recent discussions regarding this change if you know of any. Also, more QA feature ideas are welcome. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On 12/07/2010 10:27 AM, Roland McGrath wrote: > The pkgdb interface distinguishes them. Apparently there was some > motivation for that in the first place. If the git hooks are not > going to distinguish them, then pkgdb should change not to either. Currently the git ACLs do enforce per-branch ACLs. It does make the acl config rather lengthy and the logic behind it a bit cumbersome, but it works. > > In my own experience, I've never put someone on any ACL for a package whom > I wouldn't trust to respect informal agreements about who should do what > commits to which branches. So any finer granularity on the ACL enforcement > is to avoid accidental braino commits, if anything. Since it's so easy to undo things in git I think this is less of a concern. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Tue, Dec 07, 2010 at 08:16:11PM +0100, Matej Cepl wrote: > Dne 7.12.2010 19:57, Stephen John Smoogen napsal(a): > > Or something like that. I do remember a lot of over-engineering and > > then a very simple it does this from Alan. And I remember a lot of > > issues we were having with customers going away after having them run > > it. > > There is something weird about firewalls ... whenever anybody starts to > write about them, the result is super-over-complicated unreadable junk. > After fighting with firewalls for years, and while I thought that they > are something scary, I was enlightened in RHCE training, and since then > I have this script (http://mcepl.fedorapeople.org/tmp/iptables-script > ... the current revision) and it works for me well. Sure, ability to > write trivial bash scripts is required, but I don't thing nothing over > the ability of most people using RHEL. Weird. And yes, this is very much > workstation-style laptop, and this serves me well whenever I came with it. I'm sure that script works fine for you, but ... The issue we face with libvirt is it needs to be able to add extra rules to the existing firewall, and have those rules added in the right place, and preserved across firewall restarts, reboots and so on. There are other services which need to add rules too (see cups mentioned previously in this thread). Unfortunately a shell script, or lokkit, has not been able to handle this gracefully. The question is what should replace it (I am favouring /etc/iptables.d/ but as you can see other people disagree with me). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On 12/07/2010 10:25 AM, Jeff Spaleta wrote: > On Tue, Dec 7, 2010 at 6:20 PM, Jesse Keating wrote: >> While I'm looking into the git setup and ACLs and all this, I have a >> question. >> >> Is anybody seeing any real value of having different commit ACLs per >> Fedora branch? I've seen some argument for EPEL vs Fedora, but is there >> real value in ACLs for f13, f14, devel, etc...? > > > I'm not sure there is. I'd like an on ramp to recruit yet to be > sponsored contributors into helping out by allowing them to patch the > packaging without build or bodhi rights...give me the ability to > review their work and do the builds. But I don't need that on a per > branch level. > > -jef That can be accomplished by having them do an anonymous clone, commit their changes locally, and send you the changes via git send-email. If you like them, you can git am the emails and the changes will appear in the repo as authored and with the changelog of the potential contributor. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
On Mon, Dec 06, 2010 at 08:08:49PM -0600, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > On most laptops, however, which are the most common types of system sold > > today, a firewall is very definitely needed when you're connecting to > > hotel networks, public wifi access points... > > The only thing you need a firewall by default for is to prevent services > that are listening on the network from being accessible. The better > solution is to stop having services listen on the network by default. > > This was done for sendmail many years ago; why hasn't it been done for > other things, such as rpcbind (and RPC services), cups, etc.? These > daemons should bind to localhost only unless otherwise configured. Afaik ntpd, sobby and software written in erlang (e.g. ejabberd) does not support this (completely). Regards Till pgpj5P18mGjYp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
Ralf Corsepius wrote: > On 12/07/2010 06:41 AM, Matt Domsch wrote: >> On Tue, Dec 07, 2010 at 03:35:35PM +1000, Jeffrey Fearn wrote: >>> Matt Domsch wrote: I would like to propose blocking packages at the F15 alpha compose point if they have not resolved their FTBFS from F14 or earlier. The lists may be broken down by when they last did build. With 3 exceptions, these 110 bugs are all still in NEW state as well, so they haven't had much maintainer love in quite some time (6-18 months). I trust module-init-tools will get resolved with an impending upstream release. Not like that can go unfixed forever. :-) perl-Makefile-Parser-0.211-3.fc14 [u'631098 NEW'] (build/make) nb,nb,perl-sig >>> Isn't the real bug here that koji is allowing Auto Install to run? >>> >>> Koji should be exporting: >>> >>> export PERL_EXTUTILS_AUTOINSTALL="--skipdeps" >> Perhaps- but not Koji - mock. > No. rpm.specs are supposed to be independent of the context they are > being built in (... koji, mock, plain rpmbuild or whatever). > > I.e. if at all, then it should be rpm which sets something of this kind > (I am not proposing it to do so.) > > ATM, packages need to take precautions that autoinstall doesn't run by > themselves. Form over function arguments seem to rule Fedora, which is probably why I find working in it so utterly frustrating. Anyway I think the best thing for me to do is stop being a package maintainer and get off the devel list, then I never have to spend my time on it again ... which sounds wonderful! Cheers, Jeff. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, Dec 7, 2010 at 8:12 PM, Matt Domsch wrote: >> Note that I am not advocating keeping these packages unfixed. I wanted >> to point out that things might turn ugly and might even trigger an >> avalanche when you remove the FTBFS packages from the repo and then >> the packages that depend on them will start to cry. > > skvidal pointed out repoquery --tree-whatrequires can help us find the > whole affected set of packages. I'm looking at generating that list > now. If we include all ~550 orphan packages in the run, plus the ~100 > FTBFS packages, plus all packages that these depend on, I'm sure it'll > wind up being a long list. All the more reason to look _now_, and not > 2 days before Alpha compose. Not to over burden you with the FTBFS effort. But to help me best prioritize my own time it would be great if you configure out a way for me quickly find the FTBFS packages in the dep chain for the packages I already co-maintain. The current representative governing body of voices in my head are not primarily an altruistic group. To get their resource allocation approval it would help immensely if I could show them the specific FTBFS packages that have a direct impact on my current workload. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Bugzappers meeting in 7 minutes!
This from Matej, who tried to send it a while ago, but who appears to be unable to post to the mailing list for some reason (I blame Canonical): Some of leading members of our glorious BugZappers crew presented some unreasonable requirements, like they would to sleep sometimes and stuff, but in our very benevolent and endless mercy other BugZappers then present on #fedora-bugzappers channel decided to postpone shift permanently the weekly BugZappers meeting to 21:00 UTC (that's 13:00 PST and 16:00 EST). See you all there! Matěj So we're meeting today in 7 - well, 6, now - minutes. Sorry for the extremely late notice. :) We'll send out better notice in future. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 7, 2010 at 7:20 PM, Jesse Keating wrote: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? No -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, Dec 07, 2010 at 02:10:00PM -0500, Orcan Ogetbil wrote: > On Tue, Dec 7, 2010 at 12:01 AM, Matt Domsch wrote: > > I would like to propose blocking packages at the F15 alpha compose > > point if they have not resolved their FTBFS from F14 or earlier. ??The > > lists may be broken down by when they last did build. ??With 3 > > exceptions, these 110 bugs are all still in NEW state as well, so they > > haven't had much maintainer love in quite some time (6-18 months). > > > > The subtlety here is that a FTBFS does not imply the package is not > functional. A package may be FTBFS due to various trivial reasons, > e.g. the name of a BuildRequires has changed and the new BuildRequires > does not Provides the old one. In such cases, from the functionality > perspective, the package does not need a rebuild. > > Note that I am not advocating keeping these packages unfixed. I wanted > to point out that things might turn ugly and might even trigger an > avalanche when you remove the FTBFS packages from the repo and then > the packages that depend on them will start to cry. skvidal pointed out repoquery --tree-whatrequires can help us find the whole affected set of packages. I'm looking at generating that list now. If we include all ~550 orphan packages in the run, plus the ~100 FTBFS packages, plus all packages that these depend on, I'm sure it'll wind up being a long list. All the more reason to look _now_, and not 2 days before Alpha compose. I believe keeping the distribution self-hosting (meaning, it can build itself) is an important goal. When we have packages that no longer build, either through their fault or through the fault of one of their dependencies, we lose the ability to be self-hosting, and I question the value of being open source if we can't use that source anymore. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 438244] No cpanget man page
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=438244 Steven Pritchard changed: What|Removed |Added Status|CLOSED |ASSIGNED Version|12 |rawhide Resolution|WONTFIX | Keywords||Reopened --- Comment #6 from Steven Pritchard 2010-12-07 15:00:54 EST --- Re-opening... This is still a valid bug that I'll try to get to ASAP. -- 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
[Bug 544738] cpanspec doesn't escape "/" in --filter-requires leading to bad sed statements
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=544738 Steven Pritchard changed: What|Removed |Added Status|CLOSED |ASSIGNED Version|12 |rawhide Resolution|WONTFIX | Keywords||Reopened --- Comment #6 from Steven Pritchard 2010-12-07 15:01:58 EST --- Re-opening... This is still a valid bug that I'll try to get to ASAP. -- 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: End of life in bugzilla, how to reopen?
On Tue, Dec 7, 2010 at 8:53 PM, Andreas Tunek wrote: > On Tue, 2010-12-07 at 20:48 +0100, François Cami wrote: >> On Tue, Dec 7, 2010 at 8:39 PM, Andreas Tunek >> wrote: >> > On Tue, 2010-12-07 at 22:26 +0530, Siddhesh Poyarekar wrote: >> >> 4 as well (not F13), but I can not change the version. >> >> > Do I have to file a new bug? >> >> >> >> I have reopened i >> > >> > So what kind of special access do you have to have to bugzilla in order >> > to change version? >> >> You would need to become a bugzapper for instance. >> See http://fedoraproject.org/wiki/BugZappers > > Shouldn't the end of life message reflect that then? It should tell me > to contact a bug zapper to move the bug report. You could also have cloned the bug against F14. I think you don't need any special access to do that. Anyway, the bug's reopened, and we probably need a few logs from you to debug more. I've included instructions to do so in the bug report. Cheers François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Mon, Dec 06, 2010 at 09:01:26PM +0100, Tomasz Torcz wrote: > Yeah, general discovery. From the top of my head: > - Pulseaudio sinks and sources > - libvirt instances for virt-manager > - VNC desktops for Vinagre > - local web pages (think SOHO router config page) for zeroconf > enabled Webbrowsers like Epiphany > - remote disk management (udisks) > - local FTP sites and WebDAV shares shown in nautilus places I guess most of these pages require authentication, so what use is it to know that they exist if one does not know the credentials for them? And if people know the credentials, why don't they know where to enter them? Regards Till pgpwzUVdAMtIV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
On Tue, 2010-12-07 at 20:48 +0100, François Cami wrote: > On Tue, Dec 7, 2010 at 8:39 PM, Andreas Tunek wrote: > > On Tue, 2010-12-07 at 22:26 +0530, Siddhesh Poyarekar wrote: > >> 4 as well (not F13), but I can not change the version. > >> > Do I have to file a new bug? > >> > >> I have reopened i > > > > So what kind of special access do you have to have to bugzilla in order > > to change version? > > You would need to become a bugzapper for instance. > See http://fedoraproject.org/wiki/BugZappers > > François Shouldn't the end of life message reflect that then? It should tell me to contact a bug zapper to move the bug report. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? There should be at least a distinction between EOL releases and non EOL releases, e.g. someone having only commit access for F12 must not have commit access for F13+ currently, because usually only ownership / ACLs for current Fedora releases are up to date in PackageDB. And there should still be a distinction in PackageDB for different (co)maintainer for different Fedora releases. Regards Till pgpNqLQFLOAXj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
On Tue, Dec 7, 2010 at 8:39 PM, Andreas Tunek wrote: > On Tue, 2010-12-07 at 22:26 +0530, Siddhesh Poyarekar wrote: >> 4 as well (not F13), but I can not change the version. >> > Do I have to file a new bug? >> >> I have reopened i > > So what kind of special access do you have to have to bugzilla in order > to change version? You would need to become a bugzapper for instance. See http://fedoraproject.org/wiki/BugZappers François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
On Tue, 2010-12-07 at 22:26 +0530, Siddhesh Poyarekar wrote: > 4 as well (not F13), but I can not change the version. > > Do I have to file a new bug? > > I have reopened i So what kind of special access do you have to have to bugzilla in order to change version? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
Jesse Keating wrote, at 12/08/2010 03:20 AM +9:00: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? > There can be a case that F-13 package and F-14 package are completely "different", even if the packages have the same name. For example there may be a case that a package of older version shipped in F-13 is written in perl, and new version shipped in F-14 is complete rewritten in python (and I know one example, and for this case re-review request for newer python version was submitted by the person who was not the primary maintainer of perl version). In this case for F-13 it may be reasonable that perl-sig is added in watchcommits, however on F-14 it is perhaps meaningless. And even they may want to change primary maintainer between these two (although for this case the primary maintainer did not change finally). Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-BerkeleyDB/el6/master: 12/12] Sync with rawhide.
commit c8550842012e10312c157dc7ffa90c4159ab6817 Merge: 4906ac0 a0afb94 Author: Steven Pritchard Date: Tue Dec 7 13:17:47 2010 -0600 Sync with rawhide. .gitignore |2 +- perl-BerkeleyDB.spec | 72 +++--- sources |2 +- 3 files changed, 64 insertions(+), 12 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-BerkeleyDB/el6/master] (12 commits) ...Sync with rawhide.
Summary of changes: 7e24a6c... Fix typo that causes a failure to update the common directo (*) 4cd3f1e... - rebuild against perl 5.10.1 (*) 741a1dc... Update to 0.41. (*) 698c420... - Mass rebuild with perl-5.12.0 (*) 08279d0... - Rebuild for Berkeley DB 4.8.30 in F-13 and Rawhide (#5922 (*) 1702df1... dist-git conversion (*) 2554f11... * Wed Jul 7 2010 Paul Howarth - 0.43-1 (*) 1d864be... Update to 0.42 (*) 736f0ff... Update to 0.43 (*) 0af503f... Rebuild for libdb 5.1.19 in Rawhide (*) a0afb94... - Rebuilt for gcc bug 634757 (*) c855084... Sync with rawhide. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Firewall
Dne 7.12.2010 19:57, Stephen John Smoogen napsal(a): > Or something like that. I do remember a lot of over-engineering and > then a very simple it does this from Alan. And I remember a lot of > issues we were having with customers going away after having them run > it. There is something weird about firewalls ... whenever anybody starts to write about them, the result is super-over-complicated unreadable junk. After fighting with firewalls for years, and while I thought that they are something scary, I was enlightened in RHCE training, and since then I have this script (http://mcepl.fedorapeople.org/tmp/iptables-script ... the current revision) and it works for me well. Sure, ability to write trivial bash scripts is required, but I don't thing nothing over the ability of most people using RHEL. Weird. And yes, this is very much workstation-style laptop, and this serves me well whenever I came with it. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, Dec 7, 2010 at 12:01 AM, Matt Domsch wrote: > I would like to propose blocking packages at the F15 alpha compose > point if they have not resolved their FTBFS from F14 or earlier. The > lists may be broken down by when they last did build. With 3 > exceptions, these 110 bugs are all still in NEW state as well, so they > haven't had much maintainer love in quite some time (6-18 months). > The subtlety here is that a FTBFS does not imply the package is not functional. A package may be FTBFS due to various trivial reasons, e.g. the name of a BuildRequires has changed and the new BuildRequires does not Provides the old one. In such cases, from the functionality perspective, the package does not need a rebuild. Note that I am not advocating keeping these packages unfixed. I wanted to point out that things might turn ugly and might even trigger an avalanche when you remove the FTBFS packages from the repo and then the packages that depend on them will start to cry. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 182507] clear-password mod from replica is discarded before changelogged
https://bugzilla.redhat.com/show_bug.cgi?id=182507 https://bugzilla.redhat.com/attachment.cgi?id=467113&action=diff https://bugzilla.redhat.com/attachment.cgi?id=467113&action=edit Description: Replication drops unhashed passwords which is necessary for the AD password sync. This patch allows the passwords replicated and introduces a method to encrypt logs in the changelog. See also http://directory.fedoraproject.org/wiki/Changelog_Encryption Thanks, --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 661083] New: FTBFS perl-PDF-API2-0.73-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-PDF-API2-0.73-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=661083 Summary: FTBFS perl-PDF-API2-0.73-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-PDF-API2 AssignedTo: bjohn...@symetrix.com ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: bjohn...@symetrix.com, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-PDF-API2-0.73-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 661088] New: FTBFS perl-File-Comments-0.07-7.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-File-Comments-0.07-7.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=661088 Summary: FTBFS perl-File-Comments-0.07-7.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-File-Comments AssignedTo: p...@city-fan.org ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: p...@city-fan.org, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-File-Comments-0.07-7.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 661092] New: FTBFS perl-Test-WWW-Mechanize-1.28-1.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-Test-WWW-Mechanize-1.28-1.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=661092 Summary: FTBFS perl-Test-WWW-Mechanize-1.28-1.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-Test-WWW-Mechanize AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-Test-WWW-Mechanize-1.28-1.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 661086] New: FTBFS perl-WWW-Mechanize-1.66-1.fc15
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-WWW-Mechanize-1.66-1.fc15 https://bugzilla.redhat.com/show_bug.cgi?id=661086 Summary: FTBFS perl-WWW-Mechanize-1.66-1.fc15 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-WWW-Mechanize AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-WWW-Mechanize-1.66-1.fc15.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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: Firewall
On Tue, Dec 7, 2010 at 09:24, Jesse Keating wrote: > On 12/07/2010 08:03 AM, Richard W.M. Jones wrote: >> There's also more to life than TCP ports. UDP ports, ICMP, other >> protocols, other unrecognized protocols, packets containing completely >> random stuff ... Having a firewall that lets through every TCP port >> does still give you protection from this other stuff. > > This is starting to sound like more reasonable arguments than "ZOMG > FIREWALL". Thank you. We should be sure to document these things in a > page that explains why Fedora has a Firewall by default, and why the > default configuration has been chosen. My memory of it goes something like this (notting can clarify) Tech Support A: We are having a lot of issues with broken in systems from network services Developer A: Well they need to turn them off then. Developer B: Well that would turn off Developer C: Well we do have a firewall Developer A: Firewalls are hard.. do you know how hard it would be to come up with something that doesn't break everyone. Developer B: Hmmm we will need a gui and a backstore and ... Alan Cox: Oh I wrote this lokkit so Telsa could setup a firewall after her box got dodgy at a conference. The tech support guys can give it out to people to test. Or something like that. I do remember a lot of over-engineering and then a very simple it does this from Alan. And I remember a lot of issues we were having with customers going away after having them run it. The main things that will need to be done is a) make sure most services aren't listening to UDP, SNP, etc to the outside world b) make sure that you can trust the services that do listen. c) expect a lot of blowback from outside of Fedora after release. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? I've never had a use case where I need to give someone access to only one branch. -- Ian Weller Where open source multiplies: http://opensource.com pgpZb5ibi07eg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
> Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? The pkgdb interface distinguishes them. Apparently there was some motivation for that in the first place. If the git hooks are not going to distinguish them, then pkgdb should change not to either. In my own experience, I've never put someone on any ACL for a package whom I wouldn't trust to respect informal agreements about who should do what commits to which branches. So any finer granularity on the ACL enforcement is to avoid accidental braino commits, if anything. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
On Tue, Dec 7, 2010 at 6:20 PM, Jesse Keating wrote: > While I'm looking into the git setup and ACLs and all this, I have a > question. > > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? I'm not sure there is. I'd like an on ramp to recruit yet to be sponsored contributors into helping out by allowing them to patch the packaging without build or bodhi rights...give me the ability to review their work and do the builds. But I don't need that on a per branch level. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is there any value to per-Fedora branch ACLs?
While I'm looking into the git setup and ACLs and all this, I have a question. Is anybody seeing any real value of having different commit ACLs per Fedora branch? I've seen some argument for EPEL vs Fedora, but is there real value in ACLs for f13, f14, devel, etc...? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 660849] New: FTBFS perl-Class-Observable-1.04-8.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-Class-Observable-1.04-8.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660849 Summary: FTBFS perl-Class-Observable-1.04-8.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-Class-Observable AssignedTo: andr...@bawue.net ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: andr...@bawue.net, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-Class-Observable-1.04-8.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660860] New: FTBFS perl-CGI-Application-Plugin-SuperForm-0.5-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-SuperForm-0.5-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660860 Summary: FTBFS perl-CGI-Application-Plugin-SuperForm-0.5-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-SuperForm AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-SuperForm-0.5-2.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660857] New: FTBFS perl-CGI-Application-Plugin-Stream-2.10-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-Stream-2.10-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660857 Summary: FTBFS perl-CGI-Application-Plugin-Stream-2.10-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-Stream AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-Stream-2.10-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660821] New: FTBFS perl-CGI-Application-Plugin-LogDispatch-1.02-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-LogDispatch-1.02-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660821 Summary: FTBFS perl-CGI-Application-Plugin-LogDispatch-1.02-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-LogDispatch AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-LogDispatch-1.02-4.fc14.src.rpm Failed To Build >From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660832] New: FTBFS perl-POE-Component-SNMP-1.1001-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-POE-Component-SNMP-1.1001-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660832 Summary: FTBFS perl-POE-Component-SNMP-1.1001-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-POE-Component-SNMP AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-POE-Component-SNMP-1.1001-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660836] New: FTBFS perl-POE-Component-Server-SimpleHTTP-2.04-1.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-POE-Component-Server-SimpleHTTP-2.04-1.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660836 Summary: FTBFS perl-POE-Component-Server-SimpleHTTP-2.04-1.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-POE-Component-Server-SimpleHTTP AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-POE-Component-Server-SimpleHTTP-2.04-1.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660826] New: FTBFS perl-Class-DBI-AsForm-2.42-11.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-Class-DBI-AsForm-2.42-11.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660826 Summary: FTBFS perl-Class-DBI-AsForm-2.42-11.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-Class-DBI-AsForm AssignedTo: tcall...@redhat.com ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-Class-DBI-AsForm-2.42-11.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660828] New: FTBFS perl-CGI-Application-FastCGI-0.02-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-FastCGI-0.02-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660828 Summary: FTBFS perl-CGI-Application-FastCGI-0.02-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-FastCGI AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-FastCGI-0.02-2.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660827] New: FTBFS perl-POE-Component-DBIAgent-0.26-7.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-POE-Component-DBIAgent-0.26-7.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660827 Summary: FTBFS perl-POE-Component-DBIAgent-0.26-7.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-POE-Component-DBIAgent AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-POE-Component-DBIAgent-0.26-7.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660800] New: FTBFS perl-CGI-Application-Dispatch-2.17-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Dispatch-2.17-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660800 Summary: FTBFS perl-CGI-Application-Dispatch-2.17-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Dispatch AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Dispatch-2.17-2.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660808] New: FTBFS perl-Test-HTTP-Server-Simple-StashWarnings-0.04-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-Test-HTTP-Server-Simple-StashWarnings-0.04-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660808 Summary: FTBFS perl-Test-HTTP-Server-Simple-StashWarnings-0.04-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-Test-HTTP-Server-Simple-StashWarnings AssignedTo: rc040...@freenet.de ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: rc040...@freenet.de, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-Test-HTTP-Server-Simple-StashWarnings-0.04-4.fc14.src.rpm Failed To Build >From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660787] New: FTBFS perl-CGI-Application-Plugin-CAPTCHA-0.01-2.fc15
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-CAPTCHA-0.01-2.fc15 https://bugzilla.redhat.com/show_bug.cgi?id=660787 Summary: FTBFS perl-CGI-Application-Plugin-CAPTCHA-0.01-2.fc15 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-CAPTCHA AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-CAPTCHA-0.01-2.fc15.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660810] New: FTBFS perl-Class-Can-0.01-5.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-Class-Can-0.01-5.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660810 Summary: FTBFS perl-Class-Can-0.01-5.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-Class-Can AssignedTo: ianburr...@gmail.com ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: ianburr...@gmail.com, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-Class-Can-0.01-5.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660792] New: FTBFS perl-CGI-Session-4.35-5.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Session-4.35-5.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660792 Summary: FTBFS perl-CGI-Session-4.35-5.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Session AssignedTo: andr...@bawue.net ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: andr...@bawue.net, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Session-4.35-5.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660771] New: FTBFS perl-CGI-Application-Plugin-ActionDispatch-0.97-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-ActionDispatch-0.97-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660771 Summary: FTBFS perl-CGI-Application-Plugin-ActionDispatch-0.97-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-ActionDispatch AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-ActionDispatch-0.97-2.fc14.src.rpm Failed To Build >From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660775] New: FTBFS perl-CGI-Application-Plugin-ValidateRM-2.3-5.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-ValidateRM-2.3-5.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660775 Summary: FTBFS perl-CGI-Application-Plugin-ValidateRM-2.3-5.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-ValidateRM AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-ValidateRM-2.3-5.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660777] New: FTBFS perl-CGI-Application-Plugin-ViewCode-1.02-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-ViewCode-1.02-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660777 Summary: FTBFS perl-CGI-Application-Plugin-ViewCode-1.02-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-ViewCode AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-ViewCode-1.02-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660763] New: FTBFS perl-HTML-FormFu-Model-DBIC-0.06000-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-HTML-FormFu-Model-DBIC-0.06000-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660763 Summary: FTBFS perl-HTML-FormFu-Model-DBIC-0.06000-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-HTML-FormFu-Model-DBIC AssignedTo: cw...@alumni.drew.edu ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-HTML-FormFu-Model-DBIC-0.06000-2.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660774] New: FTBFS perl-CGI-Untaint-1.26-9.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Untaint-1.26-9.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660774 Summary: FTBFS perl-CGI-Untaint-1.26-9.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Untaint AssignedTo: tcall...@redhat.com ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Untaint-1.26-9.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660761] New: FTBFS perl-HTML-FillInForm-2.00-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-HTML-FillInForm-2.00-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660761 Summary: FTBFS perl-HTML-FillInForm-2.00-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-HTML-FillInForm AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-HTML-FillInForm-2.00-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660762] New: FTBFS perl-CGI-Application-Plugin-ConfigAuto-1.32-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-ConfigAuto-1.32-2.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660762 Summary: FTBFS perl-CGI-Application-Plugin-ConfigAuto-1.32-2.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-ConfigAuto AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-ConfigAuto-1.32-2.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660755] New: FTBFS perl-CGI-Application-Plugin-AutoRunmode-0.16-5.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-AutoRunmode-0.16-5.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660755 Summary: FTBFS perl-CGI-Application-Plugin-AutoRunmode-0.16-5.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-AutoRunmode AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-AutoRunmode-0.16-5.fc14.src.rpm Failed To Build >From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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
[Bug 660749] New: FTBFS perl-CGI-Application-Plugin-Session-1.03-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: FTBFS perl-CGI-Application-Plugin-Session-1.03-4.fc14 https://bugzilla.redhat.com/show_bug.cgi?id=660749 Summary: FTBFS perl-CGI-Application-Plugin-Session-1.03-4.fc14 Product: Fedora Version: rawhide Platform: All URL: http://linux.dell.com/files/fedora/FixBuildRequires/mo ck-results/ OS/Version: Linux Status: NEW Keywords: Triaged Severity: high Priority: high Component: perl-CGI-Application-Plugin-Session AssignedTo: emmanuel.sey...@club-internet.fr ReportedBy: ft...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: emmanuel.sey...@club-internet.fr, fedora-perl-devel-l...@redhat.com Blocks: 659965 Classification: Fedora perl-CGI-Application-Plugin-Session-1.03-4.fc14.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) -- 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 default services
2010/12/7 Genes MailLists : > On 12/07/2010 10:20 AM, Michał Piotrowski wrote: > >> How many users use NFS on desktop? This is not even used on all servers. >> >> So the question is - do we want to have NFS by default? >> >> I use samba and I don't want to force all users to install it by default. >> > > > No idea how many but count me in - on our home network (assume thats > what a desktop is?) we use NFS for all the linux boxes (and mac's), and > samba for the small number of windows machines. > > Are you talking of LiveCD install or regular full install - on the > latter for sure NFS should be installed - in my view. The former I never > use :-) Ok, but IMO NFS is not something essential and crucial for 99% boxes out there, that needs to be turned on by default for all users. Do we agree with this? -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: maybe OT for devel? The Install F14 DVD.iso
On Tue, 07 Dec 2010 10:18:53 + Frank Murphy wrote: > Sorry list, > Couldn't find where to find the correct info\contact for this. > > sha256sum -c *-CHECKSUM > Fedora-14-i386-DVD.iso: OK > > sudo mount -o loop > /home/frank/Torrents/Fedora_14/Fedora-14-i386-DVD/Fedora-14-i386-DVD.iso > /mnt > > diff -r /mnt "/media/Fedora 14 i386 DVD" > diff: /mnt/RPM-GPG-KEY-fedora-sparc: No such file or directory > diff: /media/Fedora 14 i386 DVD/RPM-GPG-KEY-fedora-sparc: No such > file or directory > diff: /mnt/RPM-GPG-KEY-fedora-sparc64: No such file or directory > diff: /media/Fedora 14 i386 DVD/RPM-GPG-KEY-fedora-sparc64: No such > file or directory > > Using "isomaster" and checking the iso, > the above keys are shown as links. > > Am I still ok, to burn and distribute DVDs'? (Freemedia\lugger hat) Yes, it's a know cosmetic issue. You can ignore the above. Those keys were not shipped in the final fedora-release. It's nothing to worry about. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
On Tue, Dec 07, 2010 at 05:45:58PM +0100, Andreas Tunek wrote: > How do I reopen the bug? Previously in the bug report I stated that > this affects F14 as well (not F13), but I can not change the version. > Do I have to file a new bug? I have reopened it for you. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
End of life in bugzilla, how to reopen?
Bug 467267 got this message: --- Comment #7 from Bug Zapper 2010-12-05 02:07:18 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. How do I reopen the bug? Previously in the bug report I stated that this affects F14 as well (not F13), but I can not change the version. Do I have to file a new bug? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, Dec 06, 2010 at 11:01:20PM -0600, Matt Domsch wrote: > mingw32-libglademm24-2.6.7-8.fc12 [u'631374 NEW'] (build/make) sailer,rjones > mingw32-pangomm-2.26.0-1.fc12 [u'631208 NEW'] (build/make) sailer,rjones > mingw32-plotmm-0.1.2-4.fc12 [u'631082 NEW'] (build/make) sailer,rjones > mingw32-gtkmm24-2.19.6-1.fc14 [u'631110 NEW'] (build/make) sailer,rjones CC-ing to the mailing list. We've hired someone to take over the "residual maintenance" of the few mingw32 packages that people are using but not enough to want to take ownership. Unfortunately he doesn't start for another 3 months. > ocaml-deriving-0.1.1a-10.fc13 [u'631141 NEW'] (build/make) rjones,ocamlmaint This will be fixed in the coming OCaml rebuild (F15 feature). 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: Showing packages installed on the system: show-installed
On Tue, Dec 7, 2010 at 9:26 AM, FlorianFesti wrote: > This is now implemented as "show-installed" which is part of > yum-utils-1.1.29-2.fc15 found in Fedora devel. Awesome! I'm very happy to see this! -- Jared Smith Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On 12/07/2010 08:03 AM, Richard W.M. Jones wrote: > There's also more to life than TCP ports. UDP ports, ICMP, other > protocols, other unrecognized protocols, packets containing completely > random stuff ... Having a firewall that lets through every TCP port > does still give you protection from this other stuff. This is starting to sound like more reasonable arguments than "ZOMG FIREWALL". Thank you. We should be sure to document these things in a page that explains why Fedora has a Firewall by default, and why the default configuration has been chosen. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Tue, 2010-12-07 at 11:12 -0500, seth vidal wrote: > > dude, read to the end of the thread. I walked away - I conceded the > point about disabling the firewall. Sorry, sent too early (and twice, to add insult to injury). Anyway, to put a more positive note on this, I'm looking forward to Tomas work, and the NetworkManager integration for it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Mon, 2010-12-06 at 14:56 -0500, seth vidal wrote: > > ah, printing. > > Is there anything that's not last century? > So you are trying to defend the last-century firewall technology by calling everything that wants to share data last century ? That seems not the most constructive attitude... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide vendorarch?
On 12/07/2010 04:57 PM, Marcela Mašláňová wrote:
> On 12/07/2010 02:48 AM, Ralf Corsepius wrote:
>> Hi,
>>
>> Could somebody explain this change between f14 and f15?
>>
>> f14: perl -V:vendorarch
>> vendorarch='/usr/lib64/perl5';
>> f15: perl -V:vendorarch
>> vendorarch='/usr/lib64/perl5/vendor_perl';
>>
>> This causes f15 to install their vendorarch'ed modules under
>> /usr/lib64/perl5/vendor_perl
>> instead of
>> /usr/lib64/perl5
>>
>>
>> I.e. rebuilding packages under f15/rawhide causes perl-modules to move
>> from /usr/lib64/perl5 to /usr/lib64/perl5/vendor_perl
>>
>> E.g.:
>> # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc14.noarch.rpm
>> /usr/share/perl5/HTTP/Server/Simple.pm
>> /usr/share/perl5/HTTP/Server/Simple/CGI.pm
>> /usr/share/perl5/HTTP/Server/Simple/CGI/Environment.pm
>>
>> # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc15.noarch.rpm
>> /usr/share/perl5/vendor_perl/HTTP/Server/Simple.pm
>> /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI.pm
>> /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI/Environment.pm
>>
>> In generaly, I fail to understand why "vendor_perl" is necessary and why
>> this change was introduced to f15.
>>
>>
>> Also, I am facing FTBS errors, which I suspect to be related to this
>> f14->f15 change and to rawhide currently containing a mixture of
>> perl-packages using vendorarch=/usr/share/perl5 and others
>> vendorarch=/usr/share/perl5/vendor_arch.
>>
>>
>> Ralf
>>
>>
>> --
>> 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
>
> Hello,
> I sent email in July about that:
> http://lists.fedoraproject.org/pipermail/perl-devel/2010-July/024634.html
I vaguely remember this proposal :)
> I applied the patch in September, because I completely forgot about that
>
> email. The idea was install all modules into core directory
> /usr/lib64/perl5 or /usr/share/perl5. The vendorarch directory
>
> /usr/lib64/perl5/vendor_perlshould beempty.
Well, what I am observing is the opposite of what you describe.
f15-built modules land in %{_libdir}/perl5/vendor_perl
while
f14-built modules land in %{_libdir}/perl5,
That's why I am wondering - Has a bug crept into perl's setup?
> If core and vendor
>
> are the same as it is in F-14, then it's non-existent module looked up
> twice in the same
>
> path without luck.
>
> So, my suggestion is change all modules to install into core directories and
>
> leave vendorarch empty for personal RPMs, which also cut down time for
> looking up
How comes, f14 already did so and f15 has stopped doing so?
I am confused.
> modules. (Empty vendorarch toke less then core twice).
>
> There were questions in some new reviews if it's good idea to replace
> vendor with core,
>
> because they could be needed in future. I'm looking forward your
> comments/ideas.
Ralf
--
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: Firewall
On Tue, Dec 07, 2010 at 09:50:22AM +, Tim Waugh wrote: > If the CUPS snmp backend could say to "the firewall", "hey, please allow > responses on this port I've got for the next few seconds" -- which can > be controlled using PolicyKit -- then this network discovery would > finally work. Is there a compelling reason for this not to be: - cups snmp backend says to "the firewall", "hey, please allow responses on this port I've got" - cups snmp backend listens for responses until timeout - cups snmp backend says to "the firewall", "hey, I'm done now. thanks!" That seems more helpful than "a few seconds" anyway. And worst case is that the snmp backend crashes or otherwise forgets to remove its rule, which shouldn't be terribly severe since then it won't be listening, either. Some other point the the cups startup/stop process could make sure any such leftover rules are cleared just to be sure. I have no problem with the mechanism for talking to the firewall being some PolicyKit-enabled helper program. I just don't see a strong argument for it being a daemon. -- 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: Firewall
On Tue, 2010-12-07 at 11:10 -0500, Matthias Clasen wrote: > On Mon, 2010-12-06 at 14:56 -0500, seth vidal wrote: > > > > > ah, printing. > > > > Is there anything that's not last century? > > > > So you are trying to defend the last-century firewall technology by > calling everything that wants to share data last century ? > > That seems not the most constructive attitude... > dude, read to the end of the thread. I walked away - I conceded the point about disabling the firewall. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Mon, 2010-12-06 at 14:56 -0500, seth vidal wrote: > > ah, printing. > > Is there anything that's not last century? > So you are trying to defend the last-century firewall technology by calling everything that wants to share data last century ? That seems not the most constructive attitude... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as semantic desktop (nautilus and tracker integration) ?
On Sun, 2010-12-05 at 17:04 +0100, valent.turko...@gmail.com wrote: > On Sat, Dec 4, 2010 at 11:44 PM, valent.turko...@gmail.com > wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=501227 > > > > I'm writing to devel list just if anybody can say will there be any > > chance to get nautilus and tracker integration working? Is this on > > anybody's radar? > > > > Thanks, > > Valent. > > Is this feature abandoned because of GNOME 3? Will GNOME 3 have some > similar integration with tracker? GNOME 3 does not really affect tracker <> nautilus integration at all. There are plans to have support for files (presumably including tagging) in the shell (see e.g. http://blogs.gnome.org/mccann/2010/04/07/the-grip-the-trip-and-the-slip/ ) and there's also some code from the Zeitgeist team (http://seilo.geekyogre.com/2010/12/revisiting-gnome-shell-zeitgeist/ ). I don't know how much of this will be available in 3.0, though. It might end up being a 3.2 feature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On Mon, Dec 06, 2010 at 03:25:30PM -0800, Jesse Keating wrote: > On 12/06/2010 12:18 PM, Tom Lane wrote: > > Jesse Keating writes: > >> The argument of default firewall or not would probably quiet down quite > >> a bit if we had any sort of decent UI to help users get the firewall out > >> of their way when they're really trying to do something. > > > > +1. In today's environment, not having a firewall by default is an > > incredibly stupid idea. What we need to do is fix the UI problems, > > not bypass them by dramatically reducing security. > > > > regards, tom lane > > I keep seeing claims of "incredibly stupid", and at the same time saying > we need to make it easier to open up ports when they need them. What is > the default firewall protecting me from, if I'm allowed and hand held > through opening up ports on demand? There's also more to life than TCP ports. UDP ports, ICMP, other protocols, other unrecognized protocols, packets containing completely random stuff ... Having a firewall that lets through every TCP port does still give you protection from this other stuff. 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: Firewall
On Tue, Dec 07, 2010 at 08:44:02AM +0100, Matej Cepl wrote: > Dne 7.12.2010 00:21, Jesse Keating napsal(a): > > Actually bittorrents that have upnp work. Routers I've seen come > > pre-configured to allow upnp, so an app on a computer, or a game > > console, sends out a upnp request to open up/forward a port and the > > router complies. > > And I really hope this will never work on any computer I admin ... there > is apparently now small cottage industry of Windows viruses switching > off firewall via UPNP. Not to mention that UPnP is a scary hack: http://www.upnp-hacks.org/upnp.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide vendorarch?
On 12/07/2010 02:48 AM, Ralf Corsepius wrote: > Hi, > > Could somebody explain this change between f14 and f15? > > f14: perl -V:vendorarch > vendorarch='/usr/lib64/perl5'; > f15: perl -V:vendorarch > vendorarch='/usr/lib64/perl5/vendor_perl'; > > This causes f15 to install their vendorarch'ed modules under > /usr/lib64/perl5/vendor_perl > instead of > /usr/lib64/perl5 > > > I.e. rebuilding packages under f15/rawhide causes perl-modules to move > from /usr/lib64/perl5 to /usr/lib64/perl5/vendor_perl > > E.g.: > # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc14.noarch.rpm > /usr/share/perl5/HTTP/Server/Simple.pm > /usr/share/perl5/HTTP/Server/Simple/CGI.pm > /usr/share/perl5/HTTP/Server/Simple/CGI/Environment.pm > > # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc15.noarch.rpm > /usr/share/perl5/vendor_perl/HTTP/Server/Simple.pm > /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI.pm > /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI/Environment.pm > > In generaly, I fail to understand why "vendor_perl" is necessary and why > this change was introduced to f15. > > > Also, I am facing FTBS errors, which I suspect to be related to this > f14->f15 change and to rawhide currently containing a mixture of > perl-packages using vendorarch=/usr/share/perl5 and others > vendorarch=/usr/share/perl5/vendor_arch. > > > Ralf > > > -- > 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 Hello, I sent email in July about that: http://lists.fedoraproject.org/pipermail/perl-devel/2010-July/024634.html I applied the patch in September, because I completely forgot about that email. The idea was install all modules into core directory /usr/lib64/perl5 or /usr/share/perl5. The vendorarch directory /usr/lib64/perl5/vendor_perlshould beempty. If core and vendor are the same as it is in F-14, then it's non-existent module looked up twice in the same path without luck. So, my suggestion is change all modules to install into core directories and leave vendorarch empty for personal RPMs, which also cut down time for looking up modules. (Empty vendorarch toke less then core twice). There were questions in some new reviews if it's good idea to replace vendor with core, because they could be needed in future. I'm looking forward your comments/ideas. Best regards, Marcela -- Marcela Mašláňová BaseOS team Brno -- 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 default services
On 12/07/2010 10:20 AM, Michał Piotrowski wrote: > How many users use NFS on desktop? This is not even used on all servers. > > So the question is - do we want to have NFS by default? > > I use samba and I don't want to force all users to install it by default. > No idea how many but count me in - on our home network (assume thats what a desktop is?) we use NFS for all the linux boxes (and mac's), and samba for the small number of windows machines. Are you talking of LiveCD install or regular full install - on the latter for sure NFS should be installed - in my view. The former I never use :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On 12/07/2010 04:28 PM, Richard W.M. Jones wrote: > On Tue, Dec 07, 2010 at 09:50:22AM +, Tim Waugh wrote: >> On Mon, 2010-12-06 at 21:50 +, Richard W.M. Jones wrote: >>> Still not seeing how /etc/iptables.d wouldn't work ... >> >> Here is how: >> >> When I ask CUPS for a list of network printers, it runs the backends >> in /usr/lib/cups/backend. One of those is /usr/lib/cups/backend/snmp, >> which: >> >> a) binds to a local unprivileged UDP port >> b) sends a broadcast SNMP request >> c) listens for (unicast) responses to that request >> >> We don't hear any of those responses because they are not recognised as >> "related" by the kernel. The iptables rules drop them. >> >> If the CUPS snmp backend could say to "the firewall", "hey, please allow >> responses on this port I've got for the next few seconds" -- which can >> be controlled using PolicyKit -- then this network discovery would >> finally work. >> >> There's no way to know the local UDP port in advance >> so /etc/iptables.d-like systems all fail here. > > Does firewalld solve this? Surely a solution to this is going to have > to live in a stateful extension to iptables in the kernel, or a fix to > the 'related' packets function? > > Rich. > I'm pretty sure it was one of the things that Thomas was looking into together with Tim as that has been one of the things that just didn't properly work out of the box for cups and printer discovery. I'm not exactly sure about how they planed to fix it though, i'd need to double check with him. Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
