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
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
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,
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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,
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
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,
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
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
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
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
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
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
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-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
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
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
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-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
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(+),
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
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
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. =(
--
38 matches
Mail list logo
