mergerepos issue
Hi all, I have attached an external repo to one of my build tags. After attaching the repo, I issued a koji regen-repo tag. This is what I get: 1348/2199 - kde-l10n-Walloon-4.2.2-1.fc11.noarch 1349/2199 - kde-l10n-Lithuanian-4.2.2-1.fc11.noarch 1350/2199 - 1:perl-Error-0.17015-2.fc11.noarch Traceback (most recent call last): File /usr/libexec/kojid/mergerepos, line 241, in module main(sys.argv[1:]) File /usr/libexec/kojid/mergerepos, line 236, in main merge.write_metadata() File /usr/libexec/kojid/mergerepos, line 216, in write_metadata mdgen.doPkgMetadata() File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 364, in doPkgMetadata self.writeMetadataDocs(packages) File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 527, in writeMetadataDocs self.primaryfile.write(po.xml_dump_primary_metadata()) File /usr/lib/python2.5/site-packages/yum/packages.py, line 1015, in xml_dump_primary_metadata msg += misc.to_unicode(self._dump_format_items()) File /usr/lib/python2.5/site-packages/yum/packages.py, line 894, in _dump_format_items msg += self._dump_pco('provides') File /usr/lib/python2.5/site-packages/yum/packages.py, line 919, in _dump_pco msg += pcostring UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 28: ordinal not in range(128) Unicode error? I don't get it! Any pointers? Regards, Jitesh -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mergerepos issue
Aaah .. some RPMs have unicode in their 'provides' tag which causes this problem. Temporarily, I have removed those from the external repo and it works fine :) Jitesh On Fri, 2009-06-05 at 06:46 -0700, Jitesh Shah wrote: Hi all, I have attached an external repo to one of my build tags. After attaching the repo, I issued a koji regen-repo tag. This is what I get: 1348/2199 - kde-l10n-Walloon-4.2.2-1.fc11.noarch 1349/2199 - kde-l10n-Lithuanian-4.2.2-1.fc11.noarch 1350/2199 - 1:perl-Error-0.17015-2.fc11.noarch Traceback (most recent call last): File /usr/libexec/kojid/mergerepos, line 241, in module main(sys.argv[1:]) File /usr/libexec/kojid/mergerepos, line 236, in main merge.write_metadata() File /usr/libexec/kojid/mergerepos, line 216, in write_metadata mdgen.doPkgMetadata() File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 364, in doPkgMetadata self.writeMetadataDocs(packages) File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 527, in writeMetadataDocs self.primaryfile.write(po.xml_dump_primary_metadata()) File /usr/lib/python2.5/site-packages/yum/packages.py, line 1015, in xml_dump_primary_metadata msg += misc.to_unicode(self._dump_format_items()) File /usr/lib/python2.5/site-packages/yum/packages.py, line 894, in _dump_format_items msg += self._dump_pco('provides') File /usr/lib/python2.5/site-packages/yum/packages.py, line 919, in _dump_pco msg += pcostring UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 28: ordinal not in range(128) Unicode error? I don't get it! Any pointers? Regards, Jitesh -- 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: mergerepos issue
On Fri, 5 Jun 2009, Jitesh Shah wrote: Aaah .. some RPMs have unicode in their 'provides' tag which causes this problem. Temporarily, I have removed those from the external repo and it works fine :) I bet the provides did not have unicode but had random other encoding. -sv -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
package review questions
Hi, I'm working on unofficial package review for redmine ( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ). Redmine is written in ruby and is using rubygem-actionwebservice, which is shipped with redmine. Rubygem-actionwebservice was abandoned by upstream like two years ago, and same happened for fedora package. My question is if redmine package should install it on system or it should be considered as blocker, until upstream of redmine migrate to activeresource. Second question is when redmine contains plugins which are separate applications/libraries (coderay is used by redmine for example) this applications/libraries should be shipped within this package or should be shipped in it's own package (and package should be created when it doesn't exists)? My thoughts are that it should be shipped separately, so it could be used by more applications. Thanks for help, Jan Klepek -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Fri, Jun 5, 2009 at 09:48, Jaroslav Reznik jrez...@redhat.com wrote: Mostly it depends on YouTube - it's 90% of all Flash content for me. So if YouTube (and p0rn variants :D) adopts video tag, battle is nearly won. For games - canvas with JS is nice way. But it's missing IDE as Adobe has - my roommate is using some and I have to admit - it's really great tool - if you are more designer than coder. For now - we have technology, now we need tools. youtube is testing html5 too: http://www.youtube.com/html5 as my flash on fedora10 x86_64 is crashing all the time at the moment I am really looking forward to this. I have some other useful flash usages too, for example the open flash chart: http://teethgrinder.co.uk/open-flash-chart-2/ , which is used by quite a bit of sites. Some google sites, like analytics and finance also use flash. Cheers Christof -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about web applications
David Nalley, Thu, 04 Jun 2009 07:00:25 -0400: Perhaps I am the least well suited to respond as I did some of the initial review. However, there are at least 10 bundled libraries with ampache, including pear-XML_RPC, nusoap, getid3, small snippets from Horde, captchaphp, php-Snoopy, etc. In addition to the security benefits, creating the separate package means other packages (even other web apps) can make use of the libraries that would be available in Fedora instead of just ampache. I can empathize with the extra work that this causes, as I am trying to fix a few of these problems with another web app. Yes, it is PITA, but try to compare this with situation about Java packages and your problems will suddenly look trivial ;-). Yes, all dependencies needs to be separated into their own packages (*if possible* from their respective upstream sources) and your package should be just requiring them. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Reindl Harald, Thu, 04 Jun 2009 20:45:21 +0200: I think it is simple BAD to close bugreports with upstream! For me as enduser of fedora i have one bugzilla and i really like to help with bugreports, try things if maintainer needs better explains what happens. As you can see from this thread, there are as many opinions on this issue as there are packages in Fedora ;-). It all depends from the style of packager's work. E.g., openoffice.org maintainer prefers to move all non- packaging bugs upstream ASAP (he does the moving) and then he works on them upstream (firefox maintainers have similar attitude). Advantage (and one of the foundational pieces of Red Hat philosophy) is that a) our work can be shared with others, b) we can use results of others work. And yes, whole process of upstreaming should be invisible and painless to reporter of RH bug, but our tooling in this area is non-existent. Join the party at https://bugzilla.redhat.com/show_bug.cgi?id=452962 :) Matej -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 20:23:01 Adam Williamson escribió: On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: I'll happily raise upstream bugs myself but it irks me when maintainers close Fedora bugs with the UPSTREAM resolution without actually taking the upstream fix and bringing it into Fedora. If I've reported a bug in Fedora bugzilla it's because the bug is present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a bug closed UPSTREAM doesn't help at all if I have a real problem with a Fedora package. In Mandriva I had it set up so Bugzilla has both an UPSTREAM *resolution* and an UPSTREAM *keyword*. This handles this situation. If, say, the bug is in a package that gets frequent releases, and was filed on the development release, you can just use CLOSED UPSTREAM, because you can rely on the fact that there'll be a new upstream release of the package soon after the upstream report is fixed, you (the maintainer) will then naturally package the new release, and the fix for the bug will have been rolled into the distribution package without you having to do anything besides your normal packaging work. In other situations, you can set the UPSTREAM keyword, so the bug remains open but you know it's being handled upstream and you need to bring the fix downstream once it's available upstream. I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and CLOSED bugs are not as easy to search for duplicates when you are reporting bug. Jaroslav 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: Some pulseaudio questions...
On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: Folks, Anyone want to clarify my understanding of PA's use of mlock/posix_madvise? From looking over the code - in particular pa_will_need, and its callsites - it looks like PA doesn't really use this support that it has for locking pages. Which seems weird. mlock() is not actually used anymore by PA on modern kernels. The longer story goes like this: Text book RT applications use mlock()/mlockall() to lock themselves into memory and make sure they never are swapped out. This is something we cannot really do for PA given that map a *lot* of stuff into our address space: libraries, SHM segments for communications with other clients, cached samples, and so on. If we'd lock all that into memory there wouldn't be any memory left for much else, i.e. all other programs would have to share what is remaining and would have to swap all the time. Given that PA is just an auxiliary tool and not the main reason people run computers this is hence not an option. Due to that PA doesn't use mlock()/mlockall() like textbooks suggest, and it never did. Now, just ignoring the whole locking issue is also not an option. So I tried to find a compromise: try my best to make sure that the data accessed by the RT threads is available in memory but ignore the rest of the memory. To achieve that I needed a way to safely swap in memory when *I* need it to instead of letting the kernel to do as it as late as possible. Then, whenever the non-RT threads in PA pass off data to the RT threads I first swap the data in explicitly. That way I hope that the RT threads never need to wait for swapping in and can continue to loop in their little loops and continue to do whatever else they might want to do, but not wait for disks spinning. There is a system call for requesting swapping in of memory: posix_madvise(POSIX_MADV_WILLNEED). A few kernel releases ago this didn't work for anonymous memory, only for file-backed memory. (But on my request this was then changed in the kernel). Now, to support older kernels I added a dirty dirty hack: I try to lock those pages into memory and then unlock them right away, which should have about the same effect as the madvise() call. On current kernels that mlock() is never tried however, because WILLNEEED works fine anyway. And it's a horrible hack. And I probably should remove this from PA now. I'll admit I'm about ready to hack in some horrible mlockall hacks to see if that'll stop the poppy/skippyness on this box. I doubt that locking PA into memory will fix your issues. If PA drops out often this might have various reasons, but probably not swapping. Often the timing calls of your sound driver are inaccurate and cause PA to miss its deadlines. To work around that you could try disabling timer-based scheduling mode and revert to sound card IRQ scheduled playback. For that try passing tsched=0 to module-hal-detect in /etc/pulse/default.pa. Then restart PA. Another issue might be that PA does not actually get scheduled often enough by the kernel. Might be caused by a bad driver (nvidia closed source). You can run PA as RT if you wish (which we hopfully will be able to enable by default in F12). For that increase RLIMIT_RTPRIO to 10 or so in /etc/security/limits.conf and login again. Usually running pulseaudio -v in a terminal might give you a hint what might be going wrong. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 01:23 PM, Bastien Nocera wrote: I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. My experience with scanning in Fedora is so awful that I dropped any expectation: I have an old HP ScanJet 5370C, for which according with sane-project.org the support is Good (avision backend). For me the best was around F9, when it worked 50% of the time: a scan operation produced garbage, the next one was usable, the next one garbage and so on. I always had to scan twice to get something acceptable. F8 and earlier it produced garbage most of the time and in F10 the application just got frozen, doing nothing and I had to kill it. Now F11 is a new low: when pressing the scan or preview buttons from either xsane-gimp or gnomescan the result is X crashing and me seeing the GDM screen. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? Am Interested I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Not sure if have the necessary skills yet. If I got some mentoring, would be up for it. Cheers /Bastien, who doesn't own a scanner Brand X Scanner (PCline?) FRank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On 06/05/2009 06:57 AM, Lennart Poettering wrote: Usually running pulseaudio -v in a terminal might give you a hint what might be going wrong. Lennart, Maybe this is a stupid question (you know I am constantly full of them), but is there any way for pulseaudio to detect this common condition where the audio is skipping and inform the user of the possible workarounds (maybe a DBUS popup or something directly to syslog). I'm just considering that the average user might not make the leap to running pulseaudio -v in a terminal to figuring this out. Just brainstorming, ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 08:56:47AM -0400, Tom spot Callaway wrote: On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box Same here. Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 04:14 PM, Matthias Clasen wrote: On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: Now F11 is a new low: when pressing the scan or preview buttons from either xsane-gimp or gnomescan the result is X crashing and me seeing the GDM screen. X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. It crashes every time when I am trying to scan with a GUI, the only way to do somehing without a crash is using scanimage from commandline, which is aborting with scanimage: received signal 15. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: Now F11 is a new low: when pressing the scan or preview buttons from either xsane-gimp or gnomescan the result is X crashing and me seeing the GDM screen. X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide moving on to Fedora 12 content
2009/6/5 Jesse Keating jkeat...@redhat.com: I've made the switch tonight so that rawhide will be Fedora 12 content. This will cause a huge number of updates, if the compose actually finishes, and will finish quite late. For the next few days, attempts to use mirror manager for the Fedora 11 repo will fail. This is something we hope to fix at the Fedora Activity Day next week. Couldn't this have waited until F11 was out? Else the people that are testing F11-preview will be out of luck with using yum to install or update. Or did I understand incorrectly the comment above? -- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 04:32:12PM +0300, Nicu Buculei wrote: On 06/05/2009 04:14 PM, Matthias Clasen wrote: X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. FWIW I've had no trouble using xsane in F11. -- 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: Interested in scanning?
On Fri, Jun 05, 2009 at 08:56:47AM -0400, Tom spot Callaway wrote: On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. I'm willing to help with testing. I have a Epson 4490, and Nikon Coolscan V slide scanner. The latter has been a trainwreck with sane for a long time, but I'm told its finally possible to use it. So if we have a nice GUI front end for scanning, i'll help out with testing. Daniel, who has 'vuescan' as the only closed source software on his Fedora machine for which no practical open source replacement yet exists. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 04:47 PM, Matthew Garrett wrote: On Fri, Jun 05, 2009 at 04:32:12PM +0300, Nicu Buculei wrote: On 06/05/2009 04:14 PM, Matthias Clasen wrote: X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. So I should fill a but for both Xsane, GnomeScan and X.org? FWIW I've had no trouble using xsane in F11. Different hardware, different sane backends. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Friday 05 June 2009 08:56:47 Tom spot Callaway wrote: On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box nb: I have two scanners up here as well that can be utilized, they're actually dual firewire/usb scanners that krh got when working on the firewire stack (and I inherited when I was working on it). Of course, last I knew, they both worked just fine using the gimp sane plugin, so they may not be all that interesting. (One is an Epson somethingorother, one is a Microtek, both are reasonably nice scanners) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 05:11 PM, Matthew Garrett wrote: On Fri, Jun 05, 2009 at 05:01:58PM +0300, Nicu Buculei wrote: On 06/05/2009 04:47 PM, Matthew Garrett wrote: If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. So I should fill a but for both Xsane, GnomeScan and X.org? Against X.org first. Finding out why it's crashing would give insight into where the root cause is. OK FWIW I've had no trouble using xsane in F11. Different hardware, different sane backends. Almost certainly. But it's a far cry from Scanning is broken in Fedora. I prefixed it with for me, i know it works for some people. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Hi, 2. to GDM maintainers: Is it possible to change the list of languages dynamically (based on the language-supports installed) on the GDM login screen? We only show a language in the language list if 1) It's got at least one translation in /usr/share/locale 2) it's recognized by libc as a valid utf8 locale 3) it's listed in iso-codes 4) it's got enough font converage to at least show it's own name in the language list. --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Am Freitag, den 05.06.2009, 20:30 +0530 schrieb Ankitkumar Rameshchandra Patel: Nicolas Mailhot wrote: Le Ven 5 juin 2009 15:06, Ankitkumar Rameshchandra Patel a écrit : applications like gedit, nautilus showing square boxes instead of Hindi text. Actually, in F11 they'll show a nice popup suggesting to look for and autoinstall hindi fonts. So this part is already fixed (maybe not in all apps but in pango-based apps at least) That's good to know. Thanks Nicolas. But, it's not only the matter of fonts, rather language support which includes - fonts, input method (and maps), spell checker, openoffice langpack, kde langpack and language packs for various other applications. So, how are we going to solve those things? By doing yum install hindi-support?! We cannot put all languages on the LiveCD because there is not enough space. Currently the group hindi-support looks like this: group idhindi-support/id _nameHindi Support/_name _description/ defaultfalse/default uservisibletrue/uservisible langonlyhi/langonly packagelist packagereq type=mandatorylohit-hindi-fonts/packagereq packagereq type=mandatorym17n-contrib-hindi/packagereq packagereq type=mandatorym17n-db-hindi/packagereq packagereq type=conditional requires=aspellaspell-hi/packagereq packagereq type=conditional requires=gcomprisgcompris-sound-hi/packagereq packagereq type=conditional requires=hunspellhunspell-hi/packagereq packagereq type=conditional requires=hyphenhyphen-hi/packagereq packagereq type=conditional requires=xorg-x11-server-Xorgibus-m17n/packagereq packagereq type=conditional requires=kdelibs3kde-i18n-Hindi/packagereq packagereq type=conditional requires=kdelibskde-l10n-Hindi/packagereq packagereq type=conditional requires=moodlemoodle-hi/packagereq packagereq type=conditional requires=openoffice.org-coreopenoffice.org-langpack-hi_IN/packagereq packagereq type=defaultiok/packagereq packagereq type=defaultsamyak-devanagari-fonts/packagereq packagereq type=defaultsarai-fonts/packagereq /packagelist /group Is there something you are missing? Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Le Ven 5 juin 2009 17:03, Ray Strode a écrit : Hi, 2. to GDM maintainers: Is it possible to change the list of languages dynamically (based on the language-supports installed) on the GDM login screen? We only show a language in the language list if 1) It's got at least one translation in /usr/share/locale 2) it's recognized by libc as a valid utf8 locale 3) it's listed in iso-codes 4) it's got enough font converage to at least show it's own name in the language list. Please, the main use of the language list is to select a keyboard layout. All the keyboard defs are installed by default. Punting a user to qwerty just because those other bits are missing is not going to make anyone happy. Especially if the user password can not be typed using qwerty. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Ankitkumar Rameshchandra Patel (an...@redhat.com) said: I think above checks only ensures the technical (rather i18n) support exists. But, what about the native language desktop users who expects fedora to be equal for all languages (just like english)? How about, We only show a language in the language list if - language-support is installed (e.g. yum groupinstall chinese-support) Well, there are languages we would support fine that don't have a specific language-support group (most anything that uses a Latin-1 like charset, and no specific input method.) Moreover, the groups that are installed aren't actually recorded anywhere on the installed system. (And having gdm attempt to discover/compute what groups are installed is completely impractical.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 08:56 -0400, Tom spot Callaway wrote: Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box I have a relatively new Canon Scanner, that has no current hope of working on Linux. Boy I'd love to see that changed. -- 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: Maintainer Responsibilities
On Thu, 2009-06-04 at 23:19 +0200, Edwin ten Brink wrote: Aside from all discussions in this thread, the current Bugzilla documentation seems quite clear on this topic. Whatever the outcome of the discussion is, I think the documentation which is visible to the end-user (customer), should at least match the common practice/procedure. Note also that the discussion is primarily focussed on the Resolution of the bug report, while there are also two Keywords available with respect to upstream. I've quoted the full texts below for reference. From https://bugzilla.redhat.com/describekeywords.cgi This page doesn't really cover Fedora policy or practice, it covers RHEL policy and practice, which is not the same thing. The next revision of Bugzilla will in fact include a link on this page, directing you to: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow for the Fedora policy and practice. That page says in passing: The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report. but that's just what I wrote when updating the page, it's not based on any official discussion / agreement, so I made it intentionally vague and (hopefully) non-controversial. -- 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: Rawhide moving on to Fedora 12 content
On Fri, 2009-06-05 at 10:36 -0300, Martín Marqués wrote: Couldn't this have waited until F11 was out? Previous releases we've waited longer, but given that F12 is a short release cycle, and that we delayed F11 release twice it was important that we get rawhide moving on for the sake of F12. Else the people that are testing F11-preview will be out of luck with using yum to install or update. Or did I understand incorrectly the comment above? They'll have access to the updates and updates-testing repo, just not the 'fedora' repo. It is a bit of an inconvenience for users for a few days. -- 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: GDM Language list...
Mathieu Bridon (bochecha) wrote: How about that: 1. user chooses a language in GDM for the first time 2. PK tries to install the language-support group 3. if this group exist and some packages could be installed (i.e. not already installed), the user is presented a nice PK popup, just like the font or codec install suggestion, but for the support of his language If no packages need to be installed, then the user won't be bothered by an obtrusive popup. We can do it only the first time as, well, if it doesn't work the second time, then the user specifically chose not to install them or to remove one of the required packages There is yet another dependency of internet connection here... -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Fri, 2009-06-05 at 10:44 +0200, Jaroslav Reznik wrote: In other situations, you can set the UPSTREAM keyword, so the bug remains open but you know it's being handled upstream and you need to bring the fix downstream once it's available upstream. I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and CLOSED bugs are not as easy to search for duplicates when you are reporting bug. As Edwin noted, there is in fact an Upstream keyword in RH Bugzilla (and a 'MoveUpstream' keyword). 'Upstream' appears only ever to have been used for two bugs, however. 'MoveUpstream' seems to have been used extensively in the past, but rarely lately: it does seem to fit the case I described, however. So, yeah, if you like this idea, use the 'MoveUpstream' keyword. :) -- 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: Action requested: check dist tags and conditionals
Toshio Kuratomi (a.bad...@gmail.com) said: Does this look like the right generic structure for doing this: %if 0%{?fedora} = X || 0%{?rhel} = Y # Do things from X until Current Fedora, Y until Current RHEL # Y should be the latest released version if we don't know that # it's not going to change in the next version %else %if %{fedora} 0%{fedora} X ! %{rhel} # Do things for Fedora X %else %if ! %{fedora} %{rhel} 0%{rhel} Y # Do things for RHEL Y %else # Do things for any other distros %endif %endif %endif If so, then we'd want to prettify and codify it a bit so we can put it in the Packaging Guidelines Looks reasonable. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 11:23 +0100, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Cheers /Bastien, who doesn't own a scanner I have a scanner, but it's a rather well-behaved one (an HP ScanJet 2100C). As long as SANE is installed you don't really need to do anything to set it up - you can just run GIMP or xsane directly and get to scanning. Looking at gnome-scan, I see the author is asking for help: http://blogs.gnome.org/gnome-scan/ testing it out, it seems a bit odd - it certainly has a nicer interface than xsane's horribleness, but it seems a bit weird in places. It defaulted to a rather odd scanned image size for me, and the preview tab would only show that area of the page. I then switched to the 'Letter' size on the main tab, previewed again, and the preview seemed to come out right - but I couldn't then click and drag to resize the area to be scanned. I had to go back to the main tab, switch back to 'Manual', then go back to the preview tab before I could click and drag to resize - and if I then tried to refresh the preview, it didn't preview correctly again, it only previewed a tiny corner of the area and I couldn't click and drag the selection to make it any bigger. So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). On the packaging side of things, I would also be happy to help but it looks like we're not short of volunteers. What would be useful, I guess, is input from anyone who has a scanner that's a pain to set up, explaining what they have to do, so we could look into how we could ease that task. I may do a quick build of gnome-scan 0.7.1 to see if it addresses my problems, though that's an unstable release we may not want to package officially. The thought also occurs that this is an area that would be helped by one of my little hobby horses, the pony that I'd like to have which I call HardwareKit, which is just my name for a little widget/layer/whatever between udev/HAL/DeviceKit and PackageKit: it would allow the system to prompt you to install a given set of packages when it notes a certain piece or type of hardware being plugged in. So, in this case, if HAL/DeviceKit notices a scanner being plugged in, it could call out to PackageKit to install our scanning package group. That's something I've been wishing we had for a while now. -- 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: Some pulseaudio questions...
On Fri, 2009-06-05 at 11:11 -0400, Jon Masters wrote: On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: Text book RT applications use mlock()/mlockall() to lock themselves into memory and make sure they never are swapped out. This is something we cannot really do for PA given that map a *lot* of stuff into our address space: libraries, SHM segments for communications with other clients, cached samples, and so on. If we'd lock all that into memory there wouldn't be any memory left for much else Yeah, I'm aware of this. But there perhaps should be some option anyway - after all, you already have all the support code for it, and already handle setting real time priorities too. In my brief time with a hacked up local build that does an mlockall right at the beginning of the mainloop, I am hearing few audio pops and skips on this box. It's obviously not a longer term solution, just a datapoint. I'll join the PA devel list over the weekend, it's not strictly that Fedora specific now. But one thing I'm wondering is whether you might benefit from splitting PA into a small core-util bit that were lockable and having all the rest outside in separate tasks - that's probably not too feasible at this stage though. I want to help fix whatever problems I'm getting on each of my machines running PA, rather than sound like I'm trashing talking PA as a technology. The sad reality is that Linux audio worked for me more smoothly 14 years ago when I started with Linux (and manually had to set jumpers, run isapnpdump, etc.) than it does now. It was smoother when I had early ESD[0] than it is now, and smoother when I first built experimental ALSA drivers than it is now. Things like PA are a great concept in theory, but they're not of much benefit if (as in my case) the only obvious way I can get an decent experience is to hack my system and run stuff under pasuspender. Jon. [0] And I mean alongside 0.1 enlightment, back when I had the Free Software Song as a ringtone and enjoyed hearing the startup pips as ESD opened the sound device. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). IMO the obnoxious license dialog that xsane still subjects you to is sufficient reason already to replace it. We don't tolerate dialogs like that in other default-installed components... Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 12:50:40PM -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). IMO the obnoxious license dialog that xsane still subjects you to is sufficient reason already to replace it. We don't tolerate dialogs like that in other default-installed components... Why don't we patch it out then Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 17:56 +0100, Daniel P. Berrange wrote: On Fri, Jun 05, 2009 at 12:50:40PM -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). IMO the obnoxious license dialog that xsane still subjects you to is sufficient reason already to replace it. We don't tolerate dialogs like that in other default-installed components... Why don't we patch it out then Ok, lets try that: https://bugzilla.redhat.com/show_bug.cgi?id=504344 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Just wanted to run this by the group to make sure it's desired before I start working on it... I've been dipping my toes into packaging things for Fedora lately, and one thing that feels a bit awkward is that the packaging guidelines are full of boilerplate like: Use this when a desktop entry has a 'MimeType key. %post update-desktop-database /dev/null || : %postun update-desktop-database /dev/null || : noarch packages The following macros must be used at the top of the spec file to determine the correct installation paths: %{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)} %{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}} If you are installing anything into the global site_packages directory, use the following trick. First, define python_sitelib at the top of your specfile: %{!?python_sitelib: %global python_sitelib %(%{__python} -c from distutils.sysconfig import get_python_lib; print get_python_lib())} Heck, there's an entire page full of these: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets it seems to me that this is a bit of a silly approach - it encourages cut and paste errors (or people cutting and pasting non-canonical blocks from other people's spec files), it just looks bad in spec files, and if any of those snippets happens to need to be changed a bit - say, the syntax for updating the desktop database changes, or something - we'd have to adjust them in seven zillion different spec files. It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? If I'm right, I'm happy to work on this and contribute it as patches to the relevant packages, or as a new package in itself, or something. Where should such macros go? Should we have a separate package for them which is brought in when you install the development environment package set? Or should they be added to the appropriate -devel packages - e.g., Tcl snippets should be turned into a /etc/rpm/macros.tcl that's in the tcl-devel package? Or a combination of the two? Thanks! -- 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: orphaning nopaste // ruby help wanted for broken package
Simon Wesp wrote: Dear List, short version: I'm going to orphan nopaste since rafb.net/paste, which was used by this package, is discontinued (bug #504108). I tried to contact upstream four times and asked if they were planning to switch to another provider, but no avail If someone with ruby skills is able to rewrite nopaste for another pastebin, he/she is welcome to take over the package. I do ruby. I'd be willing to look when I get home today. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Fri, Jun 5, 2009 at 7:34 PM, Casey Dahlincdah...@redhat.com wrote: Simon Wesp wrote: Dear List, short version: I'm going to orphan nopaste since rafb.net/paste, which was used by this package, is discontinued (bug #504108). I tried to contact upstream four times and asked if they were planning to switch to another provider, but no avail If someone with ruby skills is able to rewrite nopaste for another pastebin, he/she is welcome to take over the package. woot.!I Was meaning to contact you about this.I already own perl-App-Nopaste whiich can also proveide /usr/bin/nopatse (with lots more possibilities than rafb). More than happy to obsolete/provide (and extend to support fpaste too). If anyone beats me too it - iwannit! -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Hi, On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamsonawill...@redhat.com wrote: I've been dipping my toes into packaging things for Fedora lately, and one thing that feels a bit awkward is that the packaging guidelines are full of boilerplate like: [...] Heck, there's an entire page full of these: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets [...] It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? It would be awesome to get rid of the boilerplate. Honestly though, I'd rather the solution was just works than replace giant glob of muck with %{glob_of_muck} For instance, if a file gets dropped under /usr/share/icons/something rpm should run gtk-update-icon-cache /usr/share/icons/something automatically. the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat that makes that happen. likewise, desktop-file-utils should be able to drop a file there to make update-desktop-database get run and so on. I don't know how hard it would be to fix rpm to allow for that though. --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
Iain Arnell wrote: On Fri, Jun 5, 2009 at 7:34 PM, Casey Dahlincdah...@redhat.com wrote: Simon Wesp wrote: Dear List, short version: I'm going to orphan nopaste since rafb.net/paste, which was used by this package, is discontinued (bug #504108). I tried to contact upstream four times and asked if they were planning to switch to another provider, but no avail If someone with ruby skills is able to rewrite nopaste for another pastebin, he/she is welcome to take over the package. woot.!I Was meaning to contact you about this.I already own perl-App-Nopaste whiich can also proveide /usr/bin/nopatse (with lots more possibilities than rafb). More than happy to obsolete/provide (and extend to support fpaste too). If anyone beats me too it - iwannit! You can have it. Your solution sounds better. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESco meeting summary for 20090605
We are trying out a meeting irc bot plugin to handle meetings in a more consisent and timely manner. You can find a copy of the meeting output at: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html We would appreciate feedback on this format for meeting logs. If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Ray Strode wrote: Hi, On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamsonawill...@redhat.com wrote: I've been dipping my toes into packaging things for Fedora lately, and one thing that feels a bit awkward is that the packaging guidelines are full of boilerplate like: [...] Heck, there's an entire page full of these: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets [...] It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? It would be awesome to get rid of the boilerplate. Honestly though, I'd rather the solution was just works than replace giant glob of muck with %{glob_of_muck} For instance, if a file gets dropped under /usr/share/icons/something rpm should run gtk-update-icon-cache /usr/share/icons/something automatically. the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat that makes that happen. likewise, desktop-file-utils should be able to drop a file there to make update-desktop-database get run and so on. I don't know how hard it would be to fix rpm to allow for that though. Just off the top of my head, this doesn't feel like something rpm should be in charge of. To me it seems more likely that we need something in a base/core rpm that installs an inotify script for system dirs that does what it should when something is dropped into it...? -- Nathanael d. Noblet T: 403.875.4613 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Nathanael D. Noblet wrote: I don't know how hard it would be to fix rpm to allow for that though. Just off the top of my head, this doesn't feel like something rpm should be in charge of. To me it seems more likely that we need something in a base/core rpm that installs an inotify script for system dirs that does what it should when something is dropped into it...? Ugh, no. We don't need another running service to do this. Just have rpm do it as part of its post install and you don't need to involve inotify; it knows a file showed up because it put it there a few milliseconds ago. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? It would be awesome to get rid of the boilerplate. Honestly though, I'd rather the solution was just works than replace giant glob of muck with %{glob_of_muck} Yes indeed, this would be best in many cases. Some can't really be done like that, though - like the snippets for Tcl and Python to define the version, directories for certain types of file and so on. They're just...informational. Defining them as macros seems the optimal solution. For instance, if a file gets dropped under /usr/share/icons/something rpm should run gtk-update-icon-cache /usr/share/icons/something automatically. the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat that makes that happen. likewise, desktop-file-utils should be able to drop a file there to make update-desktop-database get run and so on. I don't know how hard it would be to fix rpm to allow for that though. This is definitely possible; Mandriva (I know I talk about MDV a lot, I'm sorry, it's what I know! :) does this, via an implementation called 'file triggers'. This is not yet upstream, though. The MDV patch that implements this is: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup MDV's wiki discussion of it is here: http://wiki.mandriva.com/en/Rpm_filetriggers It appears to be something upstream has thought about several times. Here's an RPM 5 community discussion of it, with Jeff Johnson's thoughts: http://rpm5.org/community/rpm-devel/2959.html Here's a discussion from the rpm.org Wiki: http://www.rpm.org/wiki/Problems/Scriptlets I'm not sure what the current status is for rpm.org - whether they're actively working on a solution for this side of things or what. Oh, and please try to consider the original proposal in replies to this thread, as I sense a derail coming :). file triggers is certainly an interesting topic, but there are some snippets which just don't fit the case, see above. -- 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 5 Jun 2009, Nathanael D. Noblet wrote: [...] It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? It would be awesome to get rid of the boilerplate. Honestly though, I'd rather the solution was just works than replace giant glob of muck with %{glob_of_muck} For instance, if a file gets dropped under /usr/share/icons/something rpm should run gtk-update-icon-cache /usr/share/icons/something automatically. the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat that makes that happen. likewise, desktop-file-utils should be able to drop a file there to make update-desktop-database get run and so on. I don't know how hard it would be to fix rpm to allow for that though. Just off the top of my head, this doesn't feel like something rpm should be in charge of. To me it seems more likely that we need something in a base/core rpm that installs an inotify script for system dirs that does what it should when something is dropped into it...? 1. file-globs-based actions means it works for everything 2. inotify doesn't work on FS 3. inotify can't be run for ALL FILES things are happening to make it possible to do the above in rpm. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
Here also is the full txt file of the meeting: 17:00:15 nirik #startmeeting 17:00:28 nirik #meetingtopic FESCo Meeting - https://fedorahosted.org/fesco/report/9 17:00:38 jds2001 nirik: you drive this meeting, I'm not sure how to operate this new-fangled thing :D 17:00:57 nirik happy to. I was going to make that the first topic. ;) 17:01:10 * nirik thought jds2001 wasn't going to be around today. Moving done? 17:01:36 jds2001 that was yesterday. 17:01:41 jwb wait, what thing? 17:01:46 jds2001 I still have boxes all around :( 17:01:51 jds2001 jwb: fedbot 17:01:57 jwb so we're not doing gobby? 17:02:00 * dgilmore is here 17:02:17 jds2001 we could try each I guess. 17:02:21 nirik well, lets go ahead and discuss which we want to do... 17:02:25 nirik #topic ticket 158: Create new meeting summary procedure 17:02:28 jwb fedbot 17:02:33 jwb because i don't have gobby setup :) 17:02:49 nirik so, this is a plugin to supybot, created by the fine debian folks. 17:03:10 nirik it runs the meeting and produces a log and summary and such. 17:03:29 notting examples of the summaries? 17:03:30 dgilmore nirik: i like the idea its something everyone can use and we can post all meetings logs to a common location 17:03:43 * nirik is digging up a example. 17:03:58 nirik http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-04-16.33.html 17:04:06 nirik this was the IRC Support sig meeting yesterday. 17:04:13 nirik dgilmore: yeah, I would like that too. 17:04:27 jwb we could still use both 17:04:29 nirik currently it's running on my machine here, but we could easily add it to zodbot and get it on a fedora location. 17:04:43 notting so, it's all keyword based? 17:04:44 jwb nirik, could have febot log to gobby 17:04:54 nirik notting: yeah. 17:04:57 nirik #commands 17:05:10 jwb we need a #gobby 17:05:11 jwb :) 17:05:18 jds2001 nirik: is it packaged? 17:05:23 notting hm. it might be simpler, i'm not sure if it will end up more legible on the list/wiki 17:05:29 nirik this does more than log, it does summary and such. 17:05:41 nirik jds2001: not yet. I can do so. 17:05:49 jwb notting, at this point i think we should just focus on getting something there consistently 17:05:54 jwb notting, cleanup can happen later 17:06:04 notting jwb: right, but that can be done by just assigning someone :) 17:06:13 nirik I would like all meetings to use the same format and go the same place and be searchable. ;) 17:06:13 jds2001 notting: i could setup something like http://fp.o/meetings/whatever 17:06:22 jds2001 to point to the right spot on noc1. 17:06:32 dgilmore nirik: yep 17:06:42 jwb notting, true. but robots are soo much cooler 17:06:48 nirik we have a bunch in the wiki as well. 17:06:49 jds2001 so that we dont have to put it on the wiki. 17:06:52 nirik Meeting: space 17:07:10 notting jds2001: well, we'd still want them all (both before and after we change) in the same place 17:07:12 nirik but the wiki search is... suboptimal 17:07:51 jds2001 nirik: i google site:fedoraproject.org whatever I'm looking for :( 17:08:13 nirik so, I guess I think this is usable, but if we just want to assign a minutes taker, or try gobby, or whatever I am open to it if people feel its better. 17:08:43 * abadger1999 notes that we should make sure the logs get backed up. 17:08:46 nirik perhaps ask for feedback from people who read logs after this meeting? 17:08:59 notting nirik: works for me 17:09:12 jds2001 abadger1999: noc1 gets backed up, right? 17:09:14 * nirik nods. I backup the machine they are on here. ;) But yes, if they go to noc1 they should get backed up 17:09:20 jds2001 if we add this plugin to zodbot? 17:09:43 abadger1999 jds2001: I don't know, thus: make sure ;-) 17:09:52 notting nirik: maybe take the log from this and post it on the wiki, get comments, and we can move everything together later? 17:10:29 nirik well, not sure it would post right to the wiki. It expects to be it's own html/txt file. 17:10:37 nirik but yes, I can ask for feedback from it. 17:10:51 nirik it does allow logs to be posted right when the meeting is done, which is nice. 17:11:06 nirik also links to the items in the logs, etc. 17:11:50 * nirik waits for any other votes/opinions. 17:12:05 jwb i'm good with either 17:12:32 sharkcz the bot looks good 17:12:38 jds2001 i like the bot. 17:12:49 * j-rod happy w/the bot, knows nothing of gobby at all though 17:13:19 nirik #action nirik will post the summary/logs from the meeting plugin for comment/feedback on fedora-devel. 17:13:24 nirik ok, shall we move on? 17:14:07 nirik #topic ticket 159: FPC report - 2009-06-02 17:14:11 nirik .fesco 159 17:14:14 zodbot nirik: #159 (FPC report - 2009-06-02) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/159 17:14:30 jwb +1 17:14:45 sharkcz +1 17:14:58 notting +1 17:14:59 j-rod +1 17:14:59 nirik seems reasonable to reduce the number of duplicate things in spec files... +1 here. 17:15:24 jds2001 n+1 17:16:11 nirik #agreed Approval for ticket 159
Re: GDM Language list...
Ankitkumar Rameshchandra Patel wrote: There is yet another dependency of internet connection here... An Internet connection (and a reasonably fast one at that) is basically required to use Fedora effectively. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On 06/05/2009 10:51 AM, Kevin Fenzi wrote: We are trying out a meeting irc bot plugin to handle meetings in a more consisent and timely manner. You can find a copy of the meeting output at: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html We would appreciate feedback on this format for meeting logs. If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. kevin Notting's #agreed note wasn't picked up by meetbot: 17:30:11 notting #agreed rsync should be fixed in the same manner -Toshio 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Adam Williamson wrote: %{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)} %{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}} %{!?python_sitelib: %global python_sitelib %(%{__python} -c from distutils.sysconfig import get_python_lib; print get_python_lib())} This kind of stuff should really be provided in RPM macros in a package which is BRed anyway (tcl resp. python themselves are good candidates). I really don't see why the macro has to be defined by the specfile itself, that makes no sense. For KDE 4, that kind of macros is defined by kde-filesystem. MinGW does the same in mingw32-filesystem now. It's also kinda silly to have to query the tcl or python binary at runtime for this. The RPM macro should be set to a constant value by a package which KNOWS the constant value (again, like it is in KDE and MinGW, we're not calling kde4-config each time to figure out where to put files!). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On 06/05/2009 10:31 AM, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? If I'm right, I'm happy to work on this and contribute it as patches to the relevant packages, or as a new package in itself, or something. Where should such macros go? Should we have a separate package for them which is brought in when you install the development environment package set? Or should they be added to the appropriate -devel packages - e.g., Tcl snippets should be turned into a /etc/rpm/macros.tcl that's in the tcl-devel package? Or a combination of the two? To some extent, yes. macros can go overboard, though. I think that the macros you're planning are going to make sense, though :-) The way to get these changed is to first go through the Packaging Committee to get the changes approved, then have the macros merged into the packages that will provide them. Then patch the packages that should be updated. Note: I remember one argument against macros being that they make spec files harder to port between distros but I'm not willing to champion that argument. If someone else does, I'll certainly listen to the reasoning, though. :-) -Toshio 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: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. We should probably try to have these transferred to the wiki, under the Meeting: namespace, with an appropriate category assigned. Perhaps the bot could be given an account that would allow that access? -- 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... Honestly, that just sounds silly. It's not obscuring things, it's a sensible level of abstraction and reuse. I suspect you'd have trouble selling that position to developers - instead of calling functions from obscure external libraries, just copy and paste the code from them into every single app you build! I don't think that'd go down a storm. ;) As long as there's a clear and sensible policy for how macros should be implemented (what the files should be called and what packages they should go in), they wouldn't be 'obscure' at all. All you'd need to do to check what a given macro did would be 'grep (macroname) /etc/rpm/macros.*' or something similar. -- 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote: To some extent, yes. macros can go overboard, though. I think that the macros you're planning are going to make sense, though :-) Thanks. The way to get these changed is to first go through the Packaging Committee to get the changes approved, then have the macros merged into the packages that will provide them. Then patch the packages that should be updated. Would it be best to have the concrete implementation (or at least some examples) built before taking it to the packaging committee, or no? Note: I remember one argument against macros being that they make spec files harder to port between distros but I'm not willing to champion that argument. If someone else does, I'll certainly listen to the reasoning, though. :-) The obvious answer to that is to try and standardize macro usage between distributions, not to not use macros. For e.g., I revamped the Mandriva Tcl packaging policy late last year: I took the macro names and even code snippets from Fedora's Tcl policy. I just implemented them as system-wide macros in the tcl-devel package instead of writing in the policy that they should be re-defined at the top of every spec file :) -- 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: (Most) Results from the Candidate Questionnaire are available now
Sorry, was a bit busy over the past few days and didn't get around to answer all mails. On 04.06.2009 00:30, Andreas Thienemann wrote: On Wed, 3 Jun 2009, Paul W. Frields wrote: [...] I'm disappointed this ended up being a more difficult process than you intended, but I have no doubt we can improve it for the next cycle. Leaving a bit more time between the cut-off date for the questionaire and the town hall meeting should hopefully fix that. My basic idea is to have the question finished and in the wiki after the first half of the nomination period is over. I'd also suggest the answers should get sent in no later than end of nomination period + something like 2 or 3 days. That way the total time of the whole the election business stays roughly the same. People that are late with the nomination then only have something like two or three days to answer the question, but that's their decision -- they could have had 9 or10 days if they had chosen to nominated earlier. CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, 5 Jun 2009 14:56:34 -0400 Paul W. Frields sticks...@gmail.com wrote: On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. We should probably try to have these transferred to the wiki, under the Meeting: namespace, with an appropriate category assigned. Perhaps the bot could be given an account that would allow that access? That would be great, but it currently has no ability to talk to a wiki. The upstream page at http://wiki.debian.org/MeatBot has: Wishlist: Publish to a wiki page? (I'll do it if someone gives me wiki-posting code) So, perhaps someone could contribute that. :) Currently it just writes logs/summary to a local filesystem. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On 06/05/2009 11:59 AM, Adam Williamson wrote: On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote: The way to get these changed is to first go through the Packaging Committee to get the changes approved, then have the macros merged into the packages that will provide them. Then patch the packages that should be updated. Would it be best to have the concrete implementation (or at least some examples) built before taking it to the packaging committee, or no? Yes it would. We'd want to end up with a list of the macros to use in specific circumstances rather than the expanded form that's currently there. In doing that, we'd want to test that the new Guidelines work, so having the concrete implementation is necessary. If this sounds daunting, doing a few at a time is certainly possible. Note: I remember one argument against macros being that they make spec files harder to port between distros but I'm not willing to champion that argument. If someone else does, I'll certainly listen to the reasoning, though. :-) The obvious answer to that is to try and standardize macro usage between distributions, not to not use macros. For e.g., I revamped the Mandriva Tcl packaging policy late last year: I took the macro names and even code snippets from Fedora's Tcl policy. I just implemented them as system-wide macros in the tcl-devel package instead of writing in the policy that they should be re-defined at the top of every spec file :) nod That would be great! -Toshio 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote: On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... Honestly, that just sounds silly. It's not obscuring things, it's a sensible level of abstraction and reuse. I suspect you'd have trouble selling that position to developers - instead of calling functions from obscure external libraries, just copy and paste the code from them into every single app you build! I don't think that'd go down a storm. ;) Libraries have well defined error handling. Macros can get pretty mysterious when they start failing. Poor analogy. joe As long as there's a clear and sensible policy for how macros should be implemented (what the files should be called and what packages they should go in), they wouldn't be 'obscure' at all. All you'd need to do to check what a given macro did would be 'grep (macroname) /etc/rpm/macros.*' or something similar. -- 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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, Jun 5, 2009 at 1:18 PM, Joe Nallj...@nall.com wrote: On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote: On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... Honestly, that just sounds silly. It's not obscuring things, it's a sensible level of abstraction and reuse. I suspect you'd have trouble selling that position to developers - instead of calling functions from obscure external libraries, just copy and paste the code from them into every single app you build! I don't think that'd go down a storm. ;) Libraries have well defined error handling. Macros can get pretty mysterious when they start failing. Poor analogy. ??? There are tons of bugs I have dealt with where a library has gone off into some mysterious way that didn't follow defined error handling. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. The Merchant of Venice -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On Fri, Jun 05, 2009 at 09:04:08PM +0200, Thorsten Leemhuis wrote: Sorry, was a bit busy over the past few days and didn't get around to answer all mails. On 04.06.2009 00:30, Andreas Thienemann wrote: On Wed, 3 Jun 2009, Paul W. Frields wrote: [...] I'm disappointed this ended up being a more difficult process than you intended, but I have no doubt we can improve it for the next cycle. Leaving a bit more time between the cut-off date for the questionaire and the town hall meeting should hopefully fix that. My basic idea is to have the question finished and in the wiki after the first half of the nomination period is over. I'd also suggest the answers should get sent in no later than end of nomination period + something like 2 or 3 days. That way the total time of the whole the election business stays roughly the same. People that are late with the nomination then only have something like two or three days to answer the question, but that's their decision -- they could have had 9 or10 days if they had chosen to nominated earlier. Thorsten, if you get a chance, would you mind hanging a link off the wiki's [[Elections]] page with a brief summary of the procedure you used, and/or any suggestions for improvements? When it comes time for the next election we can refer to it. If you're willing and able then to fill that role, you can refer to it; and if not, we'll be able to carry on as needed. -- 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: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 01:05:06PM -0600, Kevin Fenzi wrote: On Fri, 5 Jun 2009 14:56:34 -0400 Paul W. Frields sticks...@gmail.com wrote: On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. We should probably try to have these transferred to the wiki, under the Meeting: namespace, with an appropriate category assigned. Perhaps the bot could be given an account that would allow that access? That would be great, but it currently has no ability to talk to a wiki. The upstream page at http://wiki.debian.org/MeatBot has: Wishlist: Publish to a wiki page? (I'll do it if someone gives me wiki-posting code) So, perhaps someone could contribute that. :) Currently it just writes logs/summary to a local filesystem. I'd like to try this (and fail badly, and then have it rewritten by someone who knows better). The main problem I see is that the thing's written in Tcl which I don't know. Maybe I could try porting it to a zodbot plugin, and then use python-mediawiki to do the auth + posting. -- 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: (Most) Results from the Candidate Questionnaire are available now
On Thu June 4 2009, Thorsten Leemhuis wrote: On 03.06.2009 21:28, Thorsten Leemhuis wrote: http://www.leemhuis.info/files/fedora/answers-table.ods Both updated with the answers from Dglimore. He has been added twice to the ods table. Regards, Till 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri June 5 2009, Toshio Kuratomi wrote: For things that are replacing actions, there is a certain amount of obscuring being done. This is a barrier for entry for people who know how to build software from upstream but don't know how to package. It also can make debugging harder if something does go wrong in the macro. In case of macros in %post and related sections, afaik one can easily inspect the code after macro expansion using rpm --scripts -q... Regards Till 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: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 12:28 -0700, Toshio Kuratomi wrote: /me notes that we did pass it in the end, though. I don't believe this would be a problem for things like python_sitelib which are defining standard directory locations. using macros for directories is something that we do everywhere. For things that are replacing actions, there is a certain amount of obscuring being done. This is a barrier for entry for people who know how to build software from upstream but don't know how to package. It also can make debugging harder if something does go wrong in the macro. However, these are balanced by giving us the ability to change the instructions in a central location and having that propagate out to the next build of all packages. And they can make it simpler to perform an action correctly if it is complex. I think therefore I'll plan to to the most non-controversial ones first - things like the version and directory macros for Tcl and Python - and then maybe look at the more debated ones after that. I'll bring the first wave of ones to the packaging committee once I have proposed patches ready. Sound good? -- 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: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 01:56:59PM -0600, Kevin Fenzi wrote: On Fri, 5 Jun 2009 15:30:36 -0400 Paul W. Frields sticks...@gmail.com wrote: So, perhaps someone could contribute that. :) Currently it just writes logs/summary to a local filesystem. I'd like to try this (and fail badly, and then have it rewritten by someone who knows better). The main problem I see is that the thing's written in Tcl which I don't know. Maybe I could try porting it to a zodbot plugin, and then use python-mediawiki to do the auth + posting. Oh, the link on the summary is pointing to the wrong page. The tcl thing was the old generation of plugin. The http://wiki.debian.org/MeatBot one which we are using is in python. ;) Yay! -- 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
File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Hi, On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamsonawill...@redhat.com wrote: On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? It would be awesome to get rid of the boilerplate. Honestly though, I'd rather the solution was just works than replace giant glob of muck with %{glob_of_muck} Yes indeed, this would be best in many cases. Some can't really be done like that, though - like the snippets for Tcl and Python to define the version, directories for certain types of file and so on. They're just...informational. Defining them as macros seems the optimal solution. Right, totally agree. For instance, if a file gets dropped under /usr/share/icons/something rpm should run gtk-update-icon-cache /usr/share/icons/something automatically. the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat that makes that happen. likewise, desktop-file-utils should be able to drop a file there to make update-desktop-database get run and so on. I don't know how hard it would be to fix rpm to allow for that though. This is definitely possible; Mandriva (I know I talk about MDV a lot, I'm sorry, it's what I know! :) does this, via an implementation called 'file triggers'. This is not yet upstream, though. The MDV patch that implements this is: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup MDV's wiki discussion of it is here: http://wiki.mandriva.com/en/Rpm_filetriggers It appears to be something upstream has thought about several times. Here's an RPM 5 community discussion of it, with Jeff Johnson's thoughts: http://rpm5.org/community/rpm-devel/2959.html Here's a discussion from the rpm.org Wiki: http://www.rpm.org/wiki/Problems/Scriptlets Oh neat! I'm not sure what the current status is for rpm.org - whether they're actively working on a solution for this side of things or what. Panu, does this patch make sense? Oh, and please try to consider the original proposal in replies to this thread, as I sense a derail coming :). file triggers is certainly an interesting topic, but there are some snippets which just don't fit the case, see above. Right, I'veretitled the subject. I guess there are two different halves to the spec boilerplate problem. --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathanael D. Noblet wrote: Casey Dahlin wrote: Nathanael D. Noblet wrote: I don't know how hard it would be to fix rpm to allow for that though. Just off the top of my head, this doesn't feel like something rpm should be in charge of. To me it seems more likely that we need something in a base/core rpm that installs an inotify script for system dirs that does what it should when something is dropped into it...? Ugh, no. We don't need another running service to do this. Just have rpm do it as part of its post install and you don't need to involve inotify; it knows a file showed up because it put it there a few milliseconds ago. Inotify isn't a service/daemon, and its running already afaik?? Its a kernel API. You need a service running to operate it. - --CJD -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkopsp4ACgkQIHOkVH4pLz5XUQCaAw5Ol2Evm0miTclrIQNJIFgZ 1kUAnRX4X/RYVF0kt9M828cpMwXFs7ps =lmLv -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono ( Moonlight) Licensing? Revisited
On Sun, May 31, 2009 at 12:15 PM, Kevin Kofler kevin.kof...@chello.atwrote: King InuYasha wrote: I really don't see why you should freak out over Moonlight, if Mono is protected, then Moonlight 2 should be protected, since it is a form of Mono itself. Moonlight needs to go to RPM Fusion anyway because it needs to link to FFmpeg, unless you want to use the proprietary codec pack from M$ (yuck!). So it's no use arguing about whether Moonlight itself is patent-encumbered or not. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Then don't use FFmpeg. And since Moonlight itself will not contain the MS codec pack, it can still fit in main Fedora repositories. If you don't want to do that, then find someone knowledgeable in GStreamer to write a GStreamer media backend for Moonlight. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Fri, Jun 5, 2009 at 7:48 PM, Casey Dahlincdah...@redhat.com wrote: Iain Arnell wrote: If anyone beats me too it - iwannit! You can have it. Your solution sounds better. Taken - for the sole purpose of retiring it gracefully. I've added a nopaste sub-package to perl-App-Nopaste in devel, F-11, and F-10 that should provide a seamless upgrade for existing users. It supports multiple pastebins and provides redundancy; if one site goes down, it just tries another one. -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 504270] New: [Fonts-Indic][te_IN] - GSUB shape with SSA and HA are wrong.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [Fonts-Indic][te_IN] - GSUB shape with SSA and HA are wrong. https://bugzilla.redhat.com/show_bug.cgi?id=504270 Summary: [Fonts-Indic][te_IN] - GSUB shape with SSA and HA are wrong. Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: fonts-indic AssignedTo: rbhal...@redhat.com ReportedBy: smai...@redhat.com QAContact: extras...@fedoraproject.org CC: smai...@redhat.com, rbhal...@redhat.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-b...@redhat.com Classification: Fedora Target Release: --- Description of problem: GSUB shape with SSA (0C37) and HA (0C39) is showing wrong in the font. Its positioning for the lower part of the composed character, should be below-right aligned which is now aligned as below-middle. As of now The Image that is given to our Internal web page, is hand drawn and partly wrong also. But, the lower part alignment is Perfect there which is showing right-aligned. These specific Combinations are given below : 68. U+0C24 U+0C4D U+0C37 త్ష TA + HALANT + SSA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 70. U+0C24 U+0C4D U+0C39 త్హ TA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 103. U+0C28 U+0C4D U+0C37 న్ష NA + HALANT + SSA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 105. U+0C28 U+0C4D U+0C39 న్హ NA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 140. U+0C2E U+0C4D U+0C39 మ్హ MA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 175. U+0C2F U+0C4D U+0C39 య్హ YA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 208. U+0C30 U+0C4D U+0C37 ర్ష RA + HALANT + SSA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 210. U+0C30 U+0C4D U+0C39 ర్హ RA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 243. U+0C32 U+0C4D U+0C37 ల్ష LA + HALANT + SSA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 245. U+0C32 U+0C4D U+0C39 ల్హ LA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 278. U+0C35 U+0C4D U+0C37 వ్ష VA + HALANT + SSA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. 280. U+0C35 U+0C4D U+0C39 వ్హ VA + HALANT + HA = In image main character must be corrected as in font and in font the position of sub character(which is at the bottom) should be corrected as in image. Version-Release number of selected component (if applicable): lohit-telugu-fonts-2.3.8-1.fc11 How reproducible: Always Steps to Reproduce: 1. Start system with FC11 or Latest 2. Change the ibus with RAWCODE 3. Open Gedit 4. Type the combination's Unicode as given above. 5. Observe the lower part of the composed character. Actual results: Its showing below-middle alignment. Expected results: It should be below-right alignment. 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 504272] New: [Fonts-Indic][te_IN] - Character 'HA' showing wrong shape in Composition
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [Fonts-Indic][te_IN] - Character 'HA' showing wrong shape in Composition https://bugzilla.redhat.com/show_bug.cgi?id=504272 Summary: [Fonts-Indic][te_IN] - Character 'HA' showing wrong shape in Composition Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: fonts-indic AssignedTo: rbhal...@redhat.com ReportedBy: smai...@redhat.com QAContact: extras...@fedoraproject.org CC: smai...@redhat.com, rbhal...@redhat.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-b...@redhat.com Classification: Fedora Target Release: --- Created an attachment (id=346638) -- (https://bugzilla.redhat.com/attachment.cgi?id=346638) Proper Image Shape of 0C39 - HA. Description of problem: Telugu Character 'HA' (0C39) showing wrong shape when composed with another consonant as a below-base character. One of the example is : U+0C28 U+0C4D U+0C39 (there are many like this) The nearest hand-drawn shape image is attached here for primary reference. Version-Release number of selected component (if applicable): lohit-telugu-fonts-2.3.8-1.fc11 pango-1-24.1-1.fc11 How reproducible: Always Steps to Reproduce: 1. Start system with FC11 or Latest 2. Change the ibus with RAWCODE 3. Open Gedit 4. Type the combination's Unicode as given above. 5. Observe the lower part of the composed character. Actual results: Its wrongly showing. Expected results: It should be like the image attached here! Additional info: See the attachment. -- 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/ipa-gothic-fonts/devel ipa-gothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-gothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-gothic-fonts/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2981 Modified Files: ipa-gothic-fonts-fontconfig.conf ipa-gothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-gothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/devel/ipa-gothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts-fontconfig.conf23 Apr 2009 06:52:34 - 1.1 +++ ipa-gothic-fonts-fontconfig.conf5 Jun 2009 11:03:26 - 1.2 @@ -21,5 +21,15 @@ stringIPAGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-gothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/devel/ipa-gothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts.spec 23 Apr 2009 06:52:34 - 1.1 +++ ipa-gothic-fonts.spec 5 Jun 2009 11:03:27 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-gothic-fonts/F-11 ipa-gothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-gothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-gothic-fonts/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3871 Modified Files: ipa-gothic-fonts-fontconfig.conf ipa-gothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-gothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-11/ipa-gothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts-fontconfig.conf23 Apr 2009 07:28:18 - 1.1 +++ ipa-gothic-fonts-fontconfig.conf5 Jun 2009 11:05:05 - 1.2 @@ -21,5 +21,15 @@ stringIPAGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-gothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-11/ipa-gothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts.spec 23 Apr 2009 07:28:18 - 1.1 +++ ipa-gothic-fonts.spec 5 Jun 2009 11:05:05 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-gothic-fonts/F-11 ipa-gothic-fonts.spec,1.2,1.3
Author: tagoh Update of /cvs/pkgs/rpms/ipa-gothic-fonts/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20387 Modified Files: ipa-gothic-fonts.spec Log Message: Index: ipa-gothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-11/ipa-gothic-fonts.spec,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- ipa-gothic-fonts.spec 5 Jun 2009 11:05:05 - 1.2 +++ ipa-gothic-fonts.spec 5 Jun 2009 11:51:21 - 1.3 @@ -51,6 +51,7 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-gothic-fonts/F-10 ipa-gothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-gothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-gothic-fonts/F-10 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20987 Modified Files: ipa-gothic-fonts-fontconfig.conf ipa-gothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-gothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-10/ipa-gothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts-fontconfig.conf23 Apr 2009 07:42:26 - 1.1 +++ ipa-gothic-fonts-fontconfig.conf5 Jun 2009 11:51:47 - 1.2 @@ -21,5 +21,15 @@ stringIPAGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-gothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-10/ipa-gothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts.spec 23 Apr 2009 07:42:26 - 1.1 +++ ipa-gothic-fonts.spec 5 Jun 2009 11:51:47 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -51,10 +51,14 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-gothic-fonts/F-9 ipa-gothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-gothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-gothic-fonts/F-9 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2489 Modified Files: ipa-gothic-fonts-fontconfig.conf ipa-gothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-gothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-9/ipa-gothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts-fontconfig.conf23 Apr 2009 09:42:05 - 1.1 +++ ipa-gothic-fonts-fontconfig.conf5 Jun 2009 12:01:26 - 1.2 @@ -21,5 +21,15 @@ stringIPAGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-gothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-gothic-fonts/F-9/ipa-gothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-gothic-fonts.spec 23 Apr 2009 09:42:05 - 1.1 +++ ipa-gothic-fonts.spec 5 Jun 2009 12:01:26 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -51,10 +51,14 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pgothic-fonts/F-10 ipa-pgothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-pgothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pgothic-fonts/F-10 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5441 Modified Files: ipa-pgothic-fonts-fontconfig.conf ipa-pgothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pgothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pgothic-fonts/F-10/ipa-pgothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pgothic-fonts-fontconfig.conf 23 Apr 2009 07:48:02 - 1.1 +++ ipa-pgothic-fonts-fontconfig.conf 5 Jun 2009 12:10:35 - 1.2 @@ -21,5 +21,15 @@ stringIPAPGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pgothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pgothic-fonts/F-10/ipa-pgothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pgothic-fonts.spec 23 Apr 2009 07:48:02 - 1.1 +++ ipa-pgothic-fonts.spec 5 Jun 2009 12:10:35 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -51,10 +51,14 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pgothic-fonts/F-9 ipa-pgothic-fonts-fontconfig.conf, 1.1, 1.2 ipa-pgothic-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pgothic-fonts/F-9 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5955 Modified Files: ipa-pgothic-fonts-fontconfig.conf ipa-pgothic-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pgothic-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pgothic-fonts/F-9/ipa-pgothic-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pgothic-fonts-fontconfig.conf 23 Apr 2009 09:43:24 - 1.1 +++ ipa-pgothic-fonts-fontconfig.conf 5 Jun 2009 12:12:42 - 1.2 @@ -21,5 +21,15 @@ stringIPAPGothic/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPGothic/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pgothic-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pgothic-fonts/F-9/ipa-pgothic-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pgothic-fonts.spec 23 Apr 2009 09:43:24 - 1.1 +++ ipa-pgothic-fonts.spec 5 Jun 2009 12:12:42 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Gothic-typeface OpenType font by IPA Group: User Interface/X @@ -51,10 +51,14 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/F-11 ipa-mincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-mincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8192 Modified Files: ipa-mincho-fonts-fontconfig.conf ipa-mincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-mincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-11/ipa-mincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts-fontconfig.conf23 Apr 2009 07:36:05 - 1.1 +++ ipa-mincho-fonts-fontconfig.conf5 Jun 2009 12:18:51 - 1.2 @@ -21,5 +21,15 @@ stringIPAMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-11/ipa-mincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts.spec 23 Apr 2009 07:36:05 - 1.1 +++ ipa-mincho-fonts.spec 5 Jun 2009 12:18:51 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/F-10 ipa-mincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-mincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/F-10 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8707 Modified Files: ipa-mincho-fonts-fontconfig.conf ipa-mincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-mincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-10/ipa-mincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts-fontconfig.conf23 Apr 2009 07:49:36 - 1.1 +++ ipa-mincho-fonts-fontconfig.conf5 Jun 2009 12:20:21 - 1.2 @@ -21,5 +21,15 @@ stringIPAMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-10/ipa-mincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts.spec 23 Apr 2009 07:49:36 - 1.1 +++ ipa-mincho-fonts.spec 5 Jun 2009 12:20:21 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/F-9 ipa-mincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-mincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/F-9 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9042 Modified Files: ipa-mincho-fonts-fontconfig.conf ipa-mincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-mincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-9/ipa-mincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts-fontconfig.conf23 Apr 2009 09:44:45 - 1.1 +++ ipa-mincho-fonts-fontconfig.conf5 Jun 2009 12:21:52 - 1.2 @@ -21,5 +21,15 @@ stringIPAMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-9/ipa-mincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-mincho-fonts.spec 23 Apr 2009 09:44:45 - 1.1 +++ ipa-mincho-fonts.spec 5 Jun 2009 12:21:52 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pmincho-fonts/devel ipa-pmincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-pmincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pmincho-fonts/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9878 Modified Files: ipa-pmincho-fonts-fontconfig.conf ipa-pmincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pmincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/devel/ipa-pmincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts-fontconfig.conf 23 Apr 2009 07:09:37 - 1.1 +++ ipa-pmincho-fonts-fontconfig.conf 5 Jun 2009 12:25:13 - 1.2 @@ -21,5 +21,15 @@ stringIPAPMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pmincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/devel/ipa-pmincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts.spec 23 Apr 2009 07:09:37 - 1.1 +++ ipa-pmincho-fonts.spec 5 Jun 2009 12:25:13 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pmincho-fonts/F-11 ipa-pmincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-pmincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pmincho-fonts/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv10336 Modified Files: ipa-pmincho-fonts-fontconfig.conf ipa-pmincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pmincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-11/ipa-pmincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts-fontconfig.conf 23 Apr 2009 07:38:45 - 1.1 +++ ipa-pmincho-fonts-fontconfig.conf 5 Jun 2009 12:26:56 - 1.2 @@ -21,5 +21,15 @@ stringIPAPMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pmincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-11/ipa-pmincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts.spec 23 Apr 2009 07:38:45 - 1.1 +++ ipa-pmincho-fonts.spec 5 Jun 2009 12:26:56 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pmincho-fonts/F-10 ipa-pmincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-pmincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pmincho-fonts/F-10 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv10650 Modified Files: ipa-pmincho-fonts-fontconfig.conf ipa-pmincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pmincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-10/ipa-pmincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts-fontconfig.conf 23 Apr 2009 07:56:15 - 1.1 +++ ipa-pmincho-fonts-fontconfig.conf 5 Jun 2009 12:28:17 - 1.2 @@ -21,5 +21,15 @@ stringIPAPMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pmincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-10/ipa-pmincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts.spec 23 Apr 2009 07:56:15 - 1.1 +++ ipa-pmincho-fonts.spec 5 Jun 2009 12:28:17 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pmincho-fonts/F-9 ipa-pmincho-fonts-fontconfig.conf, 1.1, 1.2 ipa-pmincho-fonts.spec, 1.1, 1.2
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pmincho-fonts/F-9 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv11076 Modified Files: ipa-pmincho-fonts-fontconfig.conf ipa-pmincho-fonts.spec Log Message: * Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 - Disable hinting. Index: ipa-pmincho-fonts-fontconfig.conf === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-9/ipa-pmincho-fonts-fontconfig.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts-fontconfig.conf 23 Apr 2009 09:46:32 - 1.1 +++ ipa-pmincho-fonts-fontconfig.conf 5 Jun 2009 12:29:48 - 1.2 @@ -21,5 +21,15 @@ stringIPAPMincho/string /edit /match + + !-- disable hinting -- + match target=font + test name=family + stringIPAPMincho/string + /test + edit name=hinting mode=assign + boolfalse/bool + /edit + /match /fontconfig Index: ipa-pmincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/F-9/ipa-pmincho-fonts.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- ipa-pmincho-fonts.spec 23 Apr 2009 09:46:32 - 1.1 +++ ipa-pmincho-fonts.spec 5 Jun 2009 12:29:48 - 1.2 @@ -6,7 +6,7 @@ Name: %{fontname}-fonts Version: 003.01 -Release: 2%{?dist} +Release: 3%{?dist} Summary: Japanese Proportional Mincho-typeface OpenType font by IPA Group: User Interface/X @@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT %changelog +* Fri Jun 5 2009 Akira TAGOH ta...@redhat.com - 003.01-3 +- Disable hinting. + * Wed Apr 22 2009 Akira TAGOH ta...@redhat.com - 003.01-2 - Correct the source URL. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/devel ipa-mincho-fonts.spec,1.2,1.3
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15591 Modified Files: ipa-mincho-fonts.spec Log Message: Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/devel/ipa-mincho-fonts.spec,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- ipa-mincho-fonts.spec 5 Jun 2009 12:17:15 - 1.2 +++ ipa-mincho-fonts.spec 5 Jun 2009 12:49:19 - 1.3 @@ -51,6 +51,7 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-pmincho-fonts/devel ipa-pmincho-fonts.spec,1.2,1.3
Author: tagoh Update of /cvs/pkgs/rpms/ipa-pmincho-fonts/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16493 Modified Files: ipa-pmincho-fonts.spec Log Message: Index: ipa-pmincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-pmincho-fonts/devel/ipa-pmincho-fonts.spec,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- ipa-pmincho-fonts.spec 5 Jun 2009 12:25:13 - 1.2 +++ ipa-pmincho-fonts.spec 5 Jun 2009 12:53:41 - 1.3 @@ -51,6 +51,7 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/F-11 ipa-mincho-fonts.spec,1.2,1.3
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16945 Modified Files: ipa-mincho-fonts.spec Log Message: Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-11/ipa-mincho-fonts.spec,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- ipa-mincho-fonts.spec 5 Jun 2009 12:18:51 - 1.2 +++ ipa-mincho-fonts.spec 5 Jun 2009 12:56:10 - 1.3 @@ -51,6 +51,7 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/ipa-mincho-fonts/F-10 ipa-mincho-fonts.spec,1.2,1.3
Author: tagoh Update of /cvs/pkgs/rpms/ipa-mincho-fonts/F-10 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18313 Modified Files: ipa-mincho-fonts.spec Log Message: Index: ipa-mincho-fonts.spec === RCS file: /cvs/pkgs/rpms/ipa-mincho-fonts/F-10/ipa-mincho-fonts.spec,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- ipa-mincho-fonts.spec 5 Jun 2009 12:20:21 - 1.2 +++ ipa-mincho-fonts.spec 5 Jun 2009 13:02:24 - 1.3 @@ -51,6 +51,7 @@ rm -rf $RPM_BUILD_ROOT %_font_pkg -f %{fontconf} *.otf + %doc Readme_%{archivename}.txt IPA_Font_License_Agreement_v1.0.txt ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 347237] Making Pango use a given cairo_font_face_t
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=347237 pango | general | Ver: unspecified --- Comment #17 from Jeffrey Stedfast 2009-06-05 20:03 UTC --- Unfortunately with Silverlight 2.0, Moonlight now has more requirements in this area :-( Firstly (and most importantly), Silverlight 2 allows you to specify a list of font families that the text renderer needs to use to find a font that will render each glyph. For example, a developer might specify in XAML: FontFamily=Georgia, Arial In this scenario, the text renderer should use Georgia to render any glyphs that are available in that font, but fallback to using Arial for anything Georgia lacks (like ♥♦♪♫ and such). Currently PangoFontDescription does handle this if it is using the FontConfig backend (from what I understand), so some logic is already there for this font fallback, but we'll need it to work for a cairo_font_face_t backend as well. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=347237. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Google releases Page Speed
Hi http://lwn.net/Articles/336376/ Google has announced the release of its Page Speed tool under the Apache license. Page Speed is a tool we've been using internally to improve the performance of our web pages Rahul ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Google releases Page Speed
On Fri, 5 Jun 2009, Rahul Sundaram wrote: Hi http://lwn.net/Articles/336376/ Google has announced the release of its Page Speed tool under the Apache license. Page Speed is a tool we've been using internally to improve the performance of our web pages I'm a might busy with things at the moment, anyone on the list want to use this tool on our websites and do a review? (Of both the tool and our sites?) -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Google releases Page Speed
On Fri, Jun 5, 2009 at 12:39 PM, Mike McGrathmmcgr...@redhat.com wrote: I'm a might busy with things at the moment, anyone on the list want to use this tool on our websites and do a review? (Of both the tool and our sites?) The tool is pretty cool, but I'm not much of a web developer. So far, I've ran it against http://fedoraproject.org, and it came up with some seemingly good suggestions. These are the only two it classified as big wins, the other stuff is minor (some inefficient CSS as item 3, for example) 1) We're not gzipping content going to the browser. On the main page: Compressing the following resources with gzip could reduce their transfer size by about two thirds (~11.8kB). * Compressing http://fedoraproject.org/static/css/fedora.css could save ~7.2kB. * Compressing http://fedoraproject.org could save ~3.5kB. * Compressing /en/static/js/release-counter.js could save ~1.1kB. 2) Caching parameters for browsers are not optimal (some of these suggestions we obviously can't follow, but we can others): The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached: * /en/static/js/release-counter.js * http://fedoraproject.org/static/css/fedora.css * http://fedoraproject.org/static/css/print.css The following cacheable resources have a short freshness lifetime. Specify an expiration at least one month in the future for the following resources: * http://fedoraproject.org/static/images/arrow.png * /static/images/border-left.png * /static/images/border-right.png * fedora11-countdown-banner-4.en.png * /static/images/f10launch.png * /static/images/fedora-logo.png * /static/images/line-bottom.png * http://fedoraproject.org/static/images/line.png Favicons should have an expiration at least one month in the future: * http://fedoraproject.org/static/images/favicon.ico 3) The inefficient CSS warning I was talking about earlier: http://fedoraproject.org/static/css/fedora.css has 6 very inefficient and 24 inefficient rules of 116 total rules. Very inefficient rules (good to fix on any page): * #content .roles a:hoverTag key with 2 descendant selectors and hover pseudo selector * #content p.warning aTag key with 2 descendant selectors and Class overly qualified with tag * #content ul#resources aTag key with 2 descendant selectors and ID overly qualified with tag * #content ul#resources liTag key with 2 descendant selectors and ID overly qualified with tag * .toolbar *Universal key with descendant selector * #content div.login *Universal key with 2 descendant selectors and Class overly qualified with tag Inefficient rules (good to fix on interactive pages): * #head h1 aTag key with 2 descendant selectors * .home #nav-home aTag key with 2 descendant selectors * .get #nav-get aTag key with 2 descendant selectors * .join #nav-join aTag key with 2 descendant selectors * .help #nav-help aTag key with 2 descendant selectors * #content table thTag key with 2 descendant selectors * #content table thTag key with 2 descendant selectors * #content table tdTag key with 2 descendant selectors * #content .download liTag key with 2 descendant selectors * #content .download aTag key with 2 descendant selectors * #content .roles liTag key with 2 descendant selectors * #content .roles aTag key with 2 descendant selectors * #footer a:hoverTag key with descendant selector and hover pseudo selector * #content #sponsors liTag key with 2 descendant selectors * #content #sponsors li imgTag key with 3 descendant selectors * .downloadbox li liTag key with 2 descendant selectors * .download-block p imgTag key with 2 descendant selectors * .download-sidebar a:hoverTag key with descendant selector and hover pseudo selector * #content .panel h3Tag key with 2 descendant selectors * #login-box .field labelTag key with 2 descendant selectors * #content .login h3Tag key with 2 descendant selectors * #content .login inputTag key with 2 descendant selectors * #content .login labelTag key with 2 descendant selectors * #content .login ulTag key with 2 descendant selectors ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[PATCH] Updated new staging hosts in ssh_known_keys
Can I get 2 +1's --- modules/ssh/files/ssh_known_hosts |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/modules/ssh/files/ssh_known_hosts b/modules/ssh/files/ssh_known_hosts index d99fbc8..5ab5a25 100644 --- a/modules/ssh/files/ssh_known_hosts +++ b/modules/ssh/files/ssh_known_hosts @@ -5,7 +5,8 @@ app4,10.8.34.48 ssh-rsa B3NzaC1yc2EBIwAAAQEA0cbc0AhUL0vAhKZz7QrPNeJ/o8y1 app5,192.168.1.13 ssh-rsa B3NzaC1yc2EBIwAAAQEAywNK0LXCaimjLd094G72QVFGGrNA6IdUtVaO5RGXMt0eQeK3o59jaSdgIwz1aDw7jbvP8Iu28kQj9du/RkGh9RGOY2kn2wwHru3D58pyXK23KdWyZwlvkSwz8vEBySzSghXbh4Jiglzr6wdSzkLNwio6xD8GqnJX9iO+dyWjQ3E/v1RQo42kX62GcaUob3jFi49Yhoxu064oupuq5PL5qZvfDH6QMWhW7rxQj+a7by5YgBU6UAGwND46arxhag7x3t+9PghKTx725dr+hw8XhGoW3MrKnElh6Pj97B0qPOVcXAoveZUeaPTmvBeusR97Uoulpc5Q0Ctovj99xVvEtQ== app6,192.168.1.24 ssh-rsa B3NzaC1yc2EBIwAAAQEAzfWOx94ZhtetSGGE543cyMvdnP6jLtAgma3HbSZdX3/NaGN6lvIdbPwiaR78FH3XTiZHnzujgGZJ+wybfaYHsxkNOHiEhgYGdlLYzGVppQHLzUDoGE9fYCj3EVB1Y5JXfgaFCVMFEWe7uTVHWsSgB9iUzkuLWjfTL7+J/BNyCfWPv50Gnh6YELwjHuTtRX8Wl+Gbj4AAt/J0aWqAgima940+9oEPxnk5QzXOkVym0EXeNoBNTEEU/SlvNEy/u85wE+/xfsa6WgqtZI/KlM4LXveRkZcH5Zwn0aK7W7j9uzs1KTHxnjfb3pA4FcfHW1zxtliaM4EHvKyNpFzViASWQQ== bapp1,10.8.34.124 ssh-rsa B3NzaC1yc2EBIwAAAQEAvuD479APThoqX12HxbXfN80C4J3aN7+2X/oVF+un5tIG21DwRfPuJu/9uJKJM72X9zGAI9/DGVLyRPtzQOoBWA75N2NQjR2RKTJc2Jcl4/HVr98UN9bAVqgGU50OpONsgbncP4yadRLEkeLFYA6Bn5p/PhIrJ1TSYT0Vr9RcLy0GINqor3aMAICRYlRUrsWeCBnue7XRAsvWg5O7DX3bVf9Rwu4HQpIpvDzzXDvX33DWJUbN7Q8Lgb+1cyUsYh37eMeo79evj4VeMpOykDML4TGcmjkbF4hkt5kJJwrQSjaqVMtWeB6bDDX5zbYhuuCwCoYGA6WeDJJpv8M1d79I0Q== -app1.stg,10.8.34.113 ssh-rsa B3NzaC1yc2EBIwAAAQEAxYavmpopcIbcLS8m3hcqLt9UBsmHH5M9kJ6/j+dzJ2VlSN+204xfafIBo1iHspppK8ctkN1899V7JyCnIqOYDWQd5Q98Xbum8fn5oaRjHL+AlbAFAh8zH1nxr0hgDRVZCahqIFJeWospzXaEbmCBG52VZJkp3vlA5endOUjFML/YkJpoXfjND3+rL4ZweaeW202OH7tixQV8uGGQTlbzvAt2zpeO3D0ATKES9efMCH+DUOKk7Tvrpr2oqiiqkPMZBzOyhsfhLXKcxrnKluj1v1/ZtqOeyP8QK1lvZ9MohLRor/y3v9D3ci0ifwPVCK2egL2hz2/PDtdQ5tvbAblVLw== +app1.stg,10.8.34.113 ssh-rsa B3NzaC1yc2EBIwAAAQEA3q1llw6x3Iuoym0SHEZnMYG87/g+zF49rnxPwnd7En1Kcu0aIACw8DxmgDpToiOYPwPNDGWyPEsnyGNVC5slxGnlmsLQP3BZ8ZCgAhQNLg5+QyGNjgzDRHLaUH8e+g9Av4oz17Sudw/kfv+ZcU/YRw8nfkQBZMtoORZF6x+D1fuME/HtcVFkS/GQNjUsea/iU30gypFO2b0r6VR/A4xQ6Nbvr11zsx+5R0/lWNbk1ODAVyBTXFbk2VxF3g/MYV7S+9R2ggoWZsNWsvgCam0/dGruMG1vIGiql8XIfIX1IeBizVDZJOY4lWVM0HpndZypSPQwt1ZW9YNtek+EYTLv8Q== +app2.stg,10.8.34.114 ssh-rsa B3NzaC1yc2EBIwAAAQEAol7fqrP+11Wb142bCLZ2YWfW3JQTCKeJSTwvN06V+KjMTb4abi9t7JnVCcJKUrEt94rVIE/fNfbUMxTpSNX0wuE38aFavfMuYUZ2Fvp47UOESVNZLSC3VvpoCQmQA1+7HmuPwwvRsFFrtjGnQdF/h04Gu7E7ucdMnxVuVRIdEOuCkUU8cDpYmyIa7dbrYh2XZHw+Ry6rIt+szZcQqxJ0b/cOHPkQDgX7JaGGXRX0M3qI+/MYGdtrJVDE29G9Cu/sIP0mHfgY+bwKbomg8Dr+MNc2rpDnvsxjVnTVPle8IxnDRGAZQl9FxbiEwtw8iYwpeTct06ZHTuBMhncJqcanrQ== asterisk1,192.168.1.34 ssh-rsa B3NzaC1yc2EBIwAAAQEA9K8imSdywSbQv9twrVRUA9zVtUeDQAa6sTXK+y0zz3Ct7L+6YtyonprgXA42JcRdg5WiKsmcTDC9T2GSc4GvyKqXvmaZN5V7Ry608vHDWyv639Y8r9IjMbSIEGbSu3Q8WpbxYYgqQ5PE8pWRi7Qu3/hTNU49y+sQ5qPHjZ7Y/0QHMnQDkn1xWdaUdq8ahkkDAECIUU15Cmj7ClRO01V+T+sP0VitsCaa3T2RfDsmxEtnCr9e0dG9jovalfO1aEvzpstClOzYoxLvr32hxm1qHMr5wxmSUc1ymLL6Llil1oTJ8WyCimGlZFMSU0HkRohbzPGdV3YfOp+AKj6CEI67IQ== asterisk2,192.168.1.36 ssh-rsa B3NzaC1yc2EBIwAAAQEA2+kJvYuTDFEkKVAiohgA0G1m5InxoVdqaHqkl9NWQIDsebLEe0wvfGEs83APEEqUNOL+TarC9B5vR0XowhGiekuHkSXYD0U/T+GGLOk9PCqsWEYCkeNPED38cGpEkO5tmM5rNy4Ol0CMQ7t7lFJCTZtgKc/C5IBPiuouDw4Sfxag3Yj2P8IPRQ49zY73p/NqyTvc3mgfxnJB7gqzh91bsE7DINuhD82dryYVrXrqlT1DVR++B7HdiWX44kAQE0l6BD4VcszfBJ5Mg+dGP/z7swiIbRTgQ4ZiOefyiHwC6iLoEs17Hq35CJOUpZLYo26wDrp9UBIlti78ZrtZVbeCVw== backup1,10.8.34.219 ssh-rsa B3NzaC1yc2EBIwAAAQEAwYSCsVH8hFlBsGDYw1FzsQEA98EwU25gJMhzyNir8QkWTPzoaZ5ncD0PY1jRAWc4ye8fCzzgsre8knwqyDrCEz3LLJkSEspELsuBNT7F5c4XsON5uS57W7Nufr5pf18ePXUbztLVdHhzx5xIuRXpW3UrI8qcxTeYnfsh4LMaofCDer60KvFQ/9oUHAV//pIiUc8hKKSnkjjdha12mBrTuTXfg5sslLReugcyv3zYQNrQmG/B1hwI1gMcf3gHUccJ+Cm648pErnSh26Tl1rzis5p/ipSehM68eIsfRdz2vMwEY4jeA++yJ+JiqpPgzrd1IoGo1oAH61fPUVz+lLYahw== @@ -46,7 +47,7 @@ ppc7,10.8.34.230 ssh-rsa B3NzaC1yc2EBIwAAAQEA0CLk4k56ZKw+bDUd7cmSbrG5aes ppc8,10.8.34.231 ssh-rsa B3NzaC1yc2EBIwAAAQEAqPy1UptflYSQQB7lrFlp5YY+KY1jJTLmNEB5mMI0lfqlrtIpOLdh45VcAZCWtUNG1DifDsO66Zdv10syo/8X98nP0MLd2yLnpZdA9I4GflSO/CAqRGNNqRI7pXQr7J/JpiMBJV16qF6WCn2QXsDj+nX7nrVVCKqyontkksrypdqqS2S9c9kTCDihyZ6gBM0oyTFx1ByqPlMzleMcsGX2xaoEcjmrQXIEjrLLuB7zU+e5mhq0io0JtZXTfdb5pWu/hGHwvIt7qUOjl+y5DeUdRQ1/kceIbnZHP9Fz59g/BOS8kSlZj1Fpy6Ybc+6R+hwfCWiMnHjz6FkYRtxPa0ARFw== ppc9,10.8.34.232 ssh-rsa B3NzaC1yc2EBIwAAAQEAx3efirQRHCKYgZSEbxti7NekcalP5gECICqx/bBYsLm8zgF7n5mzd/vrGBz/XKffAo48nPRQM06tB4begynFwuussDVw+wtMO7mAO0DPcHcD2qrDXg0qJt9voHI1JO2aUue5qo8N2KSCP/geVsTH5qjsRDu+ZYkmYt+0/G/Rz3Usvn90+WkyI++s68enSEl9bVw5G9wydweUXhPuJMIaD+z/+LDfUSv8CyZJWebDCd+BJY0p5yavULtA2ptcDR852roHy+84K2PBYmnTSdypNmUE5zLd6Kll7zdLwLhnJqfgHGd9eNQVfBuguYNZqWvdbmNgymP06P1vKJBDXRrRQw== proxy1,10.8.32.55 ssh-rsa
Change Request backup1
We've got a tech on site that needs to take backup1 down to install an SAS adapter and new tape drive. You may remember this was requested before, we didn't have the right cable / card on site so the request was approved but the change wasn't made. 2+1's? -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Updated new staging hosts in ssh_known_keys
On 2009-06-05 05:42:41 PM, Mike McGrath wrote: Can I get 2 +1's --- modules/ssh/files/ssh_known_hosts |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/modules/ssh/files/ssh_known_hosts b/modules/ssh/files/ssh_known_hosts index d99fbc8..5ab5a25 100644 --- a/modules/ssh/files/ssh_known_hosts +++ b/modules/ssh/files/ssh_known_hosts +1 Thanks, Ricky pgpg63dbKbqNj.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Updated new staging hosts in ssh_known_keys
On Friday 05 June 2009 12:42:41 pm Mike McGrath wrote: Can I get 2 +1's --- modules/ssh/files/ssh_known_hosts |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/modules/ssh/files/ssh_known_hosts b/modules/ssh/files/ssh_known_hosts index d99fbc8..5ab5a25 100644 --- a/modules/ssh/files/ssh_known_hosts +++ b/modules/ssh/files/ssh_known_hosts @@ -5,7 +5,8 @@ app4,10.8.34.48 ssh-rsa B3NzaC1yc2EBIwAAAQEA0cbc0AhUL0vAhKZz7QrPNeJ/o8y1 app5,192.168.1.13 ssh-rsa B3NzaC1yc2EBIwAAAQEAywNK0LXCaimjLd094G72QVFGGrNA6IdUtVaO5RGXMt0eQeK 3o59jaSdgIwz1aDw7jbvP8Iu28kQj9du/RkGh9RGOY2kn2wwHru3D58pyXK23KdWyZwlvkSwz8vE BySzSghXbh4Jiglzr6wdSzkLNwio6xD8GqnJX9iO+dyWjQ3E/v1RQo42kX62GcaUob3jFi49Yhox u064oupuq5PL5qZvfDH6QMWhW7rxQj+a7by5YgBU6UAGwND46arxhag7x3t+9PghKTx725dr+hw8 XhGoW3MrKnElh6Pj97B0qPOVcXAoveZUeaPTmvBeusR97Uoulpc5Q0Ctovj99xVvEtQ== app6,192.168.1.24 ssh-rsa B3NzaC1yc2EBIwAAAQEAzfWOx94ZhtetSGGE543cyMvdnP6jLtAgma3HbSZdX3/NaGN 6lvIdbPwiaR78FH3XTiZHnzujgGZJ+wybfaYHsxkNOHiEhgYGdlLYzGVppQHLzUDoGE9fYCj3EVB 1Y5JXfgaFCVMFEWe7uTVHWsSgB9iUzkuLWjfTL7+J/BNyCfWPv50Gnh6YELwjHuTtRX8Wl+Gbj4A At/J0aWqAgima940+9oEPxnk5QzXOkVym0EXeNoBNTEEU/SlvNEy/u85wE+/xfsa6WgqtZI/KlM4 LXveRkZcH5Zwn0aK7W7j9uzs1KTHxnjfb3pA4FcfHW1zxtliaM4EHvKyNpFzViASWQQ== bapp1,10.8.34.124 ssh-rsa B3NzaC1yc2EBIwAAAQEAvuD479APThoqX12HxbXfN80C4J3aN7+2X/oVF+un5tIG21D wRfPuJu/9uJKJM72X9zGAI9/DGVLyRPtzQOoBWA75N2NQjR2RKTJc2Jcl4/HVr98UN9bAVqgGU50 OpONsgbncP4yadRLEkeLFYA6Bn5p/PhIrJ1TSYT0Vr9RcLy0GINqor3aMAICRYlRUrsWeCBnue7X RAsvWg5O7DX3bVf9Rwu4HQpIpvDzzXDvX33DWJUbN7Q8Lgb+1cyUsYh37eMeo79evj4VeMpOykDM L4TGcmjkbF4hkt5kJJwrQSjaqVMtWeB6bDDX5zbYhuuCwCoYGA6WeDJJpv8M1d79I0Q== -app1.stg,10.8.34.113 ssh-rsa B3NzaC1yc2EBIwAAAQEAxYavmpopcIbcLS8m3hcqLt9UBsmHH5M9kJ6/j+dzJ2VlSN+ 204xfafIBo1iHspppK8ctkN1899V7JyCnIqOYDWQd5Q98Xbum8fn5oaRjHL+AlbAFAh8zH1nxr0h gDRVZCahqIFJeWospzXaEbmCBG52VZJkp3vlA5endOUjFML/YkJpoXfjND3+rL4ZweaeW202OH7t ixQV8uGGQTlbzvAt2zpeO3D0ATKES9efMCH+DUOKk7Tvrpr2oqiiqkPMZBzOyhsfhLXKcxrnKluj 1v1/ZtqOeyP8QK1lvZ9MohLRor/y3v9D3ci0ifwPVCK2egL2hz2/PDtdQ5tvbAblVLw== +app1.stg,10.8.34.113 ssh-rsa B3NzaC1yc2EBIwAAAQEA3q1llw6x3Iuoym0SHEZnMYG87/g+zF49rnxPwnd7En1Kcu0 aIACw8DxmgDpToiOYPwPNDGWyPEsnyGNVC5slxGnlmsLQP3BZ8ZCgAhQNLg5+QyGNjgzDRHLaUH8 e+g9Av4oz17Sudw/kfv+ZcU/YRw8nfkQBZMtoORZF6x+D1fuME/HtcVFkS/GQNjUsea/iU30gypF O2b0r6VR/A4xQ6Nbvr11zsx+5R0/lWNbk1ODAVyBTXFbk2VxF3g/MYV7S+9R2ggoWZsNWsvgCam0 /dGruMG1vIGiql8XIfIX1IeBizVDZJOY4lWVM0HpndZypSPQwt1ZW9YNtek+EYTLv8Q== +app2.stg,10.8.34.114 ssh-rsa B3NzaC1yc2EBIwAAAQEAol7fqrP+11Wb142bCLZ2YWfW3JQTCKeJSTwvN06V+KjMTb4 abi9t7JnVCcJKUrEt94rVIE/fNfbUMxTpSNX0wuE38aFavfMuYUZ2Fvp47UOESVNZLSC3VvpoCQm QA1+7HmuPwwvRsFFrtjGnQdF/h04Gu7E7ucdMnxVuVRIdEOuCkUU8cDpYmyIa7dbrYh2XZHw+Ry6 rIt+szZcQqxJ0b/cOHPkQDgX7JaGGXRX0M3qI+/MYGdtrJVDE29G9Cu/sIP0mHfgY+bwKbomg8Dr +MNc2rpDnvsxjVnTVPle8IxnDRGAZQl9FxbiEwtw8iYwpeTct06ZHTuBMhncJqcanrQ== asterisk1,192.168.1.34 ssh-rsa B3NzaC1yc2EBIwAAAQEA9K8imSdywSbQv9twrVRUA9zVtUeDQAa6sTXK+y0zz3Ct7L+ 6YtyonprgXA42JcRdg5WiKsmcTDC9T2GSc4GvyKqXvmaZN5V7Ry608vHDWyv639Y8r9IjMbSIEGb Su3Q8WpbxYYgqQ5PE8pWRi7Qu3/hTNU49y+sQ5qPHjZ7Y/0QHMnQDkn1xWdaUdq8ahkkDAECIUU1 5Cmj7ClRO01V+T+sP0VitsCaa3T2RfDsmxEtnCr9e0dG9jovalfO1aEvzpstClOzYoxLvr32hxm1 qHMr5wxmSUc1ymLL6Llil1oTJ8WyCimGlZFMSU0HkRohbzPGdV3YfOp+AKj6CEI67IQ== asterisk2,192.168.1.36 ssh-rsa B3NzaC1yc2EBIwAAAQEA2+kJvYuTDFEkKVAiohgA0G1m5InxoVdqaHqkl9NWQIDsebL Ee0wvfGEs83APEEqUNOL+TarC9B5vR0XowhGiekuHkSXYD0U/T+GGLOk9PCqsWEYCkeNPED38cGp EkO5tmM5rNy4Ol0CMQ7t7lFJCTZtgKc/C5IBPiuouDw4Sfxag3Yj2P8IPRQ49zY73p/NqyTvc3mg fxnJB7gqzh91bsE7DINuhD82dryYVrXrqlT1DVR++B7HdiWX44kAQE0l6BD4VcszfBJ5Mg+dGP/z 7swiIbRTgQ4ZiOefyiHwC6iLoEs17Hq35CJOUpZLYo26wDrp9UBIlti78ZrtZVbeCVw== backup1,10.8.34.219 ssh-rsa B3NzaC1yc2EBIwAAAQEAwYSCsVH8hFlBsGDYw1FzsQEA98EwU25gJMhzyNir8QkWTPz oaZ5ncD0PY1jRAWc4ye8fCzzgsre8knwqyDrCEz3LLJkSEspELsuBNT7F5c4XsON5uS57W7Nufr5 pf18ePXUbztLVdHhzx5xIuRXpW3UrI8qcxTeYnfsh4LMaofCDer60KvFQ/9oUHAV//pIiUc8hKKS nkjjdha12mBrTuTXfg5sslLReugcyv3zYQNrQmG/B1hwI1gMcf3gHUccJ+Cm648pErnSh26Tl1rz is5p/ipSehM68eIsfRdz2vMwEY4jeA++yJ+JiqpPgzrd1IoGo1oAH61fPUVz+lLYahw== @@ -46,7 +47,7 @@ ppc7,10.8.34.230 ssh-rsa B3NzaC1yc2EBIwAAAQEA0CLk4k56ZKw+bDUd7cmSbrG5aes ppc8,10.8.34.231 ssh-rsa B3NzaC1yc2EBIwAAAQEAqPy1UptflYSQQB7lrFlp5YY+KY1jJTLmNEB5mMI0lfqlrtI pOLdh45VcAZCWtUNG1DifDsO66Zdv10syo/8X98nP0MLd2yLnpZdA9I4GflSO/CAqRGNNqRI7pXQ r7J/JpiMBJV16qF6WCn2QXsDj+nX7nrVVCKqyontkksrypdqqS2S9c9kTCDihyZ6gBM0oyTFx1By qPlMzleMcsGX2xaoEcjmrQXIEjrLLuB7zU+e5mhq0io0JtZXTfdb5pWu/hGHwvIt7qUOjl+y5DeU dRQ1/kceIbnZHP9Fz59g/BOS8kSlZj1Fpy6Ybc+6R+hwfCWiMnHjz6FkYRtxPa0ARFw== ppc9,10.8.34.232 ssh-rsa B3NzaC1yc2EBIwAAAQEAx3efirQRHCKYgZSEbxti7NekcalP5gECICqx/bBYsLm8zgF 7n5mzd/vrGBz/XKffAo48nPRQM06tB4begynFwuussDVw+wtMO7mAO0DPcHcD2qrDXg0qJt9voHI 1JO2aUue5qo8N2KSCP/geVsTH5qjsRDu+ZYkmYt+0/G/Rz3Usvn90+WkyI++s68enSEl9bVw5G9w ydweUXhPuJMIaD+z/+LDfUSv8CyZJWebDCd+BJY0p5yavULtA2ptcDR852roHy+84K2PBYmnTSdy
Re: Change Request backup1
On 2009-06-05 12:44:27 PM, Mike McGrath wrote: We've got a tech on site that needs to take backup1 down to install an SAS adapter and new tape drive. You may remember this was requested before, we didn't have the right cable / card on site so the request was approved but the change wasn't made. +1 Thanks, Ricky pgp1mXyiuqgtJ.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list