Non-responsive maintainer: sabbaka

[Pierre-Yves Chibon]

Good Morning Everyone,

Since February 7th the packager sabbaka has been receiving a daily email asking
them to either adjust their bugzilla or their FAS account so the email address
in FAS matches an existing bugzilla account.

Having a bugzilla account is mandatory per:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account

sabbaka is maintainer of rpms/tlog

Does anyone know how to contact sabbaka?


Thanks,

Pierre



PS: the users dkaspar, kir and leogallego having been receiving the same email
since February 24th. Their attention to that email would be appreciated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-32-20210301.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-32-20210228.0):

ID: 793765  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/793765
ID: 793772  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/793772

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Self Introduction: Phil

[Frédéric Pierret]

Le 3/1/21 à 2:43 AM, Phil Dibowitz a écrit :

Hey all,

Hi I'm Phil, a new Fedora packager! Some of you may know me from devconf (both 
CZ and US) during my time at Facebook or as one of the co-founders of the 
Southern California Linux Expo (SCALE) conference. For the rest of you, hi, I'm 
Phil, nice to meet you! :)

I've been working on opensource - both my own and others - for over 2 decades 
now. I'm the primary author of iptstate, sugarjar, concordance, and PIUS. I'm a 
maintainer of Chef and Redhat's init-scripts/network-scripts. I've contributed 
to a bunch of other crap including the kernel.

I'm primarily going through the packager process to get sugarjar packaged for 
Fedora.

For those interested, sugarjar is a tool to help make working with github 
easier - especially when doing rebase or squash-based workflows which the base 
git tools struggle with. It is mostly just a glorified wrapper around `hub` and 
`git`.

And as suggested, my PGP fingerprint:
   121B DA2D 4ACB 6361 6B36 7A0E 58E1 1BB1 E414 D9AD

If I missed anything I should have included, yell at me accordingly. ;)



Hi Phil,

Welcome and enjoy to be around here on devel and packaging stuff. Don't 
hesitate to request help if needed here or on IRC #fedora-devel.

Best,
Frédéric



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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 1st March (Today)

[Aniket Pradhan]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 15
February at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a
public meeting, and open for everyone to attend. You can join us over:

IRC:
https://webchat.freenode.net/?channels=#fedora-neuro

or Matrix/Element:
https://matrix.to/#/!xgwUsLNGIoOAXMxGMQ:matrix.org?via=matrix.org&via=t2bot.io

The channel is also bridged to Telegram, so you can also join us there on the
@NeuroFedora group:
https://t.me/NeuroFedora

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 today'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20210301T13&p1=%3A&ah=1

The meeting will be chaired by @major (me). The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last week's meeting:
https://meetbot.fedoraproject.org/fedora-neuro/2021-02-15/neurofedora.2021-02-15-13.05.html
- Open Pagure tickets:
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Open bugs check: https://tinyurl.com/neurofedora-bugs
- Open package reviews check:
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- Koschei packages check:
https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F33/F34:
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks
Regards

Aniket Pradhan
http://home.iiitd.edu.in/~aniket17133/
Aliases: MeWjOr/major

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dilemma: -source repository data randomized by koji builder arch

[Vít Ondruch]

Dne 25. 02. 21 v 16:34 Fabio Valentini napsal(a):

Hello everybody,

There's a problem that's been puzzling me for months, since I started
writing the repochecker service (which provides the backend FTI/FTBFS
data for the new packager-dashboard):

There is no correct "source of truth" for BuildRequires / complete
package dependency graphs.

While SRPM *contents* are forbidden from being dependent on their
environment (e.g. Sources or Patches guarded by %ifarch / %if
%fedora), their metadata (RPM headers) will still potentially be
architecture-dependent.

For example: The most frequent case of this is packages disabling
support for Qt5WebEngine on ppc64le and s390x, because it's not
available on those architectures. That means %ifarch conditionals
wrapping the BuildRequires for Qt5WebEngine. But that leads to the
interesting problem of the SRPM file having architecture-dependent RPM
headers.



Would it be possible to use rich dependencies instead? E.g.

~~~

BuildRequires: (Qt5WebEngine %ifnarch pp64le)

~~~

The above certainly wont work, but having the generated dependencies to 
correspond with source dependencies would be worth of the effort.



Vít





However, because koji only keeps *one* SRPM file from each build (even
though they have potentially different metadata on different
architectures), and the architecture that one SRPM is generated on is
basically random, the contents of the -source repositories are,
basically, randomized, and unreliable.

The architecture-dependent nature of SRPM files in -source
repositories affects at least those tools and Fedora services:

- dnf builddep (errors when encountering foreign-arch dependencies,
even if they are guarded by %ifarch in the .spec file)
- dnf repoquery and repoclosure produce wrong results
- koschei gets confused by architecture-dependent BuildRequires and
claims "failed dependency resolution" for foreign-arch dependencies

I file an issue with koji asking for a way to get correct metadata for SRPMs:
https://pagure.io/koji/issue/2726

However, I agree that keeping 6 SRPM files with identical *content*
and only different *metadata* is incredibly wasteful. But koji is the
only place in the build pipeline at which the entire and correct
dependency information is available, and it's lost afterwards, because
the rebuilt SRPM files produced by mock on each architecture are
discarded. I don't know if there could be a way to expose an
"srpmdiff" between the SRPM files on different architectures ...

But I'd argue that it's definitely not good that there's currently *no
way* to query BuildRequires *correctly* and *reproducibly* (other than
possibly rebuilding all fedora SRPM files for each target
architecture, but I do not have the resources - nor the desire - to do
that, just to get correct dependency information).

For the repository data that's processed by repochecker (for the
packager-dashboard data), I needed to add hard-coded overrides for
those "false positives", which is definitely not scalable for the
hundreds of different architecture-dependent BuildRequires that exist
in Fedora, but I also don't have a way to find them other than "look
at the .spec file":

https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json

