Re: DNF5: Checking signatures of packages installed out of a repository?

[stan via devel]

On Tue, 31 Oct 2023 16:23:41 +0100
Petr Pisar  wrote:

> I would would like to hear your opinion: Should DNF5 start verifying
> all packages? Should DNF5 keep ignoring signatures for
> out-of-repository packages? Or should rather narrow the verification
> skip to packages from a local file system? Any other options?

I build a local kernel from the src.rpm, and install it with 

dnf -C install [etc.]

I never see this warning (dnf4).  Would I start
seeing it with dnf5?  It is easy enough to add the --no-gpgchecks
option if it is required, and it seems like a good reminder that the
package being installed might be a security risk.  Though, in my
specific case, that isn't true if the fedora src.rpm is valid.  A
pretty safe bet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Help running centpkg

[stan via devel]

On Fri, 06 Oct 2023 16:05:25 -
"Michael Dawson"  wrote:

> I'm trying to build
> https://gitlab.com/redhat/centos-stream/rpms/nodejs using centpkg but
> am running into errors.
> 
> I'm using Fedora 37 and get this error when I run centpkg mockbuild
> --with=bundled in the directory where I've cloned the
> https://gitlab.com/redhat/centos-stream/rpms/nodejs respository and
> switched to the stream-nodejs-18-rhel-8.10.0 branch.
> 
> I'm getting this error:
> 
> Total
>3.7 MB/s |  50 MB
>00:13 Running transaction check Transaction check succeeded.
> Running transaction test
> Error: Transaction test error:
>   file /usr/sbin/alternatives from install of
> chkconfig-1.19.2-1.el8.x86_64 conflicts with file from package
> alternatives-1.24-1.fc38.x86_64
  

This sounds like a package conflict error.  Two packages are trying to
manage the same file.  I find no bugzillas for chkconfig or
alternatives. I infer from that that packages within the same fedora
version don't have this conflict.  Thus, I suggest that you use an f38
instance, so that this package conflict doesn't occur.  No guarantees,
though, maybe no one else has hit this error.  If it still doesn't work,
you should open a bugzilla against one of the packages with the
information you have provided in this email.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaned packages looking for new maintainers

[stan via devel]

On Mon, 24 Jul 2023 15:38:03 -
"Julio Faracco"  wrote:
 
> I also need access to the packager group to claim maintainership.
> Who could provide it to me?
> I will probably take twincam.

I'm not a packager, but these are some links to official information on
how to become a Fedora packager.

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[stan via devel]

On Thu, 20 Jul 2023 09:17:51 -0500
Justin Forbes  wrote:

> for them. I have been running preempt=full for quite some time on my
> desktops systems here.

I've been running custom compiled kernels with preempt_full=Y on my
desktop for several years (since at least kernel 5.1). Currently
running 6.5 with it enabled.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Elliot

[stan via devel]

On Fri, 14 Jul 2023 14:20:28 -
"Elliot L"  wrote:

> Hi, my name is Elliot and I am a digital humanities student. In the
> open source world, I've made some small contributions to desktops
> such as Budgie and Xfce and I hope to do more work in this area. I
> also know basic RPM packaging and I would like to contribute to
> Fedora in the packaging field.
> 
> Since I am a new user, I don't have a sponsor and I am not in the
> packager broup. Looking at some of the orphaned packages, I know one
> I would like to try to maintain would be the
> rhythmbox-alternative-toolbar plugin. Should I post this in a
> separate thread?
> 
> Please let me know if there is any other information I should
> provide, thanks!

Welcome to Fedora.  I'm not a packager, but these are some links to
official information on how to become a Fedora packager.

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

[stan via devel]

On Fri, 23 Jun 2023 10:41:00 +
مصعب الزعبي  wrote: 
> - One year between releases.

This is easy to attain under the current system.  Just don't upgrade
every 6 months.  The upgrade process is tested to upgrade 2 fedora
versions, so, for example, from f38 to f40.  This is a one year
cadence.  You'll miss some changes, those that are not backward
compatible, but you will still receive security updates.

Incidentally, I'm not in favor of lengthening release and lifetime.  If
I wanted that, I would look for a distro that did that.

As someone else suggested, in the past I have run rawhide for a few
years, and it was just fine, with occasional glitches, but nothing like
'it eats babies'.  I wouldn't recommend it to someone who just came
from windows, but anyone who has worked through issues for a few
releases of fedora should be fine.  And, there are the forums and
lists, so it is possible to get help.  I *do* recommend that if you run
rawhide continuously, that you leave a working stable fedora install on
your machine that you can boot to access the web for help and essential
services in case something goes wrong.  Insurance.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SecureBoot certificates

[stan via devel]

On Tue, 13 Jun 2023 11:05:53 -0400
"Chris Murphy"  wrote:

> OK I tried this again and discover shim is signed twice.

It has been awhile since I built a local kernel that I signed, but even
a locally built kernel was signed twice when using rpmbuild.  I assume
that somewhere in the build plumbing there are two certificates and two
sign procedures.  I just removed them because they were dummy
certificates (test) when I built locally, and I didn't need them.

So, this has been happening for years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Using AI/Machine Learning with rpmautospec?

[stan via devel]

On Fri, 09 Jun 2023 21:22:44 -
Reon Beon via devel  wrote:

> It it atomaticly add/update the spec file when more files are added
> in the right places in the spec file?

So, are you suggesting that a neural network be trained on all existing
spec files in fedora, and then used to automatically correct new spec
files?  That seems like a lot of work, and is the theoretical concept
even sound?  That is, is there too much variation in spec files, even
correct spec files, because of the underlying variation in material
being packaged, to allow a neural network to be trained and function
correctly?

Sounds like a great summer intern project, or the seed for a PhD thesis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LibreOffice packages

[stan via devel]

On Sat, 03 Jun 2023 08:45:28 -0500
Michael Catanzaro  wrote:

> I'm not going to defend callous layoffs during a time when Red Hat is 
> earning big profits. And I have no clue what our corporate overloads 

It is a fact of corporate life that if you are a manager and want to be
promoted, cutting head count / costs, doing more with less resources, is
a great way to move up the ladder.  It shows the people above you that
you have the right attitude.  No one makes it to the executive level
without a certain ruthlessness.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: more distinct default bash prompt?

[stan via devel]

On Wed, 24 May 2023 15:05:07 -0400
"Chris Murphy"  wrote:
 
> Green is an efficient color choice. It tends to appear to the
> brightest. Part of this relates to the luminosity function of human
> vision which has a peak wavelength that happens to be the same as the
> medium wavelength photo receptor (i.e. green). So given the same
> amount of  radiant energy emitted across the visible spectrum, green
> will appear to be the brightest.
> 
> Light purple is OK, Blue, indigo, or yellow tends to be harder to to
> detect complex shapes (like letters and numbers) but I'm not sure of
> the reason(s).

I'm attaching an image of a prompt with yellow, my default, and a
prompt with green using Jens' prompt suggestion.  I find the green too
bright, I would prefer it with a little more black in it.  But I would
just override it anyway.

A long time ago I had a monochrome crt that defaulted to a sort of burnt
orange which also worked fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 38 - in witch timespan a net iso is build..??

[stan via devel]

On Tue, 09 May 2023 12:10:49 -
André verwijs  wrote:

> installed Fedora with "Fedora-Everything-netinst-x86_64-38-1.6.iso"
> but hat small issues. (firewall packages) In witch timespan will a
> new iso be build..?? At least use the latest updates for  this (or
> any other) installation iso... 

As I understand it, once the final isos have been released, they are
permanent.  They don't get rebuilt because it would require testing to
ensure that they pass all the QA tests, and that testing is being
conducted on the next release in rawhide instead.  So, to answer your
question, the new iso is built at the release of the next version of
fedora (in approximately 6 months).

Once the iso packages are installed, it is possible to access the
fedora repositories and get packages via the package manager of choice.
In a terminal, with an internet connection active, type
dnf update
to see the available updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[stan via devel]

On Thu, 27 Apr 2023 07:01:15 -0400
Stephen Smoogen  wrote:

> I am NOT a proponent of this proposal. I don't want to go to
> Discourse. Web interfaces like that cause me cognitive pain and
> grumpiness to use longer than a few minutes. As such I know my
> involvement with Fedora will go down further.
> 
> If it comes across that I am for this change, it is because I am
> tired and frustrated. The mailman system has been running on inertia
> since at least February 2018, when the last software updates to the
> mailman software were done. Over the last 5 years, the system has
> mostly run, but in the last year has increasingly had longer and
> longer outages. My tiredness comes from spending most of my
> Thanksgiving and Winter breaks trying to find reasons and then doing
> whatever cave-man hacks I could to fix it without breaking mail
> altogether. My frustration and anger comes from the fact that I spent
> most of the last 5 years assuming that it was somebody else's problem
> and they would take care of it so I could focus on keeping other
> things running.

I know almost nothing about mail list infrastructure.

Are there other open source linux distributions using the latest
mailman?  Could their process be copied and put in as a drop in
replacement for fedora with a little tweaking?  How do they deal with
the spam problem?  I'm not asking you to do it, but you appear to be a
domain expert, so you can probably answer these questions off the top
of your head.

Some more questions.  What language is mailman written in?  What are
the major incompatibilities of the new version with the older version?
Are there more modern alternatives that are easier to set up and
maintain?

Crazy ideas.

Would it cost less resources to set up a private usenet server for
messages than to continue maintaining the mailman application?  Is
it even possible?  Could it be outsourced to one of the big usenet
providers? I doubt it would be even a dent in their capacity since they
maintain 10 years of binary usenet posts.  Could such a usenet
server be kept in sync with Discourse, and allow posts to the server to
be propagated to Discourse?  I'm thinking of some kind of automated web
application that takes each post on the usenet server and logs in to
Discourse and posts it to the appropriate place.  A user would
configure it with their credentials once, and forget it.  Sort of the
way youtube-downloader works, except opposite.  In the other direction,
there would be a web scraper that regularly scrapes posts on fedora
discourse and reposts them to the usenet server.  Again, the user
enters their credentials once, and done.

Ignore this if it seems too woo woo or irrelevant or resource intense.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Is texlive-was-9 retired for Fedora 38?

[stan via devel]

On Tue, 25 Apr 2023 17:30:28 + (UTC)
Globe Trotter via devel  wrote:

> Is texlive-was-9 retired for Fedora 38? My package did not upgrade
> from F37 and so I was wondering about it.

As near as I can tell, there is no package in fedora called
texlive-was-9.

There is a package 
texlive-wasy-10:svn53533-65.fc38.noarch.rpm
that contains
/usr/share/texlive/texmf-dist/fonts/source/public/wasy/wasy9.mf
in F38.
https://koji.fedoraproject.org/koji/rpminfo?rpmID=33307983

Is that what you mean?  It seems to be there in F38.  Is it possible
that it has conflicts, and so wasn't updated?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[stan via devel]

On Mon, 24 Apr 2023 19:47:07 +0200
Kamil Paral  wrote:

> On Thu, Apr 20, 2023 at 11:21 PM Matthew Miller
>  wrote:
> 
> > I propose that we transition devel list, and eventually most of our
> > mailing lists, to Fedora Discussion (our Discourse-powered forum).

> project is going to die eventually. Mailing lists are a big hurdle
> for newcomers. Young people are not used to it (who still uses
> mailing lists, in read-write mode, except for OSS communities?), the
> lists are difficult to set up, the user interfaces are bad, there are
> many peculiarities to be aware of (top-posting, etc).

I think an analogy would be that mailing lists are like vim or emacs,
and web forums are like nano.  To someone who is used to using a power
editor, using nano is irritating.  Sure they can accomplish the task,
but it is like slogging through mud instead of running on a track.
If all you've ever known is slogging through mud, of course, that
is going to be acceptable, and using a power editor is going to be like
slogging through mud (because of the learning curve).

I think that is why there are so many complaints about the switch from
existing mail list users.  They have a system in place that allows them
to run, and really don't want to slog through mud instead.

The change to a forum doesn't really benefit them.  The benefits mainly
accrue to the maintainers and managers of the forums, not the users.  I
suppose it could be argued that if the change makes the project more
efficient, more viable, they are gaining a benefit, but what assurances
are there that the benefit will happen?  i.e. what evidence is there
that the benefit they are slogging through mud for will actually occur?

I've read all the responses to the announcement, and I don't think I've
seen an architectural analysis.  
What communication requirements does a project like Fedora need?
What is the theoretical optimal process for each requirement?
Is there an existing optimal tool for each of those optimal
processes?
Are there sub optimal tools that can be used for multiple requirements?
Is the loss of effectiveness / efficiency of using a sub optimal
tool worth the reduction in the number of tools?

This is trying to answer the question, "If there was a magic wand we
could wave, and perfectly satisfy the communication needs of the
fedora project, what would that look like?"  And, "How would we get
from here to there?"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: default bash history (non)preservation

[stan via devel]

On Thu, 13 Apr 2023 12:48:01 +0200
Vít Ondruch  wrote:

> Dne 12. 04. 23 v 17:40 stan via devel napsal(a):
> > On Wed, 12 Apr 2023 10:39:44 +0200
> > Vít Ondruch  wrote:
> >  
> >> What about using `~/.bash_logout` to avoid the need of `hx`?  
> > I had to do some research to even understand what you were asking.  
> 
> 
> Sorry, I am not expert in this field. The discussion just caught my 
> attention and that was result of my very brief research.

What I meant is that I wasn't aware of .bash_logout until you asked
about it.  So I learned by researching it, and improved what I was
doing.

> > Typing exit or logout is more keystrokes than hx, so .bash_logout
> > is not really compelling.  
> 
> 
> Ctrl+D is what I am using all the time. That is probably less
> keystrokes then `hx`, because you save the pressing the Enter ;)

