Re: Three steps we could take to make supply chain attacks a bit harder
Kevin Kofler via devel wrote: > Dominique Martinet wrote: >> Before making each of these safer we should make sshd not link with so >> many things in the first place. > > Indeed. E.g., Arch Linux does not transitively link sshd against liblzma. > Fedora does because of this innocuous-looking patch: > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > we should just stop using sd_notify at all. Upstream openssh-portable has a proposed patch which simply implements the sdnotify protocol directly. That would provide the benefits with none of the over-linking risk. https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13 It could use some review from distro folks familiar with sshd systemd integration. (The wider point about splitting the sdnotify functionality is still quite useful, to avoid everyone re-implementing the same thing and possibly adding bugs in _that_ process.) -- Todd signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning all my packages
Sérgio Basto wrote: > On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote: >> a project >> where the primary sponsor and downstream no longer provides >> source code freely and openly > > what you are talking about ? all RHEL Source are freely available on > Centos Stream , and RHEL never was free . That's not the case, but I don't wish to go wildly off-topic about it either. _Most_ of the source is available, but not all of it. This is a case where -- for me -- close is not good enough. To each their own. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning all my packages
Hi, Michael J Gruber wrote: > Thank you for all the effort you have put into maintaining these > packages so far, for the benefit of all of Fedora, and consequently > its downstream! Thanks! > Your reasons resonate with me, though I'm not taking the same > conclusions. Have you arranged "succession" with your git > co-maintainers? I have not, but I presumed that git would be picked up quickly as it's a rather important package. And it looks like that's already happened. :) All the best,, -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning all my packages
Hi, I'm orphaning all my packages (which I effectively did months ago). It's been fun being a maintainer since 2006. However, I am not interested in contributing to a project where the primary sponsor and downstream no longer provides source code freely and openly. It's simply not consistent with why I use and contribute to Fedora and Free/Open Source Software in general. I'm a maintainer of the following packages: cgit git paperkey I'm an admin of the following packages: fail2ban rubygem-asciidoctor I have commit privileges on these additional packages: asciidoc git-filter-repo rpmlint Thanks, -- Todd Zullinger ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Red Hat & Fedora -- largely stepping out of this ecosystem
Carlos O'Donell wrote: > On 6/26/23 18:47, Jeff Law wrote: >> What Red Hat has done may be technically legal and perhaps good for >> its business. However, to me it's ethically unconscionable. Those >> who know me know I'm not an zealot, but I do have a baseline set of >> ethical values and Red Hat crossed that line. > > Why is it ethically unconscionable? There is a lot of confusion around > what has happened and why. What you are saying, and what actually happened > don't line up in my mind :-) Something I'm having trouble with is Red Hat's position that you can choose to be a customer or to exercise your rights under the GPL, but you cannot be both. I don't know how to view that as anything other than sacrificing the spirit of F/OSS to help the books. I am sympathetic to the odd/difficult nature of running a business based on F/OSS. Until now I thought Red Hat was doing it pretty well. I thought Jeff's message was well written. I am still struggling with whether I should take the same path. :( -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora ELN Plans for Summer 2023
Stephen Gallagher wrote: > On Fri, Jun 16, 2023 at 11:53 AM Miro Hrončok wrote: >> >> On 16. 06. 23 15:39, Stephen Gallagher wrote: >>> This leads me to my next schedule announcement: we will be performing >>> the initial CentOS Stream 10 branch creation in Gitlab for all >>> packages in the Fedora ELN runtime package set[1] during the week of >>> July 19th, coincident with the Fedora 39 mass-rebuild. >> >> Will you please, please, please, please import the packages with git history >> and not via fepdkg srpm -> centpkg import? > > YES! Excellent news! As someone who takes git history (maybe a little too) seriously, this is quite welcome. Thanks to all who helped make the change. :) -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38
Pavel Raiskup wrote: >> I thought that previous fedpkg or mock releases printed a >> large banner which explained this a bit and linked to >> further details? I would have thought that was still in >> place, but perhaps not. > > Mock prints the banner you expect iff the corresponding > epel-* symlink doesn't exist (if it exists, user already > made the decision). This is at least the desired > behavior; if Mock misbehaves, please report. Will do. I checked on a clean system and got the banner. I noticed that it includes centos-stream. It has a small note that "some packages may be a bit ahead the Red Hat Enterprise Linux N" but I wonder if that's really useful to new mock users? I'm not sure that makes it clear how likely you are to have incompatible builds at any given point. IMO, that belongs with the epel-next configs, not epel. And there's already a link from epel-next-$VER-$ARCH to centos-stream+epel-next-$VER-$ARCH. Do you think it would it be reasonable to propose dropping centos-stream from the epel alternatives configuration? If not, what about making the warning a bit stronger? I'm not asking you or anyone else to do that work. I'm just wondering if it has already been debated and firmly settled before I spend time doing it. -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38
bradb...@seanet.com wrote: > I misspelled centos as contos Now fedpkg mockbuild works with the proper > links: > >>ls -l $HOME/.config/mock > total 8 > lrwxrwxrwx. 1 bradbell bradbell 41 Jun 3 19:09 epel-8-x86_64.cfg -> > /etc/mock/centos-stream+epel-8-x86_64.cfg > lrwxrwxrwx. 1 bradbell bradbell 41 Jun 3 19:09 epel-9-x86_64.cfg -> > /etc/mock/centos-stream+epel-9-x86_64.cfg That's not what you want for epel though. It will build against centos-stream rather than rhel/alma/rocky, i.e. the stable EL. While it might appear to work, it will inevitably build packages which link against the wrong versions of libraries, pick up bogus dependencies, etc. You want to pick one of the *+epel-[89]-x86_64.cfg config files. I thought that previous fedpkg or mock releases printed a large banner which explained this a bit and linked to further details? I would have thought that was still in place, but perhaps not. -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
I wrote: > I may attempt to resolve some of the issues, but if there's > some documentation on the changes it would make it a lot > easier. :) I filed an upstream PR with a couple of commits: https://github.com/rpm-software-management/rpmlint/pull/1066 This fixes the test suite and works in very basic testing. I'd be surprised if there aren't other issues remaining nor bugs in my changes. I'll push that to rawhide soon-ish to get some testing. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: RPM 4.19 soname bump in Rawhide
Hi, Michal Domonkos wrote: > We're currently preparing an update to RPM 4.19 ALPHA for Rawhide in a > side-tag. The new version features a soname bump: Is there a porting guide for rpm python users? The rpmlint package has a number of test failures and quite likely other breakages which may not be caught by the test suite. I may attempt to resolve some of the issues, but if there's some documentation on the changes it would make it a lot easier. :) One issues with rpmlint was use of hdr.dsFromHeader(). The rpm commit which removed this says it was "a bit weird and long redundant, rpm.ds() takes a header as an argument since over ten years now." But AFAIK, there was no deprecation warning which rpmlint saw that would have warned about using this method. Thanks, -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Place to write something up
Chris Adams wrote: > Kind of a random thing, but... I would like to write up how to use GRUB2 > to do BIOS-PXE+UEFI-PXE+UEFI-HTTP boot. I asked for the Fedora packages > to include the needed PXE bit, and it does now (thanks!), so I feel I > owe a good explanation on how to use it. :) > > I don't have any kind of personal blog or such, and probably could use > some review once I do write something... is there a good Fedora-provided > place to do something like that? The Quick Docs might be a good place: https://docs.fedoraproject.org/en-US/quick-docs/contribute-to-quick-docs/ or perhaps Fedora Magazine: https://docs.fedoraproject.org/en-US/fedora-magazine/contributing/ I think Quick Docs would be a nicer home for something like this, but either place would be cool to see it. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
TLDR; I'm in the "please, not a web forum" camp, but I also feel like this is effectively a foregone conclusion, unfortunately. As a maintainer of a small number of packages, I follow devel to keep up with changes affecting the distribution and occasionally chime in or find areas where I can help in some way. I have gained an immense amount of knowledge about Fedora this way as well as a strong appreciation for the folks doing the heavy lifting. I've tried to use discourse a bit and find it to be like every other web forum -- heavy to load and frustrating to work with. My reasons match what a number of other folks here have already said. In particular, I don't like moving from an email discussion method where each participant can choose their own client and tools to work as they want to a web interface which is one-size-fits-all (or none, as often everyone loses something). I'd be among those who are simply less informed and engaged in the Fedora development community if things move to a web forum. If there are a lot more gains in doing so, I wish you well in the endeavor. Thanks, -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: dnf failing to pull from epel - HTTP 404
Laura Flores wrote: > Link to the thread: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/SN2KUYRQRVPN5YD25LQRCRTOXGH2TUDH/ I think https://pagure.io/fedora-infrastructure/issue/11233 is tracking this. It looks like the problematic system should be out of the mirror lists, which I suspect should prevent the issue from reaching end-users. That would take effect after the downstream mirrors sync after the change to remove ib01. (I'm not directly involved, so I could be misinterpreting the status.) -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: default bash history (non)preservation
Chris Adams wrote: > Once upon a time, Michael Catanzaro said: >> On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams >> wrote: >>>I wouldn't do that part; that's additional disk I/O for every prompt. >>>Especially when the system might be having issues, users (especially >>>root) don't need something interfering with every command. This would >>>mean an NFS home would insta-hang at the slightest issue. >> >> Hm, but consider also that if the filesystem is slow or unreliable, >> then your entire desktop is going to hang as well. (It probably >> _shouldn't_ hang, but it absolutely does.) You cannot even open >> gnome-terminal until the I/O operations complete. With that baseline >> in mind, I'd say the benefits outweigh the costs, but we should make >> it easy to opt out somehow. > > You are assuming Fedora is only used for desktops. Indeed. I think that setting PROMPT_COMMAND as an array in the default configuration would be the place to start. Then packages which enable such functionality can be added with more granularity. If the desktop working group wants to default to having such a configuration enabled, it can be done without affecting the server images, etc. And folks can easily opt-out even on the desktop. (I'd still prefer if it was opt-in for the desktop, but that's just an opinion.) That makes it easier to add snippets to /etc/profile.d rather than coordinating everything via the setup package. Hard-coding a default for everyone which leaves a good number of folks unhappy in either case is not ideal. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: default bash history (non)preservation
Chris Murphy wrote: > I've implemented the suggested two line change to > .bash_profile: > > # User specific environment and startup programs > shopt -s histappend > PROMPT_COMMAND="history -a;$PROMPT_COMMAND" > [...] > Any thoughts? As others have said, enabling this by default has consequences which would make a good number of folks unhappy, so it's probably not an ideal candidate to enable by default. One thing worth noting, I think, is that since bash-5.1, PROMPT_COMMAND may be an array. This lends itself to adding something in /etc/profile.d which appends 'history -a' to the PROMPT_COMMAND array, e.g.: PROMPT_COMMAND+=( history -a ) (which would grow half a dozen or so lines with the needed checking that 'history -a' wasn't already present, that PROMPT_COMMAND was an array instead of a string, etc.) I don't believe that Fedora's defaults from the setup package currently use an array, so perhaps working toward that change would be a good first step. Once in place, a package which provides the history appending behavior could be easily added and those who prefer it could install it. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %patchN deprecated?
Florian Festi wrote: > On 3/29/23 10:31, Michael J Gruber wrote: >> Has `%patchN` been deprecated in favour of `%patch N`? > > Yes, see %patch section on > https://rpm-software-management.github.io/rpm/manual/spec.html Quoting that: %patch is used to apply patches on top of the just unpacked pristine sources. Historically it supported multiple strange syntaxes and buggy behaviors, which are no longer maintained. To apply patch number 1, the following are recognized: %patch 1 (since rpm >= 4.18) %patch -P1 (all rpm versions) %patch1 (deprecated, do not use) For new packages, the positional argument form 1) is preferred. For maximal compatibility use 2). Both forms can be used to apply several patches at once, in the order they appear on the line. The third form where the number is a part of the directive is deprecated and should not be used anymore. Which gets to Michael's question "which releases can take it?" Changing `%patch1` to `%patch 1` limits support to Fedora 37 and above, unless this has been backported to older Fedora and/or RHEL rpm? Until it's supported by all current Fedora and RHEL releases, it's not a change I'd want in the packages I maintain. I'd have to go with `%patch -P1` (anywhere that %autosetup / %autopatch wasn't used). -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dogtag-pki is not installable on F38/Rawhide because it fails the GPG check even if you attempt to skip the check
Hi, Chris Kelley wrote: > TL;DR dogtag-pki is not installable on F38/Rawhide because > it fails the GPG check (F37 and prior are fine), even if > --nogpgcheck is specified, and I don't understand why. > > 1) Why does the key not work? > 2) Why does --nogpgcheck not work? It seems like it must be related to the issues reported recently with respect to changes in the rpm signature backend & stricter crypto-policies, but I don't see _why_ they are failing. They don't appear to be using SHA1 or DSA algorithms. :/ I think it is suspicious that the three packages which fail to verify are the three which have not been built within the past week or so. Attempting an install in a rawhide container from today, then checking the package cache after it fails simply reports the rpm signature as BAD. [root@8f5fc423842b /]# rpm -Kvv dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm D: loading keyring from rpmdb D: PRAGMA secure_delete = OFF: 0 D: PRAGMA case_sensitive_like = ON: 0 D: read h# 150 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-18b8e74c-62f2920f to keyring D: read h# 160 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-20de059c-5c7ffdbe to keyring /var/cache/dnf/copr:copr.fedorainfracloud.org:group_pki:master-7092f479845efeda/packages/dogtag-jss-5.4.0-0.1.alpha1.20230227143934UTC.0c4012e6.fc39.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 20de059c: BAD Header SHA256 digest: OK Header SHA1 digest: OK Payload SHA256 digest: OK V4 RSA/SHA256 Signature, key ID 20de059c: BAD MD5 digest: OK Maybe there was some issue in COPR and/or rawhide at the time those packages were signed which caused them to fail verification now? It may be worth trying to rebuild them to see if they can be properly signed? -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later
Tomas Korbar wrote: > Extending the question here. > > -- Forwarded message - > From: Tomas Korbar > Date: Thu, Mar 9, 2023 at 9:51 AM > Subject: License: GPL-3.0-or-later AND GPL-2.0-or-later > To: > > > Hi guys, > I am doing the conversion of license tags in my projects and i have a > project where some files are under the GPL-2.0-or-later license and other > under the GPL-3.0-or-later license. Perhaps this has been mentioned > somewhere but i did not notice, but is it possible to merge these 2 into > just GPL-3.0-or-later and thus reduce the specification to only one license? Per the licensing guidelines¹ The spec file License: field consists of an enumeration of all licenses covering any code or other material contained in the corresponding binary RPM. This enumeration must take the form of an SPDX license expression. No further analysis as to the "effective" license should be done. ¹ https://docs.fedoraproject.org/en-US/legal/license-field/#_basic_policy -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedpkg: Failed to get repository name from Git url or pushurl
Petr Pisar wrote: > [...] Either turn that directory into a git repository (git > init-db . && git add hello.spec && git commit -a) ... Just a minor, tangential nit, `git init` is the preferred and documented command. The `git init-db` command is an ancient name for it. The documentation for `git-init-db` has pointed users to `git init` since January 2007. :) -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: packaging tutorial error - /usr/bin/systemd-nspawn mock-chroot debug advice
Kenneth Goldman wrote:
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
>
> ~~~
>
> when running that tutorial (Fedora 37, x86), I get this error:
>
> ERROR: Exception(/home/kgold/hello/hello-2.10-1.fc37.src.rpm)
> Config(fedora-37-x86_64) 0 minutes 18 seconds
> INFO: Results and/or logs in: /home/kgold/hello/results_hello/2.10/1.fc37
>
> ~~~
>
> The log has at the end:, but I suspect that the python issue is a reporting
> issue, not the actual failure.
>
> RPM build errors:
> Child return code was: 1
> EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
> d0156a2d35ca46a0ba55a993d05852c1 -D /var/lib/mock/fedora-37-x86_64/root -a
> -u mockbuild --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv.lphffv1r:/etc/resolv.conf --bind=/dev/btrfs-control
> --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0
> --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
> --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8
> --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe
> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\\033]0;\\007"
> --setenv=PS1= \\s-\\v\\$ --setenv=LANG=C.UTF-8
> --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --target x86_64
> --nodeps /builddir/build/SPECS/hello.spec\n', 1)]
> Traceback (most recent call last):
> File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
> result = func(*args, **kw)
> ^
> File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 598, in
> do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command, output),
> child.returncode)
> mockbuild.exception.Error: Command failed:
>
> ~
>
> When I try /usr/bin/systemd-nspawn directly, I get this. What directory is
> it looking for? /var/lib/mock/fedora-37-x86_64/root exists. I don't run as
> root, right?
>
> mock-chroot: No such file or directory.
If you're running that command directly, it looks like you
need to quote some things. Particularly:
--setenv=PS1= \\s-\\v\\$
should be quoted:
--setenv=PS1=' \\s-\\v\\$'
(I don't know offhand if the backslashes still need to be
escaped or not.)
As for the real issue, the mock build log may have more
details above the EXCEPTION. That's probably worth
exploring before you spend too much time on how to reproduce
the systemd-nspawn command.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: livcd-creator gives incorrect checksum for recently rebuilt local repo packages
Alexander Ploumistos wrote: > On Mon, Feb 27, 2023 at 4:15 AM Globe Trotter via devel > wrote: >> I wonder if anyone has any suggestions on how to get >> around this problem. I create my local repo using >> >> createrepo . >> >> inside my RPMS/x86_64 directory. > > Is there a specific reason you are not using createrepo_c? > Does that give you the same error? FWIW, createrepo comes from createrepo_c: $ rpm -qf /bin/createrepo createrepo_c-0.20.1-1.fc36.x86_64 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: providing gpg verification for a package without signature
Hi, Globe Trotter via devel wrote: > I have been trying to package slim again. The package does not come with a > signature or a gpg key. > > From > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification > I don't see an option of what to do if there is no signature provided. > > Any suggestions or pointers to where I can get guidance on this? Per the guidelines: Where the upstream project publishes OpenPGP signatures of their releases, Fedora packages SHOULD verify that signature as part of the RPM build process. If upstream doesn't provide a signature for their releases, then there isn't anything to verify. The guideline is also a SHOULD not a MUST, so it's not a blocker to lack signature verification (though I'd argue it should be a very strong SHOULD, if not a MUST. ;) It might be worth asking the upstream maintainer if they would consider signing the release tarballs. I have to guess that you're looking to use slim-fork, rather than the original slim? The latter hasn't seen any changes since 2013¹, while the former has been updated recently to 1.4.0² (as far as I can tell with some quick searching). ¹ https://github.com/iwamatsu/slim/tags ² https://sourceforge.net/projects/slim-fork/files/ -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 branched
Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: >> 'git pull --rebase' is a strange command to suggest. I does the job, >> but almost by accident, and it's confusing things by mixing in rebasing. >> Can we make this just say 'git fetch' or 'git fetch -v' ? > > The thing is, you should ALWAYS git pull --rebase to pull from git > repositories, NEVER just git pull. While that was generally good advice (for folks who aren't maintainers of an upstream project, i.e. most people), it's not as accurate a statement as it once was. Since git-2.33.1 (2021-10-12), `git pull` should not create a merge commit by default. The default is --ff-only, which means: Only update to the new history if there is no divergent local history. This is the default when no method for reconciling divergent histories is provided (via the --rebase=* flags). Running `git pull` should do what most people want without the risk of surprising newer users due to a rebase with conflicts. It's better to have the pull simply stop rather than creating a merge (as it used to do) or attempting to rebase automatically -- as a default. Regardless, `git fetch` is the better recommendation here. It achieves the goal of getting the newly-branched release into the local repository and has no other effects. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedoras GnuPG default option is deprecated
Christopher Klooz wrote: > A fresh installation of Fedora 37 has by default the "--supervised" option > active in its gpg-agent systemd file > (/usr/lib/systemd/user/gpg-agent.service). > > According to GnuPG Docs [1], this option is deprecated. Once gpg-agent is > invoked, the log of "systemctl --user status gpg-agent.service" confirms > that with: "gpg-agent[2022]: WARNING: "--supervised" is a deprecated option" > > Is this intended? > > Off the cuff I do not see an immediate security issue, but I guess it makes > sense to get over deprecated options. The gpg-agent (and dirmngr) systemd service files are installed from gnupg directly. Ideally, this should be fixed upstream. The --supervised option was deprecated in ca5d5142c (Deprecate the --supervised options., 2022-04-25)¹ but no change was made to the doc/examples/systemd-user/ files. This appears to have been first released with gnupg-2.3.6. ¹ https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek wrote:
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of stray files there from old rpm builds there…
I've used the following in ~/.rpmmacros for many years to
have rpmbuild keep package files together, as rpkg/fedpkg
do:
%_sourcedir %{_topdir}/%{?name:%name}
%_specdir %{_sourcedir}
%_builddir %{_sourcedir}
%_srcrpmdir %{_sourcedir}
%_rpmdir%{_sourcedir}
That doesn't address the deeper issues with respect to
rpmautospec compatibility, but it does make rpmbuild much
more comfortable to use, at least for me.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: opensubdiv: strange failure on doc subpackage
Hi, Luya Tshimbalanga wrote: > Hello team, > > While building opensubdiv, the failure[1] occurred on doc subpackage with > the following line: > > BuildError: The following noarch package built differently on different > architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm > rpmdiff output was: > added /usr/share/doc/opensubdiv/doxy_html/a00785.js > removed /usr/share/doc/opensubdiv/doxy_html/a00788.js > > > Any idea about root cause? [...] > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=95728588 This happens frequently with doxygen documentation. It looks like only a few adjustments are needed to resolve it though. I prepared the changes in a fork of the package repo: https://src.fedoraproject.org/fork/tmz/rpms/opensubdiv/c/0cd9137 and ran a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=95730383 I'm far from an expert with Doxygen; others may have better ideas on how to resolve this. Here's a PR with the changes, for testing and review: https://src.fedoraproject.org/rpms/opensubdiv/pull-request/1 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mystery fedpkg srpm failure
Hi, Florian Weimer wrote: > I don't see what spec file aspect is causing this failure: > > $ fedpkg clone -a cups-bjnp > Cloning into 'cups-bjnp'... > remote: Enumerating objects: 278, done. > remote: Counting objects: 100% (278/278), done. > remote: Compressing objects: 100% (222/222), done. > remote: Total 278 (delta 112), reused 96 (delta 47), pack-reused 0 > Receiving objects: 100% (278/278), 158.64 KiB | 752.00 KiB/s, done. > Resolving deltas: 100% (112/112), done. > $ cd cups-bjnp > $ fedpkg srpm > Not downloading unused cups-bjnp-2.0.3.tar.gz > > setting SOURCE_DATE_EPOCH=1669852800 > error: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file > or directory > > RPM build errors: > Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file or > directory > Could not execute srpm: Failed to execute command. > > fedpkg-simple doesn't have this problem (presumably because it downloads > whatever is in the sources file, whether used or not), so the package > builds fine in Koji. > > Any ideas? Removing the tabs between 'Source' and ':' resolves the issue: $ sed -Ei 's/(Source)\t+/\1/' cups-bjnp.spec ; fedpkg srpm Downloading cups-bjnp-2.0.3.tar.gz 100.0% setting SOURCE_DATE_EPOCH=1669852800 Wrote: /tmp/cups-bjnp/cups-bjnp-2.0.3-7.fc38.src.rpm I didn't look into how fedpkg parses the spec file, but that rather unusual whitespace is the cause here, AFAICT. I leave it to others to debate where the fix belongs (in rpkg/fedpkg and/or cups-bjnp.spec). -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Question about git signed tags
Vitaly Zaitsev via devel wrote: > On 29/11/2022 09:24, Bob Hepple wrote: >> "... Arch supports signed git tags. I'm hoping Fedora does too. > > On Fedora you must upload source tarball, its signature and public key to > the Fedora look-aside cache A minor expansion on that; the public key / upstream keyring must be be stored in dist-git rather than in the lookaside cache, per the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures Any detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) must be uploaded to the package lookaside cache alongside the source code, while the keyring must be committed directly to the package SCM. One of reasons being that it's (at least slightly) easier to notice a change to the public key / keyring when it's in dist-git versus the lookaside cache. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %{bash_completions_dir} or %{%bash_completion_dir} what is the correct macro ?
Sérgio Basto wrote: > I fully agree with this commit, maybe you can go ahead with an official > PR. Done, thanks! EPEL8 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/57 EPEL7 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/58 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %{bash_completions_dir} or %{%bash_completion_dir} what is the correct macro ?
Sérgio Basto wrote: > in an effort to do things correctly and without hacks > I noticed that redhat-rpm-config-202-1.fc35.noarch defines > %bash_completions_dir and epel-rpm-macros %defines bash_completion_dir > > Which one is the correct ? hopefully we have a few case [1] (18) vs [2] > (14) > I think the bash_completions_dir is the right one ... , what is you > opinion ? I agree, for that's worth. :) In EPEL, `bash_completion_dir` was added to epel-rpm-macros in 46557e2 (Add %bash_completion_dir., 2016-08-11) on the epel7 branch. I don't know if there is any corresponding list discussion of that change, but I didn't spend any time searching outside of Git and Pagure. The commit message doesn't reference any ticket or discussion. The change was copied into the epel8 and epel9 branches when they were initialized. In Fedora, `bash_completions_dir` was added to redhat-rpm-config in 483a3b8 (Add macros.shell-completions, 2022-06-25), per PR#206¹. Subsequently, this change was made for EPEL on the epel9 branch in c212ede (Backport macros.shell-completions from Fedora, 2022-09-01), via PR#49². While the non-plural form in EPEL predates what is in Fedora, I think that the plural form as used in Fedora and EPEL-9 would be best going forward. That just requires adding macros.shell-completions to the epel7³ and epel8⁴ branches of epel-rpm-macros. (I didn't test the changes, I only prepared them to get a start on the work if that direction is desirable.) The existing `bash_completion_dir` could be changed to point to `bash_completions_dir` to avoid breaking any users of it while also making it clearer to folks reading the macros files which is the preferred spelling. ¹ https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/206 ² https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/49 ³ https://src.fedoraproject.org/fork/tmz/rpms/epel-rpm-macros/c/9c7b88b ⁴ https://src.fedoraproject.org/fork/tmz/rpms/epel-rpm-macros/c/dc9df62 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX - How to handle MIT and BSD
Neal Gompa wrote: > On Tue, Nov 15, 2022 at 11:05 AM Todd Zullinger wrote: >> Am I missing something obvious or does licensecheck not work >> as expected? This is with licensecheck-3.3.0-2.fc36.noarch. > > licensecheck does not follow/use SPDX-License-Identifier at all. It > predates that scheme. Then it seems odd to recommend it when someone asks "Does licensecheck support SPDX identifiers?" I think. :) The answer is closer to: "sort of, but not really in a way that helps Fedora maintainers do the SPDX license conversion." -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: pypolicyd-spf-2.9.3 crashes Postfix
Chris Adams wrote: > Once upon a time, Todd Zullinger said: >> Sylvain Jones via epel-devel wrote: >>> It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x >>> crashes Postfix unexpectedly. Perhaps a missing dependency? >> >> It looks like pypolicyd-spf-2.9.3-2 should be in >> epel-testing now. That update will install python3-authres, >> so you may way to clean up the pip-installed copy you >> mention below. > > Except... for EPEL 9, there is no python3-authres. There is a request > for it to be added though: > > https://bugzilla.redhat.com/show_bug.cgi?id=2142503 Oops. Looks like there's a similar issue for python3-pymilter which was added as another missing dependency in the -3 package, per: https://bugzilla.redhat.com/2142743 A bug was filed to branch pymilter for EPEL-9 in August and a duplicate was filed today: https://bugzilla.redhat.com/2120091 https://bugzilla.redhat.com/2142747 -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX - How to handle MIT and BSD
Neal Gompa wrote: > On Tue, Nov 15, 2022 at 6:24 AM Miro Hrončok wrote: >> Do we have a command line tool for this? Does licensecheck support SPDX >> identifiers? >> >> (I find the use of browser extension for this very weird. I have the LICENSE >> file unpackaged with the sources on my machine, I am not browsing it on the >> web.) > > licensecheck supports SPDX, you just have to run it with > "--shortname-scheme spdx". In my recent & limited experience, licensecheck did not produce valid SPDX output in many cases. As an example, take a file with the following license header: /* * test-run-command.c: test run command API. * * (C) 2009 Ilari Liusvaara * * This code is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ I expect it to return GPL-2.0-only, but it returns GPL-2: $ licensecheck --shortname-scheme spdx t/helper/test-run-command.c t/helper/test-run-command.c: GPL-2 I did not see any files in the git source labeled with the appropriate SPDX identifier for GPL-2.0*. Similar for LGPL. For BSD-3-Clause, licensecheck used a lower-case C, which then fails to match a valid license in rpmlint. Am I missing something obvious or does licensecheck not work as expected? This is with licensecheck-3.3.0-2.fc36.noarch. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: pypolicyd-spf-2.9.3 crashes Postfix
Hi, Sylvain Jones via epel-devel wrote: > It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x > crashes Postfix unexpectedly. Perhaps a missing dependency? It looks like pypolicyd-spf-2.9.3-2 should be in epel-testing now. That update will install python3-authres, so you may way to clean up the pip-installed copy you mention below. https://bugzilla.redhat.com/show_bug.cgi?id=2142476 > Seems to be ahead from what I assume the upstream is, pip. > Is this an error? Installing authres via pip was able to > fix things without installing pypolicyd-spf via pip. The upstream project was renamed some time ago. It is now called spf-engine, which is at 2.9.3 in pypi as well. https://bugzilla.redhat.com/show_bug.cgi?id=1801011 -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Karma for OpenSSL needed
Ian Laurie wrote: > On 11/2/22 04:22, Dmitry Belyavskiy wrote: > > Dear colleagues, > > I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as HIGH. > Could you please check the freshly pushed builds to get necessary karma > ASAP? > > Are we not fixing Fedora 35? It won't be EOL until mid December (delays in 37 > pushed it out a few times). Fedora 35 has openssl-1.1.1q-1.fc35. It's not vulnerable to the issues patched today in openssl-3.0.7. :) -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Failed RPM database migrations
Hi, Richard W.M. Jones wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2 > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > https://bugzilla.redhat.com/2042099 > > The RPM database is supposed to move from /var/lib/rpm to > /usr/lib/sysimage/rpm. This was supposed to happen automatically when > you upgraded the rpm package from an earlier version to 4.17.0-10.fc36 > (Feb-Mar 2022). > > On several machines it is reported that the migration was only half- > completed. The symptoms are that the RPM database is still in > /var/lib/rpm (/usr contains symlinks to it). See typical output from > failed & successful migrations at the end of the email. > > So _if_ you have rpm >= 4.17.0-10.fc36 installed: > > - Do you see the symptom of a failed migration? Or does it appear >to be successful? (Or neither case??) > > - Did you: > * Install F37 or Rawhide from scratch? > * Upgrade using ordinary dnf update or similar? > * Upgrade using dnf system-upgrade? > * Some other install/upgrade method? I upgraded two systems from f35 to f36 in the past week via dnf system-upgrade. Neither of them completed the rpm migration. I _think_ the issue is due to the version-release in the %triggerun which should enable the rpmdb-migrate service. That is: %triggerun -- rpm < 4.17.0-7 # Handle rpmdb migrate service on erasure of old to avoid ordering issues if [ -x /usr/bin/systemctl ]; then systemctl --no-reload preset rpmdb-migrate ||: fi That was accurate when it was added in 0b9f813 (Migrate rpmdb to /usr/lib/sysimage/rpm (#2042099), 2022-01-26). However, when rpm was updated in f35 in e9927df (Rebase to rpm 4.17.1 (http://rpm.org/wiki/Releases/4.17.1), 2022-07-01), which never had the migration code, it prevented any up-to-date f35 system from triggering the migration. Anyone upgrading from f35 after rpm-4.17.1 was pushed to f35 won't have the rpmdb-migrate service enabled and the database will remain in /var/lib/rpm (with .migratedb) and symlinks in /usr/lib/sysimage/rpm. It seems that it's not so much a failed migration as a migration which is never attempted. :/ -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL7 repo error for distribution-gpg-keys?
manuel wolfshant wrote: > On 10/22/22 00:22, Troy Dawson wrote: >> >> distribution-gpg-keys-1.78-1.el7 is currently in testing. >> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0 >> >> You can get things moving my using the epel-testing repo >> yum --enablerepo=epel-testing update mock-core-configs > > s/distribution-gpg-keys/distribution-gpg-keys :) I presume s/mock-core-configs/distribution-gpg-keys/ is what you meant? ;) But since the OP was trying to install mock-core-configs and hitting the issue, installing that package with the epel-testing repo enabled would seem to be the quicker way to the end goal. Thanks to the karma you each left, the update is on the way to the stable repo now. (I added another, but only because I had done the testing before I noticed that it only needed 2 positive karma points.) -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
rpmlint %forgeautosetup support (was: Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal))
Hi, Sergey Mende wrote: >> Mildly related, I've been working on getting rpmlint updated >> to 2.3.0 and now 2.4.0. I filed a PR to get comments from >> other rpmlint maintainers and (hopefully) catch any bugs I >> may have introduced: >> >> https://src.fedoraproject.org/rpms/rpmlint/pull-request/27 > > A bit off topic, but it would be nice to make rpmlint > recognize `forgeautosetup` (a simple change of > `autosetup_regex` in rpmlint/checks/SpecCheck.py). I doubt > that this change would be accepted upstream as it is > fedora-specific. What you would suggest to get it through. > Sorry for that simple question, I am quite new here, so > not familiar with all workflows yet. Ahh, that affects spec files which use %forgeautosetup and have patches, right? They get `patch-not-applied` warnings. It may be worth asking upstream. Such a trivial adjustment¹ to the regex might be acceptable. If not, perhaps they'll have a good idea for how to best override that downstream. It appears that would require a patch at the moment, while it would be nicer if we could adjust the regex in a config file. ¹ The patch would look like this, for anyone curious: diff --git i/rpmlint/checks/SpecCheck.py w/rpmlint/checks/SpecCheck.py index 71d3ede6..95b4635e 100644 --- i/rpmlint/checks/SpecCheck.py +++ w/rpmlint/checks/SpecCheck.py @@ -71,7 +71,7 @@ setup_regex = re.compile(r'%setup\b') # intentionally no whitespace before! setup_q_regex = re.compile(r' -[A-Za-z]*q') setup_t_regex = re.compile(r' -[A-Za-z]*T') setup_ab_regex = re.compile(r' -[A-Za-z]*[ab]') -autosetup_regex = re.compile(r'^\s*%autosetup(\s.*|$)') +autosetup_regex = re.compile(r'^\s*%(forge)?autosetup(\s.*|$)') autosetup_n_regex = re.compile(r' -[A-Za-z]*N') autopatch_regex = re.compile(r'^\s*%autopatch(?:\s|$)') -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Miro Hrončok wrote: > On 03. 10. 22 12:09, Vít Ondruch wrote: >> And how is this change related to: >> >> https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide > > I was unaware of this change at all. > > Tom, should rpmlint ditch that file instead and Require > rpmlint-fedora-license-data? I'm not Tom (and I have not been asked to play Tom on TV), but I think that sounds like a good plan. Maintaining this data in two places is at least one more place than we'd like to have to maintain it. Thanks for working on automatic generation of the license data in rpmlint format Miro! And thanks to Miroslav and everyone who has worked on fedora-license-data. Hooray for not having to screen scrape the wiki for license data! Mildly related, I've been working on getting rpmlint updated to 2.3.0 and now 2.4.0. I filed a PR to get comments from other rpmlint maintainers and (hopefully) catch any bugs I may have introduced: https://src.fedoraproject.org/rpms/rpmlint/pull-request/27 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Kevin Fenzi wrote: > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote: >> Isn't peer review much better and easier solution over all? We could also >> require signed commits I guess. > > I think it would slow things down quite a lot to require peer review of > every commit. > > I'd personally like to avoid anything where we need to support gpg. > It's a mess and I think it would waste a lot of cycles explaining how to > use it or help people get setup. ;( If there's some easier/more clear > way to sign things that could be a option tho. Since git-2.34 (released in November of last year), ssh may be used for signing commits and/or pushes. That's likely a bit simpler than gpg. On the other hand, if it's cached by ssh-agent and/or uses the same key used to connect to dist-git, it might not add as much to the security as we might want. But it may be an option, in case it spurs anyone to come up with a change which improves security and doesn't add too much additional burden. You mentioned ecdsa-sk / ed25519-sk FIDO authenticator algorithms earlier. Git ssh-signed commit/push might be useful if/when other parts of our infrastructure can make use of those key types. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The future of FMN (Fedora Messaging Notifications)
Kevin Fenzi wrote: > Lest it sound like everyone just wants it to behave this way, I > personally _do_ like getting emails for actions I did myself. > I find that later when I am looking back to see what changed by who I > can (sometimes surprisingly) find out it was me. :) > > So, I would prefer this be a pref (perhaps set to not notify by > default?) I'd second that. I wouldn't want to lose the ability to get those notifications entirely. I'm happy to adjust the settings to do that¹. I send them via email and filter them, so I use it as a historical log more than an immediate notification. But they are good as a confirmation that an action has made its way through the system, as well. ¹ I hope that the settings can be simplified a bit. The current setup is quite powerful but is rather difficult to understand, particularly because it's not something most of us do very often. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: More is not Less
Hi, Ron Olson wrote: > Sorry if I missed something, but under Rawhide I > discovered when I tried to “more somefile.txt” I got > “less” behavior, while Fedora 35 still runs more like, uh, > more. I'm not quite sure what "less" behavior you mean, so I'm only guessing. If you mean that more doesn't exit automatically when you reach EOF, that looks to be due to: df6b29d3b (more: POSIX compliance patch preventing exit on EOF without -e, 2021-09-29)¹ ¹ https://github.com/util-linux/util-linux/commit/df6b29d3b -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GitHub source URLs not working
Fabio Valentini wrote: > Fri, Nov 26, 2021 at 8:37 PM Susi Lehtola >> I am experiencing problems updating packages employing GitHub source >> URLs. For instance, [...] >> https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz >> Download failed: >> 404 Client Error: Not Found for url: >> https://codeload.github.com/pyscf/pyscf/tar.gz/v2.0.1/pyscf-2.0.1 [...] >> The URLs used to work. Has anyone else noticed the same problem? > > Yes, I've experienced similar problems today. > > If this is not a bug but a deliberate change by GitHub, it's going to > be a major PITA to fix all those .spec files for sources hosted on > GitHub ... > So ... does anybody know (or can find out) whether it's the former or > the latter? https://www.githubstatus.com/ shows most github services are having issues. That (hopefully) indicates the source download issues are part of the outage rather than an intentional change¹. https://www.githubstatus.com/incidents/r5qrpp2f5fc0 is the direct incident URL, I believe. ¹ but it could be an intentional change which has also led to -or simply coincided with- an outage. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPMLint 2.0 released!
Miro Hrončok wrote: > On 03. 06. 21 21:51, Tom Callaway wrote: >> I have landed rpmlint 2.0.0 in rawhide, along with Mirek Suchý's toml >> configs (with updates for the licenses.toml). PRs, bug reports, and >> suggestions welcome. > > Thanks, spot! > > I'm looking at the stuck Python 3.10 rebuild due to the s390x builder outage: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=69342995 > > And I wonder whether the package should be noarch? Do you recall why it is > not? The build above is rmlint (no 'p') -- it took me a minute to two to notice that. The rpmlint package is noarch. This appears to be the rpmlint build in the f35-python side tag: https://koji.fedoraproject.org/koji/taskinfo?taskID=69362379 That build did fail too: DEBUG util.py:444: Error: DEBUG util.py:444: Problem 1: conflicting requests DEBUG util.py:444:- nothing provides python(abi) = 3.9 needed by python3-pytest-flake8-1.0.6-3.fc34.noarch DEBUG util.py:444:- nothing provides python3.9dist(pytest) >= 3.5 needed by python3-pytest-flake8-1.0.6-3.fc34.noarch DEBUG util.py:444: Problem 2: conflicting requests DEBUG util.py:444:- nothing provides python(abi) = 3.9 needed by python3-zstd-1.4.5.1-3.fc34.i686 It looks like that's due to building rpmlint before all of its build deps were rebuilt for python 3.10? -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: git push permission denied
Tony Breeds wrote: > One annoying gotcha I hit after adding the new key to my agent was that > many places now failed to auth as it tried each key in my agent and > exceeded the MaxAuthTries in sshd The IdentitiesOnly option to ssh is useful for that. From ssh_config(1): Specifies that ssh(1) should only use the configured authentication identity and certificate files (either the default files, or those explicitly configured in the ssh_config files or passed on the ssh(1) command-line), even if ssh-agent(1) or a PKCS11Provider or SecurityKeyProvider offers more identities. The argument to this keyword must be yes or no (the default). This option is intended for situations where ssh-agent offers many different identities. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow
Pierre-Yves Chibon wrote: > On Fri, Feb 05, 2021 at 12:11:45PM +0100, Florian Weimer wrote: >> Would it be possible to add the sequence of commands to the proposal to >> convert an existing clone with unpushed changes? >> >> I think it is something along the lines of (for src.fedoraproject.org): >> >> git checkout master >> git branch --move rawhide >> git branch --set-upstream-to=origin/rawhide >> >> I'm not entire sure if “rawhide“ is the correct branch to use, and if >> the sequence of commands is the right one. > > All of the above is correct. > > I'll add it to the wiki page, thanks for the suggestion! The `git checkout master` (or `git switch master`) can be omitted (at the slight cost of being more verbose with the `git branch` commands). git fetch # optionally with -p / --prune git branch -m master rawhide git branch -u origin/rawhide rawhide For folks that might have a different branch checked out with changes on it, the attempt to switch branches will just get in the way. I had some clones which were on branches other than master and which contained changes. I ran this in my Fedora git tree: for i in /path/to/dist/fedora/*/; do ( pushd $i && git fetch -p && git branch -m master rawhide && git branch -u origin/rawhide rawhide ) done |& tee /path/to/output Anyone who has used a remote name other than 'origin' will have to adjust that part of the command, of course. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: src.fedoraproject.org branch conversion status
[re-sending to devel instead of devel-announce, apologies if this arrives twice.] Kevin Fenzi wrote: > Greetings everyone and thanks for your patience with us today. Thank you Kevin and all the folks who help make such changes happen relatively seamlessly. :) > You will want to re-clone any repos you have that have changed, or pull > changes and switch to the new branch. In case it's helpful (and not better documented elsewhere), it's possible to rename your existing local master branch to rawhide and adjust the upstream tracking branch. In a typical dist-git clone from the rpms tree, you'd do this: git fetch && git branch -m master rawhide && git branch -u origin/rawhide rawhide The -u option is the short form of --set-upstream-to. That should make the switch relatively simple for folks, I hope. It's easier than making a fresh clone, for me. -- Todd ~ The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. -- Bill Watterson (Calvin and Hobbes) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Ian McInerney wrote: > Why not split the cvs package like git and create a cvs-core package that > actually contains the cvs executables/files and then only BR/require that > from git/git-cvs? That would be the more immediate solution that prunes the > affected packages from the xinetd orphaning by quite a lot. The cvs package _is_ split up. Git doesn't BR cvs-inetd or anything. The reason this dep chain is in the list is because *iff* xinetd were to be removed (without cvs dropping the BR), then cvs would be removed, taking git along with it (if git did not drop its cvs BR). That's certainly _not_ going to happen though. ;) I don't think there's much doubt about the ease of a fix, should one be required. If xinetd goes away, cvs can simply drop the inetd subpackage. But someone may pick up xinetd and make that moot. Failing either of those outcomes, git can drop its cvs BR & subpackage easily. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Sérgio Basto wrote: > Like tftp we may replace xinetd by systemd service files [1] , > if we replace cvs-inetd by a systemd service, the problem is solved. > > [1] > https://src.fedoraproject.org/rpms/tftp/c/15a26fcde8a0078766b6bbba183d89f920e51535?branch=master The cvs package has supported systemd for years. There is simply an inetd subpackage which provides support for xinetd still. If xinetd is left orpahaned and retired, dropping the inetd subpackage from cvs might look something like: https://src.fedoraproject.org/fork/tmz/rpms/cvs/c/ee901571db I didn't file that as PR yet because it's not clear whether xinetd will be adopted or not. But it should be relatively easy for us (in the sense of most any interested packager) to remove the xinetd dep from cvs. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi,
Richard W.M. Jones wrote:
> On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote:
>> The cvs and cvsps BR's are for the test suite, since we
>> prefer to use the comprehensive test suite that git
>> includes. So dropping those BR's is not a useful option.
>
> The test suite still ran, and the subpackage still got built.
>
> However in the test suite the cvsimport tests were skipped:
>
> t9600-cvsimport.sh . skipped: skipping
> cvsimport
> tests, cvs not found
> t9601-cvsimport-vendor-branch.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9602-cvsimport-branches-tags.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9603-cvsimport-patchsets.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9604-cvsimport-timestamps.sh .. skipped: skipping
> cvsimport
> tests, cvs not found
Yep, exactly. If we simply removed the BR's, we'd just be
shipping a subpackage with commands that weren't tested and
wouldn't work without cvs. Not a good user-experience. :)
I'll keep my eye on the progress of removing the xinetd
dependency from cvs and will be sure to disable cvs in git
if that doesn't happen for some reason. Hopefully it
doesn't come to that.
In that case, a change like this should be all we need:
diff --git i/git.spec w/git.spec
index 5188290..e85363b 100644
--- i/git.spec
+++ w/git.spec
@@ -66,8 +66,8 @@
%endif
# Allow cvs subpackage to be toggled via --with/--without
-# Disable cvs subpackage by default on EL > 7
-%if 0%{?rhel} > 7
+# Disable cvs subpackage by default on Fedora >= 34 and EL > 7
+%if 0%{?fedora} >= 34 || 0%{?rhel} > 7
%bcond_with cvs
%else
%bcond_without cvs
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Richard W.M. Jones wrote: > On Mon, Nov 09, 2020 at 12:09:00PM +0100, Miro Hrončok wrote: >> rjones: xinetd, numad > > Your "packager dashboard"[1] which I found for the first time today is > very useful! > > Turns out the problem for my package is this weird ol' dependency chain: > > coccinelle -> git -> cvs -> xinetd > > Well the first part of that is understandable, because Cocci uses git > to apply patches (ie. autosetup -S git). > > cvs -> xinetd is sort of understandable too. > > git -> cvs however(!) It turns out that git has a cvs import > subpackage. But I wonder if git actually needs cvs around at build > time to create this? I commented out the BR: cvs, cvsps lines in the > spec file and it built a cvs import subpackage just fine for me. The cvs and cvsps BR's are for the test suite, since we prefer to use the comprehensive test suite that git includes. So dropping those BR's is not a useful option. Either cvs will drop it's dependency on xinetd and this problem will be moot or it won't and cvs will be removed from Fedora. In the latter case, having git ship the git-cvs subpackage would be silly. If cvs gets dropped, we'll likely drop the git-cvs subpackage entirely (as was done for EL8 -- we have a %bcond_with/%bcond_without cvs in place already). I expect that the xinetd dep in cvs will be removed, but if it turns out no one cares about cvs and that doesn't happen, removing the cvs dep from git will be trivial enough. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
Michael J Gruber wrote: >> = NOTE about xinetd = >> >> Many packagers are listed as affected by xinetd. The dependency chain is: >> >> cvs (kasal, ppisar) >> cvs-inetd.noarch requires xinetd >> >> git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) >> git.src requires cvs >> git-cvs.noarch requires cvs >> >> ( ) >> requires git >> >> Note that if xinetd indeed goes away, your package will most likely not be >> affected, unless you actually need git-cvs. >> >> = end NOTE = > > Also, git requires only the client functionality, not cvs-inetd itself. So it > would be good to get input from the former xinetd maintainer whether > - xinetd should be retired fro some reason (and cvs should retire the > cvs-inetd subpackage) > - or xinetd should simply be picked up. > > Thanks for the clear info about the dependency, btw. It would have been easy > to miss otherwise. Indeed, thanks Miro and Michael! _If_ it comes to it, the git package has a conditional for building without CVS. It's trivial to change the default for f34+ and avoid the cvs dep. It seems likely that cvs can drop the inetd subpackage without much trouble though, so it shouldn't come to that. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
I wrote: > Zdenek Dohnal wrote: >> CCing Git maintainer to see whether it can be implemented or not. I somehow forgot to say that I'm just one of several maintainers for the git package. :) I've Cc'd the git-maintainers alias to include the other folks. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Hi,
Zdenek Dohnal wrote:
> To be honest, I'm sad about the change.
It is just a default though, and I'll certainly change it on
my systems. But like many others, I too can still recall
(decades ago) being dumped into vi and having no clue how to
do anything -- including just exiting.
> I'm not sure if which other applications use the default editor, I know
> only git from those. So let's say I will talk about the editor which
> git-commit spawns during committing a change.
Anywhere EDITOR or VISUAL isn't set, plenty of tools default
to /bin/vi. It's much, much more than just git -- even if
that is a fairly common way for users to end up in vi these
days.
> What about this - Git could generate a message within the comments
> during commit:
>
> 'Using editor: {message}'
>
> In case of Vi:
>
> 'Using editor: Vi , for more info type :help'
>
>
> Or nano:
>
> 'Using editor: nano'
>
> CCing Git maintainer to see whether it can be implemented or not.
Doing this would clutter the instructions for making the
commit itself and would be a distraction IMO. I would also
be very hesitant to make such an adjustment to the default
git commit template anywhere but upstream.
While I very much prefer vim to nano myself, it's hard for
me to argue that dropping someone who's never used vi into
it is a great default. It's not nearly as convenient or
useful as it could be for a new user. It's wonderful and
powerful once you know it, but I don't think that makes it a
good default.
Since git is far from the only place a user might find
themselves in the default $EDITOR, we'd end up having to add
similar instructions for all (or many) of those tools.
(At that point, we'd be better off adding it to vi in some
manner -- and dealing with the inevatible fallout of what
that breaks. That all seems like far more work than it's
worth.)
I think the fact that we'd even need to include such
instructions for how to use the editor is a sign that the
editor might not be a great _default_.
With this change adding a nano-default or such subpackage,
perhaps other editor packages will eventually offer a
similar subpackage to make them the default? (Effectively
what Debian's got with the 'editor' alternative.)
Then users/admins who want to quickly deploy a different
system-wide default could do so (in a manner consistent with
how we're setting nano as the default)?
If the result is that more users learn about the wide
variety of useful and powerful editors available in Fedora,
that's a good outcome.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
Hi, E.N. virgo wrote: >> Why are replying from there instead of using your email client normally? > I set this list to send digests instead of individual messages; > so, I was using other means to get to the in-reply-to field. If you're using the "Plain Text Digests" delivery mode, you might try switching to the "Mime Digests" mode. If your mail client is moderately decent, using the mime digests will get you a single delivery where each message is a separate MIME part. Then you can reply to an individual message and keep the threading intact (again, assuming your mail client is half decent at handling MIME parts). At the least, you'd then easily have the In-Reply-To headers if you had to manually add them. :) (It's been ages since I tested the mime digest option, certainly prior to Mailman 3. But I don't have any reason to suspect they won't work as well or better now as they did then.) -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [External] Re: Fedora+Lenovo
Markus Larsson wrote: > While I'm fine with spending 2500€ of company money on a > work machine, I'm rather hesitant to spend that kind of > money on laptops for the kids :) Isn't that where some good, old-fashioned nepotism comes in? The kids get a title, a valuable first entry on their CV, and a company laptop? ;) More seriously, it's nice to see this announcement. Thanks to all the folks who worked to make it happen! -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git-core deps under f32
I wrote: > clime wrote: >> It seems the f32's git-core got many more deps for some reason, even >> such as dbus-broker or systemd. [...] > I'll try to poke a bit in the next few days as I can make > some time. I had not noticed the inflated depchain. Thank > you for pointing it out. I was curious, so I looked at this tonight. The git-core requires are the same on f31 and f32: $ diff -qs \ <(rpm -qp --requires git-core-2.25.2-1.fc31.x86_64.rpm 2>/dev/null) \ <(rpm -qp --requires git-core-2.26.0-1.fc32.x86_64.rpm 2>/dev/null) Files /dev/fd/63 and /dev/fd/62 are identical Checking each of those deps, openssh-clients grew a dep on libfido2, which in turn requires u2f-hidraw-policy that is provided by systemd. That looks like the main chain which leads to the additional packages installed in a mock chroot. In a fedora 32 container (and most "regular" installs), systemd is already present, so the change should have very little impact outside of mock or other targets which are smaller than the default fedora 32 container image. I don't think that git-core should drop openssh-clients and it seems pretty reasonable for openssh-clients to require libfido2 to enable two factor authentication. Does that sound alright to you as well, clime? -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git-core deps under f32
Hi, clime wrote: > Hello, > > I very much appreciate the git-core package but there seems to be some > change under f32 which makes it download many more deps during > installation. > > This is f32: > > $ mock -r fedora-32-x86_64 install git-core > ... > = > Package > = > Installing: > git-core > Installing dependencies: > acl > cryptsetup-libs > dbus > dbus-broker > dbus-common > device-mapper > device-mapper-libs > fipscheck > fipscheck-lib > gnutls > iptables-libs > json-c > kmod-libs > less > libargon2 > libcbor > libedit > libfido2 > libmnl > libnetfilter_conntrack > libnfnetlink > libpcap > libseccomp > nettle > openssh > openssh-clients > qrencode-libs > systemd > systemd-pam > systemd-rpm-macros > > Transaction Summary > = > Install 31 Packages > > Total size: 14 M > Installed size: 60 M > ... > > This is f31: > ... > = > Package > = > Installing: > git-core > Installing dependencies: > fipscheck > fipscheck-lib > less > libedit > openssh > openssh-clients > > Transaction Summary > = > Install 7 Packages > > Total download size: 6.1 M > Installed size: 35 M > ... > > It seems the f32's git-core got many more deps for some reason, even > such as dbus-broker or systemd. Out of curiosity, do you notice the same deps if you install git-core-2.26.0 from: https://copr.fedorainfracloud.org/coprs/g/git-maint/git/ on f31? I'll try to poke a bit in the next few days as I can make some time. I had not noticed the inflated depchain. Thank you for pointing it out. Off hand, there's nothing which comes to mind as a newly added dependency in the git-core package that I would expect to pull in much more on f32. Is it possible that the chroot which mock provides for f32 is smaller than for f31 and the new deps aren't so much new as newly exposed? (I haven't checked that at all, so it's just an idle thought.) If nothing jumps out as a result of this thread, it might be good to file this in bugzilla so we can track it there. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rubygem-asciidoctor Fedora 31 update
Hi Ivan. Ivan Chavero wrote: > Are there any plans to upgrade the spec file of rubygem-asciidoctor for > Fedora 31 to the 2.0.10 version? Unfortunately, I don't think it would be an appropriate update for Fedora 31. And update from 1.5.6 to 2.0.10 would cause some package builds to break and that would be needless pain for maintainers on F31 -- particularly those who might need to push an important bugfix or security update. It was unfortunate that we missed the window to get the 2.0.10 update into Fedora 31 before it was released. Hopefully things will stay closer to upstream going forward. My main interest in asciidoctor stems from using it for building Git's documentation. Upstream Git has done some great work to make asciidoctor well-supported as an alternative to asciidoc in the past few releases. I switched the Fedora git packages to asciidoctor recently (even on Fedora 31 with its older asciidoctor release). -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F32 (gcc) compiler cannot create executables due to annobin
Jakub Jelinek wrote: > On Sat, Mar 14, 2020 at 11:54:54PM +0100, Dominik 'Rathann' Mierzejewski > wrote: >>> Known issue? >> >> The above was with gcc-10.0.1-0.9.fc32 and annobin-9.06-1.fc32. >> >> Looks like it was fixed in the meantime as another build gets >> gcc-10.0.1-0.8.fc32 and the same annobin now. > > One either needs gcc-10.0.1-0.9.fc32 and annobin-9.06-4.fc32 or > gcc-10.0.1-0.8.fc32 and annobin-9.06-1.fc32. > gcc-10.0.1-0.9.fc32 has been briefly as a buildroot override in order > to rebuild annobin, but later on somebody asked for the override again > without asking for an annobin override too. > Right now both older packages should be in the buildroots, and the > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d927e07eb1 > errata needs some karma before it can be tagged in. What's a good way to test that gcc build so we can give karma? I'm pretty sure it addresses the git build issue on s390x (as it does in rawhide), but I'd like to do an s390x build on f32 to confirm that before I provide karma. It feels wrong to provide karma based on an "it worked in rawhide" test. :) I could probably run it in mock with the s390x emulation if I'm willing to wait a day for the results. (I'm not sure that's much of an exaggeration if my memory of the last time I tried it to run a full git build is accurate.) -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: ClamAV - was Re: Question
Andrew C Aitchison wrote: > On Sun, 9 Feb 2020, Pete Geenhuizen wrote: > >> Is this the right list to ask about the status of ClamAV 0.102.1 and >> when it will be released? >> If this is not the right list please tell which list I to which I >> should direct this question. > > I don't have answers for that, but I would imagine this is the right place. FWIW, a similar question came up on the Fedora devel a few days ago, in relation to the release on 0.102.2 which fixes a DoS bug in clamd. That thread is here: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/I5MP26TOBE433G22JG5CWHKNGM74CF5U/ It was noted that the security issues fixed in 0.102.2 only affects 0.102.x and that Fedora and EPEL remain on the 0.101.x series at the moment. That may be tangential to your question about an update to the 0.102.x series in general. But if you were worried particularly because of some security vulnerabilities, it might help you rest a little easier. -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: How to reuild wdune ?
Fabio Valentini wrote: > On Mon, Dec 23, 2019, 17:45 J. Scheurich wrote: >> $ git commit >> error: gpg failed to sign the data >> fatal: failed to write commit object >> >> Same problem 8-( >> > Looks like you have the option to sign your git commits turned on globally, > probably in ~/.gitconfig or something. The --show-origin option to git config is handy for finding where you've set the option. E.g.: git config --show-origin --get commit.gpgSign -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Trouble with install ordering and SELinux config
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.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: Asciidoctor 2.0.10
Hi, I wrote: > I'm planning to push asciidoctor-2.0.10 to rawhide in the > next few days. This has now been built and should show up in the next rawhide compose. > This is a major bump from our current 1.5.8, but upstream > has worked hard to fix regressions found since the initial > 2.0.0 release back in March. > > The 2.0.0 release notes can be found at: > > https://github.com/asciidoctor/asciidoctor/releases/tag/v2.0.0 > > The subsequent minor release are covered at: > > https://github.com/asciidoctor/asciidoctor/releases -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: Asciidoctor 2.0.10
Hi Fabio, Fabio Valentini wrote: > I'm the maintainer of rubygem-jekyll-asciidoc, and I think there > shouldn't be issues with it when updating rubygem-asciidoctor. > The Jekyll AsciiDoc plugin is published by the asciidoctor project > themselves, so I just hope they know what they're doing :) Heh, I hope so also. We'll find out soon, as I've just built asciidoctor-2.0.10 in rawhide. -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: Asciidoctor 2.0.10
Hi Robert-André, Robert-André Mauchin wrote: > Using Igor's whatrequires script > (https://gist.github.com/ignatenkobrain/a2b21a4db497a2a4b441e3957fcc8483), we > get: Nice. I didn't know about that one either. > PACKAGE DEPENDENT > DEPENDENCIES > rubygem-asciidoctor-1.5.6.1-6.fc30.noarch > rubygem-asciidoctor-pdf-1.5.0-0.10.alpha.18.fc31.noarch (rubygem(asciidoctor) > >= 1.5.3 with rubygem(asciidoctor) < 3.0.0) > > rubygem-jekyll-asciidoc-2.1.1-3.fc31.noarch rubygem(asciidoctor) > >= 1.5.0 > awesome-4.3-2.fc31.src > asciidoctor > > booth-1.0-3.f2d38ce.git.fc31.2.src asciidoctor > esh-0.3.0-1.fc31.src > /usr/bin/asciidoctor > hugo-0.55.6-1.fc31.src > rubygem-asciidoctor > ipmctl-01.00.00.3469-1.fc32.src > asciidoctor > johnzon-0.9.4-7.fc30.src > /usr/bin/asciidoctor > js8call-1.1.0-2.fc31.src > rubygem-asciidoctor > libzypp-17.14.0-1.fc32.src > /usr/bin/asciidoctor > > mod_auth_mellon-0.14.2-2.fc31.src rubygem-asciidoctor > nanomsg-1.1.5-2.fc31.src > rubygem-asciidoctor > ndctl-66-1.fc31.src > rubygem-asciidoctor > nng-1.1.1-3.fc31.src > rubygem-asciidoctor > oidentd-2.4.0-1.fc32.src > rubygem-asciidoctor > qpid-dispatch-1.8.0-3.fc32.src > rubygem-asciidoctor > rubygem-chake-0.17.1-3.fc31.src > rubygem(asciidoctor) > > rubygem-jekyll-asciidoc-2.1.1-3.fc31.srcrubygem(asciidoctor) > rubygem-slim-3.0.9-4.fc31.src > rubygem(asciidoctor) > rubygem-tilt-2.0.8-6.fc31.src > rubygem(asciidoctor) > tuned-2.12.0-3.fc32.src > asciidoctor > usbguard-0.7.2-8.fc31.src > asciidoctor > weechat-2.4-4.fc32.src > asciidoctor >= 1.5.4 > wiki2beamer-0.10.0-2.fc31.src > rubygem-asciidoctor > wsjtx-2.1.0-2.fc31.src > rubygem-asciidoctor > zypper-1.14.29-1.fc32.src > /usr/bin/asciidoctor Fortunately, it appears the only package this turns up which the others have not is johnzon. But that's because that package was recently retired due to being orphaned for longer than 6 weeks. Thanks, -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: Asciidoctor 2.0.10
Hi Miro,
Miro Hrončok wrote:
> On 25. 09. 19 17:10, Todd Zullinger wrote:
>> dnf repoquery -q --qf '%{name}' --archlist=src --releasever=rawhide \
>> --disablerepo='*' --enablerepo=rawhide-source \
>> --whatrequires asciidoctor --whatrequires rubygem-asciidoctor
>
> When you don't include the rawhide repo, virtual provides are not checked.
> The more correct (arguably still broken, due to boolean requires) query is:
>
> $ repoquery --repo=rawhide{,-source} --whatrequires rubygem-asciidoctor
>
> If you only need BuildRequires (why?)
Good question. I probably didn't need to limit it to that.
(Maybe I'm used to thinking of compiled code, where the BR
is the package which most likely needs to be aware of the
change.)
Dropping that adds a few packages to the list:
esh
libzypp
zipper
Thanks for providing the examples and useful details.
Everytime I read about repoquery I learn a few new things.
--
Todd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: Asciidoctor 2.0.10
Hi Vit,
Vít Ondruch wrote:
> Dne 24. 09. 19 v 17:47 Todd Zullinger napsal(a):
>> These srpm's require asciidoctor or rubygems-asciidoctor:
>>
>> awesome
>> booth
>> hugo
>> ipmctl
>> js8call
>> mod_auth_mellon
>> nanomsg
>> ndctl
>> nng
>> oidentd
>> qpid-dispatch
>> tuned
>> usbguard
>> weechat
>> wiki2beamer
>> wsjtx
>
>
> Are you sure you have used correct query? Looking just for
> rubygem-asciidoctor, this is an output of my query:
>
> hugo-0:0.55.6-1.fc31.src
> js8call-0:1.1.0-2.fc31.src
> mod_auth_mellon-0:0.14.2-2.fc31.src
> nanomsg-0:1.1.5-2.fc31.src
> ndctl-0:66-1.fc31.src
> nng-0:1.1.1-3.fc31.src
> oidentd-0:2.4.0-1.fc32.src
> qpid-dispatch-0:1.8.0-3.fc32.src
> rubygem-asciidoctor-doc-0:1.5.6.1-6.fc30.noarch
> rubygem-asciidoctor-pdf-0:1.5.0-0.10.alpha.18.fc31.noarch
> rubygem-chake-0:0.17.1-3.fc31.src
> rubygem-jekyll-asciidoc-0:3.0.0-1.fc32.noarch
> rubygem-slim-0:3.0.9-4.fc31.src
> rubygem-tilt-0:2.0.8-6.fc31.src
> wiki2beamer-0:0.10.0-2.fc31.src
> wsjtx-0:2.1.0-2.fc31.src
Ahh, I see. I missed that some of the rubygem's use
rubygem(asciidoctor) as the BuildRequires. That covers
rubygem-chake, rubygem-slim, and rubygem-tilt.
The rubygem-{asciidoctor-pdf,jekyll-asciidoc} packages don't
BuildRequire asciidoctor, so my search wouldn't have picked
them up. I only looked for BuildRequires. I'm sure others
use asciidoctor at run time, but I only intended to directly
bcc package owners who BuildRequire asciidoctor.
FWIW, the query I used was:
dnf repoquery -q --qf '%{name}' --archlist=src --releasever=rawhide \
--disablerepo='*' --enablerepo=rawhide-source \
--whatrequires asciidoctor --whatrequires rubygem-asciidoctor
I should have added --whatrequires 'rubygem(asciidoctor)' as
well. I've added those rubygem package owners to Bcc to let
them know asciidoctor-2.0.10 is coming soon. Thanks for
checking and pointing that out!
> Also, we currently have just rubygem-asciidoctor-1.5.6,
> because it seems that 1.5.8 has never been built ...
In any case, it's long out of date. :)
My personal interest in asciidoctor is as a replacement for
asciidoc with the git documentation. I've worked a little
upstream with git and asciidoctor and submitted some PRs for
the asciidoctor package. Recent work by a few other folks
in the git project has greatly improved the results when
using asciidoctor for git.
--
Todd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS-UP: Asciidoctor 2.0.10
Hi all, I'm planning to push asciidoctor-2.0.10 to rawhide in the next few days. This is a major bump from our current 1.5.8, but upstream has worked hard to fix regressions found since the initial 2.0.0 release back in March. The 2.0.0 release notes can be found at: https://github.com/asciidoctor/asciidoctor/releases/tag/v2.0.0 The subsequent minor release are covered at: https://github.com/asciidoctor/asciidoctor/releases Most packages shouldn't really notice the change. But there are likely some which have relied on things which worked in 1.5.8 that may have been changed. One notable change is the removal of docbook 4.5 support (in favor of docbook 5). This can impact packages which use asciidoctor to generate intermediate xml that is then fed to xmlto. (The upstream git project is one such project, though in git we still default to asciidoc for now. And patches are landing upstream to support building with asciidoctor 2.x and docbook 5.) These srpm's require asciidoctor or rubygems-asciidoctor: awesome booth hugo ipmctl js8call mod_auth_mellon nanomsg ndctl nng oidentd qpid-dispatch tuned usbguard weechat wiki2beamer wsjtx I've included those package owners via Bcc:. If anyone needs me to hold off for a bit, please speak up. We do want to take this action soon though, so we can ensure any kinks get worked out well before we branch for f32. There's also an outstanding FTBFS bug for the current 1.5.8 package which this move to 2.0.10 conveniently fixes. -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Over 500 orphaned packages seeking new maintainers
Miro Hrončok wrote: > Note that jgit is not (yet) orphaned nor retired, and its dependencies might > be picked up by somebody. I suggest to remove the dep in rawhide temporarily > (to make the next weeks reports more readable and shorter to calculate (the > present one took 2 days)). Once the dust settles, the dependency can be > added back. Sounds good. I'm only going to droo it for %fedora > 30 in any case, since it's handy to run those tests for builds on previous releases (like in https://copr.fedorainfracloud.org/coprs/g/git-maint/git/). It's trivial to add it back if it gets rescued. Thanks, -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Over 500 orphaned packages seeking new maintainers
Hi, Pavel Cahyna wrote: > On Mon, Jul 29, 2019 at 12:59:22PM +0200, Miro Hrončok wrote: >> On 29. 07. 19 12:37, 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 >>> >>> 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. >>> >>> See the full report: >>> https://churchyard.fedorapeople.org/orphans-2019-07-28.txt >>> Grep it for your FAS username and follow the dependencies. >> ~380 packages can be unblocked if git stops buildrequiring jgit. > > This dependency is only for the testsuite. Todd, do you remember what > tests required it? (It was added in commit 6dc62852). As it happens, I do. There are 3 tests (out of many thousands) in the git test suit which use jgit. They test compatibility of the packfile format and ls-remote protocol. They're nice to have, but if jgit is another casualty of modularity, then it's easy to drop it. It's a mild shame, since jgit was just fixed after a few months of failing to even start. I'll remove the jgit dep in rawhide shortly. Thanks for the heads up Miro. And hi Pavel. :) -- Todd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: What happened to the 'python34-pycurl' and 'python34-mysql' packages?
Hi, Fred Gleason wrote: > On Wed, 2019-05-01 at 16:17 -0700, Kevin Fenzi wrote: >> Can you please refile that as two bugs? On python3-pycurl and >> python3-mysql? >> >> The python34 component is only for python34 itself, you will need to >> get >> those other two packages to fix things. > > I did attempt this initially, but the 'Component' field refuses to > accept 'python34-mysql' or 'python34-pycurl' as a valid value. What > should the proper value there be? The source packages for the python3X-* packages are generally python3-* and those are what are used in the bugzilla component field. So these should be under python3-mysql and python3-pycurl, respectively (which looks like what Kevin suggested :) ). -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
Neal Gompa wrote: > If devtoolset is available for EPEL6 (which I think it is?) I don't believe devtoolset was enabled for el6 in koji. When it was added to the mock configs for el6/el7, the consensus on the epel list was that it would be added to el6 if there was sufficient demand. I've only seen it come up once (or maybe twice) since then on the epel list. I'm not familiar enough with the koji commands to confirm it. I can see that rhel7-server-rhscl-7 is listed in the external repos, but I don't see a similar rhel6 SCL. Apologies if I simply missed an announcement on the epel lists and am passing on outdated data. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Could not execute import_srpm
Antonio Trande wrote: > On 09/04/19 22:29, Kevin Fenzi wrote: >> Can any of you folks seeing this: >> >> Run this script: >> https://paste.fedoraproject.org/paste/tWt5LBT13-~d22wBpo38uQ/raw >> >> and send me the output? > > Sorry, > > how this script works? You can download the script (using Patrick's fedorapeople URL is probably simplest): $ curl -O https://puiterwijk.fedorapeople.org/fedpkg_new-sources.sh Then make it executable and run it: $ chmod +x fedpkg_new-sources.sh $ ./fedpkg_new-sources.sh Usage: ./fedpkg_new-sources.sh rpms/project filename As the usage says, there are two arguments. One is the package name (with rpms/ prefixed in most cases). The second is the file you want to upload, just as you would pass to the 'fedpkg new-sources' command. In your case, the error occurred when trying to upload smoldyn-2.58.tgz, so based on the path in your error message, you'd want to run the following: $ ./fedpkg_new-sources.sh rpms/smoldyn /home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Orphaned packages to be retired (Java packages in 3 weeks)
Richard W.M. Jones wrote: > On Tue, Mar 12, 2019 at 11:38:47AM +0100, Miro Hrončok wrote: >> rjones: apache-ivy, maven-jar-plugin, maven-javadoc-plugin, gradle, >> xmvn, plexus-utils > > I'm unclear what if anything I could do (apart from maintaining loads > of Java packages which isn't going to happen). Is the email saying > that some package of mine depends on these? And if so which one? The list of the expanded deps was quite large, so Miro included a link to it in his message: >> Grep the list for your FAS name, follow the transitive deps: >> https://churchyard.fedorapeople.org/orphans-2019-03-11.txt $ grep rjones[^:] /tmp/orphans-2019-03-11.txt | sort -u erlang (maintained by: gemi, jeckersb, ndim, peter, rjones, skottler) libguestfs (maintained by: mdbooth, ptoscano, rjones) qemu (maintained by: amitshah, berrange, bonzini, crobinso, dwmw2, ehabkost, jforbes, lkundrak, quintela, rjones, virtmaint-sig) -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: question on spec file for building rpm with source file that includes python and C code
Hi,
Globe Trotter wrote:
> Thanks, and that takes care of it.
Glad that helped.
> Thanks also for letting me know of preferred options. I am
> quite new to this and so any advice is always helpful.
>
> I will see if the copr maintainer wants to host my build.
> fetchmail 7.0.0 alpha has support for oauth2
> authentication so is worth chasing. (Of course, I will
> test it first.)Thanks again!
Since you're building a pre-release version, you may want to
read the packaging guidelines on version/release tags:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_prerelease_versions
Rather than:
Version: 7.0.0.alpha6
Release: 1%{?dist}
You want something like:
Version: 7.0.0
Release: 0.1.alpha6%{?dist}
That will also require changes to the Source0 URL, and it
might be worth having the 'alpha6' string in a macro which
can be used in both the Release and SourceO tags.
Good luck,
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: question on spec file for building rpm with source file that includes python and C code
Hi, Globe Trotter wrote: > Here is my fetchmail.spec: [...] > %build > autoreconf -if > %configure PYTHON-: --enable-POP3 --enable-IMAP [...] You want "PYTHON=:", not "PYTHON-:". The goal is to set the PYTHON variable. I tend to put such definitions before the configure call, e.g.: %build autoreconf -if export PYTHON=: %configure --enable-POP3 --enable-IMAP But that may just be a matter of preference. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: question on spec file for building rpm with source file that includes python and C code
Hi,
[BTW, something is wrong with your mail client's quoting.
It is very hard to read your replies when your reply and the
text to which you are replying to are at the same quote
level.]
Globe Trotter wrote:
> Thanks! I see. Actually, I am not that keen on packaging
> fetchmailconf. I think that fetchmail users are able to
> edit their own files which do not change that frequently.
>
> So how do I get to ignore the python files? I am doing
> exactly the same as in the current released spec file. I
> must be missign something. Thanks!
It seems that you've added the python3-* BuildeRequires
which are not in the current Fedora fetchmail.spec. They
were removed from the Fedora fetchmail.spec in fda3158
("Remove unnecessary python-devel dependency", 2018-07-23):
https://src.fedoraproject.org/rpms/fetchmail/c/fda3158
You can see in that commit that there was previously a call
to rm which removed the fetchmailconf.py* files as well. It
was no longer needed with the python2-devel BuildeRequires
removed.
The fetchmailconf.py files are only installed if python is
found by configure. If you don't want fetchmailconf
packaged, drop those python3* packages from the
BuildeRequires and ensure python is not in the buildroot.
Since you're seeing the python files installed into the
python2.7 sitelib, I would presume that you have python2 in
the buildroot where you're building. If that's true, then
removing the python3* BuildeRequires won't be sufficient.
You should also pass PYTHON=: to configure, as the
README.packaging document suggests. That makes it clear
that even if python slips into the buildroot that you don't
want fetchmail to use it.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: /usr/bin/ld is broken in rawhide
Orion Poplawski wrote: > With current koji buildroot I end up with: > > + ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd > --w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld > -rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd > -rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/ld.gold > -rwxr-xr-x. 1 root root5441 Feb 19 07:39 /usr/bin/ldd > > and thus: > > BUILDSTDERR: collect2: fatal error: cannot find 'ld' https://bugzilla.redhat.com/show_bug.cgi?id=1683408 It might be worth untagging the binutils update until a fixed build is ready, which it looks like Mamoru has done: https://pagure.io/releng/issue/8172 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 Mass Branching
Hi, Mohan Boddu wrote: > Fedora 30 has now been branched, Thanks, to you and the releng team. :) > please be sure to do a git pull --rebase to pick up the > new branch A simple 'git fetch' should suffice to pick up the f30 branch. Depending on the state of one's repository, the 'git pull --rebase' could cause an unexpected conflict to resolve (though that will be waiting for them whenever they do eventually pull). -- Todd ___ 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: RFE: fedpkgdiff?
Hi, Richard Shaw wrote: > Out of curiosity I took a look at abipkgdiff that's provided by the > libabigail package and it's a python wrapper around abipkgdiff. I'm a > little rusty on Python but I could probably use that as a very nice > starting point... > > The next question is what package would the wrapper go in? I think the > natural place is fedora-packager. That or integrate it into rpkg/fedpkg as a subcommand if you're writing it in python anyway. If you decide to propose it for inclusion in fedora-packager (or anything other than as an rpkg/fedpkg subcommand), may I suggest that the command name use some prefix other than than fedpkg-, to avoid extra typing when tab completing fedpkg commands? If it's in fedora-packager, fedora- would probably be a reasonable prefix. Thanks, and happy hacking, -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
[EPEL-devel] Re: Trying to figure out "internal" packages
Kevin Fenzi wrote: > On 2/3/19 11:48 AM, Stephen John Smoogen wrote: >> Over the weekend, tmz asked on IRC why their RHEL-6 build was >> failing when it had not failed previously. The problem was that >> the expat21 package was being seen in the buildroot and >> over-riding the RHEL-6 expat. >> >> https://koji.fedoraproject.org/koji/rpmlist?buildrootID=15142150%20=50=nvr=component >> >> This was due to a bug in the expat21 package, but the part that I >> am trying to figure out is why the following packages are shown >> as "internal" in the buildroot. >> >> expat21-2.1.0-1.el6.x86_64.rpm internal >> expat21-devel-2.1.0-1.el6.x86_64.rpm internal >> highlight-3.8-1.el6.x86_64.rpm internal >> pcre2-10.21-22.el6.x86_64.rpm internal >> pcre2-devel-10.21-22.el6.x86_64.rpm internal >> perl-IO-Tty-1.08-3.el6.x86_64.rpm internal >> >> The following do make sense: >> >> epel-release-6-8.noarch.rpm internal >> epel-rpm-macros-6-21.noarch.rpm internal >> python2-rpm-macros-3-13.el6.noarch.rpm internal >> python-rpm-macros-3-13.el6.noarch.rpm internal >> python-srpm-macros-3-13.el6.noarch.rpm internal >> >> Are the above items where the buildrequires in a package are pulling >> them in or is there a buildroot directive adding them? > > "internal" here means local to koji, ie, in epel. > > expat21 is in epel. I have no idea why this bug wouldn't have hit > before, as expat21 hasn't been changed in many years, but it is in epel. I'm not sure either, but until recently (in the past month or two), this didn't affect koji. It still does not affect builds on el6 either via mock from a fedora host or directly via rpmbuild. For the local el6 builds, I used fedpkg --release el6 srpm and then yum-builddep on the srpm to install the deps. However, Carl George filed a bug report on this last June: https://bugzilla.redhat.com/show_bug.cgi?id=1585248 In that report he noted that yum-builddep was a symlink to dnf-utils. On the f27/f28/f29 systems I tested, yum-utils had been installed, so perhaps that is one of the important differences which keeps this from affecting normal epel users and many local/mock builds? Installing epel-release and then running yum install expat-devel also doesn't pull in expat21. I thought this might be because expat from base is already installed, so I installed expat-devel-2.0 and then ran yum update expat-devel and still don't get expat21 pulled in. In any case, is there an audit trail that shows when (and perhaps why) expat21 was added to the internal koji repo? It seems like it should be removed from there if it's manually tagged into that location. Björn, have you had any luck on the CVE's affecting expat21 so an update dropping the expat-devel provides can be submitted? -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Can we please stop enforcing Signed-off-by commits?
Stephen Gallagher wrote: > On Fri, Jan 18, 2019 at 11:18 AM John Harris wrote: >> >> On Friday, January 18, 2019 8:14:32 AM EST Stephen Gallagher wrote: >>> Note: Adding the Signed-off-by: line to a patch should be a conscious >>> act and means that you certify you have the rights to submit this work >>> under the same open source license. >> >> I'd argue that changing your project-specific .gitconfig to sign-off any >> commits is definitely a conscious act. Regardless, proprietary projects would >> have just as much of a reason to have their developers sign-off their >> commits, >> unless they solve the issue through a strong CLA or other contract with all >> developers contributing. This is not specific to 'open source' or free >> software projects. > > I was quoting from the git manpage. I didn't choose those words. Take > it up with git upstream :-) In case anyone chooses to do so, here's the last thread where a commit.signoff config option patch was suggested: https://public-inbox.org/git/20180206043723.GB30460@localhost/ There are links there to previous discussions, to provide background. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: mass-removal of LANG=anything-not-C.UTF-8 in packages
Hi Zbigniew, Zbigniew Jędrzejewski-Szmek wrote: > I'll do a mass update to use C.UTF-8 for the packages in the list that > follows, next week. I'll do test builds locally, and I'll only push to > dist-git if the local builds succeed. Let me know if you want your > package to be excluded. > git amahdal besser82 chrisw pcahyna pstodulk skisela tmz I'll take care of git soon. Thanks, -- Todd ~~ Telephone, n. An invention of the devil which abrogates some of the advantages of making a disagreeable person keep his distance. -- Ambrose Bierce, "The Devil's Dictionary" signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Cannot find -latomic when building for epel7 aarch64
Sérgio Basto wrote: > I had checked mock-core-config [1] , which are in use in copr (I guess) > and can't enable developer tools . > But on koji runs well , can you review this ? please . > > I could build azureus [4] on koji [2] which need eclipse-swt , but not > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >= 3.5` > Unfortunately I didn't have much time to dig it ... Packages from the SCL repos in mock-core-configs are restricted via the following config entry¹: includepkgs=devtoolset* That limit was not included in the initial koji configuration, but my understanding was that was going to be corrected. The only packages allowed to be used (or more specifically, BuildRequired) from the SCL repos in EPEL are devtoolset*. (Feel free to follow up on epel-devel on that, as that's where the folks who know best are.) ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-core-configs/etc/mock/epel-7-x86_64.cfg#L62 -- Todd ~~ Absurdity, n. A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce, "The Devil's Dictionary" signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Cannot find -latomic when building for epel7 aarch64
Jonathan Dieter wrote: > On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote: >> On 10/19/18 6:19 PM, Robert-André Mauchin wrote: >>> On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote: I'm trying to build duperemove[1] for epel7[2], and it's building on all the arches except aarch64. I'm BR'ing libatomic, but the error it gives in build.log[3] for aarch64 is: /usr/bin/ld: cannot find -latomic All current Fedora release builds were fine. I'm sure I'm missing something obvious, but does anyone have an idea what's going on? >>> >>> libatomic is 4.8.5 like the gcc version for other arches. >>> On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5. >>> Maybe this causes some issues. >> >> For aarch64, libatomic comes from the gcc-libraries source package, >> which I believe only exists to provide runtime support for devtoolset. >> It does not have libatomic.so, only libatomic.so.1 and .so.1.2.0. You >> probably need to use devtoolset gcc to actually build+link it. >> (Were those SCLs ever enabled for EPEL?) They were enabled in koji for EPEL-7. (In mock, they are enabled for EPEL-6 as well.) > Ok, thanks for the explanation. Unless there's an easy BuildRequires I > can add, I think I'll just leave duperemove out of EPEL. An example of using devtoolset in a spec file is here: http://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html I don't know if that will work out easily for your situation or not. -- Todd ~~ The best leaders inspire by example. When that's not an option, brute intimidation works pretty well, too. -- Demotivators (www.despair.com) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
Máirín Duffy wrote:
> So our Hyperkitty version is old here. I can't reporduce the issue on
> mailman3.org's HK, which is newer. I suspect this is a bug that's been fixed.
Indeed it was. An infrastructure ticket was filed ~7 months
back¹ and the issue was addressed upstream in 7558682 ("Fix
quoting of nested replies", 2018-04-24)².
The issue was that hyperkitty simply didn't include any
attribution of the quoted text, while many users assumed it
did and was quoting the wrong person.
Updating to hyperkitty >= 1.2.0 should resolve the issue.
Or the relatively small patch could be applied to our
instance -- if updating is a problem.
¹ https://pagure.io/fedora-infrastructure/issue/6802
² https://gitlab.com/mailman/hyperkitty/commit/7558682
--
Todd
~~
Let us think the unthinkable, let us do the undoable. Let us prepare
to grapple with the ineffable itself, and see if we may not eff it
after all.
-- Douglas Adams
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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
[EPEL-devel] Re: building with devtoolset
Dave Love wrote: > I thought devtoolset was now available for building EPEL packages, but > I've just tried with something that needs a more recent gcc than el6's > but neither devtoolset-6 nor -7 are found. Should that work? I don't think devtoolset was added to koji for el6. It's in the mock configs, so you can build locally. But IIRC, support for el6 was left out with an informal "let's wait to see if there's much (or any) demand for it" policy. -- Todd ~~ I used to think the brain was the most advanced part of the body. Then I realized, look what's telling me that. -- Emo Phillips signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora Packaging Guidelines on docs.fedoraproject.org
Brian (bex) Exelbierd wrote: > On Mon, Oct 1, 2018 at 11:03 PM Björn Persson wrote: > >> Jason L Tibbitts III wrote: >>> Indeed, asciidoctor works a bit better than asciidoc does but still >>> converts quickly. It's actually in the "rubygem-asciidoctor" package. >> >> Maybe I'll try that next time I have some free time. This is giving me >> a "best viewed with Netscape Navigator" feeling though. Not only are >> there several different badly designed document authoring languages, >> but they're apparently even splitting into tool-specific dialects. > > AIUI asciidoc is no longer maintained at all. AsciiDoc the syntax has > evolved is not even fully supported in the outdated asciidoc tool. AIUI > you should only ever run asciidoctor, the successor tooling, or use it's > libraries in your project). FWIW, git still defaults to asciidoc over asciidoctor. Some work has been done to accommodate asciidoctor, but there are a few minor formatting issues when building the docs with asciidoctor that have kept me from using it in the git packages. I agree that newer projects should target asciidoctor's implementation. I just wouldn't want to see asciidoc dropped too soon because we think it's completely unused. -- Todd ~~ I never forget a face, but in your case I'll be glad to make an exception. -- Groucho Marx signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: many legit devel@ emails marked as spam by gmail (dmarc reject)
Hi, Florian Weimer wrote: > * Todd Zullinger: > >> On the users list we enabled Mailman's DMARC mitigations >> several months ago. That has allowed posts from users >> @yahoo and other domains with strict DMARC settings to reach >> list subscribers @gmail and other domains which honor those >> DMARC settings. >> >> It may be worthwhile to enable those Mailman mitigations for >> all project lists by default (allowing lists who may not >> want it to disable the settings). > > Can we at least opt out as recipients, for those of us who still > exercise some control over their email infrastructure? AFAIK, there's no individual subscriber control in Mailman. It's applied to the list. (I'm nowhere close to an expert with Mailman3 though, so corrections are welcome.) However, it only affects messages from domains which have a DMARC 'reject' policy, as configured on the users list. So anyone with some control over their email infrastructure shouldn't generally be affected (or will have the ability to make adjustsments to their DMARC policy to allow mail to be resent from the Fedora lists). For the benefit of those who aren't familiar with Mailman's DMARC mitigations, here's how this works on the users list: When mailman is sending a message it checks the DMARC policy of the sender's domain. If that policy is set to 'reject' then Mailman will adjust the From: field to send the message from the list address instead of the sender's. For example, if a subscriber 'someu...@example.com' sends a message to the list and 'example.com' has a DMARC 'reject' policy, the original from header would be: From: Some User Mailman will change that to: From: Some User via users It will store the original From header (I believe in Original-From: but it's early in the day and that's from memory, so it could be slightly off). The advantage is that domains like @gmail.com which block (or mark messages as spam) from domains like @yahoo.com will no longer do so because the list has not resent mail from @yahoo.com counter to @yahoo.com's DMARC policy. The disadvantage is that the From: field is munged. Overall, I think it's been an improvement on the users list. -- Todd ~~ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: many legit devel@ emails marked as spam by gmail (dmarc reject)
Chris Murphy wrote: > Semi-related to the "Attention Gmail users, please turn off HTML" > thread; anyone *not* using gmail (e.g. all Yahoo email users) are > having their emails put into spam by google mail. > > >>This message has a from address in yahoo.co.uk but has failed yahoo.co.uk's >>required tests for authentication. Learn more > > And from the headers: > > smtp.mailfrom=test-boun...@lists.fedoraproject.org; >dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=yahoo.co.uk > > > And from yahoo's help. > https://help.yahoo.com/kb/SLN24050.html > > The result of the reject policy set by yahoo (and others), and that > gmail is one of the few mail hosting companies that honors p=reject, > is that such emails end up in gmail spam, and no amount of training or > filtering will fix it. And this is a silent failure. I have many > emails in spam by Fedora Project users (not just devel@). On the users list we enabled Mailman's DMARC mitigations several months ago. That has allowed posts from users @yahoo and other domains with strict DMARC settings to reach list subscribers @gmail and other domains which honor those DMARC settings. It may be worthwhile to enable those Mailman mitigations for all project lists by default (allowing lists who may not want it to disable the settings). -- Todd ~~ The secret of life is honesty and fair dealing. If you can fake that, you've got it made. -- Groucho Marx signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Linking commits to builds on dist-git
Daniel P. Berrangé wrote: > On Fri, Aug 10, 2018 at 11:27:43AM +0200, Pierre-Yves Chibon wrote: >> On Fri, Aug 10, 2018 at 10:16:13AM +0100, Daniel P. Berrangé wrote: >>> ability to write to git, but there are a variety of ways to deal with that. >> >> I'm pretty sure we used to do this at one point but one of the issue is that >> tags are no immutable, packagers can change them even if we block force push. >> I believe this is why we no longer do this :) > > A git commit "update" hook can be used to block deletion or modification > of any existing tags. Indeed. The default update hook provides exactly such a capability (as well as others to prevent deletion of tags and pushing lightweight tags). The tag can be found in the git source: https://git.kernel.org/pub/scm/git/git.git/tree/templates/hooks--update.sample and in the git-core package: /usr/share/git-core/templates/hooks/update.sample Similarly, a hook could be used to disallow the tagging service from writing to anything outside of refs/tags to help allay the concerns about a service having write access to the git repositories. Also, many thanks to Pingou and everyone who helped to add this feature! -- Todd ~~ Disobedience, n. The silver lining to the cloud of servitude. -- Ambrose Bierce, "The Devil's Dictionary" signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/message/67SF65KTHOFV2DG7TKHMTDBPJR742M7C/
Re: /results_* and /*.rpm in .gitignore (was: Source tarballs are being placed in git?)
Tim Landscheidt wrote:
> Todd Zullinger wrote:
>
>> […]
>
>> For example, the rpmlint's .gitignore contains the
>> following¹:
>
>> /*.rpm
>> /results_rpmlint/
>> /rpmlint-*/
>> /rpmlint-*.tar.gz
>
>> […]
>
> Apropos: Many .gitignores only reference the source files,
> i. e. not /results_${name} or /${name}-*.rpm. Therefore I
> usually add the latter two to .git/info/exclude and I wonder
> how others handle this.
If it's a package I often work on, I generally add it to the
.gitignore directly.
> Will fedpkg (and its backend) always create results_${name}
> and ${name}-*.rpm in the top directory or is the destination
> configurable? If the former, it would make sense to add
> them to .gitignore "for everybody", e. g. recommend that in
> the Packaging Guidelines. If not, I'd find it useful to
> have "fedpkg clone" add them to the initial
> .git/info/exclude.
The results_* and *.src.rpm files are always created at the
top level and are not configurable in fedpkg/rpkg (so far as
I can tell).
I think it makes sense to have them in every package
.gitignore file. Whether that's best done via the scripts
which are used to create a new repo after a package review,
via fedpkg/rpkg (automatically or by a command/option), or
just documented as a best practice in the guidelines I'm not
sure.
--
Todd
~~
I have to decide between two equally frightening options. If I wanted
to do that, I'd vote.
-- Duckman
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/ZAT7KK5GBEONTPI4VVGSDCFDFLHP6IJG/
Re: Source tarballs are being placed in git?
Thomas Moschny wrote:
> 2018-07-24 20:28 GMT+02:00 Todd Zullinger :
>> Years
>> ago, I submitted a patch to fedpkg/rpkg to have it resepct
>> the existing .gitignore, such that if you have a pattern
>> which matches the source being added, fedpkg won't add
>> another entry.
>
> My impression was that this is actually implemented in current fedpkg.
> I have /foo-*.tgz patterns in many of the packages I maintain, and
> fedpkg new-sources seems to respect that.
Yeah, it is. The patch I mentioned was applied (in rpkg¹).
I could have stated that more clearly.
¹ f260d2e ("fedpkg: Try not to add redundant gitignore
entries", 2010-09-08)
--
Todd
~~
The distinction between Freedom and Liberty is not accurately known;
naturalists have been unable to find a living specimen of either.
-- Ambrose Bierce, "The Devil's Dictionary"
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/4CVBXVXMX6OAXHMQDPIPWFSCFWCWRKPW/
Re: Source tarballs are being placed in git?
Daniel P. Berrangé wrote: > On Tue, Jul 24, 2018 at 01:32:45PM -0400, Todd Zullinger wrote: >> Artur Iwicki wrote: >>> That section of the guide is a bit poorly worded. You should *not* use "git >>> add" on source tarballs. These should be added only via means of "fedpkg >>> new-sources $FILES; git add ./sources". I believe what the guide means >>> under "new source files" is e.g. when upstream does not provide an icon or >>> a .desktop or an .appdata.xml file (or a systemd .service or whatever) and >>> you add your own. This does not include "new upstream release tarball". >>> >>> I'll try to think of some way to make that more clear and submit a >>> suggestion to change the guide text. >> >> Somewhat tangentially, it may be worth recommending that the >> .gitignore be edited suitably for the project as one of the >> first steps in maintainence. >> >> By default 'fedpkg sources' will add the files being added >> to the lookaside cache to the .gitignore, but it will never >> remove older files, leading to an unnecessarily large >> .gitignore file. > > It probably isn't unreasonable to file an RFE against fedpkg to request > more intelligent behaviour. eg given a tarball filename in majority of > cases it is likely quite straightforward to identify the base name > eg match the filename against something like this > >(\w+)-(\d+(\.\d+)*).(zip|tar.\w+|tgz) > > And replace the 2nd part of the regex match with '*' to form the rule > to add to the .gitignore file. Yeah, perhaps someone will get bored and do that. Years ago, I submitted a patch to fedpkg/rpkg to have it resepct the existing .gitignore, such that if you have a pattern which matches the source being added, fedpkg won't add another entry. Another option would be to have fedpkg use the package N-V-R to construct a gitignore entry and use that instead of the filename if the filename matches the pattern. I don't think it would be too hard to generate a pattern using a regex either, I just haven't been bothered enough to work on a patch. -- Todd ~~ I personally think we developed language because of our deep need to complain. -- Lily Tomlin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/message/ZRQU3C363UZ7UA6MNDRTLMUU5XEG5WG5/
Re: Source tarballs are being placed in git?
Artur Iwicki wrote: > That section of the guide is a bit poorly worded. You should *not* use "git > add" on source tarballs. These should be added only via means of "fedpkg > new-sources $FILES; git add ./sources". I believe what the guide means under > "new source files" is e.g. when upstream does not provide an icon or a > .desktop or an .appdata.xml file (or a systemd .service or whatever) and you > add your own. This does not include "new upstream release tarball". > > I'll try to think of some way to make that more clear and submit a suggestion > to change the guide text. Somewhat tangentially, it may be worth recommending that the .gitignore be edited suitably for the project as one of the first steps in maintainence. By default 'fedpkg sources' will add the files being added to the lookaside cache to the .gitignore, but it will never remove older files, leading to an unnecessarily large .gitignore file. It's much more legible to use git's pattern matching facilities to match the source files. For example, the rpmlint's .gitignore contains the following¹: /*.rpm /results_rpmlint/ /rpmlint-*/ /rpmlint-*.tar.gz This keeps 'fedpkg source' from needing to add each new tarball to the file. More importantly, it makes it harder to accidentally add a tarball to git. The additional rules are convenient for ignoring other files and directories which are often present in the work tree but are never intended to tbe committed. Refer to gitignore(5) for details on the pattern matching rules. ¹ https://src.fedoraproject.org/rpms/rpmlint/blob/master/f/.gitignore -- Todd ~~ If people are good only because they fear punishment, and hope for reward, then we are a sorry lot indeed. -- Albert Einstein signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/message/UVNDIPPZNOP3JLQILZEF2KEIJGRHRDK5/
Re: Packages which needlessly use %defattr
Jan Kratochvil wrote:
> On Wed, 04 Jul 2018 12:18:00 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> What about just doing a mass specfile update now? I think asking
>> individual maintainers to fix their packages isn't worth their
>> time. It's a safe change,
>
> Is it? I haven't found whether this change is compatible with CentOS-6 (and 7)
> which could break them if you just build the Fedora Rawhide .spec for them.
It is. Jason mentioned this in the initial message:
> RPM has provided a sensible default since version 4.4
> (which predates FC6 and RHEL5)
I regularly build git from rawhide, which has no %defattr,
for EL-{6,7} systems.
In case anyone might find that useful or wants to confirm
that the lack of %defattr causes no issues, the COPR's are:
https://copr.fedorainfracloud.org/coprs/g/git-maint/git/
https://copr.fedorainfracloud.org/coprs/tmz/git/
--
Todd
~~
Prejudice, n. A vagrant opinion without any visible means of support.
-- Ambrose Bierce, "The Devil's Dictionary"
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/3AJR4PPZNZTN3GPOWK3G7K4NHGOBNOVA/
Re: Heads up: Python 3.7 rebuild in progress
Miro Hrončok wrote: > We have 170 packages with blocked dependencies. > We also have 176 packages that fail to build from source (+ ~10 more that > are being handled). > > I need your help, I cannot possibly fix 178 packages. > > I've opened bugzillas for some, but let me ask you via e-mail before I go > file 176 of them. > > Common problems: > > * RuntimeError: generator raised StopIteration >https://www.python.org/dev/peps/pep-0479/ >Solution: return instead (works with 2.7 as well) > > * Syntax Error: async, await >Those are reserved keywords now >https://www.python.org/dev/peps/pep-0492/ >Solution: Rename. Add a wrapper if it's part of an API. I happened to look at the failure for gpodder and noticed it was due to a SyntaxError exception. The code used async as a parameter, which is now a keyword in python-3.7 (along with await). I wonder how many other failures are due to that change in reserved keywords? At least those are easy to fix. I filed a PR upstream and at src.fpo: https://github.com/gpodder/gpodder/pull/487 https://src.fedoraproject.org/rpms/gpodder/pull-request/1 I'm not a gpodder maintainer (or user, I just poked it out of curiosity), so I can't push and build it. -- Todd ~~ Suppose I were a member of Congress, and suppose I were an idiot. But, I repeat myself. -- Mark Twain signature.asc Description: PGP signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org/message/SITL72V6QR76N5BIZ35LW7PHQFWOWIKD/
Re: Heads up: Python 3.7 rebuild in progress
Miro Hrončok wrote: > We have 170 packages with blocked dependencies. > We also have 176 packages that fail to build from source (+ ~10 more that > are being handled). > > I need your help, I cannot possibly fix 178 packages. > > I've opened bugzillas for some, but let me ask you via e-mail before I go > file 176 of them. > > Common problems: > > * RuntimeError: generator raised StopIteration >https://www.python.org/dev/peps/pep-0479/ >Solution: return instead (works with 2.7 as well) > > * Syntax Error: async, await >Those are reserved keywords now >https://www.python.org/dev/peps/pep-0492/ >Solution: Rename. Add a wrapper if it's part of an API. I happened to look at the failure for gpodder and noticed it was due to a SyntaxError exception. The code used async as a parameter, which is now a keyword in python-3.7 (along with await). I wonder how many other failures are due to that change in reserved keywords? At least those are easy to fix. I filed a PR upstream and at src.fpo: https://github.com/gpodder/gpodder/pull/487 https://src.fedoraproject.org/rpms/gpodder/pull-request/1 I'm not a gpodder maintainer (or user, I just poked it out of curiosity), so I can't push and build it. -- Todd ~~ Suppose I were a member of Congress, and suppose I were an idiot. But, I repeat myself. -- Mark Twain signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/message/SITL72V6QR76N5BIZ35LW7PHQFWOWIKD/
Re: How to make DNS resolving fail early in mock?
I wrote:
> It should be possible to manually override the resolv.conf
> now by bind mounting an empty file on /etc/resolv.conf in
> the chroot. I've been meaning to play with this, but have
> not made time to do it until just now.
>
> I thought something like this would work:
>
> touch /etc/mock/empty
> echo
> "config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/etc/mock/empty',
> '/etc/resolv.conf'))" >> /etc/mock/site-defaults.cfg
>
> But testing this briefly, the host resolv.conf still ends up
> in the chroot. I'm probably overlooking something obvious.
> At least, I hope I am.
This works:
touch /etc/mock/empty
echo "config_opts['nspawn_args'] = ['--bind=/etc/mock/empty:/etc/resolv.conf']"
\
>> /etc/mock/site-defaults.cfg
sh-4.4# time curl http://example.com/
curl: (6) Could not resolve host: example.com
real0m0.016s
user0m0.005s
sys 0m0.008s
A proper patch for mock will pass the --bind option to
systemd-nspawn automatically when use_host_resolv is not
set.
--
Todd
~~
The worst thing about history is that every time it repeats itself,
the price goes up.
-- Pillar
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/CAILPALQSLLZBABJPYYXMEW25X4WHC2B/
