Re: When is pappl going to be good enough to replace cups?
On Mon, 2021-05-24 at 11:46 -0400, Solomon Peachy wrote: > On Mon, May 24, 2021 at 04:58:18PM +0200, Kevin Kofler via devel > wrote: > > Looks like you do not have a duplex printer. (Hint: Printing duplex > > is not > > always what you want. But never printing duplex makes even less > > sense. > > There's also short side duplex that makes sense in some cases for > > landscape > > printing.) > > Eh, duplexing is another basic document property, like paper size and > orientation. Granted, it's relatively likely to be overridden at > the time of printing... > > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, > and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint shines, > even > in comparison to official manufacturer drivers on $ProprietaryOS. > > (And incidently, I do have a duplexing printer, a decade-plus-old > Brother HL-5340D. Along with 31 others, though only 26 are plugged > in > at the moment. Isn't driver development/regression testing fun?) Wow! :D In any case, just let me say thanks for all your work so far, that's quite some determination! (Not to mention space, paper and power budget. :) ) > > - Solomon > ___ > 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 ___ 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: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Sat, 2021-05-15 at 17:53 +0200, Ralf Corsepius wrote: > On 5/14/21 2:50 PM, Martin Kolman wrote: > > On Thu, 2021-05-13 at 20:09 +0200, Peter Boy wrote: > > > > We discussed that in the Fedora Server Edition Working Group and > > > opted to leave it as is for the Server installation iso. A lot of > > > servers are running in a protected environment. And there are > > > situations when you need urgent access but do not sit at your > > > desktop > > > and don’t have the key available. So let the server admin decide > > > what > > > is best in a given installation context. In most cases it is the > > > current default (disallow password login) > > Do those server deployments not have any users accounts other than > > root > > ? Creating a non-root user account, possibly with admin rights (all > > possible from within Anaconda) would seem like a safer option for > > accasional/emergency password based access to such machines over > > SSH. > > I don't see, how this would any safer than directly using "root". As far as I understand the original change in upstream OpenSSH it's about only having to remotely guess a password to gain access to the root account. In comparison to remotely attack a user account you need to guess both the user name *and* password, making the potential search space quite a bit larger (provided the user name is reasonably unique). > > Ralf > ___ > 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 ___ 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: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On Thu, 2021-05-13 at 20:09 +0200, Peter Boy wrote: > > > > Am 12.05.2021 um 22:35 schrieb Ben Cotton : > > > > == Summary == > > Since 2019 the Anaconda installer GUI hosted an option called > > "Allow > > SSH root login with password", that made it possible to enable > > password based root logins over SSH on the installed system. ... > > And > > after two years of transition period it is now time to drop the > > option > > from the GUI. > > > > We discussed that in the Fedora Server Edition Working Group and > opted to leave it as is for the Server installation iso. A lot of > servers are running in a protected environment. And there are > situations when you need urgent access but do not sit at your desktop > and don’t have the key available. So let the server admin decide what > is best in a given installation context. In most cases it is the > current default (disallow password login) Do those server deployments not have any users accounts other than root ? Creating a non-root user account, possibly with admin rights (all possible from within Anaconda) would seem like a safer option for accasional/emergency password based access to such machines over SSH. > ___ > 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 ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
> On Thu, Apr 29, 2021 at 4:17 PM Martin Kolman I agree with this change, however it's the sort of thing that should > go through Fedora's Changes process: > https://docs.fedoraproject.org/en-US/program_management/changes_policy/ > > This gives it increased visibility within the Fedora contributor > community and with users. > > > Thanks, > BC Good point & we got quite a few reactions for both keeping and removing the option, so I'll create an official Fedora Change proposal. I guess this can be considered a self-contained change, not a system- wide one, right ? ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 14:14 +, Wolfgang Ulbrich wrote: > Yes, why not adding an option to anaconda to create a personal ssh > key? > Same like amazon cloud does. > Eg. when you create a el8 server in AWS, AWS gives you an option to > create a ssh key before you finish the setup of this machine. > With that key you can later login to the root account of your AWS > server machine. So if I understand it correctly: - it creates a key pair - makes the provisioned machine thrust the publick key part of the pair - you transfer the private key to your machine and use it to talk to that one machine only Sounds like an interesting idea, although in the non-cloud environment I think the best thing the installer could do is to create the key pair and ann the public key to trusted keys. User would then have to do the rest (transfer the private key in a safe manner to his machine). Yet again, patches welcome, as I'm afraid its unlikely we would get to implementing something like this any time soon. > ___ > 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 ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Fri, 2021-04-30 at 15:33 -0400, DJ Delorie wrote: > > I normally would complain about taking options away from users, but > as I > typically use ssh for root *anyway*, I felt this wasn't appropriate > (although I have a friend who never uses ssh keys, always > password-over-ssh). > > I would, however, ask that the config file have a commented out > option > that re-enables it, with a suitable text comment clearly saying > "uncomment this to allow root passwords over ssh". You are talking about the SSH daemon config file, right ? Sounds like a good ideam to me, independent on the end result of this Anaconda related discussion so I suggest opening a RFE bug on the SSH daemon with this suggestion or even outright sending patches for the default config file. :) > > Perhaps that comment might be a good place to mention ssh-copy-id ? > > Such comments make the "best practices" much more discoverable > without > frustrating users who just want to make things work. > ___ > 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 ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 08:32 +0200, Peter Boy wrote: > > > > Am 29.04.2021 um 22:09 schrieb Martin Kolman : > > > > Hi! > > At the moment the Anaconda installer used by Fedora contains an > > option > > called "Allow SSH root login with password" on the root password > > configuration screen. > > ... > > Note that the checkbox is not ticked by default, the user needs to > > make > > a conscious choice to allow this security problematic SSH login > > behavior. > > ... > > good time to finally drop the "Allow SSH root login with password" > > from > > the Anaconda GUI. > > I greatly appreciate Fedora's emphasis on establishing the most secure > system possible by default. It was one of my reasons to choose Fedora, > years ago. > > But what makes the Anaconda team think that the system administrator > could activate the option for no good reason, just for fun, > recklessness or the joy of 'adventure'? > > I don't mean to be unkind, but in my view you are about to patronize > the system administrator in a kind of missionary overzealousness. But > reading Fedora vision, Fedora is about Freedom, another good reason to > decide for it. Actually, it's the other way around - we believe in the administrator being a professional who can easily an on override via a kickstart if really needed, such as one described here: https://anaconda-installer.readthedocs.io/en/latest/common-bugs.html#enabling-root-password-ssh-login-via-password > > > If you are aware of some critical Fedora/Fedora spin usecase that > > depends on users regularly ticking this option, please let us know! > > No system administrator will 'regularly' ticking that option! That is > an unrealistic assumption. It is reserved for special exceptions > (that's why it is off by default). Others have already described such > cases. > > At the very least, I am in favor of leaving the option in the Server > Edition as it is. The option is currently not parametric in any way, but we do have per product/variant configuration files that encode differences from the Fedora baseline, such as the XFS based default partitioning for the Fedora Server variant: https://github.com/rhinstaller/anaconda/blob/master/data/product.d/fedora-server.conf#L14 So if consensus is reached for keeping the option available on Fedora Server variant only (ideally ACKEd by the Fedora Server SIG) it would be possible to show the option only in the Fedora Server installer variant, at the cost of some added code complexity. > > ___ > 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 ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 23:23 +, patra...@gmail.com wrote: > > On 4/30/21 10:23 AM, Richard W.M. Jones wrote: > > > > +1 > > > > in addition to, e.g., an _initial_ setup on a remote/headless box at > > a VPS. > > Ubuntu Server installer handles this in a very nice way by allowing to > import SSH keys from a GitHub account given a username, i.e. via an URL > like this: https://github.com/patrakov.keys . Maybe it's a good idea to > implement the same feature in Anaconda? Sounds like a good idea - we would certainly accept PRs[0] adding support for this to Anaconda in a robust manner. :) BTW, it seems to me that many developers also use GitLab and many Fedora projects use Pagure as well. Maybe it would make sense to support those as well, provided they have a suitable API available of course. [0] https://github.com/rhinstaller/anaconda > ___ > 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 ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Fri, 2021-04-30 at 15:23 +0100, Richard W.M. Jones wrote: > On Fri, Apr 30, 2021 at 03:37:54PM +0200, Vitaly Zaitsev via devel > wrote: > > On 30.04.2021 15:21, Richard W.M. Jones wrote: > > > Not everything is exposed to the internet. Please leave the > > > option, > > > disabled by default and with a suitable warning if you like. > > > > Why are you still using passwords in 2021? SSH keys are much more > > secure and easier to use. > > Because distributing SSH keys to temporary VMs is hard? Not > everything is a long-lived machine connected to the internet. What about creating an admin user instead ? It's effectively the same ammount of clicks - instead of setting a root password and checking the "Allow SSH root login with password" checkbox, create a regular user and check the "make this user an admin" checkbox. Regular users, including users with admin (sudo/wheel) privileges, can of course still login with password via SSH just fine. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: > http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > 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 ___ 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
Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
Hi! At the moment the Anaconda installer used by Fedora contains an option called "Allow SSH root login with password" on the root password configuration screen. This is how it looks like at the moment, on latest Fedora Rawhide installer image: https://m4rtink.fedorapeople.org/screenshots/fedora/rawhide_f35/root_password_screen.png For some backstory - in 2015 the OpenSSH upstream decided to disable password based root logins by default. This was done for security reasons as an attacker needs to only guess password to gain access to the root account. For a user account the attacker needs to guess both the username and password and the user account not even have admin privileges, making the remote password guessing attack both harder and less useful. The Fedora OpenSSH package carried downstream patches to revert this upstream change up until summer 2019 when it was decided to restore the upstream behavior and drop the downstream patches as enough tools that required password based SSH login have been migrated to use either key authentication or user based login methods. Now back to the "Allow SSH root login with password" checkbox in the installer GUI. :) The option was added in 2019 when Fedora disabled password based root SSH login by default, as a temporary migration aid for users of the graphical installer. Note that the checkbox is not ticked by default, the user needs to make a conscious choice to allow this security problematic SSH login behavior. Now fast forward to today, it's 2021, any use cases that needed password based root login via SSH had 2 more years to migrate while the amount of password guessing attacks certainly didn't get any lower. For that reason we in the Anaconda development team feel like it's a good time to finally drop the "Allow SSH root login with password" from the Anaconda GUI. If you are aware of some critical Fedora/Fedora spin usecase that depends on users regularly ticking this option, please let us know! If no such critical usecase is found, we will proceed with removing the option from the Anaconda GUI in a ~week from now in Rawhide. Best Wishes Martin Kolman & the Anaconda team ___ 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: Display a message on the console while upgrading a package
On Tue, 2021-03-30 at 19:35 +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 30, 2021 at 06:54:25PM +, Gary Buhrmaster wrote: > > On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > There is no good way to do this. > > > > This is one of those cases where I occasionally > > miss a mainframe fix update feature to prevent > > certain bad automated results. > > > > In SMP/E, there was the concept of HOLD's for > > a fix. There were a number of HOLD reasons, > > but one was ACTION, which prevented the > > application of the fix unless the HOLD was > > released. I.e. you had to read the docs and > > either do, or prepare to do, whatever the > > ACTION said to do before you could proceed > > FWIW, with Debian's apt, that's more or less what you get: the > upgrade > will block and ask questions. I remember quite a few times I got burned by this behavior on Debian based systems - nothing better than to start a big system update and go away only to come back hours later and find it stuck at the ~10th package asking some useless question and not progressing with the update at all. Also given that package update transactions are not always atomic and can easily result in a broken system if interrupted in the middle, this also makes breakage more likely as the transaction remains in vulnerable state much longer than it would be otherwise necessary, waiting for the user to notice and answer the question. > We have never done this in the rpm world, > and while sometimes this makes things harder, I think this is the > right > choice in the long run. Essentially, interactive questions during > upgrades > are are fine as long as you have one or two or three servers per > human, > *and* the human has time and knowledge and energy to deal with the > questions. > But the world has changed, and we have many more machines per person, > and > many more non-power users then ever. > > Zbyszek > ___ > 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 ___ 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 35 Change: rpmautospec - removing release and changelog fields from spec files (System-Wide Change proposal)
On Mon, 2021-02-15 at 11:50 +0100, Vít Ondruch wrote: > Dne 14. 02. 21 v 19:45 Kevin Fenzi napsal(a): > > So, I am a bit leary of this change for the same reason that I was for > > the last few changes like this. Namely, we are building out own layer on > > top of rpm to make our lives easier, when we probibly should try and > > just improve rpm to do this for everyone. > > > > I realize that rpm is slow to move and this might not be practical, but > > I sure wish we would try. > > > > As a strawman, what about this that upstream might take: > > > > * keep the same macros you propose (don't care what colour the bikeshed > > is) > > * src.rpms grow a (optional) releases (or whatever) dir. > > * under this (optional) dir we have a subdir for each version. > > * under that (optional) dir we have a subdir for each release. > > * under that (optional) dir we have files for changelogs. > > > Just FTR, when I was proposing some macros to include Changelog into RPM, I > was told that one of benefits of RPM and > spec file is that it is all together in one file: > > https://github.com/rpm-software-management/rpm/issues/393#issuecomment-365181602 I rather agree with that - I did some Debian packaging in the past and the bunch of random folder trees containing almost random files that stands in for the spec file in Deb packages was pretty scary for me as a packaging beginner. Having everything in a single file really helps to see what a package is about without having to dig through a million files, not to mention makes comparing package revision easy. I guess having changelog in one separate file is still bearable in this context, but would I hope it does not start a splitting trend where other parts of the spec file get randomly split out as well. > > If you look at the problem from this angle, then I can't see how this would > be acceptable to RPM upstream :/ > > > > Vít > > > > > So, the last few ansible builds would have: > > > > ansible-2.9.17-1.fc34: > > > > ansible/releases/2.9.17/1/update-to-2.9.17 > > ansible/releases/2.9.16/2/conflict-with-ansible-base > > ansible/releases/2.9.16/2/Adjust-collections-generator > > ansible/releases/2.9.16/1/update-to-2.9.16 > > ... > > > > When building, rpm would sort the releases dir, then the version subdir, > > then concat the changelog fragments into a changelog. This way > > everything is in the src.rpm. > > > > When doing a PR, you would make a new version subdir and > > put a changelog fragment in it and commit it with any of > > your other changes. > > > > Probibly some problems with that, but I thought I would throw it out > > there from my sleep deprived mind. :) > > > > Anyhow, I just am a bit leary of us building up more and more around > > rpm, and not just fixing rpm. > > > > kevin > > > > > > ___ > > 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 > > ___ > 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 ___ 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: Rawhide Repo needs downgradeable packages
On Fri, 2020-12-04 at 16:11 +0100, Marius Schwarz wrote: > > > Hi, > > > > as you may have heared, Fedora is now running on Pinephone and other > devices, that need bleeding edge versions to function. Are bleeding edge of all packages needed ? If not I wonder if just budiling what needs to be bleeding edge in a COPR overlay on top of a stable release would work. This would give you a stable base to work on and a lot of control over what goes on top of it, including downgrading packages and applying custom not-yet-upstream patches. You could of course at the same time make sure all the bits and pieces land in Rawhide, so that when you switch your COPR overlay baseline to the next Fedora stable release, less custom package versions are needed. Rinse and repeat until no overlay packages are needed. :) > > > Status of Fedora Pine as of 15:15 CET > > > > Cams now working, but app needs rework > > Mobile INET working > > WIFI working > > Touch working > > SMS working > > GPS working > > Calls partly, "calls app" does not connect to pulseaudio. > > Headphones ( sort of ) > > Mali400 GPU support working ( MPV rulez ) > > > > and with Gnome(38) instead of Phosh.. no window problems! Big > Thanks to nikhiljha and his copr repo. Nice, very good progress! :) I really need to try the latest Fedora image on my Pinephone when I have some time. :) > > > O== my request > > > > In the last 3 days alone several updates ( i.e. bind-libs, > gnome-shell 40~alpha ) caused a lot of bugs and needed to be > downgraded directly from koji, > > by first finding & downloading them with wget ( because of the > slow wifi and dependency checks, direct http links work ofcourse ), > and later downgraded with > > dnf, which is so to speak, a pain in the ass. Of course, the best > way to handle it would be, if the os compenents came from stable > repos, so that these problems do not happen. But as i said, bleeding > edge is needed atm. > > > > Is it possible to keep at least the last version of a package around > in rawhide repo, to make dnf downgrade work? That would ease a lot > of this pain. > > > > I know that there is a native koji tool to handle rawhide, but i > must say, that won't work in most cases. Let me explain: > > > > Pine has announced to open stores in the US and Canada, because of > the huge amount of requests for a pinephone. As it looks, this > phone, as cheap as it compontants are, fills a gap of some kind. > Therefor we will have much more user using it, and (i hope i can > help with it) will use Fedora with Gnome-Shell. > > Phosh is more like Android, it has it charm, but tbh I, and people I > showned it to, love they way gnome-shell handles stuff. > > > > We "may" get them to downgrade stuff with dnf, but that needs to be > as simple as it could. > > > > best regards, > > Marius Schwarz > > > > > > > > ___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: Rawhide Repo needs downgradeable packages
On Mon, 2020-12-07 at 17:45 +0100, Fabio Valentini wrote: > On Fri, Dec 4, 2020 at 4:12 PM Marius Schwarz wrote: > > > > Hi, > > > > as you may have heared, Fedora is now running on Pinephone and other > > devices, that need bleeding edge versions to > > function. > > > > Status of Fedora Pine as of 15:15 CET > > > > Cams now working, but app needs rework > > Mobile INET working > > WIFI working > > Touch working > > SMS working > > GPS working > > Calls partly, "calls app" does not connect to pulseaudio. > > Headphones ( sort of ) > > Mali400 GPU support working ( MPV rulez ) > > > > and with Gnome(38) instead of Phosh.. no window problems! Big Thanks to > > nikhiljha and his copr repo. > > > > O== my request > > > > In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell > > 40~alpha ) caused a lot of bugs and needed to > > be downgraded directly from koji, > > by first finding & downloading them with wget ( because of the slow wifi > > and dependency checks, direct http links > > work ofcourse ), and later downgraded with > > dnf, which is so to speak, a pain in the ass. Of course, the best way to > > handle it would be, if the os compenents > > came from stable repos, so that these problems do not happen. But as i > > said, bleeding edge is needed atm. > > > > Is it possible to keep at least the last version of a package around in > > rawhide repo, to make dnf downgrade work? > > That would ease a lot of this pain. > > > > I know that there is a native koji tool to handle rawhide, but i must say, > > that won't work in most cases. Let me > > explain: > > > > Pine has announced to open stores in the US and Canada, because of the huge > > amount of requests for a pinephone. As > > it looks, this phone, as cheap as it compontants are, fills a gap of some > > kind. Therefor we will have much more user > > using it, and (i hope i can help with it) will use Fedora with Gnome-Shell. > > Phosh is more like Android, it has it charm, but tbh I, and people I > > showned it to, love they way gnome-shell > > handles stuff. > > > > We "may" get them to downgrade stuff with dnf, but that needs to be as > > simple as it could. > > I'm wondering, wouldn't this scenario be a prime application of an > OSTree based system like Silverblue? > It would give you exactly what you want, being able to revert to the > previous (working) version if the new one breaks something. Even > Android does something like this nowadays. Yeah, it really seems to me that OSTree managed system with apps in Flatpaks on top could work very well on an Linux mobile device. It could actually be much better than what's used in Android at the moment as I'm not sure they really do diff updates or how very well & you usually replace one system image by another one. So there is no way easy way to revert the update & the device might need a reflash if the update process is interrupted while the new system image is being created (due to a crash or running out of battery). With OSTree one could easily have multiple update states available (sable, cutting edge, last 3 updates, etc.) and as the new OSTree is created "in the background" without destroiong the current one/s it would be really hard to get the device into such a bad state with OSTree to need a reflash. > > Fabio > ___ > 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: list major languages first in anaconda
On Thu, 2020-10-22 at 08:41 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Oct 22, 2020 at 06:28:38AM -, Sundeep Anand wrote: > > Hi, > > > > To help users choose their native language anaconda tries to evaluate > > priority languages based on geolocation and > > place them first in the list. Proposal[1] is to broad this scope by > > appending major/common speaking languages as > > well. This may cater to the use case where a major/common language speaker > > relocated to a different territory. > > Determining the list of major/common language is tricky, however, as a > > starting point we may look at gnome-control- > > center[2]. > > I strongly support this. The 10 or so most popular languages cover > maybe 60% of the world population, so this optimizes language selection > a large fraction of our users, without really making anything worse for > other users, who just have to go through the search list as before. > > As to the list of languages: I think we should go by the total number > of speakers of a given language, though taking into account popularity of > Fedora > and OSS in a given group too. (For example, French is only spoken by 77 mln as > the first language according to Wikipedia, but we have many French > contributors > and users, proportionally more than the 1% of world population that that 77 > mln is. > So I think it is important to include French in this list, even though > it's not that popular in the world.) > > Also, I think we should go by the *total* number of speakers, not just the > speakers > for whom the language is the *first* language. My thinking (and I would love > to hear from people who are in this situation) is that many parts of the world > people know multiple languages and are likely to select the interface in > a second language, if that second language for example is of European origin > and uses the Latin alphabet or is otherwise better supported by the software. > > I think we should not put regional dialects (**) of a language on the list, > and always stick to the most popular dialect. A speaker of a given regional > variant might *prefer* it, but they will not have any trouble understanding > the most popular variant. This saves us a spot, which we can fill in with > another language that is significantly different than those already on the > list. > This increases the chance that someone who is using Fedora will see at least > one language (and alphabet) which they know enough to operate the installer > interface. (So for example, en_AU, en_GB, en_HK, even though they are somewhat > popular, would not be included since en_US is.) > > Finally, a caveat that if our localization in a given language is very > bad, we should not advertise it, even if otherwise we'd want to include it. > We should instead set a medium-term goal to improve > fonts/translations/localization > in that language first. > > Going by > https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers > we have: > 1 English 1268 mln <-- on the list already, twice > 2 Mandarin1120 <-- on the list already > 3 Hindi637.3 > 4 Spanish 537.9 <-- on the list already > 5 French 276.6 <-- on the list already > 6 Standard Ar 274.0 <-- on the list already (*) > 7 Bengali 265.2 > 8 Russian 258.0 <-- on the list already > 9 Portuguese 252.2 > 10 Indonesian 199.0 > 11 Urdu 170.6 > 12 German 131.6 <-- on the list already > 13 Japanese 126.4 <-- on the list already > > (*) ar_EG is on the list. Is it close enough to other Arabic languages? > > My conclusion would be to drop en_GB, add one Hindi, Bengali, > Portuguese, Indonesian and Urdu variant each (with the caveat about > sufficient supported described above). This covers another 1.5trn people > and gives us significantly better coverage in Asia and South America. > > Japanese is important because it's a significantly distinct language > with special fonts and conventions, and I think many speakers would > not be comfortable in anything else. OTOH, German is meh, because in > my experience all Germans understand English well enough to use it in > the UI. If we had to drop one more language, I'd drop German. Just a note about about possible implementation of such suggested improvements, Anaconda does not contain the language/timezone/keyboard listings and mappings, it uses the langtable library, which provides this data over its API: https://github.com/mike-fabian/langtable So if more improvements are desired (both in data & code) they should be integrated into langtable, Anaconda (and other users of langtable) will then just pick it up automatically. In the past long gone Anaconda used to host and process the language/timezone/kybaord mappings and it was not just hard to maintain but also not accessible for other project interested in using the same data. For that reason the langtable project was created and
Re: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
On Thu, 2020-10-22 at 14:57 +0100, Peter Robinson wrote: > On Thu, Oct 22, 2020 at 1:47 PM Martin Kolman wrote: > > On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/CompressKernelFirmware > > > > > > == Summary == > > > Compress Kernel Firmwares to reduce on disk size > > > > > > == Owner == > > > * Name: [[User:pbrobinson| Peter Robinson]] > > > * Email: [mailto:pbrobin...@fedoraproject.org| > > > pbrobin...@fedoraproject.org] > > > > > > == Detailed Description == > > > > > > Since the linux 5.3 kernel there has been support for loading firmware > > > from xz compressed firmware. The upstream linux-firmware respository > > > is now over 900Mb, not including other kernel firmware that are in > > > Fedora but come from other sources. By compessing the firmware with > > > "xz -C crc32", the only option currently supported in the kernel, we > > > can reduce the ondisk size of the firmware by almost half. > > I wonder if this can also help make the boot isos and installation images > > smaller ? I'm sure they haver some > > firmware on > > them. Or alternatively we could reduce the potentially quite meintenance > > intensive firmware culling we do at the > > moment. > > I wouldn't expect it to have too much of an image on the size of rpms > in the installer as the rpms are already compressed, this is more > about on disk install size. Hmm, right - the installation environment squashfs is already compressed so indeed, no gains likely expected. > > > > == Benefit to Fedora == > > > > > > Reduced on disk size of the firmware used by the kernel. > > > > > > == Scope == > > > * Proposal owners: > > > ** Add support upstream to the linux-firmware copy-firmware script to > > > compess the firmware and create the symlinks to the compressed > > > firmware > > > ** Enable the upstream support in the Fedora linux-firmware package to > > > compress the firmware at build time > > > ** Enable compressing firmware in packages that contain firmware used > > > by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware > > > ** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete) > > > * Other developers: > > > ** No impact > > > * Policies and guidelines: N/A (not a System Wide Change) > > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > > > > > There should be no upgrade impact, the support was added to the > > > generic firmware loader interface in the kernel. > > > > > > == How To Test == > > > > > > Check devices that need firmware still work. Some devices that need > > > firmware include: > > > * GPU drivers such as nvidia, AMD and i915 > > > * Wireless drivers such as those from Intel, Broadcom/Cyprus, TI, > > > Qualcomm and Marvel > > > * Wired network interfaces > > > * Storage drivers > > > * USB controllers and drivers > > > > > > == User Experience == > > > > > > Generally users should notice little to no difference. > > > > > > == Dependencies == > > > N/A (not a System Wide Change) > > > > > > == Contingency Plan == > > > > > > * Contingency mechanism: Don't compress kernel firmware > > > * Contingency deadline: GA > > > * Blocks release? No. > > > * Blocks product? No. > > > > > > == Documentation == > > > N/A (not a System Wide Change) > > > > > > == Release Notes == > > > N/A > > > > > > > > > -- > > > Ben Cotton > > > He / Him / His > > > Senior Program Manager, Fedora & CentOS Stream > > > Red Hat > > > TZ=America/Indiana/Indianapolis > > > ___ > > > 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
Re: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)
On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/CompressKernelFirmware > > == Summary == > Compress Kernel Firmwares to reduce on disk size > > == Owner == > * Name: [[User:pbrobinson| Peter Robinson]] > * Email: [mailto:pbrobin...@fedoraproject.org| pbrobin...@fedoraproject.org] > > == Detailed Description == > > Since the linux 5.3 kernel there has been support for loading firmware > from xz compressed firmware. The upstream linux-firmware respository > is now over 900Mb, not including other kernel firmware that are in > Fedora but come from other sources. By compessing the firmware with > "xz -C crc32", the only option currently supported in the kernel, we > can reduce the ondisk size of the firmware by almost half. I wonder if this can also help make the boot isos and installation images smaller ? I'm sure they haver some firmware on them. Or alternatively we could reduce the potentially quite meintenance intensive firmware culling we do at the moment. > > == Benefit to Fedora == > > Reduced on disk size of the firmware used by the kernel. > > == Scope == > * Proposal owners: > ** Add support upstream to the linux-firmware copy-firmware script to > compess the firmware and create the symlinks to the compressed > firmware > ** Enable the upstream support in the Fedora linux-firmware package to > compress the firmware at build time > ** Enable compressing firmware in packages that contain firmware used > by the kernel: eg alsa-sof-firmware, atmel-firmware, zd1211-firmware > ** Enable the CONFIG_FW_LOADER_COMPRESS kernel option (long complete) > * Other developers: > ** No impact > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > There should be no upgrade impact, the support was added to the > generic firmware loader interface in the kernel. > > == How To Test == > > Check devices that need firmware still work. Some devices that need > firmware include: > * GPU drivers such as nvidia, AMD and i915 > * Wireless drivers such as those from Intel, Broadcom/Cyprus, TI, > Qualcomm and Marvel > * Wired network interfaces > * Storage drivers > * USB controllers and drivers > > == User Experience == > > Generally users should notice little to no difference. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: Don't compress kernel firmware > * Contingency deadline: GA > * Blocks release? No. > * Blocks product? No. > > == Documentation == > N/A (not a System Wide Change) > > == Release Notes == > N/A > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 net install iso the possibilitie to add espeakup for people like me whome are blind?
On Thu, 2020-10-08 at 12:05 -0500, Michael Catanzaro wrote: > On Thu, Oct 8, 2020 at 12:43 pm, Robbie Harwood > wrote: > > That's unfortunate, and will hurt adoption with users who need it. > > Are > > there things that could be done to make it easier to add? > > Currently anaconda is not accessible even in the default live > Workstation install that runs under gnome-shell and where everything > else is accessible. I don't know why, but orca just doesn't read > anything from anaconda, whereas it does for everything else. IIRC the latest findings point to Anaconda GUI running as root likely being teh case. Other GUI apps running as root (gparted) apparently behave the same. CCing Vladimir Slavik who has been looking into this recently. > Since that > is what the vast majority of our users will be using to install, I > would say that's where the greatest benefit lies. Of course netinstall > is important too, but realistically it's not very easy to find those > images compared with the heavily-promoted live image. > > ___ > 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: Release criteria proposal: first boot experience
On Tue, 2020-09-01 at 19:15 -0700, John M. Harris Jr wrote: > On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote: > > Hi, > > > > We currently have a bug where the Online Accounts page in initial setup > > is nonfunctional. [1] This doesn't violate any current release > > criterion, but surely we don't want to release with a broken initial > > setup experience. So let's add a new requirement for that. How about > > something like: > > > > "If an initial setup utility is run or intended to be run after the > > first boot of the installed system, then it must start successfully and > > each page or panel of the initial setup utility should withstand a > > basic functionality test." > > > > OK that's pretty basic, but it gets the point across. I think this can > > be a final requirement, not necessarily important enough to be a beta > > requirement. Bikeshed away! > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476 > > I would like to report a bug with the first boot experience: > > Upon installing a new GNOME system, I'm accosted with a dialog asking me > questions about the system I just finished configuring in Anaconda. Is there > something in Anaconda I'm missing to disable this behavior, or do I have to > write my own kickstart to fix that? You can use the "fistboot --disable" command if you are installing via kickstart: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#firstboot That should disable all post installation setup tools (Initial Setup, Gnome Initial Setup). > > -- > John M. Harris, Jr. > > ___ > 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: Deprecation of Anaconda boot parameters without inst. prefix
On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote: > On Thu, 13 Aug 2020 at 08:58, Fabio Valentini wrote: > > On Thu, Aug 13, 2020 at 2:16 PM wrote: > > > Hello everyone, > > > > > > Anaconda team has decided to deprecate use of Anaconda kernel boot > > > parameters without 'inst.' prefix. As you may already know you can > > > specify Anaconda kernel boot parameters both with and without 'inst.' > > > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when > > > you use Anaconda option without the 'inst.' prefix you will now get a > > > warning. We are *not* disabling parameters without a prefix yet. > > > > > > The reason for this is keep running into parameter conflicts with other > > > projects. As an example there is 'debug' parameter for both kernel and > > > us, so when you want to enable kernel debugging in installation > > > environment you will also enable Anaconda debug mode. > > > > > > Because of this I have created the following pull request for Anaconda: > > > > > > https://github.com/rhinstaller/anaconda/pull/2786 > > > > > > > > > In case you have any objections please start discussion either on the > > > pull request or here. > > > > > > > > > Best regards, > > > Jirka > > > > This may be a stupid question, but why are parameter namespaced with > > "inst." and not with "anaconda."? Is this a historical artifact? > > "inst" is a pretty generic term as well, and "anaconda" would > > definitely not lead to parameter overloading on the kernel cmdline. > > > > I think inst was meant to be universal so that debian etc could use > it. However I will say if I have to type 20 anaconda.= on > a serial terminal like I have to for the inst.= I will > quickly be looking for any other installer to use. I regularly end up > with enough redraw problems because the line went over whatever SOL or > the HTML-console thinks a line should be and clearing the entire line > so I can't see what I am typing. IIRC there are some platforms (PPC ? s390?) that have pretty low limit on the length of the string representing boot options, so not just typing - your options might not physically fit in if the prefix was too long. :) > > -- > Stephen J Smoogen. > ___ > 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
- Original Message -
> From: "Josef Bacik"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 9, 2020 9:11:07 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
> file system for desktop variants
>
> On 7/9/20 1:51 PM, Eric Sandeen wrote:
> > On 7/6/20 12:07 AM, Chris Murphy wrote:
> >> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
> >> wrote:
> >>>
> >>> On 7/3/20 1:41 PM, Chris Murphy wrote:
> SSDs can fail in weird ways. Some spew garbage as they're
> failing, some go read-only. I've seen both. I don't have stats on
> how common it is for an SSD to go read-only as it fails, but once
> it happens you cannot fsck it. It won't accept writes. If it
> won't mount, your only chance to recover data is some kind of
> offline scrape tool. And Btrfs does have a very very good scrape
> tool, in terms of its success rate - UX is scary. But that can
> and will improve.
> >>>
> >>> Ok, you and Josef have both recommended the btrfs restore
> >>> ("scrape") tool as a next recovery step after fsck fails, and I
> >>> figured we should check that out, to see if that alleviates the
> >>> concerns about recoverability of user data in the face of
> >>> corruption.
> >>>
> >>> I also realized that mkfs of an image isn't representative of an
> >>> SSD system typical of Fedora laptops, so I added "-m single" to
> >>> mkfs, because this will be the mkfs.btrfs default on SSDs (right?).
> >>> Based on Josef's description of fsck's algorithm of throwing away
> >>> any block with a bad CRC this seemed worth testing.
> >>>
> >>> I also turned fuzzing /down/ to hitting 2048 bytes out of the 1G
> >>> image, or a bit less than 1% of the filesystem blocks, at random.
> >>> This is 1/4 the fuzzing rate from the original test.
> >>>
> >>> So: -m single, fuzz 2048 bytes of 1G image, run btrfsck --repair,
> >>> mount, mount w/ recovery, and then restore ("scrape") if all that
> >>> fails, see what we get.
> >>
> >> What's the probability of this kind of corruption occurring in the
> >> real world? If the probability is so low it can't practically be
> >> computed, how do we assess the risk? And if we can't assess risk,
> >> what's the basis of concern?
> >
> > From 20 years of filesystem development experience, I know that people
> > run filesystem repair tools. It's just a fact. For a wide variety of
> > reasons - from bugs, to hardware errors, to admin errors, you name it,
> > filesystems experience corruption and inconsistencies. At that point
> > the administrator needs a path forward.
> >
> > "people won't need to repair btrfs" is, IMHO, the position that needs
> > to be supported, not "filesystem repair tools should be robust."
> >
> >>> I ran 50 loops, and got:
> >>>
> >>> 46 btrfsck failures 20 mount failures
> >>>
> >>> So it ran btrfs restore 20 times; of those, 11 runs lost all or
> >>> substantially all of the files; 17 runs lost at least 1/3 of the
> >>> files.
> >>
> >> Josef states reliability of ext4, xfs, and Btrfs are in the same
> >> ballpark. He also reports one case in 10 years in which he failed to
> >> recover anything. How do you square that with 11 complete failures,
> >> trivially produced? Is there even a reason to suspect there's
> >> residual risk?
> >
> > Extrapolating from Facebook's usecases to the fedora desktop should be
> > approached with caution, IMHO.
> >
> > I've provided evidence that if/when damage happens for whatever reason,
> > btrfs is unable to recover in place far more often than other filesytems.
> >
> >> When metadata is single profile, Btrfs is basically an early warning
> >> system.> The available research on uncorrectable errors, errors that drive
> >> ECC
> >> does not catch, suggests that users are decently likely to experience
> >> at least one block of corruption in the life of the drive. And that
> >> it tends to get worse up until drive failure. But there is much less
> >> chance to detect this, if the file system isn't also checksumming the
> >> vastly larger payload on a drive: the data.
> >
> > One of the problems in this whole discussion is the assumption that
> > filesystem
> > inconsistencies only arise from disk bitflips etc; that's just not the
> > case.
> >
> > Look, I'm just providing evidence of what I've found when re-evaluating the
> > btrfs administration/repair tools. I've found them to be quite weak.
> >
> > From what I've gathered from these responses, btrfs is unique in that it
> > is
> > /expected/ that if anything goes wrong, the administrator should be
> > prepared
> > to scrape out remaining data, re-mkfs, and start over. If that's
> > acceptable
> > for the Fedora desktop, that's fine, but I consider it a risk that should
> > not
> > be ignored when evaluating this proposal.
> >
>
> Agreed, it's the very first thing I said when I was asked what are the
> downsides. There's clearly more work to be done in the recovery arena. How
> often do disks fail for
Re: Many packages unnecessarily link to libpython
- Original Message - > From: "Charalampos Stratakis" > To: "Development discussions related to Fedora" > > Sent: Friday, May 15, 2020 8:12:00 PM > Subject: Many packages unnecessarily link to libpython > > pyotherside m4rtink I can report this is expected and correct. PyOtherSide provides QML <-> Python bindings by embedding a Python interpreter in a QML Plugin, so that QML code can run Python code as needed. ___ 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: Why we package Rust crates
- Original Message - > From: "Kushal Das" > To: devel@lists.fedoraproject.org > Sent: Friday, May 15, 2020 10:08:34 AM > Subject: Re: Why we package Rust crates > > On 5/15/20 1:05 AM, Igor Raits wrote: > > Hello, > > > > This email attempts to answer some frequently asked questions about > > Rust SIG packaging of crates. For those who don't know what a "crate" > > is: it is the name for a collection of functionality in Rust, similar > > to libraries (C/C++), modules (Python/Perl/PHP), gems (Ruby), etc. > > > Thank you all for the hard work. It is amazing to see so many nice tools > available in Fedora. Thanks a lot as well! :) It really seems the best that can be done with what Rust makes possible at the moment. And IMHO it is really a shame Rust still does not have a stable ABI/propert dynamic linking support. That would indeed make things so much easier, more efficient and more secure... > > Kushal > -- > Public Interest Technologist, Freedom of the Press Foundation > CPython Core Developer > Director, Python Software Foundation > https://kushaldas.in > ___ > 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: Orphaned packages looking for new maintainers (anaconda also affected)
- Original Message - > From: "Kevin Fenzi" > To: "Development discussions related to Fedora" > > Sent: Wednesday, April 29, 2020 12:26:46 AM > Subject: Re: Orphaned packages looking for new maintainers (anaconda also > affected) > > On Tue, Apr 28, 2020 at 11:30:46PM +0200, Dominik 'Rathann' Mierzejewski > wrote: > > On Tuesday, 28 April 2020 at 22:15, Kevin Fenzi wrote: > > [...] > > > I'm a bit more concerned with keybinder3. That's needed by blueberry > > > which we use in the Xfce spin. > > > > I care about blueberry as well, even though I use MATE. > > > > > Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership > > > too? > > > > > > I guess I can take it if no one else wants to... > > > > ... but I really wouldn't like to take on another package, I have too > > much on my plate maintaining what I have already. > > ok. I went ahead and took it. Thanks a lot! :) > > Co-maintainers welcome You can add me as a co-maintainer. (If there is a way to add myself in the distgit UI I have not found it. :P) > > kevin > > ___ > 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: App updates for the new AAA solution
- Original Message - > From: "Ty Young" > To: devel@lists.fedoraproject.org > Sent: Thursday, April 23, 2020 8:54:29 PM > Subject: Re: App updates for the new AAA solution > > > On 4/23/20 12:00 PM, Richard W.M. Jones wrote: > > On Thu, Apr 23, 2020 at 05:22:01PM +0100, Stephen Coady wrote: > >> Hi, > >> > >> Development work has begun on the API which will give applications access > >> to the new AAA solution. As part of our effort to migrate to this new AAA > >> solution we need to identify applications which consume the old FAS API in > >> some way. > > "AAA"? > > > > I find it good to go with the Economist (a newspaper) style guide > > which invites writers to define every term before use. > > > Seems to be the same "AAA" as what you'd find in the video gaming space: > something that is high budget and/or high quality. I'm sure is is somehow related to the AAAuto used car dealership. ;-) > > > Hopefully it also doesn't have any surprise mechanics! > > > > > > Rich. > > > ___ > 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: How to enable package gating
- Original Message - > From: "Miro Hrončok" > To: "Development discussions related to Fedora" > , "Lukas Holecek" > > Sent: Friday, April 3, 2020 3:25:16 PM > Subject: Re: How to enable package gating > > On 03. 04. 20 14:49, Lukas Holecek wrote: > > Hi Vojtěch, > > > > The issue is that the file suffix should be `.yaml`, not `.yml`. > > > > Damn that YAML suffix. It's a hard-to-find issue that happened before. > > Maybe > > Greenwave should fallback to get `gating.yml` (it would require an > > additional > > request to git repo thought). > Also note that I find it extremely confusing that we are using tests.yml and > gating.yaml (different suffix) in the same repos to have CI based gating. Yeah, this really should be unified - or possibly at this stage made interchangeable (eq. supporting both yaml/yml in both places) to reduce the number of instances where people shoot their own foot like this. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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: CPE Git Forge Decision
- Original Message - > From: "Michal Konecny" > To: devel@lists.fedoraproject.org > Sent: Friday, April 3, 2020 10:06:26 AM > Subject: Re: CPE Git Forge Decision > > > > On 02/04/2020 23:51, Björn Persson wrote: > > > > Paul Frields wrote: > > > > That statement rings hollow for me, when Github is arguably the single > biggest vendor of open source in the world, no part of itself is open > source, and thanks to its pervasiveness, open source has won the war > of how development should work. > Github shows that *proprietary centralized services* are winning the war > of how development should work. Gitlab is a smaller, competing, > proprietary centralized service. > > This trend is not in any way unique to software development. Pretty much > everything is being consolidated into centralized services governed by a > small number of corporate behemoths. Every new thing is launched as a > proprietary service that captures the market before anyone has a chance > to develop a decentralized competitor. Even those decentralized networks > that have existed since the Internet was young are now degenerating into > centralized services. The smaller players will continue to be bought by > bigger competitors until there are only one or two services in the world > for doing whatever you want to do. > There is plenty of decentralized open source solutions for plenty of services > [0]. Unfortunately not for git forge. Actually, I would say Pagure by having all project metadata in git as well (not just code but also issues, pull request review, etc.) it is the most decentralised forge at the moment as in, you can just pick up your project and put it to another Pagure instance without complicated data exporting and importing, which is more complicated by other forges generally holding project metadata in a centralized database. > > Michal > > [0] - https://fediverse.party/ > > > > I speak only for myself but it seems to me that concern over this > ongoing centralization is why people are objecting to moving to Github > or Gitlab. > > Björn Persson > > ___ > 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 > > -- > Role: Fedora CPE Team - Software Engineer > IRC: mkonecny > FAS: zlopez > > ___ > 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: The Git forge decision (was CPE Weekly: 2020-03-28)
- Original Message - > From: "Alex Scheel" > To: "Development discussions related to Fedora" > > Cc: "Leigh Griffin" > Sent: Monday, March 30, 2020 8:42:33 PM > Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28) > > - Original Message - > > From: "Bruno Wolff III" > > To: "Leigh Griffin" > > Cc: "Development discussions related to Fedora" > > > > Sent: Monday, March 30, 2020 2:08:21 PM > > Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28) > > > > On Mon, Mar 30, 2020 at 17:20:04 +0100, > > Leigh Griffin wrote: > > >On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann wrote: > > > > > >We are trying to reduce the total ownership of the team to allow us to > > >provide value on initiatives that are requested of us by our stakeholders. > > > > Pagure has value beyond Fedora and RedHat. In some ways it has more value > > than Fedora the OS, because there are less free options in the git forge > > space. (Gitlab isn't usably free as is. It would need a real fork to > > get out from under the sponsor's conflicts of interest.) > > Have you tried to use Pagure as a development based git forge? And not > just as a dist-git hosting location? It needs a lot of help! More than the > current resources provide. > > The reasons why are well documented in Pagure's issue tracker. > > If that's something you value, feel free to contribute to Pagure upstream. > But Pagure can't compete with Gitlab as a development forge in its current > state. > > There are other public git forges that behave better than Pagure: > > - SourceHut > - Gitea > - ... > > So I don't think this actually has as much value as you think. > > > And to be clear: there's a difference between a Fedora-sponsored > Development forge and a new git forge for dist-git. A lot of this > discussion has conflated these two cases. I mostly care about it > releasing the former role (pagure.io) and don't care much about > the latter role (s.fp.o). I personally see this pretty much the other way - there are many good or usable forges for hosting ones project. There is at the moment pretty much only one git forge with good (and any at all any) integration with Fedora processes - Pagure. That's why I see Pagure as important mostly in the Fedora family context and less important in the general git forge are. It would certainly be nice to see Pagure take over that as well, but I see having a fully open git forge with full Fedora integration sitting on top of distgit as more important. > > > My 2c. > > - Alex > > > > > I would have expected the council to consider this an important project > > worth pursuing on its own, not just for running part of Fedora's > > infrastructure. > > ___ > > 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: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 08:56 +0100, jkone...@redhat.com wrote: > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > > > > > > - Original Message - > > > > > > > From: "Neal Gompa" > > > > > > > To: "Development discussions related to Fedora" > > > > > > > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > > > > > > Hello everyone, > > > > > > > > > I'm pleased to announce start of DNF 5 development. We are planning > > > > > > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > > > > > > development for early adopters and tool developers and we're hoping > > > > > > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > > > > > > > > > > > > > > > > More details follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > > > > > > stack in the past years, but we have reached a point when it's > > > > > > > > > nearly impossible to consolidate the code any further without > > > > > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > > > > > > can't move with the old "libhif" API in libdnf, because making any > > > > > > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > > > > > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > > > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > > > > > > > > > > > > > > > > Priorities > > > > > > > > > -- > > > > > > > > > 1. Consistency, documentation and user experience is the top > > > > > > priority. > > > > > > > > > 2. Compatibility on the command line level. > > > > > > > > > 3. Compatibility on the API level. > > > > > > > > > > > > > > > > > > > > > > > > > > > Maintenance > > > > > > > > > --- > > > > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > > > > > > from the DNF 4 stack. > > > > > > > > > > > > > > > > > > > > > > > > > > > The existing Python API in DNF > > > > > > > > > -- > > > > > > > > > The Python API in DNF stays. We'll do our best to keep it working. > > > > > > > > > If there is an incompatible change, we'll communicate and document > > > > > > > > > it properly. > > > > > > > > > > > > > > > > > > > > > > > > > > > The new API in libdnf > > > > > > > > > - > > > > > > > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > > > > > > > is the only way to ensure that package managers work identically > > > > > >
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 09:11 +0100, Fabio Valentini wrote: > On Thu, Mar 5, 2020, 08:56 wrote: > > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "Neal Gompa" > > > > > > > > > To: "Development discussions related to Fedora" > > > > > > > > > > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > > > > > > > > Hello everyone, > > > > > > > > > > > I'm pleased to announce start of DNF 5 development. We are > > > > > > > planning > > > > > > > > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > > > > > > > > development for early adopters and tool developers and we're > > > > > > > hoping > > > > > > > > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > More details follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > > > > > > > > stack in the past years, but we have reached a point when it's > > > > > > > > > > > nearly impossible to consolidate the code any further without > > > > > > > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > > > > > > > > can't move with the old "libhif" API in libdnf, because making any > > > > > > > > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > > > > > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Priorities > > > > > > > > > > > -- > > > > > > > > > > > 1. Consistency, documentation and user experience is the top > > > > > > > priority. > > > > > > > > > > > 2. Compatibility on the command line level. > > > > > > > > > > > 3. Compatibility on the API level. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Maintenance > > > > > > > > > > > --- > > > > > > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > > > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > > > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > > > > > > > > from the DNF 4 stack. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The existing Python API in DNF > > > > > > > > > > > -- > > > > > > > > > > > The Python API in DNF stays. We'll do our best to keep it
Re: Announcing start of DNF 5 development
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Sent: Wednesday, March 4, 2020 11:01:43 PM > Subject: Re: Announcing start of DNF 5 development > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > Hello everyone, > > > I'm pleased to announce start of DNF 5 development. We are planning > > > to deliver a module stream or a COPR repo during Fedora 33 > > > development for early adopters and tool developers and we're hoping > > > in getting a stable version into Fedora 34. > > > > > > > > > More details follow. > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > stack in the past years, but we have reached a point when it's > > > nearly impossible to consolidate the code any further without > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > can't move with the old "libhif" API in libdnf, because making any > > > bigger changes to PackageKit is clearly out of scope. > > > > > > [1] > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > stack: DNF 5. And this is the plan: > > > > > > > > > Priorities > > > -- > > > 1. Consistency, documentation and user experience is the top priority. > > > 2. Compatibility on the command line level. > > > 3. Compatibility on the API level. > > > > > > > > > Maintenance > > > --- > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > from the DNF 4 stack. > > > > > > > > > The existing Python API in DNF > > > -- > > > The Python API in DNF stays. We'll do our best to keep it working. > > > If there is an incompatible change, we'll communicate and document > > > it properly. > > > > > > > > > The new API in libdnf > > > - > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > is the only way to ensure that package managers work identically > > > across the whole distribution. We'll start with C++ API and > > > auto-generated Python bindings via SWIG. We'll focus on the Python > > > bindings which are required by DNF and we will do our best to > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > created later when the C++ API is stable. At that moment rpm-ostree > > > will be ported to the new C API. > > > > > > > > > hawkey > > > -- > > > Hawkey Python API is going away and will be replaced with libdnf Python > > > API. > > > > > > > > > DNF > > > --- > > > DNF stays as the primary command-line package manager. The overall > > > functionality remains. We don't anticipate any negative impact of > > > the API rewrite on the end-users. We have built an extensive test > > > suite (over 1400 scenarios) that will help us to ensure that. The > > > argument parser and outputs may slightly change in some cases to > > > provide a more consistent user-experience. All such cases will be > > > properly documented. > > > > > > > > > microdnf > > > > > > Microdnf is becoming important because it's part of many containers > > > due to its small footprint. We're getting feedback that users would > > > appreciate something closer to DNF. We'll focus on implementing a > > > subset of DNF's functionality and improving the user experience. > > > 100% feature parity with DNF is currently out of scope. > > > > > > > > Hi, > > > > the roadmap is ambitious, but not impossible. Good luck! > > > > > Roadmap (tentative) > > > --- > > > * Mar 2020 - making the bigger API changes, upstream code barely compiles > > > * May 2020 - COPR repo with first development snapshots > > > * Jun 2020 - F33 module available for early adopters and tool developers > > > * Oct 2020 - DNF 5 landing in F34 Rawhide > > > * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora > > > > > DBus service > > > > > > DNF team has decided to create a new DBus service replacing > > > PackageKit to provide an interface to GUI applications. It's > > > probably going to take a while because we're planning to start from > > > scratch. > > > > Do you plan to make normal 'dnf' calls go through the dbus api? > > This would be interesting, but wouldn't that make using DNF in rescue > situations impossible? You mean due to the regular DBus daemon & system + session bus not running in some system rescue scenarios, right ? While possibly a bit tricky I could imagine some fallback mechanism where invocation of the CLI tool starts it's own DBus session & instance of the DNF service when it detects that the regular system & session buses are not available. Anaconda does something
Re: Seeking the maintainer of dbus-python
On Thu, 2020-02-13 at 18:54 +0100, Kevin Kofler wrote: > Martin Kolman wrote: > > I wonder if this is an actual problem on Fedora ? I would assume many > > system services and applications depend on GLib, so using dasbus should > > not pull on extra dependencies in practice. > > From a distribution standpoint, the dependency on GLib is not a problem > (Neal Gompa's point about the event loop might be relevant, but I guess that > in the case of GTK applications such as Anaconda, using the GLib event loop > is actually desirable), but having yet another library dragged onto all > images as a dependency of the installer is not so nice (even if it is only a > wrapper around GLib/GIO code doing the actual work). We have been using pydbus[0] before switching to dasbus, so this should not be a net difference asa AFAIK nothing else is using pydbus on the image. [0] https://koji.fedoraproject.org/koji/packageinfo?packageID=23792 > > Kevin Kofler > ___ > 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: Seeking the maintainer of dbus-python
On Thu, 2020-02-13 at 16:44 +0100, Kevin Kofler wrote: > Martin Kolman wrote: > > the rather new (F32+) pure-Python dasbus DBus library > > LOL, don't you love fake German? ^^ > (Actual German would be "Der Bus", not "Das Bus". ;-) ) We are aware of that & and it indeed is fake German on purpose. :) > > And the library is not really pure-Python, it uses GLib (including, as far > as I can tell, GLib/GIO's D-Bus protocol implementation, at least I see uses > of it in connection.py). I should have been more concrete - it is pure Python as in not containing C extension code that wold have to be compiled, but it indeed uses GLib for the low level DBus protocol handling. I wonder if this is an actual problem on Fedora ? I would assume many system services and applications depend on GLib, so using dasbus should not pull on extra dependencies in practice. > > Kevin Kofler > ___ > 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: Seeking the maintainer of dbus-python
- Original Message - > From: "Vojtěch Trefný" > To: devel@lists.fedoraproject.org > Sent: Wednesday, February 12, 2020 11:07:29 AM > Subject: Re: Seeking the maintainer of dbus-python > > > > On 2020-02-12 11:01, Vojtěch Trefný wrote: > > > > > > On 2020-02-12 03:03, Neal Gompa wrote: > >> On Tue, Feb 11, 2020 at 7:32 PM Michael Catanzaro > >> wrote: > >>> > >>> On Tue, Feb 11, 2020 at 11:37 pm, Miro Hrončok > >>> wrote: > Since cca mid-2018 there was no reply from any maintainer in > Bugzillas. > >>> > >>> Hi, > >>> > >>> This package has been deprecated for a very long time (a decade?). > >>> Nothing should be using it anymore. Either use GDBus via PyGObject, or > >>> another D-Bus client library instead. If anybody wants to take this > >>> package, I'm sure that could be arranged. Working out a retirement plan > >>> would also be a good idea, though if there are too many rdeps it might > >>> not be practical. > >>> > >> > >> This is probably not going to be workable: > >> > >> $ sudo dnf -q repoquery --whatrequires python3-dbus | wc -l > >> 106 > >> $ sudo dnf -q repoquery --whatrequires 'python3.7dist(dbus-python)' | wc > >> -l > >> 3 > >> > >> I don't think this was the library that was deprecated either. I'm > >> pretty sure that was the libdbus-glib library, though this is > >> unfortunately built on top of that. > >> > > > > From https://gitlab.freedesktop.org/dbus/dbus-python/blob/master/NEWS: > > > > "The deprecated dbus-glib library is no longer required. A bundled copy > > of its main loop integration code is included instead." > > > > We are using dbus-python in some of our packages (mostly test suite for > > UDisks and some helper scripts etc.). > > Actually lvmdbusd is using dbus-python so Anaconda indirectly depends on > it (Blivet is using LVM DBus API for LVM management). Yeah, I don't think Anaconda directly uses python-dbus anymore. We have recently migrated to the rather new (F32+) pure-Python dasbus DBus library and it has been working nice so far: https://github.com/rhinstaller/dasbus https://koji.fedoraproject.org/koji/packageinfo?packageID=30190 > ___ > 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: Git Forge Requirements: Please see the Community Blog
On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote: > On Wed, Jan 22, 2020 at 12:58 PM Milan Crha wrote: > > On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote: > > > they all picked GitLab CE. > > > > Hi, > > I do not want to pollute this thread with unrelated information, > > but for what it worth, I only recently realized that GitLab CE, the one > > hosted on GNOME, does not have searching working properly. I filled a > > bug upstream [1]. Being able to reliably search in issues is rather > > essential function, from my point of view. I'm wondering how they can > > search for anything when they've filled 10k+ issues. > > > > Anyway, if you think this doesn't belong to this thread then I > > apologize. > > Fulltext search in GitLab is an Enterprise Edition feature and > requires a separate deployment of ElasticSearch. Ouch - really ? :-( Well, I guess that demonstrates quite nicely the dangers of open core projects right here and there... > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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: Announcing multi-builds updates gating
On Tue, 2020-01-21 at 17:59 +0100, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > We are pleased to announce that the work to gate rawhide packages has leveled > up! Cool! :) > > Back in July we announced the first phase where bodhi got the support to gate > single-build updates. We can now officially announce that bodhi can gate > multi-builds updates. This is achieved through the use of side-tags, which can > be created on demand via ``fedpkg request-side-tag``. How "cheap" operation is this ? Should we use this every time we want to release interdepndent packages to Rawhide (say Anaconda + Initial Setup, those two often might need to be updated synchronously) or only when absolutely necessary & when we want to make use of multi package gating ? > The package can then be > built using ``fedpkg build --target=`` or via ``fepdkg > chain-build --target=``. Once all your packages are built, you > can create a bodhi update from this side-tag using either the ``Use Side-Tag`` > drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi > updates new`` command. > > Every build in the update will then be tested by the CI system which will > report > the outcome. Bodhi will then query greenwave which will rely on the collection > of these individual results to make a decision about whether to gate the > update > or not. > > More detailed documentation is available at: > - https://fedoraproject.org/wiki/Package_update_HOWTO > - https://docs.fedoraproject.org/en-US/rawhide-gating/ > > Note: this is not the end of rawhide-gating. We still have some changes > planned > to make it easier for greenwave to make a decision about an update containing > multiple builds, we want to improve the documentation for on-boarding new CI > systems and make them matter for rawhide as well as for stable releases. > We then have all the work ahead to improving our tests, including enabling > some > of them distribution-wide, looking at the reverse dependencies or testing for > the impact of an update on our composes. > > > Looking forward for your feedback! > > Pierre > For the rawhide gating team > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-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-annou...@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: Git Forge Requirements: Please see the Community Blog
On Wed, 2020-01-22 at 13:51 +0100, Florian Weimer wrote: > * Miro Hrončok: > > > On 22. 01. 20 13:12, Aleksandra Fedorova wrote: > > > I think that it would be more productive if you try to rationalize this > > > opinion. > > > I don't want to argue about the feeling you have, but I would be > > > interested in comparing notes on what exactly "Gerrit workflow" means > > > to you, and whether or not it is the same thing to me. > > > > Note that I don't describe an experience with a workflow. I am > > describing a drive by contributor experience: > > > > 1. you send a Pull Request over a familiar channel > > 2. a bot tells you that you cannot do this and you need to follow this > > tutorial instead > > 3. you push your code to some place that is far to overocmplicated to > > navigate > > 4. magic happens, there is no way to see what's going on unless you > > have experienced this before > > 5. you get dozens of bot e-mail you don't understand > > 6. eventually hopefully the bot merges the thing > > Does that really matter for src.fedoraproject.org and the current > dist-git model? > > Even if you want to make a really simple change (such as fixing a typo > in the --help message), src.fedoraproject.org will not show you the file > you need to edit, or provide you with tools to produce a patch/commit to > submit. > > The Github model is different: you would just click on the button, > make your change, add a description, and click “Propose file change”. > But even if we switched src.fedoraproject.org to Github, this would only > work for RPM spec file changes. You would still not be able to edit the > --help message directly. Weren't there some suggestions to use upackaged source code/git subtree instead of the tarball we have now ? Then the upstream source code would be there and you could fix the --help message directly in Fedora distgit. The result would be a fixed Fedora package & ideally also the same change automatically submitted to upstream for review. > That's why I think that there is little risk > of random drive-by contributions: people just won't find a place to make > the changes they want. (The potential FPCA issue I raised separately > still exists, though.) > > Thanks, > Florian > ___ > 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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Tue, 2020-01-07 at 11:20 -0700, Chris Murphy wrote: > On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote: > > On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote: > > > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > > > > I've pretty much concluded Fedora is best off dropping the nested ext4 > > > > in favor of plain squashfs, and using zstd. It's not required to do > > > > both, but the benefit is additive and significant. The work in dracut > > > > and lorax to support plain squashfs, assembling it using overlayfs > > > > instead of device-mapper is already done, and tested. > > > > > > I agree with Chris here, I think we should make the switch to plain > > > squashfs unless someone can come up something dramatic that it will > > > break :) Tweaking the current settings would be fine if we didn't have a > > > better, simpler, solution. > > > > > > A side note about the xz bcj compression -- in some experiments I > > > noticed that enabling x86 and armthumb resulted in further reduction > > > (about 400k with the default block size). My guess was due to use of ARM > > > instructions in the firmware blobs. > > Also does squashfs support zstd compression ? > > Yes, that's what I was referring to in the first sentence quoted above. Oh right, now I see it. :D In any case, nice! :) > ___ 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: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote: > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote: > > I've pretty much concluded Fedora is best off dropping the nested ext4 > > in favor of plain squashfs, and using zstd. It's not required to do > > both, but the benefit is additive and significant. The work in dracut > > and lorax to support plain squashfs, assembling it using overlayfs > > instead of device-mapper is already done, and tested. > > I agree with Chris here, I think we should make the switch to plain > squashfs unless someone can come up something dramatic that it will > break :) Tweaking the current settings would be fine if we didn't have a > better, simpler, solution. > > A side note about the xz bcj compression -- in some experiments I > noticed that enabling x86 and armthumb resulted in further reduction > (about 400k with the default block size). My guess was due to use of ARM > instructions in the firmware blobs. Also does squashfs support zstd compression ? IIRC the speedups in compression and decompression speed we got for RPMs[0] with zstd were pretty nice, so having the same for the media would be nice as well. :) [0] https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > 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: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 13:50 +0100, Miro Hrončok wrote: > On 07. 01. 20 13:17, Neal Gompa wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > > > Handling those checks is where the packaging toil is (that is, as > > > > > > long > > > > > > as Fedora is a deployment project). It is not something the > > > > > > packaging > > > > > > format makes harder. > > > > > > > > > > However, because our packaging format streamlines those checks, and > > > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > > > between dev and deployment requirements. > > > > > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > > > by devs taking shortcuts because their language packaging format lets > > > > > them. > > > > > > > > > > > > > Well said Nicolas. > > > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > > on what Fedora maintainers have always did and that is kicking forward > > > > all the upstreams, because we force them to keep updating the > > > > dependencies (or to maintain compatibility with old versions of > > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > > IMO. There won't be any collaboration between upstream projects, which > > > > was cultivated by distribution maintainers. Upstreams will sit in their > > > > silos and bundle everything. > > > Just recently I've read a discussion (IIRC on Hacker News) about an > > > article > > > about yet another mess due to NPM (I think this was for a change some > > > licensing mess, > > > not another malware) where someone suggested a radical new idea: "Lets > > > have a > > > crowd sourced set of packages that are known to have sane licenses, don't > > > contain > > > malware/CVEs and can work together!". Yeah, like, say a Linux distro such > > > as Fedora ? > > > > > > Basically, it seems to me that the language specific package management > > > systems > > > are already creaking under load & display critical issues almost on a > > > daily basis. > > > Issues people with distro packaging background pointed out long ago, only > > > to be ignored. > > > > > > So I think it really makes much more sense to continue with all the nice > > > nice improvements > > > we have been doing in RPM packaging, rather than throwing it all away and > > > switching to > > > a fundamentally inferior technology. > > > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > > > tailored or more upstream like and there is no right way which could > > > > reasonably satisfy both worlds. > > > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > > > a dependency resolving on other platforms, if the project was created > > > > using Fedora packages. This is unfortunately the reason for devs to take > > > > some shortcut, probably to go with upstream way, because if nothing > > > > else, it is typically better documented. > > > > > > > > There's some interesting cognitive dissonance here. In HN threads > > where I've seen this, people seem to be naturally discovering that > > what they want is a curation point for these modules, but when someone > > points out that the Linux distribution essentially functions in that > > role, there's some recoil. They say that they don't want that. > > > > I think the underlying problem here is that we don't sell ourselves > > well in the value proposition to these people. Most people sadly > > reference Debian as their idea of a Linux distribution. While they > > certainly provide certainty and curation, they are often too slow to > > be usable by developers to leverage new features and capabilities for > > their software. This is something we need to figure out how to market > >
Re: Let's talk about Fedora in the '20s!
On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > Handling those checks is where the packaging toil is (that is, as long > > > as Fedora is a deployment project). It is not something the packaging > > > format makes harder. > > > > However, because our packaging format streamlines those checks, and > > forces to apply them, it is blamed by devs for the impedance mismatch > > between dev and deployment requirements. > > > > But, this mismatch is not caused by our packaging format. It is caused > > by devs taking shortcuts because their language packaging format lets > > them. > > > > Well said Nicolas. > > Embracing the "language-native packaging" and "git repos" is giving up > on what Fedora maintainers have always did and that is kicking forward > all the upstreams, because we force them to keep updating the > dependencies (or to maintain compatibility with old versions of > dependencies). Once we embrace "git repos" etc, we will lose our soul > IMO. There won't be any collaboration between upstream projects, which > was cultivated by distribution maintainers. Upstreams will sit in their > silos and bundle everything. Just recently I've read a discussion (IIRC on Hacker News) about an article about yet another mess due to NPM (I think this was for a change some licensing mess, not another malware) where someone suggested a radical new idea: "Lets have a crowd sourced set of packages that are known to have sane licenses, don't contain malware/CVEs and can work together!". Yeah, like, say a Linux distro such as Fedora ? Basically, it seems to me that the language specific package management systems are already creaking under load & display critical issues almost on a daily basis. Issues people with distro packaging background pointed out long ago, only to be ignored. So I think it really makes much more sense to continue with all the nice nice improvements we have been doing in RPM packaging, rather than throwing it all away and switching to a fundamentally inferior technology. > > Also, just today I had discussion if Ruby packages should be more Fedora > tailored or more upstream like and there is no right way which could > reasonably satisfy both worlds. > > E.g. if upstream package has Windows specific dependencies, it is kind > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > a dependency resolving on other platforms, if the project was created > using Fedora packages. This is unfortunately the reason for devs to take > some shortcut, probably to go with upstream way, because if nothing > else, it is typically better documented. > > > > Vít > > > ___ > 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 31: dnf upgrade suddenly enables modular streams for protobuf
On Fri, 2019-12-06 at 17:36 +0100, Miro Hrončok wrote: > Today I've attempted to run "dnf upgrade". > > It has the following in it: > > Upgrading: > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular > > Enabling module streams: > ant > eclipse > maven I've noticed this during an update as well, pretty weird behavior when user has not explicitely asked for a module to be installed & information what has triggered this action is lacking. > > > I don't consider this behavior adequate for a released Fedora version. > > As a maintainer of dependent packages (Cura stack) I have tested and built it > against the nonmodular protobuf. What just happened here and how do I track > it down? > > dnf doesn't even tell me what module is this in. I suppose eclipse. > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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: Issue with Fedora GeoIP service
On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote: > When installing Fedora 31 on a system, I noticed that anaconda defaulted > to US/Pacific for the time zone, rather than the correct US/Central. > I'm on a Google Fiber connection, and when I check Fedora's service at > https://geoip.fedoraproject.org/city I get the info for their HQ in > Mountain View. I'm pretty sure I got my proper location in the past. > > What geoIP service is Fedora using for this? AFAIK the service is run as part of the Fedora infrastrucuture, due to its potentially sensitive nature (every manual installation that has network access will try to reach this API). It is not a third party provided API. > When I check MaxMind's > site, they give the correct info for both my IPv4 and IPv6 addresses > (which BTW the Fedora geoIP lookup doesn't have a v6 address so only > checks v4). > > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate, > and that DB has the correct info. IIRC the infra team mentioned some issues with the new geoip database being incompatible with how the service is currently implemented, resulting in being stuck with an outdated database until this is resolved. But I'm sure the people actually running this will know more, so CCing the Fedora infra list. > -- > Chris Adams > ___ > 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 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 2019-12-02 at 18:16 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Dec 02, 2019 at 10:44:46AM -0700, John M. Harris Jr wrote: > > On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel > > wrote: > > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > > > > Mabee systemd-homed is in > > > > > a position to solve this by having early enough authentication > > > > > capability by rescue.target time that any admin user can login? > > > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > > > implemented together with changes to how user metadata querying is done: > > > > instead of using dbus, a brokerless and much simpler varlink query is > > > > used. > > > > That last part is what would be relevant to early-boot logins, because > > > > less services need to be up to bring up the user session. > > > > > > There's one tricky feature of homed : remote login (ssh) is only > > > possible after an initial local login. It is OK for his intended use (a > > > personal laptop/tablet client), except for corner cases like a remotely > > > accessed personal desktop in the basement that might get rebooted e.g. > > > for updates, resulting in an accidental lockout. > > > > Basically, systemd-homed is useless for any power user, but might be useful > > for people just getting into GNU/Linux, who don't use ssh yet or don't have > > more than one system. > > How often do you ssh *into* your laptop? Actually all the time - my (personal home) laptop is where my hobby projects live, where various SSH private keys are, etc. So I SSH there to connect to another machine using the SSH keys, to work an my hobby projects from a workstation computer at home, etc. And this is just "human" SSH sessions, various automated rsync/scp connections might happen as well. > I occasionally do, but more > because I can than because I really need to. systemd-homed is most > suited for the case of a portable personal device, and this is exactly > the type of device one is relatively unlikely to access from the > network. So I don't think this limitation is so terrible. > > Nevertheless, I'm pretty sure that a workaround for this will be made > anyway. I think the latest version of the patchset allows exporting > the authorized_keys content in the non-encrypted metadata for the user. > > Zbyszek > ___ > 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: Is 50+ RPM Subpackages too extreme?
On Wed, 2019-11-27 at 07:44 +0100, Igor Gnatenko wrote: > No, 50 is perfectly fine. As others mentioned, we have much bigger amount of > them in texlive. Yeah, I also don't really see a problem in making packages more granular. There are many usecaseswhere you want that, such as installation images or minimal cloud images and containers. If packages are not granular, you need to resort to ugly hacks that are hard to maintain if you want to make yourimage smaller. With granular packages you can install only what you really need, no hacks required! > If those are like plugins which may or may not require other packages, I > would split them. And probably put Recommends > in the main package for the most used ones. > > On Wed, Nov 27, 2019, 02:58 Chris wrote: > > Hi guys, > > > > I just wanted to poll you for some advice. My notification tool I maintain > > supports more than 50+ services now, but > > the only package isolation I do within 2 RPMs. One for the actual CLI (for > > admin's who want to use it) and the > > other is for the backend library (for Devs). I only ask because each > > supported service is very modular. > > > > I kind of like the way nagios-plugins breaks apart it's check_scripts into > > many sub-packages, but 50+ subpackages > > seems a bit extreme... or is it? It certainly seems like a bit of a > > nightmare to maintain; it would be one very > > large .spec file. > > > > You can see the directory structure here on GitHub: > > https://github.com/caronc/apprise > > > > Effectively every single file in "apprise/plugins/Notify*.py" is it's own > > plugin-able module. You can add/remove > > content into here and the tool adapts. Thus the sub-packages would only > > include 1 file per RPM. > > > > Is it advisable to go this route? I presume there is no easy way to > > transition without breaking users existing > > setup? I don't know what the d/l stats are; so there may not be a large > > enough audience to even need to worry about > > this? > > > > What are your thoughts and/or advice? > > ___ > > > > 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 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, 2019-11-25 at 16:25 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
>
> == Summary ==
> Remove ''nullok'' parameter from pam_unix module in default PAM
> configuration in order to disallow authentication with empty password.
>
> == Owner ==
> * Name: [[User:pbrezina| Pavel Březina]]
> * Email:
>
> == Detailed Description ==
>
> Current default configuration allows users to login with an empty
> password by setting nullok parameter to pam_unix module. This affects
> only logins to local machine, it does not affect ssh logins as this
> must be explicitly allowed in sshd_config. We want to disallow empty
> password by default for local logins as well to improve system
> hardening.
>
> Note: It is possible to disallow empty passwords with authselect call
> (authselect enable-feature without-nullok) or by removing nullok
> manually, however it creates possible issues in other components that
> must be addressed.
>
> === Affected Components ===
> * '''passwd''' - calling passwd -d to remove users password must be
> denied if empty passwords are disallowed otherwise the user will be
> locked out of the system
> * '''AccountService''' - D-Bus methods ''SetPassword'' and
> ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
> remove user’s password and lock the user out of the system if empty
> password is disallowed. These calls must be denied in this case.
> Additionally, these methods can be run by normal users as opposed to
> ''passwd -d'' and ''chage -d 0'' which can be run only by root.
> Therefore only root should be able to call these methods.
> * '''Gnome’s Control Center''' - when creating new users, it provides
> an option to “require password to be set on first login” which creates
> user with expired empty password. This would again lock the user out
> of the system.
> * '''Other Desktop Environments''' - may have the same issue as Gnome
> Control Center
This would definitely also affect the installation, unless we want to create
user accounts
that can't log in.
So the list of affected components should include also Anaconda and Gnome
Initial Setup.
>
> === Solution Step by Step ===
>
> Step 1) Provide a unified way to read if nullok is enabled or not
>
> We will create an authselect library call that would parse existing
> PAM configuration (not necessarily generated by authselect) and return
> list of enabled/disabled features. We will implement only ''nullok''
> feature in the scope of this change but if needed it can be extended
> in the future.
>
> Step 2) Fix passwd -d
> Calling ''passwd -d'' to remove user's password will fail if
> ''nullok'' is disabled.
>
> Step 3) Fix AccountService
> These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
> will be callable only by ''root'' and must return an error if
> ''nullok'' is disabled.
>
> SetPasswordMode
> SetPassword(“”, hint)
>
> Step 4) Fix Desktop Environments
> “Require password change on next login” must keep working. This
> feature currently relies on setting an empty password. A new option
> ''nullresetok'' will be implemented for ''pam_unix'' module that will
> allow user to authenticate with empty password only if a password
> change for this user is enforced upon login. Authentication with empty
> passwords which are not expired will be prohibited (unless ''nullok''
> is set).
>
> Step 5) Update PAM configuration to disable nullok by default
> In authselect and pam components for new installations. Upgrading from
> older systems will keep nullok present.
>
> == Benefit to Fedora ==
>
> Changes in described components (Step 1 - Step 4) are necessary to
> implement in order to make sure that user accounts and tools works
> correctly when authentication with empty password is disabled by
> system administrator. Changing system default to disallow
> authentication with empty passwords (Step 5) improves system
> hardening.
>
> == Scope ==
> * Proposal owners: Coordinate the work. Make sure all required changes
> are implemented.
> * Other developers: All affected component must be fixed. Changes are
> described in ''Detailed Description''
> * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
> check of an impact with Release Engineering is needed)
>
>
> * Policies and guidelines: No updates needed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> This does not affect system upgrades because only new installation
> will have changed default.
>
> == How To Test ==
>
> * Calling ''passwd -d user'' as root must fail with default configuration.
> * Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
> ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
> default configuration.
> * "require password reset on first login" must keep working when
> creating users from Desktop
Re: Is the MBS (Module Build Service ?) alright?
On Thu, 2019-11-21 at 07:25 +0100, Nicolas Mailhot via devel wrote: > Le jeudi 21 novembre 2019 à 01:02 +0100, Kevin Kofler a écrit : > > Fabio Valentini wrote: > > > Today, builds submitted by MBS made up more than 80% of total > > > builds, > > > or over 5x the number of "normal" builds. > > > What an incredible waste of resources. > > > > Especially considering what small percentage of the packages is > > actually in > > modules. If more packages modularize, Koji will break down > > completely. > > Especially since the *actual* request made by language SIGs was to > provide a way infra side to make mass rebuilds faster, because > compiler/interpreter language changes require rebuilding everything > periodically, and the rebuild window is a period where things scrawl to > a halt for new language packages. > > MBS achieves the exact reverse: rebuild everything when there’s no deep > need, removing infra resources that could be used to make actual mass > rebuilds, triggered by upstream changes, faster. I seem to remember from early modularity demos that MBS dis some pretty elaborate caching of builds. Is that not applicable here or did it never end up in production MBS deployment ? > > regards, > > -- > Nicolas Mailhot > ___ > 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: Getting notified on broken deps from updates-testing
On Wed, 2019-11-06 at 17:10 -0500, Randy Barlow wrote: > On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote: > > Is there any good way to get notified about this sort of problems in > > timely manner prior to the update being pushed? This is currently not > > optimal. > > I'm not familiar with an existing solution to this problem, but I agree > that it is not optimal. > > I had a chat or three with Brian Stinson about some ways we could deal > with problems like this. Today, when we CI packages (i.e., Bodhi > gating), we typically just run the tests associated with the package > being altered. Brian suggested that we could *also* run the tests of > the packages that depend on the package being altered, against the > altered package. This way if a change to something (like pyramid) would > break a dependent package's tests (such as cornice), then the update > for pyramid should get a failed test result on its tests tab. Something like this would be also very very useful for the Anaconda installer & helthy compose flow. Many failed composes and installation problems are often not issues in Anaconda itself, but the many tools and libraries it interacts with changing behavior and breaking the installer & compose generation. If new build of these components triggered the Anaconda test suite, lot of this breakage could be averted and fixed early on before actually affecting anyone. > The > problem is that this does increase the load on the test system greatly, > but perhaps we can get enough hardware to make that OK. Not sure. > ___ > 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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On Tue, 2019-11-05 at 19:41 +0100, Kevin Kofler wrote: > > Python 3 traditionally in Fedora was built with a shared library > > libpython3.?.so and the final binary was dynamically linked against > > that shared library. This change is about creating the static library > > and linking the final python3 binary against it, > > I oppose this change, because this is yet another size increase: Up to ~27% speed increase for extra ~3.4 MB storage used seems like a good trade-off to me... > > > As a negative side effect, when both libpython3.8.so and > > /usr/bin/python3.8 are installed, the filesystem footprint will be > > slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). > > and while: > > > OTOH only a very small amount of packages will depend on > > libpython3.8.so. > > in practice, that does not help because some of those packages are installed > by default, e.g., the ones you mentioned being installed by default even on > the Docker image: > > > *'''libcomps''' > > *'''libdnf''' > > *'''vim''' > > but there are more, such as gdb, libreoffice, krita, boost, etc. that are > installed on various live images, and calamares, which is popular on > remixes. So all those images will be bloated as a result of your code > duplicating change. > > > In addition: > > > By applying this change, libpython's namespace will be separated from > > Python's, so '''C extension which are still linked to libpython''' > > might experience side effects or break. > > so compatibility is an issue too. > > Kevin Kofler > ___ > 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: Blender for Fedora 31 does not support multimedia?
On Fri, 2019-11-01 at 15:33 +, Leigh Scott wrote: > Rpmfusion can't ship blender due to our non-replacement policy, fedora should > consider dropping their crippled > package. While it is certainly missing some functionality, I would not call it cripled - it is for example perfectly usable for 3D model creation for 3D printing (STL file output) & often advertised as such. Dropping the Blender package from Fedora repositories would break this usecase and require people to enable Rpmfsion to get Blender even if they just need it for printable model creation. > ___ > 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: Blender for Fedora 31 does not support multimedia?
On Fri, 2019-11-01 at 00:51 +, long27km wrote: > Why isn't there an option to install other repos codecs and impls ( i know > the technical answer) ? I thought Fedora > was now supposed to be focused on being developer friendly. Dev's could just > install another distro of the os that > allows licenses like debian/ubuntu... > except maybe I still would anyway since I'd have less trouble with those > repos recently (re: x64 requires > flatpak/winepak). These growing pains are understandable, but this is getting > to be a bigger issue if we cannot simply > install and use the tools we need. As I understand this (and actual Blender maintainers & other more knoledgable pepople plese correct me if I am completely wrong) this is due to an architectural limitation of Blender - you either build against ffmpeg at build time and have multimedia support or not build against ffmpeg and don't have multimedia support. Basically there is no runtime plugin support, like in other applications that can use Gstreamer and other mechanisms to query available codecs and use them if they are installed. IIRC Blender is not the only affected application, some even have ffmpeg as a hard dependency and can't be thus packaged for main Fedora repos at all. In any case, adding plugin support is on most if not all such cases a signifficant undertaking - unlikely something Fedora maintainers of such package can pull off, not to mention upstream potetially not being interested in accepting to such patches, that effectively increase theirmaintenance bruden by adding another codepath for codec handling. > > > From: Luya Tshimbalanga > > Sent: Thursday, October 31, 2019 4:58 PM > > To: devel@lists.fedoraproject.org > > Subject: Re: Blender for Fedora 31 does not support multimedia? > > > > > Blender in Fedora repository is built with ffpmeg support disabled by default > for legal reasons. Negativo which is one > of co-maintainers provides nearly identical version with FFmpeg enabled > accessible via fedora-multimedia branch. > > > https://negativo17.org/repos > Make sure to keep that repo disabled to avoid conflict with rpmfusion. > > > Luya > > > On 2019-10-31 11:09 a.m., Code Zombie wrote: > > > > Thanks Luya, > > > > > > > > I have all ffmpeg and gstreamer codecs installed. However, I think blender > > was installed by OpenShot before I > > actually installed ffmpeg and gstreamer codecs. > > > > > > > > > > So, it might be the reason why it does not play videos or music. But, > > reinstalling blender didn't help. Never had > > this issue before. > > > > > > > > > > - Mehdi > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 11:26 AM Luya Tshimbalanga > > wrote: > > > > > > > > > > On 2019-10-31 5:05 a.m., Code Zombie wrote: > > > > > > > Hi > > > > > > > > > > > > > > It seems that Blender 2.8 on Fedora 31 does not support sound and > > > > > > > video playback and export. > > > > > > > Does anyone have the same issue? Is that normal on Fedora 31? > > > > > > > > > > > > > > - Mehdi > > > > > > > > > > > > > Hello Mehda, > > > > > > > > > > > > Blender requires ffmpeg which cannot be legally included in Fedora > > > > > > repository to effectively use multimedia due to US patents law. One of > > > > > > best approach is either get ffmpeg without the offending codecs or > > > > > > enable an alternative like gstreamer which is beyond the scope of > > > > > > packaging process. > > > > > > > > > > > > ___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: Modularity and the system-upgrade path
On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote: > > > Or, even better (or worse): Sombody installs GIMP via GNOME Software, > > > > and under the hood, dnf does its magic and installs gimp from the > > > > module, which might depend on another, even non-default module, etc. > > > > But then, what will happen when that module is EOL, and the user has > > > > never even interacted with dnf, or modules? Will system upgrades break > > > > and prompt the user to fix something they didn't even know existed, > > > > and have never interacted with? > > This has already happened. We have had complaints from people who had never > installed any module, or used the "dnf module" command and they still ended > up with > modules installed with a problem to upgrade their computers to F31. This worries me quite a bit as people often install Fedora on computers of relatives and friendsin default configuration & instruct the users to just "press the update button when it shows up".I've done that a couple times. This has been working quite fine so far, so it would be bad to loose this capability, as the actualusers in question are definitely not power users and will not be able to fix any of these issuesby themselves. Also from their point of view it's pretty much Fedora breaking if if a specific module is ta fault.And well, they are not really wrong if a default Fedora install simply breaks upgrades at arandom point in the future... > > > > > Fabio > > > > > > > > > Pierre > > > > > ___ > > > > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote: > On 10/17/19 2:35 PM, Adam Williamson wrote: > > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote: > > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote: > > > > The one thing we are using default modular stream in RHEL 8 for is to be > > > > able to provide access to packages in kickstart that were moved to > > > > modules in RHEL 8. An example is idm:client stream which is a default > > > > module stream in RHEL 8 exactly for this reason, to be able to install > > > > ipa-client package and enroll a system into IPA from a kickstart file. > > > > > > > > We don't package FreeIPA in modules in Fedora yet but this is one of > > > > real examples how default module streams are helpful to maintain > > > > coherent user experience for existing users of kickstart files. > > > > > > > > -- > > > > / Alexander Bokovoy > > > > Sr. Principal Software Engineer > > > > Security / Identity Management Engineering > > > > Red Hat Limited, Finland > > > > > > You could install the ipa-client package and enroll a system into IPA > > > from a > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed for > > > the > > > environments I support, for example. Using a module is not required there. > > > > That wasn't the point, though - the point was the answer the question > > "why do we need *default* module streams?" > > > > The logic is this: FreeIPA maintainers wanted FreeIPA to be a module in > > RHEL, to take advantage of the added flexibility around lifecycles and > > version bumps (basically so each RHEL release isn't tied to one version > > of FreeIPA forever). But if it's modularized and there's no concept of > > 'default stream modules', this is a thing that breaks: you can't > > install it from a kickstart. So, *given that* we wanted to modularize > > FreeIPA in RHEL *and* we also want to still make it deployable via > > kickstart, that creates a requirement for default stream modules or > > something a lot like it. > > This doesn't seem quite true. You couldn't install it with the same kickstart > you used for EL7, but you could use the new module command or syntax in > kickstart: Indeed, you can install modules via kickstart. For details, see: https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-9-package-selection https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#module > > module --name=NAME [--stream=STREAM] This just enables a module stream (or can explicitely disable it with the --disable option). No packages will be installed from such module unless specified in the %packages section. > > and/or > > %packages > @module:stream/profile This enables the module stream and installs a profile - the one specified or the default profile otherwise. The syntax is pretty much the same as for DNF CLI - if you call "dnf install @module:stream/profile" you should get the same result. > > > ___ > 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: Modularity and the system-upgrade path
On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote: > On to, 17 loka 2019, Orion Poplawski wrote: > > > > You could install the ipa-client package and enroll a system into IPA > > > > from a > > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed > > > > for the > > > > environments I support, for example. Using a module is not required > > > > there. > > > > > > That wasn't the point, though - the point was the answer the question > > > "why do we need *default* module streams?" > > > > > > The logic is this: FreeIPA maintainers wanted FreeIPA to be a module in > > > RHEL, to take advantage of the added flexibility around lifecycles and > > > version bumps (basically so each RHEL release isn't tied to one version > > > of FreeIPA forever). But if it's modularized and there's no concept of > > > 'default stream modules', this is a thing that breaks: you can't > > > install it from a kickstart. So, *given that* we wanted to modularize > > > FreeIPA in RHEL *and* we also want to still make it deployable via > > > kickstart, that creates a requirement for default stream modules or > > > something a lot like it. > > > > This doesn't seem quite true. You couldn't install it with the same > > kickstart > > you used for EL7, but you could use the new module command or syntax in > > kickstart: > > > > module --name=NAME [--stream=STREAM] > Actually, you could install client packages with the same kickstart file > as for RHEL 7, that was one of uses for default profiles. > > Server package installation from kickstart file is less of a worry > because we are running a different deployment process since switching to > domain level 1 and that implies you have to do client installation > first. > > And at the time when all this was designed, kickstart had no support for > modularized installation. It has it now, of course. Well, module installation vias kickstart has been supported since before 8.0 GA. But I guess the design decisions have taken place before that. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ > 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: Modularity and the system-upgrade path
On Thu, 2019-10-17 at 09:47 -0400, Stephen Gallagher wrote:
> On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote:
> > So it looks like I did not describe clearly enough what my proposed
> > enable_modules=0 flag would do. ("Disable all module code" was apparently
> > too vague.)
> >
> > How I think it should work would be:
> > * For repositories, it completely ignores modular metadata and processes
> > only the non-modular parts of the repository metadata. Therefore, it does
> > not see the Node.js 12.x stream at all. It only sees whatever Node.js is
> > in the non-modular repository. If there are currently only modular
> > versions, then it sees none at all. But with the proposal to require a
> > non-modular default version, it would then see that version, which would
> > likely be Node.js 10.x. Nobody would get forcefully upgraded from 10.x to
> > 12.x.
> > * For installed modules, it completely ignores them, acting as if the
> > database of installed modules were empty. (It just does not read that
> > database at all.)
> > * For installed packages, it treats them all as non-modular. Sure, packages
> > originally installed from a module have weird EVRs encoding module
> > metadata, but otherwise they get processed exactly like a non-modular
> > package. So the default repository only has to provide a newer EVR to
> > upgrade the package. That should address upgrades from 8.x or 10.x to the
> > new default 10.x. If the user had previously installed 12.x, they will
> > only get downgraded if they distro-sync or if package-level dependency
> > issues with the F30 build of 12.x on F31 force the downgrade.
> >
> > I hope that clears it up.
>
> It does, thanks. I think you're right, that probably *would* work,
> though it's slightly harder to do your third bullet point than it
> sounds at first blush. I suppose we could fudge it with the
> `module_hotfix` option though..
>
> > > > A slightly more elaborate, but slightly harder to implement, approach
> > > > would be to let DNF simply disable modules that are enabled locally but
> > > > no longer available in the repositories, together with disabling the
> > > > fedora-modular and updates-modular repositories by default.
> > >
> > > And again, this only works if every packager who has spent time
> > > creating a module with a default stream takes their content and shoves
> > > it back into the non-modular repository. Which in some cases they
> > > probably cannot do, because they have build-dependencies that are in
> > > conflict. This is a highly non-trivial process and it would need to be
> > > done individually for every single package. That's far more
> > > packager-hostile than fixing the default stream/buildroot problem and
> > > the upgrade path problem.
> >
> > You are overestimating by far the effort required to demodularize the
> > handful packages that are currently module-only. The evidence Fabio
> > Valentini has gathered so far shows that actually very few packages would be
> > affected and they would not be too hard to fix. And Miro has also offered
> > help with fixing affected packages.
> >
> > All in all, it would require fixing a handful packages once and for all
> > instead of implementing workarounds affecting the entire distribution and
> > its thousands of users.
> >
>
> It's worth considering. I'm not ruling it out at this time. I'm not
> committed to doing it yet either.
>
> > > > And the case of demodularizing packages has to be addressed sooner or
> > > > later anyway, so better address it sooner rather than later, before more
> > > > and more damage is done by maintainers moving packages to module-only
> > > > without a way back.
> > >
> > > I've already acknowledged upthread that demodularizing packages is a
> > > problem we need to solve. It's being worked on, but it's a lot harder
> > > than you think, because we have failsafe code implemented in libdnf to
> > > prevent *accidental* demodularization that's in conflict with this
> > > desire.
> >
> > And exactly that code needs to go, at least in Fedora. I think having a way
> > to migrate away from modules is the common case to prioritize here.
> >
>
> This is one of those cases where I think that RHEL and Fedora needs
> are in conflict; in RHEL, we absolutely need to support the failsafe
> behavior, because accidentally replacing a critical dependency will
> break user applications. In Fedora, this is likely a smaller concern.
> It needs investigation.
>
>
> > That said, it shall be pointed out that, if the proposal to demodularize all
> > default versions of packages gets implemented, we only need a *short term*
> > solution for demodularization in DNF. After 2 releases, we have no default
> > streams left (and they will never come back by policy) and we can expect
> > users to have upgraded through a release with no default streams (given that
> > we do not support upgrading directly to n+3), so at that point DNF can
> > revert
Re: Old changelog entries removal
On Thu, 2019-10-03 at 09:37 -0500, Chris Adams wrote: > Once upon a time, Daniel P. Berrangé said: > > Or just add some RPM metadata tags to record the upstream SCM type + URL + > > branch / release tag, etc. The user can thus easily find the upstream > > full commit logs corresponding to the pacakge. > > IMHO that is only good when the Fedora package is nothing but the > upstream code, built with defaults. As soon as Fedora needs to add a > patch and/or systemd unit(s), change options, etc., there should be a > Fedora changelog. Also, the current changelogs are self contained & do not require internet access. Remote changelog URLs might become inaccessible over time, making tracking down behavior changes & tricky bugs problematic. > > And even when it's a straight build of upstream, some maintainers > include RH Bugzilla numbers in their changelog entries, which is useful > too. > > -- > Chris Adams > ___ > 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: Defining the future of the packager workflow in Fedora
On Wed, 2019-10-02 at 14:44 -0400, Colin Walters wrote: > > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote: > > > As others in the thread have pointed out, mandatory pull requests just > > make no sense for most single-maintainer projects, which most packages > > probably are. > > Well, a lot of this relates to what the *merge policy* is. If a PR submitter > can merge their own PRs, and there's a > mechanism to do "merge when tests pass" (this is an important aspect), then > submitting a PR can be just about as > equally ergonomic as `git push`. Yeah, that sounds good & nice improvement to the currently available options. In some cases I run scratchbuilds as a kind of a smoke tests before the "real" build - this way I could just use this and save some time. :) All in all I think much of this discussion feels a bit redundant to me - lets just implement the support for improved PRs that can be easily & automatically created and that triger all sorts of tests and builds. If the new system is good, I'm sure many maintainers would switch to it to everyones benefit - less regressions & less time taken maintaining packages. At the same time if other maintainers have their own workflow that is not compatible with the PR workflow or makes it redundant for their packages, they should not be forced to use it. > In OpenShift we use Prow, which has the latter; I really like it. However we > also *require* peer review (submitters > can't merge their own PRs). I'd like to require review, but it does seem > like a prerequisite is moving away from the > one-repo-per-package model. > ___ > 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: Defining the future of the packager workflow in Fedora
On Wed, 2019-10-02 at 09:39 +0200, Felix Schwarz wrote: > Am 01.10.19 um 16:55 schrieb Stephen John Smoogen: > > Then there are problems with budgets and figuring out what exactly it > > would cost. We fall outside of many of the 'caveats' that would allow > > us to get free. > > IIRC at the time when Fedora evaluated its options the open source version of > Gitlab was more limited than today. AFAIK Debian + FreeDesktop developers > worked with Gitlab Inc. and finally succeeded in getting necessary features > included in the open source version. > > If the evaluation was done today and there were no Pagure I suspect Fedora > would use gitlab as well. > > (I'm also wondering if Fedora writes too much custom infrastructure when > there > are "open core" offerings which might provide more features - e.g. Gitlab > instead of Pagure, sentry instead of abrt. But I'm aware of limited > ressources > and I trust my fellow Fedorians with their judgement.) Personally I still think it's not a very good idea to depend on any open-core infrastructure software, due to the possibility of conflict of interrest in the future. Eq. the company behind the software will not accept your patches as it clashes with their business model & proprietary code additions they sell to their customers. Then you will have to maintain those patches pretty much indefinitely. Might as well use a fully open source solution to avoid such future pitfalls. > > Felix > ___ > 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: Major update to LLVM appearing in F31 without any communication, appears to violate update policy
On Thu, 2019-09-26 at 13:21 -0700, Adam Williamson wrote: > On Thu, 2019-09-26 at 20:55 +0200, Hans de Goede wrote: > > Hi Tom, > > > > On 26-09-2019 20:47, Tom Stellard wrote: > > > On 09/26/2019 11:24 AM, Adam Williamson wrote: > > > > On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote: > > > > > On 09/26/2019 11:03 AM, Adam Williamson wrote: > > > > > > We are currently in the "Beta to Pre Release" phase of the release > > > > > > cycle. The updates policy for this phase - > > > > > > https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release - > > > > > > says: > > > > > > > > > > > > "From this point onwards maintainers MUST[1]: > > > > > > > > > > > > Avoid Major version updates, ABI breakage or API changes if at > > > > > > all > > > > > > possible." > > > > > > > > > > > > However, it seems a major new release of LLVM is appearing in F31 at > > > > > > present, and AFAIK there has been no discussion or communication > > > > > > about > > > > > > this at all. > > > > > > > > > > > > LLVM 9 is currently in the buildroot, and an update with a very > > > > > > short > > > > > > description has been submitted: > > > > > > > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-b83bd6b46c > > > > > > > > > > > > (it just says "Update for LLVM 9 rebase.", which is odd since it > > > > > > *is* > > > > > > the LLVM 9 rebase). > > > > > > > > > > > > There is no Change for this, I can't find a mail about it anywhere, > > > > > > it's just been sort of dumped in. Is there enough grounds for > > > > > > dumping > > > > > > in a major new LLVM and violating the update policy at this point in > > > > > > the F31 release? > > > > > > > > > > > > > > > > There are compatibility packages included in the update, so there > > > > > should not > > > > > be any ABI breakage from this update. Also, what exactly is the main > > > > > issue right now? Is it the buildroot overrides? > > > > > > > > This is what caused me to notice it, yes. Another update got built > > > > against LLVM 9 because it was in the buildroot, which means that update > > > > is now not installable without the LLVM 9 update: > > > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-52ecb9952b > > > > > > > > openQA caught this, which put me onto the change. > > > > > > > > > > Ok, what's the best way to resolve this issue? Do you want me to > > > cancel the update and overrides and re-submit after f31-final is out? > > If there's a sufficient justification for including LLVM 9, we still > can. I just wanted to flag up that it was happening and that it > *shouldn't* happen without sufficient justification, and probably > without more communication about it. Like, a mail to devel@ "hold onto > your hats, we're going to upgrade llvm in f31 because X, Y, Z" would've > helped. > > > If I understand things correctly, there are currently separate > > mesa and llvm updates for this in bodhi? That is never a good > > idea when there are ABI dependencies between 2 updates, bodhi does > > allow you to add multiple builds in a single update. > > > > So my 2 cents is that it would be best to cancel the separate > > llvm bodhi update and add the llvm build to the mesa update, then > > the update will be self contained / cleanly apply to current F31 stable. > > So far as resolving this issue goes, the llvm update has like 11 > packages in it, the mesa update has 1. So it would make a deal more > sense to unpush the *mesa* update and add a mesa build to the llvm > update. > > Note that Bodhi will not let you add a package to two updates - even if > one of them is unpushed - so to get the exact same mesa build in an > update you would need help from someone with superpowers who could go > do nasty things in the database to override this. The easier trick is > simply to bump and rebuild mesa with no changes, and add *that* mesa > build to the llvm update. AFAIK, there is also still a further potentially relevant Bodhi limitation, that you need to be on the maintainer list for all the packages you are adding to a Bodhi update. So if maintainer A is only maintainer of LLVM and maintainer B is only maintainer of mesa, they will not be able to put their packages into a single Bodhi update themselves and will also have to ask a proven packages to do it. The resulting update will also get "tainted" by this, rejecting any further changes from non-proven packagers. (I really hope we can get at least this one fixed already. :P) > > You *could* also just leave them separate so long as you make sure not > to push the mesa update stable before the llvm one. It is better to get > this right in the first place and put all the packages into one update, > but if you wind up with them separate and are careful about the push > order it won't cause any huge problems (it just causes things like > openQA test failures that attract angry QA people :>) > -- > Adam Williamson > Fedora QA Community Monkey > IRC:
Re: Defining the future of the packager workflow in Fedora
On Fri, 2019-09-27 at 00:20 +0200, Dan Čermák wrote: > Randy Barlow writes: > > > This suggestion gives a nice clean place to write the bodhi update > > description, right in git. The commit messages can remain the way they > > are today: authored for the audience of spec file contributors. > > > > We could also support special syntax in the tag message to allow people > > to specify the various bodhi update fields (severity, karma > > requirements, whatever else) if they want to do that that way. > > I *really* like this idea, as one could still push multiple > "development" commits to git, but until one tags something, nothing is > built & released. And there is even at least one precendent, where Git tags are used to trigger some process - the GitHub releases, that list all tags & provide archives for them. So it seems like a sensible & already proven idea. > ___ > 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: Defining the future of the packager workflow in Fedora
On Thu, 2019-09-26 at 16:24 +0200, Pierre-Yves Chibon wrote: > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote: > > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote: > > > Good Morning Everyone, > > > > > > At Flock, a few of us met to discuss a future vision of the packager > > > workflow. > > > This discussion was triggered by the realization that a number of > > > initiatives > > > are happening around packaging in Fedora but there is no real shared > > > vision on > > > what we want the packager UX/workflow to be. > > > The lack of vision on the packager workflow means we could deploy > > > something > > > today, thinking it is the improvement over the current workflow but would > > > prevent us from (or make it harder to) doing other changes afterwords > > > that would > > > be even more beneficial.. > > > > > > So once that concern was raised, we took some time during the Fedora > > > Infrastructure hackfest to gather the people interested around a white > > > board and > > > brainstorm on what a future packager workflow could look like. > > > > > > We tried not to link this process to any tool in particular as well as > > > focus on > > > the what and why rather than any how. > > > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > ○ Every changes to dist-git is done via pull-requests > > > ○ Pull-requests are automatically tested > > > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji > > > ○ Every build in koji results automatically in an update in bodhi > > > ○ Every update in bodhi is automatically tested > > > ○ If the tests pass, the update is automatically pushed to the repository > > > > For packages I maintain, my preference is to touch dist-git as little > > as possible. Ideally I would never touch dist-git at all & rather wish > > it didn't exist at all in its current form of spec+patchfiles. > > > > Instead I prefer a clone of the master upstream git repo and maintain a > > branch with patches cherry-picked into it. This is used to auto-generate > > patches for the Fedora RPM, at the same time updating the patch file list > > in the RPM spec. The only manual step is adding the changelog entry & > > bumping release number. > > > > The ideas above around associating CI with pull requests make a lot of > > conceptual sense & align with modern github/gitlab software development > > best practices followed by non-distro software upstreams. Automatically > > triggering builds from merged PRs similarly makes sense, especially > > if that can automate bumping spec release number & adding a changelog > > entry based on the pull request subject. > > > > > > Obviously I can still use my upstream git repo branch and change the > > scripts to generate a pull request to dist-git instead. The downside > > is if the PR fails, I now how to rebase my real git repo & re-submit > > and new PR. > > > > So if we're talking "ideal" long term vision though, I'd rather eliminate > > the dist-git repo intermediate step as IMHO it adds no value, only > > complexity > > for the sake of historical compat with the way Red Hat distros has worked > > dating back years. Its time to say goodbye to this historical way as the > > world has moved on since this spec+patches approach was invented in the > > days of CVS source control. > > > > Allow packagers to have a clone of the upstraem git repo, and use the > > pull-requests and run Fedora CI testing against the Fedora branch of > > the upstream repo instead of against dist-git. > > > > In this way, maintaining packages in Fedora would be functionally identical > > to how an upstream project maintains their own stable branches. The only > > Fedora difference would be that the branch would need to include the RPM > > spec file in some well defined place. > > I like this. > It means that the build-system would have to generate the tarball of the > source > and put it into dist-git at srpm-build time (I believe we still want to store > a > copy of the sources used for a build). If we want to generate tarballs, we need to think about translations as well. While some projects do have translations as part of their source code repository, others currently pull them in at tarball build time. This would have to be accounted for or otherwise the resulting tarball would miss the translations. > > Three questions though: > - What about the upstream projects that still only publish a tarball at > release? > Should the packager explode that tarball into a git repo? > Do we keep the current way of uploading the tarball? > - Won't this make pull-request for new update harder? Suddenly you have the > diff > of both all of the upstream changes as well as the spec file and potential > patches. > In most cases the spec file and the patches is what will matter but for > large > code-base the diff could be quite significant then. > - Do you have in mind
Re: Defining the future of the packager workflow in Fedora
On Thu, 2019-09-26 at 18:26 +0200, Ben Rosser wrote: > On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon > wrote: > > On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote: > > > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon > > > wrote: > > > > There is a clear initial rejection of a PR-only contribution model. I > > > > hear that > > > > and that may mean that we never go this way. I'm honestly fine with > > > > that :) > > > > I do want to see why that is a show-stopper and if we can find ways to > > > > not have > > > > it be a show-stopper. > > > > > > > > When we work on upstream projects, I think it's pretty standard now to > > > > always go > > > > via PRs, even for your own branch. > > > > So that tests are run, so that other member of the community can see, > > > > comment, > > > > review the change. > > > > What is so different in Fedora that we cannot move to this model? > > > > Is it a tooling issue? > > > > Is it something else? > > > > > > Most packages in Fedora are effectively one-person projects (modulo > > > rebuild scripts and other automated tooling). My experience when > > > working on a personal project is that I don't use PRs for changes even > > > if I do develop a change in a branch, rather than master; it's a lot > > > of unnecessary overhead. There are no "other members" of the > > > community. No one is reviewing the change other than me. > > > > Would this change if the PR was automatically tested for you without you > > having > > to do anything? > > No, not really? For a personal project, a continuous integration > system can be set up to run tests on _all_ of my commits, regardless > of whether or not they're to master or to a development branch. What's > the benefit of creating a pull request here? > > That being said, packages are slightly different. If it wasn't > necessary to use the web interface to make a pull request and if > fedpkg could do it for me [1], and automatically merge it when the > build succeeds... that might be nice. But if manual work is required > to create a pull request-- filling out a form on Pagure, manually > forking a project, etc.-- I think it's a lot of overhead. And I > wouldn't want to do it for most of my packages. > > Ben Rosser > > [1] And, in an ideal world, do it without needing an API key but > rather authenticating to Pagure via some other mechanism that doesn't > require manually downloading a key, but I digress... If we are talking packager quality of live imporvements, I would vote for this as one of the improvements - unification of the ~5 methods of authetication one might need to apply when working with fedpkg at the moment. Ideally there should be one method, most likely kerberos, that autheticates the user with FAS and should be used for everything. While its true that some of the services (Pagure, COPR) use API keys, this should be an implementation detail in this case. You authorize Pagure & COPR with your FAS account once (or possibly this happens automatically) and don't have to care about API keys unless you are wiritng some automated tool that needs them. > ___ > 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: Estimate the size of iso file based on a kickstart file
On Tue, 2019-09-24 at 11:32 -0700, Brian C. Lane wrote: > On Thu, Sep 19, 2019 at 08:10:21PM +0800, Kalpa Welivitigoda wrote: > > Hi all, > > > > Given a kickstart file (flatten) and we intend to make an iso using > > it, is there a tool or service by which we can estimate the size of > > the final iso (based on the packages defined in the kickstart file) > > before actually creating the iso? > > AFAIK we don't have any stand-alone tools to do that, which is probably > a good thing since trying to estimate the installed size usually ends up > being very much not exact. In lorax-composer I have this: > > https://github.com/weldr/lorax/blob/master/src/pylorax/api/projects.py#L288 > > which does the raw estimation. But then there is this: > > https://github.com/weldr/lorax/blob/master/src/pylorax/api/compose.py#L738 > > Which adds 20% > > But wait, that's not all! Anaconda then adds more: > > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfpayload.py#L879 > > The reason behind all of this fudging is that we really don't know the > exact sizes of the installed packages, and it can be influenced by block > size, filesystem type, etc. Exactly, just for fun I'll try to enumerate the factors I can remember: - even an empty filesystem has to store it's metadata inside itself, so there will always be less useable space on a filesystem than it's raw size, this value depends on the filesystem and possibly other factors - some older/simpler filesystems (such as FAT32) are very inefficient at storing many small files which can further increase actual needed ammount of storage space - while RPMs do contain unpacked size of all the files inside, it does not list size per file, so if you have a separate mountpoint for say var, you can't know how much data will be installed in the given location by a RPM (but this is likely not a problem for image size) - RPMs can do arbitrary stuff in their scriptlets, including cache generation, that can take an arbitrary ammount o space that simply can't be estimated beforehand - when configuring the system Anaconda writes out config files, enables services and similar, which also uses up some space, though very very minor amount - kickstart describing the installation and installaiton logs are stored on the system by default, those could eat up some more space - a couple MB - AFAIK images generally use squashfs, so the content of its filesystem will be compressed, reducing it size, but again in a hard to tell beforehadn manner, based on how well the filesystem content compresses with the given algorithm used So there is indeed quite a few variables, many with values uknown until things are already in place, which is why the various percentual & absolute size adjustments are done. Technically, I guess it might be possible to just run the size estimation code for a kickstart file and then just output the estimated number instead of starting an installation/image generation if someone finds that useful & wirtes the needed patches. :) > > Even with all this added extra space I have occasionally seen it run out > of space (usually when trying to do a smaller install than a bigger one, > where the room for error is smaller). > > The 'best' way to do what you want is to put together your kickstart, > give it a big / partition, do a build and see how much free space there > is, and trim it down. But not too far :) Definitely, this is the only real way to get real numbers with the way our seoftware & its installation process is built. Actually, I would suggest this to a regular thing, done automatically say nightly, with the results being measured & notification being sent when when a given size threashold is reached. AFAIK nothing like this is done currently and we basically only catch any signifficant size increases once they break things, which is kinda late & makes fixing things harder. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > 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: Which arch should we add to Copr?
- Original Message - > From: "Dan Horák" > To: devel@lists.fedoraproject.org > Sent: Tuesday, September 17, 2019 3:50:59 PM > Subject: Re: Which arch should we add to Copr? > > On Tue, 17 Sep 2019 15:01:48 +0200 > Miroslav Suchý wrote: > > > Dne 17. 09. 19 v 13:12 Dan Horák napsal(a): > > > sounds great, but are they using a real hw or are they emulated (and > > > how)? > > > > It will be emulated using --forcearch > > https://github.com/rpm-software-management/mock/wiki/Feature-forcearch > > hm, as much as I would like to have more arches in Copr, I don't think > the emulation is production quality. Recent changes in glibc exposed > hard-to-find bugs in the s390x TCG in qemu and I saw at least one > emulation related bug for armv7 as well. It might not be perfect, but AFAIK at least one Linux distribution (Sailfish OS) has been using emulated 32-bit ARM on x86_64 hosts since 2013 to build everything without any native build hardware. Their OBS instance can be found & inspected here: https://build.merproject.org/ > > What blocks you from using armv7 VMs on aarch64 hosts? > > > 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
Re: Add a rule to have a compose when Fedora branched
- Original Message - > From: "Ben Cotton" > To: "Development discussions related to Fedora" > > Sent: Tuesday, September 17, 2019 4:38:50 PM > Subject: Re: Add a rule to have a compose when Fedora branched > > On Tue, Sep 17, 2019 at 10:00 AM wrote: > > > > I want to ask for an improvement here. Ideal solution for me would be > > to add rule that there have to be compose to do the branching and if > > the compose fails then the branching won't happen. Not sure if this is > > doable or how hard it would be to implement a similar rule, however, it > > would be an ultimate solution. Then, the compose blocker bugs had to be > > solved on Rawhide where they should be solved. > > > I want to make sure I understand what you're proposing. You're > suggesting that we shift from having the branch point be a defined, > specific date in the schedule to having it be a range of possible > options. So it would be more like the Beta and GA releases where we > target a day, but slip if we're not ready. Is this right? I understand the need for having reasonably specified set of dates so that people can plan their work around them. But simple triggering branching without any prior smoke test/dry run or CI & blindly following the dates regardless of the result does not seem like a good idea to me. We could change the branching date to Not Earlier Than, branch on the date and only start the countdown for the outer milestones once there is a compose and possibly other pieces in place (Mock/Copr chroots, etc.) for people to actually get anything done on the branched release. > > So how recent of a rawhide compose qualifies? If there's a successful > compose in the last week, is that okay? Does it have to be the night > before the branch point? Are there other judgments that go into (like > in the go/no-go meeting) or is it entirely based on the compose? > > My initial reaction is that this in an outlier and that we shouldn't > make structural changes to the schedule in response to outliers, but I > wonder if there are other guardrails we can put in place. I'm afraid this is not an outlier as compose failures still happen very often, it was simply that we got a streak of them at the worst time possible. In other cases they might not be so visible, but still regularly cause pain to Fedora contributors and users. To improve the situation there are basically two things to consider: - what development milestones should require a successful compose before we move forward with them - what breaks the compose & how we can avoid it, possibly by doing dry runs/CI runs on things before we introduce them to the compose cauldron > Perhaps by > making consistent compose failures more visible to the community? > > > Please tell me what should I do next. Should I file a FESCO ticket to > > add this rule? > > > I expect FESCo will want to wait until the community has had an > opportunity to discuss this first. I suggest waiting a week or so > (depending on how long the conversation remains productively active) > and then filing a FESCo ticket. > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: Add a rule to have a compose when Fedora branched
- Original Message - > From: "Miro Hrončok" > To: devel@lists.fedoraproject.org > Cc: "Mohan Boddu" , "Lubomir Sedlar" , > "Kevin Fenzi" > Sent: Tuesday, September 17, 2019 5:04:10 PM > Subject: Re: Add a rule to have a compose when Fedora branched > > On 17. 09. 19 17:00, jkone...@redhat.com wrote: > > If that is not doable what about taking last Rawhide compose and mark > > that as first compose of newly branched Fedora? The only thing I'm > > asking for is to have a base ground which is not available right now. > > That is actually a nice proposal. I wonder whether it is technically > possible. > CCing (hopefully) relevant people. I personally think it should work. As long as the Rawhide compose you take and rebrand as F3X is older than the F3X branching date. That way all the fcs will be fc3x and there will not be any unexpected updated post branch Rawhide packages. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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: Donate 1 minute of your time to test upgrades from F30 to F31
Looks like I have something uniqe I haven't seen in the other mails, related to packit: $ LANG=en_US sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 --enablerepo=updates-testing distro-sync RCM Tools for Fedora 31 (RPMs) 284 B/s | 286 B 00:01 Failed to download metadata for repo 'rcm-tools-fedora-rpms' RPM Fusion for Fedora 31 - Free - Updates 310 kB/s | 76 kB 00:00 Failed to download metadata for repo 'rpmfusion-free-updates' RPM Fusion for Fedora 31 - Nonfree - NVIDIA Driver 259 kB/s | 76 kB 00:00 Failed to download metadata for repo 'rpmfusion-nonfree-nvidia-driver' RPM Fusion for Fedora 31 - Nonfree - Updates 67 kB/s | 76 kB 00:01 Failed to download metadata for repo 'rpmfusion-nonfree-updates' Ignoring repositories: rcm-tools-fedora-rpms, rpmfusion-free-updates, rpmfusion-nonfree-nvidia-driver, rpmfusion- nonfree-updates Last metadata expiration check: 0:02:43 ago on Thu 12 Sep 2019 12:06:55 PM CEST. Error: Problem 1: problem with installed package python3-packit-0.5.0-1.fc30.noarch - python3-packit-0.5.0-1.fc30.noarch does not belong to a distupgrade repository - nothing provides python3.7dist(koji) needed by python3-packit-0.5.1-1.fc31.noarch Problem 2: package python2-pyglet-1.3.2-3.fc29.noarch requires python2-future, but none of the providers can be installed - python2-future-0.17.0-2.fc30.noarch does not belong to a distupgrade repository - problem with installed package python2-pyglet-1.3.2-3.fc29.noarch Problem 3: problem with installed package packit-0.5.0-1.fc30.noarch - package packit-0.5.1-1.fc31.noarch requires python3-packit = 0.5.1-1.fc31, but none of the providers can be installed - packit-0.5.0-1.fc30.noarch does not belong to a distupgrade repository - nothing provides python3.7dist(koji) needed by python3-packit-0.5.1-1.fc31.noarch (try to add '--skip-broken' to skip uninstallable packages) CCing one of the packit maintainers. ___ 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 (late): No i686 Repositories
On Mon, 2019-09-09 at 13:27 -0500, Bruno Wolff III wrote: > On Mon, Sep 09, 2019 at 18:06:02 -, > vvs vvs wrote: > > Yes, thanks. Sadly, I see that I have no choice but to switch to another > > distribution even though I'm using 64-bit > > CPU. It's just that the memory can't be upgraded and buying new computer > > just to keep running Fedora is not viable. > > It's 12 years old, is in good condition and I'm completely satisfied with > > its performance for my needs. I wonder > > what owners of thin terminals will do if they used Fedora, especially if > > there are many of them. The cost of > > upgrading some old terminals for some school can be too high. > > It is probably very rare for someone to have just enough memory for a system > to > run reasonably using i686, but tank when using x86_64. If there is some > key code that causes the problem, you might be able to rebuild that code to > use 32 bit addresses and save enough memory to make things work reasonably. Yeah, I've recently switched an old Atom A330[0] based system[1] with 2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit based distro (after finding out it can actually run 64-bit code). It has been running just fine and actually feels a bit faster now. [0] https://ark.intel.com/content/www/us/en/ark/products/35641/intel-atom-processor-330-1m-cache-1-60-ghz-533-mhz-fsb.html [1] https://ark.intel.com/content/www/us/en/ark/products/42491/intel-desktop-board-d945gclf2.html > ___ > 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 > based ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
- Original Message - > From: "Chris Murphy" > To: "Development discussions related to Fedora" > > Sent: Friday, August 30, 2019 9:55:52 PM > Subject: swap on ZRAM, zswap, and Rust was: Better interactivity in > low-memory situations > > Hi, > This is yet another follow-up for this thread: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ > > > Basics: > "zswap" compresses swap and uses a defined memory pool as a cache, > with spill over (still compressed) going into a conventional swap > partition. The memory pool doesn't appear as a separate block device. > A conventional swap partition on a drive is required. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/blockdev/zram.txt?h=v5.2.9 > > "swap on ZRAM" A ZRAM device appears as a block device, and is > effectively a compressed RAM disk. It's common for this to be the > exclusive swap device, of course it is volatile so in that > configuration your system can't hibernate. But it's also possible to > use swap priority in fstab to cause the ZRAM device to be used with > higher priority, and a conventional swap partition on a drive with a > lower priority. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/vm/zswap.rst?h=v5.2.9 Just a slight addition to this comparison - AFAIK there is a slight difference in how zswap and zram handle the in-ram swap device being full & making use of the swap device on harddrive. If the zswap device becomes full, zswap will, according to the docs, free up spase in RAM by moving the least recently used pages to the disk, so that the "hot" pages stay in ram & new pages can be placed there. In comparison AFAIK, there is no such mechanism for zram and the priority value simply means which swap will be used as the first one and once it becomes full, new pages will simply go to the next swap with lower priority. Please correct me if I am completely wrong and the Linux swap allocation algorithm actually moves pages between swap devices based on priority. :) > > > What they do: > Either strategy can help avoid swap thrashing, by moderating the > transition from exclusively RAM based work, to heavy swapping on disk. > In my testing, the most aggressive memory starved workloads still > result in an unresponsive system. Neither are a complete solution, > they really seem to just be moderators that kick the can down the > road. But I do think it's an improvement especially in the incidental > swap use case, where transition from memory to swap isn't noticeable. > > > Which is better? > I don't know. Seriously, that's what all of my testing as come down > to. A user won't likely notice the difference. Both dynamically > allocate memory to their "memory pools" on demand. But otherwise, they > really are two very different implementations. Regardless, Fedora > Workstation and probably even Fedora Server, should use one of them by > default out of the box. > > IoT folks are already using swap on ZRAM by default, in lieu of a disk > based swap partition. And Anaconda folks are doing the same for low > memory devices when the installer is launched. I've been using zswap > on Fedora Workstation edition on my laptop, and Fedora Server on an > Intel NUC, for maybe two years (earlier this summer I switched both of > them swap on ZRAM to compare). > > How are they different? > There are several "swap on ZRAM" implementations. The zram package in > Fedora right now is what IoT folks are using which installs a systemd > service unit to setup the ZRAM block device, mkswap on it, and then > swapon, during system startup. Simple. > > The ideal scenario is to get everyone on the same page, and so far it > looks like systemd's zram-generator, built in Rust, meets all the > requirements. That needs to be confirmed, but also right now there's a > small problem, it's not working. So we kinda need a someone familiar > with Rust and systemd to take this on, if we want to use the same > thing everywhere. > https://github.com/systemd/zram-generator/issues/4 > > Whereas zswap is setup by using boot parameters, which we could have > the installer set, contingent on a conventional swap partition being > created. > zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20 > zswap.zpool=zbud > > Zswap upstream tells me they're close to dropping the experimental > status, hopefully by the end of the summer. It might be a bit longer > before they're as confident with zpool type z3fold. Indeed, I've had issues with stability in the past when I tried the z3fold option, but no issue with the default values in the last ~year, so it really seems to be ready with the default values. > > Hackfest anyone? > > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to
Re: [Test-Announce] Fedora 31 Beta Freeze
On Fri, 2019-08-30 at 13:59 +0200, Kevin Kofler wrote: > Panu Matilainen wrote: > > On 8/29/19 8:30 PM, Kevin Fenzi wrote: > > > I'd support changing the freeze dates to be something more like 18:00UTC > > > the date they are listed. That would give people more time/be actually > > > on the date when people are awake. I'll float the idea to releng and > > > then fesco. > > > > > > > That would be awesome. > > But wouldn't 24:00/23:59 be even better than 18:00? And changing from 00:00 > to 24:00 wouldn't even require changing the actual time (as changing to > 18:00 does), just the way it is announced. I would personally still find even 24:00 confusing & would really suggest something clearly inambigous, such as 23:45 UTC or similar - that should clear any doubt of which day the freeze is part of once and for all & yet again no actualy changes in the machinery are needed. > > > It's really annoying to wake up to find a freeze reminder in your inbox > > when the freeze already happened. > > Well, that one is really a different issue, that there is an announcement > when the freeze has happened, but no reminder before it happens. Changing > the time of the freeze won't really fix this, sending one or more reminder > mails before the freeze time would. But of course there's also a tradeoff in > that the reminders should not become spam. > > Kevin Kofler > ___ > 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: [Test-Announce] Fedora 31 Beta Freeze
On Fri, 2019-08-30 at 10:08 +0300, Panu Matilainen wrote: > On 8/29/19 8:30 PM, Kevin Fenzi wrote: > > I'd support changing the freeze dates to be something more like 18:00UTC > > the date they are listed. That would give people more time/be actually > > on the date when people are awake. I'll float the idea to releng and > > then fesco. > > > > That would be awesome. > > It's really annoying to wake up to find a freeze reminder in your inbox > when the freeze already happened. At least, as I also understand 00:00 > to be the first second of a new day. We also hit this at least once with Anaconda in the past as we are basically setting an internal deadline a day before the freez date to avoid any such surprises. Just setting the freeze data on some sane time point would make think clear and we could stop doing that. :) > > - Panu - > ___ > 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: Let's revisit the FTBFS policy
On Thu, 2019-08-15 at 09:50 -0400, Gerald Henriksen wrote: > On Wed, 14 Aug 2019 11:23:53 -0500, you wrote: > > > So in summary, I guess I mostly support allowing packages which can't be > > rebuilt to stay in the distribution as long as they actually work and > > aren't causing maintenance burden elsewhere > > On the other hand, unbuildable packages could be viewed as a security > risk. > > If you can't just fix the security issue and rebuild, but instead have > to also fix the issue(s) that prevent the package from rebuilding this > could cause delays in getting a security update out. Not to mention packages with compiled code not picking up all the hardening flags introduced since they have last been build - that could be a security issue by itself. > ___ > 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: Let's revisit the FTBFS policy
On Wed, 2019-08-14 at 14:55 +0200, Vít Ondruch wrote: > Dne 14. 08. 19 v 14:23 Miro Hrončok napsal(a): > > Hello. > > > > Recently, a couple hundred packages were retired from rawhide (Fedora > > 31 at that time) based on the Fedora Failed to Build From Source > > Policy [1]. From various reactions over several threads it seems this > > policy is not ideal. This is an attempt to collect feedback and make > > the policy better serve Fedora's needs. > > > > Fedora has a policy for a long time that can be simplified as: > > > > 1. Mass rebuild for Fedora N happens by releng > > 2. Packages that fail to build get open bugzillas by releng > > 3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly > > reminders by releng > > I think it would be probably enough to stop here. Orphaned packages gets > garbage collected ATM. The step 4 was a bit unexpected for packages with > bugs in ASSIGNED state especially. > > Also the timing with mass rebuild and shifting packages from Rawhide to > F31 is unfortunate. I saw a lot of packages, which were reported as > FTBFS in BZ, then they were retired but later the bugs were moved from > Rawhide to F31, that was strange. While not directly policy related, I strongly suggest, if possible, to do a test compose with the packages removed to see how it fares & ideally run some tests (Open QA ?) on the result, to prevent avoidable breakage. Droping such big batches of packages without testing we can still produce out blocking deliverables & checking the deliverables appear to work simply seems too invasive to me. > > > Vít > > > > 4. A week before Fedora N+1 branching any packages which still have > > open Fedora N FTBFS bug are retired by releng > > > > However, 3 or 4 haven't happened since Fedora ~26, because the > > automation was not working any more for various reasons I don't > > understand. > > > > The policy was then updated by FESCo to allow anybody to step up and > > do 3. manually. > > However it needs 2 e-mails to devel directed at the package owners and > > that may be understood as a personal attack by some. > > So nobody ever did that but me (twice) IIRC (and I got my share of > > shame for that). > > > > Currently, the FTBFS retirement is problematic due to various things: > > > > 1) Bugzilla spam: Maintainers are spammed weekly by releng, some of > > them find that annoying and simply switch the bug to ASSIGNED to make > > it stop. > > > > The problem is, how do we both keep notifying the maintainers that > > action is needed and not spam them with stuff that will make them > > filter all Fedora e-mails to /dev/null. > > > > 2) Retirement out of the blue. When releng executes 4., packagers that > > stopped the bugzilla spam by setting the bug to ASSIGNED are suddenly > > surprised the package was retired. OTOH arguably they made a > > deliberate action to stop the notifications. However, most > > importantly, any dependent packages were not notified at all, which is > > **not fair**. > > > > This state is broken mostly because there is no automatic orphaning of > > packages that have NEW bugzillas and there is no orphaning at all for > > packages where the bugzillas are ASSIGNED for months. For the second > > bit, everything indicates that packagers are aware of the problem and > > will fix the bug in time before 4., but they don't and things blow up. > > > > 3) Questionable importance of the FTBFS bug. > > > > Repeatedly, it has been stated by some, the FTBFS bug is not important > > and we should not retire packages at all based on the fact that they > > "simply" fail to build. I personally don't agree with this for various > > reasons, but I can imagine a situation, where it is reasonable to say > > so and delay the problem. Obvious argument is: Better to have 1 > > package nonbuildable than have 100 packages nonisntallable. So we need > > a way to opt-out from the retirement, however simply setting the > > bugzilla to ASSIGNED is not it, because we will end up with packages > > last built 6 years ago (and I believe this is not what we want). > > > > > > I'm starting this thread to collect the ideas about how to make this > > better. > > If you see more problems, share them. I promise I'll do my best to > > make the policy work better for both Fedora and the people who make > > Fedora. > > > > [1] > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > > > > ___ > 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 --
Re: Why does anaconda-core runtime depend on python3-coverage?
- Original Message - > From: "Miro Hrončok" > To: "Development discussions related to Fedora" > > Cc: anaconda-maint-l...@redhat.com > Sent: Sunday, August 11, 2019 11:39:34 AM > Subject: Why does anaconda-core runtime depend on python3-coverage? > > Hey, I have noticed that anaconda-core has a runtime dependency on > python3-coverage. > > Is it some weird error, or does anaconda actually need a test coverage > measuring > tool at runtime? This is working as intended - Anaconda supports recording code coverage information at runtime, so it is possible to check code coverage during real installation runs, not just when running unit tests. > > Thanks, > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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: Does anybody care about gettext?
On Fri, 2019-08-09 at 15:14 +0100, Daniel P. Berrangé wrote: > On Fri, Aug 09, 2019 at 03:13:07PM +0200, Martin Kolman wrote: > > On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote: > > > On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote: > > > > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko < > > > > ignatenkobr...@fedoraproject.org> wrote: > > > > > > > > > Well, it was retired because it did not built since F30 mass rebuild… > > > > > > > > > > > > > I went ahead and built it with the testsuite disabled for now: I suppose > > > > any Proven Packager could also have done, but yeah normally it should be > > > > done by the maintainers. > > > > I admit the ball was dropped on this by various people (myself > > > > included), > > > > and sorry about that. [1] > > > > The new major upstream release was also a long time coming... > > > > > > > > But to me the deeper question is still "why are we proactively breaking > > > > the > > > > distro" in this way with package retirements by non-maintainers? > > > > > > > > Sure FTBFS is bad but there is no need to proactively remove core > > > > packages > > > > which are still working okay. > > > > I really really wish could stop this... causing more busy work and > > > > stress. > > > > > > When a FTBFS hits, we don't know whether the package is still working > > > ok or not as there are many possible reasons for the failure. > > Maybe this is something gating tests could help with ? If a package is FTBFS > > and has reasonable gating test coverage, you will know it is working. > > The gating CI is a pretty low bar right now. As CI is made stronger, > it could well actually make FTBFS *more* common, as CI is introducing > more scope for things to be classed as a failure. So be careful what > you wish for :-) > > > > Filing > > > the FTBFS BZs informs the maintainer(s) & allows them to investigate, > > > figure what has gone wrong & decide what changes are needed. Missing > > > on 2 mass rebuilds means the package is still build with F29 toolchain, > > > and thus lacking desired improvements Fedora is introducing, so this > > > has a cost for the rest of the distro. Somewhere there's a balance > > > between cost for the maintainer in work & cost for the distro in the > > > package being outdated. > > > > > > There was no acknowlegement on the BZ that anyone was actively working > > > on fixing it in 6 months. This is true for so many of the FTBFS BZs that > > > get filed. If the packages don't get orphaned after 6+ months of being > > > ignored, when would they ever be fixed ? > > > > > > Having said that, I think in the case of packages which are deps of > > > so much of the distro, it could have been useful to have a warning of > > > imminent orphaning on fedora-devel. There was a warning that orphaning > > > was starting, but no list of affected packages included. > > Maybe another job for automated tests/CI ? > > > > Before dropping a batch of packages, do a test compose without them and > > postpone > > the drop if the compose run crashes and burns. > > > > Sounds really like something doable which could save a lot of everyones > > time once in place. > > We can't carry on postponing things indefinitely though - at some point we > have to say enough, and expect a maintainer to actually do some maintaining. Sure & I totally agree with that. I'm just trying to find ways that can sound the alarm bells & prevent everyone impacting Rawhide breakage before it's too late and things need to be fixed post-mortem. An this case really looks like something that an automated check should be able to catch soon enough. :) > > Regards, > Daniel ___ 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: Does anybody care about gettext?
On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote: > On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote: > > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko < > > ignatenkobr...@fedoraproject.org> wrote: > > > > > Well, it was retired because it did not built since F30 mass rebuild… > > > > > > > I went ahead and built it with the testsuite disabled for now: I suppose > > any Proven Packager could also have done, but yeah normally it should be > > done by the maintainers. > > I admit the ball was dropped on this by various people (myself included), > > and sorry about that. [1] > > The new major upstream release was also a long time coming... > > > > But to me the deeper question is still "why are we proactively breaking the > > distro" in this way with package retirements by non-maintainers? > > > > Sure FTBFS is bad but there is no need to proactively remove core packages > > which are still working okay. > > I really really wish could stop this... causing more busy work and stress. > > When a FTBFS hits, we don't know whether the package is still working > ok or not as there are many possible reasons for the failure. Maybe this is something gating tests could help with ? If a package is FTBFS and has reasonable gating test coverage, you will know it is working. > Filing > the FTBFS BZs informs the maintainer(s) & allows them to investigate, > figure what has gone wrong & decide what changes are needed. Missing > on 2 mass rebuilds means the package is still build with F29 toolchain, > and thus lacking desired improvements Fedora is introducing, so this > has a cost for the rest of the distro. Somewhere there's a balance > between cost for the maintainer in work & cost for the distro in the > package being outdated. > > There was no acknowlegement on the BZ that anyone was actively working > on fixing it in 6 months. This is true for so many of the FTBFS BZs that > get filed. If the packages don't get orphaned after 6+ months of being > ignored, when would they ever be fixed ? > > Having said that, I think in the case of packages which are deps of > so much of the distro, it could have been useful to have a warning of > imminent orphaning on fedora-devel. There was a warning that orphaning > was starting, but no list of affected packages included. Maybe another job for automated tests/CI ? Before dropping a batch of packages, do a test compose without them and postpone the drop if the compose run crashes and burns. Sounds really like something doable which could save a lot of everyones time once in place. > > If a package list was included, *non-maintainers* might have noticed that > gettext was at risk & would massively impact the distro & could have > stepped up to help solve it, where the original maintainer drops the ball. > > Overall though, despite the disruption, orphaning has had the intended > effect of getting the long standing FTBFS problem resolved. > > Regards, > Daniel > -- > > : https://berrange.com -o-https://www.flickr.com/photos/dberrange > > :| > > : https://libvirt.org -o-https://fstop138.berrange.com > > :| > > : https://entangle-photo.org-o-https://www.instagram.com/dberrange > > :| > ___ > 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: Join the new Minimization Team
On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote: > > > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote: > > > > > I've already done some experiments with that. I used multi-stage > > > > > builds > > > > > with podman, but it's the same in principle. And yes, the sizes are > > > > > smaller. What was interesting though that some additional packages > > > > > (ones > > > > > that wouldn't appear in the images using the Fedora base image) has > > > > > been > > > > > dragged in as dependencies. Some of them are even related to > > > > > hardware. (See > > > > > the report [1] and the github repo [2].) > > > > > > > > It'd be nice to rebase this to F30 or even F31. F29 is not interesting > > > > anymore. > > > > > > > > A lot of the stuff in those images seems completely unnecessary: > > > > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks, > > > > grubby, systemd-bootchart, systemd-udev. > > > > > > > > > So that might be one area to focus on — to make sure that these "from > > > > > scratch" installations don't drag unnecessary stuff. > > > > > > > > Yep, that sounds like a good start. I suspect that F30 might be already > > > > better in this regard. > > > > > > Yes quite a bit has happened on the base image since F29, we have > > > removed quite a few things and trimmed down the latest rawhide to > > > 208MB. I am sure that can still be improved and I welcome any help on > > > that :-). > > > > I've regenerated it for f30 and f31: > > https://asamalik.fedorapeople.org/container-randomness/report.html > > > > I see the fedora:f31 image is 195 MB, woot! > > Is there a plan to add some form of CI to monitor this? It would make > it easy to monitor ups/downs over time and pick up mistakes that bloat > deps by accident. I think such CI runs would be very useful even for other "classical" deliverables. If the live image/netinst image/DVD image/installation initrd/etc. suddenly grows in size by say 20+ %, this is something that should trigger warnings & should be investigated. > ___ > 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: Intention to retire Release Notes RPM
On Mon, 2019-08-05 at 20:44 -0400, Neal Gompa wrote: > On Mon, Aug 5, 2019 at 8:43 PM Martin Kolman wrote: > > On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote: > > > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd > > > wrote: > > > > Hi All, > > > > > > > > Barring objection, I plan to retire the release notes package from > > > > Fedora on or after August 9, 2019. The package has not been updated > > > > since F28. Despite the fact that we have literally shipped a package > > > > containing the F28 release notes in F29 and F30, there have been no > > > > comments. This has been discussed with the docs team and is > > > > supported. I am not aware of any dependencies and I believe it was > > > > removed from release criteria in F29. > > > > > > > > I will run `fedpkg retire` and further request removal via > > > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages > > > > > > > > Please reply on list if you have any questions or concerns. > > > > > > > > > > Does Anaconda not support showing the release notes _anywhere_? That > > > was the original impetus for shipping it that way... > > There is currently no screen in either graphical or text interface of > > Anaconda that would show Fedora release notes. > > Aside from it being mildly depressing that there's no way to discover > the release notes for a Fedora release, I guess it's fine to retire. > We don't have any other entry points in the distribution for viewing > the release notes anymore... At least for the online release notes, aren't they somewhere on the default landing page in Firefox after initial Fedora installation ? I seem to remember something like that. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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: Intention to retire Release Notes RPM
On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote: > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd > wrote: > > Hi All, > > > > Barring objection, I plan to retire the release notes package from > > Fedora on or after August 9, 2019. The package has not been updated > > since F28. Despite the fact that we have literally shipped a package > > containing the F28 release notes in F29 and F30, there have been no > > comments. This has been discussed with the docs team and is > > supported. I am not aware of any dependencies and I believe it was > > removed from release criteria in F29. > > > > I will run `fedpkg retire` and further request removal via > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages > > > > Please reply on list if you have any questions or concerns. > > > > Does Anaconda not support showing the release notes _anywhere_? That > was the original impetus for shipping it that way... There is currently no screen in either graphical or text interface of Anaconda that would show Fedora release notes. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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: Rolling out Phase I of rawhide package gating
On Wed, 2019-07-31 at 13:34 -0700, Kevin Fenzi wrote: > On 7/31/19 12:05 PM, Nicolas Mailhot via devel wrote: > > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a > > écrit : > > > > > > > > "KF" == Kevin Fenzi writes: > > > > > > KF> * If you use metalinks, rpm signatures are just gravy on top, in > > > the > > > KF> end you are still just trusing SSL CA's. > > > > > > Only if you trust every mirror to always serve authentic content. > > > > And, just to provide another data point, we tried this month to make > > the network install iso talk to https dnf repos (a reposync of fedora > > devel x86_64, without x86 packages, because we don't have the storage > > budget to mirror 32 bit packages we don't have the use for them > > anyway). The repos themselves worked fine from installed systems. But, > > anaconda refused to use them, till they were re-exposed in plain un- > > secured http. > > Any errors? Bug filed? as long as the certs were valid/normal certs, > there should not be any reason that wouldn't work I wouldn't think. Indeed - this sounds like it could potentially be a serious regression, which should be investigated and fixed. > > kevin > > ___ > 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: adding speech installation to fedora network installation image
On Fri, 2019-06-28 at 10:50 -0500, mcatanz...@gnome.org wrote: > On Fri, Jun 28, 2019 at 10:44 AM, stan via devel > wrote: > > it doesn't make sense to open a bug. There is no gnome, and because > > adding gnome would make the image too large, it will not be added. > > Netinstall is a minimal image meant to be used from virtual consoles > > with no graphical support. > > But remember this isn't exclusive to netinstall. Only the live image > runs a GNOME session: that's the only scenario when anaconda is running > inside GNOME. > > I think it makes sense to open a bug against anaconda to ask the > anaconda developers whether text-to-speech is intended to work outside > of live images. Certainly - but I'm afraid we in the Anaconda team don't have any experience what all needs to be available (what packages should be included & what services started) to make text-to-speech work on the image. We would definitely welcome some feedback from a domain expert on this. There is also possibly an issue with size of the network installation image growing (which influences minimum RAM requirements for network installations in some cases), but I think we can look into that once we have concrete numbers available. > It seems odd to require that blind users exclusively > use live images to install Fedora. E.g. that's not how RHEL is expected > to be installed. And non-Workstation Fedora products do not have live > installers. > > Michael > > ___ > 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 31 System-Wide Change proposal: Python means Python3
On Thu, 2019-06-27 at 18:51 -0400, Stephen John Smoogen wrote: > On Thu, 27 Jun 2019 at 18:49, Neal Gompa wrote: > > > What about postponing this change to F32? I'd prefer python2 to be > > > > > retired and gone from the distro first, and the symlink and > > > > > %python_provide definition only switched then. I think that having > > > > > this middle state where python2 is available but python points to > > > > > python3 for exactly one release will be more confusing that switching > > > > > directly to the final state where python2 is gone and python simply > > > > > means python3. > > > > > > > > > > > > > I think it makes sense to make the switch before we retire, because > > > > then people's expectations are changed ahead of time and they can > > > > adapt to The Future(TM). > > > > > > Actually I think it makes more sense that F31 provides no /usr/bin/python. > Then a lot of things which depend on it can > be found and fixed since they have not adapted to the Future any other way. But it also efectively leaves a "hole" in the availability of the "python" command for a single Fedora release - that's not good user experience IMHO. > > > ___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: [HEADS UP] Unannounced soname bump of qrencode
On Tue, 2019-06-25 at 16:30 -0500, mcatanz...@gnome.org wrote: > Let's ensure this at least doesn't happen for the same library again > and again. > > In [1], change SHOULD NOT -> MUST NOT. > > Require maintainers (or provenpackagers) to fix violations like [2] > when unannounced soname bumps occur. > > (If anyone wants to write a script to detect such problems proactively, > even better.) Couldn't some of the upcoming gating initiatives catch incidental soname bumps ? I can imagine a test running on all builds, that checks for soname bump and gates the package if the soname bump is not appropriately marked up somewhere (say via some identifier in the package change log). Alternatively I guess reverse dependency tests could catch this, if systemd gating tests run & failed with the updated qrencode package, keeping the qrencode package gated. > > If we don't fix [2] the problem will just occur again. > > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files > [2] > https://src.fedoraproject.org/rpms/qrencode/blob/f48205000af5397008dbd645abb941e0dbb49636/f/qrencode.spec#_63 > > ___ > 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 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, 2019-06-19 at 10:51 +, Aleš Matěj wrote: > > At this point, the drpm library is the only blocker for zstd payloads, > > since createrepo_c needs to be able to handle zstd drpms. > > I looked into the drpm library and I should be able to add the zstd support > (and make sure it works with createrepo_c) > > Working on it now. Nice & thanks in advance! :) > ___ > 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: RFC: Multiple parallel side tags
- Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Sunday, June 9, 2019 12:20:34 AM > Subject: Re: RFC: Multiple parallel side tags > > Nicolas Mailhot via devel wrote: > > But, what is different here from the Fedora circles / Fedora modules / > > etc endeavours? Isn’t the root problem synchronizing common code paths, > > because free software means pervasive code reuse, apps ends up being > > deployed together, and un-sharing generates collisions / API > > incompatibilities / behaviour incompatibilities / config file > > incompatibilities / un-adressed security issues? > > > > What makes it possible in modules but not in side tags? > > Modules are just as broken. > > We really need to go back to just doing all the work directly in the one and > only Rawhide, no modules, side tags, or other such "features" that are just > conflicts waiting to happen. Yes, this means Rawhide will go back to being > broken for people trying to actually use it while a transition is ongoing, > but the point of Rawhide is to do development in it, NOT to be used. It > should be fully expected that Rawhide does NOT work as an actual distro, > ever. Its one and only purpose should be to coordinate the package > development so it all happens in one place. But even for package development and integration you need something that works at least a bit. If you won't get a compose for a few weeks due to the constant breakage you won't get much work done on landing your latest library rebase or integrating a new package. Not to mention trying to debug the breakage when nothing really works and more stuff is constantly landing. I thin there needs to be *some* sort of balance. > > Kevin Kofler > ___ > 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 > ___ 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 System-Wide Change proposal: Switch RPMs to zstd compression
- Original Message - > From: "Samuel Sieb" > To: devel@lists.fedoraproject.org > Sent: Thursday, May 30, 2019 11:52:55 PM > Subject: Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd > compression > > On 5/30/19 2:38 PM, Chris Murphy wrote: > > On Thu, May 30, 2019 at 3:31 PM Samuel Sieb wrote: > >> > >> On 5/30/19 1:56 PM, Chris Murphy wrote: > >>> I have no idea how deltarpm works, but if working on bit level > >>> difference on uncompressed data, I don't see why local rebuild needs > >>> to use the same compression level as the Fedora build system. If it's > >>> working on compressed data, well I'm not sure how that works, in > >>> particular if pixz is used which gives non-reproducible results. > >> > >> I was going to suggest earlier that deltarpm could use a faster > >> compression when repacking. But then I realized that the result has to > >> be be bit-exact with the original so the package signing is still intact. > > > > Package signing happens after compression? Compression is an > > optimization, in no way does it affect the validity of the payload. > > My understanding is that the signature is calculated over the compressed > payload. (I couldn't find any clear documentation on it with a quick > search.) I see that would make it simpler and somewhat quicker to > verify, but it does cause problems with things like deltarpm and > recompressing packages. I guess we can't just switch what the signature refers to as there are other tools that do this kind of verification on the compressed data, not just delta-RPM, right ? So maybe, could we attach a second signature computed on the uncompressed payload ? Delta-RPM could then use that to verify the reconstructed package & would be crazy fast, as the slow XZ compression will no longer be needed to be performed client-side to verify the signature. > ___ > 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 > ___ 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: Copr builders moved to Fedora 30, added AARCH64 support
- Original Message - > From: "Kevin Fenzi" > To: devel@lists.fedoraproject.org > Sent: Thursday, May 30, 2019 6:46:03 PM > Subject: Re: Copr builders moved to Fedora 30, added AARCH64 support > > On 5/30/19 5:00 AM, Pavel Raiskup wrote: > > Hello, fyi, > ...snip... > > > As a bonus, we now have builders (F30) for aarch64 architecture! Expect > > slightly slower queue processing there than on other architectures (only > > up 8 builders, and slightly slower boxes). Feel free to try them, and - as > > always - please report the issues :-) > ...snip... > > great news! Thanks for all your work on this... Indeed, thanks a lot! :) > > kevin > > > > ___ > 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 > ___ 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 System-Wide Change proposal: Disable Root Password Login in SSH
On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote: > On Thu, May 16, 2019 at 2:54 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd > > > > == Summary == > > The upstream OpenSSH disabled password logins for root back in 2015. > > The Fedora should follow to keep security expectation and avoid users > > surprises with this configuration. > > > > == Owner == > > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer > > * Email: jje...@redhat.com > > > > == Detailed Description == > > > > The OpenSSH server configuration contains a configuration option > > `PermitRootLogin`, which controls whether the root user is allowed to > > login using passwords or using public key authentication. The root > > login is target of most of the random or targeted attack on Linux > > systems and password is usually the weakest part. For that reason, the > > upstream OpenSSH changed this option in 2015 to `prohibit-password`, > > which still allows public-key authentication, but prevents the > > password logins. Fedora was for many practical reasons keeping the old > > configuration since then, but the difference is no longer bearable and > > might confuse users expecting the root logins will not be enabled out > > of the box. > > > > On the other hand, there is still a lot of infrastructure, installers > > and test instances that simply might depend on this configuration and > > therefore this change needs to go through the system-wide change so > > everyone is onboard. > > > > == Benefit to Fedora == > > > > This will provide more secure Fedora installations out of the box and > > prevent inadvertently accessible root logins in the wild. > > > > I'm not particularly *opposed* to this change in behavior, but in the > Fedora Server case, SSH is the primary mechanism for gaining access to > the system. If we disallow password logins for root, then many > installs will be inaccessible and users will get... grumpy. > > There aren't really any major problems for interactive installs where > the user has direct console access, so I'll disregard that case for > the moment. For kickstart-based installs, I suppose users would > normally know to put their SSH public keys in place, so that's also > less of a concern. > > The problematic case I see is the remote VNC headless install. The > installation is interactive, but there may not be a way to gain direct > access to the installed system after that. We need to ensure that the > resulting system is always accessible. Right now, the interactive > installer would allow us (even encourage us) to set up that machine > with only a root user and password, which after this Change would mean > that the system is not reachable. > > I see some possible options here, all requiring Anaconda changes: > 1) Provide a checkbox in the root user creation spoke (defaulting to > "off") to enable root password logins over SSH. Ideally with notes > about why it's recommended not to do this. > 2) Allow users to provide a public SSH key for the root user. Since > this is generally not performed in an environment where the keys can > be copy-pasted, we'd probably need to allow specifying a [tiny]URL for > an authorized_keys file. > 3) Force Anaconda to require the creation of a non-root user that is a > member of the `wheel` group, so that this user can be used to SSH in > and administer the system. Essentially, remove the root user creation > spoke as an option from the interactive install. The current policy during ineractive install is, one of (or both) must exists: - a root account that is not locked - a user in the wheel group This could be tweaked accordingly (eq. always require at least one user in the wheel group regardless of the state of the root account). > 4) Force Cockpit to be installed and available on any system that > doesn't select a non-root user at installation time. This will allow a > password-based login and allows the root user to set up their SSH keys > via the "Accounts" tab. > > I'm all for hearing what other options we may have here, but those are > the simplest ones I can think of. > ___ > 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 ___ 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: Upgrade to F30 gone wrong
On Mon, 2019-05-06 at 12:09 -0600, Chris Murphy wrote: > On Mon, May 6, 2019 at 7:25 AM Roberto Ragusa wrote: > > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > > > We found this bug before releasing, but it is not a release blocking bug > > > (the upgrade criteria just cover clean n > > > and n-1 upgrading to n+1 and this bug just happens whith continously > > > upgraded systems since fc21 or lower) > > > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > > Correct. > > "For each one of the release-blocking package sets, it must be > possible to successfully complete a direct upgrade from a fully > updated, clean default installation of each of the last two stable > Fedora releases with that package set installed." > > https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > > > Is this a precedent that n-installed is different than n-through-upgrades? > > It is completely impractical for QA to, every cycle, do a clean > install of each version of Fedora, and upgrade them in sequence to the > current pre-release version, and if any of those get stuck somewhere, > suggest it would be release blocking. It's totally untenable. As a manual test - indeed. But as a fully automated test running in a VM it could work IMHO. Grossly simplified description of such an automated test: - create a VM - install old fedora version N via kickstart - setup SSH keys for remote access in the kickstart - apply any other customizations needed - SSH to machine, run commands to upgrade to N+1, repeat until desired current version is reached Test considered successfull if it is possible to login to the upgraded system after final reboot. Test considered failed if a timeout is reached, with timeouts assigned to the individual parts (installation, prepare for upgrade, upgrade). More granular checks could be used, at the cost of more complicated test harness. This would presumably run for many hours, but if multiple runs could be done for different starting versions N in parallel, it should still be short enough to gate stuf like GO/NOGO decissions. > > And not least of which is the BIOS bootloader staleness issue, but > file systems are inherently non-deterministic data blobs. The older > they get, the more non-deterministic they become, and the more likely > problems are edge cases that require special handling. The older it > is, the less stable it is, and the more likely you'll run into > problems no one else has. It's just the way they are. > > > -- > Chris Murphy > ___ > 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 ___ 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: Upgrade to F30 gone wrong
On Mon, 2019-05-06 at 09:52 +0200, Nicolas Mailhot via devel wrote: > Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > > this can sometimes not even get found until after release. A lot of > > tests are done on pristine systems that are throw away. It's entirely > > understandable few people want to test Fedora pre-release on their > > rock solid 5+ year old Fedora system, but we actually stumbled on > > this > > in some sense by luck of alternate arch acting like a canary. > > That's not true, many boot problems are found quite early in the > process by rawhide users, but rawhide users feedback is not taken into > account by installer folks because they don't look at boot problems > before quite late in the cycle, when rawhide users have already moved > on manually, and the default solution is always to reinstall from > scratch. Actually we monitor all the bugs all the time, but's it's basically a firehose - if we get multiple bugreports with a similar problems or a bug with many "happened to me as well" comments it's much more likely it will get fixed than a serious looking but (from bugzilla queue PoV) one-off bug. That can indeed get lost in the overall noise caused by all the imaginable setups and installation methods people use, combined with stuff like hardware failures and driver issues. > > So problems are found, just not fixed > > -- > Nicolas Mailhot > > > ___ > 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 ___ 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: Is possible to use caching for livemedia-creator
On Fri, 2019-05-03 at 12:40 -0400, Neal Gompa wrote: > On Fri, May 3, 2019 at 12:28 PM Danishka Navin wrote: > > Hi, > > > > Is it possible to enable caching for livemedia-creator? > > Similar to the --cache option in livecd-creator. > > > > No. Anaconda (the installer engine) does not support caching, so > nothing built on top of it can either. What is caching in this context ? Caching the RPMs used to create the image or caching some intermediate states of image creation, so you don't have to rerun the whole process for different customizations ? > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-17 at 10:55 -0400, Steve Grubb wrote: > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote: > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote: > > > > > > > > I think all of these are good ideas. "No udev-settle" seems like a > > > > nice > > > > highlevel goal to shoot for. > > > > > > > > > > > > > > > > Another one I might add: "No stuck stop jobs" - it annoys me every > > > > single > > > > time when I reboot and something like rngd or conmon holds up my > > > > reboot > > > > for several minutes for no reason at all. > > > > > > > > > I've seen the rngd stop thing, hadn't had time to investigate it yet as > > > more urgent fires keep showing up :/ > > > > What's the story anyway for rngd? Why would userspace be better at > > providing entropy to the kernel than the kernel itself? Why do we > > enable it on desktops at all, such systems should not be > > entropy-starved. Do we need this at all now that the kernel can use > > RDRAND itself? > > The kernel uses RDRAND/SEED but it does not increment the entropy estimate > based on it. Another interesting thing is that TPM chips also have entropy > available, but the kernel does not use it. So, if you have a hardware based > entropy source such as TPM, you need rngd to move the entropy to the kernel. > And it also can mine CPU jitter to create some entropy on its own. And it > also supports the NIST beacon if you want that kind of entropy. Rngd greatly > helps system recover from low entropy situations. > > > > rngd runs as regular system service, hence what's the point of that > > altogether? I mean, it runs so late during boot, at a point where the > > entropy pool is full anyway, > > I'd really like to see it start much earlier. Any way to make that happen? > > > and we need the kernel's RNG much much earlier already (already because > > systemd assigns a uuid to each service invocation that derives from kernel > > RNG, and it does that super early). So, why run a service that is supposed > > to fill up the entropy pool at a point where we don't need it anymore, and > > if the kernel can do what it does most likely already on its own? > > The kernel cannot recover quickly when stressed for continued entropy > depletion. For example, we are required to be able to supply all guest VM's > with entropy from the host. They draw down the entropy pools which need > replenishment. The kernel is constantly starved for entropy. > > > Isn't it time to kick rngd out of the default install, in particular > > on the workstation image? Isn't keeping it around just cargo culting? > > I think you're being harsh without really looking deeply into the problem. If > we could set a sysctl to tell the kernel to use a TPM or increment entropy > estimate when RDSEED is used, I'd agree we should consider this. And to be > honest, it should be running during an anaconda or kickstart install in order > to safely setup an encrypted disk. AFAIK, we already home that in place - if there is not enough entropy when storage encryption is being setup, the installation will pause & notify the user to provide more entropy (generally by monkey-bashing keyboard keys). > Also, livecd uses are starved for entropy > and must use rngd to be responsive and safe. If you have a TPM, the best use > you'll get out of it is providing random numbers via rngd. :-) > > -Steve > > ___ > 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 ___ 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: F30 live images still contain dbus-daemon package, anaconda-core requires it ?
On Wed, 2019-04-10 at 11:07 +0200, Hans de Goede wrote: > Hi All, > > I just noticed that Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso still > contains the dbus-daemon package even though we are using dbus-broker now. > > I've tried to rpm -e it and it for some reason it is required by > anaconda-core which seems weird. This is by design - we decided to continue using dbus-deamon for the time being as dbus-broker required too much extra work on our side for basically no extra benefits. Adding Jirka Konecny who handled this on our side to CC. > > So should I file a bug against anaconda for this? I guess it is too late > to fix this for F30? > > Regards, > > Hans > ___ > 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 ___ 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: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-09 at 14:20 -0400, Neal Gompa wrote: > On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson > wrote: > > On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > > > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering > > > wrote: > > > > > > > Heya, > > > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > > crashed five times or so on me, always kicking me out of anaconda > > > > again, just because I wanted to undo something). But I don't really > > > > want to discuss that. What I do want to discuss is this: > > > > > > > > Can we maybe reduce the default set of packages a bit? In particular > > > > the following ones I really don't think should be in our default > > > > install: > > > > > > > > > > > This is not the first time this has come up and I expect it won't be the > > > last time. > > > > > > I think the main reason they stick around is that the people who want them > > > gone just show up right after a release, drop a bunch of requests, and > > > then > > > go off to their own busy work. Then they come back a release later, don't > > > see any change and either drop another email detailing things to be > > > dropped > > > OR discouraged that no-one ever listens. The things that do get changed > > > and > > > pulled out (or kept in) do so because people come in and work on scrubbing > > > out the reasons and making sure the replacements are socialized in. > > > > > > One of the things is that I am not sure any of these items > > > > > > > > > 1. multipathd. On a workstation, uh?? I obviously have no multipath > > > > > > 2. dmraid. Not quite as bad as multipathd as it is more likely to > > > > > > I think these two are here because of the blivet you mentioned earlier. > > > Advanced partitioning requires them to be there... and there do seem to be > > > people who actually do expect both of those to work on their workstations > > > when it was looked at to be removed in the past. > > > > > > I do not know if the SIlverBlue does not have them on the other hand. > > > > Basically, anything that's part of the install environment is going to > > be present after a live install. That accounts for both of the above: > > the installer supports multipath and dmraid storage devices, so the > > relevant packages are part of the install environment, so they're part > > of the lives, so they're installed by a live install. > > > > This is kind of a limitation of the live deployment mechanism. In > > theory a post-install stage could be added to strip things that were > > only needed at install time, or that we can tell aren't actually needed > > by the installed system, but this has never been done, though I recall > > it being discussed at times. > > > > I'd personally like to see some kind of post-install mechanism that > could remove unneeded things This is on the technical level doable as long as: - RPM & DNF tooling on the image works - you are only removing stuff - the "recipe" what to remove needs to be maintained somewhere and kept current > or apply updates before rebooting into > the new environment. This on the other hand is a bit harder four a couple reasons: - the current live installation does not need networking and this network is (IIRC) generally not setup, so you would need to make sure network is available at the time you attempt to do this - unlike the live image that is always the same and passes quite some testing (both automated and manual) before it is declared fit for GA, update repos can change more or less at random, creating a miriad of combinations with the live image package set, some of them potentially wrong (file conflicts, broken deps, failing scriptlets) - any errors due to updates might be harder to debug in the live environment than on installed system - note that thisa is not the same as netins as you would be always taking a frozen package set and then aplying a bunch of ever changing updates on top of it VS installing a full system from latest packages on netinst - while making the system up to date (and potentially more secure) this could make the live installation run quite a bit longer & taking ever longer the older the live image is (current live image just rsyncs the base filesystem content to the target, no need to run all the scriptlets and rpm machinery) > That's something that Ubiquity, DrakX, Calamares, > and YaST all do, and it's quite nice to have... It's all possible in principle, but both remove & update is: - extra code not useed on netinst that needs to be written, maintained & QAed - will this be the same for all lives or different per spins vs workstation - do the SIGs taking care of the Workstation live and other live spins actually want this ? > > > > > 3. atd? Do we still need that? Do we have postinst scripts that need > > > > > > 4. Similar crond. On my fresh install
Re: The state of Zanata Python client (Python 3 support)
On Thu, 2019-03-07 at 12:38 +0800, Jens-Ulrik Petersen wrote: > Thanks to Sundeep, who has already started and worked on this. > So hopefully we will have a working py3 zanata-python-client for F30+ soon. > :-) Nice & thanks in advance! :) Can definitely help testing the new version once it become available. :) > See https://github.com/zanata/zanata-python-client/pull/52 > > Jens > > > On Tue, Mar 5, 2019 at 9:56 PM Martin Kolman wrote: > > Hi, > > > > I come from the tha Anaconda installer project and we use the Python Zanata > > client to push & pull translations from > > the > > > > Fedora Zanata instance where Anaconda is being translated. As far as I > > know, there are many other projects that do > > the > > > > same (Blivet, Blivet-GUI, Storaged, etc.), even though it might not be > > readily apparent due to not directly > > depending on > > > > the python2-zanata-client package, but rather just installing it manually > > on the machine where builds are being > > created. > > > > > > > > As we all know, Python 2 is going away soon (in less than 10 months) and > > Fedora is already doing a lot of work to > > get > > > > remove as many Python 2 packages as possible. > > > > > > > > Therefore it's pretty alarming that something as important as a client for > > the official Fedora translation service > > is > > > > still Python 2-only with not even a hint of Python 3 support being worked > > on as far as I can tell. Python Zanata > > client > > > > upstream[0] has last activity ~year ago, but seems to be mostly dead since > > 2017 with no support for Python 3 in > > sight. > > > > > > > > There are also some bugs & an upstream issue inquiring about Python 3 > > support in the Zanata Python client: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1676408 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1685550 > > > > https://zanata.atlassian.net/browse/ZNTA-2791 > > > > > > > > And at the moment, the client can't even be installed on Rawhide and F30: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1676388 > > > > > > > > This has prompted me to write this email & to CC all people mentioned as > > maintainers on the package page[0]. > > > > > > > > What can be done about this ? Is Python 3 support for the Zanata Python > > client being worked on, so that we won't > > loose > > > > the package ? Or do we just wait for it to be dropped from Fedora - and > > then what ? > > > > > > > > Hopefully someone can answer these questions. :) > > > > > > > > Best Wishes > > > > Martin Kolman > > > > > > > > [0] https://github.com/zanata/zanata-python-client > > > > [1] https://src.fedoraproject.org/rpms/zanata-python-client > > > > ___ > > > > 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 > > > > > ___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 ___ 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: New guy - with a question
On Wed, 2019-03-06 at 12:01 -0500, Steven A. Falco wrote: > I'm new to this list, but I have been building packages for KiCad for a > little while now. I have a question about > rawhide; is it in a freeze right now? > > The reason I ask is that I built kicad-5.1.0-0.1.rc2.fc31 on koji back on > March 2, but I don't see it (or any other > fc31) packages on dl.fedoraproject.org in the rawhide area. I'm sure this is > perfectly normal, but I don't know what > to expect. I *think* it's due to some issues with the Rawhide compose process - packages only show up in the repositories after a successful compose and the composes have been continuously failing since before March 2, so the package is not yet in the user visible repositories. AFAIK the compose breakage is being worked on as we speak. > > If someone could please educate me or point me to documentation on how this > works, I'd appreciate it. > > Thanks, > Steve > ___ > 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 ___ 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
The state of Zanata Python client (Python 3 support)
Hi, I come from the tha Anaconda installer project and we use the Python Zanata client to push & pull translations from the Fedora Zanata instance where Anaconda is being translated. As far as I know, there are many other projects that do the same (Blivet, Blivet-GUI, Storaged, etc.), even though it might not be readily apparent due to not directly depending on the python2-zanata-client package, but rather just installing it manually on the machine where builds are being created. As we all know, Python 2 is going away soon (in less than 10 months) and Fedora is already doing a lot of work to get remove as many Python 2 packages as possible. Therefore it's pretty alarming that something as important as a client for the official Fedora translation service is still Python 2-only with not even a hint of Python 3 support being worked on as far as I can tell. Python Zanata client upstream[0] has last activity ~year ago, but seems to be mostly dead since 2017 with no support for Python 3 in sight. There are also some bugs & an upstream issue inquiring about Python 3 support in the Zanata Python client: https://bugzilla.redhat.com/show_bug.cgi?id=1676408 https://bugzilla.redhat.com/show_bug.cgi?id=1685550 https://zanata.atlassian.net/browse/ZNTA-2791 And at the moment, the client can't even be installed on Rawhide and F30: https://bugzilla.redhat.com/show_bug.cgi?id=1676388 This has prompted me to write this email & to CC all people mentioned as maintainers on the package page[0]. What can be done about this ? Is Python 3 support for the Zanata Python client being worked on, so that we won't loose the package ? Or do we just wait for it to be dropped from Fedora - and then what ? Hopefully someone can answer these questions. :) Best Wishes Martin Kolman [0] https://github.com/zanata/zanata-python-client [1] https://src.fedoraproject.org/rpms/zanata-python-client ___ 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: signing status
On Sun, 2019-02-10 at 09:02 -0800, Kevin Fenzi wrote: > On 2/10/19 8:01 AM, Sérgio Basto wrote: > > On Sat, 2019-02-09 at 10:33 -0800, Kevin Fenzi wrote: > > > On 2/9/19 2:00 AM, Miro Hrončok wrote: > > > > On 08. 02. 19 17:41, Kevin Fenzi wrote: > > > > > Just wanted to update everyone on our current status. > > > > > > > > > > ... > > > > > > > > > > I'm hopeful that it will catch back up today and we can go back > > > > > to > > > > > normal. > > > > > > > > Is this somehow relevant? > > > > > > This was caused by my fixing upgrade path on f30. > > > ie, there was an older 'dar' tagged in, so I tagged in the 'newer' > > > (by > > > NVR) one. It was signed, but apparently the written out rpms were > > > garbage collected already. > > > > > > I'm fixing these up and will fire a new rawhide after. > > > > Hi, I don't if it helps but I don't know you notice that Fedora- > > Rawhide- 20190207 [1] still running and pungi.log [2] last write was > > 2019-02-08 16:45:52 ( 2 days ago) ... > > It crashed/died and the status didn't update. > > It's not still composing, it will just be stuck in started forever. ;( > > Yesterdays failed in an anaconda traceback on the kde live, so I am > untagging the new anaconda(s) and restarting it. Is there a bug/link to the logs ? > > Signing should be all caught up as of yesterday. > > kevin > -- > > Best regards, > > > > [1] > > https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190207.n.0/ > > > > [2] > > https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190207.n.0/logs/global/pungi.global.log > > > > > > > kevin > > > -- > > > > > > https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190209.n.1/logs/global/pungi.global.log > > > > > > > > 2019-02-09 08:44:00 [ERROR ] Compose run failed: RPM(s) not found > > > > for > > > > sigs: ['CFC659B9']. Check log for details. Unsigned packages: > > > > dar-2.6.0-2.fc30 > > > > dar-debuginfo-2.6.0-2.fc30 > > > > dar-debugsource-2.6.0-2.fc30 > > > > electrum-3.3.2-3.fc30 > > > > libdar-2.6.0-2.fc30 > > > > libdar-debuginfo-2.6.0-2.fc30 > > > > libdar-devel-2.6.0-2.fc30 > > > > mysqltuner-1.7.19-2.git.59e5f40.fc30 > > > > openscap-1.3.0_alpha2-2.fc30 > > > > openscap-containers-1.3.0_alpha2-2.fc30 > > > > openscap-debuginfo-1.3.0_alpha2-2.fc30 > > > > openscap-debugsource-1.3.0_alpha2-2.fc30 > > > > openscap-devel-1.3.0_alpha2-2.fc30 > > > > openscap-engine-sce-1.3.0_alpha2-2.fc30 > > > > openscap-engine-sce-debuginfo-1.3.0_alpha2-2.fc30 > > > > openscap-engine-sce-devel-1.3.0_alpha2-2.fc30 > > > > openscap-perl-1.3.0_alpha2-2.fc30 > > > > openscap-perl-debuginfo-1.3.0_alpha2-2.fc30 > > > > openscap-python3-1.3.0_alpha2-2.fc30 > > > > openscap-scanner-1.3.0_alpha2-2.fc30 > > > > openscap-scanner-debuginfo-1.3.0_alpha2-2.fc30 > > > > openscap-utils-1.3.0_alpha2-2.fc30 > > > > openscap-utils-debuginfo-1.3.0_alpha2-2.fc30 > > > > python-oslo-messaging-8.0.0-1.fc29 > > > > python-oslo-messaging-doc-8.0.0-1.fc29 > > > > python2-oslo-messaging-8.0.0-1.fc29 > > > > python2-oslo-messaging-tests-8.0.0-1.fc29 > > > > python3-oslo-messaging-8.0.0-1.fc29 > > > > python3-oslo-messaging-tests-8.0.0-1.fc29 > > > > > > > > > > ___ > > > 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 > > ___ > 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 ___ 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: [Late] F30 System-Wide Change proposal: GCC9
On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote: > On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: > > I'm sorry, I forgot to create the every year feature request for GCC this > > year and only realized that when I've successfully built first non-scratch > > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > > has been discussed and GCC updates is something that has been done every > > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > > in 2007). > > That's all true, but the change process still helps us coordinate. There are > many new people in Fedora every year, and the more we have documented and > explicit rather than "oh yeah, this happens every year", the better. It also be of historical importance later on - it documents why and when the change was done for future generations, who might no longer remember the reasoning. There might be even cases where you find software referencing some strange other project, only to find two old Fedora change pages, one documenting the project being added to Fedora and another one documenting it being replaced by something else later on. This can be really helpful when hunting down obscure bugs or untangling reasons for past design decisions. > > It sounds like you're thinking of it a little as "bureaucratic paperwork > where we pretend that there's some debate about whether we're going to > continue doing a completely normal thing". But it's not that. It's "the > process for making sure our routine update to GCC across the whole distro > goes smoothly for everyone". > > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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 ___ 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: The "see-also" field in bugzilla
On Tue, 2019-01-15 at 09:25 -0800, Adam Williamson wrote: > On Tue, 2019-01-15 at 13:15 +0100, Emmanuel Seyman wrote: > > * Jan Synacek [15/01/2019 12:45] : > > > Unless I'm missing something, you have to use "External Trackers" on both > > > sides. With "SeeAlso", you specified it in one bugzilla and it > > > automatically showed in the referenced one. > > > > This only works if both bugs are in the same instance. There's never been > > inter-bugzilla-instances communication (thoough I've threatened the bugzilla > > deps to add this). > > But many of us were using it precisely *for* this. The removal seems to > have been based on the assumption that 'See also' was *only* being used > for referring to external bugs, but this was not in fact the case at > all. I used it exclusively for referring to other bugs within BRC which > were *relevant*, but not *duplicates* or *dependencies*. "External > Trackers" does not cover this at all. To my mind they were quite > different features. Exactly! I don't think I've wver seen see-also pointing to an external bug, it was always used to link related bugs in the Red Hat Bugzilla instance & that's how I always used it as well. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > 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 ___ 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
