Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Rahul Sundaram]

Hi


On Wed, Jan 4, 2023 at 10:38 AM Neal Gompa  wrote:

> On Wed, Jan 4, 2023 at 10:25 AM Chuck Anderson  wrote:
>
> > Perhaps this can be modified to create a layout that matches dist-git?
>
> Probably not, because Dist-Git is a Fedora-specific thing, so I
> wouldn't accept such a change in rpmdevtools upstream.
>
>
You can add it with a --distro flag

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaning packages

[Rahul Sundaram]

Hi

I have orphaned all the packages I used to maintain but haven't had the
time to keep up with in a long time.  Feel free to pick them up if you
like.  All the best.

https://src.fedoraproject.org/rpms/chocolate-doom
https://src.fedoraproject.org/rpms/gif2png
https://src.fedoraproject.org/rpms/ghasher
https://src.fedoraproject.org/rpms/wv
https://src.fedoraproject.org/rpms/python-bottle
https://src.fedoraproject.org/rpms/python-bottle-sqlite

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Rahul Sundaram]

Hi


On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:

>
> DNF team has experience with replacing of YUM in Fedora and RHEL. It give
> us an advantage to not repeat the same mistakes. We already know that
> shipping DNF as YUM was not a good idea.
>

This response really doesn't clarify what the end result is supposed to be.
  Are you planning to maintain a symlink from DNF and Yum to DNF5 after the
transition is complete or not?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: status update on "ostree native containers"

[Rahul Sundaram]

Hi

On Tue, Sep 27, 2022 at 6:09 PM Colin Walters wrote:

> We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
> in Fedora 36 and a lot has happened since then.
>
> One of the biggest things is that rpm-ostree now knows how to
> intelligently generate reproducible "chunked" container images.
>
> I'll describe this by also highlighting another big change; Fedora CoreOS
> is now shipped as a properly manifest listed container image alongside the
> other Fedora images on quay.io:
> https://quay.io/repository/fedora/fedora-coreos


FYI, the command in that page doesn't appear to be working because "latest"
is the default tag if you don't specify one for docker and it doesn't
exist, so you have to append ":stable" or something like that.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5 wants to replace regular rpms with modules

[Rahul Sundaram]

Hi

On Fri, Sep 23, 2022 at 9:50 AM Jaroslav Mracek wrote:

> Correct, the modular filtering is not yet implemented and this is the last
> blocker for rawhide release.
>

Quick notes from what I am seeing with limiting testing using the copr repo

* Performance is much better
* Search seems busted, no output at all
* "update" seems to have been dropped (and
/usr/lib/dnf5/aliases.d/compatibility.conf didn't appear to be user
configurable). update should really be kept as a compatibility alias
* Install is overtly verbose

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)

[Rahul Sundaram]

Hi

On Thu, Apr 7, 2022 at 5:33 PM Matthew Miller  wrote:

>
> I don't think we should characterize the Changes process in this way.
> Fedora
> is a place for experimentation, and if a proposal is rejected, it is
> totally
> appropriate to adjust that proposal based on feedback and re-submit.
>

Partly, I think this confusion is because the change process doesn't
differentiate at the status or summary level between rejected: we don't
think this is ever going to happen vs rejected:  this looks like a good
idea but the timeline doesn't look great, break it down and go slower vs
rejected:  we don't think this is fully baked yet or we want to get some
more clarity, come back after you have the answers.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Rahul Sundaram]

Hi

On Tue, Apr 5, 2022 at 6:59 PM Kevin Kofler  wrote:

>
> > Current owners plan to orphan some packages regardless of whether the
> > proposal is accepted.
>
> And that is completely unacceptable blackmailing.
>

Blackmail is always conditional.  Stating openly that someone is going to
do something unconditionally is just disclosure.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+ (new report)

[Rahul Sundaram]

Hi

On Mon, Mar 7, 2022 at 11:29 AM Michael Catanzaro  wrote:

> On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto



> > Hi,
> > In resume glib still required for 20 packages  [1],
> > apart of the sweet memories that some package bring to us , any of
> > these packages is needed ? or haven't replacement ?
>
> The maintainer is unwilling to retire them.
>
> I think we should ask FESCo to force them to be retired. It's confusing
> to have ancient versions of the packages in the distro, and they will
> stick around forever if not
>

Instead of forcing a mandate to remove it, perhaps a migration to Copr
would be a better way out of this

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Wed, Mar 2, 2022 at 11:40 AM Matthew Miller wrote:

> On Thu, Feb 24, 2022 at 08:13:15PM +0100, Zbigniew Jędrzejewski-Szmek
> wrote:
> > It would probably be good to use more of those features, but you need
> > to understand the service very well to know what systemd security
> > features can be enabled for it.
>
> I'd definitely love to see us put more effort into this — but we don't have
> any specific resources for this kind of thing, so it needs to be someone's
> labor of love.
>
> See https://pagure.io/packaging-committee/issue/667 as a first start...
>

I am surprised that security engineering folks aren't driving this but no
one else is volunteering, I can. It feels like there should be some easy
wins here even if we don't get hyper granular about the features we enable.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Thu, Mar 3, 2022 at 5:07 PM Lennart Poettering  wrote:

>
> There have been various requests of generalizing this, and making it
> available for any kind of service, not just portable services. I'd be
> onboard with that actually, but there are some unanswered questions
> regarding how distros and packages would start switching to a world of
> profiles, where suddenly things are locked down by default. But it
> would be a different model then: instead of individually turning on
> knobs, each software would pick a profile to use, and every year or so
> would be expected to update to a more current profile with stronger
> protections. If it doesn't do that it would continue to work, but it
> would be clear it is security-wise out of date.
>

All of this sounds pretty nice, I would certainly be interested in adopting
something like at work and will try to keep an eye on PR's related to
this.  Feel free to tag me for testing/feedback etc whenever this is being
worked on, would be happy to help.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Thu, Mar 3, 2022 at 9:51 AM Lennart Poettering wrote:

>
> Yes, opt-out would be better than opt-in, but it would be a major
> compat break, UNIX software doesn't expect to be sandboxed, so if you
> sandbox everything out-of-the-box you'll be drowning in bugs, and the
> failure modes are not overly nice, i.e. you'll mostly rely on
> EPERM/EACCES hopefully being logged sanely by the relevant software.
>
> ProtectHome= for example implies that a separate mount namespace is
> allocated for each service. if you enable that for *all* services at
> once, then this means all services will suddenly live in their own
> mount namespaces, and the mount they establish will not propagate
> elsewhere anymore. Thus you broke at least udisks, storaged, homed,
> systemd-runtime-dir@.service and these kinds of things — because they
> exist precisely to establish mounts in the system.
>

What I would suggest here is we make it easier to adopt the opt out model
by explicitly setting services to opt out for things they can't handle, ie)
if a core set of services we ship within Fedora itself needs some
permissions including ProtectHome to false, push for upstream/distro to
have those knobs to be false explicitly within the service so the
permissions it needs are more clearly documented within the service itself
and then if a hardened variant of a distro or a sysadmin wants to flip the
model, they will have a considerably easier time with this.  Nagging is a
good starting point but doesn't go far enough.  The adoption of these
features is still very low.  We can do better.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Thu, Mar 3, 2022 at 8:18 AM Zbigniew Jędrzejewski-Szmek wrote

>
> What do you mean by "global service overrides"?


Currently security hardening features are opt-in.  You will have to set it
on a per service level.   What I would prefer to see is the ability to have
an opt out of hardening features ie) the ability to set an override for all
systemd services such that it uses ProtectHome as an example and then
individual services can opt out.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Wed, Mar 2, 2022 at 12:31 PM Zbigniew Jędrzejewski-Szmek wrote:

> On Thu, Feb 24, 2022 at 02:28:56PM -0500, Rahul Sundaram wrote:
> > Ability to modify these policies via configuration (the above one looks
> > like a build config) and ability to do global overrides and set the
> > hardening features across all services so distributions or sysadmins can
> > configure those would be helpful
>
> It's a runtime config. Agreed with the rest though, and what
> Matthew Miller said in the other reply: volunteers welcome ;)
>

Just to be clear, there is no support for global service overrides in
systemd but you are willing to accept patches for it?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: unsafe systemd setup in Fedora

[Rahul Sundaram]

Hi

On Thu, Feb 24, 2022 at 2:14 PM Zbigniew Jędrzejewski-Szmek

>
> Systemd 250 (coming in F36), has --security-policy switch which can be
> used to enable/disable some of the checks. There is no way to tell
> systemd-analyze that things about a specific unit though.
>

Ability to modify these policies via configuration (the above one looks
like a build config) and ability to do global overrides and set the
hardening features across all services so distributions or sysadmins can
configure those would be helpful

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Rahul Sundaram]

Hi

On Wed, Nov 10, 2021 at 12:05 PM Lyes Saadi wrote:

>
> (Also, I just want to insist I am not pushing nor advising anyone to do
> something breaking Discord's TOS without their approval, I'm just
> thinking of examples of external demand for a Discord package in Fedora.)
>

https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications is
intended to address that

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: video meeting to discuss Matrix/Element and IRC

[Rahul Sundaram]

Hi

On Thu, Nov 19, 2020 at 7:56 PM Dominik 'Rathann' Mierzejewski  wrote:

>
> No, you don't. I've just joined a random room without any kind of
> registration. Try it yourself if you don't believe me:
> https://app.element.io/#/room/#lounge:privacytools.io
>

You are able to view it but are you able to participate?  If not, you
haven't joined

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Rahul Sundaram]

Hi

On Fri, Nov 13, 2020 at 5:54 PM Matthew Miller 
wrote:

> On Fri, Nov 13, 2020 at 05:46:46PM -0500, Rahul Sundaram wrote:
> > I think for a community distro, having it all in a single repo is
> > technically better as well because part of the problem that was being
> > solved by the merge was not just the community Red Hat delineation but
> also
> > the issue of build dependencies - core packages couldn't depend on
> packages
> > from extras and by splitting up repos again you will reintroduce the same
> > problems.  So don't do that.  What you need is some metadata and the
>
> But that's policy as well. It would be reasonable to have a different
> policy, like "build and soft dependencies are okay from base -> secondary,
> but not hard runtime requirements".
>

Partly yes, some of it could be solved by policy but we didn't have soft
dependency capability back then so we were limited even more technically
but even now, you are proposing not having cross repo runtime deps which
also will end up being problematic.  Using metadata for this allows you to
do well supported, lightly supported and the notion of playground etc all
in one repo and if a package gets better, you can just update the metadata
without having to move around packages which is a pain point for all the
mirrors.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Rahul Sundaram]

Hi

On Fri, Nov 13, 2020 at 5:23 PM Matthew Miller wrote:

> That reason was _mainly_ to erase the inside Red Hat,
> community-around-the-edges distinction. That was a huge success and Fedora
> wouldn't be interesting without that. But I think the _technical_ choice
> was
> in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way.
>

I think for a community distro, having it all in a single repo is
technically better as well because part of the problem that was being
solved by the merge was not just the community Red Hat delineation but also
the issue of build dependencies - core packages couldn't depend on packages
from extras and by splitting up repos again you will reintroduce the same
problems.  So don't do that.  What you need is some metadata and the
capability for the client tooling to expose that metadata so users can make
informed choices on what they are installing and that can be as flexible as
you want it to be.   apt-listbugs etc does similar things.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Boian Bonev

[Rahul Sundaram]

Hi

On Fri, Oct 2, 2020 at 4:57 PM Boian Bonev  wrote:

>
> I didn't start that project, just improved it, and somehow changing the
> name does not seem right to me :)
>

This isn't a minor change and the current name is a bit awkward and because
of a shared name, you have to deal with Conflicts or alternatives neither
of help with ease of use ex: I want to install them both to compare them
side by side.  I would agree with Matthew that a name change is warranted
here.  At the minimum, rename the binary.  Here is a parallel for that

https://github.com/rpm-software-management/createrepo_c

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Rahul Sundaram]

Hi

On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:

> These "qualifiers" are important.
>
> 1) Yes, I did get a response, as I said in the first email. The response
> showed that there weren't any issues with the kernel or core packages at
> the
> time it was dropped.
>

What you originally said - "I asked for a list of issues that warranted
ending 32 bit
support while it still worked, and got nothing"


> 2) I never said it was perfect, nothing ever is.
>

What you originally said - ". When it came down to it, it was dropped while
32 bit
Fedora still worked perfectly."

We are done here

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Rahul Sundaram]

Hi

On Fri, Jul 3, 2020 at 2:14 AM John M. Harris  wrote:

>
> None of those bugs were release blocking, and none of them meant that x86
> wouldn't boot, or that core packages didn't work
>

When you add so many qualifiers, you are now admitting a) you did get a
response b) that things weren't perfect as you claimed.  Those were merely
examples anyway.  You can find plenty more in past discussions long before
the decision was made.  You cannot possibly believe that an architecture
maintenance only involves a handful of bugs. It requires substantial
resources which aren't free.  If you want to reduce your claim to the "many
bugs that did exist and added additional maintenance burden didn't affect
me personally therefore I disagree with the decision made", now that would
be a more reasonable statement if one didn't keep bringing it up in
unrelated discussions.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Rahul Sundaram]

Hi

On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:

>That's a link to the release announcement.

Hardly the first time it was announced. It refers to x86_32 sig that was
formed much earlier which itself was a response to an earlier warning that
x86_32 support is going away unless people stepped up to support it.  Feel
free to look up the threads on that and read up on that history.  There was
plenty of time and opportunity for people to step in.  Noone was interested
enough AND had the time/skills to do it.

What you earlier claimed was -> I asked for a list of issues that warranted
> > ending 32 bit support while it still worked, and got nothing.

This isn't true.  You did get a response with links to bugs and your other
claim that these systems worked perfectly isn't correct objectively.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Rahul Sundaram]

HI

On Thu, Jul 2, 2020 at 4:54 PM John M. Harris Jr

> That's not really true. When it came down to it, it was dropped while 32
> bit
> Fedora still worked perfectly. I'm left with 5 systems that will never be
> updated as a result. I asked for a list of issues that warranted ending 32
> bit
> support while it still worked, and got nothing. Two weeks after the
> proposal,
> the announcement was made, and support was dropped.
>

This is just not true at all.   32-bit was bitrotting and community support
didn't pan out

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

"This was last proposed with Fedora 27, but it was deferred as an i686 SIG
was to be created to handle issues going forward. That SIG has been largely
unresponsive."

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Rahul Sundaram]

Hi

On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:

>
> Thanks, I am well aware. That wasn't really the topic here.
>

If there is a repeated feeling that anyone has that a particular edition
isn't what they are looking for, figuring out how to make a different set
of choices is and perhaps forming a community around their preferences is
pertinent.  This isn't addressed just to you.   Having said that, what do
you consider is the topic?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

[Rahul Sundaram]

Hi

On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson  wrote:

>
> No that doesn't help at all. It doesn't address what I wrote about many
> seeing a problem for the first time when a change is suggested and that
> this leads to more heated debates than needed.
> I also feel alienated by the target audience of Workstation since it
> pretty much only talks about developers and others.


It may very well be the case that workstation isn't what you are looking
for.  If you want to create your own remix or spin, one quick way to field
this is to create a package in copr or have an ansible playbook that sets
the defaults and configuration you want and gathering some feedback on
whether others find it useful.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Erich Eickmeyer

[Rahul Sundaram]

Hi Eric

On Fri, Jan 31, 2020 at 6:59 PM Erich Eickmeyer 
wrote:

> Hello all!
>
> I'm Erich, the current project leader of Ubuntu Studio, the
> creativity-oriented flavor of Ubuntu. I've been leading that project for
> the past two years.
>




> In order to do the Self-Contained Change Request required, I need to be
> CLA+1, so that's the motivation behind joining the packaging group or
> whatever other group anyone feels is relevant to this project.
>
> Thanks for reading!
> Erich Eickmeyer
>

Thanks for joining.  Sounds very interesting.  All the best

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Rahul Sundaram]

Hi

On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:

>
> Welcome to our lives!
> If it was mathematically possible to go above 100% that's how much
> agreement you
> would have from us.
>

If Red Hat is using Pagure internally, it is really odd to discuss
replacing Pagure with something else.  The only viable replacement is
Gitlab which is a open code project written in a language that isn't a
strong fit for Fedora. Red Hat should be assigning more resources
(development & infrastructure) to add the features needed to extend Pagure
going forward and reduce the burden on the CPE team.  Has CPE leadership
considered talking internally about that?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap-on-ZRAM by default

[Rahul Sundaram]

Hi

On Mon, Jan 27, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek wrote:

> It is "upstream" in the sense that it is under the same umbrella.
> There are no plans to move the code to the main repo, because it's in
> rust and currently combining meson which is used for systemd proper
> with rust and cargo is not very convenient.
>

A bit of a tangent but there was a proposal for systemd itself to start
using C++ at some point.  Was that or Rust still in consideration?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Rahul Sundaram]

Hi

On Fri, Dec 20, 2019 at 7:43 PM John M. Harris Jr  wrote:

> On Friday, December 20, 2019 5:33:59 PM MST Rahul Sundaram wrote:
>
> No, I mean the things that actually changed between the two. "What's new"
> or
> so on. This looks like it's just general documentation, and not release
> notes?
>

Nope.   Those are release notes and every section covers what's new.  Not
general documentation

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Rahul Sundaram]

Hi

On Fri, Dec 20, 2019 at 7:15 PM John M. Harris Jr 
wrote:

>
> > ...release notes are published on the docs site as they have always been:
> > https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/
>
> Where are the changes from the previous release there?
>

Do you mean 30?

https://docs.fedoraproject.org/en-US/docs/  click on 30

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing new anitya integration and de-orphaning process

[Rahul Sundaram]

Hi

On Mon, Dec 9, 2019 at 11:43 AM Pierre-Yves Chibon 
wrote:

>
> `Monitoring` means: you get a bugzilla ticket
> `Monitoring and scrach builds` means: you get the bugzilla ticket and an
> attempt to do a scratch build for the new version
>

I was wondering how hard it would be to open a pull request if a scratch
build was successful.  For minor version bumps, this can be helpful for
maintainers

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Rahul Sundaram]

Hi

On Wed, Oct 16, 2019 at 9:21 PM Neal Gompa  wrote:

> On Wed, Oct 16, 2019 at 9:17 PM Stephen Gallagher 
> wrote:
> >
> > On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram 
> wrote:
> > If that's the case, the most obvious way to inform you is to disallow
> > the upgrade and have you resolve it by doing a `dnf module remove bat`
> > and then rerunning the upgrade.
>

One could do that yes but it is helpful to have dnf essentially offer to do
this an option


>
> When "bat" was non-modular, we didn't require this. Why does it being
> a module change this? The underlying RPMs still have their
> dependencies satisfied. If they didn't, DNF would elect to offer its
> removal as part of the upgrade after passing "--allowerasing". This
> behavior is sane, useful, and understandable. I don't see a reason it
> wouldn't map cleanly to modular content.
>

Indeed.   Before --allowerasing was implemented by dnf and it gained the
feature to suggest that users run it to workaround broken dependencies, one
would manually be able to remove the dependencies and unbreak themselves
out of that problem and upgrading using yum wiki page did prominently
suggest that workaround.  Allowerasing was a step up in usability however
and I wouldn't want orphaned or broken modules to a hindrance to that.
Again, in the case of bat, the underlying breakages was blocking updates
for a while till I figured out the right steps.  So this isn't merely a
theoretical example either

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Rahul Sundaram]

Stephen Gallagher  wrote:

>
> Currently, our default stance has been "disallow the system upgrade if
> the modules they've locked onto won't be available there". This is
> based on our philosophy that ultimately "the app is what matters".
> Most people don't install Linux because they enjoy clicking buttons in
> Anaconda. They install Linux because they have an application they
> want to deploy
>

You have to consider that not all applications are as important as keeping
up with the distribution lifecycle itself.  If I have Fedora deployed in a
bunch of places, I need to be able to move to the next release which is
supported if the current release I am running is nearing EOL.  At that
point, if a module is orphaned and it happens to be a leaf application (say
the bat utility which is currently provided as a module and one I happen to
use), I don't really want it blocking my ability to upgrade.  I would
certain like to be informed about the fact but I would want to get to the
next release anyway.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Rahul Sundaram]

On Fri, Jul 14, 2017 at 1:27 PM Matthew Miller 
> > How about reliable online updates of running applications as a
> > benefit?
>
> AND the ability to roll back, to choose beta or stable streams, etc.
>

These are reasonably good advantages but if there isn't a seamless
transition between them, it induces a lot of pain.   For instance,  dnf
cannot install flatpak apps currently and I can't use kickstart to automate
installation in the same way etc.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New pastebin service on paste.fedoraproject.org

[Rahul Sundaram]

On Thu, Feb 23, 2017 at 1:29 PM Athos Ribeiro . I am not aware

> of the details on why we moved to this new paste, but I also agree that
> we do not need a fancy website for that and maybe that was not the
> reason we moved.
>

Seems pretty obvious it was done to get a more maintainable upstream
project.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Rahul Sundaram]

On Thu, Feb 23, 2017 at 11:04 AM Gerald B. Cox > wrote:

>
>
> So let's berate and silence someone because you thought they made "vague
> accusations"
>

Are you saying he didn't post an accusation and refused to elaborate when
asked or are you saying he did it and we should just ignore it or encourage
it anyway?

"My point wasn't restricted to this conversation"

Might be better to post a separate thread, preferably to the board list if
you want to raise a question on general moderation.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Rahul Sundaram]

On Wed, Feb 22, 2017 at 8:55 PM Gerald B. Cox wrote:

> It gets a bit tedious to read all the feigned outrage and the continuous
> aggrandisement of the Fedora Code of Conduct; it shouldn't be used as a
> construct to silence debate.
>

Vague accusations are not a debate.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Rahul Sundaram]

On Tue, Feb 21, 2017 at 5:00 AM Ralf Corsepius wrote:

> On 02/21/2017 01:02 AM, Rahul Sundaram wrote:
> >
> >
> > On Mon, Feb 20, 2017 at 6:42 PM Ralf Corsepius
> >
> >
> > No. Mr. Williamson's attitude towards the Fedora community makes it
> > impossible to answer
> >
> >
> > Without details, a vague discussion adds nothing meaningful to the
> > conversation.
>
> Yes, and? It's Mr. Williamson's responsibly.
>

What you are doing is filing a bug report with no way for anyone else to
reproduce it or resolve it and refusing to provide more info when asked.

CLOSED CANTFIX

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Rahul Sundaram]

On Mon, Feb 20, 2017 at 6:42 PM Ralf Corsepius

>
> No. Mr. Williamson's attitude towards the Fedora community makes it
> impossible to answer


Without details, a vague discussion adds nothing meaningful to the
conversation.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Container Minimal Image

[Rahul Sundaram]

On Wed, Feb 1, 2017 at 12:21 PM Matthew Miller

> It is the DNF team. I have a hope that these will be fronted by a
> command called "yum" which will implement close-to-full compatibility
> with Yum Classic
>

Would be nice to have this available in general Fedora releases by default
as well.  The yum -> dnf transition still feels like needless churn as a
end user tool but having a yum command just do the right thing as always
will help

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Rahul Sundaram]

On Tue, Dec 20, 2016 at 10:25 PM Gerald B. Cox  wrote:

>
> On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote:
>
> I don't see any context missing in a direct quote which I responded to.
> If you believe otherwise, feel free to summarize your position and include
> any context you need to.
>
>
> That's ok... I don't think you'd get the point - as I said the context was
> the thread.
>

I have read the thread.  If you are going to insist that I missed a context
repeatedly, I would recommend you explicitly state what it is without
making any assumptions about whether the other person can understand it.


Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Rahul Sundaram]

On Tue, Dec 20, 2016 at 9:59 PM Gerald B. Cox wrote:

>
> " KDE folks by and large want the updates as fast as possible.  If the
> GNOME folks would like
> their updates to age for six months, they can just keep them in
> updates-testing."
>
>
> Obviously you missed it.  Again, you have to take that comment in context
> of the entire thread.
>

I don't see any context missing in a direct quote which I responded to.  If
you believe otherwise, feel free to summarize your position and include any
context you need to.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Rahul Sundaram]

On Tue, Dec 20, 2016 at 9:33 PM Gerald B. Cox  wrote:

>
>
> Right.  I understand that but the solution of letting things stay in
> updates-testing for a long time isn't a great way to implement that.  It an
> abuse of updates-testing.
>
>
> No one is doing that.  You have to read the whole thread.
>

What makes you assume I didn't?  I am quoting you again

" KDE folks by and large want the updates as fast as possible.  If the
GNOME folks would like
their updates to age for six months, they can just keep them in
updates-testing."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Rahul Sundaram]

On Tue, Dec 20, 2016 at 9:26 PM Gerald B. Cox  wrote:

>
> I was just repeating what I thought was a good suggestion - which is based
> upon what has
> already been implemented using the current infrastructure.  Reserve "new"
> releases only for things
> that absolutely require it and let everything else be updated piecemeal.
>

Right.  I understand that but the solution of letting things stay in
updates-testing for a long time isn't a great way to implement that.  It an
abuse of updates-testing.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Rahul Sundaram]

On Tue, Dec 20, 2016 at 1:23 PM Gerald B. Cox wrote:

> Well, it isn't some theoretical construct... it's being done now with KDE
> and has
> been working just fine.  It stays in updates-testing until you decide to
> push it to stable.  KDE
> folks by and large want the updates as fast as possible.  If the GNOME
> folks would like
> their updates to age for six months, they can just keep them in
> updates-testing.   Seems
> like we're just making this more complicated than it is.
>

You can't keep things simmering in updates-stable for a long time.  What if
you need to push a bug fix or security fix that is not tied to a new major
upstream release?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Rahul Sundaram]

Hi

On Tue, Dec 13, 2016 at 12:00 PM Lennart Poettering
> Well, some of them are pretty drastic. For example, I think it would

> make a ton of sense to run all daemons where that's possible with
> ProtectSystem=strict. This would make the entire directory tree
> read-only for them (with the exception of API VFS, i.e. /proc, /sys,
> /dev), and then requires ReadWritePaths= to be used to whitelist the
> select few paths the service shall be able to write to.
>
> If we'd globally say that all services now run with
> ProtectSystem=strict by default, then we'd break pretty much all
> services that want to write something anywhere, until they get updated
> with the right ReadWritePaths= statements... And I have the suspicion
> that this kind of churn would upset quite a few people... I mean, I am
> all for breaking eggs to make an omelette, but not maybe not break all
> eggs in the egg carton at once ;-)


I am not sure anyone is suggesting breaking things.  There is a pretty
incremental approach to this which starts off with encouraging services to
whitelist things they need and when enough services do that,  toggle the
equivalent sandboxing feature by default and increase coverage over time.
If it requires every service to understand all the sandboxing features and
enable it manually, we aren't getting security features by default and we
really should.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Rahul Sundaram]

Hi

On Mon, Dec 12, 2016 at 4:03 PM Lennart Poettering
> Hmm, yeah, I should probably blog more about all the nice sandboxing

> features we have now in systemd.


It would be useful if we can set these type of options as system wide - for
both the distribution/vendor and for admin overrides with services that can
opt out rather than opt-in

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rahul Sundaram]

On Wed, Jun 15, 2016 at 11:45 AM James Hogarth wrote:

> Considering how this actively negates the security of our distribution and
> how this is being promoted in the media, with them pointing to the
> snapcraft site and the instructions there with COPR looking like it's on
> approved Fedora infrastructure (for those who don't understand anyone can
> COPR and there is no review) I honestly wonder if this is a good case for
> pulling a COPR repo...
>
> Would FESCO have authority here or is that going to be inadvisable a road?
>
Extremely inadvisable.   Copr exists in part for experimental packages.
When you enable a copr repo, you are warned that this is not part of the
official infrastructure and you are relying on the packager alone for any
support.   Pulling a COPR repo for anything other than violation of
published guidelines such as legal issues will look political even if you
have legitimate technical concerns about the quality of the software.   Do
you want Canonical to pull the Flatpak PPA because the quality of Flatpak
on Ubuntu isn't perfect?

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

Re: ZFS on linux

[Rahul Sundaram]

Hi

On Fri, Jan 15, 2016 at 11:42 PM, Gerald B. Cox wrote:

Kevin, I don't believe that is the case in this instance.  No one is
> talking about mixing code.  If you do have something however specifically
> regarding the FSF stance on
> ZFS, I'd like to read it - I've searched and haven't been able to find
> anything.  As I previously mentioned, one would think if the FSF had issue
> with it they would
> come out and rebuke all the statements out there that say it isn't an
> issue; especially since Canonical is actively working on it.
>

It depends on exactly what FSF knows and how Canonical is planning to do
this.  It is not safe to assume FSF is even aware of all the details here.
If you want FSF's opinion,  they have a public contact address for
licensing questions and respond pretty quickly.Note that FSF's opinion
although influential does not determine what Fedora legally can ship.  That
has to be approved by Red Hat legal as well.

And ... Fedora does not ship third party kernel modules.

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd package bloat

[Rahul Sundaram]

Hi

On Fri, Nov 6, 2015 at 11:23 AM, Reindl Harald wrote:

>
> the same way as other packages to it?
>
> * see php
> * see httpd
>

More useful if you could submit a spec file patch

Rahul
-- 
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: F24: no rsyslog forwarding

[Rahul Sundaram]

Hi

On Fri, Nov 6, 2015 at 12:20 PM, Reindl Harald  wrote:

> to say it in other words: i did not ask for "probably", just pointed out
> that Rawhide is currently broken, that probably systemd or probably rsyslog
> is broken in the one or other direction is clear


Can you file a bug report?

Rahul
-- 
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: bodhi 2 now live

[Rahul Sundaram]

Hi

On Sun, Aug 23, 2015 at 4:23 PM, Kevin Kofler wrote:

 No, sorry, but that is not true. I wrote those update notes in the Bodhi 1
 web interface, so of course I looked at the resulting formatting. Bodhi 1
 interpreted that syntax as a list, not as a single paragraph. This is a
 change in Bodhi 2 (and IMHO, for the worse, though if there's some official
 Markdown spec that says it should be that way, meh…).


Markdown has no official spec.  The closest you can get is commonmark.
Fairly sure, the current parsing is more correct.

http://commonmark.org/

Rahul
-- 
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: dnf caches

[Rahul Sundaram]

Hi

On Thu, Apr 23, 2015 at 1:07 PM, Pádraig Brady wrote:

 My Fedora 22 system prompted me that there was a new coreutils package for
 update.
 Rather than clicking restart and install in the GUI I tried to:

   # dnf install coreutils


dnf install coreutils --refresh


   # dnf --disablerepo=* --enablerepo=updates clean metadata


dnf clean expire-cache

Rahul
-- 
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: yumdownloader vs dnf??????

[Rahul Sundaram]

HI

On Wed, Apr 22, 2015 at 11:19 AM, Richard Shaw  wrote:

 I'm not volunteering!

 ...but perhaps a yum-dnf transition guide on the Fedora wiki would be
 nice which would cover things like this.


https://fedoraproject.org/wiki/Yum_to_DNF_Cheatsheet

Rahul
-- 
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: bodhi / fedora-easy-karma dead

[Rahul Sundaram]

Hi

On Mon, Apr 6, 2015 at 12:18 PM, Reindl Harald  wrote:


 no idea where to file a ticket there

 i can show tickets and see Fedora Account Sign Up but no login anywhere
 -


Click on open id login


 no idea why this is using the horrible trac instead bugzilla


Fedora doesn't host bugzilla.

Rahul
-- 
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: dnf replacing yum and dnf-yum

[Rahul Sundaram]

Hi

On Wed, Apr 1, 2015 at 3:40 PM, Kevin Fenzi wrote:


 * When you run 'yum' you get:

 % sudo yum list foobar
 Yum command has been deprecated, use dnf instead.
 See 'man dnf' and 'man yum2dnf' for more information.
 To transfer transaction metadata from yum to DNF, run 'dnf migrate'
 Redirecting to '/usr/bin/dnf list foobar'


All of this seems a bit rushed considering the schedule.

I have to say I agree with some of the comments in
https://fedorahosted.org/fesco/ticket/1312
 including Dennis Gilmore and Matthew Miller.  While I am glad dnf-yum is
now intended to be there by default and there is a better transition,  I
would prefer if using yum didn't result in this pretty large message
upfront.   The small number of differences between yum and dnf doesn't seem
to warrant this needless churn since massive internal changes and even some
command line changes have occurred between revisions of yum itself.

It would be much better if we can just stick to yum as the name of the
command  esp now that the classic yum command itself has been renamed to
yum-deprecated resulting in no conflicts.

Rahul
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Rahul Sundaram]

Hi

On Fri, Mar 20, 2015 at 5:01 AM, Florian Weimer  wrote:


 You'd be surprised.  There is apparently work under way, in the larger
 Fedora ecosystem, on scriptless booting, in the name of securinity
 (eventually making Android-style locked bootloaders).


Eliminating scripting from boot doesn't eliminate it for countless other
things it is used for

Rahul
-- 
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: F22 Self Contained Change: Disabled Repositories Support

[Rahul Sundaram]

Hi

On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton  wrote:


 What I don't understand is the wisdom of an official Fedora product
 endorsing a copr when either the software or packaging (or both) is not of
 sufficient quality to make it into the official Fedora repo.


I don't think of it as a endorsement.  It is making them more easily
discoverable but there is going to be a prompt of some sort that warns them
of the nature of such software and users get to choose whether they are
willing to accept that tradeoff for immediate access.  One might choose to
use say, Chromium regardless of the bundling issues for example.

Rahul
-- 
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: dnf and yum works different

[Rahul Sundaram]

Hi

On Thu, Mar 12, 2015 at 9:46 PM, Adrian Soliard  wrote:


 Recently, I run dnf update, then yum update, and I notice that yum
 detect 2 packages (fros-recordmydesktop-1.0-5.fc21.noarch and, from
 adobe repo, flash-plugin-11.2.202.451-release.x86_64).
 The case was present on two different computers

 Why dnf don't recognize that packages?


http://dnf.readthedocs.org/en/latest/user_faq.html#why-do-i-get-different-results-with-dnf-upgrade-vs-yum-update

dnf update --refresh might be what you are looking for

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

Packages

[Rahul Sundaram]

Hi

I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been hanging on
to them in hopes of finding the elusive free time that I don't get much of
anymore.  So if you to be a comaintainer or want to take over anything that
I am the point of contact, feel free to drop a request in pkgdb and send me
a note off list as well.   Thanks for those who have stepped in from time
to time.

The list of packages is at

https://admin.fedoraproject.org/pkgdb/packager/sundaram/

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 2:22 PM, Michael Cronenworth  wrote:


 I will take deluge.

 FAS: mooninite


Done

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 2:25 PM, Matthias Runge wrote:


 Congrats to the new job!

 I'd take
 * python-kombu
 * python-gdata
 * python-billiard


Thanks and done.


 * django-* packages should be all become retired.


I have orphaned them since they have EPEL branches.

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 3:51 PM, Adam Williamson  wrote:


 I rely on duplicity (via duply) so I'm willing to take it if no-one
 else will, but I'm really no expert on duplicity per se so I might not
 be the best choice. Is anyone with more experience with it willing to
 take it?


Limb asked for it first.  So I have given it to him.  You can request
co-maintainership if you are still interested

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 4:22 PM, Sereinity  wrote:


 Hi,

 I will take e_dbus and evas-generic-loaders.


Done.  The e* stack is quite old in Fedora now.  If you or anyone else
wants to keep it more current, that would be nice

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 9:28 AM, Pete Travis wrote:

 I'll take python-dateutil15, and see it through to retirement once the
 last of the dependencies are gone.


Done.


 I see you've already retired askbot - any sign from upstream that they'll
 support a newer django within a reasonable timeframe?


They intend to but no specific timeframe

Rahul
-- 
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: [EPEL-devel] Question about EPEL 7 python-ipython*

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 10:05 PM, Nordgren, Bryce L -FS  wrote:

  I notice that ipython has not been released in epel7, but has a release
 version for epel6 and Fedora 20-22. Was there a decision to exclude it from
 epel, or is this due to lack of resources/interest?



 https://apps.fedoraproject.org/packages/python-ipython-notebook


It is purely because noone has stepped up to do the maintenance. It is not
explicitly excluded.  That would only really happen if RHEL itself ships
the package or if there are licensing problems

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

Re: systemd-219 issues with 22 and Rawhide composes

[Rahul Sundaram]

Hi

On Mon, Feb 23, 2015 at 10:35 AM, Zbigniew Jędrzejewski-Szmek  wrote:

 And seriously, Rahul Sundaram is hardly a third party person. He's one
 of the active maintainers of systemd package, which you can easily
 check in the pkgdb, as well as your colleague from Red Hat.


Neither is correct at this point but as you note below, this isn't the
relevant part

But even if he was, it should hardly matter. He made a bug report
 providing the necessary justification (quoting upstream manpage), and
 it should make no difference whether he is active in other areas
 or if that bug report was his first contribution to Fedora.


FWIW,  just in case anyone is curious, I filed a bug report against Google
Chrome to drop the dependency on redhat-lsb package since it is a meta
package for a while and pulls in a long list of dependencies and the only
reason afaik for this dependency is to read the distribution name and
version.  os-release provides a standard location and format for this
information these days but it is confusing to have the system behave
differently from how the documentation says it should be setup and I
requested the change and it has been subsequently made (not by me).

I also independently filed a bug report to deprecate the distro specific
file but FESCo has rejected that. I don't believe that having this
information in multiple places is a good way to maintain a distribution and
we should strive to move to a single canonical location. I don't see a
reason not to add some documentation providing an advance notice of this
but whatever.

Rahul
-- 
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 to (formally/easily) allowing multiple versions of the same library installable

[Rahul Sundaram]

Hi

On Mon, Feb 16, 2015 at 11:17 AM, Ralf Corsepius  wrote:

 I don't buy this argument wrt. Fedora.

 Fedora is a rapid moving, forward looking distro, in which such
 regressions should be fixed and not be worked around by compat-libs.


In ideal conditions, this is fine but in the real world, people do have to
use older versions of libraries because debugging issues in newer versions
isn't a priority and won't be for a lot of users.

Rahul
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Rahul Sundaram]

Hi

On Fri, Feb 20, 2015 at 11:11 AM, Lennart Poettering  wrote:

 How many months would you like me to notify people in advance of a
 simple change like this? Isn't 6 month *ample* time?

 The problem isn't necessarily the speed of change but the amount of
caution and attention paid to inform folks affected by such changes.  It is
a fairly simple change in this case but it affects more than just one
component and not everyone is aware of the details in the first place.  A
simple announcement here or fedora devel announce list would go a long way.

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

[Rahul Sundaram]

Hi



 What is wrong with using Copr for the ring packages. It already works
 just fine (may be BZ is missing). There are no reviews, no guidelines,
 you can bundle ... I believe that everybody understands that while Copr
 is supported by Fedora, you are using these packages on your own risk. I
 can't imagine better state.


That's easy to imagine

*  Searching for packages in copr from the command line and GUI should be
trivial
*  There should be a difference between experimental random builds of the
day and packages which have gone through some review process even if it
does include some bundling
*  Formalized bug reporting
*  pkgdb, tagger, bodhi etc


Rahul
-- 
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: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)

[Rahul Sundaram]

Hi

On Fri, Feb 13, 2015 at 11:40 AM, Ian Malone wrote:

 Thanks. I think when I'd looked at it I'd discounted the review and
 comment on others' submissions process as it would seem to require you
 to have a better idea of what you're doing than the person submitting
 the package, and potentially just creating noise when other people are
 looking at it too.
 Yes, probably a good idea maintainers know how to package. :)


You are also discounting the path of being a co-maintainer first.



  Random fire'n'forget builds in a public Fedora repo would be something
  that would scare me.

 This is sort of a situation we have by default, as it's simpler for
 people to package into the SUSE public repo.


Not sure how.  Please explain.   If the goal is to make it easier to do
fire and forget builds, then koji scratch builds and perhaps copr seems to
be a good option.

Rahul
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[Rahul Sundaram]

Hi

On Tue, Jan 20, 2015 at 7:25 PM, Ian Pilcher  wrote:

 How does this affect users of other display managers (or does it)?


It doesn't affect them afaik.

Rahul
-- 
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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Rahul Sundaram]

Hi

On Fri, Jan 16, 2015 at 9:39 AM, Lubomir Rintel  wrote:

 For this reason, I avoid privilege escalation when I need to conduct
 privileged operations, but open a separate session. The sshd daemon
 running with root privileges is more trustworthy to me than my user
 session.


I have no idea what you mean here.  Turning off direct root login in SSH
doesn't make SSHD itself run as that user.  SSHD is still running as root.

Rahul
-- 
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: F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Rahul Sundaram]

Hi

On Thu, Jan 15, 2015 at 5:20 PM, Kevin Kofler wrote:

 You gain… nothing!


Kevin,

If you are unaware of the gains, ask for it.  Image based upgrades are very
common in cloud environments I work with.   It is used as alternative to
configuration management in some places and it is incredibly useful to be
able to deal with a consistent standard image and only provides deltas for
upgrades.  Chrome OS does that for example and it is used in some of the
most popular laptops in Amazon with millions of consumers.

Rahul
-- 
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: Deleting f20-gnome-3-12 copr

[Rahul Sundaram]

Hi

On Wed, Jan 7, 2015 at 4:18 PM, Stephen Gallagher  wrote:


 /me reiterates his usual argument that we need to have a graphical fedup
 front-end in Workstation to help people upgrade when it's time...


That is kind of a basic requirement.  We need to do more.  We need to
inform people when their release is going EOL and we also need to
automatically prompt users to upgrade whenever there is a new release (ie)
some  integration between GNOME Software/Apper and Fedup

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Mon, Jan 5, 2015 at 4:18 AM, Richard Hughes wrote:


 Also, if any UI changes need to happen, the time to talk to the
 designers is NOW.


Which designers?

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Mon, Jan 5, 2015 at 2:48 PM, Richard Hughes  wrote:

 I'd prefer either aday or jimmac in #gnome-design as they did most of
 the original designs, but Mo and Ryan also know the UX well.

 Pinged jimmac and ryan on that channel.

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Sun, Jan 4, 2015 at 8:46 AM, Richard Hughes  wrote:

 We're not filtering out packages that don't qualify as applications.
 GNOME Software only searches the AppStream metadata


Yes. My suggestion was to change that

Rahul
-- 
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: Yet another frustration with Fedora package management

[Rahul Sundaram]

Hi

On Sun, Jan 4, 2015 at 1:33 PM, Hedayat Vatankhah wrote:


 So, I thought that maybe every package *likes* to have its specific
 settings method; and therefore I proposed to have a global configuration
 which configures main package manager policy.


I agree with the problem.  However I don't think the solution you are
proposing is the right one

1) dnf forked yum which was supposed to be just a project name but dnf
developers have changed their mind and want dnf to be the new permanent
name.  I disagree with this decision but unless FESCo intervenes which
seems unlikely, dnf will essentially replace yum in the near future and
when more newer functionality of RPM such as soft dependencies get used,
yum will have to stop getting used after the temporary transition period.
So after the transition, you will only have to deal with dnf.conf

2) PackageKit should ideally respect yum.conf or dnf.conf instead of
requiring its own configuration file for shared common options.  Perhaps
you can talk to Richard Hughes about that

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

Re: allowing programs to open ports

[Rahul Sundaram]

Hi

On Sun, Jan 4, 2015 at 6:32 PM, Kevin Kofler  wrote:

 Björn Persson wrote:
  I bet! I worry that the questions would quickly become annoying. But if
  ports are going to be blocked by default, then there needs to be some
  way for non-sysadmin users to open them.

 No, why? The ports just need to be closed, period. Non-sysadmin users
 shouldn't be allowed to open any ports.


That won't work in a world where users *are* the sysadmins as well.  Even
in a small business where one has a sysadmin, they aren't focused on
internal issues all that much.  Users are expected to cope up.

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Mon, Jan 5, 2015 at 12:18 AM, Chris Murphy  wrote:

 So what exactly is the problem the target audience has? They want
 GNOME Packages to be included again by default so they have both an
 application GUI installer, and a packages GUI installer?


That is potentially one way to address it.  I think it is somewhat
confusing to have two different interfaces for dealing with software and it
also means that the additional metadata included in GNOME Software won't be
available for command line utilities but it might be a marginal improvement
over not having any UI at all for the rest of the packages.

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Sun, Jan 4, 2015 at 9:43 PM, Chris Murphy  wrote:

  There's already an application that does this, it's GNOME
 Packages or use yum/dnf.


If this was the answer, there wouldn't be so many repeated discussions
about it.  Users don't differentiate between say htop and geany as much as
the designers seem to have assumed.  They treat them both as essentially
applications.  However it doesn't fit the definition that GNOME Software
has and ends up being not included.   There are also users who love the
ratings and additional metadata that  GNOME Software brings and they
wouldn't get any of that with GNOME Packages or yum. dnf search is even
more limiting since it doesn't offer even the rudimentary filtering by name
that yum offers.   GNOME Packages also is not included by default.  In
other words, GNOME Software solves a problem very well but unfortunately
doesn't solve the problems that the target audience has that much.

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Sat, Jan 3, 2015 at 6:20 PM, Michael Catanzaro  wrote:

 We may have been too aggressive in removing it. I think we could include
 it by default if it had a first-run dialog that briefly explains what a
 package is, and that package management is an advanced tool for system
 administrators. Maybe with a link that launches GNOME Software.


Another alternative would be for GNOME Software to show packages perhaps
optionally and deprioritize packages in the listing which don't fit GNOME
Software's criteria for an Application.   Excluding all packages just
causes confusion and has become a FAQ as of late in users list, Ask Fedora
etc.

Rahul
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Rahul Sundaram]

Hi

On Mon, Dec 29, 2014 at 7:36 PM, Ian Malone wrote:


 Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
 upstream (so far as I am aware anyway).


That is incorrect.  Fedora is upstream for RHEL and therefore upstream for
CentOS as well albeit, one step removed.

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

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

[Rahul Sundaram]

Hi

On Mon, Dec 22, 2014 at 1:31 PM, Gerald B. Cox  wrote:


 Well, I don't think the majority of folks would agree that F2FS is some
 random filesystem.
 You'll either turn it on, or explain why not.  The community can then
 judge for themselves.


That is not how it works.  The default position is to disable any feature
unless there is some requirement to enable it.  If you request something to
be enabled, you will have to be willing to do some amount of work to make
it happen.   Eric has indicated what could convince Fedora kernel
developers.  Would you be willing to do that?

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

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

[Rahul Sundaram]

Hi

On Mon, Dec 22, 2014 at 2:04 PM, Gerald B. Cox  wrote:

 The XFStest scenario assumes that Fedora is being somewhat innovative...
 in this instance we're not.  We're playing catch-up.
 The horse has already left the barn.  The longer we delay, the sillier we
 look.  The requirement is obvious.  The bugzilla on it
 is active.


Does that mean you are unwilling to do any work to convince the Fedora
kernel developers?

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

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

[Rahul Sundaram]

Hi

On Mon, Dec 22, 2014 at 2:57 PM, Gerald B. Cox  wrote:

   If no one else was using this, that would be another thing.  You're also
 making up rules that weren't applied to other products which are included
 in Fedora;


It applies to filesystems enabled in Fedora.   Someone has to do the work.
If you aren't volunteering that's perfectly fine but other distributions
enable all sort of things that aren't enabled in Fedora and vice versa for
a number of different reasons. So that by itself isn't going to be
convincing.  Sorry.

Rahul
-- 
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: Cinnamon Spin

[Rahul Sundaram]

Hi

On Sat, Dec 20, 2014 at 11:35 AM, Dan Book  wrote:

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


Please file a bug report.


 I'm not a Fedora packager nor do I have a whole lot of time to put into
 this, but I am willing to update and maintain the spin as necessary.


Spins do take sometime regularly and you should either be actively working
with the Cinnamon maintainers in Fedora or be a co-maintainer yourself but
now that you have gotten a headstart, hopefully others can step in and take
it forward working with you if you are interested/have that time.  Thanks!

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

Re: F21 downloads repository metadata in 3 places!

[Rahul Sundaram]

Hi

On Sun, Dec 14, 2014 at 5:17 AM, Sudhir Khanger  wrote:

  DNF
 regularly downloads cache, disables delta RPM support, and doesn't support
 local repos.


With the latest dnf update, Delta RPM support is enabled again.

https://admin.fedoraproject.org/updates/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21

As a general recommendation, always refer to specific bug reports when
talking about issues

Rahul
-- 
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: Workstation Product defaults to wide-open firewall

[Rahul Sundaram]

Hi

On Thu, Dec 11, 2014 at 11:49 PM, M. Edward (Ed) Borasky wrote:

 Is there an upvote mechanism for that? I'd like to join the chorus if I
 can. ;-)


No.  Voting is limited to FESCo members.  However, if you feel you have
something more to add than the in-numerous responses already in this list,
a quick constructive summary of the pros or cons as you see them might be
useful, perhaps as a comment in the ticket.

Rahul
-- 
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: Poll: How users use DNF

[Rahul Sundaram]

Hi

On Tue, Dec 9, 2014 at 7:19 PM, M. Edward (Ed) Borasky wrote:

 I have yet to port my scripts (https://bitbucket.org/znmeb/osjourno)
 from 'yum' to 'dnf'. I'm not sure I am going to unless the live ISO
 creation tools also switch. But I have tried both 'dnf' and 'yum'
 manually during the F21 alpha and beta test phases. I think there were
 cases where 'yum' said there were updates and 'dnf' didn't. And it
 seemed like 'dnf' was slower.


http://dnf.readthedocs.org/en/latest/user_faq.html?highlight=faq#why-do-i-get-different-results-with-dnf-upgrade-vs-yum-update

Rahul
-- 
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: How many users does Fedora have?

[Rahul Sundaram]

Hi

On Mon, Dec 1, 2014 at 11:11 PM, Matthew Miller  wrote:


 Okay, this seems like a good start. What _are_ the right questions?


* Which packages are part of the default installation for various products
or spins that users actively remove?

* Which packages are not part of the installation that users frequently
install from the official/copr repositories?

* Which packages are generally popular so bugs in those packages can be
prioritized over packages which are rarely used?

* How often do users update their packages?  Which packages do they exclude?

* How often do users install packages from updates testing? Which packages?

Rahul
-- 
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: Entire process's environment attached to bugzillas by ABRT

[Rahul Sundaram]

Hi

On Sun, Nov 30, 2014 at 1:36 PM, Lars Seipel  wrote:


 There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems
 to be pretty common with virt and cloud stuff. Apart from that I can't
 think of anything else right now.


Rackspace, DigitalOcean,  Google Computing Engine etc have API info
potentially exported in the environment as well.  This is going to be quite
tedious to filter out but just in case you want to blacklist them,  you
want to blacklist the following

NOVA_*
DO_*
APPID_*

Rahul
-- 
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: Abotu setting 'PermitRootLogin=no' in sshd_config

[Rahul Sundaram]

Hi

On Sat, Nov 22, 2014 at 7:24 AM, P J P  wrote:


  Yes, we'll ensure that noone is locked out of their systems after a fresh
 install or upgrade.


This seems pretty tricky to ensure.  Anaconda doesn't enforce an additional
user because that could be done via the initial setup or gnome initial
setup.  IIRC, the interactions between them were pretty non obvious already.

Rahul
-- 
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: Abotu setting 'PermitRootLogin=no' in sshd_config

[Rahul Sundaram]

Hi


   Yes, true. We need to talk to them about it yet; still in the process.
 And that's why I was wondering if it needs to be a fully fledged feature?
 or just talking to upstream maintainers would do it?


I would suggesting going through the feature process.  Although the config
file change itself is trivial, there are multiple components that require
coordination with several teams (Anaconda, Fedora Security team, openSSH,
GNOME etc), testing and documentation.  Having FESCo review a proposal is
useful as well.

Rahul
-- 
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: RFC: xserver update strategy in F21+

[Rahul Sundaram]

On Mon, Nov 17, 2014 at 4:50 PM, Samuel Sieb wrote:

My opinion is strongly in line with Kevin, but Chris has a good point.
 However, isn't it possible to have both.  I'm not familiar with the
 proprietary drivers other than knowing that the NVidia one is available
 through rpmfusion.  (Out of the many varieties of laptops I've installed
 Fedora on (at least 30 different models from various manufacturers), I've
 only had one that required the NVidia driver.)  If the proprietary driver
 has a strong dependency on a certain X version, won't that just stop the X
 server from being upgraded?  In that case, everyone using the open drivers
 can upgrade and the others will just not get the new X server until they
 have new drivers available.  I expect this doesn't work if you compile from
 source though.  Are there many people that do that?


1) proprietary drivers depend on the kernel
2)  yes people do build from source but indirectly via the akmod system
used in RPM Fusion

Whether we should care about those users depends on whether we care about
users or just our own repositories.   We have in the past done new releases
that broke the proprietary drivers and that's somewhat unavoidable but
breaking them in an update might too problematic.  I would suggest avoiding
that if we can.

Rahul
-- 
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: No more deltarpms by default

[Rahul Sundaram]

Hi

On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore  wrote:


 /etc/yum.repos.d/fedora-updates.repo on f21 has
 metadata_expire=6h


I was looking at dnf since the discussion is about dnf


 and the metadata right now for f21 updates is an empty repo with no
 packages in it f20 updates repo
 http://dl.fedoraproject.org/pub/fedora/linux/updates/20/x86_64/repodata/
 right now has primary.sqllite of 12M and filelists.sqlite of 19M not
 sure how you got 32K


Not sure.  Probably misread something

Rahul
-- 
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: Note on 'systemd-216-9'

[Rahul Sundaram]

Hi

On Tue, Nov 4, 2014 at 7:06 PM, Zbigniew Jędrzejewski-Szmek  wrote:


 The subject of point releases hasn't come up before. Actually I
 haven't had *any* communication about the stable branches since they
 were created apart from a few patches backported by other systemd
 maintainers. If there are difficiencies, I need to hear about them.
 I love working on Fedora, and I'm happy to fix whatever I can.


 So when there are bugs for which you are pulling in fixes, if you could
push them out to the stable branch and do point releases that just fixes
bugs, that could help Fedora bug reporters understand what is that they are
testing a little better.  It also helps other distributions get upstream
reviewed bug fix releases.

Rahul
-- 
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: Note on 'systemd-216-9'

[Rahul Sundaram]

Hi

On Tue, Nov 4, 2014 at 11:37 AM, Tomasz Torcz  wrote:

 On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
  systemd 216-9 is not built from 216 at all, it is in fact systemd-217

   Why the misleading version number?


More importantly, why is this pushed so late in the release cycle?

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

dnf wants to install new packages when one tries to remove some

[Rahul Sundaram]

Hi

Just a heads up since I have run into this twice in a span of few days.  It
probably makes sense from the satsolver perspective but I found it pretty
surprising behavior.

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

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