Re: convert everything to rpmautospec?

[Iñaki Ucar]

On Mon, 8 Apr 2024 at 15:47, Fabio Valentini  wrote:

> On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar  wrote:
> >
> > So someone wanted to use rpmautospec and was willing to do the work,
> putting things together as an opt-in feature. Perfect.
> >
> > Now, I don't see any problem if some time later someone revisits the
> topic and proposes to go further. I don't see anything unfriendly here.
> Everything was set or decided at some point, and nothing could ever be
> changed if we don't allow ourselves to change our minds and be free to make
> new proposals.
> >
> > That said, we are also free to reject those proposals, and I'm -1 here.
> As of today, I think it's fine as an opt-in feature, and I'm even using it
> for some small uncomplicated packages. But I don't think it should be the
> default with an opt-out.
>
> It is already supposed to be default / preferred since this Fedora 38
> Change:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default


Described as preferred in the docs != default. Also versioning and
changelog are described separately, so some could use autochangelog but not
autorelease, or the other way around, or not at all. In the same way that
one could use autosetup or not. But here it has been proposed that
autochangelog + autorelease are not options anymore, and that you would
need to add a file to the repo to opt-out. -1 to this. The current status
is fine for me.

-- 
Iñaki Úcar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: convert everything to rpmautospec?

[Iñaki Ucar]

So someone wanted to use rpmautospec and was willing to do the work,
putting things together as an opt-in feature. Perfect.

Now, I don't see any problem if some time later someone revisits the topic
and proposes to go further. I don't see anything unfriendly here.
Everything was set or decided at some point, and nothing could ever be
changed if we don't allow ourselves to change our minds and be free to make
new proposals.

That said, we are also free to reject those proposals, and I'm -1 here. As
of today, I think it's fine as an opt-in feature, and I'm even using it for
some small uncomplicated packages. But I don't think it should be the
default with an opt-out.

Iñaki

On Mon, 8 Apr 2024 at 14:56, Emmanuel Seyman  wrote:

> * Zbigniew Jędrzejewski-Szmek [08/04/2024 09:02] :
> >
> > Well, you and Kevin see "salami tactics" (whatever that may be),
>
> FTR, I have no idea what "salami tactics" is.
>
> > while I see normal engineering practice: some new idea is hatched,
> > it's implemented and used narrowly, them it's applied by default
> > and more widely, and possibly at the end previous methods are
> > deprecated.
>
> This sounds acceptable but is not at all how these changes are proposed.
>
> An proposal is made, stating explicity that it will be opt-in or target
> a subset of the target audience and never even suggesting that the scope
> might one day be expanded.
>
> It is accepted based on that premise and, after a while, changes are
> made to make the change default or opt-out, leaving the people who would
> not have accepted it had they known they would be forced to use it with
> no recourse.
>
> This is unfriendly (thus violating one of Fedora's core principles) at
> best and deceitful at worst.
>
> > The alternative would be to have "grand plans" where we decide that
> > some technology will be used by default and mandatory before we deploy
> > it widely and get feedback.
>
> Another alternative would be not lie to the target audience by
> initially claiming that the change is opt-in. Yet another alternative
> would be to not go back on this claim.
>
> > I think that if you think this through, you'll realize that the
> > "salami tactic" is quite reasonable.
>
> I don't but wish to thank you for the condescending tone nonetheless.
>
> Emmanuel
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


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

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Iñaki Ucar]

El mié., 3 abr. 2024 3:22, Adam Williamson 
escribió:

> On Tue, 2024-04-02 at 21:15 -0400, Steve Cossette wrote:
> > I get your point, Kevin. I would argue though that, if a user is looking
> to
> > use Linux, they probably got a decent idea as to what DE they want to
> use.
> > There are SO MANY LINUX DISTROS! Making a choice between two is
> > honestly probably not that jarring imo.
>
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next - which was explicitly
> based around making it much more focused and less of a choose-your-own-
> adventure, specifically including making the download page much more
> opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> was associated with a very significant immediate bump in Fedora usage.


How do we measure "usage" and how do we attribute the bump to the change in
the download page? Did we A/B test the new page?

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package conflict management advice

[Iñaki Ucar]

On Wed, 20 Mar 2024 at 19:37, Iñaki Ucar  wrote:

>
>
> On Tue, 19 Mar 2024 at 12:34, Michael J Gruber 
> wrote:
>
>> Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <
>> iu...@fedoraproject.org>:
>> >
>> > Dear all,
>> >
>> > I'm looking for options/advice here. See [1], and a bit of context:
>> >
>> > - RStudio (now Posit.co) publishes two packages named rstudio (with
>> RStudio Desktop) and rstudio-server (with RStudio Server). They are
>> independent and have many files in common. Recent versions are based on
>> Electron (for Desktop) and have Quarto support.
>> >
>> > - In Fedora, we decided to package all the common files in the rstudio
>> package, then build rstudio-desktop and rstudio-server for these products,
>> with just the specific files. In our build, we rely on QtWebEngine for the
>> Desktop version and disable Quarto, because it would be a nightmare to
>> package (requires Deno).
>> >
>> > Now the issue [1]: there's always been confusion among users that at
>> some point install the rstudio package provided by Posit (which provides
>> everything), many times because RStudio prompts that there's a new version
>> available and they just go click unknowingly. After some time, the package
>> manager "updates" it to our version when we hit stable, and RStudio Desktop
>> is gone (because rstudio-desktop is not present). Some time ago, I disabled
>> the "new version" notification dialog to mitigate this, but these days this
>> happens more and more frequently because users want Quarto and specifically
>> opt for the package provided by Posit.
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
>> >
>> > What do you think is the best way to mitigate this? Options:
>> >
>> > 1. Keep things as they are, just tell the users to exclude the rstudio
>> package in the dnf configuration. Pros: no changes required. Cons: it's
>> clear that users don't know how to do this. And more documentation rarely
>> solves this kind of problem.
>> >
>> > 2. Make rstudio Requires rstudio-desktop. Pros: When the package
>> manager updates to our version, at least there's a working version of
>> RStudio installed. Cons: Server users shouldn't need Desktop installed.
>> Still confusing to users.
>> >
>> > 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that
>> just Requires rstudio-desktop. Pros: Same as before + Server doesn't need
>> Desktop. Cons: Still confusing to users.
>> >
>> > 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio.
>> Pros: You either install rstudio from Posit, or rstudio-desktop from
>> Fedora. And I'm not sure about this, but does installing one remove the
>> other? Or does dnf at least show the conflict and the user decides? Cons:
>> `dnf install rstudio` doesn't work anymore, so it's less discoverable. And
>> we have a similar issue with rstudio-server anyways that cannot be easily
>> solved. But I suppose that admins installing rstudio-server know how to
>> prevent package updates.
>> >
>> > 5. Introduce some version component that makes our package versions be
>> sorted < than Posit's. Pros: Upgrades never happen when a user opts for
>> packages provided by Posit. Cons: I don't know how to do this without
>> breaking our updates. Probably other issues?
>> >
>> > Any advice? Other options not considered here?
>>
>> Wow, contrived situation. I guess this shows again that packaging
>> should be left to packagers, not upstream :)
>>
>> 4. seems to be the only solution where "problematic but typical" user
>> behaviour leads to explicit conflicts rather than "funny" behaviour.
>> `dnf` will bail out and explain the conflicts ("cannot install both
>> ...") and even suggest to use "allow-erasing", which cleans things up.
>> dnf will not offer "rstudio" updates if there is no such package in
>> Fedora repos.
>>
>> Even in this case, one can only hope that users don't switch
>> inadvertently between "upstream" and Fedora. At least it requires
>> extra steps with 4 (though I don't now about pkgkit).
>>
>
> Thanks, Michael. Do you find option 5 unadvisable? Because a possible way
> I found is the following.
>
> Upstream versioning is year.month.day-build. Example: 2023.12.1-403. So
> they name their package rstudio-2023.12.1-403. In a way, the build
> identifier works as a release number for them. Our

Re: Package conflict management advice

[Iñaki Ucar]

On Tue, 19 Mar 2024 at 12:34, Michael J Gruber 
wrote:

> Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <
> iu...@fedoraproject.org>:
> >
> > Dear all,
> >
> > I'm looking for options/advice here. See [1], and a bit of context:
> >
> > - RStudio (now Posit.co) publishes two packages named rstudio (with
> RStudio Desktop) and rstudio-server (with RStudio Server). They are
> independent and have many files in common. Recent versions are based on
> Electron (for Desktop) and have Quarto support.
> >
> > - In Fedora, we decided to package all the common files in the rstudio
> package, then build rstudio-desktop and rstudio-server for these products,
> with just the specific files. In our build, we rely on QtWebEngine for the
> Desktop version and disable Quarto, because it would be a nightmare to
> package (requires Deno).
> >
> > Now the issue [1]: there's always been confusion among users that at
> some point install the rstudio package provided by Posit (which provides
> everything), many times because RStudio prompts that there's a new version
> available and they just go click unknowingly. After some time, the package
> manager "updates" it to our version when we hit stable, and RStudio Desktop
> is gone (because rstudio-desktop is not present). Some time ago, I disabled
> the "new version" notification dialog to mitigate this, but these days this
> happens more and more frequently because users want Quarto and specifically
> opt for the package provided by Posit.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
> >
> > What do you think is the best way to mitigate this? Options:
> >
> > 1. Keep things as they are, just tell the users to exclude the rstudio
> package in the dnf configuration. Pros: no changes required. Cons: it's
> clear that users don't know how to do this. And more documentation rarely
> solves this kind of problem.
> >
> > 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager
> updates to our version, at least there's a working version of RStudio
> installed. Cons: Server users shouldn't need Desktop installed. Still
> confusing to users.
> >
> > 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that
> just Requires rstudio-desktop. Pros: Same as before + Server doesn't need
> Desktop. Cons: Still confusing to users.
> >
> > 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio.
> Pros: You either install rstudio from Posit, or rstudio-desktop from
> Fedora. And I'm not sure about this, but does installing one remove the
> other? Or does dnf at least show the conflict and the user decides? Cons:
> `dnf install rstudio` doesn't work anymore, so it's less discoverable. And
> we have a similar issue with rstudio-server anyways that cannot be easily
> solved. But I suppose that admins installing rstudio-server know how to
> prevent package updates.
> >
> > 5. Introduce some version component that makes our package versions be
> sorted < than Posit's. Pros: Upgrades never happen when a user opts for
> packages provided by Posit. Cons: I don't know how to do this without
> breaking our updates. Probably other issues?
> >
> > Any advice? Other options not considered here?
>
> Wow, contrived situation. I guess this shows again that packaging
> should be left to packagers, not upstream :)
>
> 4. seems to be the only solution where "problematic but typical" user
> behaviour leads to explicit conflicts rather than "funny" behaviour.
> `dnf` will bail out and explain the conflicts ("cannot install both
> ...") and even suggest to use "allow-erasing", which cleans things up.
> dnf will not offer "rstudio" updates if there is no such package in
> Fedora repos.
>
> Even in this case, one can only hope that users don't switch
> inadvertently between "upstream" and Fedora. At least it requires
> extra steps with 4 (though I don't now about pkgkit).
>

Thanks, Michael. Do you find option 5 unadvisable? Because a possible way I
found is the following.

Upstream versioning is year.month.day-build. Example: 2023.12.1-403. So
they name their package rstudio-2023.12.1-403. In a way, the build
identifier works as a release number for them. Our package is
rstudio-2023.12.1+403-1, so the same version is always sorted > than theirs.

What if, for the next release, I change the versioning scheme to e.g.
rstudio-2024.04.01~500-1, which would always be sorted < than theirs? Our
package will be updated nicely, but then, if a user manually installs their
packages (rstudio or rstudio-server), they will never be updated by our
packages. An

Package conflict management advice

[Iñaki Ucar]

Dear all,

I'm looking for options/advice here. See [1], and a bit of context:

- RStudio (now Posit.co) publishes two packages named rstudio (with RStudio
Desktop) and rstudio-server (with RStudio Server). They are independent and
have many files in common. Recent versions are based on Electron (for
Desktop) and have Quarto support.

- In Fedora, we decided to package all the common files in the rstudio
package, then build rstudio-desktop and rstudio-server for these products,
with just the specific files. In our build, we rely on QtWebEngine for the
Desktop version and disable Quarto, because it would be a nightmare to
package (requires Deno).

Now the issue [1]: there's always been confusion among users that at some
point install the rstudio package provided by Posit (which provides
everything), many times because RStudio prompts that there's a new version
available and they just go click unknowingly. After some time, the package
manager "updates" it to our version when we hit stable, and RStudio Desktop
is gone (because rstudio-desktop is not present). Some time ago, I disabled
the "new version" notification dialog to mitigate this, but these days this
happens more and more frequently because users want Quarto and specifically
opt for the package provided by Posit.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191

What do you think is the best way to mitigate this? Options:

1. Keep things as they are, just tell the users to exclude the rstudio
package in the dnf configuration. Pros: no changes required. Cons: it's
clear that users don't know how to do this. And more documentation rarely
solves this kind of problem.

2. Make rstudio Requires rstudio-desktop. Pros: When the package manager
updates to our version, at least there's a working version of RStudio
installed. Cons: Server users shouldn't need Desktop installed. Still
confusing to users.

3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that
just Requires rstudio-desktop. Pros: Same as before + Server doesn't need
Desktop. Cons: Still confusing to users.

4. Rename rstudio as rstudio-common, make this one Conflicts rstudio. Pros:
You either install rstudio from Posit, or rstudio-desktop from Fedora. And
I'm not sure about this, but does installing one remove the other? Or does
dnf at least show the conflict and the user decides? Cons: `dnf install
rstudio` doesn't work anymore, so it's less discoverable. And we have a
similar issue with rstudio-server anyways that cannot be easily solved. But
I suppose that admins installing rstudio-server know how to prevent package
updates.

5. Introduce some version component that makes our package versions be
sorted < than Posit's. Pros: Upgrades never happen when a user opts for
packages provided by Posit. Cons: I don't know how to do this without
breaking our updates. Probably other issues?

Any advice? Other options not considered here?

Best,
-- 
Iñaki Úcar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Referencing an upstream subdir in the sources

[Iñaki Ucar]

Great guide and references. Thanks, Michael and Michal.

Iñaki

El mié., 10 ene. 2024 13:41, Michal Schorm  escribió:

> On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber 
> wrote:
> > Alternatively, we (used to?) have several packages which need to clean
> > upstream sources before even committing them to the lookaside cache.
>
> I do it for MariaDB for example, deleting part of the sources under
> unapproved licenses:
>
> https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/generate-modified-sources.sh
>
> Michal
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Wed, Jan 10, 2024 at 12:14 PM Michael J Gruber 
> wrote:
> >
> > Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar <
> iu...@fedoraproject.org>:
> > >
> > > Hi,
> > >
> > > A package has its source code embedded as a subdirectory of a larger
> > > piece of software. Sometimes they publish this subdirectory as a
> > > separate tar as a release artifact, but sometimes they forget.
> > >
> > > To avoid depending on their memory (and opening an issue each time), I
> > > would like to simply download the full repo and produce the tar
> > > myself. How should I deal with this in the spec? (Note: building this
> > > subdir as a subpackage in the main one is not a good idea in this
> > > case, it's not an option).
> >
> > Hi,
> >
> > I assume you don't want to distribute the full tar and simply cd into
> > it the proper subdir during the build? That would be the easiest
> > solution.
> >
> > Alternatively, we (used to?) have several packages which need to clean
> > upstream sources before even committing them to the lookaside cache.
> > scribus comes to my mind, some crypto things were like that in the
> > past. What you typically do is:
> > - Write a simple script which mangles the upstream package.tar and
> > repackages it as package-free.tar or such.
> > - Add the script to dist-git.
> > - comment out the original source line in spec (and the signature if
> present)
> > - specify "source: package-free.tar" instead and comment on the use of
> > the script
> > - commit only package-free.tar to dist-git
> >
> > That way, everyone can reproduce the used source code from the
> > upstream source code if needed while we only have the actual used
> > source in dist-git (lookaside).
> >
> > Michael
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Referencing an upstream subdir in the sources

[Iñaki Ucar]

Hi,

A package has its source code embedded as a subdirectory of a larger
piece of software. Sometimes they publish this subdirectory as a
separate tar as a release artifact, but sometimes they forget.

To avoid depending on their memory (and opening an issue each time), I
would like to simply download the full repo and produce the tar
myself. How should I deal with this in the spec? (Note: building this
subdir as a subpackage in the main one is not a good idea in this
case, it's not an option).

Thanks,
-- 
Iñaki Úcar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Iñaki Ucar]

On Sat, 25 Nov 2023 at 11:50, David King  wrote:
>
> Hi Iñaki
>
> On 2023-11-24 14:00, Iñaki Ucar  wrote:
> >Hi David,
> >
> >We have a couple of broken R packages due to this update:
> >
> >- https://src.fedoraproject.org/rpms/R-xml2
> >- https://src.fedoraproject.org/rpms/R-XML
> >
> >But I'm overloaded right now and I've been unable to take a look. Any help
> >would be appreciated if you have some spare cycles.
>
> I did R-xml2 and I see that spot just merged that change:
>
> https://src.fedoraproject.org/rpms/R-xml2/pull-request/1
>
> I could not find a mailing list or version control for R-XML, as I would
> suspect that someone has already prepared a fix, or at least discussed
> how to approach the issue (possibly in one of the newer released
> versions, although I could find no information about what had changed,
> unfortunately).

Thanks. R-XML fixed now too.

-- 
Iñaki Úcar
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Script for installing TeXLive packages required by a document?

[Iñaki Ucar]

This is very useful, so +1 to packaging it.

I don't know if there's a better solution. There is an R package called
tinytex [1] that provides automatic installation of TeXLive packages in a
user library. AFAIK, it just compiles the stuff, parses the logs for errors
looking for "blablabla.sty not found", and then installs them and retries
until everything is fine.

[1] https://yihui.org/tinytex/

Iñaki

On Tue, 1 Aug 2023 at 14:19, Ankur Sinha  wrote:

> Hi folks,
>
> Would any Fedora TeXLive users have any scripts to figure out what
> TeXLive packages a TeX/LaTeX document uses and install them using dnf?
>
> I've got this hacked up and it does work and I was wondering if I should
> move it to a different repository and package it up to make it available
> to all Fedora users, but does someone have a better solution/tool?
>
> https://github.com/sanjayankur31/100_dotfiles/blob/main/bin/fedora-install-texlive-deps.sh
>
> (also attached)
>
> --
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Issue with Rawhide docker image?

[Iñaki Ucar]

On Wed, 7 Jun 2023 at 19:15, Kevin Fenzi  wrote:
>
> On Tue, Jun 06, 2023 at 12:30:56PM -0500, Chris Adams wrote:
> > Once upon a time, Clement Verna  said:
> > > Once https://github.com/docker-library/official-images/pull/14789 merges,
> > > the rawhide image on the DockerHub should be fixed too :-)
> >
> > So... if it takes a manual process (including opening a PR), does it
> > really make sense to put Rawhide images on Dockerhub?
>
> Sadly, lots of people look there, but yeah... it's not great.

Yeah, basically, because $VISIBILITY. Anyway this looks like something
that could be easily automated via GH Actions.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ppc64le builds taking ages

[Iñaki Ucar]

On Sat, 20 May 2023 at 23:52, Kevin Fenzi  wrote:
>
> I've moved all the power9 virthosts running builders over to a 6.3.x
> kernel.
>
> Please let me know if this helps or doesn't with slowness issues.

Thanks! We'll keep an eye.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ppc64le builds taking ages

[Iñaki Ucar]

On Fri, 19 May 2023 at 16:55, Dan Horák  wrote:
>
> On Fri, 19 May 2023 16:27:23 +0200
> Iñaki Ucar  wrote:
>
> > Hi,
> >
> > Do we know why some ppc64le builds take so much? And with "so much" I
> > mean 7-10x the time for a "normal" run. Examples: 2 hours for [1] vs.
> > 20 hours for [2].
> >
> > And if we do know the cause, is there any way to predict it in order
> > to avoid the %check section?
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395536
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395502
>
> seems the build got restarted, perhaps due OOM on the builder, and
> actual build time was 12h, perhaps the builder or the vmhost were
> overloaded. Do you see the long build times in recent builds too? Both
> examples are from March.

Here's one: https://koji.fedoraproject.org/koji/taskinfo?taskID=101326951
Compared to: https://koji.fedoraproject.org/koji/taskinfo?taskID=101327166

And I suspect this is the cause of the large number of random errors
we've been experiencing with R packages recently. I think that the R
check command has a timeout that is triggered when a ppc64le build
takes too much (specifically when rebuilding package vignettes).
Things seem to have gone back to normal as I noticed them and disabled
vignette rebuilds in most (all?) of them. But these random extreme
delays are annoying, especially in packages with heavy tests.

Iñaki

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

ppc64le builds taking ages

[Iñaki Ucar]

Hi,

Do we know why some ppc64le builds take so much? And with "so much" I
mean 7-10x the time for a "normal" run. Examples: 2 hours for [1] vs.
20 hours for [2].

And if we do know the cause, is there any way to predict it in order
to avoid the %check section?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395536
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=98395502

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

[Iñaki Ucar]

On Tue, 2 May 2023 at 11:27, Sandro Mani  wrote:
>
>
> On 02.05.23 11:24, Iñaki Ucar wrote:
>
> On Tue, 4 Apr 2023 at 16:23, Stephen Gallagher  wrote:
>
> On Tue, Apr 4, 2023 at 9:45 AM Sérgio Basto  wrote:
>
> On Thu, 2023-03-16 at 11:19 -0400, Stephen Gallagher wrote:
>
> On Wed, Mar 15, 2023 at 1:16 PM Jerry James 
>
> ...
>
> I found a problem related with yarnpkg rpm, the macro % __find_requires
> finds that yarn scripts uses and needs /usr/bin/node , which is added
> to the requires of rpm [1] and this makes yarnpkg pull nodejs (18) even
> when nodejs20 is installed .
> To avoid this rpm automatic requires, we may add to yarnpkg.spec [2]
>
> [2]
> %global __script_requires %{nil}
>
>  [1]
> dnf repoquery yarnpkg --available --requires -q
> /usr/bin/bash
> /usr/bin/node
> /usr/bin/sh
>
> I'm not sure what you think is a bug here? Do you think `yarnpkg`
> should use *any* nodejs version that's installed? The whole point of
> the way this is broken down is that we have a default version (18, in
> this case) with the option to install 16 and 20 in parallel, but you
> have to do extra work if you want to *use* those non-default versions
> (such as patching shebang lines).
>
> This is broken again in rawhide:
>
> $ dnf -qy install yarnpkg
> $ ll /usr/bin/node*
> lrwxrwxrwx. 1 root root 7 Apr 28 00:00 /usr/bin/node -> node-20
> -rwxr-xr-x. 1 root root 28272 Apr 28 00:00 /usr/bin/node-20
> lrwxrwxrwx. 1 root root39 Mar 21 00:00 /usr/bin/nodejs-yarn ->
> ../lib/node_modules_19/yarn/bin/yarn.js
>
> If yarn should be pinned to a node version, please rebuild yarn when
> there's a major version change. And it would be nice if there's a
> mechanism to detect such a breakage. I.e. a nodejs(abi) version or
> something like that.
>
> AFAICS nodejs is generally broken in rawhide (both nodejs20 and nodejs18), 
> i.e. just
>
> $ node
> > 
> Segmentation fault (core dumped)
>
> gdb:
>
> Thread 3 "node" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x72ffe6c0 (LWP 1565850)]
> 0x757db195 in 
> v8::internal::compiler::SpecialRPONumberer::ComputeAndInsertSpecialRPO(v8::internal::compiler::BasicBlock*,
>  v8::internal::compiler::BasicBlock*) () from /lib64/libnode.so.115
>
> Sandro
>
>

True! But I only see this with nodejs20, not with 18. And this happens
also in the updates for F37 and F38.

Another weird thing about current packaging is that the default nodejs
does not provide the versioned package. I mean:

- When 18 is the default version, you can install nodejs16, nodejs,
and nodejs20, but not nodejs18.
- When 20 is the default version, you can install nodejs16, nodejs18,
and nodejs, but not nodejs20.

This seems wrong to me. And it makes it difficult to pin some software
to a particular nodejs version across Fedora releases, which I
understood was the purpose. And, per my last message, it seems you
can't do this anyway if yarn is required...

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

[Iñaki Ucar]

On Tue, 4 Apr 2023 at 16:23, Stephen Gallagher  wrote:
>
> On Tue, Apr 4, 2023 at 9:45 AM Sérgio Basto  wrote:
> >
> > On Thu, 2023-03-16 at 11:19 -0400, Stephen Gallagher wrote:
> > > On Wed, Mar 15, 2023 at 1:16 PM Jerry James 
> ...
> > I found a problem related with yarnpkg rpm, the macro % __find_requires
> > finds that yarn scripts uses and needs /usr/bin/node , which is added
> > to the requires of rpm [1] and this makes yarnpkg pull nodejs (18) even
> > when nodejs20 is installed .
> > To avoid this rpm automatic requires, we may add to yarnpkg.spec [2]
> >
> > [2]
> > %global __script_requires %{nil}
> >
> >  [1]
> > dnf repoquery yarnpkg --available --requires -q
> > /usr/bin/bash
> > /usr/bin/node
> > /usr/bin/sh
> >
>
> I'm not sure what you think is a bug here? Do you think `yarnpkg`
> should use *any* nodejs version that's installed? The whole point of
> the way this is broken down is that we have a default version (18, in
> this case) with the option to install 16 and 20 in parallel, but you
> have to do extra work if you want to *use* those non-default versions
> (such as patching shebang lines).

This is broken again in rawhide:

$ dnf -qy install yarnpkg
$ ll /usr/bin/node*
lrwxrwxrwx. 1 root root 7 Apr 28 00:00 /usr/bin/node -> node-20
-rwxr-xr-x. 1 root root 28272 Apr 28 00:00 /usr/bin/node-20
lrwxrwxrwx. 1 root root39 Mar 21 00:00 /usr/bin/nodejs-yarn ->
../lib/node_modules_19/yarn/bin/yarn.js

If yarn should be pinned to a node version, please rebuild yarn when
there's a major version change. And it would be nice if there's a
mechanism to detect such a breakage. I.e. a nodejs(abi) version or
something like that.

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

[Iñaki Ucar]

On Tue, 11 Apr 2023 at 09:32, Petr Pisar  wrote:
>
> V Sun, Apr 09, 2023 at 11:19:37PM +0200, Iñaki Ucar napsal(a):
> > I'm not sure what could be the issue, but I can reproduce this by
> > creating the simplest hello-world package containing:
> >
> > Recommends: tex(latex)
> >
> > When I build this package and try to install it in Fedora <= 38,
> > texlive is pulled. But nothing else (apart from the package itself) is
> > installed in rawhide.
> >
> "dnf install 'tex(latex)'" gives me 386 packages (with
> texlive-collection-latexrecommended-11:svn65512-69.fc39.noarch root) to
> install in Fedora 39.  Don't you have simply disabled week dependencies
> (install_weak_deps=false) in /etc/dnf/dnf.conf?

No, I don't. Here's a report with a reproducible example:
https://bugzilla.redhat.com/show_bug.cgi?id=2185620

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

[Iñaki Ucar]

I'm not sure what could be the issue, but I can reproduce this by
creating the simplest hello-world package containing:

Recommends: tex(latex)

When I build this package and try to install it in Fedora <= 38,
texlive is pulled. But nothing else (apart from the package itself) is
installed in rawhide.

Iñaki

On Wed, 29 Mar 2023 at 20:46, Tom Callaway  wrote:
>
> Hi Fedora,
>
> TeXLive 2023 (composed of texlive-base and texlive SRPMs) is in rawhide now. 
> I've done local testing to try to make sure it doesn't break anything 
> obvious... but the size and scope of TL means that there are probably still 
> some bugs introduced by this update.
>
> Change wiki page here: https://fedoraproject.org/wiki/Changes/TeXLive2023
>
> Please let me know if something stops building as a result of the new texlive 
> packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, 
> with as much detail as you can provide.
>
> There is at least one clear bug: texlive-texaccents (from texlive-base) will 
> not install at the moment, because it depends on snobol4. Snobol4 is not in 
> Fedora yet, I have made a new package which is pending review (and it 
> shouldn't be a hard review), so help with reviewing would be appreciated:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2182080
>
> Note that texlive-texaccents used to be Python, but upstream decided to 
> rewrite it in SNOBOL. The only thing (I think) that depends on texaccents is 
> texlive-collection-binextra.
>
> I do not plan to push TeXLive 2023 to any stable Fedora, just let it get 
> inherited for Fedora 39+.
>
> Also, this is the fastest I've ever turned around a TeXLive build (mostly 
> because I had just updated most things for 2022 in January).
>
> ~spot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



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

Node.js repackaging status and questions

[Iñaki Ucar]

Hi,

As a brief summary:

- The Node.js repackaging change [1-2] was accepted for F38.
- Packages nodejs16 and nodejs18 were created without any review [3-4] (?).
- Package nodejs20 was created a month ago, but I didn't find any
review request. Why?
- This repackaging has been pushed to F37 too. Why, if this was a F38 change?
- Now we have conflicts in F37 and F38 [5], with FTBFS for those
requiring unversioned nodejs.

It seems to me that there hasn't been a proper review and tracking of
this change.

[1] https://fedoraproject.org/wiki/Changes/NodejsRepackaging
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2130002
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2150093
[4] https://bugzilla.redhat.com/show_bug.cgi?id=2150094
[5] https://bugzilla.redhat.com/show_bug.cgi?id=2179086

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

[Iñaki Ucar]

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


On Thu, 16 Mar 2023 at 16:21, Stephen Gallagher  wrote:
>
> On Wed, Mar 15, 2023 at 1:16 PM Jerry James  wrote:
> >
> > On Wed, Mar 15, 2023 at 11:09 AM Jerry James  wrote:
> > > I see the same with a couple of my packages.  A look at
> > > https://src.fedoraproject.org/rpms/nodejs suggests that we shouldn't
> > > be using BuildRequires: nodejs-devel anymore, but rather
> > > nodejsXX-devel for an appropriate value of XX.  It looks like "20" is
> > > the only currently appropriate value for XX.  I am unsure how that is
> > > supposed to work going forward.
> >
> > Unfortunately, that doesn't fix the 2 cases I am looking at, because
> > they use yarnpkg, and installing yarnpkg pulls nodejs and nodejs-libs
> > into the buildroot, not nodejs20 and nodejs20-libs.
>
>
> nodejs20-* should definitely not be getting pulled in. I probably have
> a bug there (something I missed when forking it from nodejs18)
>
> I suspect that's the root cause: your existing nodejs-devel BR should
> continue to work. You don't need to specify `BuildRequires:
> nodejsXX-devel` unless you need to guarantee a specific version which
> isn't (necessarily) the default one for that release.
>
> Please open a BZ to track this problem; I'll start looking into it.
> Sorry for the disruption!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



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

nodejs broken?

[Iñaki Ucar]

Hi,

RStudio (which depends on nodejs-devel) is FTBFS since the latest
nodejs update. I see this in F37 and F38:

Error: Transaction test error:
  file /usr/lib64/libv8.so.10 conflicts between attempted installs of
nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64
  file /usr/lib64/libv8_libbase.so.10 conflicts between attempted
installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64
  file /usr/lib64/libv8_libplatform.so.10 conflicts between attempted
installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and
nodejs20-libs-1:19.7.0-13.fc37.x86_64

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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Iñaki Ucar]

I've pushed a fix for rstudio to rawhide. Can you please send a build
to the side tag?

Iñaki


On Wed, 22 Feb 2023 at 21:52, Thomas Rodgers  wrote:
>
> The f39-boost side tag builds have finished.
>
> The following packages are new FTBFS likely due to the Boost update -
> - mapnik [[https://bugzilla.redhat.com/show_bug.cgi?id=2172635][PR2172635]] 
> Boost.Phoenix related
> - credentials-fetcher  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172636][PR217636]] 
> Boost.Filesystem related
> - vsomeip3  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172639][PR2172639]] Boost.Asio 
> related
>
> The following packages are still FTBFS from the f38 mass rebuild -
> - 0ad [[https://bugzilla.redhat.com/show_bug.cgi?id=2171424][PR2171424]]
> - cryfs [[https://bugzilla.redhat.com/show_bug.cgi?id=2171464][PR2171464]]
> - folly [[https://bugzilla.redhat.com/show_bug.cgi?id=2165219][PR2165219]]
> - fbthrift [[https://bugzilla.redhat.com/show_bug.cgi?id=2171488][PR2171488]]
> - fast-netmon  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2171487][PR2171487]]
> - nextpnr  [[https://bugzilla.redhat.com/show_bug.cgi?id=2171618][PR2171618]]
> - rstudio [[https://bugzilla.redhat.com/show_bug.cgi?id=2171710][PR2171710]]
> - widelands [[https://bugzilla.redhat.com/show_bug.cgi?id=2171759][PR2171759]]
>
> The following packages are new FTBFS not apparently related to Boost 1.81.0 -
> - condor [[https://bugzilla.redhat.com/show_bug.cgi?id=2172630][PR2172630]]
> - galera  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172633][PR2172633]]
> - gnu-cash  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172637][PR2172637]]
> - inkscape  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172638][PR2172638]]
> - sourcextractor++ 
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172642][PR2172642]]
> - wesnoth [[https://bugzilla.redhat.com/show_bug.cgi?id=2172627][PR2172627]]
>
> The following packages FTBFS but the build logs provide no useful information 
> -
> - blender 
> [[https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log]]
> - hugin  
> [[https://kojipkgs.fedoraproject.org//work/tasks/5732/97785732/build.log][build.log]]
> - libyui-mga-gtk  
> [[https://kojipkgs.fedoraproject.org//work/tasks/3208/97843208/build.log][build.log]]
> - luxcorerender 
> [[https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log]]
> - mcrouter  
> [[https://kojipkgs.fedoraproject.org//work/tasks/7420/97847420/build.log][build.log]]
> - openshadinglanguage 
> [[https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log]]
> - OpenImageIO  
> [[https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log]]
> - usd 
> [[https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log]]
>
> On Mon, Feb 20, 2023 at 9:16 AM Thomas Rodgers  wrote:
>>
>> Builds are starting now.
>>
>> On Thu, Feb 16, 2023 at 9:54 AM Thomas Rodgers  wrote:
>>>
>>> We expect to start rebuilds for 
>>> https://fedoraproject.org/wiki/Changes/F39Boost181
>>> in the f39-boost side tag Monday 2022-02-20.
>>>
>>> If your package depends on Boost, or just if you see a "Rebuilt for
>>> Boost 1.81" commit pushed to your package's dist-git repo, please
>>> coordinate with me about any updates to the package. If you need
>>> to push other changes to rawhide then you will need to build in the
>>> side tag, or we'll have to rebuild it multiple times.
>>>
>>> I expect to complete the builds and request the merge of the f39-boost
>>> side tag by Friday 2022-02-24.
>>>
>>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



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

Re: Fedora Linux 38 branched

[Iñaki Ucar]

On Tue, 14 Feb 2023 at 10:46, Pavel Raiskup  wrote:
>
> On pátek 10. února 2023 11:38:25 CET Iñaki Ucar wrote:
> > On Fri, 10 Feb 2023 at 11:35, Peter Robinson  wrote:
> > >
> > > On Fri, Feb 10, 2023 at 10:27 AM Iñaki Ucar  
> > > wrote:
> > > >
> > > > On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik  wrote:
> > > > >
> > > > > Hello Tomas,
> > > > > thank you for the announcement.
> > > > >
> > > > > We also branched Fedora 38 in Copr so that everybody can submit builds
> > > > > for it by now. Also, all projects with the "Follow Fedora branching"
> > > > > option configured in their project settings have F38 chroots
> > > > > automatically enabled and they contain the last build results from
> > > > > Fedora Rawhide before the branch.
> > > >
> > > > Is this still ongoing? I don't see F38 in my projects.
> > >
> > > I do in all of my packages, you should just need to do a git pull to
> > > get the new branches.
> >
> > I meant in Copr.
>
> Just confirming - Copr branching is a two-phase process;  we first link the
> RPMs from rawhide to the branched release, and then we enable (when we know 
> the
> chroot is building fine).
> https://docs.pagure.org/copr.copr/how_to_manage_chroots.html#branching-process
>
> When Jakub announced, we just had those packages hardlinked, and RPMs 
> available
> on backend.  But the 38 chroots got enabled later (next day).

Ok, got it, thanks.

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

Re: Fedora Linux 38 branched

[Iñaki Ucar]

On Fri, 10 Feb 2023 at 11:35, Peter Robinson  wrote:
>
> On Fri, Feb 10, 2023 at 10:27 AM Iñaki Ucar  wrote:
> >
> > On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik  wrote:
> > >
> > > Hello Tomas,
> > > thank you for the announcement.
> > >
> > > We also branched Fedora 38 in Copr so that everybody can submit builds
> > > for it by now. Also, all projects with the "Follow Fedora branching"
> > > option configured in their project settings have F38 chroots
> > > automatically enabled and they contain the last build results from
> > > Fedora Rawhide before the branch.
> >
> > Is this still ongoing? I don't see F38 in my projects.
>
> I do in all of my packages, you should just need to do a git pull to
> get the new branches.

I meant in Copr.

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

Re: Fedora Linux 38 branched

[Iñaki Ucar]

On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik  wrote:
>
> Hello Tomas,
> thank you for the announcement.
>
> We also branched Fedora 38 in Copr so that everybody can submit builds
> for it by now. Also, all projects with the "Follow Fedora branching"
> option configured in their project settings have F38 chroots
> automatically enabled and they contain the last build results from
> Fedora Rawhide before the branch.

Is this still ongoing? I don't see F38 in my projects.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: How to build two flavors of the same package?

[Iñaki Ucar]

On Tue, 17 Jan 2023 at 22:28, Till Hofmann  wrote:
>
> Hi all,
>
> Someone (rightfully) suggested that we should build glfw twice, once
> with wayland support and once without:
> https://bugzilla.redhat.com/show_bug.cgi?id=2152319
>
> Is there any best practice how to build the same package in two
> different flavors, in this case cmake-based? I vaguely remember seeing a
> spec file that did that, but I don't remember where.
>
> Thanks for any pointers!

In flexiblas.spec, for 64-bit BLAS, we do

%build
%cmake -B build \

%make_build -C build
%if 0%{?__isa_bits} == 64
%cmake -B build64 \

%make_build -C build64
%endif

%install
%make_install -C build
%if 0%{?__isa_bits} == 64
%make_install -C build64
%endif

etc.

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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Iñaki Ucar]

From the point of view of the workstation experience (with a laptop),
I see no discussion on how this may impact hibernation. Currently, I
have secure boot disabled essentially because I want my laptop to
automatically hibernate (and recover from that state) whenever it is
suspended for a number of hours. I would like to see a path forward
here with secure boot enabled.

Thanks,
Iñaki

On Tue, 20 Dec 2022 at 16:22, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
>
> 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 ==
> Add support for unified kernels images to Fedora.
>
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
>
>
> == Detailed Description ==
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead, then shipped as part of a unified kernel image.
>
> A unified kernel image is an all-in-one efi binary containing kernel,
> initrd, cmdline and signature.  The secure boot signature covers
> everything, specifically the initrd is included which is not the case
> when the initrd gets loaded as separate file from /boot.
>
> Main motivation for this move is to make the distro more robust and more 
> secure.
>
> Switching the whole distro over to unified kernels quickly is not
> realistic though.  Too many features are depending on the current
> workflow with a host-specific initrd (and host-specific kernel command
> line), which is fundamentally incompatible with unified kernels where
> everybody will have the same initrd and command line. Thats why there
> is 'Phase 1' in title, so we can have more Phases in future releases
> 
>
> A host-specific initrd / command line is needed today for:
>
> * features needing optional dracut modules (initrd rebuild needed to
> enable them).
> * configuration / secrets baked into the initrd (booting from iscsi
> for example).
> * configuration being specified on the kernel command line.
> ** root filesystem being the most important one.
> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
> allow to remove this.
>
> Phase 1 goals (high priority):
>
> * Ship a unified kernel image as (optional) kernel sub-rpm.  Users can
> opt-in to use that kernel by installing the sub-rpm.  Initial focus is
> on booting virtual machines where we have a relatively small and well
> defined set of drivers / features needed.  Supporting modern physical
> machines with standard setup (i.e. boot from local sata/nvme storage)
> too should be easy.
> * Update kernel install scripts so unified kernels are installed and
> updated properly.
> * Add bootloader support for unified kernel images.  Add
> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
> unified kernel bls support] to grub2, or support using systemd-boot,
> or both.
>
> Phase 1 goals (lower priority, might move to Phase 2):
>
> * Add proper discoverable partitions support to installers (anaconda,
> image builder, ...).
> ** Temporary workaround possible: set types using sfdisk in %post script.
> ** When using btrfs: configure 'root' subvolume as default volume.
> * Add proper systemd-boot support to installers.
> ** Temporary workaround possible: run 'bootctl install' in %post script.
> * Better measurement and remote attestation support.
> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
> allow pre-calculate TPM PCR values.
> ** avoid using grub2 (measures every config file line executed which
> is next to impossible to pre-calculate).
> * Switch cloud images to use unified kernels.
>
> Phase 2/3 goals (longer-term stuff which is not realistic to complete for 
> F38).
>
> * Move away from using the kernel command line for configuration.
> * Move away from storing secrets in the initrd.
> * Handle dracut optional modules in a different way.
>
> systemd has some building blocks which can be used, although none of
> them are used by fedora today.
> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> systemd credentials] can be used for secrets (also for configuration).
> The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html
> unified kernel stub] can load credentials from the ESP.
>
> The unified kernel stub can also load
> [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
> extensions] from the ESP, which can possibly be used to replace
> optional dracut modules.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> * Better secure boot support (specifically the initrd is covered by
> the signature).
> * Better confidential computing support (measurements are much more
> useful if we know what hashes to expect for the 

Re: MuseScore 4.0

[Iñaki Ucar]

On Mon, 19 Dec 2022 at 23:17, Jerry James  wrote:
>
> On Fri, Dec 16, 2022 at 3:36 PM Iñaki Ucar  wrote:
> > Unfortunately, the playback seems to be broken. The mixer doesn't show
> > SoundFonts and there's no audio at all. :(
>
> Yes, my attempt at unbundling fluidsynth seems to be at fault.  Drat.
> I may or may not have time to debug this before I disappear for the
> rest of the year.  Most likely I'll have to figure it out and try
> again next year.  Thanks for trying it.

I managed to download the Muse Sounds, and they work. Only the basic
sounds are broken. It seems that they are not loaded. Just in case
this rings any bell.

Other differences I found with respect to the AppImage: the splash
screen doesn't show up in the Copr version, and the "Learn" materials
in the Home tab do not load.

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

[Iñaki Ucar]

On Thu, 15 Dec 2022 at 19:40, Jerry James  wrote:
>
> MuseScore is music composition and notation software, currently
> available from Fedora in the mscore package. Version 4.0 was just
> released.  If anybody would like to try it out, it is available from
> this COPR: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/.
> I do not intend to build for Fedora until some issues have been worked
> out.

Thanks for this! Testing while watching the latest Tantacrul video. :)

> WARNING!  WARNING!  WARNING!
> DO NOT TRY THIS IN A WAYLAND SESSION. It will run for anywhere from a
> few seconds to a few minutes, then abruptly exit with a "Protocol
> error".  Run an X session to try MuseScore 4.0.
> WARNING!  WARNING!  WARNING!
>
> WARNING!  WARNING!  WARNING!
> Configuration for MuseScore 3.x and 4.x differs in some important
> respects.  You may have to do a "factory reset" when switching
> versions.  Run "mscore -R" or "mscore -F" if it won't start.  This
> will clear out your list of recently opened scores, for example, so
> backup your configuration before you do this.
> WARNING!  WARNING!  WARNING!
>
> To try it out, run:
>
> sudo dnf copr enable jjames/MuseScore4
> sudo dnf install musescore
>
> Please try the video export option, which has bitrotted upstream. I
> have attempted to update it for current ffmpeg. Please let me know if
> it does or does not work for you. If it works well, I will submit my
> patch upstream.  Do this: "mscore --score-video  -o
> filename.mp4", and optionally try the --resolution and --fps
> arguments.  Run "mscore --help" for more information.  This
> functionality does not seem to be available via the GUI.
>
> Upstream bundles fluidsynth, apparently for the sole purpose of
> implementing a caching soundfont loader that uses internal fluidsynth
> APIs. I have unbundled fluidsynth for this repository, which means
> there is no soundfont cache. If you switch soundfonts frequently,
> please let me know if the performance is acceptable. If you are
> familiar with the fluidsynth API and can implement a caching soundfont
> loader using only public APIs, please do so and submit it upstream.

Unfortunately, the playback seems to be broken. The mixer doesn't show
SoundFonts and there's no audio at all. :(

Iñaki

> Several other products are bundled (beatroot-vamp, dtl, intervaltree,
> rtf2html, and KDDockWidgets).  Each of them has either been altered by
> the MuseScore developers or, in the case of KDDockWidgets, internal
> APIs are used so extensively that I cannot see how to unbundle
> successfully.  Thoughts on how any of these products might be
> unbundled are welcome.
>
> The COPR version makes a long-requested change: the package name
> changes from mscore to musescore.  Let me know if you encounter any
> problems arising from that change.
>
> A new font package is needed to build version 4.0 for Fedora.  I would
> appreciate a review from anybody who feels competent to review a font
> package: https://bugzilla.redhat.com/show_bug.cgi?id=2152347.  There
> is a question about the appropriate foundry name.  If you can help
> answer that question, please chime in.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



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

Re: Fedora Review Service

[Iñaki Ucar]

On Fri, 2 Dec 2022 at 18:21, Jakub Kadlcik  wrote:
>
> Hello folks,
>
> for a couple of years now, I've been interested in the Fedora package
> review process. Our queue is in hundreds of waiting packages for as
> long as I can remember. I believe the situation can be improved.
>
> Since summer, I did ~40 package reviews to get a better grasp of the
> situation and realized what I want to do.
>
> I started working on a service [2] that listens to fedora-messaging
> and for every new RHBZ review ticket or a new comment with updated
> packages, it submits a build in Copr. Thanks to this [1] feature, Copr
> automatically runs the fedora-review tool and generates the
> review.txt file. Once the build is finished, my service gets the
> message and generates a helpful comment (so far only to STDOUT).
>
> **Unless there is general disapproval, I am planning to let it post
> the comments to Bugzilla.**

Yes, please! This seems like a **very** helpful service to me. Thanks
for this! :)

Iñaki

> So far the benefit is limited but, it still can immediately tell the
> contributor that their package is broken and fails to build, and also
> saves a reviewer the time of running the fedora-review tool
> manually. However, I also implemented support for the fedora-review
> tool to generate a JSON output next to the standard review.txt. The PR
> is still pending [2], please review it if you can. Once this is
> released, I can parse its contents and generate much helpful comments
> for the contributors.
>
> The end goal is to let contributors go back and forth against the CI
> to fix the most obvious mistakes and then let the reviewers take
> only the final look.
>
> Hopefully, it will be a better experience for everyone.
>
>
> [1] http://frostyx.cz/posts/running-fedora-review-after-copr-build
> [2] https://github.com/FrostyX/fedora-review-service
> [3] https://pagure.io/FedoraReview/pull-request/463
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



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

Review swap

[Iñaki Ucar]

Hi everyone,

Here's an easy one: https://bugzilla.redhat.com/show_bug.cgi?id=2140316
Happy to review something in exchange.

Best,
-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: PSA: Rawhide KDE users, do not update

[Iñaki Ucar]

On Thu, 3 Nov 2022 at 20:34, Gary Buhrmaster  wrote:
>
> On Thu, Nov 3, 2022 at 6:34 PM Adam Williamson
>  wrote:
>
> > Thanks to Aleix Pol, we figured this was due to a missing rebuild of
> > layer-shell-qt , which uses private Qt symbols and so needs rebuilding
> > for each new Qt version. I did that rebuild and KDE's fine again in
> > today's Rawhide, so resume updating. :D
>
> Good catch.
>
> That brings up a question.  Is there any usable
> (automated) tooling/specifications that should/can
> have made the use of private apis be identified
> such that the lack of rebuild does not happen in
> the future for this, or another, package(*)(**)?
> Manual checking of all spec files looking for a
> BR of the Qt private headers sounds prone to
> error.

Packages using Qt private headers usually raise a FTI bug report.
Wasn't this the case with this update?

Iñaki

>
> Thanks.
>
> (*) For the next time, and there will be a next
> time.
>
> (**) Some of the Qt private apis seems somewhat
> stable, but that is only until they are not.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Confused by packager dashboard: FTBFS (source)

[Iñaki Ucar]

I opened an issue in the dashboard repo for the same reason some weeks ago.
It turns out there's a limitation on detecting these cases, so Fabio
maintains a whitelist.

Iñaki

El sáb., 24 sept. 2022 4:19, Richard Shaw  escribió:

> I've really been enjoying using the dashboard, it's pointed out things
> that I quite frankly forgot about.
>
> For python-pyside2 though it's showing FTBFS at the source level due to
> qt5-qtwebengine not being built for ppc64le and s390x, but I have a
> %ifnarch conditional removing it from the build requirements for those
> arches.
>
> After convincing myself that it must be being pulled in from another
> package I tried playing around with installing qtwebengine by starting a
> build of pyside2 in a mock chroot and shelling into it, but I was able to
> rpm -e it without conflicts with other installed packages.
>
> I then tried a scratch build which largely succeeded, all arches built but
> s390x failed during %check.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=92294488
>
> So what gives?
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

Here we go:

- F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8414514ae6
- rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c2d48988e

After the mass rebuild in the F37 side tag, we tagged all builds also
in a rawhide side tag, rebuilt everything in one go, untagged the F37
builds, and created the update for rawhide. Quick and easy.

Thanks all for your help.
Iñaki

On Wed, 24 Aug 2022 at 19:04, Kevin Fenzi  wrote:
>
> Just to chime in from a releng perspective here...
>
> IMHO you should do builds for f38 now also (either by making a side tag
> and bootstrapping them just like was done for f37, or tagging f37 builds
> you need into the f38 sidetag).
>
> While it's technically possible to push the f37 builds into rawhide
> also, it would take releng manually tagging them in, bypassing bodhi,
> gating and CI completely. It's much better to build again for
> f38/rawhide and let those builds get checked by gating and CI, etc.
>
> If you run into any problems, let me know...
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packages silently dropping approved changes

[Iñaki Ucar]

The current status is:

- opentoonz: was adapted in
https://src.fedoraproject.org/rpms/opentoonz/pull-request/1, built and
updated
- openmeeg: was re-adapted in
https://src.fedoraproject.org/rpms/openmeeg/pull-request/2, built and
updated

Thanks Diego and Antonio for your quick response.

- freefem++: a re-adaptation was proposed in
https://src.fedoraproject.org/rpms/freefem++/pull-request/2

I would also like to note that freefem's current configuration has
many issues, as can be seen in the linking result:

$ ldd /usr/bin/FreeFem++
   [snip]
   liblapack.so.3 => /lib64/liblapack.so.3 (0x7f4969c0)
   libopenblas.so.0 => /lib64/libopenblas.so.0 (0x7f4967828000)
   [snip]
   libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x7f496680)
   [snip]
   libblas.so.3 => /lib64/libblas.so.3 (0x7f4967626000)
   [snip]

The final binary links to 4 different libraries with an overlapping
set of symbols. At the same time, other libraries used by freefem
(such as arpack, suitesparse, etc.) are using libflexiblas. So this
situation is far from ideal, because mixing them is not a good idea.
The patch linked above solves this and produces a clean list of
dependencies.

Iñaki


On Fri, 26 Aug 2022 at 15:44, Ben Beasley  wrote:
>
> The policies specifying use of FlexiBLAS[1] are full of MUSTs; you can’t just 
> opt out and reject all prospective PRs out of hand. If someone can get the 
> package working with FlexiBLAS, you should accept a PR. If you think 
> freefem++ needs to be exempt from the requirement, you should open an FPC 
> ticket[2] explaining why and requesting an explicit exception.
>
> [1] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/#_packaging_blaslapack_dependent_packages
> [2] https://pagure.io/packaging-committee/issues
>
> On Thu, Aug 25, 2022, at 6:36 PM, Ralf Corsépius wrote:
> > Am 25.08.22 um 23:00 schrieb Iñaki Ucar:
> >> On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
> >>>
> >>> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> >>>>
> >>>> Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> >>>>
> >>>>> I assume their maintainers didn't do it on purpose, maybe it was
> >>>>> easier for a certain update, didn't have time to look into it and
> >>>>> weren't aware of the guideline. But this is very frustrating. Seeing
> >>>>> many hours of work just wiped out without any notice or explanation is
> >>>>> very frustrating.
> >>>>
> >>>> In my case (freefem++), it was actually was a mixture of all.
> >>>>
> >>>> To cut a long story short: This flexblas stuff doesn't "harmonize well"
> >>>> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> >>>>
> >>>> Because of this, when going after freefem++'s regressions, years after
> >>>> the flexiblas changes had been introduced, I inadvertedly and
> >>>> accidentally reverted the flexblas related changes, because these
> >>>> apparently do not work out with freefem++.
> >>>
> >>> How exactly does flexiblas break freefem++? I see v4.10 was built just
> >>> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> >>> see no reason to break with flexiblas, among other things because
> >>> openblas is the default backend. Moreover, arpack, superlu,
> >>> suitesparse and other BuildRequires link against flexiblas.
> >>
> >> In fact, freefem++ was one of the easiest packages to adapt: you just
> >> set the library, and it does nothing fancy nor too-clever to try to
> >> discover anything.
> > Then you haven't looked into details (build.log rsp. config.status).
> >
> > flexiblas causes freefem's configure script to produce bogus results.
> >
> >
> > Here's a simple patch [1] and a successful scratch
> >> build [2], with all checks passing. Please let me know if I'm missing
> >> anything, but otherwise, I'll open a PR.
> > Please don't and also abstain from submitting pull requests.
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/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 

Re: Packages silently dropping approved changes

[Iñaki Ucar]

On Fri, 26 Aug 2022 at 00:44, Ralf Corsépius  wrote:
>
>
>
> Am 25.08.22 um 23:00 schrieb Iñaki Ucar:
> > On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
> >>
> >> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> >>>
> >>> Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> >>>
> >>>> I assume their maintainers didn't do it on purpose, maybe it was
> >>>> easier for a certain update, didn't have time to look into it and
> >>>> weren't aware of the guideline. But this is very frustrating. Seeing
> >>>> many hours of work just wiped out without any notice or explanation is
> >>>> very frustrating.
> >>>
> >>> In my case (freefem++), it was actually was a mixture of all.
> >>>
> >>> To cut a long story short: This flexblas stuff doesn't "harmonize well"
> >>> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> >>>
> >>> Because of this, when going after freefem++'s regressions, years after
> >>> the flexiblas changes had been introduced, I inadvertedly and
> >>> accidentally reverted the flexblas related changes, because these
> >>> apparently do not work out with freefem++.
> >>
> >> How exactly does flexiblas break freefem++? I see v4.10 was built just
> >> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> >> see no reason to break with flexiblas, among other things because
> >> openblas is the default backend. Moreover, arpack, superlu,
> >> suitesparse and other BuildRequires link against flexiblas.
> >
> > In fact, freefem++ was one of the easiest packages to adapt: you just
> > set the library, and it does nothing fancy nor too-clever to try to
> > discover anything.
> Then you haven't looked into details (build.log rsp. config.status).

Could you please describe the issues?

> flexiblas causes freefem's configure script to produce bogus results.

If you are referring to this line

configure: -- NO ARPACK --  enable_download : no , wget: yes

then I have good news. I think we can agree that the configure script
is a mess. It just needed a simple fix to make that test successful,
namely, to substitute -llapack with -lflexiblas. Please take a look at
https://koji.fedoraproject.org/koji/taskinfo?taskID=91264332. I see no
differences in the list of "configure: ++ " that the script
produces

> Here's a simple patch [1] and a successful scratch
> > build [2], with all checks passing. Please let me know if I'm missing
> > anything, but otherwise, I'll open a PR.
> Please don't and also abstain from submitting pull requests.

I'm sorry, I'm trying to help here. But it's difficult if I don't know
the specific trouble you run into.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packages silently dropping approved changes

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:
>
> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
> >
> > Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
> >
> > > I assume their maintainers didn't do it on purpose, maybe it was
> > > easier for a certain update, didn't have time to look into it and
> > > weren't aware of the guideline. But this is very frustrating. Seeing
> > > many hours of work just wiped out without any notice or explanation is
> > > very frustrating.
> >
> > In my case (freefem++), it was actually was a mixture of all.
> >
> > To cut a long story short: This flexblas stuff doesn't "harmonize well"
> > with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
> >
> > Because of this, when going after freefem++'s regressions, years after
> > the flexiblas changes had been introduced, I inadvertedly and
> > accidentally reverted the flexblas related changes, because these
> > apparently do not work out with freefem++.
>
> How exactly does flexiblas break freefem++? I see v4.10 was built just
> fine. Then v4.11 reverted to openblas. If it works with openblas, I
> see no reason to break with flexiblas, among other things because
> openblas is the default backend. Moreover, arpack, superlu,
> suitesparse and other BuildRequires link against flexiblas.

In fact, freefem++ was one of the easiest packages to adapt: you just
set the library, and it does nothing fancy nor too-clever to try to
discover anything. Here's a simple patch [1] and a successful scratch
build [2], with all checks passing. Please let me know if I'm missing
anything, but otherwise, I'll open a PR.

[1] 
https://src.fedoraproject.org/fork/iucar/rpms/freefem++/c/a9da37dfd71508b4bad124fdbfd190b417f0afb2
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=91253729

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packages silently dropping approved changes

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:
>
> Am 25.08.22 um 13:19 schrieb Iñaki Ucar:
>
> > I assume their maintainers didn't do it on purpose, maybe it was
> > easier for a certain update, didn't have time to look into it and
> > weren't aware of the guideline. But this is very frustrating. Seeing
> > many hours of work just wiped out without any notice or explanation is
> > very frustrating.
>
> In my case (freefem++), it was actually was a mixture of all.
>
> To cut a long story short: This flexblas stuff doesn't "harmonize well"
> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.
>
> Because of this, when going after freefem++'s regressions, years after
> the flexiblas changes had been introduced, I inadvertedly and
> accidentally reverted the flexblas related changes, because these
> apparently do not work out with freefem++.

How exactly does flexiblas break freefem++? I see v4.10 was built just
fine. Then v4.11 reverted to openblas. If it works with openblas, I
see no reason to break with flexiblas, among other things because
openblas is the default backend. Moreover, arpack, superlu,
suitesparse and other BuildRequires link against flexiblas.

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

Packages silently dropping approved changes

[Iñaki Ucar]

Hi all,

Many of you know that proposing, discussing, and implementing a change
proposal is quite an effort, especially if you do this in your spare
time. I did this some releases ago in [1] to try to improve the
situation regarding BLAS/LAPACK management in Fedora. It wasn't easy,
but it was a success, and now we have specific packaging guidelines
[2] and one of the best BLAS/LAPACK stacks out there IMHO.

Given that this is not so common, I routinely (every now and then, not
very often) check for new packages that may not be aware of this
guideline, so that they may need adaptation. What I didn't expect was
to find already adapted packages silently dropping this change, and
going back to linking specific libraries instead of FlexiBLAS. :(

I assume their maintainers didn't do it on purpose, maybe it was
easier for a certain update, didn't have time to look into it and
weren't aware of the guideline. But this is very frustrating. Seeing
many hours of work just wiped out without any notice or explanation is
very frustrating.

I opened the corresponding BZ [3-4], but it would be great if these
checks and BZ could be automated somewhere. If so, please let me know
where the proper place for this is and I'll open an issue.

[1] https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2121388
[4] https://bugzilla.redhat.com/show_bug.cgi?id=2121389

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Check out the Fedora Packager Dashboard!

[Iñaki Ucar]

On Thu, 25 Aug 2022 at 11:49, Artur Frenszek-Iwicki
 wrote:
>
> While I really like the idea, I find the interface to be... how do I put it?
> Non-obvious and not very discoverable.
>
> For example, at the top of the page, there's a bunch of numbers. I have no 
> idea what they mean.
> Hovering over each of these displays a tooltip - which is nice - but five 
> seconds after that tooltip disappears,
> I'll forget the meaning and the numbers will go back to being visual clutter. 
> It would be immensely helpful
> to have some symbolic icons next to the numbers, which would allow to easily 
> guess what each of them means.
> Right now I pretty much have to memorize the layout.

Which browser are you using? There *are* icons, and the tooltips do
not disappear for me.

Iñaki

>
> The same goes for the comment/karma numbers and priority markings on the list 
> of bugs.
> Although here it's actually a bit worse, since my browser doesn't display the 
> tooltips
> and I had to use the dev tools to take a look at the underlying HTML to make 
> sense of it.
>
> Similarly, at the top of the page, I get a banner that informs me about FAS 
> integration and says:
> > After linking the dashboard with your FAS through the settings menu...
> Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" 
> gives exactly one match -
> that being the text in the banner. So there's no visible link to said 
> "settings menu" anywhere.
> How do I access it?
>
> All in all, while this is a very useful project, the current UI makes it hard 
> to make the best of it.
>
> A.FI.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 12:39, Petr Pisar  wrote:
>
> > So if the rawhide rebuild can be based on the result of the F37 side tag,
> > then bootstrapping etc. is not required, and the rebuild is fast and
> > straightforward. More so if no commits are needed.
> >
> This optimization is also possible.

Nice! And how would this work? It is a
you-need-help-from-releng-possible or an option-to-koji-possible? The
--repo-id option to "koji build" seems promising.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 12:04, Miro Hrončok  wrote:
>
> On 24. 08. 22 10:58, Iñaki Ucar wrote:
> > Thanks. The main issue is that there are circular dependencies, and it
> > requires bootstrapping in some cases and disabling the checks in
> > others, and then another pass to reenable everything. So if the
> > rawhide rebuild can be based on the result of the F37 side tag, then
> > bootstrapping etc. is not required, and the rebuild is fast and
> > straightforward. More so if no commits are needed.
>
> Either use the f37 builds or use the existing bootstrap commits. It is not
> necessary to build from the latest commit.

How is that done? I don't see any arguments to "fedpkg build" to
specify the commit and I assumed that it uses the remote HEAD. Does it
honor the local HEAD?

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

And now with the attachments... Classic.

On Wed, 24 Aug 2022 at 11:28, Iñaki Ucar  wrote:
>
> On Wed, 24 Aug 2022 at 10:59, Fabio Valentini  wrote:
> >
> > On Wed, Aug 24, 2022 at 10:39 AM Petr Pisar  wrote:
> > >
> > > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > > Hi all,
> > > >
> > > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > > for a few weeks now, where packages are being rebuilt as time permits.
> > > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > > this side tag could be safely merged both in F37 and rawhide when it
> > > > is ready.
> > > >
> > > I think you can tag any package anywhere. Therefore should be possible to 
> > > get
> > > the same build into both Fedoras.
> > >
> > > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > > macros). To mitigate it I think you can rebuild the packages in a F38 
> > > side tag
> > > without additional commits. Just follow the order which was used in F37 
> > > side
> > > tag. The commits exist both in F37 and F38 git branches. F38 builds will 
> > > get
> > > unique release strings due to differing %dist tag.
> >
> > When I was in a similar situation around the F37 branch point, releng
> > told me that while it would be *possible* for them to tag builds into
> > f38, it is possibly ill-advisable, for some of the reasons Petr
> > mentioned here, but also, the packages will get signed with the f37
> > key and not the f38 key, which will create another set of problems
> > down the line.
> >
> > Iñaki, do you have a list of packages that still needs to be rebuilt for 
> > f37?
> > I have provenpackager rights and could handle those builds for you,
>
> Thank you very much, but note that @spot (in cc) is slowly working
> through the packages, so maybe it's best to coordinate with him.
>
> > if you give me
> >
> > - name of the side tag
>
> f37-build-side-55653
>
> > - packages that still need to be rebuilt
>
> blist-37.txt attached, but note this may change if @spot sends new builds.
>
> > - which order they need to be built in (or at least how to determine an 
> > order)
>
> blist-37.txt contains batches of packages to be built in order, one
> per line. This was obtained by
>
> 1. cloning all the packages,
> 2. sed'ing the specs to set "%bcond_without bootstrap" and
> "%bcond_with checks" in those specs that contain the opposite (not
> sure if there is any other edge case),
> 3. evaluating the specs to get the BuildRequires, and finally
> 4. using these to get these dependent batches of packages.
>
> The script is in https://pagure.io/R/packaging (in R, sorry). Finally,
> I filtered out the packages that are currently in the side tag.
>
> > - what changelog message / commit message to use for the dist-git commits
>
> @spot is using just "R 4.2.1".
>
> > And for rawhide / f38, I'd need the same, but the list of *all*
> > packages that need to be built, not only the ones that are still
> > missing from f38.
>
> blist-38.txt attached. Again, one batch per line. If this rebuild
> could be based on the prior one, then there would be no need to do
> batches though.
>
> > I'll probably write a short script to handle the actual task and let
> > it run in the background today.
> >
> > Sorry for not volunteering earlier, but I'm already at my limits wrt/
> > time I can spend on Fedora.
>
> No need to apologise. On the contrary, it's very generous of you
> considering all the things you have on your plate already.
>
> --
> Iñaki Úcar



-- 
Iñaki Úcar
R-arules R-car R-mvtnorm R-ncdf4 R-NISTunits R-nws R-packrat R-parallelly 
R-pbapply R-pbdRPC R-preprocessCore R-prettyunits R-qtl R-quadprog 
R-RColorBrewer R-Rcompression R-Rcpp R-RhpcBLASctl R-Rhtslib R-RInside R-rjson 
R-rlecuyer R-RODBC R-Rsolid R-rsvg R-scatterplot3d R-sciplot R-sfsmisc R-snow 
R-sys R-tkrplot R-udunits2 R-uuid R-waveslim R-wavethresh R-widgetTools R-zoo
R-ape R-Cairo R-caTools R-foreach R-fts R-htmltools R-hunspell R-lmtest 
R-lokern R-markdown R-MatrixGenerics R-mnormt R-msm R-pbdZMQ R-plogr R-poLCA 
R-randomForest R-RcppCCTZ R-RcppDate R-rgdal R-rprintf R-S4Vectors R-sandwich 
R-statnet.common R-stringdist R-sysfonts R-tkWidgets R-webp
R-Biobase R-BiocIO R-doMC R-itertools R-mapproj R-orcutt R-RM2 R-showtextdb 
R-systemfit R-tinytex R-vcd R-whisker
R-blob R-pkgbuild R-R.cache R-R.devices R-showtext
R-doParallel R-gdata R-IRanges R-lambda.r R-timeDa

Re: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 10:59, Fabio Valentini  wrote:
>
> On Wed, Aug 24, 2022 at 10:39 AM Petr Pisar  wrote:
> >
> > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > Hi all,
> > >
> > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > for a few weeks now, where packages are being rebuilt as time permits.
> > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > this side tag could be safely merged both in F37 and rawhide when it
> > > is ready.
> > >
> > I think you can tag any package anywhere. Therefore should be possible to 
> > get
> > the same build into both Fedoras.
> >
> > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > macros). To mitigate it I think you can rebuild the packages in a F38 side 
> > tag
> > without additional commits. Just follow the order which was used in F37 side
> > tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> > unique release strings due to differing %dist tag.
>
> When I was in a similar situation around the F37 branch point, releng
> told me that while it would be *possible* for them to tag builds into
> f38, it is possibly ill-advisable, for some of the reasons Petr
> mentioned here, but also, the packages will get signed with the f37
> key and not the f38 key, which will create another set of problems
> down the line.
>
> Iñaki, do you have a list of packages that still needs to be rebuilt for f37?
> I have provenpackager rights and could handle those builds for you,

Thank you very much, but note that @spot (in cc) is slowly working
through the packages, so maybe it's best to coordinate with him.

> if you give me
>
> - name of the side tag

f37-build-side-55653

> - packages that still need to be rebuilt

blist-37.txt attached, but note this may change if @spot sends new builds.

> - which order they need to be built in (or at least how to determine an order)

blist-37.txt contains batches of packages to be built in order, one
per line. This was obtained by

1. cloning all the packages,
2. sed'ing the specs to set "%bcond_without bootstrap" and
"%bcond_with checks" in those specs that contain the opposite (not
sure if there is any other edge case),
3. evaluating the specs to get the BuildRequires, and finally
4. using these to get these dependent batches of packages.

The script is in https://pagure.io/R/packaging (in R, sorry). Finally,
I filtered out the packages that are currently in the side tag.

> - what changelog message / commit message to use for the dist-git commits

@spot is using just "R 4.2.1".

> And for rawhide / f38, I'd need the same, but the list of *all*
> packages that need to be built, not only the ones that are still
> missing from f38.

blist-38.txt attached. Again, one batch per line. If this rebuild
could be based on the prior one, then there would be no need to do
batches though.

> I'll probably write a short script to handle the actual task and let
> it run in the background today.
>
> Sorry for not volunteering earlier, but I'm already at my limits wrt/
> time I can spend on Fedora.

No need to apologise. On the contrary, it's very generous of you
considering all the things you have on your plate already.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 10:49, Petr Pisar  wrote:
>
> V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > Hi all,
> >
> > We have a new R version sitting on a side tag (f37-build-side-55653)
> > for a few weeks now, where packages are being rebuilt as time permits.
> > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > this side tag could be safely merged both in F37 and rawhide when it
> > is ready.
> >
> I think you can tag any package anywhere. Therefore should be possible to get
> the same build into both Fedoras.
>
> However, it could be unsafe (e.g. a change in C toolchain to distribution
> macros). To mitigate it I think you can rebuild the packages in a F38 side tag
> without additional commits. Just follow the order which was used in F37 side
> tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> unique release strings due to differing %dist tag.

Thanks. The main issue is that there are circular dependencies, and it
requires bootstrapping in some cases and disabling the checks in
others, and then another pass to reenable everything. So if the
rawhide rebuild can be based on the result of the F37 side tag, then
bootstrapping etc. is not required, and the rebuild is fast and
straightforward. More so if no commits are needed.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 04:56, Maxwell G  wrote:
>
> On Tuesday, August 23, 2022 1:16:00 PM CDT Iñaki Ucar wrote:
> > We have a new R version sitting on a side tag (f37-build-side-55653)
> > for a few weeks now, where packages are being rebuilt as time permits.
>
> Can this perhaps be handled differently next time? I admit that I'm not
> familiar with the R ecosystem, so the answer may be no. Side tags are not
> meant to be open for this long. So far, this R rebuild has caused a lot of
> problems (see "The R stack in Rawhide is on fire"). What are the issues that
> prevent the rebuild from happening all at once?

Time and provenpackager hands. The lack of them, to be precise.

> Can it be staged in COPR to
> make sure nothing will break? Can the packages be built all at once with a
> script?

Sure, but this is additional work that, again, requires time. See above.

We are in the process of creating a SIG, a FAS group (already done),
and adding commit access to this group to all the R software, so that
more time and more hands can be invested in the future. But yet again,
this requires time, and people were a bit overloaded already. So it is
what it is for now.

> > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > this side tag could be safely merged both in F37 and rawhide when it
> > is ready.
>
> I'll defer to the releng folks, but I think you should be able to merge the
> sidetag normally through the Bodhi interface, though it will be for f37 and
> not rawhide. You'll have to rebuild everything in rawhide.

We expected that much for F37, we just hoped that the latter could be avoided.

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

F37 side tag after branching point

[Iñaki Ucar]

Hi all,

We have a new R version sitting on a side tag (f37-build-side-55653)
for a few weeks now, where packages are being rebuilt as time permits.
Unfortunately, F37 is not rawhide anymore, so the question is whether
this side tag could be safely merged both in F37 and rawhide when it
is ready.

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

Re: The R stack in Rawhide is on fire

[Iñaki Ucar]

On Tue, 2 Aug 2022 at 18:47, Miro Hrončok  wrote:
>
> Hello folks,
>
> looks like R was update to 4.2 in a side tag, but a rebuild for ICU 71.1
> shipped it in Rawhide prematurely. As a result, none of the R-* package 
> installs.

OMG

> I wonder if we shall revert the 4.2 update in dist-git and rebuild 4.1 with
> ICU 71.1 now.

To begin with, untag Frantisek's build from f37, please. Tom prepared
the side tag to rebuild the packages there, but I believe he's not
currently available. I can't take care of this yet because we are
still waiting for [1-2].

[1] https://pagure.io/fedora-infrastructure/issue/10800
[2] https://pagure.io/fesco/issue/2815

Iñaki

>
> $ repoquery -q --repo=koji --whatrequires 'R(ABI) = 4.1' | wc -l
> 395
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2114067,2114068,2114069,2114070,2114071,2114072,2114073,2114074,2114075,2114076,2114077,2114078,2114079,2114080,2114081,2114082,2114083,2114084,2114085,2114086,2114087,2114088,2114089,2114090,2114091,2114092,2114093,2114094,2114095,2114096,2114097,2114099,2114100,2114101,2114102,2114103,2114104,2114105,2114106,2114107,2114108,2114109,2114110,2114111,2114112,2114113,2114114,2114115,2114116,2114117,2114118,2114119,2114120,2114121,2114122,2114123,2114124,2114125,2114126,2114127,2114128,2114129,2114130,2114131,2114132,2114133,2114134,2114135,2114136,2114137,2114138,2114139,2114140,2114141,2114142,2114143,2114144,2114145,2114146,2114147,2114148,2114149,2114150,2114151,2114152,2114153,2114154,2114155,2114156,2114157,2114158,2114159,2114160,2114161,2114162,2114163,2114164,2114165,2114166,2114167,2114168,2114169,2114170,2114171,2114172,2114173,2114174,2114175,2114176,2114177,2114178,2114179,2114180,2114181,2114182,2114183,2114184,2114186,2114187,2114188,2114189,2114190,2114191,2114192,2114193,2114194,2114195,2114196,2114197,2114198,2114199,2114200,2114201,2114202,2114203,2114204,2114205,2114206,2114207,2114208,2114209,2114210,2114211,2114212,2114213,2114214,2114216,2114217,2114218,2114219,2114220,2114221,2114222,2114223,2114224,2114225,2114226,2114227,2114228,2114229,2114230,2114231,2114232,2114233,2114234,2114235,2114236,2114237,2114238,2114239,2114240,2114241,2114242,2114243,2114244,2114245,2114246,2114247,2114248,2114249,2114250,2114251,2114252,2114253,2114254,2114255,2114256,2114257,2114258,2114259,2114260,2114261,2114262,2114263,2114264,2114265,2114266,2114267,2114268,2114269,2114270,2114271,2114272,2114273,2114274,2114275,2114276,2114277,2114278,2114279,2114280,2114281,2114282,2114283,2114284,2114285,2114286,2114287,2114288,2114289,2114290,2114291,2114292,2114293,2114294,2114295,2114296,2114297,2114298,2114299,2114300,2114301,2114302,2114303,2114304,2114305,2114306,2114307,2114308,2114309,2114310,2114311,2114312,2114313,2114314,2114315,2114316,2114317,2114318,2114319,2114320,2114321,2114322,2114323,2114324,2114326,2114327,2114328,2114329,2114331,2114332,2114333,2114334,2114335,2114337,2114338,2114339,2114340,2114342,2114343,2114344,2114345,2114346,2114347,2114348,2114349,2114350,2114352,2114354,2114356,2114357,2114358,2114359,2114360,2114361,2114362,2114363,2114364,2114365,2114366,2114367,2114368,2114369,2114370,2114371,2114372,2114373,2114374,2114375,2114376,2114377,2114378,2114379,2114380,2114381,2114382,2114383,2114384,2114385,2114386,2114387,2114388,2114389,2114390,2114391,2114392,2114393,2114394,2114395,2114396,2114397,2114398,2114399,2114400,2114401,2114402,2114403,2114404,2114405,2114406,2114407,2114408,2114409,2114410,2114411,2114412,2114413,2114414,2114415,2114416,2114417,2114418,2114419,2114420,2114421,2114422,2114423,2114424,2114425,2114426,2114427,2114428,2114429,2114430,2114432,2114433,2114434,2114435,2114436,2114437,2114438,2114439,2114440,2114441,2114442,2114443,211,2114445,2114446,2114447,2114448,2114449,2114450,2114451,2114452,2114453,2114454,2114455,2114456,2114457,2114458,2114459,2114460,2114461,2114462,2114463,2114464,2114465,2114466,2114467,2114468,2114469,2114470,2114471
>
> --
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the 

Re: Announcing fmt library soversion bump

[Iñaki Ucar]

On Tue, 19 Jul 2022 at 11:38, Vitaly Zaitsev via devel
 wrote:
>
> On 19/07/2022 01:28, Miro Hrončok wrote:
> > I see https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee990d1f61 was
> > pushed with just a handful of builds, while many others are broken. What
> > happened here?
>
> Maintainers had 1 week to rebuild all their packages. Most did nothing.
> Blame them, not me.
>
> I did my best: announced it in ML, waited 1 week, asked for the
> provenpackager assistance multiple times both in ML and IRC/Matrix. No
> one volunteered to help me.

As a suggestion for the next time: if you are not going to or cannot
rebuild the dependent packages, please add the maintainers to BCC. I
simply cannot read every single thread in the mailing list, nor recall
every single dependency of my packages.

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

Re: Script to get all deps of a package (for soname bumps etc.)

[Iñaki Ucar]

On Wed, 13 Jul 2022 at 18:43, Stephen Smoogen  wrote:
>
>
>
> On Wed, 13 Jul 2022 at 12:25, Iñaki Ucar  wrote:
>>
>> On Wed, 13 Jul 2022 at 18:13, Robbie Harwood  wrote:
>> >
>> > Maxwell G via devel  writes:
>> >
>> > > I believe Miro uses this for the FTI bugs. It tends to be more accurate,
>> > > especially when there hasn't been a compose for a couple days. If this
>> > > is something people are interested in, I think it's worthwhile to
>> > > include this repo definition in fedora-packager.
>> >
>> > An authoritative, preferably single, simple command to run to answer the
>> > question "across all architectures, what needs my package and in what
>> > form?" would be really helpful.  Even if there's a "correct" way to do
>> > it today, it's not discoverable (as evidenced by these threads) nor is
>> > it easy to remember.  Something like `dnf whatuses src:mypackage` (or of
>> > similar simplicity) would be appreciated.
>>
>> If this functionality requires defining and enabling additional repos,
>> maybe dnf is not the proper place? But then maybe fedpkg is. Anyway, I
>> agree that a simple command would be very much appreciated.
>>
>
> fedpkg would only call dnf to try and get the same information. It doesn't 
> have any better window on things

It could e.g. package the necessary "development" repos and activate
them when calling dnf.

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

Re: Script to get all deps of a package (for soname bumps etc.)

[Iñaki Ucar]

On Wed, 13 Jul 2022 at 18:13, Robbie Harwood  wrote:
>
> Maxwell G via devel  writes:
>
> > I believe Miro uses this for the FTI bugs. It tends to be more accurate,
> > especially when there hasn't been a compose for a couple days. If this
> > is something people are interested in, I think it's worthwhile to
> > include this repo definition in fedora-packager.
>
> An authoritative, preferably single, simple command to run to answer the
> question "across all architectures, what needs my package and in what
> form?" would be really helpful.  Even if there's a "correct" way to do
> it today, it's not discoverable (as evidenced by these threads) nor is
> it easy to remember.  Something like `dnf whatuses src:mypackage` (or of
> similar simplicity) would be appreciated.

If this functionality requires defining and enabling additional repos,
maybe dnf is not the proper place? But then maybe fedpkg is. Anyway, I
agree that a simple command would be very much appreciated.

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

Help with annocheck output

[Iñaki Ucar]

Hi,

I'm trying to understand why annocheck is complaining in [1] about
_FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS when these flags are defined
(see [2]).

A specific example, the first function reported:

Hardened: /usr/lib/flexiblas/libflexiblas_fallback_lapack.so: FAIL:
fortify test because -D_FORTIFY_SOURCE=2 was not present on the
command line (function: sgbbrd_)

If we take a look at the build log, we see:

[ 34%] Building C object
src/CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o
cd /builddir/build/BUILD/flexiblas-3.2.0/build/src && /usr/bin/gcc
-DFLEXIBLAS_CBLAS -DFLEXIBLAS_LAPACK -D_FILE_OFFSET_BITS=64 -D_NONE_
-D_POSIX_C_SOURCE=200809L -Dflexiblas_EXPORTS
-I/builddir/build/BUILD/flexiblas-3.2.0/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/include
-I/builddir/build/BUILD/flexiblas-3.2.0/include
-I/builddir/build/BUILD/flexiblas-3.2.0/build
-I/builddir/build/BUILD/flexiblas-3.2.0/libcscutils/include
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/include
-I/builddir/build/BUILD/flexiblas-3.2.0/libcscutils/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/include/cscutils
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
  -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -fPIC -std=c99
-fstack-protector-strong -fstack-clash-protection
-D_FILE_OFFSET_BITS=64 -DNDEBUG -O3 -fPIC -MD -MT
src/CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o -MF
CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o.d -o
CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o -c
/builddir/build/BUILD/flexiblas-3.2.0/src/lapack_interface/wrapper/sgbbrd.c

So the flags are there. Is this a false positive or am I missing something?

[1] 
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/101025/testReport/(root)/tests/_annocheck/
[2] 
https://kojipkgs.fedoraproject.org//packages/flexiblas/3.2.0/2.fc37/data/logs/x86_64/build.log

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

Review swap: mininet

[Iñaki Ucar]

Hi,

Here's the request: https://bugzilla.redhat.com/show_bug.cgi?id=2072115
Happy to review something in exchange.

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

Re: Help needed with new RStudio subcomponent: quarto

[Iñaki Ucar]

On Fri, 18 Feb 2022 at 14:39, Fabio Valentini  wrote:
>
> On Fri, Feb 18, 2022 at 1:36 PM Iñaki Ucar  wrote:
> >
> > Hi,
> >
> > The new version of RStudio [1] now bundles quarto [2], a publishing
> > system written in JavaScript and TypeScript that in turn bundles Deno
> > [3] (runtime written in Rust) and its standard library (this is not
> > binary, but it's tagged independently of Deno at the moment),
> > deno_dom, and Dart Sass (other binary dependencies are pandoc and
> > esbuild, but they are part of Fedora already).
> >
> > I'm a bit overwhelmed by this. Does anyone see any sane way forward
> > here? Anyone willing to help? Some thoughts:
> >
> > - We could package Deno, but how stable it is, and thus how important
> > the tie to a specific version might be. Also, there's the question
> > about how to handle its standard library and third-party modules.
> > Maybe we could follow the same strategy as with nodejs, allowing
> > bundling specific versions.
>
> I have tried packaging deno as RPMs. It is possible, but quite a big task.

I was afraid this was the case. And then there is support only for
x86_64 and aarch64, as you mentioned.

> The packages are now a bit out-of-date because I didn't have time to
> update them lately,
> but here's the work-in-progress .spec files for everything needed by deno:
> https://github.com/ironthree/deno-rpms
> and here's the work-in-progress RPM packages:
> https://copr.fedorainfracloud.org/coprs/decathorpe/deno/monitor/
>
> The "deno" binary does work, but the packages would need working with
> upstream to fix some (mostly licensing) issues before they could be
> submitted as Fedora packages.
> (Note that building deno with vendored Rust dependencies would not
> really help, since those aforementioned issues would also need to be
> resolved in that case.)

What kind of issues? Aren't they MIT licensed?

And when you talk about "packages" in this context, what does it mean?
Are they parts of the main repo? Or third-party modules? I assume it's
not what they call the "standard library", because that's JavaScript
and TypeScript.

> > - Dart Saas seems quite complicated, because it obviously requires the
> > Dart SDK [5]. Could Dart Saas be replaced by Ruby Saas?
>
> I think the Ruby SASS gem is deprecated, I'd rather replace it with
> sassc. It is the recommended replacement, alongside the Dart library -
> but given that we don't have dart in Fedora, and we already have
> libsass / sassc, I'd try to use that instead.

Ok, I see. I would need to check whether this can be a drop-in replacement.

Well, the deno part is quite a showstopper right now. I think we're
stuck with the previous version of RStudio for now. :(

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

Help needed with new RStudio subcomponent: quarto

[Iñaki Ucar]

Hi,

The new version of RStudio [1] now bundles quarto [2], a publishing
system written in JavaScript and TypeScript that in turn bundles Deno
[3] (runtime written in Rust) and its standard library (this is not
binary, but it's tagged independently of Deno at the moment),
deno_dom, and Dart Sass (other binary dependencies are pandoc and
esbuild, but they are part of Fedora already).

I'm a bit overwhelmed by this. Does anyone see any sane way forward
here? Anyone willing to help? Some thoughts:

- We could package Deno, but how stable it is, and thus how important
the tie to a specific version might be. Also, there's the question
about how to handle its standard library and third-party modules.
Maybe we could follow the same strategy as with nodejs, allowing
bundling specific versions.

- Dart Saas seems quite complicated, because it obviously requires the
Dart SDK [5]. Could Dart Saas be replaced by Ruby Saas?

[1] https://src.fedoraproject.org/rpms/rstudio
[2] https://github.com/quarto-dev/quarto-cli
[3] https://deno.land
[4] https://github.com/sass/dart-sass
[5] https://dart.dev/get-dart

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 12:59, Vít Ondruch  wrote:
>
>
> Dne 27. 01. 22 v 12:18 Iñaki Ucar napsal(a):
> > On Thu, 27 Jan 2022 at 12:09, Vít Ondruch  wrote:
> >>
> >> Dne 27. 01. 22 v 11:19 Iñaki Ucar napsal(a):
> >>> On Thu, 27 Jan 2022 at 10:58, Zbigniew Jędrzejewski-Szmek
> >>>  wrote:
> >>>>> I think this change should be reverted until a cleaner way can be
> >>>>> found to implement it.
> >>>> I'm all for making better, but please make concrete proposals.
> >>> Here's a concrete proposal:
> >>>
> >>> - Copy %build_*flags to another private macro, let's say %_build_*flags.
> >>> - Add there the stuff that is not valid once the current build
> >>> finishes (e.g., the flag that this change adds).
> >>> - Use that in %set_build_flags and leave %build_*flags as it was.
> >>>
> >> That sounds similar to
> >> "%extension_cflags/%extension_cxxflags/%extension_ldflags" Zbyszek
> >> already mentioned elsewhere. Or I don't get the point.
> >>
> >> Here is concrete proposal for Ruby:
> >>
> >> https://src.fedoraproject.org/rpms/ruby/pull-request/110
> > There's a *big* difference: switching to %extension_*flags means that
> > many packages have to be modified
>
>
> But why? In Ruby, it should be enough to change Ruby itself and all the
> other Ruby packages should be fine. Why is it different for R/OCAML?

In R, this could be enough for most packages too. But e.g. there are R
packages that are template builders for user programs, and probably
suffer from the same issue. The point is that we don't even know how
many packages are affected.

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 12:09, Vít Ondruch  wrote:
>
>
> Dne 27. 01. 22 v 11:19 Iñaki Ucar napsal(a):
> > On Thu, 27 Jan 2022 at 10:58, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> >>> I think this change should be reverted until a cleaner way can be
> >>> found to implement it.
> >> I'm all for making better, but please make concrete proposals.
> > Here's a concrete proposal:
> >
> > - Copy %build_*flags to another private macro, let's say %_build_*flags.
> > - Add there the stuff that is not valid once the current build
> > finishes (e.g., the flag that this change adds).
> > - Use that in %set_build_flags and leave %build_*flags as it was.
> >
>
> That sounds similar to
> "%extension_cflags/%extension_cxxflags/%extension_ldflags" Zbyszek
> already mentioned elsewhere. Or I don't get the point.
>
> Here is concrete proposal for Ruby:
>
> https://src.fedoraproject.org/rpms/ruby/pull-request/110

There's a *big* difference: switching to %extension_*flags means that
many packages have to be modified, and we have to ensure that stuff
does not end up in places like pkgconfig files. This is not discussed
in the change proposal. Are proposal owners willing to do that work?
Instead, what I propose leaves %build_*flags as they are, so there
should be no impact. Still, proposal owners would need to identify
which packages are currently broken and rebuild them.

And then there are other minor differences:
- Are %extension_*flags present in EPEL?
- Do we really want to remove hardening flags from extensions? Why
should we have a different standard for them? Apparently they caused
trouble in the past in Python packages. Not sure what kind of trouble,
but we have no issues in the R ecosystem, for example. And I suspect
other ecosystems do not either, since they are using %build_*flags and
not extension flags.

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 11:34, Richard W.M. Jones  wrote:
>
>
> Another concrete proposal:
>
> Is there a way to scan all binary packages in Fedora to get either a
> count or list of those packages that contain strings like
> "-Wl,-dT,/builddir/".  This will give us numbers on how bad the
> problem is.  I suspect it's quite widespread.
>
> Rich.

And another concrete proposal:

This is not reflected *at all* in the change proposal. Modify the
change proposal to acknowledge this issue and discuss it. If changes
are needed with respect to how things are done in other packages, then
required modifications should be in the scope of the proposal owners.

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 11:19, Iñaki Ucar  wrote:
>
> On Thu, 27 Jan 2022 at 10:58, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > > I think this change should be reverted until a cleaner way can be
> > > found to implement it.
> > I'm all for making better, but please make concrete proposals.
>
> Here's a concrete proposal:
>
> - Copy %build_*flags to another private macro, let's say %_build_*flags.
> - Add there the stuff that is not valid once the current build
> finishes (e.g., the flag that this change adds).
> - Use that in %set_build_flags and leave %build_*flags as it was.

Or even better:

- Define a new set of build-specific build flags, let's say
%build_specific_*flags
- Add the stuff there.
- Add them to %set_build_flags along %build_*flags

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 10:58, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> > I think this change should be reverted until a cleaner way can be
> > found to implement it.
> I'm all for making better, but please make concrete proposals.

Here's a concrete proposal:

- Copy %build_*flags to another private macro, let's say %_build_*flags.
- Add there the stuff that is not valid once the current build
finishes (e.g., the flag that this change adds).
- Use that in %set_build_flags and leave %build_*flags as it was.

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

Re: Package notes feature causing build paths to be embedded

[Iñaki Ucar]

On Thu, 27 Jan 2022 at 10:13, Richard W.M. Jones  wrote:
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2043092
>
> This is not about the feature itself but about the way it has been
> implemented.
>
> During builds LDFLAGS is modified so it contains a build path,
> something like:
>
>   
> -Wl,-dT,/builddir/build/BUILD/.package_note-rubygem-nio4r-2.5.2-6.fc36.x86_64.ld
>
> Many builds embed/store LDFLAGS somewhere.  For OCaml it gets embedded
> in the ocamlopt binary, and in *.cma files.  Similar sort of thing
> happening in Ruby, Perl, Haskell, Python, ...

Also R, which breaks R packages. Tom disabled this feature in the spec
for the time being.

> But the problem is more general than this too.  It also turns up in
> some *.pc (pkgconf) files.
>
> I think this change should be reverted until a cleaner way can be
> found to implement it.

I agree. Switching to %extension_*flags has been proposed, as Python
does, but there was a system-wide change for that [1], and now we are
asked to switch everything to using this without pondering the
consequences because this change overlooked its consequences.

[1] https://fedoraproject.org/wiki/Changes/Python_Extension_Flags

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

Re: Weird bodhi push messages

[Iñaki Ucar]

On Wed, 26 Jan 2022 at 19:09, Kevin Fenzi  wrote:
>
> On Wed, Jan 26, 2022 at 05:48:56PM +, Richard W.M. Jones wrote:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-6fc6070c5a
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-416cd48fd5
> >
> > What do the comments about XX being "ejected" mean?
>
> It means the build(s) were not tagged as bodhi expected them to be, so
> it just doesn't push that update anywhere. This can happen if an updates
> push fails in some way when bodhi is tagging things or the like.
>
> When you see this sort of thing, please file a releng ticket.

Reported here: https://pagure.io/releng/issue/10590

Iñaki

>
> I'm supposed to get notices of these, but with notifications being
> behind I probibly haven't seen them yet. ;(
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Iñaki Ucar]

On Wed, 26 Jan 2022 at 16:23, Vít Ondruch  wrote:
>
>
> Dne 26. 01. 22 v 15:48 Iñaki Ucar napsal(a):
> > On Wed, 26 Jan 2022 at 15:46, Iñaki Ucar  wrote:
> >> More issues with this change:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2046246
> >>
> >> Packages such as R (octave and others, I suppose, as well) save the
> >> build flags because they are needed to build package extensions. With
> >> this change, a path that only exists during the parent package build
> >> stage is injected, and basically extensions are broken. I consider
> >> this a bug in rpm-config-macros. If later-non-valid flags are required
> > I meant redhat-rpm-config, apologies.
>
>
> This is basically https://bugzilla.redhat.com/show_bug.cgi?id=2043092.

Ouch, what a mess...

> I'd suggest to build R and similar with:
>
> ~~~
>
> %undefine _package_note_file
>
> ~~~
>
>
> as a quick workaround and find better solution later. E.g. there is this
> proposal for Ruby:
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c14

I see that the use of %{extension_*flags} is suggested. Are these safe
to use in EPEL?

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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Iñaki Ucar]

On Wed, 26 Jan 2022 at 15:46, Iñaki Ucar  wrote:
>
> More issues with this change:
> https://bugzilla.redhat.com/show_bug.cgi?id=2046246
>
> Packages such as R (octave and others, I suppose, as well) save the
> build flags because they are needed to build package extensions. With
> this change, a path that only exists during the parent package build
> stage is injected, and basically extensions are broken. I consider
> this a bug in rpm-config-macros. If later-non-valid flags are required

I meant redhat-rpm-config, apologies.

Iñaki

> for this change, then they should be injected via some private
> variable in order to keep %{build_*flags} clean.
>
> Iñaki
>
> On Mon, 24 Jan 2022 at 16:21, Mamoru TASAKA  wrote:
> >
> > Zbigniew Jędrzejewski-Szmek wrote on 2022/01/24 17:55:
> > > On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:
> > >> On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin  
> > >> wrote:
> > >>> Sorry for the necro but there seems to be a problem with this change. It
> > >>> broke multiple packages at the linking stage:
> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=2043178
> > >>>
> > >>> On the package-note repo https://github.com/systemd/package-notes
> > >>> it is said that it requires binutils (>= 2.38) but it hasn't been
> > >>> released yet.
> > >>>
> > >>> Can the owners of this change chime in?
> > >>
> > >> I would appreciate any insights that can be offered into why the
> > >> frama-c build is failing:
> > >>
> > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81690392
> > >>
> > >> It's got something to do with this change, since the linker is
> > >> complaining that it cannot find the package-note file, but I am
> > >> unclear how this change is supposed to interact with the OCaml
> > >> ecosystem.
> > >
> > > Hi,
> > >
> > > the problem was that the %_package_note_file macro uses %buildsubdir,
> > > and %buildsubdir is set during %prep, but it seems it only available
> > > during %build and later. So the path was set wrong… I pushed a work-around
> > > to set %_package_note_file directly before prep and started a new build.
> > >
> > > (I wish we had something better for this. %buildsubdir is useful, but
> > > very fragile.)
> >
> > Well, it turned up that this issue (that %buildsubdir is unusable in %prep)
> > also affects gabedit as:
> >
> > /usr/bin/ld: cannot open linker script file 
> > /builddir/build/BUILD/.package_note-gabedit-2.5.1-11.fc36.x86_64.ld: No 
> > such file or directory
> >
> > https://koschei.fedoraproject.org/package/gabedit?collection=f36
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81664083
> >
> > Can't this issue be fixed in package-notes rpm side?
> >
> > Regards,
> > Mamoru
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
>
>
> --
> Iñaki Úcar



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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Iñaki Ucar]

More issues with this change:
https://bugzilla.redhat.com/show_bug.cgi?id=2046246

Packages such as R (octave and others, I suppose, as well) save the
build flags because they are needed to build package extensions. With
this change, a path that only exists during the parent package build
stage is injected, and basically extensions are broken. I consider
this a bug in rpm-config-macros. If later-non-valid flags are required
for this change, then they should be injected via some private
variable in order to keep %{build_*flags} clean.

Iñaki

On Mon, 24 Jan 2022 at 16:21, Mamoru TASAKA  wrote:
>
> Zbigniew Jędrzejewski-Szmek wrote on 2022/01/24 17:55:
> > On Sat, Jan 22, 2022 at 08:54:02PM -0700, Jerry James wrote:
> >> On Fri, Jan 21, 2022 at 5:35 PM Robert-André Mauchin  
> >> wrote:
> >>> Sorry for the necro but there seems to be a problem with this change. It
> >>> broke multiple packages at the linking stage:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=2043178
> >>>
> >>> On the package-note repo https://github.com/systemd/package-notes
> >>> it is said that it requires binutils (>= 2.38) but it hasn't been
> >>> released yet.
> >>>
> >>> Can the owners of this change chime in?
> >>
> >> I would appreciate any insights that can be offered into why the
> >> frama-c build is failing:
> >>
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81690392
> >>
> >> It's got something to do with this change, since the linker is
> >> complaining that it cannot find the package-note file, but I am
> >> unclear how this change is supposed to interact with the OCaml
> >> ecosystem.
> >
> > Hi,
> >
> > the problem was that the %_package_note_file macro uses %buildsubdir,
> > and %buildsubdir is set during %prep, but it seems it only available
> > during %build and later. So the path was set wrong… I pushed a work-around
> > to set %_package_note_file directly before prep and started a new build.
> >
> > (I wish we had something better for this. %buildsubdir is useful, but
> > very fragile.)
>
> Well, it turned up that this issue (that %buildsubdir is unusable in %prep)
> also affects gabedit as:
>
> /usr/bin/ld: cannot open linker script file 
> /builddir/build/BUILD/.package_note-gabedit-2.5.1-11.fc36.x86_64.ld: No such 
> file or directory
>
> https://koschei.fedoraproject.org/package/gabedit?collection=f36
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81664083
>
> Can't this issue be fixed in package-notes rpm side?
>
> Regards,
> Mamoru
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: mass rebuild status - 2022-01-25

[Iñaki Ucar]

On Tue, 25 Jan 2022 at 19:13, Kevin Fenzi  wrote:
>
> Greetings.
>
> The mass rebuild finished it's first pass on saturday morning, leaving
> 3448 failed builds.
>
> We then did a second pass yesterday ( 2022-01-24 ) of all failed builds,
> and that resulted in 1282 failed builds.
>
> The f36-rebuild tag is being merged now, but unfortunately our SOP had
> it merge via f36-signing-pending, so all the builds will pass through
> signing again, which will be a slow process. We have updated docs and
> next time will be just tagging directly into the final tag and signing
> along the way.
>
> There's a gcc build currently going that has fixes for some common
> issues that caused failures on ppc64le builds along with some other
> fixes. As soon as it's done we are going to do another pass of
> resubmitting the failed builds and will tag any that finish there.
>
> After that we will be done and it will be on maintainers to sort out
> FTBFS issues.

What do we do with the FTBFS issues filed as a result of the ppc64le
issues? Do we close them, or are they gonna be closed automatically if
the second pass succeeds?

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Iñaki Ucar]

On Mon, 17 Jan 2022 at 15:53, Iñaki Ucar  wrote:
>
> FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE 
> that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to 
> CMake + GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in 
> gcc?
>
> Iñaki
>
> [1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36
> [2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590

I found this is due to the LTO flags in FFLAGS, but this error doesn't
happen with gcc 11. Should I disable LTO in FlexiBLAS for the time
being?

Iñaki


> On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek  wrote:
>>
>> Hi!
>>
>> gcc 12 snapshot has landed as the system compiler into rawhide today.
>> GCC 12 is going to enter its stage4 development phase (only regression
>> and documentation bugfixes allowed) on Monday 17th, so there should be
>> just those bugfixes and not new features etc. anymore.
>> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
>> most important is probably that vectorization is enabled at -O2 now
>> which is the option with most of the distribution is built with.
>>
>> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
>> some cases where people need to adjust their code.  Other things
>> include the usual C++ header changes, where previously some standard
>> header included some other header as an implementation detail but it doesn't
>> any longer and so code that relied on such indirect include that isn't
>> required by the standard needs to include the header that provides whatever
>> it relies on.  Or e.g. packages using -Werror where new warnings are
>> reported with the newer compiler and -Werror results in build failures.
>>
>> If there are bugs on the compiler side, please let me know immediately,
>> so that those bugs can be fixed before the mass rebuild next week.
>>
>> Another important thing I wanted to say is that we'd like to switch
>> ppc64le from the numerically problematic IBM extended long double to
>> IEEE 754 quad long double.  This is an ABI change.  Some libraries
>> are already built so that they support both ABIs at the same time,
>> including glibc, libstdc++, libgcc, libgfortran etc.
>> For other libraries and binaries, the compiler, assembler and linker
>> will notice if they use long double and flag them as using either
>> IBM or IEEE long double and linker (or I think dynamic linker too)
>> might complain when things are mixed.
>> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
>> but the glibc/gcc libraries are built compatibly with both.
>> We'd like to configure gcc shortly before the mass rebuild with
>> --with-long-double-format=ieee so that it will default to
>> -mabi=ieeelongdouble, probably on a side-tag build first, and it
>> will be highly desirable to rebuild at least some of the most commonly
>> used library packages in the order of dependencies there, otherwise
>> I'd be afraid the mass rebuild could fail for way too many packages
>> (as the mass rebuild doesn't do dependency order rebuilds but just
>> goes through packages alphabetically or so).
>> Any suggestions on which packages have commonly used library packages
>> that use long double?
>> readelf -A on libraries on ppc64le prints either nothing (either
>> the library is thought not to use long double or supports both ABIs
>> transparently or hasn't been rebuilt for some years), or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> for libraries (or binaries or object files) that use IBM long double
>> only or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
>> for IEEE long doubles.
>> So I think we want to rebuild on a side-tag packages that
>> provide shared libraries used by hundreds of other packages that
>> are
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> right now.
>>
>> Jakub
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
>> https

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Iñaki Ucar]

FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE
that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to CMake
+ GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in gcc?

Iñaki

[1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36
[2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590

On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek  wrote:

> Hi!
>
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
>
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it
> doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.
>
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
>
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).
> Any suggestions on which packages have commonly used library packages
> that use long double?
> readelf -A on libraries on ppc64le prints either nothing (either
> the library is thought not to use long double or supports both ABIs
> transparently or hasn't been rebuilt for some years), or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> for libraries (or binaries or object files) that use IBM long double
> only or
> Attribute Section: gnu
> File Attributes
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
> for IEEE long doubles.
> So I think we want to rebuild on a side-tag packages that
> provide shared libraries used by hundreds of other packages that
> are
>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
> right now.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


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

Re: hiredis soname bump

[Iñaki Ucar]

On Mon, 17 Jan 2022 at 00:21, Nathan Scott  wrote:
>
> Hi Kevin,
>
> On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi  wrote:
> >
> > Greetings.
> >
> > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
> > 1.0.2, which includes a soname bump.
>
> I think upstream may have reverted this change FWIW ...
> https://github.com/redis/hiredis/issues/990

This refers to the incorrect SONAME bump in 1.0.1 with respect to
1.0.0. But as Kevin said, we still have 0.13.3 in Fedora, so...

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

Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Iñaki Ucar]

On Wed, 17 Nov 2021 at 16:19, Peter Robinson  wrote:
>
> On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote:
> > > Users are going to miss the iwconfig tool. Not only is it still being used
> > > out of habit (just like ifconfig from net-tools), but (also just like
> > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig"
> > > without arguments prints a nice summary of the wireless devices and their
> > > properties, such as access point ESSID and BSSID, bit rate, signal level,
> > > etc., whereas running "iw" without arguments prints a 132-line help output
> > > with around a hundred different commands (with no explanation as to what
> > > they do, as that would require even more than 132 lines: the --help output
> > > is 445 lines long). "iw" also exposes implementation details in the most
> > > unfriendly way, by requiring the user to use "dev ", "phy
> > > ", "wdev ", or "reg" prefixes depending on the individual
> > > command (and it is entirely unclear to the user why something is a dev
> > > property, a phy property, or both), whereas "iwconfig" takes the same
> > > interface name for all commands.
> > >
> > > The new ip, iw, and route tools have clearly been designed by kernel
> > > developers for kernel developers, not for end users or even system
> > > administrators. The old ifconfig and iwconfig are much easier to use.
> >
> > The same applies for nft and ss ;)  Those tools are supposed to be the 
> > future,
> > but using them feels as if the people who wrote them never used them.
> >
> > Dunno, maybe we can keep wireless-tools package? Is it a burden to
> > keep in the distro?
>
> The problems is it doesn't provide huge amounts of useful information
> for modern HW like anything after 11a/11g like no support for
> 11n/ac/ax HW and it doesn't report a lot of the newer available
> frequencies like newer added 5Ghz bands so while it does provide some
> slightly useful information if you actually look closely a lot of it
> is actually incorrect.
>
> For example it reports I don't have encryption on my 11ac WiFi which
> is connected to a WPA3 AP likely because it doesn't understand it. Is
> the nicely formatted information useful if it's actively wrong? It
> would probably more useful to alias iwconfig to "iw dev" as that
> information is close to what iwconfig provides but is actually
> accurate on vaguely modern hardware.

"iw dev" reports SSID, channel number and a lot of other useless
information, such as center and width of the channel (iwconfig reports
current bitrate, link quality and signal level, which are far more
useful), MAC (iwconfig reports the APs MAC instead) or multicast
statistics that are all equal to 0. I don't see what piece of output
from iwconfig is not accurate, at least with my hardware (11ac).

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

Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Iñaki Ucar]

On Wed, 17 Nov 2021 at 10:54, Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Wednesday, 17 November 2021 at 10:38, Iñaki Ucar wrote:
> > On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel
> >  wrote:
> > >
> > > > The Wireless Extensions support in the kernel has been long replaced
> > > > by the mac80211/cfg80211 support. Disable the kernel options and
> > > > retire the wireless-tools userspace utilities. Wireless Extensions
> > > > only supports a minor subset of the wireless interfaces, predominently
> > > > the WEP interface and userspace has been replaced by iw/libnl/ip
> > > > interfaces which offer a lot more advanced features as well as modern
> > > > 802.11 functionality like WPA.
> > >
> > > Users are going to miss the iwconfig tool. Not only is it still being used
> > > out of habit (just like ifconfig from net-tools), but (also just like
> > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig"
> > > without arguments prints a nice summary of the wireless devices and their
> > > properties, such as access point ESSID and BSSID, bit rate, signal level,
> > > etc., whereas running "iw" without arguments prints a 132-line help output
> > > with around a hundred different commands (with no explanation as to what
> > > they do, as that would require even more than 132 lines: the --help output
> > > is 445 lines long). "iw" also exposes implementation details in the most
> > > unfriendly way, by requiring the user to use "dev ", "phy
> > > ", "wdev ", or "reg" prefixes depending on the individual
> > > command (and it is entirely unclear to the user why something is a dev
> > > property, a phy property, or both), whereas "iwconfig" takes the same
> > > interface name for all commands.
> > >
> > > The new ip, iw, and route tools have clearly been designed by kernel
> > > developers for kernel developers, not for end users or even system
> > > administrators. The old ifconfig and iwconfig are much easier to use.
> >
> > Cannot agree more.
>
> I'm not sure what you're trying to accomplish by complaining here or 'me
> too'-ing. Deprecated and unused subsystems should get removed. If you
> don't like the way the current userland tools behave, open RFE's with
> their respective upstreams instead of adding noise here.

I didn't complain. I'm not opposing, yet I'm acknowledging that it is
not true that iwconfig is unused. It is very much used, if not just
for printing the nice summary that the tool provides when called
without arguments.

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

Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)

[Iñaki Ucar]

On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel
 wrote:
>
> > The Wireless Extensions support in the kernel has been long replaced
> > by the mac80211/cfg80211 support. Disable the kernel options and
> > retire the wireless-tools userspace utilities. Wireless Extensions
> > only supports a minor subset of the wireless interfaces, predominently
> > the WEP interface and userspace has been replaced by iw/libnl/ip
> > interfaces which offer a lot more advanced features as well as modern
> > 802.11 functionality like WPA.
>
> Users are going to miss the iwconfig tool. Not only is it still being used
> out of habit (just like ifconfig from net-tools), but (also just like
> ifconfig) it is also much more user-friendly. E.g., running "iwconfig"
> without arguments prints a nice summary of the wireless devices and their
> properties, such as access point ESSID and BSSID, bit rate, signal level,
> etc., whereas running "iw" without arguments prints a 132-line help output
> with around a hundred different commands (with no explanation as to what
> they do, as that would require even more than 132 lines: the --help output
> is 445 lines long). "iw" also exposes implementation details in the most
> unfriendly way, by requiring the user to use "dev ", "phy
> ", "wdev ", or "reg" prefixes depending on the individual
> command (and it is entirely unclear to the user why something is a dev
> property, a phy property, or both), whereas "iwconfig" takes the same
> interface name for all commands.
>
> The new ip, iw, and route tools have clearly been designed by kernel
> developers for kernel developers, not for end users or even system
> administrators. The old ifconfig and iwconfig are much easier to use.

Cannot agree more.

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

License change: jacktrip

[Iñaki Ucar]

Hi,

I'm working on updating jacktrip from 1.3.0 to 1.4.1. License changes: MIT
-> MIT and GPLv3 and LGPLv3.

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

Re: Stability of armv7hl builders

[Iñaki Ucar]

I asked this in another thread, but maybe this is related to [1]? How
do we disable just link-time parallelism?

[1] 
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/bc8fa85e907d4b2b88760da8d23c9e17663c44fa?branch=rawhide


On Wed, 20 Oct 2021 at 15:15, Jakub Jelinek  wrote:
>
> Hi!
>
> I've been trying to build gcc in rawhide and f35 for more than a week now,
> but haven't succeeded due to instability of the armv7hl builders.
> E.g. the
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117620
> build succeeded on all but armv7hl in less than 22 hours (on aarch64
> even took less than 5 hours), but armv7hl kept rebooting or whatever
> (impossible to find out from the logs) 8 times, see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117797
> Buildroots list.
> Eventually I've cancelled that build after 151 hours, disabled
> LTO on armv7hl (for GCC bootstrap) and am building now
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518894
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518968
> but those again show total time of ~ 21 hours, but armv7hl task times
> of 1.5 and 10 hours, so the f35 build was retried already 2 times and f36
> once.
>
> Any recent kernel changes on the boxes, or is there any way to find out
> what's going on with them, whether it oopses, OOMs or something else?
>
> In late August the package built just fine and took ~ 27 hours to build on
> armv7hl.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: final link failed: memory exhausted on armv7l

[Iñaki Ucar]

On Fri, 15 Oct 2021 at 09:43, Iñaki Ucar  wrote:
>
> On Fri, 15 Oct 2021 at 06:15, Jeff Law  wrote:
> >
> >
> >
> > On 10/13/2021 10:37 AM, Michael Catanzaro wrote:
> > > On Wed, Oct 13 2021 at 06:06:50 PM +0200, Björn 'besser82' Esser
> > >  wrote:
> > >> What you describe as lto requires a lot of memory is caused by building
> > >> lto along with non-lto in the same object file requires significantly
> > >> more memory.  For that reason one can disable building non-lto along
> > >> with lto using the `-f-no-fat-lto-objects` compiler flags instead of
> > >> `-f-fat-lto-objects`, if and *only IF* the package in question does
> > >> *NOT* ship static libraries.
> > >
> > > More background: this default is, of course, backwards. Fedora
> > > packages do not generally ship static libraries, so it makes more
> > > sense for the few packages that do to opt-in instead of opt-out. Jeff
> > > proposed a change to improve that here:
> > >
> > > https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
> > >
> > > but he left Red Hat, so it hasn't been implemented.
> > I'd still like to tackle this but my time is limited.
> >
> > However, I strongly suspect fat-lto-objects is not the problem here.  If
> > the build is running out of memory at link time, that is the LTO phase.
> > The best solution for that is to either disable LTO on the arm target,
> > or (better) limit the parallelism at link time. There was a change to
> > redhat-rpm-config that I think made it into f35 to allow a package to
> > throttle the link-time parallelism.
>
> This makes sense, because f34 builds consistently succeed in exactly
> the same hardware. How do I limit just the link-time parallelism?

Could this be related to this [1] commit?

[1] 
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/bc8fa85e907d4b2b88760da8d23c9e17663c44fa?branch=rawhide

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

Re: final link failed: memory exhausted on armv7l

[Iñaki Ucar]

On Fri, 15 Oct 2021 at 06:15, Jeff Law  wrote:
>
>
>
> On 10/13/2021 10:37 AM, Michael Catanzaro wrote:
> > On Wed, Oct 13 2021 at 06:06:50 PM +0200, Björn 'besser82' Esser
> >  wrote:
> >> What you describe as lto requires a lot of memory is caused by building
> >> lto along with non-lto in the same object file requires significantly
> >> more memory.  For that reason one can disable building non-lto along
> >> with lto using the `-f-no-fat-lto-objects` compiler flags instead of
> >> `-f-fat-lto-objects`, if and *only IF* the package in question does
> >> *NOT* ship static libraries.
> >
> > More background: this default is, of course, backwards. Fedora
> > packages do not generally ship static libraries, so it makes more
> > sense for the few packages that do to opt-in instead of opt-out. Jeff
> > proposed a change to improve that here:
> >
> > https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
> >
> > but he left Red Hat, so it hasn't been implemented.
> I'd still like to tackle this but my time is limited.
>
> However, I strongly suspect fat-lto-objects is not the problem here.  If
> the build is running out of memory at link time, that is the LTO phase.
> The best solution for that is to either disable LTO on the arm target,
> or (better) limit the parallelism at link time. There was a change to
> redhat-rpm-config that I think made it into f35 to allow a package to
> throttle the link-time parallelism.

This makes sense, because f34 builds consistently succeed in exactly
the same hardware. How do I limit just the link-time parallelism?

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

Re: final link failed: memory exhausted on armv7l

[Iñaki Ucar]

Thanks, Björn, Dan and Fabio for your comments.

On Wed, 13 Oct 2021 at 18:20, Björn 'besser82' Esser
 wrote:
>
> Am Mittwoch, dem 13.10.2021 um 16:51 +0200 schrieb Björn 'besser82'
> Esser:
> > Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> > > Hi,
> > >
> > > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> > > [3, 4] with this message (memory exhausted). The same build on the
> > > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> > > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> > > fix this?
> > >
> > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> > > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> > > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> > > [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
> >
> >
> > As the package doesn't build any *distributed* static library, you can
> > try to avoid building the linker object files to contain non-lto code:
> >
> > %global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
> > fno-fat-lto-objects!g')
> >
> > That should drastically cut the amount of memory the linker needs to
> > create the final ELF binary.  It doesn't hurt to do that on all arches /
> > releases, as it will also result in significantly shorter build time.
> >
> > Björn
>
>
> Works as suggested in a scratch build:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77177126

And thanks for this. I launched a scratch build to test this too, but
you were faster, so cancelling now. ;-) I'll implement this suggestion
then.

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

final link failed: memory exhausted on armv7l

[Iñaki Ucar]

Hi,

RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
[3, 4] with this message (memory exhausted). The same build on the
same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
fix this?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
[5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829

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

Seeking advice about versioning change

[Iñaki Ucar]

Hi all,

RStudio has changed the versioning scheme in the last release. The
last one (currently packaged in Fedora) was 1.4.1717. The new one is
(wait for it...) 2021.09.0+351 (reminds me of [1]). So two obvious
questions:

1. The two schemes actually order properly. Should I increment the epoch anyway?
2. What should I do with that +351? Do we have a policy about the "+"?
Should we make one?

Thanks in advance.

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

Re: Any thoughts about adding Apache Arrow to Fedora+EPEL ?

[Iñaki Ucar]

Hi Kaleb,

I have 0 time till the end of the month, but please let me know when
you submit arrow. I'll be happy to review it, and I'll be interested
in co-maintaining it.

Iñaki


On Mon, 20 Sept 2021 at 23:02, Kaleb Keithley  wrote:
>
> 
>
> Out of all its dependencies, only one doesn't already exist in Fedora: apache 
> ORC.
>
> I have a package review open at 
> https://bugzilla.redhat.com/show_bug.cgi?id=2005989; if someone would be so 
> kind as to pick it up so that I can keep this moving.
>
> Thanks.
>
> 
>
> On Mon, Jul 26, 2021 at 10:26 AM Kaleb Keithley  wrote:
>>
>> Hi,
>>
>> Ceph is on the threshold of adding a dependency on Apache Arrow[1].
>>
>> Ceph has had a long history of bundling dependencies so that they can be 
>> built when the platform either doesn't have the dependency or the dependency 
>> is too old. But this time, for a number of factors, the preference is to not 
>> bundle it.
>>
>> At this point I'm just exploring the possibility of getting it added to 
>> Fedora; whether anyone has any show stopper objections, etc.
>>
>> Let me know if you have any objections or questions.
>>
>> Thanks
>>
>> [1] https://arrow.apache.org/
>> --
>>
>> Kaleb
>
>
>
> --
>
> Kaleb
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: Disable locale forwarding in OpenSSH

[Iñaki Ucar]

On Thu, 9 Sept 2021 at 12:17, Florian Weimer  wrote:
>
> There is a movement towards C.UTF-8 for small images (containers and
> VMs).  C.UTF-8 has both size and performance improvements over the more
> traditional en_US.UTF-8 locale.  (The performance improvement is
> currently in upstream glibc only, but we plan to bring it to rawhide and
> Fedora 35 shortly.)
>
> However, in a world where glibc-langpack-en (or glibc-all-langpacks) is
> not installed on target systems, logging in over SSH does not result in
> a viable locale if the client use en_US.UTF-8 (or any other locale
> except C or C.UTF-8).  This causes a severe degradation in user
> experience.  It's not only that UTF-8 output does not work, there are
> also frequent warning messages from various tools.  Some may even refuse
> to run completely.
>
> I tried to bring up this topic on the OpenSSH list to get some
> cross-distribution consensus, but the discussion didn't actually go
> anywhere:
>
>   Phasing out forwarding of locale settings
>   
> 
>
> I think Fedora should do this unilaterally, dropping the downstream
> additions that enable locale forwarding in both the default client and
> server configurations.  If we do that, the OpenSSH server will use the
> locale as configured with localectl for new interactive and
> non-interactive sessions, which is C.UTF-8 in many cases.  At least
> that's what my testing on Fedora 33 suggests.
>
> Comments?

This would work... if the target system has a properly configured
locale, which is not the case many times. E.g., [1] is still
unresolved.

[1] https://github.com/CentOS/sig-cloud-instance-images/issues/154

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

Re: Plasmashell: Alt+F2 not working

[Iñaki Ucar]

On Wed, 18 Aug 2021 at 14:32, Sergio Belkin  wrote:
>
> Hi folks,
>
> Since a few days ago, the keyboard shortcut Alt+F2 for opening "run command" 
> box is not working.
>
> journalctl shows complaints as follows:
>
> plasmashell[231184]:  Could not open library 'libkdeinit5_'.
> plasmashell[231184]:  Cannot load library libkdeinit5_: (libkdeinit5_: cannot 
> open shared object file: No such file or directory)
>
> Any ideas?

Same issue here. Go to System Settings > Workspace > Shortcuts. I had
two entries for KRunner there for some reason: one showing the icon
and a blank one. I removed the latter and configured the shortcuts in
the other, and now it works fine again.

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

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 16:27, Justin Forbes  wrote:
>
> On Wed, Aug 11, 2021 at 8:46 AM Iñaki Ucar  wrote:
> >
> > On Wed, 11 Aug 2021 at 15:12, Benjamin Berg  wrote:
> > >
> > > Hi,
> > >
> > > is thermald.service active and running on that machine?
> >
> > thermald is not (and was never) installed.
> >
> > I'm pretty sure now it has something to do with some kernel change in
> > the 5.13.x series. I have a (manual) test case that reproduces the
> > issue reliably:
> > - Suspend the laptop and wait a few minutes until it cools down.
> > - Resume the session.
> > - Launch a compilation task when the sensors' output shows a
> > temperature of ~40ºC for the processor.
> >
> > I tested this for:
> > - 5.13.{4,5,8} -> fan doesn't speed up quickly enough, the laptop shuts 
> > down.
> > - 5.12.7 -> fan quickly reaches maximum speed, no shutdown.
> >
> > I see some differences for 5.12.x vs 5.13.x under
> > /sys/class/thermal/thermal_zone*/*, but I'm not sure what I should
> > look for. Or maybe the misconfiguration could be under
> > /sys/class/thermal/cooling_device*/*? Other? Any hints would be
> > appreciated.
>
> Is the intel_tcc_cooling module loaded? If so, what happens if you
> remove it?

It is loaded. Removing it doesn't help.

> Also, have you opened a bz for this? I don't recall seeing
> it, but I could be misremembering.

I didn't, because I was unsure about what or how to report this, so I
wanted to ask for help here first.
I've just opened this: https://bugzilla.redhat.com/show_bug.cgi?id=1992706

Iñaki

>
> Thanks,
> Justin
>
> > Iñaki
> >
> > > If yes, could you please edit the command line of the systemd unit to
> > > include --loglevel=debug and grab some logs[1]?
> > >
> > > Ideally both of a "bad" and "good" case.
> > >
> > > Obviously, we shouldn't be running into a critical temperature
> > > situation where the laptop simply shuts down. But I am not sure whether
> > > this is some misconfiguration or if thermald might be reacting too
> > > slowly for some reason.
> > >
> > > A good next step is likely to raise the issue with the thermald
> > > upstream and include the logs.
> > >
> > > Benjamin
> > >
> > > [1] You can also stop the service and simply run thermald manually as
> > > root. Maybe you find that more convenient. i.e. something like:
> > >   thermald --no-daemon --loglevel=debug --adaptive
> > >
> > > On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> > > > Hi,
> > > >
> > > > This is so annoying. Recently, I've been experimenting
> > > > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > > > temperature rises in which the fan doesn't catch up and doesn't reach
> > > > maximum speed. In the journal, I see:
> > > >
> > > >   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> > > > shutting down
> > > >
> > > > They happen as follows. When the laptop is still cool (e.g., recently
> > > > powered up), if I launch some compilation task, which is quite CPU
> > > > demanding, then the temperature rises quickly and I hear that the CPU
> > > > fan speeds up too slowly, so slowly that the critical temperature is
> > > > reached and the laptop shuts down. However, if the laptop was already
> > > > medium-hot due to other tasks, then the CPU fan catches up and reaches
> > > > maximum speed quickly, so the temperature is controlled.
> > > >
> > > > This wasn't happening before, and I'm guessing that maybe some default
> > > > kernel thermal parameters have changed recently? (This is replicable at
> > > > least with all the kernels currently installed: 5.13.4, 5.13.5,
> > > > 5.13.8). I see that the thermal policy is step_wise in some thermal
> > > > zones, and user_space in others (there are 8). I'll be happy to provide
> > > > more info if anyone has any clue on how to debug and/or fix this.
> > > >
> > > > Regards,
> > > > --
> > > > Iñaki Úcar
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 15:12, Benjamin Berg  wrote:
>
> Hi,
>
> is thermald.service active and running on that machine?

thermald is not (and was never) installed.

I'm pretty sure now it has something to do with some kernel change in
the 5.13.x series. I have a (manual) test case that reproduces the
issue reliably:
- Suspend the laptop and wait a few minutes until it cools down.
- Resume the session.
- Launch a compilation task when the sensors' output shows a
temperature of ~40ºC for the processor.

I tested this for:
- 5.13.{4,5,8} -> fan doesn't speed up quickly enough, the laptop shuts down.
- 5.12.7 -> fan quickly reaches maximum speed, no shutdown.

I see some differences for 5.12.x vs 5.13.x under
/sys/class/thermal/thermal_zone*/*, but I'm not sure what I should
look for. Or maybe the misconfiguration could be under
/sys/class/thermal/cooling_device*/*? Other? Any hints would be
appreciated.

Iñaki

> If yes, could you please edit the command line of the systemd unit to
> include --loglevel=debug and grab some logs[1]?
>
> Ideally both of a "bad" and "good" case.
>
> Obviously, we shouldn't be running into a critical temperature
> situation where the laptop simply shuts down. But I am not sure whether
> this is some misconfiguration or if thermald might be reacting too
> slowly for some reason.
>
> A good next step is likely to raise the issue with the thermald
> upstream and include the logs.
>
> Benjamin
>
> [1] You can also stop the service and simply run thermald manually as
> root. Maybe you find that more convenient. i.e. something like:
>   thermald --no-daemon --loglevel=debug --adaptive
>
> On Wed, 2021-08-11 at 12:31 +0200, Iñaki Ucar wrote:
> > Hi,
> >
> > This is so annoying. Recently, I've been experimenting
> > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > temperature rises in which the fan doesn't catch up and doesn't reach
> > maximum speed. In the journal, I see:
> >
> >   kernel: thermal thermal_zone0: acpitz: critical temperature reached,
> > shutting down
> >
> > They happen as follows. When the laptop is still cool (e.g., recently
> > powered up), if I launch some compilation task, which is quite CPU
> > demanding, then the temperature rises quickly and I hear that the CPU
> > fan speeds up too slowly, so slowly that the critical temperature is
> > reached and the laptop shuts down. However, if the laptop was already
> > medium-hot due to other tasks, then the CPU fan catches up and reaches
> > maximum speed quickly, so the temperature is controlled.
> >
> > This wasn't happening before, and I'm guessing that maybe some default
> > kernel thermal parameters have changed recently? (This is replicable at
> > least with all the kernels currently installed: 5.13.4, 5.13.5,
> > 5.13.8). I see that the thermal policy is step_wise in some thermal
> > zones, and user_space in others (there are 8). I'll be happy to provide
> > more info if anyone has any clue on how to debug and/or fix this.
> >
> > Regards,
> > --
> > Iñaki Úcar
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: Kernel thermal configuration issues in laptop

[Iñaki Ucar]

On Wed, 11 Aug 2021 at 14:17, Vitaly Zaitsev via devel
 wrote:
>
> On 11/08/2021 12:31, Iñaki Ucar wrote:
> > This is so annoying. Recently, I've been experimenting
> > software-initiated shutdowns in my laptop (LG Gram) due to sudden
> > temperature rises in which the fan doesn't catch up and doesn't reach
> > maximum speed. In the journal, I see:
>
> AMD CPU? Intel should start hardware throttling instead of shutting down.

product: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz

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

Kernel thermal configuration issues in laptop

[Iñaki Ucar]

Hi,

This is so annoying. Recently, I've been experimenting
software-initiated shutdowns in my laptop (LG Gram) due to sudden
temperature rises in which the fan doesn't catch up and doesn't reach
maximum speed. In the journal, I see:

  kernel: thermal thermal_zone0: acpitz: critical temperature reached,
shutting down

They happen as follows. When the laptop is still cool (e.g., recently
powered up), if I launch some compilation task, which is quite CPU
demanding, then the temperature rises quickly and I hear that the CPU
fan speeds up too slowly, so slowly that the critical temperature is
reached and the laptop shuts down. However, if the laptop was already
medium-hot due to other tasks, then the CPU fan catches up and reaches
maximum speed quickly, so the temperature is controlled.

This wasn't happening before, and I'm guessing that maybe some default
kernel thermal parameters have changed recently? (This is replicable
at least with all the kernels currently installed: 5.13.4, 5.13.5,
5.13.8). I see that the thermal policy is step_wise in some thermal
zones, and user_space in others (there are 8). I'll be happy to
provide more info if anyone has any clue on how to debug and/or fix
this.

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

Re: Licensing guidelines for AppStream project_license

[Iñaki Ucar]

On Wed, 19 May 2021 at 07:51, Otto Urpelainen  wrote:
>
> I asked this question a while ago on the packaging mailing list [0], but
> did not receive any replies. Let me try again here on devel with more
> subscribers:
>
> During the package review of qvge [1], the following question came up:
> Are the any requirements placed on the contents of AppStream metadata,
> particularly the field project_license [2]? It feels natural that is
> MUST be the same (modulo differences in notation) as specfile License,
> since both have the same meaning. However, I cannot find anything in
> Licensing Guidelines about this.

Recently, I added metadata to one of my packages per user request. I
didn't find any clear guidelines either. I also think that is should
be the same as the specfile license, and that's what I did.

> In my experience, this comes up quite often, since upstreams often have
> bundled dependencies or other copy-pasted code with different license
> than upstream's own code, yet AppStream metadata, LICENSE file, README
> and so only list upstream's own license.
>
> [0]:
> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/HMDNWXRVTW37E5TOY6SU2BJ24KFJNZLY/
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1913870
> [2]:
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_license
>
> Otto
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: New lapack packages in rawhide

[Iñaki Ucar]

Thanks for the heads-up. I'll rebuild FlexiBLAS on rawhide. Per [1], all
the other packages should be pointing to FlexiBLAS already. :)

[1] https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager

Iñaki

On Sat, 10 Apr 2021 at 16:20, Tom Callaway  wrote:

> Hi Fedorans,
>
> I've updated lapack to 3.9.1 in rawhide. This comes with several notable
> changes:
>
> 1. I've moved to using the upstream build files, specifically, cmake. This
> eliminates lots of ancient cruft in the Fedora lapack package that needed
> to be redone by hand with every new release.
> 2. This change means that the lapack and cblas header files are installed
> where upstream intends them to be installed, which is under /usr/include,
> rather than /usr/include/{lapack,cblas}/. You may need to adjust your
> dependent packages for this, but as this is the upstream behavior, you may
> have had to patch your package to find the files (and now you should not
> need to).
> 3. That said, there are now cmake helpers along with the pkgconfig files.
> If your package detects either of these and uses them during build to set
> includepaths, you should not need to change anything.
> 4. There is now a libtmglib shared library in lapack. Previously, these
> symbols lived inside liblapacke (which is still present, just now linked to
> libtmglib for those symbols).
> 5. I have disabled debuginfo. Lapack has a special "64_" variant where the
> library symbols are prefixed with "64_", but the debuginfo process was
> undoing this (somehow). This has been true for a while, which makes me
> wonder how many people were actually using that variant, but whatever.
>
> Given the scope of this change, I do not plan to push it to Fedora 34 or
> older at this time. If you find any bugs, please let me know through any of
> the usual channels (bugzilla, email, etc).
>
> ~spot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


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

Re: Fedora Packager Dashboard - Available for wide use to all packagers

[Iñaki Ucar]

Thanks for all the great work. The dashboard is fantastic.

Iñaki

On Wed, 17 Feb 2021 at 12:46, Frantisek Zatloukal  wrote:
>
> Hi,
>
> We'd like to announce that the Fedora Packager Dashboard passed the testing 
> period, was properly deployed inside Fedora Infrastructure, got fixes, 
> improvements and feature additions and is now available for widespread use 
> among all Fedora Packagers.
>
>
> For those of you who didn’t hear about the Dashboard yet, It combines all 
> relevant information for package maintainers into one web application with 
> searching and both simple and advanced (regex based) filtering possibilities. 
> You’ll find things like open bug reports, updates, overrides, FTBFS (from 
> koschei and from Fedora Health Check by decathorpe) and FTI reports, pull 
> requests and orphan/retire warnings not only for your packages directly, but 
> even for packages you depend on. It’s designed to make a packager's life 
> easier and save our packagers some of their time. An article showing it’s 
> current features is available on Fedora Community Blog: 
> https://communityblog.fedoraproject.org/fedora-packager-dashboard/ . There 
> will also be a talk about the Dashboard on DevConf.cz 2021: 
> https://devconfcz2021.sched.com/event/gmLm/packager-dashboard-life-of-packager-made-easy
>  .
>
>
> Dashboard itself is available: https://packager-dashboard.fedoraproject.org/
>
> (the Dashboard is automatically pulling new data every 15 minutes, so you can 
> just leave it open in one of your browser tabs and don’t worry about 
> reloading it :) )
>
>
> Fedora 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.
>
>
> While the testing period is behind us and we have everything properly 
> deployed, the work doesn’t end here. We have longer term plans for even more 
> stuff for the dashboard. On the top of our list currently sit support for 
> private bugs (visible after you authenticate with FAS), and contextual 
> schedules and calendars for packages you might be interested in (eg. Do you 
> maintain some Python packages? You might want to have a Python Release 
> Calendar on your dashboard.)
>
>
> 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.
>
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 15:21, Iñaki Ucar  wrote:
>
> On Mon, 25 Jan 2021 at 15:20, Iñaki Ucar  wrote:
> >
> > On Mon, 25 Jan 2021 at 14:32, Iñaki Ucar  wrote:
> > >
> > > On Mon, 25 Jan 2021 at 13:58, Jonathan Wakely  
> > > wrote:
> > > >
> > > > On 25/01/21 12:33 +, Jonathan Wakely wrote:
> > > > >>>rstudio -- error: 'bind' is not a member of 'boost'
> > > > >>>http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
> > > > >>
> > > > >>I'm going to look into this.
> > > >
> > > > The patch to add -DBOOST_BIND_GLOBAL_PLACEHOLDERS got removed again a
> > > > few days ago, but it's still needed.
> > >
> > > The patch was removed because upstream added it in [1]. A few weeks
> > > ago [2] was merged to fix building against Boost 1.75, but it's
> > > failing. Any idea why?
> > >
> > > [1] https://github.com/rstudio/rstudio/pull/7011
> > > [2] https://github.com/rstudio/rstudio/pull/8606
> >
> > In fact, the error with [2] has to do with websocketpp placeholders??
>
> Sorry, I hit "send" before pasting this:
>
> /builddir/build/BUILD/rstudio-1.4.1103/src/cpp/session/SessionConsoleProcessSocketTests.cpp:
> In member function 'bool
> rstudio::session::console_process::{anonymous}::SocketClient::connectToServer()':
> /builddir/build/BUILD/rstudio-1.4.1103/src/cpp/session/SessionConsoleProcessSocketTests.cpp:249:55:
> error: '::_1' has not been declared
>   249 |   _, ::_1, ::_2));
>
> Here: 
> https://github.com/JanMarvin/rstudio/blob/a73589c69c62b55935c2b0936bbe7ffe52fe0a49/src/cpp/session/SessionConsoleProcessSocketTests.cpp#L249

Fixed in rawhide. E.g.,
https://koji.fedoraproject.org/koji/taskinfo?taskID=60466057

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 15:20, Iñaki Ucar  wrote:
>
> On Mon, 25 Jan 2021 at 14:32, Iñaki Ucar  wrote:
> >
> > On Mon, 25 Jan 2021 at 13:58, Jonathan Wakely  
> > wrote:
> > >
> > > On 25/01/21 12:33 +, Jonathan Wakely wrote:
> > > >>>rstudio -- error: 'bind' is not a member of 'boost'
> > > >>>http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
> > > >>
> > > >>I'm going to look into this.
> > >
> > > The patch to add -DBOOST_BIND_GLOBAL_PLACEHOLDERS got removed again a
> > > few days ago, but it's still needed.
> >
> > The patch was removed because upstream added it in [1]. A few weeks
> > ago [2] was merged to fix building against Boost 1.75, but it's
> > failing. Any idea why?
> >
> > [1] https://github.com/rstudio/rstudio/pull/7011
> > [2] https://github.com/rstudio/rstudio/pull/8606
>
> In fact, the error with [2] has to do with websocketpp placeholders??

Sorry, I hit "send" before pasting this:

/builddir/build/BUILD/rstudio-1.4.1103/src/cpp/session/SessionConsoleProcessSocketTests.cpp:
In member function 'bool
rstudio::session::console_process::{anonymous}::SocketClient::connectToServer()':
/builddir/build/BUILD/rstudio-1.4.1103/src/cpp/session/SessionConsoleProcessSocketTests.cpp:249:55:
error: '::_1' has not been declared
  249 |   _, ::_1, ::_2));

Here: 
https://github.com/JanMarvin/rstudio/blob/a73589c69c62b55935c2b0936bbe7ffe52fe0a49/src/cpp/session/SessionConsoleProcessSocketTests.cpp#L249


-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 14:32, Iñaki Ucar  wrote:
>
> On Mon, 25 Jan 2021 at 13:58, Jonathan Wakely  
> wrote:
> >
> > On 25/01/21 12:33 +, Jonathan Wakely wrote:
> > >>>rstudio -- error: 'bind' is not a member of 'boost'
> > >>>http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
> > >>
> > >>I'm going to look into this.
> >
> > The patch to add -DBOOST_BIND_GLOBAL_PLACEHOLDERS got removed again a
> > few days ago, but it's still needed.
>
> The patch was removed because upstream added it in [1]. A few weeks
> ago [2] was merged to fix building against Boost 1.75, but it's
> failing. Any idea why?
>
> [1] https://github.com/rstudio/rstudio/pull/7011
> [2] https://github.com/rstudio/rstudio/pull/8606

In fact, the error with [2] has to do with websocketpp placeholders??



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 13:58, Jonathan Wakely  wrote:
>
> On 25/01/21 12:33 +, Jonathan Wakely wrote:
> >>>rstudio -- error: 'bind' is not a member of 'boost'
> >>>http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
> >>
> >>I'm going to look into this.
>
> The patch to add -DBOOST_BIND_GLOBAL_PLACEHOLDERS got removed again a
> few days ago, but it's still needed.

The patch was removed because upstream added it in [1]. A few weeks
ago [2] was merged to fix building against Boost 1.75, but it's
failing. Any idea why?

[1] https://github.com/rstudio/rstudio/pull/7011
[2] https://github.com/rstudio/rstudio/pull/8606

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 11:31, Iñaki Ucar  wrote:
>
> On Mon, 25 Jan 2021 at 11:08, Jonathan Wakely  
> wrote:
> >
> > Tom Rodgers completed the Boost 1.75.0 build for the change
> > https://fedoraproject.org/wiki/Changes/F34Boost175
> > and I've rebuilt most of the packages that depend on it.
> >
> > The following packages failed to build. I'll look at the ones that
> > appear to be due to Boost changes.
>
> [snip]
>
> > rstudio -- error: 'bind' is not a member of 'boost'
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
>
> Looking into this. There's a patch upstream.

Patch applied, rebuilding in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=60447520

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 11:31, Iñaki Ucar  wrote:
>
> On Mon, 25 Jan 2021 at 11:08, Jonathan Wakely  
> wrote:
> >
> > Tom Rodgers completed the Boost 1.75.0 build for the change
> > https://fedoraproject.org/wiki/Changes/F34Boost175
> > and I've rebuilt most of the packages that depend on it.
> >
> > The following packages failed to build. I'll look at the ones that
> > appear to be due to Boost changes.
>
> [snip]
>
> > rstudio -- error: 'bind' is not a member of 'boost'
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
>
> Looking into this. There's a patch upstream.

I get:

$ fedpkg scratch-build --target f34-boost --nowait --fail-fast --srpm
Could not execute scratch_build: Unknown build target: f34-boost

Was this merged already?

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Boost 1.75.0 in rawhide, with soname change

[Iñaki Ucar]

On Mon, 25 Jan 2021 at 11:08, Jonathan Wakely  wrote:
>
> Tom Rodgers completed the Boost 1.75.0 build for the change
> https://fedoraproject.org/wiki/Changes/F34Boost175
> and I've rebuilt most of the packages that depend on it.
>
> The following packages failed to build. I'll look at the ones that
> appear to be due to Boost changes.

[snip]

> rstudio -- error: 'bind' is not a member of 'boost'
> http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105

Looking into this. There's a patch upstream.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mass spec file change: Adding BuildRequires: make

[Iñaki Ucar]

On Mon, 30 Nov 2020 at 23:16, Tom Stellard  wrote:
>
> Hi,
>
> As part of the f34 change request[1] for removing make from the
> buildroot, I will be doing a mass update of packages[2] to add
> BuildRequires: make where it is needed.

Packages listed for iucar, done.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Highlights from the latest Copr release

[Iñaki Ucar]

On Fri, 13 Nov 2020 at 18:13, Pavel Raiskup  wrote:
>
> Thanks for questions!
>
> On Friday, November 13, 2020 5:50:46 PM CET Iñaki Ucar wrote:
> > On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup  wrote:
> > >
> > > Hello!
> > >
> > > On Nov 13 2020, a new Copr release landed production.  The list of user 
> > > visible
> > > changes is in the release notes document:
> > >
> > > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
> >
> > Many thanks for the build batches feature! I have some questions about
> > this. Building on the example in the release notes,
> >
> > - If a fourth build 101040 depends on 101020 and a fifth one 101050
> > depends on 101030, when do these ones start? As soon as each build,
> > individually, finish? Or when the whole batch, 101020 and 101030,
> > finishes?
>
> *20 and *30 re in one batch -- so both *40 and *50 are started at the same
> time after the that batch finishes.
>
> Both *40 and *50 are put into a separate batch, but that is just a detail
> in this case.
>
> The currently processed batch dependency tree can be observed at:
> https://copr.fedorainfracloud.org/status/batches/

Nice. :)

> > - Then, what happens if 101030 fails?
>
> The batch is finished as soon as all the builds inside are finished.  No
> matter if they failed or succeeded...  so the other two batches will start
> building.
>
> I know it is not ideal.  In the future we could implement something more
> clever like "give the maintainer a chance to fix the build, before we
> continue...".  But it would be way too complicated contribution at the
> start (even the actual was).  Please fill the RFE if you see a space for
> enhancement.

I think a flag to automatically cancel dependent builds if something
fails in a batch wouldn't be too complicated to implement. Will fill
an RFE.

> > - Can a build depend on more than one build ID?
>
> You should rather think about "batches" in this case, and each batch can
> only depend on one batch.
>
> Corner cases aside => --after-build-id creates a new batch, --with-build-id 
> puts
> the build into an existing batch.

And we can use any build ID in a batch with those flags, right? I.e.,
we don't need to keep track of the first one in the batch.

> > - Are these flags (after-build, with-build) available for other build
> > commands (e.g. buildscm)?
>
> I believe they are.

Nice, thanks!

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Highlights from the latest Copr release

[Iñaki Ucar]

On Fri, 13 Nov 2020 at 17:50, Iñaki Ucar  wrote:
>
> On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup  wrote:
> >
> > Hello!
> >
> > On Nov 13 2020, a new Copr release landed production.  The list of user 
> > visible
> > changes is in the release notes document:
> >
> > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
>
> Many thanks for the build batches feature! I have some questions about
> this. Building on the example in the release notes,
>
> - If a fourth build 101040 depends on 101020 and a fifth one 101050
> depends on 101030, when do these ones start? As soon as each build,
> individually, finish? Or when the whole batch, 101020 and 101030,
> finishes?
>
> - Then, what happens if 101030 fails?
>
> - Can a build depend on more than one build ID?
>
> - Are these flags (after-build, with-build) available for other build
> commands (e.g. buildscm)?

build-package was a better example for this.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Highlights from the latest Copr release

[Iñaki Ucar]

On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup  wrote:
>
> Hello!
>
> On Nov 13 2020, a new Copr release landed production.  The list of user 
> visible
> changes is in the release notes document:
>
> https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html

Many thanks for the build batches feature! I have some questions about
this. Building on the example in the release notes,

- If a fourth build 101040 depends on 101020 and a fifth one 101050
depends on 101030, when do these ones start? As soon as each build,
individually, finish? Or when the whole batch, 101020 and 101030,
finishes?

- Then, what happens if 101030 fails?

- Can a build depend on more than one build ID?

- Are these flags (after-build, with-build) available for other build
commands (e.g. buildscm)?

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