Unresponsive maintainers python-rsa python-ruamel-yaml

[Jason Montleon]

I am looking to get python-rsa and python-ruamel-yaml built for EPEL-8 
so I can finish building python-kubernetes and python-openshift for 
EPEL-8. I've managed to get in contact with maintainers for most of the 
dependencies and builds are completed, but so far with these two I have 
been unable.


I sent emails on 23 Oct 2019 and again on 5 Nov 2019 to the maintainers 
of these packages.


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

While looking for additional bugs I found the python-ruamel-yaml 
maintainer was already reported non-responsive:

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

Additional BZ's:
https://bugzilla.redhat.com/show_bug.cgi?id=1700334

Does anyone know how to get in contact with the maintainers for these 
packages?


Thanks,
--
Jason Montleon | email: jmont...@redhat.com
Software Engineer  | gpg key: 0x069E3022
Red Hat, Inc.  | irc: jmontleo
desk: 978-392-3930 | cell: 508-496-0663
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Workstation and disabled by default firewall

[Jason Montleon]

Imagine starting up VNC, having no intention of opening port 59xx, and 
intending to use SSH tunneling to connect to the service.


You think you're being more diligent only to later find out the service 
is actually exposed by the default firewall policy.


On 8/26/19 8:46 AM, Artem Tim wrote:

completely disabled by default (opened all ports 1025-65535) on Fedora 
Workstation?


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



--
Jason Montleon | email: jmont...@redhat.com
Software Engineer  | gpg key: 0x069E3022
Red Hat, Inc.  | irc: jmontleo
desk: 978-392-3930 | cell: 508-496-0663
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [EXT]Re: Fedora Workstation and disabled by default firewall

[Jason Montleon]

I don't see how that answer makes the users life any easier. Now rather 
than having to intentionally configure the firewall the user has to add 
flags or config options to listen on additional ports. It is just 
replacing one complexity with another.


The current behavior, in an effort to make casual users lives easier by 
disabling the firewall has gone ahead and intentionally made them less 
secure, which I would consider far worse.


A user with a service that isn't functioning as expected can use Google 
or read documentation to determine why, whereas a user who doesn't even 
know their system has been left intentionally less secure will simply be 
left none the wiser, possibly until it's too late.


On 8/26/19 10:23 AM, Anderson, Charles R wrote:

Perhaps VNC should default to listing only on the loopback interface.

On Mon, Aug 26, 2019 at 08:55:59AM -0400, Jason Montleon wrote:

Imagine starting up VNC, having no intention of opening port 59xx, and
intending to use SSH tunneling to connect to the service.

You think you're being more diligent only to later find out the service
is actually exposed by the default firewall policy.

On 8/26/19 8:46 AM, Artem Tim wrote:

completely disabled by default (opened all ports 1025-65535) on Fedora 
Workstation?


Not completely. Completely when from 1 to 65535. :)

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



--
Jason Montleon | email: jmont...@redhat.com
Software Engineer  | gpg key: 0x069E3022
Red Hat, Inc.  | irc: jmontleo
desk: 978-392-3930 | cell: 508-496-0663
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Workstation and disabled by default firewall

[Jason Montleon]

