Re: Packages that failed to build with Python 3.9

[Dan Čermák]

Miro Hrončok  writes:

> python-metaextract   defolos

This should be fixed in Rawhide as well.


Cheers,

Dan


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

Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging

[Dan Čermák]

Hi Ankur,

Ankur Sinha  writes:

> Hi folks,
>
> The packaging team is generally quite stretched, and we frankly need
> more people helping us out.
>
> The main issue with newcomers taking on packaging is that the learning
> curve here is much more technical then a lot of other areas in Fedora.
> So, while it is still expected that folks read the docs and learn things
> themselves, perhaps we could be more active in helping them?

That is true, getting into packaging is not easy at all.

Besides improving existing docs, how about having a individual packagers
helping out newcomers in 1:1 chats, e.g. on IRC or Jitsi?

>
> We've had rpm packaging classroom sessions in the past. Are any folks
> interested in restarting these? Maybe a different SIG could do a session
> each month to help newcomers get started with packaging their tools?
> Sponsors, what do you think?
>
> -- 
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: A few questions about a package update / policy questions / GCC 9 error

[Dan Čermák]

"Nathanael D. Noblet"  writes:

> Hello,
>
>   I maintain beanstalkd which is a message server of sorts. It recently
> released a new version however some changes I'm not 100% sure about.
>
>   When compiling I got the following GCC error.
>
> usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy'
> specified bound 201 equals destination size [-Werror=stringop-
> truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
>   |  ^~
> 
>
> Results via google says that strncpy needs to have the third argument
> less than the 2nd, so I've got this patch, similar to others:
>
> --- beanstalkd-1.12/tube.c.org  2020-06-10 09:37:35.129224346 -0600
> +++ beanstalkd-1.12/tube.c  2020-06-10 09:37:42.761138035 -0600
> @@ -12,7 +12,7 @@
>  if (!t)
>  return NULL;
>
> -strncpy(t->name, name, MAX_TUBE_NAME_LEN);
> +strncpy(t->name, name, MAX_TUBE_NAME_LEN-1);
>  if (t->name[MAX_TUBE_NAME_LEN - 1] != '\0') {
>  t->name[MAX_TUBE_NAME_LEN - 1] = '\0';
>  twarnx("truncating tube name");
>
> You'll notice it was already checking the len-1 for null. Can anyone
> verify that my change won't cause some un-intended bug I don't
> understand?

If I understand it correctly, then you are now invoking undefined
behavior: you copy at most MAX_TUBE_NAME_LEN-1 bytes to t->name and then
check whether the following byte (that was never written to) is not
equal to 0. I have not checked the code of beanstalkd, but the contents
of t->name[MAX_TUBE_NAME_LEN - 1] will be zero if it was allocated via
calloc() at best or random at worst. Irrespectively of that, the check
now no longer does what it *should*: null terminate the string if it is
not null terminated. It will now randomly null terminate it or not at
all.

>
> Finally, they also now support socket activation. Which means I was
> looking at .service file which I had setup to use a sysconfig
> environment file. When I looked at it, I realized that the default was
> to listen to 0.0.0.0 which means someone could install and if not
> really careful / pre config or what not have a service listening where
> they maybe don't want to. I was thinking of changing this to 127.0.0.1
> with a note about how it should be modified. However I figure if I do
> that, anyone with this installed and unmodified who gets the update
> will suddenly have their service stop listening to the outside world.
> What should be done then? 
>
> My thought is I leave it as 0.0.0.0 for all released versions (but what
> about epel7) and then in rawhide change to 127.0.0.1. I just don't like
> leaving the package like that for epel as well.
>
> Any ideas/direction would be appreciated.
>
> Sincerely,
> -- 
> Nathanael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Dan Čermák]

Kevin Kofler  writes:

> Michael Catanzaro wrote:
>> Kevin, the goal is to *simply* these packages:
>> 
>> mkdir -p %{_target_platform}
>> pushd %{_target_platform}
>> %cmake 
>> popd
>> 
>> It's four lines. We get to simplify it down to one line. Proposal
>> owners are provenpackagers and say they will try to fix affected
>> packages. Fine by me?
>
> In the real world, it will end up as:
>
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif

Or you use the new %cmake macro only in the f32, epel8 and master
branch and leave the other branches as they are?

>
> i.e. 8 lines instead of 4, and much less readable. Most specfiles need to 
> work on older distributions too.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
>
> == Summary ==
> This change will update all spec files in Fedora that use make and replace
> the make invocations with either the %make_build or %make_install macros.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
>
> == Detailed Description ==
>
> The goal of this change is to standardize the usage of make in Fedora.  All
> make invocations in spec files that don't use the install target will be
> modified to use the %make_build macro, and all make invocations that use
> the install target will be updated to use the %make_install macro.  Any
> additional arguments to make that are not included in either the
> %make_build and %make_install will be preserved.
>
> The %make_build macro enables parallel make builds using the -j option.  In
> case a package does not build correctly with parallel make, then parallel
> make will be disabled for that package by redefining the %_smp_mflags macro
> like this:
>
>   %global _smp_mflags -j1
>
> All changes will be submitted to dist-git repositories via pull requests.
> Pull requests will be merged after 1 week if there are no objections or
> earlier if approved by the package maintainers.
>
> A script will be used to apply the necessary changes to the spec files, and
> the result will be manually inspected before being merged.
>
> All packages updated by this change request will be rebuilt after the spec
> file changes are merged.
>
> Some packages already use the %make_build and %make_install macros.  These
> packages will be left unchanged.
>
> == Benefit to Fedora ==
> * Reduced build times: Using the %make_build macros enables parallel make
> builds which will reduce build times for Fedora packages.
>
> * This will make it easier to enforce consistent build flag usage across
> all of Fedora.
>
> == Scope ==
> * Proposal owners: Update spec files and submit pull requests and do new
> package builds.  Optional: Merge pull requests (Proposal Owner would need
> to request to be added to provenpackagers group)
>
> * Other developers: Package owners may merge pull requests and submit new
> builds if they want, but this is not required for them.  A member of the
> provenpackagers group will be needed to merge pull requests.
> * Release engineering: [https://pagure.io/releng/issues/9533 #9533]
>
> * Policies and guidelines: Package guidelines already specify that packages
> should use these macros when possible.  Documentation will be updated to
> clarify that %make_build should be used for all make invocations (besides
> make install), and also with instructions for packages that fail to build
> with parallel make.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> No impact.
>
> == How To Test ==
> End-users will not notice any changes.
>
> == Dependencies ==
> No real dependencies, each package can be updated independently.
>
> == Contingency Plan ==
> * Contingency mechanism: None.  If not all packages are updated in time,
> then the work can continue into the next release.
> * Contingency deadline: All work will be done in the rawhide branch, and
> will not be backported into the f33 branch once it is created, so whatever
> gets done before the branch date will make it into the release.
> * Blocks release? No
>
> == Documentation ==
> The packaging guidelines will be updated as described in the Scope Section.
>
>
>
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Dan Čermák]

Sorry about the empty email, I've hit send too fast…

Anyway, on the topic of parallel builds: what is everyone's opinion on
adding the %limit_build macro from openSUSE (see:
https://build.opensuse.org/package/view_file/network:chromium/memory-constraints/memory-constraints.macros?expand=1)?

tl;dr; %limit_build -m 1500 will set the number of parallel processes so
that if all of them consume 1500 MB of RAM at most, that they will not
OOM your worker (especially handy on workers with many cores, but not
much RAM).


Cheers,

Dan

Dan Čermák  writes:

> Ben Cotton  writes:
>
>> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
>>
>> == Summary ==
>> This change will update all spec files in Fedora that use make and replace
>> the make invocations with either the %make_build or %make_install macros.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>>
>> The goal of this change is to standardize the usage of make in Fedora.  All
>> make invocations in spec files that don't use the install target will be
>> modified to use the %make_build macro, and all make invocations that use
>> the install target will be updated to use the %make_install macro.  Any
>> additional arguments to make that are not included in either the
>> %make_build and %make_install will be preserved.
>>
>> The %make_build macro enables parallel make builds using the -j option.  In
>> case a package does not build correctly with parallel make, then parallel
>> make will be disabled for that package by redefining the %_smp_mflags macro
>> like this:
>>
>>   %global _smp_mflags -j1
>>
>> All changes will be submitted to dist-git repositories via pull requests.
>> Pull requests will be merged after 1 week if there are no objections or
>> earlier if approved by the package maintainers.
>>
>> A script will be used to apply the necessary changes to the spec files, and
>> the result will be manually inspected before being merged.
>>
>> All packages updated by this change request will be rebuilt after the spec
>> file changes are merged.
>>
>> Some packages already use the %make_build and %make_install macros.  These
>> packages will be left unchanged.
>>
>> == Benefit to Fedora ==
>> * Reduced build times: Using the %make_build macros enables parallel make
>> builds which will reduce build times for Fedora packages.
>>
>> * This will make it easier to enforce consistent build flag usage across
>> all of Fedora.
>>
>> == Scope ==
>> * Proposal owners: Update spec files and submit pull requests and do new
>> package builds.  Optional: Merge pull requests (Proposal Owner would need
>> to request to be added to provenpackagers group)
>>
>> * Other developers: Package owners may merge pull requests and submit new
>> builds if they want, but this is not required for them.  A member of the
>> provenpackagers group will be needed to merge pull requests.
>> * Release engineering: [https://pagure.io/releng/issues/9533 #9533]
>>
>> * Policies and guidelines: Package guidelines already specify that packages
>> should use these macros when possible.  Documentation will be updated to
>> clarify that %make_build should be used for all make invocations (besides
>> make install), and also with instructions for packages that fail to build
>> with parallel make.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> No impact.
>>
>> == How To Test ==
>> End-users will not notice any changes.
>>
>> == Dependencies ==
>> No real dependencies, each package can be updated independently.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: None.  If not all packages are updated in time,
>> then the work can continue into the next release.
>> * Contingency deadline: All work will be done in the rawhide branch, and
>> will not be backported into the f33 branch once it is created, so whatever
>> gets done before the branch date will make it into the release.
>> * Blocks release? No
>>
>> == Documentation ==
>> The packaging guidelines will be updated as described in the Scope Section.
>>
>>
>>
>> -- 
>> Ben Cotton
>> He / Him / His
>> Senior Program Manager, Fedora & CentOS Stream
>> Red Hat
>> TZ=America/Indiana/Indianapolis
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send a

Re: RHEL 9 and modularity

[Dan Čermák]

Josh Boyer  writes:

> On Fri, Jun 19, 2020 at 2:54 PM David Cantrell  wrote:
>>
>> On Thu, Jun 18, 2020 at 08:44:39AM -0400, Josh Boyer wrote:
>> >Hopefully that provides some context and helps FESCo and the wider
>> >community understand where Red Hat is headed with modularity on the
>> >Enterprise side.
>>
>> Around the idea and concept of modularity... what are the benefits to Fedora,
>> Fedora developers, and Fedora contributors?  Through the various discussions
>> on modularity, nothing solid in this regard has been presented.  If I am
>> Fedora contributor now, what can modularity do for me?
>>
>> Most of the remainder of this thread talks about the problems with the
>> implementation as it exists today and problems with other known options.
>> Putting that aside for now, why should Fedora contributors care about
>> modularity?
>>
>> Put another way, what does the developer experience look like for modularity?
>
> These are good questions, but I feel like there has been about 2+
> years of discussion and debate about what Fedora could get out of
> modularity.

Well, a short tl;dr; would certainly help, as I must admit that even
after 2+ years of discussion I see very little incentive to modularize
any of my packages.

I see benefits of modularity for CentOS/RHEL, but not so clearly for
Fedora (except for more special cases like sway, where we have the
quickly evolving wlroots library and can thus deliver an up to date sway
even for older Fedora releases).

> I'm not sure I have anything to offer that is directly
> new or better.  I do think that ELN presents a new opportunity for
> those that have already found value in the Fedora community to use and
> improve it there in the absence of widespread Fedora adoption.
> Perhaps that would allow a place for the ideas to grow and could prove
> to be illustrative.
>
> At any rate, my goal isn't to evangelize or convert Fedora to suddenly
> embrace modularity wholescale.  I am simply offering clarity on the
> plans for RHEL 9 with this technology.
>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Fedora Packager Dashboard available for testing

[Dan Čermák]

Also from me a big thank you, this is very useful for getting a quick
overview!


Cheers,

Dan

Josef Skladanka  writes:

> Hi,
>
> We'd like to announce public testing of the Packager Dashboard - a new
> service for Fedora package maintainers aiming to provide all relevant
> data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
> orphan warnings, bugzillas, pull requests, active overrides and
> updates - at a single place in an easy to read and filter way.
>
> The Dashboard is now available: https://packager.fedorainfracloud.org/
>
> Packager Dashboard leverages caching in the Oraculum backend to
> significantly speed-up loading times with comparison to querying all
> the relevant resources separately. We, of course, can't cache the
> entire Bugzilla, Pagure, Bodhi... so we only cache data for users who
> visit Packager Dashboard at least once per 14 days. Please keep in
> mind that the first load for a “new” user might take a while. Most of
> the data sources are refreshed every hour.
>
> You can use the Dashboard for individual accounts as well as for FAS groups.
>
> We'd love to hear your feedback. Please keep in mind that this is
> testing deployment - it's currently running on a server with very
> limited resources and we're aiming for production deployment on
> CommuniShift during this summer.
>
> Feel free to provide ideas or bug reports at
> https://pagure.io/fedora-qa/packager_dashboard or simply send an email
> reply to this thread with all kinds of feedback.
>
> I'd like to mention the other people who made this possible:
>  - Miro Hrončok (churchyard) - Original idea
> 
> and ideas for data to display
>  - František Zatloukal - Backend 
>  - Lukáš Brabec - Frontend 
>
> Josef
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Please BuildRequire python3-setuptools explicitly

[Dan Čermák]

Tomas Hrnciar  writes:

> pyxattr  defolos frankcrawford kevin szpak

Fixed and rebuild in Rawhide.


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

Re: RHEL 9 and modularity

[Dan Čermák]

Hi Stephen,

this will probably get buried given the immense amount of replies in
this thread already, but nevertheless, here's my 2cts.

Stephen John Smoogen  writes:

> On Sat, 20 Jun 2020 at 17:42, Neal Gompa  wrote:
>>
>> On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr  
>> wrote:
>> >
>> > On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
>> > > TL;DR benefits of modularity for Fedora:
>> > >
>> > > * Automating build chains for producing artifacts
>> > > * Straightforward mechanism of producing non-rpm artifacts using our
>> > > existing tooling (modules -> flatpaks/containers/etc.)
>> >
>> > Both of these have nothing to do with Modularity, and can be done with
>> > existing RPMs.
>> >
>>
>> They have everything to do with Modularity, because that layer is
>> where that stuff was implemented. Modularity was the result of the
>> efforts involved with Factory 2.0, which gave us a lot of improvements
>> in our build infrastructure tooling for the first time since 2007.
>> Most of that rolled out in 2017, a full ten years after the last
>> revamp of our infrastructure.
>>
>
> I think that John and others aren't aware of how a module is built
> enough to understand what you meant by
> * Automating build chains for producing artifacts
> compared to how it is done normally.
>
> In normal times, a packager goes through a list of packages, updates
> spec files with new tags and rebuilds them one by one as needed..
> sometimes multiple times because of bootstrapping or finding out that
> the order you tried was wrong. A made up example from my days of doing
> this for a different place (this isn't what is needed anymore but long
> ago I had something similar):
> bison
> flex
> gcc [options 1]
> bison
> flex
> gcc [options 2]
> glibc
> bison
> flex
> gcc
>
> do them in one order and the apps came out working... do them in the
> wrong order and it might not. Rust, Java and other language stacks
> have similar loops. A packager may have to coordinate with multiple
> people to do this several times.
>
> In a module, you write that all down in the manifest with the order
> that you want packages built in and if you need to loop through them
> with different options. Then MBS does the builds in an automated
> fashion and it is repeatable. To me this is the biggest win here as
> for various groups of mass-rebuilds it cuts down errors when order
> matters and you have to do multiple ones to get from package set A to
> package set A+1.

This is actually freaking awesome! The one thing where our build system
is really laking is that we have to manually figure out the build order
and rebuild stuff manually. Other systems like OBS handle this
completely automatically, albeit bootstrapping on OBS has its issues as
well.

Anyway, is there any chance that we can get this functionality split out
of MBS and add it to koji? If we then convince koschei to kick of real
builds in Rawhide, then we'd be in a much better shape build system wise
imho.

>
> Making it easier to make flatpacks and stuff also is built into the
> tools which came with modularity. The tools which were doing it for
> the Fedora buildsystem before this  were 'fragile'.
>
> Yes a packager or system administrator can build these things without
> the modularity build system but trying to do it in scale in Fedora
> ended up needing the tools which came with MBS.
>
>
> -- 
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Preparing for ocaml 4.11

[Dan Čermák]

"Richard W.M. Jones"  writes:

>> Maybe I should do COPR builds of all this so everybody can easily see
>> what I'm talking about?  I did a total of 63 package builds in mock,
>> many of them simple rebuilds, so it will take a little time to get
>> that going.  Do we know yet what the timeframe is for an ocaml 4.11
>> release?
>
> This is all great stuff, and I think it also makes me wonder how we
> can make OCaml packaging simpler in Fedora.
>
> RPM has a new %generate_buildrequires feature which we might utilise
> (driven from the opam package metadata, I guess?).  I would also like
> to drop the whole ocaml-pkg vs ocaml-pkg-devel split, it's confusing
> and not necessary.  And maybe we could look at some kind of opam2spec
> scripting, similar to cpanspec.  Of course the devil is in the details
> because unless we can mostly automate packaging, we could end up with
> something that's even more complicated to deal with the exceptional
> cases.

Thanks for bringing this up Rich, I was actually thinking about this for
quite a while now after getting involved in OCaml packaging a bit.

I would suggest the following: we introduce a new Provides for ocaml
packages: Opam($pkg-name) = 1.2.3
I would propose that the ocaml provides generator takes care of adding
this to the devel package. This shouldn't be really hard to pull off, it
would just need to find the opam file and grep for the version.

%generate_buildrequires could be used to parse the opam file from the
tarball and extract the dependent opam packages from the depends:
array. E.g. the following:
--8<---cut here---start->8---
depends: [
  "ocaml" {>= "4.04.2"}
  "base"  {>= "v0.13" & < "v0.14"}
  "dune"  {>= "1.5.1"}
]
--8<---cut here---end--->8---
would translate to:
--8<---cut here---start->8---
BuildRequires: Opam(ocaml) >= 4.04.2
BuildRequires: Opam(base) >= 0.13 and Opam(base) < 0.14
BuildRequires: Opam(dune) >= 1.5.1
--8<---cut here---end--->8---

The hypothetical opam2spec would be certainly also a huge improvement,
as I think that most ocaml packages could be completely autogenerated.


But as you already said, the devil is most likely in the details, so
maybe we should start collecting ideas and potential pitfalls first? I
have therefore also cc'd Olaf, who takes care of Ocaml in
openSUSE. I would hope that we can coordinate our efforts, as Olaf has
some pretty nice ocaml macros that automatically generate file lists for
the subpackages (thereby already simplifying packaging quite a bit).


And at last I'd like to throw in a (probably quite controversial) idea:
how about we move ocaml into a module? Not to be able to have multiple
ocaml versions as streams, but so that we can use MBS to automatically
untangle the bootstrap loops for us. I was totally not aware of this
feature of MBS, but it was mentioned by Stephen in this email:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NY7RTBTCHF2IVWMWJ6JG2RQZVW5EZDRB/


So, what do you think about all this?


Cheers,

Dan


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

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

[Dan Čermák]

Hi Nicolas,

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
>
> == Summary ==
>
> redhat-rpm-config will be updated so users of the auto framework get
> automated release and changelog bumping.
>
> == Owner ==
>
> * Name: [[User:nim| Nicolas Mailhot]]
> * Email: 
>
> == Detailed Description ==
>
> This is a system-wide change because all packages build with
> redhat-rpm-config, but it only concerns packages that opted to use
> this part of redhat-rpm-config (auto framework).
>
> The change will make those packages auto-bump and auto-changelog at
> the rpm level, in an infrastructure-independent way.

Please forgive the silly questions (it's getting late here…), but how
does this look in practice?
How do I let rpm generate the changelog automatically?
Is the old changelog discarded?
And is this related to Piere/Pingou's work on the same topic that was
deployed to koji staging?


Cheers,

Dan


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

Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)

[Dan Čermák]

Nicolas Mailhot via devel  writes:

> Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
>> Nicolas Mailhot via devel wrote:
>> > So if you want to push Fedora release logic to its ultimate
>> > conclusion,
>> > the thing that should be in charge of committing the new
>> > release/changelog build state to package history in git is bodhi,
>> > not
>> > koji.
>> 
>> Why do build events need to be recorded in the Git history in the
>> first place? 
>
> The changelog is built-in the rpm format. Therefore, it needs to exists
> at rpmbuild stage. Therefore, you need to record past changelog state
> so new builds are consistent with previous builds.

The changelog should be consistent, but it needn't record every single
build event. Otherwise OBS would not work at all: the build system bumps
the release field automatically on each rebuild, but it does not touch
the changelog at all.


Cheers,

Dan


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

Re: [Fedora-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

[Dan Čermák]

Hi Nicolas,

Nicolas Mailhot  writes:

>> How do I let rpm generate the changelog automatically?
>
> This feature is not changelog generation, just changelog bumping on
> build events. You still need some other method to put non-build events
> in the changelog.
>
> The detached changelog is just one more file in SRPM sources, which is
> modified by rpmbuild at `%build` time with other files rpmbuild
> modifies. The tricky part is to modify the source file as a source file
> so rpmbuild adds the result to the produced SRPM (and, that does not
> work in mock right now, because mock serves the SRPM that existed at
> the start, not at the end of the build. Though it’s probably just a
> matter of getting mock to call again its SRPM creation method at the
> end of the build).

So essentially you store the changelog in a separate file (like it is
done in openSUSE) and use that to calculate the next release field?

Given the other replies to this thread (that this is all local only,
unless koji does git commits), does that mean that it's still: dist-git
commit = rebuild. The "only" difference to the current state of affairs
being, that I don't have to specify the Release field myself?

>
> The packager does not have to request the modification in his spec,
> it’s done as part of the various %auto_foo calls the change introduced

Could you provide an example how this would look in practice?

>
>> And is this related to Piere/Pingou's work on the same topic that was
>> deployed to koji staging?
>
> It’s a different implementation, at the rpm level, that does not tie
> bumping to Fedora infra (koji included). Though, it is probably
> complementary to what pingou did on the changelog alimentation front.
>
> IMHO the design mistake so far was to conflate bumping and non-build
> event changelog filling. You need to do both of course but build event
> should be a build event driven by the lowest common denominator
> (rpmbuild) with koji/infra scrapping rpmbuild results as usual and
> exposing them to users.

This is a good point imho: not every rebuild warrants a changelog entry
and having both separated appears sensible to me.


What I am currently missing from this proposal though is:
- How is this actually even implemented?
- How will this look in practice?
- Given that additional files would be put into dist-git, how do we roll
  this back in case things go wrong? (Having thousands of "remove
  %autorelease" commits by releng could be an option here, albeit not a
  pretty one).


Cheers,

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

Re: make: *** No targets specified and no makefile found.

[Dan Čermák]

"Martin Gansser"  writes:

> Hi,
>
> cant't built guayadeque on rawhide [1] but on f32 [2] it works.
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/4781/47574781/build.log

This looks related to the recent cmake changes wrt to out of source
builds. See here for migration steps:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration

> [2] 
> https://kojipkgs.fedoraproject.org//packages/guayadeque/0.4.7/0.16.20200717git3c54f64.fc32/data/logs/x86_64/build.log
>
> how can i solve this ?
>
> Ragards
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: [pam_radius] aarch64 GCC failures during ./configure's working compiler step?

[Dan Čermák]

Hi Alex,

Alex Scheel  writes:

> Not to pile on to what seems like a common topic... :-)
>
> Koschei notified me that one of my co-owned packages, pam_radius failed
> to build on aarch64 with the recent gcc update (10.1.1 -> 10.2.1). ppc and
> x86 built just fine.
>
> Looking at the build log, I'm almost inclined to kick off a new build
> on aarch64 to see if it is still there, or just issued at the wrong
> time:
>
> https://kojipkgs.fedoraproject.org/work/tasks/8159/47858159/build.log
>
>> + ./configure --build=aarch64-redhat-linux-gnu 
>> --host=aarch64-redhat-linux-gnu --program-prefix= 
>> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
>> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
>> --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec 
>> --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
>> --infodir=/usr/share/info --enable-werror
>> configure: WARNING: unrecognized options: --disable-dependency-tracking
>> checking build system type... aarch64-redhat-linux-gnu
>> checking host system type... aarch64-redhat-linux-gnu
>> checking target system type... aarch64-redhat-linux-gnu
>> checking for aarch64-redhat-linux-gnu-gcc... gcc
>> checking whether the C compiler works... no
>> configure: error: in `/builddir/build/BUILD/pam_radius-1.4.0':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> error: Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
>> Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
>> RPM build errors:
>> Child return code was: 1
>

This is most likely due to annobin being broken in rawhide on aarch64
(see Neal's email to devel from Saturday).


Cheers,

Dan


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

Re: transitive package-build-requires generator

[Dan Čermák]

Hi clime,

not a "proper" answer, but at least parts of the functionality that you
desire must be present in Koschei. Maybe Mikolaj Izdebski (iirc the
main developer of Koschei) can help you out?


Cheers,

Dan

clime  writes:

> Hello!
>
> Is there a tool to which I would provide a package name, source
> release (f32) and target release (epel8) and it would output all build
> requires transitively so that I know what specifically I need to add
> to epel8 to be able to build the target package successfully there?
>
> Thank you
> clime
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Self Introduction: Kevin Buettner

[Dan Čermák]

Hi Kevin,

welcome to the pack!

Kevin Buettner  writes:

> Hi,
>
> My name is Kevin Buettner.
>
> I've been involved in GDB development for over 20 years.  I'm an
> (upstream) GDB global maintainer.  I would like to become a
> co-maintainer of the GDB package for the Fedora project.

You should talk to the maintainers of GDB then ;-) (all in the To: field
as well).

>
> In order to come up to speed on what Fedora package maintenance
> is about, I've been reading the following page as well as many of
> the links on that page:
>
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> Kevin


Cheers,

Dan


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

Re: CPE Weekly: 2020-04-04

[Dan Čermák]

Ben Rosser  writes:

> On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel  wrote:
>>
>> - Original Message -
>> > From: "Nicolas Mailhot via devel" 
>> > To: "Development discussions related to Fedora" 
>> > 
>> > Cc: "Nicolas Mailhot" 
>> > Sent: Monday, April 6, 2020 9:10:56 AM
>> > Subject: Re: CPE Weekly: 2020-04-04
>> >
>> > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
>> > >
>> > > It'd be interesting to see if the FESCo election system could be
>> > > repurposed to get a sense of all packagers' opinions, rather than
>> > > make assumptions on how the community as a whole feels based on a few
>> > > vocal members and their participation in the mailing lists.
>> >
>> >
>> > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
>> > so it’s the official place to reach Fedora packagers.
>>
>> That's not the point I was making.
>>
>> Not everyone is inclined to loudly argue their positions on the mailing
>> list. There have only been 12 unique participants to this thread and 57
>> to the other thread.
>>
>> That isn't indicative of the entire Fedora packager ecosystem. A lot of
>> people are staying silent.
>>
>>
>> I believe we need a different way to engage the rest of our packager
>> base.
>
> I'm a packager who has been staying silent, but I generally strongly
> agree with the points that Adam, Miro, Neal, and others have been
> making

As a $nobody that has stayed silent so far, I'd second this: essentially
everything that I would have said, has already been said and ignored
over and over and over again. Honestly, I don't see a point in repeating
the same things again, just to get a polite "we're terribly sorry how we
handled this, but no, we've decided to stick with gitlab"

> with a few caveats:
>
> * I don't _really_ mind if we wind up using Gitlab over Pagure, but if
> we do, I do feel pretty strongly that we should use Gitlab CE and
> self-host it-- I don't think it would be right for Fedora to use an
> externally hosted solution and I don't think we should use the
> enterprise edition.

I would very much prefer Pagure, mostly because it is one of the few
true FLOSS git forges and we're currently it's biggest user.

>
> * I don't like how this process has been conducted, and I think that
> official responses from CPE thus far haven't really made things
> better-- if anything, the "we apologize, but this is the decision
> we've made" attitude is making things worse.

Exactly. All threads that have unraveled so far only make me
increasingly frustrated and let me feel more and more powerless: if even
established and respected community members cannot make the CPE
reconsider and go back to the drawing board, then what on earth can I
do? Why should I even try to make a positive impact in the Fedora
community, if the CPE doesn't even consider our core values? What will
be ditched next for a proprietary SaaS solution? (yes I am exaggerating
on purpose with the last one)

>
> * I fear that, once again, we haven't adequately understood the
> consequences of replacing pagure and some of the features that were
> recently-- finally!-- added to it in order to replace missing pkgdb2
> functionality will again be lost for a long period of time... and
> nothing I've read in any of these threads so far has helped reassure
> me that's not the case.

Your fear has been confirmed multiple times by Leigh Griffin: there is
*no* plan or analysis yet how the currently required features of our
pagure dist-git can be implemented in gitlab and how much that will
cost (how that does not defeat the original purpose of this whole ordeal
is beyond me).

I honestly have nothing more to add to that, as imho the last paragraph
already tells us how this thing will end :-(


Dan


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

Re: CPE Git Forge Decision

[Dan Čermák]

Leigh Griffin  writes:

>> If you had stopped at the first
>> objections and revisited the decision making process with the rest of
>> the community involved in an open manner, you would have been forgiven,
>> because everyone here is trying to assume good faith. Alas, you haven't
>> done that. Apologizing for your mistakes is a necessary step, but it's
>> not sufficient.
>>
>
> Ok let's scenario this out so as several people want us to restart and go
> again, largely because they disagree with the decision and Pagure is the
> choice that they would have made. If we re-engage now, I firmly believe we
> will get a whole new set of requirements to complement the existing
> requirements but scoped deliberately (as has been suggested by numerous
> replies) to a situation where Pagure is the only choice for Fedora.

And how will that be different from your initial set of requirements,
that had far too surprising similarities to GitLab EE's features?

I really don't like to jump in and start pointing fingers, but during
the initial discussion of the requirements, it was pointed out multiple
times that all of this looks like a pretense to ditch Pagure for
Gitlab. So honestly, I really don't see how that would make the process
so far more unfair (it would actually make it more fair to all Fedora
contributors who value Pagure & the associated values and who are
feeling increasingly ignored and betrayed).


Regards,

Dan


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

Why does Koschei not run real builds?

[Dan Čermák]

Hi list,

my question is pretty much $subject: Why doesn't Koschei kick of
real builds off packages on dependency changes? From my naive POV that
looks like the missing piece to give us the "OBS-experience". Having
that at least in Rawhide sounds like a good thing to me.


Cheers,

Dan


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

Re: Why does Koschei not run real builds?

[Dan Čermák]

Fabio Valentini  writes:

> On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
>  wrote:
>>
>> Hi list,
>>
>> my question is pretty much $subject: Why doesn't Koschei kick of
>> real builds off packages on dependency changes? From my naive POV that
>> looks like the missing piece to give us the "OBS-experience". Having
>> that at least in Rawhide sounds like a good thing to me.
>
> It *might* be a good idea to help deal with rebuilds, but I see some
> problems with that.
>
> - koschei would need to add "rebuilt by koschei" commits to dist-git
> for this (OBS doesn't have a real VCS, so it's not a problem there)

This is the part that I don't really get: why do we need to have a
commit for each rebuild? Just to bump the release field?

Wouldn't it be completely sufficient to let koji handle this via one of
the schemes that Igor and Neal presented at Flock 2019?

(This is probably naive, but from my usage of OBS I have never
encountered the case that I miss having a commit on each rebuild)

> - those changes would add a lot of churn to .spec files, possibly
> angering a lot of packagers, and would also create possible conflicts
> between local changes and koschei builds

This wouldn't be a problem if we could get rid of the "rebuild on
commit" requirement and make this opt-in at first.

> - the builds add a lot of load to koji already (although at lower
> priority), which will probably be a problem when there's reduced
> capacity (e.g. the upcoming datacenter move)

This is indeed an issue that I was afraid of.

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


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

Re: Why does Koschei not run real builds?

[Dan Čermák]

clime  writes:

> On Mon, 13 Apr 2020 at 10:55, Dan Čermák  
> wrote:
>>
>> Hi list,
>>
>> my question is pretty much $subject: Why doesn't Koschei kick of
>> real builds off packages on dependency changes? From my naive POV that
>> looks like the missing piece to give us the "OBS-experience". Having
>> that at least in Rawhide sounds like a good thing to me.
>
> Dan, can I have some basic questions to this because I don't know OBS.
>
> Could you describe the feature in more detail with regards to
> auto-rebuilding and when it is useful?

In a nutshell: OBS will in its default mode rebuild each package once
one of its direct or indirect dependencies changes.

That is pretty useful, because as a maintainer you can just update a
library and you don't have to do a thing to get dependent packages
rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and
"need a provenpackager to rebuild dependent packages of ABC" emails on
devel. Also, if a package fails to build due to an update, it will be
noticed right away and not until the next mass rebuild.

Additionally updating a bunch of packages will no longer require that
you figure out the build order yourself: the build system figures it out
itself by rebuilding your packages until the transitive dependencies
stop changing.

All of this is of course only really viable for Rawhide and already
released Fedora branches should not be run like this, because one wrong
update could wreck the whole distro.


Cheers,

Dan


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

Re: Why does Koschei not run real builds?

[Dan Čermák]

Michael Cronenworth  writes:

> On 4/15/20 5:52 PM, Dan Čermák wrote:
>> That is pretty useful, because as a maintainer you can just update a
>> library and you don't have to do a thing to get dependent packages
>> rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and
>> "need a provenpackager to rebuild dependent packages of ABC" emails on
>> devel. Also, if a package fails to build due to an update, it will be
>> noticed right away and not until the next mass rebuild.
>
> Is it smart enough to only rebuild for SONAME bumps or ABI changes?

No, it rebuilds once a dependency actually changes (if it is rebuild and
the resulting RPM is unchanged, then no rebuild is kicked of though).

>
> I wouldn't want rebuilds "just because."

Well, you kinda do want them (in Rawhide) because ABI changes & SONAME
bumps are not applicable for all programming languages and then people &
tools make mistakes. So a "safe" update without a SONAME bump might be
one that actually required one and would be undetected unless you
rebuild & retest dependent packages.

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


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

Re: Orphaned packages looking for new maintainers (anaconda also affected)

[Dan Čermák]

Sérgio Basto  writes:

> On Mon, 2020-04-27 at 12:39 +0200, Miro Hrončok wrote:
>> GConf2
>
> GConf2 is orphan, why ? no maintainers or a task force to be removed ?

GConf2 has been deprecated for well over a decade and afaik unmaintained
for nearly half a decade. Thus: please just remove it from your
dependencies and use gsettings instead (the upstream replacement).

Many packages might actually not require it at all: emacs was pulling it
in, but it works just fine without it and with gsettings instead.


Cheers,

Dan


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

Re: Can we distribute modular .repo files in a separate package?

[Dan Čermák]

Miro Hrončok  writes:

>
> Side note: It would be great if DNF supported system-repos in /usr/share and 
> override options in /etc, but that is not (yet) the case.

slightly off-topic, but I'm just going to leave libeconf (a library to
achieve exactly that easily) here:
https://github.com/openSUSE/libeconf


Cheers,

Dan


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

Re: Review swap: psi-notify

[Dan Čermák]

Michel Alexandre Salim  writes:

> Would anyone like to swap a review?
>
> psi-notify - https://bugzilla.redhat.com/show_bug.cgi?id=1832623

Looks simple enough, I'll try to review it today. If I don't manage to,
anyone else can take the review.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New set of questions for FESCo candidates?

[Dan Čermák]

Zbigniew Jędrzejewski-Szmek  writes:

> On Mon, May 11, 2020 at 04:55:03PM -0400, Ben Cotton wrote:
>> On Mon, May 11, 2020 at 4:39 PM Kevin Fenzi  wrote:
>> 
>> > If we just make it an essay with suggestions of what to include, I think
>> > it might be more engaging than just a sentence or two on specific
>> > questions.
>> >
>> > Thinking about it from an editorial perspective, the questionnaire format
>> results in what will likely be more readable posts than a longer essay. The
>> current format does sometimes result in a sentence or two, but a lot of the
>> answers are a paragraph or two. So I'm not sure the end result would be a
>> much different amount of content; some people are going to give shorter
>> replies no matter the form. The other good thing about the current format
>> is that it makes the answers more directly comparable.
>> 
>> That said, I do like the idea of a more free-form response as a way to see
>> how candidates think. I suppose I can toss both at FESCo and let them make
>> the choice. :-)
>
> I'd vote for Nirik's proposal over a fixed set of questions...

I actually like that idea as well, as every candidate can highlight
their own focus better that way.


Cheers,

Dan


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

Re: i3 new SIG

[Dan Čermák]

Hi Eduard!

Eduard Lucena  writes:

> Hello guys,
>
> My name is Eduard Lucena, some of you maybe know me, tons of you don't. I'm
> part of the marketing team and host of the Fedora Podcast.
>
> I'm starting a SIG about i3 tiling window manager [1], with the final
> objective of create a remix that can finish up in an official spin. I have
> a ML you can join [2] and I'm hanging around on #fedora-i3 on IRC. I have a
> few ideas and I really would love to hear yours.

As the current maintainer of i3, I kinda have to join ;-)

As others have already mentioned in the thread: we should look into
joining forces with the sway SIG (which I am also a member of). While
a lot of the packages of interest are not really shared, the general
similarity would allow us to save a lot of time when it comes to QA and
the creation of a spin. Maybe we should merge into the tilling window
manager SIG? (with a better name of course).


Cheers,

Dan


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

Re: Orphaned packages looking for new maintainers

[Dan Čermák]

Hi Kevin and Dominique,

Kevin Fenzi  writes:

> Hey Dominique. If you haven't found a sponsor yet, drop me an email off
> list and I can probibly sponsor you. Thanks for stepping up to maintain
> some packages. :)

Thanks for the offer to sponsor Dominique Kevin!

Dominique, would you be interested in joining the sway SIG as waypipe
fits quite well into our maintained packages
(https://fedoraproject.org/wiki/SIGs/Sway#Packages)?


Cheers,

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

Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)

[Dan Čermák]

Hi Dominique,

Dominique Martinet  writes:

> *snip*
>
> 341 to 130ms is a good start I guess, the rest of the waiting time
> probably now outweights bash and will get some looking at at a later
> point, but might as well start somewhere.

That's quite the improvement! Good job and thanks for looking into that!

>
> How should I go about with that? Open bz bugs to all the packages I
> listed? 

I would suggest to directly create pull requests on pagure (with a
reference to this thread), as that will make it more likely that this
change will actually happen.

> strongly suggesting to get things to move to /usr/share (17) and
> flatpak (suggest some kind of cache? not sure they'll be
> interested...)  and environment-modules (not sure what to suggest
> there, I only have environment-modules because I need to test
> something with openmpi from time to time and it comes with it...)
>
>
> It might also make sense to have a packaging guideline suggesting to
> avoid /etc/bash_completion.d in favor of the /usr/share variant, I
> couldn't find anything here[1] but I might not have looked thoroughly
> enough...

Afaik we don't have an entry in the packaging guidelines about bash
completion files. Maybe the packaging committee should look into that?


Cheers,

Dan


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

Re: i3wm for EPEL8

[Dan Čermák]

Hi Eric,

first and foremost sorry about not replying to the Bugzilla bug earlier,
the past weeks were unfortunately a bit crazy.

Eric Mesa  writes:

> Hey there,
>
> I noticed that the i3 window manager wasn't available in EPEL8. Before
> trying to go through the process of becoming a package maintainer I decided
> to try and run it via copr to see how much modification was needed. For
> EPEL8 (as opposed to 7) I was able to take the current spec file and, after
> creating an EPEL8 copr repo for xcb-util-xrm (
> https://copr.fedorainfracloud.org/coprs/djotaku/xcb-util-xrm/), it would
> build. But it wouldn't install for it needed some perl packages. So I set
> about building those. You can see how far I got in (
> https://copr.fedorainfracloud.org/coprs/djotaku/i3wm/packages/), but each
> one had one or more dependencies. So I was rapidly along a path towards
> having to recreate nearly all of Perl for EPEL8. (Only a slight
> exaggeration). Unfortunately, for those, I couldn't just bum the spec file
> because they each had a patch that needed to be applied. So I had to
> download the repo from pagure, use spectool and mock to create the srpm and
> then load that into copr. Quite tedious.
>
> However, the good news is that I never had to make any mods to the spec
> files to get them to work for EPEL8. Everything just worked. So...what is
> the proper path to get the perl folks to create epel8 branches in their
> repos (again, there isn't any additional work needed - at least at this
> point in time)? In the long run, I'd definitely like to be a co-maintainer
> for i3 for epel8.

I'll be pretty blunt here: I don't really care about having i3 in epel8,
so as long as you take care of the epel8 branch and any bugs that pop
up: I'm more than happy to add you as a co-maintainer.


Cheers,

Dan


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

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Dan Čermák]

Hi Sérgio,

Sérgio Basto  writes:

> Hi,
>
> On Tue, 2020-04-14 at 11:09 +0100, Peter Robinson wrote:
>> > On 14. 04. 20 11:06, Miro Hrončok wrote:
>> > > The following packages are orphaned...
>> > > 
>> > > GConf2alexl, caillon,
>> > > caolanm, 1 weeks ago
>> > 
>> > firefox (maintained by: alexl, caolanm, gecko-maint,
>> > jgrulich, kalev, kengert,
>> > mbarnes, rhughes, rstrode, sharkcz, stransky, ueno, xhorak)
>> > firefox-75.0-1.fc33.src requires pkgconfig(gconf-
>> > 2.0) = 3.2.6
>> > 
>> > thunderbird (maintained by: alexl, caolanm, gecko-maint,
>> > johnp, kalev, kengert,
>> > mbarnes, rhughes, rstrode, ssp, stransky, ueno, xhorak)
>> > thunderbird-68.7.0-1.fc33.src requires GConf2-devel 
>> > = 3.2.6-27.fc31
>> > 
>> > icecat (maintained by: jenslody, kengert, sagitter)
>> > icecat-68.7.0-1.rh1.fc33.src requires
>> > pkgconfig(gconf-2.0) = 3.2.6
>> > 
>> > 
>> > This seems like a forgotten dependency. At least thunderbird builds
>> > fine without
>> > GConf2.
>> 
>> I bet it was a leftover from the migration to gsettings with the
>> gsettings-data-convert script, I suspect all the runtime deps
>> (anaconda too) is around this and can probably be dropped.
>
> GConf2 is not Orphan anymore , but I'd like migrate rawstudio in
> particular to gsettings , where I can find some examples of this
> migration ? 
> What we need ? change code ? , change build requires ? or what ?

You'll need to change the code and the BuildRequires. This guide should
be a decent start for the code changes:
https://developer.gnome.org/gio/stable/ch34.html


Hope this helps,

Dan


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

Re: new packages review tickets

[Dan Čermák]

Hi Mattia,

Mattia Verga via devel  writes:

> Hi all,
>
> now that we have new detailed statistics about new package review 
> tickets ( https://fedoraproject.org/PackageReviewStatus/ ) I would like 
> to make some cleanings... at the time I'm writing, there are 517 tickets 
> listed as new, many of them are older than 5 years!
>
> The first steps I would like to do, if FESCO and community agree, are:
>
> - some of these tickets are marked as "dependency rejected"; that means 
> they depend on other package review tickets that were rejected, for 
> whichever reason, so they will never get approved either. I would like 
> to just close these (there are 3 tickets in this state)
> - following the Policy for stalled package reviews [1], I would like to 
> mass comment on tickets submitted before 1/1/2017 (more than 3 years 
> old) asking the submitter if they're still interested in continue with 
> the review process and mark the ticket as NEEDINFO. After one month 
> without reply I will close the ticket, as per policy.
>
> Then there are 352 tickets listed as "review in progress", but that's 
> also not true. Here we have tickets with review-flag set to ? (review in 
> progress) or + (package approved) since 2013. There are even some 
> tickets for which the git repo as been generated.
> These tickets probably need a manual check to choose the best course of 
> action. Some of those packages have been approved and imported in 
> Fedora, some of these have been later retired also from repositories... 
> but the review ticket has never been closed.
> I would propose to:
>
> - if the package got approved and it's still in repos, just close the 
> review ticket as CURRENTRELEASE
> - if the package got approved and was later removed from repos, just 
> close the review ticket as NOTABUG
> - if the package got approved before 1/1/2019, but never imported in 
> repos, clear the review-flag and assignee and mark as NEEDINFO from the 
> submitter asking if they're still interested in this (we probably need 
> to decide what to do if the git repo has been already set up)
> - if the package got approved before 1/1/2020, but never imported in 
> repos, do not clear the approval and mark as NEEDINFO from the submitter 
> asking if they're still interested in this
> - for tickets with last change marked before 1/1/2019, if the 
> review-flag is set to be IN-PROGRESS, mark the ticket as NEEDINFO from 
> either the submitter or the reviewer
>
> Let me know if you agree (or disagree) with this proposal.

Sounds good to me. Thanks for taking care of this!


Cheers,

Dan


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

Re: Defining the future of the packager workflow in Fedora

[Dan Čermák]

I'm late to the party, but here we go anyway.

Pierre-Yves Chibon  writes:

> [snip]
>
> Here is what the vision we came to and that we would like to discuss:
>
> ○ Every changes to dist-git is done via pull-requests

As long as this is not mandatory, sure.

> ○ Pull-requests are automatically tested
> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji

Make that every tag and we are sold.

> ○ Every build in koji results automatically in an update in bodhi
> ○ Every update in bodhi is automatically tested
> ○ If the tests pass, the update is automatically pushed to the repository

So no more user's testing being able to test updates manually? I have
packages where I'd actually prefer them to be tested manually (i3,
i3status, i3lock, sway et al), because I haven't had the time to setup
openQA for these yet.

>
>
> For this workflow to work nicely we need to fix a few things first:
>
> - We need to work on the change logs in the spec files, as otherwise
>   pull-requests are going to conflict more often than not

Let's please just get rid of them and the same for the Release tag (that
should be automatically bumped by the build system on each rebuild, as
we want automatic rebuilds, don't we?).

> - We need to fine a place to insert the end-user information about an update 
> (in
>   the PR description?)

The git tag as Randy & Jeremy suggested.

> [snip]
>
> Do you like this vision? Would you change some pieces of it? Would you change 
> it
> entirely?
> In an ideal world, what would packaging software look like to you?

Like a combination of our current way of doing things combined with
openSUSE's Open Build Service (not only the automatic rebuild part,
although that is nice too).

What imho OBS did right is that it provides a single entry point for
packaging: a unified web UI with all the information & build states and
a unified CLI client for doing literally everything.
You want to update package `foo`? `osc branch devel:FooProj:foo && osc
checkout home:MyUserName:branches:devel:FooProj:foo`, make your changes
there, commit them and send a submitrequest (something like a pull
request). You want to become maintainer of a package? `osc
reqmaintainership`. Who maintains `bar`? `osc maintainer bar`. And so
on…

So what I'd love to see would be the single entry point to packaging
that Christopher described, not only as a web application, but also as a
CLI client.

To be more specific:
- My package's spec file is tracked in dist-git or git + git-lsf,
  depending on a setting I'll either have one branch for all the Fedora
  & EPEL versions or one branch for each version.

- Commits to the repository result in CI run (a default one, like
  rpmlint + additional custom tests). I can push -f all commits since
  the last tag, but nothing before that. Once I tag a commit, it is
  build "for real" (and tested) and automatically submitted as an update
  to bodhi. The changelog gets generated from the tag message and
  included into bodhi.
  On the other hand it must be possible to submit multiple packages as
  an update. I could imagine something like a `fedpkg update-multiple
  package1:$commit1 package2:$commit2 -m $message` that would tag the
  specified commits and push all builds into a single update to bodhi.

- the-new-hotness will send pull requests once a package is updated
  upstream. The pull request gets built & tested as an ordinary commit
  would. As a packager I have the option to "merge + tag" (also being
  able to modify the tag), which automatically submits this as an
  update.
  This would tremendously simplify the update process for most of my
  packages.

- If I would have a package that requires a lot of patches, then I can
  be granted the option to use source-git and keep my patches as commits
  on top of an upstream branch. This should imho require some form of
  approval though, as this can easily escalate into hundreds of patches.

- Package updates cause a rebuild of all dependencies (+ a test run of
  each of these). Only a successful rebuild is allowed to be submitted
  to bodhi.

- Allow the creation of package "namespaces" or "projects" (stolen from
  OBS' development projects): a packager or a group can create a
  namespace on the git forge, into which they can fork/link arbitrary
  packages from the distribution. The forked packages become a part of
  the buildroot of this namespace, all others are inherited from the
  distribution itself and are unaffected by changes in this namespace.

  This should allow packagers to run experiments which do not affect the
  distributions build root, but still be able to test the impact of
  their changes on a larger set of packages. Packagers should then be
  able to send their changes back via a mass-pull-request/mass-commit.

- Extend the fedpkg CLI to support more actions on pagure, e.g. finding
  out who is the current package maintainer of Foo or forking the
  package Bar and sending a PR back.


Hope all of this makes s

Re: Stepping away from packaging (and request for owners)

[Dan Čermák]

Hi Jamie,

Jamie Nguyen  writes:

> ==
> [b]: Remove my admin/commit access
> ==
>
> adobe-source-code-pro-fonts
> libmpdclient
> libuv
> mpc
> ncmpc
> newsbeuter
> notmuch

I'd be willing to help out with notmuch, as I am using it quite
extensively.


Cheers,

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

Re: List of Python 2 packages to be removed mid-November

[Dan Čermák]

Miro Hrončok  writes:

> defolos
>pyxattr
>  python2-pyxattr (→ PY2)

I will drop the python2 subpackage.

> dodji
>offlineimap
>  (→ PY2)

Can we get an exception for this please? Afaik offlineimap is not ready
for python3 yet and I'd hate it to disappear from Fedora.


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

Orphaned i3-ipc and dzen2

[Dan Čermák]

Hi list,

I have just orphaned i3-ipc and dzen2. Both packages are dead upstream
and I never used them (I inherited both as parts of the i3 stack).

Feel free to take them, but be aware that you'll effectively have to
become the new upstream.


Cheers,

Dan


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

Re: do not remove arpack package from Fedora

[Dan Čermák]

Felix Schwarz  writes:

>
> - package testing
>Manually checking updates-testing is too tedious and usually I don't want
>to install everything in updates-testing right away. But there are some
>packages which I like to get as fast as possible/which I can test easily.
>
>- So I would like to get some kind of "notification" when such a package
>  goes into updates-testing + a reminder to give feedback.
>- As an extension we could ask users who use certain applications regularly
>  if they want to try an update + ask them for bodhi karma after
>1-2 days.

This would be a nice feature! I certainly would like to help out testing
packages, but unless the maintainer pings me directly and asks me to
help, I will not notice an update being pushed to testing.


Cheers,

Dan


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

Re: eit.c:394:13: error: 'stime' was not declared in this scope; did you mean 'ctime'?

[Dan Čermák]

Hi,

"Martin Gansser"  writes:

> Hi,
>
> i'am trying to compile vdr-2.4.1 for Fedora32, but this fails with the 
> following error message:
>
> g++ -O3 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
> -Werror=overloaded-virtual -Wno-parentheses -D_GNU_SOURCE 
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fPIC -c 
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
> -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DVDR_USER=\"vdr\" -DSDNOTIFY 
> -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/var/lib/vdr/video\" 
> -DCONFDIR=\"/etc/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" 
> -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" 
> -DPLUGINDIR=\"/usr/lib64/vdr\" -DLOCDIR=\"/usr/share/locale\" 
> -I/usr/include/freetype2 -I/usr/include/libpng16-o eit.o eit.c^M
> eit.c: In constructor 'cTDT::cTDT(const u_char*)':^M
> eit.c:394:13: error: 'stime' was not declared in this scope; did you mean 
> 'ctime'?^M
> 394 | if (stime(&dvbtim) == 0)^M
> | ^^M
> | ctime^M
>
> I tried the following patch already, but this doesn't work.

You need to `#define _DEFAULT_SOURCE` (since glibc 2.19) or `#define
_SVID_SOURCE` (for glibc <= 2.19) before including time.h (and before
any headers that could include time.h themselves).

>
> --- a/eit.c.orig2019-12-12 16:23:42.231599228 +0100
> +++ b/eit.c 2019-12-12 16:24:09.093601411 +0100
> @@ -13,6 +13,7 @@
> #include "eit.h"
> #include 
> +#include 
> #include "epg.h"
> #include "i18n.h"
> #include "libsi/section.h"
>
> Any help appreciated
>
> Martin


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

Re: Fedora 32 System-Wide Change proposal: Stop shipping individual component libraries in clang-libs package

[Dan Čermák]

Ben Cotton  writes:

[snip]
>
> == Dependencies ==
> The following packages depend on clang-libs and will need to be updated:
>
> * bcc
> * bpftrace
> * castxml
> * ccls

ccls has already been fixed upstream to support building against
libclang-cpp.so (as openSUSE did the same switch earlier and ccls
suddenly became FTBFS in Tumbleweed).

> * clazy
> * gnome-builder
> * ispc
> * kdevelop
> * lldb
> * mesa
> * pocl
> * qt-creator
> * qt5-doctools
> * shiboken2
> * tinygo



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

Re: Fedora 32 System-Wide Change proposal: Stop shipping individual component libraries in clang-libs package

[Dan Čermák]

Tom Stellard  writes:

> On 12/12/2019 03:32 PM, Dan Čermák wrote:
>> Ben Cotton  writes:
>> 
>> [snip]
>>>
>>> == Dependencies ==
>>> The following packages depend on clang-libs and will need to be updated:
>>>
>>> * bcc
>>> * bpftrace
>>> * castxml
>>> * ccls
>> 
>> ccls has already been fixed upstream to support building against
>> libclang-cpp.so (as openSUSE did the same switch earlier and ccls
>> suddenly became FTBFS in Tumbleweed).
>> 
>
> Thanks for letting me know.  When are you planning to rebase to the new
> version in rawhide?

I have no concrete plans, I would have waited for the next upstream
release that includes the patch. I can cherry-pick the necessary change
earlier at your convenience, just let me know when.


Cheers,

Dan


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

Re: Fedora Packager Dashboard mockups

[Dan Čermák]

Hi Miro,

I like your packaging dashboard a lot, I think this a good idea and an
improvement for the packaging experience!

(Further replies below.)

Miro Hrončok  writes:

> While I love the concepts of Rust, I don't think there are that many benefits 
> when mostly talking to HTTP or calling dnf/libsolv API. I wanted to learn 
> some 
> Rust via https://adventofcode.com/2019 but I have failed to delicate some 
> time 
> to that, nerdslipping and procrastinating differently :D

Unless you are already quite proficient in Rust, it is probably more pragmatic
to just use Python.

>
> I was actually thinking Python + asyncio to collect the data + something like 
> Angular to present them. However I'd rather go back and do adventofcode in 
> Ook! 
> than writing the JS frontend myself ;)

I've gathered a bit of experience with Typescript at $dayjob over the
past months (unfortunately not with browsers and thus not actual
frontend stuff), so if you're patient with me (and my limited time), I'd
be willing to help out.


Cheers,

Dan


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

Re: Orphaned packages looking for new maintainers

[Dan Čermák]

Hi Jerry,

Jerry James  writes:

> Pardon the top posting. I am on the road with only my phone, no Fedora
> devices anywhere. I have been thinking about trying to get Facebook's Infer
> tool into Fedora. Several of its dependencies are on this list, but I won't
> be able to take them until I get home, after they are retired.  The ocaml
> packages, at least, have some serious dependency issues, as I recall, but I
> would like to see if they can be fixed.  Can someone please assign the
> following packages to me?  After I return I will fix them if I can & retire
> them if I cannot.
>
> jackson
> ocaml-bin-prot
> ocaml-deriving
> ocaml-sexplib

Since I'd also like to package infer for Fedora, I've taken the ocaml
packages and made you an admin of them too. Unfortunately, jackson has
already been retired, but since it's a Java package and I have zero
experience with that, I have not filed a releng ticket for that.

Feel free to contact me when you get back home & enjoy your trip in the
meantime!


Cheers,

Dan


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

Re: Compiling with AddressSanitizer

[Dan Čermák]

Hi Nathanael,

Nathanael Noblet  writes:

> Hello,
>
>I have been using a library for awhile now and have been thinking of 
> submitting it to Fedora. Part of what I have been doing with it was compiling 
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that 
> is handled with Fedora packages. Are we able to / should we provide library 
> package versions that are compiled against these kinds of sanitizers? Or if 
> someone wants to do that they should recompile the RPM with those flags and 
> use it locally?
>

Address sanitizer is a debugging tool and beside the issues that Florian
mentioned, there are also security issues involved with running ASAN
applications in production:
https://www.openwall.com/lists/oss-security/2016/02/17/9 (not sure if
this is still relevant though).

I'd certainly suggest to build applications with ASAN, UBSAN,and MSAN,
but only do that for testing. If you want to integrate this in the
rpmbuild process, you could rebuild your application in %check with ASAN
enabled and run its test suite.


Cheers,

Dan


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

Re: Compiling with AddressSanitizer

[Dan Čermák]

Hi Nathanael,

Nathanael Noblet  writes:

> Hello,
>
>I have been using a library for awhile now and have been thinking of 
> submitting it to Fedora. Part of what I have been doing with it was compiling 
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that 
> is handled with Fedora packages. Are we able to / should we provide library 
> package versions that are compiled against these kinds of sanitizers? Or if 
> someone wants to do that they should recompile the RPM with those flags and 
> use it locally?
>

Address sanitizer is a debugging tool and beside the issues that Florian
mentioned, there are also security issues involved with running ASAN
applications in production:
https://www.openwall.com/lists/oss-security/2016/02/17/9 (not sure if
this is still relevant though).

I'd certainly suggest to build applications with ASAN, UBSAN,and MSAN,
but only do that for testing. If you want to integrate this in the
rpmbuild process, you could rebuild your application in %check with ASAN
enabled and run its test suite.


Cheers,

Dan


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Dan Čermák]

Given the nearly only negative replies to this proposal: can we please
just officially mark it as retracted/rejected and move on?


P.S.: all my Fedora machines would no longer be able to run Fedora >=
32, effectively ending my involvement in this community :(

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
>
> == Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
> A test rebuild of a distribution largely based on Fedora 28 showed
> that there is only a small number of build failures due to the
> baseline switch. Very few packages are confused about the availability
> of the CMPXCHG16B instruction, leading to linking failures related to
> -latomic, and there are some hard-coded floating point
> results that could change due to vectorization.  (The latter is within
> bounds of the usual cross-architecture variation for such tests.)
>
> == Benefit to Fedora ==
>
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
>
> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.
>
> == Scope ==
> * Proposal owners: Update the gcc and
> redhat-rpm-config package to implement the new compiler
> flags.  It is expected that the new baseline will be implemented in a
> new GCC -march= option for convenience.
>
> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.
>
> * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> ** All Fedora builders need to be AVX2-capable.
> ** Infrastructure ticket:
> [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> * Policies and guidelines: No guidelines need to be changed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
> == How To Test ==
> General system testing will provide test coverage for this change.
>
> == User Experience ==
> User should observe improved performance and, likely, battery life.
> Developers will benefit from the knowledge that code with AVX2
> optimizations will run wherever Fedora runs.
>
> == Dependencies ==
> There are no direct dependencies on this change at this time.
>
> == Contingency Plan ==
> It is possible to not implement this change, or implement a smaller
> subset of it (adopting the CMPXCHG16B instruction only, for example).
>
> * Contingency mechanism: Mass rebuild with different/previous compiler glags.
> * Contingency deadline: Final mass rebuild.
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> The new micro-architecture baseline and the resulting requirements
> need to be documented.
>
> == Release Notes ==
> Release notes must mention how users can determine whether their
> system supports AVX2 prior to upgrading, for example by running
> grep avx2 /proc/cpuinfo.
>
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
htt

Re: are the ppc64le builders healthy?

[Dan Čermák]

Jason L Tibbitts III  writes:

>> "KK" == Kaleb Keithley  writes:
>
> KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days
> KK> ago.  Two different builds on f30 built or are building fine on
> KK> x86_64, i686, and aarch64, but failed with different errors on
> KK> ppc64le at different places in the build.  One looks like it ran out
> KK> of space in the file system. The other may have been OOM killed (?).
>
> There was just a bit of talk about this in IRC.  The issue seems to be
> that the CPU count of the PPC64le builders was bumped from 4 to 12, but
> the amount of memory was unchanged at 10GB RAM/2GB swap.  This could
> potentially cause resource exhaustion.
>
> Seems they've now been bumped to 22GB of RAM, which should help with OOM
> issues but probably not with disk space issues.

Although not directly related, but I thought I'll throw this in:
openSUSE has a handy package called memory-constraints which features a
single macro: %limit_build.

You give this macro the amount of RAM you expect
make/ninja/$my_build_cmd to consume at peak per thread and it sets the
number of jobs via overriding _smp_mflags so that you won't OOM.

Source:
https://build.opensuse.org/package/view_file/network:chromium/memory-constraints/memory-constraints.macros?expand=1

That could be useful for arches which have builders with a lot of cores
but not a lot of RAM or builds which consume excessive amounts.


Cheers,

Dan


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

Re: Debates/back and forths

[Dan Čermák]

Hi Danni,

Danny Lee  writes:

> Hi all,
>
> I'm new to the devel list and fedora in general, but i was wondering if 
> these kind of back and forths between a few people is a frequent 
> occurrence.  I came to Fedora to volunteer what little spare time I have 
> to help the Fedora project in some little ways. I don't feel that should 
> include wading through dozens of emailed back and forths between 
> individuals who seem to have strong, immovable opinions, I just don't 
> have time for that.

Welcome to the club of all the "silent" contributors!

Usually I try to follow discussions if they appear relevant or
interesting to me, but once they "tip over", I mark that thread as
deleted and mercilessly nuke everything new that comes in.
Yeah, I might miss some important information, but it's unlikely tbh
once you are 20 replies deep into a thread.
On the other hand: I don't want to spend all my free time reading
emails.

So, if you don't care about a specific topic: just ignore & delete it.


Btw, this list is imho still pretty moderate, only the occasional
controversy causes a huge thread of replies (and people manage to stay
civilized and tend to bring in new arguments). There's other lists
(unnamed to protect the guilty) where the signal to noise ratio is much,
much worse.

>
> Is there any chance there is a moderated list or discussion group about 
> current project tasks and issues rather than debates about how to do 
> things?  Or perhaps, a way to turn off certain threads or block certain 
> posters?
>
> Thanks for your time and info you can provide.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Better interactivity in low-memory situations

[Dan Čermák]

Chris Murphy  writes:

> On Mon, Aug 12, 2019 at 5:47 PM Emery Berger  wrote:
>>
>> For what it's worth, my research group attacked basically exactly this 
>> problem some time ago. We built a modified Linux kernel that we called 
>> Redline that was utterly resilient to fork bombs, malloc bombs, and so on. 
>> No process could take down the system, much less unprivileged ones. I think 
>> some of the ideas we described back then would be worth adopting / adapting 
>> today (the code is of course hopelessly out of date: we published our paper 
>> on this at OSDI 2008).
>
> I'm unable to find a concurring or dissenting opinions on this.  What
> kind of peer review has it received? Was it ever raised with upstream
> kernel developers? What were there responses?

I have only read parts of the Redline paper so I do not know if it was
ever tried to submit this upstream.

Judging from the Redline webpage
(https://emeryberger.com/research/redline/), it appears to only ever
been implemented on i386 and nowhere else (albeit that shouldn't be hard
to fix). Furthermore it does not support NUMA, which might be a bigger
blocker.

My guess is that Redline might clash with the general idea how processes
should be scheduled of upstream Linux. Redline solves the problem of
keeping interactive applications interactive even under severe memory
pressure by changing the way they are scheduled, allocated memory and
how much data they are allowed to read from disks. If an application is
classified as interactive (in contrast to best-effort tasks, which
corresponds to a process in the current Linux kernel), then it will get
a requested amount of CPU time each x ms (e.g. to be able to run at 25
fps). Something comparable is done with memory and disk usage.

This is a pretty nice approach in my opinion but it has certain
downsides:
- scheduling gets more complicated
- you need additional system calls to tell the kernel which processes
  are interactive (otherwise they are treated the "old" way and you gain
  nothing)
- you need a userspace component that has a database of interactive
  tasks (with a small set of configs, e.g. how often does your process
  need a chunk of the CPU time)

It could be that the kernel community would perceive that as a blocker
and would instead prefer a different and more generic solution (this is
just my personal guess). It could also very well be that no one had time
to actually upstream this, as it was an academic project (no offense
intended, I've been in academia myself and know how things
go).

Unfortunately, Redline was developed more than a decade ago, so
upstreaming it nowadays is probably equivalent to a full rewrite, given
the kernel's development pace.


Cheers,

Dan


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

Re: Intend to orphan i3 and some related packages

[Dan Čermák]

Christian Dersch  writes:

> Hi,
>
> I intend to orphan the packages related to i3 window manager:
>
> * i3
>
> * i3lock
>
> * i3status
>
> * i3-ipc
>

I'll take the i3 stack, since I have not yet migrated to sway
completely.

I'd be however more than happy to share the maintenance with others.

> * dzen2
>
> * dmenu
>
> Anybody here interested in taking them? Otherwise I'll orphan them on 
> Friday.
>
>
> Greetings
>
> Christian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Intend to orphan i3 and some related packages

[Dan Čermák]

Christian Dersch  writes:

> Am 04.09.19 um 12:36 schrieb Dan Čermák:
>
> Thanks! i3 packages are yours now. Are you also interested in dzen2? It 
> is required by i3.

Ugh, I was hoping that it wasn't... But in that case: yes, please give
it to me too, otherwise taking over i3 is futile.


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

Re: Orphaned packages to be retired (~400 during this week)

[Dan Čermák]

Elliott Sales de Andrade  writes:

> On Mon, 9 Sep 2019 at 18:02, David Sommerseth  wrote:
>>
>> On 09/09/2019 23:49, Miro Hrončok wrote:
>> > The following packages are orphaned and will be retired when they
>> > are orphaned for six weeks, unless someone adopts them. If you know for 
>> > sure
>> > that the package should be retired, please do so now with a proper reason:
>> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>>
>> [...snip...]
>>
>> > dsommers: python-which
>>
>> This surprises me quite a lot.  I have never been a package maintainer for
>> this package.
>>
>
> It's not saying you're a package maintainer for this package. It's
> saying you'll be affected by its orphaning.
>
> Search for python-which and you'll see it's because python-ethtool
> depends on it, and you maintain _that_.

As Jason L Tibbitts III noted on IRC, the "culprit" here is dblatex,
which depends on python2-which and since gcc depends on dblatex, that
drags in nearly everything.

There is a pretty simple short term fix for this though: dblatex
upstream has been bundling python-which for over a decade, which is
being reverted in the Fedora package. Since python-which is dead
upstream, I see it as the lesser evil to not patch the bundling. Also,
dblatex will probably go away anyway, as was noted previously on this
list (it does not appear to be dead though, there has been a bugfix
release less than an hour ago).


Cheers,

Dan


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

Re: Drop of PlayOnLinux package (Rawhide)

[Dan Čermák]

Michal Konecny  writes:

> I can recommend Lutris, it's really good and I think somebody is working 
> on flatpak version for it.

Indeed: https://github.com/flathub/net.lutris.Lutris

It's currently available on flathub-beta.


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

Re: Interest in doing Fedora CI with test subpackages

[Dan Čermák]

Hi Neil,

Neil Horman  writes:

> Hey all-
>   I was starting to setup CI for one of my packages in Fedora (cscope),
> which requires that I have access to the sources to run my test (cscope uses 
> its
> own source tree to search for various symbols to confirm that its working
> properly).  Getting the sources in the CI environment is a bit of a pain, so I
> started working on trying to do this by creating a test subpackage 
> (specifically
> named -citest) to package up the sources solely for the purpose of getting 
> them
> installed and available during CI runs.  It occured to me that this offers
> several advantages, among them:
> 1) the ability to codify dependencies within the ame spec file, rather than
> having to copy them to the test.yml file, and keep them in sync
>
> 2) The ability to use a file format (rpm spec files) that I'm more familiar 
> with
>
> 3) Easy access to tests that are embedded in the source tree

This is imho a pretty big advantage, as it ensures that the tests and
the source don't diverge.

>
> 4) minimizing the test harness setup in test.yml
>
> For anyone interested, I've got a pull request started here:
> https://src.fedoraproject.org/rpms/cscope/pull-request/2
>
> If anyone wants to take a look at the changes I had to make to do this (fair
> warning, its still very rough).
>
> That all said, I was wondering if perhaps there was general interest in making
> this kind of test model somewhat more formal (i.e. creating an rpm macro 
> library
> to make test package generation a bit easier, creating a standard entry point 
> to
> run tests, etc).

I am not sure whether a generalization makes sense, as there are so many
languages with such a wide range of test suites. What would make sense
to standardize would be the generation of a -citest subpackage though,
so that it is setup correctly and consistently.

>
> Thoughts welcome

I like this idea and you're actually not the first one ;-). Something
comparable is being done in openSUSE's Ruby RPM packages: if the gem
ships a testsuite, then a -test subpackage is created with the tests
inside it. (In practice these packages are unfortunately never used, as
they often lack the necessary dependencies to be installable and even
if, the testsuite usually doesn't run outside of bundler, but that's a
different story).

I think this approach makes especially sense for packages which ship an
extensive test suite that is not feasible to run during %check, but can
be run in the gating CI.


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

Re: Packit-as-a-Service is now live!

[Dan Čermák]

Hi Tome & the packit team!

(sorry for resurecting this old thread, I'm working through my backlog…)

As a co-maintainer of the exiv2 library, is there a way for us to use
packit that makes sense? I guess not for the master branch, as we are
currently reworking the API and will probably only cause the CI to be red
all the time. But could it work for our 0.27 maintenance branch only?
There we are backporting bugfixes only and try not to break the API, but
have currently no way of really checking that (bonus points if packit
includes a rebuild+retest of packages depending on exiv2).


Cheers,

Dan

Tomas Tomecek  writes:

> We are happy to announce the availability of Packit-as-a-Service [1],
> a GitHub App, which utilizes the Packit project [2].
>
> Using the Packit service in your upstream projects helps you
> continuously ensure that your projects work in Fedora OS. Just add one
> config file [3] to your repository, along with the RPM spec file and
> you're almost there. We have started publishing docs for the service
> over here [4].
>
> In the next couple of months, Packit Service will run in an
> invite-only mode, where we need to manually approve every user of the
> app. Our initial target is Fedora contributors.
>
> Packit service validates your pull requests by building your software
> in Fedora OS. Once the builds are done, Packit lets you know how to
> install the RPM with the change inside your environment.
> Packit service helps you test the changes before merging them to the
> main developer branch and shipping them to your users.
>
> Happy hacking!
> The packit team
>
> [1] https://github.com/apps/packit-as-a-service/
> [2] https://packit.dev/
> [3] https://github.com/packit-service/packit/blob/master/docs/configuration.md
> [4] https://packit.dev/packit-as-a-service/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: specfile dependecy to pip package

[Dan Čermák]

Hi Marek,

Marek Tamaskovic  writes:

>  Hi,
> I'm maintainer of libcbor package and in fedora 30 has been removed
> python3-sphinx package which is required to build documentation for
> libcbor. I can changa the dependency to python2-sphinx but thats not what I
> really want to do. Another option is to install sphinx via pip3.

You cannot/should not install packages via pip during rpmbuild as mock &
koji don't allow network connections (at least by default).

> However in build phase it will show an error which says:
>
> sphinx-build -b man -d build/doctrees   source build/man
> Traceback (most recent call last):
>   File "/usr/local/bin/sphinx-build", line 6, in 
> from sphinx.cmd.build import main
> ModuleNotFoundError: No module named 'sphinx'
> make: *** [Makefile:131: man] Error 1
>
> (it needs breathe package and that is installed as well using pip3)
>
> Now I have two questions:
>
> 1. How can I write to specfile that I need a pip package?
> I tried:
>
> BuildRequires: %{py3_dist Sphinx} >= 2.2.0
>
> And as well:
>
> BuildRequires: %{py3_dist sphinx} >= 2.2.0
>
> Both of those will show an dependency error even when I install sphinx
> and breathe using pip3:
>
> python3dist(sphinx) >= 2.2.0 is needed by libcbor-0.5.0-5.fc30.x86_64
>

In Fedora 30 there is only Sphinx 1.8.4, so you'll have to patch your
package to work with an older version of sphinx.

>
> 2. How to fix that error from sphinx-build?
> I tried to install even sphinx-multibuild (using pip) but did not succeed.
> It is suspicious that sphinx package need sphinx and it can not find it.
>
> Regards,
> Marek Tamaskovic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Defining the future of the packager workflow in Fedora

[Dan Čermák]

Daniel P. Berrangé  writes:

> On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
>
> For packages I maintain, my preference is to touch dist-git as little
> as possible. Ideally I would never touch dist-git at all & rather wish
> it didn't exist at all in its current form of spec+patchfiles.
>
> Instead I prefer a clone of the master upstream git repo and maintain a
> branch with patches cherry-picked into it. This is used to auto-generate
> patches for the Fedora RPM, at the same time updating the patch file list
> in the RPM spec. The only manual step is adding the changelog entry &
> bumping release number.

As others have said already: this is a nice idea and I definitely would
see myself using it for one package (there I have a bunch of
non-upstream patches), but not for most of them, so having this as an
option would be pretty cool.

BUT (and that is a very big but) this is very dangerous and makes
patching just far too easy and far too tempting. If you can add a new
non-upstream patch with a simple `git commit` and be done with it, then
there's very little incentive to upstream these. Patching of packages
*should* be hard to a certain extent, it even needs to be a PITA so that
you want to get rid of that patch and upstream it. Because if you don't,
you end up with hundreds of non-upstream patches that will become a huge
burden down the road. (This is the worst case scenario and not something
against you Daniel, but I've seen it happen already.)

Thus, unless there is some kind of additional review/check/person
telling you "Stop patching downstream!", I would only allow packagers to
use the source git option with FESCO's or the packaging committee's
approval.


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

Re: Defining the future of the packager workflow in Fedora

[Dan Čermák]

Randy Barlow  writes:

> This suggestion gives a nice clean place to write the bodhi update
> description, right in git. The commit messages can remain the way they
> are today: authored for the audience of spec file contributors.
>
> We could also support special syntax in the tag message to allow people
> to specify the various bodhi update fields (severity, karma
> requirements, whatever else) if they want to do that that way.

I *really* like this idea, as one could still push multiple
"development" commits to git, but until one tags something, nothing is
built & released.


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

Re: Defining the future of the packager workflow in Fedora

[Dan Čermák]

Christopher  writes:

> I just don't see this proposed workflow as solving the biggest
> problems that packagers face. For me, I think the biggest problem that
> packagers (particularly newer packagers) face is discovery of all the
> services involved in the packaging workflow, and the need to visit
> separate UIs to get answers.
>
> Rather than try to automate the workflow through these separate
> services, I'd rather work be done to create a central packager
> interface that helps packagers track where a package is in the
> workflow, and to facilitate moving from one phase to the next. For
> example, an interface could show something like a list of branches for
> a package, and whether there is a corresponding build from those
> branches. A button to the right of each branch could be shown which
> does the equivalent of `fedpkg build` on that branch (grayed out if
> there exists a build already for that commit and branch), and then
> another column with a similar button to create an update.
>
> In addition to helping the packager move a package through the
> workflow, such a centralized interface would also provide information
> about dependencies, their orphan/retired status, whether they've
> changed since the last build. It could also show a listing of bug
> reports, help maintain co-maintainer privileges, and other similar
> stuff. Basically, everything the packager needs in one place.
>
> I think such an interface would be far more useful, just to document
> the existing workflow, and help packagers know what to do, than trying
> to change the workflow and automate it. We shouldn't be looking at
> disruptive changes to the workflow... we should be looking at lowering
> the bar to packaging by making it easier to manage the current
> workflow. And then, if we find that there are changes to the workflow
> itself, we do that later, with corresponding changes to the
> centralized interface.

What you want is essentially the Open Build Service
(https://build.opensuse.org/), just for Fedora.

And yes, having something like that would be *really* good, especially
having all the overviews, build states, updates, dependencies, etc. in
one single place.

The only danger in this is, that this overview app can grow into a huge
monolith, that becomes impossible to extend at some point because it
swallowed all the functionality of our individual infra and became too
complex... But that can be avoided, if it is "just" an overview and the
rest stays the way it is.


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

Re: Orphaned packages looking for new maintainers

[Dan Čermák]

"Richard W.M. Jones"  writes:

> On Tue, Dec 24, 2019 at 09:09:26AM -0800, Jerry James wrote:
>> Pardon the top posting. I am on the road with only my phone, no Fedora
>> devices anywhere. I have been thinking about trying to get Facebook's Infer
>> tool into Fedora. Several of its dependencies are on this list, but I won't
>> be able to take them until I get home, after they are retired.  The ocaml
>> packages, at least, have some serious dependency issues, as I recall, but I
>> would like to see if they can be fixed.  Can someone please assign the
>> following packages to me?  After I return I will fix them if I can & retire
>> them if I cannot.
>> 
>> jackson
>
> For these packages:
>
>> ocaml-bin-prot
>> ocaml-deriving
>> ocaml-sexplib
>
> I orphaned them because the upstream versions we were using depended
> on camlp4.  There are newer upstream versions but they had quite
> different requirements (being basically rewritten in at least the case
> of Deriving).
>
> Anyway in the meantime all 3 packages were taken by Dan Čermák
> (https://src.fedoraproject.org/user/defolos/projects).

That is correct, however I will probably orphan ocaml-deriving and
ocaml-sexplib very soon because we only need ocaml-bin-prot for infer
and I have no need for the other two packages.

However, ocaml-bin-prot was also rewritten and went through 2 versioning
changes in the meantime resulting in the current latest version being
smaller than the current version in Fedora. This will probably cause all
kinds of funny problems if I try to submit an update with a smaller
NEVRA :(


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

Re: Let's talk about Fedora in the '20s!

[Dan Čermák]

Tom Hughes  writes:

> On 07/01/2020 12:22, Miroslav Suchý wrote:
>> Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
>>> The thing is that no matter how much you can manage to automate the
>>> creation of spec files for a given ecosystem, and I've never seen one
>>> where the typical spec file doesn't need some manual tweaking, you
>>> are still going to hit the fundamental problem that those specs then
>>> need to be reviewed.
>> 
>> I disagree.
>> Especially with libraries - be it python, gems... it can be very well 
>> automated without the need for review.
>
> Well that depends on the reason for the review, doesn't it?
>
> Just to take a few things, how does automation check that the license
> declared in the upstream metadata is correct?

openSUSE actually has a bot for exactly this in the Open Build Service
(it's not perfect of course, but it takes a good chunk of the legal
review burden from humans): https://github.com/openSUSE/cavil. Iirc Neal
has been trying to get it into Fedora.


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

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

Felix Schwarz  writes:

> Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>> I totally agree with Fabio, I can’t think of a single reason we should 
>> dismiss
>> pagure.
>
> Gitlab is used by many free software communities like Freedesktop, Gnome,
> Debian. Using the same tools could help to facilitate
> inter-process/inter-distro collaboration.
>
> Personally I guess github would attract most contributions for Fedora from new
> contributors but it is closed source so I'd prefer gitlab for Fedora. (Though
> I somehow got used to pagure and getting the gitlab integration to the same
> level as pagure currently will be a lot of work for sure.)

On top of that Gitlab is a huge Ruby on Rails application and (at least
I have the feeling that) the Fedora community doesn't have so many Ruby
developers in comparison to Python developers, so implementing something
comparable could be challenging let alone from the manpower point of
view.
And then there's the issue that we are not upstream and might have to
maintain the integration as a downstream patch forever as upstream might
not want it.


Cheers,

Dan


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

Re: Ideas for better development processes when maintaining hundreds of packages

[Dan Čermák]

"Richard W.M. Jones"  writes:

> I always think that Fedora works fine if you maintain 1-5 packages.
> It's possible to maintain 20 with a lot of work.  And if you want to
> maintain 100+ (things like the ocaml-* set that I help to maintain)
> then you have to write your own automation.  Could we do things
> better?  No one asked for them, but here are my ideas ...
>
> ---
>
> * kill the %changelog
>
> Please, let's kill it, and generate it from the git changelog.
> I'm glad to see there's a proposal to do this.
>
> A general principle I'm following here is a packager should never
> be asked to enter the same information twice.
>
> * committing to git should build the package
>
> Is there a reason why this wouldn't be the case?

Not really no. I've been involved quite a bit in building packages on
openSUSE's Buildservice and every commit there results in a rebuild. So it
is doable, *but* OBS has the advantage that it discards all builds
except for the most recent successful one, or it would have run out of
storage ages ago.

Although someone (Randy Barlow maybe?) had the idea to generate the
changelog and to trigger builds from git tags instead of commits, which
has a certain charm to it as well. If there was a choice whether to
trigger builds from commits or tags and how to generate the %changelog,
then I think that most use cases should be covered?

>
> * commit groups of packages together
>
> One reason why automatic commit -> build might not be desirable is if
> you're trying to build a group of packages in a side tag.  In my
> opinion this means we should allow groups of packages to be committed
> together.  (Unfortunately because we chose to put every package in its
> own git repo, the obvious way to do this can't work, but we could
> still have a "ChangeId:" header in the commit message that ties
> packages together).
>
> The packages should be built in build dependency order into a side
> tag, and the side tag turned into an update, with no further
> involvement from the packager unless something fails to build.
>
> This change on its own would solve the main problem that
> affects people maintaining large sets of packages.

How about something like `fedpkg add-to-side-tag` (yes the name needs
work) that would work like this:

$ fedpkg request-side-tag
$ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob

Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in
them being built in the side tag $tag_name by default. Once the side tag
is merged, you go back to building the "ordinary way".

>
> * “Fixes:” etc headers in git
>
> RHEL already does this.  It should be possible to add special headers
> to the commit message to automatically close bugs, ie:
>
>   $ git commit -m "ocaml: Update to version 4.10.0
>   Fixes: RHBZ#12345"
>
> Note the build, update and bug closing would happen completely
> automatically, assuming there was no build or test failure.

+1 on this one.

>
> * CVE bugs should autoclose when a package is rebased

I don't think this is a good idea as you should actually check that this
update fixes the CVE.


Cheers,

Dan


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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Dan Čermák]

Neal Gompa  writes:

> On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon  
> wrote:
>>
>> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
>> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon  
>> > wrote:
>> > >
>> > >
>> > > The release field would need to be set by koji ignoring whatever is in 
>> > > the spec
>> > > file. How do we want to do this?
>> > >   - Based on dates?
>> > >   - Using an always increasing integer?
>> > >   - Using the number of successful builds since the last time the 
>> > > version field changed?
>> > >   - Another idea?
>> > >
>> > > The third option looks like to be the one closest to our current 
>> > > behavior.
>> > >
>> >
>> > I always envisioned that we'd use a variant of the third option.
>> >
>> > The options I've thought of:
>> >
>> > * %{dist}.
>> > * .%{?dist}
>> > * %{dist}..
>>
>> I've been thinking a bit about this and been wondering any reason why not to 
>> do
>> simply?
>>%{dist}
>>
>> This would basically mimic what we are currently doing by hand, it would be 
>> the
>> less changes to our current way of working (making opting-in smoother).
>>
>
> If we're not doing automatic builds, sure. I've been going on two big
> assumptions:
>
> 1. We're going to do automatic building
> 2. We need *some* kind of stable leading portion of release for
> packagers to use for specified dependencies, especially
> Obsoletes+Provides combos.

How is openSUSE taking care of 2 then? OBS bumps the release on each
rebuild and that can result in crazily high release numbers. I assume
they got a mechanism for Obsoletes+Provides and we could use that too?


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

Re: Ideas for better development processes when maintaining hundreds of packages

[Dan Čermák]

Pierre-Yves Chibon  writes:

> On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote:
>> "Richard W.M. Jones"  writes:
>> 
>> > I always think that Fedora works fine if you maintain 1-5 packages.
>> > It's possible to maintain 20 with a lot of work.  And if you want to
>> > maintain 100+ (things like the ocaml-* set that I help to maintain)
>> > then you have to write your own automation.  Could we do things
>> > better?  No one asked for them, but here are my ideas ...
>> >
>> > ---
>> >
>> > * kill the %changelog
>> >
>> > Please, let's kill it, and generate it from the git changelog.
>> > I'm glad to see there's a proposal to do this.
>> >
>> > A general principle I'm following here is a packager should never
>> > be asked to enter the same information twice.
>> >
>> > * committing to git should build the package
>> >
>> > Is there a reason why this wouldn't be the case?
>> 
>> Not really no. I've been involved quite a bit in building packages on
>> openSUSE's Buildservice and every commit there results in a rebuild. So it
>> is doable, *but* OBS has the advantage that it discards all builds
>> except for the most recent successful one, or it would have run out of
>> storage ages ago.
>> 
>> Although someone (Randy Barlow maybe?) had the idea to generate the
>> changelog and to trigger builds from git tags instead of commits, which
>> has a certain charm to it as well. If there was a choice whether to
>> trigger builds from commits or tags and how to generate the %changelog,
>> then I think that most use cases should be covered?
>
> The original idea of using git tag is Jeremy Cline's.
> If we support: automatically building from commit or not, then I don't think 
> we
> need to support building from git tag, using the current approach would work
> just as well when you don't want to build from commit.

Building from a git tag would have the advantage, that each build would
show up on pagure under the "Releases" tab, albeit that is probably just
a cosmetic advantage.

>
>> > * commit groups of packages together
>> >
>> > One reason why automatic commit -> build might not be desirable is if
>> > you're trying to build a group of packages in a side tag.  In my
>> > opinion this means we should allow groups of packages to be committed
>> > together.  (Unfortunately because we chose to put every package in its
>> > own git repo, the obvious way to do this can't work, but we could
>> > still have a "ChangeId:" header in the commit message that ties
>> > packages together).
>> >
>> > The packages should be built in build dependency order into a side
>> > tag, and the side tag turned into an update, with no further
>> > involvement from the packager unless something fails to build.
>> >
>> > This change on its own would solve the main problem that
>> > affects people maintaining large sets of packages.
>> 
>> How about something like `fedpkg add-to-side-tag` (yes the name needs
>> work) that would work like this:
>> 
>> $ fedpkg request-side-tag
>> $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob
>> 
>> Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in
>> them being built in the side tag $tag_name by default. Once the side tag
>> is merged, you go back to building the "ordinary way".
>
> Isn't that just fedpkg chain-build --target=$tag_name ... ?

Could be, I've never used it.

> This is already existing and working, however, it requires the different
> packages are up to date in git (ie: you've made and push the commit updating 
> the
> spec file to the next release/version) which goes against the point above 
> about
> automatically build on commit.

Well, my idea was that you tell the infra: "hey, from this point onward
(until the side tag is merged or I turn it off), I want every commit to
be built in the side tag".


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

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

Rahul Sundaram  writes:

> Hi
>
> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>
>>
>> Welcome to our lives!
>> If it was mathematically possible to go above 100% that's how much
>> agreement you
>> would have from us.
>>
>
> If Red Hat is using Pagure internally, it is really odd to discuss
> replacing Pagure with something else.  The only viable replacement is
> Gitlab which is a open code project written in a language that isn't a
> strong fit for Fedora. Red Hat should be assigning more resources
> (development & infrastructure) to add the features needed to extend Pagure
> going forward and reduce the burden on the CPE team.  Has CPE leadership
> considered talking internally about that?

I have to second this: why are we even *having* this discussion, when
Pagure is used internally at RedHat and thus RedHat will require some
form of maintenance anyway? Why is then the RedHat CPE team pushing to
move away from Pagure, especially to Gitlab? Which albeit being a great
platform, is written in Ruby and there's a lot less Ruby devs in the
Fedora community than Python devs.

Imho it would be a good idea that Pagure is not retired and is developed
further, as it is currently one of its kind in many aspects and can be
fully tweaked and customized to our needs without being huge in the way
gitlab is.


Cheers,

Dan


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

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

Dan Čermák  writes:

> Rahul Sundaram  writes:
>
>> Hi
>>
>> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>>
>>>
>>> Welcome to our lives!
>>> If it was mathematically possible to go above 100% that's how much
>>> agreement you
>>> would have from us.
>>>
>>
>> If Red Hat is using Pagure internally, it is really odd to discuss
>> replacing Pagure with something else.  The only viable replacement is
>> Gitlab which is a open code project written in a language that isn't a
>> strong fit for Fedora. Red Hat should be assigning more resources
>> (development & infrastructure) to add the features needed to extend Pagure
>> going forward and reduce the burden on the CPE team.  Has CPE leadership
>> considered talking internally about that?
>
> I have to second this: why are we even *having* this discussion, when
> Pagure is used internally at RedHat and thus RedHat will require some
> form of maintenance anyway? Why is then the RedHat CPE team pushing to
> move away from Pagure, especially to Gitlab? Which albeit being a great
> platform, is written in Ruby and there's a lot less Ruby devs in the
> Fedora community than Python devs.

I have to apologize, this was far too harsh. What I wanted to say is the
following: wouldn't it be mutually beneficial for RedHat, Fedora and
specifically the CPE Team too, that someone¹ takes over maintenance of
Pagure since it's used by us all and there appear to be enough people
that want to continue using it?


Cheers,

Dan

¹: Yeah, I know that this is actually the tricky part to find this
someone…


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

Re: Self Introduction: Aleksei Bavshin

[Dan Čermák]

Welcome to Fedora and to the Say SIG Aleksei!


Cheers,

Dan

Aleksei Bavshin  writes:

> Hi all,
>
> My name is Aleksei and I'm Russian living in the San Franciso Bay
> Area. I've been using Linux at home since 2003 and developing
> closed-source Linux software for my daytime jobs over the last decade.
> I started with Mandrake 9, tried ALT, spent a few years with Slackware
> and finally ended my pursuit of a perfect distro on Fedora 9
> (Sulphur). Been using and promoting Fedora ever since; Linux users
> from Tomsk, Russia may still remember my efforts on keeping a mirror
> of Fedora repository in a city intranet and packaging small things
> missing in official repos.
>
> I'm also a fan of tiling window managers; have been using xmonad and
> awesome wm for a while until certain hardware issue made me switch to
> wayland. Nowadays my main wm is sway, and I'm joining Fedora to make
> contribution to sway ecosystem. My first package will be waybar, which
> I'm finally moving from copr to the main Fedora repository. Afterwards
> I'll be looking for other missing bits that would help sway users.
>
> Looking forward to doing something for my favorite Linux distribution.
> -- 
> With best regards,
> Aleksei Bavshin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Guile exception caught in /usr/lib/rpm/find-debuginfo.sh

[Dan Čermák]

Hi list,

I've just ran a mockbuild in Rawhide and the following output from
/usr/lib/rpm/find-debuginfo.sh caught my attention:

--8<---cut here---start->8---
/usr/lib/rpm/find-debuginfo.sh -j2 --strict-build-id -m -i --build-id-seed 
1.3-1.fc32 --unique-debug-suffix -1.3-1.fc32.x86_64 --unique-debug-src-base 
ocaml-ppxfind-1.3-1.fc32.x86_64 --run-dwz --dwz-low-mem-die-limit 1000 
--dwz-max-die-limit 11000 -S debugsourcefiles.list 
/builddir/build/BUILD/ppxfind-1.3
explicitly decompress any DWARF compressed ELF sections in 
/builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind
extracting debug info from 
/builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind
Exception caught while booting Guile.

/usr/bin/gdb.minimal: warning: Could not complete Guile gdb module 
initialization from:
/usr/share/gdb/guile/gdb/boot.scm.
Limited Guile support is available.
Suggest passing --data-directory=/path/to/gdb/data-directory.
--8<---cut here---end--->8---

Is this known/an issue?


Thanks in advance,

Dan

P.S.: I really hope this isn't my fault, as I've re-enabled Guile
support in gdb :-(


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

Re: CMake could not find Boost components

[Dan Čermák]

Hi Iñaki,

not exactly what you are looking for, but I have recently packaged
rstudio at $dayjob for openSUSE and recall that we had to do some
fiddling around with boost. You can find the package here:
https://build.opensuse.org/package/show/devel:languages:R:released/rstudio

More specifically, take a look at the first patch:
0001-First-pass-at-Boost-1.70-support.patch and check out the cmake
invocation in the spec:
%cmake -DRSTUDIO_TARGET=Desktop -DRSTUDIO_SERVER=TRUE 
-DCMAKE_BUILD_TYPE=Release -DRSTUDIO_BOOST_SIGNALS_VERSION=2 
-DCMAKE_INSTALL_PREFIX=%{_libexecdir}/%{name}


Hope this helps,

Dan

P.S.: if you manage to unbundle gin and gwt, please ping me, I'd love to
carry that over to openSUSE.

Iñaki Ucar  writes:

> Hi,
>
> CMake finds Boost, but then fails to find its components. Here's the
> log with -DBoost_DEBUG=1:
> https://download.copr.fedorainfracloud.org/results/iucar/rstudio/fedora-31-x86_64/01235199-rstudio/builder-live.log
>
> Is there anything special I should do for cmake to find them? Any help
> would be appreciated.
>
> Regards,
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Ideas and proposal for removing changelog and release fields from spec file

[Dan Čermák]

Hi list,

Stephen John Smoogen  writes:

> On Mon, 24 Feb 2020 at 11:50, Pierre-Yves Chibon 
> wrote:
>
>> Good Morning Everyone,
>>
>> This topic has already been discussed a few times over the past month, but
>> Adam
>> Saleh, Nils Philippsen and myself have had the opportunity to invest some
>> time
>> on it with the hope of making the packager's life simpler as well as
>> making it
>> easier to build automation around our package maintenance.
>>
>
>
> Going through the various discussions, I think we are running into a
> classic sausage factory problem.. everyone wants to have their favourite
> meat, but the only way to make it work is mix them all together, grind it
> up and come up with something else.

I have to agree with Stephen here. As someone who has been heavily
involved in building packages on OBS, where the Release field is
generated automatically by the build server: I don't see a problem in
automatically generating the release field, I would actually very much
welcome it. But then none of my packages fall into the "Beaufort D'Ete"
category, so I might be missing something here.

For the changelog: yes please, generate it from the commit log! They are
more or less the same for all my packages and I'm getting tired of copy
pasting the same text into %changelog and git commit.


Cheers,

Dan


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

Re: Donate 1 minute of your time to test upgrades from F31 to F32

[Dan Čermák]

Miroslav Suchý  writes:

> Do you want to make Fedora 32 better? Please spend 1 minute of your time and 
> try to run:
>
>   # Run this only if you use default Fedora modules
>   # next time you run any DNF command default modules will be enabled again
>   sudo dnf module reset '*'
>
>   sudo dnf --releasever=32 --setopt=module_platform_id=platform:f32 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
>
> This command does not replace `dnf system-upgrade`, but it will reveal 
> potential problems. You may also run `dnf
> upgrade` before running this command.
>
>
> If you get this prompt:
>
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
>
> you can answer N and nothing happens, no need to test the actual
> upgrade.

Ran into some issues with zypper:
Error:
 Problem 1: problem with installed package zypper-1.14.33-1.fc31.x86_64
  - zypper-1.14.33-1.fc31.x86_64 does not belong to a distupgrade repository
  - nothing provides libzypp.so.1712()(64bit) needed by 
zypper-1.14.32-1.fc32.x86_64
  - nothing provides libzypp.so.1712(ZYPP_plain)(64bit) needed by 
zypper-1.14.32-1.fc32.x86_64
 Problem 2: problem with installed package zypper-log-1.14.33-1.fc31.noarch
  - package zypper-log-1.14.32-1.fc32.noarch requires zypper = 1.14.32-1.fc32, 
but none of the providers can be installed
  - zypper-log-1.14.33-1.fc31.noarch does not belong to a distupgrade repository
  - nothing provides libzypp.so.1712()(64bit) needed by 
zypper-1.14.32-1.fc32.x86_64
  - nothing provides libzypp.so.1712(ZYPP_plain)(64bit) needed by 
zypper-1.14.32-1.fc32.x86_64


Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1810320


Cheers,

Dan


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

How to fix a dependency to the version at build time?

[Dan Čermák]

Hi list,

I have recently received a bug report for my package ccls, that it
currently fails in certain cases, because it hard codes the paths to
/lib64/clang/$CLANG_VERSION for autocompletion at build time.

This means that I need to make ccls depend on the *exact* clang version
which was available when it was build.

What is the best approach for that?

I know that there is the %requires_eq macro, but afaik it also fixes the
release, which would be overkill in my case.
I have tried this "hack":

Requires: clang = %(rpm -q --qf '%%{version}' clang)

which appears to do the right thing (TM).


However, I am not an expert on RPM macro evaluation and kinda worried
that this uses the clang version that is present on the system building
the srpm, which might not be the version that I want? Or is this not a
problem on Koji?


Thanks in advance,

Dan


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

Re: Stalled Review Request - Close it and create new?

[Dan Čermák]

Afaik the recommendation (at least for maintainers not responding to
bugreports) is to wait at least two weeks (in case someone is on
vacation), so I'd maybe wait at least until the end of the week before
taking further action.

"Andrew Bauer"  writes:

> Recently I began to create a review request for netatalk, when I noticed 
> there already was an open review request:
> https://bugzilla.redhat.com/show_bug.cgi?id=1520024
>
> May 7th was the last activity by anyone other than myself. On 11/28 I offered 
> assistance to help move the review along, but I have not received an answer. 
>
> In the interested of getting this review completed, am I in my right to close 
> this request and create a new one, or is there better course of action? 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Package bear got mixed with bear-factory, erlang-bear and bear-devel

[Dan Čermák]

Hi list,

I have discovered a very weird problem with the package bear on
apps.fedoraproject.org: it got somehow mixed with the (completely
unrelated) packages erlang-bear, bear-devel and bear-factory.

A little bit of background:
- bear is a new package (for which I am the maintainer)
- previously the name was taken by a game engine, which its maintainer
  kindly renamed to bear-factory
- bear-devel are afaik the development files of the game engine before
  it got renamed to bear-factory
- erlang-bear has nothing to do with the other packages, beside sharing
  a part of the name

A few days ago I requested bear to be unorphaned and assigned to me,
which has happened. I have imported the sources successfully and
triggered a build on rawhide.
However, the system registered that as a build of erlang-bear (but
called it just "bear"), which means that I probably just broke the
updates of erlang-bear on Rawhide (sorry!).

My actual question: what is going on? How do I get out of this mess?


Thanks in advance,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages need new maintainers (will be retired in 1 week)

[Dan Čermák]

I would take over doclifter.

Miro Hrončok  writes:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the 
> affected packages or a package that depends on one. Please adopt the 
> affected package or retire your depending package to avoid broken 
> dependencies, otherwise your package will be retired when the affected 
> package gets retired.
>
> Unorphan or unretire packages at https://pagure.io/releng/issues
>
> Full breakdown of dependent packages is at:
>
> https://churchyard.fedorapeople.org/orphans.txt
>
> Note: This procedure is now restarted and I will start retiring packages 
> that have been orphaned for 6+ weeks in 1 week from now, will be sending 
> e-mails like this each week. Each package will be announced at least 3 
> times before retirement.
> (The backlog should be done in a week, I will then pause for the holiday 
> season).
>
> Full list from two weeks ago is preserved at:
>
> https://churchyard.fedorapeople.org/orphans-1w.txt
> https://churchyard.fedorapeople.org/orphans-2w.txt
>
> Orphaned packages:
>
> Canna orphan 57 weeks ago
> NetPIPE cicku, fale, orphan 61 weeks ago
> OpenTK orphan 27 weeks ago
> PyXB lef, mmahut, orphan 10 weeks ago
> Pyrex alexl, caolanm, johnp, orphan, rhughes, rstrode, ssp 10 weeks ago
> Quake2 orphan 71 weeks ago
> RepetierHost orphan 27 weeks ago
> VLGothic-fonts orphan 71 weeks ago
> adonthell orphan 33 weeks ago
> aldusleaf-crimson-text-fonts i18n-team, orphan 21 weeks ago
> almas-mongolian-title-fonts orphan 71 weeks ago
> apigen orphan 44 weeks ago
> archimedes chitlesh, orphan 8 weeks ago
> ascii-design cicku, fale, orphan 61 weeks ago
> ath_info orphan 42 weeks ago
> aws-shell fale, orphan 64 weeks ago
> balloontip orphan 49 weeks ago
> bluecove orphan 2 weeks ago
> blueman orphan 2 weeks ago
> bonesi cicku, fale, orphan 61 weeks ago
> bouml orphan, raphgro 0 weeks ago
> bouml-doc orphan, raphgro 0 weeks ago
> brightnessctl fale, orphan 64 weeks ago
> cclive orphan 62 weeks ago
> cdm orphan 71 weeks ago
> cf-sorts-mill-goudy-fonts orphan 71 weeks ago
> doclifter mariobl, orphan 47 weeks ago
> dojo orphan 17 weeks ago
> dreamchess-tools orphan 21 weeks ago
> eclipse-xpand orphan 22 weeks ago
> eclipse-xtext orphan 22 weeks ago
> eclipse-xtext-antlr-generator eclipse-sig, mbooth, orphan 22 weeks ago
> ecryptfs-simple orphan, raphgro 0 weeks ago
> editarea orphan 62 weeks ago
> emacs-mew orphan 26 weeks ago
> emacs-verilog-mode chitlesh, orphan 8 weeks ago
> evopop-gtk-theme orphan 26 weeks ago
> evopop-icon-theme orphan 26 weeks ago
> exonerate orphan 10 weeks ago
> f2py orphan 71 weeks ago
> fbset orphan 71 weeks ago
> fedora-review-plugin-java msrb, orphan 11 weeks ago
> fotowall orphan 71 weeks ago
> fped chitlesh, orphan 8 weeks ago
> freehdl chitlesh, orphan 8 weeks ago
> freehoo orphan 71 weeks ago
> freemind orphan 9 weeks ago
> frepple orphan 71 weeks ago
> gaim-gadugadu orphan 71 weeks ago
> gausssum cicku, orphan 58 weeks ago
> gds2pov chitlesh, orphan 8 weeks ago
> geda-gaf chitlesh, orphan 8 weeks ago
> ghc-fgl orphan, petersen 61 weeks ago
> ghc-hgettext orphan, pwithnall 48 weeks ago
> ghc-pcap orphan, pwithnall 48 weeks ago
> ghc-setlocale orphan, pwithnall 48 weeks ago
> git-bugzilla orphan 38 weeks ago
> gmusicbrowser orphan 38 weeks ago
> gnome-pie orphan 17 weeks ago
> gnome-shell-extension-calc orphan 62 weeks ago
> gnome-shell-extension-fedmsg orphan 62 weeks ago
> gnu-smalltalk laxathom, orphan, s4504kr 10 weeks ago
> gnudiff orphan 49 weeks ago
> gobby orphan 71 weeks ago
> golang-github-AudriusButkevicius-kcp-go go-sig, jchaloup, orphan 7 weeks ago
> golang-github-AudriusButkevicius-pfilter go-sig, orphan 7 weeks ago
> golang-github-calmh-luhn go-sig, jchaloup, orphan 7 weeks ago
> golang-github-ccding-go-stun go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-b go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-fileutil go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-golex go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-internal go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-lex go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-lexer go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-lldb go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-mathutil go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-ql go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-sortutil go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-strutil go-sig, jchaloup, orphan 7 weeks ago
> golang-github-cznic-zappy go-sig, jchaloup, orphan 7 weeks ago
> golang-github-docopt-docopt-go orphan 26 weeks ago
> golang-github-edsrzf-mmap-go go-sig, jchaloup, orp

Re: Fw: Re: OUTAGE: Koji system 2019-01-11 -> 2019-01-14

[Dan Čermák]

Neal Gompa  writes:

>
> * Buildbot (Python 3)
> * Jenkins (Java)
> * Vespene (Python 3)

Just FYI: vespene has been recently discontinued:
https://medium.com/@michaeldehaan/discontinuing-vespene-17fd9c0f3079

(also iirc it was licensed under Apache license + commons clause, which
would make inclusion in Fedora problematic, but that's no longer of
concern anyway)

> * GoCD (Java + Ruby)
> * Zuul (Python)
>
> Of the four listed above, only the first two are packaged in Fedora.
> Buildbot is up-to-date in Fedora, but Jenkins lags behind considerably
> and needs love.
>


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: package managemt symlink

[Dan Čermák]

Hi Sören,

while I don't want to discourage you in your work, symlinking the
package manager to /usr/bin/nimue isn't going to solve a more
fundamental issue: every distro has a different naming scheme for
packages. Sure, the "big" programs (Firefox for instance) have usually
the name you'd expect, but with libraries this won't help at all.

Practical example: I want to install the development version of
expat:
Fedora & CentOS: expat-devel
Debian & Ubuntu: libexpat1-dev
OpenSUSE: libexpat-devel
Arch: expat
Alpine: expat-dev

Solving this is next to impossible, unless you want to enumerate
**every** single package of **every** supported distro manually.


Cheers,

Dan

Valor Naram  writes:

> Dear Fedora mailing list community,
>
> I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will 
> help to make linux more user friendly.
>
> A short introduction to "goeasyLinux" can be found at 
> https://github.com/ValorNaram/goeasylinux/blob/master/README.md
>
> The specification I wrote in order to make a cross platform symlink to 
> package management systems: 
> https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md
>
> With your help I want to make package installing/removing equal on all linux 
> systems without disturbing the diversity we have across linux distributions. 
> In order to do that we need just a symlink, no replacement of existing 
> software.
>
> I think you did something similar in the past.
>
> Best wishes
>
> Sören alias Valor Naram
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: package managemt symlink

[Dan Čermák]

Vít Ondruch  writes:

> Dne 05. 02. 19 v 11:09 Dan Čermák napsal(a):
>> Hi Sören,
>>
>> while I don't want to discourage you in your work, symlinking the
>> package manager to /usr/bin/nimue isn't going to solve a more
>> fundamental issue: every distro has a different naming scheme for
>> packages. Sure, the "big" programs (Firefox for instance) have usually
>> the name you'd expect, but with libraries this won't help at all.
>>
>> Practical example: I want to install the development version of
>> expat:
>> Fedora & CentOS: expat-devel
>> Debian & Ubuntu: libexpat1-dev
>> OpenSUSE: libexpat-devel
>> Arch: expat
>> Alpine: expat-dev
>>
>> Solving this is next to impossible, unless you want to enumerate
>> **every** single package of **every** supported distro manually.
>
>
> Surprisingly, I believe that release-monitoring.org could help with
> this, since there is upstream project mapping vs the distribution name
> mapping. IDK if there could be better source for this.

Sure, if everyone would participate it could solve this issue. But
reusing my above example expat:
https://release-monitoring.org/project/770/
Unfortunately only Alpine, Arch and Fedora are listed.

And it looks like release-monitoring.org doesn't track the name of the
libraries (which are probably subpackages).

Nevertheless, release-monitoring.org could solve this issue.

>
>
> Vít
>
>
>>
>>
>> Cheers,
>>
>> Dan
>>
>> Valor Naram  writes:
>>
>>> Dear Fedora mailing list community,
>>>
>>> I am Sören alias Valor Naram and I founded the project "goeasyLinux". I 
>>> will help to make linux more user friendly.
>>>
>>> A short introduction to "goeasyLinux" can be found at 
>>> https://github.com/ValorNaram/goeasylinux/blob/master/README.md
>>>
>>> The specification I wrote in order to make a cross platform symlink to 
>>> package management systems: 
>>> https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md
>>>
>>> With your help I want to make package installing/removing equal on all 
>>> linux systems without disturbing the diversity we have across linux 
>>> distributions. In order to do that we need just a symlink, no replacement 
>>> of existing software.
>>>
>>> I think you did something similar in the past.
>>>
>>> Best wishes
>>>
>>> Sören alias Valor Naram
>>>
>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: package management symlink

[Dan Čermák]

Valor Naram  writes:

>> Also what you suggest already exists, for example in the form of
>> "pacapt" (but there are alternatives too!).  What is the benefit of 
>> adding yet another version of these scripts?
>
> `Nimue` doesn't tends to be a wrapper like pacapt which itself tends to 
> "emulate" a Arch Linux environment. Nimue is just a symlink or a bash script 
> in cases a package management system uses acronyms like "-S", "-P" or "-R" 
> instead of "install", "purge", "remove" for the respective install, purge or 
> remove package functions of the package manager of your choice.
>

To be honest, I don't see the exact use case for this. If the end user
cannot be bothered to look up the command line syntax of the new
distro's package manager, then they are probably better of using a GUI
program to install packages or flatpaks.

If you would implement a universal package name translation, then this
could be **really** useful.


Side note: could you please configure your email client, so that it does
not create a new email thread for each reply that you write (it looks
like it does not set the in-reply-to field correctly)? It breaks the
thread view of the list.

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

Re: MBI (Playground 2.0)

[Dan Čermák]

This idea sounds pretty good to me.

As a less active contributor: How can I help out? Do you have a task
list? (Sorry if this got already answered in one of the follow up
emails.)


Cheers,

Dan

Igor Gnatenko  writes:

> MayBe I …(can do something useful)?
>
> Hello,
>
> We've been discussing some (hopefully) nice idea with Mikolaj, Neal and
> Jakub how we could improve packager (and user) experience and we have some
> proposal which will be described below.
>
> We would like to ask you to read it, understand it and ask us any questions
> you have. From the Fedora Infrastructure we would like to ask for some
> machines to implement this idea (you can find some more information in
> "Implementation details" part).
>
> I would like to apologize for HTML email, but it is much easier to have it
> that way to have better visibility and reading easiness.
>
> Feel free to reply to this email or comment in google doc (there is a link
> on the bottom).
> Proposal Owners
>
>-
>
>Mikolaj Izdebski (mizdebsk)  - Java SIG, Fedora
>infrastructure
>-
>
>Igor Gnatenko (ignatenkobrain)  - Rust
>SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor
>-
>
>Neal Gompa (ngompa)  - Rust SIG, Golang SIG, RPM
>contributor
>-
>
>Jakub Čajka (jcajka)  - Golang SIG, Container
>SIG
>
>
> This proposal aligns with the objective of improving the packager experience
>  by
> developing a platform whereby the proposal owners and others can experiment
> with improvements that can be funneled back into the official production
> infrastructure.
> ProblemsProblem №1: Build-only packages
>
> Some ecosystems have many build-only packages (packages which are used to
> build other packages, without having them installed on end-user systems).
> Those ecosystems include Java, Rust and Go.
>
> It is extremely hard to keep up maintaining them due to lack of
> time/people. Upstreams are usually changing quickly (sometimes when you
> update just one such package, you’d need to update tens of the
> dependencies). Few facts about such packages:
>
>-
>
>They are almost always outdated in released versions of distribution;
>-
>
>They are often FTBFS (e.g. because there was compiler update but not
>package update, broken deps, broken APIs due to deps rebases, …).
>
>
> In Rust ecosystem, we abuse Rawhide to build and store such packages there
> and then generate end-user application (e.g. ripgrep) which uses some of
> those packages and produces binary for all supported releases. Those
> applications have high quality and are supported.
>
> Rawhide gating makes this much more complicated because builds appear in
> buildroot slower, updating group of packages would need side tags and it’s
> just painful to work with.
>
> https://pagure.io/fesco/issue/2068
>
> And, after all, those packages shouldn’t be shipped to users.
> Problem №2: Testing of new rpm/koji/mock features/configuration
>
> When developing new features in RPM (e.g. rich dependencies) or testing
> different Koji configuration (e.g. removing gcc/gcc-c++ from the
> buildroot), it is required to make custom configuration and try building
> things.
> Problem №3: Developing modules
>
> Modules are built in MBS as a single unit. It is hard to develop big
> modules by progressively improving individual packages or small package
> groups. Scratch builds for modules are not implemented. Local builds work
> differently from official module builds, they don’t scale and don’t allow
> groups of people to work collaboratively. All these problems can be solved
> by first developing a flat repository of packages in a shared environment
> and then generating modulemd from such package set.
> Problem №4: Testing things before push
>
> Primary Fedora Koji and dist-git are not suited for packaging
> experimentation. Packagers are expected to experiment on their own systems
> and push changes of successful experiments only. But this approach doesn’t
> scale with number of maintained packages. Often you can find commits like
> “d’oh, forgot to upload sources” or “let’s try with this settings”. People
> need to build things somewhere quickly, do development and testing. And
> only after that, they should push commit(s) to Fedora.
> Solution
>
>-
>
>Separate Koji + Koschei deployed in Fedora infrastructure cloud;
>-
>
>Builders are optimized for the best performance (see below
>
> 
>);
>-
>
>People can have their own targets where they can break things as they
>wish without affecting others;
>-
>
>Package changes are eventually contributed to Fedora proper by merging
>changes to Fedora dist-git and rebuilding packages in official Fedora Koji;
>-
>
>All improvements can eventually be contributed back to official Fedora
>in

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Dan Čermák]

I'll take over zopfli.

Miro Hrončok  writes:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> See this in your web browser or curl it at:
>
> https://churchyard.fedorapeople.org/orphans-2019-02-11.txt
>
> Please grep it for your username.
>
>
>  Package  (co)maintainers   Status 
> Change
> 
> OSGi-bundle-ant-task  orphan   1 weeks ago
> RunSnakeRun   orphan   4 weeks ago
> SimplyHTMLmizdebsk, orphan 0 weeks ago
> aether-connector-okhttp   galileo, mizdebsk, orphan0 weeks ago
> ant   akurtakov, jcapik, kdaniel,  0 weeks ago
>mizdebsk, msrb, orphan
> ant-antunit   mizdebsk, orion, orphan  0 weeks ago
> ant-contrib   davidcl, mizdebsk, orphan0 weeks ago
> antlr3dchen, lef, mizdebsk,0 weeks ago
>mjakubicek, orphan, walters
> antlr4gil, jkastner, lef, mizdebsk,0 weeks ago
>orphan
> aopalliance   mizdebsk, orphan 0 weeks ago
> apache-commons-beanutils  fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-collectionsjcapik, mizdebsk, orphan 0 weeks ago
> apache-commons-collections4   mizdebsk, orphan 0 weeks ago
> apache-commons-compress   mizdebsk, mkoncek, orphan,   0 weeks ago
>spike
> apache-commons-configuration  fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-csvlef, mizdebsk, orphan, spike 0 weeks ago
> apache-commons-daemon mizdebsk, orphan, spike  0 weeks ago
> apache-commons-discovery  lkundrak, mizdebsk, orphan,  0 weeks ago
>spike
> apache-commons-el fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-fileupload jerboaa, mizdebsk, mmraka,   0 weeks ago
>orphan, spike
> apache-commons-io mizdebsk, orphan, spike  0 weeks ago
> apache-commons-jexl   mizdebsk, orphan 0 weeks ago
> apache-commons-jxpath fnasser, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-lang   mizdebsk, orphan, spike  0 weeks ago
> apache-commons-lang3  mizdebsk, orphan 0 weeks ago
> apache-commons-loggingkdaniel, mizdebsk, orphan,   0 weeks ago
>spike
> apache-commons-netmizdebsk, orphan, spike  0 weeks ago
> apache-ivymizdebsk, orphan 0 weeks ago
> apache-james-project  lef, mizdebsk, orphan0 weeks ago
> apache-logging-parent mizdebsk, orphan 0 weeks ago
> apache-mime4j lef, mizdebsk, orphan0 weeks ago
> apache-parent mizdebsk, orphan 0 weeks ago
> apache-ratmizdebsk, orphan 0 weeks ago
> apache-resource-bundles   mizdebsk, orphan 0 weeks ago
> apiguardian   mizdebsk, orphan 0 weeks ago
> aqute-bnd jcapik, mizdebsk, orphan 0 weeks ago
> args4jjcapik, mizdebsk, orphan 0 weeks ago
> atinject  kdaniel, mizdebsk, orphan0 weeks ago
> autotrash frafra, orphan, robyduck 6 weeks ago
> avalon-framework  jerboaa, mizdebsk, orphan0 weeks ago
> avalon-logkit jerboaa, mizdebsk, orphan0 weeks ago
> base64coder   jcapik, mizdebsk, orphan 0 weeks ago
> batik jvanek, mizdebsk, orphan 0 weeks ago
> bcel 

Re: Packaging .c files in a non-devel package

[Dan Čermák]

Hi Christophe,

since the .c files appear to be fundamental for the functionality of
make-it-quick, I'd rather silence this one specific check via an
rpmlintrc file instead of renaming them or converting this into a -devel
package.

Renaming them is probably a lot more work and calling it -devel will
confuse end users. Both are imho not worth it just for the sake of
silencing a single rpmlint warning.


Cheers,

Dan

Christophe de Dinechin  writes:

> Hello,
>
>
> I’m currently working on a Fedora package for make-it-quick 
> (https://github.com/c3d/make-it-quick), a make-only build system with basic 
> auto-configuration.
>
> rpmlint complains about shipping .c files in a non -devel package. The 
> package does contains several small .c files that are used for 
> autoconfiguration.
>
> One option would be to rename the package as “make-it-quick-devel”, but that 
> seems a bit redundant given that the whole point of the package is to be a 
> development tool.
>
> Another option would be to rename the files to use some custom extension for 
> configuration sources. But that seems more like obfuscation, and I don’t like 
> doing that just to silence rpmlint.
>
> Can you suggest a good approach?
>
>
> Thanks
> Christophe de Dinechin
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction

[Dan Čermák]

Hi Ruchit!

You can try out this site: https://whatcanidoforfedora.org/ which should
contain some initial pointers in which areas you can help out.

If you have more specific questions, you can drop by in IRC in
#fedora-devel on freenode for example.


Cheers,

Dan

Ruchit Vithani  writes:

> Hello! I'm Ruchit Vithani, a sophomore from DAIICT gandhinagar, India. I'm
> new to this community and would like to contribute. Will someone help me
> get started?
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sway SIG

[Dan Čermák]

Me too!

qrsBRWN  writes:

> I'm in too
>
> On March 27, 2019 7:49:03 PM GMT+01:00, Jeff Peeler  
> wrote:
>>On Mon, Mar 18, 2019 at 11:24 AM Till Hofmann
>>
>>wrote:
>>
>>> 
>>> There's been ongoing discussions on BZ [1] with some people showing
>>> interest in a SIG. The main purpose of this email is to see who else
>>> would be interested in contributing to sway. If we can find enough
>>> people, I'd continue with the SIG, as outlined in [2].
>>>
>>> I've never been involved in creating a SIG before, so please let me
>>know
>>> if I forgot anything.
>>>
>>
>> Please add me to the sway SIG as well.
>>
>>Jeff
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction for gaming packaging/maintaining

[Dan Čermák]

Hi Andi,

welcome to the pack!

You can try to review some packages or submit your own package, whatever
you feel like doing (if you submit a package, you'll need to get
sponsored though and reviewing packages is a good way how to get
sponsored).

In case you want to package some games, there's a pretty long list of
open source game clones: https://osgameclones.com/
Most of these are afaik not in Fedora (yet) and some smaller ones could
be a nice start (although you should watch out for licensing issues).

In case you are looking for other ways to contribute, there's always
this site: https://whatcanidoforfedora.org/


Cheers,

Dan

Karsten Andreas Artz  writes:

> Hi Benson,
> thx for welcoming me on Fedora and thx for providing the links. 
> I’ve read through them and skimmed them. 
> Should I start reviewing packages or do you have another idea?
> Regards
> Andi 
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, April 8, 2019, 9:35 PM, Benson Muite  
> wrote:
>
>  
> Hi Andi,
>  Welcome to Fedora. Some general information is at:
>  https://docs.fedoraproject.org/en-US/project/
>  The get involved page still needs an update:
>  https://docs.fedoraproject.org/en-US/project/join/
>  but packaging guidelines are here:
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/
>  
> most people start by reviewing packages - though there are other ways to 
> contribute other than packaging.
>  
>
>  
>  Regards,
>  Benson 
>
>  
>  On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
>   
>  
>Hi guys, 
>   my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
> (Fedora 26). My programming skills are on Python, Java/Java Script, and  
> C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts 
> History, Archaeology and Cath.Theology. Besides this, I can speak a lot of 
> languages: German, English, French, a  bit Italian and Spanish. 
>   
>   It would be glad starting contributing on Fedora as a maintainer. Therefore 
> I hope to work on a small  project soon.
>   I'm interested in games packaging, but I don't know where to start.
>   
>   
>   Regards 
>   Andi
>   
>   
>
>   ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>  ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction for gaming packaging/maintaining

[Dan Čermák]

Hi Andi,

the games you listed are proprietary and can thus not be shipped with
Fedora.

What you could do, is to try to improve the out of the box experience
when trying to install and play these games. But that is quite an
undertaking as that will require diving into the guts of wine.

My recommendation would be: find something in Fedora that annoys you or
that you think it lacks and try to work on that.


Cheers,

Dan

Karsten Andreas Artz  writes:

> Hi Dan, 
> thx for welcoming me to the pack! 
> I’ve skimmed through the games. I have different games in favor: Raildroad 
> Tycoon, Pizza Tycoon and escape from Monkey Island. 
> What are the first steps to start? 
> Thx in forward
> Cheers 
> Andi 
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Tuesday, April 9, 2019, 10:48 AM, Dan Čermák 
>  wrote:
>
> Hi Andi,
>
> welcome to the pack!
>
> You can try to review some packages or submit your own package, whatever
> you feel like doing (if you submit a package, you'll need to get
> sponsored though and reviewing packages is a good way how to get
> sponsored).
>
> In case you want to package some games, there's a pretty long list of
> open source game clones: https://osgameclones.com/
> Most of these are afaik not in Fedora (yet) and some smaller ones could
> be a nice start (although you should watch out for licensing issues).
>
> In case you are looking for other ways to contribute, there's always
> this site: https://whatcanidoforfedora.org/
>
>
> Cheers,
>
> Dan
>
> Karsten Andreas Artz  writes:
>
>> Hi Benson,
>> thx for welcoming me on Fedora and thx for providing the links. 
>> I’ve read through them and skimmed them. 
>> Should I start reviewing packages or do you have another idea?
>> Regards
>> Andi 
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Monday, April 8, 2019, 9:35 PM, Benson Muite  
>> wrote:
>>
>>  
>> Hi Andi,
>>  Welcome to Fedora. Some general information is at:
>>  https://docs.fedoraproject.org/en-US/project/
>>  The get involved page still needs an update:
>>  https://docs.fedoraproject.org/en-US/project/join/
>>  but packaging guidelines are here:
>>  https://docs.fedoraproject.org/en-US/packaging-guidelines/
>>  
>> most people start by reviewing packages - though there are other ways to 
>> contribute other than packaging.
>>  
>>
>>  
>>  Regards,
>>  Benson 
>>
>>  
>>  On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
>>  
>>  
>>            Hi guys, 
>>  my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
>>(Fedora 26). My programming skills are on Python, Java/Java Script, and  
>>C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts 
>>History, Archaeology and Cath.Theology. Besides this, I can speak a lot of 
>>languages: German, English, French, a  bit Italian and Spanish. 
>>  
>>  It would be glad starting contributing on Fedora as a maintainer. Therefore 
>>I hope to work on a small  project soon.
>>  I'm interested in games packaging, but I don't know where to start.
>>  
>>  
>>  Regards 
>>  Andi
>>          
>>  
>>    
>>  ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>  ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction for gaming packaging/maintaining

[Dan Čermák]

Hi Andi,

clones are usually ok, as long as they are clean-room reimplementations
and do not redistribute the original games' assets, which most of them
according to my knowledge don't.

For the other games a flatpak would be probably the best fit, as
flatpaks can contain more or less arbitrary dependencies and also be
closed source.


Cheers,

Dan

Karsten Andreas Artz  writes:

> Hi Dan,
> I’ve checked again and I guess the clones should be the one which can be 
> included on Fedora, can’t they? 
> Let me list my favors: Pizza Buisness, FreeRails, Jagged Alliance 2 - 
> Steaciatella. 
> This should be not proprietary, shouldn’t they? 
> Thx in forward!
> Cheers 
> Andi
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, April 10, 2019, 10:30 AM, Dan Čermák 
>  wrote:
>
> Hi Andi,
>
> the games you listed are proprietary and can thus not be shipped with
> Fedora.
>
> What you could do, is to try to improve the out of the box experience
> when trying to install and play these games. But that is quite an
> undertaking as that will require diving into the guts of wine.
>
> My recommendation would be: find something in Fedora that annoys you or
> that you think it lacks and try to work on that.
>
>
> Cheers,
>
> Dan
>
> Karsten Andreas Artz  writes:
>
>> Hi Dan, 
>> thx for welcoming me to the pack! 
>> I’ve skimmed through the games. I have different games in favor: Raildroad 
>> Tycoon, Pizza Tycoon and escape from Monkey Island. 
>> What are the first steps to start? 
>> Thx in forward
>> Cheers 
>> Andi 
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Tuesday, April 9, 2019, 10:48 AM, Dan Čermák 
>>  wrote:
>>
>> Hi Andi,
>>
>> welcome to the pack!
>>
>> You can try to review some packages or submit your own package, whatever
>> you feel like doing (if you submit a package, you'll need to get
>> sponsored though and reviewing packages is a good way how to get
>> sponsored).
>>
>> In case you want to package some games, there's a pretty long list of
>> open source game clones: https://osgameclones.com/
>> Most of these are afaik not in Fedora (yet) and some smaller ones could
>> be a nice start (although you should watch out for licensing issues).
>>
>> In case you are looking for other ways to contribute, there's always
>> this site: https://whatcanidoforfedora.org/
>>
>>
>> Cheers,
>>
>> Dan
>>
>> Karsten Andreas Artz  writes:
>>
>>> Hi Benson,
>>> thx for welcoming me on Fedora and thx for providing the links. 
>>> I’ve read through them and skimmed them. 
>>> Should I start reviewing packages or do you have another idea?
>>> Regards
>>> Andi 
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, April 8, 2019, 9:35 PM, Benson Muite 
>>>  wrote:
>>>
>>>  
>>> Hi Andi,
>>>  Welcome to Fedora. Some general information is at:
>>>  https://docs.fedoraproject.org/en-US/project/
>>>  The get involved page still needs an update:
>>>  https://docs.fedoraproject.org/en-US/project/join/
>>>  but packaging guidelines are here:
>>>  https://docs.fedoraproject.org/en-US/packaging-guidelines/
>>>  
>>> most people start by reviewing packages - though there are other ways to 
>>> contribute other than packaging.
>>>  
>>>
>>>  
>>>  Regards,
>>>  Benson 
>>>
>>>  
>>>  On 4/8/19 7:32 PM, Karsten Andreas Artz wrote:
>>>  
>>>  
>>>            Hi guys, 
>>>  my name is Andi, 29 and I'm from Germany.  I'm using Fedora almost 2 years 
>>>(Fedora 26). My programming skills are on Python, Java/Java Script, and  
>>>C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts 
>>>History, Archaeology and Cath.Theology. Besides this, I can speak a lot of 
>>>languages: German, English, French, a  bit Italian and Spanish. 
>>>  
>>>  It would be glad starting contributing on Fedora as a maintainer. 
>>>Therefore I hope to work on a small  project soon.
>>>  I'm interested in games packaging, but I don't know where to start.
>>>  
>>>  
>>>  Regards 
>>>  Andi
>>>          
>>>  
>>>    
>>>  ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le

Re: fedora-img-dl: a tool for downloading Fedora iso's and images

[Dan Čermák]

Hi Jens,

cool project! I see a certain overlap with fedora-mediawriter though, as
that one can download ISOs too.

I've skimmed the sources (is this upstream:
https://github.com/juhp/fedora-img-dl?) to take a look whether you
verify the GPG signatures of the downloaded images, but couldn't find
anything like that (although I can barely read Haskell). If your tool
would do that, I'd consider that a killer feature.


Cheers,

Dan

Jens-Ulrik Petersen  writes:

> Hi, I made a small cli tool for downloading Fedora iso's etc.
>
> It can download rawhide, branched, beta, and released isos (eg Workstation
> Live etc), and even WS Live respins (support for spins coming later).
>
> You can try it now from <
> https://copr.fedorainfracloud.org/coprs/petersen/fedora-img-dl/>.
>
> Feedback is welcome.
>
> Jens
>
>
> ps I am not entirely in love with the name, so if you have suggestions for
> a better one, let me know - note it may also be extended to more OSes in
> the future perhaps.
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Using SCLs to build a C++ library for EL 7?

[Dan Čermák]

Hi list,

I'm co-maintaining a C++ library that has been continuously updated in
CentOS 7 but a recent change made it incompatible with the default GCC
version available in el7. I.e. the next release (scheduled for the end
of 2019) will FTBFS in CentOS/RHEL 7.

Would it be fine to require a gcc version from a SCL to build this
library? I'm afraid that due to the nature of C++'s non-standardized ABI
it would require all dependent packages to be rebuild with gcc from the
SCL too.


Cheers,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Using SCLs to build a C++ library for EL 7?

[Dan Čermák]

John Reiser  writes:

> It would be useful for posts to be specific, and/or to include a link
> to a detailed explanation.  Such information might attract the interest
> of others, and tend to encourage the discovery of multiple approaches
> towards dealing with the underlying problems.
>
>
> On 4/29/19 1210 UTC, Jonathan Wakely wrote:
>> On 29/04/19 07:52 -0400, Neal Gompa wrote:
>>> On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák
>>>  wrote:
>>>>
>>>> Hi list,
>>>>
>>>> I'm co-maintaining a C++ library that has been continuously updated in
>
> Which library in which package?

libexiv2 in the exiv2 package.

>
>>>> CentOS 7 but a recent change made it incompatible with the default GCC
>>>> version available in el7. I.e. the next release (scheduled for the end
>>>> of 2019) will FTBFS in CentOS/RHEL 7.
>
> What is the nature of the incompatibilities, and what are specific
> examples?

We switched to from the POSIX regex library to  as it should be
provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does
not properly implement  and it made a lot of tests fail. We have
therefore switched to using the SCL gcc & clang compiler for now.

>
>>>>
>>>> Would it be fine to require a gcc version from a SCL to build this
>>>> library? I'm afraid that due to the nature of C++'s non-standardized ABI
>>>> it would require all dependent packages to be rebuild with gcc from the
>>>> SCL too.
>>>>
>>>
>>> Software Collections GCC is configured to follow C++ ABI from system
>>> GCC. This puts some limitations on the libstdc++ shipped by SCL GCC,
>
> For example, or a link to an explanation?
>
>>> but allows us to avoid that problem entirely.
>> 
>> If you're talking about the devtoolset version of GCC, that's not
>> strictly true. There are limitations on what is supported, so the
>
> For example; or a link to an explanation?
>
>> problem isn't avoided entirely.
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi 4.0.0 deployed, one known issue so far

[Dan Čermák]

Hi,

I just tried to submit an update via `fedpkg update` but got a failure
via the cli:
$ fedpkg update
Could not execute update: Could not generate update request: 'anonymous'
A copy of the filled in template is saved as bodhi.template.last

Nevertheless the update got submitted and is available on Bodhi (it's
this one:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-16433c312e).


Cheers,

Dan

Randy Barlow  writes:

> Greetings!
>
> I have just deployed Bodhi 4.0.0 to production:
>
> https://bodhi.fedoraproject.org/docs/user/release_notes.html
>
> One known issue has been found[0] so far: after creating an update,
> your browser will be redirected to a URL that does not exist. The
> update was created, however, and you should receive an e-mail with the
> URL to it (and can also see it on your user page in Bodhi).
>
> Let me know if you find any other problems!
>
>
> [0] https://github.com/fedora-infra/bodhi/issues/3248
> ___
> 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Dan Čermák]

Miro Hrončok  writes:

> the-new-hotness  orphan1 weeks ago

This looks scary, isn't this needed to actually run the-new-hotness? If
yes, I'll take it.


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned python-breathe

[Dan Čermák]

I'll take it: https://pagure.io/releng/issue/8531

Miro Hrončok  writes:

> Upon the maintainers request, I've just orphaned python-breathe.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1706355
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Specfile - Upgrade - Check if the old and the new package versions are the same

[Dan Čermák]

Hi Simon,

On March 30, 2023 12:54:49 AM UTC, Simon Pichugin  wrote:
>Hi folks,
>I've spent some time experimenting and trying to implement something like
>this ($subject):
>
>During `%preun servers`:
>
>export OLD_VERSION="$(rpm -qa openldap | awk -F- '/^openldap/ &&
>split($2,ver,/\./) >= 1 {print ver[1] "." ver[2] "." ver[3]}')"
>
>Then, during `%post servers`
>
>if [ $1 -lt 2 ] || [ "%{major_version}.%{minor_version}" =
>"${OLD_VERSION}" ] ; then
># do something
>fi
>
>I understand that it's not the correct way... Could you please suggest how
>something like this can be achieved? (during the upgrade - check if the old
>and the new package versions are the same)

You could try to use rpmdev-vercmp. I am not sure if its exit code indicates 
whether two versions are equal, but it provides easy to parse output.

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

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Dan Čermák]

Hi,

Mattia Verga via devel  writes:

> Il 31/03/23 17:27, Florian Festi ha scritto:
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
 https://fedoraproject.org/wiki/Changes/RPM-4.19
 == Detailed Description ==
 RPM 4.19 contains various improvements over previous versions. Many of
 them are internal in nature such as moving from automake to cmake,
 improvements to the test suite, stripping copies of system functions,
 splitting translations into a separate project and more. There are
 still several user facing changes:

 * New rpmsort(8) utility for sorting RPM versions
>>> Handy!
>>>
 * x86-64 architecture levels (v2-v4) as architectures
>>> Could you explain more what this means, exactly?
>> No! But here is the commit:
>>
>>   
>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>
>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>> about some x86_64 processors having additional capabilities.
>>
> Is there anyone who could provide some benchmarks to see if there are
> significant performance improvements about using v2/v3/v3 versus plain
> x86_64? If so, do you think we could drop building i686 by default (to
> save some resources) and provide v2 (or v3, or v4) alongside x86_64?

The only benchmark that *I* am aware of is this one done by Martin
Jambor: https://jamborm.github.io/spec-2022-07-29-levels/

tl;dr; v2 does not really bring notable improvements, only v3 but also
only in some selected synthetic benchmarks.


openSUSE Tumbleweed went a different route and chose to utilize
glibc-hwcaps instead:
https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels
https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD/


Cheers,

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

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Dan Čermák]

Chris Adams  writes:

> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
>> On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
>> > Why a subrpm?  Should be possible to just arrange for one src.rpm to
>> > build the library twice and install the x86-64-v3 into
>> > /usr/lib64/glibc-hwcaps/x86-64-v3/
>> > Perhaps come with some macro to simplify that for packagers.
>> 
>> If we start compiling libaries twice, it'd double the package sizes
>> (or actually more than double, since in the benchmarks the code size
>> with -v3 is also increased slightly). I assume people would want to
>> get the optimized form split out to a subpackage so people who don't
>> use this, don't pay the price. If we use the new "dynamic subpackages"
>> feature of RPM, and some smart macros, this could even not be a big
>> packaging burden.
>
> Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
> PITA sometimes.  But cramming multiple architectures of core libraries
> into a single RPM would be bad for disk space, image size, downloads,
> etc.
>
> But something that didn't exist in the i386/i686 days is containers -
> whether base images like for podman or full things like Flatpaks.
> Before going too deep into multi-level architectures, that should be
> taken into account.

Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256


Cheers,

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

Re: F39 proposal: mkosi-initrd (Self-Contained Change proposal)

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/mkosi-initrd
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
>
> `mkosi-initrd` is an alternative builder for initrds.
> It will be packaged in Fedora, so that users can use it to build
> initrds locally.
> A `kernel-install` plugin will be provided to build the initrd when a
> kernel package is installed.
> As a stretch goal, initrds will be build in koji and delivered via rpm 
> packages.
> As a further stretch goal, pre-built initrds will be used in Unified
> Kernel Images that can be delivered via rpm packages.
>
> Only a subset of installation types will be supported.
>
> == Owner ==
> * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Name: [[User:lnykryn| Lukáš Nykrýn ]]
> * Name:  [[User:Daandemeyer| Daan De Meyer]]
> * Email: zbyszek - at - in.waw.pl, lnykryn - at - redhat.com,
> daandemeyer - at - fb.com
>
>
>
> == Detailed Description ==
> The process by which we create initrds is complicated and inefficient.
> Initrds contain duplicate functionality and require a lot of maintainer 
> effort.
> The aim of this proposal is to introduce a vastly simplified mechanism
> of initrd creation and simplified initrd contents.
>
> The `mkosi-initrd` project is a set of config files for `mkosi`.
> `mkosi` is a program to build operating system images from system packages.
> An initrd is built by invoking `mkosi` with the config provided by
> `mkosi-initrd`.
>
> Instead of building initrds by scraping the file system and figuring
> out dependencies again,
> existing packages and normal package installation via `dnf`/`rpm` is
> used to populate the initrd.
> This also means that the package manager is responsible for satisfying
> dependencies.
> At runtime, `systemd` is responsible for setting up the execution
> environment and invoking programs.
>
> Currently, initrds built in this way are bigger than initrds built by dracut.
> They also have limited functionality:
> many common types of systems work just fine, but more exotic
> configurations are not supported.
> See [[#Scope|Scope]] below for a list of known good/bad features.
>
> The goal of this change is to provide an ''alternative'' mechanism.
> If the feedback is positive, we may consider using initrds built with
> `mkosi-initrd` as default in certain scenarios.
> There are no plans to remove `dracut` in the foreseeable future.
> This means that for any case not supported or not working well,
> `dracut` remains a natural fallback.
> In this way this change is similar to
> [[Changes/Unified_Kernel_Support_Phase_1]],
> as it provides a preview of a new technology as an alternative to the
> current established approach.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> Current initrd generation with `dracut` is showing its age.
> As upstream packages evolve,
> repeating the dependency resolution in `dracut` is a constant drain of
> maintainer time.
> Our `dracut` initrds are already using `systemd`.
> But `systemd` is constantly evolving and adding new functionality
> related to early boot:
> decryption of disks, access to secrets, new configuration mechanisms,
> state checks and boot counting.
> More and more, `dracut` runtime scripting is a thin wrapper around `systemd`.
> We have two job queues: the `dracut` initqueue, and the `systemd` job queue.
> This duplication makes everything harder, both during preparation and
> at runtime, for little benefit.
>
> The design principle of the new approach is to remove duplicate functionality:
> * package `Requires` replace dracut module dependency logic and
> automatic installation of libraries based on `ldd` output
> * `systemd` job management replaces the remainder of `dracut` runtime
> * the environment in the initrd is just a normal linux system (albeit
> on a temporary root fs)
> * normal package contents replace special scripts crafted for the initrd
>
> Generally, the new scheme requires very little new stuff.
> We reuse things that are already available (and used):
> `dnf` and `rpm`,
> packages for all stuff that is used in the initrd,
> `systemd`,
> special systemd units for the initrd.
>
> The new component is a mechanism that builds the initrd out of packages.
> But it is a relatively simple step that requires very little maintenance.
> The biggest part of the initial work is the creation of package lists
> to install in the initrd,
> and adjusting packages to to function correctly in the initrd and not
> pull in unnecessary dependencies.
> Afterwards, there might be occasional maintenance related to bugs or
> package splits.
>
> Initrds built with `mkosi-initrd` should be fully reproducible (in the
> sense of reproducible builds).
>
> The work done in packages has external benefits:
> package minimization a

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Dan Čermák]

Hi,

Aoife Moloney  writes:

> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
>
snip
>
> There is considerable implementation complexity within OSBS to implement this,
> because the N/V/R need to be written into generated Dockerfile as
> labels ''before'' building it,
> but it should be manageable. If not, we'll need to switch to a different 
> scheme.
> (Running dnf with --best when building the container will
> help make this reliable
> and would be a general improvement.)

Just out of interest, has this complicated part been already implemented
or is it still on the todo list? Would using a different container build
system reduce the complexity here?


Cheers,

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