Re: [GSoC'15] Btrfs content-based-storage mode

[harshad shirwadkar]

I have submitted a proposal to the Fedora Project. Please find it here:
http://harshadjs.github.io/2015/03/27/Fedora-BTRFS-Content-Storage-Mode/

I hope that a mentor finds me and we could kick-start the development of
content-based-storage mode for BTRFS, this summer!

Cheers,
Harshad.

On Thu, Mar 26, 2015 at 10:30 PM, harshad shirwadkar <
harshadshirwad...@gmail.com> wrote:

> Thanks, and I am on top of it. Will post here, once I upload it to Google
> Melange.
>
> - Harshad.
> On Thu, Mar 26, 2015 at 10:05 PM, Itamar Reis Peixoto <
> ita...@ispbrasil.com.br> wrote:
>
>>
>> On Mar 24, 2015 10:04 PM, "harshad shirwadkar" <
>> harshadshirwad...@gmail.com> wrote:
>> >
>> > Hello all,
>> >
>> > I am a CS graduate student at Carnegie Mellon University, and past
>> contributor to the Fedora Project via Google Summer of Code 2011.
>> >
>> > For my research, I would like to have btrfs with content based storage
>> option. This idea is also listed on Btrfs ideas page (
>> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Content_based_storage
>> ).
>> > I would like to implement that as a Google summer of code 2015 project.
>> However, I have not found any mentors for that idea yet. Are any of the
>> Btrfs developers interested in mentoring the project?
>> >
>> > Here is my brief background:
>> > As an undergraduate student, I worked on Ext4 snapshot project (
>> http://lwn.net/Articles/442078/). After that, I implemented snapshot
>> revert function for Ext4 snapshots as a GSoC 2011 project with Fedora.
>> Also, I have worked on Atheros based WiFi drivers for 3 years at a WiFi
>> startup. So, I do have a good Linux kernel programming background.
>> >
>> > --
>> > Thanks and Regards,
>> > Harshad Shirwadkar.
>> >
>> > --
>> > devel mailing list
>>
>> submit your proposal via google-melange right now
>>
>> --
>> 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: Pushing the extra AppData files into Rawhide

[Christopher Meng]

Thank you, I've received the notifications.
-- 
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: A proposal for Fedora updates

[Stephen John Smoogen]

On 26 March 2015 at 17:28, Bojan Smojver  wrote:

> Kevin Fenzi  scrye.com> writes:
>
> > If you wish to test something before it's fully pushed to testing, you
> > can download it directly from the buildsystem via the web interface,
> > koji command line or bodhi client command line.
>
> I am fully aware of that. I'm making a different point entirely here.
>
> Imagine a regular Fedora user - the one that has no idea about koji. This
> regular user wants to contribute by testing packages as they are built.
> This
> user is willing to trust a lower quality key in his/her Software (or
> whatever is the current fashion) manager to get the latest stuff, hot off
> the presses.
>
> And yet, such a user would have no idea new packages were available and
> would have a hard time (relatively speaking) getting them. So, I'm
> suggesting we create a "fastrack" for Fedora, so that more people can do
> this and easier. It would be totally optional etc.
>
>

Here is the problems I see with this analogy:

1) Most regular users just want to have a system which allows them to surf
the web, play some games of solitaire, and possibly read email (if it isn't
on the web). This is what the majority of people who use computers want to
do.. if the user wants to start testing things.. he is already not a
regular user.

2) This user who wants to test things is going to need to know a lot of
things which having a faster test system isn't going to fix.
A. They need to know how to test the software (oh look it installed.. now
what do I do?)
B. They need to know where to report that the software is working or not.
C. They need to know how to get help and/or backout the problem if the
software doesn't work.

There are probably other things we need them to know if we want any quicker
testing process. And working on them would actually be a lot less work than
trying to get a fastertrack repo to deal with occasional 2 day delays in
pushing to updates-testing.



> --
> Bojan
>
> --
> 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: Heads up - openssh 6.8 coming to F22

[Chris Adams]

Once upon a time, Nico Kadel-Garcia  said:
> Also, heads up on OpenSSH releases: they're planning to disable ssh-1
> compilation by default in a near future release, so the maintainer at
> Fedora will need to decide whether to manually enable it.

Please don't disable it in the client; I use SSH to connect to some old
network equipment now and then, and it (regrettably) only supports the
SSH1 protocol.  I have no problem with it being turned off in the
server, but my only alternative for this gear is to re-enable telnet
(SSH1 is more secure than that).
-- 
Chris Adams 
-- 
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: Heads up - openssh 6.8 coming to F22

[Nico Kadel-Garcia]

On Thu, Mar 26, 2015 at 10:21 AM, Jakub Jelen  wrote:
> Hi all,
>
> I know that it is quite late in F22 schedule and freeze is coming, but we
> decided to push recent upstream version into F22 before beta freeze to keep
> up with upstream.
> I spent some time with testing various use cases with our downstream patches
> and I would like to point out that I did my best. It works fine from my
> point of view. Despite of that I would like to ask you, if you could also
> try your use cases and playing around with ssh* tools and if something would
> break, please report back to me.

Also, heads up on OpenSSH releases: they're planning to disable ssh-1
compilation by default in a near future release, so the maintainer at
Fedora will need to decide whether to manually 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

