Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
> This is also a valid approach. This is the first alternative proposal > which makes me say "hmm, this would also work". It is possibly even > simpler than setting the $PATH. A very small disadvantage is that the > wrapper would need to do its work every time the binary is called. > But the wrapper could be trivially implemented in shell or it could be > a compiled binary, making the wrapper very cheap. > > Hmm, what do other people think? With my computer user hat on, I would much prefer this approach. If the supposed "dozen" of relevant packages can be built with several binaries variants, then let's pack them all in the same RPM and use this mechanism. I'm sure that if successful it would extend to more packages, including packages on the critical path. I'm fine with that eventual outcome with this scheme. This way, if I ever need to take my drive out of a fried laptop and USB-boot from it on my spare laptop from 2013, then I'm not painting myself into a corner with binaries too recent for that hardware. I was happy to be able to do that last summer, and hope to still be able to in the future (but also hope not to ever need it again). And yes, Fedora (Xfce) works just fine on that decade-old laptop. For a wrapper I would be in favor of a shell script, it makes things much easier to understand as an end user, and it can be installed once, for example: > ls -l /usr/bin/cp > lrwxrwxrwx. 1 root root 26 Jan 1 00:00 /usr/bin/cp -> > /usr/libexec/uarch-exec.sh On the condition of course that the generic binary is always present, which shouldn't be difficult if all variants are in the same package in the first place. In theory there should be less moving parts, but the difference between theory and reality... My 2 cents -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned python-blockdiag et al
Greetings, Since Pillow 10 landed in f39 the following packages are FTBFS: https://src.fedoraproject.org/rpms/python-blockdiag https://src.fedoraproject.org/rpms/python-actdiag https://src.fedoraproject.org/rpms/python-nwdiag https://src.fedoraproject.org/rpms/python-seqdiag Ever since the 3.0.0 release there has been zero activity on the project and I don't have time nor interest to keep it on life support. The following packages depend on them: python-zuul-client.src python3-sphinxcontrib-actdiag. noarch python3-sphinxcontrib-blockdiag.noarch python3-sphinxcontrib-seqdiag.noarch The only reason why I am also the maintainer of python-webcolors and python-funcparserlib was blockdiag et al but since they require low activity I will keep maintaining them for now. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
On Mon, May 22, 2023 at 3:50 AM Jens-Ulrik Petersen wrote:
>
> In Fedora the bash prompt is not colored or highlighted by default.
>
> I personally find this a usability issue: it makes it hard to find previous
> commands between long outputs when scrolling back in a terminal. Of course
> in my own host I have a custom prompt, but it means whenever I am using a
> different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
> default, which I miss.
>
> Since I spent a little time thinking about and investigating this I thought I
> would write to start a discussion here.
>
> I noticed that Ubuntu has a bold green and blue prompt and NixOS has a green
> one by default, though not Archlinux or OpenSuSE I think.
>
> I think it would be nice to have a distinctive prompt by default, or at least
> a very easy way to get one permanently (ie in a single command: even if that
> were `dnf install bash-color-prompt` or running say `colorprompt` once).
>
> For example I could suggest we change the default fedora bash prompt from:
> PS1="[\u@\h \W]\\$ "
> to something like:
> PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Maybe make it ${PROMPT_COLOR:-1;32} to have a default value without
polluting the environment?
> Then the PROMPT_COLOR envvar would make it easy for users to change or
> customize their prompt coloring anyway.
> For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
> seems readable in both dark or light terminals.
>
> What do people think overall? Are there other pros and cons of a color prompt?
> Any better ideas or direction?
I also have a colored prompt and I find the default prompt annoying
when I run a live system. I don't expect terminal users to be bothered
by this, as long as it doesn't conflict with their dotfiles (for those
who maintain theirs).
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Please clarify master vs main vs rawhide branches
On Fri, Feb 5, 2021 at 9:06 PM Steven A. Falco wrote: > > On 2/5/21 1:05 PM, Jonathan Wakely wrote: > > On 05/02/21 10:08 -0500, Steven A. Falco wrote: > >> I see that the master to main conversion has happened. I'd like to know > >> the recommended way to deal with that. > >> > >> Currently, I'm doing: > >> > >> git fetch --all > >> git remote prune origin > >> git remote set-head origin -a > >> git checkout main > >> > >> The above sets origin/HEAD to rawhide > >> > >> Question 1: Is that the right set of steps, or is there a better way to > >> update my local repos? > > > > I think this is all you need: > > > > git fetch -p > > git checkout rawhide > > > > Then optionally: > > > > git branch -d master > > > >> Question 2: For the packages I maintain, should I put changes in main or > >> rawhide? Should I keep main and rawhide in sync? > > > > They're automatically in sync. Just commit to rawhide. > > Excellent! Thanks. I knew the master-to-main change was coming but I was really surprised to see a rawhide branch too when I received a new upstream bugzilla notification. I went ahead with rawhide directly and then searched for a clarification (shoot first ask questions later...) out of laziness. Being very opposed to renaming the branch to main for the reasons behind the change, I'm very happy that the opportunity to use rawhide as our main packaging branch was taken. I understand that "master" offends some, but for starters the word itself has several meanings and out of context it doesn't have to be offending. I'm also offended by the feeling of being virtually chased by a crowd with pitchforks just because I don't see a harm of having a master branch or red-black trees (with whitelist and blacklist, I can clearly see the offense). For the people who want to be welcoming to everyone, please take that side into consideration too, this kind of injunctions can also feel exhausting, shaming and yet pointless. I'm happy that we ended up with what feels like a very logical name for our main packaging branch: rawhide is self-descriptive, consistent with the other managed branches, and hopefully not going to discourage newcomers to join. Hopefully the Rawhide TV show never sees the pitchforks of the cancel crowd. Maybe it has problematic undertones too? I have never watched it and don't plan to, for me it will always be a Blues Brothers reference but next thing you know #cancelbluesbrothers..? I sympathize with the cause and support it, but I'm also baffled at how extreme things turned. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> The f33 xfce4-pulseaudio-plugin package from updates-testing can now > work with pipewire and so far so good. I'm of course lacking the features > I was using with paprefs, but will try to find in the pipewire docs whether > the same can be achieved with pipewire-specific tooling. > > My main case was the "simultaneous output devices" to not have to do > anything when I switch between bluetooth devices (plural) or physical > jack output. > > Not sure when I'll get a chance to try Ardour, I haven't used it in months. I wish I could have answered earlier but sharing my feedback now is better than never. I'd like to state first that while I enjoy pulseaudio without being very knowledgeable or proficient, I'm also very enthusiast about pipewire. I'm however feeling very uneasy with pipewire replacing pulesaudio by default. At least from my experience on the Xfce spin. First, I had to reboot my laptop to formally switch to pipewire, which was not needed to switch back to pulseaudio. I'm not ruling out pebcak on this specific point. Then I started using pipewire and pavucontrol to switch between devices, adjust volume for certain applications, configure devices. I have some problems with pulseaudio where some applications like firefox won't remember the volume I set them at (or maybe firefox forces a 100% volume whenever it starts an audio server?) and some applications like firefox will have their audio delayed the longer a video meeting lasts and some applications refuse to have their output changed (not firefox for that matter) for example via pavucontrol. With pipewire it was stated in the change description that not all of the features of the pulseaudio daemon were supported, and it was visible. I was unable to select an output device for a running application, any application. I would have to set the device I wanted as the default one and it would only take effect for future playbacks. With bluetooth devices in particular I was not always able to switch between profiles. Finally, one day after saying "so far so good" the pipewire-pulse daemon started failing. I tried to dig the following logs from journalctl but the interesting stuff seems to be gone already. Restarting the daemon didn't help, which never happened to me with pulseaudio. The pulseaudio daemon may fail me a couple times a year, but a restart of the service always solved the immediate problem. I used pipewire-pulse mainly with Firefox, Pragha and VLC (from rpmfusion). VCL didn't work at all, I had to switch its audio to ALSA to get sound. Everything else worked, modulus the problems mentioned above like changing outputs etc. In terms of devices I used built-in speakers, didn't think about trying built-in jack, but used the built-in microphone. I also had bluetooth devices in A2DP and HSP/HFP (including microphone) and a USB microphone. No problems with the devices besides not being able to route an application to or from a specific one without making it the default. Unfortunately I didn't have time to share my notes earlier, and no time either to try to understand and possibly reproduce failures. So I will keep an eye (and an ear) on piprewire but I would recommend strongly against making it the default based on what I was able to test. I would be happy to participate in a test day if (big if) I'm available to follow troubleshooting and error reporting instructions because my understanding is that this is a fast-moving project, but I'm not confident it is ready to replace pulseaudio yet. Maybe next time I'll get a chance to play with pulseaudio-jack too. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> Same explicit dependency with the xfce4-pulseaudio-plugin package. > > I'm now much closer to giving pipewire a try. The f33 xfce4-pulseaudio-plugin package from updates-testing can now work with pipewire and so far so good. I'm of course lacking the features I was using with paprefs, but will try to find in the pipewire docs whether the same can be achieved with pipewire-specific tooling. My main case was the "simultaneous output devices" to not have to do anything when I switch between bluetooth devices (plural) or physical jack output. Not sure when I'll get a chance to try Ardour, I haven't used it in months. Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
> With the help of Tomas and Jan, we've got this sorted out. Upgrade to > pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to > share the screen. It doesn't help with UX of pipewire portal dialogs but > this is something I can live with for time being. Hi, I noticed a pipewire update today and that greatly reduced the list of dependent packages getting in the way of a dnf swap: paprefs pulseaudio-module-bluetooth-freeworld (rpmfusion) pulseaudio-module-gconf pulseaudio-module-gsettings pulseaudio-module-x11 xfce4-pulseaudio-plugin The paprefs package depends on pulseaudio-module-gsettings and is not a problem, more like a collateral casualty. The non-rpmfusion pulseaudio-module-* packages seem to be part of the problem with an explicit pulseaudio dependency. They all come from the pulseaudio SRPM, but it's not clear whether the scope of the pipewire-pulseaudio package includes those modules. Playing a bit with dnf repoquery it doesn't seem to be the case, and the other pulseaudio-module-* packages I didn't install on my system seem to share the same behavior. Same explicit dependency with the xfce4-pulseaudio-plugin package. I'm now much closer to giving pipewire a try. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote: > > On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > > you have a packager's FAS password you can change the ssh key > > > associated with the account to another that you control, and the FAS > > > password is also all you need to run a build and submit it to Bodhi. > > Well, really the weakest point is email. If you have control over a fas > accounts email address you can reset the password, etc. > > > Or you add an SSH key without removing the maintainer's keys on the > > off chance that it would go unnoticed... > > fas sends email on every such change. There are situations where notifications could go unnoticed. At this point if an attacker managed to compromise an email address and add an SSH key to a fas account, the attacker might also delete the notification email promptly. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
> The weakest point in the current system is really the FAS password. If > you have a packager's FAS password you can change the ssh key > associated with the account to another that you control, and the FAS > password is also all you need to run a build and submit it to Bodhi. Or you add an SSH key without removing the maintainer's keys on the off chance that it would go unnoticed... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> It looks like resolved tries to resolve the name on two scopes (global and > one specific to some interface). This will happen if the name lookup priority > is the same for both the two scopes. Interesting, I'll search the docs. I don't recall seeing anything about priority and that's definitely something I would want to tweak. > Maybe you're hitting https://github.com/systemd/systemd/issues/17040? > One of patches being prepared is > https://github.com/systemd/systemd/pull/17535/commits/1e5eb07b34bf3ee5420ed6e290ad524f8e26eebf. I'll subscribe to this issue, it definitely looks like the main problem I'm running into. > There'll be quite a number of patches for resolved in the upcoming systemd-248 > release. It'd probably make sense to wait and test if the issue is still > reproducible with 248-rc1. I had found https://github.com/systemd/systemd/pull/17535 but didn't find anything conclusive regarding my case. Maybe I should wait until the RC1 is available to reassess the situation? Would this RC1 land in updates-testing for f33? Thanks a lot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> The answers came quickly from address1, and were allegedly cached. > > Second bug? subsequent queries will still be cache misses. Before anyone asks, I have Cache=yes in resolved.conf, I was at least up to speed with the contents of the resolved.conf(5) manual. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> That's totally on me, I read the resolved.conf(5) manual but didn't > pay attention to the systemd-resolved.service(8) manual in the SEE > ALSO section: that would have led me to resolvectl. Thanks for the > pointer, I'll do some reading, probably figure what I mis-configured > and otherwise file a BZ. I think it's a bit of both mis-configuration and (potential) bugs (plural). I have my global configuration: DNS=address1 FallbackDNS=address2 address3 And with `resolvectl status` I can see my network's configuration: DNS=192.168.something FallbackDNS=address4 With debug logs enabled I can see 4 attempts at resolving com.example: - A via address1 - via address1 - A via 192.168.something - via 192.168.something First (maybe) bug? all 4 attempts advertise cache misses. > Cache miss for net.example IN A > Cache miss for net.example IN > Cache miss for net.example IN A > Cache miss for net.example IN Working on a cache myself, my intuition would tell me to check the cache once and dispatch queries on a miss, not the other way around. Your mileage may vary, I will not argue that point. Then following the transactions by number I quickly see this: > Processing incoming packet on transaction 42493 (rcode=NXDOMAIN). > Added NXDOMAIN cache entry for net.example IN ANY 1388s > Transaction 42493 for on scope dns on */* now complete > with from network (unsigned). > Processing incoming packet on transaction 49810 (rcode=NXDOMAIN). > Added NXDOMAIN cache entry for net.example IN ANY 1388s > Transaction 49810 for on scope dns on */* now complete > with from network (unsigned). The answers came quickly from address1, and were allegedly cached. Second bug? subsequent queries will still be cache misses. Meanwhile, the two queries forwarded to 192.168.something are failing in a loop. That is expected since this host is currently down. And since this is UDP and there are retries, that's where it takes forever and turns an innocent query into a DoS for blocking clients like getaddrinfo(). Very soon, it tries to fall back to address4: > Switching to DNS server address4 for interface wlp2s0. > Cache miss for net.example IN A > Transaction 44836 for scope dns on wlp2s0/*. > Using feature level TLS+EDNS0 for transaction 44836. > Using DNS server address4 for transaction 44836. > Sending query via TCP since UDP isn't supported. > Using feature level TLS+EDNS0 for transaction 44836. Third bug? systemd-resolved seems to have wrongfully recorded that UDP didn't work for address4, where prior to that it failed for 192.168.something and address4 was attempted for the very first time at this point. It looks like during startup the primary DNS was probed and that led to the following logs in a loop: > Using degraded feature set UDP instead of UDP+EDNS0 for DNS server > 192.168.something. > Using degraded feature set TCP instead of UDP for DNS server > 192.168.something. > Using degraded feature set UDP instead of TCP for DNS server > 192.168.something. > Using degraded feature set TCP instead of UDP for DNS server > 192.168.something. > Using degraded feature set UDP instead of TCP for DNS server > 192.168.something. > Using degraded feature set TCP instead of UDP for DNS server > 192.168.something. > Using degraded feature set UDP instead of TCP for DNS server > 192.168.something. It might have resulted in a coin flip between UDP and TCP for the whole link instead of the primary DNS since neither worked. The fallback DNS for my network will also fail numerous times since only TCP is attempted and only UDP is supported, but it fails faster thanks to TCP being TCP. Eventually the lookup fails: > Transaction 44836 for on scope dns on wlp2s0/* now > complete with from none (unsigned). It's hard to tell which logs belong to what, because there doesn't seem to be a parent transaction of the 4 started at the begining. It's difficult without a correlation id to tell when exactly it finishes, but once both 44836 and its counterpart are freed, I see this: > Sent message type=error sender=n/a destination=:1.71134 path=n/a > interface=n/a member=n/a cookie=100466 reply_cookie=2 signature=s > error-name=org.freedesktop.DBus.Error.Timeout error-message=All attempts to > contact name servers or networks failed > Sent message type=method_call sender=n/a destination=org.freedesktop.DBus > path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RemoveMatch > cookie=100467 reply_cookie=0 signature=s error-name=n/a error-message=n/a I can only assume that this is the final error of my attempt to resolve a non existend domain. I think that this error triggers the second bug: since the resolution itself failed because of one missing DNS server, nothing was actually inserted in the cache. The cache entries were created, but not added. I tried to have another resolution for the same domain while the first one was busy waiting for UDP packets and it also blocked. This at least
Re: f33: systemd-resolved hang on ip query
> An unfinished dbus call should only happen when the server fails > internally and aborts the connection. If there's an error or timeout in > the query resolution, it should still terminate the connection with > some response. > > Please enable debug logs with 'resolvectl log-level debug' and do the > reproducer and show the logs. I think it'd be better to do this in BZ > though, it seems too complex for the mailing list. > Please also include rpm versions and 'resolvectl status' output. $ resolvectl query example.com example.com: 93.184.216.34 2606:2800:220:1:248:1893:25c8:1946 -- Information acquired via protocol DNS in 1.6ms. -- Data is authenticated: no $ resolvectl query com.example com.example: resolve call failed: All attempts to contact name servers or networks failed That's totally on me, I read the resolved.conf(5) manual but didn't pay attention to the systemd-resolved.service(8) manual in the SEE ALSO section: that would have led me to resolvectl. Thanks for the pointer, I'll do some reading, probably figure what I mis-configured and otherwise file a BZ. Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> Instead, we have gnome, NM, systemd-resolved, firefox et all fighting > over who and how to handle captive portal authentication. What bothers me first and foremost is that I'm not connecting through a captive portal, and somehow I can't fully trust systemd-resolved to DoTheRightThing(tm). On paper I would love to stick to systemd-resolved as my system-wide stub resolver, but now I'm considering going back to stubby, losing turnkey caching and DNSSEC among other interesting properties. I like the opinionated nature of systemd-resolved but the lack of NXDOMAIN makes several (mis)use cases unbearable, like the one described in this thread or even simple typos. There are test cases I can no longer run during $DAYJOB because of this specific opinion (although I still haven't ruled out a mistake on my end). I generally agree that there seems to be a lack of cohesion in the network stack, but have nothing constructive to propose in that area. Between the aforementioned applications and the nsswitch configuration, we are in flexibility hell :) [1] With Fedora 33 I'm trying to understand whether the regression on my system is a bug or a misconfiguration of systemd-resolved, and of course with the current worldwide situation I only have limited networks I can connect to to try different scenarios. None of them involve captive networks. I'll keep searching sporadically until I run out of spare time, at which point I'll have to locally undo this change and go back to my old setup. Dridi [1] exaggerating on purpose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> I wouldn't mind the mitigation, if only I could disable it. Does > anyone know any better? I'm still suspecting I configured something > wrong but at the same time systemd seems to have a history with > NXDOMAIN handling. I found several things, including this related to NXDOMAIN: https://github.com/systemd/systemd/pull/17535/commits/4f9bcde3c3acadffc298a53fb60f7caf9f7bee20 The plot thickens :( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
On Tue, Dec 8, 2020 at 8:34 PM Marius Schwarz wrote: > > Am 08.12.20 um 19:32 schrieb Dridi Boukelmoune: > > > >> Petr was so nice to supply a test procedure, i suggest that you use it > >> also. > > I'll try to strace stuff to to see what's going on, but I can only > > assume that this BZ is not trying to resolve ip addresses through > > systemd-resolved. > > > > > > No, they didn't . An pretimed bind-libs update, caused apps not to be > able to resolve hostnames . they crashed. > All tools which did it themself, worked "in a way". they first tried > local resolving with /etc/hosts, thats where libc crashed, which took time, > and then used root dns to do theire jobs. > > It could have the same underlying issue: not matching sys libs. I > suggest to update them. Actually, it looks like this is happening for all NXDOMAIN replies. $ dig @1.1.1.1 com.example | grep -e SERVER -e HEADER ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29880 ;; SERVER: 1.1.1.1#53(1.1.1.1) $ dig +timeout=1 com.example ; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> +timeout=1 com.example ;; global options: +cmd ;; connection timed out; no servers could be reached A quick search for systemd-resolved nxdomain yields many results with a syslog I do not see on my system: > Server returned error NXDOMAIN, mitigating potential DNS violation > DVE-2018-0001 So it looks like my initial intuition that there could be a mitigation of sorts is starting to hold water. The problem now is that clients on my system using getaddrinfo in a way that was legit until now are now being DoS'd by systemd-resolved, waiting forever for a reply that is not coming. I wouldn't mind the mitigation, if only I could disable it. Does anyone know any better? I'm still suspecting I configured something wrong but at the same time systemd seems to have a history with NXDOMAIN handling. Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: f33: systemd-resolved hang on ip query
> Can you pls get another stackframe and compare it ( it won't match 100% > as differen apps go different way) with this bugreport: It won't matter much, the next frame is in Varnish code. Here is the pstack dump of dig: > Thread 4 (Thread 0x7fee8a3e4640 (LWP 1768516) "isc-socket"): > #0 0x7fee8bf72c4e in epoll_wait () from /lib64/libc.so.6 > #1 0x7fee8c0bb4cc in watcher () from /lib64/libisc.so.1107 > #2 0x7fee8b9ae3f9 in start_thread () from /lib64/libpthread.so.0 > #3 0x7fee8bf72903 in clone () from /lib64/libc.so.6 > Thread 3 (Thread 0x7fee8abe5640 (LWP 1768515) "isc-timer"): > #0 0x7fee8b9b49e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fee8c0b3908 in isc_condition_waituntil () from > /lib64/libisc.so.1107 > #2 0x7fee8c0a525f in run.lto_priv () from /lib64/libisc.so.1107 > #3 0x7fee8b9ae3f9 in start_thread () from /lib64/libpthread.so.0 > #4 0x7fee8bf72903 in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fee8b3e6640 (LWP 1768514) "isc-worker"): > #0 0x7fee8b9b46c2 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fee8c0a22ea in run.lto_priv () from /lib64/libisc.so.1107 > #2 0x7fee8b9ae3f9 in start_thread () from /lib64/libpthread.so.0 > #3 0x7fee8bf72903 in clone () from /lib64/libc.so.6 > Thread 1 (Thread 0x7fee8b428c80 (LWP 1768513) "dig"): > #0 0x7fee8beaed8a in sigsuspend () from /lib64/libc.so.6 > #1 0x7fee8c0a62eb in isc.app_ctxrun () from /lib64/libisc.so.1107 > #2 0x7fee8c0a6f1f in isc_app_run () from /lib64/libisc.so.1107 > #3 0x55dc25b87127 in main () > https://bugzilla.redhat.com/show_bug.cgi?id=1904415 > > I see similarities there. I case of the BR, bind-libs and glic releases > did not match as it looks ( a thesis so far, no hard facts ). This looks like a different problem. > Petr was so nice to supply a test procedure, i suggest that you use it also. I'll try to strace stuff to to see what's going on, but I can only assume that this BZ is not trying to resolve ip addresses through systemd-resolved. Thanks for the pointers, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
f33: systemd-resolved hang on ip query
Greetings, I'm not sure whether I am doing something wrong so I'd rather get someone's opinion before submitting a bug report. Since the upgrade to f33 I replaced my stubby setup with systemd-resolved since it is now the default. I was OK with that change since I didn't lose functionality compared to my previous setup. But it is breaking getaddrinfo() and IP address resolution in general, and that's an annoying regression. With varnish we use getaddrinfo() for both IP addresses and domain names, optionally we may set the numeric flag but otherwise it used to work out of the box. Now if I try to resolve an IP address without the numeric flag it hangs, never receiving a response from systemd-resolved: > #0 0x7f011ed8690e in ppoll () from /lib64/libc.so.6 > #1 0x7f011c8604f6 in bus_poll.lto_priv () from /lib64/libnss_resolve.so.2 > #2 0x7f011c860f86 in sd_bus_call () from /lib64/libnss_resolve.so.2 > #3 0x7f011c85b249 in _nss_resolve_gethostbyname4_r () from > /lib64/libnss_resolve.so.2 > #4 0x7f011ed7a397 in gaih_inet.constprop () from /lib64/libc.so.6 > #5 0x7f011ed7b269 in getaddrinfo () from /lib64/libc.so.6 I checked with dig(1) and got the same behavior, so it happens regardless of the method, be it via the DBUS/libnss_resolve route or straight UDP: $ dig getfedora.org | grep -e HEADER -e SERVER ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6462 ;; SERVER: 127.0.0.53#53(127.0.0.53) $ dig +timeout=1 1.1.1.1 ; <<>> DiG 9.11.24-RedHat-9.11.24-2.fc33 <<>> +timeout=1 1.1.1.1 ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig +timeout=1 @1.1.1.1 1.1.1.1 | grep -e HEADER -e SERVER ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51616 ;; SERVER: 1.1.1.1#53(1.1.1.1) $ dig +timeout=1 @8.8.8.8 1.1.1.1 | grep -e HEADER -e SERVER ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40077 ;; SERVER: 8.8.8.8#53(8.8.8.8) I'm not getting an answer from systemd-resolved when I try to query an IP address, despite recursive resolvers replying with NXDOMAIN. This is the case for my network's resolver, not just the 1.1.1.1 and 8.8.8.8 examples I gave above. The resolved.conf(5) manual is rather short, and I'm not seeing anything obvious that could explain this behavior. At best, I could assume a DoS mitigation, refusing to resolve blatantly invalid domains, but that's breaking the automatic getaddrinfo() fallback to resolving the numeric IP. In particular, when my recursive resolver doesn't make a big deal about it, I'd rather get a timely NXDOMAIN. Any ideas? Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Should the default editor be changed from vi to nano on upgrades to Fedora 33+
On Fri, Dec 4, 2020 at 7:23 AM Dridi Boukelmoune wrote: > > > > Maybe I need to reboot my system for vim to take over again? > > > > You will at least need to logout and log back in. > > You're right, if I force a login instead of plain sudo it becomes apparent: > > $ sudo env | grep EDITOR > $ sudo su -c env | grep EDITOR > $ sudo su - -c env | grep EDITOR > EDITOR=/usr/bin/vim Actually, the package vim-default-editor is useless for sudo usage where there is no formal login happening. Regardless of whether I logged out and in my regular user session after installing it I still get nano as the root user editor. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Should the default editor be changed from vi to nano on upgrades to Fedora 33+
> > Maybe I need to reboot my system for vim to take over again? > > You will at least need to logout and log back in. You're right, if I force a login instead of plain sudo it becomes apparent: $ sudo env | grep EDITOR $ sudo su -c env | grep EDITOR $ sudo su - -c env | grep EDITOR EDITOR=/usr/bin/vim Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Should the default editor be changed from vi to nano on upgrades to Fedora 33+
> actually Vim ships vim-default-editor subpackage now, which conflicts I did install it, but that didn't seem to have an immediate effect. > with nano-default-editor via virtual provide 'system-default-editor'. It I don't have that package on my system: $ sudo dnf remove nano-default-editor No match for argument: nano-default-editor No packages marked for removal. [...] $ sudo dnf remove *-default-editor -x vim-default-editor All matches were filtered out by exclude filtering for argument: *-default-editor No packages marked for removal. > puts setting EDITOR environment variable into a file > (vim-default-editor.sh for bash, ksh, sh and zsh, vim-default-editor.csh > for tcsh and vim-default-editor.fish for fish), which is installed under > a specific directory (/etc/profile.d for bash, tcsh, sh, ksh and zsh, > /usr/share/fish/vendor_conf.d for fish). It sets EDITOR for all users. Maybe I need to reboot my system for vim to take over again? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unretiring tmuxinator
On Tue, Oct 27, 2020 at 1:35 AM Micah Shennum wrote: > > Thank you, I will be sure to compare specs. On a related note, I am of > course also open to co-maintainership. I wish I could say the same, but the reason why I'm currently using tmuxinator via my copr repository is precisely that I don't have time to do anything but the bare minimum for Fedora these days. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unretiring tmuxinator
> I will CC myself to the 2 bugzilla tickets. Ouch, I'm not a sponsor so even if I approve your review requests it won't be enough. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unretiring tmuxinator
On Sun, Oct 25, 2020 at 8:05 PM Micah Shennum wrote: > > I want to unretire tmuxinator, as it is a tool I use and I was surprised to > find it is currently retired. Searching through the mailing list, it appears > to have been retired simply due to being orphaned. When it got retired, it was also stuck on an old version that didn't work well with the tmux version of the time. > I have a copr repo, > https://copr.fedorainfracloud.org/coprs/jimtahu/tmuxinator/, which I have > personally been using. And have now created a review request > https://bugzilla.redhat.com/show_bug.cgi?id=1891335 > > The new version needs rubygem-xdg, I found a previous review that didn't make > it into the repos here https://bugzilla.redhat.com/show_bug.cgi?id=1654426, > so I created a separate request > https://bugzilla.redhat.com/show_bug.cgi?id=1891335 > > The new version also needs an update to rubygem-thor (1.0.1) which I found > has an existing ticket https://bugzilla.redhat.com/show_bug.cgi?id=1783465 > with matching pull request > https://src.fedoraproject.org/rpms/rubygem-thor/pull-request/1 I have also have a copr repository where I had to prepare the same set of packages: https://copr.fedorainfracloud.org/coprs/dridi/tmuxinator/packages/ Feel free to compare our specs, I believe I followed the ruby packaging guidelines correctly at the time. I'm not actively maintaining the packages myself because I don't have time and I'm not a ruby developer so I don't feel confident taking bug reports. But if you don't find a reviewer in a week, I will find time to review your submissions. I will CC myself to the 2 bugzilla tickets. Thanks! Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ditch RPM in favor of DPKG
> Oddly, the subject of the original post infers getting rid of rpm but > the post itself sounds like it's proposing something different and > that's why I decided to speak up. Yes, poor joke of mine, keeps hitting home though :) Ditching RPM in favor of DPKG was never meant to be a system-wide change, but simply switching Fedora's apt package from apt-rpm to regular apt. The original post was intentionally misleading because I have a particular sense of humor and frankly I didn't think that after months of completion this change would still make my day every once in a while. https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend Seriously, nothing to worry about! Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ditch RPM in favor of DPKG
> Simply put, "no". Debian and Ubuntu ".deb" packages too often don't > follow the File System Hierarchy, they may have different layouts and > package naming capitalization schemes for matching Fedora packagers > like "PyYAML", they may have overlapping pre-set uids and mismatched > group name conventions, etc., etc, and the grub intigration for new > kernels is likely to be a nightmare. It would be a full-time job for > several competent engineers to do that kind of package impedance > matching. I'm not interested in debating Debian and derivatives packaging guidelines, but I generally prefer how Fedora does things (except notably, modularity). > Just. no.aot abd deb inside a "podman" baswed container? Maybe? > But it seems not worth the pain. The whole point of this change was to allow working with DPKG tooling without leaving the comfort zone of Fedora, without forcing a VM or container indirection. And trust me on this one, I do not inflict Debian packaging on myself by choice so I'm really keen on not adding any needless step, to the point where before submitting this change I had my own homebrew apt package. As a bonus point, this change also retired apt-rpm which had been dead and unmaintained for a decade, and according to the upstream developer himself it had unfixed security issues. So apt-rpm needed to go anyway, and there was no reason not to replace it with regular apt (apt-rpm would otherwise conflict with apt). And by the way, even though I initiated this change I later lost my ability to implement it, but it's been done since f32 thanks to Neal Gompa and Sérgio Basto. I hope it clarifies what was actually implemented. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ditch RPM in favor of DPKG
On Tue, Jul 14, 2020 at 8:39 PM Dishant Pandya wrote: > > Its ok to have something that builds deb packages on Fedora, but in my > opinion RPM is far more better then debian packages. Also the Dnf and yum > package manager on Fedora are far more advanced than apt on Ubuntu and other > Debian Based system. > I have been using fedora for over 2 years now and I have never faced the > package installation issues that I faced with apt and dpkg, for whatever > unknown reasons, may be some corruption of package file, installation state > Ubuntu's package manager gets erroneous to an unrecoverable state, and I > being a normal desktop user wasn't able to restore the state, and had to > reinstall the whole OS from scratch. dpkg/apt is good when it works, but when > it breaks its unrecoverable. RPM , dnf/yum are more reliable. That poor joke of mine keeps hitting home :) Fedora remains an RPM-based system using DNF. What this change was about was really to allow using apt with deb packages. It makes it easier to pull more tools from the dpkg ecosystem like mock equivalent sbuild. Nothing to worry about. Cheers, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-minimal container and registry negative feedback
> The tag page for fedora-minimal seems to be working > https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a > link of the page that is blank ? That's the very link from which I get a blank page, and Firefox reports an empty resource (^U to view source). The developer console on the other hand gives me the following warning: > The character encoding of the HTML document was not declared. The > document will render with garbled text in some browser configurations > if the document contains characters from outside the US-ASCII range. > The character encoding of the page must be declared in the document > or in the transfer protocol. Which is logical since the content-type header doesn't give a charset and the response body is empty. Trying with curl -v I see the following response: < HTTP/2 200 < date: Tue, 30 Jun 2020 09:18:47 GMT < server: Apache < strict-transport-security: max-age=31536000; includeSubDomains; preload < x-frame-options: SAMEORIGIN < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < referrer-policy: same-origin < last-modified: Tue, 30 Jun 2020 08:25:07 GMT < etag: "0-5a948e9b307cf" < accept-ranges: bytes < content-length: 0 < apptime: D=193 < x-fedora-proxyserver: proxy10.iad2.fedoraproject.org < x-fedora-requestid: XvsDdwgZ9DOnVuTIdll6NQE < content-type: text/html Note the explicit zero content length. HTH, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-minimal container and registry negative feedback
> The blank pages are flatpaks. We are using the same registry for containers > and flatpaks and the upstream project[0] used for registry.fp.o does not > support flatpaks so the page is just blank. That can't be right, fedora-minimal is a docker/an OCI image, isn't it? > There has not been much interest in improving registry.fp.o since we looked > at moving stuff to quay.io. Noted, being warned of known gotchas would be nice regardless of where the images are hosted. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-minimal container and registry negative feedback
> > microdnf reinstall tzdata > > There's a bug about this to split out the UTC tzdata into a minimal > tzdata so terrible hacks aren't needed to slim things down. > https://bugzilla.redhat.com/show_bug.cgi?id=1722233 I'll CC myself to this bug but it doesn't look like anything will happen soon. > > By comparison dockerhub, from which I used to pull fedora images > > before moving to fedora-minimal has a nice landing page [3] and > > maybe it's also failing to document pitfalls but so far the base image > > never surprised me. > > Anything that's particularly stripped back will always be a compromise > of size vs functionality, if the stacked image did what you already > needed why change? I needed to deploy more services on a very constrained box, and this has given me enough headroom not to worry for a while. Compromise is fine, but finding out through trial is needlessly tedious. Unless of course I missed the red tape with "here be dragons", in which case it would have been totally on me and that's where I think Fedora's container registry could be improved. I'm wondering whether container pages went blank because something went missing during the recent data center move. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedora-minimal container and registry negative feedback
Greetings, I'm not sure whether the minimization effort is still going on but I wanted to report the pitfalls I ran into moving from the fedora Docker container to fedora-minimal. For starters I was surprised by the absence of DNF and I had to find by myself, I don't remember how, that MicroDNF was present instead. So my first bit of feedback concerns the container registry. It looks a bit... out of shape? I get an empty page [1] when I click on the fedora-minimal container and as of today it is by far not the only blank page. I had to keep opening more until I found one [2] with contents. Ironically a docker container for another container runtime... Even when there is content, it doesn't tell much. This is where I would hope to get the information about MicroDNF. The other and more significant pitfall I ran into was the lack of a timezone database. This manifests either as missing tz information or reports of a corrupted tz database, depending on the application I'm trying to run. Installing tzdata was a no-op, it turns out to be installed by default but some of its contents are removed post installation. Again, something trivial to fix, but it should be documented on the registry: microdnf reinstall tzdata By comparison dockerhub, from which I used to pull fedora images before moving to fedora-minimal has a nice landing page [3] and maybe it's also failing to document pitfalls but so far the base image never surprised me. Other than that, it seems to hum along, thanks! Dridi [1] https://registry.fedoraproject.org/repo/fedora-minimal/tags/ [2] https://registry.fedoraproject.org/repo/flatpak-build-base/tags/ [3] https://hub.docker.com/_/fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
> == How To Test == > Install Fedora 33 (any edition or flavor), check that modular repos > are still installed and enabled by default. > > Update to Fedora 33 (from Fedora 31 or 32), check that modular repos > are still installed and enabled by default. > > Check that you can remove the fedora-repos-modular package (e.g. via > sudo dnf remove fedora-repos-modular) and it removes the > modular repos. > > Check that you can install the fedora-repos-modular package again > (e.g. via sudo dnf install fedora-repos-modular) and it > adds the modular repos, enabled. If someone manually disables the modular repositories prior to this change, uninstalling and reinstalling the package wouldn't make any difference because the files are %config(noreplace) and would be left alone because of the modification. Unless you had plans to deal with that too. > == User Experience == > Users can disable or enable modular repos by removing or installing > fedora-repos-modular. This is significantly better UX than editing > config files. Agreed, I hope this change will follow through. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
On Tue, Jun 9, 2020 at 5:43 PM Samuel Sieb wrote: > > On 6/9/20 6:49 AM, Dridi Boukelmoune wrote: > >> Well, that's really the point. The one you're using is one of the (4? 5?) > >> other zram implementations. It seems a bit more straightforward than the > >> systemd one for sure. > > > > The zram-generator is probably more straightforward (with literally > > less layers of indirection) than what the zram package provides. I > > would assume that a generator is also the more idiomatic (and > > efficient) solution as far as systemd is concerned and I wouldn't mind > > migrating to that if it looked feature-complete and had decent > > documentation. There is no manual page[1], only a slightly confusing > > README that hints at simplicity and incompleteness. > > There's also an example conf file included that has a lot of explanation > in it. I'm aware, but the explanation doesn't tell me anything I couldn't infer from the README. Regardless, it doesn't come close to what generators shipped with systemd provide in terms of documentation. Open the man page systemd.generator and jump to the SEE ALSO section at the end. You should see reference to several generator manuals, the first one is systemd-cryptsetup-generator(8). Opening the systemd-cryptsetup-generator(8) manual and the systemd-cryptsetup@.service(8) manual mentioned in the DESCRIPTION section, I'm looking at a different level of documentation. Again, I'm well aware thanks to the README and past threads on this list that this was initially a rust experiment, apparently successful, and if anything I'd be happy to see it go that extra mile and squash important items from the TODO file, and add decent documentation. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
> Well, that's really the point. The one you're using is one of the (4? 5?) > other zram implementations. It seems a bit more straightforward than the > systemd one for sure. The zram-generator is probably more straightforward (with literally less layers of indirection) than what the zram package provides. I would assume that a generator is also the more idiomatic (and efficient) solution as far as systemd is concerned and I wouldn't mind migrating to that if it looked feature-complete and had decent documentation. There is no manual page[1], only a slightly confusing README that hints at simplicity and incompleteness. I don't see the zram-generator as systemd magic nobody knows about like you claimed. Sure, it's not implemented as a shell script and I'd need to read its source code to understand what it does given the current lack of documentation (which is a shame considering how systemd documentation is often top notch) but as far as the zram package goes I eventually run into the same situation with zramctl. If this thread's initiative converges all implementations towards zram-generator [2] and moves the project forward, then I'm in. Currently it's a mere rust experiment to me, and by that I don't want to downplay it, but it's not mature. Dridi [1] like most rust programs I have used so far [2] shouldn't it be called systemd-zram-generator? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
> Zswap sounds like an excellent idea to look into instead of zram. Not only > that, but it'd allow traditional entry in fstab to configure it, instead of > some systemd magic that nobody knows about. In that case most of everything that happens on my system is magic, I don't have comprehensive knowledge about everything I (possibly indirectly) installed. But I am a happy zram-swap user, and while I don't remember the magic incantation I do know that I found it either in release notes or before the relevant Fedora release on this list as a self-contained or system-wide change. It turns out to be even less magic than I would expect, I can easily inspect the systemd part: $ systemctl cat zram-swap.service It turns out I can break the magic spell even one step further: $ file /usr/sbin/zramstart /usr/sbin/zramstart: Bourne-Again shell script, ASCII text executable So the zram.noarch package is for the opposite of magic, and it is very composable. All I needed to do was to install the package, configure how much RAM I want to allocate for that purpose and enable one service. In my mind fstab isn't composable because it requires concurrent modifications in this scenario, and is (for my limited skills) harder to keep track of who gets to touch it. I can't compare to other solutions, but I insist as someone who is not knowledgeable in this area: following instructions when the zram.noarch package landed and peeping a bit deeper felt like the opposite of messing about with black magic. Now the difficulty for me was to remember how I set it up "back then" (I don't even remember when) but after a quick search I was able to find what I was looking for thanks to a boring straightforward name: $ systemctl | grep zram And with my findings: $ rpm -qf /lib/systemd/system/zram-swap.service zram-0.4-1.fc32.noarch Only then did I realize that it was already mentioned in this thread's first email... But well, my memory is as persistent as my zram. I was also aware of zram-generator but it doesn't look as polished in terms of integration or documentation. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: late generation of assemble code
On Tue, May 26, 2020 at 12:07 PM Jan Kratochvil wrote: > > On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote: > > The idea was to push code generation as near as possible of code execution. > > Because at execution time, you know what are the specific features of the > > CPU, and what is used to most often by the user of the program. > > In Free Software you have that already - it is called the source code. > If you want host-specific optimizations use Gentoo Linux. One could implement a DNF plugin that builds packages locally since we have source RPM repositories. > But that approach (incl. the possible LLVM JIT) has its own kind of > disadvantages such as unreproducibility of compilation-specific problems > elsewhere - no way to have meaningful build-ids, ABRT retrace server etc. Another problem is updates of large packages. Last time I had to build LibreOffice from scratch on my $DAYJOB laptop (years ago fortunately) it took 12h to complete. On the other hand that could also clear some legal issues for packages unfit for Fedora, that would be fine as a source-only distribution. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help needed to fix FTBFS (gcc-10 caused failures)
> Having -Wall and -Wextra with -Werror is the perfect footgun, since > you’re at the mercy of whatever compiler is being used. Get yourself a > manageable set of warnings and make those fatal instead. That's what we do at $DAYJOB and we are happy whenever a new gcc or clang release finds new issues. But as I suggested this should be a development/CI thing, not enabled by default for redistribution. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help needed to fix FTBFS (gcc-10 caused failures)
On Sun, Feb 23, 2020 at 3:49 PM Mukundan Ragavan wrote:
>
> Hi all,
>
> I have two packages that fail to build from source. As far as I can tell
> from the build logs, they are gcc-10 failures. The typical "extern"
> solution does not work me (or, I am not adding 'extern' at the correct
> places).
>
> Can someone give me pointers for fixing this FTBFS? Here are the links
> containing the build logs -
>
> xfce4-panel:
> https://bugzilla.redhat.com/show_bug.cgi?id=1800267
I looked briefly at xfce4-panel and I mostly saw warnings for
deprecated declarations on Gtk2 symbols, something I'd be willing to
disregard until that component is migrated to Gtk+3.
I performed a mock build with -Wall and -Werror and broke it down like this:
grep -F '[-Werror=' results_xfce4-panel/4.14.3/2.fc33/build.log |
awk '{print $NF}' |
sort |
uniq -c |
sort -rn
480 [-Werror=unused-parameter]
44 [-Werror=deprecated-declarations]
24 [-Werror=missing-field-initializers]
6 [-Werror=cast-function-type]
2 [-Werror=unused-but-set-variable]
2 [-Werror=enum-conversion]
To get all the warnings I added -k to %make_build.
The first two can be disabled safely at %configure time, but the rest
probably need to be fixed (I would personally fix everything).
It would be nice if the xfce4-panel developers had -Wall and -Wextra
turned into errors in their continuous integration or development
process. But with so many warnings, probably trivial to silence
properly, I don't have time to help produce patches.
> xfce4-sensors-plugin:
> https://bugzilla.redhat.com/show_bug.cgi?id=1800268
I didn't try to produce a comprehensive build.log locally for this
one, but the fgets warning visible in bugzilla is super legit and
should be fixed, but the manual doesn't say precisely how errors are
handled and if the null character is always added then ignoring the
return value is harmless.
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Any plans to include kotlin in Fedora
On Wed, Feb 12, 2020 at 3:33 PM Code Zombie wrote: > > Hi > > Kotlin is an open source project. Are there any plans to include its compiler > in Fedora (if not already) repositories? Currently, it is installed manually > on Linux to the best of my knowledge, but Mac systems already install it with > HomeBrew. You could ask the same about Dart, or any other language with an opensource toolchain missing from Fedora. I think it boils down to having people to do the work, which is probably not an easy task. I'm also assuming we'd need a more up-to-date gradle package, which might not be a trivial task, and I suspect that the build system is probably full of "Fedora violations" between the need for an internet access, fetching pre-built dependencies, bundling some dependencies... That's usually what discourages me when I look at that kind of stack: somewhat large and full of no-nos. So I have to assume Kotlin is missing because nobody was bold enough to take it on (or nobody on the Fedora project is interested in Kotlin). Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Wed, Feb 12, 2020 at 12:58 PM Pierre-Yves Chibon wrote: > > On Wed, Feb 12, 2020 at 11:18:33AM +, Dridi Boukelmoune wrote: > > On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon > > wrote: > > Remark: fedpkg's request-side-tag command doesn't appear in the manual > > or bash autocomplete output. > > > > Browsing the online docs I also don't know how to delete the side tag > > since the builds were superseded by the packages from the mass > > rebuild. > > For side tags you created via fedpkg, you can delete them using: fedpkg > remove-side-tag. It will remove it without merging it. > If you want to list your side-tags you can do: fedpkg list-side-tags > --user=. I imagined this would look like this. > I'm indeed not seeing these commands in the man page, but they do appear in > fedpkg --help if that helps. Indeed, I didn't try that. Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Wed, Feb 12, 2020 at 11:27 AM Miro Hrončok wrote: > > On 12. 02. 20 12:18, Dridi Boukelmoune wrote: > > Question: can I build for rawhide, in a side tag, on an arbitrary git > > branch? > > You can, but it's very confusing for others if not kept very self-contained. The timing of the on-demand side tags announcement, the upstream releases, and the mass rebuild... was unfortunate. But if next time I check the planning before creating a side tag I should be able to either work directly on master or live with the confusion :) > Be on that branch and: fedpkg --release master --target build > > And if it blocks you, you can always do: > > koji build f33 --nowait > 'git+https://src.fedoraproject.org/rpms/pkg.git#2a1eb42beca5e8b74c966348db6f5ab803b0595b' Thanks for the incantations! Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > We are pleased to announce that the work to gate rawhide packages has leveled > up! > > 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``. 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! I was immediately on board because there was a coordinated major release of 4 packages I maintain right after this announcement. Unfortunately I wasn't able to test dependent packages because the mass rebuild kicked in and in effect updated the packages automatically on Rawhide. Especially unfortunate since my bandwidth for Fedora is very limited these days. Question: can I build for rawhide, in a side tag, on an arbitrary git branch? Remark: fedpkg's request-side-tag command doesn't appear in the manual or bash autocomplete output. Browsing the online docs I also don't know how to delete the side tag since the builds were superseded by the packages from the mass rebuild. Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS
On Tue, Dec 10, 2019 at 12:28 AM John Reiser wrote: > > > If you are running into that kind of problems where > > plugins/modules/dynamically linked objects may have conflicting > > requirements > > then see dlmopen(): https://sourceware.org/glibc/wiki/LinkerNamespaces Agreed, my first response to this kind of problem was invoking the First principle and as a downstream effort align both parts of the offending application to the latest zlib, if that application is part of the package collection. Either way I wouldn't cripple end-users with -Bsymbolic. And in the same spirit of the link you shared, even with -Bsymbolic you might lose guarantees if one part of the application linked against libz.x and the other libz.y: while intra-zlib calls may not cross boundaries there is also no guarantee that the application part linking against libz.x will not in fact make calls to libz.y in an incompatible way (since SONAMEs don't match). Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS
> Not fool proof checked, but I believe this is what would happen. Usually > one wants to only LD_PRELOAD to replace some glibc symbol, for some kind > of debug, but any library where there valid usages of LD_PRELOAD should > not be linked with -Bdynamic-functions. Having experienced the frustration of dealing with -Bsymbolic first-hand I would strongly discourage adding that kind of link behavior downstream, and if it happens to come from upstream I would strongly advocate to encourage the upstream project to drop it. Once a symbol is extern (or public if you prefer) it's very inconvenient to only be able to catch *some* calls to that symbol. One real-world use case I had for some $DAYJOB was lock contention on the happy path during error checking. For the sake of the argument let's call it libcontended... For the few customers that would run into this corner case that would bring their setup to a crawl, we devised a simple hook with LD_PRELOAD to keep track of errors and force an early return in the offending error checking code to avoid taking the lock when we knew for a fact that it wouldn't return anything anyway. I voluntarily skip other gory details, but we knew that our workaround was correct because we had access to the source code of libcontended (free software, am I right?) but weren't in a position where we could repackage that library. And since that lock contention problem was solved in the next major release, we knew that at some point as customers would eventually upgrade and leave the workaround behind. All was well and fine until we ran into one supported OS where libcontended was patched downstream with -Bsymbolic enabled. The simple workaround that required us to hook two functions was no longer working and not only that, it took us a fair amount of dumbfounding time trying to figure why. We couldn't fix this corner case on that OS. I avoided name dropping on purpose, because I don't want to point fingers, but please, reconsider doing that kind of change. If an application ends up linking to several versions of zlib then something very wrong is going on. Unless that application has some kind of plugin system where two different plugins might bring two different versions of zlib (or for that matter any library). If you are running into that kind of problems where plugins/modules/dynamically linked objects may have conflicting requirements [1] then I would apply the First principle and try to patch the plugin or whatnot that links to an older version to bring it up to speed. If that's indeed a plugin system, it might be possible to isolate conflicting shared objects to some extent with a flag like RTLD_LOCAL. Please take into consideration that resorting to -Bsymbolic might break someone else's use case further downstream, and is technically an ABI breakage. Dridi [1] by the way, equally hard to debug as the case I described above ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Introducing Square 1
On Mon, Oct 28, 2019 at 8:00 PM Troy Dawson wrote: > > I would like to introduce a plan I call Square 1 [1][2] > > There are two goals to Square 1. > The first is to get, and keep, the core buildroot[3] packages, > self-hosting[4]. > The second is to get the list of core buildroot packages as small as possible. > > What are the benefits to Square 1? > More stable release and less failed builds. > If we are able to shrink binaries, faster koji builds. > Smoother initial creation of RHEL 9.[5] > > What are the milestones to get these benefits? > - Get initial list of "core binaries" > - write/find software that will find binary/source dependencies > - write/find software that will track binary/source dependencies > - write/find/setup automation that finds and tracks binary/source > dependencies, so people can easily see what has changed over time. > - work with package maintainers to trim down binary/source dependencies > -- trimming out "extra" package languages. (ex: perl for a > minor script, when everything is in python.) > -- trimming functionality and/or moving functionality to sub-packages > or separate package. > - integrate these tests into the rawhide gating system, to alert when > new dependencies have been added. > > Much of this work overlaps with the Fedora Minimization efforts.[6] > Square 1 hopes to utilize, rather than duplicate, their efforts. And > maybe some tools created for Square 1 can help the minimization > efforts. > > Thoughts? > Ideas? > Comments? > > Troy Dawson > > [1] - Square 1 is at the heart of Ring Zero > [2] - This has nothing to do with the company or software with a > similar sounding name. > [3] - The core buildroot is the packages in @buildsys-build, and > everything needed to build those packages. Hi, Going a bit off-topic here, there is currently no @buildsys-build group in EPEL8, is that on purpose or work in progress? I was curious to see how mock dealt with that and the current configuration installs individual packages by name. Thanks, Dridi > [4] - self-hosting is the ability to build all the packages on themselves. > [5] - Yep, I said it. We're already looking at RHEL 9. > [6] - https://docs.fedoraproject.org/en-US/minimization/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Trouble with install ordering and SELinux config
> Hi, > > It looks like some leftover from the past. I don't really see why it > should be there. > > This commit removes that: > > https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb > > Fixing it also in Rawhide and F31. Thanks a lot! Can it also happen for epel7 and 8? Pretty please :) Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Trouble with install ordering and SELinux config
On Sun, Nov 3, 2019 at 9:03 PM Orion Poplawski wrote:
>
> On 11/3/19 11:17 AM, Todd Zullinger wrote:
> > Dridi Boukelmoune wrote:
> >> On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
> >>>
> >>> On 11/1/19 1:47 PM, Daniel Walsh wrote:
> >>>> Flat pack should be doing a requires(post): selinux-policy-base
> >>>>
> >>>> To make sure it is installed before flatpack.
> >>>
> >>> Thanks. The proper incantation actually though seems to be:
> >>>
> >>> %{?selinux_requires}
> >>>
> >>> which contains that. See:
> >>>
> >>> https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
> >>
> >> I have used this successfully for EPEL 7 work at $DAYJOB and woud have
> >> pointed this out earlier if I hadn't fallen off the devel list for the
> >> past few weeks.
> >>
> >> Revisiting this on Fedora 31 I still see this:
> >>
> >> $ rpm --eval %selinux_requires | grep git
> >> BuildRequires: git
> >>
> >> And I can't help but wonder whether we really need git at build time
> >> as this slows down the build root creation step.
> >>
> >> Any idea from SELinux folks?
> >
> > If it does turn out to be needed, I git-core may be a better
> > requirement than git. The former avoids pulling in the perl
> > stack, among other things.
>
> Well, as it stands since selinux-policy (which defines
> %selinux_requires) is not currently in the buildroot, none of the BRs in
> %selinux_requires are actually applied.
With mock this is not a problem, but on a system where mock is not
packaged it became a problem with this workflow:
yum builddep the.spec
rpmbuild -bs the.spec
rpmbuild --rebuild the.src.rpm
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Trouble with install ordering and SELinux config
On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>
> On 11/1/19 1:47 PM, Daniel Walsh wrote:
> > Flat pack should be doing a requires(post): selinux-policy-base
> >
> > To make sure it is installed before flatpack.
>
> Thanks. The proper incantation actually though seems to be:
>
> %{?selinux_requires}
>
> which contains that. See:
>
> https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
I have used this successfully for EPEL 7 work at $DAYJOB and woud have
pointed this out earlier if I hadn't fallen off the devel list for the
past few weeks.
Revisiting this on Fedora 31 I still see this:
$ rpm --eval %selinux_requires | grep git
BuildRequires: git
And I can't help but wonder whether we really need git at build time
as this slows down the build root creation step.
Any idea from SELinux folks?
Thanks,
Dridi
> This works because the selinux-policy-base providing packages have a:
>
> Requires(pre): selinux-policy
>
> which pushes that earlier. I'm still not entirely convinced that that
> creates a contract that selinux-policy's %post script will be run before
> the flatpak-selinux's %post script, but hopefully in practice it won't
> matter.
>
> I've created https://src.fedoraproject.org/rpms/flatpak/pull-request/5
>
> > On 11/1/19 2:51 PM, Tim Zabel wrote:
> >> On Fri, 2019-11-01 at 12:02 -0600, Orion Poplawski wrote:
> >>> My F31 kickstart install is failing with:
> >>>
> >>> DNF error: Error in POSTIN scriptlet in rpm package flatpak-selinux
> >> Hmm, I've also ran into this issue of flatpak-selinux's POSTIN failing
> >> :(
> >>
> >> Just to be sure, are you building the kickstart with SELinux set to
> >> permissive? It won't work if it's in Enforcing.
> >>
> >>> This is because flapak-selinux installs a SELinux module in %post:
> >>>
> >>> %post selinux
> >>> %selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
> >>>
> >>> which sources /etc/selinux/config. It is failing because
> >>> /etc/selinux/config
> >>> does not exist and /bin/sh exits with failure (/bin/bash does not
> >>> interestingly enough).
> >>>
> >>> This was reported earlier here:
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1723118
> >> For reference, here are some other BZs that I've ran into while trying
> >> to come up with my own fixes to this issue:
> >>
> >> *https://bugzilla.redhat.com/show_bug.cgi?id=1732132
> >>
> >> *https://bugzilla.redhat.com/show_bug.cgi?id=1665643
> >>
> >>
> >>> and the suggestion made to add:
> >>>
> >>> Requires(post): selinux-policy
> >>>
> >>> since selinux-policy owns /etc/selinux/config. However, selinux-
> >>> policy
> >>> creates /etc/selinux/config in its own %post, and Requires(post) only
> >>> guarantees that the package's contents are installed, not that its
> >>> scripts are
> >>> complete.
> >>>
> >>> So, what's the best way to fix this? We need /etc/selinux/policy to
> >>> be
> >>> present and populated with SELINUXTYPE=targeted for the selinux
> >>> policy modules
> >>> to be installed properly.
> >>>
> >>> selinux-policy does:
> >>>
> >>> %post
> >>> if [ ! -s /etc/selinux/config ]; then
> >>> #
> >>> # New install so we will default to targeted policy
> >>> #
> >>> echo "
> >>> # This file controls the state of SELinux on the system.
> >>> # SELINUX= can take one of these three values:
> >>> # enforcing - SELinux security policy is enforced.
> >>> # permissive - SELinux prints warnings instead of enforcing.
> >>> # disabled - No SELinux policy is loaded.
> >>> SELINUX=enforcing
> >>> # SELINUXTYPE= can take one of these three values:
> >>> # targeted - Targeted processes are protected,
> >>> # minimum - Modification of targeted policy. Only selected
> >>> processes are
> >>> protected.
> >>> # mls - Multi Level Security protection.
> >>> SELINUXTYPE=targeted
> >>>
> >>> " > /etc/selinux/config
> >>>
> >>> ln -sf ../selinux/config /etc/sysconfig/selinux
> >>> restorecon /etc/selinux/config 2> /dev/null || :
> >>> else
> >>> . /etc/selinux/config
> >>> fi
> >>> exit 0
> >>>
> >>> But can't this be achieved simply with:
> >>>
> >>> %config(noreplace) %{_sysconfdir}/selinux/config
> >>>
> >>> New installs would get the default config, but otherwise you would
> >>> get a
> >>> .rpmnew file.
> >>>
> >>> However, I realize that nothing is particularly simple about SELinux
> >>> so there
> >>> are probably things I'm not aware of that prevent this.
> >>>
> >>> PS - the else code seems to be a no-op.
> >> Back when I was trying to find my own fixes, I managed to fix one
> >> portion of the %post selinux that was enough to solve my own problems,
> >> but this issue you're seeing is one that I wasn't able to find a fix
> >> for myself. I've love to see a resolution to this.
> >>
> >> ___
> >> devel mailing list --devel@lists.fedoraproject.org
> >> To unsubscribe send an email todevel-le...@lists.fedoraproject.org
> >> Fedora Code of
> >>
Re: proposal to allow on-demand side tags in F32+
On Wed, Oct 16, 2019 at 8:56 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Oct 16, 2019 at 10:49:29AM -0700, Kevin Fenzi wrote: > > On Wed, Oct 16, 2019 at 10:02:12AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > I submitted a Change for wrangling today, but I'm also putting it here > > > for discussion: > > > https://fedoraproject.org/wiki/Changes/OnDemandSideTags > > > > > > This is intended to be an alternative to modularity, in the sense > > > that it allows some rpms to be built against older or newer versions > > > of dependencies, but the details of this process are invisible for > > > end users, who get only normal rpms. > > > > > > The text is too long to paste here, so please take a look on the wiki. > > > I'm especially interested in feedback if this would work for *your* > > > use case and make *your* life easier. > > I think we're talking about two different things here. > The proposal is to allow the buildroot to be arranged in some specific > way, but does not say whether the stuff that is built will be *correct*. > E.g., as you say below, if the built rpm has a dependency that cannot > be satisfied, the rpm will not be installable. > > This is where gating comes in. I think rawhide gating would an excellent > way to verity that the rpm is *correct*, but it is outside of scope of > the proposal. > > But let's compare it with two scenarios: > a) I build an rpm (non-modular) right now, and I declare a Requires: > that cannot be satisfied. End result: an rpm that FTI. > b) I build an rpm as part of a module, but it requires some old version > of the library. End result: an rpm that FTI. Of course with modules the > situation is more complicated, because the module might try to bring in > the rpm with some old library, but that causes problems and is currently > forbidden, because this breaks other packages. > c) I build an rpm in a side tag with older packages pulled in. If this > results in installation-time dependencies on those packages, FTI. > > So there really isn't much difference with the proposal: the packager > still needs to make sure that the resulting rpms are installable. > The proposal makes it easy to pull older rpms during build, solving > *part* of the "too fast, too slow" problem. If older versions they are > also necessary for installation, compat package would need to be used. I'm getting increasingly worried by this recurring and very catchy "too fast too slow" phrasing. I have seen the topic of build-only dependencies come up often lately with pro-modules praising the ability to select the exact dependency tailored for their "stream" and the anti-modules blaming a lack of transparency and maybe other things I don't quite remember at this time of the day, before coffee. Being myself not happy with Fedora modularity, I'm also not a huge fan of the state of the "everything" repository, even before modularity happened. With the rise of languages like Go and Rust and their source-based tooling we end up with effectively "source binary packages" in the distribution that nobody besides other Fedora packages would use. I may have used yum in the past to grab and NodeJS dependency, but actual "node" developers will certainly use tools from the NodeJS ecosystem like npm. Your average developer doesn't sit under a waterfall and decides that they will only use dependency from Fedora repositories and impose themselves offline builds, they use whatever dependency solver their usual tool chain provides. So to me, a good middle ground would actually to start by introducing build-only dependencies. But instead of hiding them as the anti-modularity claim, have them in a in a new set of repositories: - fedora-build - fedora-build-debuginfo - fedora-build-source - updates-build - updates-build-debuginfo - updates-build-source While it may look like *more* repositories, this should actually result in less. In my suggestion, you would *move* build-only dependencies to a separate set of repositories. By having the build repositories disabled by default, it results in less metadata to process for the main `fedora` and `updates` repositories. This doesn't hide packages from end users, and only adds an extra step to access everything that has little value on a "production" system (my laptop for example). And besides amazing improvements when it comes to fetching metadata thanks to zchunk, I would also like to have in general less packages and less metadata because DNF doesn't do so well in memory-constrained environments. Once you have build-only repositories, we have new problems to deal with, like teaching the Fedora tool chain how to distinguish normal from build-only SRPMs (and I insist this should be all packages from an SRPM or nothing). But then with the *usual* compat guidelines we can have parallel-available build-only dependencies that don't need to be visible (by default) to end users. And thus, if a package maintainer faced an FTBFS caused by a dependency bump, we would
Re: Question regarding systemd service unit cleanup
On Tue, Oct 8, 2019 at 6:45 PM Ravindra Kumar via devel wrote: > > Hi, > > > > I have removed dependency on service B from service A and all references to > service B. The new package works well for fresh install (service A can be > started normally), but it does not work for upgrades from previous versions > where service A used to depend on service B (starting service A fails as it > can’t fine the service unit for service B). After upgrade from a previous > version of the package, I noticed that a symlink to service B is left under > /etc/system/system/A.service.requires dir that is causing the issue: > > # ls -l /etc/systemd/system/A.service.requires > > total 0 > > lrwxrwxrwx. 1 root root 45 Oct 8 11:10 B.service -> > /usr/lib/systemd/system/B.service > > > > Basically, some cleanup is needed to remove the requires symlink that is no > longer needed. > > > > Any advice/examples of such cleanup? systemctl daemon-reload? Isn't this handled automatically by the %systemd scriptlets? Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler wrote: > > Matthew Miller wrote: > > A key goal of the modularity project is to allow some of the cases to be > > better addressed by allowing packagers to think in terms of upstream > > changes which affect user experience separate from the Fedora release > > cycle. The default stream for a package shouldn't be updated in disruptive > > ways in shipped releases, but a new-version stream could _also_ be > > available. And at the same time, if you upgrade to a new Fedora OS release > > but still need the old behavior and the packager is still maintaining it, > > you should be able to opt in to it. > > Sure, I fully understand the theoretical benefits to be had from Modularity > (though I still think that this is much more useful for LTS distributions > such as RHEL or CentOS than for Fedora). The issue is that it all breaks > down when modules depend on each other (and they already do), because of the > unavoidable versioning conflicts (Module A requires Module C version 1, > Module B requires Module C version 2, and only one version of Module C can > be installed) that bring us Module Hell, a.k.a., RPM Hell 2.0. And this > follows directly from the specification of the Modularity feature. And it > has already happened in practice (see the libgit2 chaos). Modularity should have been opt-in until major bugs are ironed out, and maybe we would have realized in time that either it's great or it doesn't solve anything the problem it's addressing. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: This update's test gating status has been changed to, 'greenwave_failed'.
On Sun, Oct 6, 2019 at 1:12 PM Fabio Valentini wrote: > > On Sun, Oct 6, 2019, 15:07 Miro Hrončok wrote: >> >> Couple of my updates have e-mailed me $subj. Is it something to worry about? > > > I got this too for a lot of my updates, just a few hours ago. I assumed it > was caused by some kind of server glitch, maybe related to the current koji > outage. Got one as well, then got the following before I even started investi-gating: > This update's test gating status has been changed to 'ignored'. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Tue, Oct 1, 2019 at 4:09 PM Stephen Gallagher wrote: > > On Mon, Sep 23, 2019 at 10:21 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > > > == Summary == > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > > Install the packages and use e.g. turbostat to monitor the > > performance. Improvements may only be visible if the non-free > > dptfxtract package is also installed. > > > > So, looking at the license of that tool, it seems to be fine to > redistribute it unmodified... so what if we wrote a tool that would > run the `acpidump` and `acpixtract` locally, submit it to a very > simple web service and get back the config file for their system? We Privacy alert :) I'd rather we ship the database in the RPM (or a dedicated sub-package) and let the match happen locally. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Mon, Sep 23, 2019 at 2:21 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including thermald in the default install. > > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors to monitor the temperature and use the best available method > to keep the CPU in the right temperature envelop. On certain systems > this is needed to reach the maximal performance. For optimal > performance a per-model thermald configuration should be created, this > can either be done by using dptfxtract (available from rpmfusion) or > we could ship static configuration files for a set of known models. > > For a more details explanation please consult Intel's > [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. > > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install > - Optionally provide patches for thermald to be able to read hardware > specific configuration data To me this looks like a wrong order of operations: - Upstream patches to read hardware-specific configuration data - Include the thermald package in the default Workstation install Or maybe there could be a wrapper script that does the detection and generates a configuration accordingly? Carrying downstream patches without an explicit plan about upstreaming them sounds contrary to our usual upstream-first principle. > - Optionally collect hardware specific configuration data and ship it I don't understand the second optional item. > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > Install the packages and use e.g. turbostat to monitor the > performance. Improvements may only be visible if the non-free > dptfxtract package is also installed. > > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > -- > 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: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
On Sun, Sep 15, 2019 at 11:36 PM Neal Gompa wrote: > > DNF does have some broken behaviors, but this isn't one of them. I can't confirm whether this is a broken behavior but I have a strong heuristic that I suspect would make DNF appear wrong here. If I have RPM foo-1 installed that obsoletes bar, then rpm --upgrade foo-2 that doesn't obsolete anything, whether or not I can install bar-1 at this point defines brokenness in my book as DNF to me is supposed to add value (mostly networked depsolving) on top of RPM and not go against it. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F29 liberations-fonts dependencies are messed in several packages(or it's dnf)
On Fri, Sep 13, 2019 at 10:19 AM Kevin Kofler wrote: > > And finally, unlike the old YUM, DNF also processes Obsoletes from old > versions of packages in the GA repositories, so an update can no longer > safely withdraw an Obsoletes. This is a DNF issue and we need a solution in > DNF, but the DNF developers refuse to acknowledge this as a bug in DNF. In other words, a package superseded by another still gets its Obsoletes entries taken into account? I breaks the POLA as far as I'm concerned, it means the only way to undo such a mistake is first to have the mistake only happen in the updates repository, and work around it by pushing two consecutive updates with the correct Obsoletes. If the wrong Obsolete is in the base repo it's already game over... Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Hello Nicolas, On Fri, Sep 13, 2019 at 10:51 AM Nicolas Chauvet wrote: > Well... I don't qualify as a person with much free time but... > > I'm toying with kernel-longterm in a copr for .4.19 branch, and I've > enabled i686 there. > The rebuilt is a semi-automated way. > This i686 build is totally untested, please send patch along to report > any issue (or report upstream if relevant). > https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/ While I appreciate the effort, this also doesn't work in the long term (pun intended) once we start packaging or upgrading software that relies on whatever Fedora's kernel provides that isn't in 4.19 we break that piece of software... Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
> Maybe in other distros, people interested in i686 support actually do > something about it instead of talking and talking and talking about it > on mailing lists? Maybe someone with so much free time on their hands could maintain such a kernel in Fedora by applying downstream packages of such a distro. That person'd need to find a distribution that goes at least as fast Fedora when it comes to upgrading kernel packages... I very much doubt we'll find one we could rely on. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
On Wed, Sep 11, 2019 at 12:55 PM Miroslav Suchý wrote: > > Do you want to make Fedora 31 better? Please spend 1 minute of your time and > try to run [*]: > > sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the actual upgrade. My problem listing is so large it will probably account for noise here. It all boils down to the coccinelle package (coccinelle-1.0.7-5.fc30.x86_64 on my machine) generating 8 verbose problems. If you can't reproduce it I will reluctantly dump the whole thing ;) Quick peek shows that it hasn't been rebuilt yet for f31 or rawhide: https://apps.fedoraproject.org/packages/coccinelle So I assume it's only a matter of time until it is rebuilt against f31's OCaml. I also had another package causing a problem, but I removed it from my system: > Problem 2: package python3-html2text-2019.8.11-1.fc31.noarch obsoletes > python2-html2text <= 2019.8.11-1.fc31 provided by > python2-html2text-2018.1.9-2.fc31.noarch > - package rss2email-2.71-14.fc29.noarch requires python2-html2text >= 3.01, > but none of the providers can be installed > - cannot install the best update candidate for package > python2-html2text-2018.1.9-1.fc30.noarch > - python2-html2text-2018.1.9-1.fc30.noarch does not belong to a distupgrade > repository > - problem with installed package rss2email-2.71-14.fc29.noarch I removed rss2email from my installation, smells like missing py2 obsoletes. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Some Java packages in need of new permanent maintainer(s)
On Sun, Sep 8, 2019 at 6:51 PM Fabio Valentini wrote: > > Hello packagers, > > The Stewardship SIG is currently providing only bare-minimum > maintenance for some Java packages, and none of our packages depend on > them anymore. > So, we're looking for someone to take better care of them, preferably > someone who actively uses these packages or maintains a package that > depends on them. > > The packages are: > > - java-base64 > - jboss-jstl-1.2-api > - jetty-version-maven-plugin > - stringtemplate4 > - tagsoup > > Directly dependent packages of java-base64: > - Java-WebSocket > - elasticsearch > - gherkin2-java > - java-vash > - java-xmlbuilder > - jets3t > - rescu > - smack > - sshj Doesn't Java have a Base64 class in its standard library since Java 8? Apologies if I remember wrong since I'm not doing any Java anymore and haven't for years now, but the java-base64 could go away if dependent upstreams used the built-in codec. My understanding is that it would be the package maintainers' responsibility to bring this up, potentially with patches, but it is also my understanding that we are dearly missing maintainers in this area... My 2 cents > Directly dependent packages of jboss-jstl-1.2-api: > - jboss-jsf-2.1-api > - jboss-jsf-2.2-api > > Directly dependent packages of jetty-version-maven-plugin: > - jetty8 > > Directly dependent packages of stringtemplate4: > - antlr3 > - antlr4 > - eclipselink > - gs-collections > > Directly dependent packages of tagsoup: > - icedtea-web > - javadocofflinesearch > - tika > - xom > > > If you received this email directly, you're a (co-)maintainer of one > of these packages, and would probably be best qualified to take care > of the package in question. > > If you want to take one, some, or all of them off our hands, just fill > out the "package_adoption_request" template here, and we will transfer > the package to you. https://www.pagure.io/stewardship-sig/new_issue > > If nobody claims the packages within the next two weeks, we will > orphan them again, setting them on their course towards retirement in > about two months. > > Thanks, > Fabio (decathorpe), for the Stewardship SIG > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
On Tue, Aug 27, 2019 at 11:33 AM Stephen Gallagher wrote: > > On Mon, Aug 26, 2019 at 4:21 AM Miro Hrončok wrote: > > > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know for sure > > that the package should be retired, please do so now with a proper reason: > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > ... > > cloudtoserver orphan 0 weeks > > ago > > I just retired this formally. It's been dead for years. > > > compat-openssl10 orphan 2 weeks > > ago > > This one is concerning. A quick repoquery on F31 shows that it's still > required by: > > bacula2-client-0:2.4.4-33.fc30.x86_64 > dmg2img-0:1.6.7-7.fc31.x86_64 > ettercap-0:0.8.2-15.20170306git60aca9.fc31.i686 > ettercap-0:0.8.2-15.20170306git60aca9.fc31.x86_64 > freerdp1.2-0:1.2.0-13.fc31.i686 > freerdp1.2-0:1.2.0-13.fc31.x86_64 > gnome-vfs2-0:2.24.4-29.fc31.i686 > gnome-vfs2-0:2.24.4-29.fc31.x86_64 > gnome-vfs2-smb-0:2.24.4-29.fc31.x86_64 > gq-0:1.3.4-35.fc31.x86_64 > httperf-0:0.9.0-24.fc31.x86_64 > ipsec-tools-0:0.8.2-16.fc31.x86_64 > kqoauth-qt5-0:0.98-0.5.20140122git7c31a12.fc31.i686 > kqoauth-qt5-0:0.98-0.5.20140122git7c31a12.fc31.x86_64 > libwvstreams-0:4.6.1-30.fc31.i686 > libwvstreams-0:4.6.1-30.fc31.x86_64 > medusa-0:2.2-9.fc31.x86_64 > ncrack-0:0.6-3.fc31.x86_64 > netty-tcnative-0:1.1.30-14.fc31.x86_64 > opensmtpd-0:6.0.3p1-8.fc31.x86_64 > pgadmin3-0:1.22.2-15.fc31.x86_64 > python26-0:2.6.9-21.fc31.i686 > python26-0:2.6.9-21.fc31.x86_64 > sipp-0:3.5.2-2.fc31.x86_64 > skipfish-0:2.10-0.20.b.fc31.x86_64 > slowhttptest-0:1.7-8.fc31.x86_64 > snownews-0:1.5.12-22.fc31.x86_64 > sscep-0:0.6.1-10.20160525git2052ee1.fc31.x86_64 > sslscan-0:1.11.11-4.fc31.x86_64 > stud-0:0.3-17.20120814git.fc31.x86_64 Stud should be retired anyway, this code is from 7 years, upstream is officially dead and we already have a living fork (Hitch) in Fedora. https://github.com/bumptech/stud#status Possibly retired with some flavour of coordination and upgrade path to Hitch. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Better interactivity in low-memory situations
> It may be simpler to approach the question from the other side, i.e. is there > anything that actually ever needs more than 1MB of stack space? If there is, > I haven't seen it in the decade since I've been using this tweak with various > Fedora derived distributions. Any application allowing arbitrary regular expressions and/or regex input using libpcre... Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
> Well, it went through many revisions, and some of the bits are very > recent. For example, the pre-boot random seed stuff has been added in > v243, of which we only posted an -rc1 so far, > > However, the basics have been around very early on, yes. Well, from someone not versed in bios, efi and bootloaders the spec looks reasonable. Now I'm wondering why Fedora doesn't implement the interface. Is it only a matter of someone driving the change? Was there some push-back? Or is it more complicated because it needs to involve the installer and a dozen other components? Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
python-{act,block,nw,seq}diag packages build fine without pep8, I
dropped the build dependency. I'm pretty sure it used to not be the
case though.
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 Sat, Aug 10, 2019 at 10:28 PM Kevin Kofler wrote: > > Miro Hrončok wrote: > > Because if we don't, people just gonna ignore FTBFS forever. > > And this would be a problem why exactly? > > Packages built for older Fedora releases tend to run on newer Fedora > releases just fine. If the package: > * has no broken dependencies, and > * is not reported as completely broken in Bugzilla, > it should be assumed to be working by default. > > If you encounter a package that does not actually work, it is your job as a > user to report it. This can happen independently of whether the package > still compiles or not. It can even still be broken after a successful > rebuild. > > So why are we wasting packagers' time on fixing FTBFS issues (which are > typically NOT caused by their package, but by changes in dependencies such > as your python-unversioned-command change, or such as yet another > incompatible change in GCC for the sake of compliance with some obscure > subparagraph of a language standard, etc.) when not actually needed? I > actually NEED to fix the FTBFS if the package has broken dependencies or if > I need to make some other change to it. Otherwise, the FTBFS fix is just > churn that Fedora forces me to waste my time on. Hi, I understand where you are coming from, but I still disagree. I think there has been an unfair hostility towards Miro on this topic. Your package suddenly FTBFS because of dependencies or system-wide changes but the latest package build is still functional? I agree that there is no urgency to fix this, but I disagree that status quo is fine X releases later. For starters may miss out on system wide changes (and whether someone agrees with proposed changes is not the question) and in the case you made about bug reports that mandate action from the maintainer, not taking care of FTBFS timely means that once shit hits the fan you have to both solve the FTBFS situation and the user-facing bug report. So yes, it sucks when someone's package fails because someone else screwed up by not coordinating an soname bump or whatever, but it doesn't mean that we can keep the latest successful build around and let the source repository bit-rot forever because there are no bug reports. Now there's certainly room for improvement, but I don't have a solution to offer and hammering Miro because he's been (very) active lately retiring FTBFS or orphan packages (as per the normal process) is helping. Here we had an acknowledgement from a couple maintainers and someone who stepped in to help, a very positive outcome. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Xen-devel] Xen / EC2 release criteria proposal
Sorry for the top posting, "smart" phone... What about Qubes OS? Isn't their dom0 using xen, based on Fedora? Do they use Xen as packaged by Fedora? If not, couldn't they contribute whatever they do that Fedora doesn't here? It might be worth getting in touch with them. They look like a significant Xen user, on Fedora. Dridi On Sat, Aug 10, 2019, 17:33 Adam Williamson wrote: > On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote: > > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote: > > [...] > > > So it seems like this would also be a good opportunity to revisit and > > > nail down more specifically exactly what our cloud requirements are. > > > bcotton suggested that we require two sample instance types to be > > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > > like it might be worthwhile - he's promised to get back to me). > > > > > > So, for now, let me propose this as a trial balloon: we rewrite the > > > above criterion to say: > > > > > > "Release-blocking cloud disk images must be published to Amazon EC2 as > > > AMIs, and these must boot successfully and meet other relevant release > > > criteria on c5.large and t3.large instance types." > > > > Hi Adam, > > > > Thanks for bringing this up. It's good to revisit things from time to > > time as the world changes. > > Thanks for the feedback, Matt! > > > Of the two instances that you propose, neither runs on Xen. The T2 > > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor. > > That'll teach me to trust Ben...;) > > > To ensure that a Linux based AMI functions across all of the devices > > and operating modes of EC2, you need to cover: > > > > x86 platforms > > - > > * Xen domU with only PV interfaces (e.g., M3 instances) > > * Xen domU with Intel 82599 virtual functions for Enhanced Networking > > (e.g., C3 instances running in a VPC) > > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances) > > * Xen domU with NVMe local instance storage (e.g., virtualized I3 > > instances) > > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge) > > * Xen domU with four NUMA nodes (e.g., x1.32xlarge) > > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge) > > * KVM guest with consistent performance (e.g., c5.large) > > * KVM guest with burstable performance (e.g., t3.large) > > * KVM guest with local NVMe storage (e.g., c5d.large) > > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter > > (c5n.18xlarge) > > * KVM guest on AMD processors (e.g., m5a.large) > > * KVM guest on AMD processors with maximum NUMA nodes (e.g., > > m5a.24xlarge) > > * Bare metal Broadwell (i3.metal) > > * Bare metal Skylake (m5.metal) > > * Bare metal Cascade Lake (c5.metal) > > > > Arm platforms > > - > > * KVM guest on Arm with 1 CPU cluster (a1.xlarge) > > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge) > > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge) > > > > Not all of these are going to cause an image to fail to boot up to the > > point where a customer can SSH in. But a good number of these have > > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen). > > Thanks a lot for the list, it's very helpful. It's also very long, > though. :P Still, we can certainly use it as a base. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > 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://docs.fedoraproject.org/en-US/project/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: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
Hi, > That only works properly on distros that implement the boot loader > spec and the boot loader interface properly: > > https://systemd.io/BOOT_LOADER_SPECIFICATION > https://systemd.io/BOOT_LOADER_INTERFACE Thanks for the links, I looked briefly when you replied but figured I'd need a quiet setup since this is unfamiliar territory. I have finally read both documents, and they are very accessible even to someone without prior knowledge. > Unfortunately, Fedora/grub do not support either. > > (Which is a pity of course, since it also means there's no working > "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl > kexec" support). I see. Do I understand from reading the specification that it was put together during the Fedora 18 days? Do I understand from reading the boot loader interface documented that systemd supported all this in the f18 days too? Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 31, 2019 at 7:17 AM Pierre-Yves Chibon wrote: > > On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote: > >Hello, > >I'm a little late to this conversation, but is fpaste in Category 4 due > > to > >the high legal costs, or because of a lack of a maintainer? > >It would be sad to see fpaste go away because of legal reasons. Is there > > a > >better way to handle this? > > Basically both, it has a very high legal cost and the software we use is not > maintained and hasn't been for a while. Finding a new pastebin that works, > means > investigating the ecosystem, figuring out which one fits best our needs, > getting > it deployed, monitoring the project for security issues and alike. > All this considered, CPE feels that spending time on fpaste isn't the best use > of its time, especially considering the number of nicer pastebins out there. Hi, For a pastebin replacement I can point you to my colleague's filebin [1] project that is our $DAYJOB dogfood. It's written in Go and might need work to be included in Fedora. I can only promise to help as an ambassador to make sure any request or contribution from Fedora gets attention. Dridi [1] https://github.com/espebra/filebin/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Packages requiring "Python" might be broken in rawhide
> $ repoquery --repo=rawhide-source --whatrequires /usr/bin/python --exact > 0ad-0:0.0.23b-6.fc31.src > cherrytree-0:0.38.5-5.fc30.src > chocolate-doom-0:3.0.0-2.fc30.src > distro-info-0:0.18-3.fc30.src > distro-info-data-0:0.38-2.fc30.src > dtrx-0:7.1-13.fc29.src > gcc-0:9.1.1-2.fc31.src > kcov-0:35-2.fc30.src The python dependency was added to kcov in the hope of running its convoluted test suite. It won't break the build for that reason, but I would like to get it working so I will bring this upstream. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: dridi
> What is certain is that I won't have time to proverbially sit down (on > my standing desk) and track bugs down, either as a reporter or as a > maintainer. Same thing for my stalled review requests I was hoping to > get done much sooner. I may be back on track in a couple weeks actually, I may have been too pessimistic in the first place :] Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: python2->python3 mass rebuild and auto tools
> Anyways, there are easy ways in Autotools to archieve this, and I can
> craft a patch, if you guide me to the canonical upstream of audit.
And even if you don't patch it, the need to export [1] a PYTHON
variable in the environment is exactly what should be done.
The tragedy of autotools is that people end up expecting everything to
be handled _auto_matically. Where we sit downstream we should never
ever need to worry about configure.ac files coming from upstream. One
of the goals of autotools is to allow upstream to redistribute a
bootstrapped archive, one that has already gone through the various
auto* utilities (and the controversial libtool) with a simple `make
dist`.
In the case of this package, you already _don't_ run the configure
script vanilla:
%configure --sbindir=/sbin --libdir=/%{_lib} --with-python=yes \
--with-python3=yes \
--enable-gssapi-krb5=yes --with-arm --with-aarch64 \
--with-libcap-ng=yes --enable-zos-remote \
--enable-systemd
And I assume you don't complain that audit's configure script doesn't
figure automagically that on Fedora it should --enable or build --with
exactly that configuration. Upstream gives you a choice regarding what
you may take from the build.
Auto-detection works the same, if it doesn't yield the results you
need downstream, you have an escape hatch:
./configure --help
[...]
Some influential environment variables:
[...]
PYTHON the Python interpreter
[...]
There is nothing worrying about having to help the configure script,
in some cases you have to to ensure a reproducible build.
It does suck when you need to apply a similar tweak everywhere, but it
could be something handled by the %configure macro if it starts
showing up in more than just the audit package, or simply as part of
the python-means-python3 change (except that here it's the other way
around, which we probably don't want).
Cheers,
Dridi
[1] preferred way for autoconf would be %configure ... PYTHON=python2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: dridi
Hi, > By following the process, all of your packages will get orphaned. > If that is your desire, shall we do it directly? That part, please don't :) The reason why I'm encouraging people to become co-maintainers is because I won't be unavailable forever, but longer than the orphan grace period. If we do that they will be retired before I come back and since I actively use most of the packages I maintain I'd rather not go through a re-review. Maybe I'm underestimating my availability, and maybe I will manage to handle ACL requests myself... My most active package is already co-maintained by Jens Peterson, and if it weren't for a handful of Python packages I'd say most of the time the rest is only touched for mass rebuilds and occasional (straightforward) upstream releases. I do carry some patches, most (if not all) of them were upstreamed and what's left is pending a release upstream. Low maintenance these days... What is certain is that I won't have time to proverbially sit down (on my standing desk) and track bugs down, either as a reporter or as a maintainer. Same thing for my stalled review requests I was hoping to get done much sooner. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Non-responsive maintainer: dridi
Greetings fellow package maintainers, I'm starting the non-responsive maintainer process on myself because the time I can dedicate to Fedora will significantly drop for the next 3 months. It wasn't that much to begin with... I don't think I will be able to follow up on anything, especially bugzillas, at best I plan to keep on reading what's going on on the devel list. All my packages are rather low traffic and don't require much maintenance. If you wish to become a co-maintainer, please bypass me and follow the non-responsive maintainer process. I'm not going away from Fedora, it will remain my main OS, and I plan to stick around and revisit my involvement in a couple months. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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, Jul 15, 2019 at 7:58 AM Vitaly Zaitsev via devel wrote: > > Hello, Dridi Boukelmoune. > > Mon, 15 Jul 2019 06:59:33 + you wrote: > > > game that cannot move to 64bit support because it's dragging binaries > > for which it doesn't have source code. > > Wine64 can still emulate 32-bit WinPE executables. Emulate as in not run natively even though the hardware might be able to? Thanks for the tip anyway, it might be worth giving a try. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
> I don't think we can drop multilib until at least steam/wine are ready > for it at least. Will they ever be though? Thanks to Wine I can run an open source game that cannot move to 64bit support because it's dragging binaries for which it doesn't have source code. I reverse-engineered one of the DLLs myself and helped them get closer to their goal, and it took months, but I still don't know when the authors will finally manage the transition without sacrificing features. I can't imagine how someone would deal with 32bit Wine support going away for a completely closed source game or application for which they may have purchased a license years ago that will only run on Wine or Windows. I'm certainly not opting for the latter... Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Self-Contained Change proposal: Limit Scriptlet Usage of core packages
> I disagree about the user/group creation, at least the way it's being > planned in here. > > The way openSUSE solved this problem probably makes sense for dealing > with issues like needing the users+groups to exist before package is > being installed: > > 1. sysusers are in their own (sub)packages, dep generators generate user() > and group() Provides > 2. main package can require those user() and group() names, forcing > the sysusers to be installed first > 3. Transaction ordering deals with the rest of the problem :) Sounds like something similar debuginfo packages where we don't have to do anything besides compiling with debug symbols, except that here we'd need to either install the sysusers file if it comes from upstream or create one, and I assume everything else would be handled automatically? I would be on board for such a change, as I would like to do that for the varnish package (ideally on el7 too if that can be ported over there). I have strongly considered doing that manually since this needs to be done beforehand, and in my specific case (wearing my upstream hat) we would be fine with the user short-circuiting the sysusers file prior to installation as the users/group we recommend are optional and /usr/*bin/varnish* tools can also work with other arbitrary credentials of the sysadmin's discretion to drop privileges. (Please keep the latter in mind for other packages, they may break if someone drops a different sysusers file in /etc, but ten they probably asked for it.) Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
> Also, macOS is switching from bash to zsh (?) I don't know why. > https://support.apple.com/en-ca/HT208050 Probably because they stuck to an old version of bash to avoid the GPLv3 re-licensing, or so I've been told. Maybe the version of bash they use is going EOL as well. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Please update form pep8 to pycodestyle
On Wed, Jun 26, 2019 at 3:06 PM José Abílio Matos wrote: > > On Wednesday, 26 June 2019 13.03.44 WEST Vít Ondruch wrote: > > I agree with the "# Stop linting code in %%check and measuring coverage, > > this is upstream's business" reasoning. Shouldn't we mention that > > somewhere in guidelines? > > > > > > Vít > > The funny part is that this consideration applies to more than just python. In > this case I am thinking as an example in R packages that suffer from the same > malady. :-) Well, if the linter brings actual value (shellcheck for example does) and maintainers use that to locally patch whatever fails linting and sends the patches upstream bragging that this was First discovered in Rawhide because we have the latest release of the linter, I see no problem with that :p Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Any new restriction in Koji added recently in Rawhide?
> Could this ugly hack work?
>
> %{endif __with_rebar3}
>
> Assuming the %endif macro would ignore any parameters.
This won't work... But RPM could "learn" this syntax and let spec
writers add that kind of comment inside the macro.
A bit far-fetched, I won t disagree :)
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Any new restriction in Koji added recently in Rawhide?
> > Not sure if I understand. Are you saying that
> >
> >%endif%{discard:__with_rebar3}
> >
> > will not work either?
>
> Yes, that's what I'm saying. Or rather, you'd get the warning with that
> too. It all *behaves* exactly the same as before, so it continues to "work".
Could this ugly hack work?
%{endif __with_rebar3}
Assuming the %endif macro would ignore any parameters.
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 vs. libgit
On Mon, Jun 17, 2019 at 8:59 PM Terry Bowling wrote: > > Oh, I forgot to add that related to parallel installations, when conflicting > modules are desired, generally containerization or virtualization is the > recommended solution. However, this is from the RHEL user persona > perspective. We realize that is a very different user persona from say a > developer working in Fedora Rawhide. Every once in a while someone will accuse Red Hat of using Fedora as a test bed for RHEL, and someone else will insist that despite Red Hat being a (the?) major sponsor of the project it is still a community project. But that kind of explanation can only reinforce the test bed idea. I don't want to prevent Red Hat from serving their customers better, otherwise I would be shooting myself in the foot considering that for $DAYJOB I deal with customers running RHEL or derivatives. And one reason why I chose Fedora (over say, Ubuntu) for my personal use is because I felt more comfortable on RHEL systems than on Debian derivatives on previous jobs, and looking at other distribution models (Gentoo, Slackware, Arch...) I didn't find enough appeal. But if Fedora is not a test bed, and yet RHEL is downstream of Fedora, RHEL could have implemented its modularity without forcing it onto Fedora. And the worst part for me is that it was obvious from the start that we would run into that kind of problems because Fedora has a strong anti-bundling policy (which I personally approve) and "leaf" packages eventually indirectly conflict because of dependencies. I don't know RHEL policies, but Red Hat could certainly allow some form of bundling to avoid module conflicts and not drag Fedora into a modularity "mess" that is incompatible with its Four principles. But I guess that ship has sailed and now it's too late... Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 vs. libgit
> > Thanks to soname, library are perfect use case for parallel installation > > of multiple versions. > > +1 > > We could go a step further and extend rpm and dnf to support multiple > versions of same named packages for installation. This is doable but Both rpm and dnf can do that, try running `rpm -qa kernel`. As long as same-name packages don't conflict it's ok. > not necessarily trivial. Upgrades would need a way to specify what > package NVR they are upgrading (doable) and dependencies, requires, and > obsoletes would need to be reviewed to ensure you don't wipe out a > version you want installed. Plus more. Solvable and the same end > result for users, just a different approach. The problem with parallel installation is that dnf (formerly yum) only offers a narrow option for parallel installation. But probably a plugin could do that. The real problem is so-called modularity. I support the goal of modularity, but not its vague name and neither its implementation from what I could grok. As soon as two "leaf" modules share a dependency it falls apart as this thread starting point shows. Parallel-installable libraries, whether or not packages are named following Debian's convention, are also not a problem. Either this is explicitly supported by the build system (e.g. usually autotools and pkg-config would) or otherwise it can be "forcefully enabled" in the RPM spec. And that doesn't prevent us from having parallel-installable devel packages too, but someone will likely have to give up the global /usr/include namespace (or different stack equivalent). The problem that fails every attempt at squaring dependencies is their quadratic nature. In the case of lagging upstreams, the First principle mandates that we help dependent upstream move forward. In the legitimate case of multiple living "streams" (another word I find too vague) where N streams may be supported simultaneously, then parallel installation is a better solution, not just availability. But but but... Not everyone can take the single global namespace at once and nobody wants to run gccX.Y on Fedora or RHEL, and update-alternatives (or insert any other attempt) doesn't bring the convenience of running gcc and expect TheRightThing(tm) out of the box. At best it delays the problems. Dridi ___ 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: How to maintain python-urwid orphaned package
On Thu, May 23, 2019 at 3:22 PM Tomas Tomecek wrote: > > This is still on my backlog, ideally, to also add python2 support and > add it to epel7. Miro was so nice and fixed the package in rawhide so > it works with python3. Why add python2 support? epel7 has python3 support nowadays. > Feel free to open pull requests via > https://src.fedoraproject.org/rpms/python-urwid, all the help is very > welcome! Feel free to drop me an e-mail (or open a bugzilla) for the > work you'd like to do. > > > Tomas > > On Tue, May 21, 2019 at 6:42 PM Miro Hrončok wrote: > > > > On 21. 05. 19 18:23, Globe Trotter via devel wrote: > > > I am interested in supporting the python-urwid package. How do I do > > > this?I am > > > able to compile without errors and create the rpm locally. I have an FAS > > > account > > > called aarem. > > > > Tomáš is already the maintainer. > > > > https://pagure.io/releng/issue/8369 > > > > Talk to him if you want to offer help. > > > > -- > > 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://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
Signing key for f31?
Hi, I was browsing getfedora.org looking for the f31 PGP key that DNF is currently prompting me to accept or reject. I found that the old URL [1] is gone and doesn't redirect to the new one [2] that currently shows keys up to f30. Is there a reliable location where I can verify the f31 key today? I tried to browse the Rawhide guide but couldn't find the key fingerprints. Dridi [1] https://getfedora.org/en/keys/ [2] https://getfedora.org/en/security/ ___ 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: how to create Makefile
On Thu, May 16, 2019 at 9:49 AM Martin Gansser wrote: > > Hi, > > I'm trying to compile the program olive with the help of a spec file [1], > which unfortunately fails when creating the Makefile. > Have somebody a idea or solution ? > > [1] https://martinkg.fedorapeople.org/Packages/olive/olive.spec Follow the cmake guidelines, you are missing a "%cmake ." statement before building. https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ Just in case, to my knowledge this is not an acceptable package for Fedora. Dridi ___ 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: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 9:41 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote: > Let me also add my +1 to the write-up itself, a very nice story. > > Zbyszek I may have accidentally skipped the +1 step and jumped straight to suggestions on how to improve the situation, shifting the blame away from _smp_mflags. But I agree this is a very relatable investigation! Dridi ___ 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: Removal of krb5-devel from "stable" F29 buidroot broke my package
> configure with feature autodetection is a PITA :/ The PITA doesn't come from auto-detection, rather auto-selection of (optional) dependencies. I tend to prefer explicit --with-* or --enable-* flags for anything optional and fixed defaults. It would be worse if we had to tell a configure script where each individual build dependency can be found! There tend to be more than what meets the eye, much more. Take your average project building with autotools and try this: ./configure --help | less Dridi ___ 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: xindy, texlive, and concurrency
On Thu, May 16, 2019 at 3:46 AM Jerry James wrote:
>
> I finally found some time to look at the xindy failure to build.
> First, let me say that I've got a workaround for the problem, which
> resulted in the beautiful green colors in this xindy-enabled scratch
> build of texlive-base:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34877270
>
> When the build process reached the xindy part of the build, it would
> successfully build xindy itself, then go to work on some
> documentation. This involved invoking latex on several input files.
> This marked the first (and possibly only) point in the build where
> latex was invoked, so latex.fmt had not yet been generated. Since we
> build with %{?_smp_mflags}, several independent threads invoked latex
> at approximately the same time. Every one of those invocations
> detected that latex.fmt was missing and tried to generate it.
>
> If you got lucky, each one of those threads would generate latex.fmt,
> then quickly consume it as it ran on its appointed input file. If you
> didn't get lucky, one or more threads would start reading latex.fmt
> after some other thread started writing it, but before it finished
> writing it all the way. That's why xindy would sometimes build and
> sometimes fail to build: the build process had a race condition.
So this is a build system bug from upstream. If concurrency introduces
a race condition then source-target dependencies are lacking in the
build system. Depending on the build system it may not be upstream's
fault, but the tooling itself.
A workaround for the concurrency problem would be an atomic write of
the generated file. This way even when it is generated multiple times
while others try to read it they either see a complete or missing file.
The only way I'm aware of for this workaround would be to write to a
temp file on the same filesystem, and then use mv to rename it
atomically.
> It is unfortunate that texlive is smart enough to detect missing
> format files and generate them, but not smart enough to stop that from
> happening multiple times concurrently. Anyway, poor xindy has been
> maligned: none of this was xindy's fault, nor clisp's. We, the Fedora
> packagers, threw concurrency at a job that lacked concurrency control.
> And the whole xindy_arches thing is useless: this is not an
> arch-specific problem, so removing random arches from the build
> accomplishes nothing.
>
> The workaround is to invoke latex on a dummy input file early in
> %build. This causes latex.fmt to be generated, and then everything is
> hunky-dory when xindy is built later.
>
> My recommendation is to remove the xindy_arches conditional from the
> texlive-base and texlive spec files. Make it unconditionallly on
> again. Then insert something like this at the top of %build:
>
> # Make texlive generate latex.fmt, so that multiple threads do not race to
> # make it during the xindy build.
> cat > dummy.tex << EOF
> \documentclass{article}
> \begin{document}
> This is a document.
> \end{document}
> EOF
> latex dummy.tex
> rm -f dummy.*
>
> That is the substance of this pull request:
>
> https://src.fedoraproject.org/rpms/texlive-base/pull-request/6
>
> Also, I should be able to push a clisp build with s390x support to F30
> stable tomorrow. I, personally, would really appreciate having xindy
> reappear in F30, due to Sphinx assuming it is available.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.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 Mon, May 13, 2019 at 7:57 PM Jakub Jelinek wrote: > > Sorry for digging up this thread, but since this is a recurring change > > it appears that the mass rebuild is not enough by itself. As of today > > lcov doesn't work with GCC 9.x [1] and it would be nice if either: > > > > - gcc provided an option to use a previous gcov format when a new one > > lands (I understand it makes things more complicated) > > No, we certainly don't want to diverge from gcc upstream here, and gcc > upstream doesn't have that. My idea was rather to bring the suggestion upstream if it is relevant :) > > - the Fedora lcov spec would run `make test` in a %check section > > lcov maintainers have been told they should use the json intermediate format > from gcov -i instead of trying to parse the binary data. Well, not everyone runs Fedora so lcov will still have to support the binary format for platforms that don't adopt new GCC versions as fast. I hope json support was what they were hoping to get done before May from the github issue I linked. But as a gcc+gcov+lcov user, that also requires me as an end-user to actively run gcov and lcov with the right set of flags once lcov support is here. That also means that if I have automation in place that expects to work with either GCC or LLVM toolchains, it makes things more complicated if I need my build system to work not only for me on Fedora 30 but for other team members working on the same project but on different operating systems. Hence my comment regarding compatibility when the binary format changes. Again, if that is relevant. I personally work with both toolchains, because each major release usually brings new helpful warnings or diagnostics. And for that matter I'm really happy to be on Fedora and act as a canary to learn what's coming. Dridi ___ 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, Jan 22, 2019 at 10:30 AM Jakub Jelinek wrote: > > On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote: > > This is already happening, gcc was updated, I see bugs for gcc 9 related > > FTBFS being open. This is not a proper way to coordinate this kind of thing. > > 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 said, a test mass rebuild has been performed (this year by Jeff Law) > and issues have been analyzed. Sorry for digging up this thread, but since this is a recurring change it appears that the mass rebuild is not enough by itself. As of today lcov doesn't work with GCC 9.x [1] and it would be nice if either: - gcc provided an option to use a previous gcov format when a new one lands (I understand it makes things more complicated) - the Fedora lcov spec would run `make test` in a %check section Ideally both for the sake of continuity/easier transitions. At the very least we would learn with the latter at mass rebuild time that such a problem exists. TIL that lcov is a noarch package, I had no idea! And fortunately clang and llvm-cov are still using the old format so for now I can still build code coverage reports but it's a bit annoying to discover this after upgrading. Dridi [1] https://github.com/linux-test-project/lcov/issues/58 ___ 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
bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek wrote: > This makes the assumption, which was also made earlier in the thread, > that it's somehow impossible to check what bootloader is installed. > Why? My bootloader is happy to tell me its version: > $ bootctl > ... > Current Boot Loader: > Product: systemd-boot 241-565-g43d51bb > Features: ✓ Boot counting >✓ Menu timeout control >✓ One-shot menu timeout control >✓ Default entry control >✓ One-shot entry control > File: /EFI/systemd/systemd-bootx64.efi > ... > Nowadays it's gives the exact git commit it's built from, in the past > it was just the release version, but either is enough. Therefore > 'bootctl update' can fairly reliably *update*, i.e. do the installation > if the thing we have is newer than the version already installed. That's news to me, and unfortunately it doesn't look as nifty on my system: ... Current Boot Loader: Product: n/a Features: ✗ Boot counting ✗ Menu timeout control ✗ One-shot menu timeout control ✗ Default entry control ✗ One-shot entry control ESP: n/a File: └─n/a Available Boot Loaders on ESP: ESP: /boot/efi (/dev/disk/by-partuuid/$UUID) File: └─/EFI/BOOT/BOOTIA32.EFI File: └─/EFI/BOOT/BOOTX64.EFI Boot Loaders Listed in EFI Variables: Title: Fedora ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/$UUID File: └─/EFI/fedora/shimx64.efi Title: Linux Firmware Updater ID: 0x Status: active, boot-order Partition: /dev/disk/by-partuuid/$UUID File: └─/EFI/fedora/shimx64.efi ... Where $UUID is the same for all three occurrences. Dridi ___ 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 Sat, May 4, 2019 at 9:36 PM Chris Murphy wrote:
>
> While handling this bug with a Common Bugs report is suboptimal, it
> has long been expected that users should read Common Bugs before
> installing or upgrading their systems. Making that advice more
> prominent might be reasonable.
I never heard of that, is it mentioned by the release announcement or
the blog entry on how to upgrade from fX to f{X+1}?
I think I would have remembered (and definitely checked the Common
Bugs) if that were the case. I will probably have plenty of time to
forget about it until f31 is out, so I'm all for advertising the
Common Bugs more!
Dridi
___
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: Problem with docker image for fedora:29
On Thu, May 2, 2019 at 5:31 PM Irina Boverman wrote: > > and this: > dnf install -y --allowerasing git zip unzip python krb5-workstation > java-1.8.0-openjdk java-1.8.0-openjdk-devel authconfig expect python3 > python3-requests python3-websockets pycurl which > Fedora 29 - x86_64 - Updates > 0.0 B/s | 0 B 00:56 > Failed to synchronize cache for repo 'updates' > Error: Failed to synchronize cache for repo 'updates' DNF currently doesn't retry when a download fails: https://bugzilla.redhat.com/show_bug.cgi?id=1643281 In my case it's often because there is no route to IPv6 hosts when I'm on my IPv4-only mobile network. I can work around that from the dnf command line but not always (eg. mock) and since we can't drop-in DNF configuration I'm somewhat reluctant to touch the main dnf.conf and possibly miss new defaults when I upgrade (I know RPM allows me to see what changed but I'd rather not have to remember). Try adding the -v option to see what's failing to synchronize: dnf -v install -y ... Dridi > On Thu, May 2, 2019 at 11:14 AM Irina Boverman wrote: >> >> Error: >> -- >> Fedora Modular 29 - x86_64 0.0 B/s | 0 B 00:56 >> Failed to synchronize cache for repo 'fedora-modular' >> Error: Failed to synchronize cache for repo 'fedora-modular' >> The command '/bin/sh -c dnf install -y --allowerasing git zip unzip python >> krb5-workstation java-1.8.0-openjdk java-1.8.0-openjdk-devel authconfig >> expect python3 python3-requests python3-websockets pycurl which' returned a >> non-zero code: 1 >> -- >> Is this a problem with Fedora server or something else? >> -- >> Regards, Irina. > > ___ > 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: dropping autogenerated dependency on pkg-config
On Fri, May 3, 2019 at 8:18 PM Nicolas Mailhot via devel wrote: > > Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit : > > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel > > wrote: > > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > > > > wrote: > > > > [..] > > > > > You're assuming the only use is roolback. It's not > > > > > > > > Point taken. Can you shortly describe other use cases? > > > > > > You use apps in one of those languages that static build by > > > default. > > > There is a security alert in one code component. You want to know > > > which > > > packages in your repo/mirror have been build using the broken piece > > > of > > > source code > > > > Last time we disagreed on this topic my opinion was that static > > linking should imply bundled provides: > > > > Provides: bundled() = > > > > Hopefully something that could be automated for some stacks. > > That makes it stack-specific Bundling in general is very package-specific anyway. > And anyway, the classical compiler attack (compiler that inserts > backdoor while compiling) shows that special-casing some packages for > special tracking does not work, pretty much anything that existed in > the build root need to be tracked because it may be exploited one way > or another, and spead the exploit to everything that used it. I definitely agree with that part, but I have no opinion on where that information should live. Dridi ___ 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: dropping autogenerated dependency on pkg-config
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel wrote: > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > > wrote: > > [..] > > > You're assuming the only use is roolback. It's not > > > > Point taken. Can you shortly describe other use cases? > > You use apps in one of those languages that static build by default. > There is a security alert in one code component. You want to know which > packages in your repo/mirror have been build using the broken piece of > source code Last time we disagreed on this topic my opinion was that static linking should imply bundled provides: Provides: bundled() = Hopefully something that could be automated for some stacks. To me there is no difference between bundling source code and bundling arch code, since most of the time I have seen it in action it was more a feat of vendoring for internal usage rather than actually providing a duplicate something to be consumed by others. And it would solve the post-CVE system inspection problem. Dridi ___ 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 30 officially released!
> Have you reported this to the dnf maintainers via bugzilla? Not yet, I dumped my upgrade notes here and then browsed bugzilla for error messages happening during my first f30 boot (turns out there's already a ticket for all of them) and then time ran out. Dridi ___ 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 30 officially released!
On Thu, May 2, 2019 at 8:30 AM Samuel Sieb wrote: > > On 5/1/19 8:16 AM, Dridi Boukelmoune wrote: > > Here I had to remove the following packages (and they took some of > > their dependencies away with them) beforehand: > > > > - python2-hawkey-0.31.0-2.fc29.x86_64 > > - python2-libdnf-0.31.0-2.fc29.x86_64 > > - python2-migrate-0.11.0-9.fc29.noarch > > Didn't the upgrade process suggest that you use --allowerasing? That > would most likely have solved the problem for you. No need to manually > remove them before the upgrade. It did but the transaction summary is so long that figuring out the consequences of removing packages automatically is not an easy task. I can usually follow --allowerasing on a simple dnf upgrade, but that rarely happens on a stable release. So I preferred to remove them one by one manually just to see what they would take with them. I know we still have packages that couldn't move away from Python 2 entirely but I don't know the specifics. No in-place upgrade problem since f15 doesn't mean I engage system upgrades without fearing of blowing up my setup :) Dridi ___ 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 30 officially released!
Hi,
On Tue, Apr 30, 2019 at 4:01 PM Matthew Miller wrote:
>
> It's been six months, and like clockwork, we release Fedora 30 today!
Congratulations! I have done in-place upgrades since Fedora 15 and I
was never let down. This time I even had scheduled a set of offline
tasks to do while my laptop would be unavailable but couldn't complete
half of them before noticing the system upgrade had completed. No
hard numbers but I'm pretty sure it went much faster than my upgrade
to f29.
That is a bit irrelevant but I disabled the modular repository after
upgrading to f29, so I can't comment on my upgrade experience in this
regard.
> Thank you to the thousands of people who worked to bring this release
> together. Fedora doesn't happen by magic: it happens because of you!
I'd like to break the spell a bit. Although the system upgrade always
goes smoothly (and yet I'm always worried) the download and
verification part rarely does on the first try.
Here I had to remove the following packages (and they took some of
their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64
- python2-libdnf-0.31.0-2.fc29.x86_64
- python2-migrate-0.11.0-9.fc29.noarch
Looking at my f30 setup I find this:
$ rpm -q --obsoletes fedora-obsolete-packages |
> grep -E 'python2-(hawkey|libdnf|migrate)'
python2-hawkey < 0.30-1
python2-libdnf < 0.30-1
So apparently python2-hawkey and python2-libdnf were updated on f29
after being obsoleted on f30 with no further coordination on the
fedora-obsolete-packages side. I'm not trying to blame anyone, it is
easy to forget about something that was supposed to be done.
Maybe we should change the %{release} tag to look like %{?dist}X
instead of X%{?dist}. That would allow something like:
Obsoletes: $PKG < $VERSION-f30
Since the %{release} comes after the %{version} that would still not
prevent the accident I ran into with python2-{hawkey,libdnf} and there
has already been solid cases against Epoch for this use case.
In hindsight, it's possibly the mast removal of python2 packages that
sped up the upgrade.
I have no idea why or how python2-migrate landed on my system, and
didn't actively need that one. According to DNF nothing obsoletes this
package today.
Then I had to remove libxslt-devel.i686 because the upgrade selected
both i686 and x86_64 packages and they conflict. No idea why. Trying
to reinstall libxslt-devel.i686 afterwards worked fine.
Then I realized that getdns-stubby was gone after the upgrade. I
suspect this happened because there was previously no such
sub-package. I have no idea how to deal with that kind of split.
Finally, on the first f30 right after the system upgrade I tried a DNF
upgrade and fedora-obsolete-packages was available. It was _after_
that last upgrade that I inspected its obsoleted packages with the
grep command above.
So besides those unfortunate hiccups I'm now writing the devel list on
a Fedora 30 system, happy that you chose to release it right before a
bank holiday where I live, giving me the luxury to say goodbye to
Fedora N-1 faster than usual.
Cheers,
Dridi
PS. does the wallpaper have some sort of easter egg?
___
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: Set skip_if_unavailable default to false
On Sat, Apr 27, 2019 at 10:13 AM Jaroslav Mracek wrote: > snip >> I just hope the DNF team would implement a retry on failed downloads >> to not consider a repository unavailable right off the bat especially >> when we have a list of mirrors to pick from. >> > > We are working on improvement. Thanks, I'm really looking forward to that! Is there a ticket I can subscribe to? > Jaroslav > DNF team developer > >> >> Dridi >> ___ >> 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: Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
On Thu, Apr 25, 2019 at 11:50 PM Jan Pokorný wrote: > > On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote: > > Also please note that fedora-cisco-openh264.repo ships with > > "skip_if_unavailable=true". > > off-topic: which in fact doesn't matter much, since you'll, sooner > or later and whether you want or not, receive non-free (in a sense) > binaries over the native Firefox channel (guidelines yada yada yada) > anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1648024 Not entirely off topic, the change description states that Fedora repositories ship with skip_if_unavailable=false but fedora-cisco-openh264.repo doesn't. Thanks for the bug report, that explains what I thought was pebcak when this was introduced and all I could do was disable the plugin. But I would argue that bug is off topic ;-) I just hope the DNF team would implement a retry on failed downloads to not consider a repository unavailable right off the bat especially when we have a list of mirrors to pick from. Dridi ___ 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
