Re: .so's in devel packages...
On Mon, 18 Jun 2012 12:25:12 -0700, Adam Williamson wrote: On Mon, 2012-06-18 at 18:23 +0100, Nelson Marques wrote: Hi all, I have a doubt regarding the '.so's' in devel packages... From my understanding they go in devel packages to allow the installation of several packages with different versioning Not really, no. They go in -devel packages because the only time it's actually appropriate to use a library by referring to its unversioned name is when you're compiling another application against it. It's never safe for anything to access a library at runtime via an unversioned name because there is no guarantee of stability; you can't be at all sure that the version of the library you're calling is actually capable of doing what you're asking it to do. Since the only use of the unversioned 'instance' (symlink, in Fedora...) of a library is in development, naturally it goes in the devel package. We can take advantage of this in generating dependencies, and we do, which is why it's important not to put the .so file in a runtime package, or that runtime package will get a bunch of automatically generated dependencies on -devel packages. And again, this is not the full story. There is no hard rule on where non-versioned .so files are to be packaged. They could still be local libs (with no API for public consumption) strictly required by an application. They could still be plug-ins, libraries loaded by an application at run-time. They could even be symlinks to versioned plug-in libs, with the application strictly requiring the non-versioned symlink when trying to link with a plug-in at run-time. Where .so files are to be put solely depends on their purpose. Many non-versioned libfoo.so files are just the symlink that make -lfoo work during compilation/linking. But that is not sufficient to require *all* non-versioned .so files to be placed in -devel packages. If Fedora Packaging Guidelines are still not clear about this, we may need another update for them. But detailed feedback on them would be appreciated first, IMHO. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.2-4.fc17.x86_64 loadavg: 0.52 0.77 0.44 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. Horses worked fine as transport vehicles for *many* years. Still people decided to replace them and we ended up with trains, cars, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
WDM: Resurrection
Hi, As new upstream maintainer of WINGs Display Manager, I would like to resurrect wdm package in Fedora (/etc/X11/prefdm still have wdm support and that's great). Major changes are systemd support and XDG parser for /usr/share/xsessions/. Is there a policy on packaging display managers? Something that describes things like using specific logos, backgrounds, package provides, etc... Currently I am looking at xorg-x11-xdm and gdm packages, but any formal documents are greatly appreciated. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 10:53 PM, Lennart Poettering wrote: Well, even if Mozilla fixed that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. pre-staging changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. It's not trivial, but in theory the updates could be made to work in an RCU-like fashion: Think of running Firefox processes as RCU read-side sections. The processes that are already running before the update keep seeing the old files. Newly started processes would see the new files. The RCU grace period elapses when all the previously running processes quit. At that point the old files can be deleted. As a bonus a notification would nag the users to restart their Firefox processes. After some timeout the processes would be killed by force. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 833320] New: perl-Carp-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=833320 Bug ID: 833320 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: perl-Carp-1.26 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Carp Product: Fedora Latest upstream release: 1.26 Current version in Fedora Rawhide: 1.25 URL: http://search.cpan.org/dist/Carp/ 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 -- 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: *countable infinities only
On 06/18/2012 06:18 PM, Adam Williamson wrote: I hesitate to put words in people's mouths, and correct me if I'm wrong, but it reads to me as if Jay and others are arguing from an incorrect premise. That premise is to assume that there is a God-given right for people who own computing devices to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_. The problem with this claim is that it equivocates on the meaning of a right. There are at least two definitions of a right in this sense: moral rights and legal rights. These are not the same. Moral rights are not in the gift of any Government. While we may not have a legal right to run whatever software we wish on hardware we own, it's not at all unreasonable to claim a moral right to do so. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 01:10:34PM -0600, Kevin Fenzi wrote: * ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF (nirik, 17:44:17) * AGREED: Feature is approved (+8/0) (nirik, 17:56:59) It would help a lot if a features are only approved, when they have descriptive names. From the message above it is completely unclear what was approved. But if the feature was named like for example DNF package manager preview there would be at least some information about what the DNF features is supposed to be. This is just an example, the other features could mostly be better named as well imho, for example the Clojure Feature as Full Clojure Stack. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kernel 3.4 behaves weirdly with flash drives
Hi folks, In kernels 3.4 and 3.4.2, the kernel gets the size of my pen drives wrong: it thinks they're EB[1] in size, when they're actually only 4GB and 8GB. This issue is not present in the 3.3 kernel. I was wondering if any one else is facing the same issue? The bug is filed here[2]. As a result, I cannot use stuff like fdisk on my system too. It complains: [root@ankur ~]# fdisk /dev/sdb Welcome to fdisk (util-linux 2.21.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. WARNING: The size of this disk is 1122759.7 TB (18302628885633696256 bytes). DOS partition table format can not be used on drives for volumes larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID partition table format (GPT). fdisk: unable to seek on /dev/sdb: Invalid argument [root@ankur ~]# It even prevents me from creating USB fedora installers: [root@ankur ~]# dd if=/home/ankur/Downloads/torrents/rtorrent_completed/Fedora-17-ISOs/Fedora-17-x86_64-DVD/Fedora-17-x86_64-DVD.iso of=/dev/sdb bs=8M dd: writing `/dev/sdb': No space left on device 1+0 records in 0+0 records out 0 bytes (0 B) copied, 0.105326 s, 0.0 kB/s [root@ankur ~]# dd worked flawlessly with the 3.3 kernel. I now have only one 3.3 kernel left on my system. Another broken 3.4 kernel will mean I get stuck with this bug. I've increased the installonly_limit in yum.conf to keep 3.3 around for the time being. Any hints/fixes? :) [1] http://en.wikipedia.org/wiki/Exabyte [2] https://bugzilla.redhat.com/show_bug.cgi?id=831807 -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. 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
[perl-PPI] Build-require Class::Inspector for tests
commit 4f25d27a2c4ad43392f3965ddad7a3ca3e1dd304 Author: Petr Písař ppi...@redhat.com Date: Tue Jun 19 11:24:59 2012 +0200 Build-require Class::Inspector for tests perl-PPI.spec |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/perl-PPI.spec b/perl-PPI.spec index 813724f..d246fc2 100644 --- a/perl-PPI.spec +++ b/perl-PPI.spec @@ -11,6 +11,7 @@ BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) BuildRequires: perl(List::Util) = 1.20 BuildRequires: perl(Storable) = 2.17 +BuildRequires: perl(Class::Inspector) = 1.22 BuildRequires: perl(Clone) = 0.30 BuildRequires: perl(Digest::MD5) = 2.35 BuildRequires: perl(File::Remove) = 1.42 @@ -78,6 +79,7 @@ make test TEST_FILES=xt/*.t RELEASE_TESTING=1 %changelog * Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 1.215-5 - Perl 5.16 rebuild +- Build-require Class::Inspector for tests * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.215-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild -- 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
Ruby and Fedora 17
Hi all, since Ruby/Fedora integration had some significant changes from F16 to F17, I thought it might be a good idea to write a summary of new features and send it out for all - see [1]. All comments and suggestions for further development are welcome. -- Regards, Bohuslav Slavek Kabrda. [1] http://bkabrda.fedorapeople.org/fedora17-ruby-eng-v2.pdf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby and Fedora 17
On 19/06/12 11:44, Bohuslav Kabrda wrote: Hi all, since Ruby/Fedora integration had some significant changes from F16 to F17, I thought it might be a good idea to write a summary of new features and send it out for all - see [1]. All comments and suggestions for further development are welcome. Would you be better to use an open format, not *.pdf? -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby and Fedora 17
2012/6/19 Frank Murphy frankl...@gmail.com: Would you be better to use an open format, not *.pdf? PDF looks quite open to me -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby and Fedora 17
On 19/06/12 11:50, Peter Lemenkov wrote: 2012/6/19 Frank Murphyfrankl...@gmail.com: Would you be better to use an open format, not *.pdf? PDF looks quite open to me Cool, always thought it was closed. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning fuse-encfs
Hello All. I don't use fuse-encfs anymore so I'm going to orphan it. Feel free to take over if you're interested in maintaining it. https://admin.fedoraproject.org/pkgdb/acls/name/fuse-encfs -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)
On Tue, Jun 19, 2012 at 5:09 AM, Till Maas opensou...@till.name wrote: On Mon, Jun 18, 2012 at 01:10:34PM -0600, Kevin Fenzi wrote: * ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF (nirik, 17:44:17) * AGREED: Feature is approved (+8/0) (nirik, 17:56:59) It would help a lot if a features are only approved, when they have descriptive names. From the message above it is completely unclear what was approved. But if the feature was named like for example DNF package manager preview there would be at least some information about what the DNF features is supposed to be. Because you can't click on the link and read about the feature where it describes this in detail? This is just an example, the other features could mostly be better named as well imho, for example the Clojure Feature as Full Clojure Stack. Unless you know what Clojure, you're still either clicking on the link or googling for it's meaning. There's nothing really wrong with your suggestion, but I very much doubt it's going to help in a practical way. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby and Fedora 17
On 19/06/12 12:55, Frank Murphy wrote: Cool, always thought it was closed. Actually it always satisfied two of the three requirements for free format: it was always very well documented with open documents (without any patents required), and there was always at least one independent implementation (ghostscript). However, for a long time it was governed only by Adobe. Since however one variant of PDF was also submitted to ISO, it is now fully free and open format according to any measures imaginable, IMHO. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 831192] perl-Test-Smoke-1.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=831192 --- Comment #1 from Petr Šabata psab...@redhat.com --- *** Bug 832825 has been marked as a duplicate of this bug. *** -- 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 832825] perl-Test-Smoke-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832825 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||psab...@redhat.com Resolution|--- |DUPLICATE Assignee|mmasl...@redhat.com |psab...@redhat.com Last Closed||2012-06-19 08:28:53 --- Comment #1 from Petr Šabata psab...@redhat.com --- *** This bug has been marked as a duplicate of bug 831192 *** -- 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
F18 DNF and history
Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.4 behaves weirdly with flash drives
Hi, On 06/19/2012 11:22 AM, Ankur Sinha wrote: Hi folks, In kernels 3.4 and 3.4.2, the kernel gets the size of my pen drives wrong: it thinks they're EB[1] in size, when they're actually only 4GB and 8GB. This issue is not present in the 3.3 kernel. I was wondering if any one else is facing the same issue? This is a known issue in the 3.4 kernel, a fix is being worked on upstream, see: http://permalink.gmane.org/gmane.linux.usb.general/65976 I think it is worth considering adding the proposed fix to the Fedora 3.4 kernels for now, as it seems a lot of people are bitten by this, and the proposed fix is pretty save. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 19 June 2012 14:44, Michał Piotrowski mkkp...@gmail.com wrote: According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? +1 I use it extensively on our test boxes with official packages and our custom repositories. --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.4 behaves weirdly with flash drives
On Tue, 2012-06-19 at 14:47 +0200, Hans de Goede wrote: This is a known issue in the 3.4 kernel, a fix is being worked on upstream, see: http://permalink.gmane.org/gmane.linux.usb.general/65976 I think it is worth considering adding the proposed fix to the Fedora 3.4 kernels for now, as it seems a lot of people are bitten by this, and the proposed fix is pretty save. Regards, Hans Ah! Great to know! Thanks Hans. I was beginning to think my devices are faulty.. -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG 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: Kernel 3.4 behaves weirdly with flash drives
On Tue, 2012-06-19 at 14:47 +0200, Hans de Goede wrote: I think it is worth considering adding the proposed fix to the Fedora 3.4 kernels for now, as it seems a lot of people are bitten by this, and the proposed fix is pretty save. Fedora Kernel maintainers: Please can we have this patch included until upstream merges it? -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG 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
File DateTime-Format-Flexible-0.23.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-DateTime-Format-Flexible: c35f384b7f6382ed8f3872150b84c4b0 DateTime-Format-Flexible-0.23.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-DateTime-Format-Flexible] 0.23 bump
commit 04238153835fdb3b9a5859a25311fd67dbb8c85d
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 19 14:55:05 2012 +0200
0.23 bump
.gitignore |1 +
perl-DateTime-Format-Flexible.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1743f7e..3027d4e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
DateTime-Format-Flexible-0.15.tar.gz
/DateTime-Format-Flexible-0.21.tar.gz
/DateTime-Format-Flexible-0.22.tar.gz
+/DateTime-Format-Flexible-0.23.tar.gz
diff --git a/perl-DateTime-Format-Flexible.spec
b/perl-DateTime-Format-Flexible.spec
index 6808948..6a3380c 100644
--- a/perl-DateTime-Format-Flexible.spec
+++ b/perl-DateTime-Format-Flexible.spec
@@ -1,5 +1,5 @@
Name: perl-DateTime-Format-Flexible
-Version:0.22
+Version:0.23
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ TEST_POD=1 make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 0.23-1
+- 0.23 bump
+
* Tue Jun 12 2012 Petr Pisar ppi...@redhat.com - 0.22-1
- 0.22 bump
diff --git a/sources b/sources
index 2ca9493..a11d357 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2c7ecdf826ee3bcf7fc9cc7e5141cdce DateTime-Format-Flexible-0.22.tar.gz
+c35f384b7f6382ed8f3872150b84c4b0 DateTime-Format-Flexible-0.23.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
time to fix silly ssh bug
It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Not only, but the poor new fedora user, who tries to ssh into his fedora box, won't see any message indicating what is wrong. Only if he/she can be root and read var/log/secure they may learn the reason. This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 832661] perl-DateTime-Format-Flexible-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832661 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-DateTime-Format-Flexib ||le-0.23-1.fc18 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This fixes a bug and adds one new feature. It will be pushed into F17 too. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Flexible/f17] 0.23 bump
Summary of changes: 0423815... 0.23 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: time to fix silly ssh bug
I'm confused. As long as ~/.ssh is 700 it works for me. On Jun 19, 2012 8:02 AM, Neal Becker ndbeck...@gmail.com wrote: It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Not only, but the poor new fedora user, who tries to ssh into his fedora box, won't see any message indicating what is wrong. Only if he/she can be root and read var/log/secure they may learn the reason. This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. -- 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: F18 DNF and history
On Tue, Jun 19, 2012 at 8:44 AM, Michał Piotrowski mkkp...@gmail.com wrote: Are there any plans to replace yum with dnf in the future? I imagine (and this is pure speculation) that in some perfect future, when dnf is considered mature, that it will probably be renamed to yum. In other words, I think this fork of yum is intended to eventually become the next version of yum. According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? I have no idea about that. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 832661] perl-DateTime-Format-Flexible-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832661 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-Format-Flexible-0.23-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-DateTime-Format-Flexible-0.23-1.fc17 -- 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 830850] perl-DateTime-Format-Flexible-0.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=830850 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-Format-Flexible-0.23-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-DateTime-Format-Flexible-0.23-1.fc17 -- 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: F18 DNF and history
On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 832665] perl-Perl-Critic-Pulp-72 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832665 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE Last Closed||2012-06-19 09:35:22 -- 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: Kernel 3.4 behaves weirdly with flash drives
On Tue, Jun 19, 2012 at 5:22 AM, Ankur Sinha sanjay.an...@gmail.com wrote: I now have only one 3.3 kernel left on my system. Another broken 3.4 kernel will mean I get stuck with this bug. I've increased the installonly_limit in yum.conf to keep 3.3 around for the time being. Any hints/fixes? :) You don't need to do that. If you're booted into the 3.3 kernel, yum shouldn't remove it. It'll just update one of the 2 3.4 kernels you have installed instead. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
2012/6/19 Ales Kozumplik akozu...@redhat.com: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. Sometimes it happens that after large update you have something broken in your system. It's not always clear what could broke the system - then history function is very useful. It is not present in the early versions of DNF but I will make sure to put it back in later. Thank you very much. Ales -- 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: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 02:01 PM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. I think it would be better to ensure the directory is created with the correct permissions. The administrator already has control of the StrictModes setting if they want to relax this restriction. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ggecACgkQ6YSQoMYUY97W+ACfay+Zdd9woIN7OdduzJD9lTb1 kdcAn2PDZRIotmBMeTcjIb1zp5vqsPix =e2zQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/19/2012 10:33 AM, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Ales It is very useful indeed, at least for me. Germán. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
Jayson Vaughn wrote: I'm confused. As long as ~/.ssh is 700 it works for me. On Jun 19, 2012 8:02 AM, Neal Becker ndbeck...@gmail.com wrote: It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Not only, but the poor new fedora user, who tries to ssh into his fedora box, won't see any message indicating what is wrong. Only if he/she can be root and read var/log/secure they may learn the reason. This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Are you sure?? ls -ld .ssh drwx--. 2 nbecker nbecker 4096 Jun 15 08:25 .ssh ls -ld ~/ drwxrwxr-x. 67 nbecker nbecker 4096 Jun 19 06:54 /home/nbecker/ Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DNF Any testing time-frame?
Current status Targeted release: Fedora 18 Last updated: 2012-6-19 Percentage of completion: 40% When would it hit rawhide, ballpark? -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
Bryn M. Reeves wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 02:01 PM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. I think it would be better to ensure the directory is created with the correct permissions. The administrator already has control of the StrictModes setting if they want to relax this restriction. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ggecACgkQ6YSQoMYUY97W+ACfay+Zdd9woIN7OdduzJD9lTb1 kdcAn2PDZRIotmBMeTcjIb1zp5vqsPix =e2zQ -END PGP SIGNATURE- The issue is the admin is likely some poor newb installing fedora on his home computer. I argue the reverse - the knowlegable unix hack can change it to make it stricter. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File podlinkcheck-9.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-podlinkcheck: 0393453ae2c36a3c7f3fd7c871fd7a85 podlinkcheck-9.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-podlinkcheck] 9 bump
commit 4555211b38e7386de5f5117073d53ece48f462d9
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 19 15:50:40 2012 +0200
9 bump
.gitignore |1 +
perl-podlinkcheck.spec |9 +++--
sources|2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1eb06b9..d3b576e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/podlinkcheck-8.tar.gz
+/podlinkcheck-9.tar.gz
diff --git a/perl-podlinkcheck.spec b/perl-podlinkcheck.spec
index bb869c0..355affe 100644
--- a/perl-podlinkcheck.spec
+++ b/perl-podlinkcheck.spec
@@ -1,6 +1,6 @@
Name: perl-podlinkcheck
-Version:8
-Release:2%{?dist}
+Version:9
+Release:1%{?dist}
Summary:Check Perl POD L link references
License:GPLv3+
Group: Development/Libraries
@@ -16,6 +16,7 @@ BuildRequires: perl(Carp)
BuildRequires: perl(constant::defer)
BuildRequires: perl(File::Find::Iterator)
BuildRequires: perl(File::Spec) = 0.8
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IPC::Run)
BuildRequires: perl(List::Util)
@@ -37,6 +38,7 @@ BuildRequires: perl(File::HomeDir)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(File::Find::Iterator)
Requires: perl(File::Spec) = 0.8
+Requires: perl(File::Temp)
Requires: perl(Getopt::Long)
Requires: perl(IPC::Run)
Requires: perl(Pod::Find)
@@ -76,6 +78,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 9-1
+- 9 bump
+
* Wed Jun 13 2012 Petr Pisar ppi...@redhat.com - 8-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index 82603f2..6260e32 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0fc9848f569d65d570d878e04f32cf27 podlinkcheck-8.tar.gz
+0393453ae2c36a3c7f3fd7c871fd7a85 podlinkcheck-9.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: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 19.06.2012 06:45, schrieb Adam Williamson: On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates Ah so you made a BIG MISTAKE as decision and now try to fix it in all sort of ways? who do developers think they are installing SILENT system-upgrades as default? you must not touch the setup of a enduser without a question before so do not fix the rsult, fix the problem and give users back the control of their system signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/18/2012 05:03 PM, Przemek Klosowski wrote: On 06/18/2012 01:21 PM, Reindl Harald wrote: i buy a computer i do not rent it i pay money, i own teh device after giving my money You have to realize that the ease of installing alternative software is a historical accident resulting from the fact that you buy the computer from one company and the software is provided by another company. Certainly in cases when both hardware and software come from the same company, the expectation is that you cannot freely replace the software. And, as if on cue, Microsoft just announced their own ARM tablet. Do you feel that they should leave it open to installing alternative OS? Would they subsidize its hardware cost like they apparently do with Xboxes, and would your answer change depending on whether they do? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 1:32 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better Read my mails in that thread again ... I did never specify the it I just referred to your hand waving but we have been using this for years which is just nonsense. If you have any other arguments fine ... but just stop the we used that for x years nonsense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-Smoke-1.53.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Test-Smoke: 44434030597ef256e76076f53b4076e2 Test-Smoke-1.53.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-Test-Smoke] 1.53 bump
commit 7a2a02c14d6038bfbe27a6d81e546b7c4ee82e32
Author: Petr Šabata con...@redhat.com
Date: Tue Jun 19 16:01:15 2012 +0200
1.53 bump
.gitignore |1 +
perl-Test-Smoke.spec | 27 ---
sources |2 +-
3 files changed, 18 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ce6314a..415f1ab 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Test-Smoke-1.43.tar.gz
/Test-Smoke-1.44.tar.gz
/Test-Smoke-1.47.tar.gz
/Test-Smoke-1.50.tar.gz
+/Test-Smoke-1.53.tar.gz
diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
index 0765e5a..6e71e73 100644
--- a/perl-Test-Smoke.spec
+++ b/perl-Test-Smoke.spec
@@ -1,5 +1,5 @@
Name: perl-Test-Smoke
-Version:1.50
+Version:1.53
Release:1%{?dist}
Summary:Perl core test smoke suite
License:GPL+ or Artistic
@@ -26,7 +26,7 @@ BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(lib)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Mail::Sendmail)
Requires: perl(File::Spec) = 0.82
@@ -41,18 +41,18 @@ results into an easy to read report.
%setup -q -n Test-Smoke-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
-make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-%{_fixperms} $RPM_BUILD_ROOT/*
-rm -rf $RPM_BUILD_ROOT/%{_bindir}/W32Configure.pl
-rm -rf $RPM_BUILD_ROOT/%{_mandir}/man1/W32Configure*
-rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/inc/Mail/Sendmail.pm
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} %{buildroot}/*
+rm -rf %{buildroot}/%{_bindir}/W32Configure.pl
+rm -rf %{buildroot}/%{_mandir}/man1/W32Configure*
+rm -rf %{buildroot}/%{perl_vendorlib}/inc/Mail/Sendmail.pm
%check
make test
@@ -65,6 +65,7 @@ make test
%{_bindir}/mailrpt.pl
%{_bindir}/patchtree.pl
%{_bindir}/runsmoke.pl
+%{_bindir}/sendrpt.pl
%{_bindir}/smokeperl.pl
%{_bindir}/smokestatus.pl
%{_bindir}/synctree.pl
@@ -73,6 +74,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 19 2012 Petr Šabata con...@redhat.com - 1.53-1
+- 1.53 bump
+- Drop command macros
+
* Mon Jun 11 2012 Petr Pisar ppi...@redhat.com - 1.50-1
- 1.50 bump
diff --git a/sources b/sources
index b460b97..702c78f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1b85bff12583bae1d7b1fdb23f12b32b Test-Smoke-1.50.tar.gz
+44434030597ef256e76076f53b4076e2 Test-Smoke-1.53.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: time to fix silly ssh bug
On 6/19/12 9:01 AM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. Perhaps a better idea is to just have openssh-server install /etc/skel/.ssh with the appropriate permissions. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 832667] perl-podlinkcheck-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832667 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-podlinkcheck-9-1.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-19 10:02:44 -- 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
File abi-compliance-checker-1.98.1.tar.gz uploaded to lookaside cache by hobbes1069
A file has been added to the lookaside cache for abi-compliance-checker: bcd9b4eb9334fc70d89a7165efbcef69 abi-compliance-checker-1.98.1.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: time to fix silly ssh bug
Adam Jackson wrote: On 6/19/12 9:01 AM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. Perhaps a better idea is to just have openssh-server install /etc/skel/.ssh with the appropriate permissions. - ajax That doesn't work, see my other reply -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing pyp2rpm - A python package to rpm specfile convertor
- Original Message - Hi all, for past few days, I've been working on a project called pyp2rpm. It's a tool that allows you to easily convert python package from PyPI to an RPM specfile. I would like to get it tested before I package it into Fedora, so if anyone is interested, here are the links: http://pypi.python.org/pypi/pyp2rpm https://bitbucket.org/bkabrda/pyp2rpm You can install pyp2rpm by running easy_install pyp2rpm or pip-python install pyp2rpm. I will be glad for any comments/suggestions for improvement (including comments like hey, I don't understand your readme nor help and I don't know how to use that!, which is why i intentionally didn't put any information about usage here :) ). Thanks! -- Regards, Bohuslav Slavek Kabrda. After adding some more functionality and, I finally packaged pyp2rpm for Fedora (thanks to Matthias Runge for review). So far it's only for F17 and rawhide, but I may add it for older releases if someone wishes. Here is the bodhi link for F17: https://admin.fedoraproject.org/updates/pyp2rpm-0.5.1-1.fc17 Enjoy! -- Regards, Bohuslav Slavek Kabrda. ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: *countable infinities only
Andrew Haley wrote: The problem with this claim is that it equivocates on the meaning of a right. There are at least two definitions of a right in this sense: moral rights and legal rights. These are not the same. Moral rights are not in the gift of any Government. While we may not have a legal right to run whatever software we wish on hardware we own, it's not at all unreasonable to claim a moral right to do so. Andrew. Orthogonal to moral vs. legal rights, there is also a distinction between positive and negative rights. If you have a positive right to something, that actually puts an obligation on someone to guarantee that you get/have/exercise the something. If you have a negative right to something, that only prohibits taking the something away from you, but doesn't put an obligation on anyone to guarantee that you get/have/exercise the something. For instance, in the US the right to use a printing press is protected by the First Amendment (freedom of speech), but it is a negative right, in that the government can't (except in very limited circumstances) do anything to prevent you from using a printing press, but the government is NOT obligated to provide you with a printing press. On the other hand, the right to an attorney for criminal defendants, protected by the Sixth Amendment, has been interpreted by SCOTUS a positive right, since if you cannot afford an attorney the government is obligated to provide one for you. I would claim that the moral right to run whatever software we wish on hardware we own is a negative right; it doesn't put any obligation on another party to help you do it. If you can hack up Fedora to run on a Nokia Windows phone, more power to you, but Nokia and Microsoft aren't obligated to help you do it, and aren't legally prohibited from doing things that make it difficult for you to exercise your moral right. Possibly in this example someone might consider Nokia and Microsoft to be infringing their moral right, but (in the US at least) they'd have no recourse. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
Neal Becker wrote: Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker Looks like a new change in OpenSSH then, which is IMHO a regression, unless there's a clear security vulnerability being addressed there. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On Jun 19, 2012 8:46 AM, Neal Becker ndbeck...@gmail.com wrote: Jayson Vaughn wrote: I'm confused. As long as ~/.ssh is 700 it works for me. On Jun 19, 2012 8:02 AM, Neal Becker ndbeck...@gmail.com wrote: It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Not only, but the poor new fedora user, who tries to ssh into his fedora box, won't see any message indicating what is wrong. Only if he/she can be root and read var/log/secure they may learn the reason. This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Are you sure?? ls -ld .ssh drwx--. 2 nbecker nbecker 4096 Jun 15 08:25 .ssh ls -ld ~/ drwxrwxr-x. 67 nbecker nbecker 4096 Jun 19 06:54 /home/nbecker/ Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Well, yes it works for me however my home directories are not created with 775 permissions by default. Everytime I use useradd the home directory is created as 700 - as it should be. Your home directories are created with permissions 775 by default? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On Jun 19, 2012 10:07 AM, Jayson Vaughn vaughn.jay...@gmail.com wrote: On Jun 19, 2012 8:46 AM, Neal Becker ndbeck...@gmail.com wrote: Jayson Vaughn wrote: I'm confused. As long as ~/.ssh is 700 it works for me. On Jun 19, 2012 8:02 AM, Neal Becker ndbeck...@gmail.com wrote: It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Not only, but the poor new fedora user, who tries to ssh into his fedora box, won't see any message indicating what is wrong. Only if he/she can be root and read var/log/secure they may learn the reason. This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Are you sure?? ls -ld .ssh drwx--. 2 nbecker nbecker 4096 Jun 15 08:25 .ssh ls -ld ~/ drwxrwxr-x. 67 nbecker nbecker 4096 Jun 19 06:54 /home/nbecker/ Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Well, yes it works for me however my home directories are not created with 775 permissions by default. Everytime I use useradd the home directory is created as 700 - as it should be. Your home directories are created with permissions 775 by default? What is your UMASK value in /etc/login.defs? It should be 077, which creates the home directories as 700. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On 6/19/12 11:02 AM, Kevin Kofler wrote: Neal Becker wrote: Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker Looks like a new change in OpenSSH then, which is IMHO a regression, unless there's a clear security vulnerability being addressed there. So, having actually bothered to read and think about the code now, the thing it's addressing is that if we're in the same group I can rename directories in your ~. If there are any other files you own but I can write to (in directories I can write to), then I can clobber them with my pubkey and rename them to authorized_keys. If there's another directory you own but I can write to, I can install that directory as your ~/.ssh. Then I ssh to the machine with my own pubkey and suddenly I can log in as you. Which isn't normally a thing, the way we work, because the group that owns your ~/.ssh is composed solely of you. But sshd doesn't do the getgrent() thing to verify that, so it has no choice but to assume that group-writable directories are potential uid escalation attacks. The code's not wrong, it's just perhaps not as right as it could be. That said, since one's ~ is normally group-owned by a group consisting solely of one user, defaulting it to 755 instead of 775 would make sshd happy without any real side effects. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 04:02 PM, Kevin Kofler wrote: Neal Becker wrote: Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker Looks like a new change in OpenSSH then, which is IMHO a regression, unless there's a clear security vulnerability being addressed there. OpenSSH has behaved this way as long as I have been using it (I just checked and even sshd_config on a Fedora Core *1* box has the StrictModes option). There's nothing new here at all. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gmHYACgkQ6YSQoMYUY94UXQCeO0O40DMuJIKZqeCtU2hlKoWL pN0An0QhOTzEncpsFedXeq0OtQJAHUnS =ffof -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/19/2012 03:45 PM, Eric Smith wrote: I would claim that the moral right to run whatever software we wish on hardware we own is a negative right; it doesn't put any obligation on another party to help you do it. If you can hack up Fedora to run on a Nokia Windows phone, more power to you, but Nokia and Microsoft aren't obligated to help you do it, and aren't legally prohibited from doing things that make it difficult for you to exercise your moral right. I think I'd disagree with you there. I don't think it's any different from someone using extensive technical measures to prevent anyone other than the authorized dealers of a particular car from servicing it. Such a move would be treated as anti-competitive in many countries, and IMO software should be treated in the same way. Possibly in this example someone might consider Nokia and Microsoft to be infringing their moral right, but (in the US at least) they'd have no recourse. Indeed. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Tue, Jun 19, 2012 at 9:49 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.06.2012 06:45, schrieb Adam Williamson: On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates Ah so you made a BIG MISTAKE as decision and now try to fix it in all sort of ways? who do developers think they are installing SILENT system-upgrades as default? you must not touch the setup of a enduser without a question before [citation needed] so do not fix the rsult, fix the problem and give users back the control of their system Here is a scientific study that refutes your claims: http://www.techzoom.net/publications/silent-updates/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 02:47 PM, Neal Becker wrote: Bryn M. Reeves wrote: On 06/19/2012 02:01 PM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. I think it would be better to ensure the directory is created with the correct permissions. The administrator already has control of the StrictModes setting if they want to relax this restriction. The issue is the admin is likely some poor newb installing fedora on his home computer. I argue the reverse - the knowlegable unix hack can change it to make it stricter. Then that's a policy change that should be proposed and reviewed. It's not a bug and there is nothing to fix. The current behaviour is long standing not only in Fedora but in the usptream project that we are packaging. If you'd like to change that policy I'd submit an RFE to the Fedora openssh maintainers but I wouldn't be too surprised if it was rejected. Imho the issue you describe is better dealt with through documentation for newbie admins than by changing a default that would be hazardous for some common configurations. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gmbwACgkQ6YSQoMYUY97fcwCgwyNUXnkcfYVHnt9v+l/H9sQA O0YAnj6uxrJb0bBqrSzgkHyzz7+CYRYA =hSci -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 828240] perlbrew-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828240 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2012-06-19 10:51:59 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perlbrew-0.43-1.fc17, perl-File-Path-Tiny-0.3-1.fc17, perl-Devel-PatchPerl-0.72-1.fc17, perl-Capture-Tiny-0.18-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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: .so's in devel packages...
On Tue, 2012-06-19 at 09:50 +0200, Michael Schwendt wrote: On Mon, 18 Jun 2012 12:25:12 -0700, Adam Williamson wrote: On Mon, 2012-06-18 at 18:23 +0100, Nelson Marques wrote: Hi all, I have a doubt regarding the '.so's' in devel packages... From my understanding they go in devel packages to allow the installation of several packages with different versioning Not really, no. They go in -devel packages because the only time it's actually appropriate to use a library by referring to its unversioned name is when you're compiling another application against it. It's never safe for anything to access a library at runtime via an unversioned name because there is no guarantee of stability; you can't be at all sure that the version of the library you're calling is actually capable of doing what you're asking it to do. Since the only use of the unversioned 'instance' (symlink, in Fedora...) of a library is in development, naturally it goes in the devel package. We can take advantage of this in generating dependencies, and we do, which is why it's important not to put the .so file in a runtime package, or that runtime package will get a bunch of automatically generated dependencies on -devel packages. And again, this is not the full story. I was trying to keep it simple. There is no hard rule on where non-versioned .so files are to be packaged. They could still be local libs (with no API for public consumption) strictly required by an application. I tend to talk about these as 'plugins', myself, to keep them distinct. They're really _not_ shared libraries, in my worldview anyway - as you say, they present no public API, they're not intended to be used by anything else. They just happen to use the same file format. In the context of the question - which was about .so's which _are_ in -devel packages - it was clear the OP was asking about true shared libraries, not private plugins. They could still be plug-ins, libraries loaded by an application at run-time. They could even be symlinks to versioned plug-in libs, with the application strictly requiring the non-versioned symlink when trying to link with a plug-in at run-time. Where .so files are to be put solely depends on their purpose. Many non-versioned libfoo.so files are just the symlink that make -lfoo work during compilation/linking. But that is not sufficient to require *all* non-versioned .so files to be placed in -devel packages. Indeed. If Fedora Packaging Guidelines are still not clear about this, we may need another update for them. But detailed feedback on them would be appreciated first, IMHO. I think the guidelines assume a baseline level of knowledge about library versioning, which probably isn't a terrible thing, but maybe a reference or two would help. -- 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: *countable infinities only
On Tue, 2012-06-19 at 09:40 +0100, Andrew Haley wrote: On 06/18/2012 06:18 PM, Adam Williamson wrote: I hesitate to put words in people's mouths, and correct me if I'm wrong, but it reads to me as if Jay and others are arguing from an incorrect premise. That premise is to assume that there is a God-given right for people who own computing devices to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_. The problem with this claim is that it equivocates on the meaning of a right. There are at least two definitions of a right in this sense: moral rights and legal rights. These are not the same. Moral rights are not in the gift of any Government. While we may not have a legal right to run whatever software we wish on hardware we own, it's not at all unreasonable to claim a moral right to do so. See later discussion. In the sense of 'attempt to do so', this is certainly supportable, but is a side track to our actual topic here. In the sense of 'demand that the manufacturer make it easy to do so', no, I don't believe it is reasonable to claim such a right, moral or legal. -- 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: time to fix silly ssh bug
Neal Becker wrote: It's been true for a long time that fedora sets up home dir as 775. No, it is not true. $ grep UMASK /etc/login.defs UMASK 077 This setting has been in effect as far back as Fedora 6 and possibly much farther. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
I wrote: I would claim that the moral right to run whatever software we wish on hardware we own is a negative right; it doesn't put any obligation on another party to help you do it. If you can hack up Fedora to run on a Nokia Windows phone, more power to you, but Nokia and Microsoft aren't obligated to help you do it, and aren't legally prohibited from doing things that make it difficult for you to exercise your moral right. Andrew Haley wrote: I think I'd disagree with you there. I don't think it's any different from someone using extensive technical measures to prevent anyone other than the authorized dealers of a particular car from servicing it. Such a move would be treated as anti-competitive in many countries, and IMO software should be treated in the same way. If the things that make it difficult to run software of your choosing on a device can be proven to serve no purpose but to stifle competition, then yes. But often those things have other purposes as well. For example, requiring firmware updates to be signed has a demonstrable purpose in preventing certain types of malware from infecting a product, so that feature cannot be said to serve no purpose other but to stifle competition. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 19 Jun 2012, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 09:40 +0100, Andrew Haley wrote: On 06/18/2012 06:18 PM, Adam Williamson wrote: I hesitate to put words in people's mouths, and correct me if I'm wrong, but it reads to me as if Jay and others are arguing from an incorrect premise. That premise is to assume that there is a God-given right for people who own computing devices to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_. The problem with this claim is that it equivocates on the meaning of a right. There are at least two definitions of a right in this sense: moral rights and legal rights. These are not the same. Moral rights are not in the gift of any Government. While we may not have a legal right to run whatever software we wish on hardware we own, it's not at all unreasonable to claim a moral right to do so. See later discussion. In the sense of 'attempt to do so', this is certainly supportable, but is a side track to our actual topic here. In the sense of 'demand that the manufacturer make it easy to do so', no, I don't believe it is reasonable to claim such a right, moral or legal. -- Adam Williamson Adam, just a short bald claim: In the United States and Europe there is a large body of statute law, regulatory rulings, and court decisions which say that yes, a large powerful company cannot take certain actions to impede competitors. In particular entering into a compact to make Fedora harder to install on every single x86 home computer sold is not allowed. Or once was not allowed. Recently neither regulatory bodies, nor courts, have enforced these old once settled laws and regulations. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNF Any testing time-frame?
On 06/19/2012 03:50 PM, Frank Murphy wrote: Current status Targeted release: Fedora 18 Last updated: 2012-6-19 Percentage of completion: 40% When would it hit rawhide, ballpark? I can't give a date yet, but following the FESCo approval of the feature I made review requests today: https://bugzilla.redhat.com/show_bug.cgi?id=833462 https://bugzilla.redhat.com/show_bug.cgi?id=833511 Just don't hold your fingers crossed that anyone can use this to replace yum with. Not only that a subset of the full yum functionality is supported (see the thread about 'yum history'), but the plugins API etc. is not ready either. ATM it is just what it is: an experimental fork of Yum using libsolv inside. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
(re)starting of a daemon after package update
Hi, I'm trying to find out what is the best place to restart service after update. Dovecot have runs several binaries, has some plugins,... in short, it does not like when it's running during update. I was asked by upstream to modify rpm package to stop it before update and start it afterwards (it does try-restart in %postun now). Looks simple. I check whether it's running in %pre script, create a flag and stop it. After update, I check the flag and start it again. The problem is where to put this second script? Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. So I'm considering 3 options right now 1)ignore reinstall scenario 2)start dovecot in %post script - when there are all new files, but old ones were not removed yet. This can cause trouble for example if dovecot changes config files in conf.d/*.conf and some file gets renamed/removed. 3)start dovecot in %posttrans script - all files are removed, but it's after all packages are updated and old removed. It can take half to five minutes (or even more) - between dovecot is stopped and started again. Is there any other (and better) solution? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, Jun 19, 2012 at 11:50 AM, Eric Smith e...@brouhaha.com wrote: If the things that make it difficult to run software of your choosing on a device can be proven to serve no purpose but to stifle competition, then yes. But often those things have other purposes as well. For example, requiring firmware updates to be signed has a demonstrable purpose in preventing certain types of malware from infecting a product, so that feature cannot be said to serve no purpose other but to stifle competition. Though it serves a genuine interest it is not, however, a least restrictive means. (at least not when it inhibits the user completely) It wouldn't pass the tests we'd apply if it were a state mandated restriction, should the fact that it's not actually a state restriction matter though when it has market force equal to the state's authority? Seems kind of funny that in the US we've been so careful to avoid the state infringing individual rights and then somewhat careless about other powerful entities using massive money, state granted monopolies, and market force to achieve the same ends. It's a mad world. ::shrugs:: One thing we can do is not license our code for these environments that deny users these freedoms. If we think that restrictions on freedom by private parties is an acceptable risk where it wouldn't be acceptable for the government because market solutions work against private parties then we have to do what we can to make the market solutions work. Part of that means that we should stop giving them free software for use in products where they deny users the same freedoms they enjoyed. RedHat and Fedora participating in this technical process which denies freedom to users will simply make the issue harder to address via the market because will make drawing the lines between acceptable and unacceptable behavior harder, potentially resulting in another billion dollar company on the unacceptable side of the line— an outcome which no one wants— and it will undermine the arguments people would make for state intervention, since the antitrust arguments are rather fragile and courts are unlikely to appreciate the nuance of why RedHat and only RedHat (for an extreme example) being able to ship GNU/Linux for popular desktops doesn't disprove competitive concerns. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/19/2012 04:50 PM, Eric Smith wrote: I wrote: I would claim that the moral right to run whatever software we wish on hardware we own is a negative right; it doesn't put any obligation on another party to help you do it. If you can hack up Fedora to run on a Nokia Windows phone, more power to you, but Nokia and Microsoft aren't obligated to help you do it, and aren't legally prohibited from doing things that make it difficult for you to exercise your moral right. Andrew Haley wrote: I think I'd disagree with you there. I don't think it's any different from someone using extensive technical measures to prevent anyone other than the authorized dealers of a particular car from servicing it. Such a move would be treated as anti-competitive in many countries, and IMO software should be treated in the same way. If the things that make it difficult to run software of your choosing on a device can be proven to serve no purpose but to stifle competition, then yes. But often those things have other purposes as well. For example, requiring firmware updates to be signed has a demonstrable purpose in preventing certain types of malware from infecting a product, so that feature cannot be said to serve no purpose other but to stifle competition. That's true, but couldn't you argue something similar thing for a car? As in, Unauthorized shops may install inferior copied parts. We've all heard this kind of thing before, and treat it with the contempt it deserves. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. R. - Original Message - Kevin Fenzi wrote: 18:23:37 nirik #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo 18:23:37 nirik .fesco 868 18:23:42 zodbot nirik: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868 18:24:03 nirik mmaslano was 0 in ticket. 18:24:24 nirik I'm -1. First of all, thank you Kevin for having been the only one stepping up against this nonsense! 18:24:28 limburgher Seemed. . .mildly contentious. . . 18:24:34 mitr I think the only technical objection was that spins won't fit on a CD, The only technical objection which is a blocker as far as we're concerned. Image sizes are even a release blocker! Nobody decided that spins should NOT be CD-sized. There was also the additional objection that the feature brings no practical gain, because -debuginfo is already available and the Retrace Server is available. Later in the discussion, you also pointed out that ABRT probably won't even use this information! So why ship it? Bloat just for the sake of bloat? but when repeatedly asked nobody came up with an example user/ambassador saying that CDs are needed Huh? Examples have been given in the mailing list threads. There's also the constraint that all the spins in both 32-bit and 64-bit editions need to fit on one DVD (the Multi DVD), which very much does matter to the ambassadors. 18:24:54 mezcalero nirik: out of curiosity, why do you say -1? 18:25:17 notting i am +1. obviously would need to be coordinated with any dmz-related rebuilding 18:25:21 * pjones is also +1 18:25:33 nirik I don't think the extra size is worth the gain. I think we can/should work on making abrt better. Right. 18:25:34 hughsie i don't know if i should comment, but from my role as an upstream maintainer, this would be really useful for real life debugging from end users... That's what -debuginfo packages are for! 18:25:44 limburgher mitr: Would dwarf compression help that? 18:25:48 jwb i'm marginally +1 18:25:55 pjones limburgher: no - different set of fields Even if it were affecting the mini-debuginfo fields (it doesn't), compression wouldn't help at all because the live images are already compressed. Even special-case compression has at best a very small effect after xz is run on it. 18:25:56 mitr limburgher: jakub said above that it is orthogonal 18:25:57 t8m as long as it does not replace full backtraces reported in ABRT I'm ok with it so marginally +1 18:26:11 mitr AFAICS this only benefits developers and reading crashes in unexpected components, but given Fedora's target arudence, +21 18:26:14 mitr +1 that is 18:26:16 limburgher mitr, pjones: Missed that, thanks. 18:26:22 limburgher Ok. +1 18:26:24 mjg59 I lean +1 18:26:43 mitr nirik: My best guess is that abrt will just ignore this. So just useless bloat. 18:26:57 nirik #agreed Feature is approved. (+7/-1/0) 18:27:01 _jakub_ I don't see what minidebuginfo gives us as advantage for bugreporting, in theory all you need is addresses (relative to start of DSOs) and their build-ids, everything can be recomputed from that So there, THE expert on the domain tells you the bloat is totally useless, but it's too late, you already rushed out a vote of a bunch of marginal +1s. :-/ 18:27:03 limburgher I wish spins could stay on CDs, but then I still want CD and floppy install media. stares wistfully into the past Floppies are clearly too small. CDs are not. They'd fit all we need if it weren't for the completely useless bloat added by features such as this. I also object to the fact that the feature owners have spun the feature proposal in a deliberately misleading way: * increase quality of bug reports? – ABRT won't even use this! * allow easier support for profiling and user space tracing? – Why wouldn't one just install -debuginfo for those tasks? It's not what a user needs to do every day. * misleading percentages – see Talk page * Also note that for shared objects, we already HAVE symbols for the exported functions (for free!), which is often
Re: *countable infinities only
On Jun 19, 2012, at 10:03 AM, Jay Sulzberger wrote: In the United States and Europe there is a large body of statute law, regulatory rulings, and court decisions which say that yes, a large powerful company cannot take certain actions to impede competitors. Cite the law and case law that applies to these certain actions impeding Fedora (or other Linux). Or please stop repeating this claim. In particular entering into a compact to make Fedora harder to install on every single x86 home computer sold is not allowed. Or once was not allowed. That's not how this works. It's harder to install relative to itself, but the same barrier to installing Fedora applies to installing Windows. That OEMs then find a way around that to pre-install is a function of the high demand for Windows pre-installed on hardware by end users. And harder to install does not mean anything like impossible (or effectively impossible) to install, an alternative. Recently neither regulatory bodies, nor courts, have enforced these old once settled laws and regulations. This large body of law will see that Red Hat had the option to have its keys included with new UEFI hardware, making installations equally easy or difficult for all parties involved, thus the anti-competition claim is rendered moot. That Red Hat declined to have its keys included in on the basis of unfair advantage to other distributions is an unexpected non-competitive behavior from the view of competition law. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jaroslav Reznik wrote: Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). You would probably want to make the target 1 GB (SI units), not 1 GiB. The capacity of thumb drives is measured in SI units, so a 1 GB thumb drive really is 1000^3 bytes, not 1024^3. (They start out with the binary capacity, but some fraction of that is used for overhead, leaving some amount between the SI and binary size. Hence the advertising refers to the SI size.) So we'd like to hear from rel-engs, QA etc. what's theirs position here. AFAIK the only QA issue would be getting notified as to what the new target is, so the size tests can be modified. You probably also want to create a page https://fedoraproject.org/wiki/Releases/18/Spins with the new size. The corresponding page currently exists for 16, but not 17 or 18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Jun 19, 2012, at 5:32 AM, Reindl Harald wrote: but it is NIT better it is a config full of crap and script-code You're about 6 years too late. All upstream EFI support is going into GRUB 2. Red Hat has kept GRUB legacy on life support, and that plug is going to be pulled sooner than later. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Jun 19, 2012, at 7:59 AM, Przemek Klosowski wrote: And, as if on cue, Microsoft just announced their own ARM tablet. Do you feel that they should leave it open to installing alternative OS? Apple does not. Although I don't think they're using UEFI on their hardware, the described boot process sounds similar to Secure Boot. Would they subsidize its hardware cost like they apparently do with Xboxes, and would your answer change depending on whether they do? Doesn't matter. And there's no reason for them to subsidize the hardware, just because of a lockout. There's reason for them to subsidize in order to catch up with iOS and Android, however. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 19 Jun 2012, Chris Murphy li...@colorremedies.com wrote: On Jun 19, 2012, at 10:03 AM, Jay Sulzberger wrote: In the United States and Europe there is a large body of statute law, regulatory rulings, and court decisions which say that yes, a large powerful company cannot take certain actions to impede competitors. Cite the law and case law that applies to these certain actions impeding Fedora (or other Linux). Or please stop repeating this claim. In particular entering into a compact to make Fedora harder to install on every single x86 home computer sold is not allowed. Or once was not allowed. That's not how this works. It's harder to install relative to itself, but the same barrier to installing Fedora applies to installing Windows. That OEMs then find a way around that to pre-install is a function of the high demand for Windows pre-installed on hardware by end users. And harder to install does not mean anything like impossible (or effectively impossible) to install, an alternative. Recently neither regulatory bodies, nor courts, have enforced these old once settled laws and regulations. This large body of law will see that Red Hat had the option to have its keys included with new UEFI hardware, making installations equally easy or difficult for all parties involved, thus the anti-competition claim is rendered moot. That Red Hat declined to have its keys included in on the basis of unfair advantage to other distributions is an unexpected non-competitive behavior from the view of competition law. Chris Murphy Chris, rather than me attempting to explain to you the long history here, I gently suggest that you attempt to study the statutes and regulations and court decisions with some sympathy for free software, and indeed, some sympathy for the rule of law. Thanks, and please forgive me for not answering you in the style you demand. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
On Tue, 2012-06-19 at 09:01 -0400, Neal Becker wrote: It's been true for a long time that fedora sets up home dir as 775. But ssh, with default settings, won't allow public keys to work when home dir has mode 775. Creating the home dirs with 775 mode is actually a bug or misconfiguration on your side. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 19.06.12 16:42, Andre Robatino (robat...@fedoraproject.org) wrote: Jaroslav Reznik wrote: Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). You would probably want to make the target 1 GB (SI units), not 1 GiB. The capacity of thumb drives is measured in SI units, so a 1 GB thumb drive really is 1000^3 bytes, not 1024^3. (They start out with the binary capacity, but some fraction of that is used for overhead, leaving some amount between the SI and binary size. Hence the advertising refers to the SI size.) For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 04:19 PM, Jaroslav Reznik wrote: So we'd like to hear from rel-engs, QA etc. what's theirs position here. First and foremost each SIG sets and choose what is on the spin they ship so if you dont want to ship the bloat that gets added with the MiniDebugInfo then simply don't atleast afaik now there is nothing forcing spins to ship something that they don't want to. With my QA hat on I can tell you that we test components that make up the spin(s) but do not care anything about the size of the spins nor should we since as I said before that decision should be made/handled by the SIG since they are the ones creating the spins to suit *their* target audience as best as they can. And given that releng is a community service like QA I guess the only concern they might have if there are enough resources available to host the spin... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Jóhann B. Guðmundsson wrote: First and foremost each SIG sets and choose what is on the spin they ship so if you dont want to ship the bloat that gets added with the MiniDebugInfo then simply don't atleast afaik now there is nothing forcing spins to ship something that they don't want to. How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) With my QA hat on I can tell you that we test components that make up the spin(s) but do not care anything about the size of the spins nor should we since as I said before that decision should be made/handled by the SIG since they are the ones creating the spins to suit *their* target audience as best as they can. The target size is one of the release-blocking criteria you're supposed to validate. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Application-Plugin-ConfigAuto] Perl 5.16 rebuild
commit a237bd8415c25f65c5097e9fc84f8f1e7c80bd0a
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 19 19:17:15 2012 +0200
Perl 5.16 rebuild
perl-CGI-Application-Plugin-ConfigAuto.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Application-Plugin-ConfigAuto.spec
b/perl-CGI-Application-Plugin-ConfigAuto.spec
index 9980a12..8105da3 100644
--- a/perl-CGI-Application-Plugin-ConfigAuto.spec
+++ b/perl-CGI-Application-Plugin-ConfigAuto.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Application-Plugin-ConfigAuto
Version:1.33
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Easy configuration file management for CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 1.33-4
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.33-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
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: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 05:02 PM, Lennart Poettering wrote: 950 MiB as new target image size. Arguably we should not have any specific target image size but rather a list of valid image sizes ( cd/dvd/usb keys ) for spins to aim at which SIG's themselves choose to use each release cycle and can adjust accordingly which gives them the ability to shrink/expand to suit *their* targets audience needs at any given time. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Kevin Kofler wrote: How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Michael Cronenworth wrote: It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. The only similarity being the separated symbol data from the binary. I do not mean sub-packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Lennart Poettering mzerqung at 0pointer.de writes: For those too lazy to calculate the difference between 1 GB and 1 GiB: 1 GB equals 953 MiB. We hence should probably stick to to 950 MiB as new target image size. To avoid confusion over units or rounding/truncation (1 GB isn't *exactly* 953 MiB, for example), the QA size tests are expressed in bytes - see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 ARM GA Release
The Fedora ARM team is pleased to announce that the Fedora 17 GA release for ARM is now available for download from: http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/ The GA release includes prebuilt images for Versatile Express (QEMU), Trimslice, Beagleboard xM, Pandaboard, Kirkwood Plugs, Highbank and iMX based hardware platforms. Please visit the announcement page for additional information and links to specific hardware images: http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_GA We invite you to download the Fedora 17 GA release and provide your valuable input to the Fedora ARM team. Please join us on the IRC in #fedora-arm on Freenode or send feedback and comments to the ARM mailing list. On behalf of the Fedora ARM team, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 05:15 PM, Kevin Kofler wrote: The target size is one of the release-blocking criteria you're supposed to validate. Yeah but that's just for the Default spin not spins in general which is the Gnome Desktop environment. If we did not have the so called Default we would be validating that spins would fit the valid image size it has chosen for *their* target audience. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 04:32 AM, Reindl Harald wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. -- 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: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 12:49 PM, Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 04:32 AM, Reindl Harald wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? D) Lilo runs -J -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 10:44:00AM -0600, Chris Murphy wrote: On Jun 19, 2012, at 5:32 AM, Reindl Harald wrote: but it is NIT better it is a config full of crap and script-code You're about 6 years too late. All upstream EFI support is going into GRUB 2. Red Hat has kept GRUB legacy on life support, and that plug is going to be pulled sooner than later. F18 is already using grub2 for EFI. I think we can remove grub-legacy now. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 05:49 PM, Jesse Keating wrote: You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? [1] =) JBG 1. http://people.freedesktop.org/~kay/loader/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 1:55 PM, Matthew Garrett mj...@srcf.ucam.org wrote: F18 is already using grub2 for EFI. I think we can remove grub-legacy now. What about the Fedora images for Amazon EC2? I seem to recall that because of pvgrub use they can't use grub2 yet. (I don't claim to be an expert on the cloud images -- I'm just asking a question based on what I seem to recall from earlier conversations.) -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 2012-06-19 at 12:03 -0400, Jay Sulzberger wrote: Adam, just a short bald claim: In the United States and Europe there is a large body of statute law, regulatory rulings, and court decisions which say that yes, a large powerful company cannot take certain actions to impede competitors. In particular entering into a compact to make Fedora harder to install on every single x86 home computer sold is not allowed. Or once was not allowed. Recently neither regulatory bodies, nor courts, have enforced these old once settled laws and regulations. I'm aware of this. So are Red Hat's lawyers, I'm sure. I am inferring from the stuff posted by Matthew so far that they believe there is no basis for a legal complaint in Microsoft's behaviour in this area. I certainly can't see one myself, though of course I am not a lawyer; as I've already noted, it's very hard to characterize Microsoft's behaviour as 'impeding competitors'. They have done nothing at all to prevent anyone else from complying with the Secure Boot specification. -- 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: *countable infinities only
On Tue, 2012-06-19 at 12:10 -0400, Gregory Maxwell wrote: On Tue, Jun 19, 2012 at 11:50 AM, Eric Smith e...@brouhaha.com wrote: If the things that make it difficult to run software of your choosing on a device can be proven to serve no purpose but to stifle competition, then yes. But often those things have other purposes as well. For example, requiring firmware updates to be signed has a demonstrable purpose in preventing certain types of malware from infecting a product, so that feature cannot be said to serve no purpose other but to stifle competition. Though it serves a genuine interest it is not, however, a least restrictive means. (at least not when it inhibits the user completely) It wouldn't pass the tests we'd apply if it were a state mandated restriction, should the fact that it's not actually a state restriction matter though when it has market force equal to the state's authority? I think you're arguing a long way in advance of your evidence here. The Secure Boot requirements either in the UEFI spec or in the Microsoft certification scheme for x86 certainly do not 'inhibit the user completely'; on the contrary they leave all power in the hands of the user, who has only to choose to exercise it. The requirements in the Microsoft certification scheme for ARM can be somewhat more reasonably described as 'inhibiting the user' (though only to an extent), but in that context, they certainly do not have 'market force equal to the state's authority', and are certainly no more restrictive than the system already in use on equivalent devices from competing manufacturers. It's a fun pastime to wave around the concept of competition and monopoly legislation every time Microsoft coughs, but let's face it: when Microsoft actually was guilty of blatant monopoly abuse it took years to reach a fairly weak judgment against them which had virtually no practical consequences. The chances of getting any kind of judicial relief in a case like this where the situation is far less clear-cut than a partisan interest may want it to be seem, to be, astronomical. -- 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: F18 DNF and history
On 19 June 2012 11:51, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Would it be helpful, if there was a list of extensively used options so that DNF knew what high notes it needed to hit sooner rather than later? -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Tue, 2012-06-19 at 12:19 -0400, Jaroslav Reznik wrote: As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG meeting that we would have to break CD size limit (and the breaking of CD size image was used as argument to accept this feature). We agreed that 800 MiB is achievable target: - all spins will still fit Multi Desktop Live DVD - there's still space available for overlay for USB disks - you can still get 800 MiB CD-Rs (may hit HW constraints...) Other possibility is to go directly to 1 GiB but we are not sure there's advantage (at least not now). Contingency plan - at least for one release we'd like to have a 700 MiB KS (with more compromises). So we'd like to hear from rel-engs, QA etc. what's theirs position here. As far as QA is concerned it's entirely your decision (as a personal note to self, I'll have to update the Deliverables SOP draft). We just need to know so we know what limit to check against in testing. As a personal comment, though, doesn't this seem a little fast to make the decision? Wouldn't it at least make sense to wait for minidebuginfo to be implemented, then spin a test KDE image and see exactly how big it turns out with the current package set? Note that spins are not absolutely required to hit their target size at Alpha; it becomes a hard requirement at Beta stage. So you have up until Beta release to make the decision, really. -- 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
