Re: no error handling in Yum any more?

[M. Edward (Ed) Borasky]

I've seen this before - it's probably some network glitch. I fixed it
by killing the yum job, rebooting, running 'yum clean all' and running
a speed test before restarting the yum job.

On Sun, Dec 21, 2014 at 8:59 PM, Felix Miata  wrote:
> I started a yum upgrade process. When it reached 342/784 (@avahi) over half
> an hour ago, the screen writing from the process simply halted. Ps on another
> tty shows Yum is still running. Disk space and RAM are ample. Top shows
> virtually no CPU in use. Nothing seems amis in the tail of /var/log/yum.log.
> How does one find out why nothing is happening?
> --
> "The wise are known for their understanding, and pleasant
> words are persuasive." Proverbs 16:21 (New Living Translation)
>
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
>
> Felix Miata  ***  http://fm.no-ip.com/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Twitter: http://twitter.com/znmeb; OSJourno: Robust Power Tools for
Digital Journalists https://osjourno.com

Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

no error handling in Yum any more?

[Felix Miata]

I started a yum upgrade process. When it reached 342/784 (@avahi) over half
an hour ago, the screen writing from the process simply halted. Ps on another
tty shows Yum is still running. Disk space and RAM are ample. Top shows
virtually no CPU in use. Nothing seems amis in the tail of /var/log/yum.log.
How does one find out why nothing is happening?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why isn't F2FS support in the Kernel?

[Gerald B. Cox]

Yes, I looked at that bug report and the somewhat terse response.  I
thought I'd post here first before I went the bugzilla route.

Based upon the information I discovered tonight it seems a bit puzzling it
isn't included.  Seriously, Ubuntu includes it and we don't?
Google is using it for the Nexus 9?  The "experimental" rationale just
doesn't hold weight - especially since we are allowing for
BTRFS Raid5/6; which is made out to be toxic.  If it's good enough for
Google and ahem:  "Ubuntu" - it's beyond ridiculous we don't have it.


On Sun, Dec 21, 2014 at 7:09 PM, Orion Poplawski 
wrote:

> On 12/21/2014 07:48 PM, Gerald B. Cox wrote:
>
>> I was wanting to play around with F2FS about 6 months ago, found it
>> wasn't yet included in the F20 kernel (even though Fedora packages
>> f2fs-tools?).  I did a quick search and found some comments basically
>> saying it was under heavy development, stay away, etc. etc. so I kinda
>> forgot about it.
>>
>> Today I see an article on Phoronix:
>> http://www.phoronix.com/scan.php?page=news_item&px=MTg3MDQ
>>
>> which wonders why Fedora doesn't ship it.  Then, it says Ubuntu and
>> other distributions are shipping it?  I then find out that the Nexus 9
>> tablet uses it as its default file system...
>>
>> So, Ubuntu and other distributions ship it... Google is using it for
>> their latest tablets, yet Fedora says it isn't ready to ship?
>>
>> Something isn't right.  I thought Fedora was suppose to be on the
>> leading edge.  Is this some sort of political thing with Redhat/Samsung?
>>
>
> Not much info at the old request: https://bugzilla.redhat.com/
> show_bug.cgi?id=972446 but that would be the place to ask I would think.
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why isn't F2FS support in the Kernel?

[Orion Poplawski]

On 12/21/2014 07:48 PM, Gerald B. Cox wrote:

I was wanting to play around with F2FS about 6 months ago, found it
wasn't yet included in the F20 kernel (even though Fedora packages
f2fs-tools?).  I did a quick search and found some comments basically
saying it was under heavy development, stay away, etc. etc. so I kinda
forgot about it.

Today I see an article on Phoronix:
http://www.phoronix.com/scan.php?page=news_item&px=MTg3MDQ

which wonders why Fedora doesn't ship it.  Then, it says Ubuntu and
other distributions are shipping it?  I then find out that the Nexus 9
tablet uses it as its default file system...

So, Ubuntu and other distributions ship it... Google is using it for
their latest tablets, yet Fedora says it isn't ready to ship?

Something isn't right.  I thought Fedora was suppose to be on the
leading edge.  Is this some sort of political thing with Redhat/Samsung?


Not much info at the old request: 
https://bugzilla.redhat.com/show_bug.cgi?id=972446 but that would be the 
place to ask I would think.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Why isn't F2FS support in the Kernel?

[Gerald B. Cox]

I was wanting to play around with F2FS about 6 months ago, found it wasn't
yet included in the F20 kernel (even though Fedora packages f2fs-tools?).
I did a quick search and found some comments basically saying it was under
heavy development, stay away, etc. etc. so I kinda forgot about it.

Today I see an article on Phoronix:
http://www.phoronix.com/scan.php?page=news_item&px=MTg3MDQ

which wonders why Fedora doesn't ship it.  Then, it says Ubuntu and other
distributions are shipping it?  I then find out that the Nexus 9 tablet
uses it as its default file system...

So, Ubuntu and other distributions ship it... Google is using it for their
latest tablets, yet Fedora says it isn't ready to ship?

Something isn't right.  I thought Fedora was suppose to be on the leading
edge.  Is this some sort of political thing with Redhat/Samsung?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] 2014-12-22 @16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2014-12-22
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

I'm sorry - I actually meant to send a mail on Friday asking if folks 
thought we needed a meeting or not, but I forgot! My bad. So instead 
I'll send the announcement just in case. I don't have much in the way 
of agenda topics myself, but I'll show up and see if we have enough 
interest / attendance to go ahead. If you've got a topic that you 
think really needs discussing, please go ahead and throw it in the 
pot, either by replying to this mail or at the start of the meeting. 
Thanks everyone!

== Proposed Agenda Topics ==

1. Previous meeting follow-up
  * adamw to sync with cmurf and look at revising multiboot criteria
2. Nightly testing progress, everyone happy with the approach so far?

3. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: allowing programs to open ports

[Stephen John Smoogen]

On 21 December 2014 at 14:40, Björn Persson  wrote:

> Stephen John Smoogen wrote:
> >On 21 December 2014 at 09:28, Björn Persson 
> >wrote:
> >
> >> Mattia Verga wrote:
> >> >The alternative could be a "open approach" from Firewalld, where an
> >> >application, when it's executed, can inform firewalld that needs to
> >> >open a port, firewalld asks the user if it should grant access to
> >> >the application and then opens the port... but this needs to be
> >> >implemented in the source of every application, it can eventually be
> >> >sponsored to become a standard in the linux world.
> >>
> >> There is already a way for an application to inform the operating
> >> system that it needs to open a port. It's called the Berkeley socket
> >> API, and every program that communicates across a network already
> >> uses it. Why don't you guys patch GlibC's implementations of bind
> >> and connect to notify FirewallD and get it automatically enabled in
> >> every program, instead of requiring every communicating program to
> >> call a second API in addition to the Berkeley socket API?
> >
> >I am expecting because the patch would break other things
>
> What things would it break that wouldn't be broken if every program had
> to call FirewallD on its own?
>
> >and would be
> >something that upstream would not want accept to glibc. With Fedora not
> >wanting to put in patches not accepted by upstream it would be less
> >accepted that firewalld is.
>
> So you think that countless other upstreams would feel compelled to
> accept the patches to always open ports twice, because they want their
> software to work on Fedora, but GlibC is important enough to be able to
> refuse without risk of being dropped from Fedora? Or maybe that GlibC
> can refuse because it's a library and can push the problem up to the
> programs?
>
>
Uhm no. You seem to be wanting a fight over something, and I have no mood
to engage. I hope you have a more pleasant holidays than what your tone
indicates you are currently having.


> --
> Björn Persson
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: allowing programs to open ports

[Björn Persson]

