Am 23.01.2015 um 19:26 schrieb Dan Winship:
On 01/23/2015 10:53 AM, Reindl Harald wrote:
on servers and static machines you don't need any dynamic network
configuration
which is why NM in F22 will have a "configure-and-quit" mode for such
machines
which is still no valid reason to reconfig
- Original Message -
> 2015-01-21 11:49 GMT+01:00 Nikos Mavrogiannopoulos :
> >
> > Step 6: ... If the proposed package is not reviewed for 2 months, the
> > package must be reviewed by the submitter, and a git module with the
> > master branch will be approved.
> I share your concern about
On 01/24/2015 12:32 AM, Kevin Kofler wrote:
In many Free Software projects (e.g., GCC, KDE, etc.), the people who are
allowed to approve other people's commits can also approve their own.
This is not entirely true. GCC and related projects apply a pretty
complex peer review process, with defi
Compose started at Sat Jan 24 05:15:03 UTC 2015
New package: gnome-builder-3.15.4.1-1.fc22
IDE for writing GNOME-based software
New package: perl-Crypt-Random-TESHA2-0.01-1.fc22
Random numbers using timer/schedule entropy
New package: python-sep-0.2.0-1.fc22
A file has been added to the lookaside cache for perl-MooX-Options:
cd2b948ae1c6f29ffc2739a99abe11d4 MooX-Options-4.015.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/ma
https://bugzilla.redhat.com/show_bug.cgi?id=1184825
--- Comment #4 from Fedora Update System ---
perl-Date-Easter-1.22-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Date-Easter-1.22-1.fc21
--
You are receiving this mail because:
You are on
Summary of changes:
3fbaa56... Generate warning when missing required params (*)
(*) 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-de...@lists.fedoraproject.org
https
https://bugzilla.redhat.com/show_bug.cgi?id=1184825
--- Comment #2 from Fedora Update System ---
perl-Date-Easter-1.22-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/perl-Date-Easter-1.22-1.el7
--
You are receiving this mail because:
You are o
I notice that Debian recently [since July 2014] started to recommend
that packagers run autoreconf on build. Their reasons are given here
and seem to be good ones:
https://wiki.debian.org/Autoreconf
In the interests of fairness I can think of two drawbacks too:
- newer versions of (especially
- Original Message -
> I think the last bullet point here is the important part. I understand
> the disposition for a technical solution, but someone that just drops
> their package in - even after two months - isn't really getting a sense
> of community out of the experience. The proces
https://bugzilla.redhat.com/show_bug.cgi?id=1142983
--- Comment #1 from Fedora Update System ---
perl-WWW-Shorten-3.06-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-WWW-Shorten-3.06-1.fc20
--
You are receiving this mail because:
You are on
Kamil Paral wrote:
> So, enforcing upgrade path for stable releases sounds good. But when we
> add development releases into the mix, we need to break upgrade path in
> certain cases. And we probably need to come up with a different solution
> to ensure you can correctly upgrade to it on the releas
On Friday, January 23, 2015 08:44:03 AM Andrew Lutomirski wrote:
> $ sandbox -X xterm
> [nothing happens]
It made me install selinux-policy-sandbox and seunshare. I am able to run
Firefox under sandbox without any problem. I am running Fedora 21 KDE.
--
Regards,
Sudhir Khanger,
sudhirkhanger.co
> "PT" == Pete Travis writes:
PT> Maybe some list or other communication channel that's more clearly
PT> for packaging issues - I'm told devel@ can be intimidating - would
PT> help, but I'm not really suggesting anything specific.
Just to be sure, you do know about packag...@lists.fedoraproj
On Fri, 23 Jan 2015, Kevin Fenzi wrote:
> There's one issue we are looking into to be aware of, builds now give:
> SysCallError: (-1, 'Unexpected EOF')
> instead of watching the build you just started. The build is running
> fine and you can follow it on the web interface. Hopefully we will push
>
Announcing the creation of a new nightly release validation test event
for Fedora 22 Rawhide 20150124. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
On 01/24/2015 03:14 PM, Richard W.M. Jones wrote:
I notice that Debian recently [since July 2014] started to recommend
that packagers run autoreconf on build. Their reasons are given here
and seem to be good ones:
https://wiki.debian.org/Autoreconf
In the interests of fairness I can think of
On Sat, 24 Jan 2015 19:42:20 +0100, Ralf Corsepius wrote:
> In many other cases autoreconf can cause subtile and hard to find
> issues. In complex cases, it doesn't work at all.
Especially the former can be troublesome if they don't cause a build
to fail. For example, it can lead to issues such
On Sat, 2015-01-24 at 17:42 +0100, Kevin Kofler wrote:
> Kamil Paral wrote:
> > So, enforcing upgrade path for stable releases sounds good. But
> > when we add development releases into the mix, we need to break
> > upgrade path in certain cases. And we probably need to come up
> > with a differ
Ralf Corsepius wrote:
> This is not entirely true. GCC and related projects apply a pretty
> complex peer review process, with defined roles and privileges. (Cf. the
> file MAINTAINERS in GCC's sourcetree for details).
>
> Somewhat over-simplified the process condenses into "All proposed
> changes
On Sat, 2015-01-24 at 11:05 -0800, Adam Williamson wrote:
>
> With a change along those lines, I think we could plausibly look at
> hard enforcement of the upgrade path, and it would be a good
> improvement. It may be necessary to have *some* kind of override
> mechanism for the case where we h
On Sat, Jan 24, 2015 at 07:42:20PM +0100, Ralf Corsepius wrote:
> On 01/24/2015 03:14 PM, Richard W.M. Jones wrote:
> >
> >I notice that Debian recently [since July 2014] started to recommend
> >that packagers run autoreconf on build. Their reasons are given here
> >and seem to be good ones:
> >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 24 Jan 2015 11:05:52 -0800
Adam Williamson wrote:
> On Sat, 2015-01-24 at 17:42 +0100, Kevin Kofler wrote:
> > Kamil Paral wrote:
> > > So, enforcing upgrade path for stable releases sounds good. But
> > > when we add development releases in
On Sat, 2015-01-24 at 16:11 -0600, Dennis Gilmore wrote:
> > With a change along those lines, I think we could plausibly look
> > at hard enforcement of the upgrade path, and it would be a good
> > improvement. It may be necessary to have *some* kind of override
> > mechanism for the case where
On Sat, 24 Jan 2015 14:36:43 +0100
Robert Scheck wrote:
> On Fri, 23 Jan 2015, Kevin Fenzi wrote:
> > There's one issue we are looking into to be aware of, builds now
> > give: SysCallError: (-1, 'Unexpected EOF')
> > instead of watching the build you just started. The build is running
> > fine a
On Sat, Jan 24, 2015 at 11:05:52 -0800,
Adam Williamson wrote:
Someone proposed that using the 'updates' repository during the
Branched period could help solve quite a few things here, and I think
that's an interesting idea.
The other thing it fixes is packages dgowing up as orphaned when th
I'm trying to do the following:
1) add the smi2021 driver for EasyCap Somagic usb frame grabbers into the
kernel tree
2) compile the kernel with smi2021 as a module
3) build the rpm.
I got the driver from Jon Arne Jorgensen's kernel branch on github:
https://github.com/jonjonarnearne/smi2021
t
On Sun, 2015-01-25 at 06:50 +, Amadeus W.M. wrote:
> I'm trying to do the following:
>
> 1) add the smi2021 driver for EasyCap Somagic usb frame grabbers
> into the
> kernel tree
> 2) compile the kernel with smi2021 as a module
> 3) build the rpm.
>
> I got the driver from Jon Arne Jorgensen
28 matches
Mail list logo