Should GnuPG 1.4.x be revived?
Hi, several users of Emacs and one user of Vim complained in rhbz#574406 [1] that they can no longer use their editor to open and edit gpg-encrypted files in Fedora 13. The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely compatible with GnuPG 1.4. I looked at GnuPG 2 and it seems that it would be very difficult to modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a password using shell -- it needs entire terminal (as it uses ncurses program pinentry-curses). Text editors can use only shell to send a password to GnuPG. What about reviving GnuPG 1.4? It is maintained, secure, supported, and its integration into text editors is used extensively and works well. It can live alongside GnuPG 2. What do you think? Any idea how to solve this issue? Thanks, Karel [1] https://bugzilla.redhat.com/show_bug.cgi?id=574406 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 09:54 AM, Karel Klic wrote: > Hi, > > several users of Emacs and one user of Vim complained in rhbz#574406 [1] > that they can no longer use their editor to open and edit gpg-encrypted > files in Fedora 13. > > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely > compatible with GnuPG 1.4. > > I looked at GnuPG 2 and it seems that it would be very difficult to > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a > password using shell -- it needs entire terminal (as it uses ncurses > program pinentry-curses). > Text editors can use only shell to send a password to GnuPG. > > What about reviving GnuPG 1.4? It is maintained, secure, supported, and > its integration into text editors is used extensively and works well. It > can live alongside GnuPG 2. > > What do you think? Any idea how to solve this issue? This one really must be addressed upstream. It's absurd that GnuPG doesn't work with GNU Emacs. If needs be, Richard Stallman is quite capable of knocking the maintainers' heads together. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On Tue, 2010-07-13 at 10:54 +0200, Karel Klic wrote: > Hi, > > several users of Emacs and one user of Vim complained in rhbz#574406 [1] > that they can no longer use their editor to open and edit gpg-encrypted > files in Fedora 13. > > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely > compatible with GnuPG 1.4. > > I looked at GnuPG 2 and it seems that it would be very difficult to > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a > password using shell -- it needs entire terminal (as it uses ncurses > program pinentry-curses). > Text editors can use only shell to send a password to GnuPG. > > What about reviving GnuPG 1.4? It is maintained, secure, supported, and > its integration into text editors is used extensively and works well. It > can live alongside GnuPG 2. > > What do you think? Any idea how to solve this issue? It's a lot harder to add IDEA support for GnuPG 2, too. Although hopefully that will no longer be an issue within a year or two. -- dwmw2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package review checklist
> Should someone write up a draft for an official package review > checklist, and have FPC update it when guidelines change? (I guess by > writing this email I just volunteered myself...) How about scripting and packaging it? Then one could just run it on the final srpm for review. Of course the reviewer would still need to complete the review details themselves manually but from a decent up-to-date template with some tedious bits hopefully filled in. Maybe some code could also be pulled from the review-o-matic project? With time it could be specialized also to deal with specific types of packages (python, perl, fonts, etc) but it can start simple. Submitters could also use it to sanity check their submissions perhaps. Though in the longer term I still think moving package reviews from bugzilla to a dedicated web app would make sense (oops...). It would probably be good if someone on FPC or FESCo say owned it. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning zikula module packages originally made for Fedora Insight
I'm orphaning the following packages: zikula-module-EZComments zikula-module-filterutil zikula-module-pagemaster They were modules needed for the first prototype of Fedora Insight, but I haven't been keeping up with upstream zikula for months now and can't maintain them responsibly. Copying the logistics list, in case any of the FI folks want to pick these up - I'm not sure where we stand with regards to zikula these days, as the platform choice seems to be under reconsideration. If FI is no longer using these modules, it may be a good idea to retire these packages. Thanks, --Mel PS: I haven't done this before, so if I'm missing something, let me know... I'm following http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages and headed to packagedb to click the "release ownership" button for those 3 packages now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package review checklist
On 07/13/2010 12:27 PM, Jens Petersen wrote: >> Should someone write up a draft for an official package review >> checklist, and have FPC update it when guidelines change? (I guess by >> writing this email I just volunteered myself...) >> > How about scripting and packaging it? Then one could just run it on > the final srpm for review. Of course the reviewer would still need > to complete the review details themselves manually but from a decent > up-to-date template with some tedious bits hopefully filled in. > Maybe some code could also be pulled from the review-o-matic project? > With time it could be specialized also to deal with specific types > of packages (python, perl, fonts, etc) but it can start simple. > Submitters could also use it to sanity check their submissions perhaps. > Though in the longer term I still think moving package reviews from > bugzilla to a dedicated web app would make sense (oops...). > > It would probably be good if someone on FPC or FESCo say owned it. > > Jens > A long long time ago (like in 3-4 years) Aurelien Bompard ( http://fedoraproject.org/wiki/AurelienBompard ) has written a short python script ( referenced in the above link) which automates a couple of checks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package "ownership"
On Tue, Jul 06, 2010 at 09:35:32AM -0700, Jesse Keating wrote: > > The "system" is fairly open with regard to just about everything except > attitude. Currently it's mostly attitude that prevents "openness". The ACL system restrict changes to other people packages to provenpackagers. And then the policies restrict a lot what provenpackages can do. So, the system is not very open, at least very unlike what Adam described. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package review checklist
On Tue, 2010-07-13 at 12:36 +0300, Manuel Wolfshant wrote: > On 07/13/2010 12:27 PM, Jens Petersen wrote: > >> Should someone write up a draft for an official package review > >> checklist, and have FPC update it when guidelines change? (I guess by > >> writing this email I just volunteered myself...) > >> > > How about scripting and packaging it? Then one could just run it on > > the final srpm for review. Of course the reviewer would still need > > to complete the review details themselves manually but from a decent > > up-to-date template with some tedious bits hopefully filled in. > > Maybe some code could also be pulled from the review-o-matic project? > > With time it could be specialized also to deal with specific types > > of packages (python, perl, fonts, etc) but it can start simple. > > Submitters could also use it to sanity check their submissions perhaps. > > Though in the longer term I still think moving package reviews from > > bugzilla to a dedicated web app would make sense (oops...). > > > > It would probably be good if someone on FPC or FESCo say owned it. > > > > Jens > > > A long long time ago (like in 3-4 years) Aurelien Bompard ( > http://fedoraproject.org/wiki/AurelienBompard ) has written a short > python script ( referenced in the above link) which automates a couple > of checks. I have also tried to automate some of the necessary step for package review: http://pingou.fedorapeople.org/reviewHelper.py Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On Tue, Jul 13, 2010 at 09:57:38AM +0100, Andrew Haley wrote: > On 07/13/2010 09:54 AM, Karel Klic wrote: > > Hi, > > > > several users of Emacs and one user of Vim complained in rhbz#574406 [1] > > that they can no longer use their editor to open and edit gpg-encrypted > > files in Fedora 13. > > > > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and > > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely > > compatible with GnuPG 1.4. > > > > I looked at GnuPG 2 and it seems that it would be very difficult to > > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a > > password using shell -- it needs entire terminal (as it uses ncurses > > program pinentry-curses). > > Text editors can use only shell to send a password to GnuPG. > > > > What about reviving GnuPG 1.4? It is maintained, secure, supported, and > > its integration into text editors is used extensively and works well. It > > can live alongside GnuPG 2. > > > > What do you think? Any idea how to solve this issue? > > This one really must be addressed upstream. It's absurd that GnuPG > doesn't work with GNU Emacs. If needs be, Richard Stallman is quite > capable of knocking the maintainers' heads together. That is certainly the good approach to get a long term solution for Fedora, but it isn't much use for people using Fedora 13 today who have broken gpg support. It sounds like a compat-gnupg14 package is a reasonable approach to fixing this in Fedora 13 stable, and likely also Fedora 14 if upstream don't get their act together quickly enough for that release. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 10:51 AM, Daniel P. Berrange wrote: > On Tue, Jul 13, 2010 at 09:57:38AM +0100, Andrew Haley wrote: >> On 07/13/2010 09:54 AM, Karel Klic wrote: >>> >>> several users of Emacs and one user of Vim complained in rhbz#574406 [1] >>> that they can no longer use their editor to open and edit gpg-encrypted >>> files in Fedora 13. >>> >>> The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and >>> GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely >>> compatible with GnuPG 1.4. >>> >>> I looked at GnuPG 2 and it seems that it would be very difficult to >>> modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a >>> password using shell -- it needs entire terminal (as it uses ncurses >>> program pinentry-curses). >>> Text editors can use only shell to send a password to GnuPG. >>> >>> What about reviving GnuPG 1.4? It is maintained, secure, supported, and >>> its integration into text editors is used extensively and works well. It >>> can live alongside GnuPG 2. >>> >>> What do you think? Any idea how to solve this issue? >> >> This one really must be addressed upstream. It's absurd that GnuPG >> doesn't work with GNU Emacs. If needs be, Richard Stallman is quite >> capable of knocking the maintainers' heads together. > > That is certainly the good approach to get a long term solution for > Fedora, but it isn't much use for people using Fedora 13 today who > have broken gpg support. It sounds like a compat-gnupg14 package is > a reasonable approach to fixing this in Fedora 13 stable, and likely > also Fedora 14 if upstream don't get their act together quickly enough > for that release. Sure. This sounds like the right approach for now. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: recoll review request help : using modified versions of libraries for build
On Sun, 2010-07-11 at 20:08 -0600, Kevin Fenzi wrote: > On Sun, 11 Jul 2010 11:31:01 +0530 > Ankur Sinha wrote: > > > hi, > > > > I'd like to confirm if I can approve recoll[1] which uses some build > > deps that it ships in the tar itself. Namely, "unac" and "binc imap". > > > > > > > > 1. I see a unac directory with a "stripped down version of unac". > > > > You need > > > to > > > > package unac separately and add it as a build requires IMO. > > > > > > Parts of unac are significantly modified for Recoll use. The > > > comment is misleading, this is not just a "stripped down version of > > > unac". I fixed the README (for the next version). Recoll could not > > > use the standard package. > > > > > > You can find the new README.recoll file at the following link. I > > > hope this clarifies things: > > > http://bitbucket.org/medoc/recoll/src/tip/unac/ > > ... > > > > ... > > > There is also a partial and modified copy of binc imap. As > > > far as I know this is not packaged on Fedora and not available as a > > > library, so including the code is the only way to reuse it. > > > > > > > AFAIK, these need to be packaged separately and then used as BRs. > > However, the modifications made for use in the package make it a > > little complex. > > > > Any help would be appreciated. > > Have you looked over: > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries > > I think it would be best to talk to upstream of this project and > see if there is any chance of them upstreaming any of their patches for > these projects. If not, then getting to admit that they are forking > them and only using them internally would at least be good to know. > > kevin hello, Yes. I did look at that page and ask the reporter and upstream to look at it too. The packages that they've used have significantly been changed to fit the needs of recoll, so I'm not sure sending patches to upstream makes sense. They've only used parts of the packages too, not the entire thing. Upstream acknowledges[1] that these have been used internally only, so I think it's okay. Thanks. regards, Ankur > https://bugzilla.redhat.com/show_bug.cgi?id=612719#c6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
On Tuesday 13 July 2010 01:28:50 Jesse Keating wrote: > We're ready for the next phase of dist-git migration testing. Building! > We now have a staging koji server that has been modified to accept > builds from our test dist-git server. I've also updated fedpkg (in the > fedora-packager package) to build against this koji instance. What I > would like is for people to do some trials, duplicate what they are > doing in dist-cvs over on dist-get with fedpkg and try to build things > so that we can get a picture of where things are falling over, or where > things are working. > > We're also looking for people that will help create draft modifications > to documentation regarding CVS. I can be a source of info for how > things work in dist-git and I need volunteers to get the info from me > and translate it into draft wiki pages. > > Another recently done target in fedpkg is the "import" command, which > can be used to import contents from an srpm. I have tested it somewhat, > but I'd like more people who regularly use cvs-import.sh to try it as well. > > So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) For the moment, Yum on Fedora 13 says: Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) Requires: GitPython >= 0.2.0 Installed: GitPython-0.1.6-2.fc13.noarch (@anaconda-InstallationRepo-201005130101.x86_64) -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
On Tue, 2010-07-13 at 13:34 +0200, Laurent Rineau wrote: > > So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) > > For the moment, Yum on Fedora 13 says: > > Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) >Requires: GitPython >= 0.2.0 >Installed: GitPython-0.1.6-2.fc13.noarch > (@anaconda-InstallationRepo-201005130101.x86_64) rpm -Uhv http://kojipkgs.fedoraproject.org/packages/GitPython/0.2.0/0.1.beta1.fc13/noarch/GitPython-0.2.0-0.1.beta1.fc13.noarch.rpm fixes this :) Léon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 7/7/2010 10:29 PM, Tom "spot" Callaway wrote: > [fabbione] cluster: gfs2-utils-3.0.12-3.fc14.x86_64 > clusterlib-3.0.12-3.fc14.x86_64 false positive > [fabbione] resource-agents: ldirectord-3.0.13-1.fc14.x86_64 also false positive > [lon] fence-virt: fence-virtd-0.2.1-3.fc14.x86_64 this is a good one :) will fix it. > [rmccabe] clustermon: modcluster-0.17.0-1.fc13.x86_64 good one too, will take care of those. Thanks fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: recoll review request help : using modified versions of libraries for build
On 07/13/2010 04:53 PM, Ankur Sinha wrote: > The packages that they've used have significantly been changed to fit > the needs of recoll, so I'm not sure sending patches to upstream makes > sense. > Have they tried doing that yet? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
Przemek Klosowski wrote: > In the context of this discussion, I think Kevin understands WONTFIX as > "the packager can't do anything about it, and leaves it up to the > upstream", whereas other people use the original meaning, and want see > something less categorical in Fedora/Bugzilla. Actually, I think WONTFIX is a bad choice of resolution here, UPSTREAM or, in the specific case of the reporter refusing to file an upstream bug, INSUFFICIENT_DATA is IMHO a better choice. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 09:54 AM, Karel Klic wrote: > several users of Emacs and one user of Vim complained in rhbz#574406 [1] > that they can no longer use their editor to open and edit gpg-encrypted > files in Fedora 13. > > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely > compatible with GnuPG 1.4. > > I looked at GnuPG 2 and it seems that it would be very difficult to > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a > password using shell -- it needs entire terminal (as it uses ncurses > program pinentry-curses). > Text editors can use only shell to send a password to GnuPG. > > What about reviving GnuPG 1.4? It is maintained, secure, supported, and > its integration into text editors is used extensively and works well. It > can live alongside GnuPG 2. No disagreement here in that GnuPG (of whatever version) should work with Emacs and vim. That should be fixed. However, as a GnuPG developer, I'd like to suggest another reason for keeping both GnuPG 1.x and 2.x: although there is significant overlap, they're not really aimed at the same problem. 1.x is aimed at servers where its "all in one" construction simplifies things, or in embedded systems or other places where space is tight. Some people also prefer the smaller and more easily reviewed code base and thus use 1.x as their "desktop" GnuPG. The version numbering is unfortunate in that it suggests that 2.x replaces 1.x, but in reality, the 1.x branch is a maintained product on its own. 1.x and 2.x are designed to be able to be installed together if necessary (note that the upstream code generates a binary named "gpg2" - the "gpg" binary in F13 is due to a local patch). This was done very well in F11. See, for example: http://www.mail-archive.com/gnupg-us...@gnupg.org/msg04642.html and http://www.mail-archive.com/gnupg-us...@gnupg.org/msg04645.html David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100713 changes
Compose started at Tue Jul 13 08:15:08 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-0.4.so.0()(64bit) emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4) emerillon-devel-0.1.1-2.fc13.x86_64 requires pkgconfig(champlain-0.4) entangle-0.1.0-4.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit) epiphany-2.31.3-2.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit) evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gnome-phone-manager-0.65-6.fc14.x86_64 requires libgnome-bluetooth.so.7()(64bit) gnome-shell-2.31.2-3.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) lekhonee-gnome-0.11-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) manedit-1.2.1-3.fc12.x86_64 requires man mine_detector-6.0-3.fc13.x86_64 requires libgnat-4.4.so()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-panel-status-0.1.21-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) mutter-mbl-2.29.1_0.4-1.fc14.i686 requires libgirepository-1.0.so.0 mutter-mbl-2.29.1_0.4-1.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit) mutter-mbl-devel-2.29.1_0.4-1.fc14.i686 requires libgirepository-1.0.so.0 mutter-mbl-devel-2.29.1_0.4-1.fc14.x86_64 requires libgirepository-1.0.so.0()(64bit) perl-DBI-Dumper-2.01-8.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0) perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) perl-Mail-Box-2.095-1.fc14.noarch requires perl(File::FcntlLock) perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) perl-Test-AutoBuild-1.2.2-9.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0) plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc plplot-ada-5.9.6-1.fc14.i686 requires libgnat-4.4.so plplot-ada-5.9.6-1.fc14.x86_64 requires libgnat-4.4.so()(64bit) python3-beaker-1.5.3-4.fc14.noarch requires python3-paste qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) seed-2.31.1-2.fc14.i686 requires libgirepository-1.0.so.0 seed-2.31.1-2.fc14.x86_64 requires libg
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 03:21 PM, Daniel P. Berrange wrote: > > That is certainly the good approach to get a long term solution for > Fedora, but it isn't much use for people using Fedora 13 today who > have broken gpg support. It sounds like a compat-gnupg14 package is > a reasonable approach to fixing this in Fedora 13 stable, and likely > also Fedora 14 if upstream don't get their act together quickly enough > for that release. > "compat-gnupg14" suggests that it is a temporary thing. It appears like the Python3 transition, both versions are probably going to be around forever and hence gnupg14 is a better package name IMO. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
2010/7/13 Daniel P. Berrange : > On Tue, Jul 13, 2010 at 09:57:38AM +0100, Andrew Haley wrote: >> On 07/13/2010 09:54 AM, Karel Klic wrote: >> > Hi, >> > >> > several users of Emacs and one user of Vim complained in rhbz#574406 [1] >> > that they can no longer use their editor to open and edit gpg-encrypted >> > files in Fedora 13. >> > >> > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and >> > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely >> > compatible with GnuPG 1.4. >> > >> > I looked at GnuPG 2 and it seems that it would be very difficult to >> > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a >> > password using shell -- it needs entire terminal (as it uses ncurses >> > program pinentry-curses). >> > Text editors can use only shell to send a password to GnuPG. >> > >> > What about reviving GnuPG 1.4? It is maintained, secure, supported, and >> > its integration into text editors is used extensively and works well. It >> > can live alongside GnuPG 2. >> > >> > What do you think? Any idea how to solve this issue? >> >> This one really must be addressed upstream. It's absurd that GnuPG >> doesn't work with GNU Emacs. If needs be, Richard Stallman is quite >> capable of knocking the maintainers' heads together. > > That is certainly the good approach to get a long term solution for > Fedora, but it isn't much use for people using Fedora 13 today who > have broken gpg support. It sounds like a compat-gnupg14 package is > a reasonable approach to fixing this in Fedora 13 stable, and likely > also Fedora 14 if upstream don't get their act together quickly enough > for that release. > > Regards, > Daniel > -- No need to introduce a new compat-gnupg14 package, simply revive gnupg in koji is enough. http://koji.fedoraproject.org/koji/packageinfo?packageID=453 gnupg 2.x is named as gnupg2 in fedora. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Developers of packages please pay attention to selinux labeling.
If you are changing the locate of an executable or libraries the executables write to, please make sure SELinux labels are still consistant or contact the selinux developers for help. IF you update a package in a released version of Fedora and change the locations you MUST make sure it still works with selinux in enforcing mode. packagekit got released this to F13 and Rawhide this week and changed its location. packagekitd should be labeled rpm_exec_t, Since it moved it got the default label and is now running unconfined. This causes labels to get screwed up and lots of bugs are being reported on it. It gives SELinux a bad name. And it makes our user community mad. SELinux has been around a long time. Packages should be using it at least in testing. This is unacceptable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 07:55 AM, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. > > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. > > Should we set the context manually, or will a restorecon in %post be sufficient? -J -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 06:25 PM, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. > > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. > Wasn't there a move earlier to move policies to the packages instead of maintaining everything centrally? As long as it abstracted away from me, I don't really pay much attention to it. If it was part of my package, I probably can keep it updated better. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
Daniel J Walsh wrote: > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. I QA'd this package as working under SELinux enforcing machines and did not encounter any issues. Could you point to the bugs in question so I can study what I missed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 13 July 2010 13:55, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. > > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. No. SELinux is unacceptable when it displays ridiculous warning messages to users telling them it has detected suspicious activity on a system that has ONLY JUST BEEN INSTALLED. Please, for the love of everything, stop it. (my assumption here - this nonsense has been going on for so many releases I've lost count). -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 06:58 PM, Christopher Brown wrote: > No. SELinux is unacceptable when it displays ridiculous warning > messages to users telling them it has detected suspicious activity on > a system that has ONLY JUST BEEN INSTALLED. > That should have failed the release criteria as it is written currently. Let the QA team know by citing bug numbers. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review trade needed
I hit a new dependency when building perl-Mail-Box for EPEL, and I could use a quick package review of perl-File-FcntlLock (its a teeny tiny perl package). Will happily trade reviews. https://bugzilla.redhat.com/show_bug.cgi?id=614008 ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 09:30 AM, Rahul Sundaram wrote:
> On 07/13/2010 06:58 PM, Christopher Brown wrote:
>> No. SELinux is unacceptable when it displays ridiculous warning
>> messages to users telling them it has detected suspicious activity on
>> a system that has ONLY JUST BEEN INSTALLED.
>>
>
> That should have failed the release criteria as it is written
> currently. Let the QA team know by citing bug numbers.
>
> Rahul
>
All of the bugs like this
https://bugzilla.redhat.com/show_bug.cgi?id=567454
The problem is without the rpm_exec_t label it runs as initrc_t which is
an unconfiend domain. It creates /tmp output files and redirects the
stdout of all packages being updated. If any confined app transitions
it attempts to append to a file labeled tmp_t rather then rpm_tmp_t.
This caused all confined applications to generate an AVC like
node=(removed) type=AVC msg=audit(1266885495.204:24851): avc: denied {
read append } for pid=6724 comm="tzdata-update" path="/tmp/tmpNJCaKB"
dev=dm-1 ino=110966 scontext=unconfined_u:system_r:tzdata_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
It is obviously difficult to trace this type of error back to packagekit.
It just takes a few seconds to send us a heads up and we can fix the
next selinux policy package.
These are the things labeled rpm_exec_t on a Fedora machine
/usr/libexec/yumDBUSBackend.py
/bin/rpm
/usr/bin/rpm
/usr/bin/yum
/usr/sbin/pup
/usr/bin/smart
/usr/sbin/pirut
/usr/bin/apt-get
/usr/sbin/up2date
/usr/sbin/synaptic
/usr/bin/apt-shell
/usr/sbin/rhn_check
/usr/sbin/yum-updatesd
/usr/libexec/packagekitd
/usr/libexec/ricci-modrpm
/usr/bin/fedora-rmdevelrpms
/usr/bin/rpmdev-rmdevelrpms
/usr/sbin/system-install-packages
/usr/share/yumex/yum_childtask\.py
/usr/sbin/yum-complete-transaction
/usr/share/yumex/yumex-yum-backend
So putting this into the packagekitd package does not make sense.
As long as you give us a heads up we can prevent these types of blowups.
Since this policy is shared between yum, packagekit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 07:14 PM, Daniel J Walsh wrote: > On 07/13/2010 09:30 AM, Rahul Sundaram wrote: > >> On 07/13/2010 06:58 PM, Christopher Brown wrote: >> >>> No. SELinux is unacceptable when it displays ridiculous warning >>> messages to users telling them it has detected suspicious activity on >>> a system that has ONLY JUST BEEN INSTALLED. >>> >>> >> That should have failed the release criteria as it is written >> currently. Let the QA team know by citing bug numbers. >> >> Rahul >> >> > All of the bugs like this > > https://bugzilla.redhat.com/show_bug.cgi?id=567454 > That's a post release regression. I was pointing out that SELinux denials right after installation of a new release (without any updates) fails the release criteria. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 13 July 2010 14:44, Daniel J Walsh wrote:
> On 07/13/2010 09:30 AM, Rahul Sundaram wrote:
>> On 07/13/2010 06:58 PM, Christopher Brown wrote:
>>> No. SELinux is unacceptable when it displays ridiculous warning
>>> messages to users telling them it has detected suspicious activity on
>>> a system that has ONLY JUST BEEN INSTALLED.
>>>
>>
>> That should have failed the release criteria as it is written
>> currently. Let the QA team know by citing bug numbers.
>>
>> Rahul
>>
> All of the bugs like this
>
> https://bugzilla.redhat.com/show_bug.cgi?id=567454
>
> The problem is without the rpm_exec_t label it runs as initrc_t which is
> an unconfiend domain. It creates /tmp output files and redirects the
> stdout of all packages being updated. If any confined app transitions
> it attempts to append to a file labeled tmp_t rather then rpm_tmp_t.
>
> This caused all confined applications to generate an AVC like
>
> node=(removed) type=AVC msg=audit(1266885495.204:24851): avc: denied {
> read append } for pid=6724 comm="tzdata-update" path="/tmp/tmpNJCaKB"
> dev=dm-1 ino=110966 scontext=unconfined_u:system_r:tzdata_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
>
> It is obviously difficult to trace this type of error back to packagekit.
>
> It just takes a few seconds to send us a heads up and we can fix the
> next selinux policy package.
>
> These are the things labeled rpm_exec_t on a Fedora machine
>
> /usr/libexec/yumDBUSBackend.py
> /bin/rpm
> /usr/bin/rpm
> /usr/bin/yum
> /usr/sbin/pup
> /usr/bin/smart
> /usr/sbin/pirut
> /usr/bin/apt-get
> /usr/sbin/up2date
> /usr/sbin/synaptic
> /usr/bin/apt-shell
> /usr/sbin/rhn_check
> /usr/sbin/yum-updatesd
> /usr/libexec/packagekitd
> /usr/libexec/ricci-modrpm
> /usr/bin/fedora-rmdevelrpms
> /usr/bin/rpmdev-rmdevelrpms
> /usr/sbin/system-install-packages
> /usr/share/yumex/yum_childtask\.py
> /usr/sbin/yum-complete-transaction
> /usr/share/yumex/yumex-yum-backend
>
>
> So putting this into the packagekitd package does not make sense.
>
> As long as you give us a heads up we can prevent these types of blowups.
> Since this policy is shared between yum, packagekit
Whilst I appreciate your huge efforts to provide users with a more
secure system, you need to realise that SELinux as it stands at the
moment is utterly broken. As you clearly don't think this is the case,
please spend some time in userland before beating on developers for
not caring about this.
If we can't even build (and QA!) a system that ships without SELinux
warnings, there is clearly a problem. Adding SELinux checks to Fedora
development slows things down even further. You really need to work
with the AutoQA people to get this automated. Developers simply
shouldn't have to worry about this.
I understand wanting SELinux checks for *EL but for Fedora? Seriously?
Wow, just wow.
--
Christopher Brown
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, Jul 08, 2010 at 11:31:09AM -0400, Brandon Lozza wrote: > A mass rebuild would be recommended as the new compiler will produce faster > code. I believe everything will benefit and it's worth looking into. For > example I noticed a significant difference on the OpenSUSE distro when GCC was There may also be some regressions that cause newer gcc's to miscompile some previously working code due to a corner-case in some newly introducted optimization. Rare, but does happen. I've reported a few myself over the years, and while the gcc people are extremely good at tracking these down, I'd feel much more comfortable if a mass rebuild got done early on, just to be sure. "Problem started after mass recompile" is much so much easier to diagnose than "Problem started after bumping package from 1.1 to 1.2 (or even 1.1-1 to 1.1-2 where we just fixed typos in the documentation". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
On Tue, 2010-07-13 at 13:48 +0200, Léon Keijser wrote: > On Tue, 2010-07-13 at 13:34 +0200, Laurent Rineau wrote: > > > So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) > > > > For the moment, Yum on Fedora 13 says: > > > > Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) > >Requires: GitPython >= 0.2.0 > >Installed: GitPython-0.1.6-2.fc13.noarch > > (@anaconda-InstallationRepo-201005130101.x86_64) > > rpm -Uhv > http://kojipkgs.fedoraproject.org/packages/GitPython/0.2.0/0.1.beta1.fc13/noarch/GitPython-0.2.0-0.1.beta1.fc13.noarch.rpm > > fixes this :) Or: yum install http://kojipkgs.fedoraproject.org/packages/GitPython/0.2.0/0.1.beta1.fc13/noarch/GitPython-0.2.0-0.1.beta1.fc13.noarch.rpm ...if you don't want the rpmdb warnings, and missing yumdb etc. data that is the reason for them. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 05:11 PM, Christopher Brown wrote: > [...] > Whilst I appreciate your huge efforts to provide users with a more > secure system, you need to realise that SELinux as it stands at the > moment is utterly broken. As you clearly don't think this is the case, > please spend some time in userland before beating on developers for > not caring about this. > > If we can't even build (and QA!) a system that ships without SELinux > warnings, there is clearly a problem. Adding SELinux checks to Fedora > development slows things down even further. You really need to work > with the AutoQA people to get this automated. Developers simply > shouldn't have to worry about this. > > I understand wanting SELinux checks for *EL but for Fedora? Seriously? > > Wow, just wow. I am sorry, Christopher but I have to partially disagree with you. There is absolutely no reason to make Fedora any less secure than *EL. Or any less secure that it can be. Yes, selinux can be cumbersome at times. Yes, it can be improved. But that cannot be done without proper feedback. And yes, AutoQA doing selinux checks is a good idea. Manuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 10:11 AM, Christopher Brown wrote:
> On 13 July 2010 14:44, Daniel J Walsh wrote:
>> On 07/13/2010 09:30 AM, Rahul Sundaram wrote:
>>> On 07/13/2010 06:58 PM, Christopher Brown wrote:
No. SELinux is unacceptable when it displays ridiculous warning
messages to users telling them it has detected suspicious activity on
a system that has ONLY JUST BEEN INSTALLED.
>>>
>>> That should have failed the release criteria as it is written
>>> currently. Let the QA team know by citing bug numbers.
>>>
>>> Rahul
>>>
>> All of the bugs like this
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=567454
>>
>> The problem is without the rpm_exec_t label it runs as initrc_t which is
>> an unconfiend domain. It creates /tmp output files and redirects the
>> stdout of all packages being updated. If any confined app transitions
>> it attempts to append to a file labeled tmp_t rather then rpm_tmp_t.
>>
>> This caused all confined applications to generate an AVC like
>>
>> node=(removed) type=AVC msg=audit(1266885495.204:24851): avc: denied {
>> read append } for pid=6724 comm="tzdata-update" path="/tmp/tmpNJCaKB"
>> dev=dm-1 ino=110966 scontext=unconfined_u:system_r:tzdata_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
>>
>> It is obviously difficult to trace this type of error back to packagekit.
>>
>> It just takes a few seconds to send us a heads up and we can fix the
>> next selinux policy package.
>>
>> These are the things labeled rpm_exec_t on a Fedora machine
>>
>> /usr/libexec/yumDBUSBackend.py
>> /bin/rpm
>> /usr/bin/rpm
>> /usr/bin/yum
>> /usr/sbin/pup
>> /usr/bin/smart
>> /usr/sbin/pirut
>> /usr/bin/apt-get
>> /usr/sbin/up2date
>> /usr/sbin/synaptic
>> /usr/bin/apt-shell
>> /usr/sbin/rhn_check
>> /usr/sbin/yum-updatesd
>> /usr/libexec/packagekitd
>> /usr/libexec/ricci-modrpm
>> /usr/bin/fedora-rmdevelrpms
>> /usr/bin/rpmdev-rmdevelrpms
>> /usr/sbin/system-install-packages
>> /usr/share/yumex/yum_childtask\.py
>> /usr/sbin/yum-complete-transaction
>> /usr/share/yumex/yumex-yum-backend
>>
>>
>> So putting this into the packagekitd package does not make sense.
>>
>> As long as you give us a heads up we can prevent these types of blowups.
>> Since this policy is shared between yum, packagekit
>
> Whilst I appreciate your huge efforts to provide users with a more
> secure system, you need to realise that SELinux as it stands at the
> moment is utterly broken. As you clearly don't think this is the case,
> please spend some time in userland before beating on developers for
> not caring about this.
>
> If we can't even build (and QA!) a system that ships without SELinux
> warnings, there is clearly a problem. Adding SELinux checks to Fedora
> development slows things down even further. You really need to work
> with the AutoQA people to get this automated. Developers simply
> shouldn't have to worry about this.
>
> I understand wanting SELinux checks for *EL but for Fedora? Seriously?
>
> Wow, just wow.
>
We get the point you do not like SELinux. Fine.
I don't want to get into a discussion of SELinux value here. The goal
is just to get developers to think about the SELinux of changing the
location of paths in their spec file after release, just like they would
think of the Ownership/Permission changes in the spec file. We usually
catch these things in Rawhide quickly but if it happens in a released
package, it can lead more people to think SELinux is just broken.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Distributions & updates
On 07/09/2010 08:48 AM, Fred Walker wrote: > Hello: > I hope this is the proper place for this post. > I do not have access to DSL )-; > Because of this I would like to make a suggestion. > When a new Distribution is released I get the DVD with everything on it. > The problem is after the install and upgrade the new Distribution looks > to the repositories for up dates. This is fine if you have some form of > HI-speed available. When you don't it is an issue. It can take days > for the new updates to down load. > It would be GREAT if arrangements could be made for a subscription that > would send out a DVD with updates biweekly or monthly. I think this > could be a good way to keep those of us without HI-speed connections > available up to date. A subscription could help raise funds for > development and maintenance cost. You could even use advertising to > help pay for the cost. Something like selling the DVD cover as > advertisement space! You could even do some form of USB Thumb Drive > swapping, Just a suggestion. Thanks, all, Fred http://www.redhat.com/about/presscenter/1998/press_rhmember.html Everything new is old again ;) -- Peter "I can imagine a world without war, without hate. I can imagine us attacking it, because they'd never expect it." 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Tue, Jul 13, 2010 at 08:55:47AM -0400, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. I do not understand the "the executables write to" part of the condition of what is bad and therefore not at all what needs to be avoided. Is it possible to move a library from /usr/lib to /lib without breaking selinux? Regards Till pgplwbFTm6U4g.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
Dne 13.7.2010 01:28, Jesse Keating napsal(a): > Thanks in advance! (and find me on IRC or file tickets against > fedora-packager in fedora hosted if you run into issues) Cannot find you on IRC ... https://fedorahosted.org/fedora-packager/ticket/18 Matěj -- understand, v.: To reach a point, in your investigation of some subject, at which you cease to examine what is really present, and operate on the basis of your own internal model instead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
Le 13/07/2010 15:30, Rahul Sundaram a écrit : > > On 07/13/2010 06:58 PM, Christopher Brown wrote: >> No. SELinux is unacceptable when it displays ridiculous warning >> messages to users telling them it has detected suspicious activity on >> a system that has ONLY JUST BEEN INSTALLED. >> > > That should have failed the release criteria as it is written > currently. IIRC pyzor, for example, has never worked on an selinux system, as it tries to write stuff in / (and no one has minded for many releases) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Distributions & updates
On Fri, Jul 09, 2010 at 08:48:24AM -0400, Fred Walker wrote: > Because of this I would like to make a suggestion. > When a new Distribution is released I get the DVD with everything on it. > The problem is after the install and upgrade the new Distribution looks > to the repositories for up dates. This is fine if you have some form of > HI-speed available. When you don't it is an issue. It can take days > for the new updates to down load. Where do you get the DVD? If it is a commercial shop, maybe they might also provide you with updates discs if you ask. There is also the free media project in Fedora, maybe they know someone that can help you: http://fedoraproject.org/wiki/Distribution/FreeMedia Also you might look for a local linux user group, maybe you can the updates there. Also for faster updates you might increase the metadata_expire for the fedora repo in /etc/yum.repos.d/fedora.repo to something like forever, because it should not change and you do not need to re-download it every seven days. And in case you do not use it, the yum-presto plugin will reduce the amount of download data for updates if you update regularly. Regards Till pgpuLOJaJ3oWb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 08:15 PM, Nicolas Mailhot wrote: > IIRC pyzor, for example, has never worked on an selinux system, as it > tries to write stuff in / (and no one has minded for many releases) > The release criteria only cares about the default package set and configuration in my understanding. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Tue, Jul 13, 2010 at 03:11:44PM +0100, Christopher Brown wrote: > > > > As long as you give us a heads up we can prevent these types of blowups. > > Since this policy is shared between yum, packagekit > > Whilst I appreciate your huge efforts to provide users with a more > secure system, you need to realise that SELinux as it stands at the > moment is utterly broken. As you clearly don't think this is the case, > please spend some time in userland before beating on developers for > not caring about this. On the other hand, I cannot understand why packagers submit packages that have no chance to work in default Fedora settings, with SELinux in Enforcing mode. There are sometimes such obvious errors and missing labels that I cannot imagine not catching an audit message when program fails to even start! There should be no excuses, especially when asking Dan is so simple and he is always patient and helpful. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) pgphv5Q7m1elD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Image-ExifTool-8.25.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Image-ExifTool: 271d6cb716f74af7a5072561d7ca4750 Image-ExifTool-8.25.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Image-ExifTool/EL-6 perl-Image-ExifTool.spec, 1.25, 1.26 sources, 1.20, 1.21
Author: spot
Update of /cvs/pkgs/rpms/perl-Image-ExifTool/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv22097/EL-6
Modified Files:
perl-Image-ExifTool.spec sources
Log Message:
8.25
Index: perl-Image-ExifTool.spec
===
RCS file: /cvs/pkgs/rpms/perl-Image-ExifTool/EL-6/perl-Image-ExifTool.spec,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -p -r1.25 -r1.26
--- perl-Image-ExifTool.spec12 Jul 2010 20:27:11 - 1.25
+++ perl-Image-ExifTool.spec13 Jul 2010 14:59:12 - 1.26
@@ -1,6 +1,6 @@
Name: perl-Image-ExifTool
-Version: 8.15
-Release: 2%{?dist}
+Version: 8.25
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Applications/Multimedia
Summary: Utility for reading and writing image meta info
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Tue Jul 13 2010 Tom "spot" Callaway - 8.25-1
+- update to 8.25
+
* Sun May 02 2010 Marcela Maslanova - 8.15-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Image-ExifTool/EL-6/sources,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- sources 12 Jul 2010 20:27:11 - 1.20
+++ sources 13 Jul 2010 14:59:13 - 1.21
@@ -1 +1 @@
-750cc49c18ef1ed65300bc39bc4e6536 Image-ExifTool-8.15.tar.gz
+271d6cb716f74af7a5072561d7ca4750 Image-ExifTool-8.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Image-ExifTool/devel .cvsignore, 1.20, 1.21 perl-Image-ExifTool.spec, 1.28, 1.29 sources, 1.21, 1.22
Author: spot
Update of /cvs/pkgs/rpms/perl-Image-ExifTool/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv22097/devel
Modified Files:
.cvsignore perl-Image-ExifTool.spec sources
Log Message:
8.25
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Image-ExifTool/devel/.cvsignore,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- .cvsignore 15 Feb 2010 13:15:25 - 1.20
+++ .cvsignore 13 Jul 2010 14:59:13 - 1.21
@@ -1 +1 @@
-Image-ExifTool-8.10.tar.gz
+Image-ExifTool-8.25.tar.gz
Index: perl-Image-ExifTool.spec
===
RCS file: /cvs/pkgs/rpms/perl-Image-ExifTool/devel/perl-Image-ExifTool.spec,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -p -r1.28 -r1.29
--- perl-Image-ExifTool.spec2 May 2010 16:26:50 - 1.28
+++ perl-Image-ExifTool.spec13 Jul 2010 14:59:13 - 1.29
@@ -1,6 +1,6 @@
Name: perl-Image-ExifTool
-Version: 8.15
-Release: 2%{?dist}
+Version: 8.25
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Applications/Multimedia
Summary: Utility for reading and writing image meta info
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Tue Jul 13 2010 Tom "spot" Callaway - 8.25-1
+- update to 8.25
+
* Sun May 02 2010 Marcela Maslanova - 8.15-2
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Image-ExifTool/devel/sources,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -p -r1.21 -r1.22
--- sources 23 Mar 2010 12:56:46 - 1.21
+++ sources 13 Jul 2010 14:59:13 - 1.22
@@ -1 +1 @@
-750cc49c18ef1ed65300bc39bc4e6536 Image-ExifTool-8.15.tar.gz
+271d6cb716f74af7a5072561d7ca4750 Image-ExifTool-8.25.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Distributions & updates
On 13/07/10 15:48, Till Maas wrote: > On Fri, Jul 09, 2010 at 08:48:24AM -0400, Fred Walker wrote: > > http://fedoraproject.org/wiki/Distribution/FreeMedia Not so relevant for this. Best bet may be to install: yum-plugin-security and just go for security updates with: yum --security update failing that just create a yum update list and grab them at a local internet cafe. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 10:37 AM, Till Maas wrote: > On Tue, Jul 13, 2010 at 08:55:47AM -0400, Daniel J Walsh wrote: >> If you are changing the locate of an executable or libraries the >> executables write to, please make sure SELinux labels are still >> consistant or contact the selinux developers for help. IF you update a >> package in a released version of Fedora and change the locations you >> MUST make sure it still works with selinux in enforcing mode. > > I do not understand the "the executables write to" part of the condition > of what is bad and therefore not at all what needs to be avoided. > > Is it possible to move a library from /usr/lib to /lib without breaking > selinux? > > Regards > Till > Usually yes. matchpathcon /usr/lib/mylib.so matchpathcon /lib/mylib.so If they are the same no problem, if they are different talk to us. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 13/07/10 15:47, Tomasz Torcz wrote: > On Tue, Jul 13, 2010 at 03:11:44PM +0100, Christopher Brown wrote: >>> >>> As long as you give us a heads up we can prevent these types of blowups. >>> Since this policy is shared between yum, packagekit >> >> Whilst I appreciate your huge efforts to provide users with a more >> secure system, you need to realise that SELinux as it stands at the >> moment is utterly broken. As you clearly don't think this is the case, >> please spend some time in userland before beating on developers for >> not caring about this. > > > On the other hand, I cannot understand why packagers submit packages that > have no chance to work in default Fedora settings, with SELinux in Enforcing > mode. Nobody I know enables SELinux. smolt says about half leave it enabled: http://smolts.org/static/stats/stats.html But I'm guessing a lot of experienced users/devs disable it given previous experiences... It's a bit of a catch 22 really. Personally I do momentarily enable to test but always disable because of _hundreds_ of errors in the applet thingy. Enabling in non enforcing mode causes a huge performance hit, causing for example the "do you want to kill" dialog to pop up when I try to quit firefox. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
> Personally I do momentarily enable to test but always disable > because of _hundreds_ of errors in the applet thingy. You can disable the applet thingy without disabling selinux. I do. - Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/13/2010 09:03 PM, Pádraig Brady wrote: > Nobody I know enables SELinux. > smolt says about half leave it enabled: > http://smolts.org/static/stats/stats.html > But I'm guessing a lot of experienced users/devs > disable it given previous experiences... > It's a bit of a catch 22 really. > The smolt stats has some gaps but setting aside that. 68.9% has SELinux enabled according to it. Besides if you are a Fedora package maintainer and do not test your package with SELinux in enforcing mode, you aren't doing a good job. Regardless of whether you have it enabled on your system, you know that a large numbers of users would since it is the default configuration resulting in a broken user experience. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On Tue, Jul 13, 2010 at 10:54:06AM +0200, Karel Klic wrote: > Hi, > > several users of Emacs and one user of Vim complained in rhbz#574406 [1] > that they can no longer use their editor to open and edit gpg-encrypted > files in Fedora 13. > > The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and > GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely > compatible with GnuPG 1.4. > > I looked at GnuPG 2 and it seems that it would be very difficult to > modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a > password using shell -- it needs entire terminal (as it uses ncurses > program pinentry-curses). > Text editors can use only shell to send a password to GnuPG. > > What about reviving GnuPG 1.4? It is maintained, secure, supported, and > its integration into text editors is used extensively and works well. It > can live alongside GnuPG 2. > > What do you think? Any idea how to solve this issue? > Having gpg1 and gpg2 seems reasonable to me. Note, though, that the problem is slightly more limited in scope. At least with vim, if you have an X display, gpg2 will invoke the graphical pinentry where you can enter your passphrase and go about your business. Plain console, remote sessions that are not allowed to send the graphical window back to the local session, and systems that don't have the graphical pinentry programs installed will all experience this problem, though. -Toshio pgplgej2cXAXE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Tue, Jul 13, 2010 at 10:15 AM, Pekka Pietikainen wrote: > On Thu, Jul 08, 2010 at 11:31:09AM -0400, Brandon Lozza wrote: >> A mass rebuild would be recommended as the new compiler will produce faster >> code. I believe everything will benefit and it's worth looking into. For >> example I noticed a significant difference on the OpenSUSE distro when GCC >> was > There may also be some regressions that cause newer gcc's to miscompile > some previously working code due to a corner-case in some newly > introducted optimization. Rare, but does happen. I've reported a few myself > over the years, and while the gcc people are extremely good at tracking > these down, I'd feel much more comfortable if a mass rebuild got done > early on, just to be sure. > > "Problem started after mass recompile" is much so much easier to diagnose than > "Problem started after bumping package from 1.1 to 1.2 (or even 1.1-1 to > 1.1-2 where we just fixed typos in the documentation". > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I'm going to keep a personal note of the apps which do perform faster and grab the src rpm's so that I can compile them myself with LTO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
Dne 13.7.2010 17:33, Pádraig Brady napsal(a): > Personally I do momentarily enable to test but always disable > because of _hundreds_ of errors in the applet thingy. Hundreds? I have been running RHEL-6 from mid-Januray (that means Rawhide was quite stable comparing to it) with SELinux in the Enforcing mode with even special SELinux user staff_u and I just don't see *hundreds* bugs on day-to-day basis. I was very faithful in filing ALL SELinux issues to bugzilla and I am quite sure it wasn't hundred so far. Matěj -- In those days spirits were brave, the stakes were high, men were real men, women were real women and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri. -- Douglas Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package "ownership"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/10 2:43 AM, Patrice Dumas wrote: > On Tue, Jul 06, 2010 at 09:35:32AM -0700, Jesse Keating wrote: >> >> The "system" is fairly open with regard to just about everything except >> attitude. Currently it's mostly attitude that prevents "openness". > > The ACL system restrict changes to other people packages to provenpackagers. > And then the policies restrict a lot what provenpackages can do. So, the > system is not very open, at least very unlike what Adam described. > Right, the attitude has led to policy of what provenpackagers can do, but the underlying system is open. All it takes is an attitude change as nothing else is preventing provenpackagers from doing more. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8jdUACgkQ4v2HLvE71NUyggCgrJOtrWOEry+OUh6h6tRn5y1w RaEAn37hTdMBziF/Zb8+3DQJI4XQNLFy =hhxu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2010 05:38 AM, David Shaw wrote: > On 07/13/2010 09:54 AM, Karel Klic wrote: > >> several users of Emacs and one user of Vim complained in rhbz#574406 [1] >> that they can no longer use their editor to open and edit gpg-encrypted >> files in Fedora 13. >> >> The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and >> GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely >> compatible with GnuPG 1.4. >> >> I looked at GnuPG 2 and it seems that it would be very difficult to >> modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a >> password using shell -- it needs entire terminal (as it uses ncurses >> program pinentry-curses). >> Text editors can use only shell to send a password to GnuPG. >> >> What about reviving GnuPG 1.4? It is maintained, secure, supported, and >> its integration into text editors is used extensively and works well. It >> can live alongside GnuPG 2. > > No disagreement here in that GnuPG (of whatever version) should work with > Emacs and vim. That should be fixed. However, as a GnuPG developer, I'd > like to suggest another reason for keeping both GnuPG 1.x and 2.x: although > there is significant overlap, they're not really aimed at the same problem. > 1.x is aimed at servers where its "all in one" construction simplifies > things, or in embedded systems or other places where space is tight. Some > people also prefer the smaller and more easily reviewed code base and thus > use 1.x as their "desktop" GnuPG. The version numbering is unfortunate in > that it suggests that 2.x replaces 1.x, but in reality, the 1.x branch is a > maintained product on its own. > > 1.x and 2.x are designed to be able to be installed together if necessary > (note that the upstream code generates a binary named "gpg2" - the "gpg" > binary in F13 is due to a local patch). This was done very well in F11. > This is why I'm so surprised to see gpg be deprecated in f13. Upstream is supporting both and the manpage even indicates that the binary should be gpg2. I don't see any reason for it to have been removed in f13, and am willing to help maintain it. I've been a pgp and gpg user since the early 90's, I attempted to port pgp to the Atari ST (unsuccessfully I should note :) ) at one time. - -- Brian C. Lane Red Hat / Port Orchard, WA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTDyONxF+jBaO/jp/AQIIbwf/dP0Vs740iJUke+0nAYXE3OO0Gwe6SHFm kfMdGUAwNrRTIwSiwMkGrQNtOQN7XlbG2fkBVcyt4SWgRBJPDlRIXZgWRwjxfw7l mptTwmhshhuwQjGS0mfaZJ1X1WF6voYwLxoOIMDEMB9d8+SP+4vFq22obkEqjU3w RJUpSW2XJR9JCv6O8yQbBK2PbC++LIM4lJcmifBFLh1u2KjsuyejBMz4iL/ieCam aO9fexC2y38hq9FPmQeyQdtUaak+z8vIEA6ZgHFqLxuCMUl3nlDE70kq4CnDDnz4 9gIhfWxWSc0lSQdW7UzU1eD9YNSNz7Q1IU4jx+aMcsbIi2eTQjdc5w== =Vdl1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
KDE-SIG meeting report (28/2010)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 28/2010 Time: 2010-07-13 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-13 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2010-07-13/kde-sig.2010-07-13-14.00.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2010-07-13/kde- sig.2010-07-13-14.00.log.html -- = Participants = * Jaroslav Reznik * Kevin Kofler * Rex Dieter * Steven Parrish * Than Ngo * Thomas Janssen * Lukas Tinkl * Radek Novacek and KDEPIM guests ;-) -- = Agenda = * topics to discuss: o kdepim 4.5 in Rawhide o Features/KDE45 : due asap! [1] o kde-4.4.5 updates status o Desktop validation testing expansion [2] * recent bugs: o Pressing any key causes kvkbd to print or move too many letters or spaces [3] = Summary = * welcome Radek! Features/KDE45 : due asap! * Qt 4.7 should be standalone feature probably but no time for it * ACTION: rdieter to consult knm upstream about future of monolithic client kdepim 4.5 in Rawhide * it's not clear kdepim-4.5 will make it in time for F-14 * AGREED: delay kdepim-4.5 decision/voting pending feedback from upstream kde-4.4.5 updates status * missing libmsn in the latest f14 push * otherwise 4.4.5 looks good Desktop validation testing expansion * will be discussed on mailing list -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-20 = Links = [1] https://fedoraproject.org/wiki/Features/KDE45 [2] http://lists.fedoraproject.org/pipermail/kde/2010-July/007616.html [3] http://lists.fedoraproject.org/pipermail/kde/2010-July/007616.html -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Tue, Jul 13, 2010 at 11:55:15AM -0400, Brandon Lozza wrote: > I'm going to keep a personal note of the apps which do perform faster > and grab the src rpm's so that I can compile them myself with LTO. Remember that currently LTO doesn't play well with debug info, for C sometimes somewhat usable debug info is generated, but for C++ or Fortran often the debug info is completely useless, if the compiler doesn't crash with -g. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On 07/13/2010 11:55 AM, Brandon Lozza wrote: > I'm going to keep a personal note of the apps which do perform faster > and grab the src rpm's so that I can compile them myself with LTO. Jakub Jelinek said that "LTO isn't really usable in 4.5." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/10 4:34 AM, Laurent Rineau wrote: > On Tuesday 13 July 2010 01:28:50 Jesse Keating wrote: >> We're ready for the next phase of dist-git migration testing. Building! >> We now have a staging koji server that has been modified to accept >> builds from our test dist-git server. I've also updated fedpkg (in the >> fedora-packager package) to build against this koji instance. What I >> would like is for people to do some trials, duplicate what they are >> doing in dist-cvs over on dist-get with fedpkg and try to build things >> so that we can get a picture of where things are falling over, or where >> things are working. >> >> We're also looking for people that will help create draft modifications >> to documentation regarding CVS. I can be a source of info for how >> things work in dist-git and I need volunteers to get the info from me >> and translate it into draft wiki pages. >> >> Another recently done target in fedpkg is the "import" command, which >> can be used to import contents from an srpm. I have tested it somewhat, >> but I'd like more people who regularly use cvs-import.sh to try it as well. >> >> So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) > > For the moment, Yum on Fedora 13 says: > > Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) >Requires: GitPython >= 0.2.0 >Installed: GitPython-0.1.6-2.fc13.noarch > (@anaconda-InstallationRepo-201005130101.x86_64) > Wait a tic, 0.2.0 is tagged as dist-f13-updates... so it should be in stable updates. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8jwgACgkQ4v2HLvE71NUOPACfQYCvstZ0iBL2yKVnjQh7JkZL J3kAn2PLqZ9KdOD9DvGZDpAzGevp6BV9 =jkov -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/10 4:34 AM, Laurent Rineau wrote: > On Tuesday 13 July 2010 01:28:50 Jesse Keating wrote: >> We're ready for the next phase of dist-git migration testing. Building! >> We now have a staging koji server that has been modified to accept >> builds from our test dist-git server. I've also updated fedpkg (in the >> fedora-packager package) to build against this koji instance. What I >> would like is for people to do some trials, duplicate what they are >> doing in dist-cvs over on dist-get with fedpkg and try to build things >> so that we can get a picture of where things are falling over, or where >> things are working. >> >> We're also looking for people that will help create draft modifications >> to documentation regarding CVS. I can be a source of info for how >> things work in dist-git and I need volunteers to get the info from me >> and translate it into draft wiki pages. >> >> Another recently done target in fedpkg is the "import" command, which >> can be used to import contents from an srpm. I have tested it somewhat, >> but I'd like more people who regularly use cvs-import.sh to try it as well. >> >> So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) > > For the moment, Yum on Fedora 13 says: > > Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing) >Requires: GitPython >= 0.2.0 >Installed: GitPython-0.1.6-2.fc13.noarch > (@anaconda-InstallationRepo-201005130101.x86_64) > Oops, I'll push that into updates-testing. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8jnYACgkQ4v2HLvE71NVh+QCcDr4g1eTUQGwcAkqfUOWgwAl3 cU0An2GWysdK9dBL/HbKGwWBId4H6ogu =JEjS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
Pádraig Brady wrote: >Nobody I know enables SELinux. >smolt says about half leave it enabled: >http://smolts.org/static/stats/stats.html >But I'm guessing a lot of experienced users/devs >disable it given previous experiences... It's closer to 70% actually, also consider the 18.7% being market as "Unknown". >Personally I do momentarily enable to test but always disable >because of hundreds of errors in the applet thingy. If you have _hundreds_ of errors with SELinux, i'm afraid you are exaggerating, using a custom policy or you might have a serious labeling issue : touch /.autorelabel reboot My system is running as staff_u, and i don't remember reporting more than 20-30 AVCs over now almost a year. If you think it might be an issue with the policy, you should report those bugs into RHBZ. >Enabling in non enforcing mode causes a huge performance hit, >causing for example the "do you want to kill" dialog to pop up >when I try to quit firefox. Can you measure the *huge* performance hit, i would be interested to see your numbers. As far as i'm aware, the performance hit of SELinux is around 5-7%. >But I'm guessing a lot of experienced users/devs >disable it given previous experiences... Well, they should reconsider their decision and just take a look at how many user space tools are available to make their life easier. The FUD about SELinux need to stop. signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
Kevin Kofler writes: > [...] > Actually, I think WONTFIX is a bad choice of resolution here, UPSTREAM or, > in the specific case of the reporter refusing to file an upstream bug, > INSUFFICIENT_DATA is IMHO a better choice. ... or FEDORA_MAINTAINER_PATCH_ROBOT_TOO_BUSY. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
2010/7/14 Brian C. Lane : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/13/2010 05:38 AM, David Shaw wrote: >> On 07/13/2010 09:54 AM, Karel Klic wrote: >> >>> several users of Emacs and one user of Vim complained in rhbz#574406 [1] >>> that they can no longer use their editor to open and edit gpg-encrypted >>> files in Fedora 13. >>> >>> The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and >>> GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely >>> compatible with GnuPG 1.4. >>> >>> I looked at GnuPG 2 and it seems that it would be very difficult to >>> modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a >>> password using shell -- it needs entire terminal (as it uses ncurses >>> program pinentry-curses). >>> Text editors can use only shell to send a password to GnuPG. >>> >>> What about reviving GnuPG 1.4? It is maintained, secure, supported, and >>> its integration into text editors is used extensively and works well. It >>> can live alongside GnuPG 2. >> >> No disagreement here in that GnuPG (of whatever version) should work with >> Emacs and vim. That should be fixed. However, as a GnuPG developer, I'd >> like to suggest another reason for keeping both GnuPG 1.x and 2.x: although >> there is significant overlap, they're not really aimed at the same problem. >> 1.x is aimed at servers where its "all in one" construction simplifies >> things, or in embedded systems or other places where space is tight. Some >> people also prefer the smaller and more easily reviewed code base and thus >> use 1.x as their "desktop" GnuPG. The version numbering is unfortunate in >> that it suggests that 2.x replaces 1.x, but in reality, the 1.x branch is a >> maintained product on its own. >> >> 1.x and 2.x are designed to be able to be installed together if necessary >> (note that the upstream code generates a binary named "gpg2" - the "gpg" >> binary in F13 is due to a local patch). This was done very well in F11. >> > > This is why I'm so surprised to see gpg be deprecated in f13. Upstream > is supporting both and the manpage even indicates that the binary should > be gpg2. > > I don't see any reason for it to have been removed in f13, and am > willing to help maintain it. I've been a pgp and gpg user since the > early 90's, I attempted to port pgp to the Atari ST (unsuccessfully I > should note :) ) at one time. > > - -- > Brian C. Lane Please fill a Review Request for gnupg in bugzilla, if no one opposes reviving gnupg in koji . Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REMINDER: Test machine resources for package maintainers
On Sat, Jul 10, 2010 at 07:10:51PM -0600, Kevin Fenzi wrote: > Recent changes include: > > - I have added a RHEL6b2 test machine. This may help EPEL-6 maintainers > check for packages or test/debug their packages. Thank you very much. There seems to be a typo in the reverse DNS entry for varen: $ ssh varen.scrye.com reverse mapping checking getaddrinfo for revan.scrye.com [216.17.180.7] failed - POSSIBLE BREAK-IN ATTEMPT! Regards Till pgp5aR6HJzXMg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Class-C3/EL-6 perl-Class-C3.spec,1.13,1.14
Author: kevin
Update of /cvs/pkgs/rpms/perl-Class-C3/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3475
Modified Files:
perl-Class-C3.spec
Log Message:
Sync up with devel changes to get building in EL-6
Index: perl-Class-C3.spec
===
RCS file: /cvs/pkgs/rpms/perl-Class-C3/EL-6/perl-Class-C3.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-Class-C3.spec 6 Feb 2010 10:26:40 - 1.13
+++ perl-Class-C3.spec 13 Jul 2010 16:23:53 - 1.14
@@ -1,6 +1,8 @@
+%global older_perl %(%{__perl} -e '$] < 5.009_005 ? print 1 : print 0')
+
Name: perl-Class-C3
Version:0.22
-Release:1%{?dist}
+Release:4%{?dist}
Summary:Pragma to use the C3 method resolution order algorithm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,23 +15,25 @@ Requires: perl(:MODULE_COMPAT_%(ev
# see rh#205081,rh#204800
%define __perl_provides %{nil}
Provides: perl(Class::C3) = %{version}
+Provides: perl(c3) = %{version}
BuildRequires: perl(ExtUtils::MakeMaker) >= 6.42
BuildRequires: perl(Test::More) >= 0.47
-BuildRequires: perl(Algorithm::C3) >= 0.06
-BuildRequires: perl(Class::C3::XS) >= 0.07
BuildRequires: perl(Test::Exception) >= 0.15
-BuildRequires: perl(Scalar::Util) >= 1.10
# testing...
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Class::C3)
BuildRequires: perl(Sub::Name)
+# past 5.9.5 mro is in core
+%if %{older_perl}
+BuildRequires: perl(Algorithm::C3) >= 0.06
+BuildRequires: perl(Class::C3::XS) >= 0.07
+BuildRequires: perl(Scalar::Util) >= 1.10
Requires: perl(Algorithm::C3) >= 0.06
-Requires: perl(Scalar::Util) >= 1.10
-# strictly speaking, this is optional. However, speed is always nice :)
Requires: perl(Class::C3::XS) >= 0.07
+Requires: perl(Scalar::Util) >= 1.10
+%endif
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -43,6 +47,7 @@ method resolution order.
%setup -q -n Class-C3-%{version}
%build
+%{?perl_ext_env_unset}
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -52,6 +57,7 @@ rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+cp opt/c3.pm %{buildroot}%{perl_vendorlib}/
%{_fixperms} %{buildroot}/*
@@ -63,11 +69,21 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
-%doc ChangeLog README opt/ util/
+%doc ChangeLog README util/
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Sat May 15 2010 Chris Weyl 0.22-4
+- bump
+
+* Sat May 15 2010 Chris Weyl 0.22-3
+- install c3.pm as well; drop opt/ from doc
+- conditionalise
+
+* Fri Apr 30 2010 Marcela Maslanova - 0.22-2
+- Mass rebuild with perl-5.12.0
+
* Sat Feb 06 2010 Chris Weyl 0.22-1
- PERL_INSTALL_ROOT => DESTDIR
- add perl_default_subpackage_tests, and drop t/ from doc
--
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: Developers of packages please pay attention to selinux labeling.
Once upon a time, Christopher Brown said: > Whilst I appreciate your huge efforts to provide users with a more > secure system, you need to realise that SELinux as it stands at the > moment is utterly broken. It works for a lot of people, so I would hardly call it "utterly broken". > I understand wanting SELinux checks for *EL but for Fedora? Seriously? Since the major security risk is at the desktop, and Fedora is more targeted at the desktop than RHEL, SELinux is IMHO more important in Fedora than RHEL. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Class-C3/EL-6 .cvsignore,1.7,1.8
Author: kevin Update of /cvs/pkgs/rpms/perl-Class-C3/EL-6 In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv3709 Modified Files: .cvsignore Log Message: Oops. Missed cvsignore Index: .cvsignore === RCS file: /cvs/pkgs/rpms/perl-Class-C3/EL-6/.cvsignore,v retrieving revision 1.7 retrieving revision 1.8 diff -u -p -r1.7 -r1.8 --- .cvsignore 2 Apr 2009 07:10:19 - 1.7 +++ .cvsignore 13 Jul 2010 16:26:08 - 1.8 @@ -1 +1 @@ -Class-C3-0.21.tar.gz +Class-C3-0.22.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Developers of packages please pay attention to selinux labeling.
On Tue, Jul 13, 2010 at 2:55 PM, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. > > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. Yeah updating (core!) packages like PackageKit without even testing it with the default setup *is* indeed unacceptable. Image a kernel update that eats your data on ext4 but has not been tested on it because the maintainer happens to run $othernondefaultfs (yes not really the same scale; but it shows how wrong this behavior is). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REMINDER: Test machine resources for package maintainers
On Sat, Jul 10, 2010 at 07:10:51PM -0600, Kevin Fenzi wrote: > Please see the above page or contact me directly for any more > information. Can you maybe add the fedora-packager group to the default set of installed packages? sudo yum install @fedora-packager Then useful tools like fedora-cvs (-a) and rpmdevtools are available. Regards Till pgpQhBURCuVfl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 612875] perl-Class-C3 FTBFS : BuildRequires Self!
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=612875 --- Comment #1 from Kevin Fenzi 2010-07-13 12:27:34 EDT --- Hey Chris. I went ahead and synced this over from devel to EL-6. I hope you don't mind... Just wanted to get a few things flowing. http://koji.fedoraproject.org/koji/taskinfo?taskID=2316827 Hopefully I didn't muck anything up. ;) -- 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: REMINDER: Test machine resources for package maintainers
On Tue, 13 Jul 2010 18:22:52 +0200 Till Maas wrote: > On Sat, Jul 10, 2010 at 07:10:51PM -0600, Kevin Fenzi wrote: > > > Recent changes include: > > > > - I have added a RHEL6b2 test machine. This may help EPEL-6 > > maintainers check for packages or test/debug their packages. > > Thank you very much. There seems to be a typo in the reverse DNS entry > for varen: > $ ssh varen.scrye.com > reverse mapping checking getaddrinfo for revan.scrye.com > [216.17.180.7] failed - POSSIBLE BREAK-IN ATTEMPT! Oops. Good catch. Should be fixed as soon as DNS change filters out. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 06:03 PM, Brian C. Lane wrote: > This is why I'm so surprised to see gpg be deprecated in f13. Upstream > is supporting both and the manpage even indicates that the binary should > be gpg2. > > I don't see any reason for it to have been removed in f13, and am > willing to help maintain it. We could also ask original maintainers of gnupg, if they are willing to co-maintain it. https://admin.fedoraproject.org/pkgdb/acls/name/gnupg > I've been a pgp and gpg user since the > early 90's, I attempted to port pgp to the Atari ST (unsuccessfully I > should note :) ) at one time. > > - -- > Brian C. Lane > Red Hat / Port Orchard, WA > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEVAwUBTDyONxF+jBaO/jp/AQIIbwf/dP0Vs740iJUke+0nAYXE3OO0Gwe6SHFm > kfMdGUAwNrRTIwSiwMkGrQNtOQN7XlbG2fkBVcyt4SWgRBJPDlRIXZgWRwjxfw7l > mptTwmhshhuwQjGS0mfaZJ1X1WF6voYwLxoOIMDEMB9d8+SP+4vFq22obkEqjU3w > RJUpSW2XJR9JCv6O8yQbBK2PbC++LIM4lJcmifBFLh1u2KjsuyejBMz4iL/ieCam > aO9fexC2y38hq9FPmQeyQdtUaak+z8vIEA6ZgHFqLxuCMUl3nlDE70kq4CnDDnz4 > 9gIhfWxWSc0lSQdW7UzU1eD9YNSNz7Q1IU4jx+aMcsbIi2eTQjdc5w== > =Vdl1 > -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 05:52 PM, Toshio Kuratomi wrote: > Having gpg1 and gpg2 seems reasonable to me. > > Note, though, that the problem is slightly more limited in scope. At least > with vim, if you have an X display, gpg2 will invoke the graphical pinentry > where you can enter your passphrase and go about your business. It's the same with Emacs. > Plain console, remote sessions that are not allowed to send the graphical > window back to the local session, and systems that don't have the graphical > pinentry programs installed will all experience this problem, though. Yes, exactly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REMINDER: Test machine resources for package maintainers
On Tue, 13 Jul 2010 18:27:22 +0200 Till Maas wrote: > On Sat, Jul 10, 2010 at 07:10:51PM -0600, Kevin Fenzi wrote: > > > Please see the above page or contact me directly for any more > > information. > > Can you maybe add the fedora-packager group to the default set of > installed packages? > > sudo yum install @fedora-packager > > Then useful tools like fedora-cvs (-a) and rpmdevtools are available. Sure, makes perfect sense. Done. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meeting logs enhancement
Greetings. Thanks to some scripting work from Mike Mcgrath, there's a enhancement to our meeting logs site available: You can now go to http://meetbot.fedoraproject.org/teams/ and see a per directory listing of meetings grouped by their meeting name. This would allow you for instance to see all the fesco meeting logs and browse them at your leisure, without having to find the right dates for meeting by going to: http://meetbot.fedoraproject.org/teams/fesco It's important that people running IRC meetings use the '#meetingname' command to name their meeting, and always keep the same name there so the logs appear under the same team name moving forward. Hopefully this helps people find and review logs of our meetings. kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting logs enhancement
On 07/14/2010 12:07 AM, Kevin Fenzi wrote: > Greetings. > > Thanks to some scripting work from Mike Mcgrath, there's a enhancement > to our meeting logs site available: > > You can now go to http://meetbot.fedoraproject.org/teams/ and see a per > directory listing of meetings grouped by their meeting name. This would > allow you for instance to see all the fesco meeting logs and browse > them at your leisure, without having to find the right dates for > meeting by going to: http://meetbot.fedoraproject.org/teams/fesco > This is nice. Would it be possible to enhance the meeting bot to send meeting minutes to the appropriate mailing lists automatically? Suggestion from http://www.cyber-anthro.com/?p=342 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/w3c-markup-validator/devel .cvsignore, 1.15, 1.16 sources, 1.15, 1.16 w3c-markup-validator.spec, 1.27, 1.28
Author: scop
Update of /cvs/pkgs/rpms/w3c-markup-validator/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv19766
Modified Files:
.cvsignore sources w3c-markup-validator.spec
Log Message:
* Tue Jul 13 2010 Ville Skyttä - 1.1-1
- Update to 1.1.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/w3c-markup-validator/devel/.cvsignore,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- .cvsignore 18 Jun 2010 20:29:08 - 1.15
+++ .cvsignore 13 Jul 2010 18:42:03 - 1.16
@@ -1 +1 @@
-w3c-markup-validator-1.0.tar.xz
+w3c-markup-validator-1.1.tar.xz
Index: sources
===
RCS file: /cvs/pkgs/rpms/w3c-markup-validator/devel/sources,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- sources 18 Jun 2010 20:29:08 - 1.15
+++ sources 13 Jul 2010 18:42:03 - 1.16
@@ -1 +1 @@
-5de17a8d57ebe79f51170d09865d5a5c w3c-markup-validator-1.0.tar.xz
+7bfa6a47123ac28c8847c121c799c527 w3c-markup-validator-1.1.tar.xz
Index: w3c-markup-validator.spec
===
RCS file: /cvs/pkgs/rpms/w3c-markup-validator/devel/w3c-markup-validator.spec,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -p -r1.27 -r1.28
--- w3c-markup-validator.spec 18 Jun 2010 20:29:09 - 1.27
+++ w3c-markup-validator.spec 13 Jul 2010 18:42:03 - 1.28
@@ -1,5 +1,5 @@
Name: w3c-markup-validator
-Version:1.0
+Version:1.1
Release:1%{?dist}
Summary:W3C Markup Validator
@@ -59,6 +59,7 @@ rm htdocs/images/markup_validation_servi
%patch2 -p1
%patch3 -p1
%patch4 -p1
+find . -type f -name "*.orig" -delete # patch backup files
mv htdocs/sgml-lib .
@@ -145,6 +146,9 @@ done
%changelog
+* Tue Jul 13 2010 Ville Skyttä - 1.1-1
+- Update to 1.1.
+
* Fri Jun 18 2010 Ville Skyttä - 1.0-1
- Update to 1.0, XML encoding fix applied upstream.
--
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: Meeting logs enhancement
On Wed, 14 Jul 2010 00:11:49 +0530 Rahul Sundaram wrote: > This is nice. Would it be possible to enhance the meeting bot to send > meeting minutes to the appropriate mailing lists automatically? > Suggestion from > > http://www.cyber-anthro.com/?p=342 I think it's on the upstream TODO list. Along with automatic posting to a wiki if requested. Will see where they are on that... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 13 July 2010 17:26, drago01 wrote: > Yeah updating (core!) packages like PackageKit without even testing it > with the default setup *is* indeed unacceptable. I did test it with SELinux enabled, but I don't run enforcing as it gets in my way as a developer. There was no message[1] in the SELinux Troubleshooter when installing or using the new package for me. Richard. [1] Well, there are 254 other messages about npviewer, wine and vlc, but I digress. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide perl-5.12 status
On 07/13/2010 10:33 AM, Marcela Mašláňová wrote: > On 07/08/2010 10:13 AM, Marcela Mašláňová wrote: >> BTW: We are talking about 4 packages, involving these 3 maintainers: >>> >>> perl-DBI-Dumper: Chris Weyl >>> perl-Data-Alias: Chris Weyl >>> perl-Pugs-Compiler: Steven Pritchard. >>> perl-Test-AutoBuild: Daniel Berrange >> > The ticket for rel-eng was created: > https://fedorahosted.org/rel-eng/ticket/3882 Thank you. Unfortunately, some well-known rel-eng deity immediately closed it. 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: measuring success
On 07/03/2010 06:50 AM, Till Maas wrote: > Also Bodhi does not allow to fix updates by other people than the update > submitter afaik. Anyone with commit privs to the rawhide branch of a package should be able to submit/edit updates for that package. Yes, it's not ideal, but that is how it is currently implemented. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: depcheck test (was Re: measuring success)
On 07/06/2010 04:09 PM, Till Maas wrote: > On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote: >> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote: >>> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote: On 7/6/10 8:52 AM, Till Maas wrote: > IMHO it should not be a +1 karma but some different flag that is set for > updates that passed the tests. Using karma is viewed as the path of least resistance to getting support in current bodhi for this. For future bodhi yes, it makes some sense to use some different flagging mechanism. >>> >>> Essentially using a different flag is just re-using the code used to >>> flag a package as critpath-approved only with a different name. >>> Therefore it should not need that much more effort. >> >> Feel free to help write the code to prove this point! >> >>> Btw. using the "path of least resistance" to implement policy >>> changes seems to be what makes the new workflows suck for package >>> maintainers, e.g. with the change in place using a auto-karma value of 1 >>> will become 0. >> >> Well that's only one *proposed* idea. We could just as easily have >> autoqa give a comment with neutral (0) karma on updates which pass, and >> -1 on failed updates, which would serve all the same purposes. That >> might be a better idea, actually. > > Using karma 0 the patch could be this one: > http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch This patch looks good at a first glance -- it's pretty much exactly what I was planning to do. The only tweak that is needed is to ensure that anonymous people can't pretend to be AutoQA: -if comment.author == "autoqa": +if not comment.anonymous and comment.author == "autoqa": This patch, along with my critpath/nofrozenrawhide/epel changes, avoid making database schema changes to bodhi. This makes it very easy to perform upgrades. For the TurboGears2 port of bodhi that is underway, these flags should definitely be proper columns in the db model. Another benefit of the TG2 port is we will be able to utilize the SQLAlchemy migration tools, which will allow us to change the schema as we need to, instead of hacking together these "path of least resistance" changes. Thank you for all of your help with Bodhi, Till. Your work is much appreciated. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On 07/06/2010 12:15 PM, Kevin Fenzi wrote: > On Sat, 03 Jul 2010 19:55:27 +0200 > Till Maas wrote: > >> On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote: >>> On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote: >>> I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. https://fedoraproject.org/wiki/Package_update_acceptance_criteria >>> >>> Btw. does Bodhi really work the way it is said there? What happens >>> if there are +1 and -1 karma values for an critpath update? >>> According to the criteria, -1 karma does not have any impact at all >>> except for all other updates, because they contain a karma >>> threshold. >> >> Interestingly the first critpath update I saw with f-e-k is not >> approved but should be according to the criteria: >> https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850 > > It doesn't have enough karma... it got: > > -1, +1, +1, for a total of 1. > > So, I guess it's not going to push without hitting +2. > > I've asked Luke to comment here and your parent post about how things > work, as I would love to know too. ;) Right now for a critical path update to gain approval, it must have a net karma of at least 2, including a +1 from a proventester, and +1 from another authenticated user. This is the behavior that was implemented and utilized during the No Frozen Rawhide pre-release stage of F13. If we want to change this behavior, that's fine with me. Let's discuss alternative solutions. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git testers wanted!
On 07/12/2010 05:28 PM, Jesse Keating wrote: > Thanks in advance! (and find me on IRC or file tickets against > fedora-packager in fedora hosted if you run into issues) fedpkg clone --branches fails. https://fedorahosted.org/fedora-packager/ticket/20 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: depcheck test (was Re: measuring success)
On Tue, Jul 13, 2010 at 03:55:46PM -0400, Luke Macken wrote: > This patch looks good at a first glance -- it's pretty much exactly what > I was planning to do. The only tweak that is needed is to ensure that > anonymous people can't pretend to be AutoQA: > > -if comment.author == "autoqa": > +if not comment.anonymous and comment.author == "autoqa": Yes, I thought about this later, too and forgot it again. But now I also remembered a second issue. If autoqa uses -1 comments to indicate that an update is not approved (anymore), then it must use +1 comments to indicate that they are approved (again) to not influence the karma. > This patch, along with my critpath/nofrozenrawhide/epel changes, avoid > making database schema changes to bodhi. This makes it very easy to > perform upgrades. For the TurboGears2 port of bodhi that is underway, > these flags should definitely be proper columns in the db model. > Another benefit of the TG2 port is we will be able to utilize the > SQLAlchemy migration tools, which will allow us to change the schema as > we need to, instead of hacking together these "path of least resistance" > changes. How long do think it will take till the TG2 port is ready? In the git tg2 branch there has not been any activity since February. If it is a very long term project, it might still be useful to keep the old bodhi code cleaner for easier maintenance. > Thank you for all of your help with Bodhi, Till. Your work is much > appreciated. Thank you, too. Regards Till pgpVp8FHnKM8x.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gdb index feature
We're going to be pushing in a new gdb feature that creates indices for the debuginfo. These indices are created by gdb, then merged into the executable or shared library using objcopy. This will be done as part of the find-debuginfo.sh script, run by RPM. The point of this change is that it greatly speeds up gdb startup. It also greatly reduces gdb memory use. I am not completely sure when all the work will appear in rawhide, but I wanted to send a short warning in case something is broken. If this process causes some problem, please report it against "gdb" in bugzilla, and somebody will look at it ASAP. thanks, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Tue, 2010-07-13 at 16:45 +0200, Nicolas Mailhot wrote: > Le 13/07/2010 15:30, Rahul Sundaram a écrit : > > > > On 07/13/2010 06:58 PM, Christopher Brown wrote: > >> No. SELinux is unacceptable when it displays ridiculous warning > >> messages to users telling them it has detected suspicious activity on > >> a system that has ONLY JUST BEEN INSTALLED. > >> > > > > That should have failed the release criteria as it is written > > currently. > > IIRC pyzor, for example, has never worked on an selinux system, as it > tries to write stuff in / (and no one has minded for many releases) If it's not installed by default, we don't care (as far as the release criteria go). The criterion Rahul is referencing is: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" from the final release criteria - https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria . The 'In most cases' is a standard weasel clause we use when we might want to not fix an issue that would technically breach the criteria if it would only show up in really odd circumstances - for instance, if you have to have three rare bits of hardware installed in conjunction before you'd hit the denial, or something like that. The test case for validating this criterion is: https://fedoraproject.org/wiki/QA:Testcase_desktop_error_checks note that it doesn't test non-default package sets, and doesn't test actively *running* applications, only booting to a default desktop. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 07/14/2010 02:46 AM, Adam Williamson wrote: > > The test case for validating this criterion is: > > https://fedoraproject.org/wiki/QA:Testcase_desktop_error_checks > > note that it doesn't test non-default package sets, and doesn't test > actively *running* applications, only booting to a default desktop. > I think we need to change that to actively run and test the default applications that are accessible from the menu. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On 13/07/10 16:57, Matěj Cepl wrote: > Dne 13.7.2010 17:33, Pádraig Brady napsal(a): >> Personally I do momentarily enable to test but always disable >> because of _hundreds_ of errors in the applet thingy. > > Hundreds? I have been running RHEL-6 from mid-Januray (that means > Rawhide was quite stable comparing to it) with SELinux in the Enforcing > mode with even special SELinux user staff_u and I just don't see > *hundreds* bugs on day-to-day basis. I was very faithful in filing ALL > SELinux issues to bugzilla and I am quite sure it wasn't hundred so far. To be clear, the "hundreds" contained many duplicates. I'm not complaining since I haven't looked into any of these issues, I'm just trying to provide insight into why SELinux might not be as tested as one would like. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary for today's FESCo meeting (2010-07-13)
=== #fedora-meeting: FESCO (2010-07-13) === Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-07-13/fesco.2010-07-13-19.30.log.html Meeting summary --- * init process (nirik, 19:30:01) * mclasen is unable to attend today, and will be out the next 2 weeks as well. ;( (nirik, 19:30:28) * #351 Create a policy for updates - status report on implementation (nirik, 19:32:48) * LINK: https://fedoraproject.org/wiki/Bodhi (nirik, 19:33:26) * #382 Implementing Stable Release Vision (nirik, 19:37:43) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas#Stable_releases_should_provide_a_consistent_user_experience_throughout_the_lifecycle.2C_and_only_fix_bugs_and_security_issues (nirik, 19:39:23) * #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 (nirik, 19:50:06) * AGREED: xo 1.0 should be added to release critera and tested for the next cycle. (nirik, 19:57:19) * #416 Set EOL Date For Fedora 12 (nirik, 19:58:45) * AGREED: 29th is fine for f12 EOL. (nirik, 20:04:02) * #418 Packager jgarzik violated Fedora Packaging (Review) Policy (nirik, 20:04:16) * AGREED: no sanctions at this time (nirik, 20:09:55) * #409 Feature Request: GNUstep (nirik, 20:11:36) * LINK: https://fedoraproject.org/wiki/Talk:Features/GNUstep (nirik, 20:12:24) * AGREED: defer for another week for more info. (nirik, 20:16:16) * #413 F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming (nirik, 20:16:20) * AGREED: This feature is approved (nirik, 20:20:15) * #419 F14Feature: DebugpythonStacks - http://fedoraproject.org/wiki/Features/DebugPythonStacks (nirik, 20:20:30) * AGREED: This feature is approved (nirik, 20:22:36) * #420 F14Feature: EC2 - http://fedoraproject.org/wiki/Features/EC2 (nirik, 20:23:08) * AGREED: This feature is approved (nirik, 20:28:22) * #421 F14Feature: Gdbindex - http://fedoraproject.org/wiki/Features/GdbIndex (nirik, 20:28:41) * AGREED: This Feature is approved. (nirik, 20:32:26) * #422 F14Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3 (nirik, 20:33:51) * AGREED: This Feature is approved. (nirik, 20:40:50) * #423 F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik, 20:41:03) * LINK: http://sourceware.org/bugzilla/show_bug.cgi?id=11805 is the prelink issue (mclasen, 20:44:54) * AGREED: defer and ask for more info on this feature. (nirik, 20:48:52) * #424 F14Feature: netbeans 6.9 - http://fedoraproject.org/wiki/Features/NetBeans_6.9 (nirik, 20:49:08) * AGREED: This Feature is approved. (nirik, 20:53:31) * #425 F14Feature: OpenSCAP - http://fedoraproject.org/wiki/Features/OpenSCAP (nirik, 20:53:41) * AGREED: This Feature is approved. (nirik, 20:56:34) * #426 F14Feature: Rakudo Star - http://fedoraproject.org/wiki/Features/Rakudo_Star (nirik, 20:56:56) * AGREED: Feature is approved. (nirik, 21:01:46) * #427 F14Feature: Spice - http://fedoraproject.org/wiki/Features/Spice (nirik, 21:01:58) * AGREED: This Feature is approved. (nirik, 21:08:32) * FES tickets roundup. (nirik, 21:08:40) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 21:09:01) * Open Floor (nirik, 21:14:32) Meeting ended at 21:25:21 UTC -- 19:30:01 #startmeeting FESCO (2010-07-13) 19:30:01 Meeting started Tue Jul 13 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 #meetingname fesco 19:30:01 The meeting name has been set to 'fesco' 19:30:01 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 #topic init process 19:30:01 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:06 Afternoon 19:30:11 evening. 19:30:18 night. 19:30:28 #info mclasen is unable to attend today, and will be out the next 2 weeks as well. ;( 19:30:31 i reject your classist linear notion of time 19:30:43 on that note, i'll be gone next week as well. 19:31:02 as will i! 19:31:52 ok. 19:31:53 * cwickert is here 19:32:05 afternoon all 19:32:37 ok, lets go ahead and get started I guess... 19:32:48 #topic #351 Create a policy for updates - status report on implementation 19:32:49 .fesco 351 19:32:50 nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:33:07 lmacken wrote up some bodhi karma stuff 19:33:26 https://fedoraproject.org/wiki/Bodhi 19:33:38 jlaska: any new news on autoqa? 19:33:46 sorry, i didn't get around to writing up my bit this week. :\ 19:33:50 do we wish to adjust the current karma settings? or leave them as-is for now? 19:34:00
Re: Developers of packages please pay attention to selinux labeling.
On Tue, Jul 13, 2010 at 8:55 AM, Daniel J Walsh wrote: > If you are changing the locate of an executable or libraries the > executables write to, please make sure SELinux labels are still > consistant or contact the selinux developers for help. IF you update a > package in a released version of Fedora and change the locations you > MUST make sure it still works with selinux in enforcing mode. > > packagekit got released this to F13 and Rawhide this week and changed > its location. packagekitd should be labeled rpm_exec_t, Since it moved > it got the default label and is now running unconfined. This causes > labels to get screwed up and lots of bugs are being reported on it. It > gives SELinux a bad name. And it makes our user community mad. SELinux > has been around a long time. Packages should be using it at least in > testing. This is unacceptable. > Please write up a guideline proposal, stating what needs to be checked on an update by the packager, and submit it to FPC. I am sure that they will consider it, and it will make things clear for packagers. Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
Dne 13.7.2010 23:17, Pádraig Brady napsal(a): > To be clear, the "hundreds" contained many duplicates. > I'm not complaining since I haven't looked into any > of these issues, I'm just trying to provide insight > into why SELinux might not be as tested as one would like. Just to note, that setroubleshooter thingy is MUCH better in resolving duplicates than abrt ... no surprise, it has much more structured and smaller text to compare. Matěj -- Somewhere at the edge of the Bell curve was the girl for me. -- Based on http://xkcd.com/314/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: depcheck test (was Re: measuring success)
On 07/13/2010 04:59 PM, Till Maas wrote: > On Tue, Jul 13, 2010 at 03:55:46PM -0400, Luke Macken wrote: >> This patch looks good at a first glance -- it's pretty much exactly what >> I was planning to do. The only tweak that is needed is to ensure that >> anonymous people can't pretend to be AutoQA: >> >> -if comment.author == "autoqa": >> +if not comment.anonymous and comment.author == "autoqa": > > Yes, I thought about this later, too and forgot it again. But now I also > remembered a second issue. If autoqa uses -1 comments to indicate that > an update is not approved (anymore), then it must use +1 comments to > indicate that they are approved (again) to not influence the karma. Yep, good call. >> This patch, along with my critpath/nofrozenrawhide/epel changes, avoid >> making database schema changes to bodhi. This makes it very easy to >> perform upgrades. For the TurboGears2 port of bodhi that is underway, >> these flags should definitely be proper columns in the db model. >> Another benefit of the TG2 port is we will be able to utilize the >> SQLAlchemy migration tools, which will allow us to change the schema as >> we need to, instead of hacking together these "path of least resistance" >> changes. > > How long do think it will take till the TG2 port is ready? In the git > tg2 branch there has not been any activity since February. If it is a > very long term project, it might still be useful to keep the old bodhi > code cleaner for easier maintenance. I'd like to have it in beta testing phase by F14, but we'll see how that goes. The current tg2 branch has the entire model ported to SQLAlchemy, with a variety of improvements, and a lot of the test suite is ported over as well. The next step is to port the controllers & templates. I've been holding off on doing this for little while, as I have been doing a lot of bugfixing in the current branch, and I want to avoid having two out-of-sync code bases. However, we're pretty much at the point where I'm about ready to freeze the current branch and start porting the controllers over in the very near future. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Tue, 2010-07-13 at 16:33 +0100, Pádraig Brady wrote: > On 13/07/10 15:47, Tomasz Torcz wrote: > > On Tue, Jul 13, 2010 at 03:11:44PM +0100, Christopher Brown wrote: > >>> > >>> As long as you give us a heads up we can prevent these types of blowups. > >>> Since this policy is shared between yum, packagekit > >> > >> Whilst I appreciate your huge efforts to provide users with a more > >> secure system, you need to realise that SELinux as it stands at the > >> moment is utterly broken. As you clearly don't think this is the case, > >> please spend some time in userland before beating on developers for > >> not caring about this. > > > > > > On the other hand, I cannot understand why packagers submit packages that > > have no chance to work in default Fedora settings, with SELinux in > > Enforcing mode. > > Nobody I know enables SELinux. > smolt says about half leave it enabled: > http://smolts.org/static/stats/stats.html > But I'm guessing a lot of experienced users/devs > disable it given previous experiences... > It's a bit of a catch 22 really. > > Personally I do momentarily enable to test but always disable > because of _hundreds_ of errors in the applet thingy. > Enabling in non enforcing mode causes a huge performance hit, > causing for example the "do you want to kill" dialog to pop up > when I try to quit firefox. I have it enabled all the time on all my machines, and have never seen either problem. I only get a small number of alerts, which I always report to Bugzilla. I find Dan usually fixes them very quickly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Wed, 2010-07-14 at 02:53 +0530, Rahul Sundaram wrote: > On 07/14/2010 02:46 AM, Adam Williamson wrote: > > > > The test case for validating this criterion is: > > > > https://fedoraproject.org/wiki/QA:Testcase_desktop_error_checks > > > > note that it doesn't test non-default package sets, and doesn't test > > actively *running* applications, only booting to a default desktop. > I think we need to change that to actively run and test the default > applications that are accessible from the menu. That's sort of covered in https://fedoraproject.org/wiki/QA:Testcase_desktop_menus . I didn't explicitly mention the apps should run without AVCs, but I would probably have considered it a blocker bug if I'd actually hit a case where an AVC popped up when doing that test. We could discuss adding it explicitly to that case and the criteria, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting logs enhancement
On Tue, 2010-07-13 at 12:48 -0600, Kevin Fenzi wrote: > On Wed, 14 Jul 2010 00:11:49 +0530 > Rahul Sundaram wrote: > > > This is nice. Would it be possible to enhance the meeting bot to send > > meeting minutes to the appropriate mailing lists automatically? > > Suggestion from > > > > http://www.cyber-anthro.com/?p=342 > > I think it's on the upstream TODO list. Along with automatic posting to > a wiki if requested. > > Will see where they are on that... This should probably be opt-in, since many groups already have more refined manual processes for handling meeting recaps. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Tue, 2010-07-13 at 16:00 -0400, Luke Macken wrote: > > I've asked Luke to comment here and your parent post about how things > > work, as I would love to know too. ;) > > Right now for a critical path update to gain approval, it must have a > net karma of at least 2, including a +1 from a proventester, and +1 from > another authenticated user. This is the behavior that was implemented > and utilized during the No Frozen Rawhide pre-release stage of F13. > > If we want to change this behavior, that's fine with me. Let's discuss > alternative solutions. That's broadly how we already agreed it should work, at FESCo level. I have asked FESCo to consider how to handle the case where negative karma is provided, though. Particularly negative karma from a proven tester. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] systemd for F14 - the next steps
Heya, as many of you probably know systemd got accepted as feature for F-14 by FESCO a few weeks back. https://fedoraproject.org/wiki/Features/systemd And in case you want to read up what systemd actually is, here's the blog post that introduced it (only slightly out-of-date, we have however advanced a bit since then): http://0pointer.de/blog/projects/systemd.html Since the acceptance by FESCO it has been added to Rawhide together with patched or updated versions of a few related packages. However, what has not been done so far is making it the default in Rawhide. So far it does not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I want to notify everybody that I am planning to do this change very soon now (tomorrow?). Then, systemd will be pulled in onto your rawhide system and is used exclusively for booting (so far, you can still choose between it and upstart in grub, with a default on upstart), and problems booting should be reported to systemd in rhbz then. At this point the following packages in rawhide have been updated to provide socket based activation [Hint: in case you are wondering, socket activation is one of the amazing things in systemd, see the original announcement for details]: dbus, udev, avahi, rtkit. Before F14 I want to at least add rpcbind and rsyslog to this list for socket based activation, and most likely cups. For rpcbind/rsyslog the patches have been submitted upstream, and even have partly been merged already). It would be great if we could ship native unit files (as replacement for the current sysvinit scripts) for as many packages in Fedora as we can for F14, and in particular for all those services that are installed by default. [Hint: unit files is the systemd term for files describing services (i.e. daemons) and other objects systemd starts and maintains]. I have prepared native unit files for the majority of services of the default install, and will now post them on bugzilla piece by piece for inclusion in the rpms. Ideally, those unit files are shipped upstream, but they can be added in the rpms too. Unit files are usually very short for normal services and should be easy to write (i.e. you don't have to think about dependencies or any complexities like that at all in most cases, unless you want to do fancy stuff involving early boot or late shut down). Unit files should be written for daemons that currently install SysV init scripts and also (and this matters!) for all services currently started via D-Bus bus activation. Writing native unit files enables the radical form of parallelization that systemd employs. Units without native unit files, i.e. only SysV or D-Bus service files, will only benefit from very minimal parallelization. Note that neither patching in socket based activation, nor shipping native unit files will break services in a non-systemd boot up. In order to keep our options open to possibly revert things before F14 we explciitly made sure not to break compatibility with non-systemd boots. i.e. the socket actviation patches become NOPs if systemd is not running and the native unit files are ignored, so that only sysv init scripts matter. Also note that even in the case that we do roll back to upstart before the release of F14 this work won't be in vain, as work that has been done has been done and will then becom euseful when we adopt systemd in the next cycle. I want to stress though that at this point in time I see no reason to assume that we shouldn't make it for F14. So, here's my call for help, in order to make this all a big success: a) if you maintain a package which includes a daemon/service from the default install, expect a proposed unit file in bugzilla soon. Would be awesome if you could check it and add it to your RPM. Even better would be if you get it merged upstream. I have unit files the majority of these services. Ping me on irc (#systemd on fdo, I'm 'mezcalero'), if you wonder whether yours is one of them, and if you have questions. b) if you maintain a package which includes a daemon/service from outside the default install, it would be awesome if you could ship native unit files too, even though I don't have any ready for you. Writing unit files is not difficult, and should be well documented in the man pages. In particular have a look daemon(7), i.e. http://0pointer.de/public/systemd-man/daemon.html and related man pages. A good example for a systemd-enabled RPM for a D-Bus service is rtkit. You might want to check it out and its .spec file: http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?view=markup A good example for a systemd-enabled RPM for a service that currently installs a SysV init script, checkout Avahi and its .spec file: http://cvs.fedoraproject.org/viewvc/devel/avahi/avahi.spec?view=markup Some package could use the native unit love more than others. For example, I have seen terrible things done to daemonize processes and drop privs in pure shell (the bittorrent packages as one exa
Re: Developers of packages please pay attention to selinux labeling.
Adam Williamson wrote: >On Tue, 2010-07-13 at 16:33 +0100, Pádraig Brady wrote: >> On 13/07/10 15:47, Tomasz Torcz wrote: >> > On Tue, Jul 13, 2010 at 03:11:44PM +0100, Christopher Brown wrote: >> >>> >> >>> As long as you give us a heads up we can prevent these types of blowups. >> >>> Since this policy is shared between yum, packagekit >> >> >> >> Whilst I appreciate your huge efforts to provide users with a more >> >> secure system, you need to realise that SELinux as it stands at the >> >> moment is utterly broken. As you clearly don't think this is the case, >> >> please spend some time in userland before beating on developers for >> >> not caring about this. >> > >> > >> > On the other hand, I cannot understand why packagers submit packages that >> > have no chance to work in default Fedora settings, with SELinux in >> > Enforcing mode. >> >> Nobody I know enables SELinux. >> smolt says about half leave it enabled: >> http://smolts.org/static/stats/stats.html >> But I'm guessing a lot of experienced users/devs >> disable it given previous experiences... >> It's a bit of a catch 22 really. >> >> Personally I do momentarily enable to test but always disable >> because of _hundreds_ of errors in the applet thingy. >> Enabling in non enforcing mode causes a huge performance hit, >> causing for example the "do you want to kill" dialog to pop up >> when I try to quit firefox. > >I have it enabled all the time on all my machines, and have never seen >either problem. I only get a small number of alerts, which I always >report to Bugzilla. I find Dan usually fixes them very quickly. >-- >Adam Williamson >Fedora QA Community Monkey >IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org >http://www.happyassassin.net > >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
On Sat, 2010-07-10 at 12:47 -0800, Jeff Spaleta wrote: > That being said. I really really think that its only appropriate for > someone who has talked specifically to the maintainers of a package to > make that sort of wontfix closure judgement and to do the closure. I > do not think its best practise for others to attempt to act as good > Samaritans to WONTFIX/CANTFIX closures of this nature. [...] Now that the WONTFIX resolution has been thorougly discredited, would someone with the power please reopen the bug? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
On Sun, 2010-07-11 at 13:22 +0200, Christoph Wickert wrote: > Am Sonntag, den 11.07.2010, 06:14 +0200 schrieb Kevin Kofler: > > Matt McCutchen wrote: > > > I don't know if Fedora has an official stance documented somewhere, but > > > I personally would support Eric's viewpoint. A Fedora maintainer should > > > be responsible for all the bugs in the package, even if that just means > > > forwarding them upstream. > > It is indeed documented in the wiki: "If there are bugs which you aren't > capable of fixing yourself because they deal with intricacies of the > source code which you don't fully understand, then you still need to > address these bugs. It can be helpful to work with the upstream > maintainer of the code, ..." > see http://fedoraproject.org/wiki/Package_maintainer_responsibilities It's not clear to me whether that refers to true upstream bugs or only to Fedora-specific bugs that are too intricate to solve without upstream help. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