Stephen John Smoogen wrote:
>On 21 December 2014 at 09:28, Björn Persson 
>wrote:
>
>> Mattia Verga wrote:
>> >The alternative could be a "open approach" from Firewalld, where an
>> >application, when it's executed, can inform firewalld that needs to
>> >open a port, firewalld asks the user if it should grant access to
>> >the application and then opens the port... but this needs to be
>> >implemented in the source of every application, it can eventually be
>> >sponsored to become a standard in the linux world.
>>
>> There is already a way for an application to inform the operating
>> system that it needs to open a port. It's called the Berkeley socket
>> API, and every program that communicates across a network already
>> uses it. Why don't you guys patch GlibC's implementations of bind
>> and connect to notify FirewallD and get it automatically enabled in
>> every program, instead of requiring every communicating program to
>> call a second API in addition to the Berkeley socket API?
>
>I am expecting because the patch would break other things

What things would it break that wouldn't be broken if every program had
to call FirewallD on its own?

>and would be
>something that upstream would not want accept to glibc. With Fedora not
>wanting to put in patches not accepted by upstream it would be less
>accepted that firewalld is.

So you think that countless other upstreams would feel compelled to
accept the patches to always open ports twice, because they want their
software to work on Fedora, but GlibC is important enough to be able to
refuse without risk of being dropped from Fedora? Or maybe that GlibC
can refuse because it's a library and can push the problem up to the
programs?

-- 
Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: chromium

[Corey Sheldon]

also the russian fedora pkgs are not the  defaults and even use different
keys and everything.If you need chromium that bad in 21 ( i personally
use chrome 40 on my server 21 instance )  either help spot or use the
russian fedora rpms at thy own risk as they are technically still
experimental .AND pls stop fodding up this ml

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
310.909.7672
www.facebook.com/1stclassmobileshine
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1