So, if anybody has an idea how we can solve this issue and actually
provide correct repository data, that would be great :(

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




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

Re: How to build RISC-V Fedora disk image by muself

[Takayuki Nagata]

I am not sure how the image is actually built, but I have tried to
build an image with appliance-creator on a RISC-V VM, and the built
image is bootable. In my case:

# dnf install appliance-tools
# wget 
http://fedora.riscv.rocks:3000/davidlt/fedora-riscv-kickstarts/raw/branch/master/fedora-riscv64-minimal-rawhide.ks
# vi fedora-riscv64-minimal-rawhide.ks
(enable repo and edit something to prevent errors by the following commend.)
# appliance-creator -n ThinCrust -c
fedora-riscv64-minimal-rawhide.ks --cache ./cache/

Then I have gotten ThinCrust/ThinCrust-sda.raw.xz file.

I have referred the following URLs to get the above steps.

http://fedora.riscv.rocks/koji/taskinfo?taskID=320958
https://fedoraproject.org/wiki/Features/ApplianceTools
https://pagure.io/appliance-tools

Takayuki Nagata

2021年3月1日(月) 2:57 Richard W.M. Jones :
>
> On Sun, Feb 28, 2021 at 11:43:28PM +0800, Jinyan wrote:
> > I tried to boot fedora in qemu according to the steps given in [1].
> > During this process, I used the disk image named `Fedora-Developer-
> > Rawhide-*.raw.xz`.
>
> They are built by Koji, and TBH I'm not precisely sure how.  I think
> Koji has a way to compose disk images.  CC-ing David Abdurachmanov who
> runs the Koji RISC-V instance.
>
> > I am curious about what is inside and how to
> > compile and generate it. Where can I get the steps to generate it ?
>
> If you mean how are the component RPMs built, then it's using the Koji
> instance here:
>
> http://fedora.riscv.rocks/koji/
>
> and they are built in exactly the same way as any other Fedora
> architecture, except we have our own Koji instance and RISC-V
> hardware.  The sources are the regular Fedora dist-git.
>
> > Thank you
> >
> > [1] https://fedoraproject.org/wiki/Architectures/RISC-V/Installing
>
> You can use virt-install + anaconda to build your own disk image, and
> that should work exactly the same as for any other architecture
> (except for adjusting paths to point to the RISC-V repos rather than
> the normal Fedora ones).  In fact there are instructions on the page
> linked above for using virt-install.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: split-DNS, resolvconf on Fedora (OpenVPN related issues)

[Petr Menšík]

On 2/25/21 4:50 PM, David Sommerseth wrote:
> Hi!
> 
> On 25/02/2021 14:39, Petr Menšík wrote:
> [..snip...]
>>
>> This case is exactly what I am trying to prevent. There is multiple
>> implementations of dns cache, most of them can support split-DNS by some
>> configuration. If openvpn supports systemd-resolved natively, does that
>> mean it would not be able to support split-DNS on dnsmasq or unbound?
>> What is motivation to support specific implementation instead of generic
>> interface? I don't want to ask openvpn to support also dnsmasq or
>> unbound natively, because I think there should be middle layer support.
>> I am trying to use resolvconf as such layer.
> 
> systemd-resolved is already enabled in Ubuntu 18.04 (but not fully) and
> now in Fedora 33 (which goes a long way of integration into the system).
> 
> It also provides a D-Bus interface which is reasonable to integrate with.
> 
> This solved use cases we have for customers connecting Ubuntu machines
> to OpenVPN Cloud, where DNS is a big part of the Cloud solution.
> 
>> I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first
>> class citizens in Fedora, even when they are not installed by default.
>> Of course, also knot-resolver and pdns-recursor should be supported, if
>> they are (willing and) able to.
> 
> dnsmasq and unbound are great packages as well, but they are not really
> designed for system integration in the same level as systemd-resolved
> when considering today's ever changing network topology.  Just take an
> average laptop user today - how many various networks might that user
> connect during a day, especially when travelling?

I have been using dnssec-trigger, which acts as DNSSEC enabled and
unbound split DNS provider for 4 years, also during travels on train. I
admit it hit some issues on weird networks, but nothing serious. dnsmasq
also has good integration with Network Manager, just use dns=dnsmasq. I
disagree they are not ready for laptop users. They both work fine. And
both do not block DNSSEC by default like systemd-resolved does.
> 
> Since we have the impression systemd-resolved is becoming more and more
> used by default, we figured that would be a reasonable service to
> integrate with.  It also seems to handle the various use cases of
> roadwarriors pretty well as well as virtualised servers.  Plus it
> provides a reasonable D-Bus API to work with (more on that below).
I am not sure it is becoming default for its quality or its push from
systemd developers. Sure, it is whole driven by dbus. Dnsmasq has split
DNS configuration available from dbus, it just is not enabled by
default. None of more serious DNS caches has dbus interface I think.
> 
> OpenVPN 3 Linux aims to run with as least privileges as possible.  And
> tt tries to integrate with the basic existing network components on the
> system.  But running with least privileges is a challenge with lots of
> the network stack, as it requires some elevated privileges.  So
> OpenVPN 3 Linux is split up into several components doing a dedicated task.

By the way, how would OpenVPN 3 work on windows, where I expect dbus
support is missing? Does it have similar equivalent also to
systemd-resolved local cache? Can it archieve split DNS?
> 
> == Some OpenVPN 3 Linux architecture details ==
> 
> The most privileged service running is the openvpn3-service-netcfg
> (net.openvpn.v3.netcfg).  This is responsible for creating and configure
> TUN interfaces (with or without kernel acceleration), setting up routes
> and DNS.  But it runs as the openvpn:openvpn user with CAP_NETADMIN.  If
> using the resolv.conf approach (currently the default, which edits
> /etc/resolv.conf directly - which IS nasty), it also adds CAP_DAC_OVERRIDE.
It is about 2 years when we were removing CAP_DAC_OVERRIDE from our
services, because selinux-policy does not grant it anymore. I think it
is a good thing. Running as openvpn user, but requiring then
CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root
users without this permission would have. I would suggest reconsider
such design and run netcfg as root, just with dropped capabilities
except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call
should not pose significant threat.

> 
> But we generally try to avoid exec() any external code and depend on
> available APIs on the host, whether it is Kernel Netlink, libc related
> interfaces or D-Bus.  In fact, the script-hooks found in OpenVPN 2.x is
> non-existing in OpenVPN 3 Linux.

In such situation, calling resolvconf as a helper seems secure enough. I
don't see any value in avoiding exec(), when CAP_DAC_OVERRIDE were not
first to purge. Please reach to selinux-policy maintainers to discuss
the best solution. I think DAC_OVERRIDE should be avoided if possible,
let them confirm it.

> You can however achieve similar features (but with some more work
> currently) by subscribing to various D-Bus signals OpenVPN 3 services
> sends.  The openvpn3-add

Re: OCaml 4.12

[Richard W.M. Jones]

Another problem is there is a circular dependency going through
ocaml-odoc.  I believe it's this (although there could be others):

ocaml-odoc ->  
BR: ocaml-markup ->
BR: ocaml-lwt ->
BR: ocaml-luv ->
BR: ocaml-ctypes ->
BR: ocaml-integers ->
BR: ocaml-odoc

I broke it by excluding ocaml-odoc, but that caused lots of packages
to fail to build, so now I'm trying to build them by hand which is a
bunch of work.

We might need to remove a dependency somewhere to break the cycle, as
we did with dune.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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: Dilemma: -source repository data randomized by koji builder arch

[Fabio Valentini]

On Fri, Feb 26, 2021 at 8:38 AM Miroslav Suchý  wrote:
>
> Neal is correct that you only need to **query** on different architecture.

That is correct.

However, querying all 25000+ .spec files from fedora every day is more
trouble than I asked for (and I don't even know how to "query on a
different architecture" (do I need qemu-static for that?), and all
that stil does not help me feed this information into a yum repository
for analysis / repoquery / etc.

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

[Richard W.M. Jones]

On Mon, Mar 01, 2021 at 11:47:41AM +, Richard W.M. Jones wrote:
> We might need to remove a dependency somewhere to break the cycle, as
> we did with dune.

I've removed the -doc subpackage from ocaml-integers.  (Also possibly
not related, but debuginfo generation was broken for this package so I
disabled that too.)

We may want to revisit this, although the -doc subpackage was more of
a nice-to-have.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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: split-DNS, resolvconf on Fedora (OpenVPN related issues)

[Kevin Kofler via devel]

Petr Menšík wrote:
> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our
> services, because selinux-policy does not grant it anymore. I think it
> is a good thing. Running as openvpn user, but requiring then
> CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root
> users without this permission would have. I would suggest reconsider
> such design and run netcfg as root, just with dropped capabilities
> except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call
> should not pose significant threat.

IMHO, the proper fix would be to have a proper facl on resolv.conf for the 
openvpn user.

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

Re: OCaml 4.12

[Richard W.M. Jones]

On Mon, Mar 01, 2021 at 11:59:22AM +, Richard W.M. Jones wrote:
> On Mon, Mar 01, 2021 at 11:47:41AM +, Richard W.M. Jones wrote:
> > We might need to remove a dependency somewhere to break the cycle, as
> > we did with dune.
> 
> I've removed the -doc subpackage from ocaml-integers.  (Also possibly
> not related, but debuginfo generation was broken for this package so I
> disabled that too.)
> 
> We may want to revisit this, although the -doc subpackage was more of
> a nice-to-have.

Thinking about this more, rather than remove the subpackage(s) (there
are several more), I've decided to make them conditional instead, so
we have the choice to still build them in future.

See:

https://src.fedoraproject.org/rpms/ocaml-integers/c/f40c89973e1e83b0df48950082892d02dadda8b2?branch=rawhide
https://src.fedoraproject.org/rpms/ocaml-compiler-libs-janestreet/c/9262ec1087cb3d4d0a62d3717f32911df54ac01f?branch=rawhide

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

shigofumi-0.9 license change

[Petr Pisar]

shigofumi-0.9 changed license from "GPLv3+ and GPLv2+" to
"GPLv3+ and LGPLv2+" because of a bundled gettext.h.

-- Petr



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

Logs from Open NeuroFedora Meeting: 1300 UTC on Monday, 1st March

[Aniket Pradhan]

Hi everyone,

Please find the logs from today's meeting below. We will meet again in 2 weeks.

Minutes: 
https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-03-01-13.00.html
Log: 
https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-03-01-13.00.log.html

Minutes in text format:

=
#fedora-neuro: NeuroFedora 2021-03-01
=


Meeting started by MeWjOr at 13:00:55 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2021-03-01/neurofedora.2021-03-01-13.00.log.html
.



Meeting summary
---
* Agenda  (MeWjOr, 13:03:41)
  * New introductions and roll call.  (MeWjOr, 13:03:48)
  * Tasks from last week's meeting.  (MeWjOr, 13:03:57)
  * Open Pagure tickets.  (MeWjOr, 13:04:02)
  * Open bugs check.  (MeWjOr, 13:04:06)
  * Open package reviews check.  (MeWjOr, 13:04:13)
  * Koschei packages check.  (MeWjOr, 13:04:18)
  * CompNeuro lab compose status check  (MeWjOr, 13:04:23)
  * Neuroscience query of the week  (MeWjOr, 13:04:28)
  * Next meeting day, and chair.  (MeWjOr, 13:04:36)
  * Open Floor  (MeWjOr, 13:04:41)

* New introductions and roll call  (MeWjOr, 13:05:11)
  * major/MeWjOr, Aniket Pradhan, (+5:30), random python stuff,
packaging...  (MeWjOr, 13:06:13)
  * omnidapps,Josh Santos, (+7:00), update python-matplotlib-scalebar
(omnidapps, 13:07:24)
  * iztokf, Iztok Fister Jr., (+1:00), packaging  (iztokf[m], 13:08:48)

* Tasks from last meeting  (MeWjOr, 13:09:28)
  * Tasks from the last meeting:

https://meetbot.fedoraproject.org/fedora-neuro/2021-02-15/neurofedora.2021-02-15-13.05.html
(MeWjOr, 13:09:44)
  * omnidapps MeWjOr : look into Venus to ascertain how much work
migration from Pluto would be -- work in progress  (MeWjOr,
13:11:01)
  * FranciscoD assign
https://bugzilla.redhat.com/show_bug.cgi?id=1922612 to omnidapps --
Done  (MeWjOr, 13:12:00)
  * omnidapps work on updating matplotlib-scalebar -- WIP  (MeWjOr,
13:12:23)
  * FranciscoD ping https://bugzilla.redhat.com/show_bug.cgi?id=1809405
for updates  (MeWjOr, 13:15:51)
  * MeWjOr complete https://bugzilla.redhat.com/show_bug.cgi?id=1821189
: snakemake -- WIP, more deps  (MeWjOr, 13:17:24)
  * LINK: https://pagure.io/fedora-infrastructure/issue/9664
(FranciscoD, 13:18:13)
  * FranciscoD file a bug with infra about neuro-sig packages not marked
in Koschei -- WIP: mizdebsk is looking into it  (MeWjOr, 13:18:45)
  * LINK: https://pagure.io/fedora-kickstarts/pull-request/759
