Re: Getting rid of systemd-sysv-convert?

[Rahul Sundaram]

On 06/21/2013 06:48 PM, Reindl Harald wrote:


Am 22.06.2013 00:39, schrieb Jared K. Smith:

Your logical fallacy here is that the distribution works just like you do.  
I've seen you argue time and time again
in the mailing lists that because *you* do things a certain way, that the 
*distribution* should work that way.  Or
that if you don't like a particular tool, that the distribution shouldn't use 
it.  I don't know how else to say it
other than to come right out and say it directly -- the distribution doesn't 
revolve around you

right, but that does not firbid me to say my opinion
If you had said it once and let it go, it would have been fine but when 
you repeat yourself dozens of times, it is quite obnoxious and doesn't help.


Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 22.06.2013 00:39, schrieb Jared K. Smith:
> Your logical fallacy here is that the distribution works just like you do.  
> I've seen you argue time and time again
> in the mailing lists that because *you* do things a certain way, that the 
> *distribution* should work that way.  Or
> that if you don't like a particular tool, that the distribution shouldn't use 
> it.  I don't know how else to say it
> other than to come right out and say it directly -- the distribution doesn't 
> revolve around you

right, but that does not firbid me to say my opinion

> Now to come back from the theoretical to the case in point -- systemd.  Yes, 
> we *could* have held up the release of
> the entire distribution (for how long?) until every single System-V and 
> upstart style initscript was converted over
> to systemd.  I could argue that doing so might have technically been the 
> right thing for *systemd*, but I cannot
> argue that it's the right thing for the distribution overall

maybe, maybe not

the direction in software development release half ready things is bad and will
continue to be bad and especially in context of opensource it is the worst
because there would be no need for marketing to force releases

> If you think I'm wrong and feel like pressing the issue further, I invite you 
> to open a FESCo ticket and have them
> review the issue again.  But please, don't continue to rant about decisions 
> made in the past without trying to find
> a way to make things better in the future

IMHO point out mistakes made in the past is the first step to prevent make them 
again
if i would follow your logic i would need to shutup at all and accept that it
never happended to learn from mistakes in the past - weel, i have stil the hope
that peo9ple sooner or later start to learn from mistakes and not repeat them



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Jared K. Smith]

On Fri, Jun 21, 2013 at 5:40 PM, Reindl Harald wrote:

> in my life i make descisions and follow them straight
>

If you're one person, it's fairly easy to make a decision and follow it
straight through to completion.  If you're a Linux distribution, it's a bit
harder to make radical shifts -- and heaven only knows that Fedora takes
more radical shifts than many other Linux distributions.

Your logical fallacy here is that the distribution works just like you do.
I've seen you argue time and time again in the mailing lists that because
*you* do things a certain way, that the *distribution* should work that
way.  Or that if you don't like a particular tool, that the distribution
shouldn't use it.  I don't know how else to say it other than to come right
out and say it directly -- the distribution doesn't revolve around you.  It
doesn't revolve around me either, and didn't even revolve around me while I
was the FPL.  It revolves around collective consensus and the authority
delegated to those we elect to FESCo and FAmSCo and to those on the Fedora
Board.

Now to come back from the theoretical to the case in point -- systemd.
Yes, we *could* have held up the release of the entire distribution (for
how long?) until every single System-V and upstart style initscript was
converted over to systemd.  I could argue that doing so might have
technically been the right thing for *systemd*, but I cannot argue that
it's the right thing for the distribution overall.  Fedora is a living
breathing collection of moving parts -- you can't stop the entire process
just to make one tiny portion perfect.  The whole reason we have an
engineering steering committee is so that they can make the tough decisions
on items like this.  You can continue to argue about what should have
happened in the past, but it's not going to change the fact that we've
collectively made a decision to keep rolling Fedora releases without having
everything perfectly converted over to systemd.

If you think I'm wrong and feel like pressing the issue further, I invite
you to open a FESCo ticket and have them review the issue again.  But
please, don't continue to rant about decisions made in the past without
trying to find a way to make things better in the future.  Open source is
about scratching itches -- you can either scratch the itch yourself,
convince someone else to scratch the itch for you, or convince someone else
that it's really them that's itching.  Complaining about an itch you had
two years ago doesn't help relieve the itchy feeling.

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 21.06.2013 23:52, schrieb drago01:
> On Fri, Jun 21, 2013 at 11:40 PM, Reindl Harald  
> wrote:
>> Am 21.06.2013 17:54, schrieb Brendan Long:
>>> On 06/20/2013 05:11 PM, Reindl Harald wrote:
 /etc/init.d/ should be empty, with wrappers or not, on a
 distribution switching to systemd - period
>>>
>>> Why?
>>
>> *why not*
>>
>> is fedora now using systemd or sysv-init?
>> in my life i make descisions and follow them straight
> 
> That's a non argument really. Do the scripts work or not? They do so
> there is no urgent need to convert them asap

