Re: Fedora Board, FESCo FAmSCo Elections - Voting Information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 04, 2009 at 07:19:42PM -0500, Nigel Jones wrote: Please Note There will be a Fedora Infrastructure outage during the voting period that may effect the voting application, as a result we have brought the voting start date forward to the 5th December instead of the 8th December. As announced by Paul Frields in the event of extended outage, we will as appropriate extend the voting period. We have also implemented a new feature in our voting software, so users can verify their votes. Vote verification can be done at: https://admin.fedoraproject.org/voting/verify You will be prompted for your Fedora Account System username and password and a list of elections where votes have been recorded will be listed. For more information please refer to: Fedora Infrastructure Outage Information: * https://www.redhat.com/archives/fedora-announce-list/2009-December/msg0.html * https://fedorahosted.org/fedora-infrastructure/ticket/1845 Contingency plans in case of extended outage: * https://www.redhat.com/archives/fedora-advisory-board/2009-December/msg00014.html * The series of outages have been very short overall, but upper estimates of various outages possibly affecting the voting application are close to 8 hours. Therefore, in keeping with our contingency plan, the voting period for the Board, FESCo, and FAmSCo elections will be extended by one additional day. These elections now end on 2009-12-16 UTC 2359. - -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLJlMarNvJN70RNxcRAr+nAJ4mrm1hOvNLoafJBJVCSLbJDRs6vACeOc2H VG/6jW/S+2E1rqDLX5Uganw= =DbVy -END PGP SIGNATURE- -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Fedora Weekly News 206
* 1 Fedora Weekly News Issue 206 o 1.1 Announcements + 1.1.1 FEDORA BOARD, FESCO FAMSCO ELECTIONS + 1.1.2 FEDORA DEVELOPMENT ANNOUNCEMENTS # 1.1.2.1 Fedora 10 final updates cutoff: December 11 + 1.1.3 FEDORA EVENTS # 1.1.3.1 Upcoming Events # 1.1.3.2 Past Events o 1.2 Ambassadors + 1.2.1 Fedora 12 release party in Athens, Greece + 1.2.2 Fedora 12 release party in Caracas, Venezuela + 1.2.3 Fedora Ambassadors active in Tunisia + 1.2.4 FAmSCo election now open: Vote + 1.2.5 Fedora 12 is here o 1.3 QualityAssurance + 1.3.1 Test Days + 1.3.2 Weekly meetings + 1.3.3 FUDCon Toronto + 1.3.4 BugZappers triaged bugs policy change + 1.3.5 Release criteria revision + 1.3.6 Bugzilla 3.4 public beta + 1.3.7 Fedora 13 schedule + 1.3.8 Fedora 13 Alpha release notes o 1.4 Translation + 1.4.1 Fedora 13 Schedule Draft Discussion + 1.4.2 FLSCo Election Proposed + 1.4.3 Update About translate.fedoraproject.org Issues + 1.4.4 Mentoring of New Members o 1.5 Artwork + 1.5.1 Goddard Ahead + 1.5.2 Improving the Fedora Community Website o 1.6 Security Advisories + 1.6.1 Fedora 12 Security Advisories + 1.6.2 Fedora 11 Security Advisories + 1.6.3 Fedora 10 Security Advisories - Fedora Weekly News Issue 206 - Welcome to Fedora Weekly News Issue 206[1] for the week ending December 13, 2009. What follows are some highlights from this issue. This week's issue kicks off with an announcement that the Fedora-related voting has been extended one day due to some infrastructure outages. There is still time to vote, if you haven't yet! In news from Ambassadors, details on Fedora 12 release parties in Greece and Venezuela, and an Ambassadors update from Tunisia. Also a reminder to vote before the end of today in the FAMSco elections. In Quality Assurance news, we have a special double issue for you, including details from the latest weekly meetings, a report on QA activities at FUDCon Toronto last weekend, and early news on Fedora 13 work. In Design news, early details on Goddard theming and looks toward updating the Fedora community website. Security Advisories brings us up to date on the latest security patches for F10 through F12. We hope you enjoy FWN 206! If you are interested in contributing to Fedora Weekly News, please see our 'join' page[2]. We welcome reader feedback: fedora-news-l...@redhat.com FWN Editorial Team: Pascal Calarco, Adam Williamson 1. http://fedoraproject.org/wiki/FWN/Issue206 2. http://fedoraproject.org/wiki/NewsProject/Join -- Announcements -- In this section, we cover announcements from the Fedora Project, including general announcements[1], development announcements[2] and Events[3]. Contributing Writer: Pascal Calarco 1. http://www.redhat.com/archives/fedora-announce-list/ 2. http://www.redhat.com/archives/fedora-devel-announce/ 3. http://fedoraproject.org/wiki/Events --- FEDORA BOARD, FESCO FAMSCO ELECTIONS --- Paul W. Frields announced[1] that elections for the Fedora Board, FESCo and FAmSCo would be extended one day, now ending at 2009-12-16 UTC 2359. As a reminder: All groups have chosen to use the Range Voting method [2] Ballots may be cast on the Fedora Elections System at [3]. If this is the first time you've used the voting system, please refer to the Fedora Elections Guide, currently located at [4]. Fedora Board Election: This election, the Fedora Board is electing two candidates and will appoint another two members. Vacating the seats on the board this election are elected representatives Matt Domsch Bill Nottingham, and appointed representatives Christoher Aillon and Dimitris Glezos[5]. The candidates for this election, in alphabetical order are: * Chris Tyler (ctyler) * Colin Walters (walters) * Matt Domsch (mdomsch) * Steven M. Parrish (SMParrish) To vote, you must have a signed Contributor License Agreement (CLA). Vote Here: [6] Town Hall Logs: [7] [8] Fedora Engineering Steering Committee Election: For this election, FESCo will be electing four candidates to sit on the committee. Vacating the seats on FESCo this election are Jon Stanley, Dan Horák, Jarod Wilson, and David Woodhouse. The candidates for this election, in alphabetical order are: * Adam Jackson (ajax) * Christoph Wickert (cwickert) * Justin M. Forbes (jforbes) * Matthew Garrett (mjg59) * Peter Jones (pjones) * Richard June (rjune) * Robert Scheck (rsc) To vote, you must have a signed
X509 login patches
Hi all and welcome me to the list :), i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the username of the user there are cases (like in our PKI) where CN is just Christos Triantafyllidis and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have EnvVarForUserName = SSL_CLIENT_S_DN which uses the whole DN as username. b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution. I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them. Best regards, Christos Triantafyllidis [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git smime.p7s Description: S/MIME cryptographic signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: X509 login patches
On Mon, Dec 14, 2009 at 8:03 PM, Christos Triantafyllidis ct...@grid.auth.gr wrote: Hi all and welcome me to the list :), i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the username of the user there are cases (like in our PKI) where CN is just Christos Triantafyllidis and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have EnvVarForUserName = SSL_CLIENT_S_DN which uses the whole DN as username. What did you do about the email address? It normally uses c...@configured.org I should look at the patch of course. Steve b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution. I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them. Best regards, Christos Triantafyllidis [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Steve Traylen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: X509 login patches
On 12/14/2009 02:03 PM, Christos Triantafyllidis wrote: Hi all and welcome me to the list :), Welcome, and thanks for the patches! Comments in-line. i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the username of the user there are cases (like in our PKI) where CN is just Christos Triantafyllidis and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have EnvVarForUserName = SSL_CLIENT_S_DN which uses the whole DN as username. koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see DNUsernameComponent=DN special-cased to mean use the whole DN. I don't see any env. vars other than DN that would be useful for authentication. b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution. This looks very interesting, thanks. I'll see about testing it locally and merging it. I wonder if this could be extended to integrate with gnome-keyring (or similar) to provide once-per-session login for SSL certificates. I'll look into this. I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them. Best regards, Christos Triantafyllidis [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: X509 login patches
Hi Mike, first of all i need to clarify that i'm not koji expert (as i said i'm using it only a few weeks). On Dec 14, 2009, at 9:42 PM, Mike Bonnet wrote: koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see DNUsernameComponent=DN special-cased to mean use the whole DN. I don't see any env. vars other than DN that would be useful for authentication. Hm that sounds like a cleaner approach! Thanks. I'm going to implemented probably later today... One special case that i can think is if one would like to use the issuer's DN or any part of it but this is not the case for me so i can skip it. One case that (i think) is not covered even from my approach though is the usage of an X509 extension of the certificate (i.e. the SubjectAlternativeNames) but for now i can live without them. Christos smime.p7s Description: S/MIME cryptographic signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: What is public/private fork? - Criteria packaging in fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, So taking into consideration all the feed back , here are the changes done: - - bump soname in the code from 1.2.11 to 1.2.12 - - In the srpm, libtar-ng now obsoletes libtar, so that the conflicts are resolved. - - Tar ball is bz2 and not gzip to save space. - - The autom4te.cache dir is now removed. - - License changes from MIT to BSD as per the original suggestion of the author. - - Removed README.new from the tar and updated README with new code details, Also updated COPYRIGHT, while retaining the original clauses. SPEC: http://huzaifas.fedorapeople.org/spec/libtar-ng.spec SRPM: http://huzaifas.fedorapeople.org/srpms/libtar-ng-1.2.12-1.fc12.src.rpm Any more comments/suggestions would be welcome. Kevin Kofler wrote: Huzaifa Sidhpurwala wrote: I have forked libtar as libtar-ng, because the upstream does not have time to maintain it anymore. Here is the bz: https://bugzilla.redhat.com/show_bug.cgi?id=546169 Now the question is what is a private fork? Am i wrong in forking it and packaging in fedora? IMHO, this should be packaged, and in a way to Obsoletes/Provides: libtar as it's backwards-compatible and actually actively maintained unlike libtar. The Obsoletes/Provides should of course be versioned, so if a new libtar springs up at a later point (i.e. if the maintainer really goes back to actively developing it), it can be introduced instead of or in addition to the fork. Kevin Kofler - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLJfeNzHDc8tpb2uURAmAPAJ95Bi1pavbb9YmT6vfksjHzgf59rgCfXm75 E+X/Aa6LF+RwXiq7ExupLUQ= =oSV4 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Ralf Ertzinger wrote: It does. There may not be a yum repo for it, but the last update was some days ago to 10.0 r42, similar to the 32 bit version. There is an unofficial yum repo for 64-bit flash-plugin: http://forums.fedoraforum.org/showthread.php?t=205642 signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 08:06, Josephine Tannhäuser a écrit : 2009/12/6, Adrian Reber adr...@lisas.de: https://bugzilla.redhat.com/show_bug.cgi?id=544720 This is not a lib! The guidelines should be read as: « Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons » (Just IMHO, that's the guidelines spirit, the guidelines text should be amended in a non-library-oriented wording, libs are the most common case but they're not the only one) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit : As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. The worst case I've seen reported is when the RAM overhead managed to annihilate register improvements (worst case in a very specific load). So RAM overhead is pretty much a urban myth on x86_64 -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Need a sponsor to review my packages
Hi The qtiplot hasn't been maintained since 20081215, see http://koji.fedoraproject.org/koji/packageinfo?packageID=5171. I want to sync qtiplot version with upstream. I need a sponsor to review the following two packages, which are required by qtiplot 0.9.7.10: https://bugzilla.redhat.com/show_bug.cgi?id=liborigin2 https://bugzilla.redhat.com/show_bug.cgi?id=542313 Later if possible, I would like to be a comaintainer for qtiplot. Anyone can help me? Qtiplot may be the best opensource alternatives of origin. Thanks Chen Lei -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Hi On 12/14/2009 04:56 AM, Nathanael Noblet wrote: As a DBA / Developer, I second this... obviously I can't complain because they are both free. However the setup/configuration of postgreSQL compared to MySQL is basically something easy, versus something where I don't have a clue what is going on, and there are million ways to do it, and when I'm done I have no idea if I'm wide open to the entire world, or as secure as on MySQL. There are a few other odd bits too, I mean I really don't get the purpose of copying template1, what is that? etc etc etc... MySQL is just more intuitive. I agree on that, and a major problem with PostgreSQL at the moment is that it doesn't have a clustering engine. So MySQL is still the simplest choice out there for the end user. Steven -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Le Lun 14 décembre 2009 00:20, Bruno Wolff III a écrit : On Sun, Dec 13, 2009 at 19:02:55 -0200, Henrique Junior henrique...@gmail.com wrote: By the way, Monty is asking for some Help saving MySQL [0]. Monty can just go and fork it. The only limitation is that he won't be able to dual license it any more. Yes, unfortunately a lot of the noise against the SUN/Oracle merger is people that just want the licensing changed because they can't imagine building a successful company on GPL software (very sad). The same kind of people splintered the open source Java community by refusing to help sun when it GPL-ed the JVM and diverting resources to new projetcs instead. That being said, Mysql *does* compete with Oracle (not technically, but commercially very much so, it kills the use one db everywhere corp market paradigm where Oracle is all too happy to count cpus for lots of small Oracle databases), and this competition relies on the Mysql brand (that finally managed to reach CTO awareness level), and Oracle getting its hand on the brand would definitely lower competition for several years (and I don't have any SAP or other shares). -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What is public/private fork? - Criteria packaging in fedora
On Mon, 14 Dec 2009 14:00:06 +0530, Huzaifa wrote: Hi, So taking into consideration all the feed back , here are the changes done: - - bump soname in the code from 1.2.11 to 1.2.12 Please, with further comments on this package let's limit ourselves to one place only. _Eiter_ the review request ticket _or_ this list, but no cross-comment madness which requires answers in multiple places. With that said, 1.2.12 has not touched the SONAME at all. http://bugzilla.redhat.com/546169 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
2009/12/14, Nicolas Mailhot nicolas.mail...@laposte.net: The guidelines should be read as: « Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons » This is more a wishful thinking than a practical thing The guidelines should be a system of rules without place for everyone to interprete in it what he/she wants to see in the guidelines. -- Josephine Fine Tannhäuser 2.6.31.5-127.fc12.i686.PAE -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 11:28, Josephine Tannhäuser a écrit : 2009/12/14, Nicolas Mailhot nicolas.mail...@laposte.net: The guidelines should be read as: « Bundling any other component your component depends on in the same package is forbidden; each component should be packaged separately in its own package for legal and maintenance reasons » This is more a wishful thinking than a practical thing The guidelines should be a system of rules without place for everyone to interprete in it what he/she wants to see in the guidelines. I don't have the time right now but I personally would not hesitate to propose this as a formal packaging guideline if FPC feels it is not what the current guidelines intended (but did not express cleanly). Every domain I've packaged has the same recurring maintenance problems with bundled components (be it libraries, java jars, reference files), there is nothing library specific in the problems bundling causes (forking, non tracking of upstream fixes, conflicts, etc) So, you may think this is wishful thinking, but on my experience it is a very practical and pragmatic rule. Bundling helps you get new components in fast and then makes package maintenance a burden forever (years after years). -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
That's assuming that the footprint of libraries relative to distinct applications is large enough to cancel out the space savings. (I have no data either way). A 64bit kernel doesn't need any 32bit userspace. An X server, on my 32bit system has about 8.5MB of programme text (server and libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. Regarding shared libraries its worth noting the point about Instruction pointer relative data access: http://en.wikipedia.org/wiki/X86-64#Architectural_features Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
of course this is a practicable rule, BUT the problem is upstream or the rule itself. kernels internal zlib is not a lib its a module, wordpress internal php-gettext is not a lib, its a php code file. The trick is to declare that a lib is not a lib and you can close the bug as not a bug... Easy cake.. -- Josephine Fine Tannhäuser 2.6.31.5-127.fc12.i686.PAE -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 10:27 AM, Nicolas Mailhot wrote:
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit :
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
much in the real world.
The worst case I've seen reported is when the RAM overhead managed to
annihilate register improvements (worst case in a very specific load). So RAM
overhead is pretty much a urban myth on x86_64
It's not an urban myth - Conversely, it can quite easily be proven:
int main()
{
long i;
void *array[100];
for ( i = 0; i 100; i++ ) {
array[i] = (void*) i;
};
while(1) {};
}
Compile this snippet for -m64/-m32:
# gcc -m64 -o test-64 -Wall test.c
# gcc -m32 -o test-32 -Wall test.c
Then run them and watch memory consumption (here top):
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5909 corsepiu 20 0 11536 8128 248 R 100.0 0.4 0:16.93 test-64
5903 corsepiu 20 0 5560 4180 224 R 99.0 0.2 1:10.20 test-32
QED
Of course, this is an extreme case, but they also aren't that rare in
real world cases.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: parsecvs repo? [Re: Help wanted with dist-cvs to git conversion
Jim Meyering j...@meyering.net writes: Does anyone know of a public and *maintained* repository for parsecvs? I've looked numerous times (as recently as a few weeks ago), and tried to contact Keith Packard, hoping he would still be maintaining it, but have had no luck. I've recently pushed a few changes to a fork of the tree @ repo.or.cz. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Ralf Corsepius wrote: Of course, this is an extreme case, It isn't that extreme - pointers can make up a significant component of data-structures. E.g. any programme that has to store many instances of small amounts of data, the pointer size can have a big impact on memory usage. If the data is heavily inter-linked, even more so. Whether that's the case for most applications, I do not know however. It would though be interesting for someone to go measure this, especially in the aggregate. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If this is timesharing, give me my share right now. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Le Lun 14 décembre 2009 12:45, Josephine Tannhäuser a écrit : of course this is a practicable rule, BUT the problem is upstream or the rule itself. kernels internal zlib is not a lib its a module, wordpress internal php-gettext is not a lib, its a php code file. The trick is to declare that a lib is not a lib and you can close the bug as not a bug... Easy cake.. This is playing with words. I'm sure that when the guideline was written lib was intended as some code in any language that can be shared. What is less clear is the other shared components which are not code (resource files, fonts, templates, etc) but there is no doubt at all in my mind on the code part. Though your interpretation is one reason we keep refining guidelines to leave no room for bad packager excuses. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Lun 14 décembre 2009 12:51, Ralf Corsepius a écrit : Of course, this is an extreme case, but they also aren't that rare in real world cases. They aren't that rare on very specific workloads (numeric computation). People in those fields often have large datasets that appreciate lots of memory (ours work with GiB-sized datasets at least) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Debarshi Ray wrote: Regarding shared libraries its worth noting the point about Instruction pointer relative data access: http://en.wikipedia.org/wiki/X86-64#Architectural_features You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. The point is that few applications need to be 64bit (this may change in time, when email and browser apps start to demand 4GB+, but that time is a while away - per-process memory demands should stay flat for a while if browsers and the like switch from single-process/multi-threaded to a multi-processes model). For the few apps where it makes a difference, sure, run them as 64bit. (Also, please assume in any replies that I have a modicum of clue about the low-level technical details between i386 and x86_64). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: magnetic interferance from money/credit cards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cvs.fedora.redhat.com
On Sun, Dec 13, 2009 at 10:13:15PM -0600, Mike McGrath wrote:
Some of you that have very old checkouts (I'm looking at you Domsch!)
might still be trying to contact cvs.fedora.redhat.com. If you try to use
cvs in the future and it's not working suddenly, make sure your CVSROOT
points to cvs.fedoraproject.org and do a fresh checkout.
You can also use this to rewrite the CVS/Root files.
find . -name Root -exec sed -i -e \
's/cvs.fedora.redhat.com/cvs.fedoraproject.org/' \{\} \;
Thanks,
Matt
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com www.dell.com/linux
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Is bodhi supposed to be fully working again?
Is Bodhi (aka https://admin.fedoraproject.org/updates/) supposed to be fully working again? I can login, but whenever I try to add a new update, I get 500 Internal error after clicking on Save Update and waiting a minute or so. Tom -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cvs.fedora.redhat.com
On Mon, Dec 14, 2009 at 07:16:19AM -0600, Matt Domsch wrote:
On Sun, Dec 13, 2009 at 10:13:15PM -0600, Mike McGrath wrote:
Some of you that have very old checkouts (I'm looking at you Domsch!)
might still be trying to contact cvs.fedora.redhat.com. If you try to use
cvs in the future and it's not working suddenly, make sure your CVSROOT
points to cvs.fedoraproject.org and do a fresh checkout.
You can also use this to rewrite the CVS/Root files.
find . -name Root -exec sed -i -e \
's/cvs.fedora.redhat.com/cvs.fedoraproject.org/' \{\} \;
Or the command 'cvschroot' in package cvsutils.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
make update broken?
Ideas? $ make update Creating a new update for gnome-bluetooth-2.28.4-2.fc12 Password for hadess: Creating a new update for gnome-bluetooth-2.28.4-2.fc12 ServerError(https://admin.fedoraproject.org/updates/save, 500, Internal Server Error) Traceback (most recent call last): File /usr/bin/bodhi, line 153, in main data = bodhi.save(**update_args) File /usr/lib/python2.6/site-packages/fedora/client/bodhi.py, line 111, in save 'bugs': bugs, File /usr/lib/python2.6/site-packages/fedora/client/baseclient.py, line 316, in send_request req_params = req_params, auth_params = auth_params) File /usr/lib/python2.6/site-packages/fedora/client/proxyclient.py, line 292, in send_request raise ServerError(url, http_status, msg) ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 500, Internal Server Error) make: *** [bodhi] Error 255 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: make update broken?
On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera bnoc...@redhat.com wrote: Ideas? The Fedora Infrastrutcure is being moved to a new datacenter: https://www.redhat.com/archives/fedora-announce-list/2009-December/msg8.html https://fedorahosted.org/fedora-infrastructure/ticket/1845 -- Jeff Ollie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cvs.fedora.redhat.com
On Mon, 14 Dec 2009 05:13:15 +0100, Mike McGrath wrote: Some of you that have very old checkouts (I'm looking at you Domsch!) might still be trying to contact cvs.fedora.redhat.com. If you try to use cvs in the future and it's not working suddenly, make sure your CVSROOT points to cvs.fedoraproject.org and do a fresh checkout. Wouldn't it be worth to setup some dummy host printing such message on SSH banned login? I was still waiting for cvs.fedora.redhat.com until the outage ends. Regads, Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: make update broken?
On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera bnoc...@redhat.com wrote: Ideas? The Fedora Infrastrutcure is being moved to a new datacenter: https://www.redhat.com/archives/fedora-announce-list/2009-December/msg8.html https://fedorahosted.org/fedora-infrastructure/ticket/1845 I though this was finished already. I guess not... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: On 12/11/2009 02:41 PM, Adam Williamson wrote: On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). ...nd (oh boy, I love it when a plan comes together) mark it as blocking F13Beta , because I reckon this breaks beta criterion #4: https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria I like the sentiment here, but I'm not sure this is really in the spirit of the criteria - Vasily, as I understand it, is still in the process of implementing the support for UEFI on VirtualBox. There's at least two issues here. One is that we're not shipping the native X driver for vbox video yet. Last I checked this was because it's hidden away in the vbox source, and didn't build against whatever X server we were shipping, and that vbox upstream didn't _want_ it shipped externally yet because they hadn't finalized the interface. The other is that the kernel doesn't seem to be binding an efifb device to it, and/or that it is and X is not noticing that and thus loads vesa instead of fbdev. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: make update broken?
On Mon, 2009-12-14 at 14:43 +, Bastien Nocera wrote: On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera bnoc...@redhat.com wrote: Ideas? The Fedora Infrastrutcure is being moved to a new datacenter: https://www.redhat.com/archives/fedora-announce-list/2009-December/msg8.html https://fedorahosted.org/fedora-infrastructure/ticket/1845 I though this was finished already. I guess not... It's working at least partially. I managed to submit a F11 update but the same update for F12 fails with internal server error. Strange. Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
On Sun, 2009-12-13 at 19:27 -0500, Tom Lane wrote: (FWIW, I completely agree with Monty that Oracle is likely to do their best to kill MySQL once they have it. But they can't kill the GPL'd version as long as people are willing to work on that. Evidently Monty isn't.) http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL-109.html Oracle Makes Commitments to Customers, Developers and Users of MySQL Just released. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma p...@dishone.st said: If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. Then you might as well run the native system architecture, which is 64 bit, rather than try to figure out which apps run better as 32 bit and maintain a full duplicate set of libraries! :-) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
On Mon, 2009-12-14 at 10:32 +0100, Steven Moix wrote: I agree on that, and a major problem with PostgreSQL at the moment is that it doesn't have a clustering engine. Except Hot Standby and Streaming Replication features that will likely appear in 8.5, PostgreSQL project won't have an engine which will provide clustering support -- and PostgreSQL will have one and only one engine. There are some solutions around, though. So MySQL is still the simplest choice out there for the end user Depends. *I* have tried it a few times, and I lost data. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
Josephine Tannhäuser wrote: kernels internal zlib is not a lib its a module, The kernel cannot use userspace shared libraries, so it's the one component which is allowed to bundle zlib. But it's the only one! wordpress internal php-gettext is not a lib, its a php code file. That's just a lame excuse. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
On Mon, Dec 14, 2009 at 01:27:52PM +0100, Nicolas Mailhot wrote: Le Lun 14 décembre 2009 12:45, Josephine Tannhäuser a écrit : of course this is a practicable rule, BUT the problem is upstream or the rule itself. kernels internal zlib is not a lib its a module, wordpress internal php-gettext is not a lib, its a php code file. The trick is to declare that a lib is not a lib and you can close the bug as not a bug... Easy cake.. This is playing with words. I'm sure that when the guideline was written lib was intended as some code in any language that can be shared. What is less clear is the other shared components which are not code (resource files, fonts, templates, etc) but there is no doubt at all in my mind on the code part. Just to make clear, Nicolas's interpretation is correct. Attempting to work around the problem by language lawyering does not promote better software. -Toshio pgp0dG6h5Mczk.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anyone else want to maintain alltray?
Rahul Sundaram, ref: alltray Is it possible to do something else for this package, except be the main maintainer? I use it, and want to follow, and learn more about it. Thanks. Em 14-12-2009 05:14, Rahul Sundaram escreveu: On 12/14/2009 09:03 AM, Huzaifa Sidhpurwala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I want to take it It is all yours now. Have fun. Rahul -- Lucélio Gomes de Freitas ETFCSF- U.G.F.- P.U.C.(RJ) Engº, Analista Suporte(Free Mind). Email:aa.luce...@gmail.com Tel: 55 0XX 21 85964911 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 7:33 AM, Paul Jakma p...@dishone.st wrote: If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. [snip] time, when email and browser apps start to demand 4GB+, but that time is a while away I enjoyed how in nearly one breath you claim that performance is usually irrelevant then go on to name an application where performance is quite visible: A considerable amount of page load time is browser rendering. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) What was the point of this conversation again? People have demonstrated on this list, with benchmarks, that x86_64 makes a material performance improvement across a broad swath of applications where performance matters. You point out that users don't care about performance in many cases. I do not disagree but I have no clue how we can qualify or quantify that. Certainly, when some website posts benchmarks of Fedora vs other distribution those threads get a lot of discussion but that isn't really evidence. I also do not know how it is relevant, in context of x86_64, to Fedora as the use of x86_64 is effectively free. The costs, such as reduced compatibility with binary browser plugins, are simply not relevant to many people. You're obviously convinced of your opinion, other people hold the view that good performance is part of the distribution's core job. Other than the point that x86_64 also increases security (from greatly increased address space layout randomization, and reduced PIE cost), I think we've hit on every point for and against using x86_64 in this thread— yet I think not a single person has changed their initial view. I don't see how any resolution is going to come from further discussion. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anyone else want to maintain alltray?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.12.2009 17:19, Lucélio Gomes de Freitas napsal(a): Rahul Sundaram, ref: alltray Is it possible to do something else for this package, except be the main maintainer? I use it, and want to follow, and learn more about it. Thanks. Yes, you can be co-maintainer. - -- Nikola Pajkovsky npajk...@redhat.com .~. Base Operating Systems Brno /V\ // \\ Jabber: ni...@isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJmW8AAoJED4+/Vgo+H2XGU8H/jMfXumiD5PIE+xMM1U7pKoS dBPznFAqGYei3dZsgAUMgLni4uAIzn+nBFyX05eTPyMyJspGgaPs1LmgXho5grrW pMByuoJq1Ty4DzSqhrU8bLnn3W9jsHc4y9/Iq7yoI8jLMfeug8hU8MX8MV5LDinL fwpORMsCXLdoBahS4gX9yPZ3SA07ekDNCjVg3bjeYt+APL+PedEJq3qUmiAr0jnT hKrkl7oznvqZwzR1D8FgnClSfngn6P2un7nCohSkexZsOEJ6ONWp2x8zu6J6dPOZ usDt7WAvvskyTDg8jqmWnyqI8rOOrHg1Gtdwe2+dNl01Za01zyvbObdV+gGmbSs= =3qPF -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 01:56 AM, Jon Masters wrote: On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote: Once upon a time, Jon Mastersjonat...@jonmasters.org said: Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. That's presumptuous and unfair. Sure, without AMD and others we'd likely be on Itanium (which I actually quite like as an architecture) but Intel 64 isn't just some copy-and-paste effort either. I thought Intel adopted AMD 64-bit extensions pretty much wholesale. No shame in that---they were well-designed and well engineered. We the CPU consumers should be thankful for how well this was executed by both Intel and AMD. Kudos to Intel for acting in the best interest of their customers especially since they had so much invested in Itanium, both financially and in term of company pride. While Itanium (aka Itanic :) was well-intentioned and looked good on paper, Intel/HP run into practical problems with the extent to which VLIW can be exploited by compilers, and with the hardware implementations, so that the actual performance is underwhelming. The Itanium siren song contributed to demise of SGI and wobbliness of HP so let's not be too nostalgic about it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Gregory Maxwell wrote: Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. I'm not rejecting the performance metric at all. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) Only because it's obsolete. Multi-process browsers use a lot less RAM per process. What was the point of this conversation again? For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. Some people chose to argue But you should just run 64bit completely, despite people already having described one reason to 32bit (memory usage). And from that we somehow got into a x86_64 versus x86 thread of doom, with (IMHO) much missing of the general point. Anyway, enough. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Where do you go to get anorexia? -- Shelley Winters -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anyone else want to maintain alltray?
Nikola Pajkovsky, OK.. I am ready to be co-maintainer, it is a pleasure to be part of this team. what is the first step/guideline? I hope do not dissapoint. Thanks. Em 14-12-2009 14:20, Nikola Pajkovsky escreveu: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.12.2009 17:19, Lucélio Gomes de Freitas napsal(a): Rahul Sundaram, ref: alltray Is it possible to do something else for this package, except be the main maintainer? I use it, and want to follow, and learn more about it. Thanks. Yes, you can be co-maintainer. - -- Nikola Pajkovskynpajk...@redhat.com .~. Base Operating Systems Brno /V\ // \\ Jabber: ni...@isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJmW8AAoJED4+/Vgo+H2XGU8H/jMfXumiD5PIE+xMM1U7pKoS dBPznFAqGYei3dZsgAUMgLni4uAIzn+nBFyX05eTPyMyJspGgaPs1LmgXho5grrW pMByuoJq1Ty4DzSqhrU8bLnn3W9jsHc4y9/Iq7yoI8jLMfeug8hU8MX8MV5LDinL fwpORMsCXLdoBahS4gX9yPZ3SA07ekDNCjVg3bjeYt+APL+PedEJq3qUmiAr0jnT hKrkl7oznvqZwzR1D8FgnClSfngn6P2un7nCohSkexZsOEJ6ONWp2x8zu6J6dPOZ usDt7WAvvskyTDg8jqmWnyqI8rOOrHg1Gtdwe2+dNl01Za01zyvbObdV+gGmbSs= =3qPF -END PGP SIGNATURE- -- Lucélio Gomes de Freitas ETFCSF- U.G.F.- P.U.C.(RJ) Engº, Analista Suporte(Free Mind). Email: aa.luce...@gmail.com Tel: 55 0XX 21 85964911 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Adam Williamson wrote: On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. It's quite meaningful, e.g. for power conservation. As you no doubt are aware of, modern system regularly clock down the CPU. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: It occurred to me lately that nothing has occurred to me lately. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 14, 2009, at 5:44 PM, Adam Jackson wrote:
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote:
On 12/11/2009 02:41 PM, Adam Williamson wrote:
On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote:
File a bug please, attaching your xorg.conf, Xorg.0.log and output of
the dmesg command (all from inside of VB virtual machine, of course).
...nd (oh boy, I love it when a plan comes together) mark it as
blocking F13Beta , because I reckon this breaks beta criterion #4:
https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
I like the sentiment here, but I'm not sure this is really in the
spirit of the criteria - Vasily, as I understand it, is still in the
process of implementing the support for UEFI on VirtualBox.
There's at least two issues here.
One is that we're not shipping the native X driver for vbox video yet.
Last I checked this was because it's hidden away in the vbox source, and
didn't build against whatever X server we were shipping, and that vbox
upstream didn't _want_ it shipped externally yet because they hadn't
finalized the interface.
Right, looks like it isn't good time to package vboxvideo.
The other is that the kernel doesn't seem to be binding an efifb device
to it,
Kernel uses efifb, and progress bar with logo drawn in the center looks nice
and correct.
and/or that it is and X is not noticing that and thus loads vesa
instead of fbdev.
X detects fbdev right (at least X -configure creates xorg.conf with right
driver), but it couldn't detect modes (resolution)
using fbdev, thus X loads vesa to somehow fill the gaps imho.
#0 fbdev_open (scrnIndex=value optimized out, dev=0x1501fc /dev/fb0,
namep=0x0) at fbdevhw.c:412
#1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at
fbdevhw.c:442
#2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=value optimized out) at
fbdev.c:394
#3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at
xf86Init.c:663
#4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4)
at xf86Init.c:939
#5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315
fbdev_open with (,namep = 0x0,) doesn't call ioctl(/*
/dev/fb0*/,FBIOGET_FSCREENINFO,), which might returns required information:
(gdb) call ioctl(fd,0x4602,(void*)(fix))
$2 = 0
(gdb) p fix
$3 = {id = EFI VGA\0\0\0\0\0\0\0\0, smem_start = 0x8000 Address
0x8000 out of bounds, smem_len = 6291456, type = 0,
type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0,
line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0,
reserved = {0, 0, 0}}
ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,) called from fbdev_open with (,namep
!= 0x0,), but I am not sure how fbdevHWProbe(,namep != 0x0,) will affect
probing algorithm and X working :) .
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
On Monday 14 December 2009 04:27:52 am Nicolas Mailhot wrote: Though your interpretation is one reason we keep refining guidelines to leave no room for bad packager excuses. Just to be clear what is bad here is the excuse, not the packager (didn't realise it when writing, English has this funny property you can stack words directly and create valid sentences that may be read in many different ways) It is hard to write unambiguous text. In guidelines or other documents. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: MariaDB and Fedora
Le lundi 14 décembre 2009 à 17:03 +0200, Devrim GÜNDÜZ a écrit : On Sun, 2009-12-13 at 19:27 -0500, Tom Lane wrote: (FWIW, I completely agree with Monty that Oracle is likely to do their best to kill MySQL once they have it. But they can't kill the GPL'd version as long as people are willing to work on that. Evidently Monty isn't.) http://www.marketwire.com/press-release/Oracle-Corporation-NASDAQ-ORCL -109.html Oracle Makes Commitments to Customers, Developers and Users of MySQL Oracle commitments are only worth the money Oracle expects earning through them. For example the BEA commitment was we will support existing customers for 10 years, and the nuances of what exactly support means when Oracle has decided a product had no future are only starting to get clear today. This new PR only commits for three years. That's a miser, it would take at least that much time for Oracle to execute a smooth kill (transitioning existing Mysql customers) if it started today. You need to remember Oracle's bread and butter is the Enterprise market where time scales are longer (as evidenced by the 7 years+ RHEL release lifecycle) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 05:18:47PM +, Paul Jakma wrote: For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. There's little testing effort done on this. People still occasionally trip over bugs in the ioctl conversion code in the kernel, and there's a couple of other cases where exported ABI doesn't get converted correctly. Now, while it's undeniable that these are bugs that should be fixed, it's also pretty difficult to justify adding a third x86 variant to our list of supported configurations, especially when it's known to be more problematic than the other two that already satisfy almost everybody's needs. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
On Mon, Dec 14, 2009 at 6:44 AM, Toshio Kuratomi a.bad...@gmail.com wrote: Just to make clear, Nicolas's interpretation is correct. Attempting to work around the problem by language lawyering does not promote better software. Another specific non-library case the pytz package was shipping its own timezone definitions separate from the tzdata package that required additional maintenance (stupid shifts in daylight savings time..thanks US congress.) I was told about it, added a patch to pytz and now it reads the tzdata resource files instead of shipping its own. Less work for me as a maintainer long term.. one less aperiodic package update for users...and more consistent timezone handling for users. The intention of the guidelines...is to guide people in using their judgement on how to handle things. Now in the pytz case as soon as I was made aware of the duplication of timezone resource files..it was obvious that I should make a best effort to reuse a common system wide set and it was easily done. But sometimes its not obvious and that's when a peer discussion needs to happen. Or sometimes its obvious but a best effort runs into problems because of upstream customization or tweaking and that's when a peer discussion needs to happen. The guidelines help define the boundary of the grey area when discussion really needs to happen. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anyone else want to maintain alltray?
2009/12/14 Lucélio Gomes de Freitas aa.luce...@gmail.com: Nikola Pajkovsky, OK.. I am ready to be co-maintainer, it is a pleasure to be part of this team. what is the first step/guideline? I hope do not dissapoint. Thanks. Log into the package database and click the Add myself to this package button: https://admin.fedoraproject.org/pkgdb Note that you must first be a member of the Fedora Packagers group. -- Mat Booth -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, Dec 9, 2009 at 10:24 AM, Jeff Spaleta jspal...@gmail.com wrote: Good Alaskan Morning! In two weeks I'm going to be in Antarctica for a month+ and I'm looking for other packagers to step in for me and maintain my packages and prepare them for F13. I'm not exactly sure what my time and bandwidth access will be so I'm planning for the worst and that I'll be reliably off the grid through mid Feb. Please let me know if you can take on a co-maintainer/primary maintainer role for any of the packges and see them through the next couple of months. Okay I've processed all the pending packagedb requests that have come in so far. Thanks for the response. I'll try to push development tree builds for the latest releases of all the packages I own in the next week. But no promises. Watch your commit emails. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
trouble with signals and skb_rec_datagram()
Hello List... I am working on trying to port a LINUX kernel driver from RedHat AS 4/5 to Fedora 11 12. Within this driver, I create some threads. The threads call skb_rec_datagram(). When it is time to shut down the system, my main kernel code ( in RH 4 5 ) called kill_proc( pid, SIGTERM, 0 ) to terminate the threads created above. The skb_rec_datagram() would return with an error, and the threads would then exit cleanly. Now for Fedora 11 12, I understand that kill_proc() is no longer available to use. So, I have performed experiments that replace the kill_proc() with kill_pid() or with send_sig_info(). Neither of these routines are terminating my threads. I have added extra debug to the code. The return codes from kill_pid() and send_sig_info() are zero, implying that what I asked for was accomplished. Yet, my threads did not terminate. I added code after the skb_rec_datagram() call to print out the error value. This printk statement does not execute when the SIGTERM is genereated. Using crash on a live Fedora 12 system, I see that my threads are, as expected, sitting inside skb_rec_datagram(). So, I am left with two choices. Either the replacements for kill_proc() are not functioning, or skb_rec_datagram() has changed its behavior that ignores SIGTERM. Interestingly, I can kill -9 my threads as ROOT from the command line on a RH 4/5 system. But I can not do so on a Fedora 11/12 system. This would seem to imply that my signals are not masked correctly. However, inspection via 'crash' on a live system seems to indicate that my signal mask is ok. Does anyone know if the behavior of skb_rec_datagram() has changed in the newer kernels ? thanks wr -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: make update broken?
On Mon, Dec 14, 2009 at 02:43:34PM +, Bastien Nocera wrote: On Mon, 2009-12-14 at 08:29 -0600, Jeffrey Ollie wrote: On Mon, Dec 14, 2009 at 7:42 AM, Bastien Nocera bnoc...@redhat.com wrote: Ideas? The Fedora Infrastrutcure is being moved to a new datacenter: https://www.redhat.com/archives/fedora-announce-list/2009-December/msg8.html https://fedorahosted.org/fedora-infrastructure/ticket/1845 I though this was finished already. I guess not... Very much still in progress. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
On Fri, Dec 04, 2009 at 05:56:02PM +0100, Kevin Kofler wrote: IMHO, if we want to ship this by default, we really need to fix FreeType for the case where the font doesn't provide hinting bytecode. AFAICT, currently, in that case, if FreeType is built with the BCI enabled, it won't do any [...] It should fall back to the autohinter when the font does not provide hinting bytecode. Aha! So that's why all the open-source fonts on my screen suddenly got really ugly. Is there an open bugzilla bug for this? -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FreeType patented bytecode interpreter now in rawhide
On Mon, Dec 14, 2009 at 04:16:10PM -0500, Matthew Miller wrote: Is there an open bugzilla bug for this? There is now: bug #547532. Thanks. -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
astronomy-bookmarks conflicts with fedora-bookmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? Thanks, Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJq8IAAoJEDbiLlqcYamx+sMP/j36892hx9wLAY+dJ1HAaQW0 Kw8TgyfW0sWvkLwcv45wwla9lP7FIvc9yFl5Bh7/84/x0fxApX0j9E50wzepYnaX Xb4MCCEM7FSMpjLRuDkN9xi1ppKr4hUKReY5oa7gfRM1sRepNHXg8pcOHv6Y3zcD NMtEZCcrZzQuPA6kSLF6QG79cS0dXJHSl2DUx8SQOoe48ETnOhSmG6870+CzTp9D 7B4LKPms0zZsnJFLl/YMm1PCgIARWumwIIJ3DQfzMjhRsVj2HF0Dfwz/I7l28pk2 eldHzGuIgfCheAB6SK/TyQzniAM2O43EVDU0e+2oEU6LVFvvlw8yXwraFNJR+Iw2 bM5Xu7bBJhZO0784idC6fMntAqBHZW6WF6I8JOD/VzgQPUs9RZwWTuOXo9kMK2kM FqtlgdzNs8HOt5N64+H45FUMTko2avLspmQuoEQBtNGXtSkpQ/luukn/kja7i812 lwttf/AmA7mzMIxA8OrsE6F9uwi9fcRcJLxHQMmVXBrXhw9kYM0wzv4Xe0IkmP/F 2dn9l/8c2L86xltN+7vpEL1++nitnhM7IPBbZesA0p9eBxH5LXokAnuW0jI/ccjF mLc78O9bIgQqIrHasUSSh/JM5g5n/1TpledJox5LIGb3eQiXUVZBLCXD5VVjN7Dn bnmtJ97j97nowuSmdQh3 =YAJh -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Datacenter, git, and cvs
If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? If so, mainly the git move, will we as users/testers/etc notice any changes - via emails sent out, koji and the like - or is it all mostly behind the scenes and package maintainers and the like will be the ones who are affected? Guess a summary of what to expect once it's all GO? -- Mike Chambers Madisonville, KY Best lil town on Earth! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
Mike Chambers wrote: If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? Only the former is taking place now. A move from cvs to git is being tested but is not imminent. I'm sure that it will be hard to miss once that change is ready and implemented. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ A lawyer was visiting a farmer on business, when he stepped out of his Mercedes in the farmyard he stepped into a cow dropping. Looking down he cried my god I'm melting! pgpXnY59ScYGE.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
On Mon, Dec 14, 2009 at 3:49 PM, Mike Chambers m...@miketc.net wrote: If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? The move from CVS to Git won't happen until post-F13. -- Jeff Ollie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2009 04:50 PM, Paul W. Frields wrote: On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. Okay, that makes sense. Thanks Paul. - --Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJrUsAAoJEDbiLlqcYamxHlgQAIP7AGOXwGIyvD93YXywRTf/ 9/vEDR9ti92gNjJ21EEw3QRYTD6czsUOZZ/EfJDldIaSQPx6aktZJQT1neBlLlgD lRFvqLY29/ZokPqF0gyBznl5FFpkbVHhClSPsBJzfPkeQ7jb50ZQU5w5z2IUSk7l yzih0lskGCeDT2RGBg3SrKVhWX1sgO8dRdmfVORg0uRRkJgDLgq7i6Fp2mkSIPqT R8iErKs8bAP24FgIZMKJGNGjUW3oUS7NuC0n1sB169y2ProPmLfMzHfagJzR438i PPQHb9QHkXhzd8YedjGGG3ks3OaZ1xoTuj6eDga9UquvZ3gKcX/gqbOH7U7b4nuC LDrCskYOhgoR+rFvP9rpgP13nUj7iK4iWu00jRNS4nvDe/Jh9oI44r4A2v7xwOCI lI1ZNZZYCM2Ci2kzKvIuezS3kOcgKXYVl/Zsio81rLgc3/Kp3RYDErmuRcuvQD9M sIe1QTVw8q0sAMuCxNDH9DuIAB4luHc3hAAdtl+n78qokmS0g4iWSMzvVteBBJB/ Q2GEBl7q4BiLAQe8HnX0bAT496yuIFMGzSbbA7qWv6oeccN16W1fLKWjPFb8xhpO xCjJsVzYsuI8aFFXxO/cXyQuojNoPw34KRi8df/71KIvlIfaQ02DKkiauJfCMIg7 zyl+TSdhiUV4ReUZwAUZ =O57+ -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
On 12/14/2009 04:50 PM, Paul W. Frields wrote: On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. Multiple packages can Provides: the same thing without problems. The issue here is that astronomy-bookmarks explicitly Conflicts: with fedora-bookmarks: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
On 12/14/2009 04:57 PM, Todd Zullinger wrote: Mike Chambers wrote: If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? Only the former is taking place now. A move from cvs to git is being tested but is not imminent. I'm sure that it will be hard to miss once that change is ready and implemented. If done right, the move to git can still service CVS requests in some capacity... that may make the transition a little less abrupt and painful. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
more - trouble with signals and skb_rec_datagram()
Hello List... I am working on trying to port a LINUX kernel driver from RedHat AS 4/5 to Fedora 11 12. Within this driver, I create some threads. The threads call skb_rec_datagram(). When it is time to shut down the system, my main kernel code ( in RH 4 5 ) called kill_proc( pid, SIGTERM, 0 ) to terminate the threads created above. The skb_rec_datagram() would return with an error, and the threads would then exit cleanly. Now for Fedora 11 12, I understand that kill_proc() is no longer available to use. So, I have performed experiments that replace the kill_proc() with kill_pid() or with send_sig_info(). Neither of these routines are terminating my threads. I have added extra debug to the code. The return codes from kill_pid() and send_sig_info() are zero, implying that what I asked for was accomplished. Yet, my threads did not terminate. I added code after the skb_rec_datagram() call to print out the error value. This printk statement does not execute when the SIGTERM is genereated. Using crash on a live Fedora 12 system, I see that my threads are, as expected, sitting inside skb_rec_datagram(). So, I am left with two choices. Either the replacements for kill_proc() are not functioning, or skb_rec_datagram() has changed its behavior that ignores SIGTERM. Interestingly, I can kill -9 my threads as ROOT from the command line on a RH 4/5 system. But I can not do so on a Fedora 11/12 system. This would seem to imply that my signals are not masked correctly. However, inspection via 'crash' on a live system seems to indicate that my signal mask is ok. Does anyone know if the behavior of skb_rec_datagram() has changed in the newer kernels ? thanks wr In Fedora 11 code for net/core/datagram.c, the skb_rec_datagram() and wait_for_packet() functions seem to have changed such that there is a new ( to me anyway ) function named receiver_wake_function(). This function, based on the comments, appears to be filtering signals. Can anyone tell me if this receiver_wake_function() is filtering out SIGTERM and SIGKILL signals ? ( I have not been able to determine how these SIG signals convert to the poll bits in the code... ) wr -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
Mike Bonnet wrote: The issue here is that astronomy-bookmarks explicitly Conflicts: with fedora-bookmarks: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 That Conflicts is probably there because they provide the same file, so without the explicit Conflicts, we'd have a file conflict, which is much worse. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
Adam Williamson wrote: I actually dropped gst-mixer with F12, as we planned all along. So that one's not an option for F12. Someone could unorphan it, or use the F11 package. (BTW, I don't see why you retired it as it was clearly still useful to some users and it can't hurt to have it in the repository.) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
Jeff Garzik wrote: If done right, the move to git can still service CVS requests in some capacity... that may make the transition a little less abrupt and painful. Perhaps. But git-cvsserver is a rather limited crutch that I can't imagine anyone wanting to spend much time on, just to let folks continue to use cvs commands directly. Who knows though, maybe there are more people that actually like cvs than I think and they'll volunteer to implement and run such a service. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ L'hypocrisie est un hommage que le vice rend à la vertu. [Hypocrisy is the tribute which vice pays to virtue.] -- Francois, Duc de La Rochefoucauld, Réflexions ou sentences et maximes morales pgp7QoPwyDFEg.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
On Mon, Dec 14, 2009 at 05:01:56PM -0500, Mike Bonnet wrote: On 12/14/2009 04:50 PM, Paul W. Frields wrote: On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks astronomy-bookmarks = 1-6.fc12 system-bookmarks [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks fedora-bookmarks = 11-2 system-bookmarks They both provide 'system-bookmarks'. Multiple packages can Provides: the same thing without problems. The issue here is that astronomy-bookmarks explicitly Conflicts: with fedora-bookmarks: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1459223 Thanks for the clarification Mike! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anyone else want to maintain alltray?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 14.12.2009 18:54, Lucélio Gomes de Freitas napsal(a): Nikola Pajkovsky, OK.. I am ready to be co-maintainer, it is a pleasure to be part of this team. what is the first step/guideline? I hope do not dissapoint. Thanks. First make account here: https://admin.fedoraproject.org/accounts and bugzilla account(bugzilla.redhat.com) See page: https://admin.fedoraproject.org/pkgdb/packages/name/alltray?_csrf_token=80a4f0d38a86652149f07d678bd10092cf2aaed3 and add yoursef as user who whatch commits and bugzilla. All patches that you will make discuse with upstream and if they refuse it send to huzai...@redhat.com and discuse with him. Have a nice coding ;) - -- Nikola Pajkovsky npajk...@redhat.com .~. Base Operating Systems Brno /V\ // \\ Jabber: ni...@isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLJsH6AAoJED4+/Vgo+H2XEKYH/3iHdooXpM2Puz1qz5gCwYEP IQHwrph+hG2FOAWXfjX0x2GN5H3iJzfsEARz/vvdGJ3QXW+9Ejy1xeN8DCTD1k9P vpRjMGwDdQDmKWD5C+kJgcqoRry88ME4Euo/EACCs/l0vDZGruhpIUSKamgK4evW Awv8UdOOmd5mUH8P/QgA+EGUrZVeElqXggmlh0Kdjh5+JoOS/FxQUJYjdqqhA0HG 8hxg+v+4lRjfVL7NV68T/eCMnhRz4NkeESYCL1nN0AWhrfgSJUFgmIODcAO4wdtR dgHoCEQAl8zIEJJ2kgC/yZt2DLkvIBj3Ck7n+VRQBNu+4rIjMzW+a51fWGWLkx4= =iMEO -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: astronomy-bookmarks conflicts with fedora-bookmarks
On Mon, Dec 14, 2009 at 10:32 PM, Eric Christensen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When trying to install astronomy-bookmarks I get the error that astronomy-bookmarks conflicts with fedora-bookmarks in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? Hello there, It's an issue that needs to be addressed _as an example_ . If every SIG turns to create similar bookmarks package, then there will be more conflicts. Every bookmark package will have to conflict other bookmark package being shipped. There was a request to opt for alternatives instead and remove all the conflicts. https://bugzilla.redhat.com/show_bug.cgi?id=508126 Chitlesh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Evo messages don't refresh when deleting
Rawhide system upgraded from F12+updates as of today.. If you go to a folder and on the right side on top of the preview pane, and click on an email and delete it, at times (although it seems not every time, and maybe random), the next email isn't refreshed and/or isn't shown on the bottom of the preview pane. In other words, it stills shows the body of the deleted email and not the new one. But if you were to click on a different email without deleting the one you just left, it shows the correct email/body. Anyone else seeing this? evolution-bogofilter-2.29.3-1.fc13.x86_64 evolution-data-server-2.29.3-3.fc13.x86_64 evolution-help-2.29.3-1.fc13.noarch evolution-2.29.3-1.fc13.x86_64 -- Mike Chambers Madisonville, KY Best lil town on Earth! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Mon, 2009-12-14 at 23:22 +0100, Kevin Kofler wrote: Adam Williamson wrote: I actually dropped gst-mixer with F12, as we planned all along. So that one's not an option for F12. Someone could unorphan it, or use the F11 package. (BTW, I don't see why you retired it as it was clearly still useful to some users and it can't hurt to have it in the repository.) Because I don't see a substantial enough need to keep maintaining it now gnome-volume-control has most of the features most users need. If someone wants to maintain it I'm happy to pass it off to them, though I'd now agree with Lennart and the desktop team that it should not be in the default installed package sets (comps) any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dist-git proof of concept phase 1 complete
In my effort to create a proof of concept for using git to manage our package source control, I have completed what I am calling phase one, that is taking our current dist-cvs and converting it into git format. pkgs/rpms/package/devel is now the git origin/master. All release subdirs have been turned into git branches. History back to F7, as well as the EPEL branches have been converted, from a snapshot of the CVS tree I took last week. Currently I only have anonymous git:// access setup, as we play with some options for authenticated writing. If you wish to play around with the repos, you can access it via: git://publictest5.fedoraproject.org/git/pkgs/package eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Give it a spin, see what you think. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
On Mon, 2009-12-14 at 19:55 -0500, Jeff Garzik wrote: I think of it less as a question of /liking/ CVS, and more an admission that a global workflow change has real costs for each individual developer. A flag day-style transition is clean and efficient, but often locks out developers who are not able to march in lock-step with the transition schedule. I am very pro-git (naturally, being a kernel developer) and want this switch, but it nonetheless means my home-written scripts for maintaining related project packages (cld, chunkd, tabled) must be updated and tested. Even without local script updates, developers have to learn new stuff just to keep functioning at the same level as before. Because we are not just moving source control backends, but also changing workflow, a cvs gateway to the git server wouldn't get you very far, unless it's a pretty hacked up gateway. If somebody wants to work on a gateway that's cool, I'm not considering it a blocker to rolling out the change, once we have a working proof of concept and a solid migration plan blessed by FESCo. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 21:48 -0600, Sir Gallantmon wrote: Do you have the webview set up yet? Not as of yet. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 03:21, Jesse Keating jkeat...@redhat.com wrote: [...] Currently I only have anonymous git:// access setup, as we play with some options for authenticated writing.[...] Gitosis which is already in fedora does a pretty good job of this including key based auth as well as multiple authorized users per git repo, gitweb interface etc. Might be a good starting point if you weren't already aware of it... -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wiki Feature Dashboard Additional Category
Daniel Hendrycks said the following on 12/12/2009 10:03 AM Pacific Time: Hi, my name is Daniel Hendrycks http://my.opera.com/DanielHendrycks/. I have a suggestion for the Fedora Wiki Feature Request Dashboard: The wiki page explaining how to properly request a feature had a link to another wiki article telling you what to do if you cannot implement a feature yourself. Within this article it never did state you need a developer willing to implement but in actuality you do. It is a requirement in your feature request to have someone willing to implement your request. Which wiki page is talks about not being able to implement a feature yourself? I'll try to make it clearer. My request is have a section in the feature process dashboard for features without a developer. Features would be placed in that category after being approved by the Feature Wrangler (poelcat). The feature request must specify that the feature does not have a developer for it to be put in that category (obviously). This would be more convenient for the person wanting that feature. Feature request owners would not have to hunt down developers and ask them to implement the feature for them (this would annoy some community developers at the same and worsen the Fedora Community). Instead developers could just look at what requests have no developer and contact the owner of the feature and include their name in the request, they would then be re-checked by the Feature Wrangler and hopefully transfered to FESCo for further evaluation. I am suggesting the request would be placed in the Feature has no developer (possible name of the category) section after being approved by the Feature Wrangler because this will indicate that the request meets all requirements except that it does not have a developer. Since it meets all requirements possible developers will not have to read a broken (incomplete) request, this would make developers more likely to check. This is an interesting idea. I'm not sure how it would work in reality. Chances are someone deciding to work on a feature will add or make changes to the design proposed by someone else. Summary: Have a section in the Feature Request Dashboard for features without a developer. From there developers can volunteer there skills to implement this feature if later on approved by FESCo. Thank you for your time, Daniel Hendrycks :) Topics of this nature are best discussed on fedora-devel-list which is where I'm moving this post The websites list has nothing to do with the features process. You have an interesting idea about tagging feature pages needing an owner. In reality that pretty much represents all the pages in 'Category:FeaturePageIncomplete' If they had an active owner or developer working on the feature they wouldn't be there. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, 2009-12-15 at 04:29 +, John5342 wrote: Gitosis which is already in fedora does a pretty good job of this including key based auth as well as multiple authorized users per git repo, gitweb interface etc. Might be a good starting point if you weren't already aware of it... gitosis was the first idea, which led me to a rewrite somebody has done, gitolite http://github.com/sitaramc/gitolite which I'm trying to bend to our will. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
Hello All! 2009/12/15 Jesse Keating jkeat...@redhat.com: git://publictest5.fedoraproject.org/git/pkgs/package eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel How to easily clone whole package tree? -- With best regards, Peter Lemenkov. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fedora-electronic-lab] TAPR Open Hardware License
On Mon, Dec 14, 2009 at 12:57 PM, Shakthi Kannan shakthim...@gmail.com wrote: Hi, --- On Mon, Dec 14, 2009 at 5:11 PM, Chitlesh GOORAH chitl...@fedoraproject.org wrote: | fel-userguide-release ? \-- Ok. Project name will fel-userguide. I shall create a ticket to Fedora Infrastructure. ok wait, do you need another git repo ? why can't we use the current repo ? I fear that the more we poke the infrastructure the more the budget will increase. Chitlesh ___ Fedora-electronic-lab-list mailing list Fedora-electronic-lab-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-electronic-lab-list
Re: [Fedora-electronic-lab] TAPR Open Hardware License
Hi, --- On Mon, Dec 14, 2009 at 5:34 PM, Chitlesh GOORAH chitl...@fedoraproject.org wrote: | ok wait, do you need another git repo ? why can't we use the current repo ? \-- Sorry, but, where is it? SK -- Shakthi Kannan http://www.shakthimaan.com ___ Fedora-electronic-lab-list mailing list Fedora-electronic-lab-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-electronic-lab-list
[Fedora-electronic-lab] Re: [Fedora Electronic Lab] #51: chalmers-lava2000
#51: chalmers-lava2000 --+- Reporter: shakthimaan | Owner: shakthimaan* Type: defect | Status: new Priority: major| Milestone: Fedora 13 Component: FEL | Version: devel Resolution: |Keywords: --+- Changes (by shakthimaan): * owner: shakthimaan = shakthimaan* * status: assigned = new Comment: Please hold the review for this package. I have pushed changes that upstream is working on, and will then release a new package. After that, I shall release a new RPM for review. -- Ticket URL: https://fedorahosted.org/fedora-electronic-lab/ticket/51#comment:4 Fedora Electronic Lab https://fedorahosted.org/fedora-electronic-lab Design, Simulate and Program electronics. ___ Fedora-electronic-lab-list mailing list Fedora-electronic-lab-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-electronic-lab-list
[Fedora-electronic-lab] Request for testing : Icarus Verilog v0.9.2 pre-release
Hello Verilog users, A test snapshot of the next v0.9.2 iverilog release was pushed to updates-testing repository. It is upstream's last test snapshot before the v0.9.2 release. We would like you to test it against * your large structural designs (upstream's wish) * your FPGA specific designs - post synthesis [1] and post place and route The test plan is detailed here along with some known bugs https://fedorahosted.org/fedora-electronic-lab/wiki/Testing/iverilog This release is a huge enhancement over the one in Fedora stable repositories. It is more compliant too with IEEE Standard 1364-2005 [2]. Runtime has also been improved. We would appreciate if you can give some feedbacks such as : * estimated gate count * estimated time of execution * architecture: i686 or x86_84 * rpm -q iverilog Kind regards, Chitlesh [1] : http://chitlesh.wordpress.com/2009/05/18/xilinx-icarus-verilog-post-synthesis-simulation/ [2] : https://fedorahosted.org/fedora-electronic-lab/wiki/Digital/iverilog -- Chitlesh GOORAH Fedora Electronic Lab http://spins.fedoraproject.org/fel ___ Fedora-electronic-lab-list mailing list Fedora-electronic-lab-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-electronic-lab-list
[Bug 546490] fontconfig-2.8.0-1 changes default Emacs font from DejaVu Sans Mono to Baekmuk Gulim
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=546490 Akira TAGOH ta...@redhat.com changed: What|Removed |Added CC||ta...@redhat.com --- Comment #9 from Akira TAGOH ta...@redhat.com 2009-12-14 03:52:56 EDT --- This issue is easily reproducible with fc-match monospace:lang=en though, there are two things introduced in 2.8.0: 1. the above command matches lang=ko too 2. Baekmuk Gulim has been added to the pattern with the strong binding somehow. which has ever been added with the weak binding. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 547287] New: Both cache version -2 and -3 files exists
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Both cache version -2 and -3 files exists https://bugzilla.redhat.com/show_bug.cgi?id=547287 Summary: Both cache version -2 and -3 files exists Product: Fedora Version: 12 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: fontconfig AssignedTo: besfa...@redhat.com ReportedBy: pnem...@redhat.com QAContact: extras...@fedoraproject.org CC: besfa...@redhat.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-b...@redhat.com Classification: Fedora Target Release: --- Description of problem: after upgrading fontconfig, I see new architecture definition is picked in cache dir but old cache with x86_64 arch and -2 version remains. Shouldn't -2 cache be deleted? Version-Release number of selected component (if applicable): fontconfig-2.8.0-1.fc12.x86_64 fontconfig-2.8.0-1.fc12.i686 How reproducible: always Steps to Reproduce: 1.ls -l /var/cache/fontconfig/ 2. See both versions cache files 3. Actual results: Both cache versions -2 and -3 files exists. Expected results: should only -3 with new arch definition exists in /var/cache/fontcofig Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/pothana2000-fonts/F-11 pothana2000-fonts.spec,1.2,1.3
Author: sandeeps
Update of /cvs/pkgs/rpms/pothana2000-fonts/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27407
Modified Files:
pothana2000-fonts.spec
Log Message:
Preparing for 1.3.2-2 release
Index: pothana2000-fonts.spec
===
RCS file: /cvs/pkgs/rpms/pothana2000-fonts/F-11/pothana2000-fonts.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- pothana2000-fonts.spec 14 Dec 2009 09:00:47 - 1.2
+++ pothana2000-fonts.spec 14 Dec 2009 09:22:44 - 1.3
@@ -3,7 +3,7 @@
Name: %{fontname}-fonts
Version: 1.3.2
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Unicode compliant OpenType font for Telugu
Group: User Interface/X
@@ -47,6 +47,9 @@ rm -fr %{buildroot}
%doc gpl.txt
%changelog
+* Mon Dec 14 2009 sshed...@redhat.com - 1.3.2-2
+- Release bump
+
* Mon Dec 14 2009 sshed...@redhat.com - 1.3.2-1
- Fixed FSType, Preferred Style, UinqueID and Fullname
- Fixed Invalid Glyph Names reported by fontlint
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/pothana2000-fonts/F-12 pothana2000-fonts.spec,1.3,1.4
Author: sandeeps
Update of /cvs/pkgs/rpms/pothana2000-fonts/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28586
Modified Files:
pothana2000-fonts.spec
Log Message:
Preparing for 1.3.2-2 release
Index: pothana2000-fonts.spec
===
RCS file: /cvs/pkgs/rpms/pothana2000-fonts/F-12/pothana2000-fonts.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- pothana2000-fonts.spec 14 Dec 2009 09:01:24 - 1.3
+++ pothana2000-fonts.spec 14 Dec 2009 09:25:48 - 1.4
@@ -3,7 +3,7 @@
Name: %{fontname}-fonts
Version: 1.3.2
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Unicode compliant OpenType font for Telugu
Group: User Interface/X
@@ -47,6 +47,9 @@ rm -fr %{buildroot}
%doc gpl.txt
%changelog
+* Mon Dec 14 2009 sshed...@redhat.com - 1.3.2-2
+- Release bump
+
* Mon Dec 14 2009 sshed...@redhat.com - 1.3.2-1
- Fixed FSType, Preferred Style, UinqueID and Fullname
- Fixed Invalid Glyph Names reported by fontlint
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
File Vemana2k-Li.zip uploaded to lookaside cache by sandeeps
A file has been added to the lookaside cache for vemana2000-fonts: a044265b4fbdede4d58f51eb1c9a9c7f Vemana2k-Li.zip ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/vemana2000-fonts/devel sources, 1.2, 1.3 vemana2000-fonts.spec, 1.1, 1.2
Author: sandeeps
Update of /cvs/pkgs/rpms/vemana2000-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4235
Modified Files:
sources vemana2000-fonts.spec
Log Message:
Preparing for 1.1.2-1 release
Index: sources
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 31 Aug 2009 07:11:47 - 1.2
+++ sources 14 Dec 2009 09:44:36 - 1.3
@@ -1 +1 @@
-b1a631b2725e59bda082af9cfafb51a6 Vemana2k-Li.zip
+a044265b4fbdede4d58f51eb1c9a9c7f Vemana2k-Li.zip
Index: vemana2000-fonts.spec
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/devel/vemana2000-fonts.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- vemana2000-fonts.spec 31 Aug 2009 07:11:48 - 1.1
+++ vemana2000-fonts.spec 14 Dec 2009 09:44:36 - 1.2
@@ -2,12 +2,12 @@
%global fontconf 69-%{fontname}.conf
Name: %{fontname}-fonts
-Version: 1.1.1
-Release: 2%{?dist}
+Version: 1.1.2
+Release: 1%{?dist}
Summary: Unicode compliant OpenType font for Telugu
Group: User Interface/X
-License: GPLv2+
+License: GPLv2+ with exceptions
URL: http://www.kavya-nandanam.com/dload.htm
Source0: Vemana2k-Li.zip
@@ -47,6 +47,11 @@ rm -fr %{buildroot}
%doc gpl.txt
%changelog
+* Mon Dec 14 2009 sshed...@redhat.com - 1.1.2-1
+- Fixed FSType, Preferred Styles, UniqueID and Fullname
+- Fixed Invalid Glyph Names reported by fontlint
+- with exceptions string added in License
+
* Tue Aug 31 2009 sshed...@redhat.com - 1.1.1-2
- Changed the Pothana2000 strings to Vemana2000
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 546490] fontconfig-2.8.0-1 changes default Emacs font from DejaVu Sans Mono to Baekmuk Gulim
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=546490 --- Comment #10 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-12-14 04:41:54 EDT --- also let's remember that emacs only switched to the same font engine as everyone else recently -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/vemana2000-fonts/F-11 .cvsignore, 1.1, 1.2 sources, 1.2, 1.3 vemana2000-fonts.spec, 1.1, 1.2
Author: sandeeps
Update of /cvs/pkgs/rpms/vemana2000-fonts/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4459
Modified Files:
.cvsignore sources vemana2000-fonts.spec
Log Message:
Preparing for 1.1.2-1 release
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 28 Aug 2009 14:40:36 - 1.1
+++ .cvsignore 14 Dec 2009 09:44:59 - 1.2
@@ -0,0 +1 @@
+Vemana2k-Li.zip
Index: sources
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/F-11/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 31 Aug 2009 07:37:25 - 1.2
+++ sources 14 Dec 2009 09:44:59 - 1.3
@@ -1 +1 @@
-b1a631b2725e59bda082af9cfafb51a6 Vemana2k-Li.zip
+a044265b4fbdede4d58f51eb1c9a9c7f Vemana2k-Li.zip
Index: vemana2000-fonts.spec
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/F-11/vemana2000-fonts.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- vemana2000-fonts.spec 31 Aug 2009 07:37:25 - 1.1
+++ vemana2000-fonts.spec 14 Dec 2009 09:44:59 - 1.2
@@ -2,12 +2,12 @@
%global fontconf 69-%{fontname}.conf
Name: %{fontname}-fonts
-Version: 1.1.1
-Release: 2%{?dist}
+Version: 1.1.2
+Release: 1%{?dist}
Summary: Unicode compliant OpenType font for Telugu
Group: User Interface/X
-License: GPLv2+
+License: GPLv2+ with exceptions
URL: http://www.kavya-nandanam.com/dload.htm
Source0: Vemana2k-Li.zip
@@ -47,6 +47,11 @@ rm -fr %{buildroot}
%doc gpl.txt
%changelog
+* Mon Dec 14 2009 sshed...@redhat.com - 1.1.2-1
+- Fixed FSType, Preferred Styles, UniqueID and Fullname
+- Fixed Invalid Glyph Names reported by fontlint
+- with exceptions string added in License
+
* Tue Aug 31 2009 sshed...@redhat.com - 1.1.1-2
- Changed the Pothana2000 strings to Vemana2000
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/vemana2000-fonts/F-12 sources, 1.2, 1.3 vemana2000-fonts.spec, 1.1, 1.2
Author: sandeeps
Update of /cvs/pkgs/rpms/vemana2000-fonts/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4572
Modified Files:
sources vemana2000-fonts.spec
Log Message:
Preparing for 1.1.2-1 release
Index: sources
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/F-12/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 31 Aug 2009 07:11:47 - 1.2
+++ sources 14 Dec 2009 09:45:32 - 1.3
@@ -1 +1 @@
-b1a631b2725e59bda082af9cfafb51a6 Vemana2k-Li.zip
+a044265b4fbdede4d58f51eb1c9a9c7f Vemana2k-Li.zip
Index: vemana2000-fonts.spec
===
RCS file: /cvs/pkgs/rpms/vemana2000-fonts/F-12/vemana2000-fonts.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- vemana2000-fonts.spec 31 Aug 2009 07:11:48 - 1.1
+++ vemana2000-fonts.spec 14 Dec 2009 09:45:32 - 1.2
@@ -2,12 +2,12 @@
%global fontconf 69-%{fontname}.conf
Name: %{fontname}-fonts
-Version: 1.1.1
-Release: 2%{?dist}
+Version: 1.1.2
+Release: 1%{?dist}
Summary: Unicode compliant OpenType font for Telugu
Group: User Interface/X
-License: GPLv2+
+License: GPLv2+ with exceptions
URL: http://www.kavya-nandanam.com/dload.htm
Source0: Vemana2k-Li.zip
@@ -47,6 +47,11 @@ rm -fr %{buildroot}
%doc gpl.txt
%changelog
+* Mon Dec 14 2009 sshed...@redhat.com - 1.1.2-1
+- Fixed FSType, Preferred Styles, UniqueID and Fullname
+- Fixed Invalid Glyph Names reported by fontlint
+- with exceptions string added in License
+
* Tue Aug 31 2009 sshed...@redhat.com - 1.1.1-2
- Changed the Pothana2000 strings to Vemana2000
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 542461] Review Request: digna-fonts - Handwriting font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=542461 --- Comment #9 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-12-14 04:51:06 EDT --- You can try to ask for help on the openfontlibrary mailing list (I know the situation sort of sucks right now) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 542461] Review Request: digna-fonts - Handwriting font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=542461 --- Comment #10 from Andrea Musuruane musur...@gmail.com 2009-12-14 05:23:20 EDT --- (In reply to comment #9) You can try to ask for help on the openfontlibrary mailing list (I know the situation sort of sucks right now) Nicolas, I saw you are already subscribed to that mailing list. Can you please write for me? I do not want to subscribe to another mailing list just for one post. Thanks! This is the error I get: /var/www/openfontlibrary.org/htdocs/cclib/cc-debug.php(287): error_log(../cchost_offline/cc-log.txt) [function.error-log]: failed to open stream: No such file or directory [2009-12-14 10:16 am][127.0.0.1][/media/people/contact/phranzysko] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 542461] Review Request: digna-fonts - Handwriting font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=542461 --- Comment #11 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-12-14 05:44:31 EDT --- Andrea, I am present in a lot of places but I have only so much free time in the day. Right now I'm way behind on the maintenance on my own packages, so I don't really have the time to relay other packager requests (and then track answers...) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 547307] New: fc-query extracts locale code for some fonts and not for all.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: fc-query extracts locale code for some fonts and not for all.
https://bugzilla.redhat.com/show_bug.cgi?id=547307
Summary: fc-query extracts locale code for some fonts and not
for all.
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfa...@redhat.com
ReportedBy: pnem...@redhat.com
QAContact: extras...@fedoraproject.org
CC: besfa...@redhat.com, fedora-fonts-bugs-list@redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
fc-query extracts locale code for some fonts and not for all.
Version-Release number of selected component (if applicable):
fontconfig-2.8.0-1.fc12.x86_64
lohit-konkani-fonts-2.4.3-2.fc12.noarch
How reproducible:
always
Steps to Reproduce:
1. fc-query --format '%{=pkgkit}'
/usr/share/fonts/lohit-konkani/Lohit-Konkani.ttf
2. observe one of output lines contains
font(lohitkonkani)
3. why not this as
font(:lang=kok)
Actual results:
output as font(lohitkonkani)
Expected results:
output should be font(:lang=kok)
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 547307] fc-query extracts locale code for some fonts and not for all
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=547307 Parag pnem...@redhat.com changed: What|Removed |Added CC||fedora-i18n-b...@redhat.com Summary|fc-query extracts locale|fc-query extracts locale |code for some fonts and not |code for some fonts and not |for all.|for all -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