And even if they implemented it your way you are expecting that the
developer of the application and all the libraries it uses have
written perfect bug free code with zero vulnerabilities. By that logic
we should set selinux to disabled since it sometimes causes things to
break, can be difficult to diagnose, and everyone should have written
perfect code. It should be the users decision based on what they know
(are they on a private network they trust or a public network they
don't and so on) to decide if the risk is worth the convenience.

I have also never seen anywhere on a download page that there are
security implications for downloading Workstation instead of Server.

On Mon, Aug 26, 2019 at 7:10 PM Björn Persson  wrote:
>
> Jason Montleon wrote:
> >Imagine starting up VNC, having no intention of opening port 59xx, and
> >intending to use SSH tunneling to connect to the service.
> >
> >You think you're being more diligent only to later find out the service
> >is actually exposed by the default firewall policy.
>
> When I looked at VNC many years ago it was one of those programs that
> think "I don't need to bother with security. Someone else makes me
> secure somehow. I don't know how and I don't care.". Your wording
> suggests that the VNC you refer to still works that way.
>
> You have to be very careful and know exactly what you're doing if you
> use such programs. That "someone else" who makes them secure, that's
> you, the user, because no one else is doing it. If you fail to check
> whether you have a packet filter, then you're not being careful enough.
>
> The problem isn't that you're careless. The insecure program is the
> problem. Programs like that should come with big red warning labels
> saying not to touch them unless you know exactly what you're doing –
> but they don't, because they assume that someone else takes care of
> everything security-related.
>
> The better solution is for VNC to take responsibility for its own
> security. It could do so by using TLS, by integrating with SSH, or by
> requesting IPsec from the operating system. It should refuse to
> communicate without one of those encryption protocols, or at the very
> least require the user to explicitly turn off security. These days
> there seem to be several VNC variants that support some form of
> encryption. I don't know what their defaults are, but maybe some of
> them are responsible enough to not communicate insecurely.
>
> Björn Persson
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Workstation and disabled by default firewall

[Jason Montleon]

Not to mention that firewalld has the concept of services. I never
have to know a port number to expose a service if it's defined.
`firewall-cmd --add-service=postgresql`... that could just as well be
done with a UI without ever showing a port number to a user.

If applications that need ports exposed to work in some circumstances
have well written service files it should be a non-issue.

On Tue, Aug 27, 2019 at 8:56 AM Dan Book  wrote:
>
> On Tue, Aug 27, 2019 at 8:10 AM  wrote:
>>
>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris  wrote:
>>
>> No, that is not how this works, at all. First, let's go ahead and address 
>> the idea that "if the firewall blocks it, the app breaks, so it's the 
>> firewall's fault": It's not. If the firewall has not been opened, that just 
>> means it can't be accessed by remote systems until you EXPLICITLY open that 
>> port, with the correct protocol, on your firewall. That's FINE. That's how 
>> it's designed to work. There's nothing wrong with that. This means that the 
>> system administrator (or owner, if this is some individual's personal 
>> system) must allow the port to be accessed remotely, before the app can be 
>> reached remotely, increasing the security of the system.
>>
>>
>> You've already lost me here. Sorry, but we do not and will not install a 
>> firewall GUI that exposes complex technical details like port numbers. 
>> Expecting users to edit firewall rules to use their apps is ridiculous and 
>> I'm not really interested in debating it.
>>
>> If the user is capable of editing firewall rules and wants to do so, that 
>> user can surely also change the policy to not open all these ports. Yes?
>
>
> That Gnome is intentionally sabotaging users and thinks they are too stupid 
> to understand a port number associated with a service is just another example 
> why I wish that Fedora and Redhat would put work into alternative desktops.
>
> -Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Workstation and disabled by default firewall

[Jason Montleon]

On 8/27/19 7:36 AM, Björn Persson wrote:

Jason Montleon wrote:

And even if they implemented it your way you are expecting that the
developer of the application and all the libraries it uses have
written perfect bug free code with zero vulnerabilities.


You wanted to block VNC with a packet filter and kludge it into an SSH
tunnel. One of my suggestions was that VNC could integrate with SSH to
support that without the need for the kludge and the blocking. Any
vulnerabilities in VNC or SSH that would affect my approach would affect
yours just the same. If I'm expecting perfect code then so are you.

You tried a strawman argument, and got knocked out by your own strawman.

Björn Persson

What strawman? If VNC is behind an SSH tunnel TODAY and not exposed on 
the local network and has a vulnerability how will it be taken advantage 
of without first abusing a vulnerability or authenticating via SSH. 
Today. Not in a year when someone has maybe added the features you're 
dreaming of.


It's not like this is a Linux only problem with desktop sharing services 
either. See recent Windows vulnerabilities:

https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/

Your whole idea is premised on every application being written 
perfectly, which they're not, or we'd never have to do a dnf update to 
get security fixes. And you're really hung up on the example of VNC for 
some reason.


What about a rails developer who starts up mysql or postgres to do some 
development and suddenly their DB is exposed to the world without their 
explicitly opening the port and expecting it? What if their is a 
vulnerability in one of those now?


This firewall policy of having all these services exposed by default is 
just plain awful any way you look at it.

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



--
Jason Montleon | email: jmont...@redhat.com
Software Engineer  | gpg key: 0x069E3022
Red Hat, Inc.  | irc: jmontleo
desk: 978-392-3930 | cell: 508-496-0663
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review request/swap for cros-guest-tools

[Jason Montleon]

Hi,
I packaged the integration tools for running Fedora 29 as a guest on Chrome
OS under crostini.

Most of the binaries and other files are bind mounted into the container so
the rest of what is set up (and included in the packages) are just links,
configs, and systemd unit files.

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

I do have other packages but haven't done any reviews before. If it is an
option despite that I am happy to do a review in exchange.

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

Re: more distinct default bash prompt?

[Jason Montleon]

One of the things I discovered playing with tput last night trying
some of this is that it will error if you don't have a terminal.
ssh foo.example.com virsh start bar
tput: No value for $TERM and no -T specified

To correct this using your example you can do:
if [ -t 0 ]
then
   prompt_term[0]=$(tput bold)
   prompt_term[1]=$(tput setaf 1)  # red
   prompt_term[2]=$(tput sgr0)
   export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
==> "
fi

On Tue, May 23, 2023 at 7:10 AM Nick Clifton  wrote:
>
> >> What do people think overall? Are there other pros and cons of a color 
> >> prompt?
> >> Any better ideas or direction?
>
> I like the idea of using tput to get the correct strings for
> setting different terminal effects, so I now use:
>
># Success prompt:
>prompt_term[0]=$(tput bold)
>
># Fail prompt:
>prompt_term[1]=$(tput setaf 1)  # red
>
># Turn off all attributes
>prompt_term[2]=$(tput sgr0)
>
># Make the prompt reflect the exit status of the last command
>export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'" 
> ==> "
>
> Cheers
>Nick
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide

[Jason Montleon]

I have mentioned it before, but it is still the case that some of the
downstream arm64 patches are breaking RISC-V builds with errors like:
```
../../grub-core/loader/efi/linux.c: In function ‘parse_pe_header’:
../../grub-core/loader/efi/linux.c:692:9: error: invalid use of
undefined type ‘struct grub_armxx_linux_pe_header’
  692 |   if (pe->opt.magic != GRUB_PE32_PEXX_MAGIC)
```

This is based off somewhat older work, so I don't think commit below
lines up exactly but we're having to leave these out to build on
RISC-V:
Patch0253: 0253-Add-support-for-Linux-EFI-stub-loading-on-arm-archit.patch
Patch0254: 0254-arm-arm64-loader-Better-memory-allocation-and-error-.patch
Patch0255: 0255-arm64-Fix-EFI-loader-kernel-image-allocation.patch
Patch0257: 0257-Correct-BSS-zeroing-on-aarch64.patch
Patch0258: 0258-arm64-Use-proper-memory-type-for-kernel-allocation.patch

http://fedora.riscv.rocks:3000/rpms/grub2/commit/38415bc393864606b7b99be71dc30f3f519d06cb

The mcmodel in that PR is separate from the issue with these and
reported upstream.
https://savannah.gnu.org/bugs/?65909

On Fri, Aug 9, 2024 at 12:41 PM Adam Williamson
 wrote:
>
> On Thu, 2024-08-01 at 07:46 -0600, Leo Sandoval wrote:
> > >
> > > Any progress on this? We're gearing up to Flock and branching will be
> > > the week after Flock...
> > >
> >
> > No progress since last email... Still in the testing phase.
>
> There's progress now - the last build that was sent passed openQA
> testing, so it landed. We've had grub 2.12 in Rawhide for the last two
> days.
>
> So, uh, yay? If anyone can't boot any more...please fax us the details,
> I guess?
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Serial console getty chance since F-40 GA?

[Jason Montleon]

It may be this: https://bugzilla.redhat.com/show_bug.cgi?id=2290482

On Thu, Jun 20, 2024 at 5:00 PM Peter Robinson  wrote:
>
> Hi folks,
>
> I'm seeing an issue when using serial consoles, which I use quite a
> bit when doing low level HW pieces on Edge.
>
> The serial console getty isn't coming up automatically when I update
> from GA to the latest Fedora updates.
>
> If I run "systemctl enable serial-getty@ttyS0.service --now" it comes
> up, but I can't do that on devices that have no other access
> available.
>
> I'm wondering if this was intended for some reason, I'm not seeing
> anything specific that would cause it but I suspect systemd?
>
> Peter
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



--
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F35 no USB after today's updates

[Jason Montleon]

I have a similar system. lspci out looks near identical. The system was 
just booted this morning.


I normally run it headless with just power and network connected, but 
plugging in a USB mouse, thumb drive, and USB optical drive, they show 
up fine in dmesg and lsusb output using random USB ports on the front 
and back, as does the card reader on the front of the system. I mounted 
the thumb drive fine.


# dmidecode | grep -i Precision && uname -srvpi && lspci | grep USB
Product Name: Precision Tower 7810
Linux 5.14.16-301.fc35.x86_64 #1 SMP Wed Nov 3 13:55:42 UTC 2021 x86_64 
x86_64
00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB 
xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #1 (rev 05)



On 11/8/21 08:15, Sergio Pascual wrote:


El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen (>) escribió:


On Mon, 8 Nov 2021 at 06:53, Sergio Pascual mailto:sergio.pa...@gmail.com>> wrote:
 >
 > Hi, I upgraded my workstation to F35 last Friday, and today I
'dnf updated' and rebooted. After the reboot, all my USBs are
disabled. No mouse, no keyword.
 > I know my hardware works because the keyboard works in grub, and
the light of my optical mouse in on until some errors appear in the
kernel during boot.
 >
 > I have tried:
 > kernel-5.14.15-200.fc34.x86_64
 > kernel-5.14.15-300.fc35.x86_64
 > kernel-5.14.16-301.fc35.x86_64
 >

The developers will need to know what the exact motherboard/laptop
version and manufacturer you have in order to diagnose this issue. My
initial guess is that since the f34 kernel also fails, that the
problem is with a firmware module and whatever the motherboard is
expecting to use. [The fact that it is only finding USB2 says that
either the system is really old or that it is trying to fail to its
lowest working value.]




My workstation is a Dell Precision Tower 7910.

lscpi says I have the following serial bus controllers

00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB 
xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #1 (rev 05)


Regards


 > without success.
 > I'm getting messages like these:
 >
 > [   23.722355] usb 3-10: new high-speed USB device number 7 using
xhci_hcd
 > [   23.857746] usb 3-10: New USB device found, idVendor=0bda,
idProduct=0184, bcdDevice=84.13
 > [   23.857755] usb 3-10: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
 > [   23.857759] usb 3-10: Product: USB2.0-CRW
 > [   23.857762] usb 3-10: Manufacturer: Generic
 > [   23.857764] usb 3-10: SerialNumber: 2010081884130
 > [   24.016363] usb 3-7.1: new high-speed USB device number 8
using xhci_hcd
 > [   29.648377] usb 3-7.1: device descriptor read/64, error -110
 > [   45.520400] usb 3-7.1: device descriptor read/64, error -110
 > [   45.624451] usb 3-7-port1: attempt power cycle
 > [   45.738358] usb 3-13: new high-speed USB device number 9 using
xhci_hcd
 > [   45.865929] usb 3-13: New USB device found, idVendor=05e3,
idProduct=0608, bcdDevice=32.98
 > [   45.865939] usb 3-13: New USB device strings: Mfr=0,
Product=1, SerialNumber=0
 > [   45.865942] usb 3-13: Product: USB2.0 Hub
 > [   45.866653] hub 3-13:1.0: USB hub found
 > [   45.866992] hub 3-13:1.0: 4 ports detected
 > [   46.304365] usb 3-7.1: new high-speed USB device number 10
using xhci_hcd
 > [   56.160384] xhci_hcd :00:14.0: Abort failed to stop
command ring: -110
 > [   56.160384] xhci_hcd :00:14.0: xHCI host controller not
responding, assume dead
 > [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
 > [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for
setup device command
 > [   56.488480] usb 4-2: USB disconnect, device number 2
 > [   56.904366] usb 3-7.1: device not accepting address 10, error -108
 > [   56.904412] usb 3-7-port1: couldn't allocate usb_device
 > [   56.904464] usb usb3-port2: couldn't allocate usb_device
 > [   56.904502] usb 3-13-port1: couldn't allocate usb_device
 > [   56.904603] usb 3-3: USB disconnect, device number 2
 > [   56.927819] usb 3-6: USB disconnect, device number 3
 >
 >
 >
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org

 > To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

 > F

Re: Help wanted: Multiple packages with different ver-rel from one spec

[Jason Montleon]

I am not the maintainer of the package, but I am aware that there are 
two sources with two versions here:


https://src.fedoraproject.org/rpms/python-pyasn1/blob/f33/f/python-pyasn1.spec

The sub-package ends up with a provides with the modules version:
# rpm -q --provides python3-pyasn1-modules
python-modules = 0.4.8-3.fc33
python-pyasn1-modules = 0.4.8-3.fc33
python3-pyasn1-modules = 0.4.8-3.fc33
python3.9-modules = 0.4.8-3.fc33
python3.9-pyasn1-modules = 0.4.8-3.fc33
python3.9dist(pyasn1-modules) = 0.2.8
python3dist(pyasn1-modules) = 0.2.8

Perhaps something along these lines could be helpful.

On 2/4/21 1:44 PM, Matthew Miller wrote:

On Thu, Feb 04, 2021 at 06:37:12PM -, Artur Frenszek-Iwicki wrote:

Same tarball, separate versions. Dependency is one-way.


Well, that's annoying. I guess the next thought is: is there any point in
having the bundled library actually broken out into a subpackage, or should
it just be hidden as a bundled implementation detail?


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

Re: Review request for python-durationpy

[Jason Montleon]

Thank you for the review! I will start reviewing these for you this evening!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Review request for python-durationpy

[Jason Montleon]

Hi,
python-durationpy is a new dependency of python-kubernetes, so I need to 
package it in order to continue updating python-kubernetes.

I am happy to review a package in return if it also helps someone else get 
unblocked. 

Bugzilla URL: https://bugzilla.redhat.com/show_bug.cgi?id=2314132
Spec URL: https://people.redhat.com/jmontleo/python-durationpy.spec
SRPM URL: 
https://people.redhat.com/jmontleo/python-durationpy-0.9-1.fc41.src.rpm
Source URL: https://github.com/icholy/durationpy

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

[Jason Montleon]

For what it is worth I was able to build it on Fedora 41:
```
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/jason/rpmbuild/BUILD/thunderbird-128.4.2-build/BUILDROOT
Wrote: /home/jason/rpmbuild/SRPMS/thunderbird-128.4.2-1.fc41.src.rpm
Wrote: 
/home/jason/rpmbuild/RPMS/ppc64le/thunderbird-librnp-rnp-128.4.2-1.fc41.ppc64le.rpm
Wrote: 
/home/jason/rpmbuild/RPMS/ppc64le/thunderbird-librnp-rnp-debuginfo-128.4.2-1.fc41.ppc64le.rpm
Wrote: /home/jason/rpmbuild/RPMS/ppc64le/thunderbird-128.4.2-1.fc41.ppc64le.rpm
Wrote: 
/home/jason/rpmbuild/RPMS/ppc64le/thunderbird-debugsource-128.4.2-1.fc41.ppc64le.rpm
Wrote: 
/home/jason/rpmbuild/RPMS/ppc64le/thunderbird-debuginfo-128.4.2-1.fc41.ppc64le.rpm
Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.6Lpyox
+ umask 022
+ cd /home/jason/rpmbuild/BUILD/thunderbird-128.4.2-build
+ test -d /home/jason/rpmbuild/BUILD/thunderbird-128.4.2-build
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w
/home/jason/rpmbuild/BUILD/thunderbird-128.4.2-build
+ rm -rf /home/jason/rpmbuild/BUILD/thunderbird-128.4.2-build
+ RPM_EC=0
++ jobs -p
+ exit 0
...
```

Memory did seem very high during early stages of compile. It topped
out at a little over 90GB at some points
https://people.redhat.com/jmontleo/thunderbird-mem.png


On Mon, Nov 11, 2024 at 2:15 PM Kevin Fenzi  wrote:
>
> On Mon, Nov 11, 2024 at 05:49:59PM +0100, Florian Weimer wrote:
> >
> > The cause is reported as: (signal: 9, SIGKILL: kill)
> > So probably OOM.  It could be a genuine toolchain bug, or
> > the builders have to little memory assigned relative to core count.
>
> Yeah, as noted it's a balancing act. :(
>
> > (I can't get a suitable POWER system to reproduce right now.)
>
> Just a reminder we have:
>
> ppc64le-test.fedorainfracloud.org (power9)
> and
> ppc64le-test02.fedorainfracloud.org (power10)
>
> available for package maintainers.
>
> If that helps any.
>
> kevin
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



--
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

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

[Jason Montleon]

Thank you for the PR,  I have merged it.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Remove openh264?

[Jason Montleon]

I just had the same result, but this worked for me:

sudo dnf download noopenh264.x86_64
sudo dnf install noopenh264-2.5.0-2.fc42.x86_64.rpm --allowerasing

Trying to install from the repo without downloading gave similar
results to sudo dnf swap.

On Thu, May 29, 2025 at 5:55 AM Jonathan Schleifer  wrote:
>
> Thanks for bringing this to my attention - I had no idea Fedora would
> let something so serious be unfixed for so long, as I kinda assumed
> Fedora is on top of security updates. Time to immediately delete
> openh264 indeed! However:
>
> Am 29.04.25 um 19:21 schrieb Leigh Scott:
>
> > sudo dnf swap *\openh264\* noopenh264 --allowerasing
>
> Unfortunately that does not seem to work on f42:
>
> $ sudo dnf swap \*openh264\* noopenh264 --allowerasing
> Updating and loading repositories:
> Repositories loaded.
> Problem: cannot install the best candidate for the job
>- conflicting requests
>
> Package Arch   Version Repository
> Size
> Reinstalling:
>   openh264   x86_64 2.4.1-2.fc42fedora-cisco-op
>   1.1 MiB
> replacing openh264   x86_64 2.4.1-2.fc42fedora-cisco-op
>   1.1 MiB
>
> Transaction Summary:
>   Reinstalling:   1 package
>   Replacing:  1 package
>
> Total size of inbound packages is 419 KiB. Need to download 419 KiB.
> After this operation, 0 B extra will be used (install 1 MiB, remove 1 MiB).
> Is this ok [y/N]:
>
> Any other way to close this wide open security hole?
>
> --
> Jonathan
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

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

[Jason Montleon]

On Thu, Aug 7, 2025 at 2:13 PM Barry Scott  wrote:
>
> A user on the Fedora users list reported that selinux relabelling
> was not working.
>
> I can reproduce the problem in a F42 KDE aarch64 VM.
> But it works fine on my x86_64 desktop, also F42 KDE.

Is there anything like this in dmesg? If the file was created with an
improper context (if selinux was completely disabled for instance) you
may see something like:
[7.492519] audit: type=1400 audit(1754591921.507:4): avc:  denied
{ getattr } for  pid=682 comm="selinux-autorel" path="/.autorelabel"
dev="dm-0" ino=2370
scontext=system_u:system_r:selinux_autorelabel_generator_t:s0
tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0

You can reproduce this for yourself:
# touch /.autorelabel
# chcon -t unlabeled_t /.autorelabel

Rebooting you will get an avc and it won't relabel. Booting with
enforcing=0 on the kernel command line, or otherwise setting selinux
permissive, will allow it to relabel.

I just did this on an orange pi 5 (aarch64) running Fedora 42 and it
relabeled fine, so I don't think anything is wrong/different with
Fedora 42 aarch64.

> I got as far as finding the generator script that triggers
> the relabelling.
>
> How can I debug this script?
>
> My guess is that the generator is running in a sandbox.
> Where can I write a log file with /usr/bin/echo to?
> Or is there a better way to log messages?
>
> Barry
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon

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

[Jason Montleon]

I don't know how to retrieve any other logs. Those journalctl lines are 
truncated though; you can rerun the commands with --no-pager to see if they 
provide anything interesting as to what condition was unmet. There are at least 
a few possibilities, and it might at least narrow down what's going wrong.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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