You're right.  And it flows off the fingers nicely.  I ended up adding
the trap command to my .bashrc, so now it doesn't matter how I close
the session, it will always be appended to history.  I currently have
the PROMPT_COMMAND altered to add history -a too, so I have belt and
suspenders.  I haven't really noticed any issues with the appends to
.bash_history every time a new prompt happens, so might leave it.  On
the other hand, it isn't really necessary anymore.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: default bash history (non)preservation

[stan via devel]

On Wed, 12 Apr 2023 10:39:44 +0200
Vít Ondruch  wrote:

> Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
> >
> > I have the following defined in .bashrc:
> >
> > # this logs the history explicitly before exiting a shell
> > hx ()
> > {
> >history -a;
> >exit;
> > }
> >
> > It means that I have to exit using the command hx when closing a
> > terminal.  
> 
> 
> What about using `~/.bash_logout` to avoid the need of `hx`?

I had to do some research to even understand what you were asking.
With that caveat, it seems that a .bash_logout only executes on login
shells.  So, it would not save the history of terminals in X when they
were closed.  Am I misunderstanding?

I did find something that might work in that case, at this link.

https://superuser.com/questions/410525/explain-why-bash-logout-wont-run-commands/410534#410534

"""
~/.bash_logout is only run if it you explicitly exit the shell with
exit or logout, or by typing Control-D to enter an end-of-file at the
command prompt. If you close the terminal emulator, processes are sent
SIGHUP, and bash doesn’t run ~/.bash_logout in that case.

If you want to perform work any time bash exits (and whether it’s a
login shell or not), use trap foo EXIT. The most convenient way to do
this is to put your code in a shell function, e.g.,:

print_goodbye () { echo Goodbye; }
trap print_goodbye EXIT
"""

Typing exit or logout is more keystrokes than hx, so .bash_logout is not
really compelling. The trap looks promising, I assume that I would put 
save_history_on_exit () {history -a;}
trap save_history_on_exit EXIT
in .bashrc.  Basically, running a .bash_logout in a different way.

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

Re: default bash history (non)preservation

[stan via devel]

On Tue, 11 Apr 2023 10:48:11 -0400
"Chris Murphy"  wrote:

> Hi,
> 
> For a long time I've noticed lost history from multiple Terminal
> tab/windows. It seems like the last tab or window to close is the
> history that gets written to .bash_history, and everything else is
> just lost.
> 
> Somehow I found this:
> https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/11/update-bash-history-in-realtime.html
> 
> I've implemented the suggested two line change to .bash_profile:
> 
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> 
> The resulting behavior appears to be shells still have their own
> unique histories while active. But once closed, their histories
> become merged (interlaced based on the time they were issued?) and
> available when a new shell is created.
> 
> I think this would be a pretty cool yet subtle Fedora 39 feature.
> However, 
> 
> a) I'm uncertain exactly where this belongs as a default, .bashrc or
> .bash_profile or some parent file that's copied to create these files
> (for new users); 

I like option 3 if it is going to be automatic.

> b) if this is (still) an optimal way to go about it;

Providing it without effort or awareness for users seems like the way
to go.

> c) what are the possible negative side effects?

I can't think of any.  What good is a history that doesn't include all
the commands that have been used?  Well, complex commands.  I've turned
off some common commands, like ls, because all they are is clutter.  I
also turned off saving duplicate commands, though that only works if
they are contiguous in history.  I think that would be a downside to
this if people weren't used to all the clutter in their history.
Though, with Ctrl-R, it really doesn't matter.

I actually wrote a little python program to load history, and eliminate
all duplicate commands in history while preserving order of the
commands.  So, the last duplicate command is always the one saved.
> 
> Any thoughts?

I have the following defined in .bashrc:

# this logs the history explicitly before exiting a shell
hx ()
{
  history -a;
  exit;
}

It means that I have to exit using the command hx when closing a
terminal.  Not as elegant as an automatic process you are suggesting,
but it seems to work.  I'll have to try the process you are
suggesting, (from the link you gave), to see if it results in the
same effect.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New machine - no virtual terminals

[stan via devel]

On Wed, 22 Mar 2023 12:12:42 -0400
"Steven A. Falco"  wrote:
 
> I read through the motherboard manual and while I don't see a way to
> turn off the on-board VGA hardware from the BIOS, there is a physical
> switch on the motherboard to disable it completely.
> 
> I tried that, and it worked.  Now the kernel only sees my AMD video
> card and assigns it to fb0.  And all the virtual consoles now work
> properly.
> 
> Thanks again for your help, Stan.  I appreciate it!

You're welcome.  And I learned something from Dominik's response.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New machine - no virtual terminals

[stan via devel]

On Tue, 21 Mar 2023 17:14:44 -0400
"Steven A. Falco"  wrote:

> I think I'm finally getting somewhere with this problem.
> 
> My motherboard has a built-in VGA interface, which shows up as
> "astdrmfb" on fb0.  My AMD video card is "amdgpudrmfb" on fb1.
> 
> For some reason, the kernel uses fb1 for the graphical desktop, but
> when I type Ctrl-Alt-F3 it switches to the VGA interface on fb0.
> 
> So my question is now probably simpler - I need to find a way to tell
> the kernel to ignore fb0 completely, and just use fb1 for everything.
> 
> I'll do some searching to see if I can figure that out, but if
> someone knows off the top of their head how to force a framebuffer to
> be ignored, I'd appreciate it.

Is there a way to turn off the fb0 in the BIOS?  Hit F2 or Del to get
into the bios while booting.  Yours might be different, but I think
these are pretty standard.

Check the frame buffer configs in your kernel, /boot/config*.

Mine are 
CONFIG_SYSFB=y
CONFIG_SYSFB_SIMPLEFB=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=200
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_BACKLIGHT=m
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_SIMPLE=m
but I run a custom kernel, so yours could be significantly different.
You could compare a grep of the f38 kernel config that works with a
grep of the f37 kernel config that doesn't to see if there is a
difference in their framebuffer configuration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] dracut-059 comming to F38 and F37

[stan via devel]

On Tue, 21 Mar 2023 18:39:26 +0100
Pavel Valena  wrote:

> I'm preparing an update for F38 and F37 for dracut. There might be
> some upstream breaking-changes for non-standard setups, I expect the
> builds to be identical to Fedora Rawhide.
> 
>  - F37 Koji scratch-build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=98976054

I'm on F37.  I downloaded and installed the rpms from the above link,
and then rebuilt the initramfs for an older kernel.  It booted
the system successfully.  So, one successful trial.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New machine - no virtual terminals

[stan via devel]

On Tue, 21 Mar 2023 10:25:36 -0400
"Steven A. Falco"  wrote:

> I recently put a new machine together using an AMD Radeon PRO W6600
> Graphics Card.  CPU is a threadripper pro.  Motherboard is an ASUS
> Pro WS WRX80E-SAGE SE WIFI II sWRX8 E-ATX.  Software is the KDE spin
> of Fedora 37.
> 
> It mostly works perfectly, but if I try to access a virtual terminal
> with Ctrl-Alt-F3 my monitors go to sleep, so apparently the video
> sync shuts off.  Typing Ctrl-Alt-F2 brings me back to my KDE session.
> 
> Also Ctrl-Alt-F1 shows me the text that occurred during boot - I have
> rhgb and quiet disabled in my grub configuration.  So Ctrl-Alt-F1 and
> F2 work, but F3 and above do not.
> 
> I don't see anything in /var/log/messages that would give me a hint
> as to where to start with debugging this.  I've tried running SDDM in
> wayland and in x11 modes, but that doesn't make a difference.
> 
> I'd like to write a bug for this, but I'm not sure how to gather
> enough data for a meaningful report.  Are there some kernel options I
> can try, or other ways to get more data?

Is the number of consoles in /etc/systemd/logind.conf set to more than
2?  The default is 6, and so systemd should set up 6 virtual consoles
for use.  They usually don't actuate until visited, but they should
still be available to a Ctrl-Alt-[3-6].

I boot to multiuser and start X from there, and I always get virtual
consoles.  If you do a 
journalctl -r
and then a 
/vcon
do you see lines like

fedora dracut[128053]: -rwxr-xr-x   1 root root20528 Mar 13 13:01 
usr/lib/systemd/systemd-vconsole-setup
fedora dracut[128053]: -rw-r--r--   1 root root  650 Mar 13 12:59 
usr/lib/systemd/system/systemd-vconsole-setup.service

If the setup isn't occurring it would be a systemd bug.  But check if
systemd is reporting errors when it tries to set the vconsoles up.  And
try booting into multiuser by hitting a key during boot, and putting a
3 at the end of the boot line options to see if that sets them up.

Fedora recently dropped support from the kernel for the old fbcon and
replaced it with the new simple version.  Might be related if it wasn't
taken into account.  Or KDE might have decided virtual consoles were
obsolete and dropped support for them (unlikely).

Anyway some things to try, and a confirmation that it does work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: reclaim orphaned moarvm package

[stan via devel]

On Mon, 13 Feb 2023 12:07:56 -
"Felix Wang"  wrote:

> But I am not in the Fedora packager group yet. So what I am confused
> that what should I do next.

I am not a packager, but I think this might clarify what you need to
do.  Maybe an actual packager can give more detail, if it is needed.

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

[stan via devel]

On Thu, 9 Feb 2023 17:46:51 +0100
Alec Leamas  wrote:

> Using several wxWidgets version is indeed a bit painful, been there, 
> done that. One quick fix is to configure alternatives to use the new
> 3.2 version version of wx-config instead of the default 3.0.

I'm not sure what alternatives is, but now that I know about it I can
probably find out.  The key thing is that I didn't know that wxWindows
was configurable for version.

> There is no need to actually build, just running "wx-config
> --version" reveals the version currently selected by alternatives.
> 
> There are other options including hard-wiring wx-config to an
> absolute path. However, it's IMHO more complicated and with some
> traps.

Thanks.
 
> HTH

Yes, that does help.  I'll give it another try.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Tenacity

[stan via devel]

On Wed, 8 Feb 2023 09:51:37 -0700
stan via devel  wrote:

> lot of (any?) sound editing anymore.  Just for the challenge.  Maybe
> not. :-)

I see lots of other people have taken up the challenge, and reported
issues they found, but I thought I would update with my unsuccessful
results.

I downloaded the wxWidgets code from their site, and compiled it using
their instructions on f37.  Compiled easily, with only a warning about
missing midi support.  I installed it in /usr/local

When I tried to get tenacity to use it, though, I hit a dead end.  Even
though I set the environment variable WX_CONFIG to point to it, cmake
find_program kept finding the system version 3.0.4.  I assume it looks
there first, and once it finds it, it stops.  I tried the alternative of
building it as a subprogram with the tenacity source (the tenacity
build instructions helpfully pointed to this), but it was compiled as
3.0 compatible, and tenacity complained about too old a version of some
constructs.  I then gave up.

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

[stan via devel]

On Wed, 8 Feb 2023 09:02:47 -0700
stan  wrote:

> On Wed, 8 Feb 2023 08:44:30 -0700
> stan  wrote:
> 
> > On Wed, 08 Feb 2023 06:25:07 +1100
> > Philip Rhoades via devel  wrote:
> >
> > > Has there been any discussion about getting a Tenacity RPM going
> > > for Fedora? - I would prefer that to having to use the AppImage
> > > version .
> > 
> > I knew about the corporate takeover of audacity, but I didn't know
> > about this fork.  I'm not aware of any effort to package it, but you
> > could build it from source, and install it in /usr/local, probably
> > the default.
> > 
> > If you have development tools installed, that could be as easy as
> > ./configure  (not as root)
> > make  (not as root)
> > make install  (as root)
> > in the directory where you unpack the source code.  I used to build
> > audacity that way from its git repository.  Occasionally there would
> > be a glitch with versions, but it worked pretty consistently.  You
> > will have to have /usr/local/bin in your path (I think that is also
> > a default in Fedora).
> > 
> > https://tenacityaudio.org/
> > 
> > Of course, an rpm would be more convenient, but this *is* an
> > alternative.  
>
> PS
> I see on the devel list that there are potential patent issues because
> of the use of certain codecs.  I finessed that by using the ffmpeg
> version from rpmfusion, and thus installing the free and nonfree
> codecs they are referencing.  If you try the above build without
> them, it will probably still build, but will have reduced
> functionality.  Now that mp3 and mpeg are off patent, I think the use
> of other codecs would be limited unless you are editing commercial
> DVD files using aac, or video files using h264.  Videos using webm
> probably are using open source video and audio encoders.

Disregard my comments.  The process to compile tenacity is completely
different from the process to compile audacity.  A plus is that the
BUILDING.md file gives a command to install the dependencies for
building tenacity in Fedora. As they say in the BUILDING.md file,
though, fedora lacks wxWidgets 3.1.5 or greater. That stops the
configuration,
cmake -G Ninja -S . -B build
when it errors out.
They give a link to the wxWidgets website, so it is possible to
compile it and put it in /usr/local, but that seems to be going down
the rabbit hole.  I might pursue this, even though I don't really do a
lot of (any?) sound editing anymore.  Just for the challenge.  Maybe
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

Re: Tenacity

[stan via devel]

On Wed, 8 Feb 2023 08:44:30 -0700
stan  wrote:

