Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Le 13/03/2013 17:16, Remi Collet a écrit : php-magickwand Upstream 1.0.9-2 (yes with a -) includes the fix (and the php54 patch) Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Le 13/03/2013 23:49, Orion Poplawski a écrit : In any case, this is going to be pretty disruptive. I think we need to do some hard thinking about whether we want to go with this naming scheme or not. If we do, I think we need to do IM development in a side tag to work out all the kinks. If consumer correctly use pkg-config information, there should not have any problem... Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Thu, Mar 14, 2013 at 12:20:21AM -0400, Nico Kadel-Garcia wrote: It's unfortunately demoware. While the LinuxBIOS project has optimized BIOS on a few systrems, server grade hardware can take up to five minutes simply to get past all the Power-On-Self-Test operations. And just because the Windows logo is up does not mean the system is actually for another few minutes, while slow and but unreported Hi, I'm not talking about demoware or servers: I said on a laptop and that it is a realistic future. Basically need a Windows logo laptop and no LVM. Servers and multiple OS'es is something different. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On 12. 3. 2013 at 09:46:59, Jan Zelený wrote: Hi guys, as per [1], I'd like to propose some patches for F19 comps. These patches are splitting group called Development Tools into several smaller groups. The purpose of this email is to find out if there is something fundamentally wrong with the change (except for the fact that it is change). These are key points about the patch set: 1. There should be only small visible impact to users. Currently the only tool that is commonly using comps is anaconda and that uses the Developer workstation environment. This group will contain all groups that were created by the split to ensure maximal similarity to the old state of things. 2. All in all, the Development Tools group needed a huge cleanup, as it contained a lot of different tools and/or devel packages but many times these were only fractions of development environments necessary for the particular purpose. These tools are mostly still avaiable in other groups, like C development, Electronic Lab, ... 3. The current idea for Developer Tools group is to contain just tools that are common/usable for development of most programming languages 4. This should bring only the big picture change. No need to discuss what particular packages should be in which group. That can be tuned any time later. 5. More groups targeted at specific areas should be created and/or reviewed soon-ish. Among them: Perl Development Python Development Ruby Development feel free to suggest more development-related areas that you would like to improve. The goal of this effort is to start a process which would lead to more usable comps, so users will be able (and more importantly encouraged) to simply use for example yum to install these environments. By that time, these environments should be cleaned up, in case user wants to install just specific type of devel env, not the entire Developer Workstation [1] https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gro ups Since no comments came on this topic for couple days, I pushed changes to master. Also propagated changes to F20. Again, if you see something wrong with the new partitioning or you have suggestions for further improvement, let me know. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 13/03/13 09:25 PM, Ralf Corsepius wrote: On 03/14/2013 05:03 AM, Subhendu Ghosh wrote: On Mon, Mar 11, 2013 at 2:12 PM, Honza Horak hho...@redhat.com wrote: so why is MariaDB not obsoleting mysql without all this versioning tricks and mysql-oracle installs the server under /usr/local/mysql-oracle/ and provides a mysql-oracle.service? This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal Should an exception be allowed - or is the rule so rigid ? Anything under /usr/local (except of the basic directory layout) is supposed to be 100% under a user's control and not to be touched by distributions. Somewhat oversimplified, this means /usr/local is off-limits of Fedora, no exceptions allowed. ...and for the love of all that's good and holy, please no-one suggest /opt. -- 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: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On 14/03/13 01:18 AM, Remi Collet wrote: Le 13/03/2013 23:49, Orion Poplawski a écrit : In any case, this is going to be pretty disruptive. I think we need to do some hard thinking about whether we want to go with this naming scheme or not. If we do, I think we need to do IM development in a side tag to work out all the kinks. If consumer correctly use pkg-config information, there should not have any problem... Would that be the pkgconfig file whose name changed as part of this change? :) -- 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: Unhelpful update descriptions
- Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar -- 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: Unhelpful update descriptions
On 14/03/13 02:43 AM, Jaroslav Reznik wrote: That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. I've argued somewhat down this line before, but you're taking it _way_ too far. I've been running my entire domain on Fn-1 for three years and it works fine, and I get all the appropriate security updates. It is a thing that works, please don't dismiss it. I snipped the rest of your mail, but I think you're being way too negative. -- 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: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Le 14/03/2013 10:30, Adam Williamson a écrit :
On 14/03/13 01:18 AM, Remi Collet wrote:
Le 13/03/2013 23:49, Orion Poplawski a écrit :
In any case, this is going to be pretty disruptive. I think we need to
do some hard thinking about whether we want to go with this naming
scheme or not. If we do, I think we need to do IM development in a side
tag to work out all the kinks.
If consumer correctly use pkg-config information, there should not have
any problem...
Would that be the pkgconfig file whose name changed as part of this
change? :)
No, as both names are provided.
%{_libdir}/pkgconfig/MagickCore.pc
++%{_libdir}/pkgconfig/MagickCore-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick.pc
++%{_libdir}/pkgconfig/ImageMagick-6.Q16.pc
%{_libdir}/pkgconfig/MagickWand.pc
++%{_libdir}/pkgconfig/MagickWand-6.Q16.pc
And the foo-config commands are unchanged.
%{_bindir}/Magick-config
%{_bindir}/MagickWand-config
%{_bindir}/Wand-config
$ pkg-config MagickWand --cflags --libs
-fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16
-I/usr/include/ImageMagick-6 -lMagickWand-6.Q16 -lm
-lMagickCore-6.Q16
Remi.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
Dne 13.3.2013 21:51, Conrad Meyer napsal(a): On Wed, Mar 13, 2013 at 5:40 AM, Richard W.M. Jones rjo...@redhat.com mailto:rjo...@redhat.com wrote: I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] Similarly, xchat-ruby was broken today. I've bumped the rawhide and F-19 versions in git and issued builds; however, what's the plan to push out the ruby-2.0.0 and Requires: ruby(release) = 2.0.0 packages to F-19 in tandem so as to not break anything? Or is F-19 early enough that we aren't using updates for it yet? Conrad The Ruby 2.0.0 is already in F19 and F20 and no, you don't need to push updates via Bodhi yet. And BTW, you don't have to specify the ruby(release) version anymore. 1) there is dependency on libruby.so.2.0()(64bit) anyway 2) we assume by default, that next Ruby versions will be compatible. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On 14/03/13 02:49 AM, Remi Collet wrote:
Le 14/03/2013 10:30, Adam Williamson a écrit :
On 14/03/13 01:18 AM, Remi Collet wrote:
Le 13/03/2013 23:49, Orion Poplawski a écrit :
In any case, this is going to be pretty disruptive. I think we need to
do some hard thinking about whether we want to go with this naming
scheme or not. If we do, I think we need to do IM development in a side
tag to work out all the kinks.
If consumer correctly use pkg-config information, there should not have
any problem...
Would that be the pkgconfig file whose name changed as part of this
change? :)
No, as both names are provided.
%{_libdir}/pkgconfig/MagickCore.pc
++%{_libdir}/pkgconfig/MagickCore-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick.pc
++%{_libdir}/pkgconfig/ImageMagick-6.Q16.pc
%{_libdir}/pkgconfig/MagickWand.pc
++%{_libdir}/pkgconfig/MagickWand-6.Q16.pc
And the foo-config commands are unchanged.
%{_bindir}/Magick-config
%{_bindir}/MagickWand-config
%{_bindir}/Wand-config
$ pkg-config MagickWand --cflags --libs
-fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16
-I/usr/include/ImageMagick-6 -lMagickWand-6.Q16 -lm
-lMagickCore-6.Q16
Ah, I missed that it was just an addition.
--
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: rawhide report: 20130313 changes
The message bus is your friend here: Mar 13 13:34:10 fedmsg-bot compose.rawhide.rsync.start -- started rsyncing rawhide compose for public consumption https://alt.fedoraproject.org/pub/fedora/linux/development/rawhide Is there a web page where I can see the whole history of fedmsg messages (e.g. several days back)? That would be very helpful for those of us who doesn't run our computers 24x7 and can't be connected to #fedora-fedmsg all the time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
Dne 13.3.2013 14:28, Dennis Gilmore napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:03:26 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 10:09, Peter Robinson napsal(a): On Wed, Mar 13, 2013 at 8:25 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, F19 has been branched, please be sure to do a git pull --rebase to pick up the new branch, additionally rawhide/f20 has had inheritance cut off from previous releases, so this means that anything you do for f19 you also have to do in the master branch and do a build there. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. No, branching is the correct time to do it. Mandated tagging through koji and inheritance are completely unrelated. At the moment koji tags the packages straight into f19 rather than tagging to f19-updates-candidate and having bodhi deal with the tagging. Inheritance only affect whether something is built in f19 is inherited through to rawhide. There was a discussion some time ago about this so presumably this change was either a decision by release engineering or FESCo. I am afraid that the discussion was more generic, i.e. Rawhide should not inherit from branched Fedora and since I remember the main reason for breaking inheritance was Bodhi and Bodhi is not yet in a game, it should be clarified and adjusted. Vít Peter https://fedorahosted.org/fesco/ticket/1005 i was asked to cut it at branching time, thats exactly what I did Dennis, I don't blame you, but since you refer the ticket here, I can easily quote: However, this also means users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo. Sometimes this delay is quite long during freezes. And this exact point does not apply yet and nobody realized that. I opened new ticket for FESCo to re-evaluate it. Vít [1] https://fedorahosted.org/fesco/ticket/1099 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-1.fc19
The lightweight tag 'perl-YAML-LibYAML-0.41-1.fc19' was created pointing to: 0c4fe66... Update to 0.41 -- 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-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.41-1.fc20
The lightweight tag 'perl-YAML-LibYAML-0.41-1.fc20' was created pointing to: 0c4fe66... Update to 0.41 -- 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: rawhide report: 20130313 changes
On Thu, Mar 14, 2013 at 3:02 AM, Kamil Paral kpa...@redhat.com wrote: The message bus is your friend here: Mar 13 13:34:10 fedmsg-bot compose.rawhide.rsync.start -- started rsyncing rawhide compose for public consumption https://alt.fedoraproject.org/pub/fedora/linux/development/rawhide Is there a web page where I can see the whole history of fedmsg messages (e.g. several days back)? That would be very helpful for those of us who doesn't run our computers 24x7 and can't be connected to #fedora-fedmsg all the time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel 19 was awesome to my rawhide myachine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Every text editor crashed
On Wed, Mar 13, 2013 at 10:08 PM, Christopher Meng cicku...@gmail.com wrote: BZ #920996 and BZ#919267. GTK related. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Every gtk text editor is not gedit. yum install geany yum install mate-text-editor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Ray Strode wrote: We start plymouth in the initrd, and we don't have fonts, translations, font rendering libraries or anything in the initrd. we could ship those things in the initrd but it would make the initrd substantially larger. How about turning the messages that Plymouth needs to display into pictures? There would be a set of pre-rendered image files with translations of the phrase Press Esc if you want to see what's going on. for all the different locales, and the correct image for the configured locale would be included when the initrd was generated. Plymouth would then just put that picture up on the screen, not caring about what language it's written in or with which font. The passphrase prompt could be handled the same way. Instead of just a picture of a padlock there would be a picture with a translation of Enter the disk encryption passphrase. Are there other messages that Plymouth may need to display? I would guess there aren't so many that the scalability of this approach would be a problem. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Thu, Mar 14, 2013 at 3:30 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Ray Strode wrote: We start plymouth in the initrd, and we don't have fonts, translations, font rendering libraries or anything in the initrd. we could ship those things in the initrd but it would make the initrd substantially larger. How about turning the messages that Plymouth needs to display into pictures? There would be a set of pre-rendered image files with translations of the phrase Press Esc if you want to see what's going on. for all the different locales, and the correct image for the configured locale would be included when the initrd was generated. Plymouth would then just put that picture up on the screen, not caring about what language it's written in or with which font. The passphrase prompt could be handled the same way. Instead of just a picture of a padlock there would be a picture with a translation of Enter the disk encryption passphrase. Are there other messages that Plymouth may need to display? I would guess there aren't so many that the scalability of this approach would be a problem. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel When I think of improving the booting experience tonight, I think of a booter that can't repair itself when it's broken not Plymouth...can we fix real broken things before we fix an annoying thing like plymouth? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, Mar 14, 2013 at 2:43 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar -- 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 How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 08:49 PM, Michael Cronenworth wrote: On 03/11/2013 02:41 PM, Björn Persson wrote: Yes, why not display the Grub menu? Because it's the year 2013. Not 1999. Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. Not displaying any text at all would make it harder to understand that the time to press that key is now. Many people won't even understand that they have an opportunity to press a key. Does any other computing device you own prompt you for a boot menu? Your mobile phone? Your TV (which likely has embedded Linux)? Your car? My computer is not a mobile phone or car. I much prefer it to *not* become mobile phone-like cripple. Why is that? Could it be because a boot menu is not necessary for normal operation? A normal user doesn't need to wonder Hey what kernel do I need to boot today? every time their system boots. ...until something breaks. *Then* suddenly you discover that you _do_ need a way to see all this stuff (and more). If you are a developing developer and need to boot a different kernel or change kernel parameters then you know how to get into the boot menu -- on-screen prompts or no on-screen prompts. There is a time when developers need to distance themselves from user-interfaces and realize they are not the only user of the user-interface. This is one of those times. Intentionally dumbing down the system so that even idiots can use it will result in *only* idiots using it. If you don't want to see boot menu, there is a way to switch it off. This behavior can be made much easier to enable, if necessary - along the lines of Don't ask me again checkboxes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. So maybe we should just ship code right from the Git masters of all upstreams? I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpH76gJyleNb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 09:20 PM, seth vidal wrote: On Mon, 11 Mar 2013 21:07:32 +0100 Lennart Poettering mzerq...@0pointer.de wrote: I don't think we should generate any message. Nothing at all. My BIOS doesn't print a single line, and neither does the kernel if quiet is used (which is the default). I really don't see why Plymouth or the boot loader should print any more -- unless a real problem happens, or the user explicitly asked for more, or the boot takes very long. Entering the boot loader is something that is a debugging feature, a tool for professionals. It shouldn't be too hard to expect from them to remember something as simple as maybe press shift or Space or Esc to get the boot menu or more verbose output. I mean, honestly, that's probably what most people would try automatically anyway if they want feedback from the machine. I'm mostly concerned with making new professionals. We have to make the secret information discoverable if we want people to poke and prod around. If the bioses and systems years ago had been opaque we wouldn't have gotten this far. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Wed, 2013-03-13 at 14:26 -0600, Kevin Fenzi wrote: On Wed, 13 Mar 2013 20:20:01 + Debarshi Ray rishi...@lostca.se wrote: ...snip... I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Spot had a plan related to this. basically bundle up monthly updates to all critpath (non security) stuff, QA it, and then push it out as a bundle. I see one problem with this approach: we're bound to have some update slipping into stable which breaks something that isn't caught in testing. If we do something like that, there needs to be a fast lane for updates fixing such broken updates so people don't have to wait a month for the fix. Unless... People using yum/other tools directly could keep doing whatever they currently do. ...this means that these bundles mean something additional to the normal repositories. I don't know about Spot's plan you mentioned, where can I find information about it? Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 09:45 PM, Nicolas Mailhot wrote: Le Lun 11 mars 2013 21:16, Lennart Poettering a écrit : On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote: On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. Somebody who is capable of installing multiple operating systems on one machine should easily be savvy enough to remember that pressing shift/esc/space/f2/whatever gets him the boot menu. If you installed multiple OSes and noticed that the boot menu is gone, wouldn't pressing these keys be your natural reaction anyway? My natural reaction would be to curse whoever is making me waste minutes in press-random-keys-to-see-if-you-can-unlock-boot games to win a few seconds. I'm pretty sure any poll would find the same result. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 09:50 PM, Björn Persson wrote: Chris Murphy wrote: A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. What if I need to revert to the previous kernel, or add some kernel parameter to get the system up enough to solve some boot problem? Detecting that the previous boot failed is nice and all ...and impossible. System may be very sure it booted just fine. It can easily be completely unaware that display isn't actually displaying any image at all, because there is a tiny buglet in the new version of X or video driver. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 10:30 PM, Björn Persson wrote: Lennart Poettering wrote: On Mon, 11.03.13 21:20, Björn Persson (bjorn@rombobjörn.se) wrote: Peter Robinson wrote: It use to only be displayed if there was more than one OS configured or if the CTRL was held down. Having to press a particular key means you have to get it at the second or two where grub isn't displayed. The Ctrl option is quite nice as you can do it before the BIOS disappears. But how are users supposed to discover it? By hooking this up to keys people would natrually try, such as shift, space, enter, escape, or whatever windows does for their boot menu stuff. I would probably pound frantically on the keyboard trying to hit the right key during some unknown, short interval. If there were no interval at all and the right solution were to be holding a key at the right moment, then I'd probably have about a 50% chance of not pressing any key at that moment. And after I happened to press the right key at the right moment I still wouldn't know which of the keys I pressed was the right one, so I'd have to pound frantically the next time too. After a few iterations I'd also be cursing the idiots who designed such an unfriendly user interface just because they didn't want any text on the screen. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
recent kernel broke suspend
I'm getting unreliable suspend. This seems to be the problem: Mar 14 05:39:58 nbecker1 kernel: [140688.356449] nouveau [ DRM] suspending fbcon... Mar 14 05:39:58 nbecker1 kernel: [140688.356459] nouveau [ DRM] suspending display... Mar 14 05:39:58 nbecker1 kernel: [140688.356473] nouveau [ DRM] unpinning framebuffer(s)... Mar 14 05:39:58 nbecker1 kernel: [140688.356532] nouveau [ DRM] evicting buffers... Mar 14 05:39:58 nbecker1 kernel: [140688.359764] nouveau [ DRM] suspending client object trees... Mar 14 05:39:58 nbecker1 kernel: [140690.360776] nouveau E[ PDISP] [:01:00.0][0xc000827c][88013541ea80] fini timeout, 0x8e061008 Mar 14 05:39:58 nbecker1 kernel: [140690.360778] nouveau E[ PDISP] [:01:00.0][0xc000827c][88013541ea80] failed suspend, -16 Mar 14 05:39:58 nbecker1 kernel: [140690.360780] nouveau E[ DRM] 0xd150:0xd15c7c01 suspend failed with -16 Mar 14 05:39:58 nbecker1 kernel: [140690.360831] nouveau E[ DRM] 0x:0xd150 suspend failed with -16 Mar 14 05:39:58 nbecker1 kernel: [140690.360866] nouveau E[ DRM] 0x:0x suspend failed with -16 Mar 14 05:39:58 nbecker1 kernel: [140690.361738] nouveau E[ DRM] 0x:0x suspend failed with -16 Mar 14 05:39:58 nbecker1 kernel: [140690.362347] nouveau [ DRM] resuming display... Mar 14 05:39:58 nbecker1 kernel: [140690.376607] nouveau E[ PDISP] [:01:00.0] chid 0 mthd 0x0080 data 0x 0x10055080 Mar 14 05:39:58 nbecker1 kernel: [140692.376637] nouveau E[ PDISP] [:01:00.0] chid 0 mthd 0x0080 data 0x 0x10055080 Mar 14 05:39:58 nbecker1 kernel: [140692.614708] nouveau E[ PDISP] [:01:00.0] chid 0 mthd 0x0080 data 0x 0x10055080 Mar 14 05:39:58 nbecker1 kernel: [140692.614734] nouveau E[ PDISP] [:01:00.0] chid 0 mthd 0x0080 data 0x 0x10055080 Mar 14 05:39:58 nbecker1 kernel: [140695.607810] pci_pm_suspend(): nouveau_pmops_suspend+0x0/0x80 [nouveau] returns -16 Mar 14 05:39:58 nbecker1 kernel: [140695.607819] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -16 Mar 14 05:39:58 nbecker1 kernel: [140695.607829] PM: Device :01:00.0 failed to suspend async: error -16 Mar 14 05:39:58 nbecker1 kernel: [140695.607902] PM: Some devices failed to suspend -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 10:48 PM, Björn Persson wrote: Lennart Poettering wrote: (And on EFI systems that do not initialize USB anymore during POST, you have to go through the OS to get into the boot loader anyway...) That's going to be real fun when the OS fails to boot, and I can't fix the boot because I can't get into the boot loader because the OS fails to boot. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 01:07 PM, Nico Kadel-Garcia wrote: On Mon, Mar 11, 2013 at 4:16 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote: On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. Somebody who is capable of installing multiple operating systems on one machine should easily be savvy enough to remember that pressing shift/esc/space/f2/whatever gets him the boot menu. If you installed multiple OSes and noticed that the boot menu is gone, wouldn't pressing these keys be your natural reaction anyway? Lennart I've been a hardware evaluator. Absolutely not, because different hardware components have different, and fundamentally unpredictable, configuration keys. Hiding the particular configuration key for the bootloader, that may be only work for a few seconds in a lengthy boot process on, say, an HP high end controller with several disk controller cards, is wasting the system engineer's time with repeated reboots where *she can't tell when to push the escape button without triggering the wrong configuration tool*. I would reject out of hand tools that did this. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Why is it so imtimidating / confusing to noobs? Dan On Wednesday, March 13, 2013, deep64blue wrote: On Wed Mar 13 00:32:09 UTC 2013 Máirín Duffy wrote: Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. Surely if our target audience / user base is those who have a capability / interest in contributing then we shouldn't be looking to dumb the boot experience down - that would probably be a reasonable choice for Mint or Ubuntu but I fail to see why it's a good one for Fedora. Alan -- devel mailing list devel@lists.fedoraproject.org javascript:; https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 02:33 PM, Lennart Poettering wrote: On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. This is way up on my list of most non-sensical arguments about building OSes, right next to Linux is about choice. This bullshit about boot times don't matter is just entirely bogus, and it doesn't get better by constant repitition. Fast boot times matter on desktops, Depends on what is fast. 1-2 seconds during boot is not important on desktops. they matter on embedded, they matter on mobile, Yes. they matter or servers Wrong. Servers can spare 5s of seconds. Normally, servers need reboots much less often than once a day. Fast boot times save you time and energy. Phlease. Fast boot times improve the first impression our OS makes on people. How about first impression an OS would do if it broke after upgrade and you need black magic to even _see_ where boot fails? You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. I aqree that reasonably fast boot is good. I disagree that it should be instantaneous (by default) on desktops or laptops. Show Press ESC to see boot menu for one second before booting the default kernel. Fast enough. Clear enough. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Request 17: Implement Bugzilla Account Association
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/17/ --- (Updated March 14, 2013, 11:24 a.m.) Review request for blockerbugs. Bugs: 347 https://fedorahosted.org/fedora-qa/ticket/347 Repository: blockerbugs Description --- This is a patch for tickets 347, 348, 349 and 350. Diffs (updated) - testing/test_bugchange.py 65f291122b4ae687872170517d196a621d548152 blockerbugs/util/bz_interface.py a8958be674e839d6c99694e33440a26331a8b041 blockerbugs/templates/propose_bug.html c97d72303dff2f49e4bb8bc5ff5fc2f4c764ce8b blockerbugs/templates/login.html 20674fe93eb96c6e1e9b12b5988cad67dc1a5181 blockerbugs/templates/layout.html 6d0ae9a7bc913aa408985028db4494d51379da9c blockerbugs/templates/fas_bugzilla.html PRE-CREATION blockerbugs/templates/base_nav.html ce7a7bb478ad57a65d646fa7326a210c6a4eb131 blockerbugs/models/userinfo.py PRE-CREATION blockerbugs/controllers/users.py 30b5fb5c8ef2196979a2d22c4380f302a5ce951a blockerbugs/controllers/main.py ce26c641b9db05f11510f16177b017a56cf757c2 blockerbugs/controllers/forms.py b213c055d9297b59c6cf5d83358dcd14e265e345 alembic/versions/1d12b74d12bd_add_userinfo_table.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/17/diff/ Testing --- Thanks, Martin Krizek ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Review Request 17: Implement Bugzilla Account Association
On March 13, 2013, 9:32 p.m., Tim Flink wrote: blockerbugs/controllers/main.py, line 293 http://reviewboard-tflink.rhcloud.com/r/17/diff/1/?file=232#file232line293 How come you broke this up as a separate function? It seems a bit stylistically different from the rest of the code Initially, there were some checks that were not necessary in the end. I moved the code out of the function. Good point. On March 13, 2013, 9:32 p.m., Tim Flink wrote: blockerbugs/models/userinfo.py, line 28 http://reviewboard-tflink.rhcloud.com/r/17/diff/1/?file=234#file234line28 do we know if there are limits on the possible length of these usernames? I assume that there are but then again, I made the same assumption about other fields as well First I thought that usernames are of an e-mail form (which is not true) so that's why I put '255'. However I think it's safe to assume no one will have username longer than 255 characters, right? On March 13, 2013, 9:32 p.m., Tim Flink wrote: blockerbugs/templates/fas_bugzilla.html, line 30 http://reviewboard-tflink.rhcloud.com/r/17/diff/1/?file=236#file236line30 Stylistically, this doesn't match the existing login page that we have for FAS - it would be better if they matched Fair enough, fixed. On March 13, 2013, 9:32 p.m., Tim Flink wrote: blockerbugs/util/bz_interface.py, line 190 http://reviewboard-tflink.rhcloud.com/r/17/diff/1/?file=240#file240line190 If we get here, the app will blow up with an unhandled exception which originates from my code but as I'm looking at it again, I'm wondering about having a try/catch in the controller which sets an error in the proposal form and lets the user re-submit So I put try/catch block in the controller, let me know what you think. - Martin --- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/17/#review17 --- On March 14, 2013, 11:24 a.m., Martin Krizek wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/17/ --- (Updated March 14, 2013, 11:24 a.m.) Review request for blockerbugs. Bugs: 347 https://fedorahosted.org/fedora-qa/ticket/347 Repository: blockerbugs Description --- This is a patch for tickets 347, 348, 349 and 350. Diffs - testing/test_bugchange.py 65f291122b4ae687872170517d196a621d548152 blockerbugs/util/bz_interface.py a8958be674e839d6c99694e33440a26331a8b041 blockerbugs/templates/propose_bug.html c97d72303dff2f49e4bb8bc5ff5fc2f4c764ce8b blockerbugs/templates/login.html 20674fe93eb96c6e1e9b12b5988cad67dc1a5181 blockerbugs/templates/layout.html 6d0ae9a7bc913aa408985028db4494d51379da9c blockerbugs/templates/fas_bugzilla.html PRE-CREATION blockerbugs/templates/base_nav.html ce7a7bb478ad57a65d646fa7326a210c6a4eb131 blockerbugs/models/userinfo.py PRE-CREATION blockerbugs/controllers/users.py 30b5fb5c8ef2196979a2d22c4380f302a5ce951a blockerbugs/controllers/main.py ce26c641b9db05f11510f16177b017a56cf757c2 blockerbugs/controllers/forms.py b213c055d9297b59c6cf5d83358dcd14e265e345 alembic/versions/1d12b74d12bd_add_userinfo_table.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/17/diff/ Testing --- Thanks, Martin Krizek ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: New groups in comps for F19
On Tue, Mar 12, 2013 at 1:46 AM, Jan Zelený jzel...@redhat.com wrote: Hi guys, as per [1], I'd like to propose some patches for F19 comps. These patches are splitting group called Development Tools into several smaller groups. The purpose of this email is to find out if there is something fundamentally wrong with the change (except for the fact that it is change). These are key points about the patch set: 1. There should be only small visible impact to users. Currently the only tool that is commonly using comps is anaconda and that uses the Developer workstation environment. This group will contain all groups that were created by the split to ensure maximal similarity to the old state of things. 2. All in all, the Development Tools group needed a huge cleanup, as it contained a lot of different tools and/or devel packages but many times these were only fractions of development environments necessary for the particular purpose. These tools are mostly still avaiable in other groups, like C development, Electronic Lab, ... 3. The current idea for Developer Tools group is to contain just tools that are common/usable for development of most programming languages 4. This should bring only the big picture change. No need to discuss what particular packages should be in which group. That can be tuned any time later. 5. More groups targeted at specific areas should be created and/or reviewed soon-ish. Among them: Perl Development Python Development Ruby Development feel free to suggest more development-related areas that you would like to improve. The goal of this effort is to start a process which would lead to more usable comps, so users will be able (and more importantly encouraged) to simply use for example yum to install these environments. By that time, these environments should be cleaned up, in case user wants to install just specific type of devel env, not the entire Developer Workstation [1] https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Please undo this change immediately and wait more than 2 days before you split such a massive group of important packages. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On Thu, 2013-03-14 at 04:48 -0700, Dan Mashal wrote: Please undo this change immediately and wait more than 2 days before you split such a massive group of important packages. Maybe you could say what you find problematic with these changes instead of this aggressive tone? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On 14. 3. 2013 at 04:48:33, Dan Mashal wrote: On Tue, Mar 12, 2013 at 1:46 AM, Jan Zelený jzel...@redhat.com wrote: Hi guys, as per [1], I'd like to propose some patches for F19 comps. These patches are splitting group called Development Tools into several smaller groups. The purpose of this email is to find out if there is something fundamentally wrong with the change (except for the fact that it is change). These are key points about the patch set: 1. There should be only small visible impact to users. Currently the only tool that is commonly using comps is anaconda and that uses the Developer workstation environment. This group will contain all groups that were created by the split to ensure maximal similarity to the old state of things. 2. All in all, the Development Tools group needed a huge cleanup, as it contained a lot of different tools and/or devel packages but many times these were only fractions of development environments necessary for the particular purpose. These tools are mostly still avaiable in other groups, like C development, Electronic Lab, ... 3. The current idea for Developer Tools group is to contain just tools that are common/usable for development of most programming languages 4. This should bring only the big picture change. No need to discuss what particular packages should be in which group. That can be tuned any time later. 5. More groups targeted at specific areas should be created and/or reviewed soon-ish. Among them: Perl Development Python Development Ruby Development feel free to suggest more development-related areas that you would like to improve. The goal of this effort is to start a process which would lead to more usable comps, so users will be able (and more importantly encouraged) to simply use for example yum to install these environments. By that time, these environments should be cleaned up, in case user wants to install just specific type of devel env, not the entire Developer Workstation [1] https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_g roups Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Please undo this change immediately and wait more than 2 days before you split such a massive group of important packages. Dan, thanks for your input. Did it break something for you? As I indicated above, the split itself should have no effect for vast majority of users. The only thing that might have some impact is the cleanup of packages. However that impact will not be major, as many of these packages are in different developer- focused groups anyway. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, Mar 14, 2013 at 11:53 AM, Debarshi Ray rishi...@lostca.se wrote: RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. First even if broken is a pretty extreme interpretation of First. First working is much better - and it fits with the purpose of a distribution, to make sure that the various pieces are integrated together (and to help upstream make it happen if necessary). I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Separate updates to individual packages have don't set up so high expectations. An update to a package implies that 1) (optionally) upstream released it and is happy with the quality, and 2) a Fedora packager has used it and is happy with the quality of a package. A update bundle implies the weight of the whole project behind the bundle. Where are the people signing up to do the extra work to achieve this higher level of quality? As it is, many individual packages don't get any testing; if nothing changes, the individual packages still won't get any testing, and the bundle won't be tested any more than the individual packages either. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Dne 14.3.2013 10:43, Jaroslav Reznik napsal(a): - Original Message - unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should have a guideline on the minimum amount Or maybe the question should be: should we be pushing this many updates for stable releases? I was running Fedora 17 on a laptop till a couple weeks back and I kept getting nagged by PackageKit every other evening. Atleast twice a week. That's more problem of how we treat our stable releases. Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. Take Fn - some teams are trying to mimic Rawhide-like style, some teams are not touching it even with stick and would ban any update, so currently it's mix of Fn-1 and the idea how should Rawhide look like. Take Rawhide - we are now trying to solve how to make it usable for developers, not talking about users... The idea during the stable craziness was to make it usable and replacement of Fn for people who wants live release, it did not happen (yet). = no flexibility, no way how to make different users happy, more way how to make unhappy everyone, as it's really not clear what should look like). Yes, you can enforce no updates policy, but take a look above... My idea was (and still is) - use these three levels! Fn-1 supported, stable release, updates in batch (where and when it makes sense) + make sure security updates lands on time. Fn as a living release, slowing down before it becomes Fn-1. So we can release our hands trying make Rawhide replacement for alive release and make sure it's usable for development. It also makes more seamless transition between releases (what Spot wants to solve with different release numbering - as we really fail there - we care about not touching stable release and then we push on users massive changes with a new release). And yes, otherwise it does not make sense to have two stable (and mostly stalled and dead releases as written in policy). Let's use this opportunity (and no, it's not LTS proposal, maybe it sounds a little bit Debianish ;-). Jaroslav It seems to be that you contradict to what update policy suggest [1]. Let me quote: we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time. I read it in short as no updates except bugfixes. So if Fn-1 is almost dead, it is by Fedora policy, not by non-willingness. For me, it is fine to do one update to Fn+1 every half year and then just get bugfixes. And I believe it is pretty sensible. Vít [1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/14/2013 06:52 AM, Denys Vlasenko wrote: On 03/11/2013 08:49 PM, Michael Cronenworth wrote: On 03/11/2013 02:41 PM, Björn Persson wrote: Yes, why not display the Grub menu? Because it's the year 2013. Not 1999. Whether any text is displayed or not, there still needs to be a long enough pause that the user has time to press a key. Not displaying any text at all would make it harder to understand that the time to press that key is now. Many people won't even understand that they have an opportunity to press a key. Does any other computing device you own prompt you for a boot menu? Your mobile phone? Your TV (which likely has embedded Linux)? Your car? My computer is not a mobile phone or car. I much prefer it to *not* become mobile phone-like cripple. Why is that? Could it be because a boot menu is not necessary for normal operation? A normal user doesn't need to wonder Hey what kernel do I need to boot today? every time their system boots. ...until something breaks. *Then* suddenly you discover that you _do_ need a way to see all this stuff (and more). If you are a developing developer and need to boot a different kernel or change kernel parameters then you know how to get into the boot menu -- on-screen prompts or no on-screen prompts. There is a time when developers need to distance themselves from user-interfaces and realize they are not the only user of the user-interface. This is one of those times. Intentionally dumbing down the system so that even idiots can use it will result in *only* idiots using it. If you don't want to see boot menu, there is a way to switch it off. This behavior can be made much easier to enable, if necessary - along the lines of Don't ask me again checkboxes. +1 -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 04:09 AM, yersinia wrote: On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh dwa...@redhat.com mailto:dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 Here some more info for this apparent regression http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415 Best Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Kees, could you explain how these restrictions would help secure Fedora and any potential side effects. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFBy+AACgkQrlYvE4MpobO0CQCdHilzfd1TjE1RAllQ1YsmXj43 jwIAn1KH7+Tbm+a9TBQdX5CN5vagjh8t =it6d -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/14/2013 07:06 AM, Denys Vlasenko wrote: On 03/11/2013 10:48 PM, Björn Persson wrote: Lennart Poettering wrote: (And on EFI systems that do not initialize USB anymore during POST, you have to go through the OS to get into the boot loader anyway...) That's going to be real fun when the OS fails to boot, and I can't fix the boot because I can't get into the boot loader because the OS fails to boot. +1 Yeah Lennart what do you do then? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130314 changes
Summary: Added Packages: 1 Removed Packages: 1 Upgraded Packages: 45 Size of added packages: 5107 (5.0 k) Size change of modified packages: 8168436 (7.8 M) Size of removed packages: 29396 (29 k) Size change: 8144147 (7.8 M) Compose finisheded at Thu Mar 14 10:51:53 UTC 2013 -- devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages Currently contains a nice mix of 18, 19 and 20 packages... And I cannot currently upgrade to rawhide without changing the URL in the repo file. Do you have the appropriate fedora-release for f20? Also ruby, python, php, perl and other things don't look happy. The ruby issue people are aware of, it was posted that there was still issues to be cleaned up with ruby. Often at branch time it takes a day or two for things to settle back down into a groove. Also please trim off unnecessary stuff to your reply. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130314 changes
On Thu, Mar 14, 2013 at 6:46 AM, Peter Robinson pbrobin...@gmail.com wrote: Summary: Added Packages: 1 Removed Packages: 1 Upgraded Packages: 45 Size of added packages: 5107 (5.0 k) Size change of modified packages: 8168436 (7.8 M) Size of removed packages: 29396 (29 k) Size change: 8144147 (7.8 M) Compose finisheded at Thu Mar 14 10:51:53 UTC 2013 -- devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages Currently contains a nice mix of 18, 19 and 20 packages... And I cannot currently upgrade to rawhide without changing the URL in the repo file. Do you have the appropriate fedora-release for f20? Also ruby, python, php, perl and other things don't look happy. The ruby issue people are aware of, it was posted that there was still issues to be cleaned up with ruby. Often at branch time it takes a day or two for things to settle back down into a groove. Also please trim off unnecessary stuff to your reply. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I just went from F18 to F20. I sure hope I do now. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Thu, 2013-03-14 at 09:09 -0400, Steve Clark wrote: On 03/14/2013 07:06 AM, Denys Vlasenko wrote: On 03/11/2013 10:48 PM, Björn Persson wrote: Lennart Poettering wrote: (And on EFI systems that do not initialize USB anymore during POST, you have to go through the OS to get into the boot loader anyway...) That's going to be real fun when the OS fails to boot, and I can't fix the boot because I can't get into the boot loader because the OS fails to boot. +1 Yeah Lennart what do you do then? If AIUI only the OS sets up USB, only the USB will be able to use it. Unless GRUB does its own USB setup, it simply doesn't matter in that case whether or not the GRUB menu is shown, if you can't type in it. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IPC-Cmd] Set epoch to compete with core module from perl.spec
commit d1d0b17858e94a86e077babf4d822c17e01c3075
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 14 14:56:11 2013 +0100
Set epoch to compete with core module from perl.spec
perl-IPC-Cmd.spec |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-IPC-Cmd.spec b/perl-IPC-Cmd.spec
index 0e778b0..38909d0 100644
--- a/perl-IPC-Cmd.spec
+++ b/perl-IPC-Cmd.spec
@@ -1,6 +1,8 @@
Name: perl-IPC-Cmd
+# Epoch to compete with perl.spec
+Epoch: 1
Version:0.80
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Finding and running system commands made easy
License:GPL+ or Artistic
Group: Development/Libraries
@@ -63,6 +65,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Mar 14 2013 Petr Pisar ppi...@redhat.com - 1:0.80-2
+- Set epoch to compete with core module from perl.spec
+
* Mon Mar 04 2013 Petr Pisar ppi...@redhat.com - 0.80-1
- 0.80 bump
--
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-IPC-Cmd/f19] Set epoch to compete with core module from perl.spec
Summary of changes: d1d0b17... Set epoch to compete with core module from perl.spec (*) (*) 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: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Why not add an LSM call, security_follow_restricted_link()? Then you could ship this protection with SELinux policy, and even turn it off per-label if specific applications need the old behavior. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Wed, 2013-03-13 at 22:49 +0100, Kevin Kofler wrote: So did I, and I think his proposal is an awful idea. (Unfortunately, question time at DevConf is always very short, so I didn't get to voice my disapproval in the talk.) We are not Window$ (think patch Tuesday) nor RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! I also don't think such huge batches can realistically be tested. Kevin Kofler Well this is a really easy one to solve; update bundling probably isn't necessary. Already PackageKit has a setting to control how often it checks for updates: hourly, daily (default), or weekly. Just add a monthly option, and change the default to something more sane than daily (weekly sounds like a better default than daily or monthly?); people who want faster updates can still get them (not the case if you start holding updates). That should be really simple. Alternatively, add a new setting for security updates so that those come daily by default while other updates are weekly (or monthly or annually or whatever) by default; not sure how much work that would be, but PackageKit already distinguishes between security and nonsecurity updates. 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: Improving the Fedora boot experience
On Thu, 2013-03-14 at 11:52 +0100, Denys Vlasenko wrote: Intentionally dumbing down the system so that even idiots can use it will result in *only* idiots using it. You should tone down your comments a little. Denigrating people who don't share knowledge about computers at a level similar to yours as idiots doesn't help your argument at all. In a similar vein, athletes might call you an unfit cripple if you don't keep up with them, butchers might deem you a timid wimp if you don't slaughter your own meat and artists might write you off as a blundering dolt who can't hold a brush straight if you're just an ordinary person who doesn't paint his own pictures. See how that doesn't help? If you don't want to see boot menu, there is a way to switch it off. If you want to see the boot menu, there's a way to switch it on. It's almost funny how those that can customize want their preferences as default, to the detriment of those who can't. You'd have a point if you argued slippery slope based on past performance where stuff was dumbed down -- in too many cases, configuration options vanishing from a UI were almost a death knell for the functionality behind them. However, power users and developers should not be the majority of users unless we actively want to keep Fedora reserved for an elite of developers and other IT-afficionados. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Thu, Mar 14, 2013 at 03:37:23AM -0700, Dan Mashal wrote: When I think of improving the booting experience tonight, I think of a booter that can't repair itself when it's broken not Plymouth...can we fix real broken things before we fix an annoying thing like plymouth? Of course we can. The code's available and you can attach patches in bugzilla. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote: How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan I think you'd find plenty of support for that idea iff GNOME switched to 8 months as well. 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: Improving the Fedora boot experience
On Thu, Mar 14, 2013 at 12:12:54PM +0100, Denys Vlasenko wrote: +1 -1 Or in other words: This is not Google+, please don't quote entire emails. I do remember the AOL time. An argument can stand on itself without a popularity vote. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 18:05 +0100, Jan Dvořák wrote: * Holding key on BIOS machines usually results in a long beep sound and keyboard lockup. I never understood why. AIUI, key repetition and a very short buffer holding only a low number (16 I believe) of unprocessed key events. When the buffer filled up, the BIOS beeped and all following events were discarded. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ruby 2 question
Hello:
Orion Poplawski wrote, at 03/14/2013 07:58 AM +9:00:
I get the following build (actually install) error building mysql-ruby:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.D2sqcQ
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
++ dirname /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ cd mysql-ruby-2.8.2
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ env DESTDIR=/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386 make
install
make: *** No rule to make target
`/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386/usr/include/ruby.h',
needed by `mysql.o'. Stop.
What the heck? mysql-ruby does nothing but:
mysql.c:#include ruby.h
Well, this is actually mkmf.rb creating somewhat broken Makefile (from ruby
2.0.0).
You can workaround this with something like
make install DESTDIR=%{buildroot} ruby_headers=
... but this is annoying. Orion, would you file a ticket? Vít, any idea?
(perhaps lib/mkmf.rb or tool/mkconfig.rb or so needs fixing)
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ruby 2 question
Dne 14.3.2013 15:36, Mamoru TASAKA napsal(a):
Hello:
Orion Poplawski wrote, at 03/14/2013 07:58 AM +9:00:
I get the following build (actually install) error building mysql-ruby:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.D2sqcQ
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
++ dirname /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ cd mysql-ruby-2.8.2
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ env DESTDIR=/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
make install
make: *** No rule to make target
`/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386/usr/include/ruby.h',
needed by `mysql.o'. Stop.
What the heck? mysql-ruby does nothing but:
mysql.c:#include ruby.h
Well, this is actually mkmf.rb creating somewhat broken Makefile (from
ruby 2.0.0).
You can workaround this with something like
make install DESTDIR=%{buildroot} ruby_headers=
... but this is annoying. Orion, would you file a ticket? Vít, any idea?
(perhaps lib/mkmf.rb or tool/mkconfig.rb or so needs fixing)
Regards,
Mamoru
Hi,
Sorry, I did not have a chance to take a look into it yet :/ but it is
on my todolist. I'll be back.
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Thursday, March 14, 2013 10:24 PM, Michael Catanzaro wrote: On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote: How about we just drop support for 2 fedora releases to 1 and go on an 8 month cycle? It's not that bad. Dan I think you'd find plenty of support for that idea iff GNOME switched to 8 months as well. I think his suggestion was to keep releasing every 6 months (as we do now, loosely synchronized with the GNOME schedule), but support each release only 8 months instead of 13. I, for one, would be very much in favour of that. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On 14. 3. 2013 at 04:58:51, Dan Mashal wrote: On Thu, Mar 14, 2013 at 4:56 AM, Jan Zelený jzel...@redhat.com wrote: On 14. 3. 2013 at 04:48:33, Dan Mashal wrote: On Tue, Mar 12, 2013 at 1:46 AM, Jan Zelený jzel...@redhat.com wrote: Hi guys, as per [1], I'd like to propose some patches for F19 comps. These patches are splitting group called Development Tools into several smaller groups. The purpose of this email is to find out if there is something fundamentally wrong with the change (except for the fact that it is change). These are key points about the patch set: 1. There should be only small visible impact to users. Currently the only tool that is commonly using comps is anaconda and that uses the Developer workstation environment. This group will contain all groups that were created by the split to ensure maximal similarity to the old state of things. 2. All in all, the Development Tools group needed a huge cleanup, as it contained a lot of different tools and/or devel packages but many times these were only fractions of development environments necessary for the particular purpose. These tools are mostly still avaiable in other groups, like C development, Electronic Lab, ... 3. The current idea for Developer Tools group is to contain just tools that are common/usable for development of most programming languages 4. This should bring only the big picture change. No need to discuss what particular packages should be in which group. That can be tuned any time later. 5. More groups targeted at specific areas should be created and/or reviewed soon-ish. Among them: Perl Development Python Development Ruby Development feel free to suggest more development-related areas that you would like to improve. The goal of this effort is to start a process which would lead to more usable comps, so users will be able (and more importantly encouraged) to simply use for example yum to install these environments. By that time, these environments should be cleaned up, in case user wants to install just specific type of devel env, not the entire Developer Workstation [1] https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_packag e_g roups Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Please undo this change immediately and wait more than 2 days before you split such a massive group of important packages. Dan, thanks for your input. Did it break something for you? As I indicated above, the split itself should have no effect for vast majority of users. The only thing that might have some impact is the cleanup of packages. However that impact will not be major, as many of these packages are in different developer- focused groups anyway. Thanks Jan I haven't been able to find out yet because my rawhide machine is broken but, intltool definitely needs to stay there. Well, feel free to re-add it if you think that it is common tool that developers regularly use. I don't share that thought but I certainly welcome your input and I won't be angry at all if you put it back there. We already have too many groups. I see your point. Yet, at the same time, the bigger problem I observe is that we have groups that either have way too broad scope or have misc optional packages that are borderline non-qualified to be in those groups. Such groups partially loose their purpose to make things more structured and lucid. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide Bugzilla Rebase Warning
Hi, as decided on yesterday's (2013-03-13) FESCo meeting [1], we are going to restart the Rawhide Bugzilla Rebase process [2]. Historically, it was tight to the Branch day, but to give you more time to adjust your bugs, it will happen no sooner than in one week from now - it means 2013-03-21. We will be automatically changing the version for most rawhide bugs to Fedora 19. This will result in regular bugs reported against rawhide during the Fedora 19 development cycle being changed to version '19' instead of their current assignment, 'rawhide'. This is to align with the branching of Fedora 19 from rawhide and to more accurately tell where in the lineage of releases the bug was last reported. As the process wasn't followed for several releases, more bugs than the Fedora 19 development cycle will be hit, but this will lead to Bugzilla cleanup once Fedora 19 will hit End of Life. Note that this procedure does not apply to bugs that are open for the 'Package Review' component or bugs that have the ''FutureFeature'' or ''Tracking'' keywords set. They will stay open as rawhide bugs indefinitely. If your Tracker bug does not contain ''Tracking'' keyword, please update it, so the bug is not accidentally closed. If you do not want your bugs changed to version '19', add the ''FutureFeature'' keyword. Please, let me know in case of any concerns/objections. [1] https://fedorahosted.org/fesco/ticket/1096 [2] https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19#Rawhide_Rebase ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 921652] New: perl-App-cpanminus-1.6006 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921652 Bug ID: 921652 Summary: perl-App-cpanminus-1.6006 is available Product: Fedora Version: rawhide Component: perl-App-cpanminus Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 1.6006 Current version in Fedora Rawhide: 1.6005 URL: http://search.cpan.org/dist/App-cpanminus/ 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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sJcrK7ur9ba=cc_unsubscribe -- 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: f19 mass branching
On Thu, 14 Mar 2013 11:05:27 +0100 Vít Ondruch vondr...@redhat.com wrote: Dennis, I don't blame you, but since you refer the ticket here, I can easily quote: However, this also means users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo. Sometimes this delay is quite long during freezes. And this exact point does not apply yet and nobody realized that. I opened new ticket for FESCo to re-evaluate it. That is taken a bit out of context. I was describing a problem with the old setup. It's simple: always do a rawhide build, then do your branched build. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. They block a non priv user from hardlinking/softlinking to files they don't own. ln /etc/shadow ~/myshadow The other descriptions of fs.protected_*links say that the protection applies to the lookup side when following a link, and not to the creation side when installing the link. So the potential vulnerabilities still can be created, but damage is averted at the last possible moment. It seems to me that the private /tmp feature of recent Fedora systems has removed a large percentage of the potential vulnerabilities here. If you cannot see anybody else's /tmp then you cannot create vulnerabilities in /tmp for them, and they cannot create vulnerabilities in /tmp for you. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 921653] New: perl-Net-GitHub-0.51 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921653 Bug ID: 921653 Summary: perl-Net-GitHub-0.51 is available Product: Fedora Version: rawhide Component: perl-Net-GitHub Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 0.51 Current version in Fedora Rawhide: 0.50 URL: http://search.cpan.org/dist/Net-GitHub/ 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. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jZ5XxXga0ya=cc_unsubscribe -- 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 Net-Twitter-4.00004.tar.gz uploaded to lookaside cache by jdunn
A file has been added to the lookaside cache for perl-Net-Twitter: 9a33c6a157f3611e2ce89a4d8e990b6e Net-Twitter-4.4.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-Net-Twitter] Update to 4.00004. Upstream changed to Module::Build instead of MakeMaker as well.
commit 9855a4cd118b6613adcda18a01f4490b3659c9eb
Author: Julian C. Dunn jd...@aquezada.com
Date: Thu Mar 14 11:24:23 2013 -0400
Update to 4.4. Upstream changed to Module::Build instead of MakeMaker
as well.
.gitignore|1 +
perl-Net-Twitter.spec | 22 ++
sources |2 +-
3 files changed, 12 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7be322e..b9518c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Net-Twitter-3.18003.tar.gz
/Net-Twitter-4.2.tar.gz
/Net-Twitter-4.3.tar.gz
+/Net-Twitter-4.4.tar.gz
diff --git a/perl-Net-Twitter.spec b/perl-Net-Twitter.spec
index 406dc80..e805a3e 100644
--- a/perl-Net-Twitter.spec
+++ b/perl-Net-Twitter.spec
@@ -1,5 +1,5 @@
Name: perl-Net-Twitter
-Version:4.3
+Version:4.4
Release:1%{?dist}
Summary:Perl interface to the Twitter API
License:GPL+ or Artistic
@@ -20,7 +20,6 @@ BuildRequires: perl(Devel::StackTrace) = 1.21
BuildRequires: perl(Digest::HMAC_SHA1)
BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Encode)
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)
BuildRequires: perl(HTML::Entities)
BuildRequires: perl(HTTP::Request::Common)
@@ -28,6 +27,7 @@ BuildRequires: perl(HTTP::Response)
BuildRequires: perl(JSON)
BuildRequires: perl(List::Util)
BuildRequires: perl(LWP::UserAgent) = 5.819
+BuildRequires: perl(Module::Build)
BuildRequires: perl(Moose) = 0.9
BuildRequires: perl(Moose::Exporter)
BuildRequires: perl(Moose::Role)
@@ -53,27 +53,22 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
Requires: perl(Net::Netrc)
%description
-This module provides a perl interface to the Twitter APIs. See
+This module provides a Perl interface to the Twitter APIs. See
http://dev.twitter.com/doc for a full description of the Twitter APIs.
%prep
%setup -q -n Net-Twitter-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
+%{__perl} Build.PL --installdirs vendor
+./Build
%install
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
+./Build install destdir=%{buildroot} create_packlist=0
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-env TEST_POD=1 make test
+./Build test
%files
%doc Changes README
@@ -81,6 +76,9 @@ env TEST_POD=1 make test
%{_mandir}/man3/*
%changelog
+* Wed Mar 13 2013 Julian C. Dunn jd...@aquezada.com - 4.4-1
+- Upgrade to 4.4 (bz#914316)
+
* Fri Mar 08 2013 Julian C. Dunn jd...@aquezada.com - 4.3-1
- Upgrade to 4.3 (bz#914316)
diff --git a/sources b/sources
index f679ecf..59b1ff1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-131d7f914cc37648671dd999befc2bea Net-Twitter-4.3.tar.gz
+9a33c6a157f3611e2ce89a4d8e990b6e Net-Twitter-4.4.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: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, John Reiser jrei...@bitwagon.com said: The other descriptions of fs.protected_*links say that the protection applies to the lookup side when following a link, and not to the creation side when installing the link. So the potential vulnerabilities still can be created, but damage is averted at the last possible moment. That is for symlink protection I believe. There's no way to do any hardlink protection at lookup time. Basically, these are two very different things being lumped together, and they should be addressed individually. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On 03/14/2013 02:18 AM, Remi Collet wrote: Le 13/03/2013 23:49, Orion Poplawski a écrit : In any case, this is going to be pretty disruptive. I think we need to do some hard thinking about whether we want to go with this naming scheme or not. If we do, I think we need to do IM development in a side tag to work out all the kinks. If consumer correctly use pkg-config information, there should not have any problem... Remi. Agreed. But it appears that unfortunately cmake does not do this. This will need to get addressed. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On 03/14/2013 09:30 AM, Orion Poplawski wrote: On 03/14/2013 02:18 AM, Remi Collet wrote: Le 13/03/2013 23:49, Orion Poplawski a écrit : In any case, this is going to be pretty disruptive. I think we need to do some hard thinking about whether we want to go with this naming scheme or not. If we do, I think we need to do IM development in a side tag to work out all the kinks. If consumer correctly use pkg-config information, there should not have any problem... Remi. Agreed. But it appears that unfortunately cmake does not do this. This will need to get addressed. Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/12/2013 09:42 PM, Rahul Sundaram wrote: On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi, On Thu, Mar 14, 2013 at 6:30 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: How about turning the messages that Plymouth needs to display into pictures? There would be a set of pre-rendered image files with translations of the phrase Press Esc if you want to see what's going on. for all the different locales, and the correct image for the configured locale would be included when the initrd was generated. Plymouth would then just put that picture up on the screen, not caring about what language it's written in or with which font. Yea, we've talked about doing that before. We've also talked about querying the console font. So definitely possibilities to address the limitation. --Ray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak hho...@redhat.com wrote: On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hho...@redhat.com wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kof...@chello.at wrote: Honza Horak wrote: This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. And it should not satisfy it. We now changed the Requires in akonadi-mysql to mariadb-server to be sure of what we get. This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. However, in scenarios I tested with packages similar to mysql/MySQL/mariadb it turned out, that we never reach the point where we have to choose one of more alternate providers. The reason is that yum chooses right package before going down to [1] (I tracked the code and it never came to the part _compare_providers). Can we get a comment on this from someone with more knowledge of arcane yum/RPM magic? We need this to be a stable solution, not only luck. I've tested that on sample packages in one repo, that basically looked like this: mysql-5.5.30 #last version of the package and also package currently installed mariadb-5.5.29: Provides: mysql = 5.5.29 Obsoletes: mysql 5.6 MySQL-5.6.10: Provides: mysql = 5.6.10 # doesn't obsolete mysql The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. (**) The reason why mariadb is chosen is most probably this notice printed by yum: Package mysql is obsoleted by mariadb, trying to install mariadb-5.5.29-2.fc18.x86_64 instead We haven't had time to check everything, but we've done some initial testing and it looks promising. What we have found, is that MySQL server needs the accompanying mysql and mysqladmin tools to pass all tests. There is added functionality that isn't in MariaDB. I suggest mariadb-server depends on mariadb and mariadb-common, and that mysql-community-server depends on mysql-community and mysql-community-common. They can both provide the same mysql-server and mysql symbols (i see no need for the mysql-common virtual provide). That seems to work in our tests. This means it works as we'd wish even if we let MySQL packages to provide mysql symbols. I'll test the real packages after weekend, since I'm going to be off until Sunday. Have a nice weekend! Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 11:34 AM, Przemek Klosowski wrote: Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? I wouldn't say it is for packaging *only* and CVE info is not consistently listed in the changelog anyway and a good replacement might be to just search CVE id in https://admin.fedoraproject.org/updates Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 921652] perl-App-cpanminus-1.6006 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921652 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com | Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fNawGpsRV7a=cc_unsubscribe -- 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: Fwd: MariaDB replacing MySQL
On Wed, 13 Mar 2013 18:03:18 +0100, Honza Horak hho...@redhat.com wrote: On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: We now changed the Requires in akonadi-mysql to mariadb-server to be sure of what we get. This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. Package conflict is a problem as soon as packages start depending on one particular server or tools implementation (e.g., akonadi-mysql). If both have the same virtual provide and all packages depend on that instead of a specific implementation, they can be conflicting. Yeah, but on the other hand, as soon as there are still packages that doesn't depend on a specific one (use just mysql or mysql-server) -- we need to keep the API the same -- by API I mean name of the systemd unit file, utilities names, ... As I see it, there are two options: 1. Conflicting packages. All dependent packages depend on the virtual provide. 2. Non-conflicting, parallel installable packages. Dependent packages can depend on the virtual provide or directly on one server implementation. If the servers are conflicting and other packages start depending on specific servers instead of the virtual provide, users will get into unnecessary and unresolvable conflicts. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File App-cpanminus-1.6006.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-App-cpanminus: 8a6a15cb769f942d587ffdf453383100 App-cpanminus-1.6006.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 921652] perl-App-cpanminus-1.6006 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921652 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Bug-fix release suitable for F≥19. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tWLSlcA7VOa=cc_unsubscribe -- 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-App-cpanminus/f19] 1.6006 bump
Summary of changes: f0bbd39... 1.6006 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
File Net-GitHub-0.51.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-GitHub: be48a77fe4faded162ee498619539768 Net-GitHub-0.51.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: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On 03/14/2013 09:34 AM, Orion Poplawski wrote: Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. Scratch that, it was a hack for Arch Linux's hacked version of ImageMagick sonames that doesn't work for Fedora. Will need to work on a fix... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ruby 2 question
On 03/14/2013 08:36 AM, Mamoru TASAKA wrote:
Hello:
Orion Poplawski wrote, at 03/14/2013 07:58 AM +9:00:
I get the following build (actually install) error building mysql-ruby:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.D2sqcQ
+ umask 022
+ cd /builddir/build/BUILD
+ '[' /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386 '!=' / ']'
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
++ dirname /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ mkdir -p /builddir/build/BUILDROOT
+ mkdir /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ cd mysql-ruby-2.8.2
+ rm -rf /builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386
+ env DESTDIR=/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386 make
install
make: *** No rule to make target
`/builddir/build/BUILDROOT/ruby-mysql-2.8.2-9.fc20.i386/usr/include/ruby.h',
needed by `mysql.o'. Stop.
What the heck? mysql-ruby does nothing but:
mysql.c:#include ruby.h
Well, this is actually mkmf.rb creating somewhat broken Makefile (from ruby
2.0.0).
You can workaround this with something like
make install DESTDIR=%{buildroot} ruby_headers=
... but this is annoying. Orion, would you file a ticket? Vít, any idea?
(perhaps lib/mkmf.rb or tool/mkconfig.rb or so needs fixing)
Regards,
Mamoru
Filed https://bugzilla.redhat.com/show_bug.cgi?id=921650 for tracking.
Workaround appears to work, thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 921653] perl-Net-GitHub-0.51 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921653 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Net-GitHub-0.51-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-03-14 12:10:33 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1jU1FtICPya=cc_unsubscribe -- 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-App-cpanminus] 1.6006 bump
commit f0bbd39d96011b0a0916487f81870bda9c01ff26
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 14 17:01:40 2013 +0100
1.6006 bump
.gitignore |1 +
perl-App-cpanminus.spec |8 +++-
sources |2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ad62674..9ba8325 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,3 +37,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.5021.tar.gz
/App-cpanminus-1.6002.tar.gz
/App-cpanminus-1.6005.tar.gz
+/App-cpanminus-1.6006.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index ea140c0..771b039 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.6005
+Version:1.6006
Release:1%{?dist}
Summary:Get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -20,8 +20,10 @@ Requires: perl(constant)
# CPAN::Meta not used
# CPAN::Meta::Converter bundled
# CPAN::Meta::Feature bundled
+# CPAN::Meta::History bundled
# CPAN::Meta::Prereqs bundled
# CPAN::Meta::Requirements bundled
+# CPAN::Meta::Spec bundled
# CPAN::Meta::Validator bundled
# CPAN::Meta::YAML bundled
Requires: perl(Cwd)
@@ -54,6 +56,7 @@ Requires: perl(Safe)
Requires: perl(Scalar::Util)
Requires: perl(Time::Local)
# version bundled
+# version::vpp bundled
Requires: perl(YAML)
# XXX: Keep Provides: cpanminus to allow `yum install cpanminus' instead of
# longer `yum install perl-App-cpanminus'.
@@ -91,6 +94,9 @@ make test
%{_bindir}/cpanm
%changelog
+* Thu Mar 14 2013 Petr Pisar ppi...@redhat.com - 1.6006-1
+- 1.6006 bump
+
* Mon Mar 11 2013 Jitka Plesnikova jples...@redhat.com - 1.6005-1
- 1.6005 bump
diff --git a/sources b/sources
index fc2728f..414fb30 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-312d62b0aa97dd40a3ccc5bed4d3ab4a App-cpanminus-1.6005.tar.gz
+8a6a15cb769f942d587ffdf453383100 App-cpanminus-1.6006.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-Net-GitHub] 0.51 bump
commit b99d19386e9f641fa3828aaa1a4731767a4789e4
Author: Petr Šabata con...@redhat.com
Date: Thu Mar 14 17:04:02 2013 +0100
0.51 bump
.gitignore |1 +
perl-Net-GitHub.spec | 10 ++
sources |2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8c5ec5b..638278c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Net-GitHub-0.22.tar.gz
/Net-GitHub-0.47.tar.gz
/Net-GitHub-0.48.tar.gz
/Net-GitHub-0.50.tar.gz
+/Net-GitHub-0.51.tar.gz
diff --git a/perl-Net-GitHub.spec b/perl-Net-GitHub.spec
index 927e81c..2bf79c6 100644
--- a/perl-Net-GitHub.spec
+++ b/perl-Net-GitHub.spec
@@ -1,23 +1,22 @@
Name: perl-Net-GitHub
Summary:Perl interface for github.com
-Version:0.50
-Release:2%{?dist}
+Version:0.51
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/F/FA/FAYLAND/Net-GitHub-%{version}.tar.gz
URL:http://search.cpan.org/dist/Net-GitHub
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(Any::Moose)
BuildRequires: perl(Carp)
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(HTTP::Request)
BuildRequires: perl(HTTP::Request::Common)
BuildRequires: perl(inc::Module::Install)
BuildRequires: perl(JSON::Any)
BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod) = 1.22
BuildRequires: perl(URI)
BuildRequires: perl(URI::Escape)
BuildRequires: perl(WWW::Mechanize::GZip)
@@ -51,6 +50,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Thu Mar 14 2013 Petr Šabata con...@redhat.com - 0.51-1
+- 0.51 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.50-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index c0a2b9d..8e1b483 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1b8d5af787c870ce94dade88e322e9d1 Net-GitHub-0.50.tar.gz
+be48a77fe4faded162ee498619539768 Net-GitHub-0.51.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
File perl-5.16.3.tar.bz2 uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl: 025102de0e4a597cf541e57da80c6aa3 perl-5.16.3.tar.bz2 -- 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-Net-GitHub/f19] 0.51 bump
Summary of changes: b99d193... 0.51 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: Improving the Fedora boot experience
On 03/11/2013 05:03 PM, Björn Persson wrote: Your TV (which likely has embedded Linux)? Your car? Windows? OS X? I don't have any of those, and I doubt I'll ever buy a car when I want a general-purpose computer. How do you know you don't have them? They don't show anything at boot, and run custom 'kiosk' environment. The only semi-consistent way of finding out is to go through their printed pamphlets and look for GPL: if it mentions GPL, it's probably Linux. Without any effort in that direction, my family currently owns a Linux TV, DVD player and network router/gateway, as well as several phones and computers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 921652] perl-App-cpanminus-1.6006 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=921652 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpanminus-1.6006-1 ||.fc20 Resolution|--- |RAWHIDE Last Closed||2013-03-14 12:18:00 --- Comment #2 from Petr Pisar ppi...@redhat.com --- Fixed as perl-App-cpanminus-1.6006-1.fc19 in F19. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=xk10cGhm8Ja=cc_unsubscribe -- 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: f19 mass branching
Dne 14.3.2013 16:17, Kevin Fenzi napsal(a): On Thu, 14 Mar 2013 11:05:27 +0100 Vít Ondruch vondr...@redhat.com wrote: Dennis, I don't blame you, but since you refer the ticket here, I can easily quote: However, this also means users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo. Sometimes this delay is quite long during freezes. And this exact point does not apply yet and nobody realized that. I opened new ticket for FESCo to re-evaluate it. That is taken a bit out of context. I was describing a problem with the old setup. I know that you were describing problem of old setup and I agree that it was there, but since we are not yet in point where Bodhi is used, there wouldn't be the problem you were describing but we have already the solution for non-existing problem in place. Vít It's simple: always do a rawhide build, then do your branched build. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Thu, Mar 14, 2013 at 4:17 PM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 14 Mar 2013 11:05:27 +0100 Vít Ondruch vondr...@redhat.com wrote: Dennis, I don't blame you, but since you refer the ticket here, I can easily quote: However, this also means users using branched updates-testing get newer packages than rawhide, and rawhide lags behind on fixes until those updates are promoted into updates or the base branched repo. Sometimes this delay is quite long during freezes. And this exact point does not apply yet and nobody realized that. I opened new ticket for FESCo to re-evaluate it. That is taken a bit out of context. I was describing a problem with the old setup. It's simple: always do a rawhide build, then do your branched build. Nice way of wasting people's time . :/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Przemek Klosowski wrote: On 03/11/2013 05:03 PM, Björn Persson wrote: Your TV (which likely has embedded Linux)? Your car? Windows? OS X? I don't have any of those, and I doubt I'll ever buy a car when I want a general-purpose computer. How do you know you don't have them? Well, OK, I suppose there *might* be a forgotten TV that has fallen down behind one of my bookshelves, but I really doubt it. I think I would remember if I had ever owned a TV. I do actually have a car-shaped money box, and it's true that it has never prompted me for a boot menu, but that's because there's no software in it, only bare metal. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 14 Mar 2013 11:05:27 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 14:28, Dennis Gilmore napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:03:26 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 10:09, Peter Robinson napsal(a): On Wed, Mar 13, 2013 at 8:25 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, F19 has been branched, please be sure to do a git pull --rebase to pick up the new branch, additionally rawhide/f20 has had inheritance cut off from previous releases, so this means that anything you do for f19 you also have to do in the master branch and do a build there. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. No, branching is the correct time to do it. Mandated tagging through koji and inheritance are completely unrelated. At the moment koji tags the packages straight into f19 rather than tagging to f19-updates-candidate and having bodhi deal with the tagging. Inheritance only affect whether something is built in f19 is inherited through to rawhide. There was a discussion some time ago about this so presumably this change was either a decision by release engineering or FESCo. I am afraid that the discussion was more generic, i.e. Rawhide should not inherit from branched Fedora and since I remember the main reason for breaking inheritance was Bodhi and Bodhi is not yet in a game, it should be clarified and adjusted. Vít Peter https://fedorahosted.org/fesco/ticket/1005 i was asked to cut it at branching time, thats exactly what I did Dennis, I don't blame you, but since you refer the ticket here, I can easily quote: I just did what FESCo asked me to do. all along people should have been building in rawhide first. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFCE58ACgkQkSxm47BaWfdLNwCglts39QdZ7ZQOyaiPnBC/4uiT l1AAoIRIgRD5Xq70UnRCN5lBY1sZh2+K =7Oxp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 10:08 AM, Casey Dahlin wrote: On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote: Well I believe Ubunto has been using this feature for years and maybe we should consider turning it on via systemd or a unit file. The breakage of AFD is not a legitimate reason for Fedora to turn it off. Why not add an LSM call, security_follow_restricted_link()? Then you could ship this protection with SELinux policy, and even turn it off per-label if specific applications need the old behavior. --CJD We already do, but this protection does protect unconfined_t and for those who would dare to disable SELinux. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFCFNQACgkQrlYvE4MpobN0nwCg4ynXq6hXwYzAJu1NUembARUm lCoAn37VntIVg7DUC2tEv9cDozKGC4IE =UC3e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
So I installed fedora-release from the F19 repo and did a yum
distro-sync today. Then I installed a new kernel build. Then I rebooted.
Then nothing would boot at all.
It turns out this is because the release name of Fedora 19 is:
Schrödinger's Cat
with a single quote used as an apostrophe. That release name gets
written into the grub entry for a kernel when you're installing it.
Unfortunately, the lines it goes onto look like this:
menuentry 'Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
Cat)' --class fedora --class gnu-linux --class gnu --class os
$menuentry_id_option
'gnulinux-simple-a749ca4b-0cea-4db0-883d-5c036d89e5c5' {
and:
echo 'Loading Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
Cat)'
note how both lines use single quotes for quoting. The single quote in
the release name terminates the quotes early, and leaves the rest of the
stuff that's meant to be inside the single quotes as garbage lying
around the config file.
The upshot of this - for me anyway - is that the entry for the offending
kernel didn't show up on the grub menu at all, and neither of my other
kernels would boot, though they did appear (somehow, this borkage causes
grub not to pass in any kernel parameters). So I was kinda stuck.
The fix was to boot live, mount my /boot partition, edit the grub config
file, and take the single quotes out of all occurrences of
Schrödinger's Cat. I also replaced the umlauted o (that was my first
guess at the cause of the problem), but I'm not sure if that's necessary.
So - don't get bitten by this :) If you really want to get on the F19
branch, then just make sure you hand-check your grub config file before
rebooting.
--
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: Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
Le Jeu 14 mars 2013 20:57, Adam Williamson a écrit : So - don't get bitten by this :) If you really want to get on the F19 branch, then just make sure you hand-check your grub config file before rebooting. Thank you for posting this I was trying to understand why grub refused to propose new kernels in boot menu. May I point out the problem would have been averted by using the correct unicode typographical apostrophe ’ (U+2019) instead of ' (U+0027) which is several symbols squatting on a single codepoint? Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On 14/03/13 08:09 AM, Jan Zelený wrote: I haven't been able to find out yet because my rawhide machine is broken but, intltool definitely needs to stay there. Well, feel free to re-add it if you think that it is common tool that developers regularly use. I don't share that thought but I certainly welcome your input and I won't be angry at all if you put it back there. In my experience, nearly all even somewhat mature apps need intltool to compile, so it seems a reasonable thing to install by default in the 'development' group. -- 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: Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
On Thu, Mar 14, 2013 at 09:12:58PM +0100, Nicolas Mailhot wrote: Le Jeu 14 mars 2013 20:57, Adam Williamson a écrit : So - don't get bitten by this :) If you really want to get on the F19 branch, then just make sure you hand-check your grub config file before rebooting. Thank you for posting this I was trying to understand why grub refused to propose new kernels in boot menu. May I point out the problem would have been averted by using the correct unicode typographical apostrophe ’ (U+2019) instead of ' (U+0027) which is several symbols squatting on a single codepoint? or.. not putting the codename in the bootloader strings at all ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 14/03/13 08:34 AM, Przemek Klosowski wrote: On 03/12/2013 09:42 PM, Rahul Sundaram wrote: On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. Aah, wait a minute. I was tickled pink when I discovered that I can look for vulnerability profile of a package by doing rpm --changelog -q php | grep CVE if RPM changelog is for packaging only this info wouldn't be there, right? If so, what would you recommend as a replacement? I don't think you can rely on it anyway. I'd expect the CVE to show up in the changelog any time a package update was rolled specifically to backport one or a group of CVE fixes as patches - as that's effectively a packaging change - but not necessarily if an upstream point release included some CVE fixes. -- 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: Improving the Fedora boot experience
On 14/03/13 10:51 AM, Björn Persson wrote: Przemek Klosowski wrote: On 03/11/2013 05:03 PM, Björn Persson wrote: Your TV (which likely has embedded Linux)? Your car? Windows? OS X? I don't have any of those, and I doubt I'll ever buy a car when I want a general-purpose computer. How do you know you don't have them? Well, OK, I suppose there *might* be a forgotten TV that has fallen down behind one of my bookshelves, but I really doubt it. I think I would remember if I had ever owned a TV. I do actually have a car-shaped money box, and it's true that it has never prompted me for a boot menu, but that's because there's no software in it, only bare metal. Those seats must be uncomfortable... -- 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: Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
On 14/03/13 01:12 PM, Nicolas Mailhot wrote: Le Jeu 14 mars 2013 20:57, Adam Williamson a écrit : So - don't get bitten by this :) If you really want to get on the F19 branch, then just make sure you hand-check your grub config file before rebooting. Thank you for posting this I was trying to understand why grub refused to propose new kernels in boot menu. May I point out the problem would have been averted by using the correct unicode typographical apostrophe ’ (U+2019) instead of ' (U+0027) which is several symbols squatting on a single codepoint? You may, and after pjones, you'd be the second one to do so =) -- 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
