Re: F35 Change: "Fedora Linux" in /etc/os-release
On Tue, Mar 09, 2021 at 05:32:41PM -0500, Matthew Miller wrote: > I agree that it's a little weird at first, but as Ben Cotton said, > after the first hundred times or so it becomes natural. This is not necessarily true. Our university IT department changed its name about a decade ago, from three letters to four letters (both abbreviations). But now, about ten years later still noone apart from the officials use the new name. (Even they don't consistently use it, despite orders(!) to use the new name) I assume this is because the new name is clunkier - it could be pronounced as one syllable before and now all four letters need to be pronounced separately to not sound weird. I think this is similar to the Mandrake/Mandriva example. All the best, Astra signature.asc Description: PGP signature ___ 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: Plymouth, themes and console clearing: https://bugzilla.redhat.com/show_bug.cgi?id=1933378
On Thu, Mar 04, 2021 at 02:45:29PM -0800, Adam Williamson wrote: > Well, you could still argue it's prettier than a wall-o-text boot. And > it *does* hide the wall-o-text. On the first boot after install that's maybe nice, but usually when I look at the machine booting I either do need to see why the initramfs does not boot, which one is the first service failing or why the shutdown/reboot progress is hanging - in all of those cases I prefer the wall-o-text ;) But yes, doesn't look as nice as plymouth. xD All the best, Astra signature.asc Description: PGP signature ___ 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: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Mar 03, 2021 at 06:00:55PM +, Tim Landscheidt wrote: > Kevin Fenzi wrote: > > > […] > > > The purpose here is to make the Fedora project a more welcoming place to > > people who _do_ find those terms unwelcome. That doesn't mean everyone > > does. It means we want to be welcoming and not jerks. > ^ > > I'm personally happy to do things to make people more welcome. > > Even if they are small things and cause a small amount of work for us > > existing contributors. > > > […] > > "Disagreement is no excuse for poor behavior and poor man- > ners." I also disagree with the reasons which are usually given for the change and don't think it is *any* improvement on being more welcoming. To achieve that the focus would have to be more on the inviting and mentoring part. There seems to be a group of people which are very vocal with regard to this topic and also seem to believe those reasons are valid and important, so if this fixes their issue I'm fine with that. I don't do it on the git-servers I host, but for Fedora this was decided, implemented, didn't break too much and probably won't be reverted. It doesn't make packaging not much more difficult, so I don't see any major disadvantages to having it this way. All the best, Astra signature.asc Description: PGP signature ___ 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: Donate 1 minute of your time to test upgrades from F33 to F34
Another dot on the map: Issues: - rdma-core (known problem) - jami (third party repo, does not have f34 yet) - mpd (requires libupnp.so.16, but there seems to be only libupnp.so.17 in f34 available) Error: Problem 1: package jami-daemon-20210219.1.9530a07-1.fc33.x86_64 requires libupnp.so.16()(64bit), but none of the providers can be installed - libupnp-1.12.1-2.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package jami-daemon-20210219.1.9530a07-1.fc33.x86_64 Problem 2: rdma-core-33.0-2.fc33.i686 has inferior architecture - rdma-core-33.0-2.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package rdma-core-33.0-2.fc33.i686 Problem 3: cannot install both libupnp-1.14.1-1.fc34.x86_64 and libupnp-1.12.1-2.fc33.x86_64 - package vlc-core-1:3.0.12.1-6.fc34.x86_64 requires libupnp.so.17()(64bit), but none of the providers can be installed - package jami-daemon-20210219.1.9530a07-1.fc33.x86_64 requires libupnp.so.16()(64bit), but none of the providers can be installed - problem with installed package vlc-core-1:3.0.12-1.fc33.x86_64 - package jami-20210219.1.9530a07-1.fc33.x86_64 requires jami-daemon = 20210219.1.9530a07, but none of the providers can be installed - vlc-core-1:3.0.12-1.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package jami-20210219.1.9530a07-1.fc33.x86_64 Problem 4: package vlc-core-1:3.0.12.1-6.fc34.x86_64 requires libupnp.so.17()(64bit), but none of the providers can be installed - cannot install both libupnp-1.14.1-1.fc34.x86_64 and libupnp-1.12.1-2.fc33.x86_64 - package vlc-1:3.0.12.1-6.fc34.x86_64 requires libvlccore.so.9()(64bit), but none of the providers can be installed - package mpd-1:0.22.4-2.fc34.x86_64 requires libupnp.so.16()(64bit), but none of the providers can be installed - problem with installed package vlc-1:3.0.12-1.fc33.x86_64 - problem with installed package mpd-1:0.22.6-1.fc33.x86_64 - package vlc-core-1:3.0.12-1.fc33.x86_64 requires libdav1d.so.4()(64bit), but none of the providers can be installed - vlc-1:3.0.12-1.fc33.x86_64 does not belong to a distupgrade repository - mpd-1:0.22.6-1.fc33.x86_64 does not belong to a distupgrade repository - libdav1d-0.7.1-2.fc33.x86_64 does not belong to a distupgrade repository All the best, Astra signature.asc Description: PGP signature ___ 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: Delta RPMs in Fedora 34
On Mon, Jan 04, 2021 at 06:29:13PM -0500, Matthew Miller wrote: > I also remember when this was a killer feature for Fedora, and without any > real way of judging use and demand, I'm hesitant to kill it off. But that's > definitely plan B. We can point people who are in low-bandwidth situations > at Silverblue, CoreOS, and Kinoite as the preferred approach. It is also very difficult to measure - for my part I'm happy for every MB saved when downloading updates at home, because it directly translates into waiting time. At work I don't have a bandwidth problem, so it's way less of an issue there. But I don't see anywhere how much the potential is - iirc correctly it sometimes saves hundreds of MBs, which translates into something like 10-20 Minutes saved time. Even though it's an after-the-fact information I'm still happy it doing its job. (Interestingly on the last update almost half of the md5 sums mismatched for the drpms, which increased download size from 12.3MB to 14.0MB - but this seems to be a rare problem) Personally I'd like to stay on regular Fedora Workstation / Fedora Server - I'd probably decide to take increased download times instead of switching distros/editions if drpm gets removed. All the best, Astra signature.asc Description: PGP signature ___ 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: Stale proven packagers
On Thu, Dec 24, 2020 at 11:35:03AM +, Peter Robinson wrote: > On Thu, Dec 24, 2020 at 10:43 AM Leigh Scott wrote: > > > > > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > > > > > > > > > > > It does support it, but AFAIK does not require it. > > > > > > Arguably those with elevated access (provenpackagers(*)) > > > should be required to use a hardware token such > > > as a FIDO2 authenticators with biometrics and/or > > > PIN required (some phones with biometrics are > > > are equivalent to external tokens) where passwords > > > themselves can away. That may be a bridge too > > > far at this point, but I would like to see that as a goal > > > to work towards (2021 should be the year passwords > > > die according to Microsoft). > > > > Are fedora going to provide us with the FIDO2 authenticators with > > biometrics hardware? > > My current FIDO U2F key just has a button to press. > > There's apps too Ad biometrics: There currently exists no biometrics authentication option, which has not already been broken, sometimes even before release. This only adds a false sense of security. (Fingerprints can't be just reset/renewed too) Apps are *never* equivalent to physical tokens, as phones do have a direct network connection with exposed services or network submitted code run on the device almost always. Requiring a higher security level for some things is fine, as long as it is not too tedious - otherwise people will write workarounds for it. FIDO2 itself seems to be current thing, but the biometrics option doesn't add anything useful. Ad expiration of pp accounts: Confirmation e.g. once a year by the same person is fine (with appropriate reminder emails/notifications), but as soon as you add more requirements from other persons it makes it more political. All the best, Astra signature.asc Description: PGP signature ___ 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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote: > That would be amazing! In order for it to remain as an edition, we (speaking > generally for the Council) like to see regular meetings -- at least monthly. I'll check the situation there - if there are more people interested in a meeting I'll definitely join. There is a set date currently, I can make that next week I think and for now I'll just use that one. > There are two open issues in the tracker at > https://pagure.io/fedora-server/issues, and even if it's not ever a flood of > things just making sure they're looked at helps keep things going. It seems to me that both can be closed: - #4: the image target size seems to be fine (not whats in the ticket, but the image also matches those sizes) - #5: this seems to be in the wrong group - it looks like it belongs to pagure.io/cloud-sig > […] > One outstanding thing that could be worked on is the merger of the Fedora > Cloud Base image and Fedora Server. We agreed that this should be done > several Flocks ago, but no one has had time to actually make it happen. Until now I thought of both as having a very different target audience, I've never looked at Cloud Base, as I almost completely self-host. I don't really understand why it should be merged, is there some document or chat log for that? > There was also talk of working more closely with Ansible on system roles. > I'd love to see that revived too! There is also potential for greater > collaboration with CentOS and the CentOS Stream project. I'd love to have a > clear, non-competitive answer for each of these projects on when one should > use what. Same as above, I'd like to read up on that. I'm not sure what "system roles" relate to, I've found linux-system-roles.github.io and I know a big chunk of fedora-infra systems is managed using ansible. All the best, Astra signature.asc Description: PGP signature ___ 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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
Hi! On Wed, Dec 02, 2020 at 11:11:02AM -0500, Ben Cotton wrote: > One uncomfortable question that this raises: is it time to de-Edition > Fedora Server? Please don't, for me it is the Version I'm currently migrating my Centos 7 boxes to, so having it properly tested and being high on the "if it breaks it needs to be fixed"-list is kinda important for me. > As far as I can tell, the Server Working Group has essentially been > dormant for a while, with sgallagh coming in to fix issues when they > arise. So one alternative to demoting Server would be for someone to > revive that WG. Count me in, but honestly I don't see a lot of things that need to be changed - I'm quite happy with how it behaves. But aside that I'm happy to help with those issues that come up. All the best, Astra signature.asc Description: PGP signature ___ 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: Orphaned packages looking for new maintainers
I've taken: On Mon, Nov 30, 2020 at 12:12:21PM +0100, Miro Hrončok wrote: > snownews orphan 0 weeks ago > steghide orphan, s4504kr 1 weeks ago > synergy dchen, opuk, orphan 1 weeks ago They seem easy to fix, synergy even has been fixed, but the FTBFS-bug hasn't been closed. Astra signature.asc Description: PGP signature ___ 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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings
On Fri, Sep 11, 2020 at 01:36:38PM +0200, Björn Persson wrote: > So where is a global pool of volunteer-provided DNS resolvers similar > to pool.ntp.org? I've never heard of one, and I suspect it's not > advisable to do that with DNS. There is currently no such thing that I know of, but lacking that the next best thing is to also add other providers as FallbackDNS, so that no single provider has all the requests for the machine. e.g.: FallbackDNS=8.8.8.8,9.9.9.10,1.1.1.1,208.67.222.222 I've included one address for the four big providers I know of, and (if possible) the non-censoring variant. I'm not sure if systemd uses them in a random order, but if it can this would be preferable. All the best, David signature.asc Description: PGP signature ___ 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 33 System-Wide Change proposal: Make nano the default editor
On Mon, Jun 29, 2020 at 06:11:58AM -0400, Pavel Valena wrote: > TL;DR please, +1 for nano, as "trial by fire" is not a good first > experience for someone who just wants to get something done. This is not "trial by fire", it is just a different interface than people are used from notepad.exe. Vi may be not a good first experience for someone who needs to edit a file once during the whole lifetime of that os installation, but it is useful to those who have to do it lots and lots of times or even if it is just "regularly". > I don't think this should be matter of preference of current Fedora > users or developers. Instead it's all about first impressions with a > Linux distro (or second..) for fresh users. It should. I'm willing to argue that new users for Fedora try it, because they got it recommended by someone who uses *and* likes it. If you ignore the preferences of the current users you're cutting off new users before they even try it. > A developer/poweruser can later change EDITOR to something their > familiar with, on purpose. This is easy for one machine, but not if you have to maintain lots of them. That is why I'm proposing to put that into the gnome-welcome-screen that it adds EDITOR=… to the .bashrc only for that user. That way a regular user has it set, while users created via useradd/adduser, kickstart, … by more experienced users can have useful defaults for them. > Invoking vi for fresh user is like deciding for them they need to > learn vim , although they're learning how to use git f.e., > and therefore worsens the experience they'll have IMO. Well, they also have to learn that they can't copy and paste via Ctrl+c/Ctrl+v in the commandline, but that is no reason for anyone to change terminal behavior there. (lots of git tutorials mention 'git commit -m "message"' anyway, so you don't see an editor, and don't need to learn vim ) > Btw. nano is just simple by the looks, but has lots of improvements > under the hood. With options like f.e. -xAFEGHuiBPUWzw it's a > completely different editor I use for my everyday work for years > now... that is fine, but none of those options will be enabled by default if you have to work as sysadmin on a machine which isn't your primary one. For "mostly unconfigured" machines we need a default which doesn't stand in the way of fixing systems but enables working efficiently. Unfortunately I think this arguing is moot, as the issue seems to have been decided already anyway. I only remember one change "proposal" to actually being pulled back in the last year, and I'm really disappointed about having fake discussions on devel@ whilst the decision has already been made. There are some where the Change proposal owner actually considers other options which come up in the discussion, but for a few of them there is not even an answer, and for some of them the only Change proposal owner response is "but it is the best option". All the best, David signature.asc Description: PGP signature ___ 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 33 System-Wide Change proposal: Make nano the default editor
On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote: > "In the last year, How to exit the Vim editor has made up about .005% > of question traffic: that is, one out of every 20,000 visits to Stack > Overflow questions. That means during peak traffic hours on weekdays, > there are about 80 people per hour that need help getting out of Vim." Please don't just simply take that number as "number of people trying to exit vim" One of those threads on stackoverflow was a highly popular meme and was featured in quite many webpages. I myself probably visited that thread about 5 to 10 times despite being a vim user for about 10 years now, just because I was provided with the link to that specific thread or because I wanted to show someone that thread. All the best, David signature.asc Description: PGP signature ___ 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 33 System-Wide Change proposal: Make nano the default editor
On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote: > The most user friendly solution is to have nano by default with a very easy > way to revert to vim for anyone that knows what they are doing. No, it is not. It is user friendly to the users only using the command line a few times or the users who prefer nano. For users having to edit files on a lot of different systems this is actually harmful and leads to bad behavior. On a lot of systems I manage new users don't get a default shell - which is reasonable for service users - which led to the behavior that I only edit files as root - I think the reason is that switching to a service user ends up in /bin/sh and tab completion often does not work anymore. Maybe it is an option to limit this change to Fedora Workstation and non-root accounts only? Or even better to put it as default only for users created via GUI? This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc from /etc/skel. I'm fine with configuring it on my machine, but as I administer a lot of machines (both Workstation and Server) I think the default for admins should stay vi. So it is a -1 from me for the current variant of the proposal. All the best, David signature.asc Description: PGP signature ___ 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 33 System-Wide Change proposal: swap on zram
On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: >> This is not generally true, only if RAM gets so tight that applications >> start competing for swap. >> This is why I've proposed test cases testing exactly that, as for >> the case of persistent swap I'd expect the outcome to be a clear win for >> disk swap. (Although this can in some cases also be seen as bug, as this >> would be applications not really using the allocated space) > > I don't follow this. Where are the proposed test cases? And also in > what case are you saying disk swap is a clear win? I was referencing the testcases from the email before that, but your webkitgtk compile might also work for that. What I described as persistent swap is stuff that gets swapped out and not swapped back in for hours or days. >> Until about 95% mem usage I'd expect the disk swap case to win, as it >> should behave the same as no swap (with matching swappiness values) > > Why would disk based swap win? In this example, where there's been no > page outs, the zram device isn't using any memory. Again, it is not a > preallocation. Yes, its a quite boring example, but I've included it for completeness as a border case. This is just the few megabytes it needs preallocated, whilst swap is not in use at all. >> At 150% memory usage assuming a 2:1 compression ratio this would mean: >> - disk swap: >> has to write 4G to disk initially, and for reading swap another 4G >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) >> - zram, assuming 4G zram swap: >> has to write 8G to zram initially, and for reading the data swap 16G >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) > > swap contains anonymous pages, so I'm not sure what you mean by > initial. Whether these pages are internet or typed in or come from > persistent storage - it's a wash between disk or zram swap so it can > be ignored. I was calculating it from the viewpoint of data, e.g. paging out a certain amount of data, and paging it in again. "Initial" would be the amount of data when paging in. What is definitely different is that I thought of 1 or 2 processes eating away memory, but not of many thrashing swap. For those it is definitely not possible to recover from it once thrashing has started. > Also I don't understand any of your math,how you start with a 4G zram > swap but have 8G. I think you're confused. The cap of 4GiB is the > device size. The actual amount of RAM it uses will be less due to > compression. The zram device size is not the amount of memory used. > And in no case is there a preallocation of memory unless the zram > device is used. It is easy to get confused, by the way. That was my > default state for days upon first stumbling on this. I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a 4G zram device. I've calculated with filling the zram device to the max, so it will use the full 4G. (the 4G limit was arbitrarily chosen) > This task only succeeds with ~12+G of disk based swap. Which is just > not realistic. It's a clearly overcommitted and thus contrived test. This sounds like it's just failing earlier. But it's still a test case. > But I love it and hate it at the same time. More realistic is to not > use defaults, and set the number of jobs manually to 6. And in this > case, zram based swap consistently beats disk based swap. > Which makes sense because pretty much all of the inactive pages are > going to be needed at some point by the compile or they are dropped. > Following the compile there aren't a lot of inactive pages left, and > I'm not sure they're even related to the compile at all. Especially for a compile those pages are needed quite soon, so thrashing occurs earlier too. For this it makes a lot of sense that zram is a big benefit for it. When I reached the memory limit my usecase was usually having chrome and firefox open, with firefox having about 500 open tabs, so most of the data could stay in swap until I triggered swap in, which is very different from a compiling. > Even under manual control we've got examples of the GUI becoming > completely stuck. Long threads in devel@ based on this Workstation > working group issue - with the same name. So just search archives for > interactivity. Or maybe webkitgtk. I'm afraid I've read most of those, I usually read all mails to devel@. So far it seemed mostly like exceptions, but it might also be a specific configuration on my systems and this issue is more widespread. > earlyoom will kill in such a case even if you can't. It's configurable > and intentionally simplistic, based on memory and swap free > percentage. I don't have any experience with it, as I use the time from slowdown until OOM to try to manage the issue myself, usually successful. But as mentioned above, I might have a specialized usecase, so my experience might not reflect the average users' experience. All the best, David signature.asc Description: PGP
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > To me this sounds like too much dependency on swap. That's not what I meant, I wanted to emphasize the different values of disk storage vs. RAM. As said in another email it doesn't matter at all if there is 0% or 90% of disk swap usage, while RAM usage can be quite essential. (This is in case swapped out stuff stays swapped out.) > What people hate is slow swap. This is not generally true, only if RAM gets so tight that applications start competing for swap. This is why I've proposed test cases testing exactly that, as for the case of persistent swap I'd expect the outcome to be a clear win for disk swap. (Although this can in some cases also be seen as bug, as this would be applications not really using the allocated space) > For sure there is an impact on CPU. This exchanges IO bound work, for > CPU and memory bound work. But it's pretty lightweight compression. > > And again, whatever is defined as "too much" CPU hit for the workload, > necessarily translates into either "suffer the cost of IO bound > swap-on-drive, or suffer the cost of more memory." There is no free > lunch. It really isn't magic. Yes, that seems obvious to me. What would be interesting is the point, where one is significantly slower than the other one. The theoretical testcase is writing data to memory and reading it again. For this case I'm assuming 8G RAM as total memory. Until about 95% mem usage I'd expect the disk swap case to win, as it should behave the same as no swap (with matching swappiness values) At 150% memory usage assuming a 2:1 compression ratio this would mean: - disk swap: has to write 4G to disk initially, and for reading swap another 4G (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) - zram, assuming 4G zram swap: has to write 8G to zram initially, and for reading the data swap 16G (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) It would be good to see actual numbers for this, so far I've only seen praises on how well the compression ratio is. (Plus the anecdotal references from a few people) But this should also be tested with actual CPUs and disks. zram is obviously faster, but at which point is the overhead from compression, the reduced unswapped memory and the doubled number of swapping operations starting to be smaller than the overhead from SSD read/write speed? Is this almost immediately the case or is this only closely before being OOM anyway? The "too much CPU" limit would be the actual wallclock time testprograms take without hitting OOM. If a program using 120% memory takes 90 seconds to complete its run with swap, and 60 seconds with zram swap, that would be an improvement. If it's 120 seconds the most likely issue is "too much CPU used for compression or swapping". > One thing this might alter the calculus of is swappiness. Because the > zram device is so much faster, page out page in is a lower penalty > than file reclaim reads. So now instead of folks thinking swappiness > should be 1 (or even 0), it's the opposite. It probably should be 100. > > See the swappiness section in the Chris Down article referenced in the > proposal: > https://chrisdown.name/2018/01/02/in-defence-of-swap.html This article states that setting swappiness to 100 could already be working fine on SSDs. But yes, swappiness definitely has an influence on this. I assume testing the edgecases (something around 2 and something around 100) should be enough. > There are worse things than OOM. Stuck with a totally unresponsive > system and no OOM on the way. Hence earlyoom. And on-going resource > control work with cgroupsv2 isolation. This is true boxes where the offending processes are not under manual control, where it's better that any exploding program is being terminated as soon as possible. It's exactly the other way round for manual controlled processes, as a slowdown before getting to OOM is sometimes enough to be able to decide what to free up/terminate, before OOM-Killer just goes in brute-force. That doesn't work too well nowadays, as quite often the swap on disk fills too fast on SSDs before I've got time to kill something. Usecase: I've got two browsers running, and I'm working in something memory intensive in one of them. When experiencing slowdown I'd like to kill the other one, and not terminate the more memory hungry where I'm currently working at. All the best, David signature.asc Description: PGP signature ___ 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 33 System-Wide Change proposal: swap on zram
Hi! On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: > 5GB of swap space that normally would be on disk is now taking less than 2G > of RAM. Instead of the usual 6G in the disk swap, now I have less than 2. What's bugging me about this thread is that quite a few people made comparisions resulting in "compressed zram is smaller than uncompressed disk swap". For me this seems quite obvious, and looks like flawed testing. Wouldn't it be more correct to also compress disk swap to compare size? This would probably make the size-argument void, as I'd expect them to be the same size. If it's not, that would be an useful data point. Also I don't care about 10GB stuff sitting in disk swap, whilst 1GB of RAM could be quite essential. This leaves overall performance as a potential benefit of zram swap. What almost noone wrote about is CPU usage, for which I saw two anecdotal references: "no change" and "doubled CPU usage". It would be interesting to see a comparison of swap, compressed swap and zram swap performance while having processes competing on swap. E.g. System with 8 GB RAM: * 2 processes with 3.5 GB memory each this would leave about 1GB for the system itself, so with disk swap there should be not much swapping and with zram swap I'd expect little swapping too. * 2 processes with 4 GB memory each this would force light disk swap usage in the first two cases, I'm not really sure what it would do to zram swap. * 2 processes with 4.5 GB memory each this would definitely lead to constant swapping, but it should still fit in zram swap, with a ratio of 2:1 it should theoretically fit in a 2GB zram device, and realistically in a 4GB zram device. For the programs I'd think of something allocating memory and writing/reading random parts of it, running for N iterations. Interesting points would be: average CPU usage and wallclock time for each of the processes. I've left out the obvious cases of "not enough memory usage to use any of those anyway" and "too much memory usage that it results in oom". oom killer should not invoke in daily usage anyway, I see that as a sign for "something has gone seriously wrong", comparable with "program segfaults on start". All the best, David signature.asc Description: PGP signature ___ 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: AskFedora: Can someone please answer this question on security fixes on
On Sat, May 16, 2020 at 12:38:06PM +0200, Dominique Martinet wrote: > I'm curious about this point, there is a security team[0] so it could be > interesting to get one of them on the list? I'm not following quite > close enough what they do... Currently there is not too much activity in the security team. Historically the tasks were mostly keeping an eye on open security issues and checking for long unfixed issues. For packages having the same maintainer in RHEL and Fedora I suppose there is a synergy effect that fixes also land in Fedora early. In both irc channels (#fedora-security, #fedora-security-team) now and then someone joins with a security related question, there are a few people there answering those. The mailinglist is mostly dead - I'd guess it might be a good idea to send out security reports again. All the best, David signature.asc Description: PGP signature ___ 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: Proposal: Revise FESCo voting policy
On Wed, May 13, 2020 at 12:44:44PM +0200, Kevin Kofler wrote: > The rules you propose there lead to the ridiculous effect that people who > want to astain will instead actually leave the meeting […] Yes, true, that could happen. Thats a good thought. > The whole definition of an abstention or recusal is "my vote should not > matter". If we do not want to allow this kind of abstentions, then we need > to not allow abstentions at all and require people to vote -1 instead. > Recording a 0 and actually treating it exactly like a -1 does not make > sense. Having abstentions can still be used for signalling that in future the change could be ok - if it is interpreted as: 0 = Currently I can't say, that this should go through for $reason, -1 = This should not go through, and this will not change) If abstentions would lower the necessary +1 votes, this would automatically give the author of a proposal a +1 vote for the proposal, depending on the author being in FESCo himself/herself. I think finally it boils down to the question, if it should be a bar that should be reached / "at least x people are in favor" or if it should be a majority vote / "more people in favor than against" All the best, David signature.asc Description: PGP signature ___ 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: Proposal: Revise FESCo voting policy
On Mon, May 11, 2020 at 05:36:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > One strong argument for the proposed change is that, currently, an > abstention or recusal (TIL that's the proper term) is essentially > equivalent to a negative vote. (As long as we require +5 to pass, > any vote apart from +1 has the same effect.) > > In a hypothetical case where three or four FESCo members were involved > in a change and decided to recuse themselves, a proposal gets a very > high bar of 5/6 or 5/7 votes. If one or two voting members are absent, > the change may not even pass even if *all* non-abstaining members are > in favour. Especially in the case of recusal it should be a higher bar, to keep the assessment on the same level. If a non FESCo member proposes a solution, this person needs to convince 5 people, that their solution is good. If a FESCo member proposes a solution, this person would only need to convince 4 people (or less, depending on the final rule), that their solution is good. A positive voting result should always be a statement, that at least 5 people in FESCo can approve the thing in question, to the best of their knowledge. In the case that a FESCo member assumes a conflict of interest for her/him this should just lead to a self-removal from the process (either by voting no, which seems weird, or by abstaining, which counts as no, but doesn't seem weird) The result should be the same, that 5 FESCo members (optimally with a minimum amount of conflict of interest) can confirm that the thing in question should happen. Removing people not attending the vote from the quorum can be discussed, but if a lot of people either don't care about the question or explicitely don't vote for some reason, this is probably also not a vote that should go through. All the best, David signature.asc Description: PGP signature ___ 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: Feedback on default partitioning and encryption
On Tue, Apr 28, 2020 at 03:51:57PM -0400, Simo Sorce wrote:
> If the threat model is just stolen/lost laptop/disk then encrypting the
> user data only would be sufficient.
Strictly speaking I'd say /etc/shadow, /var/lib/{pgsql,mysql}/,
/etc/sysconfig/network-scripts/ and /etc/NetworkManager/ are
also quite likely to contain user data - the first as a
bruteforce-target, the second as these are quite often installed on dev
machines (in my experience), and the others as they often contain
passwords in plaintext, which may be even more critical as the actual
user data.
I'd say there is no way around full disk encryption, maybe lifting the
hard restriction on not having double encryption might be an option, but
I don't have any performance data on that.
All the best,
David
signature.asc
Description: PGP signature
___
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: CPE Git Forge Decision
On Mon, Apr 06, 2020 at 04:02:34PM +0100, Leigh Griffin wrote: > Ok let's scenario this out so as several people want us to restart […] In this context of "restarting the scenario": > How do we accommodate that when our other stakeholders' needs are now > not being met as a whole and when the original requirements needs are > being satisfied by the choice of Gitlab (which will most likely be CE > for Fedora). This is to be taken with a grain of salt. There are quite a few people in this thread mentioning that it conflicts with the Fedora mission statement - which I'd see as being part of the original requirements implicitely. This might be less problematic with GitLab CE, which I assume seems to be the current plan. > What happens then, how do you suggest we proceed at that point? The > other stakeholder groups are already progressing with Gitlab and we > can do that for them and pause the Fedora move in this direction if > that was the scenario. What happens after months of debate if we > cannot bridge that divide? That is very easy. If it is not *possible* to have a common solution, it is necessary to have separate solutions. Everything else would be forcing a stakeholder to a solution not meeting their requirements. And yes, if one stakeholder (eg. Fedora) just insists on Pagure, and another stakeholder (maybe that internal RedHat group?) just insists on GitLab, you can either force the decision, or have both. > What happens when Pagure is sunset as the CPE team cannot run it / > maintain it? I'm genuinely curious here as if this is a path the > community want to go down then engage with Council on it but I think it > could be harmful for the project as a whole. If Fedora continues to use Pagure, and the RedHat internal group uses GitLab, and CPE sunsets Pagure, this means, another team needs to take over. (Which is not a GDPR problem as long as there is no data in there which is not allowed to be there anyway. Even then access can be provided, if necessary) After that the CPE does not have fedora-dist-management on their plate anymore and can focus on different things. Budget: Depending on what percentage of CPE teams duties are seen as fedora-specific-dist-management that might also mean some reduction in size of the CPE team in favor of the new fedora-dist-management-team. (Can also be seen as some people switching from CPE to the new team) Later it might be possible for migrating the RedHat internal group on Pagure, or Fedora on GitLab, but that needs to come from inside the community/team, and not be forced on a community/team. > That's not my choice though and until otherwise told, we are > progressing in this direction. With this you're actively choosing to continue acting following *your* decision. As mentioned in another post, it might be best to pause the whole thing for some time, an then try another path on how to proceed forward. (There is no reset, what has been done can't be just "reversed") And yes, this means not pushing for a solution in the "pause time", and yes, this also means no dicussions with GitLab, and no trying to make Pagure more GitLab like, no waiting until the dust settles to just continue with the GitLab path, and no forcing the "pause time" to be so long, that Pagure is chosen due to process stalling. That means first focussing on how to resolve the situation, before taking another step. It's obvious that there is a big problem right now, and it needs to be addressed first. If it is important to you that some formal body pauses the process and not yourself, please either name that entity or preferably request a statement about pausing or continuing the planned process yourself. From other emails it seems this formal body is the Council, but I'd like to have a confirmation for that assumption. All the best, David signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
Hi, On Mon, Mar 30, 2020 at 12:38:16PM +0100, Leigh Griffin wrote: > The decision is made and we are proceeding to engage with Gitlab and > unfortunately that won't be reversed as a decision. I haven't expected this situation, so I've read up a bit on the whole thing. From the outside it looks that the CPE team is trying since about a year to get rid of as many services as possible, due to having not enough resources to handle all. (I've only been looking at devel@ and blog posts, there is not much else I could find about the CPE team) The problem I think I see is, that there seems to be no option of giving away responsibilities - the only advances I see are either "we'll replace this with something we think is easier" or "lets turn it off". I see one exception: Fedocal, where this list has been asked, if someone wants to take over. Unfortunately that seems to be stuck due to bureaucracy. What I don't understand is, why a decision this big is not taken by FESCo (or Council) and the CentOS Governing Board itself. After all in the Blogpost about how the CPE team is planning to do things[1], it is stated: "Our intention is to run all of the apps through the Fedora Council first, in case the Council prefers any specific alternatives to a particular service or app." (I'm also not sure why the article states the Council directly, and not FESCo) It sure feels like the CPE is not bound by either FESCo, CentOS Governing Board or Fedora Council - this whole thing feels quite arbitrary. Maybe it would be wiser to consider this as a formal error and either re-do the decision process or hand the decision off to the Fedora Council and the CentOS Governing Board (maybe as a joint decision?) [1] https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ All the best, David signature.asc Description: PGP signature ___ 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: Ideas and proposal for removing changelog and release fields from spec file
On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote: >> Another idea would be generating a changelog-entry from git history when >> creating an update in bodhi, and there is no pre-existing >> changelog-entry for the current version. > > But Bodhi changelogs is not what user can read on his/her machine when > examining e.g. dnf check-update --changelogs. These are imho rpm > changelogs. So the rpm spec changelogs are the most important. Ah, sorry, what I meant to say is bodhi modifying the .spec file, adding the changelog line, and committing it, before building the package. (similarly like the releng commits when rebuilding stuff for new releases) But when I am thinking more about it I think it won't work, as bodhi would need to rebuild the package then. (afaik it does not, as koji built it already) An alternative might be something like modifying "fedpkg build" to check for missing changelogs and ask something like: "your package does not contain a changelog entry for . should we add the following entryies to the changelog for ?: " maybe even with the option of modifying the lines? All the best, Astra signature.asc Description: PGP signature ___ 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: Ideas and proposal for removing changelog and release fields from spec file
On Thu, Feb 27, 2020 at 08:08:49AM +0100, Dan Čermák wrote:
> For the changelog: yes please, generate it from the commit log! They are
> more or less the same for all my packages and I'm getting tired of copy
> pasting the same text into %changelog and git commit.
Another idea would be generating a changelog-entry from git history when
creating an update in bodhi, and there is no pre-existing
changelog-entry for the current version.
This would not break the option to build a package from just one file.
Having it all in one file is a big bonus to fedora, you can just
download that file and build your package and not worry about the whole
git-workflow, or having to check if you downloaded all files (not
completely true in case of patch files).
It also would remove the need to copy messages from git log to the
changelog. (some people complained about that - not only this message)
I'm also not really a fan of "git as single source of truth" (has been
mentioned a few times in this thread) - for me git is just a tool
ensuring that git history was not modified.
The *actual* source of truth is still the .spec file in the commit that is
used to build the package - nobody is ever looking at old commits except
for checking for malicious changes. (at least for spec files, with code
it is useful for bisecting bugs).
For end-users it might be useful to get the changelog alone (for that it
does not matter if it is generated or copied from the .spec), but I
never had any use for the changelog without the .spec file, as this
gives me the context to the changes in the .spec file.
But after all I do not care too much about how changelog is created, as
long as the previous functionality is still preserved - my git log
messages contain information about the .spec file changes while the
changelog contains changes about the functionality of the package.
("what have I changed" (git) vs. "what has changed for you" (cl))
All the best,
Astra
signature.asc
Description: PGP signature
___
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: Change proposal discussion - Optimize SquashFS Size
On Thu, Feb 06, 2020 at 03:05:26PM +0100, Kevin Kofler wrote: > […]Fedora reportedly has millions of users, but I have no way of telling how > many of those are actually affected by the longer download time […] To add another aspect, that cannot be counted properly (and thus being a personal preference): Due to my linux-usage I do need around 3 or 4 different distros available at the same time. To avoid re-downloading it every time (which usually is at least 20 to 40 minutes waiting time, which I could use to do something more productive), I store the images locally. As my laptop is already severely restricted on disk space, I don't use the full images anyway, but the netinstall images. There is one exception, where I do use the full image, which is as a base for a kickstart managed installation. For all other cases I ignore the full images (this applies to Debian as well as Fedora) - as I do know what I want to install I can use the netinstall variants. This has multiple advantages for me: * image download is faster (less stuff I don't need) * total installation time is faster (only downloaded what is needed) * I can store multiple distros (currently my free disk space is 2.4G) * I don't have to remove that much stuff after installation But granted this is only a usecase for people already knowing what they want, not a (maybe more) regular "I'm a new user and want to try this". All the best, Astra signature.asc Description: PGP signature ___ 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
[EPEL-devel] Re: RFC: Remove opensmtpd from EPEL releases
On Thu, Jan 30, 2020 at 01:49:55PM -0500, Stephen John Smoogen wrote: > Currently opensmtpd has a high level remote CVE and several others from the > release listed. I have tried to compile the updated version but […] According to the oss-security list[1], this vulnerability has been made exploitable in May 2018 - the version in EPEL (and Fedora) is 6.0.3, which was released on Jan 4, 2018[2]. > I would like to remove opensmtpd from EPEL. If someone wants to fix/patch > it that would be great also but it might become a long war of attrition. I'd prefer just retiring the epel branch. I'm not using it myself, but as it seems the CVEs I could find for OpenSMTPd do not affect the EPEL version I wouldn't remove/obsolete already installed packages. In Fedora there seems to be activity in OpenSMTPd (only checked bugzilla[3]), so maybe the Fedora Maintainer is interested in also taking the EPEL branch? (I've cc'ed the Fedora Maintainer, hope that's okay.) All the best, Astra [1] https://www.openwall.com/lists/oss-security/2020/01/28/3 [2] https://github.com/OpenSMTPD/OpenSMTPD/releases?after=opensmtpd-6.4.1p1 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1742449 signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: What would it take to drop release and changelog from our spec files? (and do we want to?)
On Mon, Jan 13, 2020 at 12:20:15PM +0100, Miroslav Suchý wrote: > Dne 10. 01. 20 v 18:21 Iñaki Ucar napsal(a): > > Most of the time, I end up copying the spec changelog in the commit > > message and I don't change the update template, > > +1 > Thou, occasionaly I *delete* some of those commits as they are unnessary in > changelog. E.g.: > > * typo fix > * revert of > * previous fix was not complete... It seems I'm using git quite differently. My spec file changelog describes what the spec changes did in regard to functionality or version changes of the tool. My git commit messages usually try to summarize, what happened to the (dist-)git-repo - mostly stuff that can be seen in `git show --stat`, although sometimes I describe what I changed inside a file. The field for bodhi I usually copy from the changelog - but to be honest I only fill it, because it's there - I don't even really know what it is used for, except being shown on the update page. On the other side when I'm looking for something, because something broke or whatever, usually I go to the spec-file on src.fedoraproject.org[1] first, and if I can't find the reason I'm looking for in the first few seconds I take a look at the changelog, which for convenience is right there. Didn't even know about `rpm -q xx --changelog` - quite nice, but as I prefer to look at the spec file instructions first anyway I'll probably still check there. (Usually I look for a specific Patch file or configure-flag, so the directly checking the spec is faster) For me this is a plus and one of the reasons I do enjoy packaging for Fedora more than I enjoy packaging for Debian - one single spec file vs. many files, and each single one of those has a different format. But I also do understand that separating the changelog from the spec file might have its benefits and that duplication of the messages for people using the git log message as changelog messages is annoying. All the best, Astra signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Dec 09, 2019 at 09:25:06PM -0700, Chris Murphy wrote: > The installer doesn't support such a configuration. No portion of the > bootloader nor the boot volume, can be encrypted. I do consider this a bug, but as there is no stable solution for that right now we can't just "fix it". > While the hibernation image could be encrypted, it's not by default. > So where's your pre-existing complaint and feature request that this > should have been enabled by default a long time ago? Why are you only > complaining about things when people have a proposal that doesn't > align with what you want, almost as if you just want to argue for the > sake of arguing? There is no need for a pre-existing complaint - if there is some new proposal coming up and someone sees a fundamental flaw that does not automatically make the person pointing that out responsible for fixing the issue the proposal tries to fix. A proposed fix for an issue is only good if it fixes more stuff than it breaks - and the opinions about this seem to diverge for now. There is always the option "let us just try it and see what happens", but as it covers a very sensitive area there is a natural tendency to being more careful about introducing change than usual. > What's on the table in the near future is encrypting ~/ by default. > And somehow because that's not good enough, in your view, you want to > shitcan encrypting ~/ at all, while waiting for a perfect solution? > How is that even remotely logical? This is quite dangerous to do without encryption of the whole disk. That would break a lot of user expectations if not properly communicated. If encrypting ~/ also entails full disk encryption that would be okay, but not separately. Not meeting user expectations when it comes to security *always* leads to bad things. Some examples: User expects no encryption, as they did not select anything regarding encryption or did not select full disk encryption: - Something breaks the system, they try to restore it and now they can't access their data anymore. User does expect encryption, but it's not labelled as encryption for ~/ only - and therefor only ~/ is encrypted: - User stores data somewhere else than in /home (e.g. sensitive internal programs in /opt or /usr/local, secrets/keys/vpn-keys/.. in /etc) -> on device loss that user might still think the data is safe anyway, as they think it is encrypted - Attacker scenario: there is physical access to the device for a few minutes - installing a trojan is super easy to be done in <10 minutes, without the need for any tool, writing the trojan on site. Having the full disk encrypted at least moves this to either about half an hour to one hour and having a live-usb-stick ready or to having a trojan ready anyways. So please be careful in case this feature gets introduced, as "less than expected security" is usually worse than "less security". Wording in the installer is super critical in regard to ~/ only encryption. All the best, David signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Fri, Dec 06, 2019 at 07:58:07PM -0700, John M. Harris Jr wrote: > Encrypting $HOME would certainly be "an incremental improvement", but it > shouldn't be done unless the user chooses to do it, and it probably shouldn't > be done using the same passphrase they use for their user account. That > should > be up to the user to decide, of course. If they want to use the same > passphrase, far be it from me to attempt to stop them. This could be quite dangerous - encrypting $HOME without encrypting the whole system could lead to a false sense of security - if this is to be enabled the user should be explicitely warned, that the system will be unencrypted, if os encryption is not enabled too. When encrypting both the os and $HOME this could be an improvement, as this would disallow forcing access to userdata on request (e.g. access by system administrator without informing users). Access without user consent would require preparation and system modification, which is a higher barrier. Encrypting $HOME only should as far as I can see be enough to comply with GDPR regulations, but this does only covers device loss, not more advanced attacks. All the best, David signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote: > FWIW this has happened at an association I help at -- they had VMs with > no root password set, and users created by puppet some of whom have > sudo. > They just expected no root password = no login possible, but it turns > out 'su' just gave out a root shell with no password entered... > > It's easy to fix once I realized that, but it had been that way for > quite a while until then; I'd definitely support removing nullok on the > default install. At least with Fedora 31 the root-Password is invalid by default, so I guess it has been set to an empty password explicitely. I'd classify this more as a bug in the puppet-scripts, as it sounds like it touched security relevant stuff on installation, without admins being aware of it. All the best, David signature.asc Description: PGP signature ___ 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: Will orphan packages with NEW F31FTBFS bugs tomorrow
Hi! On Wed, Nov 13, 2019 at 09:10:24PM +0100, Miro Hrončok wrote: > vdirsyncer I've requested this now: https://pagure.io/releng/issue/9011 ~astra signature.asc Description: PGP signature ___ 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: Will orphan packages with NEW F31FTBFS bugs tomorrow
On Fri, Nov 08, 2019 at 01:16:21PM +0100, Miro Hrončok wrote: > vdirsyncer I've contacted the maintainer via email, but if that does not work in time I'd like to take up the issue. > Remember to set the bugzilla to ASSIGNED when you actually work towards > fixing the build failure. Is this meant to be done by the maintainer only may I do that, if I intend to get the package to a fixed state? All the best, David (FAS: astra) signature.asc Description: PGP signature ___ 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: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?
On Mon, Oct 07, 2019 at 03:15:02PM +0100, Ankur Sinha wrote: > Out of curiosity, what workflow do existing package maintainers user > while packaging new software? Is it `fedpkg` based with a folder for the > spec to work in? (I still use rpmbuild + mock/koji-scratch builds). I'm only a packager since about 1.5 weeks or so, so I'm still in the process of getting used to fedpkg. Currently I use a mix of fedpkg and rpmbuild (which I probably will keep for now, as it's kinda convenient). On my system the dist-git lives in ~/rpmbuild/SOURCES.packagename, and SOURCES link to SOURCES.currentpackageiamworkingon. SPECS link to SOURCES. Although I have to re-symlink SOURCES everytime I work on a different package I can use all of rpmbuild, mock, fedpkg,… from the same source folder. Currently I'm only maintaining one package inside the fedora environment, but as I usually refuse to install anything to the system which is not tracked by the package manager I've got a few packages for cases when I need a custom patch or I need a newer version than available via dnf. For that symlinks works quite well. ~astra signature.asc Description: PGP signature ___ 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
Sponsorship request
Hi! I'm looking for a sponsor to get rss2email back into fedora (it's orphaned and retired right now, as it's been FTBFS too long) I've already got the package reviewed (bug 1740389), but forgot the FE-NEEDSPONSOR dependency, so I'm looking for a sponsor via this list. Technically this is also a self-introduction, as I've never introduced myself on this list. I've been part of the fedora security team since sometime in 2015 and am subscribed to this list since sometime in 2016, but it was never necessary for me to maintain packages myself, and I didn't really participate in the discussions. I'm currently student and teach network security as study assistant. Next to that I'm working as a system administrator in a research group running almost exclusively fedora as operating system. :) Thanks, Astra (David Kaufmann) signature.asc Description: PGP signature ___ 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 06:58:06AM -0700, John Harris wrote: > On Tuesday, August 27, 2019 4:37:24 AM MST David Kaufmann wrote: >> Both option have their disadvantages - in the case of "maintainer opens >> ports" the ports are open as soon as the package gets installed, and >> software not run/installed via package manager will give the impression >> of "just not working". > > Why in the world would somebody from the security team recommend opening a > port on the firewall as the software is installed, before it's even > configured? I'm not trying to recommend it, this is already done, e.g. for mdns, samba-client, or ssh. (To be fair that happens on os install, not necessarily on package install) I'm trying to list the problems with those options. >> Also a firewall is not that much protection as it looks like - imagine >> any port (above 1024) which was opened on the firewall (either by >> maintainer or user), but where no program is listening on. The >> additional barrier to run e.g. a c server on that machine would just >> be an additional portscan in before deploying the malware. > > Just running a firewall reduces the attack vector needed to deploy potential > malware to begin with. Very true. Unfortunately it is usually done to shield services which should not be there in the first place. Also stuff like rate-limiting or ip-header-checks are usually done by firewalls, hence my emphasis on making sure users don't start to disable the whole firewall because it is "easier". ~ David signature.asc Description: PGP signature ___ 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 08:54:57AM -0400, Dan Book wrote: > 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. Not knowing what IPs and ports are is not stupidity, it's just not knowing it. I've got electrical engineering students in a network security (!) university course which had difficulties distinguishing between IPs and ports. (It also included flow directions, but that is not too relevant, as usually the first information a user gets is just the port number, and we're always talking about a locally bound port) Users don't get to see stuff like this - usually they see hostnames without ports or ip-addresses connected with ports (like x.x.x.x:y syntax) Also making a service listen on the lo-interface only has the effect of creating confusion. Sometimes stuff like this leads to deactivation of the firewall, even though that can't help at all. ~ David signature.asc Description: PGP signature ___ 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 12:28:33AM -0600, Chris Murphy wrote: > Anyway, it would be nice to get the security team's input on this. As the security team currently does not have any meetings that I know of I'll try to answer this from my point of view. In my opinion this is a very difficult question, because it either puts a lot more load on the package maintainers (in case you go for "postinstall scripts open up required ports") or on the users (if you go for "user has to open up ports") Both option have their disadvantages - in the case of "maintainer opens ports" the ports are open as soon as the package gets installed, and software not run/installed via package manager will give the impression of "just not working". In case of "users open ports" there is the problem of "stuff doesn't work on fedora", if the particular user doesn't understand the concept of firewalls or doesn't know where to fix it. If the user does know about firewalls, the respective port usually still stays open, even if that software is being uninstalled. For both "non-packaged program needs an open port" and "user doesn't know a lot about firewalls" you'd need a mechanism to detect connection attempts and querying the user about it. Implementing such a mechanism requires switching to an application based firewall. Also a firewall is not that much protection as it looks like - imagine any port (above 1024) which was opened on the firewall (either by maintainer or user), but where no program is listening on. The additional barrier to run e.g. a c server on that machine would just be an additional portscan in before deploying the malware. As the issue of "users piping stuff through wget/curl to sh/bash" also was mentioned: In such a case any firewall won't help, as outbound connection usually are not filtered - also those tend to run on port 80/443 anyways, which usually is open even in heavily filtered networks. If there is a switch to "default reject" it is also very important that the process to open up a port is easier than to disable the firewall completely or injecting an "accept anything" rule. (e.g. by documenting how to open ports in the installation instructions) This does not solve the "port stays open if not used" problem, but at least it's one step. ~ David signature.asc Description: PGP signature ___ 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