> On Wed, 08 Feb 2023 06:25:07 +1100
> Philip Rhoades via devel  wrote:
>  
> > Has there been any discussion about getting a Tenacity RPM going
> > for Fedora? - I would prefer that to having to use the AppImage
> > version .  
> 
> I knew about the corporate takeover of audacity, but I didn't know
> about this fork.  I'm not aware of any effort to package it, but you
> could build it from source, and install it in /usr/local, probably the
> default.
> 
> If you have development tools installed, that could be as easy as
> ./configure  (not as root)
> make  (not as root)
> make install  (as root)
> in the directory where you unpack the source code.  I used to build
> audacity that way from its git repository.  Occasionally there would
> be a glitch with versions, but it worked pretty consistently.  You
> will have to have /usr/local/bin in your path (I think that is also a
> default in Fedora).
> 
> https://tenacityaudio.org/
> 
> Of course, an rpm would be more convenient, but this *is* an
> alternative.

PS
I see on the devel list that there are potential patent issues because
of the use of certain codecs.  I finessed that by using the ffmpeg
version from rpmfusion, and thus installing the free and nonfree codecs
they are referencing.  If you try the above build without them, it will
probably still build, but will have reduced functionality.  Now that
mp3 and mpeg are off patent, I think the use of other codecs would be
limited unless you are editing commercial DVD files using aac, or video
files using h264.  Videos using webm probably are using open source
video and audio encoders.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Tenacity

[stan via devel]

On Wed, 08 Feb 2023 06:25:07 +1100
Philip Rhoades via devel  wrote:
 
> Has there been any discussion about getting a Tenacity RPM going for 
> Fedora? - I would prefer that to having to use the AppImage version .

I knew about the corporate takeover of audacity, but I didn't know
about this fork.  I'm not aware of any effort to package it, but you
could build it from source, and install it in /usr/local, probably the
default.

If you have development tools installed, that could be as easy as
./configure  (not as root)
make  (not as root)
make install  (as root)
in the directory where you unpack the source code.  I used to build
audacity that way from its git repository.  Occasionally there would be
a glitch with versions, but it worked pretty consistently.  You will
have to have /usr/local/bin in your path (I think that is also a
default in Fedora).

https://tenacityaudio.org/

Of course, an rpm would be more convenient, but this *is* an
alternative.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: firefox glxtest: VA-API test failed: no supported VAAPI profile found.

[stan via devel]

On Fri, 27 Jan 2023 23:31:21 -
Reon Beon via devel  wrote:

> It seems to be this bug:
> https://github.com/rpmfusion-infra/fedy/issues/110

Strictly speaking, it is not a bug.  The fedora mesa rpm was
deliberately changed to remove some va-api and vdpau support because of
patent issues. When that new mesa stack hit fedora, I started seeing
the same messages that you are.  I then looked into it, and found the
same information as you have.  I ran the swap command recommended at
the above link, which restored the removed functionality, and I no
longer see the messages. I'm not even sure that I *need* that support.
It might be that firefox just generically checks for the support, and
reports when it is missing, whether it is needed or not.  I certainly
didn't notice any difference in my browsing experience when I was
getting the messages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Macro expanded on comment?

[stan via devel]

On Tue, 27 Dec 2022 12:29:21 -0600
Ron Olson  wrote:

> Hey all-
> 
> I commented out a SOURCES line in a spec file to test something and
> got an interesting warning: “Macro expanded in comment on line …”. I
> assume it’s just that, a warning, but was kinda surprised to see a
> commented-out line being evaluated at all. I did some searching and
> came across this BZ from 2015:
> https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to
> suggest there’s a better way (%dnl), so if I want to comment
> something out instead of putting a # in front of the line, I should
> use %dnl?

Thank you for asking this question.  When I got this error, I just
replaced the percent with a hash.  Now I can do it properly and just
put %dnl at the start of the line.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failed RPM database migrations

[stan via devel]

On Fri, 28 Oct 2022 14:59:54 -
"Sergey Mende"  wrote:

> thank you, I got the recipe from the previous conversations. I just
> asked if I could help with logs analysis or somehow else before I fix
> the issue.

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

Re: Failed RPM database migrations

[stan via devel]

On Fri, 28 Oct 2022 13:08:19 -
"Sergey Mende"  wrote:

> I upgraded from 35 to 36 in the beginning of Sept this year. The
> migration failed. May I help somehow?

I used the advice from Tom Hughes in his earlier message to complete my
failed migration.

# systemctl enable rpmdb-migrate
# systemctl start rpmdb-migrate

When that completed, the migration was successfully done.

I am running F37, started as F35 rawhide, updated using dnf,
usually daily, with reboots also usually daily.  I am currently running
rpm-4.18.0-1.fc37.x86_64.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[stan via devel]

On Fri, 30 Sep 2022 22:19:44 +0200
Björn Persson  wrote:

> Kevin Kofler via devel wrote:
> > Considering that we have been shipping these hardware codec
> > interfaces for years without any legal trouble, I find this
> > absolutely ridiculous.  
> 
> The entire codec patent business is absolutely ridiculous. Such is the
> reality we must live in.

Given the speed which digital development moves, those patents, if they
exist at all, should be no more than 5 years.  As it is, rather than
speed up the rate of innovation, the whole justification for patents,
they are slowing and restricting the rate of innovation in this area.

In the digital space, the cost of development is low, so that the
innovation that those patents are issued for would be discovered in the
course of general research without the patent holder.  There are often
conflicts of who has first discovered some innovation, resolved by
first to file, showing the lack of need for patents at all.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mesa in F37- vaapi support disabled for h264/h265/vc1

[stan via devel]

On Wed, 28 Sep 2022 19:24:34 +0200
Julian Sikorski  wrote:
  
> Wasn't this being used by firefox?
> https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

I don't know if it is used, but I received messages from firefox
nightly that VA-API support was missing when I ran it in the terminal
with the latest mesa for f37 installed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F36 to F37

[stan via devel]

On Fri, 16 Sep 2022 13:06:42 +
Zbigniew Jędrzejewski-Szmek  wrote:

> Error: Transaction test error:
>   file /usr/include/lv2/atom from install of
> lv2-devel-1.18.8-1.fc37.x86_64 conflicts with file from package
> lv2-devel-1.18.2-2.fc36.x86_64

[snip list of lv2-devel conflicts]


https://bugzilla.redhat.com/show_bug.cgi?id=2123422
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Aside: Re: Inactive packagers to be removed after the F37 release

[stan via devel]

On Thu, 15 Sep 2022 11:57:53 -0700
Adam Williamson  wrote:

> We have "critical path" groups for lots of desktops, including ones
> that aren't release-blocking: deepin, lxde, lxqt, and xfce. The logic
> here is approximately: things that are critical to those desktops are
> indeed critical to users of those desktops, and don't affect anybody
> else. So it makes sense to put them on the "critical path", because to
> the relatively small subset of users who *do* use those desktops, the
> updates really *are* critical, and it doesn't hurt users of any other
> desktop for them to be held up.

This sounds a lot more like critical set or critical graph (as in
node-edge) than critical path.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F36 to F37

[stan via devel]

On Wed, 14 Sep 2022 05:06:29 -
"Richard Myers"  wrote:

> This is for F35 -> F37 ...
> 
> I sure
> would love it if anybody knows how to fix the below warning(?), which
> shows up every time I run DNF (it has persisted through at least 3 or
> 4 Fedora revisions, maybe more):
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3.10/site-packages/dnf/plugin.py", line 104,
> in _caller getattr(plugin, method)()
>   File
> "/usr/lib/python3.10/site-packages/dnf-plugins/generate_completion_cache.py",
> line 62, in sack cur.execute("delete from available")
> sqlite3.DatabaseError: database disk image is malformed
> 
> I've tried (in the past) many things to try to fix it, but nothing
> worked.  Can't remember everything I tried, because it has been a
> couple of years, but suffice to say, I've tried the low-hanging,
> obvious stuff, and some obscure things...

The database it is trying to access is
/var/cache/dnf/packages.db
If you delete it, it will rebuild it at the next update, and that
should take care of the error, since it shouldn't build a malformed
database from scratch.  If it does, you should open an error agaist
package
python3-dnf-plugins-core
component
generate_completion_cache.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: I made a new Fedora Apps page, do you want it?

[stan via devel]

On Thu, 8 Sep 2022 12:38:49 +0200
Jakub Kadlcik  wrote:

> Hello,
> 
> I am reimplementing the current https://apps.fedoraproject.org
> page. It is not finished yet, but I wanted to share a demo with you:
> https://fedora-apps.netlify.app
> 
> The upstream is here: https://github.com/frostyx/fedora-apps/
> 
> Do you have any interest to eventually switch to this implementation
> and sunset the original one?
> 
> PS: Please don't judge me too harshly for the code quality, I am
> learning the language. I will refactor once the basic features are
> done (I know everybody is saying that :D)

I use a dark theme, and I prefer the gray text only approach of the
current page to the bright white circles with black text of your
approach.  I think that is partly to do with the text size difference
(your text is smaller).  I like the color aesthetics of the current
page better, too. I do like the ability to zoom that you have added, and
the extra content shown below the initial map.  Though I would like the
viewing window to expand when zoomed in so that it fills the screen.

I wasn't aware of this before, but it really brings home how many
aspects there are to Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

OT: triggered Re: You can't be serious! you want to remove mesa-libGL.i686 support?

[stan via devel]

On Wed, 6 Jul 2022 07:59:08 -0400
Stephen Smoogen  wrote:

> Thank you for your pointers. I have reflected on my original email and
> agree I made several mistakes in that email:
> I did not know the size of the bug problem.
> I did not investigate why the bugs were filed.
> I approached this as a one off versus a systematic problem.
> I did not help people who were affected by this in a forward moving
> way.

This reminds me too much of those old videos of the cultural revolution
when the bourgeoisie in China wore signs around their neck confessing
their crimes, while being berated by the proletariat (the communist /
Maoist true believers). I think this is a bad thing for a community like
Fedora. Isn't a simple apology or acknowledgement of error enough?

Maybe I'm reading too much into it, or it is satire?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: remove-retired-packages feedback

[stan via devel]

On Thu, 26 May 2022 15:52:06 +0200
Miroslav Suchý  wrote:

> If you already upgraded to Fedora 36 - what is your feedback about
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
> 
> Did you run the command `remove-retired-packages`? Do you find it
> useful? Comments and ideas are welcome either here or at:
> 
> https://github.com/xsuchy/fedora-upgrade/issues
> 
> Just be sure that you have latest version, i.e.,
> remove-retired-packages-36.3.

Thanks for creating this, a nice tool.  I run rawhide, and it found no
retired packages for f36 or f37.  I think that would be expected by
default.  I agree that deciding on removal of each package individually
is the right choice.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 37: Add kernel parameters that help prevent local exploits

[stan via devel]

On Fri, 20 May 2022 13:26:14 +0100
Simon Farnsworth via devel  wrote:

> On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote:
> > Add `slab_nomerge init_on_alloc=1 init_on_free=1
> > page_alloc.shuffle=1 pti=on randomize_kstack_offset=on
> > vsyscall=none ` as default kernel command line arguments. This can
> > help prevent local exploits by making it harder to exploit the
> > kernel. I do not think there will be any breakage, I have been
> > using these for a long time. The performance impact is minimal, a
> > few of these can improve performance.   
> 
> A question, then: if these options are helpful to performance and/or
> security, why are they not yet the kernel's  defaults?
> 
> If there are tradeoffs that mean that these aren't suitable for
> general use, then Fedora needs to know what those tradeoffs are
> before it can make the decision, while if they're a simple net
> improvement, then upstream kernel developers should be happy to
> switch the defaults over without requiring a kernel argument.
> 
> > This can help increase the security of Fedora, while also not
> > causing any other problems. Many users do not know what kernel
> > command line arguments are, so doing this will help them with the
> > security of their system. This does not address every problem, or
> > even most of them, but every little bit matters.  
> 
> If that's the case, why doesn't the upstream kernel switch them over?
> Is there an ABI break caused by some of these? A major performance
> regression on some workloads (if so, which workloads and does Fedora
> care)? Known bugs that upstream hasn't tracked down yet?

As an anecdotal point of reference, I compile a local custom kernel, and
have had kernel hardening set as defaults from their implementation. I
have not noticed any issues.  With the 5.18 series, however, there was
a security measure that I didn't think I needed, so I didn't implement
it.

Initialize kernel stack variables at function entry (zero-init everything 
(strongest and safest))  --->│ │   
  │ │[*] Poison 
kernel stack before returning from syscalls 
│ │   
  │ │[ ]   
Report stack depth analysis instrumentation 
 │ │   
  │ │(100) 
Minimum stack frame size of functions tracked by STACKLEAK  
 │ │   
  │ │[ ]   Show 
STACKLEAK metrics in the /proc file system  
│ │   
  │ │[*]   
Allow runtime disabling of kernel stack erasing 
 │ │   
  │ │[*] Enable 
heap memory zeroing on allocation by default
│ │   
  │ │[*] Enable 
heap memory zeroing on free by default  
│ │   
  │ │[*] Enable 
register zeroing on function exit

I don't bother with the STACKLEAK metrics or stack depth analysis.  I
also have the random implementations mentioned above turned on via
configuration options, and so compiled into the kernel as defaults.

These are all small hits to performance, and as someone in the US
Congress once said, 'a billion here and a billion there, and pretty soon
you're talking real money'.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: PackageKit Password Prompt on Fedora 36

[stan via devel]

On Sat, 16 Apr 2022 09:23:45 -0400
Mark Bidewell  wrote:

> I hope this is the right mailing list since this is about Fedora 36.

Well, it's a gray area.  It is still in beta, final decision is next
week.  So, you are more likely to get action on the test list.  This
doesn't seem egregious enough to be a release blocker, but they probably
want to know about it.

> I upgraded from Fedora 35 to the Fedora 36 Alpha (at the time).
> Occasionally when coming out of sleep I get a password prompt from, I
> believe, PackageKit.  Before I filed a bug I was curious if this was
> a known issue.

I checked bugzilla, (search for packagekit,
https://bugzilla.redhat.com/buglist.cgi?quicksearch=packagekit), and
there don't appear to be any bugs related to this.  So, before you post
to the test list, t...@lists.fedoraproject.org, you should open a
bugzilla and post the link in your email to test.  It's OK to just send
the email, but the bugzilla makes sure that the issue doesn't get lost
in the churn.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[stan via devel]

On Wed, 6 Apr 2022 06:28:59 +0200
majid hussain  wrote:

> could someone kindly tell me if my toshiba l750 machine has EFI
> support? i'm blind and efi/bios screens are in accessible.

This question is better suited to the user list rather than
this thread, but if your laptop came with windows 8 or later,
it will have uefi support. Here is a link that explains how to get into
the bios if you want to have someone double check for you.

https://www.4winkey.com/computer-help/how-to-access-enter-bios-on-toshiba-laptop.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RFI/RFC: Fedora Linux graphical recovery environment

[stan via devel]

On Tue, 5 Apr 2022 11:35:16 -0500
Gregory Bartholomew  wrote:

> On Mon, Apr 4, 2022 at 9:40 PM Gordon Messmer
>  wrote:
> 
> > The ticket mentions Boot Repair, which is the first thing that
> > comes to mind: https://help.ubuntu.com/community/Boot-Repair  
> 
> 
> Boot repair is obviously tricky because you have to have something
> bootable to initiate the repair. Practically speaking, I think the
> best option is to better support dual-drive installations. It should
> be possible to maintain two EFI partitions in a, b style when the
> user selects to have a mirrored-disk configuration. In fact I've been
> doing this on my Fedora Linux systems and I've even written some
> scripts to support it here:
> https://github.com/gregory-lee-bartholomew/bootsync
> 
> Disclaimer though -- I use systemd boot and zfs, not the default grub
> and btrfs that most Fedora Linux systems are configured with.

This is possible using standard efi boot with the cooperation of the
bios.  Just use two efi partitions, and prioritize the default one in
the bios boot menu.  Not as sophisticated as what you do, but I am
usually not running updates on the rescue system. I install the latest
fedora rawhide once a year, usually, so the rescue system is out of
support. Fine for rescue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RFI/RFC: Fedora Linux graphical recovery environment

[stan via devel]

On Tue, 5 Apr 2022 11:26:35 -0500
Gregory Bartholomew  wrote:

> On Tue, Apr 5, 2022 at 9:47 AM stan via devel
>  wrote:

> >   I just manually remove the rescue vmlinuz and initramfs and
> > then run
> > /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r)
> > "" /lib/modules/$(uname -r)/vmlinuz
> > in the /boot directory to build a new rescue kernel from the
> > currently running kernel.  Is there an option to do that also?
> > i.e. I invoke  
>> 
>> dracut from the command line and it automatically does all that if a
> > rescue_build.conf file is present in /etc/dracut.conf.d/
> >  
> 
> Well sort of. If you really want complete control over how the rescue
> kernels are installed one option is to copy
> the /usr/lib/kernel/install.d/51-dracut-rescue.install script
> to /etc/kernel/install.d and tweak it to do whatever you want under
> whatever conditions you want. As long as the script under
> /etc/kernel/install.d has the same name as the script under
> /usr/lib/kernel/install.d, it will override (i.e. run instead of) the
> one under /usr/lib/kernel/install.d.

Thanks for the information.  It will probably be a rainy day project,
as doing it manually is not onerous, since I only do it when the
production kernel version changes.  e.g. 5.17 to 5.18  So, about every
3 months?

I actually might take your suggestion about how to turn off rescue
kernels, since, like you, I have two installations of fedora, and use
one (previous version) as a rescue system.  On the other hand, belt and
suspenders.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RFI/RFC: Fedora Linux graphical recovery environment

[stan via devel]

On Mon, 4 Apr 2022 15:58:14 -0500
Gregory Bartholomew  wrote:

> > Of topic but related: I wish there was supported option to remove
> > the current rescue kernel,  
> 
> Is echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf not
> sufficient?

That is an interesting option.  It isn't documented in man dracut.conf.
Is it new?  I just manually remove the rescue vmlinuz and initramfs and
then run 
/usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" 
/lib/modules/$(uname -r)/vmlinuz
in the /boot directory to build a new rescue kernel from the currently
running kernel.  Is there an option to do that also?  i.e. I invoke
dracut from the command line and it automatically does all that if a
rescue_build.conf file is present in /etc/dracut.conf.d/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: "rescue" boot entry files are not updated on OS upgrades

[stan via devel]

On Tue, 1 Mar 2022 14:37:38 -0700
Chris Murphy  wrote:

> Summary--
> Most all Fedora variants (except Cloud) have a GRUB menu entry
> containing the word "rescue". This kernel+initramfs pair are never
> updated for the life of a Fedora installation. And they quickly become
> stale as a Fedora installation ages. This kernel's modules are
> eventually deleted, and if selected at boot time, the typical user
> experience is a dracut shell.
 

There is a way to do this manually.

In order to create a new rescue kernel and initramfs, go into boot and delete 
the current
rescue kernel and initramfs.  Then run the command below substituting the 
kernel you want
to use as the rescue kernel.  The command below defaults to the currently 
running kernel.

/boot  10:03 AM  root  tty4
/usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" 
/lib/modules/$(uname -r)/vmlinuz

Maybe it can be added to a script.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mic recording issues from browsers

[stan via devel]

On Sun, 2 Jan 2022 02:00:34 +0100
Pawel Veselov  wrote:

> Greetings!
> 
> I've been banging my head against this wall for a while now, and would
> really appreciate some pointers.
> 
> I can no longer record Google Meet meetings using RecordRTC
> (https://www.webrtc-experiment.com/RecordRTC/). This promptly became a
> problem once I upgraded from F33 to F35. I'm fairly certain this has
> therefore something to do with PipeWire. The problem occurs on every
> browser I've tried, including Chrome and Firefox. The symptoms is that
> though my audio comes through clearly to other meeting participants,
> my recording of my own voice is at the minimum chopped off, and at
> worst is mostly silence with occasional blips of syllable fragments.
> The audio coming from other participants is recorded correctly.

I have very little understanding of pipewire and no understanding of
RecordRTC.  But I have a couple of suggetions you could try.

You could try installing wireplumber, if it isn't already installed, to
see if it fixes the issue.

You could try using obs-studio (available from rpmfusion) to record the
session instead of RecordRTC (not sure how that fits with your
workflow).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[stan via devel]

On Tue, 30 Nov 2021 12:49:24 +0100
Vít Ondruch  wrote:

> I think it would be more constructive if you enumerated pros/cons of 
> sudo to support your argument then the tradition.

Not the original poster, but I find that I like the separation of roles
into two.  When I do things as root, I mentally know that they can have
very severe consequences, so I have a different mindset, a more
vigilant mindset.  I measure three times and cut once.  In fact, I do
things as root only in a single virtual console (usually), so when I go
there, I know I'm someone different.

Also, because of long usage, these are habits that are familiar and any
change means I have to develop new habits, and while I am developing
those habits, I will inevitably make mistakes.  If I continue doing
things the way I normally do, I won't make those mistakes, so they are
unnecessary mistakes.

I presume that the root account isn't going away, so it isn't a big
deal.  I'll just modify it after install to fit my work flow.

Security isn't a huge issue because I have no internet facing services
active, so people hacking root remotely is only possible through the
browser, and locally installed malware (I think).

I see this as just another small inconvenience for experienced users in
order to cater to all those 'new users'.  They do pile up, though.  I
have all kinds of notes about how to 'correct' them on install.  I
imagine this happens to everyone who joins Fedora, as the changes
accumulate, and they get left behind in their way of doing things.  Or
maybe other people don't create routines to simplify their user
experience, and so never experience this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rawhide kernel crash

[stan via devel]

On Sun, 07 Nov 2021 10:58:56 -
"Leigh Scott"  wrote:

> I think I've found the cause after switching to lightdm.
> 
[snip]
> 
> I've found nothing provides /usr/lib64/dri/simpledrm_dri.so

I don't have that file (on rawhide) and my system boots fine with
my custom compiled 5.15.0-60.fc36.x86_64.

I'm not sure if I actually have the simple framebuffer enabled.  I
thought I did, but I see there is a configuration option not set
(again, I thought I set them all), so now I'm not sure.  I followed the
help advice in the menuconfig and left the other framebuffers I have
used in the past enabled, so it could have done a failover to one of
them.

CONFIG_SYSFB_SIMPLEFB=y
CONFIG_DRM_SIMPLEDRM=m
# CONFIG_FB_SIMPLE is not set

Even though this is not clear cut, maybe it will help you track your
issue down.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: FF builds

[stan via devel]

On Thu, 9 Sep 2021 12:42:09 -0400
Demi Marie Obenour  wrote:

> On 9/8/21 10:49 PM, Bojan Smojver via devel wrote:
> > Just being devil's advocate for a second here...
> > 
> > Two days to build FF in koji? Has it gotten that big or are the
> > builds that slow?
> > 
> >  :-)  
> 
> This is also a security problem: consider a 0day exploit found in the
> wild.
> 
> Should the FF builds be given more resources?  Does Mozilla provide a
> signed Flatpak that could be used instead?

If you absolutely required a security fix, you could get the latest
nightly build from mozilla.org and run it from outside the system
directories.  If you always want the latest firefox you could build
the latest nightly from a source repository locally (takes about 90
minutes here on a not very powerful machine) and install it in
usr/local. Needs lots of development packages installed.

For integration and no worry, the fedora package is the way to go for
most people.  The issue here is rare in fedora in my experience (that
an exploit is revealed before fedora has it fixed in its repositories).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Where has the kernel-doc package gone?

[stan via devel]

On Mon, 30 Aug 2021 17:07:21 -
"Nils K"  wrote:

> I recently had to perform a bit of development/research where I often
> had to take a look in the kernel documentation.
> 
> Most of the time was spend offline so I wanted to download the
> `kernel-doc` package however it does not seem to exist. Some old
> fedora documentations still refer to it however somewhere in the 2x
> iteration of fedora it seems to have gone missing. CentOS 8 also
> still has it. Would it be possible to add this back to the repos?

Easiest would be go to the kernel.org page and use the savepage
entry in the File menu of the browser to save a copy of the
documentation.  Then you can access it offline.

A more involved and clumsy workaround is to download the src.rpm
package [1] and unpack it. It is a little complicated because you have
to run 
rpmdev-setuptree
to create the ~/rpmbuild heirarchy of directories and then
rpm -ivh [src.rpm]
[***NOT*** as root] to install the src.rpm in ~/rpmbuild and then
rpmbuild -bp kernel.spec
in ~/rpmbuild/SPECS
to expand the source.

The source tree containing all the documentation will then be under
~/rpmbuild/BUILD/kernel[...]/linux[...]/Documentation

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=8

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

[stan via devel]

On Tue, 20 Jul 2021 12:17:34 +0200
Florian Weimer  wrote:

> Firefox in rawhide hasn't been built successfully since
> firefox-89.0-1.fc35 (built 2021-06-02).  Unfortunately that version
> does not treat the clone3 system call correctly in its sandbox, so it
> won't work with future glibc 2.34 snapshots.
> 
> I fixed the issues to get firefox building again and attached a patch
> to this bug:
> 
>   firefox: FTBFS with Python 3.10 in rawhide due to collections.abc
> change 

I think this has been fixed in later firefox,
https://bugzilla.mozilla.org/show_bug.cgi?id=1718878

> (The patch also includes a glibc 2.34 compatibility change, separately
> tracked as #1983696 for downstream convenience.)

I am having trouble building nightly (firefox development version) in
rawhide, and have a bugzilla open with mozilla,
https://bugzilla.mozilla.org/show_bug.cgi?id=1721251
I copied your mail to that bugzilla, because the compatibility change
*might* be related.  It could be just a misconfiguration by me, or
other issues, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Account Migration & Production Deployment Update: COMPLETE!

[stan via devel]

On Sat, 27 Mar 2021 23:02:58 +0100
Björn Persson  wrote:

> Kevin Fenzi wrote:
> > I'd like us to add security query/respond pairs.   

> There's a limited supply of such personal secrets that I can be sure
> I'll remember, so I can't do that for too many sites. It also requires
> a not too public life. People who publish their entire lives on
> Facebook will have trouble coming up with a question that an attacker
> can't find the answer to.
> 
> Otherwise I'll make up a nonsensical phrase to enter as the answer,
> and store it securely. That turns the "security question" into a
> backup passphrase. If you want people to do this, then it's better to
> ask them to make up a passphrase.

Why change the questions that are asked?  Just answer with a
nonsensical answer, and store it in the same secure matter on your
system as your password.  e.g.  What is your favorite food?  Jamaica.
or What was your team's name in high school?  0126672651361
I suppose it could be a passphrase, but this is easier to cut and
paste.  Remembering personal secrets is a non starter as an
authentication method; it favors convenience over security, the
equivalent of 'password' or 'Decemberpass' or a sticky note on the
monitor.

I've used those hardware gadgets that spit out a number that matches a
similar hardware device at the site being logged into, but that takes
co-ordination and I didn't pay for the device, the company did, so it
could be expensive, as well as managing the co-ordination.

How about everyone has two logins, and they have to log in with
different logins from the same device, using different passwords.  They
then are considered to be authenticated.  That uses the existing
infrastructure of password managers to keep passwords secure, and just
requires two logins on the site being logged into; should be easy
enough.  Less secure than a real second factor, but more secure than a
single password.  I suppose if we consider that too much trouble, just
add a second password to the single login everywhere.  Even less secure
than the two login method, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F35 Change: "Fedora Linux" in /etc/os-release

[stan via devel]

On Wed, 10 Mar 2021 13:26:55 +0100
Björn Persson  wrote:

> It's better to give the whole distribution its own name, and not name
> it after any of its components. Fedora is a software distribution. It
> contains Linux, many GNU components, RPM, MariaDB, Libreoffice and
> lots of other things, but its name is "Fedora". Or call it "Fedora
> Software Distribution" or anything else that doesn't single out any
> of the components. That approach seems to minimize the political
> fighting.

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

Re: Building custom kernels

[stan via devel]

Thanks for doing the work and posting the result / solution.

On Wed, 3 Mar 2021 19:19:14 +0100
Julian Sikorski  wrote:

> I did actually manage to get this working, big thanks go to
> chenxiaolong for their guide [1]. I did mix-and-match some of the
> info from Fedora docs [2][3], mainly regarding how to create a
> certificate. It basically goes like:
> 
> 1. Create certs with openssl
> 2. import them with certutil and pk12util as per [3]
> 3. add self to /etc/pesign/users
> 4. run sudo /usr/libexec/pesign/pesign-authorize
> 5. restart pesign service
> 6. unlock database (pesign-client -u)
> 7. add 
> config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign',
>  
> '/var/run/pesign')) to mock site-defaults.cfg
> 8. work around bugs
> 9. run mock adding -D 'pe_signing_token NSS Certificate DB' -D 
> 'pe_signing_cert foo'
> 10. enroll the cert on the target machine
> 
> It is worth noting that for some reason the pe_signing_cert nickname
> was not the one I specified using certutil -n parameter, but an
> amalgamation of O and CN values from the certificate. Check with
> certutil -L to be sure. Moreover, while bug 1508094 mentioned by
> chenxiaolong is fixed, there are two more bugs which need to be
> worked around for all of this to work [4][5].
> Finally, the rationale: given that the Renoir APU s0ix patches have
> just missed 5.12 merge window from the looks of it, I will likely
> have to keep building my own kernels for a while. Getting the rpm
> signed automatically saves me a lot of time. Disabling secure boot
> causes windows to ask for drivelock recovery password so it is not an
> option
> 
> Best regards,
> Julian
> 
> [1]
> https://gist.github.com/chenxiaolong/520914b191f17194a0acdc0e03122e63
> [2]
> https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/
> [3]
> https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1880858 
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1934719
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Building custom kernels

