Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Solomon Peachy wrote: >> But with that knowledge comes the ability to work for a va- >> riety of organizations who will spend many resources on >> nudging their users to behave in a way that is not necessar- >> ily in their best interests. > What does "a developer's ability to choose who they work for" have to do > with end-user's ability to trust (and verify!) what data is being sent > (or not) to Fedora? Developers might not want to work for a project any longer that engages in behaviour that is perceived as being at odds with why they chose to work for that project in the first place. > Because what you're describing is a complete non-sequiter, and > represents what has been the status quo for most of Humanity's history. > No metrics necessary, because who cares what the peasants actually want? Looking at the proposed metrics (https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md), the "peasants" who do not form part of the majority of the users might indeed worry about how bug reports, etc. are processed if they (objectively) only affect x % of all in- stallations. Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Mattia Verga wrote: > […] > If the change is approved, if you not believe in who proposed the > metrics good faith, if you don't want to send your metrics, if you don't > believe that setting a simple switch to OFF will make you safe, well, > goodbye. There are plenty of other linux distributions out there. I don't think anyone here is concerned with the privacy of their personal data; most subscribers will have the know- ledge to do what they want to do. But with that knowledge comes the ability to work for a va- riety of organizations who will spend many resources on nudging their users to behave in a way that is not necessar- ily in their best interests. However, these developers choose instead to associate with projects that are centered on empowering the users. So while your last sentence is correct, the first one does not address the points raised. Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Vít Ondruch wrote: %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. >>> Do I read correctly that we can now use `%patch` in >>> e.g. `%check` section? Interesting. Is this documented? >> No, while %patch and %setup *could* be made available >> elsewhere now, they are still only available in %prep >> because that's the only place where they make sense. > Working with Ruby, which is interpreted language, there are > cases where we want to patch tests, while we want to keep > them in their original form in the package. This might sound > weird, but the thing is that for running tests, we might be > limited by infrastructure. E.g. Koji does not have internet > access, builders are slow, etc. So we might want to apply > some patch to workaround such issues. > I have no hopes convincing you. But thank you for clarification. This feels like the tests should be patched (and these patches upstreamed) to behave differently depending on some option, and the spec file should then use this option to trigger the correct one. I don't know enough about Ruby to suggest The Way™ to pass this option; but usually environment variables will do. (Other test suites have tags that can be used to select tests that should (not) be run which might be another (upstreamable) solution.) Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Statistics - L'Aigle meteorite edition
John Reiser wrote: >> New projection when we will be finished is 2025-04-06 (+5 >> days from last report). Pure linear approximation. > Such a linear approximation, based on the entire tracked history, > is the second worst possible estimate. (The worst possible estimate > is the output of a random date generator.) > Financial markets and other arenas using serious statistical forecasting > have known for decades that it is much better to estimate by assuming > a rate equal to the moving average rate over a fixed-length relevant > period. Repeatedly estimating based on the entire history does not > meet the fixed-length requirement, because the entire history grows. > Typical periods range from a small number of months to one year. > For Fedora, one relevant period might be six months, the > interval between scheduled releases. Also useful are 90 and > 120 days. > Graphing the estimated completion date based on such a moving > average rate would be much more informative and useful than the > estimated dates which have been published so far. Maybe I misunderstood the original post, but I did not per- ceive the intent of the data's publication to be informative and useful, but to motivate (converting the licenses). Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F41 Change Proposal - Reproducible Package Builds (System-Wide)
Zbigniew Jędrzejewski-Szmek wrote: > […] >> - use dynamic buildrequires to detect what plugins are needed > My problem is that the binary is linked to the libpython3.12.so shared > library… The detection part is easy, the hard part is how to have the > binary work when the shared lib is not installed. Quick 'n' dirty: Have two binaries, unconditionally call add-determinism-python for *.pyc files, either from add-determinism or the BRP macro (which essentially should be called when %__brp_python_bytecompile is called?), rely on the packager to build-require add-determinism-python or require that from python3-devel (the missing binary should fail the build otherwise). Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
Kevin Kofler wrote: >> This is not helpful in the slightest and the tone is not appreciated at >> all. > Well, I have been arguing against this exception (exempting prebuilt > autotools output) from the "no prebuilt blobs" rule for years, and it > saddens me that something like this had to happen for Fedora to finally > realize that that exception has always been a bad idea. > […] CMIIW, but it would not have made any difference as the source code had been shipped as part of the tar ball and auto(re)conf would have happily integrated it into the next build. I suspect that a modification to CMakeLists.txt and its includes would not have been detected either; even a daring, but obvious change in the 3+ lines of source itself might have gone unnoticed. A major factor seems to have been the discrepancy between "the source code" at GitHub & Co. that was probably scrutinized by many eyes and the shipped, but different artifact. So one step (as a inter-distribution effort) could be to continuously automatically compare shipped artifacts with their "make dist" equivalents and publishing the results. Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: some man pages have bugs, can't be grep'd
I wrote a very long time ago: >> I've been seeing this since clean installing Fedora 30. I don't recall >> ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded >> system (is now the clean installed system). >> [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity >> :176: warning [p 3, 0.8i]: cannot adjust line >> [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr >> [chris@flap mantest]$ ll >> -rw-rw-r--. 1 chris chris62 Jul 16 14:24 rpm.stderr >> -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout >> Is this a bug that should be reported against rpm or something else? >> I'm certain I've seen it in other man pages, but offhand I can't find >> another example. > (This also happens on Fedora 29, JFTR.) The warning seems > to stem from this line in rpm.8: > | […] > | 175 The default \fIFILELIST\fR is > | 176 > \fI/usr/\:lib/\:rpm/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\:macros.d/\:macros.*\fR:\:\fI/usr/\:lib/\:rpm/\:platform/\:%{_target}/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\ > | 176 > :fileattrs/\:*.attr\fR:\:\fI/usr/\:lib/\:rpm/\:redhat/\:macros\fR:\:\fI/etc/\:rpm/\:macros.*\fR:\:\fI/etc/\:rpm/\:macros\fR:\:\fI/etc/\:rpm/\:%{_target}/\:macro > | 176 s\fR:\:\fI~/.rpmmacros > | 177 > | […] > This line is too long for the standard layout. It already > has hints ("\:"; zero-width break points) where it should be > broken, but these seem to be ignored. So prima facie RPM > has done everything right, and there is an error somewhere > in the groff/man ecosphere. That analysis was wrong: "cannot adjust line" does not mean that the line is too long, but rather that there are no spa- ces that groff can expand to adjust (justify) the line. For rpm(8) this was worked around by formatting the default value as a code block, with line breaks after each colon, thus not requiring the lines to be adjusted/justified. Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)
Miro Hrončok wrote: > […] >> 2. change %check not to rely on unpackaged files in buildroot > That one is non-trivial and depends on the reason it is needed. > For example, what is common for Python "namepsace" packages, e.g. > pkg_name.foo. > 1) We want to test installed files, not what is in $PWD, so we set PYTHONPATH > to >%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we >(try hard to) exclude $PWD from it. This is crucial to ensure the files >we actually ship are working and the installed file set is complete. >Our macros do this for the packagers. > 2) The %{python3_site...}/pkg_name/ directory and >%{python3_site...}/pkg_name/__init__.py and >%{python3_site...}/pkg_name/__pycache__/ and >%{python3_site...}/pkg_name/__pycache__/__init__...pyc >files must be present in %{buildroot} to successfully run the tests. > 3) The files from (2) must be excluded from the package because *pkg_name* > owns >them, not *pkg_name.foo*. >We Require the "toplevel" *pkg_name* package from *pkg_name.foo*. >The files are not bit-by-bit+metadata identical, >so both packages cannot ship them. > […] My understanding of the RPM spec sections was always that: - "%prep" is for "./configure", - "%build" is for "make", - "%install" is for "make install", and - "%check" is for "make check". "make check" (usually executed /before/ "make install") works in and on the working directory (https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets). To test that the resulting binary package is functional, an- other venue is needed, and in the case of Fedora, for that purpose Fedora CI was created (https://docs.fedoraproject.org/en-US/ci/tests/). That feels like a much cleaner solution than installing some files, testing and then not shipping them because the test environment will be the same as a user's who just installed the package instead of being in the process of building the package. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Kevin Fenzi wrote: > […] > The purpose here is to make the Fedora project a more welcoming place to > people who _do_ find those terms unwelcome. That doesn't mean everyone > does. It means we want to be welcoming and not jerks. ^ > I'm personally happy to do things to make people more welcome. > Even if they are small things and cause a small amount of work for us > existing contributors. > […] "Disagreement is no excuse for poor behavior and poor man- ners." Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Please remove "-i" from "%forgemeta" templates on wiki
Kevin Kofler via devel wrote: >> I don't think "documentation is harder to keep up to date there" is right, > Well, I guess it does not apply that much to the pages which were already in > an ACL-locked namespace, in particular, the packaging guidelines that can > only be edited by FPC. I cannot speak for the FPC whether it is easier, > harder, or the same difficulty to do the edits now vs. on the wiki. > But as far as I can tell, the move also affects wiki contents that were not > previously ACL-locked, and for those, it makes a big difference whether > anyone with a FAS account can just edit them on the wiki or whether one has > to dig up the source code in some Git repository and send a pull request > (and not get any instant feedback whether the changes even compile without > also installing some documentation processing toolchain). I guess most > people can only try to get someone else to do the editing work, or will just > shrug it off as "it's wrong and I cannot edit it". > Wikis have a much lower barrier to entry than setups of the > docs.fedoraproject.org type. > […] Personally, I cannot edit the wiki, but can submit pull re- quests for the docs (and have done so). Maybe due to my GNU socialization, I also really like good, single-truth documentation. Where wikis are curated to a degree that makes them usable, the effort spent seems com- parable to a Git forge (except that as a user, one cannot discern a wiki edit by someone who knows what they are doing from one that was overlooked or one that someone wants to fix in the future, but has not gotten around to it). Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Please remove "-i" from "%forgemeta" templates on wiki
Otto Urpelainen wrote: > […] > Like I said, I am not expert in forge macros, so if anybody thinks that > my edit removal was a bad idea, wiki has an undo button. Thanks! Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Please remove "-i" from "%forgemeta" templates on wiki
Hi, using "%forgemeta" with the "-i" option causes debug infor- mation to be output which leads to %changelog entries being garbled: | [tim@passepartout ~/.cache/rpm-specs]$ grep -l '^.*%forgemeta.\+$' *.spec | xargs -r fgrep 'Packaging variables read or set by %forgemeta' | ddiskit.spec:* Tue Jan 26 2021 Fedora Release Engineering - Packaging variables read or set by %forgemeta | ddiskit.spec:* Mon Jul 27 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | ddiskit.spec:* Tue May 26 2020 Miro Hrončok - Packaging variables read or set by %forgemeta | ddiskit.spec:* Tue Jan 28 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | gmediarender.spec:* Sat Aug 01 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | gmediarender.spec:* Mon Jul 27 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | kabi-dw.spec:* Tue Jan 26 2021 Fedora Release Engineering - Packaging variables read or set by %forgemeta | kabi-dw.spec:* Tue Jul 28 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | kabi-dw.spec:* Wed Jan 29 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libindi.spec:* Tue Feb 02 2021 Christian Dersch - Packaging variables read or set by %forgemeta | libindi.spec:* Tue Jan 26 2021 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libindi.spec:* Sat Aug 01 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libindi.spec:* Tue Jul 28 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libpqxx.spec:* Mon Feb 08 2021 Pavel Raiskup - Packaging variables read or set by %forgemeta | libpqxx.spec:* Tue Jan 26 2021 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libpqxx.spec:* Sat Aug 01 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | libpqxx.spec:* Tue Jul 28 2020 Fedora Release Engineering - Packaging variables read or set by %forgemeta | [tim@passepartout ~/.cache/rpm-specs]$ Therefore, the templates at https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control use "%forgemeta" without options and note: | # – remove “-i” and “-v” before commit However, the templates on the wiki page at https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples use "%forgemeta -i" and do not clarify that this needs to be amended before committing. It would be nice if the wiki page could be updated to avoid luring packagers into using these templates, perhaps with a hatnote that the content is historical (?) and only the tem- plates in the packaging guidelines should be used. TIA, Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 status
Todd Zullinger wrote: > […] > 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. For simple cases, "git checkout rawhide && git branch -d master" should also work. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
Josh Boyer wrote: > I am looking for challenges for upcoming year - what I and my team should > enhance. I have some ideas, but I want to hear > yours. > What you - as Fedora packager - find most time consuming on packaging? > Where you will welcome more simplicity or automation? > Deciphering whatever packaging guidelines have changed since the last time I > looked and trying to figure out how to update packages to adhere to them even > though nobody audits the package set > anyway. > […] I really like Debian's "Standards-Version" field (https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-standards-version) in that context; it does not tell what changes in the guide- lines have occured, but it makes it unambiguous what guide- lines the package /should/ comply with. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: some man pages have bugs, can't be grep'd
Chris Murphy wrote: > I've been seeing this since clean installing Fedora 30. I don't recall > ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded > system (is now the clean installed system). > [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity > :176: warning [p 3, 0.8i]: cannot adjust line > [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr > [chris@flap mantest]$ ll > -rw-rw-r--. 1 chris chris62 Jul 16 14:24 rpm.stderr > -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout > Is this a bug that should be reported against rpm or something else? > I'm certain I've seen it in other man pages, but offhand I can't find > another example. (This also happens on Fedora 29, JFTR.) The warning seems to stem from this line in rpm.8: | […] | 175 The default \fIFILELIST\fR is | 176 \fI/usr/\:lib/\:rpm/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\:macros.d/\:macros.*\fR:\:\fI/usr/\:lib/\:rpm/\:platform/\:%{_target}/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\ | 176 :fileattrs/\:*.attr\fR:\:\fI/usr/\:lib/\:rpm/\:redhat/\:macros\fR:\:\fI/etc/\:rpm/\:macros.*\fR:\:\fI/etc/\:rpm/\:macros\fR:\:\fI/etc/\:rpm/\:%{_target}/\:macro | 176 s\fR:\:\fI~/.rpmmacros | 177 | […] This line is too long for the standard layout. It already has hints ("\:"; zero-width break points) where it should be broken, but these seem to be ignored. So prima facie RPM has done everything right, and there is an error somewhere in the groff/man ecosphere. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
/results_* and /*.rpm in .gitignore (was: Source tarballs are being placed in git?)
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. 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. Are there other approaches to have a clean "git status" dur- ing "normal" packaging development, tests, etc.? Tim ___ 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/RPYIISZS6625VHMSDW3C6VRXUCQ57RIX/
Local test VMs (was: Status of OwnCloud/NextCloud)
James Hogarth wrote: > […] > FIrst thing when I fired up my test harness was that F28 has changed, > and thus broken, kickstart for the user option compared to a standard > minimal that worked going back to F22 and EL7 so that had to be > debugged and fixed ... done > Next things is the ansible that I use to test ... well the lovely > folks jumping the gun on dropping python2-* packages is making life > painful since ansible still uses python2 by default and not everything > support python3 yet. There is no python2-firewall anymore for the > ansible firewalld module ... yay another silly thing to work around! > […] BTW, it would be very nice if there was (maintained) docu- mentation on how to generate Fedora VMs and for example use Ansible to configure complex interactive test setups. James's article (https://fedoramagazine.org/day-life-fedora-packager/) is mouth-watering, but lacking detail and probably outdated by now. I'm sure that many Fedora packagers have their own ("obvi- ous") solutions, but having something general could lower the bar for new packagers who do not want to dive deep into all the minutiae just to test a release. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: qarte - compilation fails
"Martin Gansser" wrote: > when compiling qarte-4.4.0 with this spec file > https://martinkg.fedorapeople.org/Packages/test/qarte.spec > '[' noarch = noarch ']' > + case "${QA_CHECK_RPATHS:-}" in > + /usr/lib/rpm/check-buildroot > + /usr/lib/rpm/brp-compress > + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip > + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 > Compiling > /home/martin/rpmbuild/BUILDROOT/qarte-4.0.0-1.fc27.x86_64/usr/share/qarte/arteconcert.py > ... > File "/usr/share/qarte/arteconcert.py", line 385 > def update_pitch(self, *args, html=False): > ^ > SyntaxError: invalid syntax > error: Bad exit status from /var/tmp/rpm-tmp.rp9wQD (%install) > only when i comment the following line, the program compiles fine: > #cp -p *.py* %{buildroot}%{_datadir}/%{name} To state the obvious: arteconcert.py is Python 3, brp-python-bytecompile uses /usr/bin/python (which is most likely Python 2): | [tim@passepartout ~]$ python2 -m py_compile ~/RPMS/BUILD/qarte-4.0.0/arteconcert.py | File "/home/tim/RPMS/BUILD/qarte-4.0.0/arteconcert.py", line 385 | def update_pitch(self, *args, html=False): | ^ | SyntaxError: invalid syntax | [tim@passepartout ~]$ python3 -m py_compile ~/RPMS/BUILD/qarte-4.0.0/arteconcert.py | [tim@passepartout ~]$ Following the advice from https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation, prepending: | %global __python %{__python3} to your qarte.spec works, but there may be cleaner solu- tions. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM Lint Errors
Greg Hellings wrote: > I have a package that includes a group of Ansible playbooks embedded into a > Python module. The playbooks include a number of templates that are designed > to be > uploaded into remote systems, templated out with appropriate variables, and > then executed on the remote system. > Since the templates are designed to become executables on the remote hosts, > they have she-bang lines as appropriate (mostly shell scripts, a few Python > scripts). However, > they are not yet supposed to be executed, since they are template files that > generate the executable files. > Rpmlint flags these files as executables (because of the she-bang) that lack > the executable flag (because that flag will be set after templating and > upload). Is there a way for > me to specifically tell rpmlint to ignore that particular error for those > files so I can avoid these false positives? Do I just have to pony up and > deal with it? You should be able to ignore certain errors with an "addFilter()" statement in one of rpmlint's configuration files (cf. /usr/share/doc/rpmlint/README.md or https://samthursfield.wordpress.com/2012/02/07/rpmlint/ for an example). AFAIUI "fedpkg lint" should consult a .rpmlint file in the RPM's directory, and I assume the build infra- structure will do that as well, but I never tested that. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM packaging and ldconfig handling
Tomasz Kłoczko wrote: > […] > Who said that I'm demanding something? > Look one more time on https://pagure.io/packaging-committee/issue/736 > Igor took this tasks VOLUNTARILY and started working on necessary specs > before I've delivered batch of patches. > When I found that number of already done modifications is trashing already > many patches which I had prepared it was no sense to be (as me) involved in > helping finish > this. > Now still is not finished about 20%. > Just please answer on the questions: > - Who will finish this? > - Why it is done so badly? > - What is the sense submitting more such mass changes if it is good chance > that they'll be not finished as well? (and now you are telling me that I'm > this bad guy because > I've been showing those "naked pictures" to other people) You can help move this forward by publishing the script(s) you used (or the patches that still apply cleanly if you wrote them manually). Also, just to state the obvious for most: This is some tidy- ing up. It's good if it's done, but it is not blocking any- thing. If someone already has patched "only" 20 % of the specs, that is good, not bad, because the work to be done has decreased by a fifth. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RPM packaging and ldconfig handling
Tomasz Kłoczko wrote: > […] > This is like with with problems on taking care of the production issues or > faults. > Always needs to be someone who is controlling whole situation but this person > does not need to to person doing all OS, HW, app, db related things which > needs to be > changed. > At the end such person in bigger organisation sometimes is taking > responsibility to teach other technical personnel about how to prevent > similar faults. Unfortunately, progress in Fedora and similar projects is not made by telling people what they are doing wrong, but by doing The Right Thing™ yourself or in collaboration with others. And even if one is reporting a fault, there are ways to enable someone to fix that fault and there ways to overwhelm them with superfluous information that makes their work harder. For example, take the first line of your text I quoted above. I can tell you that you used "with" there twice, or I can hide that nugget in a long diatribe about the English language, HTML mail and whatever. If your time is limited, you will probably prefer one over the other. Or, to paraphrase perlstyle(1): Be explicit. Be concise. Be nice. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)
Igor Gnatenko wrote: > […] >> I was not fully aware of this and I've personally hit this difficulty >> not on my proposal of the remove hicolor icon caches but on proposing, >> for example, OpenIPMI or readline changes. >> Most of my changes were by those packages maintainers simple discarded >> (readline 100% and in case OpenIPMI ~50%). >> I'm not trying to blame anyone here but all this only *result* of some >> assumptions that master branch must be fully compatible with more than >> one distribution or more than one distribution versions. > Well, I think because this is simply easy. If we separate changelog to other > file / make it auto-generated, then it should be easier for people to maintain > f26/f27/master branches separately. Right now, cherry-picking is never cleanly > applies due to changelog. Well, we need to do something with Release field as > well, I don't know why it is still not auto-generated... > […] GNU had the same problem in various projects and came up with a Git merge driver for changelogs (http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c). Now that is a text parsing orgy in C, probably provably cor- rect, but it suggests that a simpler solution for RPM spec files should be very feasible. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
Kevin Fenzi wrote: > […] I really don't understand why we do this "batched" thing to begin with. >>> To reduce the constant flow of updates that are very minor or affect >>> very few mixed in with the major updates that affect lots of people and >>> are urgent. >> But the users were already able to opt to update only weekly. So why force a >> fixed schedule on them? > To save all the Fedora users in the world from having to update metadata > for minor changes. Since there's a hourly dnf makecache every user in > the world pulls down new metadata ever time we update a repo. If we > update a repo for some minor enhancements it means everyone in the world > has to pay for that. If we just push all those out every tuesday and > don't update those unless there's something urgent we save everyone a > lot of bandwith and us computing time/resources. > […] BTW, are there technical reasons why the metadata is updated en bloc and not incrementally like for example delta RPMs, or is it just that nobody bothered to implement something like that yet for metadata? Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changes Policy & Fedora Release Life Cycle - request for review
Przemek Klosowski wrote: > In MediaWiki, revisions compared in a diff do not need to > belong to the same article. So for example, to compare the > current revision of...(488139) to the current revision of > ...(505754), you can use the URL > https://fedoraproject.org/w/index.php?diff=505754&oldid=488139 > This is not as convenient (or obvious :-)) as your approach, > Is there a way to click into that, or do you just know the URL and > substituted the IDs by hand? How did you get the IDs of the two pages in the > first place? This kind of URL is not exposed by the UI (AFAIAA). I as- sembled the URL by: 1. Going to https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle, "history", "Compare selected revisions" which gives https://fedoraproject.org/w/index.php?title=Fedora_Release_Life_Cycle&diff=488140&oldid=488139 (which means 488140 is the current revision (on the right side of the diff)), 2. doing the same for https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle which gives https://fedoraproject.org/w/index.php?title=User%3AJkurik%2FFedora_Release_Life_Cycle&diff=505754&oldid=505738, and 3. assembling the URL by removing the "title" parameter (just for cosmetics), setting the "oldid" parameter to the revision to appear on the left side and the "diff" parameter to the revision to appear on the right side. (Cf. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#View_and_render for documentation.) Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changes Policy & Fedora Release Life Cycle - request for review
Adam Williamson wrote: >> I tried to merge together all the changes we were facing during the >> last time with regards to Changes Policy & Fedora Release Life Cycle. >> The outcome is available in [1] and [2]. Before I will ask FESCo for a >> review, I would like to ask anyone who is interested for a review and >> comments. > It would be much easier to review if we could see a diff to the current > contents of the pages. When doing drafts like this, I usually copy the > original page *without* changes first, *then* make my changes, so the > 'history' tab can be used to view the changes from the original > content. In MediaWiki, revisions compared in a diff do not need to belong to the same article. So for example, to compare the current revision of https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle (488139) to the current revision of https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle (505754), you can use the URL https://fedoraproject.org/w/index.php?diff=505754&oldid=488139. This is not as convenient (or obvious :-)) as your approach, but it does not depend on a) somebody copying the original first and b) not making a mistake when copying & pasting. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Purpose of Makefile in package repository?
Adam Jackson wrote: >> I searched a bit in the wiki, and my sense is that at some >> point in the past packages were maintained in a CVS reposi- >> tory with Makefiles and that those have been replaced by Git >> repositories and fedpkg. >> Is that correct? Can such a Makefile then be deleted or >> does it serve any other purpose? > That is correct. Most packages had a nearly identical copy of this > Makefile, but a few (most notably the kernel) had extended it with > other maintainer convenience commands. I suspect what happened here is > that when we moved to git we preserved any Makefile that didn't match > the standard one. > This particular one is certainly not doing anything useful anymore, > feel free to nuke it. Thanks for the explanation. Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Purpose of Makefile in package repository?
Hi, pytz has a Makefile in its package repository with the con- tents (https://src.fedoraproject.org/rpms/pytz/blob/master/f/Makefile): | # Makefile for source rpm: pytz | # $Id$ | NAME := pytz | SPECFILE = $(firstword $(wildcard *.spec)) | define find-makefile-common | for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done | endef | MAKEFILE_COMMON := $(shell $(find-makefile-common)) | ifeq ($(MAKEFILE_COMMON),) | # attept a checkout | define checkout-makefile-common | test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo "common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to checkout the 'common' module." ; exit -1 ; } >&2 | endef | MAKEFILE_COMMON := $(shell $(checkout-makefile-common)) | endif | include $(MAKEFILE_COMMON) I searched a bit in the wiki, and my sense is that at some point in the past packages were maintained in a CVS reposi- tory with Makefiles and that those have been replaced by Git repositories and fedpkg. Is that correct? Can such a Makefile then be deleted or does it serve any other purpose? Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is it possible to upload new sources of a package from a URL?
Hedayat Vatankhah wrote: > […] > Yes, but even if I'm forced to download locally, it is much > better than being forced to upload it again. (Also, note > that the current process doesn't prevent MITM if it happens > when I download the source). > Also, it is easier to schedule the download for a time when > it is cheaper (or free), but it'd be harder to do it for an > upload since it requires authentication. > […] If data volume is expensive or difficult for you, you could look into renting a (virtual) private server and then devel- oping there via ssh. Offers usually start at less than $ 5,-/month. (I'm not aware of free solutions; it's proba- bly easier to solicit donations for one's own server than to get access on someone else's.) Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedorahosted.org retired today (2017-03-01)
Kevin Fenzi wrote: > Today we have retired fedorahosted.org. > Please see the following wiki page for up to date information: > https://fedoraproject.org/wiki/Infrastructure/Fedorahosted-retirement > * ssh pushes will direct you to the above wiki page and not complete. > * web access will redirect you to the above page. > We hope you will look to https://pagure.io for your future source and > issue hosting needs. > Note that lists.fedorahosted.org is not affected by this and will > continue moving forward. There are still several hundred binary packages in F25 that refer to that host: | [tim@passepartout ~]$ dnf repoquery --qf '%{url}\t%{name}' | fgrep fedorahosted | wc -l | 464 | [tim@passepartout ~]$ I think mass-filing bugs for those would be helpful to clear out the backlog. (In the previous thread there was also talk of a more systematic approach that checked the status of all URLs as part of build tests.) Tim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcing the release of Fedora 24 Beta!
Dennis Gilmore wrote: > […] > Cloud > - > We are working hard to make Fedora the best platform for containerized > applications, from base Fedora container images to a full-featured > platform as a service to run and manage them. To meet this goal, we are > packaging OpenShift Origin so it is easy to deploy. OpenShift Origin is > a distribution of Kubernetes, a container cluster manager from Google. > It is optimized for enterprise application development and deployment. > Origin makes it easy for developers to get started building applications > in containers and for operators to manage them. > […] I had looked at https://fedoraproject.org/wiki/OpenShift_Origin and https://fedoraproject.org/wiki/Features/OpenShift_Origin for information about OpenShift Origin (or any PaaS :-)) and Fe- dora recently and I read it to mean that that combination is on hold, with the pages not having been updated for two years. Are there other sources of information for that fea- ture? Tim -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox not working anymore over ssh?
Michael Catanzaro wrote: >> Yes. This makes it work. Thanks a lot. > Then it was probably broken by this update: > https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this? Tim -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Best practice for multiple version/OS boot?
Hi, IIRC fedora-review suggested to test packages on all sup- ported Fedora releases. So, with a larger hard disk, I want to install Fedora 19, 20 (soon) and Rawhide and throw in (recent) Debian and Ubuntu as well. As my notebook doesn't support VMs, I'm interested in best practices for partition- ing and multi-boot setups. Currently I use a partition for /boot and another for an en- crypted LVM, so I only need to worry not to put private data in /boot, and I would like to keep such flexibility. I suppose I need to create a /boot partition for each ver- sion/OS. I have had different Fedora versions share the same encrypted LVM without problems; I assume Debian and Ubuntu will do so as well, but I will keep some free space and partitions just in case. More contested seems to be the multi-boot setup. https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a myriad of opinions on how it should be set up; http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide suggests "chainloader", and http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html recommends "configfile". Of course there is also GRUB's OS prober. So what are Fedora developers /actually/ using? Creating a separate GRUB partition and "chainloader"/"configfile"? Running OS prober in the "main" OS after each installation/ kernel update? Something else? How often do the setups al- low one to shoot oneself in the foot, or are they (more or less) "foolproof"? Thanks in advance, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self introduction
Hi, after posting bug reports and patches for quite some time, I finally decided to set up a FAS account to see how I can help with packaging and other tasks at hand. I believe my Linux experience started with Vanderbilt af- ter one encounter with DJ'ing Slackware onto my system and giving up when I saw the result :-). My initial interest will probably lie in pushing out the Emacs/Perl packages that I found a) useful and b) lacking in the Fedora distribution, but as "works for me" will no longer be a sufficient criteria I have to read up on the rather voluminous documentation before I will ask for my first review. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel