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 504256] New: Please build latest perl-Math-BigInt-GMP for EPEL 4 and 5
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Please build latest perl-Math-BigInt-GMP for EPEL 4 and 5
https://bugzilla.redhat.com/show_bug.cgi?id=504256
Summary: Please build latest perl-Math-BigInt-GMP for EPEL 4
and 5
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: perl-Math-BigInt-GMP
AssignedTo: st...@silug.org
ReportedBy: redhat-bugzi...@linuxnetz.de
QAContact: extras...@fedoraproject.org
CC: st...@silug.org, fedora-perl-devel-list@redhat.com,
sch...@etes.de
Classification: Fedora
Description of problem:
Please build latest perl-Math-BigInt-GMP for EPEL 4 and 5. As the %check
section doesn't work on EPEL 4 and 5, I'm suggesting the following block
to use instead:
%if 0%{?fedora}%{?rhel} 5
%check
make test
%endif
And the %{fixperm} thing maybe doesn't exist on EPEL 4 as well, there could
be chmod -R u+w $RPM_BUILD_ROOT/* get necessary.
Version-Release number of selected component (if applicable):
perl-Math-BigInt-GMP-1.24-1
Additional info:
Please let me know, if you just don't want to be the maintainer for the
perl-Math-BigInt-GMP EPEL packages...
--
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 Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 504256] Please build latest perl-Math-BigInt-GMP for EPEL 4 and 5
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=504256
Paul Howarth p...@city-fan.org changed:
What|Removed |Added
CC||p...@city-fan.org
--- Comment #1 from Paul Howarth p...@city-fan.org 2009-06-05 04:37:00 EDT
---
Math::BigInt::GMP requires Math::BigInt = 1.87, which is not available in
either EL-4 or EL-5. Since it's also a core module bundled with the main perl
package, there's not much chance of that changing either.
I suspect that's why the test suite fails too.
%{_fixperms} works all the way back to Red Hat Linux 7 and maybe further (I
don't have anything older to hand at the moment).
--
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 Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-HTML-CalendarMonthSimple/EL-5 perl-HTML-CalendarMonthSimple.spec, 1.2, 1.3
Author: xavierb
Update of /cvs/pkgs/rpms/perl-HTML-CalendarMonthSimple/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5916
Modified Files:
perl-HTML-CalendarMonthSimple.spec
Log Message:
merge my spec with ixs'
Index: perl-HTML-CalendarMonthSimple.spec
===
RCS file:
/cvs/pkgs/rpms/perl-HTML-CalendarMonthSimple/EL-5/perl-HTML-CalendarMonthSimple.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-HTML-CalendarMonthSimple.spec 16 May 2007 11:19:01 - 1.2
+++ perl-HTML-CalendarMonthSimple.spec 5 Jun 2009 08:39:25 - 1.3
@@ -1,8 +1,8 @@
Name: perl-HTML-CalendarMonthSimple
Version:1.25
-Release:2%{?dist}
+Release:5%{?dist}
Summary:Perl Module for Generating HTML Calendars
-License:Public Domain
+License:Copyright only
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTML-CalendarMonthSimple/
Source0:
http://www.cpan.org/modules/by-module/HTML/HTML-CalendarMonthSimple-%{version}.tar.gz
@@ -12,7 +12,6 @@ BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(Date::Calc)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: /usr/bin/iconv
%description
HTML::CalendarMonthSimple is a Perl module for generating, manipulating,
@@ -23,9 +22,12 @@ a faster and easier-to-use alternative t
%setup -q -n HTML-CalendarMonthSimple-%{version}
%patch0 -p 1 -b .thisday
-# Fix UTF-8
-iconv -f ISO_8859-1 -t UTF-8 -o tmp.pm CalendarMonthSimple.pm
-mv -f tmp.pm CalendarMonthSimple.pm
+# Fix encoding :
+for i in README CalendarMonthSimple.pm ; do {
+iconv -f iso8859-1 -t utf-8 $i $i.utf8 \
+touch -r $i $i.utf8 \
+mv -f $i.utf8 $i; };
+done;
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -54,6 +56,18 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Wed Jun 03 2009 Xavier Bachelot xav...@bachelot.org 1.25-5
+- Change License: to Copyright only.
+- Fix README file encoding.
+- Preserve timestamp on converted files.
+- Remove implicit BR: iconv.
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.25-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.25-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
* Wed May 16 2007 Andreas Thienemann andr...@bawue.net 1.25-2
- Fixed typo in BR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 504256] Please build latest perl-Math-BigInt-GMP for EPEL 4 and 5
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=504256
--- Comment #2 from Robert Scheck redhat-bugzi...@linuxnetz.de 2009-06-05
05:43:16 EDT ---
Even it requires Math::BigInt = 1.87 for some of the functionalities, it
works for most of them with older Math::BigInt and gets down the 10 seconds
from Net::SSH::Perl when using without Math::BigInt::GMP to ~ 1.5 seconds.
So there's definately an improvement and a reason to have that package at
EPEL. Regarding %{_fixperms}, that's possible, I didn't investigate into this.
--
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 Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Component-Log4perl/devel import.log, NONE, 1.1 perl-POE-Component-Log4perl.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Component-Log4perl/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12885/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Component-Log4perl.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Component-Log4perl-0_02-3_fc11:HEAD:perl-POE-Component-Log4perl-0.02-3.fc11.src.rpm:1244133305
--- NEW FILE perl-POE-Component-Log4perl.spec ---
Name: perl-POE-Component-Log4perl
Version:0.02
Release:3%{?dist}
Summary:Logging extension for the POE environment
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/POE-Component-Log4perl/
Source0:
http://search.cpan.org/CPAN/authors/id/K/KE/KESTEB/POE-Component-Log4perl-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(POE), perl(Log::Log4perl)
BuildRequires: perl(Test::More), perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
Log4perl encapsulation within the POE environment.
%prep
%setup -q -n POE-Component-Log4perl-%{version}
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
%{_fixperms} %{buildroot}/*
%check
TEST_POD=1 make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/POE/Component/*
%{_mandir}/man3/*.3*
%changelog
* Sat May 30 2009 Yanko Kaneti yan...@declera.com - 0.02-3
- Implement review feedback from Mamoru Tasaka
https://bugzilla.redhat.com/show_bug.cgi?id=495888#c2
- Do not own %%{perl_vendorlib}/POE + Component
* Sun Apr 19 2009 Yanko Kaneti yan...@declera.com - 0.02-2
- remove trailing dot from summary
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.02-1
- First attempt. Based on perl-POE-Component-Logger
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:42:08 - 1.1
+++ .cvsignore 4 Jun 2009 16:34:29 - 1.2
@@ -0,0 +1 @@
+POE-Component-Log4perl-0.02.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:42:08 - 1.1
+++ sources 4 Jun 2009 16:34:29 - 1.2
@@ -0,0 +1 @@
+b924a49f1ca803b7f7894cbef445c56e POE-Component-Log4perl-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Component-Log4perl/F-11 import.log, NONE, 1.1 perl-POE-Component-Log4perl.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13683/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Component-Log4perl.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Component-Log4perl-0_02-3_fc11:F-11:perl-POE-Component-Log4perl-0.02-3.fc11.src.rpm:1244133415
--- NEW FILE perl-POE-Component-Log4perl.spec ---
Name: perl-POE-Component-Log4perl
Version:0.02
Release:3%{?dist}
Summary:Logging extension for the POE environment
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/POE-Component-Log4perl/
Source0:
http://search.cpan.org/CPAN/authors/id/K/KE/KESTEB/POE-Component-Log4perl-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(POE), perl(Log::Log4perl)
BuildRequires: perl(Test::More), perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
Log4perl encapsulation within the POE environment.
%prep
%setup -q -n POE-Component-Log4perl-%{version}
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
%{_fixperms} %{buildroot}/*
%check
TEST_POD=1 make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/POE/Component/*
%{_mandir}/man3/*.3*
%changelog
* Sat May 30 2009 Yanko Kaneti yan...@declera.com - 0.02-3
- Implement review feedback from Mamoru Tasaka
https://bugzilla.redhat.com/show_bug.cgi?id=495888#c2
- Do not own %%{perl_vendorlib}/POE + Component
* Sun Apr 19 2009 Yanko Kaneti yan...@declera.com - 0.02-2
- remove trailing dot from summary
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.02-1
- First attempt. Based on perl-POE-Component-Logger
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:42:08 - 1.1
+++ .cvsignore 4 Jun 2009 16:37:23 - 1.2
@@ -0,0 +1 @@
+POE-Component-Log4perl-0.02.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:42:08 - 1.1
+++ sources 4 Jun 2009 16:37:23 - 1.2
@@ -0,0 +1 @@
+b924a49f1ca803b7f7894cbef445c56e POE-Component-Log4perl-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Component-Log4perl/F-10 import.log, NONE, 1.1 perl-POE-Component-Log4perl.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14322/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Component-Log4perl.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Component-Log4perl-0_02-3_fc11:F-10:perl-POE-Component-Log4perl-0.02-3.fc11.src.rpm:1244133582
--- NEW FILE perl-POE-Component-Log4perl.spec ---
Name: perl-POE-Component-Log4perl
Version:0.02
Release:3%{?dist}
Summary:Logging extension for the POE environment
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/POE-Component-Log4perl/
Source0:
http://search.cpan.org/CPAN/authors/id/K/KE/KESTEB/POE-Component-Log4perl-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(POE), perl(Log::Log4perl)
BuildRequires: perl(Test::More), perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
Log4perl encapsulation within the POE environment.
%prep
%setup -q -n POE-Component-Log4perl-%{version}
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
%{_fixperms} %{buildroot}/*
%check
TEST_POD=1 make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/POE/Component/*
%{_mandir}/man3/*.3*
%changelog
* Sat May 30 2009 Yanko Kaneti yan...@declera.com - 0.02-3
- Implement review feedback from Mamoru Tasaka
https://bugzilla.redhat.com/show_bug.cgi?id=495888#c2
- Do not own %%{perl_vendorlib}/POE + Component
* Sun Apr 19 2009 Yanko Kaneti yan...@declera.com - 0.02-2
- remove trailing dot from summary
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.02-1
- First attempt. Based on perl-POE-Component-Logger
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:42:08 - 1.1
+++ .cvsignore 4 Jun 2009 16:39:06 - 1.2
@@ -0,0 +1 @@
+POE-Component-Log4perl-0.02.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Component-Log4perl/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:42:08 - 1.1
+++ sources 4 Jun 2009 16:39:06 - 1.2
@@ -0,0 +1 @@
+b924a49f1ca803b7f7894cbef445c56e POE-Component-Log4perl-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Filter-Transparent-SMTP/F-10 import.log, NONE, 1.1 perl-POE-Filter-Transparent-SMTP.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16500/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Filter-Transparent-SMTP.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Filter-Transparent-SMTP-0_2-3_fc11:F-10:perl-POE-Filter-Transparent-SMTP-0.2-3.fc11.src.rpm:1244134369
--- NEW FILE perl-POE-Filter-Transparent-SMTP.spec ---
Name: perl-POE-Filter-Transparent-SMTP
Version:0.2
Release:3%{?dist}
Summary:A POE filter for SMTP
# note license definition in Makefile.PL
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/POE-Filter-Transparent-SMTP/
Source0:
http://search.cpan.org/CPAN/authors/id/U/UL/ULTRADM/POE-Filter-Transparent-SMTP-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(POE)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
POE data filter which aims to make SMTP data transparent
just before going onto the wire as per RFC 821 Section 4.5.2.
%prep
%setup -q -n POE-Filter-Transparent-SMTP-%{version}
chmod -x LICENSE
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README LICENSE
%{perl_vendorlib}/POE/Filter/*
%{_mandir}/man3/*
%changelog
* Wed Jun 1 2009 Yanko Kaneti yan...@declera.com - 0.2-3
- Don't own %%{perl_vendorlib}/POE + Filter
- Initial import
* Thu Apr 16 2009 Yanko Kaneti yan...@declera.com - 0.2-2
- fix LICENSE permissions
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.2-1
- First attempt on packaging. Based on perl-POE-Filter-Zlib
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:40:15 - 1.1
+++ .cvsignore 4 Jun 2009 16:52:06 - 1.2
@@ -0,0 +1 @@
+POE-Filter-Transparent-SMTP-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:40:15 - 1.1
+++ sources 4 Jun 2009 16:52:06 - 1.2
@@ -0,0 +1 @@
+2763998d0713d3e9736009378296886d POE-Filter-Transparent-SMTP-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Filter-Transparent-SMTP/F-11 import.log, NONE, 1.1 perl-POE-Filter-Transparent-SMTP.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15990/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Filter-Transparent-SMTP.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Filter-Transparent-SMTP-0_2-3_fc11:F-11:perl-POE-Filter-Transparent-SMTP-0.2-3.fc11.src.rpm:1244134267
--- NEW FILE perl-POE-Filter-Transparent-SMTP.spec ---
Name: perl-POE-Filter-Transparent-SMTP
Version:0.2
Release:3%{?dist}
Summary:A POE filter for SMTP
# note license definition in Makefile.PL
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/POE-Filter-Transparent-SMTP/
Source0:
http://search.cpan.org/CPAN/authors/id/U/UL/ULTRADM/POE-Filter-Transparent-SMTP-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(POE)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
POE data filter which aims to make SMTP data transparent
just before going onto the wire as per RFC 821 Section 4.5.2.
%prep
%setup -q -n POE-Filter-Transparent-SMTP-%{version}
chmod -x LICENSE
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README LICENSE
%{perl_vendorlib}/POE/Filter/*
%{_mandir}/man3/*
%changelog
* Wed Jun 1 2009 Yanko Kaneti yan...@declera.com - 0.2-3
- Don't own %%{perl_vendorlib}/POE + Filter
- Initial import
* Thu Apr 16 2009 Yanko Kaneti yan...@declera.com - 0.2-2
- fix LICENSE permissions
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.2-1
- First attempt on packaging. Based on perl-POE-Filter-Zlib
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:40:15 - 1.1
+++ .cvsignore 4 Jun 2009 16:50:28 - 1.2
@@ -0,0 +1 @@
+POE-Filter-Transparent-SMTP-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:40:15 - 1.1
+++ sources 4 Jun 2009 16:50:28 - 1.2
@@ -0,0 +1 @@
+2763998d0713d3e9736009378296886d POE-Filter-Transparent-SMTP-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Filter-Transparent-SMTP/devel import.log, NONE, 1.1 perl-POE-Filter-Transparent-SMTP.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: yaneti
Update of /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15505/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-POE-Filter-Transparent-SMTP.spec
Log Message:
Initial import
--- NEW FILE import.log ---
perl-POE-Filter-Transparent-SMTP-0_2-3_fc11:HEAD:perl-POE-Filter-Transparent-SMTP-0.2-3.fc11.src.rpm:1244134156
--- NEW FILE perl-POE-Filter-Transparent-SMTP.spec ---
Name: perl-POE-Filter-Transparent-SMTP
Version:0.2
Release:3%{?dist}
Summary:A POE filter for SMTP
# note license definition in Makefile.PL
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/POE-Filter-Transparent-SMTP/
Source0:
http://search.cpan.org/CPAN/authors/id/U/UL/ULTRADM/POE-Filter-Transparent-SMTP-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(POE)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
POE data filter which aims to make SMTP data transparent
just before going onto the wire as per RFC 821 Section 4.5.2.
%prep
%setup -q -n POE-Filter-Transparent-SMTP-%{version}
chmod -x LICENSE
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README LICENSE
%{perl_vendorlib}/POE/Filter/*
%{_mandir}/man3/*
%changelog
* Wed Jun 1 2009 Yanko Kaneti yan...@declera.com - 0.2-3
- Don't own %%{perl_vendorlib}/POE + Filter
- Initial import
* Thu Apr 16 2009 Yanko Kaneti yan...@declera.com - 0.2-2
- fix LICENSE permissions
* Wed Apr 15 2009 Yanko Kaneti yan...@declera.com - 0.2-1
- First attempt on packaging. Based on perl-POE-Filter-Zlib
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Jun 2009 15:40:15 - 1.1
+++ .cvsignore 4 Jun 2009 16:48:37 - 1.2
@@ -0,0 +1 @@
+POE-Filter-Transparent-SMTP-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-POE-Filter-Transparent-SMTP/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Jun 2009 15:40:15 - 1.1
+++ sources 4 Jun 2009 16:48:37 - 1.2
@@ -0,0 +1 @@
+2763998d0713d3e9736009378296886d POE-Filter-Transparent-SMTP-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-PDF-API2/devel .cvsignore, 1.9, 1.10 perl-PDF-API2.spec, 1.20, 1.21 sources, 1.9, 1.10
Author: bjohnson
Update of /cvs/pkgs/rpms/perl-PDF-API2/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15933
Modified Files:
.cvsignore perl-PDF-API2.spec sources
Log Message:
v 0.73
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-PDF-API2/devel/.cvsignore,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- .cvsignore 1 Dec 2008 20:24:57 - 1.9
+++ .cvsignore 5 Jun 2009 15:17:16 - 1.10
@@ -1 +1 @@
-PDF-API2-0.72.003.tar.gz
+PDF-API2-0.73.tar.gz
Index: perl-PDF-API2.spec
===
RCS file: /cvs/pkgs/rpms/perl-PDF-API2/devel/perl-PDF-API2.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- perl-PDF-API2.spec 25 Feb 2009 11:57:59 - 1.20
+++ perl-PDF-API2.spec 5 Jun 2009 15:17:17 - 1.21
@@ -1,6 +1,6 @@
Name: perl-PDF-API2
-Version:0.72.003
-Release:2%{?dist}
+Version:0.73
+Release:1%{?dist}
Summary:Perl module for creation and modification of PDF files
Group: System Environment/Libraries
@@ -92,6 +92,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Jun 05 2009 Bernard Johnson bjohn...@symetrix.com - 0.73-1
+- v 0.73-1
+
* Wed Feb 25 2009 Paul Howarth p...@city-fan.org - 0.72.003-2
- fix dejavu-* dependencies again
- recode TODO as UTF-8
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-PDF-API2/devel/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 1 Dec 2008 20:24:57 - 1.9
+++ sources 5 Jun 2009 15:17:17 - 1.10
@@ -1 +1 @@
-c5e6e233f4e33d06f9ef6d5827d5ed84 PDF-API2-0.72.003.tar.gz
+848fb727323390128cac85cc11f52de1 PDF-API2-0.73.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 504389] New: RFE: update to 0.11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RFE: update to 0.11 https://bugzilla.redhat.com/show_bug.cgi?id=504389 Summary: RFE: update to 0.11 Product: Fedora Version: 10 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: perl-Sys-SigAction AssignedTo: andr...@bawue.net ReportedBy: bjohn...@symetrix.com QAContact: extras...@fedoraproject.org CC: andr...@bawue.net, fedora-perl-devel-list@redhat.com Classification: Fedora Description of problem: Please update to 0.11. -- 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 Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-App-Nopaste/devel perl-App-Nopaste.spec,1.2,1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-App-Nopaste/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22488
Modified Files:
perl-App-Nopaste.spec
Log Message:
* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
rafb.net has gone)
Index: perl-App-Nopaste.spec
===
RCS file: /cvs/pkgs/rpms/perl-App-Nopaste/devel/perl-App-Nopaste.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-App-Nopaste.spec 3 May 2009 08:22:22 - 1.2
+++ perl-App-Nopaste.spec 6 Jun 2009 01:11:34 - 1.3
@@ -1,6 +1,6 @@
Name: perl-App-Nopaste
Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Easy access to any pastebin
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,13 +36,25 @@ for public viewing. They're used a lot i
would normally be too long to give directly in the channel (hence the
name nopaste).
+%package -n nopaste
+# needs to beat old nopaste-2835-3
+Epoch: 1
+License:GPL+ or Artistic
+Group: Development/Libraries
+Summary:Access pastebins from the command line
+Requires: %{name} = 0:%{version}-%{release}
+
+%description -n nopaste
+This application lets you post text to pastebins from the command line.
+
+Pastebins (also known as nopaste sites) let you post text, usually code, for
+public viewing. They're used a lot in IRC channels to show code that would
+normally be too long to give directly in the channel (hence the name nopaste).
+
+
%prep
%setup -q -n App-Nopaste-%{version}
-mv bin/nopaste bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' Makefile.PL
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -67,11 +79,18 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%files -n nopaste
+%defattr(-,root,root,-)
%{_bindir}/*
%{_mandir}/man1/*
-%{_mandir}/man3/*
%changelog
+* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
+- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
+ rafb.net has gone)
+
* Sun May 03 2009 Iain Arnell iarn...@gmail.com 0.10-2
- rename nopaste command to avoid conflict with existing nopaste rpm
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-App-Nopaste/F-11 perl-App-Nopaste.spec,1.2,1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-App-Nopaste/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25148/F-11
Modified Files:
perl-App-Nopaste.spec
Log Message:
* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
rafb.net has gone)
Index: perl-App-Nopaste.spec
===
RCS file: /cvs/pkgs/rpms/perl-App-Nopaste/F-11/perl-App-Nopaste.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-App-Nopaste.spec 22 May 2009 06:40:07 - 1.2
+++ perl-App-Nopaste.spec 6 Jun 2009 01:21:51 - 1.3
@@ -1,6 +1,6 @@
Name: perl-App-Nopaste
Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Easy access to any pastebin
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,13 +36,25 @@ for public viewing. They're used a lot i
would normally be too long to give directly in the channel (hence the
name nopaste).
+%package -n nopaste
+# needs to beat old nopaste-2835-3
+Epoch: 1
+License:GPL+ or Artistic
+Group: Development/Libraries
+Summary:Access pastebins from the command line
+Requires: %{name} = 0:%{version}-%{release}
+
+%description -n nopaste
+This application lets you post text to pastebins from the command line.
+
+Pastebins (also known as nopaste sites) let you post text, usually code, for
+public viewing. They're used a lot in IRC channels to show code that would
+normally be too long to give directly in the channel (hence the name nopaste).
+
+
%prep
%setup -q -n App-Nopaste-%{version}
-mv bin/nopaste bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' Makefile.PL
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -67,11 +79,18 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%files -n nopaste
+%defattr(-,root,root,-)
%{_bindir}/*
%{_mandir}/man1/*
-%{_mandir}/man3/*
%changelog
+* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
+- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
+ rafb.net has gone)
+
* Sun May 03 2009 Iain Arnell iarn...@gmail.com 0.10-2
- rename nopaste command to avoid conflict with existing nopaste rpm
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-App-Nopaste/F-10 perl-App-Nopaste.spec,1.2,1.3
Author: iarnell
Update of /cvs/pkgs/rpms/perl-App-Nopaste/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25148/F-10
Modified Files:
perl-App-Nopaste.spec
Log Message:
* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
rafb.net has gone)
Index: perl-App-Nopaste.spec
===
RCS file: /cvs/pkgs/rpms/perl-App-Nopaste/F-10/perl-App-Nopaste.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-App-Nopaste.spec 22 May 2009 06:45:47 - 1.2
+++ perl-App-Nopaste.spec 6 Jun 2009 01:21:50 - 1.3
@@ -1,6 +1,6 @@
Name: perl-App-Nopaste
Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Easy access to any pastebin
License:GPL+ or Artistic
Group: Development/Libraries
@@ -36,13 +36,25 @@ for public viewing. They're used a lot i
would normally be too long to give directly in the channel (hence the
name nopaste).
+%package -n nopaste
+# needs to beat old nopaste-2835-3
+Epoch: 1
+License:GPL+ or Artistic
+Group: Development/Libraries
+Summary:Access pastebins from the command line
+Requires: %{name} = 0:%{version}-%{release}
+
+%description -n nopaste
+This application lets you post text to pastebins from the command line.
+
+Pastebins (also known as nopaste sites) let you post text, usually code, for
+public viewing. They're used a lot in IRC channels to show code that would
+normally be too long to give directly in the channel (hence the name nopaste).
+
+
%prep
%setup -q -n App-Nopaste-%{version}
-mv bin/nopaste bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' bin/app-nopaste
-sed -i -e 's/nopaste/app-nopaste/' Makefile.PL
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -67,11 +79,18 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%files -n nopaste
+%defattr(-,root,root,-)
%{_bindir}/*
%{_mandir}/man1/*
-%{_mandir}/man3/*
%changelog
+* Sat Jun 06 2009 Iain Arnell iarn...@gmail.com 0.10-3
+- nopaste gets its own subpackage (to replace existing nopaste pacakge now that
+ rafb.net has gone)
+
* Sun May 03 2009 Iain Arnell iarn...@gmail.com 0.10-2
- rename nopaste command to avoid conflict with existing nopaste rpm
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
