[Test-Announce] 2012-01-23 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-01-23 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again. We have a bunch of action items from last week to catch up on, and now Fedora 17 testing is starting to come online, with RATS runs and the first blocker bug review meeting next Friday. 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/20120123 The current proposed agenda is include below. If no topics beyond the standard "Previous meeting follow-up" and "AutoQA update" topics are present or proposed, the meeting will be canceled. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Requested change to BugStatusWorkFlow 3. Upcoming QA events 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: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi said: > On Fri, 20 Jan 2012 17:15:57 -0600 > Chris Adams wrote: > > I would think that making it release based rather than time based > > should be okay. If there have been N released shipped without > > package foo, then foo needs to be re-reviewed (with N being only 1 or > > 2). > > Possibly, but that info isn't super easy to find. You would need to > look at the scm-commits list to see when it was retired. If it was release-1 or release-2, those are both current and still getting updates; checking the current trees on a mirror would show if the package was in either release. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mdadm: sending ioctl 1261 to a partition!
[root@srv-rhsoft:~]$ dmesg -c mdadm: sending ioctl 1261 to a partition! mdadm: sending ioctl 1261 to a partition! what does the system want to tell me with this each time "/sbin/mdadm --detail" is called to any raid-array? can this be ignored or is there a possible bug in recent kernel/mdadm which should be reported in bugzilla? mdadm-3.2.3-3 [root@srv-rhsoft:~]$ uname -r 2.6.41.10-2.fc15.x86_64 #1 SMP Thu Jan 19 02:27:37 UTC 2012 ___ [root@srv-rhsoft:~]$ cat /proc/mdstat Personalities : [raid1] [raid10] md2 : active raid10 sdc3[0] sdd3[3] sda3[4] sdb3[5] 3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 0/29 pages [0KB], 65536KB chunk md1 : active raid10 sdc2[0] sdd2[3] sda2[4] sdb2[5] 30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 1/1 pages [4KB], 65536KB chunk md0 : active raid1 sdc1[0] sdd1[3] sda1[4] sdb1[5] 511988 blocks super 1.0 [4/4] [] unused devices: ___ [root@srv-rhsoft:~]$ /sbin/mdadm --detail /dev/md1 /dev/md1: Version : 1.1 Creation Time : Wed Jun 8 13:10:52 2011 Raid Level : raid10 Array Size : 30716928 (29.29 GiB 31.45 GB) Used Dev Size : 15358464 (14.65 GiB 15.73 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Jan 21 03:59:22 2012 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : near=2 Chunk Size : 512K Name : localhost.localdomain:1 UUID : b7475879:c95d9a47:c5043c02:0c5ae720 Events : 10563 Number Major Minor RaidDevice State 0 8 340 active sync /dev/sdc2 5 8 181 active sync /dev/sdb2 4 822 active sync /dev/sda2 3 8 503 active sync /dev/sdd2 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: An Easy But Serious Screensaver Security Problem In X.Org
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote: > Hopefully this is being addressed: > > http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA It was fixed in Fedora 16 and Rawhide (the only releases it actually affected) before Phoronix even posted their 'update', they just missed the update. https://admin.fedoraproject.org/updates/FEDORA-2012-0712/xkeyboard-config-2.3-3.fc16 Was submitted 2012-01-19 07:08:19 and pushed stable 2012-01-19 22:01:39. -- 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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: > > I use closed/upstream, when I already fixed it in upstream. This bug > > should be closed with number of release, where it is fixed or with the > > link to the commit. I wouldn't blame this state for not fixing bug in > > some projects. I guess instead of closed/upstream we would see more > > closed/wontfix|cantfix. > > I use POST for that. > > "A patch or solution believed to resolve this matter has been proposed > (POSTed) for inclusion in the package or kernel." > > For non-kernel packages I read that as meaning that the patch is in-hand > upstream, and not yet built in Fedora. POST is kind of problematic as different groups use it for different meanings. anaconda use it to mean 'a patch has been sent to anaconda-devel-list for review', for e.g. -- 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: [ACTION REQUIRED] Retiring packages for F-17
On Fri, 20 Jan 2012 17:15:57 -0600 Chris Adams wrote: > Once upon a time, Kevin Fenzi said: > > b) unretirement > > > > This could be pretty massive changes. If something was retired years > > ago, the entire spec could be very different. Or it could have been > > yesterday. But making the time variable for re-review makes it much > > more complex. Last time we looked at this, it was an easy way to > > tell if something needed re-review. Is it orphaned? then just take > > it. Is it retired? then re-review it. > > I would think that making it release based rather than time based > should be okay. If there have been N released shipped without > package foo, then foo needs to be re-reviewed (with N being only 1 or > 2). Possibly, but that info isn't super easy to find. You would need to look at the scm-commits list to see when it was retired. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi said: > b) unretirement > > This could be pretty massive changes. If something was retired years > ago, the entire spec could be very different. Or it could have been > yesterday. But making the time variable for re-review makes it much > more complex. Last time we looked at this, it was an easy way to tell > if something needed re-review. Is it orphaned? then just take it. Is it > retired? then re-review it. I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, 19 Jan 2012 18:50:50 -0500 Stephen Gallagher wrote: > On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: > > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: ...snip... > > > (And now with my packager hat on, fixing and/or updating a > > > package in the repo also requires less effort than unretiring a > > > package which got removed.) > > > > This is an important point: I think it would be much less of a > > problem to retire packages if the process for unretiring them were > > not so painful. I _do_ think the unretiring process is an excellent > > example of unnecessary bureaucracy (as is the renaming process, > > good lord, what a PITA). Those two things could stand to be trimmed > > down. At least to 'if you're a provenpackager (or even just a > > sponsored packager) you can unretire a package without any > > obstacles'. > > If you file a FESCo ticket to change this policy, this approach would > have my support. There's no reason that a package rename or > unretirement should need to go through a full review (although as I > said in an earlier email, the side-effect here is that such things > can help curb specrot). There are two cases here: a) rename The changes involved in a rename are pretty minor. Just usually adding Obsoletes and Provides and changing the name in the spec file. That said, it's amazing how easy it is to get this wrong. It happens ALL THE TIME. ;) having a review to get another pair of eyes was decided to be the best way to avoid that. I tried (and failed) to get a lower bar for this. Perhaps current fesco would be interested. b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Tue, 17 Jan 2012 02:20:15 +0100 Kevin Kofler wrote: > Kevin Fenzi wrote: > > We talked about, but never finished implementing a timeout on acl > > requests. > > > > The way this would work is that maintainer would have some time.. 3 > > weeks or something to reject a acl request. If they did not do so, > > pkgdb would automatically approve it at the end of the time. > > This would help in cases where the maintainer is overloaded or not > > paying attention. > > The question is of course why we need to allow the maintainer to > reject comaintainership in the first place. Sure. In an ideal world we never would. In the real world it might be that someone is a new maintainer and wanting to work on a package that is very complex or sensitive without much background, or someone who the current maintainers know they differ on philosophy or something that would make working together difficult, or a maintainer who doesn't get along with upstream and would cause undue friction, or a maintainer who doesn't communicate with existing maintainers well, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Kevin Kofler wrote: > Adam Williamson wrote: > > Would it make sense just to put the hicolor directory into filesystem? > > It seems silly to have every single graphical app in the distro depend > > on a package simply for the provision of the directory... > > There are also all the subdirectories such as > /usr/share/icons/hicolor/24x24/apps/. > > And the whole purpose of hicolor-icon-theme is to include those directories > and the index.theme file. I count two files and 339 directories (plus one directory and three file under /usr/share/doc/). If that's not enough to justify a separate package, but it's undesirable to include these files even on a minimal server, then perhaps they could be added to some X package that all graphical programs depend on anyway? Just a thought. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes coming for CUPS 1.6
On Fri, 2012-01-20 at 09:25 +, Tim Waugh wrote: > On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote: > > What a great idea! We could call one of them 'Postscript'... > > Not likely. :-) > > I think the current candidate for the optional vector format is PDF > 1.4/1.5. Everything old is new again... -- 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: Bundled part of code
19.01.2012 17:03, Kevin Kofler wrote: Pavel Alexeev wrote: But how I should then deal with licensing in my situation if its mismatch? There is no mismatch, it's OK to include GPLv2+ code in a GPLv3+ program, the result is just GPLv3+. (You can also declare "License: GPLv3+ and GPLv2+", but if everything is getting linked into a single binary, what's left is really just GPLv3+.) Thank you very much for clarification! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning blam: RSS feed reader
Don't currently use, don't have time to maintain it, feel free to take it (I kept myself as co-maintainer to help out the transition): https://admin.fedoraproject.org/pkgdb/acls/name/blam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Adam Williamson wrote: > Would it make sense just to put the hicolor directory into filesystem? > It seems silly to have every single graphical app in the distro depend > on a package simply for the provision of the directory... I agree. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP 5.4 Fedora 17 feature - STATUS
Le 20/01/2012 19:51, Remi Collet a écrit : > Pending > ice (owner will take care of it) > Done, thanks for your help on ice-php ! best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
* Ralf Corsepius [20/01/2012 19:53] : > > Surely the bug is open: The product you are supposed to be > responsible for (A Fedora package) suffers from an unfixed bug, > documented in bugzilla. Anyone looking in brc for the unfixed bugs of a package is going to be severely disappointed. Bugs there will only be a minute of the bugs the upstream bugtracker contains. If you're looking for this type of information, using anything but upstream's bugtracker is a waste of time. > Surely, there are things to be done. > > - Others might be able to fix it. > - You can cross check if its fixed in the next upstream release In both cases, it make more sense to do this work in upstream's context rather than a Fedora context. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP 5.4 Fedora 17 feature - STATUS
Am 20.01.2012 19:51, schrieb Remi Collet: > Le 19/01/2012 19:57, Remi Collet a écrit : >> Feature page : https://fedoraproject.org/wiki/Features/Php54 > > I just finish to rebuild > > php-5.4.0-0.1.RC6.fc17 > > And dependant packages : > > php-facedetect-1.0.1-6.fc17 > php-idn-1.2c-5.fc17 > php-libvirt-0.4.5-1.fc17 > php-magickwand-1.0.9-2.fc17 > php-pecl-apc-3.1.9-4.svn316786.fc17 > php-pecl-geoip-1.0.8-1.fc17 > php-pecl-mailparse-2.1.5-6.fc17 > php-pecl-imagick-3.1.0-0.1.RC1.fc17 > php-pecl-ssh2-0.11.3-1.fc17 > php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 thank you for your great work, especially patches for PHP/MySQL on recent fedora-versions or recent PHP/MySQL packages on older fedora-releases in your private repo all over the last years this is a great base for normal users as also for people like me building core-services in recent versions for fedora version-1 on own environments! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Math-Round] Created tag perl-Math-Round-0.06-12.fc17
The lightweight tag 'perl-Math-Round-0.06-12.fc17' was created pointing to: 528d464... Spec clean-up -- 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: PHP 5.4 Fedora 17 feature - STATUS
On Fri, Jan 20, 2012 at 4:51 PM, Remi Collet wrote: > Le 19/01/2012 19:57, Remi Collet a écrit : >> Feature page : https://fedoraproject.org/wiki/Features/Php54 > > I just finish to rebuild > > php-5.4.0-0.1.RC6.fc17 > > And dependant packages : > > cups-1.5.0-28.fc17 > graphviz-2.28.0-13.fc17 > libdigidocpp-0.3.0-13.fc17 > libpuzzle-0.11-12.fc17 > php-facedetect-1.0.1-6.fc17 > php-idn-1.2c-5.fc17 > php-libvirt-0.4.5-1.fc17 > php-magickwand-1.0.9-2.fc17 > php-pecl-apc-3.1.9-4.svn316786.fc17 > php-pecl-gearman-1.0.1-1.fc17 > php-pecl-geoip-1.0.8-1.fc17 > php-pecl-gmagick-1.0.10-0.1.b1.fc17 > php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17 > php-pecl-lzf-1.5.2-9.fc17 > php-pecl-mailparse-2.1.5-6.fc17 > php-pecl-imagick-3.1.0-0.1.RC1.fc17 > php-pecl-memcache-3.0.6-3.fc17 > php-pecl-memcached-2.0.0-0.1.git1736623.fc17 > php-pecl-mongo-1.2.7-1.fc17 > php-pecl-ncurses-1.0.1-5.fc17 > php-pecl-oauth-1.2.2-3.fc17 > php-pecl-radius-1.2.5-13.fc17 > php-pecl-rrd-1.0.5-3.fc17 > php-pecl-selinux-0.3.1-8.fc17 > php-pecl-solr-1.0.2-3.fc17 > php-pecl-sphinx-1.1.0-3.fc17 > php-pecl-ssh2-0.11.3-1.fc17 > php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 > php-pecl-yaml-1.0.1-6.fc17 > php-shout-0.9.2-10.fc17 > syck-0.61-16.fc17 > uuid-1.6.2-8.fc17 > zarafa-7.0.4-2.fc17 > zorba-2.1.0-3.fc17 > very nice, thanks for great job and for fixing php-pecl-ssh2 -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Math-Round] Spec clean-up
commit 528d46467717c60ac5c1ccd32752eedeed9ee4b9 Author: Paul Howarth Date: Fri Jan 20 19:11:36 2012 + Spec clean-up - BR: perl(Exporter) and perl(POSIX) - Make %files list more specific - Don't use macros for commands - Use DESTDIR rather than PERL_INSTALL_ROOT - Recode README as UTF-8 .gitignore |2 +- Math-Round-0.06-utf8.patch | 11 + perl-Math-Round.spec | 54 +++ 3 files changed, 41 insertions(+), 26 deletions(-) --- diff --git a/.gitignore b/.gitignore index 7a51b5d..d7bb130 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -Math-Round-0.06.tar.gz +/Math-Round-[0-9.]*.tar.gz diff --git a/Math-Round-0.06-utf8.patch b/Math-Round-0.06-utf8.patch new file mode 100644 index 000..be1cd2c --- /dev/null +++ b/Math-Round-0.06-utf8.patch @@ -0,0 +1,11 @@ +--- Math-Round-0.06/README Math-Round-0.06/README +@@ -37,7 +37,7 @@ + make install + + +-Copyright � 2002 Geoffrey Rommel. All rights reserved. ++Copyright © 2002 Geoffrey Rommel. All rights reserved. + This program is free software; you can redistribute it and/or modify + it under the same terms as Perl itself. + diff --git a/perl-Math-Round.spec b/perl-Math-Round.spec index acc8c92..024ea15 100644 --- a/perl-Math-Round.spec +++ b/perl-Math-Round.spec @@ -1,61 +1,65 @@ Name: perl-Math-Round -Version:0.06 -Release:11%{?dist} +Version:0.06 +Release:12%{?dist} Summary:Perl extension for rounding numbers - Group: Development/Libraries -License:GPL+ or Artistic -URL:http://search.cpan.org/dist/Math-Round -Source0: http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - -BuildArch: noarch +License:GPL+ or Artistic +URL:http://search.cpan.org/dist/Math-Round +Source0: http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz +Patch0: Math-Round-0.06-utf8.patch +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu) +BuildArch: noarch +BuildRequires: perl(Exporter) BuildRequires: perl(ExtUtils::MakeMaker) -Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) +BuildRequires: perl(POSIX) +Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) %description Math::Round supplies functions that will round numbers in different ways. The functions round and nearest are exported by default; others are available as described below. "use ... qw(:all)" exports all functions. - %prep %setup -q -n Math-Round-%{version} +# Recode docs as UTF-8 +%patch0 -p1 + # remove errant execute bits -find . -type f -exec chmod -x {} ';' +find . -type f -exec chmod -c -x {} ';' %build -%{__perl} Makefile.PL INSTALLDIRS=vendor +perl Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} - %install rm -rf %{buildroot} - -make pure_install PERL_INSTALL_ROOT=%{buildroot} +make pure_install DESTDIR=%{buildroot} find %{buildroot} -type f -name .packlist -exec rm -f {} ';' find %{buildroot} -type d -depth -exec rmdir {} 2>/dev/null ';' - -%{_fixperms} %{buildroot}/* - +%{_fixperms} %{buildroot} %check make test - %clean rm -rf %{buildroot} - %files %defattr(-,root,root,-) %doc Changes README -%{perl_vendorlib}/* -%{_mandir}/man3/*.3* - +%{perl_vendorlib}/auto/Math/ +%{perl_vendorlib}/Math/ +%{_mandir}/man3/Math::Round.3pm* %changelog +* Fri Jan 20 2012 Paul Howarth - 0.06-12 +- BR: perl(Exporter) and perl(POSIX) +- Make %%files list more specific +- Don't use macros for commands +- Use DESTDIR rather than PERL_INSTALL_ROOT +- Recode README as UTF-8 + * Fri Jan 13 2012 Fedora Release Engineering - 0.06-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild @@ -69,7 +73,7 @@ rm -rf %{buildroot} - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild * Mon Dec 20 2010 Marcela Maslanova - 0.06-7 -- 661697 rebuild for fixing problems with vendorach/lib +- Rebuild to fix problems with vendorarch/lib (#661697) * Mon May 03 2010 Marcela Maslanova - 0.06-6 - Mass rebuild with perl-5.12.0 -- 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: PHP 5.4 Fedora 17 feature - STATUS
Le 19/01/2012 19:57, Remi Collet a écrit : > Feature page : https://fedoraproject.org/wiki/Features/Php54 I just finish to rebuild php-5.4.0-0.1.RC6.fc17 And dependant packages : cups-1.5.0-28.fc17 graphviz-2.28.0-13.fc17 libdigidocpp-0.3.0-13.fc17 libpuzzle-0.11-12.fc17 php-facedetect-1.0.1-6.fc17 php-idn-1.2c-5.fc17 php-libvirt-0.4.5-1.fc17 php-magickwand-1.0.9-2.fc17 php-pecl-apc-3.1.9-4.svn316786.fc17 php-pecl-gearman-1.0.1-1.fc17 php-pecl-geoip-1.0.8-1.fc17 php-pecl-gmagick-1.0.10-0.1.b1.fc17 php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17 php-pecl-lzf-1.5.2-9.fc17 php-pecl-mailparse-2.1.5-6.fc17 php-pecl-imagick-3.1.0-0.1.RC1.fc17 php-pecl-memcache-3.0.6-3.fc17 php-pecl-memcached-2.0.0-0.1.git1736623.fc17 php-pecl-mongo-1.2.7-1.fc17 php-pecl-ncurses-1.0.1-5.fc17 php-pecl-oauth-1.2.2-3.fc17 php-pecl-radius-1.2.5-13.fc17 php-pecl-rrd-1.0.5-3.fc17 php-pecl-selinux-0.3.1-8.fc17 php-pecl-solr-1.0.2-3.fc17 php-pecl-sphinx-1.1.0-3.fc17 php-pecl-ssh2-0.11.3-1.fc17 php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 php-pecl-yaml-1.0.1-6.fc17 php-shout-0.9.2-10.fc17 syck-0.61-16.fc17 uuid-1.6.2-8.fc17 zarafa-7.0.4-2.fc17 zorba-2.1.0-3.fc17 Pending ice (owner will take care of it) maniadrive (tomorrow...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package categorization and distribution construction
Bill Nottingham wrote: > These could be separate groups, (i.e., XFCE's 'Office Suite' group may not > have LibreOffice). So there would be the ability to customize that. Yes, that makes sense. Right now, if you enable "Sound and Video", you get Totem forced in (and with it, plenty of GNOME dependencies such as Tracker) even if you chose only the KDE Plasma Workspaces instead of GNOME. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Adam Williamson wrote: > Would it make sense just to put the hicolor directory into filesystem? > It seems silly to have every single graphical app in the distro depend > on a package simply for the provision of the directory... There are also all the subdirectories such as /usr/share/icons/hicolor/24x24/apps/. And the whole purpose of hicolor-icon-theme is to include those directories and the index.theme file. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[SPAM] Re: Rawhide tree structure
On Fri, 20 Jan 2012 11:44:54 -0600 Mike Chambers wrote: > Did my eyes deceive me, or do the packages now get separated and put > in their respected dir of their first letter, and not located in one > dir now? Did the tree change or is this an error? > This did happen and it is not an error. It was an intentional change since many web browsers and web servers do not cope well with 17K entries in a single directory. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree structure
> "MC" == Mike Chambers writes: MC> Did my eyes deceive me, or do the packages now get separated and put MC> in their respected dir of their first letter, and not located in one MC> dir now? Yes. MC> Did the tree change or is this an error? The tree changed. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 05:55 PM, Emmanuel Seyman wrote: * Ralf Corsepius [20/01/2012 15:25] : ... and why no simply keep these BZs "open" and/or to add a note Because the bug isn't open. Surely the bug is open: The product you are supposed to be responsible for (A Fedora package) suffers from an unfixed bug, documented in bugzilla. > There's nothing more to do on it in its present > state Surely, there are things to be done. - Others might be able to fix it. - You can cross check if its fixed in the next upstream release > and having it show up in lists of open bugs is > counter-productive This logic escapes me - A reporter has reported a bug in your package and has are informed you about, so you know about it. All you are doing by closing is to switch off a semi-automated checklist you'd better off checking your package for (== QA) when modifying/updating it. Yes, this means effort, but it should be part of a packager's QA routine. People not doing so work careless. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide tree structure
Did my eyes deceive me, or do the packages now get separated and put in their respected dir of their first letter, and not located in one dir now? Did the tree change or is this an error? -- Mike Chambers Madisonville, KY "Best little town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please review: Remove redundant code - make a global into a static
Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 11:24 -0500, Bill Nottingham wrote: > Stephen Gallagher (sgall...@redhat.com) said: > > Essentially, when closing this bug as UPSTREAM, we are communicating to > > our users "This will get fixed. Probably. And it will get pulled into > > Fedora eventually. Probably." Most people, when they can actually be > > convinced to file a real bug report (even through ABRT), are doing so > > because they have an issue with the software and want to know when it's > > fixed. > > > > Closing things upstream requires that the reporters (who already likely > > had to be coaxed to file a bug in the first place) now also have to > > manually choose to go and create an account on an unrelated bug tracker > > if they want to follow along on the resolution of the issue. > > In some cases, this *is* the most appropriate resolution, though. For > example, I get the occasional RFE, or request for a behavior/appearance > change, or even for some bugfix that requires rewriting an entire subsystem > of a package. > > In that case, I will likely open up a bug upstream, and close the Fedora > bug, because it is really not up to me at all when, or *if*, such a bug gets > fixed; as a downstream maintainer, I'm not going to put changes of that sort > into Fedora alone, and upstream may very well decide not to do it. > > For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see > why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer > CLOSED->WONTFIX, as I'm not fixing that myself...) I'm suggesting that I'd prefer opening the bug upstream, setting this bug to ASSIGNED and then waiting to see what happens upstream. If upstream says they won't fix it, close it WONTFIX. If upstream is going to fix it, leave it open until a Fedora package is available that does fix it, then you can list it in the Bodhi update. 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: Package categorization and distribution construction
On Thu, Jan 19, 2012 at 11:48:38AM -0500, Przemek Klosowski wrote: > On 01/19/2012 10:43 AM, Richard W.M. Jones wrote: > > >I wrote a little graphical tool called rpmdepsize (it's in Fedora) > >which may be useful. Unfortunately it only works with a single > >package, eg: > > > > rpmdepsize kernel > > Interesting--but I tried it on my F15 box and it froze. I tried > 'rpdepsize kernel' and on a very simple (no deps) package 'setup': > it prints an error: > > (rpmdepsize:18625): LablGTK-CRITICAL **: GSourceFunc: callback > raised an exception > > and just sits there with gray screen and message 'Loading kernel ...' It runs 'yum' at this point, so it's likely that yum is just being slow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Remove redundant code - make a global into a static
From 1ddcc951eec9ede74ae6650de04a921198aec493 Mon Sep 17 00:00:00 2001 From: Rich Megginson Date: Fri, 20 Jan 2012 09:52:33 -0700 Subject: [PATCH] Remove redundant code - make a global into a static Remove redundant code - make a global into a static --- ldap/servers/plugins/linkedattrs/fixup_task.c |7 --- ldap/servers/plugins/usn/usn.c|2 +- 2 files changed, 1 insertions(+), 8 deletions(-) diff --git a/ldap/servers/plugins/linkedattrs/fixup_task.c b/ldap/servers/plugins/linkedattrs/fixup_task.c index b1c29d3..a698a6c 100644 --- a/ldap/servers/plugins/linkedattrs/fixup_task.c +++ b/ldap/servers/plugins/linkedattrs/fixup_task.c @@ -77,13 +77,6 @@ linked_attrs_fixup_task_add(Slapi_PBlock *pb, Slapi_Entry *e, goto out; } - /* make sure the plugin is not closed */ - if(!linked_attrs_is_started()){ - *returncode = LDAP_OPERATIONS_ERROR; - rv = SLAPI_DSE_CALLBACK_ERROR; - goto out; - } - /* get arg(s) */ linkdn = fetch_attr(e, "linkdn", 0); diff --git a/ldap/servers/plugins/usn/usn.c b/ldap/servers/plugins/usn/usn.c index dbae1d5..faa737c 100644 --- a/ldap/servers/plugins/usn/usn.c +++ b/ldap/servers/plugins/usn/usn.c @@ -68,7 +68,7 @@ static int usn_get_attr(Slapi_PBlock *pb, const char* type, void *value); static int usn_rootdse_search(Slapi_PBlock *pb, Slapi_Entry* e, Slapi_Entry* entryAfter, int *returncode, char *returntext, void *arg); -int g_plugin_started = 0; +static int g_plugin_started = 0; /* * Register USN plugin * Note: USN counter initialization is done in the backend (ldbm_usn_init). -- 1.7.1 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
* Ralf Corsepius [20/01/2012 15:25] : > > ... and why no simply keep these BZs "open" and/or to add a note Because the bug isn't open. There's nothing more to do on it in its present state and having it show up in lists of open bugs is counter-productive. > This would at least reflect the actual situation in Fedora: > Bug is still present. Just like every open bug in upstream's bugtracker that hasn't been reported in brc. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20/01/12 16:24, Bill Nottingham wrote: In that case, I will likely open up a bug upstream, and close the Fedora bug, because it is really not up to me at all when, or *if*, such a bug gets fixed; as a downstream maintainer, I'm not going to put changes of that sort into Fedora alone, and upstream may very well decide not to do it. For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer CLOSED->WONTFIX, as I'm not fixing that myself...) Bill Maybe Just comment: //* Standard Comment */ bug #123 some.external.place has been opened, Please keep an eye on that bug for progress. Closing this bug CLOSED->UPSTREAM I believe you can look at external trackers, without having to sign up. I just tested with KDE, which is not installed. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
Stephen Gallagher (sgall...@redhat.com) said: > Essentially, when closing this bug as UPSTREAM, we are communicating to > our users "This will get fixed. Probably. And it will get pulled into > Fedora eventually. Probably." Most people, when they can actually be > convinced to file a real bug report (even through ABRT), are doing so > because they have an issue with the software and want to know when it's > fixed. > > Closing things upstream requires that the reporters (who already likely > had to be coaxed to file a bug in the first place) now also have to > manually choose to go and create an account on an unrelated bug tracker > if they want to follow along on the resolution of the issue. In some cases, this *is* the most appropriate resolution, though. For example, I get the occasional RFE, or request for a behavior/appearance change, or even for some bugfix that requires rewriting an entire subsystem of a package. In that case, I will likely open up a bug upstream, and close the Fedora bug, because it is really not up to me at all when, or *if*, such a bug gets fixed; as a downstream maintainer, I'm not going to put changes of that sort into Fedora alone, and upstream may very well decide not to do it. For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer CLOSED->WONTFIX, as I'm not fixing that myself...) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 19 January 2012 23:23, David Tardon wrote: > On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote: >> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: >> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: >> > > Kevin Fenzi wrote: >> > > > Keeping packages around with no maintainers or people handling their >> > > > bugs is poor for everyone. >> > > >> > > Why? If I, as a user, really need a certain piece of software, I'd rather >> > > have an unmaintained package than none at all! Worst case, I can't use >> > > the >> > > package at all, in which case I'm still no worse off than with no >> > > package at >> > > all! >> > >> > I disagree. The existence of a package triggers certain assumptions: the >> > package will be maintained and keep working. That's the point of there >> > *being* a package, after all. So if there's a package for something, I >> > don't check for security updates for that 'something' myself. I figure >> > the packager is doing that for me. >> > >> > So if I wind up with an unmaintained package installed, my security has >> > just been reduced. >> > >> >> Yes, I agree with this completely. If something is not being maintained >> in Fedora, it's better to retire it. Then a user who wants that piece of >> software will have two options: >> 1) They can build it and maintain it themselves on their own system(s) >> 2) They can choose to build and maintain it for Fedora by unretiring it. > > 3) They can choose another distro that contains the package(s). > That is not a bad thing though. A) The user will be happier because they have support B) Our developers will be happier because they can focus on what they want to work on C) That distros developers will be happier because they have enough users that want what they are producing. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 781402] perl-POE-Component-Client-HTTP-0.944 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=781402 Petr Šabata changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-Component-Client-H ||TTP-0.944-1.fc17 Resolution||RAWHIDE Last Closed||2012-01-20 10:51:31 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Retire rubygem-mongrel
On Fri, Jan 20, 2012 at 09:27, Vít Ondruch wrote: > Hi, > > If nobody objects, I am going to retire *rubygem-mongrel* and its > associated gems rubygem-gem_plugin, rubygem-fastthread and > rubygem-mongrel_cluster. > > Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3 > available in Fedora, the last supported Ruby on Rails version was 2.3.7. > There are available more viable Ruby web servers such as rubygem-thin. I > believe nobody will regret this loss. > > I believe the rubygem-passenger package that is being worked on for inclusion in fedora still requires rubygem-fastthread. https://bugzilla.redhat.com/show_bug.cgi?id=470696 -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-POE-Component-Client-HTTP] 0.944 bump
commit 1d961c830b2c6c7da38cc36d9fc032e14acb7cde Author: Petr Šabata Date: Fri Jan 20 16:36:06 2012 +0100 0.944 bump .gitignore |1 + perl-POE-Component-Client-HTTP.spec | 101 -- sources |2 +- 3 files changed, 50 insertions(+), 54 deletions(-) --- diff --git a/.gitignore b/.gitignore index 9c63dd0..6844628 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ POE-Component-Client-HTTP-0.895.tar.gz +/POE-Component-Client-HTTP-0.944.tar.gz diff --git a/perl-POE-Component-Client-HTTP.spec b/perl-POE-Component-Client-HTTP.spec index a0ffb21..a15e72e 100644 --- a/perl-POE-Component-Client-HTTP.spec +++ b/perl-POE-Component-Client-HTTP.spec @@ -5,58 +5,65 @@ # rpmbuild ... --define '_with_network_tests 1' ... # rpmbuild ... --with network_tests ... # define _with_network_tests 1 in your ~/.rpmmacros -# -# Note that right now, the only way to run tests locally from a cvs sandbox -# "make noarch" type scenario is the third one. Name: perl-POE-Component-Client-HTTP -Version:0.895 -Release:5%{?dist} +Version:0.944 +Release:1%{?dist} Summary:A non-blocking/parallel web requests engine for POE - Group: Development/Libraries License:GPL+ or Artistic URL:http://search.cpan.org/dist/POE-Component-Client-HTTP Source0: http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-HTTP-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - BuildArch: noarch +BuildRequires: perl(base) +BuildRequires: perl(constant) +BuildRequires: perl(Carp) +BuildRequires: perl(Data::Dumper) BuildRequires: perl(ExtUtils::MakeMaker) -# Original perl(POE) >= 1.28 rounded to 3 digit precision -BuildRequires: perl(POE) >= 1.280 -BuildRequires: perl(HTTP::Request) >= 1.3 -BuildRequires: perl(HTTP::Response) >= 1.37 -BuildRequires: perl(URI) >= 1.24 -# Original perl(POE::Component::Client::Keepalive) >= 0.261 rounded to +BuildRequires: perl(HTTP::Headers) >= 5.810 +BuildRequires: perl(HTTP::Request) >= 5.811 +BuildRequires: perl(HTTP::Request::Common) >= 5.811 +BuildRequires: perl(HTTP::Response) >= 5.813 +BuildRequires: perl(HTTP::Status) >= 5.811 +BuildRequires: perl(IO::File) +BuildRequires: perl(IO::Handle) +BuildRequires: perl(IO::Socket::INET) +BuildRequires: perl(Net::HTTP::Methods) >= 5.812 +BuildRequires: perl(POE) >= 1.312 +# Original perl(POE::Component::Client::Keepalive) >= 0.268 rounded to # 4 digit precision -BuildRequires: perl(POE::Component::Client::Keepalive) >= 0.2610 - -# tests... +BuildRequires: perl(POE::Component::Client::Keepalive) >= 0.2680 +BuildRequires: perl(POE::Driver::SysRW) +BuildRequires: perl(POE::Filter) +BuildRequires: perl(POE::Filter::HTTPChunk) +BuildRequires: perl(POE::Filter::HTTPHead) +BuildRequires: perl(POE::Filter::Line) +BuildRequires: perl(POE::Filter::Stackable) +BuildRequires: perl(POE::Filter::Stream) +BuildRequires: perl(POE::Session) +BuildRequires: perl(Scalar::Util) +BuildRequires: perl(Socket) +BuildRequires: perl(Socket::GetAddrInfo) >= 0.19 +BuildRequires: perl(URI) >= 1.37 BuildRequires: perl(Test::Pod) BuildRequires: perl(Test::Pod::Coverage) -BuildRequires: perl(Test::More) - -# use base... -Requires: perl(POE::Filter), perl(POE::Filter::Stackable) -# use POE qw{ ... } -# Original perl(POE::Component::Client::Keepalive) >= 0.261 rounded to +BuildRequires: perl(Test::POE::Server::TCP) >= 1.14 +BuildRequires: perl(Test::More) > 0.96 +BuildRequires: perl(Time::HiRes) +Requires: perl(HTTP::Headers) >= 5.810 +Requires: perl(HTTP::Request) >= 5.811 +Requires: perl(HTTP::Request::Common) >= 5.811 +Requires: perl(HTTP::Response) >= 5.813 +Requires: perl(HTTP::Status) >= 5.811 +Requires: perl(Net::HTTP::Methods) >= 5.812 +Requires: perl(POE) >= 1.312 +# Original perl(POE::Component::Client::Keepalive) >= 0.268 rounded to # 4 digit precision -Requires: perl(POE::Component::Client::Keepalive) >= 0.2610 - +Requires: perl(POE::Component::Client::Keepalive) >= 0.2680 +Requires: perl(Socket::GetAddrInfo) >= 0.19 +Requires: perl(URI) >= 1.37 Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) -### auto-added brs! -BuildRequires: perl(Test::POE::Server::TCP) -BuildRequires: perl(Net::HTTP::Methods) >= 0.02 - -### auto-added reqs! -Requires: perl(HTTP::Request) >= 1.3 -Requires: perl(HTTP::Response) >= 1.37 -Requires: perl(Net::HTTP::Methods) >= 0.02 -# Original perl(POE) >= 1.28 rounded to 3 digit precision -Requires: perl(POE) >= 1.280 -Requires: perl(URI) >= 1.24 - %{?perl_default_filter} %description @@ -64,50 +71,38 @@ POE::Component::Client::HTTP is an HTTP user-agent for POE. It lets other sessions run while HTTP transactions are being processed,
File POE-Component-Client-HTTP-0.944.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Component-Client-HTTP: 79697fe8bf93bcc85ca7b32a94ca5906 POE-Component-Client-HTTP-0.944.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-URI] Created tag perl-URI-1.59-3.fc17
The lightweight tag 'perl-URI-1.59-3.fc17' was created pointing to: 5d64e5c... Spec clean-up -- 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
Retire rubygem-mongrel
Hi, If nobody objects, I am going to retire *rubygem-mongrel* and its associated gems rubygem-gem_plugin, rubygem-fastthread and rubygem-mongrel_cluster. Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3 available in Fedora, the last supported Ruby on Rails version was 2.3.7. There are available more viable Ruby web servers such as rubygem-thin. I believe nobody will regret this loss. Vit [1] https://github.com/evan/mongrel/commit/12a06f658a5645e8ad0fa41c488a6f4a6508d740 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20.1.2012 13:20, Stephen Gallagher wrote: That's a fantastic idea, and probably an ideal solution. Unfortunately, we're also talking about a minimum of several months' work to get that in place, just on the engineering side. Not including the deployment testing period. Sure. Just to note that the email (and bugs) is old couple of years. * BugZappers more or less failed to do any meaningful change in the state of our Bugzilla (that's to the large part my failure, but that's how it is) and there is just too few of them, I'm not sure about what you meant here. That what you want from package maintainers is basically to do manually what I have described above. Which is fine for a component with five bugs, but for components like kernel, Firefox, or some of major Gnome components with hundreds of open bugs (on the top of other problems components infested with ABRT bugs), it means hundreds of hours of work (I know what I am talking about, I was doing this work for couple of years). We hoped that those hundreds of hours could be provided by BugZappers, but it didn't happen. Also, should developers spend those hours on cleaning bugzilla so that you will be happy, or should they work on fixing bugs? It is not popular to say, but bugzilla is here not for users, but it is primarily tool for developers to organize their work. And frankly, if developers find it useless, too bad for anybody else. Just saying. Matěj ... the rest of this thread goes to /dev/null for me, except of questions which I can in my opinion usefully comment on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: An Easy But Serious Screensaver Security Problem In X.Org
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote: > Hopefully this is being addressed: > > http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0064 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-URI] Spec clean-up
commit 5d64e5c56aace0d3158fd4777601c3316f168169 Author: Paul Howarth Date: Fri Jan 20 14:22:57 2012 + Spec clean-up - Break build dependency loop by only using perl(Business::ISBN) if we're not bootstrapping - BR: perl(Carp) and perl(Exporter) - Make %files list more explicit - Use DESTDIR rather than PERL_INSTALL_ROOT - Use %{_fixperms} macro rather than our own chmod incantation - Don't use macros for commands .gitignore|6 +- perl-URI.spec | 53 +++-- 2 files changed, 36 insertions(+), 23 deletions(-) --- diff --git a/.gitignore b/.gitignore index 4d3f096..796820b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1 @@ -URI-1.54.tar.gz -/URI-1.55.tar.gz -/URI-1.56.tar.gz -/URI-1.58.tar.gz -/URI-1.59.tar.gz +/URI-[0-9.]*.tar.gz diff --git a/perl-URI.spec b/perl-URI.spec index 6d9c5e2..e57ad86 100644 --- a/perl-URI.spec +++ b/perl-URI.spec @@ -1,54 +1,71 @@ Name: perl-URI Version:1.59 -Release:2%{?dist} +Release:3%{?dist} Summary:A Perl module implementing URI parsing and manipulation - Group: Development/Libraries License:GPL+ or Artistic URL:http://search.cpan.org/dist/URI/ Source0:http://www.cpan.org/authors/id/G/GA/GAAS/URI-%{version}.tar.gz - BuildArch: noarch -BuildRequires: perl(MIME::Base64) +BuildRequires: perl(Carp) +BuildRequires: perl(Exporter) BuildRequires: perl(ExtUtils::MakeMaker) +BuildRequires: perl(MIME::Base64) BuildRequires: perl(Test::More) +# Business::ISBN -> Test::Pod -> Pod::Simple -> HTML::Entities (HTML::Parser) -> URI +%if 0%{!?perl_bootstrap:1} BuildRequires: perl(Business::ISBN) -Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) - +%endif +Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) %description This module implements the URI class. Objects of this class represent "Uniform Resource Identifier references" as specified in RFC 2396 (and updated by RFC 2732). - %prep %setup -q -n URI-%{version} chmod 644 uri-test %build -%{__perl} Makefile.PL INSTALLDIRS=perl +perl Makefile.PL INSTALLDIRS=perl make %{?_smp_mflags} - %install -make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT -find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' -find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';' -chmod -R u+w $RPM_BUILD_ROOT/* - +make pure_install DESTDIR=%{buildroot} +find %{buildroot} -type f -name .packlist -exec rm -f {} ';' +find %{buildroot} -type d -depth -exec rmdir {} ';' 2>/dev/null +%{_fixperms} %{buildroot} %check make test - %files %doc Changes README uri-test -%{perl_privlib}/URI* -%{_mandir}/man3/*.3* - +%{perl_privlib}/URI.pm +%{perl_privlib}/URI/ +%{_mandir}/man3/URI.3pm* +%{_mandir}/man3/URI::Escape.3pm* +%{_mandir}/man3/URI::Heuristic.3pm* +%{_mandir}/man3/URI::QueryParam.3pm* +%{_mandir}/man3/URI::Split.3pm* +%{_mandir}/man3/URI::URL.3pm* +%{_mandir}/man3/URI::WithBase.3pm* +%{_mandir}/man3/URI::_punycode.3pm* +%{_mandir}/man3/URI::data.3pm* +%{_mandir}/man3/URI::file.3pm* +%{_mandir}/man3/URI::ldap.3pm* %changelog +* Fri Jan 20 2012 Paul Howarth - 1.59-3 +- Break build dependency loop by only using perl(Business::ISBN) if we're not + bootstrapping +- BR: perl(Carp) and perl(Exporter) +- Make %%files list more explicit +- Use DESTDIR rather than PERL_INSTALL_ROOT +- Use %%{_fixperms} macro rather than our own chmod incantation +- Don't use macros for commands + * Fri Jan 13 2012 Fedora Release Engineering - 1.59-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
An Easy But Serious Screensaver Security Problem In X.Org
Hopefully this is being addressed: http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On 01/04/2012 10:36 AM, Michal Hlavinka wrote: On 01/03/2012 05:21 PM, Sérgio Basto wrote: I agree, at least for non-gnome users , tracker shouldn't be in autostart. https://bugzilla.redhat.com/show_bug.cgi?id=771601 Thank you Michal for opening a bug. I should learn from you: less complaining, more work towards achieving actual improvement... -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 20 Jan 2012 07:20:20 -0500 Stephen Gallagher wrote: > Well, the proposal I'm making is the one that I've been following > personally in my own projects, which I feel is providing better > service to my users. Speaking as a (mostly) user: I agree with this statement. I would rather have the bugs kept in the open state until a package with the fix is released, so that I can see when they are fixed in Fedora. Since I am not a package maintainer, I cannot estimate the impact of such a policy on the workload of those busy people. I can live with the current status quo. Just my EUR 0.02, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
kexec-tools: sync with the latest upstream release
Hi, Neil and others, I plan to sync kexec-tools and makedumpfile with upstream release, IOW, move kexec-tools to 2.0.3 and makedumpfile to 1.4.1, for Fedora 17. Do you have any objections? Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 02:04 PM, Jaroslav Reznik wrote: - Original Message - On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: We already had this discussion, I don't recall exactly - two years ago and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. I can try to find it :) As it's usually used this way - bug is reported to upstream (by reporter, us in case he does not have account or is not willing to do it), then the bug can bounce between Fedora/upstream (you know, everyone has to blame other side or sometimes it's not easy to say who to blame ;-). And the bug is actually not fixed in Fedora until we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. The biggest problem here is just - some people misuse this CLOSED UPSTREAM as we don't care in Fedora. And they would use another CLOSED resolution to close the bug :) ... and why no simply keep these BZs "open" and/or to add a note "Reported upstream" and keep abrt open to receive more of them (This would at least provide an indicator for the severity of a bug)? This would at least reflect the actual situation in Fedora: Bug is still present. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 08:04 -0500, Jaroslav Reznik wrote: > - Original Message - > > On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: > > > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: > > > > I use closed/upstream, when I already fixed it in upstream. This > > > > bug > > > > should be closed with number of release, where it is fixed or > > > > with the > > > > link to the commit. I wouldn't blame this state for not fixing > > > > bug in > > > > some projects. I guess instead of closed/upstream we would see > > > > more > > > > closed/wontfix|cantfix. > > > > > > I use POST for that. > > > > > > "A patch or solution believed to resolve this matter has been > > > proposed > > > (POSTed) for inclusion in the package or kernel." > > > > > > For non-kernel packages I read that as meaning that the patch is > > > in-hand > > > upstream, and not yet built in Fedora. > > > > > > That's certainly one reasonable approach to this specific case, > > provided > > that we > > A) Document this interpretation more clearly. > > B) Comment in the bug that the patch is committed upstream and will > > be > > available when the equivalent upstream release arrives. > > We already had this discussion, I don't recall exactly - two years ago > and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. > I can try to find it :) As it's usually used this way - bug is reported > to upstream (by reporter, us in case he does not have account or is not > willing to do it), then the bug can bounce between Fedora/upstream (you > know, everyone has to blame other side or sometimes it's not easy to > say who to blame ;-). And the bug is actually not fixed in Fedora until > we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. > > The biggest problem here is just - some people misuse this CLOSED UPSTREAM > as we don't care in Fedora. And they would use another CLOSED resolution > to close the bug :) A bigger problem would be that this claimed approach is not documented anywhere that anyone could find (short of digging through old mailing list archives). It seems to me that what we're looking at here is more of "NEEDSINFO: upstream" than any kind of CLOSED status. I think the bug should stay open as ASSIGNED and that the maintainer should be responsible for occasionally reporting back progress made on the upstream bug. 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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
- Original Message - > On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: > > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: > > > I use closed/upstream, when I already fixed it in upstream. This > > > bug > > > should be closed with number of release, where it is fixed or > > > with the > > > link to the commit. I wouldn't blame this state for not fixing > > > bug in > > > some projects. I guess instead of closed/upstream we would see > > > more > > > closed/wontfix|cantfix. > > > > I use POST for that. > > > > "A patch or solution believed to resolve this matter has been > > proposed > > (POSTed) for inclusion in the package or kernel." > > > > For non-kernel packages I read that as meaning that the patch is > > in-hand > > upstream, and not yet built in Fedora. > > > That's certainly one reasonable approach to this specific case, > provided > that we > A) Document this interpretation more clearly. > B) Comment in the bug that the patch is committed upstream and will > be > available when the equivalent upstream release arrives. We already had this discussion, I don't recall exactly - two years ago and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. I can try to find it :) As it's usually used this way - bug is reported to upstream (by reporter, us in case he does not have account or is not willing to do it), then the bug can bounce between Fedora/upstream (you know, everyone has to blame other side or sometimes it's not easy to say who to blame ;-). And the bug is actually not fixed in Fedora until we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. The biggest problem here is just - some people misuse this CLOSED UPSTREAM as we don't care in Fedora. And they would use another CLOSED resolution to close the bug :) R. > > I still think that the more ideal solution though is to keep the bug > open until a package actually hits Fedora with that fix in it (be it > an > updated version or a cherry-picked patch). This way it's clear to the > user exactly when they can expect a fix. > > Bonus: it tells users when a Bodhi update is available that will > address > their issue. This encourages more users to test. I've certainly > noticed > a marked increase in bodhi karma activity on my updates that have > more > bugs marked as addressed vs. those updates that just pull in a new > upstream version without any Fedora-specific bugs reported. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: > > I use closed/upstream, when I already fixed it in upstream. This bug > > should be closed with number of release, where it is fixed or with the > > link to the commit. I wouldn't blame this state for not fixing bug in > > some projects. I guess instead of closed/upstream we would see more > > closed/wontfix|cantfix. > > I use POST for that. > > "A patch or solution believed to resolve this matter has been proposed > (POSTed) for inclusion in the package or kernel." > > For non-kernel packages I read that as meaning that the patch is in-hand > upstream, and not yet built in Fedora. That's certainly one reasonable approach to this specific case, provided that we A) Document this interpretation more clearly. B) Comment in the bug that the patch is committed upstream and will be available when the equivalent upstream release arrives. I still think that the more ideal solution though is to keep the bug open until a package actually hits Fedora with that fix in it (be it an updated version or a cherry-picked patch). This way it's clear to the user exactly when they can expect a fix. Bonus: it tells users when a Bodhi update is available that will address their issue. This encourages more users to test. I've certainly noticed a marked increase in bodhi karma activity on my updates that have more bugs marked as addressed vs. those updates that just pull in a new upstream version without any Fedora-specific bugs reported. 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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:17 +0100, Matej Cepl wrote: > On 20.1.2012 00:31, Stephen Gallagher wrote: > > Currently, the official bug lifecycle includes the following phrase: > > "The resolution UPSTREAM can be used by maintainers to denote a bug that > > they expect to be fixed by upstream development and naturally rolled > > back into Fedora as part of the update process. Ideally, a comment > > should be added with a link to the upstream bug report." > > > > I've seen quite a few bugs lately closed with this resolution (mostly in > > the Evolution and GNOME projects for me personally). It seems to me that > > this is terribly useless in terms of informing users when their bugs are > > fixed. > > You are completely right, except: > > * since I wrote > http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody > did anything on numerous Bugzilla bugs like > https://bugzilla.mozilla.org/show_bug.cgi?id=123130, > https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know > about any Perl hacker who would be willing to help, these bugs could be > a good place to start, That's a fantastic idea, and probably an ideal solution. Unfortunately, we're also talking about a minimum of several months' work to get that in place, just on the engineering side. Not including the deployment testing period. > * BugZappers more or less failed to do any meaningful change in the > state of our Bugzilla (that's to the large part my failure, but that's > how it is) and there is just too few of them, I'm not sure about what you meant here. > * this really sounds like proverbial "somebody else should do > something" ... Well, the proposal I'm making is the one that I've been following personally in my own projects, which I feel is providing better service to my users. I agree that if we had the solution you propose above available, that would meet (or exceed) the same need. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120120 changes
Compose started at Fri Jan 20 08:15:13 UTC 2012 Broken deps for x86_64 -- [amsn] amsn-0.98.4-4.fc16.x86_64 requires libgupnp-igd-1.0.so.3()(64bit) [anerley] 1:anerley-0.3.0-7.fc17.i686 requires libcogl.so.6 1:anerley-0.3.0-7.fc17.x86_64 requires libcogl.so.6()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [blender] 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit) [clutter-gtk010] clutter-gtk010-0.11.4-3.fc17.i686 requires libcogl.so.6 clutter-gtk010-0.11.4-3.fc17.x86_64 requires libcogl.so.6()(64bit) [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [compat-gcc-34] compat-gcc-34-c++-3.4.6-23.fc17.x86_64 requires libstdc++ < 0:4.7.0 [compiz] compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.i686 requires libboost_serialization-mt.so.1.47.0 compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-gtk-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-kde-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-fusion-extras] compiz-fusion-extras-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-fusion-unsupported] compiz-fusion-unsupported-0.9.4-6.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-plugins-main] compiz-plugins-main-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [curry] curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [ease] ease-0.4-14.fc17.i686 requires libcogl.so.6 ease-0.4-14.fc17.x86_64 requires libcogl.so.6()(64bit) [ember] ember-0.6.2-2.fc17.x86_64 requires ember-media = 0:0.6.2 [emerillon] emerillon-0.1.90-5.fc17.x86_64 requires libcogl.so.6()(64bit) [eog-plugins] eog-plugins-3.2.2-3.fc17.x86_64 requires libcogl.so.6()(64bit) [frysk] frysk-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit) frysk-devel-0.4-32.fc17.i386 requires libvtejava-0.12.so frysk-devel-0.4-32.fc17.i386 requires libgtkjava-2.10.so frysk-devel-0.4-32.fc17.i386 requires libglibjava-0.4.so frysk-devel-0.4-32.fc17.i386 requires libgladejava-2.12.so frysk-devel-0.4-32.fc17.i386 requires libgcj.so.12 frysk-devel-0.4-32.fc17.i386 requires libcairojava-1.0.so frysk-devel-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgtkjava-2.10.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libglibjava-0.4.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgladejava-2.12.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libcairojava-1.0.so()(64bit) frysk-gnome-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit) frysk-gnome-0.4-32.fc17.x86_64 requires libvte-java >= 0:0.12.0 frysk-gnome-0.4-32.fc17.x86_64 requires libgtkjava-2.10.so()(64bi
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: > I use closed/upstream, when I already fixed it in upstream. This bug > should be closed with number of release, where it is fixed or with the > link to the commit. I wouldn't blame this state for not fixing bug in > some projects. I guess instead of closed/upstream we would see more > closed/wontfix|cantfix. I use POST for that. "A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel." For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. Tim. */ 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: Changes coming for CUPS 1.6
On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote: > What a great idea! We could call one of them 'Postscript'... Not likely. :-) I think the current candidate for the optional vector format is PDF 1.4/1.5. Tim. */ 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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 08:39 AM, Marcela Mašláňová wrote: On 01/20/2012 12:31 AM, Stephen Gallagher wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. Users do! To them, what you are doing is to "ignore them for now" and to "sit-out bugs", instead. Whether they will find this tolerable or consider you to be a non-collaborations jerk widely depend on the actual impact the bug they reported has on them. > I guess instead of closed/upstream we would see more closed/wontfix|cantfix. Delegating bugs for fixing to upstream, because you can't fix for whatever reasons isn't much of a problem. The problem is the attitude "CLOSED UPSTEAM" communicates: Cheating about the current shape a package is in Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20.1.2012 00:31, Stephen Gallagher wrote: Currently, the official bug lifecycle includes the following phrase: "The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report." I've seen quite a few bugs lately closed with this resolution (mostly in the Evolution and GNOME projects for me personally). It seems to me that this is terribly useless in terms of informing users when their bugs are fixed. You are completely right, except: * since I wrote http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody did anything on numerous Bugzilla bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=123130, https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know about any Perl hacker who would be willing to help, these bugs could be a good place to start, * BugZappers more or less failed to do any meaningful change in the state of our Bugzilla (that's to the large part my failure, but that's how it is) and there is just too few of them, * this really sounds like proverbial "somebody else should do something" ... Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel