Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
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
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)
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"
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
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)
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)
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)
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
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
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
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
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
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
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
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
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)
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)
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
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.
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.
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.
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.
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]
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: F24: no rsyslog forwarding
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: systemd package bloat
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: bodhi 2 now live
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
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??????
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
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
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
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
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
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
Re: Packages
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: Packages
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
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
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
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
Packages
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: systemd-219 issues with 22 and Rawhide composes
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: systemd-219 issues with 22 and Rawhide composes
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 to (formally/easily) allowing multiple versions of the same library installable
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: [Proposal] Ring-based Packaging Policies
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)
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
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
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
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
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
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
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
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: allowing programs to open ports
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
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: Yet another frustration with Fedora package management
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
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
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?
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: Why isn't F2FS support in the Kernel?
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?
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: Cinnamon Spin
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!
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
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
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?
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
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
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: Abotu setting 'PermitRootLogin=no' in sshd_config
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: RFC: xserver update strategy in F21+
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
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'
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'
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
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
Re: Requiring all files in /usr to be world-readable?
Hi On Sun, Nov 2, 2014 at 6:38 PM, Steve Grubb wrote: > Today's guru meditation: He who lives in glass house should not throw > stones. > Zen note: If the stones hit other glasses, fix that problem anyway. 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