Re: Introduction: Interested in becoming a packager for fis-gtm and vista
On 2012-07-16 22:50, Clive Hills wrote:
Coincidentally I was looking at gtm this weekend.
One of the interesting points in re packaging it is that one must
bootstrap gtm from an existing gtm using the providing source.
I'm wondering a bit how that might be affected by the Fedora packaging
guidelines?
You need to file a FPC ticket to get a one-time exception.
http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions says:
Some software (usually related to compilers or cross-compiler
environments) cannot be built without the use of a previous toolchain or
development environment (open source). If you have a package which meets
this criteria, contact the Fedora Packaging Committee for approval.
Please note that this exception, if granted, is limited to only the
initial build of the package. You may bootstrap this build with a
bootstrap pre-built binary, but after this is complete, you must
immediately increment Release, drop the bootstrap pre-built binary,
and build completely from source. Bootstrapped packages containing
pre-built bootstrap binaries must not be pushed as release packages or
updates under any circumstances. These packages should contain the
necessary logic to be built once bootstrapping is completed and the
prebuilt programs are no longer needed. This can be done like this:
# Set this to 0 after we've bootstrapped
%{!? with_bootstrap: %global bootstrap 1}
[...]
%if 0%{?with_bootstrap}
# Do stuff involving the prebuilt files
%else
# The normal build
%endif
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. That's how it has always worked, and will always work. Anyone programming in a UNIX environment has to cope with it. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. That's the normal state of things, if normal means anything. When that no longer holds true, that's not normal. As others have pointed out it is a normal situation that the system has to deal with; there's no escaping it on a UNIX-like OS and a developer can never depend on it not happening at random times. The pathname that is returned to readlink(2) doesn't exist in the file system (how could it?) but the proc path is still valid for IO and the inode will not be de-allocated while it is open: $ cp /bin/vim /tmp $ /tmp/vim foo $ ps ax | grep foo 8904 pts/3S+ 0:00 ./vim foo 8960 pts/4S+ 0:00 grep --color=auto foo $ rm /tmp/vim $ readlink /proc/8904/exe /tmp/vim (deleted) $ cat /proc/8904/exe /tmp/vim.out $ ll /tmp/vim.out -rw-rw-r--. 1 breeves breeves 2097656 Jul 17 09:41 /tmp/vim.out $ file /tmp/vim.out /tmp/vim.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x695009d204a46dd413af6afc12207ee5f21fabf5, stripped $ md5sum /tmp/vim.out 21f4752d9efdb68e6af1ff22b2652fde /tmp/vim.out $ md5sum /bin/vim 21f4752d9efdb68e6af1ff22b2652fde /bin/vim $ prelink -u -o - /tmp/vim.out | md5sum c9b7e38bacad0b1c5e04b6c71a5f45b9 - $ prelink -u -o - /bin/vim | md5sum c9b7e38bacad0b1c5e04b6c71a5f45b9 - If the check you need to make is is this the same binary? then surely it should fail if the binary was actually upgraded? If it was not and was simply modified by prelink then you should be able to do what you want by open(2)ing the proc path instead of readlink(2)ing it. If you're happy to accept something that's a different version of the binary then I'm not sure why you need to read the executable (what are you checking in it?). If it's just an inode number match it's hard to see what that achieves. Broken maintenance scripts, of dubiuous benefit, that randomly rewrite unrelated binaries, should be fixed. Suggest fixes. If you're doing something unusual the onus is on you to justify why the system should conform to your expectations instead of the expectations it's currently designed for. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
On 07/17/2012 03:02 AM, Paul Wouters wrote: On Tue, 17 Jul 2012, Mike Manilone wrote: I think we can create a new repo called security like Debian. Push all the security updates to it. Uhm, we have that. It is called RHEL Not quite although RHEL errata are also categorised as security, fix and feature. The data for vulnerabilities is also made available in standard formats (OVAL and CPE mappings for Red Hat products). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introduction: Interested in becoming a packager for fis-gtm and vista
Clive, It is great to hear that you are already interested in gtm. The good news is that during the Debian packaging we solved the bootstrapping problem. We worked along with upstream and with Debian developers to find a suitable solution. The reason why gtm is needed in order to build gtm, is that it pre-processes a set of input files, and generates code from them. The pre-processing being done by a gtm compiler. What we did to break the self-dependency, was to include in the source distribution (with the agreement of upstream) the sources of the generated files. In this way, the build process starts from the full collection of sources (including the generated files) and no initial gtm compiler is needed anymore. In addition, to ensure consistency, once we build the gtm compiler, we do a second round in which we regenerate those files the traditional way, and do a second build pass. In this manner we ensure consistency with the build process that gtm has used so far. To instrument all this, we also created a CMake configuration for gtm, and that helped a lot to control all the details of the build. The reorganized code that we worked on with upstream is in this github repository (and branch): https://github.com/luisibanez/fis-gtm/tree/hackathonjune2012-brad The upstream team will be making a fresh release at some point with this new collection of files, at: http://sourceforge.net/projects/fis-gtm/ (not there yet). If one works from the CMake-ified sources (in the github repository above), the package can be built by using only gcc through: cmake . make -j 4 make install There were other modifications details, that we will be happy to describe further if anyone is interested. With this fis-gtm package, we were also able to build the package for VistA. (where fis-gtm is the only dependency for the vista package). Luis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
On Tue, 17 Jul 2012 10:17:59 +0800 Mike Manilone crtm...@gmx.us wrote: 於 一，2012-07-16 於 22:02 -0400，Paul Wouters 提到： On Tue, 17 Jul 2012, Mike Manilone wrote: I think we can create a new repo called security like Debian. Push all the security updates to it. Uhm, we have that. It is called RHEL Paul No money to buy. :-) CentOS, Scientific Linux, ...? -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Andrew Haley writes: On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. Perhaps this might be a hard concept to wrap one's brain around, but there's a quite a bit of difference between this is an exceptional event, and that's what happens when i does, versus this is now a normal occurence that, with prelink installed, and can happen to any random executable, at any time. Across the pond, I believe that there's a word to describe this: rubbish. How presumptious of an executable binary, that's not world-writable, to expect that nobody's going to come around, suddenly, and delete it! What would those kids think of next… / That's how it has always worked, and will always work. Anyone programming in a UNIX environment has to cope with it. Sure. And since gruesome car wrecks are a normal, everyday occurence, there's no reason to do anything to davoid them. That's how they always work, and anyone will just have to deal with the aftermath, without bothering to take any steps to avoid the situation in the first place, right? pgpNpPHajsVDw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
On 17/07/12 02:40, Mike Manilone wrote: Hi, list I don't want too many updates so I disable the updates repo. But later I found that fedora repo has no updates so I couldn't get any security updates. I'm not really sure, this would give you, what you really want; especially, it may even lead to broken dependencies, because not every package is accessible just through fedora and security channels. Take an application and assume, there's a security flaw discovered. It'll probably get fixed in the latest, sometimes even in some versions; this may not include the version packaged in the distribution. Then a packager would upgrade to a newer version, introducing newer features, which you don't want to get. The never version may require other packages, which are currently unavailable in fedora or security repos. If you'd like to get security fixes backported, you'll probably want a supported (i.e. paid) distro, e.g. RHEL or it's free clones Scientific Linux, or CentOS. Please note: you will still get (many) updates and should install them all, but you won't get newer features. I'm skeptic, if a pure security repo for fedora would work that well. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On Tue, Jul 17, 2012 at 07:01:23AM -0400, Sam Varshavchik wrote: Andrew Haley writes: On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. But pathname is volatile. That's why we support security framework based on labels, not on pathnames... -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Bryn M. Reeves writes: On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. That's the normal state of things, if normal means anything. When that no longer holds true, that's not normal. As others have pointed out it is a normal situation that the system has to deal with; No, I'm afraid it's not normal, by any sense of the word, for something to randomly delete executables, and replace them with similarly looking files. there's no escaping it on a UNIX-like OS and a developer Yes, there's certainly a guaranteed way to escape it. It's called don't do stupid things. What a novel concept. can never depend on it not happening at random times. The pathname that is returned to readlink(2) doesn't exist in the file system (how could it?) but the proc path is still valid for IO and the inode will not be de-allocated while it is open: Except that's not what proc(5) says. As described, reading that symlink should give you the executable's name. Except, in this situation, it no longer does. It points to a non-existent pathname. The fact that by some miracle of miracles an open() on a non-existent pathname manages to succeed, is an irrelevant sideshow. If you're happy to accept something that's a different version of the binary I'm not. then I'm not sure why you need to read the executable (what are When did I ever said that I needed to read the executable? you checking in it?). If it's just an inode number match it's hard to see what that achieves. Just because you find it hard to see what that achieves, means only that: you find it hard to see. Broken maintenance scripts, of dubiuous benefit, that randomly rewrite unrelated binaries, should be fixed. Suggest fixes. If you're doing something unusual the onus is on you to Well, I did. pgpQ8TZnFwmLY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:01 PM, Sam Varshavchik wrote: Andrew Haley writes: Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. And a number of other common configurations for e.g. a Fedora system set to automatically apply security updates in the background. Perhaps this might be a hard concept to wrap one's brain around, but there's a quite a bit of difference between this is an exceptional event, and that's what happens when i does, versus this is now a normal occurence that, with prelink installed, and can happen to any random executable, at any time. Across the pond, I believe that there's a word to describe this: rubbish. Throwing pejoratives around doesn't change the situation. How presumptious of an executable binary, that's not world-writable, to expect that nobody's going to come around, suddenly, and delete it! What would those kids think of next… Prelink is not new. I think the fact that it's been in the distro for many years without breaking other apps that are doing this read-my-own-binary thing suggests that that is not a common idiom for UNIX programs (that's not to say it has never caused any problems but you seem to be questioning the entire design). Sure. And since gruesome car wrecks are a normal, everyday occurence, there's no reason to do anything to davoid them. That's how they always work, and anyone will just have to deal with the aftermath, without bothering to take any steps to avoid the situation in the first place, right? Adding more hyperbole and strawman arguments does not change the fact that this can and does happen on Linux and UNIX environments and that programs need to be aware of it and deal with it reasonably when it does happen. Ken Thompson once stated that if he wrote UNIX again he would spell creat with an 'e' but nobody is proposing changing that today. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Bryn M. Reeves writes: On 07/17/2012 12:01 PM, Sam Varshavchik wrote: Andrew Haley writes: Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. And a number of other common configurations for e.g. a Fedora system set to automatically apply security updates in the background. Except that those configurations have what's called pre and post RPM scripts, have you heard of them? … which can be used to reset the application, so that it knows that it's been updated. Is it really so difficult to see the difference, here? If you tell me how an app can be notified that prelink is about to rewrite it, then this would be a comparable situation. But it's not. pgp2A4OFxazXJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Tomasz Torcz writes: On Tue, Jul 17, 2012 at 07:01:23AM -0400, Sam Varshavchik wrote: Andrew Haley writes: On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. But pathname is volatile. That's why we support security framework based on labels, not on pathnames... Indeed. Let's just get rid of ext4, and just assign various labels to blobs of data on the hard drive… Pathnames. Who needs them? pgp1tXhN29ibP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:42 PM, Sam Varshavchik wrote: … which can be used to reset the application, so that it knows that it's been updated. Because that is a common need across many packages. Apparently being notified of a prelink is not such a common need. Even if such a thing did exist it could not protect you from any other modifications to the binary if it was specific to prelinking so you would still need to handle this case to avoid bugs in your program. Maybe you would find more acceptance for a request asking for something like this rather than demanding the removal of something that has been used for many years and that has good evidence for the benefits it claims to provide? If you tell me how an app can be notified that prelink is about to rewrite it, then this would be a comparable situation. But it's not. Inotify? If you care about it in your app (and since nobody else appears to have asked for it I'd argue that's a good sign that there is not yet any justification for a general facility like this) perhaps you should look at inotify and register a watch for your executable's inode so that you can take appropriate actions? This would also deal with modifications other than prelinking. You could even make such a thing into a library that other developers could use to solve the same problem. If there's widespread need for the facility I'm sure you'd soon have plenty of users and a good justification to get it included in distributions. That's generally how things move forward in open source. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik mr...@courier-mta.com wrote: Jan Kratochvil writes: Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). Documentation tends to be written after-the fact, and therefore is more likely to be incorrect than the behavior, especially in corner cases. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik mr...@courier-mta.com wrote:
Scott Schmit writes:
And what's the pathname of a deleted file?
My point exactly. There is none. Thanks, prelink!
Thanks, UNIX. What is the pathname of a file with several links?
The pathnames just doesn't mean much in UNIX, and this case is _not_
particularly special.
Even
then, the time would be better spent changing your software to use the
interface correctly (or use a more appropriate one) so you never have
problems.
Can you explain, then, the correctly approach by which an executable can
affirm whether another pid is either running the same executable, or the
post-prelinked version of the same executable.
The executable _doesn't_ affirm that. This affirmation has zero
security value due to ptrace(2) (or plain mmap(2) replacing the old
executable with something different), and I can't see any non-security
purpose of this check either. If you don't tell us what you are
_actually_ trying to do, instead of fixating on a sub-task that is
impossible or meaningless in UNIX, I'm afraid you'll stay
disappointed.
P.P.S. And I'm still trying to process the concept of a symbolic link
pointing to a non-existent pathname; yet an open() on that somehow succeeds,
nevertheless. That's one a headscratcher, even though I'm told that's how
UNIX worked for decades. You always learn something new.
Other traditional examples: /dev/std{in,out,err} (OK, these used to be
devices rather than symlinks, but that's a trivial difference),
/proc/*/fd/* in Linux.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Mass rebuild for Fedora 18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it was requested in https://fedorahosted.org/rel-eng/ticket/5222 that we do a mass rebuild for Fedora 18 for https://fedoraproject.org/wiki/Features/DwarfCompressor and https://fedoraproject.org/wiki/Features/MiniDebugInfo due to a mix up in dates it was going to start on 2012-07-30 but since that only gives a week to do the rebuild before branching for f18 on 2012-08-07 we will be starting the mass rebuild on 2012-07-18 This is a heads up that it will be done in a side tag and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlAFXQoACgkQkSxm47BaWfeSAACgu+vUKWhm2mLYHF4Xqr0TlrkS qB4AoJocdVao2s6eUpWS82L5HO2bUSdC =AAjf -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring status posting
On 07/16/2012 07:38 PM, Till Maas wrote: I was asked to send to send the status of the last run of the Upstream Release Monitoring tool to this list. It would consist of all lines in http://till.fedorapeople.org/tmp/cnucnu-last.log that mention that a package is outdated. Would you welcome this or find it disturbing? I think it would be too noisy, because currently it will contain about 500 packages where some are bogus. I don't think it's more annoying than daily 'Rawhide Reports'. e.g.: http://lists.fedoraproject.org/pipermail/devel/2012-July/169869.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Once upon a time, Sam Varshavchik mr...@courier-mta.com said: Well, SCM_RIGHTS/SCM_CREDENTIALS is how you get the peer's pid in the first place. This would be an additional check, on top of that. Is there any value in this additional check (that nobody else apparently does)? Do you not trust the kernel's credential handling? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
Am 17.07.2012 02:40, schrieb Mike Manilone: Hi, list I don't want too many updates so I disable the updates repo. But later I found that fedora repo has no updates so I couldn't get any security updates. I think we can create a new repo called security like Debian. Push all the security updates to it. I believe that there are people like me disabled updates repo. They are very dangerous! Please review whether this is okay. Thanks! no need yum update --security signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hey list, I've been a contributor to upstream systemtap since mid 2010 and have been a Fedora user since Fedora 12. Prior to joining Red Hat full time, I participated in their internship program while completing a computer engineering degree at Queens University. I'd like to become a packager for systemtap so I can help the current maintainers with backport/fixes and releases as needed. You can find me on #fedora-devel and #systemtap as lberk, feel free to ping me if you have any questions. Thanks, Lukas pgpWG84uJSFM0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 Feature Submission Deadline in one week (2012-07-24)
Hi! This a friendly reminder that The Fedora 18 Feature Submission Deadline is coming soon (maybe too soon for some of you;-) - see the Fedora 18 Schedule [1] - and it's exactly in one week, on Tuesday, July 24, 2012. After this date newly submitted features will be targeted for Fedora 19 unless an exception is granted by FESCo. So, think about the stuff you're working on if it deserves the broader visibility within the release and submit it as a feature, see Feature process Policy [2]. Feature Freeze follows in other next two weeks (2012-08-07) and Features should be *substantially complete and in a testable state* at this point [3]. Please take a look on accepted Fedora 18 Features so far to check what's going to happen in Spherical Cow, if there are no conflicts with your features or you have a cool idea how to extend/ help with the features itself. Also - for the owners of already accepted features - please update the current status of your feature (both completion percentage and last updated date). I'll go through the list in a next few days to update the main FeatureList page. After that time I can't promise you a friendly reminder but... Thanks for all for the amazing job! Jaroslav Your Feature Wrangler [1] http://fedoraproject.org/wiki/Releases/18/Schedule [2] http://fedoraproject.org/wiki/Features/Policy [3] http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy [4] http://fedoraproject.org/wiki/Releases/18/FeatureList Btw. in case you'll need a help with Feature, feel free to contact me (email, ping etc.). ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Package review requests related with pdfmod
Hi: pdfmod is just one package of distance to get into F18 since the two dependencies are now approved. Someone want to review it? -- Forwarded message -- From: Ismael Olea ism...@olea.org Date: Tue, Jul 3, 2012 at 1:16 PM Subject: Package review requests related with pdfmod To: Development discussions related to Fedora devel@lists.fedoraproject.org -- Forwarded message -- From: Ismael Olea ism...@olea.org Date: Fri, Jun 22, 2012 at 1:31 PM Subject: Package review requests To: Fedora-Mono m...@lists.fedoraproject.org Hi: I adopted this packages and need the peer reviews: - pdfmod: https://bugzilla.redhat.com/show_bug.cgi?id=834552 - poppler-sharp https://bugzilla.redhat.com/show_bug.cgi?id=834551 (dep for pdfmod) - hyena https://bugzilla.redhat.com/show_bug.cgi?id=834548 (dep for pdfmod and banshee) Volunteers? -- Ismael Olea http://olea.org/diario/ -- Ismael Olea http://olea.org/diario/ -- Ismael Olea http://olea.org/diario/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED v2] Retiring packages for Fedora 18
Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. That is currently scheduled to happen on or around August 7th. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance. Package asylum (orphan) Package cmucl (orphan) comaintained by: green Package debmirror (orphan) Package drupal6-video (orphan) Package eclipse-m2m-qvtoml (fails to build) Package emacs-common-proofgeneral (fails to build) Package fillmore-lombard (fails to build) comaintained by: salimma Package gant (fails to build) Package gnokii (orphan) comaintained by: hadess snirkel Package gnome-phone-manager (orphan) comaintained by: hadess snirkel Package gpsdrive (orphan) Package gtkmm-utils (orphan) Package hardinfo (fails to build) Package healpix (fails to build) Package hexter-dssi (orphan) comaintained by: oget Package json (orphan) Package k12linux-quick-start-guide (orphan) Package kadu (fails to build) comaintained by: gajownik radekl Package libcrystalhd (fails to build) comaintained by: kwizart Package libfwbuilder (orphan) Package libhid (fails to build) Package libqttracker (fails to build) comaintained by: jreznik Package libsoup22 (orphan) Package natus (fails to build) Package ncpfs (orphan) Package ntfs-config (fails to build) Package perl-Nagios-Plugin-Beanstalk (orphan) Package pfqueue (orphan) Package pino (fails to build) Package polyester (orphan) Package polyester3 (orphan) Package python-batchhttp (orphan) Package python-pywt (fails to build) Package python-remoteobjects (orphan) Package python-typepad (orphan) Package qtparted (fails to build) Package selenium-remote-control (fails to build) Package torque (orphan) Package typepad-motion (orphan) Package upstart (orphan) Package whatsup (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: emacs-common-proofgeneral coq requires xemacs-proofgeneral = 3.7.1-5.fc15 coq requires emacs-proofgeneral = 3.7.1-5.fc15 coq-emacs requires emacs-proofgeneral = 3.7.1-5.fc15 coq-xemacs requires xemacs-proofgeneral = 3.7.1-5.fc15 Removing: gnokii libopensync-plugin-gnokii requires libgnokii.so.7 libopensync-plugin-gnokii requires gnokii-devel = 0.6.31-1.fc18 Removing: healpix skyviewer requires chealpix-devel = 2.13a-2.fc14 skyviewer requires libchealpix.so Removing: libfwbuilder fwbuilder requires libfwcompiler.so.9 fwbuilder requires libfwbuilder-devel = 4.1.2-1.fc15 fwbuilder requires libfwbuilder.so.9 fwbuilder requires libfwbuilder = 4.1.2-1.fc15 fwbuilder-cisco requires libfwcompiler.so.9 fwbuilder-cisco requires libfwbuilder.so.9 fwbuilder-ipf requires libfwcompiler.so.9 fwbuilder-ipf requires libfwbuilder.so.9 fwbuilder-ipfw requires libfwcompiler.so.9 fwbuilder-ipfw requires libfwbuilder.so.9 fwbuilder-ipt requires libfwcompiler.so.9 fwbuilder-ipt requires libfwbuilder.so.9 fwbuilder-pf requires libfwcompiler.so.9 fwbuilder-pf requires libfwbuilder.so.9 fwbuilder-procurve requires libfwcompiler.so.9 fwbuilder-procurve requires libfwbuilder.so.9 Removing: libsoup22 libopensync-plugin-syncml requires libsoup22-devel = 2.2.105-9.fc15 libsyncml requires libsoup-2.2.so.8 libsyncml requires libsoup22-devel = 2.2.105-9.fc15 Removing: ncpfs hydra requires ncpfs-devel = 2.2.6-16.fc17 hydra requires libncp.so.2.3 hydra requires libncp.so.2.3(NCPFS.2.2.0.17) hydra requires libncp.so.2.3(NCPFS_2.2.0.19) hydra requires libncp.so.2.3(NCPFS_2.2.1) medusa requires ncpfs-devel = 2.2.6-16.fc17 medusa requires libncp.so.2.3 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1) Removing: python-batchhttp django-typepad requires python-batchhttp = 1.1-4.fc17 Removing: python-remoteobjects django-typepad requires python-remoteobjects = 1.1-4.fc17 Removing: python-typepad django-typepad requires python-typepad = 1.1.2-4.fc17 Removing: selenium-remote-control perl-Alien-SeleniumRC requires selenium-server = 1.0.3-8.20100318svn.fc15 Removing: torque pbstop requires torque-client = 3.0.4-1.fc17 perl-PBS requires libtorque.so.2 perl-PBS requires libtorque-devel = 3.0.4-1.fc17 python-pbs requires torque-devel = 3.0.4-1.fc17 python-pbs requires libtorque.so.2 python3-pbs requires libtorque.so.2 Removing: upstart clamav-milter-upstart requires /sbin/initctl clamav-scanner-upstart requires
[Test-Announce] Call for Test Days for Fedora 18
Hey, folks. It's that time again - time to start thinking about Test Days for Fedora 18. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization, or any combination of the two. To propose a Test Day, just file a ticket in QA trac - full details are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many slots open right now, with the earliest on 2012-08-09 and the latest 2012-11-01. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Alpha release or the time after the feature freeze or the Final freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific timeframe due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or timeframe you'd like, and we'll figure it out from there. If you have any questions about the Test Day process, please don't hesitate to contact me or any other member of the QA team on test@ or in #fedora-qa on IRC. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages for Fedora 18
On Tue, 17 Jul 2012 13:51:24 -0400, Bill Nottingham wrote: Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. That is currently scheduled to happen on or around August 7th. Anyone interested in archmage -- Extensible reader/decompiler of files in CHM format gnusim8085 -- A graphical simulator for Intel 8085 microprocessor gtick -- A graphical metronome software python-chm -- Python package for CHM files handling ? Those are packages which are unmaintained since 2010, but after recent contact with their owner they are still not orphaned: https://fedorahosted.org/rel-eng/ticket/5237 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring status posting
* Till Maas [17/07/2012 07:09] : I was asked to send to send the status of the last run of the Upstream Release Monitoring tool to this list. It would consist of all lines in http://till.fedorapeople.org/tmp/cnucnu-last.log that mention that a package is outdated. Would you welcome this or find it disturbing? Mostly for. Anybody who doesn't care to read it can skip it or filter it out from their mailbox. And on the plus side, making the results more visible might incite people into sending bugfixes. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Bryn M. Reeves writes: On 07/17/2012 12:42 PM, Sam Varshavchik wrote: … which can be used to reset the application, so that it knows that it's been updated. Because that is a common need across many packages. Apparently being notified of a prelink is not such a common need. Even if such a thing did exist it could not protect you from any other modifications to the binary if it was specific to prelinking so you would still need to handle this case to avoid bugs in your program. I'm having some kind of a difficulty parsing the above. How exactly would some kind of a notification that your executable has been prelinked would not be effective for modifications that result from prelinking. Maybe you would find more acceptance for a request asking for something like this rather than demanding the removal of something that has been used for many years and that has good evidence for the benefits it claims to provide? I don't recall myself demanding anything. I described a problem that prelink is causing, namely invalidation of the contents of the /proc/self/exe symlink. I also floated some alternatives, like skipping binaries that are currently running. I see little sense in demanding something that can already be easily done anyway, like removing prelink altogether, or by blacklisting a selected executable, which is trivial to implement. I just thought – and as I said, that this is not solving the problem, but sweeping it under the rug, and that there should be a better way to avoid having prelink break /proc/self/exe. If you tell me how an app can be notified that prelink is about to rewrite it, then this would be a comparable situation. But it's not. Inotify? If you care about it in your app (and since nobody else appears to have asked for it I'd argue that's a good sign that there is not yet any justification for a general facility like this) perhaps you should look at inotify and register a watch for your executable's inode so that you can take appropriate actions? This would also deal with modifications other than prelinking. I'm dying to know what other modifications are there, other than prelinking – inquiring mind wants to know. And the coin can be flipped both ways too: AFAIK nothing else other than prelink randomly scribbles over random executables. Somehow, things have been fine all along, before prelink came along, and perhaps, some consideration could've been provided for applications to use and integrate with. You could even make such a thing into a library that other developers could use to solve the same problem. If there's widespread need for the facility I'm sure you'd soon have plenty of users and a good justification to get it included in distributions. That's generally how things move forward in open source. Thank you for telling me what I've already done. But, it would've been great to avoid dealing with prelink's broken design in the first place. pgpPZzmDwKd57.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Miloslav Trmač writes: On Tue, Jul 17, 2012 at 1:38 AM, Sam Varshavchik mr...@courier-mta.com wrote: Jan Kratochvil writes: Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). Documentation tends to be written after-the fact, and therefore is more likely to be incorrect than the behavior, especially in corner cases. Ok. I guess it's time to remove the man-pages rpm from Fedora. It's useless, from the looks of things. pgpM4XsYf1Rdm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Miloslav Trmač writes:
On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik mr...@courier-mta.com
wrote:
Scott Schmit writes:
And what's the pathname of a deleted file?
My point exactly. There is none. Thanks, prelink!
Thanks, UNIX. What is the pathname of a file with several links?
Doesn't matter, either one of them is fine.
The pathnames just doesn't mean much in UNIX, and this case is _not_
particularly special.
Yes, let's get rid of filesystems, and store everything in a relational
database. Isn't that something that a convicted monopolist tried to do, the
other day?
Can you explain, then, the correctly approach by which an executable can
affirm whether another pid is either running the same executable, or the
post-prelinked version of the same executable.
The executable _doesn't_ affirm that. This affirmation has zero
security value due to ptrace(2) (or plain mmap(2) replacing the old
executable with something different), and I can't see any non-security
purpose of this check either.
Just because that you see zero value of this, and that you see no purpose
from it, doesn't mean that there is none.
If you don't tell us what you are
_actually_ trying to do, instead of fixating on a sub-task that is
impossible or meaningless in UNIX, I'm afraid you'll stay
disappointed.
I already described what I'm doing, but I don't really feel like listening
again to someone who firmly believes that they know what I'm doing better
than me.
P.P.S. And I'm still trying to process the concept of a symbolic link
pointing to a non-existent pathname; yet an open() on that somehow
succeeds,
nevertheless. That's one a headscratcher, even though I'm told that's how
UNIX worked for decades. You always learn something new.
Other traditional examples: /dev/std{in,out,err} (OK, these used to be
devices rather than symlinks, but that's a trivial difference),
Really? An example of a symbolic link pointing to a non-existent pathname?
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdout → /proc/self/fd/1
You mean to tell me that none of those symlinks exist? Could've fooled me:
[mrsam@eee900 /]$ ls -al /proc/self/fd/{0,1,2}
lrwx--. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/0 → /dev/pts/1
lrwx--. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/1 → /dev/pts/1
lrwx--. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/2 → /dev/pts/1
But they do!
crw--w. 1 mrsam tty 136, 1 Jul 17 18:31 /dev/pts/1
And that symlink exists as well! And I can even open it!
[mrsam@eee900 /]$ cat /dev/pts/1
Wow, what a novel concept.
So, can you try again, with an example of a symlink that points to a non-
existent pathname, yet one that can be open(), like /proc/self/exe →
$filename (deleted) can.
But, again, that's a sideshow and a distraction. That's not a problem, or an
issue, of course. The problem is prelink invalidating the symlink, with the
sorry excuses from the duh… but you can still open it crowd, who are
incapable of understanding what the issue is.
pgpZVYWUYO4pc.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Chris Adams writes: Once upon a time, Sam Varshavchik mr...@courier-mta.com said: Well, SCM_RIGHTS/SCM_CREDENTIALS is how you get the peer's pid in the first place. This would be an additional check, on top of that. Is there any value in this additional check (that nobody else apparently does)? Do you not trust the kernel's credential handling? I certainly trust it. But just because I trust it, it doesn't mean that any additional checks have no value. pgpw55pZAHfbD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages for Fedora 18
Anyone interested in gnusim8085 -- A graphical simulator for Intel 8085 microprocessor I would be interested in taking gnusim8085. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Once upon a time, Sam Varshavchik mr...@courier-mta.com said: Chris Adams writes: Is there any value in this additional check (that nobody else apparently does)? Do you not trust the kernel's credential handling? I certainly trust it. But just because I trust it, it doesn't mean that any additional checks have no value. Sure it does. If the credentials are always correct, additional checks past that are a waste of cycles. I ask again: do you have a legitimate use case? Is there _any_ case that other checks can succeed that this invented test of yours would catch? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Miloslav Trmač writes:
On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik mr...@courier-mta.com
wrote:
Miloslav Trmač writes:
Can you explain, then, the correctly approach by which an executable
can
affirm whether another pid is either running the same executable, or the
post-prelinked version of the same executable.
The executable _doesn't_ affirm that. This affirmation has zero
security value due to ptrace(2) (or plain mmap(2) replacing the old
executable with something different), and I can't see any non-security
purpose of this check either.
Just because that you see zero value of this, and that you see no purpose
from it, doesn't mean that there is none.
I have explained why I think the information is meaningless. Which
part is incorrect, or what am I assuming that is not true?
Yes, you have explained why you think it's meaningless. And I explained why
I think it's not.
P.P.S. And I'm still trying to process the concept of a symbolic link
pointing to a non-existent pathname; yet an open() on that somehow
succeeds,
nevertheless. That's one a headscratcher, even though I'm told that's
how
UNIX worked for decades. You always learn something new.
Other traditional examples: /dev/std{in,out,err} (OK, these used to be
devices rather than symlinks, but that's a trivial difference),
Really? An example of a symbolic link pointing to a non-existent
pathname?
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0
lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdout → /proc/self/fd/1
Traditionally, /dev/std* were special devices, not special links to
Who said anything about the type of the file they pointed to? You must've
meant to reply to some other post. I made no reference to the file type that
was targeted by the symbolic link.
pgpEmHNRIKveW.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
Chris Adams writes: Once upon a time, Sam Varshavchik mr...@courier-mta.com said: Chris Adams writes: Is there any value in this additional check (that nobody else apparently does)? Do you not trust the kernel's credential handling? I certainly trust it. But just because I trust it, it doesn't mean that any additional checks have no value. Sure it does. If the credentials are always correct, additional checks past that are a waste of cycles. You feel absolutely confident that just because you can't think of any value of additional checks, there cannot possibly be any. You're wrong. I ask again: do you have a legitimate use case? Is there _any_ case that other checks can succeed that this invented test of yours would catch? I already explained what they are. You may think you can always use ptrace, but ptrace cannot be used in every case. Furthermore, even if ptrace can, somehow, be used, that does not invalidate the value of the check. It's the same reason why the bind-chroot package exists (setting aside for the moment the completely irrelevant side issue that bind-chroot in F17 never worked, because apparently nobody bothered to actually execute systemctl start named-chroot.service and see if dig www.yahoo.com works afterwards, after fscking around with its systemd.unit file, or even read the months-old bugzilla report documenting the breakage, and what needs to be done to fix it). Putting bind in a chroot jail offers no apparent benefit or value, according to this same kind of logic. Yet, clearly it has value, even though it's impossible for some to see it. pgpZw7wIXT8qa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages for Fedora 18
On 07/17/2012 10:19 PM, Michael Schwendt wrote: gtick -- A graphical metronome software I have added myself to this package. regards Brendan (bsjones) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 746941] perl-Mojolicious-3.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=746941 --- Comment #69 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 3.10 Current version in Fedora Rawhide: 3.07 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 746941] perl-Mojolicious-3.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=746941 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-3.08 is|perl-Mojolicious-3.10 is |available |available -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Role-Tiny-1.001004.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Role-Tiny: cdee4d5f88088507eb69c77ae5c341ed Role-Tiny-1.001004.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Tree] Tidy up and don't BR: perl(Test::LeakTrace) when bootstrapping
commit 486f38bd831508b77f5d764f2d00311892090f8a
Author: Paul Howarth p...@city-fan.org
Date: Tue Jul 17 12:27:24 2012 +0100
Tidy up and don't BR: perl(Test::LeakTrace) when bootstrapping
- Don't BR: perl(Test::LeakTrace) when bootstrapping
- Don't use macros for commands
- Don't need to remove empty directories from the buildroot
- Drop explicit provides for perl(HTML::Tree) now that CPAN and RPM versions
are back in sync
perl-HTML-Tree.spec | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
---
diff --git a/perl-HTML-Tree.spec b/perl-HTML-Tree.spec
index f6943ca..6848619 100644
--- a/perl-HTML-Tree.spec
+++ b/perl-HTML-Tree.spec
@@ -1,7 +1,7 @@
Name: perl-HTML-Tree
-Version:5.02
-Release:3%{?dist}
Epoch: 1
+Version:5.02
+Release:4%{?dist}
Summary:HTML tree handling modules for Perl
Group: Development/Libraries
License:GPL+ or Artistic
@@ -15,16 +15,16 @@ BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Fatal)
-BuildRequires: perl(Test::LeakTrace)
+BuildRequires: perl(Test::Fatal)
%if !%{defined perl_bootstrap}
-BuildRequires: perl(HTML::FormatText)
+# HTML::FormatText (perl-HTML-Format) has BR: perl(HTML::TreeBuilder) from
this package
+BuildRequires: perl(HTML::FormatText)
+# perl-Test-LeakTrace - perl-Test-Valgrind - perl-XML-Twig - perl-HTML-Tree
+BuildRequires: perl(Test::LeakTrace)
%endif
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(HTML::Parser) = 3.46
Requires: perl(HTML::Tagset) = 3.02
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-# add because of possible problems with not mathing cpan,rpm version
-Provides: perl(HTML::Tree) = %{version}
%description
This distribution contains a suite of modules for representing,
@@ -37,14 +37,12 @@ a separate development track.
%setup -q -n HTML-Tree-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
%install
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
./Build test
@@ -56,6 +54,13 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/HTML::*3*
%changelog
+* Tue Jul 17 2012 Paul Howarth p...@city-fan.org - 1:5.02-4
+- Don't BR: perl(Test::LeakTrace) when bootstrapping
+- Don't use macros for commands
+- Don't need to remove empty directories from the buildroot
+- Drop explicit provides for perl(HTML::Tree) now that CPAN and RPM versions
+ are back in sync
+
* Tue Jul 10 2012 Petr Pisar ppi...@redhat.com - 1:5.02-3
- Perl 5.16 re-rebuild of bootstrapped packages
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Role-Tiny] update to 1.001004
commit dedd1cdacfea3a44bfdc6a198a2041bd7d7393f5
Author: Iain Arnell iarn...@gmail.com
Date: Tue Jul 17 05:29:47 2012 -0600
update to 1.001004
.gitignore |1 +
perl-Role-Tiny.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b72a6da..99282a0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/Role-Tiny-1.01.tar.gz
/Role-Tiny-1.001001.tar.gz
/Role-Tiny-1.001002.tar.gz
+/Role-Tiny-1.001004.tar.gz
diff --git a/perl-Role-Tiny.spec b/perl-Role-Tiny.spec
index 059bf40..98fc65a 100644
--- a/perl-Role-Tiny.spec
+++ b/perl-Role-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-Role-Tiny
-Version:1.001002
-Release:2%{?dist}
+Version:1.001004
+Release:1%{?dist}
Summary:A nouvelle cuisine portion size slice of Moose
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jul 17 2012 Iain Arnell iarn...@gmail.com 1.001004-1
+- update to latest upstream version
+
* Fri Jun 22 2012 Petr Pisar ppi...@redhat.com - 1.001002-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index 6fe96e1..23bcf95 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c8dc627418d0e3360e3ab35c120987d1 Role-Tiny-1.001002.tar.gz
+cdee4d5f88088507eb69c77ae5c341ed Role-Tiny-1.001004.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 480129] Error at calling service amavisd restart when SELinux is in enforce mode
https://bugzilla.redhat.com/show_bug.cgi?id=480129 Milos Malik mma...@redhat.com changed: What|Removed |Added Status|ON_QA |VERIFIED -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Role-Tiny/f17] (5 commits) ...update to 1.001004
Summary of changes: 9a479ec... update to 1.01 (*) 1019d3e... update to 1.001001 (*) fa7aa62... update to 1.001002 (*) 9764fa2... Perl 5.16 rebuild (*) dedd1cd... update to 1.001004 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-Tree] Created tag perl-HTML-Tree-5.02-4.fc18
The lightweight tag 'perl-HTML-Tree-5.02-4.fc18' was created pointing to: 486f38b... Tidy up and don't BR: perl(Test::LeakTrace) when bootstrapp -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML] Tidy up and fix build dependency loop
commit b92f5aef9e337e5e8a5bbb04b9b47cc282ee7669
Author: Paul Howarth p...@city-fan.org
Date: Tue Jul 17 12:54:40 2012 +0100
Tidy up and fix build dependency loop
- Haven't needed to fix documentation character encoding since 0.79
- Drop Test::Base build dependency again to avoid a BR loop (#215637)
- Filter private provides perl(yaml_mapping), perl(yaml_scalar) and
perl(yaml_sequence)
- Don't need to remove empty directories from the buildroot
- This release by MSTROUT - update source URL
perl-YAML.spec | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
---
diff --git a/perl-YAML.spec b/perl-YAML.spec
index a7c0dd5..ab60b62 100644
--- a/perl-YAML.spec
+++ b/perl-YAML.spec
@@ -1,11 +1,11 @@
Name: perl-YAML
Version:0.84
-Release:1%{?dist}
+Release:2%{?dist}
Summary:YAML Ain't Markup Language (tm)
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML/
-Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSTROUT/YAML-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Carp)
BuildRequires: perl(constant)
@@ -13,12 +13,14 @@ BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(lib)
-BuildRequires: perl(Test::Base)
-BuildRequires: perl(Test::Base::Filter)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Carp)
Requires: perl(Data::Dumper)
+# Filter private provides:
+# perl(yaml_mapping) perl(yaml_scalar) perl(yaml_sequence)
+%global __provides_exclude ^perl\\(yaml_
+
%description
The YAML.pm module implements a YAML Loader and Dumper based on the
YAML 1.0 specification. http://www.yaml.org/spec/
@@ -31,24 +33,20 @@ specification.
%prep
%setup -q -n YAML-%{version}
-# Re-code docs as UTF-8
-iconv -f iso-8859-1 -t utf8 README README.utf8
-mv README.utf8 README
-
%build
perl Makefile.PL INSTALLDIRS=vendor /dev/null
make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} %{buildroot}
+
# Removing Test::YAML (at least temporarily) due
# to security concerns and questionable value.
# https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197539
rm -f %{buildroot}%{perl_vendorlib}/Test/YAML* \
%{buildroot}%{_mandir}/man3/Test::YAML*.3*
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
-%{_fixperms} %{buildroot}/*
%check
make test
@@ -59,6 +57,14 @@ make test
%{_mandir}/man3/YAML*.3*
%changelog
+* Tue Jul 17 2012 Paul Howarth p...@city-fan.org - 0.84-2
+- Haven't needed to fix documentation character encoding since 0.79
+- Drop Test::Base build dependency again to avoid a BR loop (#215637)
+- Filter private provides perl(yaml_mapping), perl(yaml_scalar) and
+ perl(yaml_sequence)
+- Don't need to remove empty directories from the buildroot
+- This release by MSTROUT - update source URL
+
* Mon Jul 16 2012 Petr Šabata con...@redhat.com - 0.84-1
- 0.84 bump
- Drop command macros
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML] Created tag perl-YAML-0.84-2.fc18
The lightweight tag 'perl-YAML-0.84-2.fc18' was created pointing to: b92f5ae... Tidy up and fix build dependency loop -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the rawhide tree: On x86_64: perl-PDL-2.4.10-1.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-PDL-2.4.10-1.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Unix-Statgrab
perl-Unix-Statgrab has broken dependencies in the rawhide tree: On x86_64: perl-Unix-Statgrab-0.04-13.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-Unix-Statgrab-0.04-13.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-eperl
perl-eperl has broken dependencies in the rawhide tree: On x86_64: perl-eperl-2.2.14-19.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-eperl-2.2.14-19.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Class-InsideOut
perl-Class-InsideOut has broken dependencies in the rawhide tree: On x86_64: perl-Class-InsideOut-1.10-6.fc17.noarch requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-Class-InsideOut-1.10-6.fc17.noarch requires perl(:MODULE_COMPAT_5.14.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 839742] Review Request: perl-Rose-Object - Simple object base class
https://bugzilla.redhat.com/show_bug.cgi?id=839742
Jitka Plesnikova jples...@redhat.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||jples...@redhat.com
Assignee|nob...@fedoraproject.org|jples...@redhat.com
Flags||fedora-review?
--- Comment #3 from Jitka Plesnikova jples...@redhat.com ---
Package Review
==
Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated
Generic
[x]: EXTRA Rpmlint is run on all installed packages.
Note: There are rpmlint messages (see attachment).
[x]: EXTRA Spec file according to URL is the same as in SRPM.
[x]: MUST Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
least one supported primary architecture.
[x]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
$RPM_BUILD_ROOT)
Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm 4.4
Note: Note: defattr macros not found. They would be needed for EPEL5
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[-]: MUST Package contains desktop file if it is a GUI application.
[-]: MUST Development files must be in a -devel package
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Package complies to the Packaging Guidelines
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
beginning of %install.
Note: rm -rf would be needed if support for EPEL5 is required
[-]: MUST Large documentation files are in a -doc subpackage, if required.
[-]: MUST If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of the
license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macro is (instead of hard-coded directory
names).
[x]: MUST Package is named using only allowed ascii characters.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Package is not relocatable.
[!]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint is run on all rpms the build produces.
Note: No rpmlint messages.
[x]: MUST Sources used to build the package match the upstream source, as
provided in the spec URL.
[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
%{name}.spec.
[-]: MUST Package contains systemd file(s) if in need.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[-]: SHOULD If the source package does not include license text(s) as a
separate file from upstream, the packager SHOULD query upstream to
include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
/usr/sbin.
[!]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
--requires).
[?]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
upstream.
[x]: SHOULD SourceX / PatchY prefixed with %{name}.
[x]: SHOULD SourceX is a working URL.
[-]: SHOULD Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
[x]: SHOULD Package should compile and build into binary rpms on all supported
architectures.
[Bug 839742] Review Request: perl-Rose-Object - Simple object base class
https://bugzilla.redhat.com/show_bug.cgi?id=839742 --- Comment #4 from Bill Pemberton wf...@virginia.edu --- Rose::Object::MakeMethods was originally filtered from requires because it would create a circular depandancy. This was quite a few rpm versions ago (I've used essentially these same specs locally for years). It appears not to cause a problem now, so I've removed it. I'd like leave Class:XSAccessor out of the requires. It's optional for Rose::Object and would prevent Rose::Object from being in epel6 since Class:XSAccessor is not in epel6. Also, could you tell me how you are generating the missing requires? I'd like to know so I can catch these ahead of time. Spec URL: http://wfp.fedorapeople.org/perl-Rose-Object.spec SRPM URL: http://wfp.fedorapeople.org/perl-Rose-Object-0.859-5.fc17.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Moo-0.091014.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Moo: 100937be2395297989026780454d9fee Moo-0.091014.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Moo] update to 0.091014
commit d7aeebdb99258347c5dfb8993c4bdac073906881
Author: Iain Arnell iarn...@gmail.com
Date: Tue Jul 17 17:41:45 2012 -0600
update to 0.091014
.gitignore|1 +
perl-Moo.spec |9 ++---
sources |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1735201..d974b51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
/Moo-0.009013.tar.gz
/Moo-0.009014.tar.gz
/Moo-0.091007.tar.gz
+/Moo-0.091014.tar.gz
diff --git a/perl-Moo.spec b/perl-Moo.spec
index 5f705cd..f874f85 100644
--- a/perl-Moo.spec
+++ b/perl-Moo.spec
@@ -1,6 +1,6 @@
Name: perl-Moo
-Version:0.091007
-Release:2%{?dist}
+Version:0.091014
+Release:1%{?dist}
Summary:Minimalist Object Orientation (with Moose compatibility)
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,7 +10,7 @@ BuildArch: noarch
BuildRequires: perl(Class::Method::Modifiers) = 1.04
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Runtime) = 0.012
-BuildRequires: perl(Role::Tiny) = 1.001001
+BuildRequires: perl(Role::Tiny) = 1.001003
BuildRequires: perl(strictures) = 1.001001
BuildRequires: perl(Test::Fatal) = 0.003
BuildRequires: perl(Test::More) = 0.96
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jul 17 2012 Iain Arnell iarn...@gmail.com 0.091014-1
+- update to latest upstream version
+
* Sat Jun 23 2012 Petr Pisar ppi...@redhat.com - 0.091007-2
- Perl 5.16 rebuild
diff --git a/sources b/sources
index ff968b6..37f96c4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-16d99b92097a18b19904fe0256469aa2 Moo-0.091007.tar.gz
+100937be2395297989026780454d9fee Moo-0.091014.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
