Re: rpmbuild is very slow with large files

[Kamil Dudka]

On Tuesday, July 12, 2022 12:52:13 AM CEST Marius Schwarz wrote:
> 
> Hi,
> 
> I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5 
> GB rpm and found, that rpmbuild is an extrem bottleneck.
> 
> IMHO, this is caused by a fileread function which reads files in 32k 
> blocks, which is very slow and extrem IO intensive.  The result is a 
> task running at 1 core at 100% perma. With changes to larger chunks, we 
> can speed up so many build tasks on the farm.
> 
> Multicore use would also be helpful i.e. while packing the files.

What do you mean by packing?  Creation of the resulting RPM packages?
I believe this phase already runs in parallel in case multiple RPM
packages are being created out of a single source RPM package.

Kamil

> Any counter-arguments ?
> 
> strace example:
> 
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=477601377}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=477685727}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=477892054}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=47876}) = 0
> [pid 2604060] read(5, "_I @_I s_I t_E\nauss\303\244het 
> auss\303\244h"..., 32768) = 32768
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478212651}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478301347}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478409015}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478505273}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478701366}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478784826}) = 0
> [pid 2604060] read(5, " Y_I k_I t_E\naustun austun 'aU_B"..., 32768) = 32768
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=478962539}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479045029}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479130924}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479213446}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479407336}) = 0
> [pid 2604060] clock_gettime(CLOCK_REAobjections
> LTIME, {tv_sec=1657579222, tv_nsec=479489832}) = 0
> [pid 2604060] read(5, "s_I v_I u:_I k_I s_I @_I s_E\naus"..., 32768) = 32768
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479720335}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479803090}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=479950309}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=480067186}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=480305924}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=480417985}) = 0
> [pid 2604060] read(5, "B s_I ts_I u:_I g_I R_I E_I n_I "..., 32768) = 32768
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=480654716}) = 0
> [pid 2604060] clock_gettime(CLOCK_REALTIME, {tv_sec=1657579222, 
> tv_nsec=480763606}) = 0
> 
> and I don't think, this tasks needs to read the clock that often too.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [RFC] Build tag in RPM: from NVR to NVRB

[Kamil Dudka]

On Wednesday, June 22, 2022 7:45:09 PM CEST Kevin Fenzi wrote:
> On Wed, Jun 22, 2022 at 11:09:13AM -, Michael J Gruber wrote:
> > > I also think that every package change (including rebuild) must be
> > > tracked in changelog.
> > 
> > I think that convolution is at the very heart of the problem:
> > 
> > As it is, dist-git tracks "packaging sources", i.e. spec and source hashes
> > or files, and this determines the content of the src.rpm and its version.
> > 
> > What you get when you build a binary rpm from that src.spm depends very
> > much on the environment. And that environment is not reflected in the
> > version nor in the built rpm (besides Build Host and Date).
> Well, it's reflected in the requires/provides/contents of the rpm too
> though right?
> 
> If I build foo-1.0-1 against libbar-2.0-1 and then again against
> libbar-4.0-1 its going to require different libs at install/run time.

The problem is that sometimes you build against libbar-4.0-1 vs. libbar-4.0-2 
and you get qualitatively different binary RPMs as the result in each case, 
despite you triggered both the builds from the same dist-git commit.  This 
difference is not always reflected in metadata of the resulting RPMs.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Kamil Dudka]

On Thursday, April 7, 2022 3:45:45 PM CEST Stephen Gallagher wrote:
> > Sorry for keeping asking naive questions, but is there a chance to do
> > some mass rebuild prior this lands, to asses the impact? Better to avoid
> > (complete?) breakage of ELN and give change to fix the (most
> > outstanding) issues prior it lands.
> 
> 
> I'm not sure what benefit that would have. The crypto policies are
> generally applied at runtime, not build-time.

The policies applied at run time can break builds though, especially when
they include regression tests that use crypto.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake failure to build in rawhide?

[Kamil Dudka]

On Friday, April 1, 2022 5:45:38 PM CEST Hans de Goede wrote:
> Hi All,
> 
> While fixing a hedgewars F36 bug, the f37/rawhide build of the
> fixed pkg is failing:
> 
> In both F36 and F37 the invocation is:
> 
> /usr/bin/cmake -S . -B redhat-linux-build
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DMINIMAL_FLAGS=1 -DNOVIDEOREC=1
> -DBUILD_ENGINE_C=1 -DGHFLAGS=-dynamic
> '-DFONTS_DIRS=/usr/share/fonts;/usr/share/fonts/google-noto-vf;/usr/share/f
> onts/dejavu-sans-fonts;/usr/share/fonts/wqy-zenhei;' .
 
> Followed by a bunch of output and then weirdness happens, F37 last cmake
> output line:
 
> -- Build files have been written to:
> /builddir/build/BUILD/hedgewars-src-1.0.0
 
> vs F36 last output line:
> 
> -- Build files have been written to:
> /builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build
 
> F37 cmake seems to ignore the "-B redhat-linux-build" leading to this
> subsequent build error:
 
> + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
> Error: /builddir/build/BUILD/hedgewars-src-1.0.0/redhat-linux-build is not a
> directory
 
> Any help with this would be much appreciated.
> 
> Regards,
> 
> Hans

It is most likely this (not a) bug:

https://bugzilla.redhat.com/show_bug.cgi?id=2057738

... also discussed on here on the mailing list some time ago:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YM4WDDZL6PMSODITVYWMPWC4TC4447AY/

It seems to be triggered by the following intentional change in upstream cmake:

https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7001

Yet another consequence of the unnecessary change of %cmake macros in Fedora 33:

https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: dist-git force push

[Kamil Dudka]

On Friday, April 1, 2022 4:26:36 PM CEST Robbie Harwood wrote:
> Kamil Dudka  writes:
> > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote:
> >> - check whether the "new object name" is descendant of
> >> (contains) "old build object name" (rather than "old object name", which
> >> would forbid any force push)
> >> This would allow to rewrite a branch as long as the last commit hasn't
> >> been
> >> built yet (but allow only rewrites to commits since the last build). In
> >> particular, this would allow to avoid the many "commit missing patch",
> >> "actually commit the change", "duh" commits which happen after a
> >> successful
> >> `fedpkg build --scratch --srpm` followed by a half-(how do you say this
> >> nicely)ed commit.
> > 
> > I thought the plan was to use pull requests with some CI checks to
> > avoid this.
> 
> I hope not.  Unless merging the PRs and kicking off the builds are done
> automatically, this'll just be as painful as the current centos
> workflow:
> 
> - commit
> - push to fork
> - open PR
> - wait for checks
> - click "merge" button
> - wait for bots
> - kick off build
> 
> compared with:
> 
> - fedpkg commit -sc && fedpkg push && fedpkg build
> 
> Context switches for maintainers are expensive!  And while I don't
> personally think the "oops fixup" commits are a problem, a "PR with CI"
> workflow doesn't get rid of them by any means.
> 
> Be well,
> --Robbie

Yes, the fixup commits are not a big problem in Fedora git I guess.  They are 
much more painful in upstream projects where downstream consumers like to use 
git-bisect and to cherry-pick fixes from upstream.

In any case, allowing production branches to be rewritten in certain cases is 
hardly a solution in my view.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: dist-git force push

[Kamil Dudka]

On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote:
> Hi there
> 
> I know why we do not allow to force push to dist-git in the rpms namespace,

You can easily do force pushes in your own fork.  Rewriting the authoritative 
branches in the official repositories is problematic for too many reasons, 
regardless of builds.

> but I am wondering whether we can implement this more in line with the
> reason:
>
> dist-git has to be a permanent record for the "source" (spec etc.) against
> which a package is built, but currently we deny pushing even when there is
> no build against the rewritten commits. Instead, I suggest the following
> behaviour for the update-hook of git-receive-pack:
>
> - check which commit contained in "old object name" is the most recent one
> (topology order) which has been built (successfully)

There is an inherent time-of-check/time-of-use race condition in the proposal.

> - call it "old build object name"
> - check whether the "new object name" is descendant of
> (contains) "old build object name" (rather than "old object name", which
> would forbid any force push)
> This would allow to rewrite a branch as long as the last commit hasn't been
> built yet (but allow only rewrites to commits since the last build). In
> particular, this would allow to avoid the many "commit missing patch",
> "actually commit the change", "duh" commits which happen after a successful
> `fedpkg build --scratch --srpm` followed by a half-(how do you say this
> nicely)ed commit.

I thought the plan was to use pull requests with some CI checks to avoid this.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Wednesday, March 16, 2022 1:06:34 PM CET Neal Gompa wrote:
> > For completeness, here is a pull request by Miro Hrončok to change the
> > packaging of curl to something that FESCO would like to have for the
> > proposed Fedora change to be accepted:
> >
> >
> >
> > https://src.fedoraproject.org/rpms/curl/pull-request/14
> >
> >
> >
> > Advantages:
> > - libcurl-full can be automatically installed as a dependency in a dnf
> > transaction without the need to use `--allowerasing` or `dnf swap`.
> >
> >
> >
> > Disadvantages:
> > - It is incompatible with the current packaging used since RHEL-8.
> > - It allows to install both libcurl-minimal and libcurl-full together.
> > - It relies on complex RPM scriptlets to manipulate symlinks, which
> > may misbehave in some corner cases, resulting in broken dnf stack.
> >
> >
> 
> 
> Can we just not do this at all?

Yes, that sounds like a reasonable thing to do at this point.  I wanted to 
support the Fedora Minimization Objective but we do not need to do this at 
every cost:

https://docs.fedoraproject.org/en-US/minimization/

I understand the argument of FESCO that the need to use `--allowerasing`
or `dnf swap` while upgrading to libcurl-full is not user-friendly at all.

I also appreciate the effort that Miro Hrončok put to preparing the above 
mentioned pull request.  It addresses the main complaint of FESCO but the
cost of the solution is just too high in my view.

For me as a package maintainer of curl in Fedora and RHEL, not doing this 
change will save me a lot of work.  The current packaging is fairly stable
and proven to work since RHEL-8.  If we ever change it, I will have to work 
hard to make sure that upgrades to next versions of RHEL work smoothly.

We can reconsider it later in case dnf becomes more ready for such changes.
I can imagine introduction of some AllowErasing: tag in spec file that would 
make the upgrade to libcurl-full work fully transparently.  Nevertheless, I
do not have enough free time to work on this myself.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Wednesday, March 16, 2022 10:01:10 AM CET Paul Howarth wrote:
> On Tue, 22 Feb 2022 12:00:06 -0500
> Ben Cotton  wrote:
> 
> 
> > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> > 
> > == Summary ==
> > `libcurl-minimal` and `curl-minimal` will be installed by default
> > instead of `libcurl` and `curl`.
> > The "minimal" variants provide only a subset of protocols (HTTP,
> > HTTPS, FTP). The full versions can be explicitly requested as
> > `libcurl-full` and `curl-full`.
> 
> 
> Upstream's thoughts:
> https://daniel.haxx.se/blog/2022/03/16/fedora-and-curl-minimal/
> 
> Paul.

For completeness, here is a pull request by Miro Hrončok to change the 
packaging of curl to something that FESCO would like to have for the
proposed Fedora change to be accepted:

https://src.fedoraproject.org/rpms/curl/pull-request/14

Advantages:
- libcurl-full can be automatically installed as a dependency in a dnf 
transaction without the need to use `--allowerasing` or `dnf swap`.

Disadvantages:
- It is incompatible with the current packaging used since RHEL-8.
- It allows to install both libcurl-minimal and libcurl-full together.
- It relies on complex RPM scriptlets to manipulate symlinks, which
may misbehave in some corner cases, resulting in broken dnf stack.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem with cmake 3.23.0

[Kamil Dudka]

On Monday, March 14, 2022 10:22:19 PM CET Thomas Rodgers wrote:
> These are the CMake related issues I've encountered thus far -
> 
> FlightCrew: FTBFS #  CMake Error: The source directory 
> "/builddir/build/BUILD/FlightCrew-0.9.1/build" does not appear to contain 
> CMakeLists.txt.
> csdiff: FTBFS # Make Error: The source directory 
> "/builddir/build/BUILD/csdiff-2.2.0/x86_64-redhat-linux-gnu" does not appear 
> to contain CMakeLists.txt.

I have fixed csdiff by syncing the spec file with upstream:

https://src.fedoraproject.org/rpms/csdiff/c/54d3e338

Kamil

> ledger: FTBFS # Error: /builddir/build/BUILD/ledger-3.2.1/redhat-linux-build 
> is not a directory
> liblas: FTBFS # Error: 
> /builddir/build/BUILD/libLAS-d76a061f33a69a36ab116cd939c5d444b301efd8/redhat-linux-build
>  is not a directory

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem with cmake 3.23.0

[Kamil Dudka]

On Tuesday, March 15, 2022 12:18:02 AM CET Neal Gompa wrote:
> I bent over backwards to get the macros working all the way back to EPEL 7.
> 
> I updated the cmake3 package in EPEL 7[1] and I got RHEL to update
> CMake[2] and sync the macros from Fedora[3] for RHEL 8.
> 
> The only difference for EPEL 7 and EPEL 8 is that RHEL's default is to
> do in-source builds and you need to explicitly set it back in your
> spec file.
> 
> [1]: 
> https://src.fedoraproject.org/rpms/cmake3/c/1e92b954226f002762fa98582367c080f267d449?branch=epel7
> [2]: 
> https://git.centos.org/rpms/cmake/c/09b85a86fd26251b569658b4ecb5db9ace298606?branch=c8s
> [3]: 
> https://git.centos.org/rpms/cmake/c/262fd084db691b092d1df3178adc357f2dcaef38?branch=c8s
>  

Do you have any example of a spec file that builds in the buildroots
of EPEL-{7..9} and all supported releases of Fedora without additional
`%if...` macros?

Preferably something that builds the same source code multiple times,
like in the csdiff example I posted above:


https://github.com/csutils/csdiff/blob/2c3b7ce60f1bdd2bf42903dec290c6b775f1697a/make-srpm.sh#L74

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem with cmake 3.23.0

[Kamil Dudka]

On Tuesday, March 8, 2022 12:13:33 AM CET Sérgio Basto wrote:
> I advise anyone to carefully read the wiki page.

If you mean the Fedora 33 change page, it only describes the change
from Fedora 33+ perspective.  It does not take compatibility with EPEL 
buildroots into account at all.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem with cmake 3.23.0

[Kamil Dudka]

On Friday, March 4, 2022 4:17:01 PM CET Sérgio Basto wrote:
> I think you missed the 
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