[stan via devel]

On Wed, 3 Mar 2021 14:27:16 +0100
Julian Sikorski  wrote:

> Am 03.03.21 um 14:00 schrieb Dominik 'Rathann' Mierzejewski:
> > 
> > There seems to be some documentation on the wiki:
> > https://fedoraproject.org/wiki/BuildingUpstreamKernel#Sign_the_kernel_for_Secure_Boot
> > 
> > Regards,
> > Dominik
> >   
> This explains how to sign a kernel build locally with make, not how
> to make mock & rpbmbuild use a self-signed certificate for the RPM
> package.

I build a custom kernel tuned for my system from Fedora src.rpms
locally using rpmbuild (older technique without mock). I then install it
using  dnf -C  and sign it using a method similar to the above (pesign
instead of sbsign). What do you gain by having the rpms signed?
My thought is, if a person has the authority to run dnf to install
local packages on the system, secure boot is meaningless as protection.
Is it that you want the build process to sign the kernel in the rpm
package with your local keys so you don't have to go through the
process of signing the kernel after it is installed?  If that is what
you want, and you get it working, would you post the technique here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problems upgrading to f33 cloud edition

[stan via devel]

On Fri, 18 Dec 2020 10:25:30 +0100
Guido Aulisi  wrote:

> Hi, sorry for posting here if this is not correct.

Probably more appropriate for the user list.

> I'm upgraing a f32 cloud edition to f33 and I found this problem which
> I can't solve:
> 
> $ sudo dnf system-upgrade --releasever 33 --skip-broken
> --allowerasing -vvv download
> 
> I get this response:
> 
> Error: 
>  Problem: conflicting requests
>   - package
> console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch requires
> NetworkManager, but none of the providers can be installed
>   - package
> console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch requires
> NetworkManager, but none of the providers can be installed

It seems that something wants to install
console-login-helper-messages-issuegen
but the NetworkManager packages the only available versions can use
cannot be installed, probably because there is a later version being
installed.

> I don't have console-login-helper-messages installed in f32.

You could try

$ sudo dnf -x console-login-helper-messages-issuegen system-upgrade
--releasever 33 --skip-broken --allowerasing -vvv download

so that it skips the install of whatever is requiring
console-login-helper-messages-issuegen. At the least that should show
you what the chain of dependencies is that is dragging in
console-login-helper-messages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[stan via devel]

On Sat, 12 Dec 2020 09:09:46 -0700
stan  wrote:
> Is this really the best use of resources to combat
> that?

What if all the money dedicated to implementing this across the tech
industry was dedicated instead to a stem scholarship fund.  Students
who qualify to a stem program at a certified university, and who are
disadvantaged, could apply for such scholarships.  Those scholarships
could be fewer full ride, or more partial ride.  The background hardship
of the student could be taken into account in addition to poverty.
Growing up a nerd in the inner city is a magnitude more difficult than
growing up a nerd in a suburban school.  In New York state, there are
charter schools for disadvantaged students that protect studious
students from disruptive students by expelling the disruptive students.
The public schools can't do that, so studious students there are in a
toxic environment, and their performance shows that.  The students of
those charter schools perform at levels equivalent to students in
suburban schools.

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[stan via devel]

On Sat, 12 Dec 2020 15:28:57 +
Sérgio Basto  wrote:

> I'm strongly against change master to main , just because master
> suggest that is a racist word as master/slave, is like change chess
> and play not with black and white pieces but maybe with green and
> blue . This change will deprecate all I.T. books since Turing machine
> and it will be just a big a mess, first because we don't have a
> unanimous name, so here it will be main, in other place will be devel
> etc etc it will be a big confusion
> And I don't see any benefit, words will always be words and their
> meaning is given by the context.

I also think this is window dressing.  Every human being alive on the
planet today has a slave (of some description) among their ancestors,
or as a relative of their ancestors. I'm curious who came up with this
as a remedy for the effects of slavery on the descendants of slaves, and
how they decided that this was a meaningful gesture.  To me it looks
like virtue signaling designed to have a minimal impact on the bottom
line.

What does a poll of programmers who encounter the word master in code
indicate about their attitudes towards it?  Especially meaningful
would be to hear from the programmers this is meant to help.

There are millions of actual slaves on the planet as I type this, and
there are even countries where slavery is still legal, and there is at
least one religion with slavery sanctified in their scriptures.  Across
the globe sex slaves are trafficked from poorer countries to richer
countries.  Is this really the best use of resources to combat that?

If it is, then we can look forward to the demonizing of words like hit,
chain, bound, bind, submit, control in code across the globe.  It's a
good thing the people implementing this are masters of their craft, and
have lots of spare time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dell XPS 13 9310 Fingerprint Driver

[stan via devel]

On Mon, 30 Nov 2020 21:16:35 -
"Ondra Kalousek"  wrote:

> Hello. I want to buy myself Dell XPS 13 9310 (2020). The unit will
> arrive in few weeks, so I used the time to ask this questio. It has a
> fingerprint sensor Goodix 27c6:533c. But official driver is for
> Ubuntu and no RPM. There is a post how to install it, but replacing
> packages' files is very likely to break after update. Post link:
> https://aboutcher.co.uk/2020/10/goodix-fingerprint-reader-on-fedora-linux/
> 
> It is absolutely unecessary to do write to modules.alias, I think.
> 
> That Ubuntu package has a TOD library, which enables to use OEM
> drivers but there is no TOD for fedora. It would be nice to do TOD
> libfprint package, which provides libfprint (so no ugly replacements
> which will disappear after update) and that driver package or make it
> one package.
> 
> If it can be possible, can someone please make good, quality and nice
> RPM(s), which I have to install and and "at the drop of the hat" run
> into GNOME Settings and setup fingerprint? It will help me and many
> XPS 13 users, because according to reviews, this computer is very
> good for running Linux (not that one I have, which is Ok, but not
> very good).

I think this is more suited to rpmfusion since it uses a proprietary
binary blob.  If so, you should ask on one of the lists there.  See the
possible mailing lists here.
https://lists.rpmfusion.org/archives/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[stan via devel]

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:

> Is ALSA still a valid use case? I thought ALSA support was phased out
> from most relevant software?

It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

alsa is going nowhere since it is the interface to the hardware that
every other sound application depends on.  It is mature so it should
take very little maintenance to allow it to remain.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem signing custom kernel package

[stan via devel]

On Thu, 29 Oct 2020 12:13:03 -0500
Richard Shaw  wrote:

> On Sun, Oct 25, 2020 at 3:50 PM stan via devel <
> devel@lists.fedoraproject.org> wrote:  

> > Convert the private key and pem certificate to a pk12 structure.
> > openssl pkcs12 -export -out kernel_key.p12 -inkey public_key.pem -in
> > xyz_cert.x509.pem
> >  
> 
> Ok, you lost me right here. There is no file xyz_cert.x509.pem file
> to be used with "-in"...

From my history, it appears that the actual command I used was this:

openssl pkcs12 -export -inkey private_key2.priv -in public_key2.pem -name 
kernel_cert -out kernel_cert2.p12

So, I actually replaced the xyz_cert.x509.pem with public_key2.pem
It was probably my second try, thus the 2, as it took me some trial and
error to work this out.  Thus, you should use the version of keys from
your first two commands.

While I'm typing, these are the commands I actually use to sign a
kernel.  You'll need them once the keys are all distributed properly.
Depending on how you build the kernel, the redhat-testing-key might
already have signed it, and if you don't have that installed, the
kernel won't boot.  I have to remove it.  Actually, the kernels have
been signed twice lately with that test key, so I have to remove both
of them.

pesign -S -i /boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64
pesign -r -u 0 -i /boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64 -o 
/boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned
pesign -r -u 0 -i /boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned -o 
/boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned2
pesign -S -i /boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned2
pesign  --certdir /etc/pki/pesign --certificate kernel_cert --in 
/boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned2 --out 
/boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.signed --sign
pesign -S -i /boot/vmlinuz-5.9.1-300.20201025.fc31.x86_64.signed
ls -nZ
cp vmlinuz-5.9.1-300.20201025.fc31.x86_64.signed 
vmlinuz-5.9.1-300.20201025.fc31.x86_64
ls -nZ
rm vmlinuz-5.9.1-300.20201025.fc31.x86_64.signed 
vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned 
vmlinuz-5.9.1-300.20201025.fc31.x86_64.unsigned2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Problem signing custom kernel package

[stan via devel]

On Sun, 25 Oct 2020 06:20:16 -0500
Richard Shaw  wrote:

> I'm following the directions here[1] on building a custom kernel to
> test some patches[2] related to suspend[3] on my new HP ENVY X360 AMD
> laptop without S3 support.
> 
> The directions could be updated to include which commands need to be
> run as root, however, my problem is at this step:
> 
> """
> Create a PKCS #12 key file:
> 
> openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der
> """
> 
> # openssl pkcs12 -export -out key.p12 -inkey key.pem -in cert.der
> unable to load certificates
> 
> Both files are in the current directory...
> 
> Thanks,
> Richard
> 
> [1]
> https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/#_secure_boot
> [2] https://gitlab.freedesktop.org/drm/amd/-/issues/1230#note_671110
> [3] https://gitlab.freedesktop.org/drm/amd/-/issues/1230

It's been a while since I did this, so it might have changed, but these
are the steps I went through to create the signing keys.  It should at
least give you some hints, if nothing else.

A lot of work.

The configuration file needed for openssl to create the keys.
cat configuration_file.config 
"""
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts

[ req_distinguished_name ]
O = Organization
CN = Organization signing key
emailAddress = E-mail address

[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid
"""

Creating the public and private key.
openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 -batch -config 
./configuration_file.config -outform DER -out public_key.der -keyout 
private_key.priv
alternate form, haven't tried yet
openssl req -new -x509 -newkey rsa:2048 -sha256 -keyout key.asc -out cert.pem 
-nodes -days 666 -subj "/CN=$USER/"

Telling mok that on next boot, use root password to import key into its
database.
mokutil -P --import public_key.der

Converting der to pem using openssl.
openssl x509 -inform DER -in public_key.der -outform PEM -out public_key.pem

Convert the private key and pem certificate to a pk12 structure.
openssl pkcs12 -export -out kernel_key.p12 -inkey public_key.pem -in 
xyz_cert.x509.pem
# openssl pkcs12 -export -inkey private_key.priv -in public_key.pem -name 
kernel_cert -out kernel_cert.p12
Enter Export Password:
Verifying - Enter Export Password:

# Import pkcs12 file into pesign db

# pk12util -i kernel_cert.p12 -d /etc/pki/pesign
Enter password for PKCS12 file: 
pk12util: no nickname for cert in PKCS12 file.
pk12util: using nickname: Organization signing key - Organization
pk12util: PKCS12 IMPORT SUCCESSFUL
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RPM package for gql

[stan via devel]

On Tue, 6 Oct 2020 02:30:10 -0400
Nico Kadel-Garcia  wrote:

> Why not look into the "pyprpm" tool to build a source RPM to start
> with, to see if it has the dependency stack of doom common to some
> other python modules?

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

Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo

[stan via devel]

Hi,

When building the kernel with perf enabled from the src.rpm
kernel-5.9.0-0.rc6.20200925git171d4ff79f96.17.fc34.src.rpm
I get an error.  There seems to be an error in one of the build
scripts.  This was not a problem in src.rpm for
kernel-5.9.0-0.rc4.20200911git581cb3a26baf.8.fc34.src.rpm

The error seems to be in a script, and looks like a typo,
+ +# perf
/var/tmp/rpm-tmp.bbuLwN: line 499: +#: command not found
error: Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)
Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)

When I look in that temporary file, I find this, with the error line
marked by << error:

###
# DO it...
###

# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT/usr/libexec

cd linux-5.9.0-0.rc6.20200925git171d4ff79f96.17.20200927.fc31.x86_64





BuildKernel bzImage arch/x86/boot/bzImage 1

+# perf    error
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh

  /usr/bin/make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}"
  LDFLAGS="-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"  -C tools/perf V=1
  NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1
  HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=/usr
  PYTHON=/usr/bin/python3 DESTDIR=$RPM_BUILD_ROOT all


I don't know where that script comes from so I haven't corrected it and
run again, but when I turn off perf, the kernel builds and runs just
fine.

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

System no longer distributes load to multiple cores for long running task

[stan via devel]

Hi,

It's been a while (6 months?) since I ran a python program that uses a
100% cpu core for hours.  The last time I ran it, the task would migrate
from core to core to core, every second or so.  I could see it doing so
in the various tops.

Now, it runs on only one core, and doesn't move.

This is more efficient from a computing perspective because there
aren't as many task switches, but it means that the core that is
running gets very hot.  Since the rest of the cores are idle, I would
like to switch back to the previous behavior for this reason.  Can
someone tell me how?

Thanks.

PS I'm copying devel in case this isn't a kernel issue, and also
because my posts to the kernel list just seem to disappear into the
ether.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[stan via devel]

On Tue, 8 Sep 2020 17:48:30 -0400
Matthew Miller  wrote:

> On Tue, Sep 08, 2020 at 01:35:11PM -0700, stan via devel wrote:
> > Does it now have support for custom keymappings?  That is, does it
> > have a way to set a user keymap as the default? X has a very mature
> > system for setting this, so I can have my custom keymapping
> > everywhere except in editing the grub menu.  I've thought about
> > buying a programmable ergonomic keyboard so this would no longer be
> > an issue, but my current setup works.  Will it now work in Wayland?
> >  
> 
> It probably will not. Everything related to this is different, and
> there's nothing as easy or as nice. You will probably want to select
> the X session rather than the proposed new default.

Thanks for the info.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[stan via devel]

On Tue, 8 Sep 2020 11:28:20 -0400
Ben Cotton  wrote:

>  Is Wayland ready? 
> Wayland has been used by default for Fedora Workstation (which uses
> GNOME) since Fedora 25. And while it was somewhat immature initially,
> today it is a very rock-solid experience on virtually everything
> Fedora Workstation runs on.

Does it now have support for custom keymappings?  That is, does it have
a way to set a user keymap as the default? X has a very mature system
for setting this, so I can have my custom keymapping everywhere except
in editing the grub menu.  I've thought about buying a programmable
ergonomic keyboard so this would no longer be an issue, but my current
setup works.  Will it now work in Wayland?

Does it allow booting from multiuser?  Is there something equivalent to
startx so I can start it on the virtual console of my choice?

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

Re: Fedora 33 System-Wide Change proposal: swap on zram

[stan via devel]

On Tue, 28 Jul 2020 13:51:00 -0600
Chris Murphy  wrote:

> That information is stale. The feature page has been updated.
> 
> man page contains:
> 
>To  disable a configuration file supplied by the vendor, the
> recommended way is to place a symlink to /dev/null in the
> configuration directory in /etc/, with the same filename as the vendor
> configuration file.

Thanks.

> It's maybe easier to just 'dnf remove zram-generator-defaults' but
> that is a Fedora specific instruction.

After some thought, this is what I did after I posted the message.
Makes sense, can't run if it isn't there. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: swap on zram

[stan via devel]

On Thu, 4 Jun 2020 16:30:07 -0400
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/SwapOnZRAM

>  How can it be disabled? 
> 
> Immediately:
> swapoff /dev/zram0
> 
> Permanently:
> rm /etc/systemd/zram-generator.conf

I realize this is a really late reply, but I wanted to disable this
since it was never used, and when I looked at the man pages this
information was not in them.  I think it should be.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Building kernel rpms with KASAN enabled

[stan via devel]

On Thu, 16 Jul 2020 11:02:02 -0400
Steve Grubb  wrote:
 
> What is the best way to build an official Fedora kernel SRPM with
> KASAN=y?

This is the official documentation for building a custom kernel.

https://fedoraproject.org/wiki/Building_a_custom_kernel

It might already be set in the stock Fedora kernel.  You could go into
/boot and run
grep -i kasan on one of the configuration files.  All my kernels are
custom builds, so I can't check the stock setting, but mine have it
turned on.

I use rpmbuild because I've been building custom kernels from the
srpm for a long time, but that is now deprecated in favor of fedpkg or
mock, I think.

If you want to run a custom kernel in uefi secure mode, you will have
to generate a local key pair, and sign the custom kernel with pesign.
If you don't have the rh-test-cert installed in the efi key database,
you will have to remove it from the kernel binary using pesign, as well,
or it won't be found on boot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: The future of legacy BIOS support in Fedora.

[stan via devel]

On Thu, 09 Jul 2020 23:10:46 +0300
nick...@gmail.com wrote:

> On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:

> > That is, isn't this only an issue if the person doing the kernel
> > development hasn't generated their own key, and isn't signing their
> > kernels locally?  
> 
> To be honest, I don't know. Do all UEFI secure boot implementations
> allow you to add your own keys to the list of trusted keys?

I don't know, but I used Fedora tools to create the key pair, and
insert the public key (x86_64).  Anyway, just another data point in the
discussion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: The future of legacy BIOS support in Fedora.

[stan via devel]

On Thu, 09 Jul 2020 18:07:39 +0300
nick...@gmail.com wrote:

> Yes, that's why "secure boot" should only be an option and the user
> must have the option to turn it off. Otherwise, it wouldn't be
> possible to do any kernel development on that computer.

For my edification.  I build custom kernels, and sign them using
pesign with my own key that I generated locally, and put in the EFI key
database. I can then boot the custom kernel in secure mode.  Couldn't I
also sign modules if I ever generated them with that same key?

That is, isn't this only an issue if the person doing the kernel
development hasn't generated their own key, and isn't signing their
kernels locally?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[stan via devel]

On Mon, 08 Jun 2020 09:29:27 -0600
Jeff Law  wrote:

> On Sun, 2020-06-07 at 13:07 -0700, stan via devel wrote:
> > On Thu, 4 Jun 2020 16:30:09 -0400
> > Ben Cotton  wrote:
> >   
> > > https://fedoraproject.org/wiki/Changes/CompilerPolicy
> > > An obvious example is Firefox.  Upstream, the Firefox project
> > > builds primarily with Clang/LLVM.  Yet we force the Fedora
> > > package owner to find and fix issues building with GCC then
> > > either carry those custom fixes forward in Fedora or negotiate
> > > with upstream to get those changes upstreamed.  While this
> > > process can be helpful in finding non-portable code, this is
> > > ultimately a poor use of the packager's time.  
> > 
> > I compile firefox nightly locally from an hg repository.  What I
> > notice is that although mozilla officially states that it is
> > possible to limit resource use, even though I set a maximum thread
> > count, or maximum load, the clang compiler grabs every core and
> > maxes it out to 100%. Will this change help with that?  i.e.  is
> > this a clang problem?  Or is my experience because of a problem
> > with the firefox compilation process?  
> It's unclear if it's a problem in Clang/LLVM or the firefox build
> procedures. Regardless, this proposal shouldn't change/improve your
> issue in any way.

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

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

[stan via devel]

On Thu, 4 Jun 2020 16:30:09 -0400
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/CompilerPolicy

> An obvious example is Firefox.  Upstream, the Firefox project builds
> primarily with Clang/LLVM.  Yet we force the Fedora package owner to
> find and fix issues building with GCC then either carry those custom
> fixes forward in Fedora or negotiate with upstream to get those
> changes upstreamed.  While this process can be helpful in finding
> non-portable code, this is ultimately a poor use of the packager's
> time.

I compile firefox nightly locally from an hg repository.  What I notice
is that although mozilla officially states that it is possible to limit
resource use, even though I set a maximum thread count, or maximum
load, the clang compiler grabs every core and maxes it out to 100%.
Will this change help with that?  i.e.  is this a clang problem?  Or is
my experience because of a problem with the firefox compilation process?
Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[stan via devel]

On Sat, 6 Jun 2020 06:40:43 -0500
Richard Shaw  wrote:

> On Sat, Jun 6, 2020 at 5:54 AM Andy Mender 
> wrote:

> > As someone who just recently started out with packaging and has a
> > fresh view on the problem, I would be more than happy to help out
> > with the docs :).
> >  
> 
> YES PLEASE. Documentation isn't necessarily and afterthought, but
> it's not "fun" and not many people want to do it.

It is *hard*.  Good documentation requires an intimate knowledge of the
system, and all the permutations it can exhibit.  Writing about that is
not a slap dash onto the page / screen if it is going to be useful for
both beginners and old hands, it is *work*.  Read some of the official
documentation manuals for proprietary software: turgid and exhaustive,
with excruciating detail.

Add Fedora's high rate of change, and it becomes understandable why
documentation is lagging.  That rate of change doesn't make
documentation less useful, though, rather the opposite.  So, needed
more, provided less => high barrier to entry.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Supporting hibernation in Workstation ed., draft 1

[stan via devel]

On Thu, 4 Jun 2020 13:01:37 -0600
Chris Murphy  wrote:

> > Just following the conversation for information purposes, but I have
> > questions.  If systemd-boot were to be used as boot service,  could
> > the hibernate image be written to /boot/efi in place of the kernel
> > and initramfs, or in parallel? Would systemd-boot be able to use
> > it?  Would that satisfy the encrypted and signed requirements?  
> 
> No to all sadly.
> 
> On Linux, neither GRUB or sd-boot directly consume the hibernation
> image to perform resume. Bootloader and firmware based hibernation
> resumption is found on Windows and macOS (there are many hibernation
> implementations on Windows). On Linux, this is a kernel feature, so
> the bootloader loads kernel and initramfs and boots normally; the
> kernel uses a kernel parameter hint(s) to discover the location of the
> hibernation image within swap. And voila.
> 
> I think the kernel does have code to support Intel Rapid Start. This
> is a firmware based hibernation resume implementation, so first the
> firmware must support it. But honestly have no idea if it works
> exactly like it does on Windows. At least on Windows it requires a
> dedicated partition expressly for the hibernation image. And the
> firmware's Intel Rapid Start function is given a hint at hibernate
> time so i knows at next power on that it should resume from this
> hibernation image directly.
> 
> Anyway, it would take work to build a generic implementation supported
> in either bootloader.

Thanks for the information.  Too bad.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Supporting hibernation in Workstation ed., draft 1

[stan via devel]

On Thu, 4 Jun 2020 10:13:59 -0600
Chris Murphy  wrote:

> Also, as it relates to authenticated encrypted hibernation images, the
> upstream proposal is that since hibernation images can exist anywhere,
> they should always be encrypted independently from swap, and therefore
> not depend on whether swap is encrypted or how.

Just following the conversation for information purposes, but I have
questions.  If systemd-boot were to be used as boot service,  could the
hibernate image be written to /boot/efi in place of the kernel and
initramfs, or in parallel? Would systemd-boot be able to use it?  Would
that satisfy the encrypted and signed requirements?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Does the installer detects when a distro have already created BLS?

[stan via devel]

On Sun, 24 May 2020 14:56:34 -0400
Paul Dufresne via devel  wrote:

> I have installed the May 22 Rawhide on a disk today, and I am now 
> realizing that the installer did not helped me enough to create valid 
> Boot Loader Specification partitions.
> 
> So I wanted (still want) to make this disk dual boot (Fedora and
> NixOS).
> 
> Because NixOS does not follows BLS (I think... thought... I should 
> verify)... well I decided to create two boot partitions, one for the 
> Fedora BLS partition, and an other for NixOS.

Good thought.  Does NixOS allow the use of uefi?  If it doesn't, it
will definitely need a separate partition for /boot.

> And my idea was to create a big LVM(2) partition for more normal 
> partition: / and Swap... which I did.
> 
> I have chosen ext4 for my Fedora /boot, which is illegal according to 
> BLS: "$BOOT must be a VFAT (16 or 32) file system.".

I think $BOOT will be /boot/efi, and that is required to be vfat.
/boot does *not* have to be vfat.

> The installer, then forced my hand to add a /boot/efi partition,
> which I had not tought previously to add.
> 
> So I removed my LVM(2) partiton, add the /boot/efi partition, then
> added back my LVM(2) partition.
> 
> It finally installed...
> 
> One of the first problem I have, is /boot have not the correct GUID
> for BLS:
> 
> [paul@localhost /]$ cat /etc/fstab
> 
> #
> # /etc/fstab
> # Created by anaconda on Sun May 24 11:48:45 2020
> #
> # Accessible filesystems, by reference, are maintained under
> '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or
> blkid(8) for more info. #
> # After editing this file, run 'systemctl daemon-reload' to update
> systemd # units generated from this file.
> #
> /dev/mapper/myLVM-fedoraMain /   ext4 
> defaults    1 1
> UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4    defaults
>   1 2 UUID=62BD-AFFC  /boot/efi   vfat 
> umask=0077,shortname=winnt 0 2
> /dev/mapper/myLVM-fedoraSwap none    swap 
> defaults    0 0
> [paul@localhost /]$
> 
> Reading the BLS, it seems the installer did not generated a valid
> entry /boot... not the valid type (vfat, EFS)... nor a valid UUID.
> 
> Oh well, the other way of saying it is the installer did not force me
> to generate a valid /boot partition.

Because it is under / in the lvm.  /boot does not have to be vfat, it
is /boot/efi that has to be vfat.  If you want a separate /boot for the
/ in the lvm you will have to create a separate partition for it during
install (custom), but it is *not* required, thus why you did not get a
prompt.

> I have:
> 
> [paul@localhost /]$ sudo parted /dev/sda -- print
> [sudo] Mot de passe de paul :
> Modèle : ATA ST500LM021-1KJ15 (scsi)
> Disque /dev/sda : 500GB
> Taille des secteurs (logiques/physiques) : 512B/4096B
> Table de partitions : gpt
> Drapeaux de disque :
> 
> Numéro  Début   Fin    Taille  Système de fichiers Nom
> Drapeaux
>   1  1049kB  268MB  267MB   ext4
>   2  269MB   479MB  210MB fat16
> démarrage, esp
>   3  479MB   701MB  222MB   fat16    EFI System 
> Partition  démarrage, esp
>   4  701MB   194GB 
> 193GB  lvm
> 
> [paul@localhost /]$ lsblk
> NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda    8:0    0 465,8G  0 disk
> ├─sda1 8:1    0   255M  0 part /boot
> ├─sda2 8:2    0   200M  0 part
> ├─sda3 8:3    0   212M  0 part /boot/efi
> └─sda4 8:4    0   180G  0 part
>    ├─myLVM-fedoraMain 253:0    0    80G  0 lvm  /
>    └─myLVM-fedoraSwap 253:1    0 9G  0 lvm  [SWAP]
> sr0   11:0    1   6,6G  0 rom
> /run/media/paul/090130_0113 [paul@localhost /]$

Fedora can't run without a 
/ partition, usually defaults to ext4, but many other fs types available

/boot, ext? usually, but I *think* can be *some* other types. Can be
under /, then no separate /boot needed.  /boot under the / partition
the default now.  
Is there not a /boot under the / in the lvm partition
after install?   Are there not entries in /boot/loader/entries/ of the
/boot in the lvm partition?

/boot/efi required to be vfat by the uefi standard
Is there no /boot/efi/EFI/fedora directory with entries corresponding
to the lvm partition?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Re-Launching the Java SIG

[stan via devel]

On Sat, 16 May 2020 11:23:03 +0200
Nicolas Mailhot  wrote:

> Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > On Fri, 15 May 2020 08:02:34 +0200
> > Michal Srb  wrote:
> > 
> > An aside, just to clarify for myself.  That means that all Java apps
> > are
> > the equivalent of statically linked, right?  And are related to
> > things
> > like flatpaks and modules?  
> 
> No, that’s similar to venv everywhere. The language has bytecode-
> sharing objects. Java upstreams just got used not to share those
> executable objects between projects, not to version them properly, not
> to manage their ABI breaks, and to change things in the local copy
> instead of contributing changes to the original project.
> 
> That’s non-free software open source to its extreme. The code is
> available for a dev to copy and resell at his next work, but
> everything is organised (at the human not technical level) so it’s
> not possible to reuse the bytecode directly without paying someone to
> copy and fork the original code that this bytecode was generated from
> in the next project.
> 
> The practical effect is technical stagnation and market capture by
> deep pocket companies.

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

[stan via devel]

On Fri, 15 May 2020 08:02:34 +0200
Michal Srb  wrote:

> > I realize that this is technically possible to achieve, but that is
> > not how people use it. If you want to distribute your Java app, you
> > just bundle it with all its dependencies into a beefy tarball and
> > ship it. And if Java apps never share dependencies, then developers
> > are not really forced to keep up with latest versions of libraries.
> > Nobody can update the non-existent system-wide Java library that
> > would break their application. They are in control.

An aside, just to clarify for myself.  That means that all Java apps are
the equivalent of statically linked, right?  And are related to things
like flatpaks and modules?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: f32-backgrounds look like crap

[stan via devel]

On Fri, 17 Apr 2020 12:49:48 -
"Leigh Scott"  wrote:

> If there any plan to fix them?
> 
> https://leigh123linux.fedorapeople.org/pub/screenshots/Screenshot%20from%202020-04-17%2013-32-22.png

As a contrasting opinion, I accept, and am indifferent to, whatever
wallpaper the Fedora release process chooses.  I don't know if it will
work on your system, but I use wallpapoz, and only see images that I
have chosen to see after the first boot or two.  I set it so that every
window gets a different background.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Wed, 15 Apr 2020 15:46:02 +0200
Lennart Poettering  wrote:

> resolved has three modes:

[Snipped for brevity.]

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 18:39:05 -0500
Michael Catanzaro  wrote:

> On Tue, Apr 14, 2020 at 3:52 pm, stan via devel 
>  wrote:
> > Will the ability to turn off NetworkManager involvement in DNS in
> > the configuration file (None) still remain?  I use a local caching
> > DNS server, and had to do that in order to allow it to run without
> > interference / override by NetworkManager.  
> 
> Of course. You just have to set dns=None in your 
> /etc/NetworkManager.conf, as before. Also: 'systemctl disable 
> systemd-resolved.service'.

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 15:52:55 -0700
stan via devel  wrote:

> On Tue, 14 Apr 2020 16:18:02 -0500
> Michael Catanzaro  wrote:
>  
> > NetworkManager has three DNS backends: default (nss-dns, what we
> > use currently), dnsmasq, and systemd-resolved. The default backend
> > just does the wrong thing and cannot be fixed. When either dnsmasq
> > or systemd-resolved is in use, NetworkManager will go ahead and do
> > the right thing by telling dnsmasq/systemd-resolved which network 
> > interfaces should be used to resolve which hostnames. I consulted
> > with the NetworkManager developers and they recommended
> > systemd-resolved over dnsmasq, although I understand that dnsmasq is
> > good too.  
> 
> Will the ability to turn off NetworkManager involvement in DNS in the
> configuration file (None) still remain?  I use a local caching DNS
> server, and had to do that in order to allow it to run without
> interference / override by NetworkManager.

Just a further note.  I tried both dnsmasq and systemd-resolved, but
neither seemed to work.  I still saw my browser saying 
Looking up blah-blah.com ...
and timing for seconds even if I just visited the page a few minutes
before.  Once I set up my own caching DNS server, that went away except
when I visit a new site.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 16:18:02 -0500
Michael Catanzaro  wrote:
 
> NetworkManager has three DNS backends: default (nss-dns, what we use 
> currently), dnsmasq, and systemd-resolved. The default backend just 
> does the wrong thing and cannot be fixed. When either dnsmasq or 
> systemd-resolved is in use, NetworkManager will go ahead and do the 
> right thing by telling dnsmasq/systemd-resolved which network 
> interfaces should be used to resolve which hostnames. I consulted
> with the NetworkManager developers and they recommended
> systemd-resolved over dnsmasq, although I understand that dnsmasq is
> good too.

Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain?  I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: v4l2loopback kernel module in Fedora?

[stan via devel]

On Mon, 6 Apr 2020 23:47:53 -0400
Christopher  wrote:

> I actually got it working with v4l2loopback. It normally works quite

That's great!

> well. But, changing settings still crashes.

That's not.

> Literally, all I have to do is: File -> Settings -> toggle any setting
> (just to make "Apply" button available) -> click Apply
> This results in a Segmentation fault every time.
> In any case, the settings are usually saved first, so when I restart,
> it's fine. If I get the motivation, I'll file a bug against the
> RPMFusion package.

Strange that the behavior is so different, especially on something as
basic as changing settings.

> As for the original issue regarding packaging: there is a ticket being
> tracked to get it upstream into the kernel:
> https://github.com/umlaeute/v4l2loopback/issues/268

Interesting, though I probably won't ever have a use for it, I think
I'll try building it into a custom kernel just for fun.  Since it
doesn't seem to be changing a lot, once and done.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introdction: nick black

[stan via devel]

On Mon, 6 Apr 2020 09:03:54 -0400
Nick Black  wrote:

> Now, a "notcurses-noffmpeg" version in Core and a
> "notcurses+ffmpeg" in Fusion seems reasonable. Is this kind of
> thing ever done?

I think this is still true for audacity, mplayer, and chromium so they
get patented video codec support. Before mpeg was completely off patent,
there were other audio applications where this happened, with the
rpmfusion version adding support for mp3.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: v4l2loopback kernel module in Fedora?

[stan via devel]

On Sun, 5 Apr 2020 21:44:16 -0400
Christopher  wrote:

> I'm probably going to abandon the effort anyway. obs-studio in Fedora
> crashes constantly every time I try to change the settings and save,
> so I couldn't figure out how to get it to work with v4l2loopback. I

You are using obs in a different way than I am, but it works without
issue here for my unsophisticated use.  I've never had a crash.  F31.  I
am able to change settings, I changed the keymappings to use the left
windows key, finally getting some use out of it.  I am using X, and I
start obs from a terminal so if anything *does* go wrong, I see the
output from the program.  I've been really pleased with its
performance, though I'm sure I'm not really stressing it out the way
you want to.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: v4l2loopback kernel module in Fedora?

[stan via devel]

On Sun, 5 Apr 2020 02:56:08 -0400
Christopher  wrote:

> Has anyone tried packaging v4l2loopback into Fedora? I'd really like
> to set up a screen capture device for video conferencing stuff, but I
> keep running into problems with SecureBoot. I don't really know what
> I'm doing with mokutil or DKMS and I'm generally uncomfortable
> building kernel modules myself. I would be far more comfortable simply
> installing directly from a Fedora RPM that contains the signed kernel
> module needed.

Have you looked at OBS?  It's actually a tool to create streaming
content, but it performs screen capture, and has key mappings so it can
be started and stopped without switching to the gui.  It is on
rpmfusion.

> Does anybody have the requisite knowledge to create Fedora packaging
> of v4l2loopback and is willing to package for F31? I'd be happy to
> test... and possibly co-maintain, if the package maintenance were
> sufficiently simple.

Not me.

This is the procedure I used to create a local key in order to sign
custom compiled kernels.  So, if you decide to plow on through, you
should be able to adapt it for your purposes.  Though, if Leigh is
right, and out of tree modules are forbidden as Fedora packages, you
will have to keep the module rpm on your system only.

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

Re: Bugzilla signal/noise ratio

[stan via devel]

On Mon, 23 Mar 2020 10:13:05 -0700
Kevin Fenzi  wrote:

> On Mon, Mar 23, 2020 at 03:35:11PM +0100, Dominik 'Rathann'
> Mierzejewski wrote:
> > On Monday, 23 March 2020 at 12:10, Daniel Pocock wrote:
> > [...]  
> > > The bottom line is that these tools need to support our
> > > workflows, not try to shoehorn us into a particular way of
> > > working.  
them to suit your workflow.
> > 
> > And I do sympathize as I didn't like them, either. That's why I
> > spent maybe 15 minutes deleting all default notifications and
> > adding only those I wanted, e.g. new version notifications, bodhi
> > update status changes and koschei build status changes. The link to
> > the configuration interface is in each notification e-mail.  
> 
> So, indeed you can customize these notifications, which perhaps not
> all maintainers are aware of.

I have a suggestion that probably would require a lot of work to set
up, but would solve this issue.

All the notification emails come with a reply-to address.  If a
packager sends a reply to a notification, an application receives the
email at that address, and cancels the sending of that type of
notification for that person (that email address). So, as a packager
goes about their daily work, if they don't want to receive a type of
notification, they just hit reply, and they never receive that type of
notification again. If they want to receive it in the future after
cancelling it, however, they will have to manually configure that.

The work is in writing an application to receive the emails and do the
cancellation of future emails.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[stan via devel]

On Wed, 4 Mar 2020 09:22:12 -0700
stan via devel  wrote:

> On Wed, 4 Mar 2020 16:24:58 +0100
> Miroslav Suchý  wrote:
> 
> > But very likely you get some dependency problem now. In that case,
> > please report it against the appropriate package. Or against
> > fedora-obsolete-packages if that package should be removed in Fedora
> > 32. Please check existing reports first: https://red.ht/2kuBDPu
> 
> I hit 124 issues.  I have attached the dnf output.  That's a lot of
> bugzillas to open;  is there a better way?

When I looked at them, there were a lot of python2 problems.  Since it
is going away in F32, I just deleted them as problems.  That leaves
only 36 issues.  Much more manageable.  Attached.


Error: 
 Problem 1: problem with installed package 
python3-django-post_office-3.1.0-5.fc31.noarch
  - python3-django-post_office-3.1.0-5.fc31.noarch does not belong to a 
distupgrade repository
  - nothing provides python3.8dist(jsonfield) needed by 
python3-django-post_office-3.1.0-6.fc32.noarch
 Problem 2: package PyQt4-devel-4.12.3-7.fc31.x86_64 requires PyQt4(x86-64) = 
4.12.3-7.fc31, but none of the providers can be installed
  - PyQt4-4.12.3-7.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package PyQt4-devel-4.12.3-7.fc31.x86_64
 Problem 5: package blenderplayer-1:2.79b-17.fc31.x86_64 requires 
libOpenImageIO.so.2.0()(64bit), but none of the providers can be installed
  - OpenImageIO-2.0.13-1.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package blenderplayer-1:2.79b-17.fc31.x86_64
 Problem 6: package blueproximity-1.2.5-20.fc29.noarch requires pybluez, but 
none of the providers can be installed
  - pybluez-0.22-14.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package blueproximity-1.2.5-20.fc29.noarch
 Problem 8: package cegui-devel-doc-0.8.7-15.fc31.noarch requires cegui = 
0.8.7-15.fc31, but none of the providers can be installed
  - cegui-0.8.7-15.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package cegui-devel-doc-0.8.7-15.fc31.noarch
 Problem 10: package comedilib-devel-0.11.0-2.fc31.x86_64 requires 
libcomedi.so.0()(64bit), but none of the providers can be installed
  - package comedilib-devel-0.11.0-2.fc31.x86_64 requires comedilib(x86-64) = 
0.11.0-2.fc31, but none of the providers can be installed
  - comedilib-0.11.0-2.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package comedilib-devel-0.11.0-2.fc31.x86_64
 Problem 17: package gcc-python-plugin-c-api-0.17-4.fc31.x86_64 requires (gcc 
>= 9 with gcc < 10), but none of the providers can be installed
  - gcc-9.2.1-1.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package gcc-python-plugin-c-api-0.17-4.fc31.x86_64
 Problem 22: package gnomebaker-0.6.4-32.fc31.x86_64 requires 
libgstreamer-0.10.so.0()(64bit), but none of the providers can be installed
  - gstreamer-0.10.36-24.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package gnomebaker-0.6.4-32.fc31.x86_64
 Problem 23: package gstreamer-rtsp-0.10.8-25.fc31.x86_64 requires 
libgstrtp-0.10.so.0()(64bit), but none of the providers can be installed
  - package gstreamer-rtsp-0.10.8-25.fc31.x86_64 requires 
libgstrtsp-0.10.so.0()(64bit), but none of the providers can be installed
  - package gstreamer-rtsp-0.10.8-25.fc31.x86_64 requires 
libgstsdp-0.10.so.0()(64bit), but none of the providers can be installed
  - package gstreamer-rtsp-0.10.8-25.fc31.x86_64 requires 
libgstapp-0.10.so.0()(64bit), but none of the providers can be installed
  - gstreamer-plugins-base-0.10.36-24.fc31.x86_64 does not belong to a 
distupgrade repository
  - problem with installed package gstreamer-rtsp-0.10.8-25.fc31.x86_64
 Problem 24: package gxine-mozplugin-0.5.910-5.fc31.x86_64 requires gxine = 
0.5.910-5.fc31, but none of the providers can be installed
  - gxine-0.5.910-5.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package gxine-mozplugin-0.5.910-5.fc31.x86_64
 Problem 25: package hibernate-search-5.5.4-2.fc26.noarch requires 
mvn(org.apache.lucene:lucene-facet), but none of the providers can be installed
  - lucene-facet-7.7.0-2.fc31.noarch does not belong to a distupgrade repository
  - problem with installed package hibernate-search-5.5.4-2.fc26.noarch
 Problem 26: package k3d-devel-0.8.0.6-24.fc31.x86_64 requires 
libk3d-solar-solpos.so.1()(64bit), but none of the providers can be installed
  - package k3d-devel-0.8.0.6-24.fc31.x86_64 requires 
libk3dsdk-expression.so.1()(64bit), but none of the providers can be installed
  - package k3d-devel-0.8.0.6-24.fc31.x86_64 requires 
libk3dsdk-half.so.1()(64bit), but none of the providers can be installed
  - package k3d-devel-0.8.0.6-24.fc31.x86_64 requires 
libk3dsdk-ngui.so.1()(64bit), but none of the providers can be instal

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

[stan via devel]

On Wed, 4 Mar 2020 16:24:58 +0100
Miroslav Suchý  wrote:

> But very likely you get some dependency problem now. In that case,
> please report it against the appropriate package. Or against
> fedora-obsolete-packages if that package should be removed in Fedora
> 32. Please check existing reports first: https://red.ht/2kuBDPu

I hit 124 issues.  I have attached the dnf output.  That's a lot of
bugzillas to open;  is there a better way?

Error: 
 Problem 1: problem with installed package 
python3-django-post_office-3.1.0-5.fc31.noarch
  - python3-django-post_office-3.1.0-5.fc31.noarch does not belong to a 
distupgrade repository
  - nothing provides python3.8dist(jsonfield) needed by 
python3-django-post_office-3.1.0-6.fc32.noarch
 Problem 2: package PyQt4-devel-4.12.3-7.fc31.x86_64 requires PyQt4(x86-64) = 
4.12.3-7.fc31, but none of the providers can be installed
  - PyQt4-4.12.3-7.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package PyQt4-devel-4.12.3-7.fc31.x86_64
 Problem 3: package audio-convert-mod-3.46.0b-18.fc31.noarch requires 
python2-mutagen, but none of the providers can be installed
  - python2-mutagen-1.42.0-5.fc31.noarch does not belong to a distupgrade 
repository
  - problem with installed package audio-convert-mod-3.46.0b-18.fc31.noarch
 Problem 4: package audit-viewer-0.7.4-17.fc31.x86_64 requires 
gnome-python2-gnome, but none of the providers can be installed
  - gnome-python2-gnome-2.28.1-27.fc31.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package audit-viewer-0.7.4-17.fc31.x86_64
 Problem 5: package blenderplayer-1:2.79b-17.fc31.x86_64 requires 
libOpenImageIO.so.2.0()(64bit), but none of the providers can be installed
  - OpenImageIO-2.0.13-1.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package blenderplayer-1:2.79b-17.fc31.x86_64
 Problem 6: package blueproximity-1.2.5-20.fc29.noarch requires pybluez, but 
none of the providers can be installed
  - pybluez-0.22-14.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package blueproximity-1.2.5-20.fc29.noarch
 Problem 7: package bubbros-1.6.2-8.fc30.x86_64 requires pygame, but none of 
the providers can be installed
  - python2-pygame-1.9.6-1.fc31.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package bubbros-1.6.2-8.fc30.x86_64
 Problem 8: package cegui-devel-doc-0.8.7-15.fc31.noarch requires cegui = 
0.8.7-15.fc31, but none of the providers can be installed
  - cegui-0.8.7-15.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package cegui-devel-doc-0.8.7-15.fc31.noarch
 Problem 9: package chameleon-0.2-15.fc29.noarch requires python2-ply, but none 
of the providers can be installed
  - python2-ply-3.11-3.fc31.noarch does not belong to a distupgrade repository
  - problem with installed package chameleon-0.2-15.fc29.noarch
 Problem 10: package comedilib-devel-0.11.0-2.fc31.x86_64 requires 
libcomedi.so.0()(64bit), but none of the providers can be installed
  - package comedilib-devel-0.11.0-2.fc31.x86_64 requires comedilib(x86-64) = 
0.11.0-2.fc31, but none of the providers can be installed
  - comedilib-0.11.0-2.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package comedilib-devel-0.11.0-2.fc31.x86_64
 Problem 11: package decibel-audio-player-1.08-20.fc31.noarch requires 
gnome-python2-gnomekeyring, but none of the providers can be installed
  - gnome-python2-gnomekeyring-2.32.0-38.fc31.x86_64 does not belong to a 
distupgrade repository
  - problem with installed package decibel-audio-player-1.08-20.fc31.noarch
 Problem 12: package exaile-4.0.0-3.fc31.noarch requires python2-dbus, but none 
of the providers can be installed
  - python2-dbus-1.2.8-6.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package exaile-4.0.0-3.fc31.noarch
 Problem 13: package expendable-0.0.10-10.fc29.noarch requires 
gnome-python2-gconf, but none of the providers can be installed
  - gnome-python2-gconf-2.28.1-27.fc31.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package expendable-0.0.10-10.fc29.noarch
 Problem 14: package firmware-tools-2.1.15-5.fc29.noarch requires python2-rpm, 
but none of the providers can be installed
  - python2-rpm-4.15.1-1.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package firmware-tools-2.1.15-5.fc29.noarch
 Problem 15: package fwbackups-1.43.7-6.fc29.noarch requires python2-notify, 
but none of the providers can be installed
  - python2-notify-0.1.1-42.fc31.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package fwbackups-1.43.7-6.fc29.noarch
 Problem 16: package fwfstab-0.04-0.16.rc1.fc28.noarch requires 
python2-pyparted, but none of the providers can be installed
  - python2-pyparted-1:3.11.2-2.fc31.x86_64 does not belong to a distupgrade 

Re: Change proposal discussion - Optimize SquashFS Size

[stan via devel]

On Sun, 16 Feb 2020 10:57:26 -0700
"John M. Harris Jr"  wrote:

> On Monday, February 10, 2020 10:53:45 AM MST Jared K. Smith wrote:
> > On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr
> > 
> > 
> > wrote:  
> > > As for the software available, that's called choice. I know
> > > it's a relative unknown in the GNOME world, as one option is
> > > shoved down everyones' throat, but it's a key part of the KDE
> > > ideology, as well as GNU/
> > > Linux itself.  
> > 
> > John, it's obvious from your posts in this list that you're not a
> > fan of GNOME.  I'd kindly ask you to please refrain from attacking
> > GNOME, especially when the discussion at hand isn't about GNOME
> > itself.  It's not in keeping with the "be excellent to each other"
> > spirit that Fedora likes to keep in its mailing lists.
> > 
> > --
> > Jared Smith  
> 
> An observation is not an attack. What I said about GNOME is simply
> true, and is commonly considered a good thing by GNOME developers on
> this list. I just don't agree with that, and thus far there is no
> rule against disagreeing with the GNOME mindset.

No dog in this fight, so I'll probably get my just desserts for butting
in, but even if what you said about gnome is true, the way you stated
your viewpoint would be considered hostile and attacking by an unbiased
bystander.  Me, for instance.  There was no need to throw in the put
down of gnome.  You could have just said, "... called choice, one of
the basic principles of GNU / Linux.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: orphaning bleachbit

[stan via devel]

On Sun, 22 Dec 2019 21:57:01 +0100
Alessio  wrote:

> As I wrote in another e-mail, upstream is working to port the program
> to python3. There is a related branch on github.

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

[stan via devel]

On Sun, 19 May 2019 11:05:46 +0200
Silvia Sánchez  wrote:
 
> Yes, I know Python 2 will be soon removed, but I can't just let
> Bleachbit die.  It's too useful for that.
> Finding a sponsor seems to be the hard bit.  I've been looking for
> one for ages.

I have never used bleachbit, but I took a look at this program to see if
it would be a simple matter to convert it to python3.  It won't.  The
program uses the python2 and gtk2 module pygtk.  To convert it to
python3, the entire program would have to be rewritten to use gtk3 for
python3. gtk2 and gtk3 don't have the same api calls, so someone with
domain knowledge of gtk2 and gtk3 would have to do this (I don't have
that knowledge).

It looks like the command line version doesn't use the gtk module, only
the gui version.  So it probably would be fairly simple to convert the
program to a python3 version that only worked via the command line by
stripping all the gui code.  As long as the other modules it uses to
do its actual function are compatible with python3.  I didn't check that
deeply.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[stan via devel]

On Fri, 13 Dec 2019 15:34:29 -0500
Mike Pinkerton  wrote:

> I would say that the Everything netinstall image is more useful than  
> the Workstation Live image:
> 
> *  netinstall is smaller
> *  netinstall can be used to install servers
> *  netinstall with updates repo enabled yields current system without
> doing the almost inevitable post-install (from non-netinstall image)  
> update

+1
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Something wrong with kernel-headers on fedora 30?

[stan via devel]

On Thu, 07 Nov 2019 13:31:23 -0500
"James Cassell"  wrote:

> On Thu, Nov 7, 2019, at 1:23 PM, Joseph D. Wagner wrote:
> > I am on kernel 5.3.8 but I still have 
> > kernel-headers-5.3.6-200.fc30.x86_64, which hasn't updated.
> > 
> > Is there a reason a new kernel-headers package hasn't been
> > generated for the newer versions?  Has it be superseded by another
> > package? If so, then dependencies on glibc-headers need to be fixed.
> >   
> 
> I've also been confused why kernel-headers is a separate SRPM...

I have nothing to do with this change, but it has been in place for at
least 6 months, and maybe almost a year.  If the kernel api doesn't
change with a new version, there is no need to create new header files.
I assume it was done to cut down on compile time, spec file complexity,
and installation size and time (resource churn).

Maybe someone else can clarify more authoritatively.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Encrypted DNS in Fedora

[stan via devel]

On Thu, 7 Nov 2019 12:20:50 +0100
David Sommerseth  wrote:
 
> Please just watch the talk by Paul Vixie (who is one of the really
> big DNS gurus these days, even ISC BIND maintainer for quite some
> years).  And you will see that DoH is pointless when you have DoT.
> But DoT can also go much further than DoH will, when you consider the
> bigger part of the DNS query chain.

Thank you for pointing to that talk.  I found it very informative, as a
mostly ignorant user of DNS.  I run knot-resolver as a local caching DNS
server, pulling from, ironically, 1.1.1.1 via the router, and bypassing
my ISP's DNS servers.  Really opened my eyes.

For convenience, repeating it here.
https://www.youtube.com/watch?v=8SJorQ9Ufm8
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GNU IceCat Updates

[stan via devel]

On Sat, 26 Oct 2019 01:25:10 +0330
Alireza Hayati  wrote:

> Hello. I don't know if I'm right to ask this in this mailing list and
> if I should post this elsewhere, please forgive me bothering you.
> 
> I believe GNU IceCat updates are not shipped to Fedora repositories
> and we're still using 60.9 version. How can I ask for updates or just
> remind maintainers about it?
> 
> Thanks and sorry I bothered.

Asking here is OK, but you are more likely to get action if you open a
ticket asking for an update at
https://bugzilla.redhat.com
I checked koji, and it looks like it won't be in F31, but there are
several updated versions for rawhide, the future F32, the latest
being version 68.2.  I'm not sure why this is, perhaps there is a
feature it requires that won't arrive until F32.  The F32 keys
should be in F31 (there was some discussion about that happening), so
you could try downloading that package for your arch, and installing it
manually in F31 using
dnf -C update icecat
in the directory where the downloaded rpm is.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1404006

You'll probably want to download the icecat-x11 package as well, and
install them together.
dnf -C update icecat icecat-x11
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org