with your argumentation *a lot* of replacements in the last few
years had no need to be done because things worked and still
would work fine and it would have saved a lot of trouble

define *urgent*

systemd was introduced with F15, now we have F19 in a foew weeks
these are *four* major upgrades - wehn do *you* think is time
to finish things started with F15?

next year?
in 5 years?
never?
short before the next "drop-in replacment"?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[drago01]

On Sat, Jun 22, 2013 at 12:08 AM, Reindl Harald  wrote:
>
>
> Am 21.06.2013 23:52, schrieb drago01:
>> On Fri, Jun 21, 2013 at 11:40 PM, Reindl Harald  
>> wrote:
>>> Am 21.06.2013 17:54, schrieb Brendan Long:
 On 06/20/2013 05:11 PM, Reindl Harald wrote:
> /etc/init.d/ should be empty, with wrappers or not, on a
> distribution switching to systemd - period

 Why?
>>>
>>> *why not*
>>>
>>> is fedora now using systemd or sysv-init?
>>> in my life i make descisions and follow them straight
>>
>> That's a non argument really. Do the scripts work or not? They do so
>> there is no urgent need to convert them asap
>
> with your argumentation *a lot* of replacements in the last few
> years had no need to be done because things worked and still
> would work fine and it would have saved a lot of trouble

No that's not what I wrote.

> define *urgent*

In this context define is "critical enough to block a release for".

> systemd was introduced with F15, now we have F19 in a foew weeks
> these are *four* major upgrades - wehn do *you* think is time
> to finish things started with F15?

If it is that important to you ... how about sending patches? ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[drago01]

On Fri, Jun 21, 2013 at 11:40 PM, Reindl Harald  wrote:
>
>
> Am 21.06.2013 17:54, schrieb Brendan Long:
>> On 06/20/2013 05:11 PM, Reindl Harald wrote:
>>> /etc/init.d/ should be empty, with wrappers or not, on a
>>> distribution switching to systemd - period
>>
>> Why?
>
> *why not*
>
> is fedora now using systemd or sysv-init?
> in my life i make descisions and follow them straight

That's a non argument really. Do the scripts work or not? They do so
there is no urgent need to convert them asap.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Reindl Harald]

Am 21.06.2013 17:54, schrieb Brendan Long:
> On 06/20/2013 05:11 PM, Reindl Harald wrote:
>> /etc/init.d/ should be empty, with wrappers or not, on a
>> distribution switching to systemd - period
> 
> Why?

*why not*

is fedora now using systemd or sysv-init?
in my life i make descisions and follow them straight



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 19 Final blocker status: fix and karma requests

[Adam Williamson]

Hey folks, time for another F19 Final status update!

We're looking relatively hopeful at this point, but still some work to
be done.

Outstanding blockers


We need fixes for:

https://bugzilla.redhat.com/show_bug.cgi?id=924162 - "A software
selection with dependency errors is allowed to proceed if the dependency
check runs twice" - anaconda team (I know you're working on it)

https://bugzilla.redhat.com/show_bug.cgi?id=958426 - "19 Final TC1
x86_64 Desktop Live is oversized (larger than 1 GB)" - desktop team (I
know you're working on it)

https://bugzilla.redhat.com/show_bug.cgi?id=679486 - "Liveinst doesn't
start if hostname changes" - anaconda / X teams

Karma requests
--

We need karma for these blocker-bug-fixing-updates:

https://admin.fedoraproject.org/updates/anaconda-19.30.9-1.fc19
https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19

We also could do with karma for the following FE bugs, esp. grub2:

https://admin.fedoraproject.org/updates/swell-foop-3.8.1-3.fc19,iagno-3.8.1-3.fc19,gnome-mines-3.8.1-2.fc19,gnome-sudoku-3.8.1-2.fc19
https://admin.fedoraproject.org/updates/grub2-2.00-22.fc19
https://admin.fedoraproject.org/updates/initial-setup-0.3.6-2.fc19
https://admin.fedoraproject.org/updates/PackageKit-0.8.9-5.fc19
https://admin.fedoraproject.org/updates/php-5.5.0-1.fc19
https://admin.fedoraproject.org/updates/lightdm-1.6.0-10.fc19

https://admin.fedoraproject.org/updates/mate-power-manager-1.6.1-3.fc19
(proposed)