mQSuBFSFm3MRDADMQUFvE2zeREEV2+mARfGttXR0HmamD3kJJMdRmGrtvHpEgTjK
cg8ylpkjRTBOl3pWzrEfoxREnS5Ej6BbGbEdGP8cRgpnACkzVirTDtb6JLatzPzh
4xqpuO6st8ATh7/RkLdsK8R5IzjqvkJ+Q99MGZxBr6w0AaP8KMKe32TU5CzQkSMH
hL+sZQlIVa5kiEbsvrYnYVrlvw9YFsHZQ38mxFyg0A4nmt3L+CBFS4LRdaQmsu07
Qr22aeOYdD4fWKkvEtGsy2MtxIOjqljdPk+lBqBiW3qK9J3DfGLQsVBholJFBMvY
S6aLj6ITDOezJ36hHNlpQmPMOQLShIkP3/dlq7Y2xhyLY/hXG83Pw6WF7kRzF7vG
bSqSDlMlmdnRzulnNtAaE4fzNtBR26oKSfMIwX9NUz4U1wFCVrzrOzEvvU2ZvU3k
ZlpyMdm1fCEdXJt/oOWBVa6PH31TTGaYKl8JH2gQ0Z9DixaTmPS56ch3mbRGMqyz
5PzEtzvaM5b3yzMBAN/guLOJVzGKSqHwEMjhfxwDweHiOS50FAXH8i9w8qyVC/sG
4iFlS/yjH6SBm5DEdAKwIbY5EuFexgyVoVDpCZ65VSspDwoiXaHubOfNYUAEkOFJ
o/YShNMInmajsB7kTlt5mlqsJlU/xAMGH6Zv+f5GIi2k8aDryZr+rHPHqs3lyCkb
7t7041z5mfy9/rJE+U20aVvBh/uUtSMm78CvmTcwdasskEpsiZR2ScuGUgc4ahlF
61dvEnCN+5mrTtPUQPISxtLGDUMhhrrw75z7LafPF6gFmMT/RLcnbrB1xPxPwxWR
m5QpfV6qUNmRoGKnGRlyYkBbLwWRsZRSEtgFHUqb8Y3ghG1rKkEh4paFyPOzbGFo
dZOHR4dsTStu41UE1MAdn41VhTjS/mQjI/CQPCIRPscjI64svBjQria3SV0iDqxb
+Z3ACGoHdKaUI5TiJhJkjEWUjOunUfSnhR124mf7uEIG/1sHJoYonPKTtYNy2mlB
ryZs7kZ3u7V3DV4TPMji3UC8sVV2+9HR2g0xxMEXyTA1AEoQeQIK05BthxX/auoM
AKrGRPvY96RfaO9rNSerJGH+7VGpr/O4UxRDytHzRRfDb9PzMjUSspS6DtSMhk1z
lB2+riyDwQ9HqgFk2PLgnj0LE/k9IxXDxtjjMAGAM1iBRJCsQZzoXfphOtZzU1bd
6teOAW2lsT+rp/+BwU7YxSLnEj0eFJgZTMAgNblLLzh3Cu53FNPauxdhacklYjj3
LO3d0CAkcHMA0ny+zXVoQupabgFLsgvVoSLqPqWVgrd5vS8gGWwvc+b4Q9YLWYpK
qwI9tD6Z5poSbQjJPKJLuJfhiQqMgvjeLZGFnTHe9O5s1+dKInW1DhUH6yq61Exj
0grDevF7vyBBEfxkGVeKPyOd7gy7dXMRUwuaQZZ/yd2vbPv8Vbe4ux5TaltFekYc
/F6bPWB2LwGAbxKchl5O9133C4VM6yO9bb0DiMMZFsJIUlIqnkDREgjMA30n2HZ4
Xzg+aho33VMRhzaE+YTZVfmNSZk7VlM4mprFKeBERycOyUNfU0B6hOwtrwrMp6gZ
47Q0Q29yZXkgU2hlbGRvbiAoRmVkb3JhIEtleSkgPHNoZWxkb24uY29yZXlAZ21h
aWwuY29tPoiABBMRCAAoBQJUhZtzAhsjBQkB4TOABgsJCAcDAgYVCAIJCgsEFgID
AQIeAQIXgAAKCRDpWMXWcYv1l0L9APwJ2famE03OlzpOMddQIxsGEnb6cgb4X8ZE
tXNnkfmPZwD9Gt8tXcaLOqiwKjQqyiLRP3SoIqwUAJHe7GciZDZ5A/S5BA0EVIWb
cxAQAK6uQCb9BZLnWUTXZAAKDK0qT2BVOzUBefB3YD5Eixtmdf7mqjxSfs2Mci5D
rGdNZowgA9HnEeIzqg78giit21UlXhqCOt22hj0eO+Q1F401Dr6RFkkN8yQdVI1D
1UePDZQ/zz/fD0miD9KPQxGr6mwGWbn8it5NFHt1EnZMIYkXfS/TJxaMsrGY6Q2F
RLjhQ3f69i0XjqPg1/IFx5C34ds0hw3K47yDTrgqR5pp309FjselYfLkC4z8R6ti
TRbaXMwOhGuk56rEYB7Y6uzdxuQvS1zM/qqqmff3VqjwyCpVgTuqUlpiD8k/e2nq
HB/ZvrOUWgSqT6NKWBn915DlVB5U95jxLFafopI4N12rsEGW7wIgPolXZ2yU8C4S
E5kE84T8ahdHGAP9lHbqPhnA7aO1zuAl6hJB+Dcpt1nbPdqfwWR0FffkUU9kL6Qh
CiV2ZiAx6Eqm8i5pM21aTlYo0RUosK4r0xFTDZ7SR7d7EGjmfO5k+YjoUSlqOvIb
2jNg6+ZD9EFzSEq5QHMViFnMsp1j+nEYiL44GIH4NPnQWCc3/p7vdxje3HTC4eBt
E4Dp4CkTjX4MpiNrUMw57kjahv/nfITsDUcu4WcMc9e0F8GtfIgy/p3XVsXTqdcm
CersMUgFZIbptI/bGwfj713QElkNiah1NGZc52YAmFWO9f4/AAMFD/4mjUWEaW/D
plbV2tyo7w4j9cHT89+uz5R/Q/OOUjY6PhoFfAzfRAiBlOVjGba/IiYig0HJoBW8
r1HDrfO8xHCHCA9NXiBrhCLFnGM+T6m5+5YpMz5jnhv+xvudm0Dg5VxLtcBjo0/j
OUxIHBEcvm0/H3MgABHJc/vTR5n/hNJ6kGRgfgg37qIruE4GOu7BeNABBW+8IIyP
1mXvQl/zIfokAPiDqW9Rmmuj5znOc+UvOX8CcJU/8YQYNIHtCzISkFGtkcz1spET
BL6Bu5WrGbdStHFzoUKpaHQumyaHBBDn0VpJCjiRwf7Gu+LlZ/Wlah4KVo4nhk3k
NsonNqOZjK16UZnrMrdK4VIDLxzCtlrmlmbGLuH8YUmmlxuw0Nt9EiYtpFTiNUQq
Iplu8Me9O9hZ8ZmzlgJ+0tSzlXELOUUOwIgiQs67c9bEn18pHIln4YyrfCvPlhyw
Ke+xXUeGGEXmIrKTjCQrFA9eWs3nPTfTG7xQmGkf93kUZHOJMohDJlpIHQza1uyt
lu2s+s8HXiAHOBh6ZbMloL+Rg4M+w5+eKU2abQCW8QC1v9u3OgKWcZ1jZbYyTCyI
8Y7NQyiE/akAXQiUb1MHIezN7QpzHEpGxDyVr3tEYF26deJ8sVBxzd+m2wSWyFlT
dPyuTxJJFIRCYtK5wpbPhrDlQfwL5riDzIhnBBgRCAAPBQJUhZtzAhsMBQkB4TOA
AAoJEOlYxdZxi/WXW8wA/jWWfofUPZYg3QOquXIR/QDTm/fsQwTx+2vO4nEXRKlq
AP0YOSlkGoCbaeFHgX+RU5lVfHzRyONK5T7RcDTcvJD83A==
=v6Cq
-END PGP PUBLIC KEY BLOCK-





On Sun, Dec 21, 2014 at 4:12 PM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> On Sun, Dec 21, 2014 at 9:03 PM, Oleg Osipov  wrote:
> > On Sun, 21 Dec 2014 00:36:03 +0300, Athmane Madjoudj
> >  wrote:
> >
> >
> >> Chromium is already packaged by a Russian Fedora, check
> >> [1] to enable the repos (hint: use google translate or something
> similar).
> >>
> >> PS. I'm not familiar with Russian Fedora policy, so make sure to check
> if
> >> it does not replace packages from fedora base repos.
> >>
> >> [1] http://ru.fedoracommunity.org/repository
> >>
> >
> > Russian fedora has three repos: free, nonfree and fixes. Only latter one
> > replaces original fedora packages. Chromium is in russianfedora-free, [1]
> > have command to enable it.
> One fix. 4 repos. free, nonfree, fixes and branding.
>
> TL;DR If you will enable free repo it will not change original
> packages from fedora.
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/

Re: chromium

[Igor Gnatenko]

On Sun, Dec 21, 2014 at 9:03 PM, Oleg Osipov  wrote:
> On Sun, 21 Dec 2014 00:36:03 +0300, Athmane Madjoudj
>  wrote:
>
>
>> Chromium is already packaged by a Russian Fedora, check
>> [1] to enable the repos (hint: use google translate or something similar).
>>
>> PS. I'm not familiar with Russian Fedora policy, so make sure to check if
>> it does not replace packages from fedora base repos.
>>
>> [1] http://ru.fedoracommunity.org/repository
>>
>
> Russian fedora has three repos: free, nonfree and fixes. Only latter one
> replaces original fedora packages. Chromium is in russianfedora-free, [1]
> have command to enable it.
One fix. 4 repos. free, nonfree, fixes and branding.

TL;DR If you will enable free repo it will not change original
packages from fedora.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 downloads repository metadata in 3 places!

[Sudhir Khanger]

