On Tue, Dec 22, 2009 at 05:03:21PM +0100, Christoph Höger wrote:
Am Dienstag, den 22.12.2009, 15:09 +0100 schrieb Jindrich Novy:
On Tue, Dec 22, 2009 at 11:45:52AM +0100, Christoph Höger wrote:
Hi all,
after texlive 2009 crashed my latex compiling process one day before I
wanted to
On 19/12/09 11:03, Alex Hudson wrote:
The covenant is published as far as I can see here:
No, that's the previous one which was not good enough.
The new one is not yet published.
Correction: it's now published here -
http://www.microsoft.com/interop/msnovellcollab/newmoonlight.mspx
Hi all:
the new version of sextractor in rawhide (2.8.6) will have a CeCILL
license. Previously, sextractor was distributed under GPLv2
Regards
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 12/22/2009 09:07 PM, Seth Vidal wrote:
FWIW - I agree with both jesse and jarod. Official builds are from main
branch. Anything built anywhere else will never be official.
How about scratch builds?
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
FWIW - I agree with both jesse and jarod. Official builds are from main
branch. Anything built anywhere else will never be official.
How about scratch builds?
What about them? Scratch
On 12/23/2009 09:04 PM, Josh Boyer wrote:
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
FWIW - I agree with both jesse and jarod. Official builds are from main
branch. Anything built anywhere else will never be official.
How about
On Dec 23, 2009, at 7:20, Rahul Sundaram sunda...@fedoraproject.org
wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
FWIW - I agree with both jesse and jarod. Official builds are from
main
branch. Anything built anywhere else will never be official.
How about scratch builds?
On Dec 23, 2009, at 7:38, Rahul Sundaram sunda...@fedoraproject.org
wrote:
On 12/23/2009 09:04 PM, Josh Boyer wrote:
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
FWIW - I agree with both jesse and jarod. Official builds are
Hey,
I just had the weirdest thing ever, on Fedora 12
I was working on my desktop, running F-12, KVM and like 10 VM's up and running.
I had clicked on the update button, but since I was using a voip (hardware)
phone had not yet clicked on download updates. I iconified the window to get
rid of
Le Sat, 19 Dec 2009 22:08:45 -0800,
Toshio Kuratomi a.bad...@gmail.com a écrit :
On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote:
Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
Hi,
I'm packaging phatch that provides /usr/bin/phatch, a graphical
Jarod Wilson wrote:
On 12/22/09 2:45 AM, Kevin Kofler wrote:
And as I wrote before, I don't like this at all, it's a regression from
our current workflow
Define our.
Our current workflow = what Fedora's current CVS setup allows.
In my personal opinion, Jesse is spot-on, we should NOT
Alex Hudson wrote:
Correction: it's now published here -
http://www.microsoft.com/interop/msnovellcollab/newmoonlight.mspx
To my untrained eye, it seems to cover Moonlight fully, the termination
clause doesn't work retroactively, it includes coverage for the Mono
portions and it
Peter Robinson wrote:
Some what different in that vala is source code that generates plainly
readable C code. A .dll is a binary library. Its not exactly the same
arguement.
So if I encode a Mono DLL as:
unsigned char dll_data[]={...};
and generate the .dll from that, is that source code???
On 12/23/2009 01:38 PM, Kevin Kofler wrote:
As the patent license is non-Free, Moonlight still has to be considered non-
Free wherever software patents apply. So as far as I can tell, this is not
acceptable for Fedora, sorry. (But of course spot and/or RH Legal will have
the final word.)
Jeffrey Ollie wrote:
That's to be expected, as rpm -i installs a package without removing
the old one. Unless the package is specially designed (like the
kernel) you'll get conflicts. Normally, you'd want to use rpm -U
which will remove the old package before installing the new one.
On 12/23/2009 01:56 PM, Alex Hudson wrote:
On 23/12/09 18:46, Tom spot Callaway wrote:
With that said, this new covenant does NOT change our stance on
Moonlight. It is still not permissible in Fedora.
Can I ask on what grounds? Is the patent license insufficient, or is
there some other
On 23/12/09 18:58, Tom spot Callaway wrote:
On 12/23/2009 01:56 PM, Alex Hudson wrote:
Can I ask on what grounds? Is the patent license insufficient, or is
there some other problem?
It's difficult to fix things if we don't know what's broken.
The most obvious issue is that it does
2009/12/23 Kevin Kofler kevin.kof...@chello.at:
IMHO generated code does not belong into source tarballs at all.
gtkmm tarballs distribute generated C++ source code to avoid using
maintainer tools like mm-common or gmmproc by distro packagers.
and that is for a long long time. Are we going to
On 12/23/2009 02:10 PM, Alex Hudson wrote:
On 23/12/09 18:58, Tom spot Callaway wrote:
On 12/23/2009 01:56 PM, Alex Hudson wrote:
Can I ask on what grounds? Is the patent license insufficient, or is
there some other problem?
It's difficult to fix things if we don't know what's broken.
On 12/24/2009 12:52 AM, Tom spot Callaway wrote:
It grants no patent rights to Distributors, aside from those already
granted to Novell in the previous covenant. What it practically means is
that once you distribute, you stop being considered an End User by
Microsoft, and are no longer
Tom spot Callaway wrote:
(Yes, the irony of a talk on software patents being offered in MP3
format is not lost on me.)
Just think... one more year... one more year...
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote:
The whole problem is that such branches do not exist at all in the new git
setup!
If you get eaten by raptors, you can't expect another maintainer to come
in after you and have to dig around for a private branch to update a
build.
On Tue, Dec 22, 2009 at 10:56:26 -0500,
Clyde E. Kunkel clydekunkel7...@cox.net wrote:
does adding nomodeset to kernel parm line in grub.conf work?
It gets me back to the other problem. So yeah it does seem like we
are seeing the same thing. I update the bug to mention this.
--
Once upon a time, Michael Cronenworth m...@cchtml.com said:
Tom spot Callaway wrote:
(Yes, the irony of a talk on software patents being offered in MP3
format is not lost on me.)
Just think... one more year... one more year...
It doesn't look like that is the case:
On 12/23/09 3:21 PM, Jesse Keating wrote:
On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote:
The whole problem is that such branches do not exist at all in the new git
setup!
If you get eaten by raptors, you can't expect another maintainer to come
in after you and have to dig around
2009/12/21 Bojan Smojver bo...@rexursive.com:
On Sun, 2009-12-20 at 22:21 -0600, Bruno Wolff III wrote:
I didn't see any of the recent previous spec file comments indicate
back ported security fixes. So its unlikely the latest security fixes
are in any earlier version. If you want them now,
On Wed, Dec 23, 2009 at 3:00 PM, Alan Milnes a...@linux.com wrote:
2009/12/23 Alex Hudson fed...@alexhudson.com:
I realise a number of people don't care for Mono-related technologies,
but
it would be sad to see Fedora left out in the cold for this stuff.
Actually it makes me very *happy*
On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote:
Okay, we've definitely got some slight misunderstanding here... :)
I was objecting to Kevin's suggestion that we should be able to build
official packages from branches named ^private-*. But building from a
branch tagged something
I understand the use case, I'm still not super keen on having official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
Surely all previous
On Wed, 2009-12-23 at 14:23 -0800, Roland McGrath wrote:
I understand the use case, I'm still not super keen on having official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real
Rawhide Report writes:
So these huge slew of broken deps (seems like more than 10 packages) for
ghc have been in the rawhide reports for over a week now, is anybody
actively maintaining and/or planning to fix these packages? If not,
please let us know so a provenpackager can fix these, they
to:
http://koji.fedoraproject.org/mash/rawhide-20091223/logs/repodiff
abiword was successfully rebuilt:
abiword-2.8.1-3.fc13
* Mon Dec 21 2009 Peter Robinson pbrobin...@gmail.com - 1:2.8.1-3
- Rebuild against new libwv
but the depcheck shows it still broken:
http
On 12/22/2009 06:36 PM, Ville Skyttä wrote:
On Tuesday 22 December 2009, Jeroen van Meeuwen wrote:
- Use the alternatives system to point to one stack or the other for the
system default stack (think standalone applications).
Not that I'm anywhere near an expert in ruby matters, but I have
On 12/24/2009 05:49 AM, Jeroen van Meeuwen wrote:
Care to explain the term environment-modules for me please?
http://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
- Glen g...@empireenterprises.com wrote:
I want to get a perl module included in the default redhat distro.
How do I go about this?
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
MooseX::Declare.
It's easy enough to install via cpan, though I think getting it into an
official rpm would prove a boon to the perl5 community.
On Dec 23, 2009, at 3:28 AM, Marcela Maslanova wrote:
- Glen g...@empireenterprises.com wrote:
I want to get a perl module included in
A file has been added to the lookaside cache for perl-MailTools:
86a51c5a81a55e555c7a84dfdf6ab270 MailTools-2.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-MailTools/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14613
Modified Files:
.cvsignore perl-MailTools.spec sources
Log Message:
Update to 2.05
Index: .cvsignore
Hello,
Glen wrote:
I want to get a perl module included in the default redhat
distro.
It's easy enough to install via cpan, though I think getting it
into an official rpm would prove a boon to the perl5 community.
using the term redhat distro may be confusing.
If you are speaking
A file has been added to the lookaside cache for perl-Text-FindIndent:
cafaae89fdf3dfeecf7c1ba9ab434c7a Text-FindIndent-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
A file has been added to the lookaside cache for perl-Wx-Perl-ProcessStream:
671f75dd6e30e278eac0a8d8f82bf4d9 Wx-Perl-ProcessStream-0.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv11292
Modified Files:
.cvsignore perl-Wx-Perl-ProcessStream.spec sources
Log Message:
* Wed Dec 23 2009 Marcela Mašláňová mmasl...@redhat.com - 0.22-1
- update
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Wx-Perl-ProcessStream/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12513
Modified Files:
perl-Wx-Perl-ProcessStream.spec
Log Message:
missing BR.
Index: perl-Wx-Perl-ProcessStream.spec
43 matches
Mail list logo
