Re: mercurial-2.3 build fails on f18
On Mon, Aug 20, 2012 at 06:28:53PM -0400, Neal Becker wrote: > http://kojipkgs.fedoraproject.org//work/tasks/4091/4384091/build.log > > The problem is that Fedora 18 currently ships with python- > docutils-0.10-0.2.20120730svn7490.fc18. It works when downgrading to python- > docutils-0.8.1-3.fc17. > > So what to do about it? > > The discussion is here: > http://www.selenic.com/pipermail/mercurial-devel/2012-August/043522.html > > I have been talking with upstream, and they say that on debian there is a > mechanism to use any version for the build. I don't think Fedora has such a > mechanism - only the 'current' version of any tool can be used for the build. > > Is this correct? > > Any suggestions? > Note: Matt Mackall is wrong -- Fedora has over 10,000 packages and we work to keep it free of conflicts. We do have the ability to create parallel installable versions of docutils but I'd rather not. I'm hoping that upstream considers this a bug. In which case, there is a pretty easy code change to make it work. I outline the change in the bug report I opened with upstream: http://sourceforge.net/tracker/?func=detail&aid=3559988&group_id=38414&atid=422030 (I thought this might be a feature of new docutils rather than a bug but after working on it for a while I found that there doesn't seem to be any way to use a user defined writer with the new code. So it does look like a bug to me.) However, docutils currently is FTBFS because of the python3.3 update. Until that's resolved we can't get a new package built for Fedora :-(. I've emailed dmalcolm to find out if there's any progress on that. -Toshio pgpynHhHNBhfu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies from F17->F18 upgrade
On 2012-08-18 16:09, Luya Tshimbalanga wrote: I ran yum distro-sync command but encountered dependencies issue related to shotwell and ffmpeg from RPM Fusion which I removed them. Applying systemctl enable --force gdm.service was cumbersome with polkit and selinux policies problem where I had to reinstall both polkit and systemd with Ray's (halfine) suggestion. I have gdm graphical login screen operational, the entire desktop is slow compared to the previous gnome 3.4.2 on Fedora 17running on a AMD E350 powered laptop. I don't know what exactly cause slowdown, it appears to be a regression. Should I file a bug report Aside from the follow-up discussion about startx not granting proper access to the DRI /dev nodes and hence forcing llvmpipe rendering - which is probably not what's affecting Luya, as he says gdm is working - the other probable cause of sluggish performance in F18 is the old debug kernel issue. Remember, prior to Beta, most kernel builds have debugging enabled, which ever since 2.39 or so has been _very_ slow compared to non-debug modes (much more so than used to be the case). Every so often the kernel team does a build with debugging disabled, you might want to grab one of those builds and see if it resolves the issue before filing a bug. If I'm reading the changelog right, the latest non-debug build is 3.6.0-0.rc2.git0.1: http://koji.fedoraproject.org/koji/buildinfo?buildID=348688 so give that one a shot. -- 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
mercurial-2.3 build fails on f18
http://kojipkgs.fedoraproject.org//work/tasks/4091/4384091/build.log The problem is that Fedora 18 currently ships with python- docutils-0.10-0.2.20120730svn7490.fc18. It works when downgrading to python- docutils-0.8.1-3.fc17. So what to do about it? The discussion is here: http://www.selenic.com/pipermail/mercurial-devel/2012-August/043522.html I have been talking with upstream, and they say that on debian there is a mechanism to use any version for the build. I don't think Fedora has such a mechanism - only the 'current' version of any tool can be used for the build. Is this correct? Any suggestions? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ODE upgrade
Hello, all. Hans, the ode maintainer, has asked me to implement and coordinate the upgrade of ode to the current release, 0.12. The affected packages, so far as we've determined, are delelict, machineball, ompl, stormbaancoureur, xmoto and taoframework. Hans and I own the majority of this list, and I've CCd the other owners. I've got a build of ode 0.12 ready, and used it to patch all the listed packages. I've tested xmoto, stormbaancoureur, maniadrive, and machineball. I'm not sure how to adequately test derelict, ompl or taoframework. To this end, I'm posting srpms of my work so far at http://fedorapeople.org/~limb/ode/ Please test if possible and let me know if and tweaks are needed, otherwise I'll commit and build the whole lot for rawhide and f18 on Friday, 24, unless it's all clear sooner. I'll announce -devel either way. Thanks! -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2012-08-20)
=== #fedora-meeting: FESCO (2012-08-20) === Meeting started by mjg59 at 17:02:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-08-20/fesco.2012-08-20-17.02.log.html . Meeting summary --- * init process (mjg59, 17:02:37) * #888 F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot (mjg59, 17:05:17) * AGREED: close, no longer a fesco issue (mjg59, 17:14:24) * #934 Exception request F18 Feature: rngd default-on - https://fedoraproject.org/wiki/Features/rngd_default_on (mjg59, 17:14:30) * AGREED: exception granted for rngd default-on (+1 9, 0 0, -1 0) (mjg59, 17:18:09) * #937 Fedora 18 Feature Freeze Exception: Simplified crash reporting via ABRT Server - https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting (mjg59, 17:18:14) * AGREED: - exception granted for ABRT improvements (+1 7, 0 0, -1 0) (mjg59, 17:23:51) * #938 Fedora 18 Feature Freeze Exception: GNOME 3.6 - https://fedoraproject.org/wiki/Features/Gnome3.6 (mjg59, 17:24:00) * AGREED: exception granted for GNOME 3.6 (+1 7, 0 0, -1 0) (mjg59, 17:25:28) * AGREED: non-persistent service permission grant should be reworded (mjg59, 17:33:47) * #932 F18 Features - progress at Feature Freeze (mjg59, 17:36:52) * LINK: https://fedorahosted.org/fesco/ticket/932#comment:4 is the updated list (mjg59, 17:38:52) * AGREED: Happy with current state of feature process (mjg59, 17:50:16) Meeting ended at 18:30:41 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mjg59 (108) * limburgher (44) * nirik (40) * mitr (37) * pjones (32) * notting (22) * jwb (17) * zodbot (10) * jreznik (8) * gholms|pto (6) * hpa (6) * dwa (4) * kushal (2) * sgallagh (1) * abadger1999 (1) * Southern_Gentlem (1) * mmaslano (0) * t8m (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 17:02:31 #startmeeting FESCO (2012-08-20) 17:02:31 Meeting started Mon Aug 20 17:02:31 2012 UTC. The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:35 limburgher: game time? 17:02:36 #meetingname fesco 17:02:36 The meeting name has been set to 'fesco' 17:02:36 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 17:02:36 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 17:02:37 #topic init process 17:02:40 * notting is here 17:02:42 * limburgher here 17:02:43 morning. 17:02:46 * nirik is here. 17:02:57 Hello 17:03:07 jwb: Here? 17:03:11 * hpa is lurking 17:03:32 I think mmaslano said she'd be on holiday? 17:03:38 I seem to recall such. 17:03:58 And t8m, maybe? 17:04:11 mjg59: yep, she's on holiday 17:04:35 t8m is not available today too if I remember it correctly 17:05:02 mjg59, i am, sorry 17:05:07 Ok, cool 17:05:13 So, followups: 17:05:17 #topic #888F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot 17:05:20 .fesco 888 17:05:22 mjg59: #888 (F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot) – FESCo - https://fedorahosted.org/fesco/ticket/888 17:05:32 I think we're still waiting on the board for this 17:05:48 do we even need this open? or was there something more for fesco here? 17:05:58 What, exactly, are we waiting for? 17:06:00 not fesco, no 17:06:13 Yeah, fair enough 17:06:17 I'll close this, then 17:06:21 I think there were questions to the board if XYZ would meet their requests 17:06:44 KK. 17:06:46 Ok. How about we go through the exception requests and things first, and feature freeze progress at the end? 17:07:05 17:07:06 I'd prefer keeping this open - AFAICS it's undecided whether we will be able to do this for F18, and the rel-eng impact is non-trivial and perhaps woth tracking? 17:07:33 OTOH "leave it to rel-eng" works as well, the contingency plan is probably not very risky 17:07:42 mitr: We're doing it for F18 unless the board explicitly says we're not 17:07:43 mitr: care to make a comment to that effect on trac so that next time this comes up we remember why it's there? 17:07:46 I don't think it's a fesco issue 17:08:41 as much as fesco is oversight for eng/qa/releng, it is. but not without specific items that require fesco to intervene there 17:08:59 Moving on, unless anyone has anything else on this? 17:09:18 mjg59: Is my reading of "the board would be illing to approve if ..." as an implicit prohibition incorrect? 17:09:29 mitr: It's not something the board needs to approve 17:09:55 mitr: It's something the board can prohibit in the sense that they're in a position of oversight over everyone else in the project 17:10:21
is it fedora ruby
One of the projects accepted as part of Fedora's participation in the Google Summer of Code was an effort to create a site highlighting the Fedora ruby-sig's work around packaging the stack, and to provide tooling to cross-reference gem and rpm metadata and assist in the migration process. The student working on the project (Zuhao, cc'd) has done an amazing job on the codebase, and midway through the summer we deployed the site to the isitfedoraruby.com [1] domain. I'm pleased to say the site has been gaining interest amongst the Fedora / ruby community and recently we've implemented some exciting features including a tool which to compare a ruby Gemfile / Gemfile.lock against Fedora [2] and different views on the data, cross-referencing package metadata and dependencies stored on rubygems.org and in Fedora [3]. I encourage everyone to checkout the site and codebase [4]. Any and all feedback (and patches!) are more than welcome. -Mo Morsi [1] http://isitfedoraruby.com/ [2] http://isitfedoraruby.com/stats/gemfile_tool [3] http://isitfedoraruby.com/fedorarpms/rubygem-activesupport/full_deps [4] https://github.com/zuhao/isitfedoraruby -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.2 for F18?
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes: > Is there any chance that 9.2 will be available for F18? I'm holding off until there is a 9.2.0 release, or at least an RC release, but I do very much want it to be in F18. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 18 Alpha Go/No-Go Meeting, Wednesday, August 22 @ 17:00 EDT
Join us on irc.freenode.net in #fedora-meeting for this important meeting, wherein we shall determine the readiness of the Fedora 18 Alpha. Wednesday, August 22, 2012 @21:00 UTC (17:00 EDT/14:00 PDT/23:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 18 Alpha Blocker list: http://supermegawaffle.com/blockerbugs/current Jaroslav PS: in the current schedule it is @17:00 US Eastern, if you have objections, let me know and we can try to find better time... ___ 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: DisplayManagerRework: how can a DM do plymouth internally?
Daniel Drake (d...@laptop.org) said: > Hi, > > I'm porting olpc-dm to F18 / > https://fedoraproject.org/wiki/Features/DisplayManagerRework > > Thanks for the good documentation. > > The only detail that I'm unclear about is this one: > > # Add the following line only if the DM can do Plymouth internally > Conflicts=plymouth-quit.service > > What does it mean for a DM to "do plymouth internally" ? "Do plymouth internally" means the display manager handles interacting with plymouth itself, and the display manager itself telling plymouth to quit at the appropriate time. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 Alpha Go/No-Go Meeting, Wednesday, August 22 @ 17:00 EDT
Join us on irc.freenode.net in #fedora-meeting for this important meeting, wherein we shall determine the readiness of the Fedora 18 Alpha. Wednesday, August 22, 2012 @21:00 UTC (17:00 EDT/14:00 PDT/23:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 18 Alpha Blocker list: http://supermegawaffle.com/blockerbugs/current Jaroslav PS: in the current schedule it is @17:00 US Eastern, if you have objections, let me know and we can try to find better time... ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.2 for F18?
On Mon, Aug 20, 2012 at 18:38:33 +0200, Michał Piotrowski wrote: Hi, I am aware that F18 is a special release - base for a new RHEL, so it is possible that you will not want to put there not yet released software. PostgreSQL 9.2 does not have any true revolutionary features, but it has quite a long list of improvements http://www.postgresql.org/docs/devel/static/release-9-2.html Is there any chance that 9.2 will be available for F18? I think for 9.1 Tom pushed it just before beta when a few of us promised to do some testing pronmptly. So if 9.2 gets released before f18 beta there is probably a good change it will make it in F18. Otherwise it probably won't. Postgres has gotten so good, that for hobbiest purposes having the latest base release doesn't seem that important. For people that need the latest release, there are typically rpms available for download. And in the worst case rebuilding srpms for a specific fedora release isn't that hard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.2 for F18?
On 08/20/2012 04:38 PM, Michał Piotrowski wrote: Hi, I am aware that F18 is a special release - base for a new RHEL, so it is possible that you will not want to put there not yet released software. PostgreSQL 9.2 does not have any true revolutionary features, but it has quite a long list of improvements http://www.postgresql.org/docs/devel/static/release-9-2.html Is there any chance that 9.2 will be available for F18? First and foremost you should file an RFE against the relevant component to see if it can be upgraded. Secondly RHEL should not be a reason packages are not updated in Fedora to their current/latest release and or other progress is made within the project nor is Fedora the place for something being asked to be included in RHEL. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
xcb-util soname bump in rawhide
Two (deprecated) functions were removed from libxcb-util, and the soname has been bumped to match. The following (binary) packages are affected: boinc-manager i3 startup-notification xcb-util-image xorg-x11-drv-intel That last one is a touch unexpected. At any rate, I'll kick rebuilds for these. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
On Mon, Aug 20, 2012 at 05:35:07PM +0200, Björn Persson wrote: > Richard W.M. Jones wrote: > > If I give negative karma, that's because I tested the update and > > found it didn't work. > > Why would you do that instead of retracting the update? Actually because I'd forgot you could do that. Yes, I'd retract or obsolete the update in this situation. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket 429 - added nsslapd-readonly to DS schema
https://fedorahosted.org/389/ticket/429 https://fedorahosted.org/389/attachment/ticket/429/0001-Ticket-429-Add-nsslapd-readonly-to-schema.patch -- Mark Reynolds Senior Software Engineer Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
PostgreSQL 9.2 for F18?
Hi, I am aware that F18 is a special release - base for a new RHEL, so it is possible that you will not want to put there not yet released software. PostgreSQL 9.2 does not have any true revolutionary features, but it has quite a long list of improvements http://www.postgresql.org/docs/devel/static/release-9-2.html Is there any chance that 9.2 will be available for F18? -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 849703] New: Regular Expression matching in signal handler causes side-effects
https://bugzilla.redhat.com/show_bug.cgi?id=849703
Bug ID: 849703
QA Contact: extras...@fedoraproject.org
Severity: unspecified
Version: 16
Priority: unspecified
CC: cw...@alumni.drew.edu, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk,
mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rc040...@freenet.de,
tcall...@redhat.com
Assignee: mmasl...@redhat.com
Summary: Regular Expression matching in signal handler causes
side-effects
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: t...@electronghost.co.uk
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: perl
Product: Fedora
Description of problem:
Executing an RE inside a PERL deferred signal handler causes an unwanted side
effect on RE-execution in the code that was being executed when the signal
arrived.
Version-Release number of selected component (if applicable):
"This is perl 5, version 14, subversion 2 (v5.14.2) built for
x86_64-linux-thread-multi"
How reproducible:
Always
Steps to Reproduce:
Here is a test case:
== CUT HERE ==
#!/usr/bin/env perl
sub sighup {
my $bar="This-Has-Dashes-HUP";
$bar=~s/.*-//;
print "$bar\n";
}
$SIG{'HUP'}=\&sighup;
while (1) {
my $foo="This:Has:Colons";
$foo=~s/.*://;
if ($foo=~m/:/) {
print "BUG!!: $foo\n";
}
}
== CUT HERE ==
Run this endless loop and arrange to send it a SIGHUP once per second.
Actual results:
You will see output like the following:
bash$ perl ./t.pl
HUP
HUP
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
BUG!!: This:Has:Colons
HUP
HUP
BUG!!: This:Has:Colons
HUP
HUP
HUP
BUG!!: This:Has:Colons
Expected results:
You should get output like this (observed on "This is perl 5, version 12,
subversion 4 (v5.12.4) built for x86_64-linux-thread-multi" from Fedora 15):
bash$ perl ./t.pl
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
HUP
Additional info:
This is not a crash, like 809796, though they are very likely related or the
same problem.
--
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
DisplayManagerRework: how can a DM do plymouth internally?
Hi, I'm porting olpc-dm to F18 / https://fedoraproject.org/wiki/Features/DisplayManagerRework Thanks for the good documentation. The only detail that I'm unclear about is this one: # Add the following line only if the DM can do Plymouth internally Conflicts=plymouth-quit.service What does it mean for a DM to "do plymouth internally" ? Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Subject: Schedule for Today's FESCo Meeting (2012-08-20)
Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #888 F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot .fesco 888 = New business = #topic #932 F18 Features - progress at Feature Freeze .fesco 932 #topic #934 Exception request F18 Feature: rngd default-on - https://fedoraproject.org/wiki/Features/rngd_default_on .fesco 934 #topic #937 Fedora 18 Feature Freeze Exception: Simplified crash reporting via ABRT Server - https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting .fesco 937 #topic #938 Fedora 18 Feature Freeze Exception: GNOME 3.6 - https://fedoraproject.org/wiki/Features/Gnome3.6 .fesco 938 #936Clarify non-persistent service permission grant .fesco 936 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
Richard W.M. Jones wrote: > If I give negative karma, that's because I tested the update and > found it didn't work. Why would you do that instead of retracting the update? Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
python-wtforms 0.6.3 and 1.0.1
Hi, Is there a reason why python-wtforms is still at version 0.6.3, even in rawhide, while version 1.0.1 has been released end of February 2012? -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-X11-Protocol-Other/f16] Initial import
Summary of changes: 70e4f86... Initial import (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-X11-Protocol-Other/f17] Initial import
Summary of changes: 70e4f86... Initial import (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-X11-Protocol-Other/f18] Initial import
Summary of changes: 70e4f86... Initial import (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Syntax-Highlight-Engine-Kate] Specify all dependencies
commit 1345661601c8f847cfaf0f268a9899ec96b3710d
Author: Petr Písař
Date: Mon Aug 20 16:03:56 2012 +0200
Specify all dependencies
perl-Syntax-Highlight-Engine-Kate.spec |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-Syntax-Highlight-Engine-Kate.spec
b/perl-Syntax-Highlight-Engine-Kate.spec
index e97f44e..2d39151 100644
--- a/perl-Syntax-Highlight-Engine-Kate.spec
+++ b/perl-Syntax-Highlight-Engine-Kate.spec
@@ -7,11 +7,14 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Syntax-Highlight-Engine-Kate/
Source0:
http://www.cpan.org/authors/id/S/SZ/SZABGAB/Syntax-Highlight-Engine-Kate-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl(inc::Module::Install) >= 0.91
+# Run-time:
+BuildRequires: perl(base)
BuildRequires: perl(Carp)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(ExtUtils::MakeMaker) >= 6.42
BuildRequires: perl(File::Basename)
# Tests only:
+BuildRequires: perl(Term::ANSIColor)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -21,6 +24,7 @@ engine of the Kate text editor.
%prep
%setup -q -n Syntax-Highlight-Engine-Kate-%{version}
+rm -r inc/*
rm -rf lib/Syntax/Highlight/Engine/Kate/Alerts
find -type f -exec chmod -x {} +
chmod 644 Changes REGISTERED
@@ -46,6 +50,7 @@ make test
%changelog
* Mon Aug 20 2012 Petr Pisar - 0.06-8
- Modernize spec file
+- Specify all dependencies
* Fri Jul 20 2012 Fedora Release Engineering
- 0.06-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_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
[perl-Syntax-Highlight-Engine-Kate] Modernize spec file
commit 8f47c61f330337dbb89c45e55c0e8314863ea5a4
Author: Petr Písař
Date: Mon Aug 20 15:58:45 2012 +0200
Modernize spec file
perl-Syntax-Highlight-Engine-Kate.spec | 24 +++-
1 files changed, 7 insertions(+), 17 deletions(-)
---
diff --git a/perl-Syntax-Highlight-Engine-Kate.spec
b/perl-Syntax-Highlight-Engine-Kate.spec
index 92b703e..e97f44e 100644
--- a/perl-Syntax-Highlight-Engine-Kate.spec
+++ b/perl-Syntax-Highlight-Engine-Kate.spec
@@ -1,13 +1,11 @@
Name: perl-Syntax-Highlight-Engine-Kate
Version:0.06
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Port to Perl of the syntax highlight engine of the Kate text
editor
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Syntax-Highlight-Engine-Kate/
Source0:
http://www.cpan.org/authors/id/S/SZ/SZABGAB/Syntax-Highlight-Engine-Kate-%{version}.tar.gz
-# http://rt.cpan.org/Public/Bug/Display.html?id=45512
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Carp)
BuildRequires: perl(Data::Dumper)
@@ -23,40 +21,32 @@ engine of the Kate text editor.
%prep
%setup -q -n Syntax-Highlight-Engine-Kate-%{version}
-
rm -rf lib/Syntax/Highlight/Engine/Kate/Alerts
-find -type f -exec chmod -x {} \;
+find -type f -exec chmod -x {} +
+chmod 644 Changes REGISTERED
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT OPTIMIZE="$RPM_OPT_FLAGS"
-
+make pure_install DESTDIR=$RPM_BUILD_ROOT OPTIMIZE="$RPM_OPT_FLAGS"
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
%{_fixperms} $RPM_BUILD_ROOT/*
-chmod 644 Changes
-chmod 644 REGISTERED
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes README REGISTERED
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Aug 20 2012 Petr Pisar - 0.06-8
+- Modernize spec file
+
* Fri Jul 20 2012 Fedora Release Engineering
- 0.06-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_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
multiseat
Hi all, With Fedora having automatic multiseat support, I tried it and had the following issues We've encountered some issues I would consider as somehow security (not like root access, but one user can interfer other users) ones : a) In Gnome you can login as the same user on different seats at the same time with some weird behavior. b) In the gnome-control-center==> Color Management you can play with the settings of a monitor attached to another seat. c) When having two user logged the suspend options conflict. e.g USER 1: lower brightness on monitor if idle for 5 minutes USER 2: user is working. ==> No problem. User 1 - Seat 1 monitor's brightness is correctly lowered on User2's not USER 1: Suspend is set to 5 minutes and USER 1 goes for a cigarette or at lunch :) USER 2: Is working ===> Whole workstation suspend after 5 minutes while USER 2 is working BTW. If you have some pluggable HW for us, we won't say no, in case it suits our need a friend of mine and me will be selling pre-configured fedora multiseat machines in Bulgaria. Cheers, Damian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
Björn Persson xn--rombobjrn-67a.se> writes: > If Bodhi were to be designed for proxy karma it should allow the > maintainer unlimited karma points so that they could act as a proxy for > more than one user. Allowing one proxy karma point but not more than one > would be a quite arbitrary restriction. My personal feeling on that is that proxy karma is rare enough that it's probably better to just handle it the way it is now than to add extra code to Bodhi to do it. Many maintainers wouldn't use their 1 karma point for themselves anyway and could use it for proxy. Otherwise, they can find someone else to do it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
On Mon, Aug 20, 2012 at 8:53 AM, Peter Jones wrote: > On Mon, 2012-08-20 at 12:37 +0100, Richard W.M. Jones wrote: >> https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 >> >> I built the package, and I tested it. Yet doing the right thing means >> my karma doesn't count ... >> >> IMO this change makes the karma system (even) worse than before. > > The assumption has always been that if you didn't think it worked, you > wouldn't prepare an update in the first place. With that in mind, if > you've added karma to your own packages in the past, you've effectively > done so /twice/. Also, that if you submit the update, and then discover a problem, that you retract the update if possible. -J > -- > Peter > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
On Mon, 2012-08-20 at 12:37 +0100, Richard W.M. Jones wrote: > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > I built the package, and I tested it. Yet doing the right thing means > my karma doesn't count ... > > IMO this change makes the karma system (even) worse than before. The assumption has always been that if you didn't think it worked, you wouldn't prepare an update in the first place. With that in mind, if you've added karma to your own packages in the past, you've effectively done so /twice/. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
On Mon, Aug 20, 2012 at 02:23:26PM +0200, Julian Leyh wrote: > If you submit it, it means you already tested and approved it. Karma > from you gives no new (quality) information about the package. It > should be tested by independent people. Not at all. I might not be able to test the update, eg. if I'm fixing a bug for someone else which affects a system that I don't have access to; or if it's a fix for a bug which was reported but I was unable to reproduce. If I give positive karma, it's because I tested the update and found that it fixed the problem, and that's a different situation and certainly new information. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
On Mon, Aug 20, 2012 at 02:17:59PM +0200, Vít Ondruch wrote: > Dne 20.8.2012 13:37, Richard W.M. Jones napsal(a): > >https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > > >I built the package, and I tested it. Yet doing the right thing means > >my karma doesn't count ... > > > >IMO this change makes the karma system (even) worse than before. > > > >Rich. > > > > And if you don't give the karma to your package, we could expect the > opposite? I.e. you don't built it and it is not tested => it does > not work? Take it as a peer review system. If I'm parsing your comment correctly, then: (1) If I don't give any karma, that's because I didn't test the update, or I tested the update but was unable to reproduce the bug (eg. if the bug affected some system which I don't have access to, but there is an upstream fix which seems reasonable to apply). (2) If I give negative karma, that's because I tested the update and found it didn't work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
Stephen Gallagher wrote: > Furthermore, a not-inconsequential consideration is proxy-karma. For > example, I have in the past occasionally given karma +1 (and -1) on my > own packages from users that did not have Fedora accounts (or couldn't > manage to defeat the ogre that is FAS's CAPTCHA). If Bodhi were to be designed for proxy karma it should allow the maintainer unlimited karma points so that they could act as a proxy for more than one user. Allowing one proxy karma point but not more than one would be a quite arbitrary restriction. I'm not advocating this. I'm just pointing out a logical consequence that officially allowing proxy karma would have. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
2012/8/20 Andre Robatino : > Julian Leyh vgai.de> writes: > >> >> 2012/8/20 Richard W.M. Jones redhat.com>: >> > >> > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 >> > >> > I built the package, and I tested it. Yet doing the right thing means >> > my karma doesn't count ... >> > >> > IMO this change makes the karma system (even) worse than before. >> > >> > Rich. >> >> If you submit it, it means you already tested and approved it. Karma >> from you gives no new (quality) information about the package. It >> should be tested by independent people. > > That's not necessarily true. The packager might build for F16, F17, and F18, > say, but not actually have all those systems to test on (even in a VM). So > karma > would in fact give additional information. IMO packagers should be treated the > same as anyone else regarding karma. If they abuse the privilege, it can be > taken away individually, the same as any other tester. Okay, seeing it from this view does make sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
- Original Message - > Julian Leyh vgai.de> writes: > > > > > 2012/8/20 Richard W.M. Jones redhat.com>: > > > > > > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > > > > > I built the package, and I tested it. Yet doing the right thing > > > means > > > my karma doesn't count ... > > > > > > IMO this change makes the karma system (even) worse than before. > > > > > > Rich. > > > > If you submit it, it means you already tested and approved it. > > Karma > > from you gives no new (quality) information about the package. It > > should be tested by independent people. > > That's not necessarily true. The packager might build for F16, F17, > and F18, > say, but not actually have all those systems to test on (even in a > VM). So karma > would in fact give additional information. IMO packagers should be > treated the > same as anyone else regarding karma. If they abuse the privilege, it > can be > taken away individually, the same as any other tester. Exactly! R. > > > -- > 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: What's the reason for not accepting karma from Bodhi submitter
On Mon, 2012-08-20 at 12:28 +, Andre Robatino wrote: > Julian Leyh vgai.de> writes: > > > > > 2012/8/20 Richard W.M. Jones redhat.com>: > > > > > > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > > > > > I built the package, and I tested it. Yet doing the right thing means > > > my karma doesn't count ... > > > > > > IMO this change makes the karma system (even) worse than before. > > > > > > Rich. > > > > If you submit it, it means you already tested and approved it. Karma > > from you gives no new (quality) information about the package. It > > should be tested by independent people. > > That's not necessarily true. The packager might build for F16, F17, and F18, > say, but not actually have all those systems to test on (even in a VM). So > karma > would in fact give additional information. IMO packagers should be treated the > same as anyone else regarding karma. If they abuse the privilege, it can be > taken away individually, the same as any other tester. Furthermore, a not-inconsequential consideration is proxy-karma. For example, I have in the past occasionally given karma +1 (and -1) on my own packages from users that did not have Fedora accounts (or couldn't manage to defeat the ogre that is FAS's CAPTCHA). Not being able to add this karma on their behalf further reduces the available pool of testers (or at least forces me to go find someone else with a Fedora account and ask them to proxy it for me, thus resulting in three layers of indirection). 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: What's the reason for not accepting karma from Bodhi submitter
Julian Leyh vgai.de> writes: > > 2012/8/20 Richard W.M. Jones redhat.com>: > > > > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > > > I built the package, and I tested it. Yet doing the right thing means > > my karma doesn't count ... > > > > IMO this change makes the karma system (even) worse than before. > > > > Rich. > > If you submit it, it means you already tested and approved it. Karma > from you gives no new (quality) information about the package. It > should be tested by independent people. That's not necessarily true. The packager might build for F16, F17, and F18, say, but not actually have all those systems to test on (even in a VM). So karma would in fact give additional information. IMO packagers should be treated the same as anyone else regarding karma. If they abuse the privilege, it can be taken away individually, the same as any other tester. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
2012/8/20 Richard W.M. Jones : > > https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 > > I built the package, and I tested it. Yet doing the right thing means > my karma doesn't count ... > > IMO this change makes the karma system (even) worse than before. > > Rich. If you submit it, it means you already tested and approved it. Karma from you gives no new (quality) information about the package. It should be tested by independent people. If you want to add notes what it fixed, you could have done in the update message. In means of software testing and quality assurance the system is good the way it is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's the reason for not accepting karma from Bodhi submitter
Dne 20.8.2012 13:37, Richard W.M. Jones napsal(a): https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 I built the package, and I tested it. Yet doing the right thing means my karma doesn't count ... IMO this change makes the karma system (even) worse than before. Rich. And if you don't give the karma to your package, we could expect the opposite? I.e. you don't built it and it is not tested => it does not work? Take it as a peer review system. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What's the reason for not accepting karma from Bodhi submitter
https://admin.fedoraproject.org/updates/qemu-1.2-0.3.20120806git3e430569.fc18 I built the package, and I tested it. Yet doing the right thing means my karma doesn't count ... IMO this change makes the karma system (even) worse than before. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-08-20 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-08-20 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We're having a meeting. In, like, five hours. I'm gonna have a hangover. Don't mind me. 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/20120820 The current proposed agenda is included below. == Proposed Agenda Topics == 1. F18 status, mini blocker review 2. AutoQA update 3. 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
