sorting yum/dnf metadata and metadata diffs

[Casey Jao]

How feasible would it be to keep the listings in primary.xml and
filelists.xml sorted by package name and arch? Doing so could open the door
to simple and efficient diffs of repository metadata.

I recently ran some quick tests using python and elementtree. While the F21
primary.xml files from 2/7 and 2/9 both weigh around 2.6M compressed and
~18M uncompressed, sorting them and running a simple line-by-line
comparison revealed a diff of ~500K, which compressed down to ~70K. A
similar procedure on the 8M filelists.xml yielded a diff which compressed
to ~200K.

Those two are by far the largest metadata files. If the observed
improvements are typical, then keeping those files in order and hosting the
diffs between the present and the previous few days (and modifying dnf to
look for those diffs) could substantially reduce the amount of data that
users must download every time a repository is updated, which for a
fast-moving OS like Fedora could happen nearly every day.
-- 
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: rawhide report: 20150212 changes

[Parag Nemade]

On Fri, Feb 13, 2015 at 9:09 AM, Orion Poplawski  wrote:
> On 02/12/2015 07:54 AM, Fedora Rawhide Report wrote:
>>
>> Compose started at Thu Feb 12 10:59:03 UTC 2015
>
>
>> xorg-x11-server-1.17.1-1.fc22
>
>
> Shouldn't we be seeing fc23 builds now in rawhide?

I too can't see my fc23 builds in this rawhide report.

Regards,
Parag.
-- 
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 Mass Branching

[Orion Poplawski]

On 02/12/2015 02:40 AM, Peter Robinson wrote:

h>> Hi All,


Fedora 22 has been branched, please be sure to do a git pull --rebase to
pick up the new branch, as an additional reminder rawhide/f23 has had
inheritance cut off from previous releases,  so this means that
anything you do for f22 you also have to do in the master branch and do
a build there. This is the same as we did for previous Fedora releases



Is the koji rawhide repo not pointing to the new F23 builds/repo somehow?
My otf2-1.5.1-1.fc23 build doesn't appear to be showing up.

http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498


It's pointed to f-23 just fine
http://koji.fedoraproject.org/koji/buildtargetinfo?name=rawhide



Yeah, that looks good.  But I don't see fc23 builds showing up in:

http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/

but I do see it in:

http://kojipkgs.fedoraproject.org/repos/f23-build/latest/x86_64/

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

Re: Bootstrapping build-time circular dependent packages

[Orion Poplawski]

On 02/12/2015 01:43 PM, Vladimir Stackov wrote:

Say we have two packages:

Name: a
Requires: b
BuildRequires: b

and

Name: b
Requires: a
BuildRequires: a

I can bootstrap them by building and installing manually before
rpmbuild but how should I do that with koji?
Thanks for any advices!



See also: http://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping


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

Re: rawhide report: 20150212 changes

[Orion Poplawski]

On 02/12/2015 07:54 AM, Fedora Rawhide Report wrote:

Compose started at Thu Feb 12 10:59:03 UTC 2015



xorg-x11-server-1.17.1-1.fc22


Shouldn't we be seeing fc23 builds now in rawhide?

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

Re: [Proposal] Ring-based Packaging Policies

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote:
> (Logistical note: please keep all replies to this thread on
> devel@lists.fedoraproject.org)
> 
> tl;dr Shall we consider requiring a lesser package review for packages
> that are not present on Product or Spin install media?
Despite the title, and the tl;dr summary, what you are proposing boils
down to a blanket exception on bundling. This is both not enough and
dangerous. I agree that we could relax the rules in some places, where
the effort of conforming to Guidelines is just too big for the real
gain. But I think the way this is done should be much more subtle,
based on an analysis of individual tradeoffs.

In your proposal the ring of the package is the important thing. But
the dependency tree is a very well connected graph, and various fringe
packages are used by "core" packages, so there's no way to develop
anything using just the core, and any real-life server is also going
to include packages from all rings. Security bugs in "fringe"
web-facing services are more important than bugs in "core" tools
which are purely local. For example, recent XSS vulnerability in
jquery [1] nicely cuts through all rings. Unbundling jquery here would
give a huge benefit, and does not become less important the farther a
package is from the core.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1166041

> == Premise ==
> 
> So, some time ago, we started talking about dividing up the Fedora
> package set into a series of "rings". One of the driving purposes behind
> this idea was to re-evaluate our policies for packaging in each of these
> rings. A fair amount of time has passed and no formal discussions have
> taken place (that I have seen, at any rate), so I'm going to provide
> here a simple "starter" proposal that we can work from and see where it
> leads.
> 
> To begin, I'll try to identify some of the major advantages and
> disadvantages in our current policies. (In no particular order...)
> 
> === Advantages ===
> * Consistency: every shared library, language-specific module and
> application should have packaging consistent with others in its
> category. This makes it easier for comaintainers and provenpackagers to
> pick it up and work on it.
> 
> * The no-bundled-libraries policy means that when a library module
> requires an update, it means that only one package needs to be modified
> in order to enhance all applications on the system that consumes it.
> This is a significant time-saver when it comes to dealing with
> (increasingly common) security vulnerabilities.
> 
> * Package review "front-loads" the task of educating the packagers. It
> guarantees that packages enter the collection by meeting a very high
> standard. This does a great deal to accomplish the "consistency"
> mentioned above.
> 
> * Legal review and the FPCA ensures that Fedora remains true to its
> "Freedom" Foundation (as well as protecting Fedora contributors from the
> perils of the international legal system).
> 
> === Disadvantages ===
> * Very strict policies often leads to potential packagers giving up.
True. But packagers often give up for many other reasons, including
unresolved legal problems with the software, many different packaging
problems other than bundling, lack of sponsors, etc.

> * Package reviews for less-interestingackages (such as those for less
> popular SIGs) often remain un-reviewed for weeks, months or even years.
> 
> * The package policies are only ever reviewed during the initial
> creation of the package. Once that initial (high) hurdle is cleared, the
> packager essentially has free reign to do whatever they want with their
> package. This sometimes means that as time passes, the spec files
> "bit-rot" or otherwise start accumulating other inconsistencies. (A
> common example is the package whose upstream starts bundling a library
> without the packager noticing).
Your proposal would only worsen, not fix that.

> * Many upstream projects do not concern themselves with being "in" any
> particular distribution (with the notable example being the
> Debian/Ubuntu flavors which have amassed a sufficient apparent userbase
> that they sometimes get special treatment). For a variety of reasons,
> this often leads directly to bundling the vast majority of their
> dependencies. This is done for many reasons, but the two most common are
> supportability and portability; it's impossible for many upstreams to
> actually QA their package with every possible distro library. Instead,
> if they ship everything they depend on, they can guarantee *that*
> specific combination. This moves the responsibility from the
> distribution to the upstream package to maintain their bundled
> libraries.
I think this responsibility is an illusion. Most upstreams only care
that the bundled versions allow their package to continue to work, and
are not at all capable of fixing vulnerabilities or even other bugs.

I think that it is also very unlikely that packages would be 

Re: [Proposal] Ring-based Packaging Policies

[Björn Persson]

Stephen Gallagher wrote:
>* The package *MAY* contain bundled libraries or other projects, but if
>it does so, it *MUST* contain a "Provides: bundled(pkg) = version" for
>each such bundling. This is done so that we can use the meta-data to
>identify which packages may be vulnerable in the event of a security
>issue.

Before (and if) this becomes policy, it must be defined exactly what
"pkg" shall be. In some cases it's obvious. In other cases a name
exists in multiple variants. If we end up with one package bundling
"gpg", another "gnupg" and a third "gpg2", then the policy hasn't
fulfilled its purpose of making it easy to find all packages that
bundle a particular piece of software.

Shall it be the name of the RPM package in Fedora? Or the source RPM
package? But what if there isn't a Fedora package of the bundled
software? Shall it be the name of the upstream source tarball? Some
projects don't even release tarballs. The soname? That works only for
compiled libraries. The project name on Sourceforge/Github/Savannah/...?
The domain name of its website? But one project can distribute multiple
packages, and some projects use multiple websites and nothing enforces
that the name is the same everywhere. Could the name of the root
directory of its source code tree be used? Some source packages
(especially those that are packaged in zip files instead of tarballs)
contain multiple files and directories without a common root directory.

-- 
Björn Persson


pgp6ongLGAOLp.pgp
Description: OpenPGP digital signatur
-- 
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: Firefox addon signing

[Kevin Kofler]

Nikos Roussos wrote:
> If the only way is to completely disable this feature, I'd prefer we
> don't.
> I wouldn't like for us to ship a less secure build of Firefox.

After Restricted Boot, now Restricted Browser? No thanks! This "feature" 
needs to be disabled no matter whether it affects our packaged plugins or 
not.

Kevin Kofler

-- 
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: Orphaned Packages in rawhide (2015-02-10)

[Kevin Kofler]

Richard W.M. Jones wrote:
> I did a test build of SDL without the audiofile + arts + esound
> dependencies (arts + esound also seem to need audiofile), and it
> builds fine, so that is one route out of this.

Audiofile is bound to stay, and SDL should remain built against it, as 
removing it would disable some features that some applications/games using 
SDL need.

Feel free, however, to build SDL without aRts and esound support. The only 
reason aRts is still in Fedora at all is for things that support ONLY aRts 
for sound output (in particular, the knotify in kdelibs3 and the kdelibs3 
game taxipilot). There is nothing using aRts as its native sound server 
anymore, and there hasn't been since Fedora 9 (!). What will happen if you 
try to use aRts output is that an instance of aRts will be spawned, talking 
to ALSA, and terminated once the aRts-using application exits. In the 
default setup, that means you're running aRts on top of PulseAudio through 
the ALSA PulseAudio plugin, not a very interesting setup. (Better use 
PulseAudio directly.) And using aRts INSTEAD of PulseAudio is clearly not 
something we can or should support anymore, as most applications no longer 
support aRts, if they ever did. Esound support is similarly obsolete, it is 
only emulated by PulseAudio (we haven't been shipping the real ESD for a 
long time, I think since Fedora 8 (!)), so it is better to use native 
PulseAudio output.

Kevin Kofler

-- 
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: [Proposal] Ring-based Packaging Policies

[Stephen Gallagher]

On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote:
> On 12/02/15 19:32, Stephen Gallagher wrote:
> > (Logistical note: please keep all replies to this thread on
> > devel@lists.fedoraproject.org)
> >
> > tl;dr Shall we consider requiring a lesser package review for packages
> > that are not present on Product or Spin install media?
> 
> 
> Thanks for bringing this up. We really need to do something about this, 
> and the proposal is likely to get things rolling.
> 
> This is really about two things, right? A "lighter review" and a general 
> bundling exception for packages not in the core (?)
> 

Ultimately, it's about one thing: Help get more software into Fedora
without scaring people away. The ultimate goal being that Fedora becomes
(remains!) a leader in the distribution of open source software.

> As for the bundling exception I more or less just agree. One detail 
> might be to add some text about not having bundled libraries in system 
> locations, and not exporting (filtering) them.
> 

That's an interesting point. Though it's somewhat academic as most
packages that bundle are usually carrying an internal copy (either
statically linked or stored in a package-private location).

There's one other piece to bundling that I neglected to mention in my
original email that was brought up at DevConf.cz: bundling also means an
increase in memory and disk usage, since the bundled lib will
effectively be loaded multiple times into memory. I'm personally of the
opinion that this is a lesser issue, given that memory and disk space
gets cheaper every day, but it *is* a disadvantage and should be noted.

> As for the "lighter review" this is not so clear to me. I agree that we 
> need to relax the review, but:
> 
>- Wouldn't it feel a little more comfortable to list the exceptions 
> we allow compared to a regular review rather than starting with just 
> some broad statements what the review is?
> 

Yeah, I didn't want to get *too* specific in this original email. I
wasn't setting out to write new guidelines, just get a feel for whether
people thought this was worth exploring in greater detail.


>- Shouldn't we make a distinction between 'review' and 'pass'. E. g., 
> even if we allow bundled libs, we should definitely review and locate 
> them. Isn't the situation similar for other things: while we still 
> review them, things that are blockers in ring 0 could pass in ring 1?
> 

Well, I tried to cover that by noting that all bundling still had to
have the virtual "Provides: bundled(pkg)" which therefore implies that
someone has done this search. Formal review guidelines should enforce
this, I guess. I don't want the review to be *too* strict or we will end
up where we are now, with many reviews sitting in neverland for a long
time because it's a significant time commitment to perform one.


> Colin walters wrote:
> 
> > Anyways, something I think is missing from here is more
> > details on how this "on the install media set" distinction
> > is maintained over time.  If it isn't separate (yum) repositories
> > it seems like it's going to be hard to enforce.
> 
> 
> A virtual provides in all ring 1 packages?

That would still be manual, so I'm not sure how it would help. The best
we can hope for is to write some tools to compare the compose trees and
notice if anything changes between two composes. If something new
appears, it should be flagged for review.


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: Bootstrapping build-time circular dependent packages

[Itamar Reis Peixoto]

On Thu, Feb 12, 2015 at 6:43 PM, Vladimir Stackov  wrote:
> Say we have two packages:
>
> Name: a
> Requires: b

drop this one and build A, then build b, and rebuild A adding the
dependencie back
---> BuildRequires: b

>
> and
>
> Name: b
> Requires: a
> BuildRequires: a



-- 


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

Bootstrapping build-time circular dependent packages

[Vladimir Stackov]

Say we have two packages:

Name: a
Requires: b
BuildRequires: b

and

Name: b
Requires: a
BuildRequires: a

I can bootstrap them by building and installing manually before
rpmbuild but how should I do that with koji?
Thanks for any advices!

-- 
Kind regards,
Vladimir.
-- 
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: 3 days without pushes ?

[Till Maas]

On Thu, Feb 12, 2015 at 07:53:05PM +, Sérgio Basto wrote:

> yeah, but we should have some regularity, I don't like waiting without
> knowing the delay, in this case is pushing to stable, is just for my

Nobody is delaying pushes on purpose and everyone involved into it would
like it to happen faster. However, there is developer manpower missing
to fix and improve tools, that nobody can make magically appear.

Regards
Till
-- 
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: 3 days without pushes ?

[Stephen John Smoogen]

On 12 February 2015 at 12:53, Sérgio Basto  wrote:

> On Qui, 2015-02-12 at 14:41 -0500, Corey Sheldon wrote:
> > Aka patience and to be totally honest and blunt, if you have a
> > alpha/beta tester group and or a solid forum/mailing list with updates
> > to status this should seriously not be a setback  3 weeks on the other
> > hand might qualify.Appreciate the eagerness to partake in
> > development /packaging but things happen from time to time learn to
> > roll with the tides as they say
>
> yeah, but we should have some regularity, I don't like waiting without
> knowing the delay, in this case is pushing to stable, is just for my
> organization, to see what is in stable and what let in testing, and I
> have been patient.
>

I realize we haven't have a branch in a while due to the long Fedora 20
cycle, but this is how things are done usually after a branch.. there can
be up to a week delay for pushes as various things get ironed out.



> But when someone else send a package to testing and I want test it, if
> we don't have a push to testing, force me download packages manually .
> The point here is push to testing should be more quickly than push to
> stable .
>
> Thanks ,
> --
> Sérgio M. B.
>
> --
> 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: [Proposal] Ring-based Packaging Policies

[Paul Howarth]

On Thu, 12 Feb 2015 14:01:43 -0500
Colin Walters  wrote:

> On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
> 
> > tl;dr Shall we consider requiring a lesser package review for
> > packages that are not present on Product or Spin install media?
> 
> It's worth noting here that having two levels is not really going
> to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
> for quite a while:
> https://help.ubuntu.com/community/Repositories/Ubuntu
> 
> I just have one question: You're defining this split at the *runtime*
> level.  Last I saw the Base working group was trying to cut down
> BuildRequires (but sadly I haven't seen them fighting Requires yet -
> I would love if someone did that for Perl)

We generally have requires for most optional functionality in Perl
packages at the moment, to avoid bugs being raised about missing
dependencies when people try to use that optional functionality.

If there was consensus about use of soft dependencies, that would
probably help a lot in the Perl world.

Paul.
-- 
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: 3 days without pushes ?

[Sérgio Basto]

On Qui, 2015-02-12 at 14:41 -0500, Corey Sheldon wrote:
> Aka patience and to be totally honest and blunt, if you have a
> alpha/beta tester group and or a solid forum/mailing list with updates
> to status this should seriously not be a setback  3 weeks on the other
> hand might qualify.Appreciate the eagerness to partake in
> development /packaging but things happen from time to time learn to
> roll with the tides as they say

yeah, but we should have some regularity, I don't like waiting without
knowing the delay, in this case is pushing to stable, is just for my
organization, to see what is in stable and what let in testing, and I
have been patient. 
But when someone else send a package to testing and I want test it, if
we don't have a push to testing, force me download packages manually .  
The point here is push to testing should be more quickly than push to
stable .

Thanks , 
-- 
Sérgio M. B.

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

I wrote small script to list FTBFS koji entries

[Marcin Juszkiewicz]

Hi

As my work usually is around fixing packages which failed to build on
AArch64 I spend lot of time with Koji.

Today I started writing script which has to list all current FTBFS
entries from selected Koji instance - kind like [1] does but with few
extras:

- no packages which got built later
- no repeated entries

I plan to make something like Ubuntu has [2] which was great help when I
was working on fixing packages while working for Canonical.

No idea how far I will go with it but something like generator for such
page is on my to do list.

Current version of script is on [3]. My Python skills maybe are not the
greatest ones but script works for me.

Patches, ideas, bugs are welcome.


1. http://arm.koji.fedoraproject.org/koji/builds?state=3&order=-build_id
2. http://qa.ubuntuwire.com/ftbfs/
3. https://github.com/hrw/fedora-koji-scripts
-- 
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: 3 days without pushes ?

[Corey Sheldon]

Aka patience and to be totally honest and blunt, if you have a alpha/beta
tester group and or a solid forum/mailing list with updates to status this
should seriously not be a setback  3 weeks on the other hand might
qualify.Appreciate the eagerness to partake in development /packaging
but things happen from time to time learn to roll with the tides as they say

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
Google+: https://www.plus.google.com/+CoreySheldon
LinkedIn:https://www.linkedin.com/profile/view?id=70127804
Github: https://www.github.com/linux-modder



Tutoring in person or via any of the following platforms:
https://www.wizperts.com
https://www.hackhands.com
https://airpair.com
https:// fieldnation.com


{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, Feb 12, 2015 at 2:36 PM, Till Maas  wrote:

> On Thu, Feb 12, 2015 at 06:52:11PM +, Sérgio Basto wrote:
>
> > 2015-02-09 20:13:21
> > This update has been submitted for stable by sergiomb  .
> >
> > Today is 12 and still not pushed, how we can devel when have to wait 3
> > days to a push ? , pushes should be regular and not random .
> > What happened last 3 days ?  Seems that I'm not lucky when I push
> > things , in weekends sometimes I have to wait 48 hours .
>
> Update pushes will be resumed as soon as possible. Because of branching
> and problems with the signi

Re: Changing default configuration

[Ryan S. Brown]

On 02/10/2015 09:16 AM, Alberto Ruiz wrote:
> On Tue, 2015-02-10 at 14:38 +0100, Marek Skalický wrote:
>> Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500:
>>> On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote:
 does someone know what are Fedora Guidelines (or something similar)
 saying about this bug
 https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ?
 Is is possible to change default configuration file depending on
 available free space?
>>>
>>> Generally, making such a decision at install time is bad, because that
>>> might not reflect _runtime_. For example, in the cloud image, we use a
>>> / filesystem as small as Anaconda will allow, but that grows to fill
>>> available storage when the image is booted.
>>>
>>> Is there a way to make this decision when mongodb runs?
>>>
>>
>> It should be possible to code this into sysv init script. But I am not
>> sure if it is possible to do the same in systemd service...?
>>
>> My question was also about whether this should be done by mongoDB? Or
>> there should be default configuration and user can easily change it in
>> configuration file?
> 
> It should be done by MongoDB, I would get in touch with the upstream and
> discuss the problem with them.
> 
>> Marek

I don't think there should be run- *or* install-time determination on
this. Smallfiles is used for more than just free space reasons and only
the end operator knows whether they need it or not. There's a documented
upstream default, and it's the operator's job to change it if they need to.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
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: 3 days without pushes ?

[Till Maas]

On Thu, Feb 12, 2015 at 06:52:11PM +, Sérgio Basto wrote:

> 2015-02-09 20:13:21
> This update has been submitted for stable by sergiomb  .
> 
> Today is 12 and still not pushed, how we can devel when have to wait 3
> days to a push ? , pushes should be regular and not random . 
> What happened last 3 days ?  Seems that I'm not lucky when I push
> things , in weekends sometimes I have to wait 48 hours . 

Update pushes will be resumed as soon as possible. Because of branching
and problems with the signing server needed for pushing updates, updates
are currently delayed.

Also we do not have someone doing pushing updates every weekend. It also
requires manual signing.

Regards
Till
-- 
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: [Proposal] Ring-based Packaging Policies

[Alec Leamas]

On 12/02/15 19:32, Stephen Gallagher wrote:

(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)

tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?



Thanks for bringing this up. We really need to do something about this, 
and the proposal is likely to get things rolling.


This is really about two things, right? A "lighter review" and a general 
bundling exception for packages not in the core (?)


As for the bundling exception I more or less just agree. One detail 
might be to add some text about not having bundled libraries in system 
locations, and not exporting (filtering) them.


As for the "lighter review" this is not so clear to me. I agree that we 
need to relax the review, but:


  - Wouldn't it feel a little more comfortable to list the exceptions 
we allow compared to a regular review rather than starting with just 
some broad statements what the review is?


  - Shouldn't we make a distinction between 'review' and 'pass'. E. g., 
even if we allow bundled libs, we should definitely review and locate 
them. Isn't the situation similar for other things: while we still 
review them, things that are blockers in ring 0 could pass in ring 1?


Colin walters wrote:


Anyways, something I think is missing from here is more
details on how this "on the install media set" distinction
is maintained over time.  If it isn't separate (yum) repositories
it seems like it's going to be hard to enforce.



A virtual provides in all ring 1 packages?


Cheers!

--alec
--
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: 3 days without pushes ?

[Corey Sheldon]

Seen the koji build fail messages in the list or IRC ?  it not just you

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
Google+: https://www.plus.google.com/+CoreySheldon
LinkedIn:https://www.linkedin.com/profile/view?id=70127804
Github: https://www.github.com/linux-modder



Tutoring in person or via any of the following platforms:
https://www.wizperts.com
https://www.hackhands.com
https://airpair.com
https:// fieldnation.com


{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, Feb 12, 2015 at 1:52 PM, Sérgio Basto  wrote:

> Hi, .
>
> 2015-02-09 20:13:21
> This update has been submitted for stable by sergiomb  .
>
> Today is 12 and still not pushed, how we can devel when have to wait 3
> days to a push ? , pushes should be regular and not random .
> What happened last 3 days ?  Seems that I'm not lucky when I push
> things , in weekends sometimes I have to wait 48 hours .
>
> Thanks,
> --
> Sérgio M. B.
>
> --
> 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: [Proposal] Ring-based Packaging Policies

[Stephen Gallagher]

On Thu, 2015-02-12 at 14:01 -0500, Colin Walters wrote:
> On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
> 
> > tl;dr Shall we consider requiring a lesser package review for packages
> > that are not present on Product or Spin install media?
> 
> It's worth noting here that having two levels is not really going
> to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
> for quite a while:
> https://help.ubuntu.com/community/Repositories/Ubuntu
>
> I just have one question: You're defining this split at the *runtime*
> level.  Last I saw the Base working group was trying to cut down BuildRequires
> (but sadly I haven't seen them fighting Requires yet - I would love
>  if someone did that for Perl)
> 
> If Ring 0 packages BuildRequire Ring 1 (or further)
> packages, ultimately their quality is going to be somewhat contingent
> on them.  Using bundling as a differentiator though, it does seem
> like there's likely a lot less pressure to require quick security
> updates for BuildRequires.
> 
> Anyways, something I think is missing from here is more
> details on how this "on the install media set" distinction
> is maintained over time.  If it isn't separate (yum) repositories
> it seems like it's going to be hard to enforce.
> 

Well, it already *is* a separate repository to create the build trees,
so we always have a clear picture of what's in them. (The Everything and
updates repos are always a superset).

> (Who would notice if a package in 0 started depending on a ring
>  1?  Would that imply the new dependency needed another
>  review pass?)

We'd have to be keeping an eye on the contents of the install trees and
yes, that would require a new review pass, in my current proposal. I'd
be willing to grant a blanket exception for packages that were in the
distro up to the acceptance of this proposal (rather than only those
that were on the install media) though.


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: [Proposal] Ring-based Packaging Policies

[Colin Walters]

On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:

> tl;dr Shall we consider requiring a lesser package review for packages
> that are not present on Product or Spin install media?

It's worth noting here that having two levels is not really going
to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
for quite a while:
https://help.ubuntu.com/community/Repositories/Ubuntu

I just have one question: You're defining this split at the *runtime*
level.  Last I saw the Base working group was trying to cut down BuildRequires
(but sadly I haven't seen them fighting Requires yet - I would love
 if someone did that for Perl)

If Ring 0 packages BuildRequire Ring 1 (or further)
packages, ultimately their quality is going to be somewhat contingent
on them.  Using bundling as a differentiator though, it does seem
like there's likely a lot less pressure to require quick security
updates for BuildRequires.

Anyways, something I think is missing from here is more
details on how this "on the install media set" distinction
is maintained over time.  If it isn't separate (yum) repositories
it seems like it's going to be hard to enforce.

(Who would notice if a package in 0 started depending on a ring
 1?  Would that imply the new dependency needed another
 review pass?)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

3 days without pushes ?

[Sérgio Basto]

Hi, .

2015-02-09 20:13:21
This update has been submitted for stable by sergiomb  .

Today is 12 and still not pushed, how we can devel when have to wait 3
days to a push ? , pushes should be regular and not random . 
What happened last 3 days ?  Seems that I'm not lucky when I push
things , in weekends sometimes I have to wait 48 hours . 

Thanks, 
-- 
Sérgio M. B.

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

[Proposal] Ring-based Packaging Policies

[Stephen Gallagher]

(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)

tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?

== Premise ==

So, some time ago, we started talking about dividing up the Fedora
package set into a series of "rings". One of the driving purposes behind
this idea was to re-evaluate our policies for packaging in each of these
rings. A fair amount of time has passed and no formal discussions have
taken place (that I have seen, at any rate), so I'm going to provide
here a simple "starter" proposal that we can work from and see where it
leads.

To begin, I'll try to identify some of the major advantages and
disadvantages in our current policies. (In no particular order...)

=== Advantages ===
* Consistency: every shared library, language-specific module and
application should have packaging consistent with others in its
category. This makes it easier for comaintainers and provenpackagers to
pick it up and work on it.

* The no-bundled-libraries policy means that when a library module
requires an update, it means that only one package needs to be modified
in order to enhance all applications on the system that consumes it.
This is a significant time-saver when it comes to dealing with
(increasingly common) security vulnerabilities.

* Package review "front-loads" the task of educating the packagers. It
guarantees that packages enter the collection by meeting a very high
standard. This does a great deal to accomplish the "consistency"
mentioned above.

* Legal review and the FPCA ensures that Fedora remains true to its
"Freedom" Foundation (as well as protecting Fedora contributors from the
perils of the international legal system).

=== Disadvantages ===
* Very strict policies often leads to potential packagers giving up.

* Package reviews for less-interesting packages (such as those for less
popular SIGs) often remain un-reviewed for weeks, months or even years.

* The package policies are only ever reviewed during the initial
creation of the package. Once that initial (high) hurdle is cleared, the
packager essentially has free reign to do whatever they want with their
package. This sometimes means that as time passes, the spec files
"bit-rot" or otherwise start accumulating other inconsistencies. (A
common example is the package whose upstream starts bundling a library
without the packager noticing).

* Many upstream projects do not concern themselves with being "in" any
particular distribution (with the notable example being the
Debian/Ubuntu flavors which have amassed a sufficient apparent userbase
that they sometimes get special treatment). For a variety of reasons,
this often leads directly to bundling the vast majority of their
dependencies. This is done for many reasons, but the two most common are
supportability and portability; it's impossible for many upstreams to
actually QA their package with every possible distro library. Instead,
if they ship everything they depend on, they can guarantee *that*
specific combination. This moves the responsibility from the
distribution to the upstream package to maintain their bundled
libraries.

* With many languages, there is no possibility of installing multiple
versions of the same library on the same system, so if an application
requires a newer or older version of the library than is in Fedora to
run, it fails. For those languages that *do* allow this, it still adds a
significant maintenance burden on the packagers to keep multiple
versions of the same package up-to-date (which gets particularly hard
when upstream abandons a version that something else in Fedora depends
on...)


== Analysis ==
First, I will make an assumption based on the "First" Foundation: We as
the Fedora Project want people to have access to the software that they
desire. We may disagree on how that is to be achieved, but I believe the
goal is the same.

Second, I will call attention to the fact that different Fedora users
have very different needs from the software. For example, those running
Fedora Server and Fedora Cloud are likely far more concerned with Fedora
as a *deployment* platform than they are as a *development* platform.
Folks running Fedora Workstation or the KDE spin are likely to be
somewhat more interested in the development side of things (though not
exclusively).

Packaging software for development and packaging it for real-world
deployment can be very different. I'm not going to attempt to identify
all the ways that this can be the case in this email. Others have done
so with great verbosity in the past and I will not attempt to re-hash
them.

Thirdly, I will note (again) that many upstream projects have moved away
from a distro-centric model. This is in part because unlike in the past,
there are a great many distributions out there now, all with individual
packaging requirements to be inside those distros. Taken in concert with
the behaviors of many

Re: Firefox addon signing

[Reindl Harald]

Am 12.02.2015 um 18:53 schrieb Simo Sorce:

Maybe it is only about preventing people from bundling the official
Firefox version with dodgy add-ons.  Not downright malware, but things
users may not actually want without realizing it.  The signature
checking means that those who prepare the downloads can no longer use
the unmodified upstream binary.  Which in turn might force them not to
use Mozilla brands.

Maybe this is a bit far-fetched, but after hours of staring at other
people's code today, it seems pretty reasonable to me.

But what do add-on developers do?  Surely there is a way to disable this
somehow?


Mozilla stated they will have to use the Developer Version (Aurora was
the name ?) or the nightlies ...


than Fedora needs to switch to the developer version if that *really* 
can't be disabled via about:config - that is a unacceptable restriction 
until hmtlvalidator, livehttpheaders and friends are available sigend 
via the mozilla page




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: Firefox addon signing

[Simo Sorce]

On Thu, 2015-02-12 at 18:19 +0100, Florian Weimer wrote:
> On 02/12/2015 04:53 PM, Simo Sorce wrote:
> > On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
> >>> or simply exempt signature checking if
> >>> the extension is on disk. They should check on download only.
> >>
> >> That would defeat the entire purpose; malware is very commonly sideloading 
> >> extensions.
> > 
> > Malware can easily binary patch firefox to ignore verification,
> 
> Windows has Authenticode, which may change the equation somewhat.
> 
> > I do not
> > think trying to defeat sideloading with this kind of verification makes
> > much sense.
> 
> Maybe it is only about preventing people from bundling the official
> Firefox version with dodgy add-ons.  Not downright malware, but things
> users may not actually want without realizing it.  The signature
> checking means that those who prepare the downloads can no longer use
> the unmodified upstream binary.  Which in turn might force them not to
> use Mozilla brands.
> 
> Maybe this is a bit far-fetched, but after hours of staring at other
> people's code today, it seems pretty reasonable to me.
> 
> But what do add-on developers do?  Surely there is a way to disable this
> somehow?

Mozilla stated they will have to use the Developer Version (Aurora was
the name ?) or the nightlies ...

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: Firefox addon signing

[Florian Weimer]

On 02/12/2015 04:53 PM, Simo Sorce wrote:
> On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
>>> or simply exempt signature checking if
>>> the extension is on disk. They should check on download only.
>>
>> That would defeat the entire purpose; malware is very commonly sideloading 
>> extensions.
> 
> Malware can easily binary patch firefox to ignore verification,

Windows has Authenticode, which may change the equation somewhat.

> I do not
> think trying to defeat sideloading with this kind of verification makes
> much sense.

Maybe it is only about preventing people from bundling the official
Firefox version with dodgy add-ons.  Not downright malware, but things
users may not actually want without realizing it.  The signature
checking means that those who prepare the downloads can no longer use
the unmodified upstream binary.  Which in turn might force them not to
use Mozilla brands.

Maybe this is a bit far-fetched, but after hours of staring at other
people's code today, it seems pretty reasonable to me.

But what do add-on developers do?  Surely there is a way to disable this
somehow?

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Koji build failure: noarch vs. arch?

[gil]

Il 12/02/2015 16:50, Jerry James ha scritto:

Eek, sorry, got busy and forgot about this...

On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi  wrote:

I'm really not sure, but a scratch build here works fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062

Is there any changes to your local koji client config?

as i wrote in my e-mail titled "jni libraries fails in koji"
i have the same problem
i haven't done any changes in koji client config
contains
[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

As far as I can remember, the only change I have made is to add
anon_retry = yes.  This is what /etc/koji.conf currently contains:

[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

anon_retry = yes


You are just doing a 'fedpkg build' ?

Yes.


Would you like me to try and re-run it from here?

No, the package doesn't build properly with gcc 5.0.  I need to figure
out why and fix it before we try another build.

Also, note that somebody else is now seeing this problem (see gil's
message from a few minutes ago), so something definitely needs to be
fixed somewhere.  It would be good to track down the actual source of
the problem.  I'll jump onto gil's thread and comment.


--
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: Firefox addon signing

[Michael Catanzaro]

On Thu, Feb 12, 2015 at 9:53 AM, Simo Sorce  wrote:
Malware can easily binary patch firefox to ignore verification, I do 
not
think trying to defeat sideloading with this kind of verification 
makes

much sense.


And if you've already installed malware with on your computer, don't 
you kind of have bigger things to worry about than whether or not it 
can be loaded as a Firefox extension?
-- 
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: Firefox addon signing

[Daniel P. Berrange]

On Thu, Feb 12, 2015 at 09:54:16AM -0500, Miloslav Trmač wrote:
> > or simply exempt signature checking if
> > the extension is on disk. They should check on download only.
> 
> That would defeat the entire purpose; malware is very commonly
> sideloading extensions.

If we only exempt extensions installed by RPM it is reasonable to assume
that our new package review process would have validated there is no
malware present. Our package review process is serving the same kind of
purpose as Mozilla's extension review & signing process.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Firefox addon signing

[Alec Leamas]

On 12/02/15 16:53, Simo Sorce wrote:


Malware can easily binary patch firefox to ignore verification, I do not
think trying to defeat sideloading with this kind of verification makes
much sense.
Of course you may decide to exempt only extensions in non-user-writable
locations, if you are on Linux and the Firefox binary is read-only for
the user.


Besides the technical issues, what does upstream permit? Since we havn't 
re-branded firefox, are we free to modify this whatever way we want? I 
can see the argument for upstream to limit such modifications without 
re-branding.


Cheers!

--alec

--
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: Firefox addon signing

[Simo Sorce]

On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
> > or simply exempt signature checking if
> > the extension is on disk. They should check on download only.
> 
> That would defeat the entire purpose; malware is very commonly sideloading 
> extensions.

Malware can easily binary patch firefox to ignore verification, I do not
think trying to defeat sideloading with this kind of verification makes
much sense.
Of course you may decide to exempt only extensions in non-user-writable
locations, if you are on Linux and the Firefox binary is read-only for
the user.

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: jni libraries fails in koji

[Jerry James]

On Thu, Feb 12, 2015 at 8:29 AM, gil  wrote:
> Hi
> try to build leveldbjni but is mistakenly seen as a package noarch
> any ideas?
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=8909564

Possibly related to this thread:
https://lists.fedoraproject.org/pipermail/devel/2015-January/207322.html

Also, I just had another instance of this pop up, with an attempt to build csdp:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8909645

Does anybody have any clue as to what is going wrong?
-- 
Jerry James
http://www.jamezone.org/
-- 
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: Koji build failure: noarch vs. arch?

[Jerry James]

Eek, sorry, got busy and forgot about this...

On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi  wrote:
> I'm really not sure, but a scratch build here works fine:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062
>
> Is there any changes to your local koji client config?

As far as I can remember, the only change I have made is to add
anon_retry = yes.  This is what /etc/koji.conf currently contains:

[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

anon_retry = yes

> You are just doing a 'fedpkg build' ?

Yes.

> Would you like me to try and re-run it from here?

No, the package doesn't build properly with gcc 5.0.  I need to figure
out why and fix it before we try another build.

Also, note that somebody else is now seeing this problem (see gil's
message from a few minutes ago), so something definitely needs to be
fixed somewhere.  It would be good to track down the actual source of
the problem.  I'll jump onto gil's thread and comment.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

jni libraries fails in koji

[gil]

Hi
try to build leveldbjni but is mistakenly seen as a package noarch
any ideas?
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=8909564
--
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: Firefox addon signing

[Miloslav Trmač]

> or simply exempt signature checking if
> the extension is on disk. They should check on download only.

That would defeat the entire purpose; malware is very commonly sideloading 
extensions.
Mirek
-- 
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: Firefox addon signing

[Simo Sorce]

On Thu, 2015-02-12 at 09:16 -0500, Miloslav Trmač wrote:
> > On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
> > > A better way would be to add a "Fedora Signature" in addition to
> > > mozilla's and use that for packaged extensions.
> > > But that would require work on the build system (koji) side.
> > 
> > The RPMs deploying the packaged extension are already signed and those
> > signatures are checked at time of package install. So it seems like
> > firefox merely needs to be taught that the pre-packaged extensions
> > deployed by RPM are pre-verified, so it can skip its verification
> > for those, while still doing verification for stuff that is live
> > downloaded
> 
> Yes, that does seem like the most practical way and reasonably secure
> way to handle this; it might make Mozilla unhappy anyway.
> 
> Firefox is really doing this to fight malware that has probably
> actually received (possibly unintended) permission from the user to
> install itself into the system, which often includes getting
> Administrator rights.  So, to mirror that Mozilla intent exactly, even
> RPM-deployed extensions should require a Mozilla signature.
> 
> OTOH, once you give malware root rights, it can in principle modify
> Firefox to skip the check, so this is only a hurdle, not a reliable
> feature.  Equally, verifying the RPM extension contents against the
> RPM database and checking the RPM signature would be useless because
> the malware can just add its key to the keys RPM uses for
> verification.
> 
> The Mozilla blog also mentions some “third option” for “extensions
> that will never be publicly distributed and will never leave an
> internal network”, presumably bypassing the need to have them signed
> by Mozilla.  Could that be used by Fedora?

There is a forum/faq answer somewhere that they will provide a signing
server where you have to go through the same process as for normal
extensions, only you do not end up publishing them.

I am not convinced this is a good idea, some people may simply not want
to trust even mozilla (may have secrets stored in the extension or
something), so I think mozilla should be smarter and allow people to
install their own signing keys, or simply exempt signature checking if
the extension is on disk. They should check on download only.

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: Firefox addon signing

[Miloslav Trmač]

> On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
> > A better way would be to add a "Fedora Signature" in addition to
> > mozilla's and use that for packaged extensions.
> > But that would require work on the build system (koji) side.
> 
> The RPMs deploying the packaged extension are already signed and those
> signatures are checked at time of package install. So it seems like
> firefox merely needs to be taught that the pre-packaged extensions
> deployed by RPM are pre-verified, so it can skip its verification
> for those, while still doing verification for stuff that is live
> downloaded

Yes, that does seem like the most practical way and reasonably secure way to 
handle this; it might make Mozilla unhappy anyway.

Firefox is really doing this to fight malware that has probably actually 
received (possibly unintended) permission from the user to install itself into 
the system, which often includes getting Administrator rights.  So, to mirror 
that Mozilla intent exactly, even RPM-deployed extensions should require a 
Mozilla signature.

OTOH, once you give malware root rights, it can in principle modify Firefox to 
skip the check, so this is only a hurdle, not a reliable feature.  Equally, 
verifying the RPM extension contents against the RPM database and checking the 
RPM signature would be useless because the malware can just add its key to the 
keys RPM uses for verification.

The Mozilla blog also mentions some “third option” for “extensions that will 
never be publicly distributed and will never leave an internal network”, 
presumably bypassing the need to have them signed by Mozilla.  Could that be 
used by Fedora?
Mirek
-- 
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: Firefox addon signing

[drago01]

On Thu, Feb 12, 2015 at 1:53 PM, Daniel P. Berrange  wrote:
> On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
>> On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
>>  wrote:
>> > On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth 
>> > wrote:
>> >
>> > I'm sure those that need to know, know, but for those that haven't heard[1]
>> > Mozilla's official Firefox build will enforce addons to contain a Mozilla
>> > signature without any runtime option to disable the check. Initially this
>> > prevents Fedora packaged addons since they are unsigned. The Mozilla 
>> > signing
>> > process takes time and can't be part of a package building process. Is
>> > Fedora going to get authorization to build Firefox with a runtime disable
>> > option?
>> >
>> >
>> > If the only way is to completely disable this feature, I'd prefer we don't.
>> > I wouldn't like for us to ship a less secure build of Firefox.
>>
>> A better way would be to add a "Fedora Signature" in addition to
>> mozilla's and use that for packaged extensions.
>> But that would require work on the build system (koji) side.
>
> The RPMs deploying the packaged extension are already signed and those
> signatures are checked at time of package install. So it seems like
> firefox merely needs to be taught that the pre-packaged extensions
> deployed by RPM are pre-verified, so it can skip its verification
> for those, while still doing verification for stuff that is live
> downloaded

Oh indeed. It is probably sufficient to just check the signature of
non system wide extensions.
-- 
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: Firefox addon signing

[Daniel P. Berrange]

On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
> On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
>  wrote:
> > On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth 
> > wrote:
> >
> > I'm sure those that need to know, know, but for those that haven't heard[1]
> > Mozilla's official Firefox build will enforce addons to contain a Mozilla
> > signature without any runtime option to disable the check. Initially this
> > prevents Fedora packaged addons since they are unsigned. The Mozilla signing
> > process takes time and can't be part of a package building process. Is
> > Fedora going to get authorization to build Firefox with a runtime disable
> > option?
> >
> >
> > If the only way is to completely disable this feature, I'd prefer we don't.
> > I wouldn't like for us to ship a less secure build of Firefox.
> 
> A better way would be to add a "Fedora Signature" in addition to
> mozilla's and use that for packaged extensions.
> But that would require work on the build system (koji) side.

The RPMs deploying the packaged extension are already signed and those
signatures are checked at time of package install. So it seems like
firefox merely needs to be taught that the pre-packaged extensions
deployed by RPM are pre-verified, so it can skip its verification
for those, while still doing verification for stuff that is live
downloaded

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Firefox addon signing

[Florian Weimer]

On 02/12/2015 11:15 AM, Nikos Roussos wrote:
> On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth 
> wrote:
>> Is Fedora going to get authorization to build Firefox with a runtime
>> disable option?
> 
> If the only way is to completely disable this feature, I'd prefer we don't.
> I wouldn't like for us to ship a less secure build of Firefox.

It's not the only way, you can also patch the Firefox binary on disk to
disable the check.  You can even run a copy in case you cannot modify
the original version due to file system permissions.

This is why I don't see how this can be a security improvement, at least
not on Fedora.  If it really cannot be disabled, it will also cause
problems for centrally managed Firefox deployments which need to
pre-install add-ons into user profiles.

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Firefox addon signing

[drago01]

On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
 wrote:
> On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth 
> wrote:
>
> I'm sure those that need to know, know, but for those that haven't heard[1]
> Mozilla's official Firefox build will enforce addons to contain a Mozilla
> signature without any runtime option to disable the check. Initially this
> prevents Fedora packaged addons since they are unsigned. The Mozilla signing
> process takes time and can't be part of a package building process. Is
> Fedora going to get authorization to build Firefox with a runtime disable
> option?
>
>
> If the only way is to completely disable this feature, I'd prefer we don't.
> I wouldn't like for us to ship a less secure build of Firefox.

A better way would be to add a "Fedora Signature" in addition to
mozilla's and use that for packaged extensions.
But that would require work on the build system (koji) side.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned Packages in branched (2015-02-12)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

bfgminerorphan, pwouters   0 weeks ago   
clc-intercalorphan, iarnell0 weeks ago   
coneorphan, steve  0 weeks ago   
dbus-tools  orphan, miminar0 weeks ago   
dircproxy   orphan, jwilson, kevin 0 weeks ago   
egtkorphan, cicku, odysseus, raphgro   0 weeks ago   
fldigi-doc  orphan, dp67   0 weeks ago   
ip6sic  orphan, davej  0 weeks ago   
isicorphan, davej  0 weeks ago   
javasqlite  orphan 0 weeks ago   
mate-user-share orphan, raveit65, vicodan  0 weeks ago   
maven-anno-plugin   orphan, goldmann   0 weeks ago   
mojomojoorphan, iarnell, perl-sig  0 weeks ago   
ninja   orphan, adrian 0 weeks ago   
pympdtouchgui   orphan, slankes0 weeks ago   
python-asyncmongo   orphan, silas  0 weeks ago   
python-gflags   orphan, silas  0 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro0 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma0 weeks ago   
zukini  orphan, odysseus   0 weeks ago   
zukiwi  orphan, odysseus   0 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2015-02-10 (0 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2015-02-10 (0 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (22): bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (branched) for at least 6 weeks (dependend on) (0):


Orphans  (branched)(not depended on) (20): bfgminer clc-intercal cone
dbus-tools dircproxy egtk fldigi-doc ip6sic isic mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
umlgraph visualvm xnoise zukini zukiwi


Orphans (branched) for at least 6 weeks (not dependend on) (0):


Depending packages (branched) (2): starcal weka


Packages depending on packages orphaned (branched) for more than 6
weeks (0):

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned Packages in rawhide (2015-02-12)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

ale orphan, cicku, silfreed0 weeks ago   
bfgminerorphan, pwouters   2 weeks ago   
clc-intercalorphan, iarnell13 weeks ago  
coneorphan, steve  13 weeks ago  
dbus-tools  orphan, miminar14 weeks ago  
dircproxy   orphan, jwilson, kevin 5 weeks ago   
egtkorphan, cicku, odysseus, raphgro   3 weeks ago   
fldigi-doc  orphan, dp67   12 weeks ago  
ip6sic  orphan, davej  5 weeks ago   
isicorphan, davej  5 weeks ago   
javasqlite  orphan 8 weeks ago   
mate-user-share orphan, raveit65, vicodan  1 weeks ago   
maven-anno-plugin   orphan, goldmann   8 weeks ago   
mojomojoorphan, iarnell, perl-sig  13 weeks ago  
ninja   orphan, adrian 1 weeks ago   
pympdtouchgui   orphan, slankes4 weeks ago   
python-asyncmongo   orphan, silas  9 weeks ago   
python-gflags   orphan, silas  9 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro9 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma5 weeks ago   
zukini  orphan, odysseus   3 weeks ago   
zukiwi  orphan, odysseus   3 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2014-12-12 (8 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2014-12-09 (9 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: ale, egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
silfreed: ale
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (23): ale bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (rawhide) for at least 6 weeks (dependend on) (2): javasqlite
python-gflags


Orphans  (rawhide)(not depended on) (21): ale bfgminer clc-intercal
cone dbus-tools dircproxy egtk fldigi-doc ip6sic isic
mate-user-share maven-anno-plugin mojomojo ninja pympdtouchgui
python-asyncmongo umlgraph visualvm xnoise zukini zukiwi


Orphans (rawhide) for at least 6 weeks (not dependend on) (8):
clc-intercal cone dbus-tools fldigi-doc maven-anno-plugin mojomojo
python-asyncmongo umlgraph


Depending packages (rawhide) (2): starcal weka


Packages depending on packages orphaned (rawhide) for more than 6
weeks (2): starcal weka

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapr

Re: Firefox addon signing

[Nikos Roussos]

On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth  
wrote:
I'm sure those that need to know, know, but for those that haven't 
heard[1]
Mozilla's official Firefox build will enforce addons to contain a 
Mozilla signature

without any runtime option to disable the check.

Initially this prevents Fedora packaged addons since they are 
unsigned. The Mozilla
signing process takes time and can't be part of a package building 
process.


Is Fedora going to get authorization to build Firefox with a runtime 
disable option?


If the only way is to completely disable this feature, I'd prefer we 
don't.

I wouldn't like for us to ship a less secure build of Firefox.
-- 
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 Mass Branching

[Peter Robinson]

h>> Hi All,
>>
>> Fedora 22 has been branched, please be sure to do a git pull --rebase to
>> pick up the new branch, as an additional reminder rawhide/f23 has had
>> inheritance cut off from previous releases,  so this means that
>> anything you do for f22 you also have to do in the master branch and do
>> a build there. This is the same as we did for previous Fedora releases
>
>
> Is the koji rawhide repo not pointing to the new F23 builds/repo somehow?
> My otf2-1.5.1-1.fc23 build doesn't appear to be showing up.
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498

It's pointed to f-23 just fine
http://koji.fedoraproject.org/koji/buildtargetinfo?name=rawhide
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct