Re: Auto-expiring bugs are getting absurd
On Thu, 2014-02-06 at 13:21 +0100, Michael Schwendt wrote: > Has that been tried before? It sounds like a better approach. Not while I've been around, at least. > Where is the human to notice "comments after EOL" and act accordingly? There are always a minimum of two people active on any ticket who can change it in any way: the reporter and the assignee. > How many tickets would be affected by a "comment after EOL"? Don't know, probably wouldn't be too hard to look. > What is the underlying problem here anyway? I've never been hugely convinced there is one, but the problem people *claim* there is is that closing bugs on EOL releases gives a bad impression to people who report the bugs. > Too many unhandled tickets -> EOL auto-close threatening -> too many > closed tickets to handle -> how to escape from that loop? > > In several large upstream bug trackers it is no different. Are developers > always informed about what doesn't work even when not responding to > tickets? Why should users still take the time to submit problem reports > if they don't get a response? Why do you think they're any more likely to get a response if the bug stays open? > > algorithms are never perfect, but we do have to use them, as a > > perennially under-resourced project. > > I've posted about it in 2008 already, and I still think the auto-closing > leads to hiding crap under the carpet. We already don't have enough time to look after all the open bugs we have. Why are things going to be better if we have more? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Adjust wiki for ARM BeagleBone Black
That's not necessary abcboard is not used and has been removed from newer uboot builds uEnv.text files. Dennis On February 7, 2014 3:13:27 AM CET, Marcelo Barbosa wrote: >Peter, > > Changed in this part: > >Change one option in this file(only BeagleBone Black): > >vi /run/media/$USER/uboot/uEnv.txt >abcboard=am335x-bone > abcboard=am335x-boneblack > >Added. > >firemanxbr > > >On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson >wrote: > >> >I adjusted this documentation in wiki: >> > >> >https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black >> > >> >Added this important step to create image of Fedora 20 for >BeagleBone >> > Black board. >> >> >> "this important step" being what exactly? >> >> Peter >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel >Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2014 03:23 AM, Ville Skyttä wrote: > A number of packages install files to /etc/rpm in Rawhide; the > proper place for macros.* is /usr/lib/rpm/macros.d for rpm >= 4.11. > And no matter what the location, these files should not be marked > as %config. > ... > s4504kr gnustep-make s4504kr,salimma Fixed in gnustep-make-2.6.6-2 - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS9HwXAAoJEEr1VKujapN6uLcH/RwBJ6BLneiEgtLxPzOAtHwa MwBbO1R3NkOc4HtB03e+YqlewYVbFXZhgQDF5rUYU0SMc/y6Yyh0uHFsvtOtuycj l5cNxMsIG3CiF1xuVeDkDVdWwyFX7UtzbW0MgdzrPvJA22c8s63fmlleED/rzz2V 75PXMhnbGtTwYKRH2rhcFUsFSfVFm6O661S8+jAk+quLLZc/qsA7IbacUFcHBJzV VklCPDp+sx1R50YIcuNBuMzZ4Vj8feQGWZ98nbCETCo4tytZIA74TsN8N90maNHD ZrJrVXsYK5KJOYHSEikRihBlg00pP6e8Hx5Aj2QAupKTQN89nQ6DvzGaOo6hZcU= =UbX4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1062424] CVE-2014-1875 perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister changed: What|Removed |Added CC||mmcal...@redhat.com --- Comment #3 from Murray McAllister --- This issue was assigned CVE-2014-1875: http://seclists.org/oss-sec/2014/q1/272 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6YIHRHbE0q&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] CVE-2014-1875 perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister changed: What|Removed |Added Summary|perl-Capture-Tiny: insecure |CVE-2014-1875 |temporary file usage|perl-Capture-Tiny: insecure ||temporary file usage -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UuFjWRPNVC&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister changed: What|Removed |Added Alias||CVE-2014-1875 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pcgo17n6s4&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: f20, anaconda, net install and video out of range ....
On Mon, 2014-02-03 at 14:28 -0500, Adam Jackson wrote: > > Why would it not install xorg-x11-drv-cirrus when it sees the physical > > card? > > We don't have anything like the kernel's modaliases for X drivers, at > least not exposed in a way anaconda could use. Of course, it's possible to do this. "all" you need is some poor sap to maintain something like this: http://svnweb.mageia.org/soft/ldetect-lst/trunk/lst/pcitable?view=markup I was that poor sap, for a year or two. It was not an enjoyable experience. Yes, I know pciids exists: it's a useful resource if you're the poor sap who has to maintain a list like that, but it doesn't solve everything (it doesn't do the actual driver mapping, for a start). What X does is dumb, and very simple: it basically looks at the manufacturer ID and picks a driver based on that. If you've got a Cirrus card, you're getting cirrus. If you've got an ATI card, you're getting 'ati'. If you've got an NVIDIA card, you're getting nouveau. I think it has a very few quirks and exceptions, but really not many. Even if we 'exposed' X's autodetection stuff, it wouldn't be doing a whole lot of device-by-device distinctions. If some poor sap is willing to spend literally dozens of hours a release painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. Or blacklist cards known not to currently work with their native driver. Or load the correct generation of proprietary driver, if your distribution cares about proprietary drivers. (Or combine the above, like THIS nvidia card needs THIS proprietary driver, THIS one doesn't work right with the proprietary driver so we should use nouveau, and THIS one doesn't work with anything so let's load the fallback driver.) But it's incredibly dull work and the benefit really isn't that _huge_. I feel like my time is probably more productively spent, overall, doing other things. Of course, we're 'just' talking about one case, but once you start building this kind of manual device/driver table, it tends to take on a mind of its own and start multiplying. I'm rather attached to the policy of Just Saying No. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages
On Thu, Feb 6, 2014 at 4:13 AM, Toshio Kuratomi wrote: > npajkovs: Weird, In Dec 2013 he(staff@RH) did an update to ipraf-ng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 970742] Test-File-ShareDir 0.3.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=970742 --- Comment #2 from Ken Dreyer --- Created attachment 860373 --> https://bugzilla.redhat.com/attachment.cgi?id=860373&action=edit Update to Test::File::ShareDir 0.3.3. Hi Iain, Path::Tiny is now in Fedora (bug 1003660). Here's a patch against master/rawhide. F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6503255 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6MlVZn3goS&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Adjust wiki for ARM BeagleBone Black
Peter, Changed in this part: Change one option in this file(only BeagleBone Black): vi /run/media/$USER/uboot/uEnv.txt abcboard=am335x-bone > abcboard=am335x-boneblack Added. firemanxbr On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson wrote: > >I adjusted this documentation in wiki: > > > https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black > > > >Added this important step to create image of Fedora 20 for BeagleBone > > Black board. > > > "this important step" being what exactly? > > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #9 from Fedora Update System --- perl-DBD-SQLite-1.37-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OTXkhIqqlP&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058723] FTBFS: perl-DBD-Pg-2.19.3-5.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058723 --- Comment #4 from Fedora Update System --- perl-DBD-Pg-2.19.3-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=l5Y98n4Btm&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #8 from Fedora Update System --- perl-DBD-SQLite-1.40-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tUSeCoNy2I&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1052853] Unnecessary dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1052853 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Throwable-0.102080-11. |perl-Throwable-0.102080-11. |fc20|fc19 --- Comment #7 from Fedora Update System --- perl-Throwable-0.102080-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4G3eBGQ0qS&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1052853] Unnecessary dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1052853 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Throwable-0.102080-11. ||fc20 Resolution|--- |ERRATA Last Closed||2014-02-06 22:11:47 --- Comment #6 from Fedora Update System --- perl-Throwable-0.102080-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7DBVru3LJE&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058723] FTBFS: perl-DBD-Pg-2.19.3-5.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058723 --- Comment #5 from Fedora Update System --- perl-DBD-Pg-2.19.3-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zRVIWVS3r3&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Request to take over package amavisd-new
Yes please take it. This package on EPEL has permission problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Adjust wiki for ARM BeagleBone Black
>I adjusted this documentation in wiki: > https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black > >Added this important step to create image of Fedora 20 for BeagleBone > Black board. "this important step" being what exactly? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: yum-builddep bash completion
On 02/06/2014 01:42 PM, Michael Schwendt wrote: > Does any packager use yum-builddep bash completion and would like > to explain it to me? > > https://bugzilla.redhat.com/884303 I don't know about that in particular, but one handy trick is to use bash complete-filename (M-/) instead of the general complete (TAB). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
yum-builddep bash completion
Does any packager use yum-builddep bash completion and would like to explain it to me? https://bugzilla.redhat.com/884303 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 11:06:07AM -0700, Kevin Fenzi wrote: > So, all those bugs stay open on the EOL version until EOL+1? > > That seems poor to me. What do we do if someone clears needinfo and > says: Yes, this still affects me, I am running EOL release. Please fix > it. > > We cannot, the EOL release is closed, no more updates or support. > > How does leaving it open there help? It doesn't, but I think the trouble of closing those by hand is overall less than the problem of closing too many bugs > > EOL wouldn't be visibile as an available status for bugzilla > > users to select when closing a bug in the interface, so it does not > > add to UI clutter, but also makes it easy for us to do reports > > distinguishing between intentional and eol closure. > Is this possible? I believe so -- you only make the transition available to the Fedora EOL user account. But because it's bugzilla, this kind of thing may involve writing some Perl, and I'm sympathetic to the bugzilla maintenance team not wanting to deal with that. (That's the main reason for suggesting the second option, of setting a keyword instead.) > > This does risk some false positives (negatives? whatever) where > > NEEDINFO is cleared with "works for me" but the bug not closed, but > > that seems like a less serious problem. > Yeah, thats another issue with this... they would stick around in that > case until the maintainer or someone came in and cleared them. Yes, but see the other message. At the very least, I bet it will be dozens or at worst hundreds, which is a managable amount for people interested in helping with EOL triage. On the other side, we have many thousands of auto-closed bugs right now. And I think that triage work would really only be needed if we end up feeling that we've tilted the balance too far in the direction of making the package maintainers clean up. > > 3. As #1, but just leave bugs in NEEDINFO state forever. > > This would possibly require maintainers to update their searches / > > filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs > > from older releases. > It would also be misleading, IMHO. > "Hey reporter, I need info to fix this" In this case, the message would be something like "We're sorry we weren't able to resolve this bug within the lifespan of Fedora ##. We do appreciate the report, and we may be able to fix it in the next release. Could you please confirm that this is still an issue in the latest release of Fedora? Thank you." With this message, if needinfo is cleared, and then the bug isn't touched for a long time, it would probably be a good candidate for human triage. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request to take over package amavisd-new
On Thu, 06 Feb 2014 22:07:52 +0100, Juan Orti Alcaine wrote: > Hello, > > Last week, I notified the devel list about Steven Pritchard (FAS: steve) been > unresponsive [1], and after many unsuccessful attempts to get bug #695589 > fixed > [2], I request to take over the package amavisd-new. > > Any objection? > > Thank you. > > [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/194940.html > [2] https://bugzilla.redhat.com/show_bug.cgi?id=695589 No objections. There are a couple of packagers where the "non-responsive maintainer procedure" doesn't work well, because after a long period of inactivity the maintainer returns only briefly and temporarily. In some cases that has lead to starting the procedure again after some months. We need more maintainers per package, so if there is interest in the package, that's great IMO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 146 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 110 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 85 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 75 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0400/mediawiki119-1.19.11-2.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0418/libyaml-0.1.2-5.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0410/zarafa-7.1.8-1.el5,php53-mapi-7.1.8-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0433/puppet-2.7.25-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0471/lighttpd-1.4.34-1.el5.1 The following builds have been pushed to Fedora EPEL 5 updates-testing RBTools-0.5.7-1.el5 bind-to-tinydns-0.4.3-5.20140205git32dc9263.el5 lighttpd-1.4.34-1.el5.1 Details about builds: RBTools-0.5.7-1.el5 (FEDORA-EPEL-2014-0459) Tools for use with ReviewBoard Update Information: Bugfixes primarily for Perforce integration http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. ChangeLog: * Wed Feb 5 2014 Stephen Gallagher 0.5.7-1 - New upstream release 0.5.7 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.7/ - New upstream release 0.5.6 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.6/ * Wed Jan 15 2014 Stephen Gallagher 0.5.5-1 - New upstream release 0.5.5 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ - New upstream release 0.5.4 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ - Deprecation: * post-review is deprecated (and has been for a while). It now shows a deprecation warning in order to remind me to use rbt post. - Bug Fixes: * rbt patch: * rbt patch no longer fails to commit on Git if there are untracked files. * Fixed committing changes when the description has unicode characters. * Fixed compatibility with Review Board 2.0 beta. * rbt post: * Fixed R1:R2 syntax for --revision-range for Git repositories. * Fixed name-based lookups for repositories with Subversion. * rbt setup-repo: * Fixed error output when failing to write the .reviewboardrc file. * post-review: * Added --svn-show-copies-as-adds to post-review. * Mon Jan 6 2014 Stephen Gallagher - 0.5.3-1 - New upstream release 0.5.3 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ * Thu Aug 15 2013 Stephen Gallagher - 0.5.2-1 - New upstream release 0.5.2 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.2/ * Fri Aug 2 2013 Fedora Release Engineering - 0.5.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Thu May 30 2013 Stephen Gallagher - 0.5.1-1 - New upstream release 0.5.1 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.1/ - Drop upstreamed ez_setup patch - New Features: * Improved the readability of rbt status output * Added a --repository-type option to most commands * Added a --list-repository-types option to post-review * Added a new rbt l
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 85 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 49 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.60-6.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0401/libyaml-0.1.3-4.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0409/zarafa-7.1.8-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0429/mediawiki119-1.19.11-2.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0426/tpp-1.3.1-17.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0466/python-gnupg-0.3.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0465/lighttpd-1.4.34-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing GMT-4.5.11-1.el6 GMT-coastlines-2.2.4-1.el6 RBTools-0.5.7-1.el6 asciinema-0.9.7-5.el6 bind-to-tinydns-0.4.3-12.20140205git32dc9263.el6 dar-2.4.12-1.el6 docker-io-0.8.0-1.el6 lighttpd-1.4.34-1.el6 llvm-3.4-9.el6 mock-1.1.36-1.el6 python-gnupg-0.3.6-1.el6 transifex-1.2.1-5.el6 Details about builds: GMT-4.5.11-1.el6 (FEDORA-EPEL-2014-0468) Generic Mapping Tools Update Information: Update to 4.5.11. The only non-bug change was adding the latest dimensions for recent Sandwell/Smith img files that go up to 85°, and adding definition file dat.def for mgd77 ASCII DAT format to the x2sys supplement. We also had to modify the –S option in pscontour.c to address a bug. This GMT release also coincides with the latest GSHHG release version 2.2.4 which adds a few missing lakes to California and fixes an error in the Baffin Island coastline and removes skinny spikes from numerous features. Below is the list of bug corrections for individual library files or programs: - gmt_customio.c : The magic recognition of native bit grids failed due to bad math. Wrote wrong number of bytes per record for odd-width Sun rasterfiles. - gmt_grdio.c : Would restrict grid region in grdimage.c despite doing a global map with azimuthal projections. - gmt_io.c : Formats for degree annotations using colons should never end in a trailing colon. Could not properly decode yyodd (no delimiter) time coordinates like 12Oct24. The GMT_import_table function checked for greenwich before assigning the input data. - gmt_init.c : Shifted JD origin by one day (24 Nov, instead of 25 Nov). - gmt_map.c : The oblique Mercator would get the pole on the wrong hemisphere. When -Jx is used with longitudes we must use the wesn clipping and outside functions, not the Cartesian ones. Fixed clipping problem in GMT_wesn_clip for regions larger than 180 but less than 360. GMT_grdproject_init did not handle increments that had been specified as units, e.g., -D30e. - gmt_plot.c : Did not check for map-jumping in GMT_plot_rectangle (psxy -SJ). - gmt_proj.c : Inverse -JR blew up at origin; now added a check. Needed to allow for minor round-off when determining if a point is beyond the horizon for -JG general perspective projection. blockmean.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - blockmedian.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - blockmode.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - filter1d.c : Susceptible to round-off when determining t of first and last output point when -T was not given. - gmtmath.c : The MIN and MAX operators ignored NaNs, but result should be NaN if one of the operands equal NaN. Wrong index order in rarely used SVD part of LSQFIT. - gmtset.c : Did not write values to .gmtdefaults4 if BASEMAP_TYPE was graph or inside. - grdfft.c : Fix normalization for std.dev of power estimate in -E. - grdimage.c : Fix bug represented by the globalgrid.sh test script for mix of -R selections and pixel/gridline choices. - grdblend.c : Despite geographic grids there were no check to shift a grid region by ±360 to match specified output region. - grdlandmask.c : Did not set output as geographic after using -Jx1d. - grdmath.c : The MIN and MAX operators ignored NaNs, but result shou
Request to take over package amavisd-new
Hello, Last week, I notified the devel list about Steven Pritchard (FAS: steve) been unresponsive [1], and after many unsuccessful attempts to get bug #695589 fixed [2], I request to take over the package amavisd-new. Any objection? Thank you. [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/194940.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=695589 -- Juan Orti GPG Key: DEEBD08B - http://jorti.fedorapeople.org/pubkey.asc Blog: https://apuntesderoot.wordpress.com/ signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 09:49:26AM -0800, Adam Williamson wrote: > Your whole proposal more or less *is* the heuristic 'don't autoclose > bugs with comments', because of how needinfo works in RH bugzilla. It's > not a status (as you imply by writing NEEDINFO) but a flag. If you set > the needinfo flag not against a specific person but against 'anyone', > then by default, the next person who posts a comment of any kind will > clear the flag - they have to uncheck a little box if they want to *not* > clear the flag. Thanks, yes. Once upon a time in the decent past (like, embarrassingly long ago) it *was* a status, and apparently way too much of that is still in my brain. I went back and reread what I wrote, and I think it still makes sense with your clarification. The above was certainly exactly why I propose this -- it's not just moving around what we happen to call things, but has an actual positive change to the user experience. It is the case that it being a flag rather than a status makes it a bit more complicated to set up searches for bugs which are open but don't have the flag set. But it's still doable, so I hope that doesn't undermine it too much. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "a stop job is running for User Manager for 0"
On Thu, 6 Feb 2014, Reindl Harald wrote: which is user 0 that is yours, an not only yours https://bugzilla.redhat.com/show_bug.cgi?id=1023820 This workaround solved my problem: https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 basically: cat > /etc/systemd/system/sshd-shutdown.service [Unit] Description=kill all sshd sessions Requires=mutil-user.target [Service] ExecStart=/usr/bin/killall sshd Type=oneshot [Install] WantedBy=shutdown.target reboot.target poweroff.target systemctl daemon-reload systemctl enable sshd-shutdown.service Thanks for the pointer Harald! I do hope the systemd people can fix the real problem with sshd. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Feb 6, 2014 11:06 AM, "Kevin Fenzi" wrote: > > On Thu, 6 Feb 2014 04:00:17 -0500 > Matthew Miller wrote: > > > I would like to see one of the following, in order of preference: > > > > 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with > > a notice similar to the current one. (Essentially moving the > > current warning back a little bit.) > > > > Step one point five: I believe pretty much anyone can clear the > > NEEDINFO flag. > > > > Step two: when the *next* release hits EOL (and the release under > > consideration has been EOL for approximately 6 months), move any > > bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, > > with a message similar to the current EOL note. > > So, all those bugs stay open on the EOL version until EOL+1? > > That seems poor to me. What do we do if someone clears needinfo and > says: Yes, this still affects me, I am running EOL release. Please fix > it. > > We cannot, the EOL release is closed, no more updates or support. > > How does leaving it open there help? > > > EOL wouldn't be visibile as an available status for bugzilla > > users to select when closing a bug in the interface, so it does not > > add to UI clutter, but also makes it easy for us to do reports > > distinguishing between intentional and eol closure. > > Is this possible? > > > This gives a much longer timeframe where we're waiting for input, > > so by the time we actually close, the release has been EOL for a > > decent while (rather than now, at the "I just got around to > > updating!" point). > > > > This does risk some false positives (negatives? whatever) where > > NEEDINFO is cleared with "works for me" but the bug not closed, but > > that seems like a less serious problem. > > Yeah, thats another issue with this... they would stick around in that > case until the maintainer or someone came in and cleared them. > > > 2. As #1, but with no new CLOSED:EOL resolution. Instead, use > > WONTFIX or and add a ClosedEOL keyword automatically. This is uglier > > than the above but requires no bugzilla change. > > > > 3. As #1, but just leave bugs in NEEDINFO state forever. > > > > This would possibly require maintainers to update their searches / > > filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs > > from older releases. > > It would also be misleading, IMHO. > > "Hey reporter, I need info to fix this" > > "Here you go, here's the info you wanted from my Fedora 7 machine, > please provide update" > > kevin > > -- What do you all think about adding a note to bugs against Fedora N-1 when Fedora N is released, ie: "You filed this bug against Fedora 19, and Fedora 20 has recently been released. A new Fedora release includes a version update for many packages, and your issue may have been resolved. Please consider checking to see if your issue persists in Fedora 20 and updating this ticket accordingly. Any bugs remaining open when support ends for Fedora 19, shortly after the release of Fedora 21, unless the issue affects Fedora 20 or Fedora 21." Not polished copy, obviously, but giving the reporter some more warning/prodding can't hurt. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Gsoc idea feedback and suggestions.
Hey, This is Vidun. I would like to get involved in the Google Summer Of Code program with Fedora. I have an idea in mind which I would like to suggest and probably work on. The idea description as of now is too vague but I hope it drives my point. I'm looking for suggestions and feedback from the community so that I know it this kind of project fits into the scope of Fedora GSOC. The idea initially came up as a difficulty I faced when handling RTC(real time communication) for web project to handle and push notifications, alerts, messages etc. As from a lazy view point this can be easily accomplished with polling but that does not make it real time and also RTC with polling is at the expense of the client runner. There are several third party business's like Pusher that solve this problem by using their server for RTC but developers face the problem of privacy when it comes to sensitive data and they set a cap for the number of messages that can be pushed for a certain paid plan. As it can be clearly seen that using this model is both expensive and error prone as it is not in the control of the developers, so if the main server is down it would result in unexpected behaviors in applications. Some of the problems that developers face when implementing their own RTC message pushing. 1. Most of the hosting companies do not support web-sockets. This is troublesome for established companies to migrate host to support RTC. 2. Privacy issues. 3. Additional work load for developers. Developing web-socket apps is not easy. Successful implementation would solve the following problems. 1. Security for messages. 2. Developers can bootstrap this project and concentrate on the core application. 3. Ability to alter working to suit the particular Application model. I'm waiting for a green flag so that I can work on the detailed draft for the application during my week end. Regards, Vidun k. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "a stop job is running for User Manager for 0"
Am 06.02.2014 20:59, schrieb Paul Wouters: > On Thu, 6 Feb 2014, Reindl Harald wrote: > >>> Regularly, we get tests failing because the VM does not boot within 60 >>> seconds, and seems to hang at: >>> >>> "a stop job is running for User Manager for 0" >> >> here you go >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1023820 >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1010572 >> https://bugzilla.redhat.com/show_bug.cgi?id=1057811 >> https://bugzilla.redhat.com/show_bug.cgi?id=1057618 >> https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 >> >> now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes >> that long to fix so pretty clear bugs nor why prelink is not banned >> at all in the distribution > > Note that my test systems have never had prelink installed (and I've > done my best to get prelink banished forever over the years) one of the issues *looks* like prelink related that's why i listed more than one bugreport > It does seem to point to systemd related issues, although the only user > on these systems is root. which is user 0 that is yours, an not only yours https://bugzilla.redhat.com/show_bug.cgi?id=1023820 however, systemd in F20 and RHEL17 is the most broken release after F15, F16-F19 where improvements, F20 in case of systemd is a massive step backwards in case of stability and bugs sadly, because the rest of F20 is really stable and clean https://bugzilla.redhat.com/show_bug.cgi?id=1023788 is simply *unacceptable* because it was reported *long* before final release, is more than 3 months old and reproduceable with every single reboot/shutdown via ssh signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "a stop job is running for User Manager for 0"
On Thu, 6 Feb 2014, Reindl Harald wrote: Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: "a stop job is running for User Manager for 0" here you go https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes that long to fix so pretty clear bugs nor why prelink is not banned at all in the distribution Note that my test systems have never had prelink installed (and I've done my best to get prelink banished forever over the years) It does seem to point to systemd related issues, although the only user on these systems is root. I'll try and boot with more verbosity and see what I can find out. Thanks, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "a stop job is running for User Manager for 0"
Am 06.02.2014 20:43, schrieb Paul Wouters: > > I'm using a minimal netinstall version of fedora20 for testing using > KVM. We very often cycle these machines (once per test, we run hundreds > of tests) > > Regularly, we get tests failing because the VM does not boot within 60 > seconds, and seems to hang at: > > "a stop job is running for User Manager for 0" here you go https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes that long to fix so pretty clear bugs nor why prelink is not banned at all in the distribution signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
"a stop job is running for User Manager for 0"
I'm using a minimal netinstall version of fedora20 for testing using KVM. We very often cycle these machines (once per test, we run hundreds of tests) Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: "a stop job is running for User Manager for 0" The machine is still in single user mode, so I cannot get any more information out of it. The message is rather useless, because it does not tell me anything about the problem. Which job is still running? What is it waiting for? What's a User Manager? Who is "0"? I'm not even sure at what component we are looking for to report a bug :( Does anyone have more information for me? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 6 Feb 2014 04:00:17 -0500 Matthew Miller wrote: > I would like to see one of the following, in order of preference: > > 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with > a notice similar to the current one. (Essentially moving the > current warning back a little bit.) > > Step one point five: I believe pretty much anyone can clear the > NEEDINFO flag. > > Step two: when the *next* release hits EOL (and the release under > consideration has been EOL for approximately 6 months), move any > bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, > with a message similar to the current EOL note. So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? > EOL wouldn't be visibile as an available status for bugzilla > users to select when closing a bug in the interface, so it does not > add to UI clutter, but also makes it easy for us to do reports > distinguishing between intentional and eol closure. Is this possible? > This gives a much longer timeframe where we're waiting for input, > so by the time we actually close, the release has been EOL for a > decent while (rather than now, at the "I just got around to > updating!" point). > > This does risk some false positives (negatives? whatever) where > NEEDINFO is cleared with "works for me" but the bug not closed, but > that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. > 2. As #1, but with no new CLOSED:EOL resolution. Instead, use > WONTFIX or and add a ClosedEOL keyword automatically. This is uglier > than the above but requires no bugzilla change. > > 3. As #1, but just leave bugs in NEEDINFO state forever. > > This would possibly require maintainers to update their searches / > filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs > from older releases. It would also be misleading, IMHO. "Hey reporter, I need info to fix this" "Here you go, here's the info you wanted from my Fedora 7 machine, please provide update" kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 6, 2014, at 12:39 AM, Dariusz J. Garbowski wrote: > On 05/02/14 05:46 PM, Przemek Klosowski wrote: >> On 02/04/2014 06:18 PM, Chris Murphy wrote: >>> And then we can definitely justify making them bigger. 550MB, or even 1GB. >>> It's neutral to plus >>> for performance for either HDDs or SSDs (faux short stroked in the former, >>> and overprovisioned for >>> the latter). Does anyone know why the convention is to create the ESP as >>> the first partition? >> At times in the past there was a race between BIOS support for large disks >> and hard disk size, and >> BIOS boot code could not reach the far sectors of the disk. This even leaked >> into Linux sometimes, Right but BIOS only ever expected to have to read LBA 0, so it stands to reason someone's not testing whether it can jump beyond LBA 28-bit addressing if it's an ancient BIOS implementation; or beyond the MBR 32-bit address limit. But since the UEFI spec is predicated on LBA 48-bit addressing, I think my diplomatic language would be "WTF vendor" if UEFI firmware face planted on an ESP at the end of a 5TB drive. I should test it. Oh hey, it works with whatever UEFI VirtualBox uses. This is the layout. Firmware finds shim.efi way out well beyond 3TB, and GRUB is finding its grub.cfg way out there as well and boots the system fine. Disk /dev/sda: 1024000 sectors, 4.8 TiB […] Number Start (sector)End (sector) Size Code Name 1 10238871552 1023966 551.0 MiB EF00 EFI System 22048 1026047 500.0 MiB 0700 3 1026048 10238871551 4.8 TiB 0700 > It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) > with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to > boot OS. RHEL 6.5 uses ancient GRUB 0.97 so the problem could be with the boot loader, or the firmware. However, without having this computer physical present, how can you tell it uses UEFI and not BIOS? I certainly can't. Dell's spec sheet for it says in part "From bezel to BIOS to packaging" which seems like just a tagline, not a spec per se. But then the support page explicitly refers to it as BIOS: Dell Server BIOS PowerEdge R620 Version 2.1.3 http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/poweredge-r620?driverId=T2RVC&osCode=WS8R2&fileId=3329675946&languageCode=en&categoryId=BI In general, finding out whether a system's firmware is BIOS or UEFI is not easy. Either they don't say, as if it isn't a selling point, yet telling me it uses the, e.g. Intel C600 chipset isn't too obscure. HP pretty much universally refers to the UEFI firmware updates as BIOS updates. Idiotic. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 2014-02-06 at 04:00 -0500, Matthew Miller wrote: > Additionally, but requiring some development, we could add some heuristics > like: don't autoclose bugs with many incoming duplicate pointers, or > possibly (as David suggests) bugs with comments, or bugs which have been > reopened, or (here I get handwavy). Your whole proposal more or less *is* the heuristic 'don't autoclose bugs with comments', because of how needinfo works in RH bugzilla. It's not a status (as you imply by writing NEEDINFO) but a flag. If you set the needinfo flag not against a specific person but against 'anyone', then by default, the next person who posts a comment of any kind will clear the flag - they have to uncheck a little box if they want to *not* clear the flag. I still don't actually think it's a bad proposal, just wanted to be sure the implications of using the needinfo flag were clear :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Adjust wiki for ARM BeagleBone Black
Hey guys, I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. Best Regards firemanxbr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Thu, Feb 6, 2014 at 11:37 AM, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/06/2014 02:39 PM, Richard Shaw wrote: > > On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý > wrote: > > > >> On 02/05/2014 08:24 PM, Richard Shaw wrote: > >> > >>> Are there official guidelines on how to handle selinux contexts in > >>> packaging? I can still only find the draft which seems way more > >>> complicated than necessary for my needs. > >>> > >>> I'm working on a package that uses mongodb internally (runs it's own > >>> instance). Selinux is complaining because it has mongodb creating the > >>> database (and logs) outside of the normal locations > You need to tell SELinux about the labels. > > semanage fcontext -e /var/lib/mysql PATHTO/mysql > restorecon -R -v PATHTO/mysql > > Is probably what you want. Ok, I ended up getting to the same place using "-a mongod_var_lib_t"... Now how to turn that into a policy I can package? I ended up with this as the requirements to create a functional package: /var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0 /var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0 portcon tcp 27117 system_u:object_r:mongod_port_t:s0 Thanks, Ricahrd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2014 02:39 PM, Richard Shaw wrote: > On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý wrote: > >> On 02/05/2014 08:24 PM, Richard Shaw wrote: >> >>> Are there official guidelines on how to handle selinux contexts in >>> packaging? I can still only find the draft which seems way more >>> complicated than necessary for my needs. >>> >>> I'm working on a package that uses mongodb internally (runs it's own >>> instance). Selinux is complaining because it has mongodb creating the >>> database (and logs) outside of the normal locations You need to tell SELinux about the labels. semanage fcontext -e /var/lib/mysql PATHTO/mysql restorecon -R -v PATHTO/mysql Is probably what you want. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLzyGsACgkQrlYvE4MpobNYWQCeJZf17KvHSr6JfoKRSTx7oopb RgoAn1OmUd7nLkr6alO1g5Ct58KQrwHz =yJZG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 4, 2014 at 11:11 AM, H. Guémar wrote: > I'm not fond of keeping spins around when we're focusing on products. > That gives the message that they are second-class citizens in Fedora. > In my view, this not supposed to be a discussion about numbering classes / keeping score. Rather, I view spins and products as _substantially_ different: spins are more or less focused on providing upstream software (perhaps with fixed bugs, or with good curation); products are much more focused on doing extra new work to integrate, work that doesn't have any non-Fedora upstream. So, saying that every spin is/should be a product-in-making doesn't match with the way I think about this. Note that this distinction does not automatically imply anything as to visibility, promotion, or being release blocking: We could easily promote a specific spin _more_ than a specific product (say, promote Fedora Audio Product, Fedora Rails 4 spin, Fedora Cloud Product, Fedora KDE spin, Fedora Desktop, Fedora Server - the order is obviously nonsense but you get the idea). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf-0.4.13
Hello, dnf-0.4.13 is out [1], [2]. F20 version will follow shortly. We ship Delta RPM support, bash completion and keepcache again in this version. Remember to come meet the team at DevConf.cz this weekend. Ales [1] http://dnf.baseurl.org/2014/02/06/dnf-0-4-13-released/ [2] http://akozumpl.github.io/dnf/release_notes.html#id24 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Upgrade ICU to 52.1 with soname bump
Hi, On Saturday, 2014-01-25 09:47:28 -0700, Kevin Fenzi wrote: > > If time permits I'd like to do an upgrade of ICU to 52.1 next week, > > which leads to the usual soname bump. > > > > As quite a lot of packages are affected by this, is anyone objecting > > and can point out a better time for the upgrade? I was carried away with LibreOffice release and then FOSDEM, so this got postponed. > Hum... perhaps I am missing something, but I don't see anything that is > directly affected. There's no packages that buildrequire or require icu? > Or am I looking at the wrong package? > > I guess you mean libicu? Yes, sure, with ICU I referred the entire suite, the important part here being libicu and all its libs. > Are there any changes in the 50->52.1 jump that would need > patches/changes? Or should it just mostly be a rebuild? Should be a rebuild only. > Do you have any provenpackager(s) who can help you rebuild things? Maybe, but he's already overloaded ;) > > If not, I'll probably announce it on Monday and do the upgrade on > > Wednesday. > > Seems fine. So maybe next week.. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgp7vWli7jzas.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý wrote:
> On 02/05/2014 08:24 PM, Richard Shaw wrote:
>
>> Are there official guidelines on how to handle selinux contexts in
>> packaging? I can still only find the draft which
>> seems way more complicated than necessary for my needs.
>>
>> I'm working on a package that uses mongodb internally (runs it's own
>> instance). Selinux is complaining because it has
>> mongodb creating the database (and logs) outside of the normal locations.
>>
>> I think I can fix this with a "chcon -t mongod_var_lib_t
>> %{_sharedstatedir}/db/location" and "chcon -t mongod_log_t
>> /log/path" or something like that.
>>
>> Is it a good idea to do this in %post?
>>
>
> I do not think there is general guideline.
>
> As other suggested - it is bad idea to call chcon explicitly. You should
> rather write your own selinux policy (it is not that hard, really) and call
> restorecon or fixfiles.
>
Got it.
> You should not call it in %post because selinux policy can be loaded after
> your %post. The story about this is little bit longer and boring. The
> conclusion is - do that in %posttrans.
>
Ok, good to know.
> You can get some inspiration e.g. in:
> https://git.fedorahosted.org/cgit/copr.git/tree/copr.spec
> https://git.fedorahosted.org/cgit/copr.git/tree/selinux
Thanks!
I've gotten this far on my own. I used semanage and some google-fu to come
up with this that seems to fix the problem. I'm not sure if there's a
better way (i.e. a more "least privilege" route) but I have the following
in file_contexts.local:
/var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0
/var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0
And the port problem in ports.local:
portcon tcp 27117 system_u:object_r:mongod_port_t:s0
Now, how to turn that into a policy file...
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 07:30:44AM -0500, Jaroslav Reznik wrote: > > 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX > > or and add a ClosedEOL keyword automatically. This is uglier than > > the above but requires no bugzilla change. > I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far > as I know, there were some efforts to cut down BZ statuses (ON_DEV for > example), even it would be hidden. So keyword looks like much more easier > solution. I think it depends on the reasons for cutting down on statuses (or in this case, resolutions). If it's for performance reasons or some other practical concern, okay. But if it's because the plethora of options is confusing to users, I think hiding it from the UI should be okay. We could ask. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Thu, Feb 06, 2014 at 01:21:53PM +0100, Michael Schwendt wrote: > Where is the human to notice "comments after EOL" and act accordingly? Theeeoretically, the package maintainer. In the prototypical version of this back in the ancient days, I actually put myself on the CC list of all of the closed bugs. But there are several times more bugs than there used to be, and I think that would consume a whole full-time person at least for a while. > How many tickets would be affected by a "comment after EOL"? It's kind of hard to construct the exact search because the Fedora EOL script takes some time to run, and I don't think bugzilla allows anything like "comment from not $GIVENUSER after comment from $GIVENUSER". If anyone does know how to do that, help wanted. :) > I've posted about it in 2008 already, and I still think the auto-closing > leads to hiding crap under the carpet. I think it's acknowledgement that we don't have resources to fix all of the crap. But I'd like if we could better identify the important cases where we actually *should* make sure issues are addressed, while finding the right balance between maintainer and user/reported burdens. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
- Original Message - > On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: > > The problem is that no-one seems to come up with an alternative that's > > any better. Leaving bugs on EOL versions open to rot away and be ignored > > is no use. We *could* give everyone privs to re-open closed bugs, I > > guess, and I personally don't think that would end terribly, but it's > > kind of a radical plan. > > I would like to see one of the following, in order of preference: > > 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with > a notice similar to the current one. (Essentially moving the current > warning back a little bit.) > > Step one point five: I believe pretty much anyone can clear the NEEDINFO > flag. > > Step two: when the *next* release hits EOL (and the release under > consideration has been EOL for approximately 6 months), move any bugs > still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a > message similar to the current EOL note. > > EOL wouldn't be visibile as an available status for bugzilla users to > select when closing a bug in the interface, so it does not add to UI > clutter, but also makes it easy for us to do reports distinguishing > between intentional and eol closure. > > This gives a much longer timeframe where we're waiting for input, so by > the time we actually close, the release has been EOL for a decent while > (rather than now, at the "I just got around to updating!" point). > > This does risk some false positives (negatives? whatever) where NEEDINFO > is cleared with "works for me" but the bug not closed, but that seems > like a less serious problem. > > 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or > and add a ClosedEOL keyword automatically. This is uglier than the above > but requires no bugzilla change. I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. Jaroslav > 3. As #1, but just leave bugs in NEEDINFO state forever. > > This would possibly require maintainers to update their searches / > filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older > releases. > > > Any of these seem pretty easy and I think would improve the situation for > users and bug reporters without badly increasing maintainer burden or being > dishonest about our ability to fix all the things. > > Additionally, but requiring some development, we could add some heuristics > like: don't autoclose bugs with many incoming duplicate pointers, or > possibly (as David suggests) bugs with comments, or bugs which have been > reopened, or (here I get handwavy). > > > -- > Matthew Miller-- Fedora Project-- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
- Original Message - > Like this: > https://bugzilla.redhat.com/show_bug.cgi?id=959071 > > I specifically followed up to say the issue continues in Fedora 19, > and nothing changed. The bug tracker should not expire bugs if there's > been a comment after the EOL warning. The bug bot is really very dumb [1] and rewrite is planned. So far it takes a list of bugs based on search query in CSV and runs bug after bug calls. So there's no way to check for messages. Also when I took look on some bugs it closed, there was one with two comments - it's fixed, it's not and to be honest, I was thinking about what to do with these. So I'm sorry for the bug closed, the new EOL closure message now contains wording that should avoid that "not everyone is allowed to reopen bugs", we should do the same for EOL warning version change. Jaroslav [1] https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 05 Feb 2014 14:50:59 -0800, Adam Williamson wrote: > On Wed, 2014-02-05 at 22:48 +, Colin Macdonald wrote: > > On 05/02/14 22:42, David Timothy Strauss wrote: > > > This is also not the first time this has happened to me. > > > > I'll chime in: when I first switched to Fedora (F14/15 era), I found > > this quite obnoxious, enough that I remember it. > > > > So there is also an issue of being a welcoming community to newcomers. > > The problem is that no-one seems to come up with an alternative that's > any better. Leaving bugs on EOL versions open to rot away and be ignored > is no use. We *could* give everyone privs to re-open closed bugs, I > guess, and I personally don't think that would end terribly, but it's > kind of a radical plan. > > The idea of not closing bugs that have comments after the EOL > notification doesn't necessarily make things better, I don't think; we'd > just have errors in the other direction. Say someone dropped a note 'oh > yeah, this is working now!' - it would be silly not to close the bug, > right? Has that been tried before? It sounds like a better approach. Where is the human to notice "comments after EOL" and act accordingly? How many tickets would be affected by a "comment after EOL"? What is the underlying problem here anyway? Too many unhandled tickets -> EOL auto-close threatening -> too many closed tickets to handle -> how to escape from that loop? In several large upstream bug trackers it is no different. Are developers always informed about what doesn't work even when not responding to tickets? Why should users still take the time to submit problem reports if they don't get a response? > algorithms are never perfect, but we do have to use them, as a > perennially under-resourced project. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
proposal for changes to auto-expiring bugs
On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: > The problem is that no-one seems to come up with an alternative that's > any better. Leaving bugs on EOL versions open to rot away and be ignored > is no use. We *could* give everyone privs to re-open closed bugs, I > guess, and I personally don't think that would end terribly, but it's > kind of a radical plan. I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO flag. Step two: when the *next* release hits EOL (and the release under consideration has been EOL for approximately 6 months), move any bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. This gives a much longer timeframe where we're waiting for input, so by the time we actually close, the release has been EOL for a decent while (rather than now, at the "I just got around to updating!" point). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with "works for me" but the bug not closed, but that seems like a less serious problem. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. Any of these seem pretty easy and I think would improve the situation for users and bug reporters without badly increasing maintainer burden or being dishonest about our ability to fix all the things. Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On 02/05/2014 08:24 PM, Richard Shaw wrote:
Are there official guidelines on how to handle selinux contexts in packaging? I
can still only find the draft which
seems way more complicated than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own instance).
Selinux is complaining because it has
mongodb creating the database (and logs) outside of the normal locations.
I think I can fix this with a "chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location" and "chcon -t mongod_log_t
/log/path" or something like that.
Is it a good idea to do this in %post?
I do not think there is general guideline.
As other suggested - it is bad idea to call chcon explicitly. You should rather write your own selinux policy (it is not
that hard, really) and call restorecon or fixfiles.
You should not call it in %post because selinux policy can be loaded after your %post. The story about this is little
bit longer and boring. The conclusion is - do that in %posttrans.
You can get some inspiration e.g. in:
https://git.fedorahosted.org/cgit/copr.git/tree/copr.spec
https://git.fedorahosted.org/cgit/copr.git/tree/selinux
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: different version of packages in testing and rawhide
thank so much adam :) On Thu, Feb 6, 2014 at 5:17 AM, Adam Williamson wrote: > On Thu, 2014-02-06 at 05:03 -0300, Carlos Morel-Riquelme wrote: > > Hi guys i have running rawhide in my laptop and is update , all work > > fine for me > > but i don't understand why update-testing have different version of > > packages in comparison with rawhide > > > > example the following builds have been pushed to Fedora 20 > > updates-testing > > > > NetworkManager-0.9.9.0-29.git20140131.fc20 > > abrt-java-connector-1.0.8-3.fc20 > > > > now the packages version of rawhide are > > > > NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 > > > > abrt-java-connector-1.0.8-1.fc21.x86_64 > > > > i'm confused > > These are errors on the parts of the packagers, basically. They are > supposed to ensure that builds for newer releases are always versioned > higher than builds for older releases (even if it's not really > 'necessary' in the flow of how they've done the builds). > > So, if there isn't a bug filed on each one already, go ahead and file > one :) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: different version of packages in testing and rawhide
On Thu, 2014-02-06 at 05:03 -0300, Carlos Morel-Riquelme wrote: > Hi guys i have running rawhide in my laptop and is update , all work > fine for me > but i don't understand why update-testing have different version of > packages in comparison with rawhide > > example the following builds have been pushed to Fedora 20 > updates-testing > > NetworkManager-0.9.9.0-29.git20140131.fc20 > abrt-java-connector-1.0.8-3.fc20 > > now the packages version of rawhide are > > NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 > > abrt-java-connector-1.0.8-1.fc21.x86_64 > > i'm confused These are errors on the parts of the packagers, basically. They are supposed to ensure that builds for newer releases are always versioned higher than builds for older releases (even if it's not really 'necessary' in the flow of how they've done the builds). So, if there isn't a bug filed on each one already, go ahead and file one :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 05, 2014 at 02:05:06PM -0800, David Timothy Strauss wrote: > > You just need to change the Version tag. > That is not something I appear to have access to do. And, if I don't, > very few people do. The person who *reported* the bug can (although there possibly may be some cases where that doesn't work, I can't find any) -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
different version of packages in testing and rawhide
Hi guys i have running rawhide in my laptop and is update , all work fine for me but i don't understand why update-testing have different version of packages in comparison with rawhide example the following builds have been pushed to Fedora 20 updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20 abrt-java-connector-1.0.8-3.fc20 now the packages version of rawhide are NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 abrt-java-connector-1.0.8-1.fc21.x86_64 i'm confused -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 05, 2014 at 01:51:41PM -0800, David Timothy Strauss wrote: > Like this: > https://bugzilla.redhat.com/show_bug.cgi?id=959071 > I specifically followed up to say the issue continues in Fedora 19, > and nothing changed. The bug tracker should not expire bugs if there's > been a comment after the EOL warning. See https://fedorahosted.org/fesco/ticket/1198... but that didn't result in me or anyone else really doing anything this time around. But I think it's worthwhile to continue the conversation. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
