Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
17.03.2013 05:39, Rex Dieter wrote: Orion Poplawski wrote: On 03/16/2013 07:38 AM, Rex Dieter wrote: Orion Poplawski wrote: On 03/14/2013 09:34 AM, Orion Poplawski wrote: Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. Scratch that, it was a hack for Arch Linux's hacked version of ImageMagick sonames that doesn't work for Fedora. Will need to work on a fix... I've a little experience adding pkg-config hints to cmake, I'll help look into it. As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue with pkg-config in cmake is that it isn't always present on all of the platforms that cmake supports. But it is still probably the way to go on Linux. OK, first-draft patch sent upstream and applied to cmake-2.8.11-0.3.rc1.fc20 As far as I could tell, only one package in fedora is affected, converseen, and confirmed it builds ok now. Thank you very much! Then I push ImageMagick into rawhide. Could you please provide upstream bug url for that to monitor status? -- rex -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
packaging catalogs and license questions
Hello, I would like to package some additional catalogs for Skychart, but I have some questions regarding license and to the package process. First of all, as you can see on skychart download page [1], each package has more than one catalog inside. All of these catalogs are known to be public domain, but there's no license file specified either in catalogs or on original websites of the catalogs [2] [3]. Moreover, original catalog data is reworked by skychart's developer to fit the main program. So, questions about license: Should I ask for a license file to be integrated? Who I should ask for the license file, skychart's developer or who make the original catalog data? Now the technical questions. I suppose I must create new packages and requesting reviews for each catalog source instead of creating subpackages inside the main skychart specfile, right? For example, skychart-data-stars.spec will have stars catalogs and skychart-data-dso.spec will have dso catalogs, like on the skychart's website? But what if inside the stars catalogs package two catalogs have different licenses?I must create different subpackages, right? Final question. Since all these catalogs contain only data that only requires to be copied in the appropriate directory, there's no need to build anything. Can the specfile have a void %build section? ...well, quite a lot of questions! ;-) I hope someone can clarify me on this... Mattia [1] http://www.ap-i.net/skychart/en/download [2] http://ad.usno.navy.mil/wds/ [3] http://www.astro.ku.dk/~erik/Tycho-2/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Pavel Alexeev wrote: 17.03.2013 05:39, Rex Dieter wrote: As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue with pkg-config in cmake is that it isn't always present on all of the platforms that cmake supports. But it is still probably the way to go on Linux. OK, first-draft patch sent upstream and applied to cmake-2.8.11-0.3.rc1.fc20 As far as I could tell, only one package in fedora is affected, converseen, and confirmed it builds ok now. Thank you very much! Then I push ImageMagick into rawhide. Could you please provide upstream bug url for that to monitor status? The one orion gave earlier in the thread, http://public.kitware.com/Bug/view.php?id=14012 -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging catalogs and license questions
On Sun, Mar 17, 2013 at 01:16:38PM +0100, Mattia Verga wrote:
Hello,
I would like to package some additional catalogs for Skychart, but I
have some questions regarding license and to the package process.
First of all, as you can see on skychart download page [1], each
package has more than one catalog inside. All of these catalogs are
known to be public domain, but there's no license file specified
either in catalogs or on original websites of the catalogs [2] [3].
Moreover, original catalog data is reworked by skychart's developer
to fit the main program.
So, questions about license: Should I ask for a license file to be
integrated? Who I should ask for the license file, skychart's
developer or who make the original catalog data?
This should really go to the legal list:
https://admin.fedoraproject.org/mailman/listinfo/legal
Now the technical questions. I suppose I must create new packages
and requesting reviews for each catalog source instead of creating
subpackages inside the main skychart specfile, right? For example,
skychart-data-stars.spec will have stars catalogs and
skychart-data-dso.spec will have dso catalogs, like on the
skychart's website?
But what if inside the stars catalogs package two catalogs have
different licenses?I must create different subpackages, right?
Packaging questions are OK here, but they could also go on the
packaging list:
https://admin.fedoraproject.org/mailman/listinfo/packaging
I will say that I don't know why you'd want to package these
separately. It's more work for you and more work for reviewers. Why
don't you just make them subpackages of the main skychart package?
You can list multiple licenses in the License line, like:
License: GPLv2+ and Public Domain and ...
Final question. Since all these catalogs contain only data that only
requires to be copied in the appropriate directory, there's no need
to build anything. Can the specfile have a void %build section?
Yup. And have an %install which copies everything into the right
place under $RPM_BUILD_ROOT. It'd be something like:
%build
# nothing
%install
mkdir -p $RPM_BUILD_ROOT%{_datadir}/%{name}
install -m 0644 data files ... $RPM_BUILD_ROOT%{_datadir}/%{name}/
Rich.
...well, quite a lot of questions! ;-) I hope someone can clarify me
on this...
Mattia
[1] http://www.ap-i.net/skychart/en/download
[2] http://ad.usno.navy.mil/wds/
[3] http://www.astro.ku.dk/~erik/Tycho-2/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
17.03.2013 16:40, Rex Dieter пишет: Pavel Alexeev wrote: 17.03.2013 05:39, Rex Dieter wrote: As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue with pkg-config in cmake is that it isn't always present on all of the platforms that cmake supports. But it is still probably the way to go on Linux. OK, first-draft patch sent upstream and applied to cmake-2.8.11-0.3.rc1.fc20 As far as I could tell, only one package in fedora is affected, converseen, and confirmed it builds ok now. Thank you very much! Then I push ImageMagick into rawhide. Could you please provide upstream bug url for that to monitor status? The one orion gave earlier in the thread, http://public.kitware.com/Bug/view.php?id=14012 Sorry. Thank you. Meantime ImageMagick landed in rawhide - http://koji.fedoraproject.org/koji/taskinfo?taskID=5132168 -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging catalogs and license questions
Thanks Richard, I will post to the legal list for license questions. And for packaging I will follow your suggestion to build everything as subpackages. Thanks also for the tips about the %install section ;-) Mattia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Am 16.03.2013 19:26, schrieb Rex Dieter: Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. That's not necessarily true. Do our packaging guidelines actually say that anywhere? but WHY are they not saying it clearly? until now UsrMove is a half-baken thing see below - what the hell, /usr/bin/bash is a valid shell [root@fileserver:~]$ system-config-users The value for the SHELL variable was not found the /etc/shells file This incident has been reported [root@fileserver:~]$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin [root@fileserver:~]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/usr/bin/bash signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote: Am 16.03.2013 19:26, schrieb Rex Dieter: Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. That's not necessarily true. Do our packaging guidelines actually say that anywhere? but WHY are they not saying it clearly? until now UsrMove is a half-baken thing No, with UsrMove you have symbol links ll / bin - usr/bin lib - usr/lib lib64 - usr/lib64 sbin - usr/sbin I'm not sure, but I'd say, you must have the symbol links. see below - what the hell, /usr/bin/bash is a valid shell [root@fileserver:~]$ system-config-users The value for the SHELL variable was not found the /etc/shells file This incident has been reported [root@fileserver:~]$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin [root@fileserver:~]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/usr/bin/bash -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Am 17.03.2013 17:12, schrieb Sérgio Basto: On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote: Am 16.03.2013 19:26, schrieb Rex Dieter: Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. That's not necessarily true. Do our packaging guidelines actually say that anywhere? but WHY are they not saying it clearly? until now UsrMove is a half-baken thing No, with UsrMove you have symbol links ll / bin - usr/bin lib - usr/lib lib64 - usr/lib64 sbin - usr/sbin I'm not sure, but I'd say, you must have the symbol links and hwat does this change on the fact that the real location is /usr/sbin/service and /usr/bin/bash see below - what the hell, /usr/bin/bash is a valid shell [root@fileserver:~]$ system-config-users The value for the SHELL variable was not found the /etc/shells file This incident has been reported [root@fileserver:~]$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin [root@fileserver:~]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/usr/bin/bash and if both are valid both have to be valid as shell in ANY context or anything changed to the physical location signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
2013/3/15 Lukáš Nykrýn lnyk...@redhat.com: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. ... rtpproxy Fixed. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
Jared K. Smith wrote: Yes, we heard you the first three times you said that -- and it's still not happening, at least for now. Each of the three times pointed out a new showstopper-level problem with having the 2 forks coexist. It's sad that no amount of technical impossibility is convincing the decision-makers to rethink their dead-end decision. You're not doing yourself any favors by repeating yourself, especially when others on the thread are working through the technical details of how to make things work properly. No amount of technical details is going to make things work PROPERLY. It is provably impossible. At best we are going to have a very ugly and user- unfriendly hackaround. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Debarshi Ray wrote: It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep up, while GNOME did. We cannot push new versions of a library when the users of the library are not ready for it yet (especially one of our release-blocking desktops). So maybe we should just ship code right from the Git masters of all upstreams? No. I also don't think such huge batches can realistically be tested. So piecemeal updates to random packages pushed out at random points in time can be tested better? Yes, of course! It's common QA knowledge that small isolated changes can be tested much better than a huge batch of unrelated changes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Debarshi Ray wrote: It is a bit strange that we freeze before the release, and then move on to a Rawhide like environment where anything can be pushed by anybody at any point in time. And the answer to that is to find a way to drop or relax the release freezes. (I'd suggest to have Bodhi distinguish between 3 targets instead of 2 in pre-release freeze periods: testing, stable (0-day updates) and freeze_override. Then stable would be open for pushes just like after the release, and freeze_override would be controlled as stable is now (and updates pending approval for freeze_override would automatically get pushed to stable in the meantime).) That would help solving a lot of problems, including but not limited to upgrade path issues around release day. We have been working around this by semi-formally co-ordinating all GNOME updates to stable releases. We're doing the same for KDE updates, but for a simple reason: upstream releases the packages at the same time and users are expected to use matching versions, so it wouldn't make sense to split things. Updating a coherent stack that is released by upstream as such in one batch makes a lot of sense, of course. But IMHO, that approach doesn't make much (if any) sense if the upstream releases are not coordinated. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
Jaroslav Reznik wrote: Take Fn-1 - it's almost dead, nearly nobody cares about it anymore (as bugfixes/backporting are costly), and I'd say with our ability to push security updates... It's non sense to have it as supported release. That's a result of the karma system. Most people have just given up trying to push updates to Fn-1 because they never get any karma. The people enthousiastic about giving karma are all running Fn or even Fn+1 (Branched). Even for (sets of) packages which do get tested (e.g. the KDE 4.10.1 update group), one has to send mail to mailing lists to remind people to give karma. Many maintainers are fed up of having to beg for karma each time and so just give up supporting the release. This is the same phenomenon that killed Fedora Legacy. We need to get rid of karma and put power (and trust!) back into the hands of the maintainers, and Fn-1 will florish again! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
drago01 wrote: On Thu, Mar 14, 2013 at 4:17 PM, Kevin Fenzi ke...@scrye.com wrote: It's simple: always do a rawhide build, then do your branched build. Nice way of wasting people's time . :/ Always building in Rawhide first is a good habit people should always get into, plus this change solves a common problem: You never knew whether you could rely on inheritance for a particular package or whether a Rawhide build had already been made. Now you don't need to check that anymore, you know that you always have to build for Rawhide. Really, it makes things much simpler. I, for one, never liked Rawhide inheritance and I think it's a good thing that it was dropped. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
Adam Williamson wrote: In my experience, nearly all even somewhat mature apps need intltool to compile, so it seems a reasonable thing to install by default in the 'development' group. Only GNOME ones. :-) The only file type it handles that's not GNOME/GTK+-specific is .desktop files, and other projects have other ways to handle these (e.g., KDE runs scripts to sync between .desktop and .po files inside its SCMs). IMHO, it should go into a GNOME Software Development or GTK+ Software Development group. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
John Reiser wrote: It seems to me that the private /tmp feature of recent Fedora systems has removed a large percentage of the potential vulnerabilities here. If you cannot see anybody else's /tmp then you cannot create vulnerabilities in /tmp for them, and they cannot create vulnerabilities in /tmp for you. Unfortunately, private /tmp is only enabled by default in Fedora for select services and not for users, mainly because some programs (ab)use /tmp to do sockets to communicate between users. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
13.03.2013 20:24, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-pecl-imagick As you're the owner of this one, if you prefer to update it, see http://svn.php.net/viewvc?view=revisionrevision=329769 Patch incorporated, thanks again. http://koji.fedoraproject.org/koji/taskinfo?taskID=5134433 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
14.03.2013 12:17, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-magickwand Upstream 1.0.9-2 (yes with a -) includes the fix (and the php54 patch) Thanks. It built too - http://koji.fedoraproject.org/koji/taskinfo?taskID=5134893 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction
Welcome. You could start here http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group 16.03.2013 23:14, Niyo Raoul wrote: Greetings, I am a system engineer at ORINUX BURUNDI. I am not experienced in big development project. But i love programming and design. However, i have been using fedora for years and building personal application in c, c++, java, python and assembly. And also i did some scripting with shell. Therefore, i really want to participe in fedora development while learning and sharing my small experience. Please any guidelines or mentor are the most welcome to help. Regards, Raoul NIYO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Kees Cook wrote: AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Who knows what other applications this extremely surprising and incompatible change breaks? (IMHO, even private /tmp is a better solution. It's also an incompatible change, but at least it has semantics a normal user can understand, whereas your solution layers really complicated hidden rules on top of something as basic as file permissions.) I'm with Linus when he says Breaking applications is unacceptable. End of story. It's broken them. Get over it. We aren't ready to enable private /tmp for the same reason, so why is this hack any more acceptable? IMHO the initscripts change should be reverted and we should stick to Linus's defaults. He said no for a reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide / F19 tester PSA: Don't install the F19 fedora-release yet. If you do, don't install a kernel. If you do THAT, don't reboot.
Adam Williamson wrote:
Then nothing would boot at all.
It turns out this is because the release name of Fedora 19 is:
Schrödinger's Cat
with a single quote used as an apostrophe. That release name gets
written into the grub entry for a kernel when you're installing it.
Unfortunately, the lines it goes onto look like this:
menuentry 'Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
Cat)' --class fedora --class gnu-linux --class gnu --class os
$menuentry_id_option
'gnulinux-simple-a749ca4b-0cea-4db0-883d-5c036d89e5c5' {
and:
echo 'Loading Fedora (3.9.0-0.rc2.git0.4.fc20.x86_64) 19 (Schrödinger's
Cat)'
note how both lines use single quotes for quoting. The single quote in
the release name terminates the quotes early, and leaves the rest of the
stuff that's meant to be inside the single quotes as garbage lying
around the config file.
http://xkcd.com/327/ ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Ralf Corsepius wrote: Unwanted/non-user-intended network access = Must be disabled by default and must explicitly activated by user action. [snip] I for one consider the approach of background updating to be a conceptionally broken and flawed design, lacking generality and usability. The same can really be said for ALL cron jobs. They all run some background task the user didn't ask for and periodically consuming his/her resources, usually when it's the least appropriate. In most cases, the rationale is the same as here: optimizing interactive performance by precomputing things in advance, see e.g. locate (mlocate, and slocate before that) and prelink, which have been the subject of user complaints for years. The only reason the complaints have stopped is because the CPU and I/O abuse of those tasks is no longer that noticeable due to Moore's law, but that also makes me wonder whether prelink is still useful at all. (It also reduces security due to its negative impact on address space randomization, and it's nasty in other ways, e.g. RPM has hacks to unprelink on the fly for verification etc. Are a few microseconds at program startup really worth all that?) As for mlocate, I uninstall that on all my machines, the performance impact is just too big, I just perform a recursive search when I need to find something. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. Argh, so UsrMove is STILL biting us in the rear!!! So if your package is in following list, please change your Reguires to /usr/sbin/service. [list of 91 (!) packages] And this is going to be (and remain!) a problem for every single binary. The binary can be found in both /usr/(s)bin and /(s)bin because it's now actually the same directory, but RPM thinks it only lives in either of them. It's a big mess! So who still thinks that UsrMove was a good idea??? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov lemen...@gmail.com wrote: 2013/3/15 Lukáš Nykrýn lnyk...@redhat.com: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. ... rtpproxy Fixed. This is a bad, bad, bad idea for any packages that are going to remain backwards compatible with RHEL, for compilation under EPEL or other backporting. Either switch to systemd, or stick with the old location and allow initscripts to correctly include the old reference. Do not pick a hallfways fix that isn't backwards compatible at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Sun, 2013-03-17 at 17:31 +0100, Reindl Harald wrote: Am 17.03.2013 17:12, schrieb Sérgio Basto: On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote: [root@fileserver:~]$ system-config-users The value for the SHELL variable was not found the /etc/shells file This incident has been reported [root@fileserver:~]$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin [root@fileserver:~]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/usr/bin/bash and if both are valid both have to be valid as shell in ANY context or anything changed to the physical location This looks like a serious bug indeed. Can you share the link to the bug report, for those of us interested in CC-ing ourselves? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/17/2013 11:13 PM, Kevin Kofler wrote: Ralf Corsepius wrote: Unwanted/non-user-intended network access = Must be disabled by default and must explicitly activated by user action. [snip] I for one consider the approach of background updating to be a conceptionally broken and flawed design, lacking generality and usability. The same can really be said for ALL cron jobs. They all run some background task the user didn't ask for and periodically consuming his/her resources, usually when it's the least appropriate. Depends. I see a substantial difference between a cron-job working locally only and cron-jobs triggering dial-outs, or worse, potentially downloading 100s of MBs. That said, I do not have a problem with local-disk only cron-jobs and the like (updatedb, smartd etc.). The performance regressions cron-jobs may cause are a different matter and IMO, entirely independent problem (They are more an inconvenient nuisance, but they do not cause immediate material harm, like dial-outs can do). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) 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-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) 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
File CGI-Compile-0.16.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-Compile: 321640c3a34a1564ffc4574ea4af381d CGI-Compile-0.16.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
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) 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-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) 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
[perl-CGI-Compile] Update to 0.16
commit 8976a2ebc2b5b0a795a32a2e24a81b8c9bed3eac
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Mar 17 14:05:33 2013 +0100
Update to 0.16
.gitignore|1 +
perl-CGI-Compile.spec | 16
sources |2 +-
3 files changed, 10 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 30ab5de..60b8640 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
CGI-Compile-0.11.tar.gz
/CGI-Compile-0.15.tar.gz
+/CGI-Compile-0.16.tar.gz
diff --git a/perl-CGI-Compile.spec b/perl-CGI-Compile.spec
index fb0ecd4..2eda0ed 100644
--- a/perl-CGI-Compile.spec
+++ b/perl-CGI-Compile.spec
@@ -1,9 +1,9 @@
Name: perl-CGI-Compile
Summary:Compile .cgi scripts to a code reference like ModPerl::Registry
-Version:0.15
-Release:6%{?dist}
+Version:0.16
+Release:1%{?dist}
License:GPL+ or Artistic
-Group: Development/Libraries
+
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/CGI-Compile-%{version}.tar.gz
URL:http://search.cpan.org/dist/CGI-Compile
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -17,11 +17,6 @@ BuildRequires: perl(Test::More)
BuildRequires: perl(Test::NoWarnings)
BuildRequires: perl(Test::Requires)
-# obsolete/provide tests subpackage
-# can be removed during F19 development cycle
-Obsoletes: %{name}-tests 0.15-3
-Provides: %{name}-tests = %{version}-%{release}
-
%{?perl_default_filter}
%description
@@ -31,6 +26,8 @@ ready to run on a persistent environment.
%prep
%setup -q -n CGI-Compile-%{version}
+sed -i 's/\r//' t/data_crlf.cgi t/end_crlf.cgi
+
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -53,6 +50,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Sun Mar 17 2013 Emmanuel Seyman emman...@seyman.fr - 0.16-1
+- Update to 0.16
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.15-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 4e2d6e8..61d0607 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2fcf4bc473107130229f4e0a98c756ce CGI-Compile-0.15.tar.gz
+321640c3a34a1564ffc4574ea4af381d CGI-Compile-0.16.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
File Mojolicious-3.90.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: cdc6aac227319f970cb93f1153cca59d Mojolicious-3.90.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-Mojolicious] Update to 3.90
commit 79274082dc88595830dd2eb7fd33a3d43349a5b5
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Mar 17 14:29:34 2013 +0100
Update to 3.90
.gitignore|1 +
perl-Mojolicious.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a8f5174..28bb7ad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -80,3 +80,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-3.85.tar.gz
/Mojolicious-3.87.tar.gz
/Mojolicious-3.89.tar.gz
+/Mojolicious-3.90.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index bbceaad..70aaa5d 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,11 +1,11 @@
Name: perl-Mojolicious
-Version:3.89
+Version:3.90
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
URL:http://mojolicious.org/
-Source0:
http://search.cpan.org/CPAN/authors/id/A/AM/AMS/Mojolicious-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SR/SRI/Mojolicious-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl = 0:5.010001
BuildRequires: perl(Compress::Raw::Zlib)
@@ -58,6 +58,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Mar 17 2013 Emmanuel Seyman emman...@seyman.fr - 3.90-1
+- Update to 3.90
+
* Sun Mar 10 2013 Emmanuel Seyman emman...@seyman.fr - 3.89-1
- Update to 3.89
diff --git a/sources b/sources
index e008158..e6c9365 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d5a1a2fb2bdc3880b741b77265ee Mojolicious-3.89.tar.gz
+cdc6aac227319f970cb93f1153cca59d Mojolicious-3.90.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 863069] amavisd.service fails to start because required default folders are missing
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=863069 --- Comment #3 from ArcFi arcf...@gmail.com --- Confirm, amavisd-new-2.8.0-2.fc18.noarch Workaround: mkdir /run/amavisd restorecon -R -v /run/amavisd chown amavis:amavis /run/amavisd This bug continues from fedora-16. =( -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kfoFg1tIEXa=cc_unsubscribe -- 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