When the change landed, I had to fix all my packages to build although they 
had been using out of source builds since the beginning.  Now I have to fix 
them again.  Maintaining a spec file that works on RHEL-7..9 and on all 
supported releases of Fedora is more and more difficult for no good reason
but I am not giving it up for now:

https://github.com/csutils/csdiff/commit/df8d918c
https://github.com/csutils/csdiff/commit/9ec45f67

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, March 3, 2022 10:49:07 PM CET Richard W.M. Jones wrote:
> (1) I don't deny that curl-minimal will reduce the size of some niche
> containers, my point is this is not a worthwhile goal to pursue given
> the costs.

I am pretty sure there are Fedora installations not based on containers
where the installation footprint is also important.

> (2) Once people have unbroken their Fedora by installing curl-full,
> the security claims you make about compiled code paths are not
> applicable.

The users who install libcurl-full will have the same attack surface that
they have today.  However, as pointed out by others, not all users will 
install libcurl-full and those will be a priory unaffected by a portion
of the CVEs that we regularly deal with.

We are also tweaking the configuration of libcurl-minimal to ensure that
it can be used as a replacement for libcurl-full on the most common Fedora 
installations.  For example, the FTP protocol was left in libcurl-minimal
for now, despite the protocol is not optimal form security experts' point
of view, and libidn was enabled in libcurl-minimal last week:

https://src.fedoraproject.org/rpms/curl/c/cf3c14e4

Your suggestion to use CURLOPT_PROTOCOLS is a good idea and I fully support
it but it cannot be a replacement for libcurl-minimal because there is no 
algorithmic way to decide whether all users of libcurl disable a problematic 
protocol on all reachable code paths.  The problem is in general undecidable.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, March 3, 2022 3:24:38 PM CET Richard W.M. Jones wrote:
> On Thu, Mar 03, 2022 at 09:04:10AM +0100, Kamil Dudka wrote:
> > The FTP protocol is still included in libcurl-minimal, so the protocol is
> > not going to disappear with the proposed F37 change.  On the other
> > hand, it may happen that FTP will be unavailable by default in a year or
> > two.
> 
> 
> I'm still wondering what you're trying to achieve with this change.
> 
> The stated benefits[1] are that the "minimal variants are smaller",
> which is a non-goal for almost everyone.  And something to do with
> security which will be immediately negated once everyone unbreaks
> their Fedora by installing curl-full.  And the security angle would be
> better fixed by reviewing Fedora packages for correct use of
> CURLOPT_PROTOCOLS (see my other email[2]).
> 
> Rich.
> 
> [1] 
> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default#Benefit_to_Fedora
> [2] 
> ttps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7PQUPLCEQ5NMXFXZTP75XYDNF5KAJHMI/

I answered both your questions back in October 2021:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZMU36DFRSDJOIJJ75CLF45R6GDVSEYI/

Let's not replay the discussion unless we have anything new to say.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, March 3, 2022 7:07:34 AM CET Ralf Corsépius wrote:
> Am 24.02.22 um 19:35 schrieb Daniel P. Berrangé:
> 
> > On Thu, Feb 24, 2022 at 07:16:26PM +0100, Ralf Corsépius wrote:
> 
> 
> 
> > If someone is setting up a personal private mirror, I struggle
> > to understand a reason why they would pick FTP over HTTP(S)
> > today.
> 
> Because an ftp server is much lighter and much easier to maintain than a 
> fat httpd-server?
> 
> 
> > Perhaps someone will have a FTP only mirror that's
> > existed for years and simply haven't got around to enabling
> > HTTP, but addressing that is not an unreasonable expectation.
> 
> 
> Almost. E.g. I am using a LAN-wide (anonymous-only) ftp server, I set up 
> a long time ago and rarely touched since then.
> 
> Using httpd-server would simply be overkill for this use-case.
> 
> 
> > IMHO explicitly disabling FTP in dnf would be fine, as any fallout
> > could be easily dealt with by enabling HTTP. Just ensure we announce
> > such intent ahead of time via a Fedora feature proposal.
> 
> I don't agree. Not using a protocol on public dnf-servers is on thing, 
> but removing the "ftp" protocol everywhere is just silly fanatism, IMHO.
> 
> Ralf

The FTP protocol is still included in libcurl-minimal, so the protocol is not 
going to disappear with the proposed F37 change.  On the other hand, it may 
happen that FTP will be unavailable by default in a year or two.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, February 24, 2022 3:37:56 PM CET Neal Gompa wrote:
> On Thu, Feb 24, 2022 at 8:58 AM Richard W.M. Jones  
wrote:
> > On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote:
> > > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote:
> > > > Did you discuss modularising curl itself upstream?
> > > 
> > > It was added to their wish list but I do not remember anybody working on 
it:
> > > https://github.com/curl/curl/commit/8204844f
> > > > 
> > > > That would be a better idea.
> > > 
> > > Not necessarily.  Each approach has its pros and cons.
> > 
> > I'm intrigued by what you think the cons would be.  AFAICT if curl was
> > modular in this way already we wouldn't be discussing this proposal at
> > all,
> > but a different and better one around packaging splits.
> 
> It would also avoid the usability nightmare that comes with trying to
> trigger switching implementations. This is a very big hammer that
> basically tells people that we're crippling curl by default for users
> and it has very large network effects across the entire distribution.
> It's quite one thing to use curl-minimal for containers where people
> expect tools to be broken in the endless pursuit of smaller base
> images, but when real people need to use real systems in complex
> configurations, having a reduced functionality curl by default is just
> going to lead to support nightmares and complaints about random
> breakages in applications on Fedora.

Installations that need libcurl-full will have it installed.  There is no 
problem there.  You could hardly find a default that will fit everybody's 
taste.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, February 24, 2022 2:58:10 PM CET Richard W.M. Jones wrote:
> On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote:
> > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote:
> > > Did you discuss modularising curl itself upstream?
> > 
> > It was added to their wish list but I do not remember anybody working on 
it:
> > https://github.com/curl/curl/commit/8204844f
> > > 
> > > That would be a better idea.
> > 
> > Not necessarily.  Each approach has its pros and cons.
> 
> I'm intrigued by what you think the cons would be.  AFAICT if curl was
> modular in this way already we wouldn't be discussing this proposal at all,
> but a different and better one around packaging splits.
> 
> Rich.

They key problem is that we would detect fewer problems at build time and more 
problems at run-time.  Users that prefer to use libcurl this way are already 
using it via pycurl or similar binding.  So there is no reason to cripple 
libcurl for users that prefer to use in a more predictable way.

Also environments where libcurl is used (for example Java Virtual Machine) are 
sensitive to the order in which shared libraries are loaded and initialized.  
If we make libcurl load external libraries (e.g. openldap) at run-time, it is 
not going to improve the already complicated situation.

The solution would also paralyze the automatic dependency scanner in rpmbuild, 
which sees only dependencies known at build time.

Fedora packaging guidelines also insist on the unversioned .so being packaged 
in a -devel package.  This complicates versioning of libraries that are loaded 
via dlopen().

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote:
> Did you discuss modularising curl itself upstream?

It was added to their wish list but I do not remember anybody working on it:

https://github.com/curl/curl/commit/8204844f

> That would be a better idea.

Not necessarily.  Each approach has its pros and cons.

Kamil

> Then we could package up the various *.so drivers into separate packages.
> 
> Also I think this whole business of minimizing Fedora is getting way
> out of hand.
> 
> Rich.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Wednesday, February 23, 2022 7:01:26 PM CET Björn Persson wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > According to ICANN [1], there were 8.3 mln IDN domains worldwide.
> 
> And that's presumably only second-level domains. Nobody knows how many
> non-ASCII subdomains exist under ASCII second-level domains, since
> domain holders define subdomains at will without telling anybody.
> 
> There are currently 153 non-ASCII top-level domains out of 1486 total,
> which is 10.3%:
> https://data.iana.org/TLD/tlds-alpha-by-domain.txt
> 
> > Apparently .рф is fairly popular, with 1/5th of .ru registrations [3].
> 
> And that was eight years ago, only four years after рф was opened for
> registrations.
> 
> > But from what I have seen, all those internationalized domains serve
> > as a redirect or backup to sites also available as ascii.
> 
> In 2013 11% of рф domains redirected to ASCII domains, 50% were in use
> and not redirecting, and 39% were only registered but unused. Already
> in 2011, the year after the floodgates were opened, 34% were in use and
> not redirecting. This is according to page 116 of this report:
> https://web.archive.org/web/20141210151244/http://www.eurid.eu/files/publ/ID
> NWorldReport2014_Interactive.pdf
> 
> But yes, it's still often necessary to resort to ASCII, either the ACE
> form (xn--gobbledygook) or a separate ASCII-only fallback domain. Email
> in particular remains a major drag. Only in 2012 was there enough
> consensus to publish a proposed standard for SMTPUTF8. Extensions to
> IMAP and POP followed in 2013. Support in various email-handling
> programs is still lacking. As long as people feel that they must have
> an ASCII domain for email, some will naturally choose to use that same
> domain for their website rather than using two separate domains.
> 
> > And for command-line
> > tools or scripting, using those ascii versions seems quite likely…
> 
> That's another area where support for IDNA is spotty, yes. OpenSSH
> still lacks support for example. So does Nmap. The Bind utils have
> incomplete and inconsistent support. "dig", "host" and "nslookup" can
> look up non-ASCII domain names, but if a server to query is specified,
> then they expect the server to have an ASCII-only name. "delv" lacks
> support entirely.
> 
> This is the problem that you're about to make worse. People will find
> that support for IDNA is unreliable in various programs that use Curl
> under the hood. To work around the problem they'll resort to the ACE
> form, or to an ASCII-only domain they have for precisely that purpose.
> Thus you end up hampering the adoption of international domains even
> more.
> 
> > So I'd definitely vote to enable libidn2 in curl-minimal,
> > _if_ there are people who'd actually use this for real.
> 
> People can't use it until it's consistently supported, and you won't
> support it until people use it. Do you mean to wait for all the other
> command line programs to support IDNA first, and then, when the whole
> world is waiting for you, then you'll turn it on in Curl and people
> will start using it? Guess what – everybody else is also waiting for
> everybody else.
> 
> This is the same deadlock that hampers IPv6, encrypted email and many
> other things. Everybody's waiting for everybody else to move first.
> 
> Björn Persson

There seems to be demand for libcurl with IDN support on minimal Fedora 
installations, so I created a pull request to enable it in libcurl-minimal:

https://src.fedoraproject.org/rpms/curl/pull-request/13

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Wednesday, February 23, 2022 10:22:00 AM CET Dmitry Belyavskiy wrote:
> Dear Kamil,
> 
> On Wed, Feb 23, 2022 at 8:51 AM Kamil Dudka  wrote:
> > On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote:
> > > Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > > > Yes. But how many domains using idn are there? I worked on idn support
> > > > in systemd, but when preparing the description of this change I
> > 
> > realized
> > 
> > > > that I have _never_ once used an idn domain outside of testing.
> > > > 
> > > > And note that this is not about user-facing programs like firefox.
> > > > I assume that there might be _some_ use of idn in firefox. But for
> > > > command-line tools like curl this seems even less likely.
> > > 
> > > I'm pretty sure use of IDN domains is a regional thing.  I live in the
> > > US and don't see IDN domains in my normal use.  But dropping support for
> > > them from a core utility would be bad for those that live in regions
> > > where IDN domains may be more common.
> > > 
> > > --
> > > Chris Adams 
> > 
> > If this appears to be a real problem, it is easy for us to re-enable IDN
> > in libcurl-minimal, even in an update of a stable Fedora release.  So I do
> > not think we need to enable it proactively.
> > 
> > Being from Russia and having several years of interacting with Universal
> 
> Acceptance, I'd say IDN is a must nowadays.

To be clear, I am not completely against including IDN in libcurl-minimal.
On the other hand, we removed IDN from libcurl in ubi9 images in September
and nobody has complained about it so far:

https://bugzilla.redhat.com/1994521

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 10:50:06 PM CET Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> 
> > Yes. But how many domains using idn are there? I worked on idn support
> > in systemd, but when preparing the description of this change I realized
> > that I have _never_ once used an idn domain outside of testing.
> > 
> > And note that this is not about user-facing programs like firefox.
> > I assume that there might be _some_ use of idn in firefox. But for
> > command-line tools like curl this seems even less likely.
> 
> 
> I'm pretty sure use of IDN domains is a regional thing.  I live in the
> US and don't see IDN domains in my normal use.  But dropping support for
> them from a core utility would be bad for those that live in regions
> where IDN domains may be more common.
> 
> -- 
> Chris Adams 

If this appears to be a real problem, it is easy for us to re-enable IDN
in libcurl-minimal, even in an update of a stable Fedora release.  So I do
not think we need to enable it proactively.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 9:45:30 PM CET Peter Robinson wrote:
> On Tue, Feb 22, 2022 at 5:00 PM Ben Cotton  wrote:
> 
> >
> >
> > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default
> >
> >
> >
> > == Summary ==
> > `libcurl-minimal` and `curl-minimal` will be installed by default
> > instead of `libcurl` and `curl`.
> > The "minimal" variants provide only a subset of protocols (HTTP, HTTPS,
> > FTP).
> 
> Does it make sense to keep FTP with most browsers obsoleting the
> protocol due to lack of security?

Not yet, in my opinion.  But it is a controversial topic, as you can see
in the preceding discussion on this mailing list.  Of course, each application 
that does not need FTP, can disable the protocol at run-time.  But disabling 
it globally on default installations of Fedora would make this change too 
controversial.  We can reconsider it later in case the initial change is well 
accepted.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Kamil Dudka]

On Tuesday, February 22, 2022 10:47:40 PM CET Chris Adams wrote:
> Once upon a time, Demi Marie Obenour  said:
> 
> > As mentioned above, the purpose of this change is to ensure that
> > vulnerabilities in obscure protocols impact a smaller fraction of
> > users.  Right now, a vulnerability in an obscure protocol impacts
> > most users.  With this change, it will only impact users that have
> > installed the full version of curl.  This is independent of whether a
> > given protocol should be disabled outright.
> 
> 
> I just feel that if there's enough security concern with some of the
> code, then Fedora shouldn't ship that code.  Either the code is secure
> enough and maintained well enough to ship, or it's not.

With your line of reasoning, one could also disable all the hardening etc.
Software security is not a black and white problem and terms like "secure 
enough" do not work in practice.  Security policies rather work with terms 
like probability and impact.  The lower those values are the better.

Kamil

> Otherwise, don't list this as a justification for the change proposal.
> 
> -- 
> Chris Adams 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: cmake on Rawhide is broken

[Kamil Dudka]

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
> Hello all.
> 
> Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with 
> libcrypto.so.1.1 and fails:
> 
> + /usr/bin/cmake -S . -B redhat-linux-build 
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
> -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
> RPM build errors:
> /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: 
> cannot open shared object file: No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
>  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
> Child return code was: 1
> 
> Affected Koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927

Same issue with my build of cswrap.  It is weird that it happens on x86_64 only:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Kamil Dudka]

On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> > > On 12/2/21 15:08, Sérgio Basto wrote:
> > > > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > > > or
> > > > /lib/ld-2.33.so ?
> > 
> > rephrasing my question :
> >  What is the difference of /usr/bin/ld.so  for /lib64/ld-2.33.so or
> > 
> > /lib/ld-2.33.so ?
> 
> /usr/bin/ld.so will have the same absolute path, regardless of glibc version.

And /usr/bin also appears in default ${PATH} unlike /lib or /lib64.

> Kamil
> 
> > > The lib64 one is 64-bit and the lib one is 32-bit.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Kamil Dudka]

On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> 
> > On 12/2/21 15:08, Sérgio Basto wrote:
> > 
> > > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > > or
> > > /lib/ld-2.33.so ?
> > 
> > 
> 
> 
> rephrasing my question : 
> 
>  What is the difference of /usr/bin/ld.so  for /lib64/ld-2.33.so or
> /lib/ld-2.33.so ? 

/usr/bin/ld.so will have the same absolute path, regardless of glibc version.

Kamil

> > The lib64 one is 64-bit and the lib one is 32-bit.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Kamil Dudka]

On Thursday, December 2, 2021 7:38:29 PM CET Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.  Today, ld.so can
> be used to activate preloading, for example.  Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocesses—something is that exactly what is needed.
> There is also some useful diagnostic output in --help,
> --list-diagnostics.
> 
> Having ld.so as a real command (instead of just a manual page) makes the
> name architecture-agnostic.  This discourages from hard-coding
> non-portable paths such as /lib64/ld-linux-x86-64.so.2 in scripts that
> require specific functionality offered by such an explicit loader
> invocation.
> 
> Do you see a problem with installing /usr/bin/ld.so?
> 
> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
> 
> Thanks,
> Florian

I love this idea.  As it is now, we have to to hard-wire the real path to 
ld.so at multiple places in csexec and query it back in the related wrapper 
scripts:

https://github.com/csutils/cswrap/wiki/csexec

If there was a standard path to the dynamic linker (for the native arch),
we could simplify our tooling that uses it explicitly.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Automated formal verification of RPM packages

[Kamil Dudka]

On Monday, November 8, 2021 7:10:45 PM CET Jerry James wrote:
> Nice!  Thanks for working on this.  I tried to use the csmock plugin,
> but got this at the end of the build (on an x86_64 F34 host, building
> for fedora-35-x86_64):
> 
> + for file in 
> /tmp/csmockadxnd155/metamath-0.198-1.fc36/debug/raw-results/builddir/cbmc-capture/pid-*.out
> + cbmc-convert-output -a
> /bin/sh: line 4: cbmc-convert-output: command not found
> 
> !!! 2021-11-08 10:02:57error: post-process hook failed
> 
> The problem appears to be that csmock-plugin-cbmc doesn't require cbmc
> or cbmc-utils:

Thank you for pointing it out!  It is exactly as you say.  I have submitted
a pull request to fix this:

https://github.com/csutils/csmock/pull/46

Kamil

> $ rpm -q --requires csmock-plugin-cbmc
> csexec
> csmock-common(python3)
> python(abi) = 3.9
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(PayloadIsZstd) <= 5.4.18-1
> 
> Regards,
> -- 
> Jerry James
> http://www.jamezone.org/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Automated formal verification of RPM packages

[Kamil Dudka]

Formal verification of RPM packages with CBMC, Divine, and Symbiotic is now
easier than ever before!  csmock plug-ins for these tools are now available
in stable Fedora releases.  The plug-ins are still experimental and they have
some technical limitations:

- They work only for source RPM packages that contain the %check section
  that directly or indirectly invokes the binaries produced in the %build
  section.

- The tools are known to work reliably only for programs written in C.

- Only one formal verification tool can be enabled in one run of csmock.

- Only *-x86_64 build roots are supported for now.

- The fedora-rawhide-x86_64 build root is not supported at the moment.


The plug-ins can be installed on a Fedora system using the following command:

$ sudo dnf install csmock-plugin-{cbmc,divine,symbiotic}

Then you can formally verify RPM packages of your choice:

$ csmock -r fedora-35-x86_64 -t ${tool} ${pkg}.src.rpm


These plug-ins were developed as part of the AUFOVER (Automation of Formal
Verification) research project:

https://research.redhat.com/blog/research_project/aufover-2/

Some useful tips can be found on the aufover/experiments wiki:

https://github.com/aufover/experiments


If you run into any issues please do not hesitate to reach out to us.
We welcome any feedback you may have as it will help us make further
improvements to the tools.

Kamil and the AUFOVER team

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Thursday, November 4, 2021 2:07:53 AM CET Adam Williamson wrote:
> On Wed, 2021-11-03 at 09:38 -0700, Adam Williamson wrote:
> > >  and that its
> > > 
> > > subject nor the body contained any information besides the (currently
> > > valid) URL to some JSON data.
> > 
> > I don't recall exactly how this part works, but it's *probably* because
> > this is broken:
> > 
> > https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/blob/dev
> > elop/fedmsg_meta_fedora_infrastructure/waiverdb.py#L33-L36
> > 
> > note it tries to use the key 'result_id' from the message, but current
> > waiverdb.waiver.new messages do not seem to include that field.
> 
> This should fix it:
> https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/508

Thank you for working on it!

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 6:32:34 PM CET Adam Williamson wrote:
> 4. The email notifications should be customizable via
> https://apps.fedoraproject.org/notifications/ , I believe. I do agree
> it would be good if we could tweak some defaults in the notification
> code to not notify you when you do things to your own stuff, as you
> likely don't need a notification in that case. But I never get around
> to doing this for my own account, let alone sending a patch to make it
> better for everyone...

To be clear, the problem is not that I get notifications for my own actions.  
I prefer to get such notifications on services like Github or Bugzilla, so 
that the full story is recorded in my mailbox.