Re: [GSoC'15] Btrfs content-based-storage mode

[harshad shirwadkar]

Thanks, and I am on top of it. Will post here, once I upload it to Google
Melange.

- Harshad.
On Thu, Mar 26, 2015 at 10:05 PM, Itamar Reis Peixoto <
ita...@ispbrasil.com.br> wrote:

>
> On Mar 24, 2015 10:04 PM, "harshad shirwadkar" <
> harshadshirwad...@gmail.com> wrote:
> >
> > Hello all,
> >
> > I am a CS graduate student at Carnegie Mellon University, and past
> contributor to the Fedora Project via Google Summer of Code 2011.
> >
> > For my research, I would like to have btrfs with content based storage
> option. This idea is also listed on Btrfs ideas page (
> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Content_based_storage
> ).
> > I would like to implement that as a Google summer of code 2015 project.
> However, I have not found any mentors for that idea yet. Are any of the
> Btrfs developers interested in mentoring the project?
> >
> > Here is my brief background:
> > As an undergraduate student, I worked on Ext4 snapshot project (
> http://lwn.net/Articles/442078/). After that, I implemented snapshot
> revert function for Ext4 snapshots as a GSoC 2011 project with Fedora.
> Also, I have worked on Atheros based WiFi drivers for 3 years at a WiFi
> startup. So, I do have a good Linux kernel programming background.
> >
> > --
> > Thanks and Regards,
> > Harshad Shirwadkar.
> >
> > --
> > devel mailing list
>
> submit your proposal via google-melange right now
>
> --
> 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: A proposal for Fedora updates

[M. Edward (Ed) Borasky]

On Thu, Mar 26, 2015 at 4:55 PM, Bojan Smojver  wrote:
> Maybe I'm misunderstanding how things work, but I think every package in
> updates-testing is signed by a human, on an "offline" machine (i.e. someone
> has to walk the RPM to it using physical media, sign it and then bring it
> back and upload it), which may be causing some of these delays. So, I was
> thinking of a more relaxed signing key, which would used directly by the
> build system after people build the packages. Virus and malware scanning at
> this point would be useful, of course, but would not catch everything -
> that's for sure.
>
> PS. Apologies if the above is misinformation. Going from memory here, from
> the days of that Fedora compromise a few years ago.
>
> --
> Bojan

Either way I'd still probably do it - when I ran Debian and Gentoo I
ran "testing" and rarely had to reinstall. I guess the Debian analogue
would be "sid?" I guess it would be a tradeoff between the new repo
and just running Rawhide, though.

-- 
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists

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

Re: [GSoC'15] Btrfs content-based-storage mode

[Itamar Reis Peixoto]

On Mar 24, 2015 10:04 PM, "harshad shirwadkar" 
wrote:
>
> Hello all,
>
> I am a CS graduate student at Carnegie Mellon University, and past
contributor to the Fedora Project via Google Summer of Code 2011.
>
> For my research, I would like to have btrfs with content based storage
option. This idea is also listed on Btrfs ideas page (
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Content_based_storage
).
> I would like to implement that as a Google summer of code 2015 project.
However, I have not found any mentors for that idea yet. Are any of the
Btrfs developers interested in mentoring the project?
>
> Here is my brief background:
> As an undergraduate student, I worked on Ext4 snapshot project (
http://lwn.net/Articles/442078/). After that, I implemented snapshot revert
function for Ext4 snapshots as a GSoC 2011 project with Fedora. Also, I
have worked on Atheros based WiFi drivers for 3 years at a WiFi startup.
So, I do have a good Linux kernel programming background.
>
> --
> Thanks and Regards,
> Harshad Shirwadkar.
>
> --
> devel mailing list

submit your proposal via google-melange right now
-- 
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] Fedora 22 Beta Test Compose 5 (TC5) Available Now!

[Adam Williamson]

As per the Fedora 22 schedule [1], Fedora 22 Beta Test Compose 5  
(TC5) is now available for testing.

Content information, including changes, can be found at
https://fedorahosted.org/rel-eng/ticket/6132#comment:7 (and comment 8). Please 
see the
 following pages for download links and testing instructions. Normally 
dl.fedoraproject.org should provide the fastest download, but download-
ib01.fedoraproject.org is available as a mirror (with an approximately 
1 hour lag) in case of trouble. To use it, just replace "dl" with  
"download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

All Beta priority test cases for each of these test pages [2] must  
pass in order to meet the Beta Release Criteria [3]. For the Fedora  
22 cycle we are also trying to run the Final tests at this time, to 
try and identify later release blocker bugs as early as possible.

Help is available on #fedora-qa on irc.freenode.net [4], or on the  
test list [5].

Create Fedora 22 Beta test compose (TC) and release candidate (RC)  
https://fedorahosted.org/rel-eng/ticket/6132

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] 
http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test
-- 
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: A proposal for Fedora updates

[Bojan Smojver]

M. Edward (Ed) Borasky  znmeb.net> writes:

> As a bleeding-edge user I'd be in favor of this, although I thought
> that was what 'updates-testing' was.

Maybe I'm misunderstanding how things work, but I think every package in
updates-testing is signed by a human, on an "offline" machine (i.e. someone
has to walk the RPM to it using physical media, sign it and then bring it
back and upload it), which may be causing some of these delays. So, I was
thinking of a more relaxed signing key, which would used directly by the
build system after people build the packages. Virus and malware scanning at
this point would be useful, of course, but would not catch everything -
that's for sure.

PS. Apologies if the above is misinformation. Going from memory here, from
the days of that Fedora compromise a few years ago.

--
Bojan

-- 
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: A proposal for Fedora updates

[M. Edward (Ed) Borasky]

On Thu, Mar 26, 2015 at 4:28 PM, Bojan Smojver  wrote:
> Kevin Fenzi  scrye.com> writes:
>
>> If you wish to test something before it's fully pushed to testing, you
>> can download it directly from the buildsystem via the web interface,
>> koji command line or bodhi client command line.
>
> I am fully aware of that. I'm making a different point entirely here.
>
> Imagine a regular Fedora user - the one that has no idea about koji. This
> regular user wants to contribute by testing packages as they are built. This
> user is willing to trust a lower quality key in his/her Software (or
> whatever is the current fashion) manager to get the latest stuff, hot off
> the presses.
>
> And yet, such a user would have no idea new packages were available and
> would have a hard time (relatively speaking) getting them. So, I'm
> suggesting we create a "fastrack" for Fedora, so that more people can do
> this and easier. It would be totally optional etc.
>
> --
> Bojan
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

As a bleeding-edge user I'd be in favor of this, although I thought
that was what 'updates-testing' was. I currently have updates-testing
disabled, but now that I have all my scripts migrated from yum to dnf
it wouldn't be a drastic event to enable it.

Can we have the "rolling release" discussion again
after F22 goes stable? ;-)



-- 
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists

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

Re: A proposal for Fedora updates

[Bojan Smojver]

Kevin Fenzi  scrye.com> writes:

> If you wish to test something before it's fully pushed to testing, you
> can download it directly from the buildsystem via the web interface,
> koji command line or bodhi client command line. 

I am fully aware of that. I'm making a different point entirely here.

Imagine a regular Fedora user - the one that has no idea about koji. This
regular user wants to contribute by testing packages as they are built. This
user is willing to trust a lower quality key in his/her Software (or
whatever is the current fashion) manager to get the latest stuff, hot off
the presses.

And yet, such a user would have no idea new packages were available and
would have a hard time (relatively speaking) getting them. So, I'm
suggesting we create a "fastrack" for Fedora, so that more people can do
this and easier. It would be totally optional etc.

--
Bojan

-- 
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: A proposal for Fedora updates

[Adam Williamson]

On Fri, 2015-03-27 at 09:06 +1100, Bojan Smojver wrote:
> Hi there,
> 
> I've been a bit perplexed by the Fedora updates recently (talking 
> about
> F-21 specifically). Many of them appear to be obsolete the moment 
> they
> hit stable, sometimes even testing.
> 
> Take the kernel, for instance. 3.19.2-201.fc21 replaced the previous
> build in bodhi on the 24th. It is still not in testing as I'm writing
> this (although the updates system says it is). Take Firefox. 
> Submitted
> on 23rd, took 3 days to appear anywhere where "regular" folks can 
> test
> it (which is actually stable). Then there are updates (e.g. dovecot)
> that have been built in koji, but appear nowhere, probably because
> person that built it forgot to submit it.
> 
> Can we create a fedora-updates-newbuild repo or something, which 
> would
> have a different key used for signing (i.e. not the one where a human
> does the signing) and could be accessed using yum pretty much
> immediately after the build has been created and flagged to go into 
> this
> repo if it succeeds?
> 
> So, something like:
> 
> fedpkg build --push-to-newbuild
> 
> Stoopid? Irrelevant? Exists but I'm not aware of it?

'koji download-build EVR' works for me. You *can* find repo 
definitions for 'all non-scratch builds for release X', I think, but 
they have limited capacity as they all come straight from Koji, and 
they're not mashed for multiarch.

There is also a 'koji-download-scratch' that lives in fedora-review 
which can be handy for grabbing scratch builds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: A proposal for Fedora updates

[Kevin Fenzi]

On Thu, 26 Mar 2015 23:15:16 + (UTC)
Bojan Smojver  wrote:

> Corey Sheldon  gmail.com> writes:
> 
> > those ARE mirror list links the master mirror servers to be exact.
> 
> Really not a file distribution problem I'm trying to get at here. If
> you check out these two URLs:
> 
> https://admin.fedoraproject.org/updates/FEDORA-2015-4457/kernel-3.19.2-201.fc21
> https://admin.fedoraproject.org/updates/FEDORA-2015-4600/firefox-36.0.4-1.fc21
> 
> You will see what I'm talking about. It takes several days for RPMs
> to move from pending to actual "something" status.

Normally that is not the case. 

However, this week we have had a pile of issues getting updates to
push out. 

Finally the push Dennis started on Tuesday went out today. 

He's doing another one now and hopefully we will be back on track. 

If you wish to test something before it's fully pushed to testing, you
can download it directly from the buildsystem via the web interface,
koji command line or bodhi client command line. 

kevin


pgp2EHruUnsjG.pgp
Description: OpenPGP digital 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: A proposal for Fedora updates

[Bojan Smojver]

Corey Sheldon  gmail.com> writes:

> those ARE mirror list links the master mirror servers to be exact.

Really not a file distribution problem I'm trying to get at here. If you
check out these two URLs:

https://admin.fedoraproject.org/updates/FEDORA-2015-4457/kernel-3.19.2-201.fc21
https://admin.fedoraproject.org/updates/FEDORA-2015-4600/firefox-36.0.4-1.fc21

You will see what I'm talking about. It takes several days for RPMs to move
from pending to actual "something" status.

Mirrors being behind is a different issue completely. For instance, these URLs:

http://mirror.optus.net/fedora/linux/updates/21/x86_64/f/
http://mirror.optus.net/fedora/linux/updates/testing/21/x86_64/k/

Don't have current FF and kernel still, which is fine. I am not talking
about that at all.

--
Bojan

-- 
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: A proposal for Fedora updates

[Corey Sheldon]

those ARE mirror list links the master mirror servers to be exact.

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
G+: 
LinkedIn: 
Github: 
Facebook: 
Several Communities on Stack Exchange 



Tutoring in person or via any of the following platforms:
HackHands 
Wizpert 
FieldNation 
AirPair 
TrueLancer

{PayPal,Google Wallet/Play store, Apple Pay}
-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 Thu, Mar 26, 2015 at 7:02 PM, Bojan Smojver  wrote:

> Chris Murphy  colorremedies.com> writes:
>
> > That might be normal in that it takes a while for mirrors to update,
> > although I'm not sure how long (it could be days).
>
> Just to avoid confusion, I am not talking about mirrors. I am talking about
> updates not appearing at all (i.e. here:
> http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/21/ or here:
> http://dl.fedoraproject.org/pub/fedora/linux/updates/21/). It takes days,
> which is actually preventing testing, not enabling it...
>
> --
> Bojan
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fe

Re: A proposal for Fedora updates

[Bojan Smojver]

Chris Murphy  colorremedies.com> writes:

> That might be normal in that it takes a while for mirrors to update,
> although I'm not sure how long (it could be days).

Just to avoid confusion, I am not talking about mirrors. I am talking about
updates not appearing at all (i.e. here:
http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/21/ or here:
http://dl.fedoraproject.org/pub/fedora/linux/updates/21/). It takes days,
which is actually preventing testing, not enabling it...

--
Bojan

-- 
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: A proposal for Fedora updates

[Corey Sheldon]

1) Things take awhile most times as its using a queue system.2)  Just
because it's available in testing or stable does not mean its ready as  it
still takes time for the mirrors (where you are likely grabbing from unless
not using the meta link) to see and sync with them and the fact that these
happen generally on average  for the busy (primary) mirrors @ 8am 2p 6p
10-11pm US East Coast time (they can take 30-90 minutes to sync ) which is
also not the same frequency that yum /dnf are set to sync/update metadata
(or you would never stop sync and updating to be totally honest (which
would never be "stable").

Hope that was layman enough, if not please let me know what needs clarity I
will be glad to impart what I know/understand as are several others here
I'm sure.

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
G+: 
LinkedIn: 
Github: 
Facebook: 
Several Communities on Stack Exchange 



Tutoring in person or via any of the following platforms:
HackHands 
Wizpert 
FieldNation 
AirPair 
TrueLancer

{PayPal,Google Wallet/Play store, Apple Pay}
-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 Thu, Mar 26, 2015 at

Re: GNOME 3.16.0 megaupdate

[Kalev Lember]

On 03/23/2015 10:17 AM, Kalev Lember wrote:
> Hi all,
> 
> Finally, the long wait is over and the 3.16.0 release is here! Or almost
> over, first we have to get those pesky tarballs out upstream and builds
> done downstream. :)

... and it's now in F22 updates-testing. Testing and karma appreciated:

https://admin.fedoraproject.org/updates/FEDORA-2015-4700/

Thanks,
Kalev
-- 
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: A proposal for Fedora updates

[Chris Murphy]

On Thu, Mar 26, 2015 at 4:06 PM, Bojan Smojver  wrote:
> Hi there,
>
> I've been a bit perplexed by the Fedora updates recently (talking about
> F-21 specifically). Many of them appear to be obsolete the moment they
> hit stable, sometimes even testing.
>
> Take the kernel, for instance. 3.19.2-201.fc21 replaced the previous
> build in bodhi on the 24th.

bodhi - 2015-03-24 21:53:42
This update is currently being pushed to the Fedora 21 testing updates
repository.

bodhi - 2015-03-26 21:48:10
This update has been pushed to testing

Yeah I'm a little confused why it took two days for the push to happen
to updates-testing.

http://ur1.ca/jzqzj

That might be normal in that it takes a while for mirrors to update,
although I'm not sure how long (it could be days).

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

A proposal for Fedora updates

[Bojan Smojver]

Hi there,

I've been a bit perplexed by the Fedora updates recently (talking about
F-21 specifically). Many of them appear to be obsolete the moment they
hit stable, sometimes even testing.

Take the kernel, for instance. 3.19.2-201.fc21 replaced the previous
build in bodhi on the 24th. It is still not in testing as I'm writing
this (although the updates system says it is). Take Firefox. Submitted
on 23rd, took 3 days to appear anywhere where "regular" folks can test
it (which is actually stable). Then there are updates (e.g. dovecot)
that have been built in koji, but appear nowhere, probably because
person that built it forgot to submit it.

Can we create a fedora-updates-newbuild repo or something, which would
have a different key used for signing (i.e. not the one where a human
does the signing) and could be accessed using yum pretty much
immediately after the build has been created and flagged to go into this
repo if it succeeds?

So, something like:

fedpkg build --push-to-newbuild

Stoopid? Irrelevant? Exists but I'm not aware of it?

-- 
Bojan

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

Quick Review Request (owncloud-client)

[Nikos Roussos]

Hi,

I'd appreciate a quick* review on owncloud-client, so we can push the new 
version:
https://bugzilla.redhat.com/show_bug.cgi?id=1202805


(*) It's an existing package that got renamed upstream, so it should fairly 
easy to be reviewed.

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

More packager notifications migrated to FMN

[Ralph Bean]

Recall that the infrastructure team has been working on a new notifications
system[1] in an attempt to unify some of the notifications that get pushed out
by our infrastructure.  As the new system improves (and as we get time to clean
house), we will be turning off the native notifications of various systems.

- Back in February, the native emails from Koji were turned off[2].
- This past week, we turned off the old and well-loved emails from pkgdb[3] and
  dist-git[4].

For your personal notifications, the default settings in FMN[5] should get you
what you need.

There are some mailing lists that had been archiving direct notifications from
from pkgdb and dist-git and we've been working to add those into the new
system.  The scm-commits[6] and perl-devel[7] lists are working as expected
now. The meetingminutes list[8] now also automatically receives meeting minutes
from FMN, so, no need to go and send your minutes there if you have chaired an
irc meeting.

If you own a mailing list that has mysteriously stopped receiving automated
emails, please file an issue[9] requesting that we set up forwarding for you.

** P.S., unrelated, but zodbot grew a new feature recently:  the "#help"
   command is available in IRC meetings to let you solicit help from the
   broader community on.. anything.  Use it liberally.  We'll be building a
   "calls for help" web UI around it in the coming year.

[1] - 
https://lists.fedoraproject.org/pipermail/devel-announce/2014-September/001434.html
[2] - 
https://lists.fedoraproject.org/pipermail/devel-announce/2015-February/001540.html
[3] - https://admin.fedoraproject.org/pkgdb
[4] - http://pkgs.fedoraproject.org/cgit/
[5] - https://apps.fedoraproject.org/notifications
[6] - https://lists.fedoraproject.org/pipermail/scm-commits/
[7] - https://lists.fedoraproject.org/pipermail/perl-devel/
[8] - https://lists.fedoraproject.org/pipermail/meetingminutes/
[9] - https://github.com/fedora-infra/fmn/issues/new


signature.asc
Description: PGP signature
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-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: Captive portal detection on wired connections - bug or feature?

[Alexander Ploumistos]

On Thu, Mar 26, 2015 at 7:50 PM, Dan Williams  wrote:
>
> As Adam implied, you can add your own, higher-numbered file with the
> same options and NM will use those in preference to the Fedora-installed
> one.  See 'man NetworkManager.conf' for specifics.


Thanks, I found your blog post "NetworkManager for Administrators Part
1" and that filled in the blanks.
-- 
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: Captive portal detection on wired connections - bug or feature?

[Dan Williams]

On Thu, 2015-03-26 at 18:29 +0200, Alexander Ploumistos wrote:
> On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera  wrote:
> 
> > You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to
> > disable it.
> >
> 
> Is there a *proper* way to do that so that there aren't any conflicts with
> future updates, e.g. commenting the lines out, removing/renaming the file,
> setting the interval to 0, etc.?

As Adam implied, you can add your own, higher-numbered file with the
same options and NM will use those in preference to the Fedora-installed
one.  See 'man NetworkManager.conf' for specifics.

---
   If a default NetworkManager.conf is provided by your
distribution's packages, you should not modify it, since your changes
may get overwritten by
   package updates. Instead, you can add additional .conf files to
the conf.d directory. These will be read in order, with later files
overriding
   earlier ones.
---

Sorting of filenames is strcmp()-style, so 90-my-stuff.conf takes
precedence over 10-bad-stuff.conf.

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

Re: Pushing the extra AppData files into Rawhide

[Matthew Miller]

On Thu, Mar 26, 2015 at 05:40:29PM +, Richard Hughes wrote:
> So, the overwhelming amount of help I received (one person) meant I
> spent the whole of today fixing up 230 packages. Most of the packages

Looks like about 22 hours since you asked for help, so... I dunno, one
person seems pretty good.

But all that aside, thanks for doing all this work — the end results
are good for Fedora.

-- 
Matthew Miller

Fedora Project Leader
-- 
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: Captive portal detection on wired connections - bug or feature?

[Dan Winship]

On 03/26/2015 12:53 PM, Adam Williamson wrote:
>> You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf 
>> to disable it.
> 
> It would probably be better (if NM respects it) to add a higher-
> numbered file to override it; that way you aren't changing the 
> contents of a packaged file.

Yes, that will work (although the whole point of putting that file into
a separate package was that you were supposed to be able to uninstall
the package if you didn't want it).

-- 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

Re: Pushing the extra AppData files into Rawhide

[Richard Hughes]

On 25 March 2015 at 19:40, Richard Hughes  wrote:
> -- I can't promise cookies, but I'll really appreciate it and it means
> the applications won't disappear from Fedora 23. Yell if you have any
> questions.

So, the overwhelming amount of help I received (one person) meant I
spent the whole of today fixing up 230 packages. Most of the packages
built okay, but some were failing due to the GCC5 changes, or some
other FTBFS issue. If you've got a package that you think I've broken
please let me know and I'll fix it up.

Richard
-- 
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: Captive portal detection on wired connections - bug or feature?

[Adam Williamson]

On Thu, 2015-03-26 at 12:24 -0400, Bastien Nocera wrote:
> - Original Message -
> > On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote:
> > > On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> > > > On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > > > > This was most likely caused by some issues with out proxy 
> > > > > servers this evening. We were adding 3 new proxy servers 
> > > > > into the rotation and there were some config issues with 
> > > > > some of them. ;(
> > > > > 
> > > > > This would have only affected some folks in North America 
> > > > > sporadically, (when they happened to hit a proxy that wasn't 
> > > > > working right) not everyone.
> > > > > 
> > > > > Sorry this happened, everything should be back to normal now.
> > > > 
> > > > I think it would make sense to do a second ping to some other 
> > > > server if the first one to fedoraproject.org fails, for 
> > > > robustness. Maybe to redhat.com, or something that should 
> > > > never be down like google.com (my vote), or to someplace that 
> > > > promises not to track users, like duckduckgo.com (hardly 
> > > > matters much for a connectivity check?).
> > > 
> > > We could always use the Google servers that Android uses by 
> > > default, instead of Fedora :)  Those would be pretty well 
> > > guaranteed to be up...
> > 
> > You might use both so you have less chances of false positive, but
> > *please* make it uninstallable, or easily disableable.
> 
> You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf 
> to disable it.

It would probably be better (if NM respects it) to add a higher-
numbered file to override it; that way you aren't changing the 
contents of a packaged file.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Captive portal detection on wired connections - bug or feature?

[Adam Williamson]

On Thu, 2015-03-26 at 11:21 -0400, Stephen Gallagher wrote:
> On Thu, 2015-03-26 at 04:15 +0200, Alexander Ploumistos wrote:
> > On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson < 
> > adamw...@fedoraproject.org> wrote:
> > > Lots of people have been seeing it, it may be related to some  
> > > issues
> > > with the Fedora infrastructure this afternoon (the check works 
> > > by trying to contact a Fedora server).
> > That much I gathered, but when I first read about the captive 
> > portal  detection feature, I thought it was supposed to work only 
> > with  wireless connections, though I guess it would make sense to 
> > check  with all interfaces.
> > 
> > Can it be disabled for a particular interface/connection though? I 
> > am being bombarded with pop-ups as I am trying to write this...
> No, it still makes sense for wired networks. Have you ever used an  
> ethernet wall-jack at a hotel? It generally goes through a captive  
> portal, just like wireless.

How about the detection is disabled for connections in the 'Home' 
zone? I suppose that's a bit of a boundary issue so long as the 'zone' 
concept is considered a part of firewalld, but...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Captive portal detection on wired connections - bug or feature?

[Alexander Ploumistos]

On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera  wrote:

> You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to
> disable it.
>

Is there a *proper* way to do that so that there aren't any conflicts with
future updates, e.g. commenting the lines out, removing/renaming the file,
setting the interval to 0, etc.?
-- 
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: Captive portal detection on wired connections - bug or feature?

[Bastien Nocera]

- Original Message -
> On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote:
> > On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> > > On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > > > This was most likely caused by some issues with out proxy servers this
> > > > evening. We were adding 3 new proxy servers into the rotation and there
> > > > were some config issues with some of them. ;(
> > > > 
> > > > This would have only affected some folks in North America sporadically,
> > > > (when they happened to hit a proxy that wasn't working right) not
> > > > everyone.
> > > > 
> > > > Sorry this happened, everything should be back to normal now.
> > > 
> > > I think it would make sense to do a second ping to some other server if
> > > the first one to fedoraproject.org fails, for robustness. Maybe to
> > > redhat.com, or something that should never be down like google.com (my
> > > vote), or to someplace that promises not to track users, like
> > > duckduckgo.com (hardly matters much for a connectivity check?).
> > 
> > We could always use the Google servers that Android uses by default,
> > instead of Fedora :)  Those would be pretty well guaranteed to be up...
> 
> You might use both so you have less chances of false positive, but
> *please* make it uninstallable, or easily disableable.

You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable 
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

Re: Captive portal detection on wired connections - bug or feature?

[Bastien Nocera]

- Original Message -
> On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> > On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > > This was most likely caused by some issues with out proxy servers this
> > > evening. We were adding 3 new proxy servers into the rotation and there
> > > were some config issues with some of them. ;(
> > > 
> > > This would have only affected some folks in North America sporadically,
> > > (when they happened to hit a proxy that wasn't working right) not
> > > everyone.
> > > 
> > > Sorry this happened, everything should be back to normal now.
> > 
> > I think it would make sense to do a second ping to some other server if
> > the first one to fedoraproject.org fails, for robustness. Maybe to
> > redhat.com, or something that should never be down like google.com (my
> > vote), or to someplace that promises not to track users, like
> > duckduckgo.com (hardly matters much for a connectivity check?).
> 
> We could always use the Google servers that Android uses by default,
> instead of Fedora :)  Those would be pretty well guaranteed to be up...

I would hope that the Fedora infra will do better in the future to make sure
that we don't run into those problems again.

Using Google's servers would probably mean that we would need to start making
this opt-in, to avoid information leaks. We've been working on the privacy 
policy
to the same effect.
-- 
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: Captive portal detection on wired connections - bug or feature?

[Simo Sorce]

On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote:
> On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> > On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > > This was most likely caused by some issues with out proxy servers this
> > > evening. We were adding 3 new proxy servers into the rotation and there
> > > were some config issues with some of them. ;( 
> > > 
> > > This would have only affected some folks in North America sporadically,
> > > (when they happened to hit a proxy that wasn't working right) not
> > > everyone. 
> > > 
> > > Sorry this happened, everything should be back to normal now. 
> > 
> > I think it would make sense to do a second ping to some other server if
> > the first one to fedoraproject.org fails, for robustness. Maybe to
> > redhat.com, or something that should never be down like google.com (my
> > vote), or to someplace that promises not to track users, like
> > duckduckgo.com (hardly matters much for a connectivity check?).
> 
> We could always use the Google servers that Android uses by default,
> instead of Fedora :)  Those would be pretty well guaranteed to be up...

You might use both so you have less chances of false positive, but
*please* make it uninstallable, or easily disableable.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Captive portal detection on wired connections - bug or feature?

[Dan Williams]

On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > This was most likely caused by some issues with out proxy servers this
> > evening. We were adding 3 new proxy servers into the rotation and there
> > were some config issues with some of them. ;( 
> > 
> > This would have only affected some folks in North America sporadically,
> > (when they happened to hit a proxy that wasn't working right) not
> > everyone. 
> > 
> > Sorry this happened, everything should be back to normal now. 
> 
> I think it would make sense to do a second ping to some other server if
> the first one to fedoraproject.org fails, for robustness. Maybe to
> redhat.com, or something that should never be down like google.com (my
> vote), or to someplace that promises not to track users, like
> duckduckgo.com (hardly matters much for a connectivity check?).

We could always use the Google servers that Android uses by default,
instead of Fedora :)  Those would be pretty well guaranteed to be up...

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

Re: Captive portal detection on wired connections - bug or feature?

[Alexander Ploumistos]

On Thu, Mar 26, 2015 at 5:21 PM, Stephen Gallagher 
wrote:
>
> No, it still makes sense for wired networks. Have you ever used an
> ethernet wall-jack at a hotel? It generally goes through a captive portal,
> just like wireless.
>

Yes, I realized that later on and I discovered the messages pertaining to
the implementation. I can't figure out though why it happened yesterday and
not e.g. if I disconnect my ADSL router from my LAN. Perhaps a check box in
NM that disables monitoring if the user chooses to do so is in order.
-- 
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: Captive portal detection on wired connections - bug or feature?

[Michael Catanzaro]

On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> This was most likely caused by some issues with out proxy servers this
> evening. We were adding 3 new proxy servers into the rotation and there
> were some config issues with some of them. ;( 
> 
> This would have only affected some folks in North America sporadically,
> (when they happened to hit a proxy that wasn't working right) not
> everyone. 
> 
> Sorry this happened, everything should be back to normal now. 

I think it would make sense to do a second ping to some other server if
the first one to fedoraproject.org fails, for robustness. Maybe to
redhat.com, or something that should never be down like google.com (my
vote), or to someplace that promises not to track users, like
duckduckgo.com (hardly matters much for a connectivity check?).

-- 
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: Captive portal detection on wired connections - bug or feature?

[Stephen Gallagher]

On Thu, 2015-03-26 at 04:15 +0200, Alexander Ploumistos wrote:
> On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> > Lots of people have been seeing it, it may be related to some 
> > issues
> > with the Fedora infrastructure this afternoon (the check works by
> > trying to contact a Fedora server).
> That much I gathered, but when I first read about the captive portal 
> detection feature, I thought it was supposed to work only with 
> wireless connections, though I guess it would make sense to check 
> with all interfaces.
> 
> Can it be disabled for a particular interface/connection though? I 
> am being bombarded with pop-ups as I am trying to write this...
No, it still makes sense for wired networks. Have you ever used an 
ethernet wall-jack at a hotel? It generally goes through a captive 
portal, just like wireless.


signature.asc
Description: This is a digitally signed message part
-- 
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: Fedora 22 Beta blocker bug status #1

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 25, 2015 at 10:57:31PM -0700, Adam Williamson wrote:
> 12. https://bugzilla.redhat.com/show_bug.cgi?id=1185604 - systemd - 
> "fedup upgrade fails within the initramfs-fedup env"
> 
> Both the cause and the fix for this seem to be known at this point, 
> and we're waiting on the systemd maintainers finding time to do an F21 
> build. We would really appreciate it if they'd do that soon, as we 
> want to be able to test upgrades properly. Thanks, systemd maintainers.
Yep, the build was done a few days ago, but not the update. It is out
now.

Zbyszek

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

Minutes from Env-and-Stacks WG meeting (2015-03-26)

[Honza Horak]

==
#fedora-meeting-2: Env and Stacks (2015-03-26)
==


Meeting started by hhorak1 at 13:00:40 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-03-26/env-and-stacks.2015-03-26-13.00.log.html
.



Meeting summary
---
* LINK: http://docker-phracek.rhcloud.com/   (phracek, 13:07:55)
* LINK: http://vpavlin.eu/2015/02/fedora-docker-and-systemd/   (hhorak,
  13:13:10)
* LINK:
  https://lists.fedoraproject.org/pipermail/devel/2015-March/209093.html
  (hhorak, 13:20:51)
* LINK: https://sgallagh.fedorapeople.org/2015-03-24.080115-0400EDT.html
  (phracek, 13:35:36)
* ACTION: hhorak to ask copr developers them about what is the current
  status of dist-git for copr  (hhorak, 13:40:26)
* LINK: https://fedoraproject.org/wiki/Changes/Playground_repository
  (hhorak, 14:07:12)
* LINK:

https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
  (hhorak, 14:07:16)
* playground should be kind of "EPEL", for packages that are not or
  never will be in main fedora; for many conflicting repos, we already
  have copr itself -- so the "one big repo" seems to be the prefered way
  before the  (hhorak, 14:07:57)
* we'd also need to be able to let the packagers of to-be-merged repos
  know when they introduce a conflict (a tool that'd automatically
  detect rpm conflicts between the repos-to-be-merged)  (hhorak,
  14:07:57)
* ACTION: volunteer should write up some more concrete proposal with
  concrete user scenario  (hhorak, 14:07:57)
* LINK:

https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
  (mstuchli, 14:09:57)
* LINK: https://fedoraproject.org/wiki/UserLevelPackageManagement-Python
  (mstuchli, 14:10:09)
* LINK:

https://bitbucket.org/hpk42/devpi/issue/198/whitelisting-packages-that-can-be-mirrored
  (mstuchli, 14:10:51)
* ACTION: everyone to look at
  https://fedoraproject.org/wiki/UserLevelPackageManagement-Python and
  propose improvements on ML or next meeting  (hhorak, 14:15:47)

Meeting ended at 14:20:09 UTC.




Action Items

* hhorak to ask copr developers them about what is the current status of
  dist-git for copr
* volunteer should write up some more concrete proposal with concrete
  user scenario
* everyone to look at
  https://fedoraproject.org/wiki/UserLevelPackageManagement-Python and
  propose improvements on ML or next meeting




Action Items, by person
---
* hhorak
  * hhorak to ask copr developers them about what is the current status
of dist-git for copr
* **UNASSIGNED**
  * volunteer should write up some more concrete proposal with concrete
user scenario
  * everyone to look at
https://fedoraproject.org/wiki/UserLevelPackageManagement-Python and
propose improvements on ML or next meeting




People Present (lines said)
---
* hhorak (66)
* bkabrda (25)
* phracek (22)
* mstuchli (13)
* vpavlin (9)
* walters (6)
* zodbot (3)
* hhorak1 (3)
* ttomecek (1)
* sicampbell (1)




Generated by `MeetBot`_ 0.1.4

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

Heads up - openssh 6.8 coming to F22

[Jakub Jelen]

Hi all,

I know that it is quite late in F22 schedule and freeze is coming, but 
we decided to push recent upstream version into F22 before beta freeze 
to keep up with upstream.
I spent some time with testing various use cases with our downstream 
patches and I would like to point out that I did my best. It works fine 
from my point of view. Despite of that I would like to ask you, if you 
could also try your use cases and playing around with ssh* tools and if 
something would break, please report back to me.


Update and builds:
(bodhi)
https://admin.fedoraproject.org/updates/openssh-6.8p1-2.fc22
(rawhide)
http://koji.fedoraproject.org/koji/taskinfo?taskID=9333792
(f22)
http://koji.fedoraproject.org/koji/taskinfo?taskID=9333919

The only potential incompatible change is UseDNS default in sshd_config. 
You can find here new features like "Experimental host key rotation" and 
many bug fixes.


List of complete upstream changes can be found here:
http://www.openssh.com/txt/release-6.8


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

Fedora 22 Beta blocker bug status #1

[Adam Williamson]

Hi folks! It's everyone's favourite time of the year - time for QA to 
make you feel bad about blocker bugs!

We're still six days out from Beta freeze, but I wanted to try and get 
out ahead of the blocker list and try to keep up the 'shipping on 
time' trend we started with Alpha...

If you're directly CCed on this email, it's for one of these reasons:

1) You maintain one of the packages that needs maintainer attention
2) You don't actually maintain one of the packages that needs 
maintainer attention but I think you do because I can be an idiot 
sometimes
3) You're a Great Leader of some sort (hi, Paul, Jaroslav) and thus 
get to read lots of mail from idiot monkeys

If you're a case of 2), please feel free to yell at me at your leisure!

tl;dr
=

Testers, please test and karma these updates:

https://admin.fedoraproject.org/updates/libedit-3.1-11.20141030cvs.fc22
https://admin.fedoraproject.org/updates/FEDORA-2015-4398 (you can up-
karma that one if networking works in the TC4 installer)
https://admin.fedoraproject.org/updates/fedora-release-22-0.14

Developers, the following bugs need fixes. If you believe any of them 
should not be a blocker, please follow up here or in the bug report.

anaconda-n-friends
--

https://bugzilla.redhat.com/show_bug.cgi?id=1166598 "going back to 
installation destination picker swaps partitions on disks"
https://bugzilla.redhat.com/show_bug.cgi?id=1185117 "Custom 
partitioning does not allow convenient removal of volume including 
snapshots (btrfs, LVM)"

others
--

https://bugzilla.redhat.com/show_bug.cgi?id=1197894 "growpart: sfdisk 
dropped --show-pt-geometry option" (NEEDS ATTENTION)
https://bugzilla.redhat.com/show_bug.cgi?id=1204612 "eth0 is going 
missing in the cloud images"
https://bugzilla.redhat.com/show_bug.cgi?id=1204739 "Installing Fedora 
Server netinst ends up with blocked Cockpit port"
https://bugzilla.redhat.com/show_bug.cgi?id=1183807 "network spoke 
listed as not connected despite having assigned IP and hostname"
https://bugzilla.redhat.com/show_bug.cgi?id=1185604 "fedup upgrade 
fails within the initramfs-fedup env"

Detailed bug discussion
===

1.  https://bugzilla.redhat.com/show_bug.cgi?id=1166598- anaconda - 
"going back to installation destination picker swaps partitions on 
disks"

AIUI, someone (vpodzime?) is tasked to work on this and there's a 
plan, but it's moderately complex and there's some suggestion from 
anaconda team that this is more appropriately a Final blocker than 
Beta. The issue is fairly well understood and reproducible.

2. https://bugzilla.redhat.com/show_bug.cgi?id=1185117 - anaconda - 
"Custom partitioning does not allow convenient removal of volume 
including snapshots (btrfs, LVM)"

Again there's a question as to whether this is 'really' a blocker, 
though personally I think cmurf made a strong argument; it's clearly 
painful to remove a btrfs/LVM volume with more than a few snapshots in 
custom partitioning, and we can't really pretend snapshotted volumes 
aren't a thing. There might be an argument for pushing it to Final. I 
do not know what the status of work on this bug is.

3. https://bugzilla.redhat.com/show_bug.cgi?id=1191842 - anaconda - 
"unable to continue the installation after type into a weak password"

This is the good ol' password strength bikeshed. anaconda implemented a
system that allows the password strength checking to be customized, 
but FESCo has some concerns about whether it's sufficient to their 
requirements. I think I'm gonna leave this one to FESCo to herd, they 
seem to be on top of what they want from it.

4. https://bugzilla.redhat.com/show_bug.cgi?id=1184173 - bind - 
"dhclient fails to renew lease, results in dropped IPv4 network 
connection"

This one is basically done, the update is being pushed stable. The fix 
for this bug did cause the showstopper bug in TC3 whose fix caused the 
showstopper bug in TC4, though. I hate software. Anyone want to bet 
what the fix for the TC4 showstopper will break in TC5?!

5. https://bugzilla.redhat.com/show_bug.cgi?id=1197894 - cloud-utils - 
"growpart: sfdisk dropped --show-pt-geometry option"

This one rather seems to have been sitting around since Alpha; we 
could do with some urgency on it. Is anyone from Cloud WG able to step 
up and ensure this gets resolved?

6. https://bugzilla.redhat.com/show_bug.cgi?id=1204612 - distribution -
"eth0 is going missing in the cloud images"

Kushal Das seems to have taken ownership of this one today, so it 
looks like it's being taken care of.

7. https://bugzilla.redhat.com/show_bug.cgi?id=1204739 - fedora-
release - "Installing Fedora Server netinst ends up with blocked 
Cockpit port"

I believe 
https://admin.fedoraproject.org/updates/fedora-release-22-0.14 is 
intended to fix this, though it's not marked as such. Probably needs 
testing.

8. https://bugzilla.redhat.com/show_bug.cgi?id=1201120 - libblockdev - 
"DeviceTreeError: could not find parent for subvol"

W

Agenda for Env-and-Stacks WG meeting (2015-03-26)

[Honza Horak]

I've got few messages from people who cannot attend today's meeting, but 
still there may be something to discuss. Sorry for very late announcement.


WG meeting will be at 13:00 UTC (9:00 EST, 14:00 Brno, 9:00 Boston, 
22:00 Tokyo, 23:00 Brisbane) in #fedora-meeting-2 on Freenode.


= Topics =
* Follow-ups
  * Dockerfiles recommended tips
  * Playground repo revisiting
* Open Floor

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

F-22 Branched report: 20150326 changes

[Fedora Branched Report]

Compose started at Thu Mar 26 07:15:02 UTC 2015
Broken deps for armhfp
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libofstd.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires liboflog.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg8.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg16.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg12.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmnet.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmjpeg.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimgle.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimage.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmdata.so.3.6
[avro]
avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client
[bro]
broccoli-2.3-1.fc22.armv7hl requires bro-2.3
python-broccoli-2.3-1.fc22.armv7hl requires bro-2.3
[crystal]
crystal-2.2.1-2.fc22.armv7hl requires libkdecorations.so.4
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14
[gammaray]
gammaray-qt5-2.2.1-3.fc22.armv7hl requires qt5-qtbase(armv7hl-32) = 
0:5.4.0
[gcc-python-plugin]
gcc-python2-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 
0:4.9.2-1.fc22
gcc-python2-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22
gcc-python3-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 
0:4.9.2-1.fc22
gcc-python3-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22
[kde-style-skulpture]
kde-style-skulpture-0.2.4-9.fc22.armv7hl requires libkdecorations.so.4
[kdeartwork]
kdeartwork-14.12.1-1.fc22.armv7hl requires libkdecorations.so.4
kdeartwork-14.12.1-1.fc22.armv7hl requires kde-workspace >= 0:4.11
kdeartwork-kxs-14.12.1-1.fc22.armv7hl requires kde-workspace >= 0:4.11
kdeartwork-screensavers-14.12.1-1.fc22.armv7hl requires 
libkscreensaver.so.5
[kfilefactory]
kfilefactory-0.1.1-8.fc21.noarch requires kdebase-workspace
[kstars]
kstars-14.12.1-1.fc22.armv7hl requires libindi.so.0
[leksah]
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(utf8-string-0.3.7-013ef9ad8ac70ebb11df31f487b74f26)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(unix-2.6.0.1-7550b9ae9dbc74e4d6570cc239a29030)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(transformers-0.3.0.0-23508e0b4a1c1bc1cf2c2de3bb13e90c)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(time-1.4.0.1-970760bdd865d8b6cafac382276795a2)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(text-0.11.3.1-17cae9ba49c3f3d533bf78a6e387f543)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(strict-0.3.2-04f0cc1e99eff2196c0a7cd16d748b37)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(regex-tdfa-1.1.8-0b03687c4e38c00ef92e9445170081e2)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(regex-base-0.93.2-6a541a53412d1d7d310fa69bca50c85f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(pretty-1.1.1.0-2de27f83b2c1c65d629a564e9e01b27d)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(parsec-3.1.3-a8bebef411959de671abb0f1f7da556f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(old-time-1.1.0.1-29c02e2b3bbdfd9a5756f0c46f4d6071)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(network-2.4.1.2-82f6bcf79fe0252b3ab387e8dcb82e71)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(mtl-2.1.2-2f2cd438035824ec2bed4811930bc232)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(ltk-0.12.1.0-2fbb10498719be9dbdbb3d9f8adedbec)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(leksah-server-0.12.1.2-7dbd70c9f5e4dd8b3b5efcb6597b3bfd)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(hslogger-1.2.1-43834164508859009a3cc8aef7fd1e84)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gtksourceview2-0.12.5.0-588b179d0562576f9afa46559cebf79f)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gtk-0.12.5.0-2342a114ec8897cecfdda15ac92aed08)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(glib-0.12.5.0-1b94df160e141377711a221615168695)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(gio-0.12.5.0-b012293268f349d8f05c73d053798c7b)
ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires 
ghc-devel(ghc-7.6.3-18fc786f8ad3478b9bb568d865b0e48d)
ghc-leksah-devel-0.12.1.3-16.

Kakoune - new Vim inspired editor

[Jiří Konečný]

Hi all,

I want to draw your attention to new editor Kakoune.

-- Vim inspired — Faster as in less keystrokes — Multiple selections —
Orthogonal design --

It's now under heavy development by the mawww and I think it has a
bright future. I think it's now stable enough to be used and mawww wants
feedback from users. So if you like vim, test it and if you don't test
it too. I think it's better than vim for newbies.

My humble copr repo ->
https://copr.fedoraproject.org/coprs/jkonecny/kakoune/
GitHub -> https://github.com/mawww/kakoune

Copr repository will be updated on daily basis. Now manually -> going to
be automatic in future.

Any feedback will be appreciated.
Feedback about project to GitHub.
Feedback about spec file or anything Fedora based point to me directly.


-- 
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: captive portal implementation found lacking

[David Woodhouse]

On Wed, 2015-03-25 at 21:52 -0400, David Airlie wrote:
> Otherwise I think this feature is a bit half baked as is.

I don't understand how you can make *any* decisions based on HTTP 
reachability, without *first* picking up proxy settings from 
DHCP/VPN/WPAD etc., poking them into PacRunner, and *using* the 
proxies consistently and correctly.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic 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: [ppc] Default stack size on ppc64

[David Woodhouse]

On Thu, 2015-03-26 at 08:57 +, Richard W.M. Jones wrote:
> Is pthread_create used even for the main thread in the process (I
> thought the kernel created that).  In any case threads aren't being
> used explicitly by this process.
> 
> Anyway I guess the guard page is just a hole that causes the process
> to abort (as observed) and is not a mechanism for automatically
> growing the stack.

Right, It's a mechanism for catching stack overflow reliably, rather 
than letting it cause random memory corruption.

But for the original stack created by the kernel when the process is 
created, I think you just don't have the guard page. All that stops 
you is the ulimit.

So... we could potentially look for ways to reduce the stack usage of 
OCaml-compiled code, or you get to keep increasing the limit.

It might be worth taking a look at the stack frames and seeing if I 
did anything entirely stupid when setting them up, and whether they 
can be made smaller. Although if you said it was averaging ~168 bytes, 
that doesn't seem *particularly* excessive. Can you see how big the 
stack actually does get in your worst case, and how much we'd have to 
shrink by in order to get away without tweaking the ulimit?

Perhaps we could also look at using a smaller stack frame between 
OCaml functions. If we're never using certain registers in the OCaml 
code generator, we don't need to save them or leave space for them on 
the stack. All we need to do it ensure that if we're calling out to a C
function, we *do* leave enough space in the stack frame for callee-
saved registers, right?

I concede to being a bit rusty here... :)

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic 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: New to the list, and... possible bug ?

[Hoggins!]

Thank you Petr,

Le 25/03/2015 13:20, Petr Pisar a écrit :
> On 2015-03-23, Hoggins!  wrote:
>> Le 23/03/2015 16:56, Petr Pisar a =C3=A9crit :
>> Actually, no. I've always had this "error", but it was working okay.
>> Now, when I try to launch rollerd with : rollerd -rrfile
>> /var/named/all.rollrec -directory /var/named/, either I get :
>>
>> undefined time at
>> /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203.
>>  at /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203.
>> in new Net::DNS::RR( sigexpiration 20150420124526 typecovered SOA
>> orgtt ... ) at /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm
>> line 203.
> [...]
>> ***  The 1277 Net::DNS::RR::RRSIG object has no method 'first'
>> ***  THIS IS A BUG IN THE CALLING SOFTWARE, which incorrectly assumes=
>>
>> ***  that the object would be of a particular type.  The type of an
>> ***  object should be checked before calling any of its methods.
>>  at /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm line 205.
>> Net::DNS::RR::_new_hash called at
>> /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm line 65
>> eval {...} called at /usr/lib64/perl5/vendor_perl/Net/DNS/RR.pm
>> line 66
>> Net::DNS::RR::new("Net::DNS::RR", "labels", 2, "signame",
>> "atelierpanel.com.", "keytag", 37568, "class", "IN", ...) called at
>> /usr/lib64/perl5/vendor_perl/Net/DNS/ZoneFile/Fast.pm line 203
>> Net::DNS::ZoneFile::Fast::parse("file",
>> "/var/named/atelierpanel.com.hosts.signed") called at
>> /usr/lib64/perl5/vendor_perl/Net/DNS/SEC/Tools/dnssectools.pm line 38=
>> 2
>>
> It looks like dnssec-tools uses perl-Net-DNS incorrectly.
>
> Please report it to the Bugzilla tool
> .
>
> -- Petr
>

It's been reported as https://bugzilla.redhat.com/show_bug.cgi?id=1206070

It's my first bug report. Hope I'm not doing it too bad.

Cheers !

Hoggins!





signature.asc
Description: OpenPGP digital 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: [ppc] Default stack size on ppc64

[Richard W.M. Jones]

On Wed, Mar 25, 2015 at 07:57:25PM -0500, Steven Munroe wrote:
> On Wed, 2015-03-25 at 19:45 +, Richard W.M. Jones wrote:
> > On Wed, Mar 25, 2015 at 06:30:25PM +, David Woodhouse wrote:
> > > If the compiler is single-threaded, and increasing the stack ulimit 
> > > fixes the problem, that implies that the default stack ulimit is less 
> > > than the 8MiB-64KiB that it takes to reach the guard page...
> > 
> > Just so I'm clear, is the stack supposed to grow down automatically
> > (ie. does the stack automatically use MAP_GROWSDOWN), or is OCaml
> > supposed to do something when the stack hits the guard page?
> 
> It depends on which code is allocating the stack.
> 
> The default GLIBC implementation under pthread_create will allocate it
> as single anonymous mmap of 8MB then use mprotect on the lowest page to
> mark the guard page no-access. As in:

Is pthread_create used even for the main thread in the process (I
thought the kernel created that).  In any case threads aren't being
used explicitly by this process.

Anyway I guess the guard page is just a hole that causes the process
to abort (as observed) and is not a mechanism for automatically
growing the stack.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct