Re: AutoQA: distro congestion?
On Tue, 2011-04-19 at 10:50 +0200, Kevin Kofler wrote: > Axel Thimm wrote: > > Maybe the bodhi messages confused me. When I logon to a.f.o/updates it > > prominently displays: > > > > Bodhi is now enforcing the Package Update Acceptance > > Criteria across all Fedora releases. > > The criteria which are being enforced do not include AutoQA results at this > time. They do, however, include minimum testing (time and/or karma) > requirements, which probably explains why your stable request was rejected. > (And I've been fighting against those requirements since they were first > proposed, because I strongly believe this decision should really be up to > the maintainer, but I lost that battle.) Well, two questions: a) Weren't updates marked as security updates handled specially? E.g. the packages to get tagged as push-requested with the final decision being a pusher's review of the request? b) In the past if karma/time requirements were not met one could still mark the request and the request would show up. Possibly not granted/processed until the requirements were met (unless the package was security related or fixing a too nasty bug), but not immediately cleared as if it never happened (which is the current state). -- http://thimm.gr/ - http://ATrpms.net/ 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: AutoQA: distro congestion?
On Tue, 2011-04-19 at 11:05 +0200, Michael Schwendt wrote:
> You've tried to select "stable" as the target already when submitting
> the updates, and bodhi rejected that. With the CVEs mentioned for Mediawiki,
> why didn't you choose "security" instead of "stable"?
But I did. All packages are marked as "security updates" in their
"type". As a target ("request") you only have the choice "testing" or
"stable" (and "none"). There isn't any from that mentions "security" and
"stable".
E.g. the packages are marked as security updates and whatever the cause,
autoqa, missing karma, missing time, for some reason (partly undisclosed
as mentioned in my post yesterday) bodhi rejects them. IMO if the
packager marks the package as as security update bodhi should stay out
of the way and allow a human to decide on pushing the update or not. ATM
bodhi cuts me off the pushers.
--
http://thimm.gr/ - http://ATrpms.net/
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: AutoQA: distro congestion?
On Tue, 2011-04-19 at 10:54 +0200, Sven Lankes wrote: > On Tue, Apr 19, 2011 at 11:44:03AM +0300, Axel Thimm wrote: > > > This is probably part of the problem, I have been trying to push all 5 > > packages that are now in testing with bodhi rejecting due to autoqa. > > Even packages that do have a positive autoqa tag on them like > > fail2ban-0.8.4-27.fc13. > > According to the Bodhi-Status-Site, you unpushed the update on > 2011-04-17 21:24:29, then submitted it again a few seconds later. Yes, this was after I had desperately tried to push it from testing to stable and at the end tried to resubmit directly to stable. As said previously security updates at least did get their requests noted. > It has been pushed to testing on 2011-04-17 21:24:29 and it now needs to > stay in testing for a week (or until it has reached sufficient karma > including proventester feedback) until it can be pushed to stable. Oh well, it had been in testing for almost a week and I even felt bad about not stable-pushing it earlier as it was a security update. > This is what bodhi refers to with "Bodhi is now enforcing the Package > Update Acceptance Criteria across all Fedora releases." - that text also > links to https://fedoraproject.org/wiki/Package_update_acceptance_criteria This mentions that critical packages and security updates need at least 2 karma points and a proventester, that's even more than setting karma on threshold 1 (???). Is that really the current policy for _security updates_? -- http://thimm.gr/ - http://ATrpms.net/ 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: AutoQA: distro congestion?
On Wed, 2011-04-20 at 11:30 +0300, Axel Thimm wrote: > This mentions that critical packages and security updates need at least > 2 karma points and a proventester, that's even more than setting karma > on threshold 1 (???). Is that really the current policy for _security > updates_? 2 karma points *including* a proventester. That is: 1 proventester + 1 non-pt OR 2 proventester are sufficient. And yes, that is the current policy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2011-04-20)
=== #fedora-meeting: FESCO (2011-04-20) === Meeting started by nirik at 17:30:41 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-04-20/fesco.2011-04-20-17.30.log.html Meeting summary --- * init process (nirik, 17:30:44) * #515 Investigate a "features" repo for stable releases (nirik, 17:34:38) * #517 Updates Metrics (nirik, 17:35:43) * lmacken to run stats and mail to lists for comment (nirik, 17:37:01) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:37:10) * #583: Bless xwax for inclusion in Fedora (nirik, 17:39:15) * AGREED: package is acceptable. Should make sure it meets guidelines otherwise and fix it's error handling. (nirik, 17:42:27) * Beta Kudos (nirik, 17:43:02) * Open Floor (nirik, 17:44:23) * reminder: there is a build system outage later today starting at 20UTC. (nirik, 17:45:40) Meeting ended at 17:51:00 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (45) * mjg59 (11) * zodbot (8) * dgilmore (8) * ajax (6) * gholms (5) * notting (4) * mmaslano (3) * lmacken (1) * SMParrish (0) * kylem (0) * mclasen (0) * cwickert (0) -- 17:30:41 #startmeeting FESCO (2011-04-20) 17:30:41 Meeting started Wed Apr 20 17:30:41 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:41 #meetingname fesco 17:30:41 The meeting name has been set to 'fesco' 17:30:41 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:41 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:44 #topic init process 17:30:54 hi 17:31:35 morning 17:31:39 who all is around for meeting? 17:32:04 * mmaslano is here 17:32:12 * notting is here 17:32:24 Hi 17:34:12 hello irc 17:34:27 cool. I think thats quorum 17:34:38 #topic #515 Investigate a "features" repo for stable releases 17:34:38 .fesco 515 17:34:39 nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:34:44 cwickert: any news on this? 17:35:36 I guess we skip this again for this week... 17:35:43 #topic #517 Updates Metrics 17:35:43 .fesco 517 17:35:48 nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517 17:35:55 no real takers on driving this task that I know of currently either. 17:36:14 lmacken: would it make sense to do another run of the bodhi stats and send out to lists? 17:36:23 might get people interested in it.. 17:36:38 nirik: yeah, will do 17:36:53 cool. 17:37:01 #info lmacken to run stats and mail to lists for comment 17:37:10 #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:37:10 .fesco 563 17:37:12 nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:37:19 * nirik looks for kylem 17:39:08 guess he's not around... 17:39:15 #topic #583: Bless xwax for inclusion in Fedora 17:39:15 .fesco 583 17:39:16 nirik: #583 (Bless xwax for inclusion in Fedora) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/583 17:39:30 I'm not really clear on this one 17:39:43 It seems to be "It works, but will crash if it's fed encumbered files" 17:39:55 Which sounds like a bug, not anything we have to care about 17:39:57 it looks more like balk than crash. 17:40:12 yeah, doesn't really seem different than other things, other than being a bit more unfriendly about it 17:40:13 So I'd say "Yes, it can go in Fedora, but fix it to not suck" 17:40:16 * notting is +1 to allow it 17:40:34 yes +1 17:40:35 regardless, as someone who owns a rane mixer and a copy of serato, i'd actually be interested in playing with this someday 17:40:41 yeah, +1 here too... fixing it would be good too. 17:40:42 +1 17:40:46 And things like 17:40:50 "It has no .desktop file" 17:41:04 Seem to just imply that someone should write one 17:41:08 Anyway, not our problem 17:42:27 #agreed package is acceptable. Should make sure it meets guidelines otherwise and fix it's error handling. 17:43:02 #topic Beta Kudos 17:43:09 Beta went out yesterday. 17:43:26 I'd like to thank everyone who worked on it. I think it's a pretty solid beta this time. ;) 17:43:49 Yup 17:43:59 F15 is shaping up nicely 17:44:23 #topic Open Floor 17:44:29 anyone have anything for open floor? 17:44:40 * nirik digs these short meetings... :) 17:44:47 How close has this meeting come to the previous one? :P 17:45:40 #info reminder: there is a build system outage later today starting at 20UTC. 17:46:00 this one is just a tiny bit longer I think. 17:46:08 nirik: didn't want to move it up
Package with x86 vector instruction support
I've got a question whose answer I expected to find on one of these pages, but no joy: https://fedoraproject.org/wiki/Architectures https://fedoraproject.org/wiki/Architectures/x86 https://fedoraproject.org/wiki/Architectures/x86-64 I'm packaging a library that does some heavy mathematical computations. The build system tries to cleverly determine whether an Intel CPU with vector instructions is being used. Until I can convince upstream to do this at runtime, I'll need to build the package (a library) for the lowest common denominator. The package checks for MMX, SSE, SSE2, SSE3, and SSSE3. For i686, can I assume MMX? SSE? I believe I can also build an SSE2 version of the library and drop it into /usr/lib/sse2. How about for x86_64? Can I assume SSE2 is available? (I thought I could, but I see that /usr/lib64/sse2 exists on my machine, so now I'm uncertain.) I don't see a /usr/lib64/sse3 or /usr/lib64/ssse3, so I just have to forget those, right? If there is a wiki page that answers these questions, I'd appreciate a pointer. If not, perhaps someone with edit privileges could add the answer to one of the pages listed above. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can someone reach Doug Warner (silfreed)
On Mon, 18 Apr 2011 14:54:49 +0200 Matthias Runge wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > the subject says it: Is someone able to reach Douglas Warner? > I hope, he's ok, but it looks like, he's very busy. Yeah, I hope he's ok too. > He sought help for maintenance of syslog-ng [1], which I offered. This > was his last post on devel-list (dated Feb. 2, 2011), but I may be > wrong. His last build in koji is much older. Since then, I tried to > reach him three times privately and got one answer on Feb. 24 (where > he applied me for commiting to syslog-ng). ok. > Recently, syslog-ng upstream contacted the maintainers to get the > latest version into fedora. To get syslog-ng built in latest version, > I also need to update eventlog. > > There are already bug reports for eventlog [2] and syslog-ng [3] > requesting for package update. Since those bug reports are unanswered > from Doug, I assume he might be too busy for a solution. > > How to proceed for now? ok, so you have commits for eventlog, but not syslog-ng? Go ahead and apply for those and I can approve you if Doug does not. I'll email him as well... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA: distro congestion?
On Wed, 20 Apr 2011 11:02:12 +0300
Axel Thimm wrote:
> On Tue, 2011-04-19 at 11:05 +0200, Michael Schwendt wrote:
> > You've tried to select "stable" as the target already when
> > submitting the updates, and bodhi rejected that. With the CVEs
> > mentioned for Mediawiki, why didn't you choose "security" instead
> > of "stable"?
>
> But I did. All packages are marked as "security updates" in their
> "type". As a target ("request") you only have the choice "testing" or
> "stable" (and "none"). There isn't any from that mentions "security"
> and "stable".
Right. Security updates aren't allowed to just go direct to stable
either.
> E.g. the packages are marked as security updates and whatever the
> cause, autoqa, missing karma, missing time, for some reason (partly
> undisclosed as mentioned in my post yesterday) bodhi rejects them.
> IMO if the packager marks the package as as security update bodhi
> should stay out of the way and allow a human to decide on pushing the
> update or not. ATM bodhi cuts me off the pushers.
Sadly, this is not practical.
Several points to note:
The various update streams flow differently. For a normal day,
EPEL4/5/6 might have about 2-20 updates. It might be practical to look
at all these for a quick glance. f14 (updates and testing) has around
30-50ish. f13 has around 5-20, and f15 has too many to even count. ;)
It's just not at all practical to have the people signing the updates
look at each one for critera.
We have had security updates that caused considerable problems. If the
update is an important one, enlist users of that software to help test
and +1 it.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update of fedpkg coming to handle new branch names
On 4/19/11 2:39 PM, Severin Gehwolf wrote: > Could you please let us know once the new branch naming scheme is > available on the staging server? stg has the new branch names for now. The repo content is a bit stale though. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA: distro congestion?
On Wed, 20 Apr 2011 06:15:43 + (UTC), AR wrote: > Andre Robatino fedoraproject.org> writes: > > > > But if the user just wants to revoke their karma by changing their +/-1 to > > a 0 > > (say they realize they're not able to test properly, which happened to me), > > that's still not possible (see https://fedorahosted.org/bodhi/ticket/296 ). > > So > > it's necessary to get someone else to cancel it out, and it doesn't matter > > who. > > Sorry to respond to myself, but there's another relevant bug here: due to > https://bugzilla.redhat.com/show_bug.cgi?id=612328 , bodhi email notification > only works for users with working fp.o email aliases, which requires being in > at > least one non-CLA group. A user might simply be unresponsive, or due to this > bug, may not even be contactable to ask them to change their karma. Anonymous users' votes don't add to the karma level. Their votes are just informative. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA: distro congestion?
Michael Schwendt gmail.com> writes: > Anonymous users' votes don't add to the karma level. > Their votes are just informative. Not being in a non-CLA group != anonymous. Anyone can create a bodhi account and log in, but unless they're in a non-CLA group, their fp.o email doesn't work and they get no bodhi email (at least that was true last time I checked). (Sorry for the excessive pruning, have to make gmane happy.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: can someone reach Doug Warner (silfreed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/04/11 20:18, Kevin Fenzi wrote: > On Mon, 18 Apr 2011 14:54:49 +0200 > Matthias Runge wrote: > Thank you for your offer. Doug answered my mail and approved me. Recently I built latest versions of eventlog and syslog-ng for rawhide. I think, I'll build them for F15, too. syslog-ng is the only package requiring eventlog. No package requires syslog-ng, so it shouldn't break anything. Matthias >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, > > ok, so you have commits for eventlog, but not syslog-ng? > > Go ahead and apply for those and I can approve you if Doug does not. > I'll email him as well... > > kevin > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNry7kAAoJEOnz8qQwcaIWTdsH/1pvV5dA5vv90fAEKEaQ0zfS 02Qf9hXI8dSr7S9xlJS9ABQclTdwRVkvT1z2JPkoYmb2CIqpGRvhhDdyCxPRXblz 016iRg49upxD4byJyN0kQIdOzKgfNA+AX8HNW2SOqJJZYPBc2jEFchuB0DYSuheI wsSvVoy5FZLt1jBxbUcWkbe42AuBnYDzNgTAbXF5TFKLMSDKAZVu4LiBPHekEWxC Q9dauUfEJZLWzWdtoDi7c22vl5gUJdwTU7jZL7nucCGzYdPL5zvhcbJf/VpNdNh0 mBBZeD/NdMPhe31nJXpdb1JS/MOcOuUG0Iv97zFHBXbvpXv68XAIYgRCb7OjB2A= =8UOD -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-04-21 @ 17:00 UTC - F-15 blocker bug review #2
# F15 Blocker Review meeting #2 # Date: 2011-04-21 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Due to upcoming holidays, the second F15 Final blocker review meeting will be this Thursday at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F-15 blocker bugs. As usual, an updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. The list of bugs is also attached to this mail. We'll be reviewing the bugs to determine ... 1. whether they meet the Final release criteria [2] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, checkout ... https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the F15 Beta release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and is available as a bodhi update. Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * If a bug is in ON_QA ... please take a moment to apply the update, and post karma feedback [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria Thanks, James == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 4 bugs affecting 4 components. === anaconda === * https://bugzilla.redhat.com/695389 (MODIFIED) - Traceback when writing a kickstart for an unused lvm-on-raid (TypeError: 'NoneType' object is not subscriptable) === desktop-backgrounds === * https://bugzilla.redhat.com/696832 (ON_QA) - Default Install of F15-desktop does not contain fedora desktop as default === nautilus === * https://bugzilla.redhat.com/689260 (NEW) - [abrt] nautilus-2.91.91-1.fc15: gtk_action_group_add_action: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV) === system-config-services === * https://bugzilla.redhat.com/682001 (ASSIGNED) - s-c-services - all read and disabled == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 14 bugs affecting 12 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_blocker_bug_process]]. === NetworkManager === * https://bugzilla.redhat.com/696278 (NEW) - The system network services are not compatible with this version. === NetworkManager-openconnect === * https://bugzilla.redhat.com/696107 (ON_QA) - NetworkManager Openconnect fails in FC15 Alpha === gdm === * https://bugzilla.redhat.com/678236 (NEW) - User list sometimes not visible on greeter === gnome-menus === * https://bugzilla.redhat.com/697834 (NEW) - Other menu appears in default installation === gnome-session === * https://bugzilla.redhat.com/698184 (NEW) - Enabling session saving with Gnome shell makes GUI login unusable === gnome-themes-standard === * https://bugzilla.redhat.com/674799 (ON_QA) - Isn't dragged in for upgrades === gstreamer === * https://bugzilla.redhat.com/695730 (NEW) - PackageKit doesn't find codecs === ibus === * https://bugzilla.redhat.com/696510 (MODIFIED) - need a dependency in ibus-gtk3 for imsettings-gnome === imsettings === * https://bugzilla.redhat.com/693809 (ASSIGNED) - Error message about missing input methods should be removed === kernel === * https://bugzilla.redhat.com/693442 (NEW) - NETDEV WATCHDOG: em1 (sky2): transmit queue 0 timed out === ntfs-3g === * https://bugzilla.redhat.com/697008 (NEW) - Include the latest ntfs-3g package in the final F-15 compose === systemd === * https://bugzilla.redhat.com/678555 (NEW) - systemd should not purge application created cgroups, even if they contain no processes * https://bugzilla.redhat.com/692230 (NEW) - Non-root iSCSI volumes are not mounted on boot * https://bugzilla.redhat.com/696320 (NEW) - After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console == Approved NICE-TO-HAVE == The following list of of bugs are approved nice-to-have. Fixes for nice-to-have bugs will be accepted during the freeze. There are 3 bugs affecting 3 components. === gdm === * https://bugzilla.redhat.com/678236 (NEW) - User list sometimes not visible on greeter === lockdev === * https://bugzilla.redhat.com/681898 (ON_QA) - DON'T make /var/lock/lockdev world writeable (security issue) === report === * https://bugzilla.redhat.com/696240 (ON_DEV) - report is filing Fedora 15 installer bugs against rawhide (not Fedora 15) == Proposed NICE-TO-HAVE == The following list of bugs are not yet approved nice-to-have issues. Only fixes for approved nice-to-have bugs will be accepted during the freeze. There are
Re: AutoQA: distro congestion?
On 04/20/2011 02:54 PM, Andre Robatino wrote: > (Sorry for the excessive pruning, have to make gmane happy.) Pardon me for pontificating, but your pruning was perfect. Too many posts technically use interleaved quoting, but render it useless by failing to trim the quoted material. The purpose of quoting is to provide context---so it requires some care in editing the quotes. People who don't trim quotes might as well top-post---there's no benefit in bottom posting if it simply follows the entire quoted message, and top posting makes it actually easier to read the new material. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update of fedpkg coming to handle new branch names
On Wed, 2011-04-20 at 11:33 -0700, Jesse Keating wrote: > On 4/19/11 2:39 PM, Severin Gehwolf wrote: > > Could you please let us know once the new branch naming scheme is > > available on the staging server? > > stg has the new branch names for now. The repo content is a bit stale > though. Thanks, Jesse. --Severin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (698428) Make auto membership use Slapi_DN for DN comparisons
https://bugzilla.redhat.com/show_bug.cgi?id=698428 https://bugzilla.redhat.com/attachment.cgi?id=493636&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Package with x86 vector instruction support
On 4/20/11 1:59 PM, Jerry James wrote: > I'm packaging a library that does some heavy mathematical > computations. The build system tries to cleverly determine whether an > Intel CPU with vector instructions is being used. Until I can > convince upstream to do this at runtime, I'll need to build the > package (a library) for the lowest common denominator. The package > checks for MMX, SSE, SSE2, SSE3, and SSSE3. For i686, can I assume > MMX? SSE? The least capable processor we've gone out of our way to fix things for is the AMD Geode GX, which has MMX and 3DNow, but is also slightly less than a proper Pentium Pro in that it doesn't have nopl or cmov. However, rpm sets --march=i686, which implies only Pentium Pro and does not imply MMX or anything newer. Not that I know of anyone who's tried running Fedora on a bare i686 in recent memory. > I believe I can also build an SSE2 version of the library > and drop it into /usr/lib/sse2. How about for x86_64? Can I assume > SSE2 is available? (I thought I could, but I see that /usr/lib64/sse2 > exists on my machine, so now I'm uncertain.) I don't see a > /usr/lib64/sse3 or /usr/lib64/ssse3, so I just have to forget those, > right? All AMD64 and compatible chips support SSE and SSE2, correct. I'm reasonably sure that path is simply for symmetry with i686 in case some application was relying on it. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA: distro congestion?
Kevin Fenzi wrote: > On Wed, 20 Apr 2011 11:02:12 +0300 > Axel Thimm wrote: > >> E.g. the packages are marked as security updates and whatever the >> cause, autoqa, missing karma, missing time, for some reason (partly >> undisclosed as mentioned in my post yesterday) bodhi rejects them. >> IMO if the packager marks the package as as security update bodhi >> should stay out of the way and allow a human to decide on pushing the >> update or not. ATM bodhi cuts me off the pushers. > > Sadly, this is not practical. > > Several points to note: > > The various update streams flow differently. For a normal day, > EPEL4/5/6 might have about 2-20 updates. It might be practical to look > at all these for a quick glance. f14 (updates and testing) has around > 30-50ish. f13 has around 5-20, and f15 has too many to even count. ;) > It's just not at all practical to have the people signing the updates > look at each one for critera. The human making the decision should be the maintainer. That's what the maintainer is for. > We have had security updates that caused considerable problems. We've had one such instance in years of Fedora. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA: distro congestion?
Adam Williamson wrote: > 2 karma points *including* a proventester. That is: > > 1 proventester + 1 non-pt > > OR > > 2 proventester > > are sufficient. And yes, that is the current policy. Uh, that's the current policy for critical path packages, not for non- critical packages which require only the autokarma set by the maintainer (which can be as low as 1) to be reached. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On Wed, Apr 20, 2011 at 3:32 PM, Adam Jackson wrote: > The least capable processor we've gone out of our way to fix things for is > the AMD Geode GX, which has MMX and 3DNow, but is also slightly less than a > proper Pentium Pro in that it doesn't have nopl or cmov. > > However, rpm sets --march=i686, which implies only Pentium Pro and does not > imply MMX or anything newer. Not that I know of anyone who's tried running > Fedora on a bare i686 in recent memory. OK, that's fine. I'll compile without any of the fancy vector instructions for i686, then explicitly pass an -march arg of my own (I see some other packages use -march=pentium4) for the version that will live in /usr/lib/sse2. For x86_64, I'll make sure that SSE3 and SSSE3 support is off and let it do its thing otherwise. Thanks, Ajax! -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On 4/20/11 5:57 PM, Jerry James wrote:
> On Wed, Apr 20, 2011 at 3:32 PM, Adam Jackson wrote:
>> The least capable processor we've gone out of our way to fix things for is
>> the AMD Geode GX, which has MMX and 3DNow, but is also slightly less than a
>> proper Pentium Pro in that it doesn't have nopl or cmov.
>>
>> However, rpm sets --march=i686, which implies only Pentium Pro and does not
>> imply MMX or anything newer. Not that I know of anyone who's tried running
>> Fedora on a bare i686 in recent memory.
>
> OK, that's fine. I'll compile without any of the fancy vector
> instructions for i686, then explicitly pass an -march arg of my own (I
> see some other packages use -march=pentium4) for the version that will
> live in /usr/lib/sse2. For x86_64, I'll make sure that SSE3 and SSSE3
> support is off and let it do its thing otherwise.
There do exist amd64 chips with sse3 and above. I don't know offhand
whether there's a %{_libdir}/sse3 for them, though I'd not be surprised
and I suspect a quick read of the ld.so source would tell you.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110420 changes
Compose started at Wed Apr 20 13:15:55 UTC 2011 Broken deps for x86_64 -- collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16()(64bit) collectd-mysql-4.10.2-2.fc15.x86_64 requires libmysqlclient.so.16(libmysqlclient_16)(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-2.91.90-1.fc15.x86_64 requires libchamplain-0.10.so.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog) glom-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glom-libs-1.16.1-2.fc15.i686 requires libgdamm-4.0.so.12 glom-libs-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnome-themes-2.32.0-5.fc15.noarch requires gtk-theme-engine-clearlooks gnomeradio-1.8-9.fc15.x86_64 requires libgtk-3.0.so.0()(64bit) gnomeradio-1.8-9.fc15.x86_64 requires libgdk-3.0.so.0()(64bit) gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 re
Re: Package with x86 vector instruction support
On Wed, 20 Apr 2011 11:59:18 -0600 Jerry James wrote: > I'm packaging a library that does some heavy mathematical > computations. The build system tries to cleverly determine whether an > Intel CPU with vector instructions is being used. What package are we talking about? There is already at least one package in Fedora which does a similar thing: ATLAS. It normally automatically tunes itself for the optimal build flags, so some special tricks have to be done for packaging. ATLAS has currently the following versions on Fedora: i686: plain, 3dnow, sse, sse2 and sse3 x86_64: plain and sse2 The plain stands for the "atlas" package. I don't know what flags it uses. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On Wed, Apr 20, 2011 at 5:27 PM, Jussi Lehtola wrote: > What package are we talking about? > > There is already at least one package in Fedora which does a similar > thing: ATLAS. It normally automatically tunes itself for the optimal > build flags, so some special tricks have to be done for packaging. > > ATLAS has currently the following versions on Fedora: > > i686: plain, 3dnow, sse, sse2 and sse3 > x86_64: plain and sse2 > > The plain stands for the "atlas" package. I don't know what flags it > uses. I"m trying to update the m4ri package, which now does such tricks. Thanks for the pointer. I'll look at the atlas spec file and see how it's done there. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing the release of Fedora 15 Beta!!
> Coders have lots of new development tools to try out, including: > * Updates to popular languages. Python 3.2, Rails 3.0.3, and > OCaml 3.12 are all included in Fedora 15. If we are going to mention OCaml then to be fair can we please also mention GHC 7.0.2, which is major new version upgrade since F14? Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