anaconda 19.30.9 is in TC6; if that's basically working for you, you can
+1 the update. glib2 is supposed to fix the bug that causes dconf
database corruption on unclean system shutdown: you can +1 it so long as
it doesn't cause any major breakage, but it'd be ideal if people could
verify the fix. The swell-foop etc. update fixes the direct F17->F19
upgrade path; should be testable by installing F17, ensuring gnome-games
is installed, and trying a fedup or yum upgrade with those packages
available. The upgrade should not fail on
https://bugzilla.redhat.com/show_bug.cgi?id=976107 . The grub2 update
should fix editing wrapped lines in the edit mode -
https://bugzilla.redhat.com/show_bug.cgi?id=976643 - that's kind of
important. The initial-setup update fixes a few bugs, just +1 it if TC6
installs other than GNOME work okay and i-s doesn't seem busted. The
PackageKit bug implements the stricter PolicyKit policy requested by
FESCo in https://fedorahosted.org/fesco/ticket/1115 ; you can +1 it so
long as PK stuff isn't broken, but ideally we should verify the policy
behaves as expected. PHP should just be +1ed if it works properly for
normal PHP stuff. lightdm should fix things so shutdown and restart
options are offered by lightdm (which is used by Xfce, MATE, Cinnamon
and Sugar spins). mate-power-manager should fix a bug where MATE was not
suspending on laptop lid close (not accepted as an FE yet, but worth
testing in case it is).

Thanks everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Retiring Prelude IDS

[Steve Grubb]

Hello,

I am going to retire the Prelude Intrusion Detections System in F20. Upstream 
has been dead for over 3 years. The only packages that I know that link 
against it is pads, audit, and suricata. I own all 3 of those packages, so 
this should mostly be a FYI for everyone here.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Fri, 2013-06-21 at 13:17 +0200, Florian Weimer wrote:
> On 06/20/2013 09:13 PM, Dan Williams wrote:
> > nmcli doesn't work unless NM is running, since it talks to NM to do
> > stuff, so it would be incompatible with NM setting things up and
> > quitting.
> 
> It could spawn NetworkManager as a subprocess and use the peer-to-peer 
> D-Bus protocol to talk to it.  I think quite a few other programs do 
> things this way.

True.  NM git master (F20) has done the peer-to-peer thing for a couple
months actually.  But we've previously not allowed NM to auto-spawn for
a number of good reasons, mostly because starting NM can touch stuff
that you may not want touched.  We're hoping to change that by the F20
timeframe, so we could revisit this.

> On the other hand, having NetworkManager available all the time enables 
> things like management tools to use its API to query system status, 
> instead of guessing it from kernel information and heuristic analysis of 
> some files under /etc.

Exactly.  And that's why we want to enhance NetworkManager to make
people *want* to use it instead of turning it off.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Fri, 2013-06-21 at 13:42 +0200, Florian Weimer wrote:
> On 06/20/2013 08:01 PM, Stephen Gallagher wrote:
> > Mind if I ask why you think this way about NetworkManager? The NM
> > currently shipping in Fedora 19 has full support for managing static
> > NICs, as well as bonding, bridging and VLAN support for enterprise
> > use-cases.
> >
> > NetworkManager has historically been perceived as a desktop/laptop
> > tool but in its current incarnation it should be usable for all but
> > the most esoteric enterprise workloads.
> 
> To clarify, this currently only applies to the GUI tool, right?
> 
> I recently hosed my desktop installation and couldn't bring up the VPN 
> from the command line, using nmcli.  The nmcli manual page suggests that 
> feature parity with the GUI tools is not a goal ("It is not meant as a 
> full replacement for nm‐applet or other similar clients but as a 
> complementary utility to those programs."), and the lack of actual 
> device configuration facilities in nmcli reflects that.  In Fedora 19, 
> the referenced nm-settings(5) manual page is missing, too.

We should change that.  Note that you *can* bring up VPN connections
from the command-line if all the secrets are already available (which
means stored in /etc/NetworkManager/system-connections).  It's the
editing UI (which is different for each VPN) and requesting secrets
(which is important for the RH VPN of course) which isn't implemented
for the CLI.  But we plan on doing this in the near future.

Dan

> Even if you end up configuring interfaces the old way under 
> /etc/sysconfig/networking-scripts, NetworkManager still offers the 
> benefit of the centralized configuration parsing.  But on the non-GUI 
> interface, functionality is either well-hidden or still missing.
> 
> -- 
> Florian Weimer / Red Hat Product Security Team


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Lennart Poettering]

On Thu, 20.06.13 15:18, Lennart Poettering (mzerq...@0pointer.de) wrote:

> So, anyone still insists on keeping this around? If not I will file a
> bug against FPC to drop any mention of the tool and remove it from the
> systemd RPMs, and everything will get smaller and simpler and unicorns
> and butterflies will reign!

Since there was no public outcry about the idea of removing it (only one
person opposed, but I think this was mostly confusion about what the
tool does, i.e. the name suggests it would be a converter between sysv
scripts and systemd units, but it totally is not, it just recods
runlevel information before deleting sysv scripts), I wen forward and
filed this ticket to FPC:

