yum update F16-F17
I've tried updating F16 to F17 with yum again today, #yum -v --releasever=17 repolist Loading langpacks plugin Loading presto plugin Loading show-leaves plugin Adding zh_CN to language list Adding C to language list Config time: 0.011 Yum Version: 3.4.3 Setting up Package Sacks pkgsack time: 0.026 Repo-id : fedora Repo-name: Fedora 17 - x86_64 Repo-revision: 1337941209 Repo-tags: binary-x86_64 Repo-distro-tags: [cpe:/o:fedoraproject:fedora:17]: r Repo-updated : Fri May 25 18:39:56 2012 Repo-pkgs: 27,033 Repo-size: 27 G Repo-metalink: https://mirrors.fedoraproject.org/metalink?repo=fedora-17arch=x86_64 Updated: Fri May 25 18:39:56 2012 Repo-baseurl : http://mirrors.ustc.edu.cn/fedora/linux/development/17/x86_64/os/ : (15 more) Repo-expire : 604,800 second(s) (last: Mon Jun 4 14:18:27 2012) Repo-filename: ///etc/yum.repos.d/fedora.repo The fedora reop is still in the development directory, not the everything directory.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, 2012-06-03 at 11:00 +0200, Alexander Boström wrote: fre 2012-06-01 klockan 09:48 -0700 skrev Adam Williamson: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. That path is less complex than preupgrade and involves fewer moving parts; it's easier to test and easier to fix and more likely, in general, to be working at any given point. Please no. Once Fedora is installed it really ought to be able to upgrade itself without needing new boot media twice a year, that's just not user friendly. It's also much safer to first download everything and then start the RPM transaction. (IIUC a normal Anaconda upgrade will download packages during the upgrade.) You state an aspiration, I state my advice based on practical experience. Your aspiration would be nice, sure. It doesn't accurately match reality at present. I'm happy advising experienced users who don't mind a bit of poking about to use yum to keep upgrading ad infinitum. I would not recommend it to all users, though, or say it was our supported-and-most-likely-to-work upgrade mechanism. And my most important point, anyway, is that DVD/netinst upgrade is, practically speaking, generally more reliable than preupgrade, in recent history. -- 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: another upgrade, another disaster
On Sat, 2012-06-02 at 20:17 +0200, Andrea Musuruane wrote: * 1st attempt: Clean upgrade of Fedora 16 from DVD. I left the PC unattended while anaconda was upgrading RPM packages. I returned a couple of hours later and found a kernel panic. I was too angry to take note of the error. The system was no longer able to boot. * 2nd attempt: New installation of Fedora 17 from DVD. I chose to enable also the F17 remote repositories including updates - but not updates-testing. I left my harddisk layout unchanged (obviously I didn't format my /home). All partition were already ext4. I choose the Software development option. At about 80% of installation anaconda reported that there were an error in an RPM package and it couldn't complete the installation. The image was correctly checked after downloading and brasero reported that the ISO was mastered fine on DVD. * 3rd attempt: Same as options as the 2nd attempt but this time I chose to enable only the F17 remote repositories and I disabled the Install repo so I presume all the packages were downloaded from the net. At about 85% of installation I got a kernel panic - this time I took care of the message unable to handle kernel NULL pointer dereference at 0088. Frankly, I wouldn't trust your hardware. The installer uses the same kernel as the installed system, so even if you get it to install (which apparently you finally did), if you're getting quasi-random kernel panics, I wouldn't be at all surprised if you keep getting them on the installed system. That (and 'inexplicable' errors like failure to read a package on known-good media) points either to bad hardware or a kernel bug specific to your system in some way (as we don't have any known general kernel breakage AFAIK). You'd definitely need to get better data on one of the crashes (i.e. an actual log, or at least screen capture) and give it to the kernel team, to look into it. It may be worth running memtest on the system, first, though. -- 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: Easy way of testing packages?
On Sat, 2012-06-02 at 17:22 +0200, Stefan Schulze Frielinghaus wrote: On Sat, 2012-06-02 at 17:00 +0200, Kevin Kofler wrote: Stefan Schulze Frielinghaus wrote: is there an easy way to test packages except of using $ yum --enablerepo=updates-testing update package yum install yum-security yum --enablerepo=updates-testing --advisory=FEDORA-2012- update Ah this looks good! However, I have one question left. Does the yum plugin download the package directly from koji or do I have to wait until the package is distributed to all mirrors (because the command still mentions the updates-testing repo)? It uses the repos defined in yum. So updates-testing. If you're in a hurry to get an update earlier, you can use koji or bodhi command-line tools to download specific NEVRs or (in the case of bodhi) update IDs. e.g.: bodhi -D FEDORA-2012-7716 bodhi -D mesa-8.0.2-8.fc17 koji download-build --arch=x86_64 --arch=noarch 321768 koji download-build --arch=x86_64 --arch=noarch ocaml-3.12.1-9.fc17 see 'man koji' and 'man bodhi' for more details. If you do this regularly it's probably easiest to set up a local 'side' repo - I have ~/local/repo/x86_64 and a file in /etc/yum.repos.d/ to make that directory a repository (with a very short metadata expiry time). I download the packages to that path, run 'createrepo .', and then use yum to install the packages. For occasional use, you can just run yum directly on the packages; it's getting quite good at that. e.g. running 'yum update *' on a directory full of .rpms will do what you'd (probably) expect - for any of those packages you have installed, it'll update them; others will be left out. Hope that helps... -- 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
[Test-Announce] 2012-06-04 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-06-04 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again. Not much on the agenda this week, but we'd like to cover the 'Fedora 18 planning' topic that was postponed last week due to the Americans being on holiday. Brian, David - if you could come along for that section it'd help a lot, as we need to plan newUI testing. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120604 (I know I'm still a bit behind on the wiki pages. Sorry. Let's say, if you want to add a topic, create the page and put it in, eh?) The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 18 planning 3. AutoQA update 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make security updates faster?
On Tue, May 29, 2012 at 05:46:38AM +, Jóhann B. Guðmundsson wrote: On 05/29/2012 05:21 AM, Adam Williamson wrote: We actually have this on the QA wishlist and it was one of the projects we proposed for GSoC for QA, but it didn't quite make it. We may still wind up doing it through some other channel, though. See also https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Fedora_Gooey_Karma andhttp://blog.tirfa.com/gooey-karma. It makes no sense to have a gui application ( or an application for that matter ) without having written the relevant how to debug/how to test pages for each component to accommodate it. Such an application will just fail without it and might cause more harm then good and yeah I have already mention the root cause for those pages not already existing on this thread. I could not disagree more. It is blind reliance on written test cases that might cause more harm than good. IOW, if a tester does not know how a package works, it would be better if he did not test it. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make security updates faster?
On Tue, May 29, 2012 at 06:58:00PM +, Jóhann B. Guðmundsson wrote: On 05/29/2012 06:13 PM, Rex Dieter wrote: It makes no sense to have a gui application ( or an application for that matter ) without having written the relevant how to debug/how to test pages for each component to accommodate it. Indeed. However, I'd argue*both* pieces, a karma app and good test-cases, are needed, and one not need block on the other. Well we then agree on disagreeing since updating the component and running the relevant application is hardly what I call testing and requiring karma points to just do that makes absolutely no sense to me. It is called smoketesting and I think it fulfills the objective of avoiding broken updates pretty well, thanks. Note that we are talking about Fedora here, not RHEL. If you are not satisfied with the current level of testing, you are welcomed to do something about it. But forcing others to do something is not the right way to go. In any case this is something we solve in the QA community and arguably we should be the one that decide all this and FPC just implements what we have decided and tell them to. This really does not involve Fesco and we already have a good working relationship with releng. Again, this is Fedora we are talking about, not RHEL. If you (the QA community) decide on some new policy that most maintainers disagree with, they will just ignore it and there is _absolutely nothing_ you can do to enforce it. Period. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 4, 2012 at 7:57 AM, Jan Synacek jsyna...@redhat.com wrote: yum groupinstall GNOME Desktop Environment This alone unfortunately doesn't do the trick. You will probably have to yum groupinstall X Window System as well as some drivers for your graphic card to get it working. I also had to order selinux to relabel my entire /home to be able to get into any gnome session. I also had to install a bunch of other yum groups, edit systemd config to default do a graphical boot, recreate my old users, chown their directories, and perform restorecon on /home. Bye, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 3rd attempt: Same as options as the 2nd attempt but this time I chose to enable only the F17 remote repositories and I disabled the Install repo so I presume all the packages were downloaded from the net. At about 85% of installation I got a kernel panic - this time I took care of the message unable to handle kernel NULL pointer dereference at 0088. Frankly, I wouldn't trust your hardware. The installer uses the same kernel as the installed system, so even if you get it to install (which apparently you finally did), if you're getting quasi-random kernel panics, I wouldn't be at all surprised if you keep getting them on the installed system. That (and 'inexplicable' errors like failure to read a package on known-good media) points either to bad hardware or a kernel bug specific to your system in some way (as we don't have any known general kernel breakage AFAIK). You'd definitely need to get better data on one of the crashes (i.e. an actual log, or at least screen capture) and give it to the kernel team, to look into it. It may be worth running memtest on the system, first, though. Everything can be and I will run memtest as you advised. But I didn't had any kernel problem in the past - and I've used every Fedora release on the same PC for about 4 years. After I could bypass this problem - I could install the system, including I think all the RPMs anaconda was trying to install without any problem. Note that I don't run the same kernel used by anaconda because in fedora updates there is available a newer one. Anyway, in case I hit this issue again, I would be interested to know how to get the log of this kind of error. Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
The outcome was that a bunch of people were deriding MATE and not wanting it in Fedora. And this is why after 12 years of Red Hat and Fedora, I'm now moving to Linux Mint. I know I'm going to miss yum, but at least they support Cinnamon and Mate. I gave Gnome 3 a fair chance from its first release up to Fedora 17 beta, but it still feels like doing my job in spite of the desktop. I wonder why Fedora is pushing Gnome 3 like that... -- Regards Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
I'd like to brought to wider attention the bug https://bugzilla.redhat.com/show_bug.cgi?id=693180 What's the matter? If you install wine, it brings as a dependency wine-tahoma font, that is then included in system wide fonts list. This causes the font to be used by applications like Firefox when pages require tahoma. As the font is badly looking, it makes many things to look terrible. Some of us think, this font should be made specific for the wine application and not used system wide as it breaks the look and feel of too many things. Please make your voice to be heard on that. Adam Pribyl Adam, it might be better to cross-post this also to devel@ list, doing that now. I believe there are a few good engineering practices that every software should keep. One of them is that installing one application should not have detrimental effects to another application. That is violated here. Installing wine brings broken fonts (Tahoma, maybe some others) into the system and then have detrimental effects on font rendering in web applications. We should do something about it. It is unfortunate that wine package maintainer doesn't want to discuss this issue any further. To some extent, he is even right. Wine depends on a font and fonts are installed into system-wide directories. Web pages request that font. End of story. But the reality is not perfect and often we have to do compromises. This is another obstacle presented by Microsoft to the opensource world and we can't simply insist on that one and only correct solution. Because we know Tahoma rendering looks better on Windows and furthermore the web pages don't use it at all, it's just a fallback for some other font present in Windows but not in Linux. Our excuse is that there is a README in wine-tahoma-fonts package documenting how to blacklist it if you don't want it. Yes, but that doesn't help. We need Fedora to look good by default. I have heard several people saying Fonts are ugly in Fedora, I'll rather use Ubuntu instead. And guess what, Ubuntu has made these broken wine fonts wine-specific, so that they are used in wine but not in other system applications. You might disagree with their other endeavors, but they care about their user-base. Putting some info in a README is good for hackers, but it is useless for end-users. I believe the best solution here is to make Tahoma (and maybe some other fonts that are rendered horribly) a wine-specific font. Then add a README how to make those fonts available for all applications, if someone ever needs that. Or we can create a separate package for system-wide installation. This way we will have reasonable defaults and more happy users. Anyone, if you have a better suggestion how to solve this problem, please be heard. The desirable outcome is: 1. Wine is installed 2. Web page rendering looks pretty (no bitmap fonts) 3. No manual steps are needed Comments welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reporting a bug on several components - rpath issue
Hi,
I was trying to check if packages on my system has defined a rpath (1)
, I've made a little script:
# for f in $(ls /usr/lib64/*.so.* ) ; do chrpath ${f} /dev/null;
RETVAL=$?; if [ ! $RETVAL == 2 ] ; then chrpath ${f} ; rpm -qf ${f} ;
echo ; fi; done
This script reported around 70 rpath on my system related to nearly 20
different components.
For the record, rpmdev-setuptree adds a rpm macro for a local RPM
packaging environment:
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
So that's prevent rpmbuild to build a package using rpath with success.
This is not defined in the fedora buildsys by default. (nor autoqa ?...)
Now I would like to know how to massively report a bug for each
related component ? (at least those that define an rpath in /usr/lib64
from a library in the same directory).
Is there any experience doing such bugreport ?
For the root cause of the rpath issue on lib64 system is related to a
non-upstreamed patch (2) from libtool that prevents (most of the time)
the detection of the lib64 sub-directory to be in the default search
path of the system linker. Project generated from an upstream version
of libtool are likely to generate such issue.
Nicolas (kwizart)
(1) http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
(2)
http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob_plain;f=libtool-2.2.10-rpath.patch;hb=master
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reporting a bug on several components - rpath issue
On Mon, 2012-06-04 at 11:22 +0200, Nicolas Chauvet wrote:
Hi,
I was trying to check if packages on my system has defined a rpath (1)
, I've made a little script:
# for f in $(ls /usr/lib64/*.so.* ) ; do chrpath ${f} /dev/null;
RETVAL=$?; if [ ! $RETVAL == 2 ] ; then chrpath ${f} ; rpm -qf ${f} ;
echo ; fi; done
This script reported around 70 rpath on my system related to nearly 20
different components.
For the record, rpmdev-setuptree adds a rpm macro for a local RPM
packaging environment:
%__arch_install_post /usr/lib/rpm/check-rpaths
/usr/lib/rpm/check-buildroot
So that's prevent rpmbuild to build a package using rpath with success.
This is not defined in the fedora buildsys by default. (nor autoqa ?...)
Now I would like to know how to massively report a bug for each
related component ? (at least those that define an rpath in /usr/lib64
from a library in the same directory).
Is there any experience doing such bugreport ?
For the root cause of the rpath issue on lib64 system is related to a
non-upstreamed patch (2) from libtool that prevents (most of the time)
the detection of the lib64 sub-directory to be in the default search
path of the system linker. Project generated from an upstream version
of libtool are likely to generate such issue.
Nicolas (kwizart)
(1) http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
(2)
http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob_plain;f=libtool-2.2.10-rpath.patch;hb=master
I'd start with a mass mailing the maintainers of affected packages and
only after giving them some time to fix the problem I'd rerun the check
and file the bugs to the remaining unfixed packages.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi, I am the new Fedora Package Collection Maintainer. I'm from Russia, my name is Alexey, but people call me raorn (begins with small letter r). I was Packager in ALT Linux distro for about eight years, my interests are IPv6, OpenFlow, Vim, zsh, mutt, ruby and WindowMaker. I'm familiar with git and rpm stuff, if you wish, you may take a look at my ALT Linux packages here: http://git.altlinux.org/people/raorn/packages/?o=age I've been working with several upstreams, like zsh, Vim, WindowMaker, ndisc6 and recently got my first patch merged into Linux kernel ;-) I am switching to Fedora as my primary desktop platform, but I am missing some applications. Andreas Bierfert (awjb), who's WindowMaker package finally made me chose Fedora, agreed to be my sponsor. For now I'll be packaging bunch of WindowMaker applets and one day I'd like to resurrect wdm (WINGs Display Manager). I am also big fan of IPv6, running little IPv6-only network with dual-stack router, my setup is described here - http://blog.raorn.name/2012/02/ipv6-only-lan-with-dual-stack-openwrt.html In the Internet I am using nickname raorn (IRC, twitter) or, for 6-letters-or-longer-nickname-required sites I use sir.raorn (gmail, facebook). My public gpg key attached. P.S. I am also an Old Fart and will take part in most of the local flamewars ;-) -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ raorn@raorn.name.asc Description: application/pgp-keys signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote: It, in fact, provides proof that this feature is searching for a problem. Which applications require gigabytes per second throughput out of /tmp? sort(1) and maybe mock(1) ;-) (and your numbers for tmpfs would equal ext4 once you started swapping) No. Tried with 2G RAM, 8G swap, 6G tmpfs and 5G file. Stupid dd test was 2-3 times faster on tmpfs that ext4. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Update bodhi Notes?
I pushed a release to updates-testing, but I'd like to update the Notes for this release. How should I do this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fix common misspellings -- mostly mechanically
Even in mature projects full of nit-picky reviewers, it seems there
are always a few misspelled words in comments, documentation, etc.
Here's a recipe for correcting those. Hook this up as a
make check dependent rule to prevent recurrence.
First, get this http://github.com/lyda/misspell-check
and install its misspellings script.
Then, (presuming you use git for VC), run this to
see what you might want to change[*]:
git ls-files|misspellings -f -|perl -nl \
-e '/^(.*?)\[(\d+)\]: (\w+) - (.*?)$/ or next;' \
-e '($file,$n,$l,$r)=($1,$2,$3,$4); $q='\''; $r=~s/$q/$q\\$q$q/g;'\
-e 'print sed -i $q${n}s!$l!$r!$q $file'
It massages the misspellings output into sed -i invocations.
Here are the ones from autoconf/master:
sed -i '104s!Stange!Strange!' AUTHORS
sed -i '175s!Propogate!Propagate!' ChangeLog.1
sed -i '673s!occurences!occurrences!' ChangeLog.2
sed -i '6973s!Accomodate!Accommodate!' ChangeLog.3
If you look at the AUTHORS file, you see that the first is a false
positive: we don't want to change the name of a contributor.
However, the three remaining commands fix legitimate spelling errors,
albeit only in ChangeLog files.
Remember that this is a naive tool. Be sure to review each
change carefully, and *in context*. It has no clue about the
boundaries between code and comments. For example, you must
be careful that it does not change grammar tokens or variable
names like THRU or UPTO to THROUGH or UP TO.
Jim
[*] The misspellings script appears to be intended to do some
of this itself, but so far, it hasn't worked for me.
Note that for a typo like cant, you'll be presented with this
sed command:
sed -i '16s!cant!cannot,can not,can'\''t!' m4/nullsort.m4
While the perl filter was careful to escape the single quote in the RHS
of the substitution, it will not choose which of those three
alternatives to use. Search for , in the list of sed commands
to identify ones with more than one alternative spelling.
For each of those, you must manually select the word that you prefer.
Once you've done that, you can save the sed commands to a file, say
K, and apply their changes with bash K.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning ncpfs
Hi all, I'm orphaning ncpfs package (utilities for the ncpfs filesystem, a NetWare client for Linux). I don't have a access to NetWare and time to maintain the package. Ncpfs is pretty old, but it's still used. Written in C, upstream is not interested in it anymore. There are five opened bugs, two of them are security related. I can offer SRPM for Mars (Martin Stovers NetWare-Emulator [1]) as a small gift:) - it may be useful. If anyone is willing to maintain the package, feel free to take it. [1] http://www.compu-art.de/mars_nwe/ Best regards, Vitezslav Crhonek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
On 06/04/2012 02:23 PM, Richard Körber wrote: The outcome was that a bunch of people were deriding MATE and not wanting it in Fedora. And this is why after 12 years of Red Hat and Fedora, I'm now moving to Linux Mint. I know I'm going to miss yum, but at least they support Cinnamon and Mate. I gave Gnome 3 a fair chance from its first release up to Fedora 17 beta, but it still feels like doing my job in spite of the desktop. I wonder why Fedora is pushing Gnome 3 like that... Fedora has invested a lot on infrastructure that supports other desktop environments including spins.fedoraproject.org and Fedora includes KDE, Xfce etc and Cinnamon is under review at https://bugzilla.redhat.com/show_bug.cgi?id=771252. There were genuine concerns about the maintenability of MATE and that has nothing to do with pushing GNOME or whatever else. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
MALLOC_PERTURB_: everyone should set this envvar
I posted about MALLOC_PERTURB_ about a year ago, http://thread.gmane.org/gmane.linux.redhat.fedora.devel/132690 but it is clear that not everyone is setting the variable, so for those who didn't take the time last year, or who are new to the subject, do yourself a favor and set MALLOC_PERTURB_ to a value in 1..255 everywhere. For those who can't be bothered to click the link, here's that post: If you are into development on glibc-based systems and do not set MALLOC_PERTURB_ to a nonzero value, then you are missing an easy opportunity to detect subtle bugs early. Sure, you can use valgrind, and it will detect whatever a MALLOC_PERTURB_ setting would have caught, and more, but it's far more expensive and takes some effort, however minimal. If you use zsh or bash, put this in one of your startup files: # http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) and remember that when you find surprising bugs, that others who are also running tests (but without MALLOC_PERTURB_) will not see the same failures. This is useful enough that it is worth considering for inclusion in /etc/profile. Why do I insist? Here's a nice example: a month or so ago I was investigating a build problem in libvirt and as part of that, ran make check from the cloned source tree. Imagine my surprise when one of the tests failed. Obviously, while it was failing for me, it was not failing for the many people who build libvirt regularly, so what was different here? I had MALLOC_PERTURB_ set in my environment and they did not. The bug I uncovered was a heap corruptor that dated back to libvirt-0.9.5: http://thread.gmane.org/gmane.comp.emulators.libvirt/56605 TL;DR: Add these lines to your ~/.bash_profile or ~/.zshenv: # http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) One caveat: this does induce a small performance penalty (usually negligible), so when you're measuring performance, you may want to turn it off. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem pairing mouse with F17
On 06/03/2012 11:07 PM, Jóhann B. Guðmundsson wrote: On 06/04/2012 02:30 AM, Digimer wrote: I can confirm that selinux is disabled (as sestatus shows 'disabled'). Any idea what I should next? File a bug report against Gnome-Bluetooth you can try running this hciconfig hci0 sspmode 0 from the command line as root which was the only way I manage to get my Samsung Galaxy S-II running Android ICS 4.0.3 to pair with my laptop which is running F17 with the latest 3.5 rc kernel. If the workaround works for you and you need to keep the change across reboots you can create a simple type oneshot unit that does that for you. Like... # vim /etc/systemd/system/bluetooth-legacy-pairing.service which contains [Unit] Description=Persistant Bluetooth Legacy Pairing Hack [Service] Type=oneshot ExecStart=/sbin/hciconfig hci0 sspmode 0 RemainAfterExit=yes [Install] WantedBy=graphical.target JBG Thanks for the reply, Jóhann, but it didn't help. When I ran 'hciconfig hci0 sspmode 0', there was nothing returned. I tried to pair again twice with no luck. Syslog showed: === Jun 4 08:37:19 lework udevd[525]: specified group 'plugdev' unknown Jun 4 08:38:04 lework bluetoothd[770]: bluetoothd[770]: Discovery session 0x7f0ab7111eb0 with :1.168 activated Jun 4 08:38:04 lework bluetoothd[770]: Discovery session 0x7f0ab7111eb0 with :1.168 activated Jun 4 08:38:08 lework bluetoothd[770]: bluetoothd[770]: Stopping discovery Jun 4 08:38:08 lework bluetoothd[770]: Stopping discovery Jun 4 08:38:09 lework udevd[525]: specified group 'plugdev' unknown Jun 4 08:38:09 lework dbus-daemon[837]: dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.168 (uid=1000 pid=14431 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) Jun 4 08:38:09 lework dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.168 (uid=1000 pid=14431 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) === Jun 4 08:38:27 lework bluetoothd[770]: bluetoothd[770]: Discovery session 0x7f0ab7124180 with :1.168 activated Jun 4 08:38:27 lework bluetoothd[770]: Discovery session 0x7f0ab7124180 with :1.168 activated Jun 4 08:38:30 lework bluetoothd[770]: bluetoothd[770]: Stopping discovery Jun 4 08:38:30 lework bluetoothd[770]: Stopping discovery Jun 4 08:38:31 lework udevd[525]: specified group 'plugdev' unknown Jun 4 08:38:32 lework dbus-daemon[837]: dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.168 (uid=1000 pid=14431 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) Jun 4 08:38:32 lework dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.168 (uid=1000 pid=14431 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) === I created a rhbz here: https://bugzilla.redhat.com/show_bug.cgi?id=828199 -- Digimer Papers and Projects: https://alteeve.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update bodhi Notes?
On 04/06/12 13:01, Neal Becker wrote: I pushed a release to updates-testing, but I'd like to update the Notes for this release. How should I do this? Log to https://admin.fedoraproject.org/updates/ find the update and change it? What's the problem with that? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 828214] perl-Archive-Tar-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828214 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote: Brian Wheeler wrote: How is this change a win? Unfortunately, due to Lennart's ignorance (we're all ignorant of something), he will consider your e-mail flame-bait and not reply. Its not his ignorance - he's on vacation for the next two weeks... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update bodhi Notes?
Matej Cepl wrote: On 04/06/12 13:01, Neal Becker wrote: I pushed a release to updates-testing, but I'd like to update the Notes for this release. How should I do this? Log to https://admin.fedoraproject.org/updates/ find the update and change it? What's the problem with that? Matěj Yes, thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libwbxml-0.11.1 has changed license from (LGPLv2+ and GPLv2+) to (LGPLv2+)
Upstream released new bug-fixing version of libwbxml. Besides other improvements, this versions relicenses the only GPLv2+ file to LGPLv2+ making the whole package covered by LGPLv2+ now. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: supercat anybody working on it?
On Sat, Jun 02, 2012 at 08:16:49PM -0700, Garrett Holmstrom wrote: On 6/2/2012 7:03 PM, Adrian Alves wrote: am not following what u mean? On Sat, Jun 2, 2012 at 5:30 AM, Michael Schwendt mschwe...@gmail.com mailto:mschwe...@gmail.com wrote: On Fri, 1 Jun 2012 23:00:29 -0300, Adrian Alves wrote: done I built it, check this out: Spec URL: http://alvesadrian.fedorapeople.org/supercat.spec Check this out: This means to read the following link because it describes a mistake that your spec file makes: https://fedoraproject.org/wiki/Packaging:UnownedDirectories And the following page is _not_ just for reviewers: ;-) This means to read the following link because it is wise to follow the packaging guidelines even before formally submitting a package for review: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines When you submit a new package, it is wise to run through the ReviewGuidelines and check that your package meets all the requirements there (or if you can't figure out how to satisfy one of them, to ask on IRC/mailing list or note that you couldn't figure out that one problem in the review request). That way a reviewer looking at your package can see what standard things they'll have to work on with you and also can concentrate on finding things wrong that aren't part of the codified package review. -Toshio pgpmmqiVejxRG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Matthias Clasen wrote: Its not his ignorance - he's on vacation for the next two weeks... Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Easy way of testing packages?
On Sun, 2012-06-03 at 23:51 -0700, Adam Williamson wrote: [...] If you're in a hurry to get an update earlier, you can use koji or bodhi command-line tools to download specific NEVRs or (in the case of bodhi) update IDs. e.g.: bodhi -D FEDORA-2012-7716 bodhi -D mesa-8.0.2-8.fc17 koji download-build --arch=x86_64 --arch=noarch 321768 koji download-build --arch=x86_64 --arch=noarch ocaml-3.12.1-9.fc17 see 'man koji' and 'man bodhi' for more details. If you do this regularly it's probably easiest to set up a local 'side' repo - I have ~/local/repo/x86_64 and a file in /etc/yum.repos.d/ to make that directory a repository (with a very short metadata expiry time). I download the packages to that path, run 'createrepo .', and then use yum to install the packages. For occasional use, you can just run yum directly on the packages; it's getting quite good at that. e.g. running 'yum update *' on a directory full of .rpms will do what you'd (probably) expect - for any of those packages you have installed, it'll update them; others will be left out. Ah this is really nice. koji/bodhi commands make life really easy, and since yum accepts RPMs from the current directory, an update is made easy! Next time I will provide Karma faster and _easier_ :D Thanks a lot, Stefan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 04.06.2012 12:50, schrieb Alexey I. Froloff: On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote: It, in fact, provides proof that this feature is searching for a problem. Which applications require gigabytes per second throughput out of /tmp? sort(1) and maybe mock(1) ;-) (and your numbers for tmpfs would equal ext4 once you started swapping) No. Tried with 2G RAM, 8G swap, 6G tmpfs and 5G file. Stupid dd test was 2-3 times faster on tmpfs that ext4. but the stupid dd-test does not reflect reality for most workloads /tmp is not touched most of the time in any way - keep in mind that applications needs to be changed to usr /var/tmp if they expect really large temp-files compare the real benefit with the complete work and bugreports for forgotten packages trying to store a iso-image and such things on /tmp the benefit for the normal workload has to be compared with the overall work for a feature and not only some generic tests signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Am 04.06.2012 15:36, schrieb Matthias Clasen: On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote: Brian Wheeler wrote: How is this change a win? Unfortunately, due to Lennart's ignorance (we're all ignorant of something), he will consider your e-mail flame-bait and not reply. Its not his ignorance - he's on vacation for the next two weeks... that is not the point his features are usually taken with no interest was the userbase thinks - in case of /tmp on tmpfs i see no prove what should be really faster, how much faster and if this is measurable in typical workloads * most users will not notice any improvement * many users explained why it is a bad idea to change defaults * users who think it is good for their worksload are donig it since years so why are features causing global changes to the distribution approved without careful condiseration and repeatly ignoring the userbase? you can not say 10.000 users which are not crying out loud are automatically pro signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 1, 2012 at 3:10 PM, Gerry Reno gr...@verizon.net wrote: On 06/01/2012 03:56 PM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 2:37 PM, Gerry Reno gr...@verizon.net wrote: Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. And how many consumer OEMs ship them? -J Any Chinese fab would be able to produce any quantity needed within weeks to any number of OEM's. Key words, would be able. What OEM ships this *today*? That's my point. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. The whole point is that is that I provided just one example of an equally effective solution to SecureBoot that has much less impact on both Microsoft and Linux. The entire x86 industry is going to become a mess if SecureBoot is implemented. It'll be signature-HELL and a lot more. This whole SecureBoot runaway train needs to have the brakes slammed on. I'm not saying I love SecureBoot, but that ship has sailed. I also wish Amiga hadn't futzed with their floppy drive stepper motors to squeeze in more sectors per disk and made my floppies unreadable without a trip to eBay, but that ship has sailed as well, so I pretty have to find the best solution available for the situation at hand. I would love for SecureBoot not to have happened, or to have happened differently. If wishes were horses, even the poor would eat. -J Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120604 changes
Compose started at Mon Jun 4 08:15:03 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [OpenGTL] OpenGTL-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) OpenGTL-devel-0.9.16-4.fc18.i686 requires libLLVM-3.0.so OpenGTL-devel-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) OpenGTL-libs-0.9.16-4.fc18.i686 requires libLLVM-3.0.so OpenGTL-libs-0.9.16-4.fc18.x86_64 requires libLLVM-3.0.so()(64bit) [PackageKit] PackageKit-zif-0.7.4-6.fc18.x86_64 requires libzif.so.3()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [calligra] calligra-core-2.4.90-1.fc18.x86_64 requires calligra-kexi-map-form-widget 0:2.4.90-1.fc18 [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [gdb-heap] gdb-heap-0.5-8.fc17.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [gnome-python2-desktop] gnome-python2-evolution-2.32.0-9.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [inkscape] inkscape-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) inkscape-view-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) [kdeplasma-addons] kdeplasma-addons-4.8.3-1.fc18.x86_64 requires libkexiv2.so.10()(64bit) plasma-wallpaper-marble-4.8.3-1.fc18.x86_64 requires libmarblewidget.so.13()(64bit) [mapnik] mapnik-2.0.0-4.fc17.i686 requires libicuuc.so.48 mapnik-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit) mapnik-utils-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so
[Bug 828226] perl-MooseX-MarkAsMethods-0.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828226 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-MooseX-MarkAsMethods-0 ||.15-1.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-04 10:31:27 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
On 06/03/2012 03:41 PM, Kevin Kofler wrote: Rahul Sundaram wrote: Just because people have the ability to install Fedora and post in a forum doesn't mean that you can reliably assume that they are willing to fiddle with BIOS settings on their system or they would prefer that over a installation that just works. We have worked for years to make Fedora more usable and be easily installable for users who are transitioning from Windows. One could argue that the regression in usability is not as important as the loss of freedom in this specific instance but it is undeniable that it is a usability regression that would affect a number of users. It's a usability regression in the firmware, not our fault at all. And? It affects our users. A blame game doesn't help them at all. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Unicode-Casing-0.12.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Unicode-Casing: 2f674a2564a4129daa076eb3185a0557 Unicode-Casing-0.12.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-Casing] 0.012 bump
commit b2f5dc669a02b0e761af0b2cb6a21ea87a698171
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 16:45:28 2012 +0200
0.012 bump
.gitignore |1 +
perl-Unicode-Casing.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ad57800..2ab05bc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Unicode-Casing-0.07.tar.gz
/Unicode-Casing-0.08.tar.gz
+/Unicode-Casing-0.12.tar.gz
diff --git a/perl-Unicode-Casing.spec b/perl-Unicode-Casing.spec
index 958eb38..a379c66 100644
--- a/perl-Unicode-Casing.spec
+++ b/perl-Unicode-Casing.spec
@@ -1,7 +1,7 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Unicode-Casing
-Version:0.08
-Release:2%{?dist}
+Version:0.12
+Release:1%{?dist}
Summary:Perl extension to override system case changing functions
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 0.12-1
+- 0.12 bump
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.08-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index a5becf9..9481b6b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-11104e2aeecdaf256a8ddba7c61666d4 Unicode-Casing-0.08.tar.gz
+2f674a2564a4129daa076eb3185a0557 Unicode-Casing-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828231] perl-PPIx-Regexp-0.027 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828231 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PPIx-Regexp-0.027-1.fc ||18 Resolution|--- |RAWHIDE Last Closed||2012-06-04 10:46:42 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: MALLOC_PERTURB_: everyone should set this envvar
# http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) For supportability (and to help remind you to turn it off before performance tests), then also consider adding a line such as: echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_ # $HOME/.bash_profile Also inexpensive: export MALLOC_CHECK_=1 # 0: off; 1: announce on stderr; 2: abort echo 12 MALLOC_CHECK_=$MALLOC_CHECK_ # $HOME/.bash_profile which handles double free(), single-byte overruns, etc. For always on detection of overlapping memcpy() at low cost, then consider http://bitwagon.com/glibc-memlap/glibc-memlap.html . -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Hi, first I would like to point out that I am totally open for a discussion about this. IMO bugzilla is just not the right place for it. As you have pointed out there are two aspects on this: A technical part and a subjective part about the look and feel. I guess we can agree that the technical part of font installation etc. is done like it should be. However, it is _not_ the wine-tahoma-fonts package which bullies its way and changes the system look and fell on its own. There are some web-pages which (maybe unintentionally) explicitly request a tahoma font and if you have wine installed - beware - they get what they request. You argue they do so as a fallback which under 'normal' circumstances should never be used. My question would then be why we do reach this point in the first place. Maybe that is a starting point where we can improve. We can also argue about the look and feel of the wine tahoma font itself and get to the point where we can vote if this is an ugly or a pretty font. I as a packager will not keep this freedom of choice from the fedora users. As a packager I, however, find it important that for the use-case of wine the best available user experience is provided. Hence this font needs to be included an pulled in by wine like it is today. Now the question remains if there is action needed on this issue. As I understand that some users do not like the wine tahoma font, the package as been adopted to disable bitmaps by default and instructions have been added on how to disable the font. I am sure the font itself could be improved in certain ways, so if there are skilled people who want to work on it I urge them to get in contact with upstream. For me the remaining issue is what has been mentioned in comment rhbz693180#37 about the tahomabd.ttf file. If this is the case we should see to get it fixed upstream. If it cannot be done upstream I am open for discussions to add a workaround which would be to either exclude tahomabd.ttf completely or get an exception to put it into wines own font dir till it is fixed. Regards, Andreas On Mon, 2012-06-04 at 05:04 -0400, Kamil Paral wrote: I'd like to brought to wider attention the bug https://bugzilla.redhat.com/show_bug.cgi?id=693180 What's the matter? If you install wine, it brings as a dependency wine-tahoma font, that is then included in system wide fonts list. This causes the font to be used by applications like Firefox when pages require tahoma. As the font is badly looking, it makes many things to look terrible. Some of us think, this font should be made specific for the wine application and not used system wide as it breaks the look and feel of too many things. Please make your voice to be heard on that. Adam Pribyl Adam, it might be better to cross-post this also to devel@ list, doing that now. I believe there are a few good engineering practices that every software should keep. One of them is that installing one application should not have detrimental effects to another application. That is violated here. Installing wine brings broken fonts (Tahoma, maybe some others) into the system and then have detrimental effects on font rendering in web applications. We should do something about it. It is unfortunate that wine package maintainer doesn't want to discuss this issue any further. To some extent, he is even right. Wine depends on a font and fonts are installed into system-wide directories. Web pages request that font. End of story. But the reality is not perfect and often we have to do compromises. This is another obstacle presented by Microsoft to the opensource world and we can't simply insist on that one and only correct solution. Because we know Tahoma rendering looks better on Windows and furthermore the web pages don't use it at all, it's just a fallback for some other font present in Windows but not in Linux. Our excuse is that there is a README in wine-tahoma-fonts package documenting how to blacklist it if you don't want it. Yes, but that doesn't help. We need Fedora to look good by default. I have heard several people saying Fonts are ugly in Fedora, I'll rather use Ubuntu instead. And guess what, Ubuntu has made these broken wine fonts wine-specific, so that they are used in wine but not in other system applications. You might disagree with their other endeavors, but they care about their user-base. Putting some info in a README is good for hackers, but it is useless for end-users. I believe the best solution here is to make Tahoma (and maybe some other fonts that are rendered horribly) a wine-specific font. Then add a README how to make those fonts available for all applications, if someone ever needs that. Or we can create a separate package for system-wide installation. This way we will have reasonable defaults and more happy users. Anyone, if you have a better suggestion how to solve this problem,
Re: *countable infinities only
On Sun, Jun 3, 2012 at 10:11 AM, Peter Jones pjo...@redhat.com wrote: On 06/02/2012 05:47 PM, Gregory Maxwell wrote: There is no additional security provided by the feature as so far described—only security theater. So I can't modify the kernel or bootloader, great—but the kernel wouldn't have let me do that in the first place unless it had an exploit. So I just put my rootkit inside systemd so that it executes the kernel exploit right after reboot, and the exploited kernel now silently keeps updates from being applied. You've sortof missed the point. A privilege escalation exploit, currently, can sabotage your bootloader, insert its own ahead of it, and modify the kernel to perpetually hide itself. Right now such exploits are generally bounded by selinux, which would, in most cases, stop them from performing the systemd trick that you describe. At that point it has escalated past the point where it's confined by selinux or anything else, and can do your trick and far worse. And again, there *are* bootkit exploits in the wild now. So any argument that there's no legitimate security benefit to securing the bootloader is prima facie false. It's the goal that matters. Not the method. The attacker wants persistent control of the system which can't be fixed by updates. Replacing the kernel/bootloader is just one of many possible means to achieve this end. With signing, yes, replacing the bootloader doesn't work because doing so will brick the machine. But it doesn't matter, because replacing systemd is in no way worse for the attacker than replacing the bootloader in most situations where they would have been able to replace the bootloader. So two possible situations: kernel security works completely and there is no privileged escalation exploit strong enough to defeat the kernel imposed security— in which case you don't need any boot time cryptographic lockdown because the kernel can simply deny the ability to rewrite the kernel/bootloader, or it's possible that kernel security is buggy, in which case, the attacker doesn't really have to care about the boot-time cryptographic lockdown because he can just make systemd run the exploit code again at every boot— which would accomplish the attackers goals just as well as replacing the bootloader/kernel. The case where it would matter is where the attacker can bypass kernel security and raw-write to the disk, but can not write to kernel memory or execute arbitrary code as the kernel or replace the update process with a fake one... which seems really narrow to me. Not to mention the disinterest in this as a feature is demonstrated by the fact that while we could have officially supported inhibiting root from writing to disk (and accessing kernel memory in order to allow them to escalate to raw-disk-writing) which would be 100% as effective as boot-time cryptographic lockdown, absent kernel bugs, but we haven't and there is no public evidence (as far as I can tell) of Fedora users asking for it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Notice: Retiring vbetool in F18
Historically the only thing requiring vbetool was pm-utils, but that's not been true in a nice long time: * Fri Oct 08 2010 Adam Jackson a...@redhat.com 1.3.1-2 - Drop the vbetool dependency, suspend is only supported on KMS drivers. That was F14 gold: % koji -q latest-pkg dist-f14 pm-utils pm-utils-1.3.1-2.fc14 dist-f14 ajax In lieu of flowers, please send patches for KMS drivers to dri-de...@lists.freedesktop.org. - ajax 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: Reminder: Fedora 15 end of life on 2012-06-26
On 05/31/2012 02:09 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings. This is a reminder email about the end of life process for Fedora 15. Fedora 15 will reach end of life on 2012-06-26, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 17, no new packages will be added to the Fedora 15 collection. Are we going to get the 'F15 is end-of-life in a month' reminder against relevant bugs? That was never done for F14, nor have the F14 bugs been mass closed. I assume we don't want to make a habit of that. Thanks, Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
28.05.2012 16:45, Tomáš Smetana wrote: On Sun, 27 May 2012 23:28:03 +0400 Pavel Alexeevfo...@hubbitus.com.ru wrote: Hi. Due to the security issues ([1] for example) and act as newcomer provenpackager I'll plan update ImageMagick in Fedora 16 too (I should had been done it early off course). It seams addressed in rawhide. Hello, may I ask why you prefer bumping the soname instead of just patching the vulnerabilities? The patch is actually ready. Replacing the library with an ABI incompatible version in the stable Fedora release sounds like an overkill in this case. Thanks and regards, Because there several security issues and I think more reliable let it doing to upstream author rather than guaranties all correct in Fedora. In case there one or two sequential bugs I'll try off course handle it separately without so expensive updates off course. Rebuild all dependencies is done now, update submitted for testing: https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16 Testers are welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
Tadej Janež wrote: Pavel, On Tue, 2012-05-29 at 20:21 +0400, Pavel Alexeev wrote: It is main reason why I request provenpackager rights. In fedora 17 it was so painful because I several times asks build dependencies and then ask help to push updates too. I think in that turn now I can do all that myself, so it should be smoother. As there around 6 security issues, I think update upstream release is easiest, and furthermore robust way handle it. I've seen you didn't listen to Tomáš's or Kalev's advice on not bumping the ImageMagick's soname in a stable release. Furthermore, you didn't give any warning to the maintainers of the dependent packages (except for the message on this list). In my opinion, being a provenpackager is no excuse for not doing that. Please, use the packagename-ow...@fedoraproject.org addresses to send out emails to the appropriate package maintainers. For techne (one of the dependent packages which I maintain) you bumped the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and rawhide. Is there a way to revert the change and make a 0.2.3-2.fc16.1 build? The best practice now is to do a bump release in all newer branches. So just bump the Version in fedora 17 and rawhide to 0.2.3-3. The changelog entry could look like: - bump release or something similar. Hope this helps Johannes Best regards, Tadej Janež -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote: Matthias Clasen wrote: Its not his ignorance - he's on vacation for the next two weeks... Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post. Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
03.06.2012 22:57, Tadej Janež wrote:
Pavel,
On Tue, 2012-05-29 at 20:21 +0400, Pavel Alexeev wrote:
It is main reason why I request provenpackager rights. In fedora 17 it
was so painful because I several times asks build dependencies and
then ask help to push updates too.
I think in that turn now I can do all that myself, so it should be
smoother.
As there around 6 security issues, I think update upstream release is
easiest, and furthermore robust way handle it.
I've seen you didn't listen to Tomáš's or Kalev's advice on not bumping
the ImageMagick's soname in a stable release.
Furthermore, you didn't give any warning to the maintainers of the
dependent packages (except for the message on this list).
In my opinion, being a provenpackager is no excuse for not doing that.
Please, use the packagename-ow...@fedoraproject.org addresses to send
out emails to the appropriate package maintainers.
I post message there over week ago. I thought it was sufficient.
Provenpackager rights off course do not excuse that or other mistakes.
On the contrary it only take me possibility make such tasks without make
troubles for others. If I must also write to each maintainer separately
- I promise do it next time. Sorry.
For techne (one of the dependent packages which I maintain) you bumped
the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and
rawhide.
Is there a way to revert the change and make a 0.2.3-2.fc16.1 build?
I do not known unfortunately.
Furthermore I've submitted update to testing ta moment read that
[1].https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
May be it possible just update in Fedora 17 too?
Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions. I had look in my packages and few others and found it was
updated many times in that way. In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??
I apologize for the inconvenience. Can I help something now?
If you or other will insist I may unpush that update and try patch IM
for all issues off course... But I really do not want doing it now.
Best regards,
Tadej Janež
[1]
https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MALLOC_PERTURB_: everyone should set this envvar
John Reiser wrote: # http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) For supportability (and to help remind you to turn it off before performance tests), then also consider adding a line such as: echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_ # $HOME/.bash_profile Good idea. Or have a weekly cron job send clue-bat mail to yourself reminding you that you do have this envvar set. For the first year or so during which I had this enabled, when I'd hit a memory-related problem, I didn't immediately think, Oh! that may be because I've enabled MALLOC_PERTURB_, so the above might well help, initially. If you do add something like that, be sure to use a guard so that it is printed only for interactive sessions, e.g., test -n $PS1 echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_ Once you've been graced with enough MALLOC_PERTURB_-induced failures, you get used to it, always remember to include it in bug reports,... then you can turn that off ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Today's FESCo Meeting (2012-06-04)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = New business = #topic #857 F18 Feature: Initial Experience .fesco 857 #topic #859 F18 Feature: Active Directory .fesco 859 #topic #860 F18 Feature: Boost 1.50 Uplift .fesco 860 $topic #856 Request to be made admin of the packager group .fsco 856 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 10:57 AM, Kevin Kofler wrote: And I don't think having to disable Secure Boot in the firmware is a hurdle which will make our users simply walk away. The usability of Fedora Live will take a hit---the premise is that you can insert the CD and boot as-is. If Live is going to require permanent changes to the system, one might as well permanently install, no? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
Olav Vitters wrote: Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour. My intentions were not to insult anyone and I am not seeking a reply to my e-mail. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Once upon a time, Andreas Bierfert andreas.bierf...@lowlatency.de said: I guess we can agree that the technical part of font installation etc. is done like it should be. However, it is _not_ the wine-tahoma-fonts package which bullies its way and changes the system look and fell on its own. There are some web-pages which (maybe unintentionally) explicitly request a tahoma font and if you have wine installed - beware - they get what they request. Well, no they don't. They are requesting the font Microsoft calls Tahoma, not a Wine-provided imitation of Tahoma. Providing a font called Tahoma that isn't Tahoma is a bad idea. In general, the fonts that are designed to copy other fonts get a different name. In many cases, this is required because some font names are trademarked (IIRC Helvetica is an example). Wine should not call their font Tahoma. They should call it something else and then map requests for Tahoma to their imitation font. -- 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: Update ImageMagick in Fedora 16
Pavel Alexeev forum at hubbitus.com.ru writes: If you or other will insist I may unpush that update and try patch IM for all issues off course... But I really do not want doing it now. In my opinion, the right way to handle this is to backport the security fixes. You even have patches linked to each of the security bugs on bugzilla.redhat.com. And yes, this means unpushing the update with the soname bump. Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 20:10, Pete Walter wrote: Pavel Alexeevforumat hubbitus.com.ru writes: If you or other will insist I may unpush that update and try patch IM for all issues off course... But I really do not want doing it now. In my opinion, the right way to handle this is to backport the security fixes. You even have patches linked to each of the security bugs on bugzilla.redhat.com. And yes, this means unpushing the update with the soname bump. May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, 2012-06-03 at 19:56 +0200, Björn Persson wrote: Adam Williamson wrote: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. I refuse to buy writable DVDs or CDs, because if I did I would be giving money to the copyright lobby, helping to finance its campaign for ever-increasing mass surveillance and censorship of the Net. It is possible to boot a DVD image from the hard disk, but it's anything but easy and rarely succeeds at the first attempt, so that's not something I want to fiddle around with twice a year on both of my Fedora boxes. I also won't install anything that I haven't checked the PGP signature on. That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be careful to not let it download anything. Therefore I usually upgrade by Yum. That's also a laborious process, but I usually get a mostly working system in the end. Cool story bro. Given that I was stating my personal opinion on the message we should communicate to the general user population about which upgrade methods are most likely to work with the least tweaking, though, I'm not sure what relevance your personal qualms about buying optical media have to do with anything. It's not like I said we should disable yum upgrades. (you can, of course, boot from the DVD or netinst image without ever touching optical media. It is trivial to write them to a USB stick.) -- 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: another upgrade, another disaster
On Sun, 2012-06-03 at 19:56 +0200, Björn Persson wrote: I also won't install anything that I haven't checked the PGP signature on. That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be careful to not let it download anything. The checksums of the images themselves are signed, and the images are built by the same team that controls the process for signing individual packages, using a process by which only packages from the Fedora build system could possibly be included. You can't logically claim to trust the individual packages but not trust the signatures on the DVD/netinst images. They are precisely equally trustworthy. -- 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: another upgrade, another disaster
On Mon, 2012-06-04 at 10:03 +0200, Andrea Musuruane wrote: On Mon, Jun 4, 2012 at 8:50 AM, Adam Williamson awill...@redhat.com wrote: * 3rd attempt: Same as options as the 2nd attempt but this time I chose to enable only the F17 remote repositories and I disabled the Install repo so I presume all the packages were downloaded from the net. At about 85% of installation I got a kernel panic - this time I took care of the message unable to handle kernel NULL pointer dereference at 0088. Frankly, I wouldn't trust your hardware. The installer uses the same kernel as the installed system, so even if you get it to install (which apparently you finally did), if you're getting quasi-random kernel panics, I wouldn't be at all surprised if you keep getting them on the installed system. That (and 'inexplicable' errors like failure to read a package on known-good media) points either to bad hardware or a kernel bug specific to your system in some way (as we don't have any known general kernel breakage AFAIK). You'd definitely need to get better data on one of the crashes (i.e. an actual log, or at least screen capture) and give it to the kernel team, to look into it. It may be worth running memtest on the system, first, though. Everything can be and I will run memtest as you advised. But I didn't had any kernel problem in the past - and I've used every Fedora release on the same PC for about 4 years. After I could bypass this problem - I could install the system, including I think all the RPMs anaconda was trying to install without any problem. Note that I don't run the same kernel used by anaconda because in fedora updates there is available a newer one. Anyway, in case I hit this issue again, I would be interested to know how to get the log of this kind of error. Depending on how hard the fail is, it may be in /var/log/messages when you reboot. If not, all you can do is take a picture of the screen when the crash comes, or maybe try and use netconsole: http://www.mjmwired.net/kernel/Documentation/networking/netconsole.txt which I've got working once, but it's a bit finicky. -- 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: Update ImageMagick in Fedora 16
Pavel Alexeev forum at hubbitus.com.ru writes: May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? No, I did not test this. And here's a few reasons why I think this shouldn't be pushed: - You are forcing others to do work they otherwise wouldn't need to do. Why do you want me to test ImageMagick functionality in 57 dependant packages? Fix your security bugs and leave other packages alone. F16 is supposed to be stable. - A major ImageMagick update that introduces new features and new code invalidates the QA that has gone into the packages that use ImageMagick. - Needless update churn. We have the Stable Updates Policy for a reason. Do you development on rawhide and let stable Fedora release be stable. - The soname bump breaks third party packages that use ImageMagick libraries. An example is 'transcode' from rpmfusion. http://fedoraproject.org/wiki/Updates_Policy explicitly says that such ABI bumps are left to the discretion of FESCO and the packager. Have you already asked FESCO for their blessing? Note that you should open this dialog _BEFORE_ you build or push updates. Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Fedora 15 end of life on 2012-06-26
On Mon, 2012-06-04 at 11:03 -0400, Cole Robinson wrote: On 05/31/2012 02:09 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings. This is a reminder email about the end of life process for Fedora 15. Fedora 15 will reach end of life on 2012-06-26, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 17, no new packages will be added to the Fedora 15 collection. Are we going to get the 'F15 is end-of-life in a month' reminder against relevant bugs? That was never done for F14, nor have the F14 bugs been mass closed. I assume we don't want to make a habit of that. Housekeeping procedures sort of fell through some cracks when John Poelstra stopped doing them; they come somewhere between QA, bugzappers, releng and the program manager (who currently doesn't exist). We'll try and co-ordinate to make sure things happen properly and in the correct order for the f18 cycle, and clean up on the f16 and f17 cycle housekeeping tasks. -- 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: Update ImageMagick in Fedora 16
Pete Walter wrote: Pavel Alexeev forum at hubbitus.com.ru writes: May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? No, I did not test this. And here's a few reasons why I think this shouldn't be pushed: - You are forcing others to do work they otherwise wouldn't need to do. Why do you want me to test ImageMagick functionality in 57 dependant packages? Fix your security bugs and leave other packages alone. F16 is supposed to be stable. - A major ImageMagick update that introduces new features and new code invalidates the QA that has gone into the packages that use ImageMagick. - Needless update churn. We have the Stable Updates Policy for a reason. Do you development on rawhide and let stable Fedora release be stable. - The soname bump breaks third party packages that use ImageMagick libraries. An example is 'transcode' from rpmfusion. http://fedoraproject.org/wiki/Updates_Policy explicitly says that such ABI bumps are left to the discretion of FESCO and the packager. Have you already asked FESCO for their blessing? Note that you should open this dialog _BEFORE_ you build or push updates. Pete Just to be fair there was a mail to this mailing list, where he described his plans. [1] Also I think he did the major part of the work and if it's fine for him, I don't really see a problem. I mean of course it could be better and he could also bump the releases of all the newer fedora versions, but I think there is not so much work for the package maintainers left. I don't want to argue in favor of the whole upgrade but I think the criticism is a bit too harsh. Johannes [1] http://lists.fedoraproject.org/pipermail/devel/2012-May/167462.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2012-06-04)
=== #fedora-meeting: FESCO (2012-06-04) === Meeting started by mjg59 at 17:01:49 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-06-04/fesco.2012-06-04-17.01.log.html . Meeting summary --- * init process (mjg59, 17:02:09) * #857 F18 Feature: Initial Experience (mjg59, 17:04:12) * AGREED: postpone feature discussion until next week so mclasen can provide further feedback on the page (mjg59, 17:09:01) * #859 F18 Feature: Active Directory (mjg59, 17:09:11) * AGREED: Active Directory is accepted as an F18 feature (mjg59, 17:15:13) * #860 F18 Feature: Boost 1.50 Uplift (mjg59, 17:15:20) * AGREED: Boost 1.50 accepted as an F18 feature (mjg59, 17:18:16) * #856 Request to be made admin of the packager group (mjg59, 17:18:35) * AGREED: tibbs made an admin of the packager group, will ping other admins to check on status (mjg59, 17:26:22) * Open floor (mjg59, 17:27:09) * LINK: https://fedoraproject.org/wiki/User:Pjones/Features/SecureBoot is what I've got right now FYI (pjones, 17:29:11) * AGREED: limburgher to chair next meeting (mjg59, 17:52:05) Meeting ended at 17:52:16 UTC. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
3.5.0 kernel problem
I'm using a Rawhide VirtualBox 4.1.16 guest set up to automatically install guest additions via dkms for each new kernel. My problem is apparently caused by failure of the guest additions to build properly with the 3.5.0 kernel. When it attempts to build (either when I install a new 3.5.0 kernel, or boot into one) it causes the corruption I mentioned. For the time being I've removed dkms in the guest. The next version of VirtualBox will probably have a fix. http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/475811-re-linux-kernel-3-5-rcx-has-been-released-test-post-your-commentshere-post2467176.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.5.0 kernel problem
On Mon, Jun 4, 2012 at 1:54 PM, Andre Robatino robat...@fedoraproject.org wrote: I'm using a Rawhide VirtualBox 4.1.16 guest set up to automatically install guest additions via dkms for each new kernel. My problem is apparently caused by failure of the guest additions to build properly with the 3.5.0 kernel. When it attempts to build (either when I install a new 3.5.0 kernel, or boot into one) it causes the corruption I mentioned. For the time being I've removed dkms in the guest. The next version of VirtualBox will probably have a fix. http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/475811-re-linux-kernel-3-5-rcx-has-been-released-test-post-your-commentshere-post2467176.html Someone else reported issues with VBox and the 3.5 kernel upstream. The changes to mmap broke the build of it. Al Viro looked at it and apparently found that vbox has some dodgy code that was relying on some of the old symbols and needs to be rewritten. I am utterly unsurprised in this development. Anyway, as you said, VirtualBox needs to fix itself. There's nothing we can do here. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Sun, 03 Jun 2012 20:57:01 +0200, Tadej Janež wrote: For techne (one of the dependent packages which I maintain) you bumped the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and rawhide. Is there a way to revert the change and make a 0.2.3-2.fc16.1 build? Revert the change in git f16 branch, submit a new build job, then replace the build in the bodhi ticket. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64 loadavg: 0.31 0.25 0.27 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
Hi, I agree some wine fonts are particularly ugly, but then : 1. why is wine making them mandatory? Can't the package be made optional in wine and wine use one of the default system fonts when it is not present? 2. otherwise an uglier workaround is to ship a fontconfig rule in your package that makes some other font take precedence when an app demands tahoma Either way, the problem is not how the font file is installed, or that other apps make use of tahoma in documents that specify tahoma when a tahoma font is available, it's that the font itself is ugly and wine does not suggest a better alternative to tahoma-loving apps -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reminder: Voting has begun in Fedora Board, FAmSCo, and FESCo elections, ends June 7th
Greetings! A friendly reminder that the elections for the Fedora Board, Fedora Engineering Steering Committee (FESCo), and the Fedora Ambassadors Steering Committee (FAmSCo) began on June 1st, 2012, at 00:00:01 UTC, and will end Thursday, June 7th, 2012 at 23:59:59 UTC. Please refer to a UTC time zone converter if you are unsure if your time zone's relation to UTC, such as: http://www.timeanddate.com/worldclock/converter.html Ballots may be cast on the Fedora Elections System at: https://admin.fedoraproject.org/voting If this is the first time you've used the voting system, please refer to the Fedora Elections Guide, currently located at: http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Fedora_Elections_Guide/index.html I encourage everyone to read about the candidates for each body; in addition to their nominations, candidates were also asked to participate in questionnaires and IRC town halls, and links for that information is shown below for each group of nominees. Fedora Board: * Nominations and questionnaire answers: http://fedoraproject.org/wiki/Board/Elections/Nominations * Town Hall Logs: http://fedoraproject.org/wiki/Elections#Fedora_Project_Board Fedora Engineering Steering Committee (FESCo): * Nominations and questionnaire answers: http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations * Town Hall Logs: http://fedoraproject.org/wiki/Elections#FESCo_.28Engineering.29 Fedora Ambassadors Steering Committee (FAmSCo): * Nominations and questionnaire answers: http://fedoraproject.org/wiki/FAmSCo_election_2012_F18_nominations * Town Hall Logs: http://fedoraproject.org/wiki/Elections#FAmSCo_.28Ambassadors.29 * Please note that voting for FAmSCo is no longer restricted to Ambassadors only; eligible voters need only be part of the cla_done and any other non-cla group in the Fedora Account System. For more general information about the election, including eligibility information, please refer to: http://fedoraproject.org/wiki/Elections Please remember to cast your vote! Cheers, -Robyn I just wrote an email without any hot dog puns Bergeron ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions.
It's not provenpackager specific stuff, but found in the basic packaging
guidelines:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag
I had look in my packages and few others and found it was
updated many times in that way.
Just read the page linked above. There is no strict requirement to
apply this release versioning scheme for old branches. If newer branches
would always win RPM Version Comparison because their %version field
is _higher_, you can bump %release in older branches without risk.
In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??
As the guidelines say: Be careful with this!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
and Cinnamon is under review at https://bugzilla.redhat.com/show_bug.cgi?id=771252. Yes, it's under review for 6 months now... :( I have the impression that the criticism about Gnome 3 isn't taken very seriously. Neither from the Gnome nor from the Fedora developers. It's just frustrating... -- Regards Richard Körber -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: fatal errors on install
Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
On 06/05/2012 12:26 AM, Richard Körber wrote: and Cinnamon is under review at https://bugzilla.redhat.com/show_bug.cgi?id=771252. Yes, it's under review for 6 months now... :( So help out if you can. Going on a rant isn't going to contribute towards that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
On Mon, 2012-06-04 at 20:56 +0200, Richard Körber wrote: and Cinnamon is under review at https://bugzilla.redhat.com/show_bug.cgi?id=771252. Yes, it's under review for 6 months now... :( If you read the history, you can see why. Implementing an entire desktop environment in line with Fedora policies isn't trivial. The review is active and clearly working towards a conclusion...it's not as if anyone is stalling. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/04/2012 10:24 AM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 3:10 PM, Gerry Reno gr...@verizon.net wrote: On 06/01/2012 03:56 PM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 2:37 PM, Gerry Reno gr...@verizon.net wrote: Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. And how many consumer OEMs ship them? -J Any Chinese fab would be able to produce any quantity needed within weeks to any number of OEM's. Key words, would be able. What OEM ships this *today*? That's my point. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. The whole point is that is that I provided just one example of an equally effective solution to SecureBoot that has much less impact on both Microsoft and Linux. The entire x86 industry is going to become a mess if SecureBoot is implemented. It'll be signature-HELL and a lot more. This whole SecureBoot runaway train needs to have the brakes slammed on. I'm not saying I love SecureBoot, but that ship has sailed. Yes, and just like the Titanic it will have a lasting horrible impact. Gerry I also wish Amiga hadn't futzed with their floppy drive stepper motors to squeeze in more sectors per disk and made my floppies unreadable without a trip to eBay, but that ship has sailed as well, so I pretty have to find the best solution available for the situation at hand. I would love for SecureBoot not to have happened, or to have happened differently. If wishes were horses, even the poor would eat. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
On Mon, 2012-06-04 at 20:06 +0200, Nicolas Mailhot wrote: 1. why is wine making them mandatory? Can't the package be made optional in wine and wine use one of the default system fonts when it is not present? You can use wine without the font installed. It is just the meta package which pulls in the fonts so that a normal desktop use gets the best experience possible. You can obviously remove the font package and fiddle with wine.inf or your registry to define sensible replacements where you see fit. -- Andreas Bierfert andreas.bierf...@lowlatency.de 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: *countable infinities only
On Mon, Jun 4, 2012 at 2:44 PM, Gerry Reno gr...@verizon.net wrote: On 06/04/2012 10:24 AM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 3:10 PM, Gerry Reno gr...@verizon.net wrote: On 06/01/2012 03:56 PM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 2:37 PM, Gerry Reno gr...@verizon.net wrote: Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. And how many consumer OEMs ship them? -J Any Chinese fab would be able to produce any quantity needed within weeks to any number of OEM's. Key words, would be able. What OEM ships this *today*? That's my point. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. The whole point is that is that I provided just one example of an equally effective solution to SecureBoot that has much less impact on both Microsoft and Linux. The entire x86 industry is going to become a mess if SecureBoot is implemented. It'll be signature-HELL and a lot more. This whole SecureBoot runaway train needs to have the brakes slammed on. I'm not saying I love SecureBoot, but that ship has sailed. Yes, and just like the Titanic it will have a lasting horrible impact. I'm not disputing that that's a possibility. I'm just arguing that in lieu of a better solution being available on hardware that's either currently available or shipping in a Windows 8/Fedora 18-19 timeframe, I can see why the decision that was made was made. My opinion on SecureBoot, my opinion of Microsoft's Windows 8 certification requirements around SecureBoot, and my opinion on Fedora's actions to mitigate a bad situation are 3 distinct things. -J Gerry I also wish Amiga hadn't futzed with their floppy drive stepper motors to squeeze in more sectors per disk and made my floppies unreadable without a trip to eBay, but that ship has sailed as well, so I pretty have to find the best solution available for the situation at hand. I would love for SecureBoot not to have happened, or to have happened differently. If wishes were horses, even the poor would eat. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
On 2012/06/04 20:06 (GMT+0200) Nicolas Mailhot composed: 1. why is wine making them mandatory? Probably related to Tahoma being the Windows System (aka Menu) font in W2K and/or WXP (IIRC, in both). -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
On Mon, 2012-06-04 at 16:21 -0400, Felix Miata wrote: On 2012/06/04 20:06 (GMT+0200) Nicolas Mailhot composed: 1. why is wine making them mandatory? Probably related to Tahoma being the Windows System (aka Menu) font in W2K and/or WXP (IIRC, in both). It is quite nicely described on wikipedia [1]: The Wine project includes a free font (Wine Tahoma Regular and Wine Tahoma Bold) designed to have identical metrics to the Tahoma font.[6] This was done because Tahoma is available by default on Windows, and many applications expect the font to be available. Before Wine included a Tahoma replacement font, some applications, such as Steam, would not display any text at all, rendering them nearly unusable. [1] - http://en.wikipedia.org/wiki/Tahoma_(typeface)#Free_replacement -- Andreas Bierfert andreas.bierf...@lowlatency.de 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: another upgrade, another disaster
On Mon, 2012-06-04 at 22:52 +0200, Björn Persson wrote: Adam Williamson wrote: Given that I was stating my personal opinion on the message we should communicate to the general user population about which upgrade methods are most likely to work with the least tweaking, though, I'm not sure what relevance your personal qualms about buying optical media have to do with anything. It's not like I said we should disable yum upgrades. You wanted to more strongly recommended that people do DVD/netinst upgrades. By recommending this we'd be encouraging users to buy more optical media and thereby give more money to the copyright lobby. Given that freedom is one of Fedora's core values I don't think we should encourage people to give money to organizations that are fighting to take freedom away from the Internet. Good for you. As things stand, though, as a project, we have no position on that issue and no objection to optical media. Everyone has their bugbears. If you can make it clear that enough people in Fedora feel as strongly as you do about copyright levies, then maybe things will be different. But, still, the fact remains that the 'DVD' and netinst images are not in fact tied to optical media. I'd guess (it is entirely a guess, I have no data) that they're as often deployed via USB as they are via discs, these days. -- 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: another upgrade, another disaster
On Tue, May 29, 2012 at 16:58:18 -0400, Steve Gordon sgor...@redhat.com wrote: I eventually hit it with a hammer and did yum remove '*fc16*', when I reviewed the resultant transaction there were a handful of fc17 packages also removed as a result of dependencies but these were easily installed again, pulling in their fc17 dependencies instead. At this point I now appear to have a stable system and everything working, we'll see how long that lasts for though ;). The problem with that is some packages might have been inherited into f17 from f16 because there weren't rebuilt for f17. (Since there was a mass rebuild for f17 there aren't many of these.) You can use package-cleanup --orphans to find packages not in any of your currently used repos. You can take that list and list the available packages (yum list available) to find ones with just blocked updates and try removing the rest. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 06:23 PM, Gerry Reno wrote: On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On Mon, 04 Jun 2012 19:37:07 -0400 Gerry Reno gr...@verizon.net wrote: Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( The install guide might be of help... http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Installation_Guide/index.html#encrypt-x86 And this is really the sort of question best suited to the users list: http://lists.fedoraproject.org/mailman/listinfo/users not the devel list. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 07:37 PM, Gerry Reno wrote: On 06/04/2012 06:23 PM, Gerry Reno wrote: On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( . Opened bug on inability to edit Volume Group name: https://bugzilla.redhat.com/show_bug.cgi?id=828592 . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 07:44 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 19:37:07 -0400 Gerry Reno gr...@verizon.net wrote: Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( The install guide might be of help... http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Installation_Guide/index.html#encrypt-x86 And this is really the sort of question best suited to the users list: http://lists.fedoraproject.org/mailman/listinfo/users not the devel list. ;) kevin Hey Kevin, I've been custom partitioning Fedora installs since the beginning of anaconda. Look back several years and you'll find still unaddressed installation bugs for anaconda/preupgrade. For example /boot on RAID. And things in F17 installer are not exactly as described on the guide. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
Richard Körber wrote: Yes, [Cinnamon]'s under review for 6 months now... :( It's available from repos.fedorapeople.org though: http://repos.fedorapeople.org/repos/leigh123linux/cinnamon/ Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Przemek Klosowski wrote: The usability of Fedora Live will take a hit---the premise is that you can insert the CD and boot as-is. If Live is going to require permanent changes to the system, one might as well permanently install, no? Disabling Secure Boot doesn't necessarily have to be permanent if the firmware is designed properly. (Of course, if the only way they allow you to disable it is to delete all keys and if they don't offer a way to restore them, then it's permanent, but I'd call that a very broken firmware.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide: libudev version bump, merged into systemd, libudev user need rebuild
We merged the upstream udev repository entirely into the systemd repository. There is no standalone upstream udev project anymore. The version of systemd which includes udev has landed in rawhide a couple of days ago. Fedora 18 will not have a udev.rpm, no libudev.rpm and no libudev-devel.rpm. The libgudev1.rpm and libgudev1-devel.rpm are provides the same way as before and will still exist. Please remove all udev dependencies in packages which link against udev. They should now just use: Buildrequires: systemd-devel If a versioned dependency is needed, please use: Requires: systemd XXX The systemd version number jumped to the next version of the last release of udev, it is currently 185. Systemd includes libudev.so.1, while the old libudev.rpm provided libudev.so.0. Therefore, all packages using udev need to be rebuilt. These symbols are no longer provided by libudev.so.1: - udev_monitor_new_from_socket() custom application sockes are no longer supported by udevd, use the usual udev_monitor_from_netlink() - udev_queue_get_failed_list_entry() failed events are not recorded by udev since a long time, code that used this can just be removed - udev_get_dev_path() udev_get_sys_path() udev_get_run_path() systemd does not allow to configure any of these filesystem paths, they should simply be hard-coded and be replaced by /dev, /sys and /run/udev Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
I follow this thread, and I follow the other thread about the same topic, on the user forum where I belong. Flame if if you like for posting her, but when I read this URLs below [1], I do feel worry. http://blogs.msdn.com/b/b8/archive/2012/05/22/designing-for-pcs-that-boot-faster-than-ever-before.aspx#comments [1] So quickly, in fact, that there is no longer time for anything to interrupt boot. When you turn on a Windows 8 PC, there’s no longer long enough to detect keystrokes like F2 or F8, much less time to read a message such as “Press F2 for Setup.” For the first time in decades, you will no longer be able to interrupt boot and tell your PC to do anything different than what it was already expecting to do. I am located in Japan, I use pre-installed windows (as if it was a choice) notebooks because I need mobility. My usage of Linux is the desktop, not the server. Knowing the mentality the Japanese makers, they will surely enforce UEFI on their W8 models, not letting users disabling it at boot time. The only think I expect [hope], at the time of the purchase of my next notebook (W8/UEFI) -- mine is now 7 y.o. over -- is to erase the OS for morons. To install my beloved distribution on a empty volume, and to boot. Explain me how to remove secure boot, I will do it. It's a chore, thanks to the nice people at M$, but I want to do it. And that's possibly (but I speak for myself) what most casual Linux DE users want. They want to run Linux only. On a side note: I could not probably not run Linux if I had to compile all my software. I can today because of projects like Fedora. And I feel grateful. I don't use a Linux distribution because i am a computer geek, I use Linux in the same manner i would use an machine gun, if I was living in a middle east country, fighting for my freedom. I keep a bullet for the fat sweaty bald pig. -- nomnex nom...@gmail.com Freenode: nomnex Registered Linux user #505281. Be counted at: http://linuxcounter.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 2 Jun 2012 12:18:17 -0400 Orcan Ogetbil oget.fed...@gmail.com escribió: On Sat, Jun 2, 2012 at 12:05 PM, Jesse Keating wrote: The only Freedom you've lost is that now, in addition to the person-hours to do the work and monetary cost to host your bits or generate physical media, you have an additional cost if you wish to have your own cert that will be accepted out of the box by the next generation of PC hardware. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. That's a better deal than Fedora's gpg signing setup. Hmm, will the package maintainers have the freedom to not support users who have the secureboot enabled? How are we going to detect this? i look at it this way. if you patch your software to only run on machines with secureboot disabled your software then becomes non free and has to be removed from fedora. this is becasuse you are placing usage restrictions on it. depending on the license of the software adding such a restriction would violate the license. I am not a lawyer at all and never pretend to play one, but i do not think you as a package maintainer can do that. an upstream could, but i imagine it would be viewed in the same light as a commercial use restriction and become non-free. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/Nb0MACgkQkSxm47BaWfe1jgCgnhuRMWC5OMFUVR6Uz5CtTxVq cykAoKDVd6iw3kttJaePELJ04P3tcL3h =5xkU -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, 05 Jun 2012 03:35:22 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Przemek Klosowski wrote: The usability of Fedora Live will take a hit---the premise is that you can insert the CD and boot as-is. If Live is going to require permanent changes to the system, one might as well permanently install, no? Disabling Secure Boot doesn't necessarily have to be permanent if the firmware is designed properly. (Of course, if the only way they allow you to disable it is to delete all keys and if they don't offer a way to restore them, then it's permanent, but I'd call that a very broken firmware.) Yeah, my reading of: Mandatory. If the firmware is reset to factory, then any customized Secure Boot variables are also factory reset. If the firmware settings are reset to factory defaults, all custom-set variables shall be erased and the OEM PKpub shall be re-established along with the original, manufacturer-provisioned signature databases. means you can just reset back to default and get the factory provided keys back. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wine font changes system look and feel
On 2012/06/04 16:56 (GMT+0200) Andreas Bierfert composed: I guess we can agree that the technical part of font installation etc. is done like it should be. However, it is _not_ the wine-tahoma-fonts package which bullies its way and changes the system look and fell on its own. There are some web-pages which (maybe unintentionally) Intentionally in most cases, because it's widespread, and often copied, but also quite naively. Those who specify Tahoma as a fallback for Verdana really don't understand what they are doing. Virtually no Windows systems with Tahoma installed will not also have Verdana installed. For that to happen someone would need to remove Verdana. Both are part of the Windows OS installation, but not part of a Wine installation. Web pages will always show Verdana on Windows, but on Fedora system with Wine, nothing makes it likely that either Verdana or Tahoma will be used. Wine-Tahoma is very clearly not Tahoma. explicitly request a tahoma font and if you have wine installed - beware - they get what they request. No they don't, unless the same ttf files are installed on those Wine systems as are installed on Windows systems. You argue they do so as a fallback which under 'normal' circumstances should never be used. My question would then be why we do reach this point in the first place. Maybe that is a starting point where we can improve. It happens because: 1-Microsoft's TTF fonts are not in the browser's font path 2-a poor imitation of Tahoma named Tahoma is in the browser's font path 3-Clueless web authors include Tahoma as a fallback to Verdana, which is not part of a standard Wine install, while the Tahoma impostor is As a packager I, however, find it important that for the use-case of wine the best available user experience is provided. Hence this font needs to be included an pulled in by wine like it is today. The second best possible experience can only result if Microsoft's Tahoma font is in the font path. The best would be for Tahoma not to exist at all, and something else be provided by fontconfig when it is requested. Tahoma is a horizontally squished variant of the ugly Verdana, designed for maximum legibility at small sizes, and out of place in any other context. Now the question remains if there is action needed on this issue. As I understand that some users do not like the wine tahoma font, the package as been adopted to disable bitmaps by default and instructions have been added on how to disable the font. Unless Microsoft's Tahoma can be installed as a part of Wine installation, the Wine installation needs somehow to strongly suggest that Microsoft's Tahoma become installed, and note the auto-installed impostor's limitations. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-OpenSSH] Do not require specific architecture of openssh-clients
commit 96b40818247aa0ac8071b3ac7d8b07c082254079
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 09:37:22 2012 +0200
Do not require specific architecture of openssh-clients
The %_isa is undefined on noarch build root. Or it just gets random
value depending on machine koji picks up.
In general there is no reason why noarch package should require
specific ISA, especially in this case.
perl-Net-OpenSSH.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-OpenSSH.spec b/perl-Net-OpenSSH.spec
index 647e9cd..5d015dc 100644
--- a/perl-Net-OpenSSH.spec
+++ b/perl-Net-OpenSSH.spec
@@ -1,6 +1,6 @@
Name: perl-Net-OpenSSH
Version:0.57
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Perl SSH client package implemented on top of OpenSSH
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,7 +11,7 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: openssh-clients%{?_isa}
+Requires: openssh-clients
# Needed to stop the sample scripts pulling in more perl packages.
%{?perl_default_filter}
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 0.57-4
+- Do not require specific architecture of openssh-clients
+
* Fri May 18 2012 Steve Traylen steve.tray...@cern.ch - 0.57-3
- Rebuild for bad _isa rpm macro.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Codes] The POD tests do not run by default anymore
commit 3b406ea0d8ba12a07eddb42fa5d996242cf7fb1c
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 13:51:08 2012 +0200
The POD tests do not run by default anymore
perl-Locale-Codes.spec |8
1 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/perl-Locale-Codes.spec b/perl-Locale-Codes.spec
index 7490da3..4de35ae 100644
--- a/perl-Locale-Codes.spec
+++ b/perl-Locale-Codes.spec
@@ -1,6 +1,6 @@
Name: perl-Locale-Codes
Version:3.21
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Distribution of modules to handle locale codes
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,9 +13,6 @@ BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
BuildRequires: perl(Storable)
BuildRequires: perl(Test::More)
-# Optional tests
-BuildRequires: perl(Test::Pod) = 1.00
-BuildRequires: perl(Test::Pod::Coverage) = 1.00
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# Inject not detected module version
@@ -51,6 +48,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 3.21-2
+- The POD tests do not run by default anymore
+
* Fri Mar 02 2012 Petr Pisar ppi...@redhat.com - 3.21-1
- 3.21 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-Codes] Switch build script from Module::Build to EU::MM
commit ac29bc901e2160f05756b9ed92629e955b2a44c4
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 13:53:25 2012 +0200
Switch build script from Module::Build to EU::MM
perl-Locale-Codes.spec | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
---
diff --git a/perl-Locale-Codes.spec b/perl-Locale-Codes.spec
index 4de35ae..db9fd46 100644
--- a/perl-Locale-Codes.spec
+++ b/perl-Locale-Codes.spec
@@ -7,7 +7,7 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Codes/
Source0:
http://www.cpan.org/authors/id/S/SB/SBECK/Locale-Codes-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Module::Build)
+BuildRequires: perl(ExtUtils::MakeMaker)
# Tests
BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
@@ -31,16 +31,17 @@ including languages, countries, currency, etc.
chmod -x examples/*
%build
-%{__perl} Build.PL installdirs=vendor
-./Build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=$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 \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-./Build test
+make test
%files
%doc ChangeLog LICENSE README README.first examples
@@ -50,6 +51,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%changelog
* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 3.21-2
- The POD tests do not run by default anymore
+- Switch build script from Module::Build to EU::MM
* Fri Mar 02 2012 Petr Pisar ppi...@redhat.com - 3.21-1
- 3.21 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML-Tiny] The POD tests do not run by default
commit 1faddf246fc30f013c54103280db5aa0d53c3f08
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 14:18:28 2012 +0200
The POD tests do not run by default
perl-YAML-Tiny.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-YAML-Tiny.spec b/perl-YAML-Tiny.spec
index 6f02600..66eb441 100644
--- a/perl-YAML-Tiny.spec
+++ b/perl-YAML-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-YAML-Tiny
Version:1.51
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
Group: Development/Libraries
@@ -14,7 +14,6 @@ BuildRequires: perl(File::Spec) = 0.80
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More) = 0.47
-BuildRequires: perl(Test::Pod)
BuildRequires: perl(YAML)
BuildRequires: perl(YAML::Syck)
Requires: perl(Exporter)
@@ -50,6 +49,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 1.51-2
+- The POD tests do not run by default
+
* Wed Mar 14 2012 Petr Šabata con...@redhat.com - 1.51-1
- 1.51 bump
- Remove command macros
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Leak] Specify all dependencies
commit 8d14bc143063d8d86355547732d19ec554d7da18
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 14:23:22 2012 +0200
Specify all dependencies
perl-Devel-Leak.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Leak.spec b/perl-Devel-Leak.spec
index e4c779f..128e915 100644
--- a/perl-Devel-Leak.spec
+++ b/perl-Devel-Leak.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Leak
Version:0.03
-Release:16%{?dist}
+Release:17%{?dist}
Summary:Utility for looking for perl objects that are not reclaimed
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,11 @@ URL:http://search.cpan.org/dist/Devel-Leak/
Source0:
http://www.cpan.org/authors/id/N/NI/NI-S/Devel-Leak-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
+BuildRequires: perl(base)
+BuildRequires: perl(DynaLoader)
+# Tests:
+BuildRequires: perl(Test)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -46,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 0.03-17
+- Specify all dependencies
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.03-16
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Build] Do not run PAR tests on bootstrap
commit 6963f57cb67159a6e48137be851ee50305dda3e1
Author: Petr Písař ppi...@redhat.com
Date: Mon Jun 4 14:40:01 2012 +0200
Do not run PAR tests on bootstrap
perl-Module-Build.spec | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
---
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 25ed5e2..44d8a0a 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -1,7 +1,7 @@
Name: perl-Module-Build
Epoch: 2
Version:0.40
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Build and install Perl modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,12 +36,16 @@ BuildRequires: perl(IO::File)
BuildRequires: perl(lib)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Module::Metadata) = 1.02
-BuildRequires: perl(PAR::Dist)
BuildRequires: perl(Parse::CPAN::Meta)
BuildRequires: perl(Perl::OSType) = 1
+# Optional tests:
+%if !%{defined perl_bootstrap}
+BuildRequires: perl(Archive::Zip)
+BuildRequires: perl(PAR::Dist)
%if 0%{?fedora} || 0%{?rhel} 7
BuildRequires: perl(Pod::Readme)
%endif
+%endif
BuildRequires: perl(Test::Harness) = 3.16
BuildRequires: perl(Test::More) = 0.49
BuildRequires: perl(version) = 0.87
@@ -54,6 +58,7 @@ Requires: perl(ExtUtils::Manifest) = 1.54
Requires: perl(ExtUtils::Mkbootstrap)
Requires: perl(ExtUtils::ParseXS) = 2.21
Requires: perl(Module::Metadata) = 1.02
+# Keep PAR support optional (PAR::Dist)
Requires: perl(Perl::OSType) = 1
Requires: perl(Test::Harness)
@@ -97,6 +102,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Mon Jun 04 2012 Petr Pisar ppi...@redhat.com - 2:0.40-2
+- Do not run PAR tests on bootstrap
+
* Thu May 31 2012 Petr Pisar ppi...@redhat.com - 2:0.40-1
- 0.40 bump
- All reverse dependecies must require use 2-digit Module::Build version now
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828203] New: Locale-Codes 3.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828203 Bug ID: 828203 QA Contact: extras...@fedoraproject.org Severity: unspecified URL: http://search.cpan.org/~sbeck/Locale-Codes-3.22/ Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: Locale-Codes 3.22 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: ppi...@redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: ASSIGNED Component: perl-Locale-Codes Product: Fedora New version 3.22 is available. The only change is a database of codes. Pushing to older Fedoras is recommended. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828213] New: perl-Alien-SDL-1.434 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828213 Bug ID: 828213 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Assignee: mmasl...@redhat.com Summary: perl-Alien-SDL-1.434 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Alien-SDL Product: Fedora Latest upstream release: 1.434 Current version in Fedora Rawhide: 1.430 URL: http://search.cpan.org/dist/Alien-SDL/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828214] New: perl-Archive-Tar-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828214 Bug ID: 828214 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Assignee: mmasl...@redhat.com Summary: perl-Archive-Tar-1.88 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Archive-Tar Product: Fedora Latest upstream release: 1.88 Current version in Fedora Rawhide: 1.84 URL: http://search.cpan.org/dist/Archive-Tar/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