On Thu, Dec 18, 2014 at 9:04 AM, Kevin Kofler  wrote:
> KDE has the setting in Apper under [Tools icon⌄] "Preferences" in the first
> (selected by default) tab ("General Settings"). It's called "Check for
> updates:", and it's a dropdown list with the options "Hourly", "Daily",
> "Weekly", "Monthly" or "Never". IMHO, that's clearly the right place and UI
> for this setting.

That doesn't differentiate between metered and un-metered connections.
Most people would tether their laptops with their phones via portable
hotspot which is treated as a regular wifi connection.

Currently, the only good option is to disable dnf and PackageKit. Most
folks would not know what's eating their mobile data.

-- 
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60  807F 8C00 45D9 F5EF C394.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trusted apps and trusted networks (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)

[Stephen John Smoogen]

On 21 December 2014 at 09:45, Björn Persson  wrote:

> Mattia Verga wrote:
> >Since I'm not good to write complex sentences in English, here is a
> >schema that explains how I think firewalld should work as I wrote in
> >the previous post.
>
> A "trusted app" to me would mean that I trust that it's secure enough
> to communicate even on *untrusted* networks. I don't usually trust any
>

That is personal semantics versus actual semantics. You define "trusted" as
X, someone defines it as Y. They may or may not overlap which causes all
kinds of arguments over words versus actual usage.

What Mattia is saying is that you set levels of trust for programs or
acceptance (again another overloaded word that will causes arguments over
definitions).

Program A is 'accepted' or 'trusted' or 'fill in your word here' to work on
network A without intervention. If the system is not on that network then
before Program A can have a port open, it needs the user to determine
whether or not that is allowed.
Program B is not 'accepted' in any white list and so the user needs to be
notified.

I think in the end a firstboot or anaconda module on user security settings
should be put in. In places where the environment is preset up, it can be
turned off easily in kickstart or a boot time flag.

User A wants to be notified of all programs opening ports even if he is
going to whitelist them.
User B does not want to be notified and could care less about security.
etc.



> network, but in the rare cases when I do, I'll let any bug-ridden junk
> communicate because I'm confident that there isn't anything on the
> network that will exploit any security holes. If Gnome-user-share (your
> example) can't be trusted on untrusted networks, then including it in a
> "trusted app list" seems very wrong. Since you didn't even give the user
> an option to allow Gnome-user-share to communicate on the untrusted
> network, your list seems more ĺike a list of known defective apps.
>
> --
> Björn Persson
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: allowing programs to open ports (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)

[Stephen John Smoogen]

On 21 December 2014 at 09:28, Björn Persson  wrote:

> Mattia Verga wrote:
> >The alternative could be a "open approach" from Firewalld, where an
> >application, when it's executed, can inform firewalld that needs to
> >open a port, firewalld asks the user if it should grant access to the
> >application and then opens the port... but this needs to be
> >implemented in the source of every application, it can eventually be
> >sponsored to become a standard in the linux world.
>
> There is already a way for an application to inform the operating system
> that it needs to open a port. It's called the Berkeley socket API, and
> every program that communicates across a network already uses it. Why
> don't you guys patch GlibC's implementations of bind and connect to
> notify FirewallD and get it automatically enabled in every program,
> instead of requiring every communicating program to call a second API in
> addition to the Berkeley socket API?
>
>
I am expecting because the patch would break other things and would be
something that upstream would not want accept to glibc. With Fedora not
wanting to put in patches not accepted by upstream it would be less
accepted that firewalld is.


> Alternatively, cut out the packet filter and have GlibC ask the user
> whether the call to bind or connect shall be allowed to succeed (or
> automatically allow or deny the call if so configured). This has the
> advantage that the program is informed that it's not allowed to
> communicate.
>
> --
> Björn Persson
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: chromium

[Oleg Osipov]

On Sun, 21 Dec 2014 00:36:03 +0300, Athmane Madjoudj  
 wrote:




Chromium is already packaged by a Russian Fedora, check
[1] to enable the repos (hint: use google translate or something  
similar).


PS. I'm not familiar with Russian Fedora policy, so make sure to check if
it does not replace packages from fedora base repos.