https://fedorahosted.org/fpc/ticket/308

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Brendan Long]

On 06/20/2013 05:11 PM, Reindl Harald wrote:
> /etc/init.d/ should be empty, with wrappers or not, on a
> distribution switching to systemd - period

Why?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI: F20 Feature: Migrate to Bluez5

[drago01]

On Fri, Jun 21, 2013 at 5:29 PM, Bastien Nocera  wrote:
> On Fri, 2013-06-21 at 17:16 +0200, Kalev Lember wrote:
>> 2013-05-06 11:13, Peter Robinson skrev:
>> > On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera  wrote:
>> >> Heya,
>> >>
>> >> In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
>> >>
>> >> Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as
>> >> such, management applications and a number of libraries and daemons will
>> >> need to be ported.
>> >>
>> >> For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to
>> >> be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5.
>> >> Packages for BlueZ5 will be available as soon as we figure out how to
>> >> integrate a few downstream features that were in the Fedora packages.
>> >>
>> >> Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
>> >> other applications relying on Bluez4 will need to be ported by their
>> >> respective maintainers.
>> >
>> >
>> > Any analysis to what packages are affected, how many are yet to
>> > support the new API and how hard it will be for them to be ported
>> > over.
>>
>> I took a look to see what the impact would be. I am not a BlueZ expert,
>> so Bastien, please correct me if I am wrong somewhere.
>>
>> BlueZ ships a daemon and provides two main interfaces for applications
>> to use it:
>>
>>  1) libbluetooth shared library
>>
>>  2) org.bluez DBus API
>>
>> The TL;DL version is that in my findings, the only package that still
>> needs porting to bluez 5 is blueman. Others should either just continue
>> working, or need new versions packaged up.
> 
>> The following use the DBus API:
>>
>> blueman [Status: needs porting to 5.x]
>> gnome-bluetooth [Status: ported]
>> libbluedevil[Status: port available in a git branch,
>>  https://git.reviewboard.kde.org/r/108912/]
>> pulseaudio  [Status: ported]
>
> And NetworkManager. There's probably a number of applications that use
> bluez via D-Bus without requiring it as a dependency if the
> functionality isn't the main one, so there's likely going to be other
> impacted packages.
>
> NetworkManager is in the process of being ported.
>
> You're also missing obex-data-server, obsoleted and not ported to BlueZ
> 5, which is used by gnome-user-share (patches are upstream to be ported)
> and gvfs-obexftp (won't be ported).

Why?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up - drop unnecessary calls to libgcrypt when gnutls is used

[Florian Weimer]

On 06/21/2013 05:33 PM, Tomas Mraz wrote:

Due to the gnutls now using nettle as the crypto backend instead of
libgcrypt, it is not necessary anymore to call libgcrypt initialization
in applications and libraries that call gnutls and link to libgcrypt.


Can you drop the libpthread dependency from libgnutls, too?  That would 
speed up programs which use GNUTLS and are not multi-threaded.


I'm attaching a list of packages/files in rawhide (x86_64) which link 
against libgcrypt* and libgnutls* at the same time.


--
Florian Weimer / Red Hat Product Security Team
  nevra  |  
  name 
-+-
 aria2-1.17.0-1.fc20.x86_64  | 
/usr/bin/aria2c
 claws-mail-3.9.2-1.fc20.x86_64  | 
/usr/bin/claws-mail
 claws-mail-plugins-acpi-notifier-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/acpi_notifier.so
 claws-mail-plugins-address-keeper-3.9.2-1.fc20.x86_64   | 
/usr/lib64/claws-mail/plugins/address_keeper.so
 claws-mail-plugins-archive-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/archive.so
 claws-mail-plugins-attachwarner-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/attachwarner.so
 claws-mail-plugins-att-remover-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/att_remover.so
 claws-mail-plugins-bogofilter-3.9.2-1.fc20.x86_64   | 
/usr/lib64/claws-mail/plugins/bogofilter.so
 claws-mail-plugins-bsfilter-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/bsfilter.so
 claws-mail-plugins-clamd-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/clamd.so
 claws-mail-plugins-fancy-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/fancy.so
 claws-mail-plugins-fetchinfo-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/fetchinfo.so
 claws-mail-plugins-gdata-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/gdata.so
 claws-mail-plugins-mailmbox-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/mailmbox.so
 claws-mail-plugins-newmail-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/newmail.so
 claws-mail-plugins-notification-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/notification.so
 claws-mail-plugins-pdf-viewer-3.9.2-1.fc20.x86_64   | 
/usr/lib64/claws-mail/plugins/pdf_viewer.so
 claws-mail-plugins-perl-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/perl.so
 claws-mail-plugins-pgp-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/pgpcore.so
 claws-mail-plugins-pgp-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/pgpinline.so
 claws-mail-plugins-pgp-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/pgpmime.so
 claws-mail-plugins-python-3.9.2-1.fc20.x86_64   | 
/usr/lib64/claws-mail/plugins/python.so
 claws-mail-plugins-rssyl-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/rssyl.so
 claws-mail-plugins-smime-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/smime.so
 claws-mail-plugins-spamassassin-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/spamassassin.so
 claws-mail-plugins-spam-report-3.9.2-1.fc20.x86_64  | 
/usr/lib64/claws-mail/plugins/spamreport.so
 claws-mail-plugins-tnef-3.9.2-1.fc20.x86_64 | 
/usr/lib64/claws-mail/plugins/tnef_parse.so
 claws-mail-plugins-vcalendar-3.9.2-1.fc20.x86_64| 
/usr/lib64/claws-mail/plugins/vcalendar.so
 climm-0.7.1-6.fc19.x86_64   | 
/usr/bin/climm
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/cancel.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/cupstestdsc
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/cupstestppd
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lp.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lpoptions
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lppasswd
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lpq.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lpr.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lprm.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/lpstat.cups
 cups-1:1.7-0.6.b1.fc20.x86_64   | /usr/bin/ppdc
 cups-1:1.7-0.6.b1.fc20.x86_64   | 
/usr/bin/ppdhtml
 cups-1

[Bug 791078] perl-Config-IniFiles should require IO::Scalar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=791078

Paul Howarth  changed:

   What|Removed |Added

 CC||p...@city-fan.org

--- Comment #14 from Paul Howarth  ---
(In reply to Konstantin Ryabitsev from comment #13)
> There is no EL6 version of perl-IO-stringy, so this change breaks
> perl-Config-IniFiles on EL6.

Yes there is; it's in RHEL (optional), and CentOS (see Bug #884802).

-- 
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=eC77HPnwn1&a=cc_unsubscribe
--
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/mailman/listinfo/perl-devel

[Bug 791078] perl-Config-IniFiles should require IO::Scalar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=791078

Konstantin Ryabitsev  changed:

   What|Removed |Added

 CC||mri...@gmail.com

--- Comment #13 from Konstantin Ryabitsev  ---
There is no EL6 version of perl-IO-stringy, so this change breaks
perl-Config-IniFiles on EL6.

-- 
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=H9ck3S22io&a=cc_unsubscribe
--
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/mailman/listinfo/perl-devel

Re: [Fedora QA] #388: Page not found after login to Propose

[Fedora QA]

#388: Page not found after login to Propose
---+-
  Reporter:  kparal|  Owner:  mkrizek
  Type:  defect| Status:  new
  Priority:  major |  Milestone:
 Component:  Blocker bug tracker page  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-

Comment (by tflink):

 That is strange but don't put too much time into figuring it out - one of
 the things that we're going to be doing soon is to rip out the current
 auth and replace it with FAS-OpenID. The current method of raw FAS access
 isn't going to be around for too much longer.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

File System-Command-1.100.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-System-Command:

4174aa91b6f032b97549ba9aec5dc714  System-Command-1.100.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/mailman/listinfo/perl-devel

Heads up - drop unnecessary calls to libgcrypt when gnutls is used

[Tomas Mraz]

Due to the gnutls now using nettle as the crypto backend instead of
libgcrypt, it is not necessary anymore to call libgcrypt initialization
in applications and libraries that call gnutls and link to libgcrypt.

If your application also uses libgcrypt on your own you can also
consider moving it to use gnutls crypto calls as
per /usr/include/gnutls/crypto.h. This way you can avoid having two
crypto implementation backends used in your application simultaneously.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI: F20 Feature: Migrate to Bluez5

[Bastien Nocera]

On Fri, 2013-06-21 at 17:16 +0200, Kalev Lember wrote:
> 2013-05-06 11:13, Peter Robinson skrev:
> > On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera  wrote:
> >> Heya,
> >>
> >> In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
> >>
> >> Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as
> >> such, management applications and a number of libraries and daemons will
> >> need to be ported.
> >>
> >> For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to
> >> be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5.
> >> Packages for BlueZ5 will be available as soon as we figure out how to
> >> integrate a few downstream features that were in the Fedora packages.
> >>
> >> Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
> >> other applications relying on Bluez4 will need to be ported by their
> >> respective maintainers.
> > 
> > 
> > Any analysis to what packages are affected, how many are yet to
> > support the new API and how hard it will be for them to be ported
> > over.
> 
> I took a look to see what the impact would be. I am not a BlueZ expert,
> so Bastien, please correct me if I am wrong somewhere.
> 
> BlueZ ships a daemon and provides two main interfaces for applications
> to use it:
> 
>  1) libbluetooth shared library
> 
>  2) org.bluez DBus API
> 
> The TL;DL version is that in my findings, the only package that still
> needs porting to bluez 5 is blueman. Others should either just continue
> working, or need new versions packaged up.

> The following use the DBus API:
> 
> blueman [Status: needs porting to 5.x]
> gnome-bluetooth [Status: ported]
> libbluedevil[Status: port available in a git branch,
>  https://git.reviewboard.kde.org/r/108912/]
> pulseaudio  [Status: ported]

And NetworkManager. There's probably a number of applications that use
bluez via D-Bus without requiring it as a dependency if the
functionality isn't the main one, so there's likely going to be other
impacted packages.

NetworkManager is in the process of being ported.

You're also missing obex-data-server, obsoleted and not ported to BlueZ
5, which is used by gnome-user-share (patches are upstream to be ported)
and gvfs-obexftp (won't be ported).

Cheers


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Bill Nottingham]

Pavel Simerda (psime...@redhat.com) said: 
> > From: "Chris Adams" 
> > I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> > have run into vendor software (such as the Plesk web hosting control
> > panel) that can't handle it.  I expect if that was the "one true way" in
> > some future version of RHEL, they'd adapt.
> 
> AFAIK with the current kernels, the only difference between aliased and
> non-aliased secondary addresses is Netlink's 'label' attribute.  If you
> want to add an address that would be seen through the alias API, you just
> need to assign it a label.  With libnl3 (used by NetworkManager), this is
> a matter of computing it and assigning it via rtnl_link_set_label(). 
> Currently we don't do that, as this for us this is unnecessary overhead,
> and as there is no known demand for it and also because the new-style
> multiple address API have been available for years.

Yeah - we have support for the label attribute in initscripts for backwards
compatibility with ifconfig/prior configuration, but we use ip/netlink for
all configuration.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI: F20 Feature: Migrate to Bluez5

[Kalev Lember]

2013-05-06 11:13, Peter Robinson skrev:
> On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera  wrote:
>> Heya,
>>
>> In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
>>
>> Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as
>> such, management applications and a number of libraries and daemons will
>> need to be ported.
>>
>> For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to
>> be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5.
>> Packages for BlueZ5 will be available as soon as we figure out how to
>> integrate a few downstream features that were in the Fedora packages.
>>
>> Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
>> other applications relying on Bluez4 will need to be ported by their
>> respective maintainers.
> 
> 
> Any analysis to what packages are affected, how many are yet to
> support the new API and how hard it will be for them to be ported
> over.

I took a look to see what the impact would be. I am not a BlueZ expert,
so Bastien, please correct me if I am wrong somewhere.

BlueZ ships a daemon and provides two main interfaces for applications
to use it:

 1) libbluetooth shared library

 2) org.bluez DBus API

The TL;DL version is that in my findings, the only package that still
needs porting to bluez 5 is blueman. Others should either just continue
working, or need new versions packaged up.


Applications that use the libbluetooth shared library
-

The library ABI hasn't changed and the soname in 5.x is still the same
as was in 4.x: libbluetooth.so.3, so the impact should be minimal.
Everything should be able to continue working without needing even a
simple rebuild.

Affected packages:

$ repoquery -q --whatrequires bluez-libs -s | sort | uniq
amora-1.1-10.fc19.src.rpm
anyremote-6.3.1-1.fc20.src.rpm
asterisk-11.4.0-2.fc20.src.rpm
bluecove-2.1.1-0.5.20101024snap63.fc19.src.rpm
blueman-1.23-6.fc19.src.rpm
bluemodem-0.7-9.fc19.src.rpm
bluez-4.101-6.fc19.src.rpm
bluez-hcidump-2.5-2.fc19.src.rpm
btkbdd-1.3-2.fc19.src.rpm
cwiid-0.6.00-21.20100505gitfadf11e.fc19.src.rpm
dolphin-emu-3.0-12.fc19.src.rpm
fawkes-0.5.0-7.fc20.src.rpm
foxtrotgps-1.1.1-5.fc19.src.rpm
gammu-1.26.1-10.fc19.src.rpm
gnokii-0.6.31-6.fc20.src.rpm
gnome-phone-manager-0.68-10.fc19.src.rpm
gpsd-3.9-1.fc20.src.rpm
gvfs-1.17.2-1.fc20.src.rpm
gypsy-0.9-1.fc20.src.rpm
kismet-0.0.2013.03.R1-1.fc20.src.rpm
libbtctl-0.11.1-13.fc20.src.rpm
libopensync-plugin-irmc-0.22-6.fc19.src.rpm
nxtrc-2.3-7.fc19.src.rpm
obexd-0.46-5.fc20.src.rpm
obex-data-server-0.4.6-5.fc19.src.rpm
obexfs-0.12-6.fc19.src.rpm
obexftp-0.23-13.fc20.src.rpm
openobex-1.5-8.fc19.src.rpm
pilot-link-0.12.5-16.fc20.src.rpm
pulseaudio-4.0-1.fc20.src.rpm
pybluez-0.18-6.fc19.src.rpm
qemu-1.5.0-9.fc20.src.rpm
syncevolution-1.3.99.3-2.fc20.src.rpm
vfrnav-20130510-1.fc20.src.rpm
wiiuse-0.12-8.fc19.src.rpm
xbmc-12.2-3.fc20.src.rpm


Applications that use the org.bluez dbus API


The DBus service is shipped in the 'bluez' package and I assume all the
DBus API consumers have a dep on the 'bluez' package for that:

$ repoquery -q --whatrequires bluez -s | sort | uniq
blueman-1.23-6.fc19.src.rpm
bluemodem-0.7-9.fc19.src.rpm
bluez-4.101-6.fc19.src.rpm
gammu-1.26.1-10.fc19.src.rpm
ganyremote-6.2-1.fc20.src.rpm
gnome-bluetooth-3.8.1-1.fc20.src.rpm
kanyremote-6.2-1.fc20.src.rpm
libbluedevil-1.9.2-4.fc20.src.rpm
pulseaudio-4.0-1.fc20.src.rpm

I took a quick look at all the packages above and the following don't
seem to use the dbus API and have a dep on the 'bluez' package for other
reasons (use command line utilities etc.):

bluemodem
gammu
ganyremote
kanyremote

The following use the DBus API:

blueman [Status: needs porting to 5.x]
gnome-bluetooth [Status: ported]
libbluedevil[Status: port available in a git branch,
 https://git.reviewboard.kde.org/r/108912/]
pulseaudio  [Status: ported]

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> The kernel does not know anything about interfaces which do not
> exist, possibly lacks information about interfaces which are not up,
> and has no concept whatsoever of DNS, DHCP (at least after boot) or
> OpenVPN or settings.

The idea of NM being able to go away is for static configurations, such
as servers, where there are no interfaces that don't exist.  If it
matters, it is up, and there's already plenty of library access to DNS.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/21/2013 03:01 PM, Chris Adams wrote:

Once upon a time, Florian Weimer  said:

On the other hand, having NetworkManager available all the time
enables things like management tools to use its API to query system
status, instead of guessing it from kernel information and heuristic
analysis of some files under /etc.


Current network information is available from the kernel and doesn't
require "guessing".  Why would you code something to talk to some random
daemon API (that may change) when you could talk directly to the source
via the kernel netlink API?


The kernel does not know anything about interfaces which do not exist, 
possibly lacks information about interfaces which are not up, and has no 
concept whatsoever of DNS, DHCP (at least after boot) or OpenVPN or 
settings.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> On the other hand, having NetworkManager available all the time
> enables things like management tools to use its API to query system
> status, instead of guessing it from kernel information and heuristic
> analysis of some files under /etc.

Current network information is available from the kernel and doesn't
require "guessing".  Why would you code something to talk to some random
daemon API (that may change) when you could talk directly to the source
via the kernel netlink API?
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-19 Branched report: 20130621 changes

[Fedora Branched Report]

Compose started at Fri Jun 21 09:15:02 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq
derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod
derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[dsqlite]
dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60
dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit)
[dustmite]
dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[freeipa]
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2
freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 
0:1.3.1.0
[gl3n]
gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60
gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc19.noarch requires python-virtinst
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[nodejs-tilelive]
nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) < 0:0.4
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
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)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[zarafa]
php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64



Broken deps for i386
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg
derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
der

Re: Revisor: still F13 repository!!!

[Bruno Wolff III]

On Fri, Jun 21, 2013 at 14:06:53 +0100,
  Vincenzo Virgilio  wrote:


Installing revisor, it doesn't have anaconda in its dependency.

There is still the bug of creating anconda-runtime directory in /usr/lib and 
the link to anaconda executable.

These are well known problems, it's ok, but repositories are still F13!!!

I'm wondering!!!


Revisor gets almost no attention. Pungi is the official tool for doing builds. 
Probably it would be best for the maintainer to just retire it at this point.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Revisor: still F13 repository!!!

[Vincenzo Virgilio]

Hi!

This week i started working on a new project with Fedora 19beta.

Installing revisor, it doesn't have anaconda in its dependency.

There is still the bug of creating anconda-runtime directory in /usr/lib and 
the link to anaconda executable.

These are well known problems, it's ok, but repositories are still F13!!!

I'm wondering!!!

Best regards,

Vincenzo Virgilio
-- Inviato dal mio cellulare Android con K-9 Mail.-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A need for build triggers & automatic rebuilds

[Florian Weimer]

On 06/21/2013 08:28 AM, Krzysztof Daniel wrote:


OSGI records that there is a file
org.eclipse.jetty.http_9.0.3.v20130506.jar that holds a plugin with
version 9.0.3.v20130506. That version goes at the build time in a couple
of places (including metabundle).


Such exact dependencies are fundamentally broken and do not scale.  We 
cannot rebuild the whole world just for minor (say, security) updates. 
Lying about the version number (so that the new version looks like the 
old one to OSGi) doesn't strike me as a good idea, either, because it 
will confuse developers and other tools.


I tried to bring this up on the Project Jigsaw mailing list a couple of 
years ago, but I'm not sure if I brought across this point.  From my 
point of view, these Java module frameworks refuse to acknowledge that 
there is extensive experience with distro-level release engineering. 
(Basically, exact dependencies and multiple versions of the same code 
might be convenient now, but will seriously hurt you down the road.)



Exact match can't be used at all, because if jetty is updated, then it
will be impossible to install Eclipse.


Well, if it doesn't work with the old version, that's the right thing to do.

I believe Debian relaxes the OSGi-generated dependencies on system 
libraries.  Fedora should do the same thing in its Eclipse packaging.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/20/2013 08:01 PM, Stephen Gallagher wrote:

Mind if I ask why you think this way about NetworkManager? The NM
currently shipping in Fedora 19 has full support for managing static
NICs, as well as bonding, bridging and VLAN support for enterprise
use-cases.

NetworkManager has historically been perceived as a desktop/laptop
tool but in its current incarnation it should be usable for all but
the most esoteric enterprise workloads.


To clarify, this currently only applies to the GUI tool, right?

I recently hosed my desktop installation and couldn't bring up the VPN 
from the command line, using nmcli.  The nmcli manual page suggests that 
feature parity with the GUI tools is not a goal ("It is not meant as a 
full replacement for nm‐applet or other similar clients but as a 
complementary utility to those programs."), and the lack of actual 
device configuration facilities in nmcli reflects that.  In Fedora 19, 
the referenced nm-settings(5) manual page is missing, too.


Even if you end up configuring interfaces the old way under 
/etc/sysconfig/networking-scripts, NetworkManager still offers the 
benefit of the centralized configuration parsing.  But on the non-GUI 
interface, functionality is either well-hidden or still missing.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/20/2013 09:13 PM, Dan Williams wrote:

nmcli doesn't work unless NM is running, since it talks to NM to do
stuff, so it would be incompatible with NM setting things up and
quitting.


It could spawn NetworkManager as a subprocess and use the peer-to-peer 
D-Bus protocol to talk to it.  I think quite a few other programs do 
things this way.


On the other hand, having NetworkManager available all the time enables 
things like management tools to use its API to query system status, 
instead of guessing it from kernel information and heuristic analysis of 
some files under /etc.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Attention F19 users! DO NOT upgrade to Erlang R16B01 if prompted.

[Peter Lemenkov]

2013/6/21 Peter Lemenkov :
> Hello All.
>
> Recent Erlang bugfix release fixed a few issues but added another
> nasty one - actually almost all Erlang application will fail to start.
> I'm working on it. Meanwhile please stay with R16B or downgrade to it.

Fixed erlang-mochiweb:

* https://admin.fedoraproject.org/updates/erlang-mochiweb-2.4.2-2.fc19

--
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Attention F19 users! DO NOT upgrade to Erlang R16B01 if prompted.

[Peter Lemenkov]

2013/6/21 Peter Lemenkov :
> Hello All.
>
> Recent Erlang bugfix release fixed a few issues but added another
> nasty one - actually almost all Erlang application will fail to start.
> I'm working on it. Meanwhile please stay with R16B or downgrade to it.

Fixed couchdb:

* https://admin.fedoraproject.org/updates/couchdb-1.2.2-3.fc19

--
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Attention F19 users! DO NOT upgrade to Erlang R16B01 if prompted.

[Peter Lemenkov]

Hello All.

Recent Erlang bugfix release fixed a few issues but added another
nasty one - actually almost all Erlang application will fail to start.
I'm working on it. Meanwhile please stay with R16B or downgrade to it.

Here are few links for those who's curious:

* http://thread.gmane.org/gmane.comp.lang.erlang.general/68995/focus=69001
* https://issues.apache.org/jira/browse/COUCHDB-1833
* http://thread.gmane.org/gmane.comp.networking.rabbitmq.general/23889
* http://thread.gmane.org/gmane.comp.lang.erlang.general/69019

Sorry for that. I hope to fix everything before next monday.
--
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: headsup ghc-7.6.3 coming soon to rawhide

[Jens Petersen]

> I am planning to start pushing all the version
> updates and rebuilds soon to F20 Rawhide.

This is now done and in record time!
(I think it is first time I managed to rebuild
everything (all 220+ packages modulo xmobar) in under 24 hours.)

So next rawhide report should be normal again I hope. :)

Thanks, Jens
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel