Re: shared-mime-info and desktops
On Wed, Jul 15, 2015 at 4:47 PM, Kevin Fenzi wrote: > Greetings. > > For a while now it's been possible for desktops to have their own mime > info (which is great), but it seems we have also gotten rid of the > generic one, which causes some strange behavior: > > https://bugzilla.redhat.com/show_bug.cgi?id=1243049 > > ie, /usr/share/applications/defaults.list no longer exists, and > shared-mime-info ships just a: > /usr/share/applications/gnome.list > > This leads to issues with tools that don't happen to be run under > gnome. Of course other desktops can (and probibly should) make their > own lists, but IMHO we should also have a generic one for tools not > running under any particular DE. > > So, my questions: > > 1. Can we add back a defaults.list ? > > 2. Should other DE's ship their lists also in shared-mime-info or > should they provide it as part of some other base package? > On the one hand one place might be nice, on the other it would make > shared-mime-info update more often and sometimes for things that don't > affect you. > > Thanks for any thoughts... > > kevin > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Cinnamon and MATE ship mimeapps lists (though they weren't functional until recently), and I am not sure if they are set up to work without the defaults. I think it makes more sense for the DE-specific mimelists to be shipped by the DE, and not a single package. -- 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: shared-mime-info and desktops
On Wed, Jul 15, 2015 at 5:01 PM, Dan Book wrote: > > On Wed, Jul 15, 2015 at 4:47 PM, Kevin Fenzi wrote: > >> Greetings. >> >> For a while now it's been possible for desktops to have their own mime >> info (which is great), but it seems we have also gotten rid of the >> generic one, which causes some strange behavior: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1243049 >> >> ie, /usr/share/applications/defaults.list no longer exists, and >> shared-mime-info ships just a: >> /usr/share/applications/gnome.list >> >> This leads to issues with tools that don't happen to be run under >> gnome. Of course other desktops can (and probibly should) make their >> own lists, but IMHO we should also have a generic one for tools not >> running under any particular DE. >> >> So, my questions: >> >> 1. Can we add back a defaults.list ? >> >> 2. Should other DE's ship their lists also in shared-mime-info or >> should they provide it as part of some other base package? >> On the one hand one place might be nice, on the other it would make >> shared-mime-info update more often and sometimes for things that don't >> affect you. >> >> Thanks for any thoughts... >> >> kevin >> >> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> > > Cinnamon and MATE ship mimeapps lists (though they weren't functional > until recently), and I am not sure if they are set up to work without the > defaults. I think it makes more sense for the DE-specific mimelists to be > shipped by the DE, and not a single package. > http://pkgs.fedoraproject.org/cgit/cinnamon-desktop.git/tree/x-cinnamon-mimeapps.list http://pkgs.fedoraproject.org/cgit/mate-desktop.git/tree/mate-mimeapps.list -- 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: perl-Net-DNS-SEC license correction
GPL/Artistic is the perl license; the module's META.json specifies the MIT license. The text included in the module is similar to the MIT and ISC license text, it is definitely not the Artistic license or GPL. Personally I would seek clarification from the author(s). On Fri, Aug 7, 2015 at 10:49 AM, Paul Wouters wrote: > On Fri, 7 Aug 2015, Petr Šabata wrote: > > This package's license tag was wrong all along; the license >> tag will be corrected to `MIT'. Updates are on the way. >> > > hm, I had 1.01 packages pending.. > > Also, the license says GPL+ or Artistic. The README says: > > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose and without fee is hereby granted, provided > that the above copyright notice appear in all copies and that both that > copyright notice and this permission notice appear in supporting > documentation, and that the name of the author not be used in advertising > or publicity pertaining to distribution of the software without specific > prior written permission. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS IN THE SOFTWARE. > > > Is that not the artistic license? > > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: DKMS is not installing the right kernel-devel package
This has also been a problem for several releases with the akmods from rpmfusion. I think the more "correct" solution (read to the end) would be to somehow prioritize the kernel-devel package (possibly multiple) that matches the installed kernel(s). kernel-debug-devel is never the "correct" choice when only standard kernels are installed, but it gets installed because of alphabetical order; this ordering is one way to get something useful installed instead. This of course is pie-in-the-sky and doesn't match with how dependencies can currently be declared and resolved, AFAIK. -Dan On Tue, Jun 9, 2015 at 3:41 PM, Thorsten Leemhuis wrote: > On 09.06.2015 21:04, Neal Gompa wrote: > > I've noticed that when dkms is installed, it's not grabbing the right > > kernel-devel package as a dependency. > > Because that's not possible with ordinary dependencies (might be > possible with soft dependencies [Suggests, Enhances etc]) unless we > change something in the kernel packaging (see below). > > > Instead, it grabs > > kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not sure > > why. > > Because all kernel*devel package provide kernel-devel iirc. > > > Anyone have any idea why this is happening and a way to work around it? > > Create something like a meta-package "kernel-devel-all" that depends on > all available kernel-devel packages (kernel-devel, kernel-PAE-devel, > kernel-debug-devel, ...) for the arch in question; then add "Requires: > kernel-devel-all" to the akmods and dkms packages. That's messy and > creates overhead for users, but that's afaics the only way it will work > for everyone; otherwise you'll always run into situations where a > kernel-devel package for one kernel variant gets installed while you are > running different variant. Example: You get kernel-devel via some > dependency in akmods or dkms; but you are running kernel-PAE on your > i686 machine, so building modules with akmods or dkms will fail, as > that's requires kernel-PAE-devel. > > HTH; CU, knurd > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DKMS is not installing the right kernel-devel package
That's great, for people who already know what to do. The problem is for people who try to install dkms or akmods and then it doesn't work. There are plenty of people who use dkms or akmods modules but don't compile anything themselves (and those people are less likely to understand the kernel-devel issue). -Dan On Tue, Jun 9, 2015 at 4:24 PM, Reindl Harald wrote: > > Am 09.06.2015 um 22:01 schrieb Dan Book: > >> This has also been a problem for several releases with the akmods from >> rpmfusion. I think the more "correct" solution (read to the end) would >> be to somehow prioritize the kernel-devel package (possibly multiple) >> that matches the installed kernel(s). kernel-debug-devel is never the >> "correct" choice when only standard kernels are installed, but it gets >> installed because of alphabetical order; this ordering is one way to get >> something useful installed instead. This of course is pie-in-the-sky and >> doesn't match with how dependencies can currently be declared and >> resolved, AFAIK >> > > honestly that is a *non* problem at all > > * if you need to compile modules you need kernel-devel > * if you *once* had it installed yum7dnf will keep it up-to-date > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DKMS is not installing the right kernel-devel package
On Wed, Jun 10, 2015 at 2:12 AM, Thorsten Leemhuis wrote: > Dan Book wrote on 09.06.2015 22:01: > > This has also been a problem for several releases with the akmods from > > rpmfusion. > > There was always a problem; there where just less people running into > it, because yum/dnf installed "kernel-devel" most of the time, which > matched the kernel that was running on most systems; but quite a few > x86-32 users ran into problems afaics, as kernel-PAE get's installed > there sometimes and hence they needed kernel-PAE-devel. > > Mosts of the docs and howtos on the net don't mention that, which leads > to confused and frustrating users; those in the end might be one of > multiple problems why they switch to another distribution. > > > I think the more "correct" solution (read to the end) would > > be to somehow prioritize the kernel-devel package (possibly multiple) > > that matches the installed kernel(s). > > That's not a solution, that's solving the problem for some users and > ignoring others (those that use kernel-PAE for example). > "The kernel-devel package that matches the installed kernel(s)" would include kernel-PAE-devel matching kernel-PAE, in this fantasy land I invented. > > > [...] > > CU > thl > -Dan > > > On Tue, Jun 9, 2015 at 3:41 PM, Thorsten Leemhuis > <mailto:fed...@leemhuis.info>> wrote: > > > > On 09.06.2015 21:04, Neal Gompa wrote: > > > I've noticed that when dkms is installed, it's not grabbing the > right > > > kernel-devel package as a dependency. > > > > Because that's not possible with ordinary dependencies (might be > > possible with soft dependencies [Suggests, Enhances etc]) unless we > > change something in the kernel packaging (see below). > > > > > Instead, it grabs > > > kernel-debug-devel. This occurs on Fedora 21 and 22, and I'm not > sure > > > why. > > > > Because all kernel*devel package provide kernel-devel iirc. > > > > > Anyone have any idea why this is happening and a way to work > around it? > > > > Create something like a meta-package "kernel-devel-all" that depends > on > > all available kernel-devel packages (kernel-devel, kernel-PAE-devel, > > kernel-debug-devel, ...) for the arch in question; then add > "Requires: > > kernel-devel-all" to the akmods and dkms packages. That's messy and > > creates overhead for users, but that's afaics the only way it will > work > > for everyone; otherwise you'll always run into situations where a > > kernel-devel package for one kernel variant gets installed while you > are > > running different variant. Example: You get kernel-devel via some > > dependency in akmods or dkms; but you are running kernel-PAE on your > > i686 machine, so building modules with akmods or dkms will fail, as > > that's requires kernel-PAE-devel. > > > > HTH; CU, knurd > > -- > > devel mailing list > > devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> > > https://admin.fedoraproject.org/mailman/listinfo/devel > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- 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: Browser choice in live images
On Thu, Nov 5, 2015 at 11:35 AM, Kevin Kofler wrote: > Jos Vos wrote: > > I see that the F23 Xfce live image still includes only Midori as the > > internet browser, similar to the F22 image. > > At least one image that is still consistent with its goals in its > application choice. The KDE image is now polluted by Firefox, which sticks > out like a sore thumb. :-( > > Kevin Kofler > There is sadly an ever shrinking list of web browsers which are both feature-complete and open-source, and the other one has bundling problems. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: i3wm based minimal Spin?
On Wed, Nov 11, 2015 at 11:20 PM, Dennis Chen wrote: > Hi, > > What are the chances that a minimal desktop spin can be created for the > 24 release? It would be nice to have a prepackaged "desktop > environment" with the terminal as it's main focus. > > Dennis Chen > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > As with anything, it probably depends foremost on someone being willing to set it up. There is a "Basic Desktop" group that could be used. -- 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: LibreOffice packaging is a messy dependency graph
I have run into this before and it was very confusing, it really should be a separate command from remove for when you actually want to remove what dnf thinks is now "unused". On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen wrote: > On 12/01/2015 07:02 AM, Christopher wrote: > >> What's the deal with libreoffice packages being a dependency for so many >> system library packages? >> >> I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of >> surprising >> packages with it, including some fonts and system libraries. Granted, I >> don't think I need any of these things, so it's probably safe to uninstall >> them, but it is surprising that so many packages depend on libreoffice >> packages. I'd normally expect the dependencies to be the other way around >> (libreoffice-* depending on system libraries some basic fonts, while other >> fonts are independent or have only optional dependencies on LibreOffice). >> >> I don't need or want an offline office suite (it's huge, and takes up >> bandwidth during updates). I don't mind uninstalling it after a fresh >> install, but it is surprising how much goes with it. >> > > > http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default > > http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label > > Its not that system libraries depend on libreoffice but libreoffice being > the sole user of those libraries, and dnf offering to remove the otherwise > unused cruft along with it. > > - Panu - > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: LibreOffice packaging is a messy dependency graph
Thank you for the information, but it is still confusing. What I mean by that is that there is no discoverability to why dnf is choosing to remove all the extra packages. So the user is left to assume that none of those packages can function without the one you want to remove. I spent half an hour trying to get dnf to remove a single package with nothing depending on it and eventually gave up and used rpm -e. It was only a day or two later when I saw the new dnf behavior being discussed on IRC that I realized what it was trying to do. On Tue, Dec 1, 2015 at 3:42 AM, Igor Gnatenko wrote: > > http://dnf.readthedocs.org/en/latest/command_ref.html#autoremove-command-label > > dnf autoremove will just remove dependencies which is not used by > another packages. > > BTW you can ignore removing non-used packages for one transaction > using option --setopt=clean_requirements_on_remove=false > > On Tue, Dec 1, 2015 at 8:29 AM, Igor Gnatenko > wrote: > > # dnf autoremove > > > > On Tue, Dec 1, 2015 at 8:21 AM Dan Book wrote: > >> > >> I have run into this before and it was very confusing, it really should > be > >> a separate command from remove for when you actually want to remove > what dnf > >> thinks is now "unused". > >> > >> On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen < > pmati...@laiskiainen.org> > >> wrote: > >>> > >>> On 12/01/2015 07:02 AM, Christopher wrote: > >>>> > >>>> What's the deal with libreoffice packages being a dependency for so > many > >>>> system library packages? > >>>> > >>>> I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of > >>>> surprising > >>>> packages with it, including some fonts and system libraries. Granted, > I > >>>> don't think I need any of these things, so it's probably safe to > >>>> uninstall > >>>> them, but it is surprising that so many packages depend on libreoffice > >>>> packages. I'd normally expect the dependencies to be the other way > >>>> around > >>>> (libreoffice-* depending on system libraries some basic fonts, while > >>>> other > >>>> fonts are independent or have only optional dependencies on > >>>> LibreOffice). > >>>> > >>>> I don't need or want an offline office suite (it's huge, and takes up > >>>> bandwidth during updates). I don't mind uninstalling it after a fresh > >>>> install, but it is surprising how much goes with it. > >>> > >>> > >>> > >>> > http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default > >>> > >>> > http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label > >>> > >>> Its not that system libraries depend on libreoffice but libreoffice > being > >>> the sole user of those libraries, and dnf offering to remove the > otherwise > >>> unused cruft along with it. > >>> > >>> - Panu - > >>> -- > >>> devel mailing list > >>> devel@lists.fedoraproject.org > >>> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > >> > >> > >> -- > >> devel mailing list > >> devel@lists.fedoraproject.org > >> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > > > -- > > > > -Igor Gnatenko > > > > -- > -Igor Gnatenko > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On Tue, Dec 1, 2015 at 3:02 AM, Petr Spacek wrote: > On 1.12.2015 08:20, Dan Book wrote: > > I have run into this before and it was very confusing, it really should > be > > a separate command from remove for when you actually want to remove what > > dnf thinks is now "unused". > > Maybe it would help if these auto-removed packages are clearly marked as > such > in summary printed by DNF. > > Currently the output looks like this: > $ dnf remove ekiga > Dependencies resolved. > = > Removing: > ekiga x86_64 4.0.1-17.fc22 @fedora 19 M > evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M > geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k > gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M > libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M > ... and so on > > It would be easier to understand if it printed: > > $ dnf remove ekiga > Dependencies resolved. > = > Removing: > ekiga x86_64 4.0.1-17.fc22 @fedora 19 M > Removing unused dependencies: > evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M > geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k > gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M > libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M > > ... and so on > > Petr^2 Spacek > This would be a great improvement indeed. -Dan > > > > > On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen < > pmati...@laiskiainen.org> > > wrote: > > > >> On 12/01/2015 07:02 AM, Christopher wrote: > >> > >>> What's the deal with libreoffice packages being a dependency for so > many > >>> system library packages? > >>> > >>> I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of > >>> surprising > >>> packages with it, including some fonts and system libraries. Granted, I > >>> don't think I need any of these things, so it's probably safe to > uninstall > >>> them, but it is surprising that so many packages depend on libreoffice > >>> packages. I'd normally expect the dependencies to be the other way > around > >>> (libreoffice-* depending on system libraries some basic fonts, while > other > >>> fonts are independent or have only optional dependencies on > LibreOffice). > >>> > >>> I don't need or want an offline office suite (it's huge, and takes up > >>> bandwidth during updates). I don't mind uninstalling it after a fresh > >>> install, but it is surprising how much goes with it. > >>> > >> > >> > >> > http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default > >> > >> > http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label > >> > >> Its not that system libraries depend on libreoffice but libreoffice > being > >> the sole user of those libraries, and dnf offering to remove the > otherwise > >> unused cruft along with it. > >> > >> - Panu - > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: LibreOffice packaging is a messy dependency graph
On Wed, Dec 2, 2015 at 8:42 AM, David Tardon wrote: > Hi, > > On Tue, Dec 01, 2015 at 02:20:34AM -0500, Dan Book wrote: > > I have run into this before and it was very confusing, it really should > be > > a separate command from remove for when you actually want to remove what > > dnf thinks is now "unused". > > Why? Remove is the opposite of install. "dnf install foo" will install > package foo _and_ all its dependencies. So it is only logical that > "dnf remove foo" should remove package foo _and_ all its (unneeded) > dependencies. > Because 1. this behavior has never been default before, and 2. it is just as logical for "remove" to be the opposite of "install" like so: Install installs foo and its dependencies, remove removes foo and any packages depending on it. And this is exactly how it has to work, so it is expected. Anyway the proposal in another thread, to specify in the list that the extra removals are because they are unneeded dependencies, and not just more removals, would solve a lot of the confusion. > > D. > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On Wed, Feb 3, 2016 at 6:10 PM, Samuel Sieb wrote: > On 02/03/2016 02:28 PM, Felix Miata wrote: > >> Problem #3: >> When running from say the /boot directory the same dnf command above: >> >> # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* >> >> dnf reports cannot install package inityada, cannot install package >> vmliyada, >> It ought to be smart enough not to try to install local files that >> are >> not installation package files (e.g., those ending in .rpm or any other >> type >> it might understand and support). >> >> This is not something dnf can do anything about. Bash handles the > globbing and passes the filenames to dnf. That's why you should quote > them. Dnf doesn't know that you were using wildcards unless the glob > doesn't match any filenames in which case bash will pass it on. Once > "vmlinuz" is on the command line to dnf, it can't know that you didn't mean > that to be a package name. More specifically, the command should be: # dnf update 'kd*' 'kf*' 'q*' 'per*' 'pyt*' 'u*' 'v*' 'x*' 'y*' 'z*' or you can backslash-escape each asterisk. On fish shell for example, commands like these will simply fail if you forget to escape wildcards that are not actually meant for the shell. > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF Issue, packages being incorrectly removed - was: Re: corebird
On Fri, May 27, 2016 at 2:17 AM, Nico Kadel-Garcia wrote: > On Thu, May 26, 2016 at 1:03 PM, Gerald B. Cox wrote: > > > > On Thu, May 26, 2016 at 3:02 AM, Michal Luscon > wrote: > >> > >> This might have been caused by > >> https://bugzilla.redhat.com/show_bug.cgi?id=1259865 > >> > >> . > >> > >> Michal > > > > > > Yes, Kevin mentioned that and it is in the other thread (corebird). I'm > > just wondering if this is something that will be resolved > > with the upgrade to F24. > > Just don't use "dnf autoremove" it is not, and cannot be, your friend > except to perhaps provide a *guideline*, of removable packages. Never > run it without manual review of the target packages. > For whatever reason, autoremove is the default behavior of dnf unless you disable clean_requirements_on_remove, so you can expect this issue to hit new users. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Mon, May 30, 2016 at 6:20 PM, Richard W.M. Jones wrote: > On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: > > So there's tmux, screen, curl, wget, and probably quite a few others > > that don't necessarily get daemonized that are probably affected. > > Currently you can `scp ... &' and the process will survive a logout > and continue running. Very useful when you want to copy files between > machines without waiting around. > > Rich. IMO it is expected that any process started with & will survive a logout. If this does not allow that behavior by default it will invite much discord. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Wed, Jun 1, 2016 at 9:48 AM, Lennart Poettering wrote: > On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: > > > This is still looking at the problem back-asswards. The problem isn't > that > > screen and tmux are special cases. The problem is that some handful of > > programs that got spawned in a GUI desktop environment are special cases, > > not exiting when they should. > > > > Fix the broken programs, don't force every well-behaved program in the > > universe to change to accommodate your broken GUI environment. This is > > Programming 101. > > Again, this isn't just work-arounds around broken programs. It's a > security thing. It's privileged code (logind, PID 1) that enforces a > clear life-cycle on unprivileged programs. > > Any scheme that relies on unprivileged programs "being nice" doesn't > fix the inherent security problem: after logout a user should not be > able consume further runtime resources on the system, regardless if he > does that because of a bug or on purpose. > > Lennart That's your opinion, and while many sysadmins may share it, many will not. Having this as an optional security feature would be fantastic. Enforcing it by default on every user many of which use tmux, screen, nohup, and & to persist long running processes for daily work, is not something to do just because you think it is what people should do. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Wed, Jun 1, 2016 at 10:28 AM, Tomasz Torcz wrote: > > > I think that programs needing special treatment should use operating > system's facilities to communicate that. So tmux, screen, nohup should > really open a new session. It's unfortunate that tmux author is hostile > against that, but maybe a clean, compile-time optional patch would persuade > him? > Anyway, I think some examples of ”how to inform systemd I'm a special > program not to reap” would be welcome. Does it need to be done through > D-Bus interaction with logind? Is using PAM sufficient/required? > (Nb. screen already uses PAM for some functionality). As mentioned, this isn't just about screen, tmux, and nohup (or if there's any other programs used in a similar context). *Any* command run with a trailing & is commonly expected to survive logout, usually from remote shells. Setting this as a default security policy without allowing that standard behavior is going to be, at best, very surprising to a lot of people, and documenting a new way to do the same thing isn't good enough. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Wed, Jun 1, 2016 at 2:19 PM, Przemek Klosowski < przemek.klosow...@nist.gov> wrote: > On 05/27/2016 12:45 PM, Christopher wrote: > > > It seems to me that what's happening is that systemd is now enforcing this > "login session" perspective... metaphorically speaking, gluing the > transparent overlay onto the map (but don't worry! they also provide a > special adhesive remover!). This makes it that much harder for people to > make use of what's underneath without viewing it through the overlay... > which, as it turns out, is a *very* common thing to do (screen, tmux, > nohup, etc.). > > This is a very good observation. The 'login' infrastructure deals with > authorization to run processes on the computer, which is orthogonal to > managing characteristics of individual processes, such as whether they are > transient or persistent. Admitedly, the logout process has to deal with the > lingering processes: Windows, for instance, throws a dialog box asking to > terminate the apps. This is somehow a violation of layering which I just > pointed out above, but I think it is correct in asking for user intent. > > In any case, the common use case nowadays is a personal device, where this > whole issue is somehow moot: there are no multiple users, the user is the > administrator, and the login session is really from startup to > shutdown---so the proposed change doesn't change the user-visible behavior > much, except making the reboot quicker. > I think one needs to be careful with even this assumption though. I have used my server in a hybrid fashion, where I'll log into it both in a desktop environment and via SSH and use the same tmux window or backgrounded processes from each. Killing these processes just because I started them from the desktop instead of via SSH is not an agreeable default. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Wh{o,at} broke rawhide?
On Thu, Jun 9, 2016 at 4:51 AM, Marcin Juszkiewicz wrote: > W dniu 09.06.2016 o 00:18, gil pisze: > > I have no idea why but most of your mails end in my spam folder ;( > > Il 08/06/2016 21:15, Kevin Fenzi ha scritto: >> >>> On Wed, 8 Jun 2016 21:07:26 +0200 >>> Marcin Juszkiewicz wrote: >>> >> > Any ideas (other than "switch to F24/Ubuntu/Debian/Umbaumba" ones)? >>> > the latest is the better solution ... >> > > > 3. Try another DE and see if the problem happens there? >>> >> > who did you of bad kde? >> > > And level of your answers probably answers why. Actually it is because his email provider asks to be sent to spam. See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IO2DOQHVL4MQYATUQ6447DQWDJFXCWLH/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaning blueman
Hello, The blueman package has been orphaned by previous maintainer leigh123linux. It is an important service (bluetooth support) for the Cinnamon, MATE, XFCE, and other desktops, so if anyone is willing and capable, a new maintainer would be appreciated. -Grinnz -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [OT] Tim, Gil, et. al. (e-mail address settings)
> > repeat my self for last time: is not a my problem. > if you want block another time my fedora account, please, > take a seat > regards > .g > Nobody is blocking you. But aside from this one instance I went digging through my spam folder, I do not see your messages, and I suspect many others do not either. Communication doesn't work if you can't reach the audience, quite literally in this case. But if you don't care, then that's all. -Grinnz -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 System Wide Change: KillUserProcesses=yes by default
On Sat, Jul 9, 2016 at 6:20 PM, Alex Thomas wrote: > > As it looks from my vantage point, the choice is either carry a patch > to revert this change in systemd, or accept the load of carrying an unknown > number of patches to allow other software to accommodate this change. > > My suggestion is to plan on reverting the systemd change to > KillUserProcess=no in F25, and reevaluate for F26, when we have a better > understanding of just how many programs have to be rewritten/patched/forked > to accommodate this new paradigm. > As I understand it, this option has been available for a while, the change in question is just to make it default. In which case the choice is between letting it become default, or just setting the default back to off in Fedora. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24
On Wed, Oct 5, 2016 at 11:59 AM, Gerald B. Cox wrote: > > > I created a RFE bug requesting that the upgrade function in DNF be changed > to incorporate "offline" upgrades as an option. If it is really > an issue, DNF should handle it. > https://bugzilla.redhat.com/show_bug.cgi?id=1382063 > > This would be really nice to have. I'd like to add that at least the MATE and Cinnamon spins, possibly others, do not include PackageKit and instead expect users to update using yumex-dnf or dnf itself. So ideally an offline update mechanism can be added to dnf, and then exposed in yumex-dnf. But we may have to consider installing PackageKit in those spins. My concern with this is that PackageKit and dnf do not share history and many users are used to using dnf. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Cinnamon Spin
Hello, I have put together a basic Cinnamon Live spin, and was wondering if this is something people would like to see become official. It's not ready for submission quite yet, there is a bit of a hack to change the default gtk-theme to Zukitwo, as the Adwaita gtk-theme messes up title-bar and desktop icon colors (something that should probably be fixed upstream, this happens for any Cinnamon install by default in F21). I'm not a Fedora packager nor do I have a whole lot of time to put into this, but I am willing to update and maintain the spin as necessary. I have the kickstart files in this github repo: https://github.com/Grinnz/spin-kickstart-cinnamon And resulting images, which I have briefly tested and installed in a VM: https://grinnz.com/public/spins-cinnamon/ I added a skeleton wiki page as well: https://fedoraproject.org/wiki/Cinnamon_Spin -Dan Book -- 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
On Sat, Dec 20, 2014 at 12:54 PM, Fabio Alessandro Locati < fabioloc...@gmail.com> wrote: > Hi, > > I'm Fale, one of the cinnamon maintainer of Fedora and I was working on a > Cinnamon Spin too. Due to the big amount of work I'm doing during these > months, I kind of left it behind. I can join you with this project if you > want too :). > > Thanks a lot, > Fabio > Thank you, I would definitely appreciate any assistance. Right now the spin is rather simple, it is using the fedora-live-base.ks, installing the cinnamon-desktop group and otherwise mostly following the XFCE spin's kickstart for setting up lightdm and the liveuser. > > On Sat, Dec 20, 2014 at 6:14 PM, Rahul Sundaram > wrote: > >> 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 >> >> > > Thanks for the information. I have filed a bug report as I didn't find one existing about this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1176370 -Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Cinnamon Spin
On Sun, Dec 21, 2014 at 1:25 PM, Thomas Gilliard wrote: > > On 12/20/2014 8:35 AM, Dan Book wrote: > > Hello, > I have put together a basic Cinnamon Live spin, and was wondering if this > is something people would like to see become official. It's not ready for > submission quite yet, there is a bit of a hack to change the default > gtk-theme to Zukitwo, as the Adwaita gtk-theme messes up title-bar and > desktop icon colors (something that should probably be fixed upstream, this > happens for any Cinnamon install by default in F21). I'm not a Fedora > packager nor do I have a whole lot of time to put into this, but I am > willing to update and maintain the spin as necessary. > > I have the kickstart files in this github repo: > https://github.com/Grinnz/spin-kickstart-cinnamon > And resulting images, which I have briefly tested and installed in a VM: > https://grinnz.com/public/spins-cinnamon/ > > I added a skeleton wiki page as well: > https://fedoraproject.org/wiki/Cinnamon_Spin > > -Dan Book > > > I successfully installed the cinnamon x86_64.iso via f21 liveusb-creator > with the (dd) option [1] and installed it to Bare metal from the USB. > > Thanks for this build I hope it becomes a spin. > > I included links to your build here: > [1] http://wiki.sugarlabs.org/go/Fedora_22#liveusb-creator > > NOTE: > Install error anaconda 21.48.21-1 (liveinst) > **(anaconda:2201) : Warning **: Binding 'Print' failed! > repeated many times in terminal. > > menu/administration/Fedora Release Notes has 2 entries (both work) > > Tom Gilliard > satellit > #fedora-qa freenode IRC > Thank you for the feedback. I will look into these, but I don't know much about anaconda. -Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Cinnamon Spin
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). I'm not a Fedora > packager nor do I have a whole lot of time to put into this, but I am > willing to update and maintain the spin as necessary. > > I have the kickstart files in this github repo: > https://github.com/Grinnz/spin-kickstart-cinnamon > And resulting images, which I have briefly tested and installed in a VM: > https://grinnz.com/public/spins-cinnamon/ > > I added a skeleton wiki page as well: > https://fedoraproject.org/wiki/Cinnamon_Spin > > -Dan Book > Update: Cinnamon is now using an updated version of the Zukitwo gtk-theme and I have re-spinned isos at https://grinnz.com/public/spins-cinnamon/ . Once the next cinnamon update goes through the workaround to set the gtk-theme can be removed. IMO the spin is now suitable for further testing and development for inclusion in the fedora spins, if anyone is up to the task. -Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Cinnamon Spin
On Mon, Jan 26, 2015 at 9:51 PM, Carlos Morel-Riquelme < empateinfin...@gmail.com> wrote: > Dan, thank for the new but the download links for the spin (wiki > skeleton) isn't available :( > > On Mon, Jan 26, 2015 at 11:24 PM, Dan Book wrote: > >> 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). I'm not a Fedora >>> packager nor do I have a whole lot of time to put into this, but I am >>> willing to update and maintain the spin as necessary. >>> >>> I have the kickstart files in this github repo: >>> https://github.com/Grinnz/spin-kickstart-cinnamon >>> And resulting images, which I have briefly tested and installed in a VM: >>> https://grinnz.com/public/spins-cinnamon/ >>> >>> I added a skeleton wiki page as well: >>> https://fedoraproject.org/wiki/Cinnamon_Spin >>> >>> -Dan Book >>> >> >> Update: Cinnamon is now using an updated version of the Zukitwo gtk-theme >> and I have re-spinned isos at https://grinnz.com/public/spins-cinnamon/ >> . Once the next cinnamon update goes through the workaround to set the >> gtk-theme can be removed. IMO the spin is now suitable for further testing >> and development for inclusion in the fedora spins, if anyone is up to the >> task. >> >> -Dan >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Current downloads can be found at https://grinnz.com/public/spins-cinnamon/ , I'll update the screenshot and link on the wiki. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora spins torrents statistics
On Wed, May 3, 2017 at 12:38 PM, Adam Williamson wrote: > On Wed, 2017-05-03 at 00:56 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, May 02, 2017 at 10:45:12AM +0200, Germano Massullo wrote: > > > As torrents seeder of certain Fedora spins, I would like to share some > > > upload statistics: > > > 47.81 GB Fedora 25 KDE x86_64 > > > 29.40 GB Fedora 25 KDE i386 > > > 24.14 GB Fedora 25 Xfce i386 > > > 21.96 GB Fedora 25 Xfce x86_64 > > > 20.09 GB Fedora 25 LXDE x86_64 > > > 19.45 GB Fedora 25 LXDE i386 > > > > > > Torrents have been added on 25 November 2016 > > > > Very interesting. It seems i386 is holding strong, on par with amd64 > > for Xfce and LXDE. > > Can't conclude that from a single seeder, as we're missing information > on *how many seeders there are* for each torrent. For instance, if only > one or two people bother to seed i386, but 10-20 people are seeding > x86_64, then if all seeders have the same upload total for each > torrent, x86_64 would have 10x the total transfer volume... It is a rather small sample size to draw any conclusion in any case. The majority of spin downloads are from the static file servers these days. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mp3 encoding now ok
On Wed, May 3, 2017 at 5:31 PM, Emmanuel Seyman wrote: > * Jon [03/05/2017 15:57] : > > > > Normally Spot would revel these kind of topics. > > > > Where are you Spot? > > > > Have you run this topic through RH legal? > > Yes, it has been run through Red Hat legal channels. > > https://lists.fedoraproject.org/archives/list/legal@lists. > fedoraproject.org/message/34NPNTJITRHRP2FRKKYGL2YMEUU4BDYF/ That is regarding decoding software, not encoding. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cannot dnf group remove "Cinnamon Desktop"
On Mon, May 8, 2017 at 10:40 AM, Jorge Gallegos wrote: > Hi, > > I found out the Cinnamon Desktop group is behaving like Hotel > California. I had ``dnf group install "Cinnamon Desktop"`` some time in > the past, and was trying to cleanup now after finishing fiddling with > it. It turns out that Cinnamon Desktop's dependencies somehow bind to > protected dependencies, i.e. > > ``` > [root@ragnia ~]# dnf group remove "Cinnamon Desktop" > Last metadata expiration check: 2:18:50 ago on Mon May 8 07:18:18 2017. > Dependencies resolved. > Error: The operation would result in removing the following protected > packages: dnf, systemd, systemd-udev. > ``` > > Is this intended? A cursory search in bugz turns out no real results, > but wanted to make sure if maybe I am missing something here, if not I > will be opening a new bug. Try setting clean_requirements_on_remove=False in /etc/dnf/dnf.conf. See http://dnf.readthedocs.io/en/latest/conf_ref.html#main-options ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cannot dnf group remove "Cinnamon Desktop"
On Wed, May 10, 2017 at 2:09 PM, Jorge Gallegos wrote: > On Mon, May 08, 2017 at 12:02:40PM -0400, Dan Book wrote: > > On Mon, May 8, 2017 at 10:40 AM, Jorge Gallegos wrote: > > > > Hi, > > > > I found out the Cinnamon Desktop group is behaving like Hotel > > California. I had ``dnf group install "Cinnamon Desktop"`` some time > in > > the past, and was trying to cleanup now after finishing fiddling with > > it. It turns out that Cinnamon Desktop's dependencies somehow bind to > > protected dependencies, i.e. > > > > ``` > > [root@ragnia ~]# dnf group remove "Cinnamon Desktop" > > Last metadata expiration check: 2:18:50 ago on Mon May 8 07:18:18 > 2017. > > Dependencies resolved. > > Error: The operation would result in removing the following > protected packages: dnf, systemd, systemd-udev. > > ``` > > > > Is this intended? A cursory search in bugz turns out no real results, > > but wanted to make sure if maybe I am missing something here, if not > I > > will be opening a new bug. > > > > > > Try setting clean_requirements_on_remove=False in /etc/dnf/dnf.conf. > See http://dnf.readthedocs.io/en/latest/ > > conf_ref.html#main-options > > This appears to have no effect on dnf group operations? > > ``` > [root@ragnia ~]# dnf --setopt "clean_requirements_on_remove=False" group > remove "Cinnamon Desktop" > Last metadata expiration check: 2:25:11 ago on Wed May 10 10:42:51 2017. > Dependencies resolved. > Error: The operation would result in removing the following protected > packages: dnf, systemd-udev, systemd. > ``` > > I tried editing /etc/dnf/dnf.conf as well with the same results Try `dnf group remove cinnamon-desktop` or Cinnamon -- "Cinnamon Desktop" may be trying to remove the environment group cinnamon-desktop-environment which includes the whole base system. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: perl Package to Install Core Modules
On Thu, Jun 15, 2017 at 1:27 PM, Stephen Gallagher wrote: > > > If that's the case, I think these two approaches are *basically* identical, > except that the metapackage approach will probably cause DNF to misbehave > due to > the "clean_requirements_on_remove=true" default configuration (which > might cause > it to try to remove a bunch of other packages that were installed at the > same > time as 'perl'. > In my opinion, this is merely an example of why the " clean_requirements_on_remove=true" default is problematic. But I won't rehash that discussion here. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: perl Package to Install Core Modules
On Thu, Jun 15, 2017 at 2:06 PM, Emmanuel Seyman wrote: > * Stephen Gallagher [15/06/2017 13:27] : > > > > If your intent is to say unequivocally that this system must not include > the > > perl interpreter unless all of these packages are installed, then that's > when > > you should use Requires: > > This is what upstream is requesting. Not exactly; the request is that if the package named "perl" is installed, then the system should have all of the core modules installed. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: spins-kickstarts workflow changes
This sounds like a good step to me. I am used to the pull request workflow though. On Fri, Feb 19, 2016 at 5:55 PM, Zach Villers wrote: > +1 for moving forward and involving pagure. I'm not experienced enough to > pick out any issues, but will help however I can. > On Fri, Feb 19, 2016 at 2:37 PM Kevin Fenzi wrote: > >> Greetings. >> >> I am sending this to the devel and spins lists. Feel free to forward to >> other places people who might be affected by it should see it. >> >> Some history: >> >> We setup the spin-kickstart project on fedorahosted a long time ago. >> At the start it was just the various spins and it's trac instance was >> used in the new spins workflow. Then, it was a handy place to put the >> dvd iso kickstart that releng made also. Then over time we added cloud >> and docker and everything else that used a kickstart to it. In the >> start we added some bugzilla components for the various spins for end >> user bugs, and used the trac for workflow things. Over time due to >> all the images there lots of people have been given commit access to >> the repo. Then the spins sig went quiet and we have sort of been limping >> along since then with trac tickets not getting to anyone who cares, >> etc. >> >> I'd like to propose the following plan of action: >> >> * Setup a new project at pagure.io called just kickstarts or >> releng-kickstarts or something. (Bikeshed alert). >> >> * Setup tags for all the various groups that have kickstarts. ie, >> 'xfce' 'docker' 'cloud' 'atomic' 'workstation' etc. And get someone >> from each of those groups to actually watch the tags or someone to CC >> on who will actually look at those tagged issues. >> >> * Reduce the number of commiters a bunch and ask people to submit PR's >> when they want a change. This will allow releng/qa to control changes >> when in freeze. ie, we can require a freeze break and point to the >> PR/bug with the exact change and merge it when it's approved. >> >> * Copy the git repo over to it from fedorahosted. Close that repo. >> >> * Mass close all the fedorahosted trac tickets and close trac to new >> ones with a note to file new issues in pagure. ( 21 tickets >> currently): https://fedorahosted.org/spin-kickstarts/report/1 >> >> * Close the "LiveCD*" components in bugzilla to new bugs and close any >> existing ones with a note to refile at pagure. (18 bugs currently): >> >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=LiveCD&component=LiveCD%20-%20FEL&component=LiveCD%20-%20Games&component=LiveCD%20-%20KDE&component=LiveCD%20-%20LXDE&component=LiveCD%20-%20Xfce&list_id=4654195&product=Fedora&query_format=advanced >> >> * Adjust koji config to pull from pagure.io instead of fedorahosted. >> >> Thoughts? Additional steps? Better plans? >> >> kevin >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 workstation, and (almost) hidpi displays
On Fri, Oct 21, 2016 at 6:08 PM, Adam Williamson wrote: > > > 13" 1080p laptops are the biggest exception to this that I can think > of. I dunno what you do with them on Windows; I think Windows has a > slider somewhere which more or less works like the 'scaling factor' > setting. FWIW, here on windows 7, there are just options for 1.25 and 1.5 scaling. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F25 workstation, and (almost) hidpi displays
On Fri, Oct 21, 2016 at 6:20 PM, Adam Williamson wrote: > On Fri, 2016-10-21 at 18:16 -0400, Dan Book wrote: > > On Fri, Oct 21, 2016 at 6:08 PM, Adam Williamson < > adamw...@fedoraproject.org > > > wrote: > > > > > > > > > 13" 1080p laptops are the biggest exception to this that I can think > > > of. I dunno what you do with them on Windows; I think Windows has a > > > slider somewhere which more or less works like the 'scaling factor' > > > setting. > > > > > > FWIW, here on windows 7, there are just options for 1.25 and 1.5 scaling. > > Out of curiosity, do you know if that's hidpi-style 'scale everything' > scaling, or is it just font size scaling? > > I read somewhere that Apple came up with a trick for doing 1.5x hidpi > scaling - they just scale everything 3x in software then tell the GPU > to scale it back down by 2x on output. Which is a neat wheeze. Be > trickier to do 1.25x that way, though. It seems to be hidpi style. Looking into the help topic there's also an option to set a custom scale anywhere between 1-5x in 0.01 increments. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: f32-backgrounds look like crap
On Fri, Apr 17, 2020 at 11:12 AM Adam Williamson wrote: > On Fri, 2020-04-17 at 16:09 +0300, Benson Muite wrote: > > On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote: > > > > Hi Leigh, > > > > > > > > > > > > Do you think you could please use nicer language? There's no need to > > > > use words like that to describe other people's work in the community. > > > > > > That was the nicest term I could use to describe it! > > > > > > > I personally quite like the 90s retro look. > > > > > > > > Hi Leigh, > > > > Elections for alternative wallpapers are currently open: > > https://apps.fedoraproject.org/nuancier/elections/ > > Please vote for ones that you like. > > > > The submission phase for Fedora 32 has unfortunately already closed. > > Please do make wallpaper submissions for Fedora 33 as well to ensure > > there is a wide choice of excellent candidates. > > For people who have Strong Opinions (TM) about wallpapers, the design > process is open: you could have been reviewing the candidates and the > refinement process as it happened, and providing (respectful!) input > there... > > https://pagure.io/design/issue/669 > > for instance, the halftoning is a choice, and there were candidates > with more and less of it, and only a handful of people giving their > opinions... > I don't have an opinion on the artistic value of it (or any previous Fedora background), but functionally, it has a low quality appearance which many people won't look past, and it is busy with color contrast making it difficult to see desktop icons. -Dan ___ 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: f32-backgrounds look like crap
On Fri, Apr 17, 2020 at 9:10 AM Benson Muite wrote: > > On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote: > > > Hi Leigh, > > > > > > > > > Do you think you could please use nicer language? There's no need to > > > use words like that to describe other people's work in the community. > > > > That was the nicest term I could use to describe it! > > > > > > > > I personally quite like the 90s retro look. > > > > > Hi Leigh, > > Elections for alternative wallpapers are currently open: > https://apps.fedoraproject.org/nuancier/elections/ > Please vote for ones that you like. > > The submission phase for Fedora 32 has unfortunately already closed. > Please do make wallpaper submissions for Fedora 33 as well to ensure > there is a wide choice of excellent candidates. > I think it's important to point out here that while the available alternatives are great options, it does not change the desktop experience presented to users who first install Fedora of whatever flavor. The only thing that affects that is the choice of default for that spin, whether it can be improved by a user who wants to customize their experience is orthogonal. -Dan ___ 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: Untouched BZ against cinnamon-desktop
On Thu, Apr 30, 2020 at 5:34 AM Michal Schorm wrote: > Hi, > > A long time ago I filled a BZ for F29 against the package group > @cinnamon-desktop-environment. [1] > Now I checked, and the issue still exists, so I re-opened it and moved > against F32. > > How can I get someone appropriate to notice it? > The generic > "Assignee: Alternative GTK desktop environments" > seems unresponsive. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1684764 I don't know the cause of the issue here, which seems to stem from something more central than the cinnamon group, but you should not be installing any environment groups at any time except as a new system. The environment groups are meant to define the entire installation environment, to install cinnamon (or another desktop) after having an already installed desktop environment, use the @cinnamon-desktop group. -Dan ___ 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 31->32 dnf system-update experience
On Fri, May 8, 2020 at 12:05 PM Scott Talbert wrote: > On Fri, 8 May 2020, Michael Catanzaro wrote: > > >> That is kind of what I figured. BTW, I used the GUI method to upgrade. > > > > Yeah me too. And my fedora-obsolete-packages is also gone. > > > > It cannot be installed, either. I wonder: am I misunderstanding how this > is > > supposed to work? Or has something improperly obsoleted it? > > Sounds like it is new expected behavior of dnf: > https://bugzilla.redhat.com/show_bug.cgi?id=1827398 The default clean_requirements_on_remove is still something I turn off immediately on any system's dnf.conf. It's come up before[1] that this could be presented way better in the dnf UI, it's very confusing. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/75QEOFNRNPUSFCC533242OFVDEXKEFLS/ -Dan ___ 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 31->32 dnf system-update experience
On Fri, May 8, 2020 at 12:54 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Fri, May 08, 2020 at 12:39:04PM -0400, Dan Book wrote: > > On Fri, May 8, 2020 at 12:05 PM Scott Talbert wrote: > > > > > On Fri, 8 May 2020, Michael Catanzaro wrote: > > > > > > >> That is kind of what I figured. BTW, I used the GUI method to > upgrade. > > > > > > > > Yeah me too. And my fedora-obsolete-packages is also gone. > > > > > > > > It cannot be installed, either. I wonder: am I misunderstanding how > this > > > is > > > > supposed to work? Or has something improperly obsoleted it? > > > > > > Sounds like it is new expected behavior of dnf: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1827398 > > > > > > The default clean_requirements_on_remove is still something I turn off > > immediately on any system's dnf.conf. It's come up before[1] that this > > could be presented way better in the dnf UI, it's very confusing. > > No, this is not related to clean_requirements_on_remove. As mentioned > upthread, fedora-obsolete-packages now does its job without being > installed. > Sorry I was responding to the confusion in the linked bug report which stems from the UI display of that feature. -Dan ___ 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: What other external trackers would you like added to Bugzilla?
On Mon, Aug 12, 2019 at 2:36 PM Petr Pisar wrote: > - Perl: https://rt.perl.org/Public/ I would not expend effort on this, as it is planned to be moved the github in the near future. https://www.nntp.perl.org/group/perl.perl5.porters/2019/06/msg255335.html -Dan ___ 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: What other external trackers would you like added to Bugzilla?
On Mon, Aug 12, 2019 at 3:11 PM Dan Book wrote: > On Mon, Aug 12, 2019 at 2:36 PM Petr Pisar wrote: > >> - Perl: https://rt.perl.org/Public/ > > > I would not expend effort on this, as it is planned to be moved the github > in the near future. > > https://www.nntp.perl.org/group/perl.perl5.porters/2019/06/msg255335.html > However, CPAN modules not from the Perl core have bugtrackers on https://rt.cpan.org which is an unrelated instance that will not be moving (they may also have trackers on github). If it matters. -Dan ___ 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 Workstation and disabled by default firewall
On Mon, Aug 26, 2019 at 8:31 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > Hello all. > > Is it okay that firewall is completely disabled by default (opened all > ports 1025-65535) on Fedora Workstation? > > I think that this is a major vulnerability and it must be fixed by > changing default zone to public. > > firewall-cmd --list-all > FedoraWorkstation (active) > target: default > icmp-block-inversion: no > interfaces: enp1s0 > sources: > services: dhcpv6-client mdns samba-client ssh > ports: 1025-65535/udp 1025-65535/tcp > protocols: > masquerade: no > forward-ports: > source-ports: > icmp-blocks: > rich rules: > I agree that this is quite ill advised. As the maintainer of the Cinnamon spin, can anyone answer whether (1) this would affect spins other than Workstation, and (2) if so, how to fix it? Thanks, -Dan ___ 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 Workstation and disabled by default firewall
On Tue, Aug 27, 2019 at 8:10 AM wrote: > On Tue, Aug 27, 2019 at 4:22 AM, John Harris wrote: > > No, that is not how this works, at all. First, let's go ahead and address > the idea that "if the firewall blocks it, the app breaks, so it's the > firewall's fault": It's not. If the firewall has not been opened, that just > means it can't be accessed by remote systems until you EXPLICITLY open that > port, with the correct protocol, on your firewall. That's FINE. That's how > it's designed to work. There's nothing wrong with that. This means that the > system administrator (or owner, if this is some individual's personal > system) must allow the port to be accessed remotely, before the app can be > reached remotely, increasing the security of the system. > > > You've already lost me here. Sorry, but we do not and will not install a > firewall GUI that exposes complex technical details like port numbers. > Expecting users to edit firewall rules to use their apps is ridiculous and > I'm not really interested in debating it. > > If the user is capable of editing firewall rules and wants to do so, that > user can surely also change the policy to not open all these ports. Yes? > That Gnome is intentionally sabotaging users and thinks they are too stupid to understand a port number associated with a service is just another example why I wish that Fedora and Redhat would put work into alternative desktops. -Dan ___ 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 Workstation and disabled by default firewall
I guess it should not be surprising, Gnome has made it clear for many years now their only target audience is infants and grandmothers. How many of these users do you think Fedora really has? -Dan On Tue, Aug 27, 2019 at 9:12 AM Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > Red Hat is written as two separate words. So you can put some work > into learning that :) > > Anyhow, why does user need to learn what port is? Can you imagine your > grandma / grandfather learning how to open some port on the firewall? > > On Tue, Aug 27, 2019 at 3:05 PM Dan Book wrote: > > > > On Tue, Aug 27, 2019 at 8:10 AM wrote: > >> > >> On Tue, Aug 27, 2019 at 4:22 AM, John Harris > wrote: > >> > >> No, that is not how this works, at all. First, let's go ahead and > address the idea that "if the firewall blocks it, the app breaks, so it's > the firewall's fault": It's not. If the firewall has not been opened, that > just means it can't be accessed by remote systems until you EXPLICITLY open > that port, with the correct protocol, on your firewall. That's FINE. That's > how it's designed to work. There's nothing wrong with that. This means that > the system administrator (or owner, if this is some individual's personal > system) must allow the port to be accessed remotely, before the app can be > reached remotely, increasing the security of the system. > >> > >> > >> You've already lost me here. Sorry, but we do not and will not install > a firewall GUI that exposes complex technical details like port numbers. > Expecting users to edit firewall rules to use their apps is ridiculous and > I'm not really interested in debating it. > >> > >> If the user is capable of editing firewall rules and wants to do so, > that user can surely also change the policy to not open all these ports. > Yes? > > > > > > That Gnome is intentionally sabotaging users and thinks they are too > stupid to understand a port number associated with a service is just > another example why I wish that Fedora and Redhat would put work into > alternative desktops. > > > > -Dan > > ___ > > 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 > ___ > 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 > ___ 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: No longer supporting mailing lists:
This conversation is pretty pointless. You are never going to convince other people to like Discourse more than mailing lists, and they are never going to convince you the other direction. -Dan On Tue, Aug 27, 2019 at 11:35 AM Gerald B. Cox wrote: > Here is an interesting discussion on "threaded discussions": > https://meta.discourse.org/t/threaded-discussion-is-ultimately-too-complex-to-survive-on-the-public-internet/63172 > > I personally don't like them. As the threads increase the discussion > becomes hard to follow... > > On Tue, Aug 27, 2019 at 12:20 PM Louis Lagendijk wrote: > >> On Tue, 2019-08-27 at 12:00 -0300, Gerald B. Cox wrote: >> >> Why is it when I say that I don't want to clutter up my email with mail >> from mailing lists I'm told it's a misconfiguration. It's not a >> misconfiguration. I don't want the forum email cluttering up my mail - and >> I don't want to use an NNTP gateway, I want to use Discourse. Why is that >> so hard to understand? >> >> On Tue, Aug 27, 2019 at 11:47 AM John Harris >> wrote: >> >> On Tuesday, August 27, 2019 7:29:28 AM MST Gerald B. Cox wrote: >> > Using mail, I have to access the archives to read the full thread. >> >> This is just due to your configuration. You could easily either save the >> mailing list to your mailbox, or use an NNTP gateway. >> >> Different people have different work flows, you like to go to Discourse, >> others prefer mail/nntp. For a lot of people (including myself) the lack of >> threading is a show stopper for their workflow. >> >> >> The mail interface in Discourse is...lacking a lot of features for a lot of >> people. Your comment "why is that so hard to understand" applies both >> ways >> >> /Louis >> >> ___ >> 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 >> > ___ > 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 > ___ 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 Workstation and disabled by default firewall
On Wed, Aug 28, 2019 at 4:27 PM Adam Williamson wrote: > That is talking about the whole idea that having a firewall enabled by > default is not as important if there are no listening services by > default; at that point you can make the argument that installing a > service that listens on a port is a conscious decision to "open" that > port. > And we are expecting this apparent target audience of people that don't understand the firewall GUI to understand that installing such a service is a conscious decision to open a port? -Dan ___ 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 Workstation and disabled by default firewall
On Thu, Aug 29, 2019 at 11:11 AM Adam Williamson wrote: > On Wed, 2019-08-28 at 23:13 -0400, Christopher wrote: > > On Wed, Aug 28, 2019 at 8:56 PM John Harris > wrote: > > > On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote: > > > > A similar idea that would keep it separate from the installer might > be > > > > to offer a dialogue as a "first-boot" action, but that seems like > it'd > > > > be a very GNOME-specific thing, and firewalld is not specific to the > > > > WM/Desktop. > > > > > > It might be okay to be a GNOME-specific thing, as that's the only spin > of > > > Fedora which is affected by this decision. > > > > > > > The default firewall config affects every user of that edition, even > > if they never use GNOME (or even use graphical boot). So, I don't know > > if this would be adequate. > > Why would you install Workstation if you didn't intend to use GNOME? > I would agree, but people do install multiple desktops after installing a spin. Such a use case needs to be considered (not sure if it matters, though). -Dan ___ 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: f32-backgrounds available for testing
On Fri, Mar 6, 2020 at 12:03 PM Luya Tshimbalanga wrote: > Hello team, > > f32-backgrounds is available for testing on > https://bodhi.fedoraproject.org/updates/FEDORA-2020-ed62604eca > > For the Design team, new change is the drop of standard, normalish, tv, > tv-wider folders in favour of a single wallpapers (aside the time of day > theme) using system settings thus tremendously saving space. > > > Happy testing. > The extras subpackages don't seem to be included in the build, will they be added? Thanks, -Dan ___ 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: Editions vs. Spins
On Mon, Jan 14, 2019 at 1:48 PM Japheth Cleaver wrote: > On 1/13/2019 10:19 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jan 12, 2019 at 07:51:34PM +0100, Kevin Kofler wrote: > >> Stephen John Smoogen wrote: > >>> Side note, I was at a loss of what you were getting at. There were > several > >>> ways it could be interpreted and has been used by people in the past to > >>> mean different things. > >> I think John's statement was pretty clear: The artificial distinction > >> between "Editions" and "Spins" needs to go away. > >> > >>> The problem is that there is an inherent conflict of resources here. > When > >>> we put everything on the download pages, everyone including the spin > >>> owners say it was too confusing. > > The issue of which spins/editions are promoted is orthogonal to the > > issue of counting. After all, counting just reflects the actual > > frequency of installations, not the reasons for it. > > > > But counting may provide a fresh look at this issue. We'll have much > > better data which spins/editions are used. If it turns out that KDE is > > more popular than previous statistics showed, or that KDE has a higher > > retention rate (the number of short-lived installations is low > > suggesting that users "like it if they see it"), this would be a > > strong argument to make the KDE spin more visible. > > > > Zbyszek > > Relying on use-data here seems counter-intuitive. Shouldn't the decision > be made based on project first principles or community goals first, with > visibility and marketing effort being put in subsequent to that to meet > those goals? > It is important for the community/project goals to align with what people actually want. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Editions vs. Spins (was: Re: F30: System-Wide Change proposal: DNF UUID)
On Mon, Jan 14, 2019 at 6:20 PM wrote: > On Mon, Jan 14, 2019 at 12:05 PM, John Harris > wrote: > > The easiest way to make any of the Spins more accessible, for them to > > have any > > chance comparable to the prominent advertising of Workstation and > > similar > > options, would be to make them more prominent on the "getfedora" > > index. This > > also have a huge effect on SEO. > > So the reason spins are not very visible -- and ought to stay not very > visible -- is that they don't get the same level of attention as the > main products, and we don't really want anybody to download those > unless they know in advance what they are doing. In particular, we > really don't want Fedora to be judged by the quality of its spins and > labs. There are a lot of them, and it's just not plausible to keep up > with quality control for every one. > > I agree that the spins in general could use more QA attention to fit this role. But it is volunteer work - the QA team can only manage so many editions, and there are two people that even touch the Cinnamon spin including myself, and one person managing almost the entire stack of software it uses, and personally I am quite disincentivized to spend time on a spin which is given such little fanfare by the project, the only reason I continue is because I believe it is objectively a better desktop environment than the ones Fedora pushes. Because it is so invisible, less people realize it exists, and because of that, nearly nobody shows up to assist. It is a chicken and egg problem. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default
On Thu, Jun 27, 2019 at 12:30 PM Björn Persson wrote: > > If there is a significant risk that the warning will be overlooked, > then how about just making the warning more visible? > > Based on experience with people installing things from CPAN for Perl, there is no "more visible" that has any appreciable impact unless it causes the process to fail. -Dan ___ 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 31 System-Wide Change proposal: Python means Python3
On Thu, Jun 27, 2019 at 2:48 PM Miro Hrončok wrote: > On 27. 06. 19 18:49, Ben Cotton wrote: > > On Thu, Jun 27, 2019 at 12:06 PM Miro Hrončok > wrote: > >> > >> So I might ask: What's the benefit of not having an unversioned python > at all? > >> > > Avoiding ambiguity. Admittedly, it's avoiding large future pain at the > > cost of small-and-frequent current pain. I'm not sure it's Fedora's > > place to drive that mindset shift, particularly if upstream is taking > > the opposite approach. > > To be fair, upstream allows us to choose. If we decide that we want > "python" > command not to exists, it's a valid choice. > > As Python maintainers, we want to make it python3. If Fedora decides that > removing it is a better way, we have the ability to do that. > > I'd argue that it brings more problems. Such as: Should there also be no > "pip", > no "pytest", no "pylint"... command? Or should we switch those to Python > 3, but > just have no "python" command? What happens if users do "dnf install > python"? > Should they get Python 3 or nothing? etc. > > Either way, we really **need** "python" to no longer be Python 2. There > are > still people "out there" who call Python 2 the "default Python" because > that's > what you get when you type "python". > As an outsider to the Python community, not having any binary or package that responds to the expected name "python" would be a disaster. -Dan ___ 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 should replace mailing lists with Discourse
On Tue, Oct 16, 2018 at 11:06 AM Ben Rosser wrote: > 2) What's the migration strategy look like? Can users on the mailing > lists be automatically added to the relevant discourse lists? > > 3) Will there be a transition period where the old list addresses > continue to work? Can they be maintained in perpetuity, or at least > aliased to the right thing? > I agree these are absolutely the most important questions to answer. Silently breaking the experience for anyone not paying enough attention is not acceptable. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Sat, Oct 20, 2018 at 6:09 AM Stephen J. Turnbull wrote: > Dominik 'Rathann' Mierzejewski writes: > > Gerald B. Cox writes: > > > > Regardless, as I mentioned above, if they have a bug, then it > > > should be reported for them to address. > > > > I wouldn't call it a bug, just bad UX for a minority(?) target > > audience. > > I'm pretty sure the Discourse developers would concede that bad UX for > email users is undesirable. I'm *not* sure they would concede that > it's bad UX. We know how to render HTML to plain text, to RTF, and so > on; Discourse deliberately chose not to do so, but rather chose a > format of their own or perhaps some existing format (this is the first > I've heard of BBcode, so I can't judge). > It is not a format of their own, but it's not appropriate for plaintext, so it sounds like a bug to me. https://en.wikipedia.org/wiki/BBCode -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Beta is GO
On Thu, Sep 24, 2020 at 2:34 PM Ben Cotton wrote: > On Thu, Sep 24, 2020 at 2:31 PM Ben Cotton wrote: > > > > The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on > > Tuesday, 17 March 2020. > > > This, of course, should read Tuesday, 29 September 2020. > It really has been a long March hasn't it... -Dan ___ 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: Cockpit depends on NetworkManager.
On Mon, Oct 16, 2017 at 9:51 PM, Matthew Miller wrote: > On Tue, Oct 17, 2017 at 03:20:09AM +0200, Radka Janekova wrote: > > so recently I managed to destroy[1] two production servers by removing > what > > I saw as useless web-config utility. Apparently Cockpit depends on > > NetworkManager, which nobody would expect and is easily overlooked. > > PLEASE FIX > > I think the bug here is that DNF is being over-zealous. NetworkManager > does not require Cockpit, but Cockpit requires NetworkManager. For some > reason, DNF thinks that Cockpit is the *only* reason NetworkManager is > installed, and "helpfully" decides to remove it. This is clean_requirements_on_remove being helpful as usual. Never should have been a default setting as I've argued before, and the first thing I disable in /etc/dnf/dnf.conf. http://dnf.readthedocs.io/en/latest/conf_ref.html#clean-requirements-on-remove-label -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cockpit depends on NetworkManager.
On Tue, Oct 17, 2017 at 7:29 AM, Jonathan Wakely wrote: > > >> This is clean_requirements_on_remove being helpful as usual. Never should >> have been a default setting as I've argued before, and the first thing I >> disable in /etc/dnf/dnf.conf. >> http://dnf.readthedocs.io/en/latest/conf_ref.html#clean-requ >> irements-on-remove-label >> > > It would be a nice feature if it hadn't been for PackageKit not > marking packages correctly in older Fedora versions. Anybody who has > done in-place upgrades has totally wrong mark-installed metadata in > their local DB, with no good way to fix that. > > Occasional bugs like NetworkManager not being marked as needed by > anything don't entirely negate the feature's usefulness. They don't, but they do add to the list of reasons why it should not be enabled by default. The other major reason is that there is (still) no feedback to the user why the extra packages are being removed. This could be fixed, but it hasn't been. Other package managers, and indeed yum before, had a specific command to enable this sort of behavior called autoremove. I would be perfectly fine with having such a command, and having the ability to enable clean_requirements_on_remove, but I disagree with its default setting. -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: IRC Announcement
On Fri, May 28, 2021 at 12:01 PM PGNet Dev wrote: > On 5/27/21 2:04 PM, Nick Bebout wrote: > > Since its beginnings, the Fedora Project has used the freenode IRC > network for our project communications. Due to a variety of recent changes > to that network, the Fedora Project is moving our IRC communications to > Libera.Chat. > > If a still-fuzzy "variety of recent changes to that network" are the > reason for this latest fire-drill/tempest, then just fyi, > A Lee's provided some documented reply, > > > https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf >https://freenode.net/news/post-mortem-may21 > > To my read it doesn't seem as clear-cut as some are making it all out to > be. If 'trust' is the underlying issue here, there seems to be enuf not > passing the smell test on 'both sides'. > > IME, projects want a place to talk that's trustworthy. > > > > caveat emptor. > Andrew Lee has a flexible relationship with the truth. This is not a both sides issue, as every other free software project has also agreed. -Dan ___ 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: IRC Announcement
On Fri, May 28, 2021 at 12:32 PM PGNet Dev wrote: > > Andrew Lee has a flexible relationship with the truth. This is not a > both sides issue, as every other free software project has also agreed. > > Well, it seems you're good then. So, great. > > Just for me, not my 1st rodeo dealing with the spectrum from > megalomaniacal-sociopathic-CEOs to petulant-lemming-staff-actions > And, like I said, to my read, not so clear cut, despite declarations that > "This is not a both sides issue". > > I just shared some add'l info that I thought was relevant so folks could > read a bit (more) & make their OWN decisions rather than just blindly do > what (arguably) "every other free software project" is doing. > That's fine. It's good to have all the information. This is just my opinion, but while everyone has made mistakes, this mass migration is due specifically to Andrew Lee's actions. -Dan ___ 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
