Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
W dniu 25 października 2011 08:32 użytkownik Matej Cepl mc...@redhat.com napisał: Dne 24.10.2011 22:27, Michał Piotrowski napsal(a): Yeah, this solution has its drawbacks, but it also has undoubted advantages. I am probably dumb, but could you tell me some *undoubted* advantage of using #!/usr/bin/env sh You can alias sh to other shell. I need to use this from time to time on some servers, for example alias php='/usr/local/php5.3/bin/php -c /usr/local/directadmin/data/users/ehorizon/php/eventhorizon.pl/php53.ini' PATH=/usr/local/php5.3/bin:$PATH Without this trick I would not be able to use php 5.3 cli on my shared hosting. (note, that couple of years ago, we were removing /usr/bin/env python from all Python scripts in Fedora packages, and replacing them with /usr/bin/python, because it was (rightly) agreed, that the moment Fedora doesn't have Python in /usr/bin we have much bigger problems to solve). Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Matej Cepl mc...@redhat.com: Dne 24.10.2011 22:48, Michał Piotrowski napsal(a): For example - you can switch to different version of language interpreter with different configuration without modification of the script and without the hassle for server admin. So, because you haven't learned about ln(1) yet, Sometimes you have no control over the server that you are using. we all have to wait for the moment, where yum (for example) gets broken, because of some random bug in some random version of python in /usr/local/bin? Awesome! I not suggested to use this in Fedora scripts, but generally it's verry usefull. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:02 AM, Harald Hoyer wrote: On 10/24/2011 08:05 PM, Chris Adams wrote: === #fedora-meeting: FESCO (2011-10-24) === * Discussion about https://fedoraproject.org/wiki/Features/UsrMove (t8m, 17:26:45) This sounds interesting (speaking as an admin that typically sets up servers with separate, ro-mounted, /usr). I'm not sure about moving _everything_ to /usr, but I guess that's one approach. Other Unix systems I've used have had /bin as a symlink to /usr/bin, but not /sbin (still kept core system maintenance tools in /sbin on root fs). I'm also not sold on eliminating sbin directories (I like having system admin type stuff kept separate), and I don't see why that needs to be rolled into the same feature (especially as just a footnote, not a top-line change). What does it gain to have /sbin and /usr/sbin? Not molest ordinary users with tools they are not supposed to used. Security through obscurity? Right, yes. We already have it in $PATH for the normal user. Right, Fedora made the mistake to do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/24/2011 08:27 PM, Miloslav Trmač wrote: 2011/10/24 Michał Piotrowskimkkp...@gmail.com: Hi, 2011/10/24 Chris Adamscmad...@hiwaay.net: * Discussion about https://fedoraproject.org/wiki/Features/UsrMove (t8m, 17:26:45) Cool idea. Next I suggest to stop using /bin /sbin /lib /lib64 in F19, and not to create these links on freshly installed systems in F20. What about * the FHS? * #! /bin/sh in thousands of existing scripts? If anything, wouldn't it make more sense to move stuff in the opposite direction, from /usr/bin to /bin ? usr doesn't really mean anything - originally it was used because the filesystem format couldn't support more than 64MB(?) in a single volume, so the system had to be split to / and /usr. You want your OS in one directory and not split in 4 toplevel directories. Also, Fedora already sort-of has a system for stateless OS images - see /etc/sysconfig/readonly-root. What will happen to it? It does not go away with this feature. And more importantly, what is the overall benefit to our users? I can't find anything compelling in the Benefit to Fedora section (if /usr/ can be snapshotted, why not / ?); AFAICT this requires changing 257 packages for mostly aesthetic reasons. Mirek It's not only an aesthetic issue. This enables possibilities, which were not doable before. - snapshot /usr (with btrfs) - hot swap the OS (/usr) with another version - mount /usr ro and keep the rootfs writeable - share the _whole_ OS with other machines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/24/2011 10:12 PM, Michał Piotrowski wrote: In any case #!/usr/bin/env sh seems to be more portable solution. please :) you can propose this as a separate feature for F18 :) Let's see, if it gets accepted :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Harald Hoyer harald.ho...@gmail.com: [ ... ] - mount /usr ro and keep the rootfs writeable Which problem does this actually solve? People keep repeating that like forever as if it is a magic bullet to solve something. But it is a nice gimmick not more. And no it does not add any security. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. - snapshot /usr (with btrfs) - hot swap the OS (/usr) with another version - mount /usr ro and keep the rootfs writeable - share the _whole_ OS with other machines - mount rootfs encrypted - mount /usr not encrypted (no secrets here) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
W dniu 25 października 2011 09:20 użytkownik Harald Hoyer har...@redhat.com napisał: On 10/24/2011 10:12 PM, Michał Piotrowski wrote: In any case #!/usr/bin/env sh seems to be more portable solution. please :) you can propose this as a separate feature for F18 :) Let's see, if it gets accepted :) Ok, no problem. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
That's strange: the only two occasion I had a failed OTP were: 1) A configuration problem: (Yubikey not enabled, yubikey prefix not correct, using unburned key) 2) In a two slot configuration, whenever I press the button too long and it generates an OTP from the second slot If you are sure that's not your case, maybe filing a bug would be of help? HTH Mario On 24 October 2011 15:34, Paul Wouters p...@xelerance.com wrote: On Mon, 24 Oct 2011, Mario Ceresa wrote: why is it failing? That's what I wanted to know. The FAS website just says failed OTP did you reburn your yubikey with fedora-burn-yubikey and activated it in your FAS profile? Yes, even using the latest rawhide versions of the yubikey related packages to work around the libusb issues. Paul -- 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: BEWARE: a problematic glibc made it to stable (F16)
On Mon, Oct 24, 2011 at 10:46:31AM -0700, Adam Williamson wrote: On Mon, 2011-10-24 at 18:50 +0200, Kevin Kofler wrote: Adam Williamson wrote: We have lots of suggestions. As I've said at least fifty times, it's pointless going too far with the slapping of band-aids on the current karma system, because it's fundamentally too simplistic: it's never going to be perfect and there is a definite point of diminishing returns if we keep screwing with it. Right. That's why we need to abolish it. Why? How would that make anything better? With the proven tester system, one somewhat-broken update got through. Without it, we would have had five or six utterly broken glibc updates this F16 cycle. Just check the history of submissions to glibc in Bodhi. Given the known attitudes of the glibc maintainers, if they were allowed to simply submit all their builds directly to stable, they would certainly have done so...and broken everyone's systems time and time again. I'd say the history of F16 updates to glibc demonstrates the raging success of the proventesters system, not its failure. You snipped the part where Kevin wrote [...] if the maintainer demonstrates incompetence at taking these decisions, the offending maintainer needs to be replaced. The problem here appears to be a human one, not something that software is going to fix any time soon. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Mon, Oct 24, 2011 at 11:34:46PM +0200, Jim Meyering wrote: Jim Meyering wrote: Adam Williamson wrote: ... The only breakage in one which was approved was to do with compiling things - which, sure, is a pain in the ass, but it's not the kind of problem critpath was introduced to deal with in the first place. The problem is bigger than it first seemed, and still not fixed. True, I noticed the problem initially when running a just-built git, but in fact the distributed /usr/bin/git demonstrates precisely the same heap corruption as the one I built. See the further discussion on http://bugzilla.redhat.com/747377 The underlying bug seems pthread-related. When I make git grep run without using threads there is no problem. To demonstrate the problem, run this on a multi-core system, in a clone of a decent-sized git repository like git's own: for i in $(seq 100);do echo $i; timeout 1 ./git grep -q stat;done Oops. Drop the ./, of course, to test /usr/bin/grep: I think you mean /usr/libexec/git-core/git-grep :-) I'm not convinced yet this is a glibc issue. It could be a problem in the threaded work-queue code in git-grep which is just exposed by the change in glibc. No one will know until we finally diagnose the bug. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. right, but still a lot of files in /lib* /sbin and /bin, which do not need encryption here. Having all in /usr make the thing so much cleaner... Just to give you some food for thought: Next steps could include to only allow /usr prefixed files in Fedora rpms. /var and /etc could be setup with tempfiles and config templates. So our OS (set up by rpms) only lives in /usr. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 2011-10-25, Michał Piotrowski mkkp...@gmail.com wrote: 2011/10/25 Matej Cepl mc...@redhat.com: Dne 24.10.2011 22:48, Michał Piotrowski napsal(a): For example - you can switch to different version of language interpreter with different configuration without modification of the script and without the hassle for server admin. So, because you haven't learned about ln(1) yet, Sometimes you have no control over the server that you are using. There are systems allowing users to select interpreter from preinstalled versions (e.g. eselect in Gentoo). Something like alternatives in Fedora but per user. This a thing I miss in Fedora. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
Francois: you should already be able to use yubikey for FAS, bodhi and ssh. You don't need the yubikey prompt: just put your username, go to the password field and then press the key's button. Regards, Mario On 25 October 2011 10:13, François Kooman fkoo...@tuxed.net wrote: On 10/24/11 3:34 PM, Paul Wouters wrote: Yes, even using the latest rawhide versions of the yubikey related packages to work around the libusb issues. My problem was, maybe I'm just stupid, that I assumed that a successful test of the Yubikey in the FAS web interface would enable Yubikey authentication. This is not true, you have to manually enable the Yubikey functionality first (by clicking edit, Active: enabled, filling in the prefix (press the button on yubikey to automatically do that) before being able to test the Yubikey (Test Auth). Now if only I could use the Yubikey to login to FAS, Bodhi or SSH (non of them ask for yubi auth)... Regards, François -- 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: yubikey
On 10/25/11 10:23 AM, Mario Ceresa wrote: Francois: you should already be able to use yubikey for FAS, bodhi and ssh. You don't need the yubikey prompt: just put your username, go to the password field and then press the key's button. Really? That seems weird. If someone takes my key they would be able to login? I would expect it to be two-factor authentication (username password + yubikey). (I'm unable to test right now as I don't have my yubi with me) Regards, François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: retire referencer in Fedora 16+ ?
On Mon, 2011-10-24 at 15:46 -0400, Alex Lancaster wrote: My sentiments exactly. Better not to keep known broken packages around; it's only going to cause grief for users if they find out they can't even install the package. Once it's fixed upstream to not rely on libgnomeuimm, it can easily be added back to Fedora. Alex, could you please follow the End of Life procedure to get it removed from F16+? http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife Done: retired package in packagedb, removed files in git and filed rel-eng bug: https://fedorahosted.org/rel-eng/ticket/4962 (Will check comps now, to make sure it's removed from there too, if present). Alex Hi, Just wondering if we have another reference tool in the repos? Anyone? -- Thanks, Regards, Ankur: FranciscoD http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ 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: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 09:56:19AM +0200, Harald Hoyer wrote: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. right, but still a lot of files in /lib* /sbin and /bin, which do not need encryption here. Having all in /usr make the thing so much cleaner... Just to give you some food for thought: Next steps could include to only allow /usr prefixed files in Fedora rpms. /var and /etc could be setup with tempfiles and config templates. So our OS (set up by rpms) only lives in /usr. I really think this is something that should be discussed across all (or at least more than 1) distro. This change will have all sorts of repercussions with thousands of upstreams. Luckily there are forums and standards bodies for cross-distro discussions of this sort. Some of these are imperfect, a few like FSB are mostly dead, but that's a good reason to fix those organizations, not to go it alone. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 748771] New: perl-Mozilla-CA-20111025 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Mozilla-CA-20111025 is available https://bugzilla.redhat.com/show_bug.cgi?id=748771 Summary: perl-Mozilla-CA-20111025 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Mozilla-CA AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 20111025 Current version in Fedora Rawhide: 20110914 URL: http://search.cpan.org/dist/Mozilla-CA/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 748770] New: perl-Module-Runtime-0.011 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Module-Runtime-0.011 is available https://bugzilla.redhat.com/show_bug.cgi?id=748770 Summary: perl-Module-Runtime-0.011 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Module-Runtime AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 0.011 Current version in Fedora Rawhide: 0.010 URL: http://search.cpan.org/dist/Module-Runtime/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 746941] perl-Mojolicious-2.10 is available
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=746941 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-2.09 is|perl-Mojolicious-2.10 is |available |available --- Comment #5 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-10-25 06:42:59 EDT --- Latest upstream release: 2.10 Current version in Fedora Rawhide: 1.99 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Christoph. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Mozilla-CA-20111025.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Mozilla-CA: 74026b1a7aa0de8fc17d81efb3629195 Mozilla-CA-20111025.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mozilla-CA] Cache source tar ball.
commit a26a526760523bea2d4f5bfd3bb0ae7d7cf51a03 Author: Petr Písař ppi...@redhat.com Date: Tue Oct 25 13:54:05 2011 +0200 Cache source tar ball. .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index 69afc77..33952a1 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ /Mozilla-CA-20110409.tar.gz /Mozilla-CA-20110904.tar.gz /Mozilla-CA-20110914.tar.gz +/Mozilla-CA-20111025.tar.gz diff --git a/sources b/sources index bc55b2f..9186574 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -10774d7598c8bb2c242669648ff663e3 Mozilla-CA-20110914.tar.gz +74026b1a7aa0de8fc17d81efb3629195 Mozilla-CA-20111025.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
[Bug 748770] perl-Module-Runtime-0.011 is available
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=748770 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED CC|ppi...@redhat.com | Fixed In Version||perl-Module-Runtime-0.011-1 ||.fc17 Resolution||RAWHIDE Last Closed||2011-10-25 07:49:58 -- 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: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Harald Hoyer harald.ho...@gmail.com: If anything, wouldn't it make more sense to move stuff in the opposite direction, from /usr/bin to /bin ? usr doesn't really mean anything - originally it was used because the filesystem format couldn't support more than 64MB(?) in a single volume, so the system had to be split to / and /usr. You want your OS in one directory and not split in 4 toplevel directories. I'd actually find it more natural to have _my data_ (whatever data means here, probably including httpd configuration and ssh keys - and defining this well is probably a difficult problem) in one directory and not all over / . I can rebuild the system anytime, and in a sense I don't really care about the system, but I need to backup my data. Also, Fedora already sort-of has a system for stateless OS images - see /etc/sysconfig/readonly-root. What will happen to it? It does not go away with this feature. Does it make sense to have two separate facilities for stateless OS images? How do they interact? When do I use one instead of the other? And more importantly, what is the overall benefit to our users? I can't find anything compelling in the Benefit to Fedora section (if /usr/ can be snapshotted, why not / ?); AFAICT this requires changing 257 packages for mostly aesthetic reasons. It's not only an aesthetic issue. This enables possibilities, which were not doable before. - snapshot /usr (with btrfs) If my stateful data were mounted to /var/lib/*, why couldn't I snapshot the read-only / volume just as easily? - hot swap the OS (/usr) with another version Can I really do that when various processes will be running and have /usr/lib*/libc.so.* mapped? - mount /usr ro and keep the rootfs writeable OK... but again, we supposedly have that functionality with /etc/sysconfig/readonly-root. - share the _whole_ OS with other machines ... as long as I manage to update the configuration in /etc at the same time I update the OS image. Perhaps possible, but non-trivial. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: retire referencer in Fedora 16+ ?
On Tue, Oct 25, 2011 at 12:11 PM, Ankur Sinha sanjay.an...@gmail.com wrote: Hi, Just wondering if we have another reference tool in the repos? Anyone? Bibus, pybliographer? Zoltan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Am 25.10.2011 13:45 schrieb Christoph Trassl fed...@trassl.net: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Christoph. I was more thinking about Laptop loss here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rwhide: Last Kernel not booting in vmware
Am 24.10.2011 12:45, schrieb Josh Boyer: On Sat, Oct 22, 2011 at 5:18 PM, Reindl Harald h.rei...@thelounge.net wrote: Linux rawhide.vmware.local 3.1.0-0.rc9.git0.0.fc17.x86_64 #1 SMP Wed Oct 5 14:37:47 this is the last kernel booting in vmware for me all following see screenshot Make sure your grub config file has an initrd line for that kernel. It doesn't seem like an initramfs is getting run. ___ you are right adding the missing line and 3.1.0-0.rc10.git0.1.fc17.x86_64 boots thank you! title Fedora (3.1.0-0.rc10.git0.1.fc17.x86_64) root (hd0,0) kernel /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 ro root=UUID=9b4bf81a-5b1e-4922-b0d1-e6b65e9b61f9 nodmraid selinux=0 scsi_mod.scan=sync elevator=noop notsc divider=10 clocksource=acpi_pm noswapaccount cgroup_disable=memory noisapnp noresume nodomains nobar norom printk.time=0 thermal.off=1 nosmp nolapic noapic SYSFONT=latarcyrheb-sun16 LANG=de_DE.UTF-8 KEYTABLE=de-latin1-nodeadkeys title Fedora (3.1.0-0.rc9.git0.0.fc17.x86_64) root (hd0,0) kernel /vmlinuz-3.1.0-0.rc9.git0.0.fc17.x86_64 ro root=UUID=9b4bf81a-5b1e-4922-b0d1-e6b65e9b61f9 nodmraid selinux=0 scsi_mod.scan=sync elevator=noop notsc divider=10 clocksource=acpi_pm noswapaccount cgroup_disable=memory noisapnp noresume nodomains nobar norom printk.time=0 thermal.off=1 nosmp nolapic noapic SYSFONT=latarcyrheb-sun16 LANG=de_DE.UTF-8 KEYTABLE=de-latin1-nodeadkeys initrd /initramfs-3.1.0-0.rc9.git0.0.fc17.x86_64.img -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 01:45:45PM +0200, Christoph Trassl wrote: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Does not seem to make any sense to me, unless you verify that no one has messed with your kernel/bootloader in /boot or /dev/sda. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, Oct 25, 2011 at 11:40:29AM +0200, François Kooman wrote: On 10/25/11 10:23 AM, Mario Ceresa wrote: Francois: you should already be able to use yubikey for FAS, bodhi and ssh. You don't need the yubikey prompt: just put your username, go to the password field and then press the key's button. Correction -- ssh will still use ssh keys. There's no option for passwords in fedora infra anymore so there's also no option to use the yubikey there. Really? That seems weird. If someone takes my key they would be able to login? I would expect it to be two-factor authentication (username password + yubikey). (I'm unable to test right now as I don't have my yubi with me) Correct -- it's not currently two-factor (it's either this or that). We've been kicking around whether we want to make it two-factor, how we'd do that, who we'd enforce it upon, etc, for a while... it's hard because we have several different classes of users with different requirements for each. -Toshio pgp4i4XdusSLM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
Thanks Toshio for the correction! Best, Mario On 25 October 2011 18:22, Toshio Kuratomi a.bad...@gmail.com wrote: On Tue, Oct 25, 2011 at 11:40:29AM +0200, François Kooman wrote: On 10/25/11 10:23 AM, Mario Ceresa wrote: Francois: you should already be able to use yubikey for FAS, bodhi and ssh. You don't need the yubikey prompt: just put your username, go to the password field and then press the key's button. Correction -- ssh will still use ssh keys. There's no option for passwords in fedora infra anymore so there's also no option to use the yubikey there. Really? That seems weird. If someone takes my key they would be able to login? I would expect it to be two-factor authentication (username password + yubikey). (I'm unable to test right now as I don't have my yubi with me) Correct -- it's not currently two-factor (it's either this or that). We've been kicking around whether we want to make it two-factor, how we'd do that, who we'd enforce it upon, etc, for a while... it's hard because we have several different classes of users with different requirements for each. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 06:41:21PM +0200, Christoph Trassl wrote: On 10/25/2011 05:30 PM, Till Maas wrote: On Tue, Oct 25, 2011 at 01:45:45PM +0200, Christoph Trassl wrote: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Does not seem to make any sense to me, unless you verify that no one has messed with your kernel/bootloader in /boot or /dev/sda. Correct. Verifying the kernel/bootloader could easily been done within seconds - at every boot. Yet as long as it is not done, encrypting /usr is no improvement. And even if it is done, you would also need to verify that nobody installed a keyboard logger on your device if your fear attackers that have easily physical access to the device in question. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 Alpha on Power ready for testing!
Good news everyone! At long last the Fedora Secondary Arch Team for Power proudly presents the Fedora 16 Alpha release. It's still hot, so grab it while you can from here (in case you have appropriate hardware, obviously): https://mirrors.fedoraproject.org/publiclist/Fedora/16-Alpha/ppc64/ But beware, it's still a bit rough around the edges and needs some more TLC, but hey, it's an Alpha, right? ;) More details about this Alpha release can be found here: https://fedoraproject.org/wiki/Fedora_16_Alpha_PPC_release_notes and we do have an official release announcement as well here: https://fedoraproject.org/wiki/F16_Alpha_PPC_release_announcement (both of which have shamelessly been taken from the primary arch Fedora 16 wikis and modified to reflect the state of Power architecture, known issues and some workarounds for those). I want to thank everyone involved in making this happen, it's been a pretty long stretch with quite a few hurdles, but we finally got the first big milestone done towards the goal to get a Fedora 16 on Power out. Next up obviously Beta and then RC, so stay tuned for more updates in the near future! As usual, the whole team can typically be found on the #fedora-ppc IRC channel on FreeNode and via our email list: https://admin.fedoraproject.org/mailman/listinfo/ppc And we have our Secondary Arch wiki with (decently) updated information: http://fedoraproject.org/wiki/Architectures/PowerPC Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, 25 Oct 2011, Mario Ceresa wrote: That's strange: the only two occasion I had a failed OTP were: 1) A configuration problem: (Yubikey not enabled, yubikey prefix not correct, using unburned key) 2) In a two slot configuration, whenever I press the button too long and it generates an OTP from the second slot If you are sure that's not your case, maybe filing a bug would be of help? Indeed. With the information discussed today,I realised the prefix was wrong. After I fixed that, the yubikey test auth worked! I'll do a pending update in an hour and see if bodhi/koji work with it :) Thanks! Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Another glibc change that nearly got pushed into F16
It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
W dniu 25 października 2011 09:26 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: W dniu 25 października 2011 09:20 użytkownik Harald Hoyer har...@redhat.com napisał: On 10/24/2011 10:12 PM, Michał Piotrowski wrote: In any case #!/usr/bin/env sh seems to be more portable solution. please :) you can propose this as a separate feature for F18 :) Let's see, if it gets accepted :) Ok, no problem. I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I can help with it. I only need to know how to find all scripts that uses #!/bin/sh without installing all packages :) -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 11:24 AM, Michał Piotrowski wrote: W dniu 25 października 2011 09:26 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: W dniu 25 października 2011 09:20 użytkownik Harald Hoyer har...@redhat.com napisał: On 10/24/2011 10:12 PM, Michał Piotrowski wrote: In any case #!/usr/bin/env sh seems to be more portable solution. please :) you can propose this as a separate feature for F18 :) Let's see, if it gets accepted :) Ok, no problem. I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I can help with it. I only need to know how to find all scripts that uses #!/bin/sh without installing all packages :) A reasonable approximation is repoquery --whatrequires /bin/sh. I count 5319 packages -- good luck... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? -- Chris Adams cmad...@hiwaay.net 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 -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real0m2.737s user0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real0m3.677s user0m1.013s sys 0m2.296s Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Michał Piotrowski mkkp...@gmail.com said: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? It is an unnecessary hack, since the intepreters all have standard locations. It also adds the overhead of a second exec() call and a PATH search (start env, let it parse its command line, then search the PATH for the desired interpreter, then exec() the interpreter). It also makes system scripts more fragile; for example, if somebody installs (from source) a different version of python in /usr/local/bin, all RPM-installed scripts in /usr/bin (that may not even work with that version) will now use the new version with unpredictable results. -- Chris Adams cmad...@hiwaay.net 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
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real 0m2.737s user 0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real 0m3.677s user 0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: [...] What is wrong with #!/usr/bin/env interpreter from technical POV? It's more wordy. It makes it impossible to pass an interpreter argument. It will execute slower. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 08:39:25PM +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real 0m2.737s user 0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real 0m3.677s user 0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. 34% slower is a more appropriate way to look at it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? It is an unnecessary hack, since the intepreters all have standard locations. It also adds the overhead of a second exec() call and a PATH search (start env, let it parse its command line, then search the PATH for the desired interpreter, then exec() the interpreter). Overhead is not big - about 0,00094s according to Richard's test. It also makes system scripts more fragile; for example, if somebody installs (from source) a different version of python in /usr/local/bin, all RPM-installed scripts in /usr/bin (that may not even work with that version) will now use the new version with unpredictable results. Yes, this is a good argument. -- Chris Adams cmad...@hiwaay.net 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 -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Class-Load-0.12.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Class-Load: f1bb822ffb509b5f96b17237f318ab70 Class-Load-0.12.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: UsrMove feature
2011/10/25 Frank Ch. Eigler f...@redhat.com: =?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: [...] What is wrong with #!/usr/bin/env interpreter from technical POV? It's more wordy. Yes. It makes it impossible to pass an interpreter argument. This actually may be a problem. For my use cases alias works fine, but it will not work inside script because of chicken or the egg problem. It will execute slower. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load] Update to 0.12
commit 7a438a539122da2b15bf0e4e55300d4cb1bbeebd
Author: Paul Howarth p...@city-fan.org
Date: Tue Oct 25 19:52:30 2011 +0100
Update to 0.12
- New upstream release 0.12:
- Require Module::Runtime ≥ 0.011, which fixes problems with Catalyst
under
Perl 5.8 and 5.10
- Add versioned runtime dependencies for Module::Runtime and Package::Stash
perl-Class-Load.spec | 12 ++--
sources |2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index d1cf845..f55e1c3 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,5 +1,5 @@
Name: perl-Class-Load
-Version: 0.11
+Version: 0.12
Release: 1%{?dist}
Summary: A working (require Class::Name) and more
Group: Development/Libraries
@@ -15,7 +15,7 @@ BuildRequires:perl(ExtUtils::MakeMaker)
# Module requirements
# ===
BuildRequires: perl(Data::OptList)
-BuildRequires: perl(Module::Runtime) = 0.009
+BuildRequires: perl(Module::Runtime) = 0.011
BuildRequires: perl(Package::Stash) = 0.32
BuildRequires: perl(Try::Tiny)
# ===
@@ -39,6 +39,8 @@ BuildRequires:perl(Test::CPAN::Changes)
# Runtime requirements
# ===
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Module::Runtime) = 0.011
+Requires: perl(Package::Stash) = 0.32
# Also requires core module perl(Exporter) via a use base construct
%description
@@ -76,6 +78,12 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Tue Oct 25 2011 Paul Howarth p...@city-fan.org - 0.12-1
+- Update to 0.12:
+ - Require Module::Runtime ≥ 0.011, which fixes problems with Catalyst under
+Perl 5.8 and 5.10
+- Add versioned runtime dependencies for Module::Runtime and Package::Stash
+
* Wed Oct 5 2011 Paul Howarth p...@city-fan.org - 0.11-1
- Update to 0.11:
- Don't accept package names that start with a digit
diff --git a/sources b/sources
index 1823280..bd9d802 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-02180e505179e1ea718a5a22f93d2c0c Class-Load-0.11.tar.gz
+f1bb822ffb509b5f96b17237f318ab70 Class-Load-0.12.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: BEWARE: a problematic glibc made it to stable (F16)
On Tue, 2011-10-25 at 08:32 +0100, Richard W.M. Jones wrote: You snipped the part where Kevin wrote [...] if the maintainer demonstrates incompetence at taking these decisions, the offending maintainer needs to be replaced. The problem here appears to be a human one, not something that software is going to fix any time soon. Sure. But in the meantime, the software sure is mitigating the problem. (Getting humans replaced is something of an arduous process, in Fedora.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load] Created tag perl-Class-Load-0.12-1.fc17
The lightweight tag 'perl-Class-Load-0.12-1.fc17' was created pointing to: 7a438a5... Update to 0.12 -- 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: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 21:59:40 Tuesday 25 October 2011 Josh Stone wrote: On 10/25/2011 11:24 AM, Michał Piotrowski wrote: W dniu 25 października 2011 09:26 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: W dniu 25 października 2011 09:20 użytkownik Harald Hoyer har...@redhat.com napisał: On 10/24/2011 10:12 PM, Michał Piotrowski wrote: In any case #!/usr/bin/env sh seems to be more portable solution. please :) you can propose this as a separate feature for F18 :) Let's see, if it gets accepted :) Ok, no problem. I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I can help with it. I only need to know how to find all scripts that uses #!/bin/sh without installing all packages :) A reasonable approximation is repoquery --whatrequires /bin/sh. I count 5319 packages -- good luck... Someone would have to find a killer feature to justify touching this amount of packages :). Not to mention that such changes should happen upstream and I (probably a number of other maintainers too) would not maintain local patches for smth like it, but if someone convince upstreams to use the new way I wouldn't mind it at all too. Please everyone think first what amount of other work can be done for the time needed to modify these 5319 packages. Regards, Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, Oct 25, 2011 at 6:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Correct -- it's not currently two-factor (it's either this or that). We've been kicking around whether we want to make it two-factor, how we'd do that, who we'd enforce it upon, etc, for a while... it's hard because we have several different classes of users with different requirements for each. Maybe something like SAML or OpenID 2.0 would be a solution for this (free single sign on included)... The people @yubikey wrote a module for simpleSAMLphp to support the Yubikey for 2-factor authentication. Would be nice to have single sign on for Bugzilla, FAS, Bodhi, Wiki... Regards, François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. Otherwise it'll only get fixed with a 0-day. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real0m2.737s user0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real0m3.677s user0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one tiny tiny fraction of a second, isn't it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Adam Williamson awill...@redhat.com: On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real 0m2.737s user 0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real 0m3.677s user 0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one tiny tiny fraction of a second, isn't it? Look again carefully for i in $(seq 1000); do -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Tue, Oct 25, 2011 at 12:17:54PM -0700, Adam Williamson wrote: On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. Doh. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. My non-expert advice would be that this should be a blocker. It would be better if experts in POSIX arcana could weigh in on this subject though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, 2011-10-25 at 12:21 -0700, Adam Williamson wrote: On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real0m2.737s user0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real0m3.677s user0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one tiny tiny fraction of a second, isn't it? Oh. Duh. I missed the 1,000 attempts. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/2011 03:21 PM, Adam Williamson wrote: On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real0m2.737s user0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real0m3.677s user0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one tiny tiny fraction of a second, isn't it? There are also possible Security ramifications of allowing the interpreter to be replaced, users could stumble upon this. Python even tries to prevent this with the -Es qualifier. man python ... -s Don't add user site directory to sys.path. -E Ignore environment variables like PYTHONPATH and PYTHONHOME that modify the behavior of the interpreter. I think putting #!/usr/bin/env interpreter is a very bad idea for administrative tools. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6nDZ0ACgkQrlYvE4MpobNN3QCdG3620U65PBvuls1KPkZHWCLm T5EAoK4Vpm41pYxpMZty3hF/bJsBg/nx =no7E -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
2011/10/25 Daniel J Walsh dwa...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/2011 03:21 PM, Adam Williamson wrote: On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote: 2011/10/25 Richard W.M. Jones rjo...@redhat.com: On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski wrote: 2011/10/25 Chris Adams cmad...@hiwaay.net: Once upon a time, Michał Piotrowski mkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? This is what's wrong: $ cat sh.sh #!/bin/sh $ cat env.sh #!/usr/bin/env sh $ chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh; done real 0m2.737s user 0m0.750s sys 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done real 0m3.677s user 0m1.013s sys 0m2.296s Yeah, it is noticeably slower - about 0,00094s. Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one tiny tiny fraction of a second, isn't it? There are also possible Security ramifications of allowing the interpreter to be replaced, users could stumble upon this. Python even tries to prevent this with the -Es qualifier. man python ... -s Don't add user site directory to sys.path. -E Ignore environment variables like PYTHONPATH and PYTHONHOME that modify the behavior of the interpreter. I think putting #!/usr/bin/env interpreter is a very bad idea for administrative tools. It seems that this idea has real technical disadvantages: - possible security problems - slower execution of scripts - inability to pass an argument to interpreter - random problems caused by using of local interpreter - the need for modification of 5000+ packages Harald, game is not worth the candle. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Alexander Kurtakov (akurt...@redhat.com) said: Someone would have to find a killer feature to justify touching this amount of packages :). Not to mention that such changes should happen upstream and I (probably a number of other maintainers too) would not maintain local patches for smth like it, but if someone convince upstreams to use the new way I wouldn't mind it at all too. Please everyone think first what amount of other work can be done for the time needed to modify these 5319 packages. I'm not sure why this would even be discussed. ln -s /usr/bin /bin, and move along to other business. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Bill Nottingham nott...@redhat.com said:
I'm not sure why this would even be discussed.
ln -s /usr/bin /bin, and move along to other business.
I think someone proposed (as an addition to UsrMove) having the /bin,
/sbin, etc. symlinks deprecated and to remove them in a couple of
releases. IMHO aside from necessary compatibility (such as the dynamic
loader being in /lib{,64}), there's way too much history involved in
/bin (and to a lesser extend /sbin) to ever consider removing the
symlinks.
More importantly, there's no compelling reason FOR removing them, other
than somebody's idea of neatness. I have no problem removing compat
symlinks when they are no longer needed; I just don't believe that will
ever be the case for /bin, /lib{,64}, and /sbin.
--
Chris Adams cmad...@hiwaay.net
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
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
So do I. So let's come back to the original discussion.
Am 25.10.2011 22:11 schrieb Chris Adams cmad...@hiwaay.net:
Once upon a time, Bill Nottingham nott...@redhat.com said:
I'm not sure why this would even be discussed.
ln -s /usr/bin /bin, and move along to other business.
I think someone proposed (as an addition to UsrMove) having the /bin,
/sbin, etc. symlinks deprecated and to remove them in a couple of
releases. IMHO aside from necessary compatibility (such as the dynamic
loader being in /lib{,64}), there's way too much history involved in
/bin (and to a lesser extend /sbin) to ever consider removing the
symlinks.
More importantly, there's no compelling reason FOR removing them, other
than somebody's idea of neatness. I have no problem removing compat
symlinks when they are no longer needed; I just don't believe that will
ever be the case for /bin, /lib{,64}, and /sbin.
--
Chris Adams cmad...@hiwaay.net
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Chris Adams cmad...@hiwaay.net writes: Once upon a time, MichaÅ Piotrowski mkkp...@gmail.com said: What is wrong with #!/usr/bin/env interpreter from technical POV? It is an unnecessary hack, Even if it were not a hack, and not significantly slower, it would still be completely unacceptable because it will break just about every user-written shell script (not to mention perl script, python script, yadda yadda). There is no advantage to this change that is worth the amount of pain you are proposing to inflict on end users. What you'll probably mostly accomplish is to drive people away from Fedora and into distributions that have more respect for their users' time. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New bodhi bugfix release in production
bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. https://admin.fedoraproject.org/updates I raced to get this out before the infrastructure freeze today, and since then there have already been many more bugfixes in git, so expect another release shortly after F16 is released. Please file bugs here: https://fedorahosted.org/bodhi/newticket Client fixes - bodhi -L dies with out-of-range exception after branching f16 https://fedorahosted.org/bodhi/ticket/625 https://bugzilla.redhat.com/show_bug.cgi?id=746780 - bodhi -r dist-f14 -b 676195 don't respect -r option https://bugzilla.redhat.com/show_bug.cgi?id=747939 Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 - fedora-easy-karma submits too many comments to bodhi when bodhi has a server problem (edit) https://bugzilla.redhat.com/show_bug.cgi?id=698441 - Bodhi no longer adds comments to Security Response bugs https://fedorahosted.org/bodhi/ticket/485 Buildroot override fixes - Buildroot overrides require commit access to devel branch rather than branch override applies to https://fedorahosted.org/bodhi/ticket/620 - Cannot request build root override https://bugzilla.redhat.com/show_bug.cgi?id=729722 - buildroot overrides stay after expiration date https://bugzilla.redhat.com/show_bug.cgi?id=723071 Masher fixes - Updates-testing report emails should use package names not update number https://fedorahosted.org/bodhi/ticket/644 - Current updateinfo data is broken (epoch=None) https://bugzilla.redhat.com/show_bug.cgi?id=652296 - Fedora Update System suggests to reboot when not asked to do so https://bugzilla.redhat.com/show_bug.cgi?id=681850 Package fixes - - bodhi-server should require python-fedora-turbogears https://bugzilla.redhat.com/show_bug.cgi?id=743975 pgpcXyy8mbom9.pgp 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: Another glibc change that nearly got pushed into F16
On Tue, Oct 25, 2011 at 8:17 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. Otherwise it'll only get fixed with a 0-day. As long as its not the broken one shipped as 0-day :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On 24 October 2011 01:20, Vincent Beers wrote: [..] If there is no package maintainer, I'm willing to try and be one, since I'm a bit of a fan of the software. (Though I'll have to study up on package maintaining.) Nice. You may want to have a look at: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers Regards, -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
Tomas Mraz wrote: If there were any commands in sbin that are usable also for regular users then they should have been moved to bin. Some examples of commands that are usable to unprivileged users: ip route ifconfig -a lspci lsusb lsmod ldconfig -p mkfs ~/my_disk_image fuser lsof mksock ~/my_socket ntpdate -q -u some_time_server I've always found it annoying when I want to list the computer's IP addresses for example, and I have to prefix the ifconfig command with /sbin/ or /usr/sbin/, and remember which of those two it should be. It's particularly odd that I can use /sbin/mkfs to make a disk image without privileges, but /bin/mount won't mount it even if I own both the image and the mount point. The division into bin and sbin seems rater arbitrary and I see no significant advantages with it. Thus I support the plan to move everything to /usr/bin. Björn Persson 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: UsrMove feature
=?iso-8859-1?q?Bj=F6rn_Persson?= bj...@xn--rombobjrn-67a.se writes: It's particularly odd that I can use /sbin/mkfs to make a disk image without privileges, but /bin/mount won't mount it even if I own both the image and the mount point. The division into bin and sbin seems rater arbitrary and I see no significant advantages with it. Thus I support the plan to move everything to /usr/bin. That is a pretty lame argument: you can fix that much less intrusively by putting both /bin and /sbin in your PATH. Which indeed has been the default on Fedora for some time now, I believe. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually *was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
2011/10/25 Björn Persson bj...@xn--rombobjrn-67a.se: It's particularly odd that I can use /sbin/mkfs to make a disk image without privileges, but /bin/mount won't mount it even if I own both the image and the mount point. You could create a setuid-root executable on the disk image and then mount it. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, 25 Oct 2011 14:59:51 -0700 Adam Williamson awill...@redhat.com wrote: On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually *was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. Please read down... Masher fixes - Updates-testing report emails should use package names not update number https://fedorahosted.org/bodhi/ticket/644 But see the test list... there's an issue with the new package name based links. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, 2011-10-25 at 16:10 -0600, Kevin Fenzi wrote: On Tue, 25 Oct 2011 14:59:51 -0700 Adam Williamson awill...@redhat.com wrote: On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually *was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. Please read down... Masher fixes - Updates-testing report emails should use package names not update number https://fedorahosted.org/bodhi/ticket/644 But see the test list... there's an issue with the new package name based links. ;) It's not just the updates-testing list, though. When I go to the web interface, search for updates to, say, grub2, get a list, and click on one of the results, I get an ID-based URL, not a package name-based one. I then paste that into an email, IRC conversation, or trac compose request ticket, and no-one can see what the update *is* unless they click on the link. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, Oct 25, 2011 at 02:59:51PM -0700, Adam Williamson wrote: On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually *was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. I'd be happy to revert this if the majority of people prefer the other format. Bodhi will still use the n-v-r style URLs for the updates-testing digests, but will default to the static IDs otherwise. The biggest problem with using the builds in the URL is that the URLs break if they are edited to add/remove/update them. I guess we could add some additional logic to try and be clever and find the update even if one of the builds is missing or modified. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
Luke Macken wrote: In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually*was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. I'd be happy to revert this if the majority of people prefer the other format. Bodhi will still use the n-v-r style URLs for the updates-testing digests, but will default to the static IDs otherwise. The biggest problem with using the builds in the URL is that the URLs break if they are edited to add/remove/update them. I guess we could add some additional logic to try and be clever and find the update even if one of the builds is missing or modified. Think about how bugzilla bugs are handled in IRC. Bugs all have ID numbers. Why should updates be different? I vote for static IDs because I have run into the case of modified updates and broken URLs. Adam, can you not pursue an enhancement to the IRC bot that translates bug URLs into descriptions to also handle bodhi IDs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tuesday, October 25, 2011, 6:32:26 PM, Michael wrote: Luke Macken wrote: In case you hadn't noticed, response to this has so far been pretty negative. It seems people liked being able to tell from the URL what the update actually*was*. I must admit I do to. I've resorted to creating the 'old-style' URLs manually when I do lists of updates on test@ or in trac, now. I'd be happy to revert this if the majority of people prefer the other format. Bodhi will still use the n-v-r style URLs for the updates-testing digests, but will default to the static IDs otherwise. The biggest problem with using the builds in the URL is that the URLs break if they are edited to add/remove/update them. I guess we could add some additional logic to try and be clever and find the update even if one of the builds is missing or modified. Think about how bugzilla bugs are handled in IRC. Bugs all have ID numbers. Why should updates be different? I vote for static IDs because I have run into the case of modified updates and broken URLs. Adam, can you not pursue an enhancement to the IRC bot that translates bug URLs into descriptions to also handle bodhi IDs? This is surreal. Are you trying to single handely kill what little real user testing is being done on the various Fedora releases? Now you want to make users bring up yet another tool - an IRC client? Why not just be done with it, and bury the reports in a locked filing cabinet in a barred sub-basement room labeled Ignore me - do not open? Perhaps there are simpler alternatives. The whole point of the updates testing reports is to provide information that _quickly_ makes folks aware of what new packages are available in updates-testing for a given release. Real users know the names of the packages that they use. That information is now gone - hidden behind a VERY SLOW process of is following links. I tried the first day the report changed. I gave up, as it was taking a significant time to bring up each link. The first reaction in the proven testers meeting was that the new reports were not at all useful, and should be immediately reverted. It has been a number of weeks since then, but it appears we now have something else instead. The report generated by the latest iteration is broken. This has already been noted by others, and they have made suggestions as to how to fix this (listing the package names below the URL). I had an idea a number of weeks ago to increase the visibility of those packages sitting for long periods of time in updates-testing, in faint hope that someone would care enough to test and give karma. Kevin Fenzi encouraged me to open a TRAC request. It was to simply show the number of days that each package has been in updates-testing in the report, something that bodhi should have readily at hand. Having URLs that are not brokwn is important. Showing the package name and the number of days it has been in updates testing (to the left of the name) is equally important. Please consider doing all of these in your next revision. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
Jeffrey Ollie wrote: 2011/10/25 Björn Persson bj...@xn--rombobjrn-67a.se: It's particularly odd that I can use /sbin/mkfs to make a disk image without privileges, but /bin/mount won't mount it even if I own both the image and the mount point. You could create a setuid-root executable on the disk image and then mount it. There's -o nosuid for that, but that wasn't my point. The context is the distinction between bin and sbin. If mkfs belongs in /sbin, why is mount in /bin? If mount belongs in /bin, why is mkfs in /sbin? Björn Persson 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: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 10:57:59PM +0200, Harald Hoyer wrote: So do I. So let's come back to the original discussion. I've added some points from re-reading the FHS and from this thread onto the Feature page. The immediate suggestion I have is that you should consider splitting the / = /usr move from the /sbin = /bin move. Although changing either produces the same kind of pain, the benefits and drawbacks of each have differences. For instance, it doesn't seem like you've listed any of your perceived benefits for moving /sbin = /bin on that page. Reading between the lines, I'm guessing that you think it's confusing to have the programs split like that. However, several people on the list have said they'd find it more confusing to have them merged. -Toshio pgp45cyhuejrF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, Oct 25, 2011 at 09:17:39PM +0200, fkoo...@tuxed.net wrote: On Tue, Oct 25, 2011 at 6:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Correct -- it's not currently two-factor (it's either this or that). We've been kicking around whether we want to make it two-factor, how we'd do that, who we'd enforce it upon, etc, for a while... it's hard because we have several different classes of users with different requirements for each. Maybe something like SAML or OpenID 2.0 would be a solution for this (free single sign on included)... The people @yubikey wrote a module for simpleSAMLphp to support the Yubikey for 2-factor authentication. Would be nice to have single sign on for Bugzilla, FAS, Bodhi, Wiki... bugzilla likely won't happen as that's controlled by RH (If upstream bugzilla grew OpenID support, they might be convinced to let that be used... not sure). FAS and bodhi are single sign on (iirc, everything on admin.fedoraproject.org). wiki shares the same authn verification with fas but not the auth cookie. So you can login to the wiki with your yubikey or fas password but you do have to do it separately from your login to fas/bodhi/pkgdb/etc. koji is separate. From previous talks with the koji devs I'm not sure whether they'd take a patch to add openid or not. Best to open a conversation with them if you're interested. -Toshio pgpVC0VubnoSk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Remaining F16 blockers and F16 planning
Hey, folks. Just thought I'd send out an overview of remaining unaddressed F16 blockers, in case anyone can help with them. We were scheduled to do the F16 RC compose today, but with these unaddressed, we can't. We hope we'll be able to do the compose tomorrow, but if blockers remain unaddressed, we'll fall back to doing a compose labelled TC3 so we can at least test and ensure that the release is ready aside from the remaining known blockers. 1. https://bugzilla.redhat.com/show_bug.cgi?id=668282 PackageKit yum backend uses incorrect encoding for dynamic category names, makes them show up with '?' characters in KPackageKit Nils is working on this one and currently expects to have a fix ready for tomorrow. 2. https://bugzilla.redhat.com/show_bug.cgi?id=731245 KDE fails to start inside a VM , large amount of memory [@ miCopyRegion] Any input on this bug is welcome; it's easy enough to reproduce (download any post-Alpha F16 KDE live image and try to boot to a desktop within a typical virt-manager created KVM). Soren has said he'll look at this tomorrow, but any other contributions would be good. 3. https://bugzilla.redhat.com/show_bug.cgi?id=736893 New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot We're still rather looking for information from the reporter here, but if others have iSCSI-capable setups it would be good to have more testing. Tim Flink from the QA team has done successful iSCSI testing, but that's only one data point. 4. https://bugzilla.redhat.com/show_bug.cgi?id=743273 grub2 fails to install on IMSM raid device This is another where we could probably do with more data: we know install to Intel BIOS RAID *can* work, but it also seems somewhat fragile. Jes had various issues in some of his tests but eventually got it to work; pjones and I have had successful tests but I also had a couple of that failed with similar errors to Jes'. More tests of installs of F16 Final TC2 to Intel BIOS RAID might help establish exactly where the bugs are. 5. https://bugzilla.redhat.com/show_bug.cgi?id=748747 Totem doesn't display video when using software 3D rendering ajax is planning to look at this one tomorrow, I believe, but again, it would be great to have input from anyone else who's able to help fix the issue. Note that the issue affects most GNOME components which do video - not just totem, but cheese and empathy also. Video is broken when using software 3D in all of them. Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, 2011-10-25 at 19:03 -0400, Al Dunsmuir wrote: Think about how bugzilla bugs are handled in IRC. Bugs all have ID numbers. Why should updates be different? I vote for static IDs because I have run into the case of modified updates and broken URLs. Adam, can you not pursue an enhancement to the IRC bot that translates bug URLs into descriptions to also handle bodhi IDs? This is surreal. Are you trying to single handely kill what little real user testing is being done on the various Fedora releases? Now you want to make users bring up yet another tool - an IRC client? Why not just be done with it, and bury the reports in a locked filing cabinet in a barred sub-basement room labeled Ignore me - do not open? Erm, put down the flamethrower. IRC was just an example. Really this is just a tooling question of whether it's overall more convenient to have Bodhi use IDs and then implement convenience scripts/tools wherever we refer to the updates which can identify them - like a bot in IRC, and a modification to the updates-testing email to make it use the old format, etc - or whether it's better to have Bodhi use NEVRs and then have to somehow deal with the problem of updates with dozens of packages, and the problem of updates which are edited to include *different* NEVRs. Whichever one turns out to be the most efficient solution is what we'll go with, I'm sure. No-one's out to get you. Deep breaths. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, 2011-10-25 at 16:44 -0700, Toshio Kuratomi wrote: FAS and bodhi are single sign on (iirc, everything on admin.fedoraproject.org). Well, Bodhi seems to do a damn good job of forgetting you're signed in. I've never tried to analyze this carefully, it's just a subjective feeling that I seem to have to log into it a hell of a lot... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F15: subversion 1.7 / kdesvn
hi well, suversion 1.7 was not pushed until now and that is why i think it's a good moment for my questions: as far as i can see there are different maintainers for subversion and kdesvn, upgrade to subversion 1.7 (including svn upgrade in the working-dir) works fine but with subversion 1.7 the format in teh working directory is changed and the kde-kontextmenu will no longer offer display of history and missing some other entries http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng i guess kdesvn should be updated too and i try to point this out before pushing updates to stable subversion: http://koji.fedoraproject.org/koji/packageinfo?packageID=752 kdesvn: http://koji.fedoraproject.org/koji/packageinfo?packageID=2200 -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
Adam Williamson wrote: On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 In case you hadn't noticed, response to this has so far been pretty negative. Coming from someone (me) who often does updates involving 1 pkg that sometimes require removing/adding components after initial submission, I very much welcome the new ID-based (default) URL's -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tue, 2011-10-25 at 20:30 -0500, Rex Dieter wrote: In case you hadn't noticed, response to this has so far been pretty negative. Coming from someone (me) who often does updates involving 1 pkg that sometimes require removing/adding components after initial submission, I very much welcome the new ID-based (default) URL's Indeed, packagename-based urls are not very practical for 60+ package updates... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Proventesters meetup tomorrow at 18UTC (2011-10-26)
We are going to be having another proventesters meetup tomorrow on IRC in #fedora-meeting at 18:00UTC. Purpose of meetup: Brainstorm ideas on improving testing and processes for testing updates. * Intro/gather more agenda items * Recruiting more proventesters/testers. * One stop page for updates testing resources https://fedoraproject.org/wiki/Package_tester_resources * Your amazing agenda item here. Please do join us if you are a proventester, want to become one, or have ideas for improving the testing of updates. Note that this is not the venue for changing the updates policy, see FESCo for that, this is an attempt to get things working better within our existing updates policy. Hope to see folks there! kevin signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 08:33 PM, Michał Piotrowski wrote: 2011/10/25 Chris Adamscmad...@hiwaay.net: Once upon a time, Michał Piotrowskimkkp...@gmail.com said: I created feature page https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this feature. /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The #!/usr/bin/env foo suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. What is wrong with #!/usr/bin/env interpreter from technical POV? Install a different shell as ~/bin/sh and prepend ~/bin to your $PATH and you will see. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Killing perl-Pugs-Compiler-Rule
On Mon, Oct 24, 2011 at 04:08:14PM -0500, Steven Pritchard wrote: On Fri, Oct 21, 2011 at 10:03:10AM +0200, Petr Pisar wrote: Steven, I cannot see corresponding ticket for rel-engs. This error still pops up in regualar repository summaries. Sorry, I wasn't aware of the proper procedure to go through for this. (This is the first time I've retired a package.) I've done everything except the rel-eng ticket. When I try to create that, I get TICKET_CREATE privileges are required to perform this operation. I'm assuming I need to login with my FAS account? (Again, I've never had to create a rel-eng ticket...) Sure you need to log in using your Fedora account. -- Petr pgpvy5xAwHYWZ.pgp Description: PGP signature -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Module-Runtime-0.011.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Runtime: d0d2ab338c5bb2769a8f7db200cfdb2b Module-Runtime-0.011.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Runtime] 0.011 bump
commit 93f67aa0ac7241a6027a5c3eac2eea223d907b24
Author: Petr Písař ppi...@redhat.com
Date: Tue Oct 25 13:39:00 2011 +0200
0.011 bump
Fixes compatibility with perl-5.10 and older, so no need to back-port
it.
.gitignore |1 +
perl-Module-Runtime.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2491510..d34773c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Module-Runtime-0.008.tar.gz
/Module-Runtime-0.009.tar.gz
/Module-Runtime-0.010.tar.gz
+/Module-Runtime-0.011.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index a61bd64..2a3ada6 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -1,6 +1,6 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Module-Runtime
-Version:0.010
+Version:0.011
Release:1%{?dist}
Summary:Runtime module handling
License:GPL+ or Artistic
@@ -45,6 +45,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Tue Oct 25 2011 Petr Pisar ppi...@redhat.com - 0.011-1
+- 0.011 bump
+
* Fri Oct 07 2011 Petr Pisar ppi...@redhat.com - 0.010-1
- 0.010 bump
diff --git a/sources b/sources
index 76df804..98a44bb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-069e890c996c99d283070e7aad3de10b Module-Runtime-0.010.tar.gz
+d0d2ab338c5bb2769a8f7db200cfdb2b Module-Runtime-0.011.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mozilla-CA] 20111025 bump
commit e2bab7b265570a19e45e4b11ae7105fdd1c2c5e8
Author: Petr Písař ppi...@redhat.com
Date: Tue Oct 25 13:48:32 2011 +0200
20111025 bump
perl-Mozilla-CA.spec |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Mozilla-CA.spec b/perl-Mozilla-CA.spec
index b954de0..e35d2f7 100644
--- a/perl-Mozilla-CA.spec
+++ b/perl-Mozilla-CA.spec
@@ -1,6 +1,6 @@
Name: perl-Mozilla-CA
-Version:20110914
-Release:2%{?dist}
+Version:20111025
+Release:1%{?dist}
Summary:Mozilla's CA cert bundle in PEM format
License:MPLv1.1 or LGPLv2+ or GPLv2+
Group: Development/Libraries
@@ -40,12 +40,15 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
make test
%files
-%defattr(-,root,root,-)
%doc README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Oct 25 2011 Petr Pisar ppi...@redhat.com - 20111025-1
+- 20111025 bump
+- Remove defattr from spec code
+
* Fri Sep 16 2011 Petr Pisar ppi...@redhat.com - 20110914-2
- Redirect to ca-certificates bundle (bug #738383)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 748771] perl-Mozilla-CA-20111025 is available
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=748771 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Fixed In Version||perl-Mozilla-CA-20111025-1. ||fc17 Last Closed||2011-10-25 08:09:47 --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-10-25 08:09:47 EDT --- Just a dummy upgrade to keep the version. Upstream removed some non-web server authorities which does not affect us as we redirect to original CA file instead. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