(FranciscoD, 13:19:30)
  * FranciscoD add python3-pynn to f34+ kickstarts -- Done,
https://pagure.io/fedora-kickstarts/pull-request/759  (MeWjOr,
13:20:02)
  * ACTION: FranciscoD : Package bluepyopt:
https://bugzilla.redhat.com/show_bug.cgi?id=1849706  (MeWjOr,
13:22:10)
  * ACTION: MeWjOr Fix deps for snakemake and proceed with the review.
(MeWjOr, 13:22:35)

* Open Pagure tickets.  (MeWjOr, 13:22:55)
  * Tickets marked for discussion:

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
(MeWjOr, 13:23:03)
  * NeuroFedora at INCF Neuroinformatics Assembly:
https://pagure.io/neuro-sig/NeuroFedora/issue/427  (MeWjOr,
13:23:51)
  * Use Pluto instead of Venus:
https://pagure.io/neuro-sig/NeuroFedora/issue/421  (MeWjOr,
13:25:02)
  * ACTION: omnidapps work on how to get started with Pluto  (MeWjOr,
13:31:41)
  * ACTION: MeWjOr work on templates to transfer on Pluto  (MeWjOr,
13:32:27)
  * LINK: https://src.fedoraproject.org/rpms/pluto   (omnidapps,
13:32:59)

* Open bugs check.  (MeWjOr, 13:35:02)
  * NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr,
13:35:12)

* Open package reviews check.  (MeWjOr, 13:38:43)

* Koschei packages check.  (MeWjOr, 13:42:18)
  * Neuro-sig packages on Koschei:
https://koschei.fedoraproject.org/groups/neuro-sig  (MeWjOr,
13:42:35)

* CompNeuro lab compose status check  (MeWjOr, 13:44:02)
  * The comp neuro lab image task on Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
(MeWjOr, 13:44:23)
  * LINK: https://pagure.io/releng/failed-composes/issue/2291
(FranciscoD, 13:45:30)
  * F34 comp neuro image is building correctly  (MeWjOr, 13:47:00)
  * rawhide comp neuro image failed. Look into it if it continues to
fail  (MeWjOr, 13:47:53)
  * LINK: https://www.irccloud.com/pastebin/8cFKjSZg/   (omnidapps,
13:48:51)
  * rawhide comp neuro image failed. dependency issue.  (MeWjOr,
13:48:52)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1933615
(FranciscoD, 13:49:54)

* Neuroscience query of the week  (MeWjOr, 13:51:20)
  * If you find anything interesting, add it to this ticket here:
https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
13:52:55)
  * LINK:

https://www.incf.org/blog/new-publication-neuroinformatics-members-incf-community
(MeWjOr, 13:54:52)

* Next mee

Orphaned Telegram packages

[Vitaly Zaitsev via devel]

Hello all.

I decided to retire and orphan all Telegram packages from Fedora and RPM 
Fusion for the following reasons: [1].


Orphaned from Fedora:
rpms/tdlib

Orphaned from RPM Fusion:
free/libtgvoip
free/tg_owt
free/telegram-desktop

If someone interested, feel free to take them, but please read the [1] 
first.


[1]: 
https://lists.rpmfusion.org/archives/list/rpmfusion-develop...@lists.rpmfusion.org/thread/5A7MRE3BG66PQXSP263FUZ7XS5PMDNUV/


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

ELN SIG First Meeting

[Stephen Gallagher]

Thank you to everyone who responded to the WhenIsGood. While no time
was available for all respondents, I selected the time with the
greatest availability. We will hold the inaugural ELN SIG meeting on
Friday, March 12th at noon EST (1700 UTC). We will hold this meeting
on Freenode IRC in #fedora-meeting (or via matrix.org at
https://matrix.to/#/#fedora-meeting:matrix.org ). We can decide at
this meeting whether we want to hold meetings via videochat or
IRC/matrix.org in the future.

I'd like to encourage anyone interested in this meeting to submit
agenda topics by replying to this email. Currently the agenda consists
of:

* Populate the initial SIG membership
* Agree on rules for expanding SIG membership
* Form a group to maintain the SIG documentation

If you want to add a meeting reminder to your calendar, here is an iCal link:
https://apps.fedoraproject.org/calendar/ical/calendar/meeting/9920/?reminder_delta=5
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Orphaning the cura-lulzbot package set

[Tom Callaway]

This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.

Accordingly, I've orphaned the following packages:

* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot

~spot

P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dilemma: -source repository data randomized by koji builder arch

[Miroslav Suchý]

Dne 01. 03. 21 v 12:57 Fabio Valentini napsal(a):

trouble than I asked for (and I don't even know how to "query on a
different architecture" (do I need qemu-static for that?), and all


mock -r fedora-33-ppc64le shell

https://github.com/rpm-software-management/mock/wiki/Feature-forcearch

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Dilemma: -source repository data randomized by koji builder arch

[Neal Gompa]

On Mon, Mar 1, 2021 at 6:58 AM Fabio Valentini  wrote:
>
> On Fri, Feb 26, 2021 at 8:38 AM Miroslav Suchý  wrote:
> >
> > Neal is correct that you only need to **query** on different architecture.
>
> That is correct.
>
> However, querying all 25000+ .spec files from fedora every day is more
> trouble than I asked for (and I don't even know how to "query on a
> different architecture" (do I need qemu-static for that?), and all
> that stil does not help me feed this information into a yum repository
> for analysis / repoquery / etc.
>

You can just pretend by setting a different target. RPM knows all the
targets, even the non-default ones.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: OCaml 4.12

[Jerry James]

On Mon, Mar 1, 2021 at 7:02 AM Richard W.M. Jones  wrote:
> Thinking about this more, rather than remove the subpackage(s) (there
> are several more), I've decided to make them conditional instead, so
> we have the choice to still build them in future.

Sorry about that.  I thought I had broken the circular dependencies on
odoc, but obviously missed some.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-35-20210301.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 7/15 (aarch64), 1/16 (x86_64)

New failures (same test not failed in Fedora-IoT-35-20210227.0):

ID: 794426  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/794426
ID: 794435  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/794435

Old failures (same test failed in Fedora-IoT-35-20210227.0):

ID: 794399  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/794399
ID: 794408  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/794408
ID: 794424  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/794424
ID: 794429  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/794429
ID: 794432  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/794432
ID: 794433  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/794433

Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-35-20210227.0):

ID: 794391  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/794391
ID: 794392  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/794392
ID: 794393  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/794393
ID: 794422  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/794422

Passed openQA tests: 12/16 (x86_64), 7/15 (aarch64)

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.36 to 0.19
Previous test data: https://openqa.fedoraproject.org/tests/793084#downloads
Current test data: https://openqa.fedoraproject.org/tests/794422#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: OCaml 4.12

[Richard W.M. Jones]

On Mon, Mar 01, 2021 at 09:18:31AM -0700, Jerry James wrote:
> On Mon, Mar 1, 2021 at 7:02 AM Richard W.M. Jones  wrote:
> > Thinking about this more, rather than remove the subpackage(s) (there
> > are several more), I've decided to make them conditional instead, so
> > we have the choice to still build them in future.
> 
> Sorry about that.  I thought I had broken the circular dependencies on
> odoc, but obviously missed some.

No worries!  We really need a better way to visualise these
dependencies.  At the moment I'm trying builds and breaking the deps
as I find them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: OCaml 4.12

[Jerry James]

On Mon, Mar 1, 2021 at 9:26 AM Richard W.M. Jones  wrote:
> No worries!  We really need a better way to visualise these
> dependencies.  At the moment I'm trying builds and breaking the deps
> as I find them.

I agree.  The OCaml world is chock full of circular dependencies.  I
actually started writing a little tool over the Christmas break to
help me visualize dependency cycles and explore ways of breaking them.
Let me dust that off and see what still needs to be done to make it
useful.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Building custom kernels

[Brandon Nielsen]

On 2/28/21 12:00 PM, Julian Sikorski wrote:

W dniu 27.02.2021 o 20:59, Julian Sikorski pisze:

Hi,

I am trying to test some Renoir s2idle patches [1]. It appears that 
Fedora kernel source is now maintained on gitlab as kernel-ark [2]. 
What I tried is adding the patches to the fedora-5.11 branch and 
running make dist-srpm, but it failed due to config mismatch on 
CONFIG_INIT_STACK_NONE:


Processing 
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config 
... Error: Mismatches found in configuration files
Found CONFIG_INIT_STACK_NONE=y after generation, had 
CONFIG_INIT_STACK_NONE=is not set in Source tree

make[1]: *** [Makefile:145: dist-configs-check] Błąd 1

Is this expected? Is there a better way of testing patches on Fedora 
kernels? Thanks for the help in advance.


Best regards,
Julian

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
[2] https://gitlab.com/cki-project/kernel-ark


Hi,

the same keeps happening if I try to merge os-build into agdf5 tree or 
even if I try to make srpm in the ark-latest branch. Is this normal?


Best regards,
Julian



I found the same last week and the documentation[0] feels really unloved.

I eventually resorted to rebuilding from the SRPM and apply patches there.

[0] - 
https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/

 ___

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Re: OCaml 4.12

[Richard W.M. Jones]

z3 build was cancelled, unclear why:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 10, 2021 at 12:47:25PM -0500, Ben Cotton wrote:
> == Contingency Plan ==
> * Contingency mechanism: moving this change to Fedora 36, if not
> successfully finished until Fedora 35 branching from Rawhide
> * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
> * Blocks release? No

What is the final decision wrt. to compat package creation? With 190
packages failing to build, I think it's very likely that at least some
of those will still fail to build 5 months from now. The contingency
mechanism, as described, would be to postpone the update to F36 at that
point. I think this is not desirable, not least because it doesn't guarantee
that we will not have a very similar situation *12* months from now.

So instead, I'd very much propose to plan that a compat package will
be created, and that *some* packages will require autoconf-2.69, and
if they do, switch them over to use the compat package. *If* it turns
out early enough that the compat package is not needed, we can skip it.

Overall, I think things would go much smoother this way. With the
current plan, by creating a flag day, we're actually making it harder
to develop against 2.71, because it'll not be available in Fedora
until *everything* has been switched over.

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

Re: Self Introduction: Phil

[Matthew Miller]

On Sun, Feb 28, 2021 at 05:43:08PM -0800, Phil Dibowitz wrote:
> Hi I'm Phil, a new Fedora packager! Some of you may know me from
> devconf (both CZ and US) during my time at Facebook or as one of the
> co-founders of the Southern California Linux Expo (SCALE)
> conference. For the rest of you, hi, I'm Phil, nice to meet you! :)

Awesome, welcome!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: How to build RISC-V Fedora disk image by muself

[Brian C. Lane]

On Mon, Mar 01, 2021 at 07:28:49PM +0900, Takayuki Nagata wrote:
> I am not sure how the image is actually built, but I have tried to
> build an image with appliance-creator on a RISC-V VM, and the built
> image is bootable. In my case:

I'm curious to know if anaconda and livemedia-creator will run in this
environment. lmc wouldn't work if you were trying to build it from a
different arch, but if it is running on RISC-V it should work, in
theory, as long as anaconda supports it.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ELN SIG First Meeting

[Davide Cavalca via devel]

On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> I'd like to encourage anyone interested in this meeting to submit
> agenda topics by replying to this email. Currently the agenda

One thing I'd be interested in exploring is the feasibility of
extending ELN to cover EPEL as well. This would make it easier to keep
EPEL consistent between major releases (as packages would get branched
automatically). It would also make it possible to test the combined ELN
+ EPEL snapshot and find potential issues early on in the process.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

Hi,

On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede  wrote:
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683 
> > 
> > seems like this is already in updates.  you definitely have the gnome-shell 
> > 40.beta installed?  could be a pam_fprintd is returning a different error 
> > code than expected for no enrolled fingerprint
So we've been investigating this in the above upstream link.

There is a case where pam_fprintd is returning a code we aren't
expecting, but, it shouldn't ever happen :-)

pam_fprintd checks up front if there are no enrolled fingerprints and
then returns the correct error code in that case.

You guys are apparently getting past that part and failing later.
Almost as if the prints were there and then a split second later
disappeared.

One theory is there are files present, but they're unreadable. Maybe
because of selinux?

Can you try in permissive mode, also output ls -lRZ /var/lib/fprint

> Any debugging options which I can enable somewhere to show the pam_fprintd 
> error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so
in /etc/pam.d/fingerprint-auth
that should make the journal more chatty.

--Ray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Michael J Gruber]

So, you list 3 typical reasons why packages in rawhide FTBFS and 2 existing 
policies which are meant to prevent 2 of these 3 reasons if packagers followed 
these policies. And you want these policies to be enforced technically

What I am missing is:
- A viable suggestion on how to prevent the third reason (pushes for sidetag 
builds, your #2.) within your proposal.
- Any mentioning of what provenpackagers could do to avoid conflicts.

I completely agree that FTBFS in rawhide is annoying. But not every policy can 
be enforced technically. We have scratch builds for PRs in dist-git, which is 
great. But (if this hasn't changed lately) I cannot fork my own dist-git repo 
and file a PR, so I cannot use that to communicate my intentions to a 
provenpackager nor to my co-maintainers. I cannot even use that to build into a 
sidetag.

I think it's quite simple - If I as a maintainer break it I need to fix it, 
that's the deal. And as Fedora packagers we have a *lot* of infrastructure at 
our disposal (koji, koschei etc.) which helps us with that task. If there are 
rough edges (such as the one mentioned above) we should work on improving the 
tools.

Personally, my packages FTBFS only when there is a change in the compiler chain 
or a library or rpm build macros or such. No technical solution that checks my 
pushes would prevent those FTBFS or even alert me to them.

OTOH, sidetag or copr builds such as done for upcoming python versions are a 
great way to alert packagers before everything breaks on rawhide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

FedoraRespin-33-updates-20210301.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/37 (x86_64)

ID: 794467  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/794467
ID: 794484  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/794484
ID: 794489  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/794489
ID: 794497  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/794497
ID: 794500  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/794500

Passed openQA tests: 32/37 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ELN SIG First Meeting

[Kevin Fenzi]

On Mon, Mar 01, 2021 at 07:45:09PM +, Davide Cavalca via devel wrote:
> On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > I'd like to encourage anyone interested in this meeting to submit
> > agenda topics by replying to this email. Currently the agenda
> 
> One thing I'd be interested in exploring is the feasibility of
> extending ELN to cover EPEL as well. This would make it easier to keep
> EPEL consistent between major releases (as packages would get branched
> automatically). It would also make it possible to test the combined ELN
> + EPEL snapshot and find potential issues early on in the process.

I'm not sure exactly what you mean here... 

I think (please correct me if I'm wrong) you are wanting "all EPEL
packages" to also be built as part of ELN and shipped as some sort of
'EPEL-ELN' ?

The main problem with this is that "all EPEL packages" is not a defined
set like ELN is. EPEL is not a specific collection of packages. It's
packages which have maintainers that wish to maintain them. For this
(and other) reasons we have never mass branched epel, we have always let
maintainers branch when they wish to support that branch. 

I'm not sure if there's a way around this... I suppose we could try and
collect a list of packages where maintainer(s) always want to branch
them, but that would need to be a living document/list and would
probibly be hard to keep up to date. 

kevin


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

Re: ELN SIG First Meeting

[Stephen John Smoogen]

On Mon, 1 Mar 2021 at 14:46, Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > I'd like to encourage anyone interested in this meeting to submit
> > agenda topics by replying to this email. Currently the agenda
>
> One thing I'd be interested in exploring is the feasibility of
> extending ELN to cover EPEL as well. This would make it easier to keep
> EPEL consistent between major releases (as packages would get branched
> automatically). It would also make it possible to test the combined ELN
> + EPEL snapshot and find potential issues early on in the process.
>
>
That would require a lot of changes in both EPEL and in Fedora. In Fedora
there is a general expectation that if a 'branch' is active then it is
maintained by someone.. usually the primary maintainer.  Many Fedora
maintainers are only interested in maintaining packages in the latest
release. THis is why the ELN packages are being 'watched/maintained' by the
ELN team and sig. Maintainership usually means dealing with bug reports,
build failures, etc which can take up a good amount of time.

This is part of the reason why EPEL packages are not auto-forked for each
EL release. Most maintainers are only interested in supporting maybe EL-6
or EL7 and we need to find someone new to do the EL-8 branch. We would need
to have a dedicated team of people to do this with ELN related items. We
would also need to have additional build and storage resources to deal with
these artifacts, not alone the growth of 'just need this' packages. When I
was trying to make EPEL-8 1:1 with EPEL-7 I found I was having to add more
and more packages just to get the new build 'requires:' done. I stopped
around a thousand 'new' packages to the tree when I was reminded that we
don't do automatic branching for EPEL. I really don't know how many
packages would be needed to make it work, but do know it is a full time job
to get set up and keep going. While ELN is probably 4000 src.rpms we would
be looking at needing to build/rebuild double that for EPEL.




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


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

Does Koji cancel builds when a new build is submitted?

[Richard W.M. Jones]

And if so it this a new behaviour?

I'm only wondering, not because I think this is bad, but because I've
seen a bunch of builds today being cancelled and I wonder why it is
happening.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: How to build RISC-V Fedora disk image by muself

[Richard W.M. Jones]

On Mon, Mar 01, 2021 at 11:12:25AM -0800, Brian C. Lane wrote:
> On Mon, Mar 01, 2021 at 07:28:49PM +0900, Takayuki Nagata wrote:
> > I am not sure how the image is actually built, but I have tried to
> > build an image with appliance-creator on a RISC-V VM, and the built
> > image is bootable. In my case:
> 
> I'm curious to know if anaconda and livemedia-creator will run in this
> environment. lmc wouldn't work if you were trying to build it from a
> different arch, but if it is running on RISC-V it should work, in
> theory, as long as anaconda supports it.

Our long term aim is that Fedora/RISC-V will behave exactly as any
other architecture.  No special changes/workarounds should be
necessary.  For common things we're already there.  To try it out,
suggest setting up a VM as described here:

https://fedoraproject.org/wiki/Architectures/RISC-V/Installing

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Justin Forbes]

On Sun, Feb 28, 2021 at 12:00 PM Julian Sikorski  wrote:
>
> W dniu 27.02.2021 o 20:59, Julian Sikorski pisze:
> > Hi,
> >
> > I am trying to test some Renoir s2idle patches [1]. It appears that
> > Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What
> > I tried is adding the patches to the fedora-5.11 branch and running make
> > dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE:
> >
> > Processing
> > /home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config
> > ... Error: Mismatches found in configuration files
> > Found CONFIG_INIT_STACK_NONE=y after generation, had
> > CONFIG_INIT_STACK_NONE=is not set in Source tree
> > make[1]: *** [Makefile:145: dist-configs-check] Błąd 1
> >
> > Is this expected? Is there a better way of testing patches on Fedora
> > kernels? Thanks for the help in advance.
> >
> > Best regards,
> > Julian
> >
> > [1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
> > [2] https://gitlab.com/cki-project/kernel-ark
>
> Hi,
>
> the same keeps happening if I try to merge os-build into agdf5 tree or
> even if I try to make srpm in the ark-latest branch. Is this normal?
>
I am guessing you are currently on F32? There are unfortunately some
config options which are gcc version dependent.  I know it has been
complained about upstream, but they exist.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: split-DNS, resolvconf on Fedora (OpenVPN related issues)

[Petr Menšík]

I don't think it is so easy. It can add facl on resolv.conf file before
it drops privileges. But Any other process might remove the file again
and write a new one, preventing openvpn to update it later. Because
openvpn is not supposed to be owner of /etc/resolv.conf, it should not
dictate what rights it needs.

For example dnsmasq solves similar problem by forking second process
connected by a pipe with original. Original then drops privileges and
switches to unprivileged user, just keeping NET_ADMIN to be able
reopening privileged ports. When it requires lease changes, it sends
request over pipe to process still with enough privileges. Because it
does not have any other sockets open to attackers, it just have to check
input data sufficiently. I think similar position might have netcfg
part. It seems safe enough to keep root privileges to manipulate
resolv.conf (or resolvconf).

On 3/1/21 2:35 PM, Kevin Kofler via devel wrote:
> Petr Menšík wrote:
>> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our
>> services, because selinux-policy does not grant it anymore. I think it
>> is a good thing. Running as openvpn user, but requiring then
>> CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root
>> users without this permission would have. I would suggest reconsider
>> such design and run netcfg as root, just with dropped capabilities
>> except CAP_NET_ADMIN, if it needs to modify resolv.conf. resolvconf call
>> should not pose significant threat.
> 
> IMHO, the proper fix would be to have a proper facl on resolv.conf for the 
> openvpn user.
> 
> Kevin Kofler

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Lennart Poettering]

On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:

> > 1. Dots (".") for separating IPV4 address bytes
> > 2. Colons (":") for separating IPv6 address parts, as well as separating
> >   port numbers from the IP addres
> > 3. Brackets ("[]") for separating ipv6 addresses from the rest of the
> >   construct
> > 4. Percent ("%") characters to separate interface info from the rest
> > 5. Hash ("#") characters to separate SNI host name specifications
> >
> > Now, we currently don't use "," and ";" for separators here, but as
> > these things keep growing we might need them for something soon too.
>
> I understand your willingness to apply the same rules for multiple
> options in the config files owned by systemd codebase. This, however, is
> a content pushed out by external parties, not a part of systemd
> proper.

It's a configuration file *owned* by resolved. it's its private
property, with defined and documented syntax. if other tools make
changes to that config files, but they better follow the documented
syntax then.

I'd be a lot more open to a more relaxed parser if this was some
"foreign" config file, not owned by resolved. i.e. /etc/resolv.conf is
owned by glibc and is maybe even more generic than that. There it's
our duty to to accept even the worst formatted files.

But resolved.conf is inherently only ours, we define the contents and
are the sole consumer of it. Hence I think we don't have to be and
shouldn't be so lenient, so that the variances remain smaller.

I mean, I#d consider the original issue here a simple bug. The
question is simply where to fix it: in cloud-init or in systemd. Given
that cloud-init is responsible for it, and given that either way
there's exactly one project to fix I think it should be cloud-init
that is fixed.

> Digital Ocean updates pushed with cloud-init use. Cloud-init does not
> have any native support for systemd-resolved. It means it writes
> something that systemd-resolved imports into own state. I would argue
> that your arguments for systemd-wide configuration rules do not apply
> here. Either you'd need to fix cloud-init or allow for a variance in
> input data that comes to systemd-resolved from third parties.

Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd-resolved fallback DNS servers: usability vs. GDPR

[Ed Greshko]

On 02/03/2021 06:03, Lennart Poettering wrote:

On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:


Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.

Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?



Pardon my "editorial" comment here.  I'm rather down on Digital Ocean.  Servers 
in their
network have been responsible for the majority of sustained brute force ssh 
attacks on my
systems.  I find myself filing multiple abuse reports with them weekly.

--
People who believe they don't make mistakes have already made one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd-resolved fallback DNS servers: usability vs. GDPR

[Michael Catanzaro]

On Mon, Mar 1, 2021 at 11:03 pm, Lennart Poettering 
 wrote:

Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?


I think they've deployed something entirely custom.

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

[Francisco J . Tsao Santín via devel]

On Mon, 1 Mar 2021, Vitaly Zaitsev via devel wrote:

> I decided to retire and orphan all Telegram packages from Fedora and RPM
> Fusion for the following reasons: [1].
> 

Sad to read this. Thanks for the work of these years, I have used the
telegram-desktop package for years.

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ELN SIG First Meeting

[Davide Cavalca via devel]

On Mon, 2021-03-01 at 12:47 -0800, Kevin Fenzi wrote:
> I'm not sure exactly what you mean here... 
> 
> I think (please correct me if I'm wrong) you are wanting "all EPEL
> packages" to also be built as part of ELN and shipped as some sort of
> 'EPEL-ELN' ?

Yes, the idea I had in mind was that each package that currenty has an
"epel8" branch would also get an "epeln" branch that would be built
against ELN. Then when ELN branches into CentOS Stream, the epeln
branches could be used as the starting point for the corresponding EPEL
release.

> The main problem with this is that "all EPEL packages" is not a
> defined
> set like ELN is. EPEL is not a specific collection of packages. It's
> packages which have maintainers that wish to maintain them. For this
> (and other) reasons we have never mass branched epel, we have always
> let
> maintainers branch when they wish to support that branch. 
> 
> I'm not sure if there's a way around this... I suppose we could try
> and
> collect a list of packages where maintainer(s) always want to branch
> them, but that would need to be a living document/list and would
> probibly be hard to keep up to date. 

Yeah, that's a good point. To be clear, I was not proposing to do this
for all Fedora packages, just for the ones that were already present in
the current EPEL.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

[Miro Hrončok]

On 01. 03. 21 21:29, Michael J Gruber wrote:

But (if this hasn't changed lately) I cannot fork my own dist-git repo and file 
a PR, so I cannot use that to communicate my intentions to a provenpackager nor 
to my co-maintainers.


You can. Not just lately, you always could, since Pull Requests were possible.

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

Re: ELN SIG First Meeting

[Davide Cavalca via devel]

On Mon, 2021-03-01 at 15:49 -0500, Stephen John Smoogen wrote:
> That would require a lot of changes in both EPEL and in Fedora. In
> Fedora there is a general expectation that if a 'branch' is active
> then it is maintained by someone.. usually the primary maintainer. 
> Many Fedora maintainers are only interested in maintaining packages
> in the latest release. THis is why the ELN packages are being
> 'watched/maintained' by the ELN team and sig. Maintainership usually
> means dealing with bug reports, build failures, etc which can take up
> a good amount of time.

That's a fair point. To be clear, I would not expect this to happen by
itself -- it this idea turns out to be feasible, I would be happy to
pitch in and/or try and find resources to help with this from my end.

> This is part of the reason why EPEL packages are not auto-forked for
> each EL release. Most maintainers are only interested in supporting
> maybe EL-6 or EL7 and we need to find someone new to do the EL-8
> branch.

Interesting, I had not realized this was the case. My (likely naive)
assumption was that if there's an epelX branch for a given package,
there would likey be an epelX+1 too, and when that wasn't the case it
was mostly because the maintainer hasn't gotten around it yet or nobody
had asked. My assumption was that by providing a readily updated
"epeln" branch we would save the maintainer some of this work.

Are you saying that for some packages it is expected that the
maintainer would only care about say epel7 and not epel8? In that case,
do we / would we track the maintainer for epel8 specifically somewhere,
if one were to volunteer?

> We would need to have a dedicated team of people to do this with ELN
> related items. We would also need to have additional build and
> storage resources to deal with these artifacts, not alone the growth
> of 'just need this' packages. 

Is there an easy way to ballpark estimate the resource demand that an
effort like this would require?

> When I was trying to make EPEL-8 1:1 with EPEL-7 I found I was having
> to add more and more packages just to get the new build 'requires:'
> done. I stopped around a thousand 'new' packages to the tree when I
> was reminded that we don't do automatic branching for EPEL. I really
> don't know how many packages would be needed to make it work, but do
> know it is a full time job to get set up and keep going. While ELN is
> probably 4000 src.rpms we would be looking at needing to
> build/rebuild double that for EPEL.

Ah, that's fair. I hadn't thought about potentially neededing to branch
extra packages to meet new build dependencies, but you're absolutely
right, that would be a major issue here.

I should probably expand on why I'm thinking about this in the first
place. I want to use ELN as a proxy for the next CentOS Stream release
to streamline its qualification on our infrastructure. The idea being
that if we can continously test ELN on a small subset of production,
that will detect potential issues early on, allow us to get ahead of
policy changes that might require internal work, and hopefully surface
bugs that we can report and fix upstream long before branch time.

However, we use EPEL a lot in our infrastructure, to the point that I
suspect it would be difficult to do a meaningful prod-like deployment
with ELN alone. I could probably hack something around this, but I
figured it'd be worth to see if we can build a generic solution instead
that could benefit Fedora and CentOS upstream, rather than something
Facebook specific. To be clear, I'm aware that this would require work
and resources within Fedora, and I'd be happy to help with both as
needed if this is deemed feasible.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: split-DNS, resolvconf on Fedora (OpenVPN related issues)

[Kevin Kofler via devel]

Petr Menšík wrote:
> I don't think it is so easy. It can add facl on resolv.conf file before
> it drops privileges. But Any other process might remove the file again
> and write a new one, preventing openvpn to update it later. Because
> openvpn is not supposed to be owner of /etc/resolv.conf, it should not
> dictate what rights it needs.

Well, what I propose is really to have a systemwide file ACL set by the RPM 
owning resolv.conf, listing all system users that need write access to the 
file, and openvpn would be one of them.

If something then overwrites the file losing the ACLs, that something needs 
to be fixed then.

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

Re: How to build RISC-V Fedora disk image by muself

[Matthew Miller]

On Mon, Mar 01, 2021 at 09:28:40PM +, Richard W.M. Jones wrote:
> > > I am not sure how the image is actually built, but I have tried to
> > > build an image with appliance-creator on a RISC-V VM, and the built
> > > image is bootable. In my case:
> > 
> > I'm curious to know if anaconda and livemedia-creator will run in this
> > environment. lmc wouldn't work if you were trying to build it from a
> > different arch, but if it is running on RISC-V it should work, in
> > theory, as long as anaconda supports it.
> 
> Our long term aim is that Fedora/RISC-V will behave exactly as any
> other architecture.  No special changes/workarounds should be
> necessary.  For common things we're already there.  To try it out,
> suggest setting up a VM as described here:

I really, really, really suggest focusing on either
anaconda/livemedia-creator or osbuild (aka composer, aka weldr). These are
maintained by actual active teams. appliance-creator (and omg ThinCrust --
there's a blast from the past) are at best lightly kicked down the road
whenever serious problems develop.

-- 
Matthew Miller

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

[Julian Sikorski]

Am 01.03.21 um 22:37 schrieb Justin Forbes:

On Sun, Feb 28, 2021 at 12:00 PM Julian Sikorski  wrote:


W dniu 27.02.2021 o 20:59, Julian Sikorski pisze:

Hi,

I am trying to test some Renoir s2idle patches [1]. It appears that
Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What
I tried is adding the patches to the fedora-5.11 branch and running make
dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE:

Processing
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config
... Error: Mismatches found in configuration files
Found CONFIG_INIT_STACK_NONE=y after generation, had
CONFIG_INIT_STACK_NONE=is not set in Source tree
make[1]: *** [Makefile:145: dist-configs-check] Błąd 1

Is this expected? Is there a better way of testing patches on Fedora
kernels? Thanks for the help in advance.

Best regards,
Julian

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
[2] https://gitlab.com/cki-project/kernel-ark


Hi,

the same keeps happening if I try to merge os-build into agdf5 tree or
even if I try to make srpm in the ark-latest branch. Is this normal?


I am guessing you are currently on F32? There are unfortunately some
config options which are gcc version dependent.  I know it has been
complained about upstream, but they exist.

Justin


I am on F33 x86_64. In case F33 is affected too, is there a workaround 
beyond building the kernel from a rawhide VM?


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

Fedora-Cloud-33-20210302.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210301.0):

ID: 794899  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/794899
ID: 794906  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/794906

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: How to build RISC-V Fedora disk image by muself

[Florian Weimer]

* Matthew Miller:

> I really, really, really suggest focusing on either
> anaconda/livemedia-creator or osbuild (aka composer, aka weldr).

Isn't the original weldr gone (as in, last commit in mid-2018)?  And
it's lorax once more?

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