The actual problem was that I received the same e-mail 49 times and that its 
subject nor the body contained any information besides the (currently valid) 
URL to some JSON data.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 8:30:15 PM CET Adam Williamson wrote:
> Further to this: I did re-run the tests, they did pass, it did make
> Bodhi happy, and I successfully submitted the update to stable. It
> should get pushed in the next push, I hope.
> 
> It looks like what happened is that Bodhi didn't update its recorded
> gating status for the update when the waivers were submitted. Note
> there's two different calculations of the gating status in Bodhi, which
> can confuse things. The status you see on the right-hand side of the
> web UI - "All required tests passed" or whatever - is actually
> generated *by the front end code* whenever your browser loads the page.
> The JS front end code runs a (verbose) Greenwave query when you view
> the page, and uses the results to generate that status and also the
> Automated Tests results list itself. So that status will always be 'up
> to date'.
> 
> When you try and push the update, though - whether by clicking on the
> button in the web UI, or using the CLI client - Bodhi doesn't use that
> status, because the Bodhi back end code doesn't *know* about that
> status at all. Instead it checks a property of the update object, which
> gets updated...sometimes. The "This update's test gating status has
> been changed to XXX" messages that get posted on the update
> periodically are actually telling you about *that* status check.
> Basically, unless the most recent message was "This update's test
> gating status has been changed to passed" or "This update's test gating
> status has been changed to ignored", you will not be able to push it.
> 
> I think probably the bit that broke down here is that when you
> submitted your waivers, Bodhi didn't get told. The way this is
> *currently* supposed to work is that Greenwave listens out for new
> waivers, decides whether they change an update push decision, and
> publishes a greenwave.decision.update message if so. Bodhi listens for
> the greenwave.decision.update messages and either just accepts what
> they say or re-calculates the decision (it depends on some other stuff
> that doesn't matter rn). Looking through datagrepper logs, I see
> waiverdb.waiver.new messages from waiverdb when you created your
> waivers, but I *don't* see greenwave.decision.update messages in
> response to them. So I think Greenwave messed up and didn't think the
> waivers changed the decision. So Bodhi didn't get a message telling it
> to re-calculate the gating status, and it stayed at 'failed'.
> 
> There is, I believe, a cron job that runs every few hours or every day
> or something that re-calculates the gating status of *every* active
> update, so it would probably have got caught up at some point. But it
> should really get recalculated as soon as a relevant waiver is
> submitted.
> 
> I *hope* this should be fixed in the next Bodhi release, whenever it
> gets done and deployed. I actually rewrote how that works completely:
> 
> https://github.com/fedora-infra/bodhi/pull/4230
> 
> mainly because I considered the existing design to be flat out wrong
> (for reasons I won't go into unless you really care :>), but also
> because I did, a few months ago, look through the code and find that
> greenwave could get this wrong for openQA tests/waivers. I forget the
> details, but there's some point at which it makes some assumptions
> which are only true for CI tests/waivers. I started out aiming to fix
> that, but instead decided the design was wrong and it made more sense
> to have Bodhi just listen out for new result / new waiver messages
> directly. I believe I wrote that properly so it will work for
> waivers/results related to both CI and openQA tests, but we'll find out
> for sure when it's deployed, I guess. :D
> 
> Sorry again for the trouble!

Thank you for taking care of the update as well as explaining the problem
in detail!

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 4:19:23 PM CET Kalev Lember wrote:
> My understanding is that the test that failed and is blocking the push to
> stable is the openQA test. When I discussed a similar issue that a GNOME
> megaupdate ran into with adamw a few weeks ago, he said that the way to
> retrigger openQA tests is to either edit the builds in the update or
> unpush/submit it again to testing, and that the retrigger tests button
> doesn't do anything for openQA tests. Apparently Bodhi also has some kind
> of issue with waiving openQA tests so waiving doesn't work in practice. :)
> 
> Maybe it's worth a try here to see if unpushing and resubmitting to testing
> helps? And if it doesn't, maybe ask on irc in #fedora-qa to see if they can
> help get the openQA tests for the update going again?
> 
> Hope this helps,
> Kalev

Thanks for the suggestion!  I have just tried it.  It seems to be one step 
backwards now but it might help with some delay...

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 3:37:03 PM CET Fabio Valentini wrote:
> Maybe multiple people attempting to waive test results and re-triggering
> tests while things are still pending is not a good idea?
> 
> It looks like the re-triggered tests failed again, after the tests had been
> waived, overriding the waiver. (please correct me if I'm wrong)
> 
> Fabio
> 
> (PS: sorry if this shows up as HTML email, I don't have access to my Fedora
> machine right now)

To be sure, I tried to do both actions (waive and request stable) in a short 
period of time but the result is still the same.  Another batch of useless
e-mail notifications is now coming my way...

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 3:10:47 PM CET Mattia Verga via devel wrote:
> It appears that the tests are now waived, so you can push the update to
> stable as usual.
> 
> Mattia

I wish I could but it is unfortunately sill not the case:

$ bodhi updates request FEDORA-2021-1d24845e93 stable
Requirement not met Required tests did not pass on this update

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 2:17:28 PM CET Kamil Dudka wrote:
> On Tuesday, November 2, 2021 1:58:02 PM CET Miro Hrončok wrote:
> > On 02. 11. 21 8:47, Kamil Dudka wrote:
> > > On September 22 I submitted a Fedora 35 update of curl, which obsoleted
> > > a previously submitted security update of curl.  The update has reached
> > > karma +13 since then, yet I was unable to make Bodhi push the update to
> > > 
> > > stable:
> > >  https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d24845e93
> > > 
> > > I can see that there are some automated tests failing but I have no idea
> > > where the tests come from or how to waive their results.
> > 
> > To waive their results:
> >  $ bodhi updates waive FEDORA-2021-1d24845e93 "Test didn't run"
> 
> Thanks for the hint!  I have just tried it but there seems to be no status
> update as of yet.  The current status is still "testing".

As a side-effect I received 49 identical e-mails from 
notificati...@fedoraproject.org
with not very specific subject "fedmsg notification" and the following link 
inside:

https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0/waivers/9123

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 1:58:02 PM CET Miro Hrončok wrote:
> On 02. 11. 21 8:47, Kamil Dudka wrote:
> > On September 22 I submitted a Fedora 35 update of curl, which obsoleted
> > a previously submitted security update of curl.  The update has reached
> > karma +13 since then, yet I was unable to make Bodhi push the update to
> > 
> > stable:
> >  https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d24845e93
> > 
> > I can see that there are some automated tests failing but I have no idea
> > where the tests come from or how to waive their results.
> 
> To waive their results:
> 
>  $ bodhi updates waive FEDORA-2021-1d24845e93 "Test didn't run"

Thanks for the hint!  I have just tried it but there seems to be no status 
update as of yet.  The current status is still "testing".  The only action 
that is available to me is "Unpush", which is not really helpful.

> To actually run the tests: there is a *Re-Trigger Tests* button in the ride
> column of the update in bodhi. Also:
> 
>  $ bodhi updates trigger-tests FEDORA-2021-1d24845e93

I clicked the button multiple times in the past.  It did not help.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On Tuesday, November 2, 2021 9:14:31 AM CET Peter Robinson wrote:
> On Tue, Nov 2, 2021 at 7:48 AM Kamil Dudka  wrote:
> 
> >
> >
> > On September 22 I submitted a Fedora 35 update of curl, which obsoleted
> > a previously submitted security update of curl.  The update has reached
> > karma +13 since then, yet I was unable to make Bodhi push the update to
> > stable:
> >
> >
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d24845e93
> >
> >
> >
> > I can see that there are some automated tests failing but I have no idea
> > where the tests come from or how to waive their results.  The tests
> > directory in the f35 branch in Fedora git has not been touched since
> > 2017:
> >
> >
> >
> > https://src.fedoraproject.org/rpms/curl/c/c7e4ac60
> >
> >
> >
> > Any idea how to move the update forward?
> 
> 
> Well I don't know about the tests but you could have filed it as a
> blocker/freeze exception [1] for F-35 as we have a policy for fixing
> CVEs for things that are shipped in core artifacts because things like
> installers/Live images etc aren't updated over the life of the
> release, that ship has now sailed but please be aware of the process
> going forward especially for something as core as curl.
> 
> [1] https://qa.fedoraproject.org/blockerbugs/

Thanks for heads up!  Nevertheless, curl upstream releases each 8 weeks and 
each release usually contains some security fixes.  So, if the images do not 
get updated over the life of the release, we will be in a similar situation
a few weeks later anyway.  And we always need to balance the risk and profit 
for any last minute changes...

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora 35 security update of curl blocked for a month

[Kamil Dudka]

On September 22 I submitted a Fedora 35 update of curl, which obsoleted
a previously submitted security update of curl.  The update has reached
karma +13 since then, yet I was unable to make Bodhi push the update to 
stable:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-1d24845e93

I can see that there are some automated tests failing but I have no idea
where the tests come from or how to waive their results.  The tests
directory in the f35 branch in Fedora git has not been touched since 2017:

https://src.fedoraproject.org/rpms/curl/c/c7e4ac60

Any idea how to move the update forward?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libcurl-minimal

[Kamil Dudka]

On Saturday, October 16, 2021 5:32:17 PM CEST Richard W.M. Jones wrote:
> On Thu, Oct 14, 2021 at 09:52:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Hi Kamil and everyone,
> > 
> > what is the plan with introduction of libcurl-minimal in Fedora?
> > IIUC, libcurl and libcurl-minimal both have the same Provides, so
> > libcurl-minimal can be used to satisfy automatically generated
> > dependencies:
> > 
> > $ dnf repoquery --provides libcurl-minimal
> > libcurl = 7.78.0-3.fc35
> > libcurl(x86-32) = 7.78.0-3.fc35
> > libcurl(x86-64) = 7.78.0-3.fc35
> > libcurl-minimal = 7.78.0-3.fc35
> > libcurl-minimal(x86-32) = 7.78.0-3.fc35
> > libcurl-minimal(x86-64) = 7.78.0-3.fc35
> > libcurl.so.4
> > libcurl.so.4()(64bit)
> > $ dnf repoquery --provides libcurl
> > libcurl = 7.78.0-3.fc35
> > libcurl(x86-32) = 7.78.0-3.fc35
> > libcurl(x86-64) = 7.78.0-3.fc35
> > libcurl-full = 7.78.0-3.fc35
> > libcurl-full(x86-32) = 7.78.0-3.fc35
> > libcurl-full(x86-64) = 7.78.0-3.fc35
> > libcurl.so.4
> > libcurl.so.4()(64bit)
> 
> What's the aim here?  Small size on disk?  General fear of having
> insecure but unused protocols linked with programs?

Both.  The size reduction is, of course, more significant when you count
the libraries that are directly or indirectly pulled in by the rarely used 
protocols or features of (lib)curl.

The decision whether a security issue applies to a certain deployment is often 
not driven by experts with deep technical knowledge of projects like curl.
An argument that a protocol is normally not used by a program, or that the 
protocol is disabled on almost all code paths, may appear less compelling to 
the decision makers than if the code in question was simply not compiled in.

> It's a shame it has to be packaged this way.  I got half way through
> writing a curl handler (which I really must finish) and my impression
> is that at a code level they are quite modular, so maybe upstream
> would be interested in turning them into real loadable modules.  Then
> we could package each protocol ("curl-http.so") as a separate RPM
> which is really best of all worlds.

That might be an alternative with all its pros and cons.  But it is simply
not available now and nobody is working on it, as far as I know.

> In the meantime I'd like to encourage every program in Fedora that
> uses curl to call CURLOPT_PROTOCOLS(3).  This is a real defence
> against remote exploits (CVE-2013-0249 was one that happened in qemu).

Yes, that makes sense.

Kamil

> Rich.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libcurl-minimal

[Kamil Dudka]

On Sunday, October 17, 2021 2:40:05 PM CEST Steven Grubb wrote:
> On Sat, Oct 16, 2021 at 10:08 PM Kevin Kofler via devel <
> 
> devel@lists.fedoraproject.org> wrote:
> > Steve Grubb wrote:
> > > I'd like to suggest making libcurl-minimal very minimal for security
> > > reasons. The main curl package has many security issues (CVE's)
> > > constantly. But usually, the problem is in some obscure
> > > feature/protocol.
> > > Looking at the packages that depend on libcurl with rpmreaper, most
> > > would
> > > use http(s). There might be some that use another protocol. But clear
> > 
> > text
> > 
> > > protocols like telnet and ftp really don't have a use in today's
> > 
> > internet.
> > 
> > > Too many threats for clear text.
> > 
> > I suspect that disabling FTP in libcurl is going to break a lot of stuff.
> 
> I'd be curious, what package uses curl for it's FTP support?
> 
> -Steve

For example dracut, dnf, and rpm seem to use FTP:


https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55

https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636

https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio/url.c#L25

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libcurl-minimal

[Kamil Dudka]

On Friday, October 15, 2021 12:47:44 PM CEST Mark Wielaard wrote:
> Hi,
> 
> On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote:
> 
> > As I understand it, Zbyszek is now proposing to make changes to other
> > packages  and/or distribution metadata in order to make
> > (lib)curl-minimal actually used on some Fedora installations by default.
> 
> 
> This sounds interesting. For elfutils-debuginfod-client we really only
> support http(s):// and file:// so replacing our dependency from full
> libcurl to libcurl-minimal seems a good idea (assuming those 3
> protocols are in libcurl-minimal). Please let us know what we should
> do/test to see if this works as intended.

I think that no changes are needed in the elfutils-debuginfod-client package 
for now.  libcurl-minimal provides libcurl, so you should be able to simply 
swap the packages and use libcurl-minimal with elfutils-debuginfod-client:

# yum install --allowerasing libcurl-minimal

Actually, putting a strict requirement on libcurl-minimal to any package
would be counterproductive because it would prevent users from "upgrading"
to libcurl-full.

We would rather need it the other way around -- explicitly tag the packages 
that would *not* work properly with libcurl-minimal for some reason.

Kamil

> Thanks,
> 
> Mark

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libcurl-minimal

[Kamil Dudka]

On Thursday, October 14, 2021 3:27:03 PM CEST Steve Grubb wrote:
> Hello,
> 
> On Thursday, October 14, 2021 6:51:54 AM EDT Kamil Dudka wrote:
> > > what is the plan with introduction of libcurl-minimal in Fedora?
> > 
> > I proposed to use libcurl-minimal and curl-minimal in minimal base images
> > 
> > half a year ago but there has been no reply so far:
> > https://pagure.io/minimization/issue/25
> 
> I'd like to suggest making libcurl-minimal very minimal for security
> reasons. The main curl package has many security issues (CVE's) constantly.
> But usually, the problem is in some obscure feature/protocol. Looking at
> the packages that depend on libcurl with rpmreaper, most would use http(s).
> There might be some that use another protocol. But clear text protocols
> like telnet and ftp really don't have a use in today's internet. Too many
> threats for clear text.
> 
> So with security in mind - and not solving excessive dependencies, I'd
> suggest going very minimal. Just maybe 3 or 4 of the most used protocols by
> things that require libcurl.
> 
> Cheers,
> -Steve

Hi Steve,

this is exactly what the following bug (filed by Jan Pazdziora) is about:

https://bugzilla.redhat.com/2005874

The changes proposed in the above bug have already landed into Fedora Rawhide.

As I understand it, Zbyszek is now proposing to make changes to other packages 
and/or distribution metadata in order to make (lib)curl-minimal actually used 
on some Fedora installations by default.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libcurl-minimal

[Kamil Dudka]

Hi Zbyszek,

On Thursday, October 14, 2021 11:52:59 AM CEST Zbigniew Jędrzejewski-Szmek 
wrote:
> Hi Kamil and everyone,
> 
> what is the plan with introduction of libcurl-minimal in Fedora?

I proposed to use libcurl-minimal and curl-minimal in minimal base images
half a year ago but there has been no reply so far:

https://pagure.io/minimization/issue/25

> IIUC, libcurl and libcurl-minimal both have the same Provides, so
> libcurl-minimal can be used to satisfy automatically generated
> dependencies:
> 
> $ dnf repoquery --provides libcurl-minimal  
> libcurl = 7.78.0-3.fc35
> libcurl(x86-32) = 7.78.0-3.fc35
> libcurl(x86-64) = 7.78.0-3.fc35
> libcurl-minimal = 7.78.0-3.fc35
> libcurl-minimal(x86-32) = 7.78.0-3.fc35
> libcurl-minimal(x86-64) = 7.78.0-3.fc35
> libcurl.so.4
> libcurl.so.4()(64bit)
> $ dnf repoquery --provides libcurl
> libcurl = 7.78.0-3.fc35
> libcurl(x86-32) = 7.78.0-3.fc35
> libcurl(x86-64) = 7.78.0-3.fc35
> libcurl-full = 7.78.0-3.fc35
> libcurl-full(x86-32) = 7.78.0-3.fc35
> libcurl-full(x86-64) = 7.78.0-3.fc35
> libcurl.so.4
> libcurl.so.4()(64bit)
> 
> AFAICS, no other package makes use of libcurl-{full,minimal}.
> In systemd we only care about a narrow subset of protocols, so
> libcurl-minimal is perfect. I considered adding
> Suggests:libcurl-minimal%{_isa} in systemd. IIUC, that'd bias dnf towards
> the installation of libcurl-minimal. But the problem is that if some other
> package expects libcurl in the full version, it'll be disappointed.

If a package (strictly) requires libcurl-full, it should probably have an
explicit dependency for it.  If some packages require implementation of a
specific protocol or feature, we could introduce virtual provides for them,
too, to make the sets of protocols/features in the -minimal variants less
hard-coded.

> Hence my question: how to proceed with pulling in libcurl-minimal where
> it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in
> systemd and let the maintainers of other packages add
> Recommends:libcurl-minimal%{_isa} or Requires:libcurl-minimal%{_isa} if
> they need it? What packages would that be? 
> Another option would be do not do any of this at package level, but instead
> pull in libcurl-minimal through comps or kickstart or equivalent when doing
> installations.

This is more a question for users of (lib)curl.  I do not have any strong
opinion on that.

Kamil

> (Sorry if this is all documented somewhere… I looked around, but didn't see
> anything relevant.)
> 
> Zbyszek

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

[Kamil Dudka]

On Monday, October 4, 2021 2:24:22 PM CEST Miro Hrončok wrote:
> On 04. 10. 21 14:16, Kamil Dudka wrote:
> > On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote:
> >> Some results from a Rawhide podman container:
> >> 
> >> # koji download-build --arch x86_64 coreutils-9.0-1.fc36
> >> # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm
> >> coreutils-9.0-1.fc36.x86_64.rpm
> >> 
> >   # git clone
> >> 
> >> https://github.com/systemd/systemd
> >> # cd systemd
> >> # /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
> >> # echo $?
> >> 1
> >> 
> >> Some further tests:
> >> # mkdir test
> >> # cd test
> >> # touch testfile
> >> # ln -s testfile testlink
> >> # strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w .
> > 
> > Thanks for the reproducer!  This is a regression in the new upstream 
> > release:
> >  https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v
> >  9.0-2-ge8b56ebd536> 
> > I will submit a fixed build as soon as I figure out how to untag the
> > broken one:
> > 
> > $ koji untag-build f36 coreutils-8.32-31.fc36
> > 2021-10-04 14:16:18,518 [ERROR] koji: ActionNotAllowed: tag requires
> > autosign permission
> It seems that coreutils itself builds fine, so there should be no need to
> untag jut to fix it:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=76673896

Indeed.  A build of coreutils with the upstream fix applied is running:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1840134

Thank you both for the help and sorry for the breakage!

Kamil

> But either way: to answer the question how to untag: You need a releng
> person to do that.
> 
> Or, you can:
> 
>   $ fedpkg request-side-tag
>   $ koji tag f36-build-side-12345 coreutils-8.32-32.fc36
>   $ koji wait-repo f36-build-side-12345 --build coreutils-8.32-32.fc36
>   $ fedpkg build --target f36-build-side-12345

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

[Kamil Dudka]

On Monday, October 4, 2021 1:58:36 PM CEST František Šumšal wrote:
> Some results from a Rawhide podman container:
> 
> # koji download-build --arch x86_64 coreutils-9.0-1.fc36
> # dnf install coreutils-common-9.0-1.fc36.x86_64.rpm
> coreutils-9.0-1.fc36.x86_64.rpm
 # git clone
> https://github.com/systemd/systemd
> # cd systemd
> # /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
> # echo $?
> 1
> 
> Some further tests:
> # mkdir test
> # cd test
> # touch testfile
> # ln -s testfile testlink
> # strace /usr/bin/chmod -R a+rX,u+w,g-w,o-w .

Thanks for the reproducer!  This is a regression in the new upstream release:


https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-2-ge8b56ebd536

I will submit a fixed build as soon as I figure out how to untag the broken one:

$ koji untag-build f36 coreutils-8.32-31.fc36
2021-10-04 14:16:18,518 [ERROR] koji: ActionNotAllowed: tag requires autosign 
permission

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bad exit status from %prep during chmod -Rf a+rX,u+w,g-w,o-w . (coreutils 9.0-1.fc36)

[Kamil Dudka]

On Monday, October 4, 2021 11:57:14 AM CEST Miro Hrončok wrote:
> Hello,
> 
> I see this failure in dnf in Copr and Koji:
> 
> https://copr.fedorainfracloud.org/coprs/churchyard/patch251/build/2872812/
> https://koji.fedoraproject.org/koji/taskinfo?taskID=76673401
> 
> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.x8REO2
> + umask 022
> + cd /builddir/build/BUILD
> + cd /builddir/build/BUILD
> + rm -rf dnf-4.9.0
> + /usr/bin/gzip -dc /builddir/build/SOURCES/dnf-4.9.0.tar.gz
> + /usr/bin/tar -xof -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd dnf-4.9.0
> + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
> error: Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep)
>  Bad exit status from /var/tmp/rpm-tmp.x8REO2 (%prep)
> 
> I am perplexed with the error.
> 
> Could it be some problem with updated coreutils?

Yes.  The error message comes from rpmbuild.  chmod itself did not provide
any diagnostic message.  Is it possible to trigger the error locally?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proposal to deprecated `fedpkg local`

[Kamil Dudka]

On Thursday, January 28, 2021 7:55:05 PM CET Vít Ondruch wrote:
> Dne 28. 01. 21 v 19:36 Simo Sorce napsal(a):
> > On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote:
> >> Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a):
> >>> Vít Ondruch  writes:
>  Thx everybody for their responses and sorry for such controversial
>  topic. I am not going to propose this upstream after all. However I
>  have
>  few takeaways:
>  
>  1) I see responses of Fedora long timers and I understand that you
>  have polished workflows. But I really think that for newcomers, mock
>  should be the preferred way. I'd love to see documentation adjusted to
>  prefer mock everywhere.
>  
>  2) I would really love you to stop using VMs for your build/testing.
>  With exception of Kernel and Kernel related issues, the argument of
>  "mock being slow" can't stand. Every VM will be more resources hungry
>  then mock, slowing every your task.
>  
>  3) The argument of mock being slow can't stand, because in one of my
>  examples I posted elsewhere in this thread, I picked up the simplest
>  package I could and the build took 7 seconds. This is certainly not
>  slow, in this time you can't even switch to your email client to check
>  your emails.
> >>> 
> >>> So far on this thread, you've asked feedback on a proposal, and then
> >>> when provided with feedback you didn't like, repeatedly argued with our
> >>> comments and told us we're wrong.  This is not a good way to engage with
> >>> feedback.
> >> 
> >> I have provided the numbers here:
> >> 
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
> >> rg/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/
> >> 
> >> where I tried to point out that I don't perceive build of trivial
> >> package done in 7s to be slow. For nontrivial package the mock overhead
> >> is negligible. Nobody replied (in constructive way). On various places,
> >> I have suggested to use "--no-clean" option for repeated builds. But in
> >> the whole thread, there was no confirmation that anyone would use it.
> >> 
> >> Yet I am repetitively told that mock is slow, you repeat it down bellow
> >> once again without any evidence. Your only argument to this discussion
> >> is that mock is slow, because you believe so and other people have said
> >> so. I would really appreciate if I was given some specific
> >> counterargument supported by numbers.
> > 
> > That "mock is slow" is just one of the claims, and not the prevalent
> > one at that.
> > It is also inconvenient.
> > Takes disk space and bandwidth I do not care for.
> > It is complex to use when what you care is to fit the current running
> > systems.
> > And in general, for those that do not use it is yet another thing to
> > learn to use that I personally do not care for learning as I have no
> > need for it.
> > 
> > You are claiming that "fedpkg local" is bad, we are responding it is
> > not, we use it and it works better for us.
> > 
> > As for many other things there isn't just one true way, mock works best
> > for you, and local works best for others, why is that a problem ?
> 
> I have started the thread reflecting on experience of fresh packager
> coming to Fedora. First issue was that `fedpkg local` pollutes the work
> directory. There is also second issue, that `fedpkg local` is polluting
> the whole system with build dependencies (and this is my concern). I
> don't think that anybody should have polluted work directory and their
> system by packagers work. If experienced packages are fine with that, so
> be it. But I am concerned, that these practices are possibly suggested
> to fresh coming people.
> 
> I have already withdrew the original proposal, but that does not mean I
> am less concerned.
> 
> 
> Vít

I have never used `fedpkg local` myself.  However, what prevents me from doing 
the following steps?

$ fedpkg srpm
$ sudo yum builddep ...
$ rpmbuild --rebuild ...
$ sudo yum install ...

The above is my usual workflow when I debug something.  Is it also going to be 
prohibited in some way?

Kamil

> > Simo.
> > 
> >> Vít
> >> 
> >>> In particular, *numerous* people have told you that mock builds are
> >>> slow for us.  Instead of telling us that we're wrong about our own
> >>> experience because it doesn't match yours, make an effort to understand
> >>> what the difference is between them.  Or accept it for what it is:
> >>> feedback that *you asked for*.
> >>> 
> >>> Thanks,
> >>> --Robbie
> >> 
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/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: Deprecating SCP

[Kamil Dudka]

On Monday, November 2, 2020 6:31:33 PM CET Florian Weimer wrote:
> * Kamil Dudka:
> > On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote:
> >> * Kamil Dudka:
> >> > As far as I know, (lib)curl has never silently transformed a protocol
> >> > scheme explicitly specified with URL.  This can be discussed upstream
> >> > but I do not feel like starting the discussion myself.
> >> 
> >> Curl does it for https://, so it should be fine for scp://.
> > 
> > Could you please be more specific?  What exactly does curl do for https://
> > ?
> It automatically replaces the underlying HTTP transport with HTTP/2 if
> the server replaces it.  These protocols are about as similar as SCP and
> SFTP, I would say.

Thank you for clarifying it!

The key difference is that the HTTP protocol upgrade to HTTP/2 (or HTTP/3
via Alt-Svc header) are covered by IETF specifications.  There is also no 
protocol scheme to specify HTTP/2 explicitly in URL, unlike SCP vs. SFTP.

Kamil

> Thanks,
> Florian

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Deprecating SCP

[Kamil Dudka]

On Monday, November 2, 2020 5:57:29 PM CET Florian Weimer wrote:
> * Kamil Dudka:
> 
> 
> > As far as I know, (lib)curl has never silently transformed a protocol
> > scheme explicitly specified with URL.  This can be discussed upstream
> > but I do not feel like starting the discussion myself.
> 
> 
> Curl does it for https://, so it should be fine for scp://.

Could you please be more specific?  What exactly does curl do for https:// ?

Kamil

> Thanks,
> Florian
> -- 
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
> O'Neill

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Deprecating SCP

[Kamil Dudka]

On Monday, November 2, 2020 4:47:47 PM CET Simo Sorce wrote:
> On Mon, 2020-11-02 at 16:36 +0100, Kamil Dudka wrote:
> > How is the "compatibility scpd to support old clients" going to differ
> > from the current implementation?
> > 
> > libcurl implements its own SCP client over libssh.  Will this
> > implementation 
> > continue to work after OpenSSH gets updated on servers?
> > 
> > Applications often allow users to pass arbitrary URLs to libcurl.  So one
> > can, 
> > for example, use scp:// URLs to specify a kickstart for Anaconda. 
> > The fact that scp utility will be reimplemented over SFTP does not help
> > much in this case.  Each build of libcurl that supports scp:// supports
> > sftp:// as well. But libcurl will not transmit scp:// requests over
> > sftp:// in case SCP is not supported by the remote server any more.
> 
> 
> Sounds like a RFE for libcurl to slowly move scp:// to be using the
> sftp protocol instead ?

As far as I know, (lib)curl has never silently transformed a protocol scheme 
explicitly specified with URL.  This can be discussed upstream but I do not 
feel like starting the discussion myself.

> Or they could simply deprecate it, and then users will have to change
> their config to say sftp://
> 
> For something like libcurl the latter is probably more appropriate
> anyway.

Yes, I believe this is the curl way to handle it.  Nothing is being changed 
for curl now as I understand it.  So there is no need to take an immediate 
action.  Anyway, I will notify curl upstream about the plan so they are not 
surprised later on.

Kamil

> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Deprecating SCP

[Kamil Dudka]

On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote:
> Hi Fedora users!
> 
> Over the last years, there were several issues in the SCP protocol, 
> which lead us into discussions if we can get rid of it in upstream [1]. 
> Most of the voices there said that they use SCP mostly for simple ad-hoc 
> copy and because sftp utility does not provide simple interface to copy 
> one or couple of files back and forth and because of people are just 
> used to write scp rather than sftp.
> 
> Some months ago, I wrote a patch [2] for scp to use SFTP internally 
> (with possibility to change it back using -M scp) and ran it through 
> some successful testing. The general feedback from upstream was also 
> quite positive so I would like to hear also opinions from our users.
> 
> It still has some limitations (missing -3 support, it will not work if 
> the server does not run sftp subsystem, ...), but it should be good 
> enough for most common use cases.
> 
> Today, I set up a copr repository with the current openssh from Fedora + 
> the patch [2] for anyone to test and provide feedback, either here on 
> the mailing list, or in the github PR according to ones preferences.
> 
> I am looking for any kind of feedback from the idea through the 
> usability, implementation. Is this something you would like to see in 
> Fedora soon? Do you have something against this? Is your use case missing?
> 
> [1] 
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html
> [2] https://github.com/openssh/openssh-portable/pull/194/
> [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/

How is the "compatibility scpd to support old clients" going to differ
from the current implementation?

libcurl implements its own SCP client over libssh.  Will this implementation 
continue to work after OpenSSH gets updated on servers?

Applications often allow users to pass arbitrary URLs to libcurl.  So one can, 
for example, use scp:// URLs to specify a kickstart for Anaconda.  The fact 
that scp utility will be reimplemented over SFTP does not help much in this 
case.  Each build of libcurl that supports scp:// supports sftp:// as well.  
But libcurl will not transmit scp:// requests over sftp:// in case SCP is not 
supported by the remote server any more.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Error creating the package RPM: make:*** No rule to make target 'install'.

[Kamil Dudka]

On Thursday, October 1, 2020 11:50:02 AM CEST Helg Green via devel wrote:
> %build
> cd app
> make %{?_smp_mflags}
> 
> %install

I guess that `cd app` is missing here?

Kamil

> mkdir -p %{buildroot}
> make install INSTALL_ROOT=%{buildroot}
> 
> %post
> # Setup icons
> touch -c /usr/share/icons/hicolor
> if command -v gtk-update-icon-cache >/dev/null 2>&1; then
>   gtk-update-icon-cache -tq /usr/share/icons/hicolor 2>/dev/null ||:
> fi

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [ELN] need a working build of systemtap for a rebuild of qemu

[Kamil Dudka]

On Wednesday, September 23, 2020 1:09:37 PM CEST Aleksandra Fedorova wrote:
> Thanks for the heads-up. There was a CI cluster downtime yesterday and
> the build was impacted by it. I restarted it, and it passed
> 
> https://osci-jenkins-1.ci.fedoraproject.org/job/eln-build-pipeline/17459/
> 
> The systemtap-4.4-0.20200922git05179173e71c.eln103 is now available in
> ELN buildroot.

systemtap-4.4-0.20200922git05179173e71c.eln103 works for me.  Thanks!

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[ELN] need a working build of systemtap for a rebuild of qemu

[Kamil Dudka]

The latest eln build of systemtap fails to install, which prevents qemu
from being built:

https://bugzilla.redhat.com/1881342

The maintainer of systemtap says that it is the eln rebuild what went wrong.  
So he created a new rawhide build in the hope that it will trigger a new eln 
build, which would afterwards be installable in the eln buildroot.

But there is no eln (re)build of systemtap-4.4-0.20200922git05179173e71c.fc34 
yet despite builds that landed into rawhide much later are already rebuilt.

Could someone from the ELN team please check what happened?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Tuesday, July 21, 2020 4:02:29 PM CEST Neal Gompa wrote:
> On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka  wrote:
> > What exactly do you mean by "work"?  If the option does not take any
> > effect, that is perfectly fine because the Fedora change did not reach
> > EPEL-8 (yet).
> > 
> > Or are you saying that using cmake -B. breaks EPEL-8 builds?  Do you have
> > any example?
> 
> I'm saying that doing that is supposed to break CMake on RHEL 8
> because the option isn't supported. That's *why* I haven't yet
> backported the macros to EPEL 8. I am trying to work around missing
> features in CMake.

That does not really matter.  My fix based on `-B.` works fine on Fedora and 
does not break anything on EPEL-7 and EPEL-8.  It is currently not needed on 
EPEL-8 but it is harmless and I am able to use a single spec file (without any 
%ifdef) everywhere.  In case the backward-incompatible change of the %cmake 
macro reaches EPEL-8 (after an update of cmake), the fix will work there, too.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Tuesday, July 21, 2020 3:41:02 PM CEST Neal Gompa wrote:
> On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka  wrote:
> > On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
> > > That's odd, it shouldn't work,
> > 
> > I believe it does.
> > 
> > > since -B wasn't introduced until CMake 3.13...
> > 
> > You only need working -B option to override a previously specified -B
> > option. Otherwise CMake defaults to the current working directory as
> > build directory. So appending -B. is a no-op on EPEL-7 and EPEL-8, which
> > were not affected by this change.
> 
> So my understanding is that the option shouldn't work at all on CMake
> 3.11 in EPEL 8, as it does not exist in the man page:
> https://cmake.org/cmake/help/v3.11/manual/cmake.1.html

What exactly do you mean by "work"?  If the option does not take any effect, 
that is perfectly fine because the Fedora change did not reach EPEL-8 (yet).

Or are you saying that using cmake -B. breaks EPEL-8 builds?  Do you have
any example?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
> That's odd, it shouldn't work,

I believe it does.

> since -B wasn't introduced until CMake 3.13...

You only need working -B option to override a previously specified -B option.
Otherwise CMake defaults to the current working directory as build directory.
So appending -B. is a no-op on EPEL-7 and EPEL-8, which were not affected by 
this change.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Monday, July 20, 2020 9:23:46 PM CEST Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 20 July 2020 at 20:46, Kamil Dudka wrote:
> 
> > On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
> > 
> > > Or you could just use "%global __cmake_in_source_build 1" which
> > > reverts to the previous behavior.
> > 
> > 
> > That does not make any sense.  The packages I talk about have used
> > out of source builds since forever.
> > 
> > 
> > > Or you could *actually* make it do it out of source even with older
> > > Fedora releases as I did with my example commit.
> > 
> > 
> > I thought I did.  And not only for Fedora releases ;-)
> > 
> > https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/
> 
> 
> Is there any way to make this portable across all Fedora releases and
> EPEL? I'd like to avoid %ifdeffery if possible.

The fix I mentioned (appending -B.) worked for me on EPEL-7, EPEL-8 and 
Fedora, without any %ifdef.

Kamil

> Regards,
> Dominik

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
> Or you could just use "%global __cmake_in_source_build 1" which
> reverts to the previous behavior.

That does not make any sense.  The packages I talk about have used
out of source builds since forever.

> Or you could *actually* make it do it out of source even with older
> Fedora releases as I did with my example commit.

I thought I did.  And not only for Fedora releases ;-)

https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

[Kamil Dudka]

On Monday, July 20, 2020 7:37:25 PM CEST Neal Gompa wrote:
> This is because ceph is not adapted yet for
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

Yes, this change broke a lot of builds as it had been discussed on this list.

> Your spec file is a complete mess, so I have not yet touched it to fix it.

The spec file looks fine to me.  Have you ever seen texlive.spec?

> Here's an example of how I fixed one package:
> https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576
> 6cba54da78
 
I had exactly the same problem in my own projects.  Appending -B. at the end 
of the line(s) starting with %cmake has fixed it:

https://github.com/kdudka/predator/commit/34ef2198

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

[Kamil Dudka]

On Thursday, July 2, 2020 1:02:05 PM CEST Nicolas Mailhot via devel wrote:
> If there is buy-in, it will be implemented by goodwill people. If there 
> is no buy-in, it won’t, normal community development process. Put 
> yourself in the category you want to be in, your choice, not mine.

I believe that Change submission guidance is pretty clear on this:

"If you have improvement in mind, work to get implementers committed
to the effort _before_ filing a Change proposal, rather than expecting
them to show up for work once the Change is accepted."

See https://docs.fedoraproject.org/en-US/program_management/changes_guide/

Kamil

> Implementation is moving the call to SRPM creation at the end of the 
> build process instead of relying on the SRPM as it existed at the start 
> of the build process. So, while it is work, it is not complex work (I’m 
> sure there is more than that because tuning a production process is more 
> than the "it works" POC stage, but that’s tuning, not reconception).
> 
> Regards,
> 
> -- 
> Nicolas Mailhot

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: out of Koji disk space

[Kamil Dudka]

On Wednesday, July 1, 2020 2:00:09 PM CEST Jan Kratochvil wrote:
> On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> 
> > In the end we have limited resources and you are running into those
> > limits. We can either have fewer builders with more disk space and a
> > long queue of builds or we can have more builders with smaller disk
> > space.
> 
> 
> Good to know disk space really is a limiting factor there (as it is in
> general cheap compared to CPUs+RAM).
> 
> Sure a best step would be to have multiple (two) kinds of builders with
> different disk sizes and blacklist/whitelist packages to them.

I like the idea but would suggest to rather implement denylist/allowlist
so that someone does not have to rename those lists later on:

https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language

Kamil

> I am aware that
> idea is obvious, is there a Koji patch needed or even administration
> of two kinds of builders is too much?
> 
> 
> Jan

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Wednesday, July 1, 2020 10:54:46 AM CEST Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 01, 2020 at 09:44:12AM +0200, Kamil Dudka wrote:
> 
> > On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote:
> > 
> > > May I suggest another option?
> > > I provide a package for Micro, an editor written in Go with a
> > > discoverable 
> interface. https://micro-editor.github.io/
> > > 
> > > It is compiled as a static binary of 4.6 MB with no dependency.
> > 
> > 
> > How does it fit in Fedora, where dynamic linking is preferred?
> > 
> > 
> > > Probably bigger than nano, but it's nicer overall,
> > 
> > 
> > So you like it more than nano.  Could you be more specific about what
> > "nicer" 
> means to others in this context?
> > 
> > 
> > > with mouse support
> > 
> > 
> > nano also has mouse support.  It can be enabled by --mouse.
> 
> 
> Cool! Can this be included in the proposal? Can nano be made to use --mouse
> by default so it doesn't have to be specified on every invocation? 
> Zbyszek

Technically we are able to make the change in /etc/nanorc which is customized 
for Fedora already.  But there is a reason why it is not enabled by default:  
The mouse handling in nano takes precedence over mouse handling in terminal, 
which some users (including me) rely on.  Neither vim has the mouse support 
enabled in its default configuration.  This might be better to discuss at
the upstream mailing list.  Using fundamentally different configuration of 
nano might be disturbing for users that switch between Linux distributions.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Tuesday, June 30, 2020 9:16:40 PM CEST Robert-André Mauchin wrote:
> May I suggest another option?
> I provide a package for Micro, an editor written in Go with a discoverable 
> interface. https://micro-editor.github.io/
> 
> It is compiled as a static binary of 4.6 MB with no dependency.

How does it fit in Fedora, where dynamic linking is preferred?

> Probably bigger than nano, but it's nicer overall,

So you like it more than nano.  Could you be more specific about what "nicer" 
means to others in this context?

> with mouse support

nano also has mouse support.  It can be enabled by --mouse.

> and syntax highlighting.

nano also has syntax highlighting.  It has been enabled by default since 2015.

Kamil

> Best regards,
> 
> Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Friday, June 26, 2020 3:55:01 PM CEST Peter Robinson wrote:
> > -1 for the change. If the so called 'end-user' (whatever does it mean)
> > can learn git, she or he can also learn 'vi' or at least how to enable
> > the preferred editor. Personally, I can see nothing special on the
> > nano, for me it qualifies as very poor editor
> 
> 
> I feel you're completely missing the point, it's about a straight
> foward to understand editor by default so they aren't scared away
> before they even learn what an environment variable is, it's not about
> being the best most special editor. They may well have learned how to
> use git on windows or Mac before moving to Linux.

The distribution of git I use on Windows defaults to vi, too.

Kamil

> I would flip this
> around and say anyone who knows vim enough should know how to change
> their default editor.
> 
> Peter

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Friday, June 26, 2020 12:07:46 PM CEST Ian McInerney wrote:
> On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka  wrote:
> > On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
> > > On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:
> > > > ...snip...
> > > > 
> > > > Gentoo Linux uses the /etc/env.d tree to globally set environment
> > 
> > > > variables:
> > https://devmanual.gentoo.org/tasks-reference/environment/index.html
> > 
> > > > It worked there long time before systemd was invented.  But clearing
> > 
> > this
> > 
> > > > up in Fedora would ask for a separate system-wide change I guess...
> > > > 
> > > > Kamil
> > > 
> > > Isn't /etc/profile.d more inline with the FHS though?
> > 
> > Could you please provide any reference?
> 
> As I mentioned, the FHS calls out the "profile" file in /etc as being the
> "Systemwide initialization file for sh shell logins" [1].

/etc/profile may in general contain arbitrary shell code that conditionally 
sources other configuration files etc. whereas /etc/env.d on Gentoo is used 
solely to initialize environment variables.

> While not in the
> FHS, it is custom to append ".d" to directories containing multiple
> configuration files to parse (as you have even suggested with env.d).

I did not suggest it for Fedora really.  I just mentioned that the problem 
that _this_ change proposal is facing was already solved in another distro
10+ years ago.

> That
> is why I said it would be /more inline/ with the FHS (I never said it was
> in the FHS currently), since it would then gather the files used by the
> "profile" script into the directory "profile.d".

That is what you say.  But the specification itself does not say it at all.

Kamil

> > The FHS calls out
> > 
> > > /etc/profile as being the "systemwide initialization file for sh shell
> > > logins," so the profile.d directory would be the natural extension to
> > 
> > that.
> > 
> > > I don't see a mention of an env or evn.d in the FHS at all.
> > 
> > I see no mention of profile.d in FHS 3.0 either.
> 
>  But there is no mention of an "env" file that is a systemwide environment
> file either. So where does the initial "env" name fit into the FHS better
> than the "profile" name?
> 
> -Ian
> 
> [1]
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSys
> temConfiguration

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
> On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:
> > ...snip...
> > 
> > Gentoo Linux uses the /etc/env.d tree to globally set environment
> > 
> > variables:
> > https://devmanual.gentoo.org/tasks-reference/environment/index.html
> > 
> > It worked there long time before systemd was invented.  But clearing this
> > up in Fedora would ask for a separate system-wide change I guess...
> > 
> > Kamil
> 
> Isn't /etc/profile.d more inline with the FHS though?

Could you please provide any reference?

> The FHS calls out
> /etc/profile as being the "systemwide initialization file for sh shell
> logins," so the profile.d directory would be the natural extension to that.
> I don't see a mention of an env or evn.d in the FHS at all.

I see no mention of profile.d in FHS 3.0 either.

Kamil

> -Ian

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Kamil Dudka]

On Thursday, June 25, 2020 10:27:06 PM CEST Michael Catanzaro wrote:
> On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney 
>  wrote:
> 
> > Are you sure this will work? I just ran a test, and putting a new 
> > config file inside /usr/lib/environment.d only works for Gnome, and 
> > doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal 
> > in the respective session and examining the environment variables). 
> > From what I gather in [1], systemd is not a standard way of 
> > interacting with the user's environment variables, and only Gnome has 
> > decided to use it. So this method of implementing this change seems 
> > to be making the default editor for Gnome be nano and not changing 
> > the defaults for anyone else.
> 
> 
> Erm... well, no. Plan foiled?
> 
> The goal of using /usr/lib/environment.d was to avoid setting more 
> environment variables in random places in various shell scripts. But if 
> that only works in GNOME, I guess it's not a great solution after all.

Gentoo Linux uses the /etc/env.d tree to globally set environment variables:

https://devmanual.gentoo.org/tasks-reference/environment/index.html

It worked there long time before systemd was invented.  But clearing this
up in Fedora would ask for a separate system-wide change I guess...

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Use %make_build and %make_install macros

[Kamil Dudka]

On Saturday, June 20, 2020 12:17:26 AM CEST Tomasz Kłoczko wrote:
> All parallel build issues should be treated *as critical bugs*
>  which should be *ASAP fixed*.
> 
> kloczek

Seriously, are you saying that bugs causing slower build are as important
as bugs causing data lost or security vulnerabilities at run time?

If they are so important for you, please help us to get them fixed!

I tried to parallelize the build of nss and failed:

https://src.fedoraproject.org/rpms/nss/c/6e689ce0
https://src.fedoraproject.org/rpms/nss/c/3c27dc24

I would really appreciate your help on this.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: CMake to do out-of-source builds

[Kamil Dudka]

On Tuesday, June 16, 2020 12:18:29 PM CEST Kevin Kofler wrote:
> Igor Raits wrote:
> 
> > Not sure if I follow, what means "can already be done with the existing
> > one"? Does it mean that you can already specify a build dir via CLI and
> > some packages already do (e.g. libsolv)?
> 
> 
> As I wrote elsewhere in the thread, most packages actually do the opposite 
> (which AFAIK has been working for much longer), cd-ing to the build dir and
> specifying the source dir using the CLI (typically "%cmake ..").

Yes.  All the cmake-based packages that I maintain upstream do exactly this.

Kamil

> Kevin Kofler

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is dist-git a good place for work?

[Kamil Dudka]

On Wednesday, May 6, 2020 4:35:11 PM CEST Vít Ondruch wrote:
> I am not concerned about remote branches disappearing. I am concerned
> about the complete opposite, when the remote branches appearing in my
> local copy and not disappearing once the remote copies go.

Isn't this exactly what `git remote prune` and `git fetch --prune` are for?

You can also use `git config` to make it the default behavior if you like.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: mruprich (Michal Ruprich)

[Kamil Dudka]

On Thursday, April 23, 2020 4:08:24 PM CEST Robbie Harwood wrote:
> That's not how this works.

Yes and I am trying to suggest you how to make it work.

> Even if your assertion were true (which it isn't), we have a closure
> status for that.  Michal (the maintainer, who isn't you) even used it -
> CLOSED NOTABUG.  Maintainers can and should ask for more information in
> that case - think questions like "what would you like to see change in
> $package".  But it's pretty clear what the change is (drop telnet-server
> from spec file), to the point where I can (and did) offer a patch.

I do not think that a patch would help in this case.  The underlying problem 
is that there should be an agreement on whether to remove the package or not.  
Bugzilla is not the appropriate place to discuss it because many users of the 
package do not get any notifications about such discussions.

> I want to assume good faith here, but it's hard to not see this as
> either non-responsiveness or laziness.

You mean laziness on your part to find the appropriate discussion channel
and summarize technical facts supporting your idea to remove the package?

> It really looks like my requests
> were ignored until maintainer status was called into question.

Because you did not use an appropriate channel to discuss your concerns.  
Bugzilla is a tool to report bugs, most frequently when something does
not work as documented and things like that.  This was apparently not
the case.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: mruprich (Michal Ruprich)

[Kamil Dudka]

On Wednesday, April 22, 2020 7:28:36 PM CEST Robbie Harwood wrote:
> To make this as clear as I can, let's look at
> https://bugzilla.redhat.com/show_bug.cgi?id=1815163

The above mentioned ticket is not a bug report in the first place.   You just 
expressed your personal opinion about a package maintained by someone else
in Fedora.  While I respect your opinion about the package being redundant,
it is not a sufficient reason for the maintainer to quickly take an action.  
There might be other people using the package and Bugzilla is not the right 
place to discuss whether a package should be removed or not.  If there are 
technical reasons behind your request, you should state them explicitly.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: fedpkg broken (pycurl issue?)

[Kamil Dudka]

On Monday, April 20, 2020 3:59:59 PM CEST Neal Becker wrote:
> Maybe the problem is that my local pycurl is not compatible with fedpkg?

The more important problem is that your local pycurl is not compatible with
libcurl, which is exactly what the error message is telling you, isn't it?

I would suggest to rather use the system-provided pycurl, which has
a downstream patch to disable this (IMO not so useful) run-time check:

https://src.fedoraproject.org/rpms/python-pycurl/blob/c0aa6c5c/f/0002-python-pycurl-7.43.0-tls-backend.patch

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should logrotate timer be enabled by default on all installations?

[Kamil Dudka]

On Wednesday, March 18, 2020 3:50:34 PM CET Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 18, 2020 at 01:04:58PM +0100, Kamil Dudka wrote:
> 
> > logrotate is a utility designed to simplify the administration of log
> > files on 
 a system which generates a lot of log files.  It used to be
> > triggered by cron. The cron hook was unconditionally installed with
> > logrotate but it took effect only if a cron daemon was installed.
> > 
> > Starting with Fedora 30, logrotate is triggered by a systemd timer
> > instead.  
 In order to make updates smoother, the timer was enabled on
> > updates in case a cron daemon was configured on the system.
> > 
> > The timer is currently not enabled on fresh installs to avoid surprises
> > (such 
 as data lost) on systems where logrotate is installed but not
> > actually used. logrotate can also be triggered independently of
> > systemd/cron and can be even run by non-privileged users to rotate logs
> > they have access to.
> > 
> > Some people think that the logrotate timer should be enabled by default on
> > all 
 systems where the logrotate package is installed:
> > 
> > 
> > https://bugzilla.redhat.com/1655153#c4
> > 
> > 
> > Do you think it would be a good idea?
> 
> 
> Yes, I think it's reasonable to enable it by default. People should just
> not
 install logrotate package if it's not necessary. We should also make
> sure that the package is not Required from those packages that use the
> journal. 
> (I think that for most cases text logs are not necessary, and journald
> is a better approach, but for the cases where text logs are created,
> logrotate is something that people want 99% of the time, so we should
> make it easy to have the right thing happen if the package is installed.)
> 
> Note: we have a documented process for enabling services:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/.
> logrotate.timer satisfies the requirements to be enabled without a fesco
> exception. So it should be enough to file a PR for fedora-release. 
> Zbyszek

Thank you all for sharing your opinion on this!

I have opened a pull request to enable logrotate.timer by default:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/111

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should logrotate timer be enabled by default on all installations?

[Kamil Dudka]

On Wednesday, March 18, 2020 3:20:17 PM CET Dusty Mabe wrote:
> I guess it would be worth analyzing the problem space a bit:
> 
> - in the past how many people do we think had logrotate installed and not 
> cron?

I am worried more about automated provisioning rather than manual installations.

> - what are the worst case scenarios if logrotate.timer defaults to off?

- Running out of disk space.

- Violation of privacy and retention terms.

> - what are the worst case scenarios if logrotate.time defaults to on?

- Unexpected data loss.

- Security holes triggered by (previously ineffective) insecure logrotate
  configurations as, for example, this one:

https://bugzilla.redhat.com/CVE-2019-10143

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Should logrotate timer be enabled by default on all installations?

[Kamil Dudka]

logrotate is a utility designed to simplify the administration of log files on 
a system which generates a lot of log files.  It used to be triggered by cron.  
The cron hook was unconditionally installed with logrotate but it took effect 
only if a cron daemon was installed.

Starting with Fedora 30, logrotate is triggered by a systemd timer instead.  
In order to make updates smoother, the timer was enabled on updates in case
a cron daemon was configured on the system.

The timer is currently not enabled on fresh installs to avoid surprises (such 
as data lost) on systems where logrotate is installed but not actually used.  
logrotate can also be triggered independently of systemd/cron and can be even 
run by non-privileged users to rotate logs they have access to.

Some people think that the logrotate timer should be enabled by default on all 
systems where the logrotate package is installed:

https://bugzilla.redhat.com/1655153#c4

Do you think it would be a good idea?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mock build Fedora package on CentOS 7

[Kamil Dudka]

On Thursday, January 16, 2020 6:12:42 AM CET Nico Kadel-Garcia wrote:
> On Wed, Jan 15, 2020 at 12:08 PM Ian Pilcher  wrote:
> There are notes in the "mock" buglists
> at:https://github.com/rpm-software-management/mock/issues/390 . The
> short answer is "not very well".  The dnf tools in RHEL 7 and 8 are
> not sufficient to actually run dnf for "mock". There are options to
> bootstrap Fedora 31 from a container using "podman" to install the
> zstd compressed binary RPM, but it's slow and painful and unreliable
> unless you build your entire toolchain from a collection of SRPM's.

I have exactly opposite experience with the mock's bootstrap feature based
on podman.  We use it on our internal service to statically analyze Fedora 
packages on RHEL-7 hosts and it works perfectly.  I am not sure about
CentOS 7 though,  bug fixes may land there with some delay...

> My notes and patches aare available
> at:https://github.com/nkadel/mockrep, especially the editing of

I guess it should have been: https://github.com/nkadel/mockrepo

Kamil

> fedora-31.tmpl in the mock-core-configs.spec./

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: dnf autoremove by default on upgrades

[Kamil Dudka]

On Monday, January 13, 2020 4:07:56 PM CET Chris Murphy wrote:
> I understand the path of least resistance with upgrades. They're
> better off being upgraded, even if they silently have sale bits no
> longer upgraded. From a security perspective, I think being silent
> about that is not great.

Being silent is bad but automatic removal is not much better in general.

> But what I'm getting at is not an upgrade that gets them a system
> nearly identical to a clean install, but rather removing things that
> really should be removed.

The problem is that there is no universal definition of "things that
really should be removed".  One could think that a binary PDF reader
with last update in 2013 should be removed no matter what, while other
Fedora users would not be able to use Fedora without it and proactively 
overcome all the obstacles we created to force them to remove it ;-)

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: dnf autoremove by default on upgrades

[Kamil Dudka]

On Monday, January 13, 2020 5:59:49 AM CET Chris Murphy wrote:
> On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi  wrote:
> 
> >
> >
> > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote:
> > 
> > > Hi,
> > >
> > >
> > >
> > > This might be a bad idea. But I'm looking for better ideas than status
> > > quo.
> >
> > >
> > >
> > > A known problem is upgraded systems get crusty over time. Maybe folks
> > > should clean install more often, yet they don't.
> > >
> > >
> > >
> > > If there's a new good idea, but it's a short term solution, the fact
> > > it'll
> > > live forever acts as a deterrent to implementing it.
> > >
> > >
> > >
> > > What if there were an autoremove for anything older than Fedora n-2,
> > > that
> > > is, keep current plus last two releases? i.e. for upgrades to Fedora
> > > 33,
> > > keep stale packages from 33, 32, and 31.
> > >
> > >
> > >
> > > Or another idea?
> >
> >
> >
> > Well, we already have fedora-obsolete-packages. That should handlle this
> > case no? Folks who want to have obsolete things removed can make sure to
> > have fedora-obsolete-packages installed and it should obsolete those.
> 
> 
> It's not installed by default. Should it be?

Nope.  It could cause dependencies of 3rd party SW to be unexpectedly removed.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bugzilla needinfo reminders

[Kamil Dudka]

On Friday, October 25, 2019 11:02:00 AM CEST Tomasz Torcz wrote:
> On Fri, Oct 25, 2019 at 09:30:39AM +0200, Kamil Dudka wrote:
> 
> > On Friday, October 25, 2019 9:11:39 AM CEST Tomasz Torcz wrote:
> > 
> > > Hi,
> > > 
> > > 
> > >   Few days ago (22nd Oct) I've started receiving daily reminders
> > > 
> > > about needinfo for over a year old bugs.  Which is strange, as those
> > > bugs
> > > are closed.
> > 
> > 
> > Bugzilla sends you notifications because the needinfo flag is set on you.
> > Why do not you simply clear the needinfo flag if it is not valid any
> > more?
> 
> 
>   I've done it now.
> 
> 
> > >   The notification are not really true, also. For example, bug …460
> > > 
> > > below is listed as 66 days old.  I've filled it on 2018-07-09,
> > > which makes it 473 days old.
> > > 
> > > 
> > >   Can we revert whatever change was made to bugzilla on 21st Oct
> > > 
> > > in order to receive less nags?
> > 
> > 
> > I do not support this request.  I appreciate those notifications myself.
> > 
> 
> 
>   They make sense for current bugs. Not for the ones CLOSED for months.

I use the needinfo flag on closed bugs, too.  For example, if the bug is 
closed as WONTFIX, one can ask for a workaround or related recommendation.  
The needinfo flag (and the notifications it triggers) increases the chance
of getting a qualified answer, which in turns helps other people that find
the closed bug report through a web search.

Kamil


> -- 
> Tomasz Torcz   "Never underestimate the bandwidth of a station
> xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bugzilla needinfo reminders

[Kamil Dudka]

On Friday, October 25, 2019 9:11:39 AM CEST Tomasz Torcz wrote:
> Hi,
> 
>   Few days ago (22nd Oct) I've started receiving daily reminders
> about needinfo for over a year old bugs.  Which is strange, as those bugs
> are closed.

Bugzilla sends you notifications because the needinfo flag is set on you.
Why do not you simply clear the needinfo flag if it is not valid any more?

>   The notification are not really true, also. For example, bug …460
> below is listed as 66 days old.  I've filled it on 2018-07-09,
> which makes it 473 days old.
> 
>   Can we revert whatever change was made to bugzilla on 21st Oct
> in order to receive less nags?

I do not support this request.  I appreciate those notifications myself.

Kamil

> - Forwarded message from bugzi...@redhat.com -
> 
> Date: Fri, 25 Oct 2019 02:27:16 GMT
> From: bugzi...@redhat.com
> To: to...@pipebreaker.pl
> Subject: [Red Hat Bugzilla] Your Outstanding Requests
> 
> The following is a list of bugs or attachments to bugs in which a user has
> been
> waiting more than 3 days for a response from you. Please take
> action on these requests as quickly as possible. (Note that some of these
> bugs
> might already be closed, but a user is still waiting for your
> response.) 
> We'll remind you again tomorrow if these requests are still outstanding, or
> if
> there are any new requests where users have been waiting more than 3
> days for your response.
> 
> needinfo
> 
> 
>   Bug 1599383: frequent errors with iwlwifi (389 days old)
> https://bugzilla.redhat.com/show_bug.cgi?id=1599383
>   
>   Bug 1574460: Null pointer dereference in sha256_ssse3 module (66 days
> old)
> https://bugzilla.redhat.com/show_bug.cgi?id=1574460
>   
> To see all your outstanding requests, visit:
> https://bugzilla.redhat.com/request.cgi?action=queue=tomek%40pipeb
> reaker.pl=type
 
> - End forwarded message -
> 
> -- 
> Tomasz Torcz   "Never underestimate the bandwidth of a station
> xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Kamil Dudka]

On Friday, August 30, 2019 8:44:39 AM CEST Miroslav Suchý wrote:
> I think that no one contemplate supporting RHEL 7 regarding zstd.

Panu said that the backport would be almost trivial:

https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/message/Z4EFFNJNVAP35KH74N3W5GC4E2AQXC7V/

I am not asking for a supported RHEL-7 update of rpm.  A working patch would
be sufficient for my needs.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Kamil Dudka]

On Thursday, August 29, 2019 11:17:18 PM CEST Nico Kadel-Garcia wrote:
> Sent from my iPhone
> 
> 
> > On Aug 29, 2019, at 12:58 PM, Kamil Dudka  wrote:
> > 
> > 
> >> On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote:
> >> 
> >>> On 6/4/19 9:56 AM, Daniel Mach wrote:
> >>> 
> >>> Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
> >>> 
> >>> 
> >>>>> On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> >>>>> 
> >>>>> Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> >>>>> 
> >>>>> 
> >>>>>> If we did this, wouldn't it make it very difficult to use tools like
> >>>>>> mock on RHEL / CentOS 7 to build for Fedora 3x?
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> Speaking of Mock:
> >>>>> Either the RPM on host need to understand the new format/compression 
> >>>>> **or**
> >>>>> the packages in @buildsys group (including transitional deps) have to
> >>>>> 
> >>>>> be in
> >>>>> old format - then you can build for Fedora 3x using bootstrap
> >>>>> feature.
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> I need to underline this, it would be really really really bad if we
> >>>> were
> >>>> not able to --installroot fedora chroots at least on RHEL 8.  How
> >>>> likely
> >>>> is a backport of zstd support into RPM in EL7+?
> >>> 
> >>> 
> >>> RHEL 8 should be quite easy - get zstd package into RHEL and recompile 
> >>> rpm with zstd support.
> >>> 
> >>> RHEL 7 is a different story. The patch doesn't apply directly and a 
> >>> backport would be needed.
> >>> 
> >>> Panu,
> >>> how difficult it would be to backport the zstd support to RHEL 7 RPM?
> >> 
> >> 
> >> 
> >> Technically, backporting rpmio backends is almost trivial, even to much 
> >> older rpm versions.
> >> 
> >> Getting new features into older RHEL is a much bigger problem.
> >> 
> >> 
> >>- Panu -
> > 
> > 
> > Has there been any progress on this?
> > 
> > What is the recommended way to build Fedora 31+ RPMs on a RHEL-7
> 
> 
> With “mock”, available from EPEL.

It does not work because RHEL-7 rpm does not support zstd, so `mock --init` 
fails with a lot of unsatisfied dependencies on rpmlib(PayloadIsZstd).

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

[Kamil Dudka]

On Tuesday, June 4, 2019 9:43:53 AM CEST Panu Matilainen wrote:
> On 6/4/19 9:56 AM, Daniel Mach wrote:
> 
> > Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
> > 
> >> On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
> >> 
> >>> Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
> >>> 
>  If we did this, wouldn't it make it very difficult to use tools like
>  mock on RHEL / CentOS 7 to build for Fedora 3x?
> >>>
> >>>
> >>>
> >>> Speaking of Mock:
> >>> Either the RPM on host need to understand the new format/compression 
> >>> **or**
> >>> the packages in @buildsys group (including transitional deps) have to 
> >>> be in
> >>> old format - then you can build for Fedora 3x using bootstrap feature.
> >>
> >>
> >>
> >> I need to underline this, it would be really really really bad if we
> >> were
> >> not able to --installroot fedora chroots at least on RHEL 8.  How likely
> >> is a backport of zstd support into RPM in EL7+?
> > 
> > RHEL 8 should be quite easy - get zstd package into RHEL and recompile 
> > rpm with zstd support.
> > 
> > RHEL 7 is a different story. The patch doesn't apply directly and a 
> > backport would be needed.
> > 
> > Panu,
> > how difficult it would be to backport the zstd support to RHEL 7 RPM?
> 
> 
> Technically, backporting rpmio backends is almost trivial, even to much 
> older rpm versions.
> 
> Getting new features into older RHEL is a much bigger problem.
> 
>   - Panu -

Has there been any progress on this?

What is the recommended way to build Fedora 31+ RPMs on a RHEL-7 host?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RANT: compton-ng…

[Kamil Dudka]

On Tuesday, August 13, 2019 12:22:17 PM CEST Panu Matilainen wrote:
> On 8/13/19 1:19 PM, Kamil Dudka wrote:
> 
> > On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote:
> > 
> >> On 8/13/19 11:17 AM, Igor Gnatenko wrote:
> >>
> >>
> >>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1738293
> >>>
> >>>
> >>>
> >>> How did it pass review?
> >>>
> >>>
> >>>
> >>>
> >>>> Obsoletes:  compton
> >>>
> >>>
> >>>
> >>>
> >>> Silently doing Obsoletes of an active package and doing so even
> >>> without version which is prohibited by the Packaging Guidelines.
> >>> Really?
> >>>
> >>>
> >>>
> >>>
> >>>> cp -a yshui-%{appname}-%{test_shortcommit}/subprojects/test.h
> >>>> /builddir/build/BUILD/%{appname}-%{version}/subprojects/
> >>
> >>
> >>
> >>>
> >>>
> >>> I am not sure if it is written anywhere, but hardcoding
> >>> /builddir/whatsoever is so bad…
> >>>
> >>>
> >>>
> >>>
> >>>> %meson --buildtype=release
> >>>
> >>>
> >>>
> >>>
> >>> There is specific reason why we have --buildtype=plain in %meson
> >>> macro, because with release buildtype, debuginfo is unusable…
> >>>
> >>>
> >>>
> >>>
> >>>> # Enable LTO
> >>>> %global optflags%{optflags} -flto=$(nproc)
> >>>> %global build_ldflags   %{build_ldflags} -flto
> >>>
> >>>
> >>>
> >>>
> >>> Have anybody ever talked to the RPM folks about proper way of enabling
> >>> LTO for builds? This specific way of setting it makes build
> >>> non-reproducible.
> >>
> >>
> >>
> >>
> >> Rpm can't help it if gcc/linker argument makes builds non-reproducable.
> >> That said, see https://github.com/rpm-software-management/rpm/pull/809,
> >> gcc upstream is aware of the issue and supports -flto=auto now, which is
> >> what builds should be using for reproducability.
> >>
> >>
> >>
> >>- Panu -
> > 
> > 
> > By reproducibility you mean that the number of jobs can be (in some
> > cases)
> > controlled by RPM macros?
> > 
> > Does the number of jobs have any impact on the resulting binary?
> > 
> 
> 
> See the above URL.
> 
> It doesn't affect the actual link stage, but it affects the stored 
> optflags in the package (and the actual binaries if that was enabled)
> 
>   - Panu -

OK, got it.  The issue is that -flto=N can be stored in the resulting binary 
RPMs and the N can differ across builds.  So you want to use -flto=auto to 
always store the same flag, even though the flag may have different semantics 
in different builds of the same package.

Sorry for not understanding it originally.  It is good idea to provide some 
context when you post to such generic list as fedora-devel.  Not all readers 
are experts in all topics and/or have capacity to read in depth all referred 
documents.

Thank you for clarifying it!

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RANT: compton-ng…

[Kamil Dudka]

On Tuesday, August 13, 2019 11:26:12 AM CEST Panu Matilainen wrote:
> On 8/13/19 11:17 AM, Igor Gnatenko wrote:
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1738293
> > 
> > How did it pass review?
> > 
> > 
> >> Obsoletes:  compton
> > 
> > 
> > Silently doing Obsoletes of an active package and doing so even
> > without version which is prohibited by the Packaging Guidelines.
> > Really?
> > 
> > 
> >> cp -a yshui-%{appname}-%{test_shortcommit}/subprojects/test.h
> >> /builddir/build/BUILD/%{appname}-%{version}/subprojects/
> 
> > 
> > I am not sure if it is written anywhere, but hardcoding
> > /builddir/whatsoever is so bad…
> > 
> > 
> >> %meson --buildtype=release
> > 
> > 
> > There is specific reason why we have --buildtype=plain in %meson
> > macro, because with release buildtype, debuginfo is unusable…
> > 
> > 
> >> # Enable LTO
> >> %global optflags%{optflags} -flto=$(nproc)
> >> %global build_ldflags   %{build_ldflags} -flto
> > 
> > 
> > Have anybody ever talked to the RPM folks about proper way of enabling
> > LTO for builds? This specific way of setting it makes build
> > non-reproducible.
> 
> 
> Rpm can't help it if gcc/linker argument makes builds non-reproducable. 
> That said, see https://github.com/rpm-software-management/rpm/pull/809, 
> gcc upstream is aware of the issue and supports -flto=auto now, which is 
> what builds should be using for reproducability.
> 
>   - Panu -

By reproducibility you mean that the number of jobs can be (in some cases) 
controlled by RPM macros?

Does the number of jobs have any impact on the resulting binary?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mock - signal reaction

[Kamil Dudka]

On Tuesday, July 30, 2019 4:59:13 PM CEST Jan Buchmaier wrote:
> Do we want to catch/process SIGABRT as well?

I see no obvious use case for catching SIGABRT by mock.

Why are you asking about SIGABRT specifically?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mock - signal reaction

[Kamil Dudka]

On Tuesday, June 4, 2019 9:33:33 AM CEST Miroslav Suchý wrote:
> Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a):
> 
> >> Now I'm working on signal SIGTERM handling and I would like to kill all
> >> processes related to the main mock process.
> >> 
> >>  What do you think is it a good
> >> 
> >> idea to kill all processes, or do we want to kill the main process only?
> >> And what about SIGINT so-called KeyInterrupt in python? Same reaction?
> > 
> > Your question is missing some context.  Are you trying to improve signal 
> > handling in your own code that uses mock, or are you trying to improve
> > signal handling in the implementation of mock itself?
> 
> 
> I will try to clarify this.
> 
> In past, when you send SIGKILL to Mock, then only Mock terminated. It leaves
> behind any running rpmbuild or dnf.
> Jan is working on fix for this use
> case:
>   https://github.com/rpm-software-management/mock/issues/153
> As part of this work, we asked ourself the question: should mock clean up
> after itself when exiting?

I think it should.  But you will need to handle SIGTERM instead of SIGKILL.
 
> But I wonder what should be correct/expected behaviour? E.g., is someone
> running daemons in mock using 'chroot' or
> 'shell' command and would be
> surprised if Mock will kill it when Mock will terminate?

Not that I know of.

> Or we can assume
> that when Mock terminate then nothing should be running in the chroot?

Yes please.

> What are your use-cases?

csmock uses it for fully automated static analysis of RPM packages.

Kamil

___
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: Mock - signal reaction

[Kamil Dudka]

On Monday, June 3, 2019 12:18:02 PM CEST Jan Buchmaier wrote:
> Now I'm working on signal SIGTERM handling and I would like to kill all
> processes related to the main mock process.
>  What do you think is it a good
> idea to kill all processes, or do we want to kill the main process only?
> And what about SIGINT so-called KeyInterrupt in python? Same reaction?

Your question is missing some context.  Are you trying to improve signal 
handling in your own code that uses mock, or are you trying to improve
signal handling in the implementation of mock itself?

Kamil

___
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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Kamil Dudka]

On Friday, March 22, 2019 12:25:28 PM CET Vitaly Zaitsev wrote:
> Hello, Kamil Dudka.
> 
> Fri, 22 Mar 2019 12:03:26 +0100 you wrote:
> 
> 
> > Enforcing -Werror=format-security in Fedora build system was a mistake.
> 
> 
> No. Enforcing -Werror=format-security is good choice. This helped
> maintainers to fix lots of potential security vulnerabilities in packages.

There are more effective ways to capture and process compiler warnings.

Using -Werror in production builds can in fact be counterproductive when 
someone is trying to release a security update for a real security issue
and has to deal with unexpected build failures.

Another problem is that -Werror aborts the build prematurely.  When building 
in parallel, it may be even non-deterministic how many errors are reported 
before the build stops.  So people have to apply fixes (or workarounds) in 
iterations, which is not fun with packages like libreoffice.

Needless to say that build.log does not contain any machine-readable 
information about the warnings detected during the build, because compiler 
diagnostic may be suppressed by the build system, diagnostic messages may
be interleaved with each other when building in parallel, etc.

We have better tooling to reliably capture compiler warnings of your choice,
fully automatically, and in a machine readable format:

$ csmock ${pkg}.src.rpm -t gcc

You can also transparently inject compiler flags without changing anything
in the buildroot (and unnecessarily breaking production builds of others):

$ csmock ${pkg}.src.rpm -t gcc --gcc-add-flag=...

Kamil

___
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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Kamil Dudka]

On Friday, March 22, 2019 10:41:23 AM CET Jakub Jelinek wrote:
> If we in Fedora made -Werror=format-security warning default, then
> one couldn't out of box build gcc nor many other projects.  Not to mention
> that it is extremely nasty, because if e.g. some project uses -Wno-format
> for selected source(s), then if -Werror=format-security is the default
> (or just present in flags), then it causes errors as well.

Enforcing -Werror=format-security in Fedora build system was a mistake.
It made developers introduce new bugs while trying to fix nonsense build 
failures, as in this example:

https://bugzilla.redhat.com/1025257#c5

Kamil

___
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 Lifecycles: imagine longer-term possibilities

[Kamil Dudka]

On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote:
> On 2018-12-06, Florian Weimer  wrote:
> 
> > In a sense, it's the old discussion between explicit rename recording
> > and rename detection.  I think it's clear by now that rename detection
> > has won.
> >
> >
> 
> Can you give us some example of a rename detection that works?
> 
> If a packager cherry-picks patches, he looses upstream's commit IDs. If
> an upstream uses non-descriptive commit messages (e.g. five commits with
> the same "A bug fix" subject), commit messages are not uniq. If the
> packager needs to ammend patches (the commit bodies) to resolve conflicts
> (i.e. porting back the fixes by rebasing the patches), the code changes
> are not uniq. If an upstream releases a new version after a year, the
> packager won't probably remember all the cherry-picked fixes.
> 
> How can a packager identify which commits originates from the upstream
> and which are uniq to Fedora and must be carried across rebases to
> a new release?
> 
> A tempting answer could be use merge-commits extensively. However, would
> that really help? I must admit I'm not fond of merge-commits and I don't
> have much experience with them.
> 
> If I imagine a dist-git tree full of intermingled upstream and Fedora
> commits, I don't know how I as a packager would package a new upstream
> release. Should I just blindy believe in "git merge"? I have a few bad
> experiences with git losing diff chunks on the way. How could I keep
> the packaging accountable and verifiable?
> 
> -- Petr

It is not covered by any policy or supported tooling but, just to help
myself with future maintenance, I always append "Upstream-commit: "
to the commit message whenever I take a patch (commit) from the upstream
git repository.

Kamil

___
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: koji download-build fails with [ERROR] koji: PermissionError: [Errno 13] Permission denied

[Kamil Dudka]

On Wednesday, September 19, 2018 11:27:04 AM CEST Richard W.M. Jones wrote:
> I don't know if this is a problem with this specific version of koji,
> or our Koji builders, but:
> 
> $ koji download-build nbdkit-1.7.3-1.fc30 --arch=x86_64 --arch=noarch
> Downloading: nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm
> 2018-09-19 10:14:21,056 [ERROR] koji: PermissionError: [Errno 13] Permission
> denied: 'nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm'
 
> $ rpm -q koji
> koji-1.16.0-1.fc29.noarch
> 
> This happens with other fc30 builds I have tried to download too.
> 
> Rich.

Do you have write access to your $PWD ?

The error can be easily reproduced with:

$ install -m0555 -d dir && cd dir && koji download-build nbdkit-1.7.3-1.fc30 
--arch=x86_64 --arch=noarch
Downloading: nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm
PermissionError: [Errno 13] Permission denied: 
'nbdkit-ext2-plugin-1.7.3-1.fc30.x86_64.rpm'

___
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: F29 System Wide Change: OpenLDAP without Non-threaded Libraries

[Kamil Dudka]

On Tuesday, July 17, 2018 2:24:04 PM CEST Matus Honek wrote:
> Florian is right, the idea is to make changes to the source code
> (probably a downstream patch will be needed) such that the threaded
> library will be built twice, once with libldap soname and once with
> libldap_r soname, and the non-threaded libldap won't be shipped at
> all.
> 
> The non-threaded version basically provides a subset of capabilities of
> the threaded version, which are additionally thread safe
> (i.e. mutexes). There shouldn't be really any noticeable change.
> 
> Does this make sense?

So can it happen that both the libraries will be loaded at the same time
by a single process (one of them for example through libcurl)?

Will everything work as expected in this case?

Kamil

___
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/ZSJ5XRXEZAX5WTIJCQWPO3GU6SO3IZSV/

Re: [HEADS UP] Removal of GCC from the buildroot

[Kamil Dudka]

On Tuesday, July 10, 2018 5:44:50 PM CEST Kevin Kofler wrote:
> Igor Gnatenko wrote:
> 
> > As per Changes/Remove GCC from BuildRoot
> > , I'm
> > going to automatically add BuildRequires: gcc and/or BuildRequires:
> > gcc-c++ to packages which fail to build with common messages (like gcc:
> > command not found, also autotools/cmake/meson are supported).
> > 
> > I'm going to do this tomorrow.
> > 
> > After which, I'm going to ask rel-eng to finally remove it from
> > buildroot.
> > This will happen before mass rebuild. Stay tuned.
> 
> 
> I still think that this change is absolutely counterproductive, because it 
> will actually INCREASE local mock build times for all C/C++ programs for
> all packagers, because gcc and gcc-c++ will no longer be included in the
> root cache.

You are free to tweak your local mock configs to preinstall arbitrary packages 
(and include them in root cache) if build speed is your concern.  Have a look
at the 'chroot_setup_cmd' option.

Kamil

> It is also yet another pointless mass change to a huge number of packages, 
> right after the %defattr one.
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> /message/LIQJUDDE2WBU32PGOVHRAR2SBJ4ILR2R/

___
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/XYZVDBUIY6PWSAFM46ZT5B44SB4Y744N/

backward incompatible ABI change in libnice after rebuild against updated gstreamer1

[Kamil Dudka]

gstreamer1 was updated to version 1.14.0 in f28 on March 21st:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1060701

.. but not all its dependencies were rebuilt.  While trying to update
the libnice package now, libabigail tells me that my update is backward-
incompatible because the symbol gst_plugin_desc is removed by the update:

https://taskotron.fedoraproject.org/artifacts/all/95c002dc-5211-11e8-bb3c-525400fc9f92/tests.yml/libnice-0.1.14-7.20180504git34d6044.fc28.log

It does not seem to be introduced by any changes in the libnice package.
Is the reported symbol removal expected/safe?

If not, how can I get around this in the libnice package?

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Kamil Dudka]

On Thursday, May 3, 2018 12:10:25 AM CEST Iain Rae wrote:
> no, I'm afraid you're misunderstanding. if someone steals a laptop the
> live user session can be  more  valuable than the root password. with
> the live session you have access to everything the owner of the sesion
> is logged into. with the root password you have access to everything on
> the laptop. But you can't for example access his banking account .you
> need the banking account login details.

If you have full root access while the session is running, you can access the 
login details, too.  You can read memory or attach debugger to any process of 
your choice.  Obviously, there cannot be any login details that are available 
to the regular user but that cannot be accessed by root at the same time.

When you install programs from untrusted sources using sudo, you usually have 
a user session running.  So the mentioned xkcd does not really apply here.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Kamil Dudka]

On Wednesday, May 2, 2018 4:34:51 PM CEST Stephen John Smoogen wrote:
> The issue is where they do not know they have installed software to
> their home directory.

Sure but still better than if they did not know they had installed software 
outside of their home directory, at least from perspective of other users 
sharing the same system.

> This leads to the problem outlined in
> https://xkcd.com/1200/ where the user account is more precious than
> having root.

Wait.  If you have full root access, you have automatically access to data 
(and running sessions) of all users on that system.

I think you are misreading the xkcd.  It says that stealing a user sessions
is _almost_ as serious as having root access on that system.  Still as root 
you can do a superset of things compared to having a user session only.

> > 2. You do not allow users to easily install software to their home
> > directory.
> 
> >In that case, they will install questionable software using sudo,
> >which
> >gives it root privileges and affects all other users on the system
> >(and
> >possibly other systems reachable through a trusted network).
> >
> >
> 
> 
> Which most users will do anyway because every stackoverflow and
> software install says you have to do a 'curl | su -' or a 'sudo
> pip/gem/etc install'

Because that is currently the only way that works reliably.  If you find out
a more secure way that works for the users equally well, it will find its way 
to stackoverflow some day.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org