[1] http://ru.fedoracommunity.org/repository



Russian fedora has three repos: free, nonfree and fixes. Only latter one  
replaces original fedora packages. Chromium is in russianfedora-free, [1]  
have command to enable it.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

trusted apps and trusted networks (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)

[Björn Persson]

Mattia Verga wrote:
>Since I'm not good to write complex sentences in English, here is a 
>schema that explains how I think firewalld should work as I wrote in
>the previous post.

A "trusted app" to me would mean that I trust that it's secure enough
to communicate even on *untrusted* networks. I don't usually trust any
network, but in the rare cases when I do, I'll let any bug-ridden junk
communicate because I'm confident that there isn't anything on the
network that will exploit any security holes. If Gnome-user-share (your
example) can't be trusted on untrusted networks, then including it in a
"trusted app list" seems very wrong. Since you didn't even give the user
an option to allow Gnome-user-share to communicate on the untrusted
network, your list seems more ĺike a list of known defective apps.

-- 
Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

allowing programs to open ports (was: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break)

[Björn Persson]

Mattia Verga wrote:
>The alternative could be a "open approach" from Firewalld, where an 
>application, when it's executed, can inform firewalld that needs to
>open a port, firewalld asks the user if it should grant access to the 
>application and then opens the port... but this needs to be
>implemented in the source of every application, it can eventually be
>sponsored to become a standard in the linux world.

There is already a way for an application to inform the operating system
that it needs to open a port. It's called the Berkeley socket API, and
every program that communicates across a network already uses it. Why
don't you guys patch GlibC's implementations of bind and connect to
notify FirewallD and get it automatically enabled in every program,
instead of requiring every communicating program to call a second API in
addition to the Berkeley socket API?

Alternatively, cut out the packet filter and have GlibC ask the user
whether the call to bind or connect shall be allowed to succeed (or
automatically allow or deny the call if so configured). This has the
advantage that the program is informed that it's not allowed to
communicate.

-- 
Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: kvm: vcpu unhandled rdmsr:

[poma]

...
> "Phenom" doesn't exist in the /usr/share/libvirt/cpu_map.xml, therefore 
> libvirt? chooses probably the closest to specification, 
> and it is always Opteron_G3, even if cpu mode='host-passthrough'.
> Is this the culprit, dunno, but both systems do have a tendency to "hose".
> And this is nothing new, it is ongoing long since.
> 

To correct myself, there is "phenom" in the 'cpu_map.xml', although this is not 
the second generation.
However the question is whether it is at all important to libvirt/qemu given 
the limited number of used properties.

Also, this can be surpassed by cpu mode='host-passthrough' although even that 
is not fully applied, probably related to the limitation of the qemu BIOS i.e. 
due to the lack of susceptibility to "subtle" differences in socket - core 
relation.

But even that did not help.

Finally, one small thing helped, and this is not the daisy.
3.18.1-2.fc22.x86_64



Someone once said, the Earth is round.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fwd: Re: Cinnamon Spin

[Thomas Gilliard]

I had to add this to get printers to work:
yumex:
 system-config-printer
 system-config-printer-applet

add to .ks?

Tom Gilliard
satellit on #fedora-mate

leigh123linux:
https://git.fedorahosted.org/cgit/comps.git/commit/?id=78dda7b6b8e6d068bfcbdc9f787633e248dc7810



 Forwarded Message 
Subject:Re: Cinnamon Spin
Date:   Sat, 20 Dec 2014 22:19:59 -0500
From:   Dan Book 
Reply-To: 	Development discussions related to Fedora 

To: 	Development discussions related to Fedora 





On Sun, Dec 21, 2014 at 1:25 PM, Thomas Gilliard > wrote:



   On 12/20/2014 8:35 AM, Dan Book wrote:

Hello,
I have put together a basic Cinnamon Live spin, and was wondering
if this is something people would like to see become official.
It's not ready for submission quite yet, there is a bit of a hack
to change the default gtk-theme to Zukitwo, as the Adwaita
gtk-theme messes up title-bar and desktop icon colors (something
that should probably be fixed upstream, this happens for any
Cinnamon install by default in F21). I'm not a Fedora packager nor
do I have a whole lot of time to put into this, but I am willing
to update and maintain the spin as necessary.

I have the kickstart files in this github repo:
https://github.com/Grinnz/spin-kickstart-cinnamon
And resulting images, which I have briefly tested and installed in
a VM:
https://grinnz.com/public/spins-cinnamon/

I added a skeleton wiki page as well:
https://fedoraproject.org/wiki/Cinnamon_Spin

-Dan Book



   I successfully installed the cinnamon x86_64.iso via f21
   liveusb-creator with the (dd) option [1] and installed it to Bare
   metal from the USB.

   Thanks for this build  I hope it becomes a spin.

   I included links to your build here:
   [1] http://wiki.sugarlabs.org/go/Fedora_22#liveusb-creator

   NOTE:
   Install error anaconda 21.48.21-1  (liveinst)
   **(anaconda:2201) : Warning **: Binding 'Print' failed!
 repeated many times in terminal.

 menu/administration/Fedora Release Notes has 2 entries (both work)

   Tom Gilliard
   satellit
   #fedora-qa  freenode IRC


Thank you for the feedback. I will look into these, but I don't know 
much about anaconda.


-Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20141221 changes

[Fedora Rawhide Report]

Compose started at Sun Dec 21 05:15:02 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6
[boswars]
boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[ember]
ember-0.7.2-2.fc22.i686 requires libtolua++-5.1.so
[fawkes]
fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
[gcc-python-plugin]
gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
[glances]
glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0
[google-roboto-fonts]
google-roboto-condensed-fonts-1.2-6.fc22.noarch requires 
google-roboto-common = 0:1.2-6.fc22
[gtatool]
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libofstd.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires liboflog.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg8.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg16.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg12.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmjpeg.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmimgle.so.3.6
gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmdata.so.3.6
[guacamole-server]
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2
libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2
[nodejs-astral]
nodejs-astral-0.1.0-2.fc22.noarch requires npm(clone) < 0:0.2
[nwchem]
nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1
[pam_mapi]
pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0
[python-selenium]
python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib
[shogun]
shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires 
shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22
[stratagus]
stratagus-2.2.7-4.fc22.i686 requires libtolua++-5.1.so
[uwsgi]
uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so
uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so
[vfrnav]
vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16
vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16



Broken deps for x86_64
--
[3Depict]
3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit)
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libofstd.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires liboflog.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg8.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg16.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg12.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmnet.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmjpeg.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires 
libdcmimgle.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires 
libdcmimage.so.3.6()(64bit)
aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmdata.so.3.6()(64b

Re: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

[Mattia Verga]

Since I'm not good to write complex sentences in English, here is a 
schema that explains how I think firewalld should work as I wrote in the 
previous post.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

[Mattia Verga]

Il 20/12/2014 23:32, Michael Catanzaro ha scritto:

On Sat, 2014-12-20 at 22:24 +0100, Reindl Harald wrote:

you completly ignored the following paragraph, my guess is because
"ask
the user" is considered harmful by GNOME upstream

Well I read it, but yes, I do think that ask the user is harmful. We
need to get out of the business of training users to click through
security prompts. You and I will have to agree to disagree on this.

Well, at work I use Windows 7 and when I have to set up a FTP server I 
must open the firewall settings and manually set it to allow incoming 
connections to the program (not to FTP port, so the program can open up 
all ports it wants). That's really much more complex than clicking a 
security prompt.


If the problem is file sharing, and specifically gnome-user-share, I 
think firewalld can inlude a "trusted app" list: if a user enables file 
sharing he's aware of doing that, so there's no need that firewalld asks 
him again if it's ok for gnome-user-share to open any port. This is also 
the way how Windows 7 works for file sharing, with three security levels 
for this trusted app list in case you're on a public network or home or 
at work.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct